An incremental approach to storage tiering

March 8, 2009

I’ve been thinking a lot about storage tiering lately, and the more I get deep into this, the more I’m convinced that tiering (either in-box or cross-array) requires an incremental approach, or even a trial-and-error approach. Of course, this is tied to a storage management policy (of course, if you have one 😉 ), but while tiering in general can provide benefits and savings, your mileage can very much vary.

Hence the need to try on the field incrementally. This means imho carefully planning and adding one tier at a time (in-box) or adding additional types of storage (frames, nas, cas, you name it) in order to leverage different types of services, more than just faster or slower spindles.

Tiering is not really sexy “per se”.. it becomes interesting anyway as soon as you add to it chargeback policies, SLAs, and business scenarios. While I hate that, the “business guys” tend to see (if they see it, at all) storage environments purely as jbods, and I believe that we can’t expect more than that from them… We know that the storage thing is far more complicated (and damn interesting) than that, but sometimes it can be useful to think at your frames+arrays+nas+cas+vtls+you-name-it as a whole, so that you can continue to think of the business value that the storage as a whole provides (this brings to mind also the storage virtualization arena, but that’s another story, at least from a business perspective, imho).

Cross-aray tiering (while many don’t accept this as tiering) can make sense for me in a couple of scenarios:

1) you over-consolidated on a single array/frame: this leads to dealing with data types that problably don’t need to sit on that uber-fast-and-sleek array, and instead can and should be moved elsewhere (e.g. using your SAN environments for massive NAS-like data… just put it on a NAS, as long as it complies with your storage requirements – more on this later).

2) you are already in the process of defining privileged vs unprivileged tiers of storage, and want also to leverage different means of accessing the data (NAS, again, or CAS, or inline-dedupe-boxes, or whatever comes to mind). The different protcol approach allows you to introduce a new box that does a whole different thing than the traditional array, but you could end up with a valid alternative in terms of storage tiering.

Is this the opposite of storage consolidation? well… it may be. But sometimes it happens that while consolidating you end up saturating your primary storage, and this leads you to scale up to bigger/expensive arrays, and that’s not  a good thing in general, particularly if you still know that a big part of your data actually leads you to actually scale down to something cheaper!!!

The excercise here is not trivial: how can you decide in a couple of seconds if you need to scale your big array, add ports to your switch, purchase additional hbas, add additional licenses for your replication systems, or instead add a different type of storage that lets you use your CATx cabling (i’m talking NAS here… not FCoE… 😉 ), etc? It depends a lot on how is made your storage is configured, and also on how you manage it.

In-box tiering… I’m not yet ready for that, but I want it as hell. This is because I want a first distinction on tiers, call them “san tier”, and “out-of-the-san tier” (see above). That said, I see in-box tiering as a great challenge and opportunity, and of course will go for it in the near future. In the last few days I’ve been digging a lot about flash drives (in san environments). This proved to be an extremely interesting arena (arena is probably the right term, considering the uber-fun posts/blogwars from the Storage Anarchist and friends). First, let me tell you that I believe in flash, and want that kind of storage as my Tier-0 in my boxes asap. But again, going to flash without carefully planning could seriously be a big error, and not a cheap one too! Here we need one of two things: a careful analisys of what you could move to flash in order to get extreme performance, or a way for the storage to figure out itself  on your behalf. The latter is (afaik) still not present as a feature in today’s frames, so let’s stick to the former. How do you decide what to put on flash? Everything!!! I would say.. but I’ll probably my budget manage won’t agree that much. Seriously, this is a great tiering exercise. Just consider those 2 tiers: flash (tier 0), and fc (tier 1). This needs a lot of statistics analisys, talking with the app/servers/mainframe guys, and deciding where tu put what. Not easy, but necessary: ultimately, this excercise could lead you in deciding that you don’t need flash at all: instead of scaling up to tier 0, you could figure out that it’s best for you to scale down to tier 2 (SATA, for example). Probably this is the way to go… First define what you can move to tier 2, then decide if you need at all a tier 0, and in that case move only the uber-mission-critical (in terms of performance) data there. You’ll probably end up nonetheless with a far from perfect distinction, but at least it’s a start. Manual Tiering is just that… analisys, implementation, statistics, and back to analisys, and so forth… This is the incremental approach I’ve been thinking of.

How to improve on that? not easy, because sooner or later you’ll end up with an army of applications/databases/you-name-it that all want to be in tier 0, maybe just for some time (end of month? batch processing?). How do you deal with this? I guess the answer resides in Automated Tiering… and that should be carried out by the storage array itself. But still, that’s the future, so let’s wait and stick to our incremental approach to tiering for now.

As seasoned storage managers know, tiering is not just related to disk speeds: it could be nonetheless related to raid protection, or other criteria that lets you define different privileges, protection, performance ranges inside your storage environment. The important thing, anyway, is that YOU NEED a chargeback policy or at least different SLAs for different tiers. Avoid those, and you’ll end up with a good technical exercise that no business manager can’t understand, and even worse, you won’t have the strength to ask your customers (internal or external) to choose between tiers (why should I choose tier 2 if it has the same cost and SLA as tier 0?).

The list goes on and on. This is indeed a mix of technical issues (take, for example, wide striping or thin provisioning) and business needs/cases. There is no free beer here… your solution is probably different than mine, but still I believe that the principles behind storage tiering reside on the incremental approach (which defines the effectiveness of tiering, in terms of performance), and the chargeback/SLA policy (which define the applicability of tiering in your environment).

It’s a long walk… but it’s good to be on the path! 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: