What Is Policy-Based Storage Management?

In prior blogs I’ve stressed the fact that cloud-enabled storage requires policies to make the best use of your storage resources.  In this blog I’ll dig a little deeper into what I mean by this.

First, let’s define some storage attributes that could be used to create your policies.

1) Growth - When I provision storage for this application, will it have slow growth, or fast growth?

2) Efficiency - Do I want to pack all my data as tightly as possible, or am I concerned this might affect performance?

3) Speed - Does this application need the fastest pipes, or will any old pipe do?

4) Reliability - Will the world stop spinning (well at least my world) if I lose access to this data?  Or could I live without it for a few hours?

5) Security – Am I worried about anyone else seeing my data?  Or, like my daughter’s Facebook page, the more the merrier?

Using the 5 above attributes, we could build a simple policy structure that looks something like this:

We’d just define 3 tiers of storage and plop data into the storage system in the appropriate tier.  Easy huh?  Well, yes, and that’s pretty much how storage has been provisioned for the past few decades.  Buy a fleet of storage arrays, categorize them as either tier 1, 2, or 3, and assign your applications accordingly.

But, unfortunately, simple methods aren’t always the most efficient.  What if, for instance, you have an application with high Security needs but low Speed and Growth requirements?  In the tiering model above, any attribute with a “high” value would override everything else in the matrix, causing inefficiencies in a simple silo’d tiered storage model.

To solve this problem, let’s look at a more advanced model:

In this model, each characteristic of the 5 attributes can be specified independently.  Now, instead of 3 rigid tiers, 243 different profiles can be created by moving the check marks back and forth for each attribute.  A little more complicated, but certainly more efficient than the first model.  With virtualized storage and a shared IT resource model (i.e. the cloud), the concept of rigid tiers goes away and is replaced by a virtual storage pool containing storage systems of all shapes and sizes.  In order to provision storage, applications are assigned somewhere within the virtual pool based on the criteria defined in a profile such as the one shown.  In a simple policy model like the one above, provisioning could be done manually by humans, but is much better left to machines because things can get complicated very quickly.

To illustrate, let’s see what happens if a few sub-critera are defined for each attribute:

Yikes, we now have over 14 million possible profiles based on only 15 attributes with 3 choices for each.  This is why automation quickly becomes a requirement in policy-based storage management.  With a policy engine, the desired profile can be automatically mapped to the most appropriate storage resource, with the appropriate software functionality automatically enabled, and a monitoring system in place to alert of any out-of-policy conditions.

What’s left for us humans to do?  Nothing really – other than listening to the machines hum, and waiting for some sort of alert that tells us something needs fixin’.  Sort of like an airline pilot listening to the jet engines hum and watching the cockpit gauges as autopilot actually flies the plane.  I’ll talk more about the pilot’s, er, storage architect’s role in policy-based storage management in an upcoming blog…

Be Sociable, Share!

•