Home | Storage | Will Poor SRM Products Kill The Storage Array?

Will Poor SRM Products Kill The Storage Array?

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×

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.

About Chris M Evans

Chris M Evans has worked in the technology industry since 1987, starting as a systems programmer on the IBM mainframe platform, while retaining an interest in storage. After working abroad, he co-founded an Internet-based music distribution company during the .com era, returning to consultancy in the new millennium. In 2009 Chris co-founded Langton Blue Ltd (www.langtonblue.com), a boutique consultancy firm focused on delivering business benefit through efficient technology deployments. Chris writes a popular blog at http://blog.architecting.it, attends many conferences and invitation-only events and can be found providing regular industry contributions through Twitter (@chrismevans) and other social media outlets.
  • http://varchitectmusings.wordpress.com Kenneth Hui


    Spot on in your analysis. The biggest obstacles to effective SRM tools is the continuing FUD and lack agreed upon open standards. I was an ECC field specialist for EMC and we basically had to reverse engineer any non-EMC array that customers wanted ECC to manage. It became too resource intensive and the functionality was never half as good as the native management tool for a given array. You can’t underestimate how difficult that is to do when you consider that ECC did not and probably still do not manage a Symmetrix, a CLARiiON, or a Celerra as well as as each array’s own native tools.

    The FUD doesn’t help either, and I would include EMC here, although ALL the SRM and storage vendors are guilty as well. It is not particularly helpful when you state that your tool can manage 5 different vendor’s arrays and what you really mean is that you can provision one vendor’s storage but can only report on the other 4. That kind of nurtured confusion is not helpful to the end-user. And of course, there is the issue with vendors claiming that support is voided if you use another vendor’s SRM tool to actively manage their array…

  • http://www.snia.org wayne m. adams

    To clarify an assertion made in the article — “the failed implementation of SMI-S”.
    The SMI-S program is alive and well — well implemented by many storage vendors for enterprise-class storage found in data-centers. Unfortunately, SMI-S has meant many things to many people, and can be easily cited for any shortcoming when there is a desire to have a single pane of glass to manage and configure everything…..which means there needs to be a single standard that can actively manage and configure anything that either stores or moves data (to/from storage).
    Why SMI-S is doing well:
    – it provides the basic management features to monitor storage, depict configurations of the storage, track key events, and configure storage and SANs.
    – it saves storage companies significant engineering resources to program to a reduced number of interfaces; costs are shared across the industry
    – SMI-S is an ISO standards, so it is applicable globally for vendors engineering products and for end-users who procure solutions. Global organizations can have a consistent architecture in their dispersed data centers.
    – the standard is open to the entire industry to reference, implement, and further develop to meet new requirements — SNIA has programs and tools to bootstrap any vendor into a successful implementation.
    – SNIA fosters two key programs to improve the end-user experience and reduce vendors tested interoperability configurations – SMI-lab and CTP.

    So, even though SMI-S does not solve everything required for SRM, it is a rock-solid building block for any and every SRM solution.

    Please visit SMI-S related SNIA webpages at http://www.snia.org/SMI

    Wayne M. Adams
    Chairman, SNIA Board of Directors

    • http://www.brookend.com Chris Evans


      Thanks for the comments. I will probably respond in a dedicated post, as I partially agree with some of your comments but not on others.


  • Pingback: Temp Accounts Specialist Hitachi Global Storage Technologies Singapore Pte Ltd - Info Lowongan Kerja()

  • Pingback: Tweets that mention The Storage Architect » Blog Archive » Will Poor SRM Products Kill The Storage Array? -- Topsy.com()

  • Pingback: Z-Drive P84 500GB PCIEXP SSD – Solid State Drive | FireBall Tech Computer Repair - Tucson Computer Repair - Bill Arnoldi - Computer Repair Tucson - Rita Ranch Computer Repair()

  • Pingback: Cepoint’s R-STOR, 6TB Enterprise SATA Raid for High performance Storage clustering ships with iSCSI or Fibre connectivity and secure remote access features! | Ergonomic Computer Desk()

  • Pingback: The Storage Architect » Blog Archive » Why SMI-S Doesn’t Work()

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×