Anyone Interested in a 105,000 RPM Drive?
by Claus Mikkelsen on Jun 29, 2009
There has been so much discussion in the past 2 weeks over Hitachi Dynamic Provisioning (HDP) and the size of our pages which are, by comparison, large when compared to other thin provisioning implementations. As we all recall from our first course in Computing 101 and memory management, larges pages in memory provide better performance but at the expense of using more capacity. In the “olde” days of extremely expensive memories, large pages were considered a very bad thing. Now let’s look at this phenomenon as it applies to storage, and we see a different argument since: (1) the scale of costs is dramatically different, (2) we’re only looking at disk access, not the majority of I/O which is typically satisfied out of cache, and (3) in our HDP implementation, we actually can use the entire 42 MB page depending on whether the next WRT is sequential or random. I won’t rehash all the arguments here; you can read them all in Hu’s blog, Marc Farley’s, Nigel Poulton’s (replete with video; nice touch, Nigel!), not to mention Tony Asaro’s this morning.
But there is a related topic I’ve been wanting to write about for a while now, and it relates to the trade-off in memory management at it relates to HDP and page size. But before I dive into it, let me take you back in time and (re)introduce some buzzwords and concepts from the past, in this case, the late 1970’s and early 1980’s. The two concepts were: “Access Density” and “Short Stroking”. Access density is a measure of IOPS per capacity of a hard drive and Short Stroking was what a lot of folks were doing to compensate for declining Access Density. The two terms are, or course, still used but rarely outside the domain of DBA’s. Put 10 DBA’s in a room and you’ll know what I mean (I used to be a DBA so I’m kinda allowed to poke them).
The problem at the time was that drive capacities on those 14-inch diameter behemoth drives were increasing, but they couldn’t spin the drives faster than 3200 RPM. Spinning a 14-inch drive reminds me of those circus guys spinning dinner plates on the ends of sticks: the tolerances by today’s standards were pretty bad. The problem was increasing capacity with the same RPM. Sound familiar? That is the Access Density problem.
The answer to this dilemma was “Short Stroking”, meaning just putting less data on the drive (to reduce the IOPS demand). It even included physically placing data in the center of the platters so that the heads wouldn’t have to seek (stroke, hence the term) as far. And you all thought Short Stroking was a description of my golf game? It actually is, but that’s a discussion left for another day…
Enter the new decade. Anyone see a repeat here? It’s been quietly happening again, since the drive folks are stuck at the 9-year old 15,000 RPM drives. Unfortunately, that will not change; there is no 20,000 RPM drive in our future. And while we all want utilization rates to increase from the measly 20%-30% industry average, the fact is that unless we start adopting available technology, it will not, for many applications.
I’ve spoken with many customers that were delighted with their 36GB 15K drives, tolerated their 76GB counterparts, but limit the amount of data stored on their 300GB or larger drives. Meaning if something is not done, utilization rates might actually go down further. In other words, they’re Short Stroking, especially in the database world. Performance still rules, and the drive guys won’t be giving us any relief, and flash drives are still too pricey. So what do we do?
Well, HDP, and Thin Provisioning in general, address the utilization rate problem, I think we’ll all agree on that one. But does it address the Access Density problem? Read on…
Our implementation of HDP lays out data in 42MB stripes (32MB stripes on the HDS AMS2xxx midrange array, that was announced today) in a wide striping scheme that offers as much as a 700% improvement (measured) in workloads (or more!!). Access Density, what’s that? 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!). We’re seeing many of our customers adopting HDP only for performance reasons, and not only for thin provisioning reasons. A customer I spoke to last week had a batch job that went from 10-15 minutes to less than 1 minute using HDP wide striping (150,000-225,000 RPM drives?).
And it gets better…
Considering that the major effort in provisioning, especially databases, is to “provision for performance”, now you don’t even have to do that. I’ll defy anyone to manually provision in a way that will outperform the wide striping we do with HDP. So now I’m telling our customers to just throw the data out into a HDP pool and let us manage for performance. For the thin provisioning argument, there are some caveats with some older file systems, but for performance, there are no drawbacks.
So with HDP we have:
1. Thin provisioning – 30%-40% improvement is not uncommon
2. Massive improvements in performance – orders of magnitude
3. Provisioning for performance – What’s that?
Maybe soon we can get all the world’s DBA’s to have a bonfire-party to burn all those old whitepapers they’ve been clutching for 30 years…..I’ll provide the matches…
Comments (6 )
Bas Raayman on 30 Jun 2009 at 1:06 am
Claus,
I can see your point of the 105K RPM drive, but wouldn’t the 42 MB page size necessity (or the reasoning behind this page size) become obsolete if you were to use flash drives…?
Bas
Bas Raayman on 30 Jun 2009 at 1:07 am
By the way, I think it’s Marc Farley and not Marc Foley. 
Claus on 30 Jun 2009 at 11:27 am
Firstly, Marc, I apoligize for messing your name up (note to self: no more midnight posts!!). Thank you Bas, for pointing that out. I’m always having my name mispelled so I should know better.
As to your other question, I would never argue that we’d be as fast as flash but I would argue that we’re cheaper!!
The way I look at it is wide-striping becomes an interesting alternative somewhere between standard FC drives and flash. What’s interesting is that they both boost performance for the same type of workload, namely, high R/W ratio with random reads. There’s WRT performance benefit as well, but it’s less dramatic.
It’s the customer’s vote on this one. We just provide the candidates…
Hu Yoshida » Blog Archive » HDP Is More Than Thin Provisioning on 06 Jul 2009 at 11:20 pm
[...] Claus Mikkelsen visited a financial customer in New York where they were excited about the performance improvements which come from the wide striping of pages across the width of the HDP pool. They saw a 10 – 15 min batch job run in less then a minute. Claus points out that a major task of provisioning, especially for data bases, is to provision for performance Since HDP stripes across all the disks in the HDP pool, and now with v05, automatically rebalances the stripe when new pages are added to the pool, performance tuning by manually balancing spindle usage is a thing of the past. [...]
Karl Fasick on 22 Jan 2010 at 1:02 pm
Thanks for giving a name to what I’ve been calling “IOPs per GB”. That a key factor as capacity increases – especially when contemplating SATA 2 TB disks in some cases.
To pool or not to pool? We’re currently laying out an AMS 2300 for mixed Windows workloads. SQL, Exchange, Hyper-V and lots of DFSR managed files.
This array is our team’s first chance to allocate disk based on needs of the applications rather than submitting requests to a storage team. We understand the benefits of going wide but our previous experiences where applications affect performance of other applications make us wary of pooling.
We have been pleasantly surprised at the speed we’re getting with simple 6D+1P and 1D+1D RAID groups. We also tested making the 6D+1P the start of a new DP and didn’t see any reason not to do this – and now we can add additional 6D+1P blocks as we desire. We also like the fact that once deployed – an app shouldn’t get slowed down by other apps sharing the same disk.
That being said – we have lots of questions wondering how to tell when we’d be better off putting all or more disks in a pool – or keep them separate. Should multiple SQL instances go in the same pools – seems likely if they have similar workloads. At what granularity would it make sense to break out Exchange data? By server, by database, log vs DB, by backup schedule, or not at all? Where are the sweet spots? Old EVA guides tested SQL data and log configurations – I think 28 disks and fewer they said put them together, more than 28 – separation started to show improvements.
We’re relying on whitepapers and lots of extrapolation to figure out how old whitepapers apply to new technology. For example the best SQL on AMS guide I can find makes no mention of 450 GB SAS disks or DP.
Got any tips on where to get more info or newer whitepapers? Since we’re production IT we’re not set up as a lab that can do lots of testing on our own, but we want to make informed decisions up front.
Wanner on 06 Jul 2010 at 4:06 am
We migrated from a EVA5000 (60x146GB 10k) to a AMS2300 with 90x450GB 15k in one HDP pool – the result was that our backups are running 2 times slower than with the EVA – for me the AMS2000 series HDP pool is a huge step back because simple things like sequential reads are not handled well. HDS Switzerland now advised us to go backup to the old design like we used on the AMS1000.
Conclusion:
To pool or not to pool? It depends – if you like to have a fast backup – better don’t pool
