Claus, someone should smack you up for bad math! And the HBP smackups continue

Claus Mikkelsen at HDS wrote in his most recent blog post:

Having a 700% improvement in workload throughput is equivalent to having 105,000 RPM drives (very crude arithmetic and workload assumptions, but you get the point; don’t beat me up on this!).

What??  "don't beat me up on this"  Claus, what sort of lame disclaimer is that??  If you are going to write something stupid - and you know it when you are writing it, don't beg for mercy like a stoolie.  The math checkers in the storage blogosphere will find out and then decide if they want to give you a heaping load of sh%& for it. 

But I'm going to cut you slack because you are promoting wide striping, an excellent technology that doesn't get enough attention.  So, thanks.  We're really good at wide striping in 3PAR arrays and we appreciate the fact that HDS is trying to help people understand how well the technology can work - even if the explanation you provided is screwed up. While I'm at it, let me give you props for this line too:

I’ll defy anyone to manually provision in a way that will outperform the wide striping we do with HDP

A page from the 3PAR hymnal! - except you don't have to be using thin provisioning on a 3PAR array in order to get wide striping.  Automated provisioning in 3PAR arrays provides wide striping that performs much better than can be achieved with manually tuning. Not only that, but the utilization levels with 3PAR arrays are very high - especially for mixed workloads, where customers often want to store data for different applications on different RAID levels or tiers. 

With HBP (HDS Bloated Provisioning) - if application data is stored on different RAID levels you need different pools for each RAID level, which means you have to divide your disk resources between pools, which means your wide stripes aren't as wide and the performance advantages of wide striping are diminished. The other problem with using multiple pools is that utilization tends to be lower because disk resources are leveraged unevenly across different subsets of applications.

Nigel Poulton, who is a pretty good guy for a dyed-in-the-wool HDS cheerleader, and I have been videoing back and forth about HBP and 3PAR's thin provisioning differences.  I seem to recall him saying that you could setup an HDS array with a single pool.  Really Nigel - would that be s serious recommended best practice? All data stored in one RAID level?

Tony Asaro, in his blog,  quoted Nigel as saying:

For a start it maps perfectly with the internal workings of the USP V and VM.

Which was my point - Hitachi's engineer's did it to make it easier for themselves as opposed to fitting it to customer requirements.  Which leads me to Nigel's metadata fixation where he assumes that all metadata processes obey the same immutable rules of coding. They don't. That's because processes that are core design concepts usually are more efficient than bolt-on afterthoughts.  

Comments

[Nigel]

In bit of a hurry myself this time, so will pen something better later on.

But a quick point -

I believe (and as you know I dont work for HDS) that keeping each HDP pool to a single RAID level is merely an HDS best practice. I know that you can mix and match RAID levels within a single pool if you want to, HDS just dont recommend it. In fact on page 6 of my HDP best practices guide that I wrote ages ago I list advantages and disadvantes of homogeneous (everything the same) and heterogeneus (different RAID, spindles size....) pools. If you want to know HDP I suggest you have a gander, its the best HDP document out there in my humble opinion - Its a PDF @ http://blogs.rupturedmonkey.com/?p=274

One of the good things about HDP - you have a lot of choices - mix and match RAID if you want. Have multiple pools if you want. Flexibility.....

Oh and as for me being an HDS cheerleader. Dont know what the cheerleaders at your school looked like, but I doubt they looked anything like me ;-)

Nigel

[marc farley]

Thanks Nigel, the documents you have written have been an excellent source of information on HDS arrays for some time now. Most vendors in this industry wish we had somebody like you on our sides!

If you think its possible to mix RAID types in a single pool on USP arrays, then you are probably correct. I wouldn't have any reason to doubt it and I expect you'll get to the bottom of it.

My point is why have pools at all? I don't see how establishing another layer of physical resource management improves the flexibility of the array. For all the boasting that HDS does about their virtualization technology, you'd think they would try to eliminate physical control points instead of creating new ones.

Compare this to 3PAR's approach which is to have the system virtualize all disk drive resources into small pieces (chunklets) that are automatically RAID-striped and concatenated into virtual volumes. 3PAR admins create and manage virtual volumes, choosing the RAID type they want without having to choose or reserve the disks they want to use first. Creating a new volume from scratch and bringing it online is amazingly simple.

Watch this highly paid consultant do it in this video: http://www.youtube.com/watch?v=g0UoCkpo0yY

[3parNovice]

Why choose a RAID type, if it is already RAIDed with parity on the back end?

[marc farley]

Storage is usually not "pre-RAIDed" but needs to have a RAID level assigned by an administrator to meet requirements with capacity, performance and data protection variables.