Back in September, I wrote an article describing a product that I wanted that didn't exist: a local "virtual" storage option for VDI. Basically I described why I didn't like SANs for VDI and that I thought it would be cool if there was some sort of software that could virtualize access to the local hard drives that are in a VDI host server. I was thinking a solution like that could create the best of both worlds: fast flexible storage without the overhead costs of a SAN.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The new "IntelliCache" feature that's part of XenServer 5.6 SP1 is kind of along those lines, although it only works with shared disk images today (while most of today's VDI solutions use persistent disks).
In a new white paper from Datacore (direct PDF link), they claim that their SANmelody software running on a VDI host does fulfill my fantasy storage requirements. And they claim they can do it with full multi-server redundancy with a cost of less than $70 per user. (That's $70 for everything.. the VM host, the SANmelody software, the disks you need for storage... everything!)
Frequent readers know that I'm not one to republish vendor papers. But in this case, the Datacore paper (by Ziya Aral & Jonathan Ely) is actually really, really good. They take a no-BS look at VDI storage, and they validate their architecture with standard tools like Login Consultants' VSI benchmark.
From the paper: Previous publications have reported on configurations which use thousands of virtual desktops to defray the cost of these controllers. Reading between the lines, it becomes immediately apparent that per-virtual desktop hardware costs rise very sharply as such configurations are scaled downward. Yet, it is precisely these smaller VDI configurations which are the more important from most practical standpoints. On the other hand, this configuration may also be scaled upwards, in a linear fashion, to thousands of virtual desktops, thus eliminating distended configurations created by the search for artificial "sweet spots" at which costs are optimized.
The problem for Virtual Desktop implementations is that SANs are often implemented with large and costly storage controllers and complex external storage networks. While these have the advantage of achieving reasonable scalability, they introduce a very large threshold cost to VDI implementations. To overcome this burden, hardware vendors typically benchmark with one-to-several thousand virtual desktops.
Many companies, while understanding the potential benefits of the technology, are introducing pilot programs or attempting to fit initial VDI implementations into existing structures. If the granularity of VDI implementations is to be in the thousands, then the user is forced to consume, not just the “whole loaf”, but an entire bakery truck full of loaves at one sitting ... and this before even knowing whether the bread tastes good. The alternative is equally unappetizing. The user “bites the bullet” and accepts the high threshold cost and complexity of a full-blown SAN while running far less than the optimal number of virtual desktops. [In this case] the per-desktop cost of the implementation becomes much larger than it would have been if the “old scheme” of discrete desktops had remained. This is quite an introduction to a new, “cost-saving” technology... as an increasing number of ever-practical bloggers have noted.
The authors give an overview of their testing scenario, which started with two identical servers each configured to host 110 virtual desktops. Each server had five drives: a boot drive and two pairs of Datacore-controlled 2-disk pools, one which was used for that server's storage and the second which was used as a backup mirror of the other server's pool. They used simple SATA drives since they wanted to establish the simplest baseline possible:
We were loath to use anything but the most standard, easily configured SATA components. SAS, Fibre Channel spindles, fast devices, hybrid disks, and SSDs all have their place in the real world and are well understood to deliver a multiple of ordinary SATA performance. Still, the incorporation of such devices in baseline benchmarking has the same effect as building VDI architectures around this or that storage array. Such optimizations may become the dozen different tails attempting to wag an increasingly confused dog. Not only do they make comparisons difficult, but they lead to the subtle intrusion of a specific hardware architecture into the realms in which the VDI requirements themselves should be paramount."
Their hardware worked out to $3848 per server (~ $35 per user), with the full price going up to ~$67 total per user once you factored in the Datacore software. They went on to explain:
The principle innovation in this benchmark result is the use of DataCore’s storage virtualization system on the same hardware platforms used to host Virtual Desktops. While conventional wisdom might suggest that the DataCore software would thus become a competitor for the same scarce resources of the hardware platform, such as memory and CPU, numerous experiments proved the opposite to be true. In each case, such co-located configurations easily outperformed configurations with external storage.
The reasons are easy to isolate, retrospectively. The Virtual Desktop application is not particularly I/O intensive and proves to be easily served by DataCore at the cost of very few CPU cycles. The elimination of the lion’s share of external channel traffic serves to further reduce those demands. In return, block-cache latencies become nearly nonexistent, channel overheads disappear, and I/O latencies are eliminated. The resident SANmelody “pays” for itself without losing anything in the way of capability or portability.
While the test scenario was limited to two servers, you can also scale up via a "star" topology. The idea there is that you still use local drives in your VDI hosts (each running Datacore) as your primary storage, while the center hub in the star topology is a continuously synced replica of each VDI host to ensure no data is lost if you lose a VDI host. (And if you need ultimate high availability, you can keep a spare VDI host that could boot VMs from the central hub storage pool temporarily.) They also pointed out another advantage of using local storage, namely that "these types of configurations ... are inherently “self-tuning”. Each time a group of Virtual Desktops are added, so too is the storage infrastructure necessary to support them."
The Datacore authors were aware of how different this approach is versus typical VDI storage architectures:
On the whole, the benchmarked architecture differs from most of the results published by other storage vendors. Instead of constructing a VDI configuration around a storage controller or pre-existing SAN architecture, it builds the SAN around the VDI servers themselves.
Finally, they poked fun at the "tuner" crowd (themselves included), to suggest that no amount of "tuning" a typical VDI environment would yield enough price-to-performance gains as high as their virtual storage option:
Memory tweaks, enhanced hardware, and various tuning “tricks” produce the expected results. Still, increases in costs and complexity produce a system which is little better in price/performance than the one tested here. Sadly, for a group of “old tuners”, we have had to conclude that the benchmarked configuration is optimized enough to cross the threshold for practical VDI configurations and that additional low-level optimizations make only small, incremental changes.
To me this is one of the best vendor papers I've read in a long time. What do you think? What are we missing?