Flash has been quite the interesting party animal in the world of infrastructure and has managed to permeate nearly every piece of technology, although a bit slower than I had hoped. One of the most interesting places that I see it used (from a design perspective) is directly inside a hypervisor – I’ll limit this article to VMware vSphere, but it really doesn’t have to end there. While I’ve written on various producers of server side caching solutions in the past (such as PernixData, SanDisk, NetApp, and thanks to some user comments I will soon cover Proximal Data), I felt it worth the time to look further into the reasons why it has changed from a “cool science project” to what will soon be a staple in server design and virtualization architecture.
Contents
Not If, But When
The fact that a flash device, be it an SSD or PCIe card, will be a standard part of future server virtualization builds is simply a matter of time. We’re still in the hey-thats-cool-but-I-don’t-trust-it phase of reality for a lot of organizations, and that’s a well grounded fear built on past experience and a dose of common sense. Early adopters of this technology will be looking for breaking “Chris’ 50% rule” that I made up some time ago. It basically states that companies are typically not interested in adopting risk for anything less than a 50% gain in performance | reliability | pick your verb here.
Cheap Bang for the Buck
The really neat thing about server side caching is that it typically offers at least a 100% increase in overall performance – and that’s a very conservative number. In a write-through model, where writes are still committed on the back end disk array itself, the gains are realized when data is later read from the write-through flash device. Obviously a heavy read environment will drive more of a gain than a heavy write environment, but typical workloads are 60% reads or higher. To be fair, I use the term typical – we’re not talking the transaction log files of a database here (100% sequential writes).
Still, droping latency to near 0 and offering thousands of IOPS for 60%+ of your disk commands isn’t too shabby. Add to the equation a flash device in the $1000-2000 range and a license to run someone’s server side caching software and you’re looking at a relatively cheap cost to entry for a significant gain.
Workload Predictions
The real underlining point for having server side caching become a necessity is due to how our workloads are changing. I see this really going two different ways: next generation server technology allowing us to cram more VMs on a host, and Phase 2 virtualization for Virtual Business Critical Apps (VBCA). In either scenario, the bottleneck continues to be storage related for the vast majority of cases. Without any form of server cache, there’s either not enough IOPS available on the downstream device, the server HBA is being brutalized by IOPS, or the round trip latency is too high for a VBCA. A flash device will absolutely need to be in the server, with further options existing in the array itself (such as controller cache) or surrounding the disk groups (such as a disk cache).
Thoughts
Server side caching addresses a lot of low hanging fruit performance issues. For many commercial and enterprise sized organizations, it provides a low cost way to soak up a significant amount of unnecessary IOPS to the array without being a headache to manage. Most of the market players I’ve mentioned in this post have shown me some really neat ways to non-invasively provide a hypervisor layer cache that virtual workloads are completely unaware exist (one of them still seems to think that guest agents make sense – no!).
I’m looking forward to seeing more advancement in this space, especially around the concept of responsible write-back caching that provides against single points of failure. Kudos to PernixData on that one so far, but I think others will either get there eventually or have some rationale against it.
