InfoStor : The real state of SRM, part 2, July 2007 Page 1

Storage resource management (SRM) challenges include multi-vendor support, homegrown versus vendor tools, and the trend toward SRM suites.

By John Echaniz and Justin Schnauder

Part 1 in this series of articles (see June 2007, p. 31) focused on what SRM tools are good for-and where improvements are required.

In an effort to reduce costs in their storage environments, most companies are deploying storage arrays from multiple vendors. Competing vendors often offer deep discounts on their products and services to gain a foothold in a company dominated by another vendor. This is especially true in the large enterprises, which can have hundreds of large storage arrays and thousands of hosts. The mix of multiple array, switch, and operating system vendors has driven the requirement for storage resource management (SRM) vendors to invest heavily in development efforts to support third-party products at an expanded level.

Different SRM products have approached multi-vendor support in different ways. EMC Control- Center, for example, emphasized homogeneous discovery, concentrating on deep, functional support of EMC’s products before expanding support for other vendors’ hardware.

Conversely, Hitachi Data Systems’ HiCommand Storage Services Manager was originally developed and marketed by AppIQ and was intended from the outset to support heterogeneous storage environments. AppIQ targeted the most common storage hardware from multiple vendors, but not to the same depth the EMC ControlCenter team pursued for its own products. The same can be said of Symantec’s CommandCentral Storage suite.

When it comes to homogeneous discovery, EMC, Hitachi, and IBM certainly provide greater detail on utilization, reporting, replication functionality, and performance of their own arrays. Their abilities to deliver such detail on competitive gear vary by vendor and array model.

When you are evaluating SRM products, you should evaluate multi-vendor capabilities in a demo or lab environment before you make a commitment to a product.

Equally important is evaluating the functional limitations associated with different array models within a given vendor. Array product suites have been combined and consolidated over time through acquisitions. SRM products have extended support to these acquired products in a similar manner to competitive products. Functionality of acquired products is gradually incorporated into the overall framework of the SRM tool, but users should not assume the SRM software will provide every function that is native to the array simply because the products share a label.

The ability to perform third-party discovery of storage devices is probably the single largest deficiency in the SRM market, due to the wide variety of array vendors and models. Because of the lack of cooperation among storage vendors and the relative immaturity of standards such as SMI-S, the ability for one vendor to interface with a competitive vendor’s storage device still leaves much to be desired.

Users evaluating SRM tools will find array functionality for heterogeneous discovery limited to gathering component data such as vendor, model, cache size, array firmware, capacity utilization, and some limited performance metrics. Provisioning support usually includes basic LUN masking, but little in the way of advanced operations. Real-time monitoring is usually not available, but limited historical examination can be performed from the available counters, depending upon the device. Typically, performance statistics of this type do not provide the level of detail required to completely analyze an array. As an example, counters such as cache utilization and hit ratio may not be gathered, but overall read and writes may be available.

It is important to remember that third-party vendor support is usually reliant on an intermediate system that actually does the communicating with the third-party arrays. For example, management of HDS arrays by other SRM vendors requires Hitachi’s HiCommand Device Manager to do the actual data collection from the HDS arrays.

This condition introduces several limitations, including the following:

Disparate software application versions must be managed carefully. An array upgrade that might seem innocuous could disable a third-party collection mechanism, and/or the quality of its data; and
Scaling of the solution has the added potential to increase consumption of server resources. With separate systems required to communicate with the arrays for each third-party hardware vendor in the environment, the overall server footprint of the SRM infrastructure can grow quickly.

Until the SMI-S management standard is mature and adopted by all storage vendors, bloated SRM frameworks will be required for heterogeneous discovery and end-to-end storage management.

Lack of complete solutions

A significant number of enterprises (including several large financial institutions) have chosen to forego vendor-based SRM altogether. These companies have deployed homegrown toolsets in response to what they viewed as an unappealing SRM market which, at the time of their in-house tool development, was immature and unable to satisfy their requirements. In an effort to remain vendor-neutral or to create a data-collection structure that meets their specific needs, these companies have invested significant dollars to create these homegrown SRM tools utilizing storage vendors’ APIs. These unique applications often include

Customized zoning policies and unique processing for NAS and SAN-attached storage configuration changes, featuring rigid provisioning change windows;
Company-specific provisioning requirements for integration into disaster-recovery and business continuance models;
Customized SAN-attached storage and NAS provisioning requirements; and
Storage reporting and chargeback models aligned with very specific tier definitions.

Faith in these custom tools and the paradigms associated with their utilization has limited the flexibility of these companies to implement dynamic tools and new technologies. Extremely long lead times are required to integrate new storage arrays, switches, and NAS devices into these custom products. Therefore, to continue utilizing “supported” devices, some of these companies have deployed overly complex designs that feature hardware that does not provide the necessary processing power, capacity, and/or density to facilitate achievable economies of scale. In an effort to simplify their day-to-day storage operations and bring stability to their infrastructures, many of the integrated policies and procedures have subsequently become obstacles to performance at the array and host level.

