This article can also be found in the Premium Editorial Download "Storage magazine: Solid-state adds VROOM to virtual desktops."
Download it now to read this article plus other related content.
VDI is tough on storage
Despite these benefits, VDI is no panacea for either IT managers or users. VDI places additional stress on the local infrastructure. VDI “boot storms”
Solid-state drives (SSDs) are a recognized solution to the boot storm problem. Boot-up operations are almost entirely read I/O activities and SSDs provide I/O performance substantially greater than that of hard disk drives (HDDs), especially on a per-GB basis. Although SSDs are much more expensive per GB, it’s not necessary to over-buy capacity to get the required aggregate I/O throughput as may be the case with HDD-based storage systems.
In the boot storm scenario, it makes sense to place the bootable images on a logical device and isolate access to that “drive.” It doesn’t make sense to use local SSD cache on the server because the image can be moved or hog the cache to the exclusion of other data.
Beyond boot storms
Beyond boot storms, SSD would appear to be very attractive to other applications in virtual environments. After all, since user I/O is centralized, front-end SSDs could handle high-demand activity and take the strain off the back-end HDD infrastructure. This would allow organizations to use high-capacity, low-cost HDDs to support their virtual desktops without sacrificing performance.
Unfortunately, a generalized SSD solution just doesn’t work in this scenario. SSD delivers optimum performance, whether implemented as cache or a separate storage tier, for recursive reads. It doesn’t work for random I/O workloads or for write-intensive operations. In a VDI implementation, the multitude of systems requesting user data appears to the disk system to be highly random. Data access for users is individualized, so the data requested by one user is unlikely to be requested by the next and therefore can’t take advantage of SSD read speeds.
With randomized data access, data will be continually swapped in and out of SSD. This creates two problems at the hardware level. First, SSD write performance is notoriously inefficient. SSD providers compensate through various write buffering and rotational write schemes, but these merely delay the inevitable. More insidiously, SSD cells can wear out in as few as 3,000 write operations, although enterprise-class SSDs can last as long as 100,000 write operations. Even so, with thousands or tens of thousands of users accessing the system, it won’t take long to start burning out cells. As cells wear out, the SSD performance gradually diminishes.
One company that attempts to solve this problem is Virsto Software with its Virsto for VDI “storage hypervisor” that virtualizes the storage serving virtual server implementations; both VMware and Hyper-V are supported. Virsto claims it can double the VDI performance per physical machine and reduce the storage needed for hypervisors by as much as 90%. With thousands of virtual machines (VMs), this could be significant. Moreover, Virsto eliminates the random nature of VM I/O with sequential writes and a logging architecture.
The common thread to these implementations is finding (or creating) environments where data isn’t accessed randomly or at least isn’t repeatedly rewritten. It’s neither cost-effective nor practical in most cases to implement an all-SSD storage environment. Storage managers need to target specific use cases where SSD will yield benefits that outweigh the costs.
This was first published in July 2012