Reinventing storage virtualization

The initial approach to storage virtualization, which has been around for years, was to address it in the storage-area network  because the SAN sat between the storage and servers, and would cause the least disruption to these systems. However, after nearly a decade, this approach has not taken off while server virtualization has become widely accepted. What needs to be changed to make storage virtualization as ubiquitous as server virtualization?

Before the advent of server virtualization, servers were configured for peak load but most of the time sat idling, resulting in average utilization rates in the low teens. Many attempts were made to consolidate applications on servers to utilize idle cycles, but it was difficult to convert applications between different operating systems. The breakthrough came with the ability to virtualize the server so it could run any operating system, enabling applications to be consolidated without converting them.

The utilization of storage systems is also low, typically in the 20% to 30% range. Storage gets stranded because application owners do not want to share storage and risk having other applications impact performance or availability. Since most open systems do not allow storage volumes to be expanded as the application generates more data, the common management practice is to simply overallocate storage capacity. While the declining cost of storage helps limit the cost of that practice, the operational cost for environmentals, change management, backup/recovery, technology refresh, and search and discovery escalates as storage capacity becomes increasingly oversubscribed and underutilized.

Storage for open systems is presented through logical unit numbers (LUN) or volumes that a storage system carves out of a RAID array group of physical disk drives and presents to the application. This process of creating LUNs and managing them is vendor unique. In order to virtualize storage from different storage systems, the difference in LUN or volume management must be masked.

Early attempts at storage virtualization tried to address this problem by remapping heterogeneous LUNs to a common virtual LUN format for presentation to the host systems. But remapping introduced another layer of operational and management complexity, which inhibited the acceptance of the approach.

The breakthrough came with the ability to virtualize physical LUNs without the need to remap them by using a virtualization technique based on storage control units. LUNs are configured in the external storage systems in their vendor-specific way. These LUNs are then connected to the virtualization control unit over Fibre Channel ports as though they were connecting to a host server. Software in the control unit discovers the LUNs on the Fibre Channel port and presents them through the control unit's cache to an application server as if the LUNs were one of its own internal LUNs.

This approach does not remap the LUN, but enables LUNs from different systems to be managed with the common management tools of the storage virtualization control unit. The LUN image is presented inside the control unit cache and inherits all the services that are available in that control unit, like copy, move and replicate. There is no need to reinvent these functions for the purposes of virtualization. Lower-level storage can improve their native performance by connecting through the large high-performance cache of the virtualization control unit.