Building a virtual infrastructure with scalable storage is a cheaper, more flexible alternative to shared storage, and a virtual storage appliance is a convenient way to achieve this design.
Virtual storage appliances (VSAs) have gone mainstream in the past year. Since VMware launched its first
NetApp released a production-ready version of its OnTap appliance after years of testing and demonstration. Hewlett-Packard also rebranded the original LeftHand appliance as the StoreVirtual appliance, which has large-scale SKUs for hundreds of nodes. Even pure software players, such as Nexenta Systems, have begun to package their software as VSAs to enable scenarios not possible with traditional storage.
As with all new technology, the appliances do have drawbacks, and you must make compromises to ensure you meet the business requirements of a VSA deployment.
VSA deployment basics
A VSA is a scalable storage system on a virtual machine (VM) that consumes local storage in one host and makes it available to multiple hosts as shared storage. Usually the storage from the VSA is consumed again by a hypervisor and used to run another VM.
Some VSAs also provide redundancy by replicating storage among multiple VSAs, each located on a different physical hypervisor. This enables VM migrations between hosts and, with replicated VSAs, even high availability for VMs without a dedicated SAN or network-attached storage. These are the fundamentals of VSAs, but each vendor extends these capabilities and enhances their application to compete with the rest.
Sacrificing disk capacity
Because of its redundant nature, a RAID reduces available disk capacity, but this is the price we pay to eliminate downtime when one disk fails. The storage a VSA consumes from the hypervisor will usually be on a RAID disk set, which means we sacrifice 10% to 50% of disk capacity for this continued operation.
More resources on deploying VSAs
Virtual storage appliance: How it works and what it does
Virtual storage appliance expands beyond SMB use into enterprise
Virtual storage appliances drill-down: Optimizing VSAs
To avoid losing access to the storage shared by the VSA, most VSAs work in clusters of two to 10 VSA nodes. The data then resides on at least two cluster members on different physical hypervisor hosts, which ensures the VM data is still available from another VSA if one host fails. Storing two copies of the data on two VSAs, however, means you only get to use half of the capacity of the RAID array.
With 10% to 50% of disk capacity set aside for a RAID, we now lose 50% of what remains to replicated VSAs, leaving us with 25% to 45% of the original scalable disk storage space. Fortunately, the disks in your physical servers are usually cheaper than the SAN disks you would have to use without VSAs, but you must still plan for capacity loss.
Performance compromises and multiple disk writes
When deploying a VSA, disk access from the VM must pass through a hypervisor twice -- once between the VM and the VSA and a second time between the VSA and the physical disk. Though the latencies are small, they add to every transaction and produce a lower maximum performance limit. As a result, many VSA deployments will use a small number of low performance disks, limiting VM performance before these latencies become an issue.
When you use VSAs to provide high availability, you often turn local host disks into redundant shared storage. To accomplish this, the cluster of VSAs maintains multiple copies of the VM data on different physical hosts. Every VM disk write must be sent to two different nodes, which doubles the I/O load for the VM and can compromise performance.
RAID has a write multiplier effect, where one VM write process to a RAID produces between two and six disk accesses on the physical disks. If the VSA multiplies the writes by two and the RAID array then multiplies by four (RAID-5 has a four write multiplier), we end up with one VM write producing eight physical disk accesses. Typically, this causes no problems, but it can pose a risk for some workloads. Multiplying write processes with terminal servers or a virtual desktop infrastructure can slow performance and affect end user satisfaction.
Making compromises for scalable storage
VSAs can remove the requirement for dedicated shared storage and provide scalable storage without single points of failure. The appliances can, however, cripple the performance of some VMs. Understanding the workload you will apply to the VSA and its effect on physical storage is as critical to a successful deployment as understanding the inner workings of each VSA.
This was first published in December 2012