This article can also be found in the Premium Editorial Download "Storage magazine: Best storage products of the year 2002."
Download it now to read this article plus other related content.
System-Managed Storage (SMS) in the mainframe world allows the mainframe operating system to take over and automate management tasks that were previously performed manually. SRM seeks the same in the open systems environment. In this space, SRM server agents interact with this network-based software layer to create an SMS-like environment for all open-systems OS platforms wherever a SRM agent resided.
|Wheeling and dealing: get the best SRM price|
An alternative approach to managing your storage is to buy more storage as you need it, and don't install as SRM tool. Of course, this approach flies in the face of what SRM tools were designed to do: prevent storage overallocation and overcapacity through proactive management. Yet in some shops, storage overallocation and overcapacity may still be the easiest and cost-effective approach for storage resource management.
In at least two circumstances, buying more storage makes sense. For smaller companies with rapidly growing storage needs, it may be cheaper to over allocate and overbuy than try to hire people to manage what they have. Further supporting the argument to buy more hardware is that SRM tools aren't cheap and pricing methods vary. List prices start at $200 per server for the agents with additional costs for the SRM management software and the physical server. Other vendors have pricing models that range from the amount of storage you have managed to the complexity of your storage environment. Costs will likely start at $10,000 and may exceed $50,000, assuming a deployment on 40 servers. Installation, management and ongoing software maintenance tacks on further expenses.
While SRM tools are being deployed to contain storage costs, the rate at which the cost of high-end, mid-tier and low-end storage is dropping, throwing more storage at the problem isn't an entirely illogical approach to solving the problem. Again, this tactic depends on each customer's environment and shouldn't be thought of as the recommended solution. But with the scarcity and relative immaturity of SRM tools, their rapidly changing nature, the lack of personnel with storage management expertise and the continuing drop in storage prices, one shouldn't discount the "just buy more storage" option.
Non-SMS volumes in the mainframe environment are essentially storage volumes on which limited storage management is performed. This network-based software layer benefits the open-systems environment since it gives a central point to introduce a basic level of storage management without respect to the server operating system or the requirement of deploying agents on all of the servers.
Not surprisingly, other vendors such as Veritas and IBM are looking at this approach, simply because it makes sense for the enterprise. Most active proponents for the adoption of this model are the same individuals who helped design and made this work in the mainframe environment. For example, the CTO and VP of Engineering at Fujitsu Softek, Nick Tabellion. He was one of the original designers and developers of SMS for IBM in the mainframe world and was brought in by Fujitsu Softek to develop a similar concept for them.
Cons. A couple of holes exist in the network-centric approach. First, while a new software layer in the network should in theory simplify the entire SAN design and architecture in a number of important ways, mostly importantly it does not give satisfactory end to end performance management in high-end environments.
While one may not initially view performance management as part of an SRM tool, in high-end environments storage and performance management are inextricable and you can not have one without the other. This network centric approach will not natively offer end to end performance management that's a by product of the next two approaches.
The other hole that exists for the network centric approach is that's it essential to have a common network based software layer. Without such a layer, it would appear unlikely vendors taking this angle would be able to provide the full functionality that their customers may want. So if your company did not plan to deploy this software layer, you should look beyond these vendor's SRM tools in light of the next two categories.
This philosophy probably reflects the most widely available next generation approach on the market today. In this design, the SRM tool communicates with the APIs available on the interfaces of each of the vendor's storage arrays. In so doing, this method removes much of the proprietary nature of managing the existing vendor storage arrays today.
Pros. This avenue would appear to make sense in environments where products already exist in a controlled growth environment or where change is not rapidly occurring. It also offers more in-depth reporting and management tools than the other two next-generation approaches. You may want to approach API-centric solutions with caution in environments that experience rapid or unexpected change or aren't well-documented, or if you don't need the depth of management and reporting offered by this solution.
Two vendors, CreekPath and EMC, have already publicly announced plans to deploy their technology using this approach. CreekPath has sought to achieve this by purchasing the APIs for each of the hardware vendors and then coding to the APIs provided to them. EMC, on the other hand, is offering API swaps, where they will freely give away their APIs to their storage arrays if the other vendor gives away their API's in return. So far, only HP has taken EMC up on that offer. So for the majority of vendors not sharing their APIs, EMC is reverse engineering the other vendor's storage arrays to get the code they need to do their job.
Cons. While on the surface, the API-centric approach may sound appealing, writing to each other's APIs is a costly and time-consuming process for vendors. One has to wonder how successful this product approach will be as storage array APIs change and storage arrays come and go. Also, with so many storage vendors in the market and CreekPath and EMC currently only having support from some of the big players (IBM, HDS, HP, and NetApp), users possessing older or newer generation storage arrays may be limited in the scale to which they can deploy this solution.
The standards-centric approach has started to generate interest and support from big and small players. In this approach, vendors code their products to a common set of standards that are present not just on storage arrays, but throughout the entire storage network that would be used to gather, analyze and manage data.
Pros. Standards provide a common interface that shortens the software product development life cycles. This common set of rules is exactly what small startups such as AppIQ are now betting on, while larger companies like EMC are using to hedge their bets. For companies like AppIQ, standards allows them to bring their products to market quickly since they no longer need to worry about the proprietary API's of each vendor's storage array. Plus with this standards-based approach, they will be able to mine data out of any standards-based device irrespective of vendor and give end users far more information on a single screen at a price point most companies can afford.
Cons. First, it is unlikely a standards-based approach will give end users all the information they want in every situation. Some users will need certain functionality that comes from the code of a specific vendor's equipment. Neither this approach nor the similar API-centric approach help to eliminate the complexities as the network-centric approach does. It still requires highly-trained individuals to interpret and understand the data being managed and reported on in this standards-centric approach.
However, there's no disputing this approach merits close attention. Bruce Nash of Fujitsu Softek believes standards-centric solutions may offer 70% to 80% of the storage information organizations may want or need. While it may not provide everything end users may want, this information is probably 70% to 80% more than they have now.
This was first published in January 2003