I'm interested in exploring the case for on-array tiering. Makes no sense to me. Sounds like tech for lazy people!...
I engaged Jon in a quick tweet discussion (I'm the "inbound tweet") until we both had to attend to personal matters but I wanted to come back to this statement because he's brought this up before and I find it a little bothersome. Not because Jon's asking a question or challenging the use case - I'm perfectly fine with that.
My rub is that his premise seems to be that block-level tiering is being positioned as a replacement for data management policy and best practices. That's not the story - at least not the Compellent story. For example, Jon's last tweet on the matter was this:
Seems like understanding your data and applying appropriate services to it based on its business context is becoming a must have, not a theoretical nice to have.
If anyone's selling array based block-level tiering as a replacement for data management policy, archiving best practices, private information security and the like, I'm not aware. This is a pure storage optimization play. There's nothing about automated block-level tiering that would prevent the development, implementation or enforcement of a good data management policy.
What makes my ears prick up is when a statement like Jon's attempts to paint automated block-level tiering as an evil when it's nothing of the sort. You want to implement an HSM scheme or data management policy on top of ATS? Go right ahead - you'll still have data that is less actively accessed (or practically inactive for that matter) until the data management police take appropriate action is my guess.
On Jon's blog, he quotes an anonymous former EMC employee:
The real dillusion [sic] in the tiered storage approach is that the data owners – the end users – have no incentive to participate in data classification, so the decisions get left to data administrators or worse (software). Just because data is accessed frequently doesn’t mean the access is high priority.
This really sums up the ATS nay saying. First, it's not a delusion to say that data owners aren't incented to participate in data classification. It's an ironclad fact. If you're lucky enough to have published a data retention policy, the exemptions and exclusions start flying almost before the ink is set on paper. Still, I don't believe that ATS is a solution to that problem, but rather a reaction to it.
Secondly, the whole concept that ATS is somehow trying to equate data access to criticality is, in my opinion, fallacious. At some level, yes, access frequency tells us a lot about the data - chiefly that there's a lot of interest in it. It doesn't tell us that it's necessarily important to the business. It may be - it likely is. It may not be. Conversely, infrequently accessed blocks may contain business critical data. Maybe it doesn't and likely it's less critical (now) because it's not being accessed frequently (now).
So ATS gives you a way to store data cost effectively, without impeding the data steward from taking action to classify the data and handle it appropriately. It's not an enemy of data management - nor an ally for that matter. So why is it drawing so much ire from Jon?
Jon, feel free to continue to champion for better data management practices - I'm with you. But please don't waste energy fighting something that adds value today while we're waiting for that battle to be won.
As for the use cases - ask your friendly neighborhood Storage Center user!
Really good response. I am with both you and Jon. Let's all promote the idea of good solid data management but let's also deal with the reality that it is not going to happen. Storage Managers are not lazy, storage managers are worked too hard against overwhelming odds. Reality is that Automated Tiering for some may be the only way to go especially in the move down to SATA aspect.
My concern with ATS as I discuss in this entry:
Is that it should not be presented as the be all and end all when it comes to upward migration, i.e. performance acceleration. In some cases performance sensitive data is ver specific and can be addressed by a simple SSD insertion not a full on switch to automated tiering. Especially for block systems. However there are data sets where it is far to random and less specific. In that case while maybe not ideal it is the only way to get the job done.
Good comments John.ReplyDelete
I'm a Compellent user with 352 spindles (>150TB), in a business with VERY dynamic storage demands. My best use case example that I often convey to people about this feature is as follows:
I have a very LARGE database that is used for statistics of our products that is not updated very often, but when it is updated it is several hundred million rows in a chunk, consisting of a hundred or so GB of data. Now this insert needs to be done quickly so the data can be analyzed (and not have it take months were it just on SATA). BUT, since only 2 people access this data now and then after it is in it doesn't really justify having the whole database sit on RAID 10, 15K disk (especially in it's current 5TB state).... The RAID 5-9 performance is more than acceptable for this application during queries & reads, but NOT acceptable for writes....
With block-level-tiering I don't have to make any decisions on if/when to move my volumes around, nor take ANY action... I have writes set to RAID 10, 15K and then then the data AUTOMATICALLY progresses down to RAID 5-9, SATA within a few weeks. Saving me space for further writes by the dozens of other applications, and not wasting my costly 15K disk for all this space. In this case (I have many other examples on how COOL this is -- where FAST writes are always welcome, even if the data will end up on slower disk within days or weeks) I get the best of everything.
This example is outside the realm of a data management policy, where I have actually decided that I want this data on slower disk, BUT I can still have my FAST writes!!
Hopefully it does come across that I do agree with Jon also in that the need for solid and practiced data management policy isn't fulfilled by ATS alone. It will be interesting to see where SSD begins to fill in as the price drops. Right now, storage vendors are trying to figure out where to put it so it will sell (and not having much luck at that - ask STEC and EMC).
That's a great story and your last statement sums it up. What ATS is providing is efficiency and lower cost. Data policy is something else all together.
Great discussion John.ReplyDelete
So, with ATS, do you NOT have to have any certain amount of capacity reserved/set aside for the migration up and down the tiers? If so, how do you determine just how much capacity to set that reservation at? Is it 10% of the overall capacity? 20%? It would seem to me that if you had a 5TB Database, you would need to have 5TB’s of Tier 1 space for those times it needed to be moved up correct? What happens to that Tier 1 space once it moves back down to SATA?
Craig you could probably be best to answer this, you have 150 TB Array, how much capacity is reserved for that process?
Interesting comment "storage vendors are trying to figure out where to put SSD so it will sell (and not having much luck at that - ask STEC and EMC)."
Yet companies that sell SSD exclusively are telling me that they are reporting record numbers. See here:
George, I was talking about the EMC carryover of STEC drive inventory from 2009 into 2010 that caused some "street" issues for STEC.ReplyDelete
Believe you me - I'm pulling for SSD in the long term.
No reserve space is required at all. Volumes aren't tied to a storage group or disk tier like a typical SAN environment. With the ATS example I described, the block writes are written to Tier1, R10 - while the rest of the blocks stay where they are - and the volume continues to exist. There is no 'wait time' for the 5TB volume to be completely cloned/migrated to Tier1 to get the increased performance - the writes just happen on FAST disk. Then immediately after the new writes the volume will exist on blocks on multiple tiers. As the activity on those higher-tiered blocks diminishes, ATS will automatically (if I choose this volume to tier) move those blocks down to Tier2 (maybe 10K FC or 10K SAS), then to Tier3 (maybe 7.2K or 5.4K SATA, or whatever tickles your fancy) -- all based on the profile I chose in the Storage Center interface. So blocks from the same volume may have blocks on several tiers, no problem :)
And what I love the most - is that whatever I choose today for a storage plan, I can change tomorrow and ATS will migrate the blocks around to the appropriate Tier without any effort on me, besides defining the profile.
@ George CrumpReplyDelete
George, I read your bit on "SSD Domination" being "on target", and after noting that this article was paid for by an SSD vendor, I also noted that you provide absolutely no independent or verifiable sources for the claim of SSD "domination" being on track.
I just looked at the IDC and Gartner numbers (both of whom continue revising their SD projections downward), and I find no support for your assertions.
SSD uptake in IT is a small fraction of what industry projections have been calling for.
STEC stock is in the tank, meanwhile the HDD stocks are up dramatically!
STEC sales forecasts have been revised downward again, EMC STILL can't sell what it bought last June, and shareholder lawsuits are multiplying.
To me this sounds more like SSD implosion than domination.
Finally -- how does a company like Texas Memory Systems "having a record quarter" translate into domination?
They sold 20 units more in Q4 than they did in Q3, and reached a total of $7 million in revenue for Q4, up from 6.4 million for the previous quarter.
Seagate and WD both had "record quarters" and grew their HDD businesses faster than TMS grew it's SSD business -- so TMS is actually lagging the storage market, not leading.
The real question here is -- why isn't SSD achieving even a fraction of the market penetration that ssd hypesters like EMC's Tucci have been propounding?