vSphere Flash Read Cache: No Market Killer

I've been following the evolving server-side caching market pretty closely during the past couple of years as at least a dozen vendors, from startups to industry giants, have released increasingly sophisticated products. With vSphere 5.5, VMware included its own caching system. While it seems this could potentially spell the end of the third-party caching market, the technology has its limitations.

vSphere Flash Read Cache is the result of a much more ambitious project at VMware called vFlash. vFlash was supposed to provide a framework for third-party caching engines to integrate into the vSphere kernel and a basic write-through caching engine that, while accelerating storage IO for virtual machines, would more significantly serve as an example for third-party software vendors to improve on.

I've heard several rumors as to why vFlash didn't make it into vSphere 5.5 in the way it was originally intended, from VMware's engineers discovering critical design flaws to the whole vFlash engineering team leaving VMware en masse. Regardless of how it happened, what we actually got with vSphere 5.5 is Flash Read Cache.

vSphere Flash Read Cache, which I'll call vFRC for short, has a curious mix of advanced and basic features. As we should expect from a VMware product, vFRC is more tightly integrated into the vSphere hypervisor than many earlier caching products--such as EMC's XtremeSW Cache, which I insist on calling by its earlier and more practical name, VFcache--that run their caching engines in the guest virtual machines.

While many other products have difficulty supporting vMotion and the vSphere features that use vMotion, such as DRS and Fault Tolerance, vFRC is fully integrated into the vMotion workflows. In fact, vFRC is one of the few caching systems that can, in addition to migrating the VM, use vSphere's extended vMotion functionality to migrate the cache contents. While migrating the cache contents extends the amount of time the vMotion takes, it eliminates the temporary performance loss created when a VM starts running on a new host with a cold cache.

That sophisticated hypervisor integration makes vFRC's obvious limitations all the more frustrating. The key problem with vFRC is that it requires system administrators to designate a fixed amount of cache space to each guest VM. While clever administrators can script the process of assigning cache to each of their VMs, the static allocation means that an admin has to plan how much flash each VM deserves.

[Read how performance gains can hit a wall with flash-based caching systems that add write-back capabilities in "Flash Write-Back Caching Limitations."]

It also means that as workloads shift, the amount of cache available remains static. In comparison, third-party caching products such as SanDisk's FlashSoft and those from Proximal Data and PernixData can assign cache space to VMs dynamically, giving more space to more active VMs on a minute-by-minute basis, which should be a lot more efficient in providing a bigger speed boost with any given amount of flash.

Even worse, the static allocation means that in order for vMotion to move a VM with 100 Gytes of cache from one host to another, the destination host has to have 100 Gbytes of SSD space that isn't allocated to any other VMs. Organizations using DRS or FT will have to leave a significant fraction of their expensive flash unused to leave enough space to accommodate a DRS or FT event.

So, with these limitations, vFRC definitely doesn't threaten to end the third-party caching market. Sure, some organizations will find it to be good enough, but if I were spending thousands of dollars on a PCIe SSD, another few bucks for better caching software would be a no-brainer.