Extending Management Functions in Volume Management and SAN Virtualization Systems

Once virtualization lenses and storage pools have been implemented, they tend to remain in place for a long time. It's not surprising that volume management and SAN virtualization system vendors have integrated other management functions into their products, including hot sparing and automated storage migration.

Hot Sparing with Volume Managers and SAN Virtualization Systems

The basic idea of hot sparing is to have storage resources in reserve that can be used to take the place of a failed member in a mirror or RAID array.

Whereas storage subsystems work with internal disk drives in the subsystem, volume managers and SAN virtualization systems work with downstream subsystems in the SAN. This means that many types of storage could be used as hot-spare storage to cover a wide range of address spaces. The flexibility of SAN access with volume managers and SAN virtualization systems results in the widest range of options for hot sparing.

Automated Data Migration Using Volume Managers and SAN Virtualization Systems

Sometimes it is preferable to replace existing storage instead of adding storage. Some of the reasons for replacing existing storage are as follows:

• It eliminates maintenance charges on existing storage products.

• Faster performance is needed that cannot be achieved with the existing storage product.

• Existing storage is nearing end of life.

• You can install storage with new management features.

Data migration can be done at the storing or filing level, but where storage virtualization is concerned, it is a storing-level function. Virtualization-driven migration is a process that transfers data from one or more LUs to one or more other LUs. Although the new storage will likely be larger in capacity than existing storage, the migration process needs to use the same-sized address space so that the filing system that uses it can access data with the current set of addresses.

Traditionally, data migration was done while the system is unavailable to users and applications to avoid potential data integrity problems. However, it is also possible for a volume manager or SAN virtualization system to migrate data on a running system without having to stop any application processes.

To accomplish this, the virtualization product starts copying block data from the first address space on the old LU(s) to the new one(s), keeping a record of all block addresses that have been copied. When a request is made to read data that has already been copied, the request is serviced from new storage. When a read request is made to access an address that has not been moved yet, it is serviced from old storage. When an update is made to data that has not been moved yet, it can be written to both new and old storage, eliminating the need to copy those blocks from old to new storage.

After all the data is copied, the volume manager or SAN virtualization system applies substitution to transparently switch over to the new system. While the new storage presents a new network address and identity to the virtualization product, the host filing system is "spoofed" into believing the old storage is still being used. At some point the system may be stopped and the actual addresses and identities may be configured. A good time for this would be when expanding the capacity of the filing system.