Data Placement: Who’s Architecture is Really Broken?

[#1]

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!

[#2]

Funny... we are on the same page.  Labor costs and keeping

down complexity (complexity certainly drives up head count).

We see who is coming down the pike with simpler solutions

also (I work for a VAR/reseller/integrator).  Just the other day

commenting internally in reponse to this:

virtualgeek.typepad.com/.../our-vmware-cent.html

Author writes and I respond:

- end-to-end QoS mechanisms since it will be a unified fabric

      No.  As we learned from the initial Brocade DCF talk/meeting a while back (March?),  QoS is for

     (read: ).  Brocade is cut-through routed.  *MUCH* better than store and forward (cough... cough).

      And oh... while I'm jabbing.  The only reason the older needed QoS was a knob for people to tweek

      their underpowered  (compared to IBM's DS series for example).  We're busy or challenged (see below) - don't need more knobs!

And:

Most customers I talk to don't even leverage what they already have :-)

   Most customers don't leverage what they have because their staffs are either:

        - challenged  OR

        - working like rented mules and do indeed have a life outside of work

...

So yes I agree, the complexity needs to be hidden and

automated.  Regarding SSDs - not sure yet.  The cost is obviously quite high and I'm sure their are tipping points in design decisions all over the place (i.e. if we go with SSDs , we are going to need 4 mirrored pairs, transaction

turnaround time isn't that critical and will blow

our budget... blah blah blah).

[#3]

Thanks for the comment Rob!

[#4]

Quote

That’s why the EVA has disk groups and performance tools.

Performance tools?  Any available to the customer ?

We can gather the performance data with evaperf, but the supplied tool to analyze this data (TLviz_formatter) actually wrecks it (wrong data in tables, wrong table header, etc).

Pretty useless...

Do I hear Storage Essentials ?  My pockets aren't that deep...

Any other suggestion ?