After some years of false starts and false hopes, storage virtualization, also known as block virtualization, is finally proving its worth. All the major vendors have embraced it, most notably IBM, EMC, and HDS (Hitachi Data Systems); the solutions themselves have improved; and customers, typically large shops managing large SANs with intense data availability requirements, understand how to deploy it and where to get good ROI. No longer a technology in search of a problem, storage virtualization offers a way to address a wide range of storage management woes.
![]() |
In addition to creating storage pools composed of physical disks from different arrays, storage virtualization provides a wide range of services, delivered in a consistent way. These stretch from basic volume management, including LUN (logical unit number) masking, concatenation, and volume grouping and striping, to data protection and disaster recovery functionality, including snapshots and mirroring. In short, virtualization solutions can be used as a central control point for enforcing storage management policies and achieving higher SLAs.
Perhaps the most important service enabled by block-level virtualization is nondisruptive data migration. For large organizations, moving data is a near-constant fact of life. As old equipment comes off lease and new gear is brought online, storage virtualization enables the migration of block-level data from one device to another without an outage. Storage administrators are free to perform routine maintenance or replace aging arrays without interfering with applications and users. Production systems keep chugging along.
Click for larger view. |
Four architectural approaches
In a virtualized SAN fabric, there are four ways to deliver storage virtualization services: in-band appliances, out-of-band
appliances, a hybrid approach called SPAID (Split Path Architecture for Intelligent Devices), and controller-based virtualization.
Regardless of architecture, all storage virtualization solutions must do three essential things: maintain a map of virtual
disks and physical storage, as well as other configuration metadata; execute commands for configuration changes and storage
management tasks; and of course transmit data between hosts and storage. The four architectures differ in the way they handle
these three separate paths or streams — the metadata, control, and data paths — in the I/O fabric. The differences hold implications
for performance and scalability.
An in-band appliance processes the metadata, control, and data path information all in a single device. In other words, the metadata management and control functions share the data path. This represents a potential bottleneck in a busy SAN, because all host requests must flow through a single control point. In-band appliance vendors have addressed this potential scalability issue by adding advanced clustering and caching capabilities to their products. Many of these vendors can point to large enterprise SAN deployments that showcase their solution’s scalability and performance. Examples of the in-band approach include DataCore SANsymphony, FalconStor IPStor, and IBM SAN Volume Controller.
Steve Norall is a senior analyst for the Taneja Group.
Talkback
E-mail
Printer Friendly
Reprints





