Virtualised storage can help firms get more out of a SAN, by sharing space efficiently across the network and enabling easier backups. ZDNet examines the virtualisation solutions on offer.

Virtualised storage is a new approach to storage area networks (SANs), designed to provide a shareable storage pool, which can include equipment from many different vendors. With virtual storage, physical storage is converted into a pool of logical blocks that can be presented to servers.

SANs without virtualised storage have already addressed many of the important issues involved in storage management. They allow storage to be managed separately from servers, and they make it possible to add more storage without having to rebuild or reboot servers, for instance. SANs also allow storage to be replicated between remote sites and can make it easier to back up networks. Standalone SANs
But SANs have some shortcomings. It is still necessary to assign physical storage devices to specific servers or at least to specific file systems, for example. In addition, many of the SANs installed so far have been vendor-specific, and while interoperability is improving, it is still not guaranteed. Corporate mergers and the piecemeal implementation of SANs have left some firms with SAN islands that do not link effectively with each other.

Storage can be an expensive element of a network, and it can be made more expensive if some of it is wasted Ã,­ and this often happens. 'Most people, when they configure a server, they might put in 100GB of storage, then add another 100GB just to be safe,' says Donal Madden, storage business manager for Compaq. This surplus capacity mounts up as servers are added, but it can be reduced by consolidating storage so that several servers can share surplus storage Ã,­ so the total safety margin can be reduced.

It is already possible to virtualise storage within the host servers, but the storage device must have been partitioned to those servers before deployment, and it will need software running on the host. Alternatively, it can be partitioned within the storage subsystem, so that an array appears as multiple logical volumes, but then it is valid only for that subsystem.

The best approach to developing virtualised storage is probably to add intelligent systems within the SAN itself. This may be done by adding a SAN management appliance to look after the virtualisation process.

This SAN management appliance (SMA) is the only SAN node which sees the storage devices and the servers as they actually physically are, while everything else merely sees what it is permitted to see. Storage can be pooled by the SMA and made available to servers as SCSI blocks. Erik Ottem of SAN specialist Gadzoox, says, 'The SAN serves up SCSI blocks, there's no volume management or file system. Each operating system only sees the storage allocated to it, but it's not limited in any physical form.'

This removes the need to allocate physical devices to specific servers, and it allows dissimilar devices to be mirrored. To mirror 50GB of data, all that is needed is another 50GB of capacity, regardless of whether it is part of a Raid subsystem or a single drive. Storage can also be split into multiple pools and the pools mirrored. SAN virtualisation also makes it possible to dynamically alter storage volume sizes.

Chris Lentz of virtual SAN software developer Datacore says, 'We can take storage from anybody Ã,­ including SCSI and IBM's Serial Storage Architecture (SSA) Ã,­ and turn the lot into an open storage pool that you are able to deliver across the network to any client.'

Lentz argues that when virtualised storage systems are being set up, it is helpful if changes to host servers and file systems are kept to a minimum. 'Minimum intrusion is the name of the game Ã,­ we don't install software on the servers so it is completely non-disruptive to the application servers. But some of the marketing people say it is a disruptive technology because it makes people think differently.'

Using this type of approach, any application that will run on a SCSI disk can also run on virtualised storage Ã,­ for example, Veritas Volume Manager, or another disk management system. And because the SMA controls access to storage it can add a second level of security, alongside zoning within the switched fabric.

Disk map decisions

There are two ways of implementing virtual storage: symmetrical and asymmetrical. In symmetrical storage virtualisation, version B in the diagram below, the control device sits astride the data path and all data requests must pass through it. Asymmetrical virtualisation (version A) places the control device alongside the data path. The virtualisation theory is the same; the difference is where the virtual disk map is stored.

Symmetrical virtualisation is typified by devices running Datacore's SANsymphony software, such as the Gadzoox Axxess SMA. This is an Intel-based rack-mounted server with dual or quad Pentium III Xeon processors, running Windows NT, but only the kernel and storage services are loaded.

While the Axxess SMA connects directly into a Gadzoox Capellix switch using two or more host bus adapter cards (HBAs), the two are tightly integrated. The SMA uses zoning to separate the servers and storage, with only the Axxess device seeing both. This has backup advantages, as the SMA knows what is stored where and can replicate it if necessary. It can also aggregate the storage allocated to each operating system environ-ment and back it up as a block.

The symmetrical approach can affect network performance. Every I/O must go through the SMA, because it sits on the data path between the servers and the storage pool. Axxess therefore incorporates up to 2GB of cache to reduce latency. But a fabric can only have one active Axxess SMA, though it can be connected to multiple Fibre Channel switches, subject to perfor-mance limitations. A second SMA could be added for redundancy, but it would have to remain inactive until needed.

Asymmetrical virtualisation avoids this problem. It allocates storage blocks to the servers, which must then store the block map needed to keep track of these allocations. This could be done in software, but for performance reasons, and to avoid changes to applications, a modified HBA card is the preferred route.

StoreAge, for example, has developed a SAN appliance to support virtual volume management across heterogeneous storage. It relies upon StoreAge's own PCI-based intelligent HBAs, and allows users and applications to request services from the SMA, which the firm calls a Metadata Centre, because it creates and distributes metadata:Ã,­ data about data.

The StoreAge technology is proprietary, but similar open technologies are under development. The best example is probably Compaq's VersaStor technology, which has attracted support from key SAN companies including StoreAge and IBM, as well as Fibre Channel switch developers Brocade and McData, and HBA developers such as Emulex, JNI and QLogic.

VersaStor, too, will rely on block maps loaded into HBAs by a storage management appliance, which in turn has to be intelligent enough to handle load distribution and data migration. This still leaves the SMA as a potential single point of failure, but if it does fail the SAN can continue as normal, using the stored block maps.

Symmetrical schemes have the advantage that they can work with today's SAN hardware, whereas VersaStor must await the development of proprietary appliances. But asymmetrical virtualisation may offer higher reliability and performance.

Copyright © 2009 CBS Interactive, a CBS Company. All Rights Reserved.
ZDNET is a registered service mark of CBS Interactive. ZDNET Logo is a service mark of CBS Interactive.