Storage management is key to lowering TCO

To avoid a TCO TKO, storage administrators should consolidate resources and choose subsystems with the right management hooks.

By Bob Handlin

The amount of storage an IT administrator can manage depends largely on how well devices and software plug into an organization's larger storage management strategy. Many of the advantages offered by storage devices are offset by the higher total cost of ownership (TCO) incurred when those products either make the storage infrastructure more complex or are simply harder to manage.

It is no secret that IT budgets are under tight scrutiny. CIOs and IT managers are learning to do more with less. Vendors continue to deliver products with more performance and more bells and whistles, but the IT focus is shifting away from "bigger, better, and faster" toward reduced TCO. The wide array of devices to manage, each with its own interface and tools, has created an operations nightmare. For most storage professionals, management is more important than performance.

Click here to enlarge image

Today's problem is finding people to manage all of the storage resources, securing enough budget to pay them, and finding a way to hold on to them once they are trained. Having a manageable infrastructure allows you to maintain more resources with fewer people.

Data centers today can include a wide variety of storage devices, network components, and underlying protocols (see figure, bottom left). The most obvious problem is a lack of consolidation. Each of the islands of equipment has a separate hardware acquisition cost that's higher than it needs to be. This is because for every application, you have to buy more storage than you need to avoid the pain and expense of taking systems down to add more storage. As the cost of raw storage continues to drop, there's a temptation to just buy more cheap storage. Therein lies the trap: The biggest pain point is not in buying the storage, but in owning and managing it.

The critical attributes involved in building a manageable storage infrastructure include:

  • Consolidation of resources—The fewer resources you need to manage, the less complex the management task.
  • Proper instrumentation— Storage devices and software must be able to plug into a unified storage management environment.

Figure 1.
Click here to enlarge image

Consolidation is King
Storage should be a unified, manageable layer of resources that lets system administrators parse out services from a single source. With an intelligent infrastructure in place, storage can be presented as a unified "utility" layer that can provide whatever storage services your environment requires: Block storage over Fibre Channel for databases; inexpensive file services via network-attached storage (NAS), and maybe even iSCSI for block-level storage over IP or to extend your SAN across multiple sites (see figure 1). This architecture could offer:

  • Converged storage services—Put all of your storage assets under a single management umbrella, from which you can parcel out either block or file services.
  • Consolidated storage capacity—Build one big pool of storage per site. You can then manage capacity for just the one pool instead of disparate SAN, NAS, or DAS islands.
  • Management of storage access—Use the same set of "knobs" to control secure access to each of the resources, so you can run multiple applications per storage instance without worrying about intrusions.

The obvious benefit of consolidation is that you'll have fewer storage islands to manage, and each service will be manageable through the same set of management interfaces. This means you can manage more storage per administrator—a comforting thought in a world when system management professionals are hard to find, harder to keep, and increasingly expensive to employ (see figure 2).

Figure 2.
Click here to enlarge image

Device-level Management
To build a consolidated infrastructure, storage needs to plug into an organization's larger storage management infrastructure. Look for subsystems that do not require you to learn a variety of new interfaces. Vendors should provide unique tools for only those features that solve unique, device-specific problems (e.g., proprietary multi-site disaster recovery). Beyond that, make sure the vendors have instrumented their devices to plug seamlessly into existing tools that solve generic management problems. This requires:

  • A full-featured command line interface;
  • An embedded GUI;
  • Support for SNMP; and
  • APIs.

A command line interface provides the power of configuration scripts, which facilitates a variety of management tasks. First, it provides the ability to offload configuration files from devices, modify them as scripts, make changes, test the scripts centrally, and then deploy the tested scripts throughout the enterprise. This approach lets you focus infrastructure development on a few key engineers who can architect the entire global network, saving you the expense of local expertise at each site.

Second, it allows you to move a configuration off the device and archive it (daily or even hourly) for easier disaster recovery. Third, it makes discovering the source of a configuration error as easy as comparing a set of ASCII text files.

An embedded GUI simplifies otherwise complex, device-specific tasks. For example, if a product implements a unique virtualization scheme, the vendor should provide tools to make the functionality intuitive to users. The GUI must also be easy to integrate into any umbrella platform (HP OpenView, CA Unicenter, etc.) that has been deployed.

A GUI can be critical for troubleshooting a particular device. A misbehaved system sometimes has configuration issues in areas of the software where your specialists don't usually spend a lot of time and haven't necessarily memorized the syntax. The GUI makes browsing the system for such issues—and then correcting them—a far more intuitive task.

SNMP is required to integrate into existing management environments. A comprehensive set of Management Information Bases (MIBs), accompanied by a rich set of event and statistical information, allows a device to plug into a wide variety of enterprise management applications.

Users and software vendors need ways to address a device programmatically, to unlock functionality in the device that the vendor hasn't yet packaged through a particular management interface. Newer entrants to the market are offering a generalized approach to managing their devices, using eXtensible Markup Language (XML) and the Common Information Model (CIM). The popularity of XML stems from its ability to support multiple data types, using an Internet-friendly format that is similar to HTML. Because of this, when XML is combined with the standard objects being defined for CIM, XML can provide a structured approach to configuration and data movement. This combination shows great promise as the next-generation API of choice.

This last piece of the puzzle is critical to the long-term manageability of a device in consolidated software environments. Without a solid API, the long-term upside potential for managing a device that is part of a heterogeneous storage infrastructure is limited.

Bob Handlin is senior product manager at Pirus Networks (www.pirus.com) in Acton, MA.

This article was originally published on May 01, 2002