Storage Peer Incite: Notes from Wikibon’s September 18, 2007 Research Meeting
This week Wikibon presents Managing the resources for storage resource management. More than a decade after it was first introduced for open systems, storage resource management (SRM) technology has made little progress. SRM software still has not achieved anything close to true heterogeneity; it still is largely alert-centric, flooding storage managers with alerts night and day and with little or no automation to support rules-based response to events. Most of all, many SRM offerings still only address storage capacity and not I/O performance, which is vital, particularly as disk capacities grow. This is in marked contrast to network management suites, for instance, which today can manage large, heterogeneous networks, provide a high degree of automated response to events such as shifting traffic from a failing switch to a hot spare to prevent a network interruption, and can diagnose more complex problems for network administrators, making their jobs much easier.
Today SRM works best in smaller, homogeneous installations managed by larger-than-average groups of storage administrators. Yet the need for good storage management tools has never been greater, and it is particularly so in large, heterogeneous storage environments supporting global enterprises, exactly the kind of situations where today's SRM tools fail to deliver. The end result is customers bear the responsibility of integrating point product functions to manage large storage networks.
This week's newsletter, based on Tuesday's Peer Incite meeting, looks at the failings of SRM technology and at some of the alternatives, such as storage virtualization, that may meet some storage management needs. Bert Latamore
The explosion in complexity and cost of storage over the past few years has caused storage administrators to wish almost wistfully for the type of management framework that they have seen adopted in the networking and other technology worlds: a framework that can comprehensively manage heterogeneous devices at any scale of operation.
The ideal storage management framework would provide rich discovery, reporting and proactive scheduling of storage resources without dramatically increasing (indeed, dramatically reducing) the labor necessary to achieve utilization, performance and environmental optimization ideals. Recently we have seen increased interest in storage resource management (SRM) as users continue to grapple with storage challenges and vendors refurbish marketing campaigns intended to wrap their product sets in a glow of technology integration that may or may not be justified.
However, we’ve been through the storage resource management adoption process once before with nearly no success. Under circumstances in which the infrastructure to be managed is relatively small, relatively homogeneous and features larger than usual numbers of administrators, introducing a stand-alone SRM product has shown some success. But under more normal circumstances, where storage switches, devices, fabrics, etc., are heterogeneous, administrative resources are very tight, and scaled operation is very large, the reality is that the SRM tools are uniformly incapable of bringing much relief for the storage administrator’s pain.
Unfortunately, we don’t see near-term market pressures dramatically altering the state of the SRM industry. Large vendors will continue to invest in innovation that attempts to extend any proprietary advantages they have in the storage world, and that includes investment in SRM. Additionally there is no clear evidence that providers of server operating systems (Windows, Unix, Linux) are willing to put forward clean, clear standards for storage formats and object forms.
Independent of leadership that intends to bridge rather than preserve storage technology differentiation, the storage resource onus falls to users. The first step they should take is to define the SRM framework they want in their organizations, emphasizing policies and processes, many of them labor intensive, that make the most business sense for how they configure, provision, move, report on, and ultimately retire storage assets. Using proven frameworks such as ITIL and CMMI will increase chances of success. With such definitions in place, users will be in a better situation to appropriately cobble together point tools and frameworks from the multiple storage providers they use to support their overall SRM objectives.
Action item: Users should continue to evaluate storage resource management product sets if only to learn what constitutes a reasonable, comprehensive SRM approach in their business. They should adopt these frameworks not from a technology standpoint per se but more from a policies, processes and practices perspective to ensure they are in control of and capable of appropriately extending their storage resource management tooling over the next few years.
SRM (Storage Resource Management) initiatives began in earnest in the late 1990’s. This was a Unix, Windows and later a Linux market which held great promise 2-4 years ago but has faded in recent years. There were several reasons the 20+ SRM companies faded and lost momentum:
- SRM products had a hard time moving from a reactive, reporting tool to a proactive tool that could make decisions and take actions based on user-defined policies,
- SRM products were mainly homogeneous, thus failing to provide support for heterogeneous environments, and
- SRM products only dealt with disk space allocation and lacked any insight into disk performance issues. SRM users were worn down with all the alerts and decisions that they had to perform manually.
As a result, organizations eventually struggled to make a good business case for SRM acquisitions.
Action Item: Today’s reality is that organizations will need to integrate a variety of vendor and homegrown tools. Storage organizations must accept that the structure of storage is going to be split up by vendor and type of array and that organizationally, minimizing the number of vendors and storage pools is one way to reduce storage administration overheads.
After nearly a decade of startup investment, acquisitions, starts and stops, the promise of storage resource management (SRM) continues to fall short of expectations. Businesses continue to clamor for lower costs, better service, less complexity, transparent metrics, and more speed. Storage administration, for its part, would like to respond with better utilization, fewer storage administrators, predictable performance, facile change management and improved reporting across the storage infrastructure.
Unfortunately, the business case for SRM is not compelling due in a large part to the lack of comprehensive products that address the needs of heterogeneous storage management. Indeed, many users are turning to virtualization to address capacity management concerns, which in turn leads to demand for more SRM capabilities on the performance front. It is becoming increasingly clear that in the near-to-mid term, SRM is simply not the big answer to providing the business with better across-the-board storage service. Rather there will be many little answers that users will have to cobble together (with more labor than desired) to meet the reporting, change management and performance management needs of the organization.
Action Item: Comprehensive SRM is not on the critical path, even though it should be, because heterogeneous SRM is not achievable. Users should not default to SRM for better service; rather they should choose and implement best-of-breed function to solve specific problems and rely on their own sets of policies, practices and approaches to managing heterogeneous storage infrastructure.
The Assessment of SRM by the Wikibon community (see The SRM leadership vacuum and Managing the resources for storage resource management) is stark. The picture is comprised of a patchwork of products, high implementation costs (leading to poor ROI) and spotty vendor investment all sounding a death knell for full-fledged heterogeneous SRM. Why has SRM failed in open systems where it has worked well for mainframes, other proprietary systems and networking? In a nutshell, lack of standardization. There are no accepted standards for discovery and limited coherent system information on storage usage and performance. Further, there is little capability to tie users to applications to the storage resources consumed. Attempts to build a repository of data have been fraught with high costs and unreliable data -- not a stable platform on which to build automation.
This leaves two strategic choices for storage management:
- Implement point products (e.g., Onaro for change management) and specific technologies (e.g., storage virtualization) to address high priority problem areas (e.g., performance, provisioning, migration or application dependency) and apply these across heterogeneous storage pools. This strategy requires tying point tools together loosely with strong policies and procedures that are followed;
- Create homogeneous storage islands and use the incumbent storage vendor's tools and technologies within those islands to maximize automation.
Neither strategy delivers one set of common tools across the data center. Both strategies have some degree of vendor lock-in. Both approaches will rely on strong procedures, homegrown software and scripts to integrate different storage management software. As a result, an emphasis on training, education and the use of proven frameworks such as CMMI and ITIL are crucial to success.
Action Item: With SRM, reach for the moon and not the stars. Storage management should focus on a small number of best-of-breed storage technologies and take pragmatic steps to tie them together with strong procedures.
When it comes to true, cross-platform, heterogeneous storage management, it sometimes appears users are the only ones interested. This may seem unfair as highly publicized activities like the Aperi initiative have required some considerable effort on behalf of participating vendors, especially IBM, the project's catalyst.
The stated goal of the Aperi group is to develop a common management platform for all types of storage systems and build on SNIA's SMI-S standard. This sounds pretty good, but alas, politics and posturing have put the Aperi buzz on a downward trajectory since its initial announcement least year.
If IBM, the company who invented the reference model for SRM capability with DF/SMS, won't or can't provide leadership, then which supplier will provide the impetus? Microsoft? Perhaps but it's unlikely unless Windows suddenly takes back the world. Will Seagate come from below (before you laugh, remember that Seagate once owned 33% of Veritas through the sale of Seagate's backup suite to Veritas)? Or perhaps from above via the likes of Oracle or SAP. Or maybe leadership will come from the side from VMware or even a Google File System.
If any of these scenarios sound too risky (and they are) then vendors should simply give up on heterogeneity and go for best-in-class functionality.
Action Item: The goal of heterogeneous storage resource management is fraught with pitfalls. In the near-to-mid term, vendors should combine virtualization strategies (to address heterogeneous capacity management) with delivery of best-of-breed SRM function, focusing on niches such as performance management, change management and reporting.
Moderator: Peter Burris
Storage resource management (SRM) technologies are being positioned as substitutes for high-cost storage administration labor, among other benefits. However, the Wikibon community reports that the tendency of SRM systems to saturate administrators with alerts can actually lead to a greater demand for storage personnel, especially at larger, more complex scales of operation. Rather than defaulting to buying programs that reflect process, storage administrators are better advised to adopt planning, provisioning, tuning, retiring, etc., practices that can move them closer to SRM ideals, without requiring an uncertain SRM technology implementation.
Action Item: Do not base an SRM business case on labor savings, except in smaller IT shops. Trading seasoned practitioners for immature -- or worse, suspect -- technology rarely leads to improved operations and business services.