SAN design and management: an ongoing process

Computer Technology Review, July, 2004 by Thomas J. Lynch

Many organizations today still approach SAN design and management like a one-time event: once it's done, it's done. The problem with that approach, however, is that businesses aren't static. Data is continually growing. New regulations affect how data is handled. Storage needs change. And the SAN has to change to meet those needs.

The Evolution of Storage Management

Of course, being able to change a SAN design in response to shifting business requirements assumes that some kind of design even exists, and historically that hasn't always been the case. Much like the adoption of the LAN in the late 1980s and early 1990s, the adoption of the SAN was slower than anticipated. While pioneers and pundits in the storage industry heralded each passing year as the "Year of the SAN," their lofty, extensive vision of SANs did not really materialize as predicted. Instead, the real-life problems of the data center and ever-shrinking budgets for new technologies required pragmatic, tactical solutions.

Initial storage solutions tended to be simple and piecemeal. Long SCSI, technology bridging, fabric conversion and server consolidation solutions solved a problem for IT and were not encumbered by overly optimistic expectations, but they were limited by their lack of interoperability and extensibility. In addition, lack of standards and dueling standards slowed the adoption of new technologies, as did the volatility of the competing storage hardware and software vendors. With no clear leader in the field, various manufacturers came and went or were absorbed by other companies, contributing to the lack of clear direction in the storage market.

In the midst of this chaos, IT departments recognized that continuing data growth would require iterative changes in their approach to storage, and that well-planned SANs were needed to provide a more cohesive and reliable solution. Eventually, standards emerged, the backplane became the backbone of the enterprise, and the islands of information began to join.

It Takes a Process

While the virtues of the SAN have become clear, and many technological obstacles have been overcome, budgetary constraints continue to be a problem. Strapped for cash and limited in staffing resources, IT professionals must plan well and spend wisely. To stretch available dollars as far as they can go, the implementation of more efficient and wide-sweeping technology must be combined with better processes.

An effective process for designing and managing a SAN involves four basic steps:

* Identifying what you've got

* Classifying what you've got based on its characteristics and the relationship of the parts to one another

* Defining policies and procedures for managing both the SAN and the data it stores

* Automating the defined policies and procedures

Identification

Like any journey, to be able to get where you're going, you must first know where you are. Before you can implement a sound storage strategy and process, you must first identify what storage resources you currently have. From a SAN perspective, this includes identifying the servers, operating systems, applications, infrastructure and peripherals (tape automation systems, arrays, jukeboxes and so forth). The IT environment, captured in this way, can then be succinctly and successfully communicated to the other members of the IT department as well as other departments and stakeholders within the organization.

For many organizations, creating such an inventory involves using spreadsheets, e-mail, sticky notes, charting programs or other static communication mechanisms to produce an almost (but clearly not) real-time picture of their IT world. More sophisticated methods include the use of SAN design tools that automate the discovery process, support the collection of detailed information about the configuration and subcomponents of each element in the SAN, and automatically check for interoperability problems or incorrect connections or configurations.

[ILLUSTRATION OMITTED]

Classification

Once the parts of the SAN have been identified, the next step is to classify them based on the characteristics and capabilities of each device, as well as the relationships among them. How much capacity is available on each device? What's the unit cost for storage? How are the devices interconnected? Who has access to each zone, and what can they do with the data stored there?

This assessment is sometimes very revealing, as many organizations find over-allocated space, large amounts of capacity lurking in the dark corners of the SAN or potential security breaches. As the classification process proceeds, a true image of the SAN begins to take shape. Components once perceived as independent entities can now be seen as part of the whole. Their vertical relationships (application-to-spindle) and horizontal relationships (infrastructure, racks in arrays in frames, applications and operating systems) as well as their relationship to the business become more apparent.

Definition

The next step in the process involves defining how the components of the SAN relate to the workflow of the organization, both in terms of maintaining the SAN and maintaining the organization's data.