Not surprisingly, each of these vendors' software products reflects this software-centric design philosophy. CA's BrightStor, BMC's Patrol, and Veritas' SANPoint Control as well as many of the smaller SRM newcomers each use a central server to gather and report information from the software agents they deploy on the individual servers.
Pros. The upside to this approach is that a significant amount of storage information is collected, information such as storage allocation, utilization and even performance metrics. This can be invaluable information when trying to determine what tier of storage one wants to place the underlying data onto. This approach also isn't dependent upon the underlying hardware to gain many of the desired benefits.
Cons. SRM tools are rapidly evolving from passive to active. Currently, some SRM tools are passive - they only monitor and report on the storage for the servers on which they reside. But the next generation of SRM tools moves to actively managing the entire storage infrastructure based upon policies set in the SRM tool. This next step in SRM puts some of these vendors at a disadvantage compared to the device-centric model, especially in a SAN environment.
Without the ability to communicate with the underlying storage array, one wonders how existing manual tasks such as LUN security on the storage arrays and switch zoning on the different vendor's switches would be automated when moving storage between servers, especially if the SRM tool isn't currently communicating with these devices.
A number of software and hardware vendors have asked this question as well. They appear to be taking steps in a number of areas, resulting in changes in their next generation of products. These product design changes blend together the aforementioned device- and software-centric views.
This blending of these views reflects a crossroads in the life cycle of SRM products. At least that's what Charles Witt, a systems engineer with ProvisionSoft, Andover, MA, believes. Witt sees customers as not being satisfied with just monitoring and reporting on storage, and being unable to translate that information into action. As vendors make this transition in product design, they are emphasizing one of three general design paths to reach their ultimate SRM objective.
Pros. This approach prevents vendor lock-in and creates a common software layer between the servers and the storage arrays that the SRM tool communicates with. Fujitsu Softek believes this new network-based software layer begins to create a storage environment similar to what already exists in the mainframe world. In the mainframe environment, storage exists in two distinct classes: System Managed Storage (SMS) and non-SMS volumes.
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.
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.
API centric
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.
Standards centric
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.
Application-centric approach
What's next? All indications are that the existing design paths discussed above will merge into a powerful new SRM suite with an application-centric approach that combines the best of each categories. In many cases, it's already happening. Today's SRM tools fit into various niches, but each product is starting to incorporated some elements common to the other categories (see "SRM-only vendors")
Make no mistake: It's the customers not the vendors who are driving this charge toward an application-centric design. Scott Shimomura, product design manager at Fujitsu Softek, and Scott Hansbury at Creekpath Software say their customers want end-to-end storage management and reporting. This end-to-end approach starts at the application level, goes through the storage network to the spindle level on the individual storage arrays.
As SRM products evolve, smaller vendors who have first-generation SRM products typified by passive storage management will be challenged to adapt their products to become increasingly active in storage management. Even large vendors will struggle to adapt their models to the more flexible model that will surely emerge. Vendors such Veritas and BMC will need to build more hardware capability into their legacy software-centric infrastructures, while the EMC's and IBM's of the world will need to introduce more open software designs into their device-centric approaches.
To help make this transition, the big boys will likely try to acquire some of the smaller companies that have technology they want. Sun just recently did this by acquiring Pirus Networks. It can provide the network-centric portion Sun lacked in their product suite. Veritas snatched up the Storage Reporter product from NTP Software, presumably to allow their SANPoint Control product to work on servers lacking Veritas' legacy software. IBM meanwhile offers DataCore's SANsymphony software and recently purchased TrelliSoft. Both of these are said to be interim solutions that IBM will offer until their full suite of products under their StorageTank initiative are ready to ship.
So as these SRM tools develop, choosing the best product for your environment will be difficult because of the constantly changing nature of the products. And we haven't even heard yet from big name computer companies that may enter the SRM space. While unlikely, it is not impossible SRM may follow the same path as it did in the mainframe world. What, for example, is to stop a Microsoft, Sun, IBM, Cisco or Brocade from entering this field with an SRM option, especially with so many small vendors looking to get bought out?
All these major players would have to do is buy a small company, add the new SRM functionality as part of their core OS package and they are in the SRM business. In fact, Brocade's recent purchase of Rhapsody Networks may indicate just such a move to incorporate more storage intelligence onto their switch. One would also have to think that with a portion of the intelligence of this application-centric approach moving into the network, Cisco could be a major player, especially with their army of engineers and dominance in the network, and their recent foray into the Fibre Channel space.
All this competition is good for the end user. As they mature, SRM tools will get better and better. As the market matures, the number of choices will drop and the winners will begin to emerge. What will define the winners are those companies who can successfully execute on the adoption and integration of these different SRM approaches into one robust application-centric solution.