Wednesday, March 12, 2014

VMware Flash Read Cache (vFRC) Test Drive

VMware vFRC, or Flash Read Cache is a technology that lets you use host-side solid state storage or SSDs as a read cache for your virtual machines.  This allows for extremely low latency and very high performance for cached data, and has the corollary affect of reducing load on the SAN.  While it looks great on paper - how does it really perform?

A few weeks ago, I was able to get my hands on some 300GB eMLC SSD drives - seven of them.  I slapped one into each blade in the test cluster, and got to testing the performance of vFRC.  I am fairly impressed with the results.

To enable vFRC you need local SSD storage on your ESXi host.  This can be PCI-E flash, or a SAS or SATA SSD drive.  If you are going to put this in a production environment, it's highly recommended to use eMLC or SLC drives, as the wear and tear these drives will experience will be significant, especially when used as a cache.

It is also important to note that you will need ESXi 5.5 and vCenter - and you must use the vSphere web client to make all the changes.  An Enterprise Plus license is also required to take advantage of the features.

First, you need to enable the SSD on the host as a vFRC cache in the vSphere web client.  You may need to reboot the host in order to recognize the SSD storage.


You can verify the addition of the flash resource on the summary tab of the host screen.




Second, go onto the VM you wish to accelerate in the vSphere web client.  The VM hardware revision must be vmx-10.


Click OK, and you're done!  You will see the cache on the summary tab of the virtual machine screen.



Now, here's a random access performance test from HDTune.  This is the first run after enabling vFRC.



Here is the second run after enabling vFRC


I also ran the tests in IOMeter - 512B 100% Random Read


Not too shabby.  But, how is the SAN performing?


These are real numbers.  You'll have to trust me, but the second column is NFS ops/s.  And there is a decent load on this SAN (a couple hundred VMs).

But wait, there's more!  vFRC works with VMotion, so you can select to have it keep the migrate the cache contents.


To truly test this, I ran a benchmark test during a host to host vMotion of this VM.  IOMeter doesn't show this very well, so I ran a HDTune graph so you could visibly see the impact.

The red arrows show the start and finish of the vmotion operation.  This was using 8MB block sizes.



As you can see, vFRC is a highly useful feature of VMware.  While it doesn't have the same feature set as other vendors who have been offering SSD host-cache/acceleration, it works very well for a first iteration.



Update:

I chose not to set the block size for this post, as it doesn't really matter for this instance to say - "hey, it works!"

However, VMware has a great article if on vFRC performance and tuning.  If you're just getting started with vFRC, you should definitely read this:

http://www.vmware.com/files/pdf/techpaper/vfrc-perf-vsphere55.pdf

2 comments:

  1. Thanks for the post. Interesting that you chose to not set a specific block size to your caching setup.

    ReplyDelete
    Replies
    1. True. I don't believe it was really necessary to change the block size (default is 8KB) for the purposes of this demonstration. I would agree that there would be a performance effect (especially at the application layer) based on the block size chosen, but that goes beyond the scope of this post. However, the vFRC Performance whitepaper shows some interesting results and good tips for performance tuning. I will amend the article to include a link to that.

      Delete

Featured Post

Remove 3D Objects and other annoying folders on Windows 10

 Microsoft just keeps adding more crap to clutter up the navigation in Windows 10.  Seriously, who needs a 3D Objects folder?  The tiny perc...