A 10-step plan for deploying SANs

A 10-step plan for deploying SANs

In many IT environments, the most acute problem is backup and restore, which clogs the corporate network, causes administrative nightmares, and contributes to overall TCO.

Richard R. Lee

The storage industry has put a lot of resources into promoting both the concepts behind and the benefits of storage area network (SAN) architectures. However, the industry has not done enough to educate end users and storage architects on how to deploy SANs without abandoning much of their existing client/server assets and storage infrastructure. As a result, most key decision makers are left with the impression that the SAN paradigm and all of its benefits can only be realized by "ripping and replacing" their existing enterprise storage infrastructures.

It is therefore necessary to explore both the practicalities and pragmatics of designing and deploying SANs based on existing and new storage assets, while leveraging your current enterprise infrastructure.

SANs should provide:

- Anything-to-anywhere connectivity

- High availability (fault resistance/tolerance)

- Scalability (capacity and bandwidth)

- Centralized enterprise-wide storage resource management

- "Off-the-network," or "LAN-free," backup and restore

- Storage resource sharing

- Disk and tape pooling

- Third-party copying (instant copy)

- Homogeneous and heterogeneous data sharing

- Dramatically reduced TCO (acquisition, administration, and support)

These capabilities require an architecture that supports maximum flexibility in its connectivity options, has no single points of failure or systems bottlenecks, and enables ubiquitous access to any file from any client or server across the enterprise (access permissions withstanding). This level of capabilities requires a switched fabric based on a high-bandwidth, low-latency interconnect technology. Fibre Channel meets these requirements, but is still relatively new and has limited interoperability with existing interconnect standards and storage assets.

Most storage architects want to use existing interconnects, such as SCSI, ESCON, and SSA, and other installed assets (such as JBOD, RAID, tape libraries, and optical jukeboxes, along with new ones (e.g., Fibre Channel fabrics) to build an evolutionary SAN.

To provide a bridge to the past, and a gateway to the future, consider the following 10-step plan for deploying your SAN.

1. First, identify SAN capabilities that are a "must have" during your initial phase of server-centric (e.g., client-server) to storage-centric architectural migration. In many IT environments the most acute problem is backup and restore, which clogs the corporate network and causes administrative nightmares. This is an ideal candidate for Phase 1 activities.

2. Define which server assets will be used in your Phase 1 deployment. This "server review" provides a unique opportunity to fine-tune your server consolidation efforts. Many servers are dedicated to backup and restore operations, and can now be re-deployed or retired.

In addition, because the cost of attaching all servers to a SAN can be substantial, it is prudent to examine how older servers can be retired and their workloads consolidated onto newer, more powerful machines with better scalability and throughput.

3. Determine which applications will operate in your SAN environment during its initial deployment phase. In the initial phase, many applications will not be SAN-aware and will not take full (or partial) advantage of your SAN`s capabilities. In many of these scenarios, there will be requirements for local, server-based storage, along with storage on the SAN.

4. Determine and define "sharing" requirements. File and print sharing will be major services that can take advantage of disk and tape pooling. Although not highly visible on most people`s radar screens, file and print sharing are core components of any enterprise. Given the size of these shared resources, they are well positioned to use SANs from day 1, offloading the overtaxed server-based storage devices.

5. Determine which storage management platform will become the "standard" for your SAN. In most heterogeneous and distributed enterprise environments, no single storage management platform is used for all requirements.

There are different management platforms for Unix, Windows NT, NetWare, and all the proprietary operating systems (OS/390, AS/400, VMS, etc.). All are from different vendors and many may not be available in "SAN-aware" versions.

With your SAN deployment, you may have the opportunity to finally standardize on one storage management platform to meet all requirements.

6. Define initial storage capacities and volume requirements for each node (server) and the applications/services that it supports. Using zoning techniques, along with virtual RAID configurations, you can map initial storage and volume configurations. Using typical SAN configuration tools, you can also assign maximum values to allow for unanticipated growth.

7. Define disaster tolerance requirements for critical applications/services and data. This will include using remote mirroring (logically and physically) and developing business continuance policies and procedures in the event of an application/server outage or failure anywhere on the SAN.

8. Determine which applications and services will be used in either high-availability or high-scalability SAN cluster scenarios. Via its "shared-everything" storage environment and through the use of built-in virtualization techniques, clusters of nodes can be easily configured for either high availability or scalability.

9. Define your deployment timetable with respect to how and when you will set up your SAN and when you will begin "cutting over" to it.

Given most SAN architectures, there will be little, if any, opportunity to operate systems in parallel until they have been proven to be "production-ready." You will also need to move backup activities off local severs and onto the SAN at an early stage. This will make the overall migration process more manageable.

10. Develop and establish "test scenarios" and "fire drills" in testing the SAN. Using replicated data sets from critical applications and backup data, you can test your SAN under simulated load conditions, along with introducing controlled failures to determine "best practices" procedures for data recovery and re-establishment of SAN activities.

SAN hype is running rampant in the storage industry today. With some exceptions, everyone is focused on the features and benefits of this new paradigm, with few willing or capable of divulging the details of "how we get there from here." This has started to create a credibility gap in the minds of IT managers as they attempt to differentiate between the rhetoric and actual deliverables.

By taking a practical approach to deploying your SAN, you can reduce--if not eliminate--many of the risks while still leveraging your existing infrastructure and storage assets to the maximum extent possible.

Richard R. Lee is president of Data Storage Technologies Inc., a management and technology consulting firm in Ridgewood, NJ. He is a frequent contributor to InfoStor, and is the author of "Microsoft Windows NT Cluster Server--MSCS" (1999), Osborne/McGraw-Hill.

This article was originally published on July 01, 1999