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?