Storage tiering is one of those concepts that has been around for a while, the question has always been "what's the trade-off?"  Compellent was the first storage vendor I worked with who offered the feature, and others have followed with offerings of their own.  EMC, whose arrays support our Enterprise Cloud platform, released their FAST software late in 2009, bringing the technology to our CLARiiON and Celerra storage platforms.

So it's magic, and everything sits on the right kind of storage and I get compliments from my executives and customers all the time, right?  Well…

(Disclaimer: most of this information/discussion came from a series of fantastic days with the VCE group.  If I'm mistaken or misrepresenting anything here, please chime in with a comment and set me straight.)

So the challenge from a service provider is the granularity of the tiering scope.  Right now, FAST can tier at a LUN level.  This is certainly something that has practical uses, especially inside the enterprise where LUN constructs usually map to applications, or at least to business units.  Putting a FAST policy on the LUNs where your Exchange datastores are, or where your file servers or SQL servers are will definitely show some tiering benefits.  The challenge is that not all data on a LUN is accessed equally, and that fact is going to limit your tiering efficiency.  Does every message in the datastore need to be on the same tier?  Does every file get accessed with the same frequency?  No, not usually.  The answer right now is to make up for these limitations on the design side.  Let's make two (or more) LUNs for the file server, and segment data based on access date.  The Celerra file mover would be an option here, allowing the tiering to happen at a file-level, but of course that's a limited option based on the array and storage type.

The next version of FAST is rumored to include the ability to do tiering at a sub-LUN level.  Interesting?  You bet.  Especially if the policy can dictate how narrow or wide the sub-LUN space is, it could be very beneficial.  Remember the file servers from the previous example?  Maybe you don't need two LUNs and a manual process if you can tier at a more granular level.  Sure, it's not going to be as efficient as file (or ultimately block) level tiering, but it's an improvement.

The problem is that this leaves some gaps for the cloud offerings for service providers.  While I'm very interested in being able to offer a tiered storage service to our customers (yes, storage is the single largest part of the cost of an enterprise VM right now), but it has to be able to be correlated back to the customer.  What I mean by that, is that if a customer buys a VM with 100Gb of tiered storage, I need to be able to report to the customer where that 100Gb VM lives real-time.  With LUN-level, and even sub-LUN-level tiering I don't have any way to relate the service back to the customer on a per-VM basis.  Sure, I could segment customers by LUN, but that impacts my provisioning processes and the efficiency of the storage design.  If the customer can't see what they have purchased, it's not going to show the value needed to pass the smell test for the SMB and mid-enterprise markets, I can tell you that.

So what would I like to see?  How about being able to do VM-level tiering, and being able to enable that and associate the VM with a tiering policy straight from vCenter with a right-click?  How awesome would that be?  I've mentioned the idea to a couple people, and from the feedback I'm getting it doesn't sound like I'm the first person to ask for this kind of functionality!  Here's hoping we see/hear more about this at EMC World.

How could storage tiering be changed to better suit your customers/business/products?  Since my experience on this topic is limited to my VCE discussion, how do NetApp and others address this topic?

15,983 total views, no views today

 

3 Responses to Storage Tiering for the Service Provider

  1. Chuck Hollis says:

    I think I’d disagree with you.
    My bet (and personal experience) is that service provider tenants want to know (a) what service they’ve paid for, (b) what service they’re getting, and ultimately (c) is there a better offer for the service level I need?
    Breaking it down to exact portions of data on specific media (which can change several times per second) seems excessive and unwarranted for most tenant requirements. I would hope that the VCE team spoke of FAST v2 as well and sub-LUN tiering.
    To my way of thinking, there’s a couple of ways to price FAST fairly. First, here’s a give service level (IOps and response times) — the fact that the service provider can deliver it with a mix of flash and SATA is an opportunity for margin expansion. Second, you signed up for a low service level, here’s a “surge” capability that’s transparently available (and paid for) should it be required.
    Most SPs think they’re selling an SLA. Most of the time, though, they’re selling insurance that the SLA was wrong :-)
    Thanks for the post … we need to do a better job here.
    — Chuck

  2. Honestly, I hope we can get to the position you describe with our customers, it would certainly solve a lot of the issues we are facing. I think our primary challenge in bringing these services to market are of our own making, but are challenges none the less. We have worked hard to make sure that we are positioning our Enterprise Cloud services in a way that our SMB/Mid-enterprise customers can relate to, and see the business value in, and I think you would be surprised at the level of transparency that our customers demand of us. It’s not at all out of the norm for us to have fairly in-depth conversations with prospects on how we do what we do, not just the SLA we provide (or the insurance we are selling in case the SLA was wrong!) in our offerings.
    Some of that push-back is internal (educating the sales teams), but much of it is driven externally. The desire to know exactly where a particular VM lives with respect to the storage tiering available is a direct request from a customer, as he wants it to show the value of the solution to his execs. The hesitancy to thin-provision so as to better show the value/differentiation of our offerings is another place this shows up.
    Little to none of that do I expect our partners to fix for us; that being said, there are some ways to implement the current feature-sets that help us better manage the infrastructure (I’m sure there might be some margin expansion in there… :-) AND give the customers what they are asking for. Our products are successful and growing as they are now, and further advances in efficiency and management by ANY of our partners can only provide for more of the same.

  3. Ahhh Pareto strikes again. I think the dilemma that is created internally, is caused by trying to cater the infrastructure to a small segment of the existing or prospective users. While it is true that some (to stay with Pareto we’ll call it 20%) of the customers/prospects are concerned about I/O and transparent storage views; the majority are simply in it for the “just make it work” results. So spinning off of what Chuck said, the “Insurance that the SLA was wrong approach” is closer to how I’m having to position this product today. Users of the platform won’t question much unless performance is being affected. The situation that I wouldn’t want to get into is, a poorly performing DB server or App server that is analyzed to be running on “tiered” storage for what (at that point at least) will be considered the financial benefit of the service provider and nothing more. I/O latency matched with perceived storage design failures would be akin to discovering (after years of living in it) that your house was completely wired incorrectly. When things were working, you were fine, but once that discovery is made, you hate the house and subsequently the builder. In the SP world that is known as churn.
    Not sure I have a clear answer…although a premium offered to customers for guaranteed I/O might be a way to appease the more demanding customer and yet still let the entire infrastructure reap the rewards of tiered storage.
    Keep blogging…conversations like these will advance the product sets and offerings much faster than designing in a one company box.
    -Andrew