Anybody who has struggled with configuring storage for VMware virtual servers will be happy to hear help is on...
the way -- the solution to your problems may be hidden in your array.
By Jeff Byrne
From the moment server virtualization burst onto the scene nearly a decade ago, it has created significant challenges for data storage managers. And based on recent Taneja Group research, many of those challenges are far from being overcome.
In our most recent end-user survey on virtual server storage, we found more than half of storage administrators are experiencing one or more of the following storage-related issues in their virtual server environments:
- Scalability: Server consolidation leads to contention for storage and I/O resources, limiting the number of virtual machines (VMs) that can be run productively on a given system.
- Performance: The multiplicative effect of repetitive, small-block I/O operations -- driven by a hypervisor and performed across multiple VMs -- can have a crippling effect on storage performance.
- Agility: In a heavily consolidated environment, common administrative tasks such as creating and provisioning a VM, migrating workloads to new servers and non-disruptively moving virtual machine disk files between arrays, can be quite tedious and time consuming.
These problems are exacerbated in a VMware vSphere/ESX environment because VMware's hypervisor-driven approach to storage creates some significant challenges for storage providers. VMware Virtual Machine File System (VMFS) imposes an additional layer in the stack connecting virtual servers with storage, making it difficult for vendors to make native, array-based storage capabilities available to VMware users and applications. Because many storage operations have been recently emulated in software by vSphere/ESX, users can't take advantage of the higher performance available in array-based hardware.
Clearly, the right place for these functions is in the array. Citrix Systems Inc. first demonstrated this in 2009 with the release of StorageLink, which enables XenServer-based applications to directly take advantage of array-based functionality. But the VMFS layer has prevented VMware-driven applications from fully leveraging array capabilities.
Fortunately, with vSphere 4.1's vStorage, VMware provides the means for storage vendors to take these storage matters into their own hands. The vStorage APIs for Array Integration (VAAI) are designed to enhance primary storage integration. By offloading VM operations that should be handled at the array level -- such as Storage vMotion, VM provisioning and cloning -- VAAI lets storage vendors address the storage issues that may have inhibited the adoption of VMware server virtualization. Let's look at the VMware-specific storage problems and how the VAAI-enabled capabilities now offered by major storage vendors address those issues.
1. Limited virtual machine scalability due to LUN-level locking. In earlier versions of vSphere and ESX Server, tasks such as creating, migrating or snapshotting VMs caused a complete LUN to be reserved each time shared storage was accessed. The hypervisor accomplished the LUN-level locking operation through the use of SCSI reservations, which required several SCSI commands. Unfortunately, the LUN was unavailable
to other virtual servers while it was locked, resulting in resource contention and performance penalties.
A VAAI function known as Hardware Assisted Locking allows storage to be locked at the block level rather than at the volume (LUN) level by using one efficient SCSI command. Concurrent access reduces contention; multiple VMs on a single LUN are no longer in a latency-sensitive race to lock and unlock the LUN over and over again. Moreover, this frees administrators to conduct a broader range of storage-intensive tasks (clones, snaps, formats, etc.) during peak hours without impacting application performance.
2. Inefficient and repetitive write operations. Prior to VAAI, a number of common vSphere operations, including provisioning VMs from templates and extending thin provisioned virtual disks (VMDKs), interacted with block storage inefficiently. vSphere/ESX would move empty blocks of data (zeroes) to the array via the repeated execution of SCSI write commands and the transmitting of zeroes over the network.
With the new VAAI Block Zero capability, construction of zero data blocks can be offloaded to an array, reducing the amount of I/O created by servers and transmitted data. When VMFS encounters data blocks containing zeroes, write operations can be replaced by a single SCSI WRITE_SAME command, which transmits a sector of data along with a count of how many times that sector should be duplicated on disk. In-array creation of empty data can be used with any array, but it's more useful where thin persistence technologies in the array can capture zero writes on ingest and avoid the writing of empty data to disk altogether.
3. Slow and resource-intensive VM cloning and data migration. In earlier versions of vSphere and ESX, VMware copy operations such as VM cloning and Storage vMotion were accomplished via the use of millions of back-to-back, small block I/Os in which small blocks of data were moved from array to host (via SCSI READ commands) and back again (via SCSI WRITE commands). This approach was extremely I/O intensive and consumed considerable physical server and network resources.
The VAAI Full Copy function changes all that. Similar to Block Zero operations, Full Copy can execute block operations (copy or move) entirely within the array through use of a SCSI Extended Copy (XCopy) command and without the involvement of the host. While Extended Copy minimizes I/O across server hardware and reduces the consumption of network bandwidth, Extended Copy operations can also execute with far greater speed. Storage controllers can use their full internal bandwidth, optimization mechanisms and workload awareness to move data with maximum efficiency without needlessly consuming precious controller cache.
The vStorage foundation in vSphere 4.1 contains functionality well beyond just primary storage, including mechanisms that can enable better backup handling, deeper snapshot or continuous data protection (CDP) integration, and more. If you're a VMware user, vStorage is certainly one strong reason to consider adopting vSphere 4.1. vStorage may make a significant difference in how well your data storage infrastructure meets your virtual infrastructure demands. Whether you're considering primary storage, data protection, replication or some other part of your infrastructure, ask your storage vendor if they leverage vStorage and VAAI capabilities in particular.
BIO: Jeff Byrne is a senior analyst and consultant at Taneja Group. He can be reached at email@example.com.