Sure, we have point products that can managed small numbers of arrays.  [...] ]]> A random comment made on twitter a few days ago has been stuck in my mind and been going around and around.  It’s finally emerged.  Even as we start into 2011 we don’t really have scalable Storage Resource Management products for the Enterprise.

Sure, we have point products that can managed small numbers of arrays.  All vendors produce those.  They aren’t good; pick something like cross-vendor support – a feature that really doesn’t work and was made worse by the failed implementation of SMI-S by SNIA and you can see my point.

But what happens when we want to scale to hundreds of arrays and multi-petabyte deployments?  From my experience what we see is end users falling back to the basic command line interfaces and abandoning the SRM products as the amount of overhead they add in terms of additional management, support and cost exceeds the benefit.

There is also another trend we’re seeing as we move to more comprehensive virtual environments; storage management is being added as a plugin to the virtualisation management platform.   This means complex SRM tools aren’t required as the rate of change of the storage component in a unified architecture is much less and in some cases almost zero.

Does this really mean SRM tools have had an impact?  I believe it does.  Once environments reach a certain size, it becomes incredibly difficult to manage them effectively.  How many Storage Admins have been asked the simple questions; “how much storage do we have” and “how much storage are we using/have free” and found themselves having to make excuses about how difficult that is to work out or to calculate across heterogeneous environments.

The virtualisation trend I’ve mentioned also poses another risk; the original premise of the SAN was to consolidate dispersed storage tied to servers.  Consolidation made management more simple and reduced costs.  However unified computing is being delivered as a package which doesn’t include consolidated storage (it includes storage arrays, but they’re not designed to be shared across multiple unified server/network deployments).  As a consequence I believe we’ll see the rise of embedded storage blades and of SSD arrays to support unified virtual servers, with bulk “nearline” storage of data being the storage array’s only purpose.

Could this situation have been changed by better SRM tools?  Well perhaps and perhaps not.  It partially depends on what you include in the definition of SRM software.  I would define SRM to encompass everything from reporting to management, where management means provisioning/deallocation and operation.  One critical component of storage management is the ability to seamlessly move data around storage arrays as required.  This is a feature only appearing today, some 5 years or more after it was really needed; server virtualisation removed the incumberances of the physical server from the OS/application – storage mobility (which should remove the incumberance of the storage array) is still in it’s infancy.

Hopefully 2011 will be a year where some of the data mobility features finally reach maturity and that can only be good for us all.

On the one hand, CLIEX [...] ]]> I’ve been using the HiCommand CLIEX (the extended CLI) today. It differs from the normal CLI in that it talks directly to the array via a command device and bypasses both Storage Navigator and Device Manager. HDS have needed this way of communicating with an array for a long time.

On the one hand, CLIEX is a good thing; the functions are more akin to those offered by EMC’s Solutions Enabler in that I can perform direct configuration on the array without an intermediate product. Some of the things I’ve tried include extracting the actual configuration of an array (which can be obtained in XML format) and creating Host Storage Domains and assigning LDEVs. Although the commands aren’t lightning quick (no pun intended), they are certainly quicker than the corresponding commands through Device Manager or Storage Navigator and obviously remove the need to install Device Manager in its entirety. As I’m running tests against a new array, I want to create lots of HSDs (one per FEP) and assign a separate LDEV to each. CLIEX saved me a lot of time (especially as I haven’t got a Device Manager up yet).

On the negative side, the commands are powerful and “delete” functions give no warning or final check; so at your peril use the delete functions! I checked removing an LDEV while running (a lot) of I/O to a LUN and the command was bounced, however when the I/O was reduced (but the LUN still technically in use), I was able to pull the LDEV away with the obvious consequences. Also, these commands talk directly to the array and appear to bypass the configuration on the SVP. If you make a CLIEX change followed up by a Storage Navigator change without first having refreshed SN, then you simply overwrite the CLIEX changes (I know, I tried it).

One little bugette I found… The CLIEX command hdvmcliex is actually a batch file, so if you want to call the command from within a batch script you need to prefix with the “CALL” command.

I can see the CLIEX interface could be extremely useful. I intend to use it to mass configure a USP from scratch. In addition, I can also see how it could be useful to create dynamic failover scripts (more on this in a future post) without the need for Device Manager to be running. However HDS need to beef up the security around the product to prevent inadvertent allocation and deallocation gotchas. They also need to consider moving the locking mechanism (which allows a reserve to be taken on the SVP and prevent SN/CLIEX/Device Manager clashing configuration changes) to being a specific CLIEX command rather than relying on the Device Manager locking function.

One final thought… I’m not sure of any additional security to prevent any user with a command device from installing and running CLIEX and trashing an entire array. Unless you know otherwise?