It is thus important to consider the long-term ramifications of custom storage software development when you are thinking about SRM tool implementation. It is quite common to find a happy medium between custom software to handle specific automation needs, and SRM deployments to handle the more basic elements of storage and SAN administration.

It is in this middle ground where the best solutions lie: Fewer storage administrators are needed overall because of SRM control, more junior employees are able to conduct a wide variety of administrative duties through an SRM GUI, and more senior administrators are able to focus on the oversight of the environment, more-advanced automation, and design for the future.

The rise of SRM suites

While many SRM products do provide vast amounts of information and functionality to end users, there is a level of complexity and overhead associated with maintaining them. Niche products that perform some, but not all, of the tasks associated with SRM are beginning to make their way to the forefront. Tasks such as LUN masking of disk arrays or monitoring block-level replication between sites do not require a full-blown SRM toolset, or suite. The niche products provide the vendors with an opportunity to deploy new functionality without having to regression-test the changes within an SRM toolset to determine what effect the new code will have on the product as a whole. Eventually this same functionality will likely be included in full-blown SRM suites. EMC’s Symmetrix Management Console and IBM’s Storage Manager Client are good examples of this type of point product.

These same products are also beginning to find their place as disaster- recovery toolsets.

Companies that deploy full SRM toolsets do not want to create a duplicate environment to perform the same tasks in the event of a site disaster. These niche management tools can provide a basic GUI to perform array configuration in a disaster-recovery location, driving down the cost of building a disaster-tolerant infrastructure.

Some SRM vendors have also broken their products into distinct components that plug into one another, again as a way to make SRM adoption easier to handle in phases or in limited scope. For example, IBM’s three SRM components- TotalStorage Productivity Center (TPC) for Disk, Fabric, and Data-allow companies to scale their levels of SRM implementation and ease into a new method of storage administration.

It is clear that SRM tools provide significant enough benefits to outweigh the burdens of deployment and management. By consolidating management into a small number of environments, SRM software provides critical visibility to the storage network and its components, for an increasingly wide variety of activities.

In the next part of this series, we will examine specific SRM tools that can help prospective users identify which products best fit their needs.

John Echaniz is director of client solutions, and Justin Schnauder is a technologist, with Novus Consulting Group (NovusCG-www. novuscg.com). David Askew, client technology executive at NovusCG, also contributed to this article.

Key questions to ask your SRM vendor

Can the SRM infrastructure components be distributed to multiple systems?
Can the SRM servers be clustered for high availability?
Are the product’s database views exposed for SQL client interfacing?
Is this product fully SMI-S-compliant?
How often are service packs created?
How do SRM upgrades impact the existing environment?
How is the product licensed? By the amount of storage managed? By managed object?
How are other vendors’ products tested for integration with the SRM product?
For heterogeneous deployments, how many additional systems are required to support third-party arrays?
How are agents deployed? How much is manual versus automated?
How large (number of servers, arrays) is the largest deployment of the product?
What features are on the product’s road map for the next 18 months?
Does the product support virtualization of servers, storage, and NAS? If so, how are virtual entities handled?
How is disaster recovery approached for the SRM infrastructure?

SRM’s effect on staffing

Companies are always looking for ways to reduce IT costs. SRM tools, with their graphical user interfaces (GUIs), can augment or replace command-line storage administration tasks, which may tempt management to reduce the number of experienced administrators-significantly altering an IT department’s salary structure. One major telecommunications company was able to reduce its high-end, pricey storage administrators from eight to four, supplementing with less-expensive contractors and employees after the implementation of an enterprise SRM tool.

But is this a wise choice? Although the migration to SRM tools may lead a company to believe it can get by with less-expensive and less-experienced storage administrators, the trade-offs must be considered. Any cost relief gained by relying on inexperienced administrators should be weighed against the risk of outages that may result.

Experienced administrators understand the links between storage technologies and business requirements and have the foresight necessary to manage large amounts of data with differing protection requirements. Novice administrators likely will not have this level of understanding and may lack the ability to analyze complex infrastructures. For example, performance analysis and troubleshooting are key disciplines for storage administrators. Using performance-tuning applications often requires an advanced level of understanding and experience to translate and diagnose problems.

Also, storage administrators must be able to identify situations where the SRM data is not current. If zoning changes are made directly at the switch level, for instance, the SRM software’s configuration data might not be up to date. Therefore, applying changes to old configurations will almost certainly result in outages.

Using an SRM tool’s GUI for array and switch management potentially lessens the risk of employing novice storage staff. But risks still abound. SRMs are slow to take advantage of new functionality when introduced by the respective vendors at the array, switch, and host levels. If an organization wishes to use more-advanced functionality earlier than it is supported by SRM, then the organization must have significant expertise on hand to manage it.

When considering SRM adoption, IT managers must consider how advanced their operations are and weigh that against the benefits of SRM. As with most things, the truth is somewhere in the middle: SRM is generally worth deploying in large environments to consolidate and streamline management, but SRM will never replace seasoned expertise.

Page 1 of 1