The IT Melting Pot!

It’s really great to see the capabilities of the Nutanix platform! Just read this great blog post by @andreleibovici around Content Based Read Cache (CBRC) and how this isn’t necessary at all on a platform like Nutanix!

Conclusion

Overtime I will discuss more about the technology behind Content and Extent Caches. For now what is important to know is that Nutanix provides a better in-memory microsecond latency benefits provided by CBRC for any VDI solution on any of the aforementioned hypervizors, for both Linked and Full-Clones. In fact, Nutanix engineers even recommend Horizon View administrators to disable CBRC because the Nutanix approach is less costly to the overall infrastructure.

It is amazing when your world turns upside down and a technology that used to be awesome becomes mostly irrelevant. It amazes me how fast technology evolves and help organizations to achieve better performance and lower OPEX.
 
For a long time I have discussed the benefits of CBRC (Content Based Read Cache) available with Horizon View 5.1 onwards, allowing Administrators to drastically cut-down on read IO operations, offloading the storage infrastructure and providing greater end-user experience.
 
Here are few of the blog posts I wrote on CBRC technology: Understanding CBRC (Content Based Read Cache), Understanding CBRC – RecomputeDigest Method, Sizing for VMware View Storage Accelerator (CBRC), View Storage Accelerator Performance Benchmark, CBRC and Local Mode in VMware View 5.1, View Storage Accelerator (CBRC) Hashing Function.
 
CBRC helps to address some of the performance bottlenecks and the increase of storage cost for VDI. CBRC is a 100% host-based RAM-Based caching solution that helps to reduce read IOs issued to the storage subsystem and thus improves scalability of the storage subsystem while being completely transparent to the guest OS. However, CBRC comes at a cost.
 
When the View Storage Accelerator feature (CBRC) is enabled, a per-VMDK digest file is created to store hash information about the VMDK blocks. The estimated size of each digest file is roughly:

• 5 MB per GB of the VMDK size [hash-collision detection turned-off (Default)]
• 12 MB per GB of the VMDK size [hash-collision detection turned-on]

The digest file creation for a large replica disk can take a large amount of time and a bulky quantity of IOPS, therefore it’s is recommendable not to run the operation, create new desktop pools, or recompose existing pools during production hours.

CBRC also uses a RAM to manage the cached disk blocks. The per-VMDK digest file is also loaded into memory. That is the reason why CBRC should not be enabled under memory-overcommit environments. If a host is memory over-committed and CBRC is enabled – the memory pressure is increased as CBRC also uses memory for the cache. In such cases, the host could experience increased swapping and the overall host performance could be impacted.

Whilst I wrote about CBRC benefits, I also received numerous negative comments about the technology, including lack of support for full-clone desktops, being unsupported for layering tools like Unidesk, and taking too long to generate new hashes for every replica.

CBRC is a platform feature (vSphere), however it is only enabled and available via Horizon View. Other VDI products such as XenDesktop or vWorkspace cannot utilize the feature.

Nutanix suppress the need for CBCR, providing similar functionality to any VDI solution running on top of vSphere, Hyper-V or KVM. Nutanix has a de-duplication engine built into the solution that works real-time for data stored in DRAM and Flash.

Content Cache (Dynamic Read cache)
 
The Content Cache (aka “Elastic Dedupe Engine”) is a de-duped read cache that spans both the Nutanix Controller VM memory and SSD. Upon a read request of data not in the cache the data will be placed in to the single-touch pool of the content cache which completely sits in memory where it will use LRU (Least Recently Used) until it is ejected from the cache.
 
Any subsequent read request will “move” (no data is actually moved, just cache metadata) the data into the memory portion of the multi-touch pool, which consists of both memory and SSD.
 
From here there are two LRU cycles, one for the in-memory piece upon which eviction will move the data to the SSD section of the multi-touch pool where a new LRU counter is assigned. Any read request for data in the multi-touch…

Continue reading here!

//Richard