Data Placement: Who’s Architecture is Really Broken?

Anonymous — Thu, 07 Aug 2008 22:17:00 GMT

I just read a blog where Chuck Hollis (http://chucksblog.typepad.com/chucks_blog/2008/07/the-great-data.html) of EMC launched an attack on storage virtualization. Called us all “spindle randomizers.” He based this attack on the idea that you can’t mange performance on virtualized arrays. Chuck seems to believe that you can’t make an array perform without manually placing every byte on every platter. That’s a misguided idea that’s got to be challenged. Unfortunately Chuck seems to be missing the bigger issues. Labor has become the largest cost in an IT organization. Not software. Not hardware. Not even power & cooling. Labor! The cost to manage all of that IT infrastructure. We recently asked storage managers what they need most. Did they say capacity? No. Did they say performance? Certainly not! Their top concern is administrative costs. With the amount of digital data doubling every 18 months the top issue is managing all of that data and the infrastructure that stores it. That kind of data growth drives complexity in a big, big hurry. We’ve got to fight that complexity with simplicity at every opportunity. Storage array virtualization is a critical foundation for fighting that complexity. With it 90%+ of the storage needs can be met with a simple create, present, and let it run. You don’t have to make a bunch of extra decisions that the machine could have made just as well. And you don’t have to come back and handle simple issues that the machine can manage just fine. You’re freed up to spend your time on the hard problems, be they performance, capacity utilization, or other, where a person really adds value. Without array virtualization the mind numbing details suck up the time and keep you from the interesting and important problems. There just aren’t enough hours in the day! But what about the cases where you do need to manage the performance? Go ahead! That’s why the EVA has disk groups and performance tools. There’s nothing in a virtualized array that prevents you from doing the tuning you need. You just don’t have to when you don’t need to. That’s critical. There aren’t enough hours in the day to be tuning every LUN!

Chuck tries to paint a vision where SSD’s make manually managing all the details a requirement. A wave of the future. But that’s a productivity killing tsunami. Nobody can afford all of that time! Virtualized arrays have been handling multiple drive speeds for years. We’ll do just fine with SSD’s. The issue Chuck’s trying to hide is that EMC’s CX architecture doesn’t include storage virtualization. They’ve got an inherent limiter that’s going to be very hard to overcome. We “spindle randomizers” aren’t going to be the ones that have to live with the consequences of our architecture. It’s Chuck and company. Good luck guys!

Storage Just got SASsy! VMware set free of the SAN.

jasontreu — Tue, 22 Jul 2008 02:24:00 GMT

By Lee Johns, director of marketing, StorageWorks Entry Storage and Storage Blades, HP

Serial Attached SCSI (SAS). Does not sound very exciting really does it? Many of you will know SAS as a class of disk drives found in servers and arrays but how many have ever though of using SAS as an interconnect for storage instead of Fibre Channel or iSCSI? Probably not many and with good reason. SAS is a point to point protocal that can not compete today with the sophistication of network storage toploogies like Fibre Channel and iSCSI for Enterprise Arrays.

But what if you just want to deliver a simple solution for shared boot, or a VMware infrastructure that enables Vmotion without a SAN, or you have an application that performs best with a direct attached storage architecture but you want better storage utilization. Now the cost and complexity of a SAN seems somewhat redundant. Why is there no way to provide the performance you need with the consolidation and utilization of a SAN without the overhead of an expensive fibre channel network infrastructure or leaving things as they are with existing direct attached storage (DAS)?

There is an answer. It is using SAS as a shared storage interconnect and with it you can build much simpler shared storage environments that can be managed by a server administrator. This saves you time, money and enables you to build the best architecture for any application. It is not a replacement for the traditional SAN but it is an enhancement to DAS that places the data and control where it should be and does not force fit a SAN as the answer to all storage problems.

Shared SAS solutions are available today and I encourage you to think where they could help you improve your Direct Attached Storage architectures and augment the SAN. SAS began as an internal server interconnect so maybe it is no surprise that dedicated storage vendors like EMC and NetApp are ignoring SAS as an interconnect. They feel it is threatening to them and that is exactly why you should be taking a serious look!

Around the Storage Block Blog : virtualization, SAN

Data Placement: Who’s Architecture is Really Broken?

Storage Just got SASsy! VMware set free of the SAN.