The Gotcha with vFRC and vCenter 5.5

vFlash Read Cache (vFRC)is a feature of vSphere 5.5 that can accelerate the read IO of VM’s by leveraging server side flash resources form an SSD or PCIe Flash card. This can help offload reads so your (legacy) storage can be used more efficiently and also so you can consolidate more VM’s per host without reducing performance. If you have a hyper-converged environment, such as Nutanix, this is not required as your platform has flash and intelligence already built in. One of the big use cases for vFRC and products from VMware’s partners that are like it, is accelerating Database performance, but without having to allocate a ton of memory. You could effectively get more DB’s per host, without the same performance impact. Flash storage is really near line memory, or cheap memory, rather than expensive storage. However with vFRC, there is a gotcha that could lie dormant for a long time before it bites you.

Last week I came across VMware KB 2072392 article about a bug with vFlash Read Cache and vCenter that could impact people when doing maintenance of vCenter. Michael White wrote about this in his weekly newsletter. The KB article describes a situation where vCenter can consume all CPU, Memory or Disk I/O after enabling vFRC (I’m assuming this is limited to the size of your vCenter and not an entire host, the KB doesn’t specify). Although there is no patch available at this stage the KB does provide a workaround and asks anyone that has experienced this, and where the workaround doesn’t fix it, to log a support request with VMware. This bug was a bit of a surprise to me, as I didn’t strike it in any of the testing I had previously done with vFRC. But to be honest I hadn’t rebooted vCenter when vFRC was enabled either (as far as I can recall). The rebooting of vCenter is what triggers the bug. So this could be lying dormant for a very long time before it creeps up on you the next time you go to patch vCenter.

If you rely on vFRC then it would pay to read the KB and apply the workaround. If you were thinking about implementing vFRC in the future, then it might pay to wait until there is a patch available. Alternatively you can apply the workaround before enabling vFRC to avoid the problem. But there are also plenty of alternatives to vFRC in the market from VMware Partners and they may be worth investigating (such as PernixData, Fusion-io’s ioTurbine etc).

Note: If you are running Oracle RAC (or anything else that uses the multi-writer flag), the use of the multi-writer flag is not compatible with vFRC. It can lead to data corruption! VMware has updated KB 1034165 with the details. PernixData FVP is also not compatible with the use of the multi-writer flag. Before using any caching or IO acceleration solution you should check the compatibility with the VMware multi-writer capability if you plan to use it. 

Final Word

Traditional SAN and NAS storage can benefit greatly from add-on flash acceleration solutions, if you have the types of problems they solve. However the new web-scale IT hyper-converged solutions that are available to the masses from Nutanix (where I work) and others, have flash acceleration built in. There are no add-ons you have to buy to get the benefits of flash, while retaining the economics of web scale, the capacity of hard disks, and the simplicity of an intelligent automated platform. There is no one right solution for everything though, so you should evaluate any particular solution based on your requirements. It would definitely be worth your while checking out the new hyper-converged solutions, even if you’re not ready to adopt them just yet.

—

This post appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster. Copyright © 2014 – IT Solutions 2000 Ltd and Michael Webster. All rights reserved. Not to be reproduced for commercial purposes without written permission.