开启辅助访问

超融合+云计算论坛

 找回密码
 立即注册

QQ登录

只需一步,快速开始

查看: 1964|回复: 2
收起左侧

[架构设计] Data Locality&Read Cache—为什么是桌面虚拟化高性能的关键-1

[复制链接]
发表于 2015-10-28 23:03:19 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
本帖最后由 渝粤 于 2015-10-28 23:05 编辑

Lets start with describing an common performance issue with Horizon View (Formally VMware View) environments using Linked Clones.

1. Read and Write I/O for all Virtual Desktops is serviced by a central storage controller/s over a storage network (FC, FCoE , IP etc)
2. High performance Caching is on the storage controller which is not local to the ESXi host
3. Performance is 100% dependant on the Storage Area Network or Storage Controllers for performance and where latency or contention exists, performance will suffer.
The End Result is
1. Boot and/or login storms performance may be poor
2. Read I/O heavy tasks such as AV scans are a high impact to the ESXi host, Storage Network and Storage Controllers which can have a high impact on other workloads using the same shared storage (virtual and/or physical)
3. Steady state performance can be impacted poor (such as application load times)

One thing VMware has done to improve this situation is create Content Based Read Cache (CBRC a.k.a View Storage Accelerator).

CBRC has been shown in many tests to greatly improve the performance especially during boot storms, login storms and antivirus scans.

Andre Leibovici (@andreleibovici) wrote a great article on his blog “myvirtualcloud.net” showing the benefits on CBRC here which in summary showed that the I/O to the underlying storage was reduced and performance improved in all three of the above mentioned scenarios.

While CBRC does improve the situation, it does have some limitations.

1. Restricted to 2048MB (2GB)
2. The Bulk of the user data (Read I/O) and ALL Write I/O is still serviced remotely on the Storage Array over the Storage Area Network which still places a serious dependency on the Storage Network and (limited number of) Storage Controllers.
3. Virtual machine host caching is applied only when the virtual machine is powered off. Configuring host caching for a powered-on virtual machine requires virtual machine shutdown to apply the configuration. In the case of linked clone virtual machines, caching cannot be enabled when any of the virtual machines based on the same shared base disk are powered on.
4. Enabling host caching will create additional disks for each boot VMDK and snapshot VMDK, which results in increased storage utilization.
5. If the administrator changes the advanced configuration parameters, some changes might require the vSphere CBRC module to be unloaded and reloaded for the changes to take effect.
6. Host caching cannot be configured for non-vCenter managed pools, or terminal server pools.

Note: The Source for some of the above limitations is the VMware View Storage Accelerator – View 5.1 White paper which can be found here.

In a Nutanix environment, there is a number of features which go further to address these issue. The first is called “Extent Cache” which is a READ cache in DRAM of each Controller VM (CVM). The “Extent Cache” is by default 3072MB but can be increased to whatever size suits your environment.

The below is a visual representation of the Nutanix Extent Cache.

NutanixExtentCache.jpg

Some of the benefits of Nutanix Extent Cache are

1. Can be sized to suit your requirements (Not limited to 2GB)
2. Does not require the use of CBRC
3. Reduced overhead on the Storage Network (IP Network) as more read I/O can be cached locally
4. Due to Nutanix DFS “Data locality”, data that not stored in Extent Cache is generally accessed locally via SSD. This further reduces the overhead on the Storage Network & dramatically reduces the impact on other controllers within the Nutanix cluster- See my post Data Locality & Why is important for vSphere DRS clusters for more information about Data locality
5. During boot storms, login storms and antivirus scans more data can be served from Cache (Extent Cache) and less read I/O is forced to be served by SSD (or local SATA drives if the data is “Cold”). This not only improves Read performance but makes more I/O available for Write operations which are generally >=65% in VDI environments
6. Works with any Virtual Machine, not just VDI and is hypervisor agnostic.
7. No need to configure a View Desktop Pool to use “Host Caching” as the “Extent Cache” performs this function (and more) at the Nutanix layer automatically
8. No need to configure “Regenerate Cache” or “Blackout Times” which is required for CBRC
9. No additional storage is used by Nutanix Extent Cache
10. Changes to the Nutanix Extent Cache can be done without disruption to the Virtual machines

Note: Extent cache is not limited to desktop workloads, it also works with any type of virtual machine and is operating system agnostic.

In Part 2, We discuss the Nutanix Dynamic Shadow’s feature will be discussed to show how Nutanix ensures data locality for 100% read only data such as Linked Clone Replica’s.

A special Thank you to  Jason Langone VCDX#54 (@langonej) for reviewing this post and to Tabrez Memon one of the brilliant Engineers at Nutanix who has worked on features discussed in this post and provided valuable input into this series.

欢迎来到 【nutanix.club】最大的中文超融合&云计算社区 请记住我们的网址 www.nutanix.club [这是默认签名,更换签名点这里!]
回复

使用道具 举报

发表于 2016-4-3 17:53:33 | 显示全部楼层

Thanks for sharing
欢迎来到 【nutanix.club】最大的中文超融合&云计算社区 请记住我们的网址 www.nutanix.club [这是默认签名,更换签名点这里!]
回复 支持 反对

使用道具 举报

发表于 2017-12-6 16:40:30 | 显示全部楼层
能翻译下更好,谢谢
欢迎来到 【nutanix.club】最大的中文超融合&云计算社区 请记住我们的网址 www.nutanix.club [这是默认签名,更换签名点这里!]
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

返回顶部快速回复上一主题下一主题返回列表微信扫一