Early today VMware formally announced the (almost) release of VMware View 5.1. Many assumed that View 5.1 would support vSphere 5 Content Based Read Cache (also known as CBRC); they were correct. For those who have been living under a rock, vSphere 5 has the ability to cache bits of a virtual machine in ram, where latency is measured in nanoseconds and not milliseconds. This is of particular benefit for linked clone virtual machines, where under View 5.x you have up to 1000 clones linked to a single image. Note: CBRC is referred to within VMware View as “VMware View Storage Accelerator”; this is the official term now that View 5.1 has been released.
Andre Leibovici of VMware has had a series of blog posts all about CBRC. Rather than plagiarize all his hard work, I’m going to recommend you visit his site if you want a technical introduction into how CBRC works.
Earlier this week I finished up some testing that shows exactly what CBRC does. The following graphs show IO reduction for three specific scenarios: 2000 desktop boot storm, logon storm, and on demand virus scan storm. View 5.1 allows you to enable caching for either the master replica image OR the master replica image and the persistent disks. My hosts in this case were rather close to overcommitting memory, so I chose to cache the master replica image only to minimize the amount of ram used for the cache. Read this to understand how much ram you will need based on your own settings.
I created these graphs because they are those which show the greatest amount of benefit from CBRC. Remember that much of the EUC storage workload is writes, so I’m looking for read heavy scenarios in order to find out what CBRC can really do.
The stats are all reads of the master replica image measured using ESXTOP. Storage stats are interesting enough, but the truth is if you see less reads at the ESXi host you will see less reads within your storage environment.
So that you have some perspective, you are looking at results for a ESXi host that is running 143 Windows 7 desktops. I was actually testing 2000 desktops at once, but for simplicities sake I am showing the results for only one of my hosts.
Do I really need to explain this? Yes there was still a (small) read spike at the 2 minute mark even with CBRC enabled, but even with that you are looking at over a 95% reduction in reads (red line) to the replica image. Even though vSphere uses at most 2 GB of ram for CBRC, the working set (the data that is actually read) of the master replica image is rather small during boot up.
This is a 90 minute logon storm. Again, the benefits of CBRC during this window are obvious. With CBRC enabled (blue line) the reads to the replica image were again reduced by over 95% on average. This would be of great benefit in environments where logon storms were a frequent occurrence.
Let me preface this graph by saying that you really should be using antivirus solutions that are optimized for EUC environments. This includes vShield Endpoint (with McAfee or Trend Micro plugins) or even McAfee MOVE. I’ve tested them all, and they are a huge improvement over traditional client-based AV tools. Now that I’ve gotten that out of the way, you are looking at an AV scan storm that used the McAfee command line AV client. Each AV session was initiated one right after another, a process which takes about 5-7 seconds per desktop. In this case not only was IO reduced by over 70% (blue line), with CBRC enabled the scans finished in less than a third of the time of the “no CBRC” test. AV scan storms are among the most “stressful” storage tests I do, and CBRC enabled amazing results.
The question is does CBRC change my storage requirements? My opinion: In most cases not really. If I were to show you steady state IO during a Login VSI user simulation test you would see maybe a percent or two reduction in IO to the replica master image, which means that you really can’t adjust your core storage design. I consider CBRC a safety valve that helps you maintain desktop performance during those periods of load that may otherwise affect desktop performance. Given that only a few GB of ram are required, you may find the CBRC a no brainer. As always, test in a lab or with a small pilot first before deploying into production.