Storage

01:23 PM
Howard Marks
Howard Marks
Commentary
50%
50%
Repost This

vSphere Flash Read Cache: No Market Killer

VMware's integrated caching technology has some advanced features but doesn't pose a threat to third-party caching vendors.

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.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
MarciaNWC
50%
50%
MarciaNWC,
User Rank: Apprentice
10/10/2013 | 7:04:34 PM
re: vSphere Flash Read Cache: No Market Killer
It seems VMware has the potential to impact a lot of third-party IT markets, including security.
Drew Conry-Murray
50%
50%
Drew Conry-Murray,
User Rank: Apprentice
10/10/2013 | 1:07:01 AM
re: vSphere Flash Read Cache: No Market Killer
I assume the fixed limit on cache is something that VMware would be able to address in a future version. If that happens, do you see it having a bigger impact on the third-party cache market?
More Blogs from Commentary
Edge Devices Are The Brains Of The Network
In any type of network, the edge is where all the action takes place. Think of the edge as the brains of the network, while the core is just the dumb muscle.
SDN: Waiting For The Trickle-Down Effect
Like server virtualization and 10 Gigabit Ethernet, SDN will eventually become a technology that small and midsized enterprises can use. But it's going to require some new packaging.
IT Certification Exam Success In 4 Steps
There are no shortcuts to obtaining passing scores, but focusing on key fundamentals of proper study and preparation will help you master the art of certification.
VMware's VSAN Benchmarks: Under The Hood
VMware touted flashy numbers in recently published performance benchmarks, but a closer examination of its VSAN testing shows why customers shouldn't expect the same results with their real-world applications.
Building an Information Security Policy Part 4: Addresses and Identifiers
Proper traffic identification through techniques such as IP addressing and VLANs are the foundation of a secure network.
Hot Topics
White Papers
Register for Network Computing Newsletters
Cartoon
Current Issue
Video
Slideshows
Twitter Feed