A Well-Designed Volume Manager - Technology Information

Computer Technology Review, April, 2000 by Nelson Nahum

The emerging Storage Area Network (SAN) architecture, seen by most experts as the solution for the increasing needs for storage in enterprises, dictates new techniques of storage management not found in the traditional server-attached storage. The need of sharing storage subsystems by many Application Servers with a uniform management scheme introduces new hardware, software, and storage interfaces.

The new widely adopted storage interface is Fibre Channel (FC). FC allows for higher transfer rates, hot plugs, increased distance, and increased number of initiators/devices attached. However, the adoption of Fibre Channel by itself is not enough to implement a real working SAN.

The Need For A Volume Manager

The fact that, with Fibre Channel, many computers and storage subsystems can coexist and interact on the same SAN causes new challenges that were not present in the traditional "one to one" topologies. One of the main problems is created by the fact that all the computers on the SAN see the same RAID partitions of a storage subsystem. This FC characteristic may cause different computers with different operating systems to write data and signatures to the same RAID partition, corrupting each other's data.

Most of the current RAID subsystems have a limited partition capability (eight to thirty-two LUNs). This limitation does not normally present a practical difficulty in a server-attached storage environment. However, in a SAN environment, many computers (possibly over 32), can share the same large (and expensive) storage subsystem causing the 32 LUN limitation to be a significant handicap.

One of the key advantages of the SAN is that storage is added "as needed". In a conventional design, a user needs to carefully plan his future storage requirements in order to purchase enough storage. The ease by which devices are added with Fibre Channel allows the user to purchase storage only for his immediate needs and add more as required, benefiting from the sharp decline in storage prices. However, while this is one of the most important features of Fibre Channel-based architecture, its benefits to the user cannot be realized without a flexible Volume Manager.

A Volume Manager designed for SAN should be able to assign information to any specific user free storage space available on the SAN at any location and RAID level desired, without regard to physical location, topology, individual disk capacity, and other elements of the physical setup of the SAN. The Volume Manager should also provide for a completely flexible mechanism for expanding existing volumes or creating new volumes as may be required by the individual applications.

The Fibre Channel standard allows for the attachment of multi-vendor storage subsystems, as well as multiple servers with different Operating Systems. NT 2000, Linux, Netware, and Unix servers should be able to share the same storage subsystems. While this is a major advantage of the SAN architecture only the connectivity function is provided via the Fibre Channel protocol. A uniform Volume Manager across the SAN is needed in order to simplify the management of the various storage elements and fulfill the real promise of SAN.

For all the above reasons, a properly designed Volume Manager becomes an essential component for a real SAN implementation. A Volume Manager designed for SAN should be capable of:

* Creating Volumes from many and different storage subsystems;

* Expanding Volumes with nonconsecutive storage space from different JBOD and/or RAID subsystems;

* Assigning Volumes to selected servers within the same SAN and hide from the others;

* Changing "access permissions" from one computer to another;

* Creating unlimited number of Volumes;

* Managing all the Volumes in a uniform way, independent of the specific storage subsystems and/or Operating System;

* Providing a platform for Operating System independent Storage Applications. Such applications may be used to replicate, compress, produce "snapshots," and many other manipulations of the Volumes within the SAN without affecting host server performance.

Current Solutions

Most existing systems do not provide for a real, SAN-oriented volume management function. Typically, volumes, as they are defined in a storage subsystem, are merely Logical Units (LUs), which are just simple partitions of the RAID subsystems. Typical systems allow for eight to thirty-two such "volumes." It is important to note, however, that these "volumes" are created, allocated, and managed at the RAID subsystem level and not at the SAN level. For example, a volume cannot be created across two (or more) RAID subsystems (even from the same type), or a system cannot present to a host many small volumes (say few hundreds), or a volume cannot be expanded, etc. Therefore, these designs lack some essential functionality required from a SAN-oriented Volume Management system.

In addition, the volumes created by these RAID subsystems assume a one-to-one correspondence with servers, even though more servers and RAID subsystems may be physically connected on the same Fibre Channel loop or fabric. This architecture relies on external measures to resolve storage access conflicts, e.g., fabric switches with zoning capabilities and FC host adapters with "hiding" functions. Another common solution is the use of host-based management software, which front-ends the operating system storage access system and can create, manipulate, and hide volumes. This solution, by its very nature, is again not a SAN level solution; for example, one host cannot create a volume to be used by another host.