转发: PVS让存储颤抖，系列博文之一：PVS的写缓存新技术
转自：http://virtualworld.blog.51cto.com/各位Citrix合作伙伴，晚上好
实现桌面虚拟化的障碍来自于哪里？你可以列举出很多因素，包括实施的复杂性，要替换掉前端PC，PC使用人员惰性对项目的抵触等等，但是更重要的是他的成本在首次购置时超出了一台PC的价格。桌面虚拟化整体项目的成本不外乎是软件、硬件以及服务。其中软件包括虚拟化软件的License和微软相关软件的授权License，硬件一般包括服务器、存储和网络交换设备等。一般来说硬件成本占整个桌面虚拟化成本的超过60%，甚至更高。在硬件成本中存储的成本又是最高的，有统计数据表明硬件成本中超过一半是共享给了共享存储。PVS的技术能显著降低桌面虚拟化项目的成本已经被无数项目所证实，但是由于PVS是有别于桌面管理控制台之外的一个单独的管理服务器，所以以前在很多项目中VMware都对客户说Citrix的管理平台太复杂，管理效率低下，对业内不太了解的客户自然就信以为真，殊不知为此付出了惨重的代价；最近一段时间很少再听到VMware公司还对客户说同样的话了，原因是他们自己的控制台越来越多，复杂程度超过了Citrix的桌面虚拟化，不过可惜的是换来的并不是类似Citrix PVS对桌面发布技术的高效，而是因为把收购来的不同产品硬性整合所带来的多产品之间混乱格局，此话题咱们暂且先搁置，有时间再慢慢道来。今天给大家带来的是一个PVS的新技术，叫做“Cache in RAM with Disk Overflow”，什么意思呢？顾名思义，就是把为每个虚拟机分配的Write Cache写到Target Device的RAM中，当RAM写满之后，才继续写入Target Device的硬盘中。
我们这篇文章将会是第一讲，介绍该特性，下一篇博文将会详细通过实际数据来验证该特性，以及介绍如何使用该方式。所有文章会首先发布在51CTO的博客上：http://virtualworld.blog.51cto.com/，并且有更多博文内容。
回顾一下PVS的技术特性在我们介绍这个新特性之前，你必须对PVS的写缓存技术有一点的了解。好在这几年都陆陆续续写过一点心得，有时间的话推荐你去看看我之前写的几篇博文：PVS写缓存容量设计和部署位置的考虑http://virtualworld.blog.51cto.com/1412963/1441381PVS的内存和存储规划设
http://virtualworld.blog.51cto.com/1412963/1441391
Cache in RAM with Disk Overflow的由来
如果你曾经使用过PVS 7.1的版本，细心的你就会发现PVS 7.1的版本增加了一个新的Write Cache的存放位置称之为“Cache in RAM with Disk Overflow”。见下图：在旧的PVS软件版本上你可是看不到此特性的哦，如下图6.X版本的PVS：
实际上在设计之初这个特性是为了处理在微软ASLR和PVS之间发生的一些应用程序兼容性问题。当时这个问题其实是出在当我们把Write Cache设置为“Write Cache on Target Hard Disk”的时候会出现随机性的应用程序崩溃现象（当然VDI项目的实际案例中我们都是把Write Cache 放在共享存储上）。在Vista系统发布之后，微软引入了一个新的安全机制叫做Address Space Layout Randomization ，简称叫做ASLR，该功能把已知的操作系统的系统模块随机的放到内存地址空间中，当我们把Write Cache设置为“Write Cache on Target Hard Disk”时，就会出现应用程序随机崩溃的情况，因为应用程序可能在调用一个操作系统的服务，也可能是一个explorer的shell。这个问题只要你把Write Cache设置为放在内存中，又或者是放在服务器的内存中，又或者是私有模式，都不会出现此问题，所以，Citrix的研发部门特意开发了一个新的Write Cache的存放位置称之为“Cache in RAM with Disk Overflow”，也就是说Write Cache优先放在Target Device的RAM中，当RAM放满了之后再把不常用的数据放在Target Device的硬盘中。关于此问题的详细解释可以参考Citrix的知识库文章：http://support.citrix.com/article/CTX139627没想到这个新特性的最大”副作用”就是带来了极大的IOPS上的性能提升，大幅度的减少，甚至消除了对物理存储设备的需求！
Citrix的顾问团队最近对该新特性做了一些详细的实验室测试，同时也在客户的生产环境中实际测试并捕捉了大量的数据，我已经迫不及待的要把这些数据及时的分享给你了！
PVS Write Cache类型详解当我们决定采用PVS方式来发布虚拟桌面时，一个最为重要的因素就是通过确认Write Cache的摆放位置来达到最大化性能。虽然上面两篇博文都已经有所论述，但我们还是做一简单回顾把。1. 缓存到服务器上，就是说放在PVS的服务器上，缺省和vDisk的摆放位置一样，只不过是不同路径；和其它方式相比这种方式性能最差，也没有高可用配置，所以在VDI方式中坚决杜绝使用，只是在Streaming到物理机或者是无盘瘦客户机时才使用；2. 缓存到Target Device的硬盘上。这种方式会在Target Device的硬盘上创建一个写缓存文件.vdiskcache。所以在Target Device的硬盘是需要NTFS的文件分区别格式来创建这个.vdiskcache文件。到目前为止这种方式是Citrix最佳实践的推荐部署方式，虽然并非是性能最好的方式，但是他在成本和性能之间达到了一个平衡，所以在大部分项目中都是采用这种方式部署。备注：这种模式下为了让写缓存磁盘达到最高的吞吐量，建议打开Intermediate Buffering（中间缓冲）这个配置选项。默认下该选项是禁用的，如何启用该选项可以参考CTX126042.3. 缓存到RAM（内存）中。这种方式保留Target Device的一部分内存用来存放Write Cache，这部分的RAM操作系统将不能再使用了。这部分保留用于Write Cache的内存在vDisk的属性中配置。这种方式能提供更高的吞吐率，更好的响应时间，以及为Write Cache提供比前几种方式更高的IOPS，比较内存的读写速度要远胜于磁盘的速度。不过这种方式还是有一些问题的。首先没有overflow（暂且翻译成“溢出”）功能，一旦写缓存占满了被分配的RAM空间，Target Device将不可用了（甚至发生蓝屏），因此Target Device必须有足够多的内存来存放Write Cache，不过这样一来就会带来更高昂的成本；其次，如果企业有需求要求储存永久设置和数据，例如事件日志等，还是需要保存在Target Device的硬盘介质上。在实际项目中，我们通常会在发布XenApp成员服务器的时候会使用这个功能，主要是因为在一台物理服务器上通常我们不会运行太多的XenApp虚拟机，而VDI方案就不同了，通常数量较多，所以一般来说没有那么多可用的内存可供Write Cache使用。4. 缓存到RAM并且溢出到硬盘，这是一种新的Write Cache形式，其实就是第二和第三种方式的组合，默认状态下Write Cache是写入到Target Device的内存中，当内存写满了时在写入到Target Device的硬盘中。他的工作方式如下。a) 在过去版本相同，缓存的大小是在vDisk的属性中配置，缺省状态下，缓存的大写是64MB，并且可以设置为任何大小。b) 该模式并不是像方式“缓存到RAM（内存）中”那样预留一部分Target Device的内存，“缓存到RAM并且溢出到硬盘”方式的Write Cache是被映射到内存中的非页面池中，并且按照需求来使用，如果系统不再需要时，内存是可以被释放到系统的；c) 在Target Device的硬盘上，“缓存到RAM并且溢出到硬盘”方式并不是使用旧方式的.vdiskcache文件，而是使用一个VHDX格式的文件：vdiskdif.vhdx文件。d) 在启动的时候，该VHDX文件的文件头是4M大小；e) 数据是首先写入到内存中的缓存，一旦缓存满了，不活动的数据将溢出到磁盘上；f) 数据写入到VHDX时是以2MB一个块写入，而不是以前的以4K一个块写入。在开始的时候，看起来Write Cache貌似比旧的.vdiskcache这个缓存文件增长的要快，但是随着时间的推移，新格式的文件所消耗的空间却不会显著增大，这是因为数据最终将会被填充到保留的2M数据块中；“缓存到RAM并且溢出到硬盘”方式的注意事项1. 最初开始时，Write Cache的VHDX文件会比.vdiskcahce文件格式增长的更快。这是由于VHDX格式使用2MB的数据块而不是4K的数据块，但是随着时间的推移，新格式的文件所消耗的空间却不会显著增大，这是因为数据最终将会被填充到保留的2M数据块中；2. “Intermediate buffering”选项不适用于这种Write Cache模式，实际上，“缓存到RAM并且溢出到硬盘”这种Write Cache方式其实就是用来取代“Intermediate buffering”方式的；3. 系统缓存（System Cache）和vDisk的内存缓存（vDisk RAM Cache）是同时在工作。这句话的意思其实就是说如果有一个块数据从Target Device的内存缓存中被移动到了磁盘的溢出文件上，这个数据时期实际上还是存在于Windows的系统缓存（System Cache）中，再读取时它还是从内存中读取而不是从磁盘中读取；4. “缓存到RAM并且溢出到硬盘”这种Write Cache方式仅适用于Windows 7/Windows 2008 R2以及之后的操作系统版本；5. “缓存到RAM并且溢出到硬盘”这种Write Cache方式需要安装一个PVS 7.1的补丁，请参考：http://support.citrix.com/article/CTX140337（32bits）http://support.citrix.com/article/CTX140338（64bits）数据服人一切不以婚姻为目地的谈恋爱都是耍流氓，所以一切没有实际数据验证的理论都是不可信的。测试环境说明物理硬件环境物理服务器CPU：2路8核CPU，Inter 2.20 GHz物理服务器RAM：256 GBHypervisor：vSphere 5.5XenApp虚拟机环境虚拟机CPU：4个vCPU虚拟机RAM：30 GB虚拟机操作系统：Windows 2012虚拟机磁盘：30 GB（Write Cache放在E盘，存放到存储的Tier 1）测试工具IOMeter测试方法使用IOMeter，我们在XenApp的虚拟机上运行了五次测试，比较了不同形式的Write Cache类型，测试方式描述如下：1. E:盘测试：IOMeter使用了一个8GB大小的文件直接写入到Write-Cache磁盘（E：盘），这个测试可以让我们知道由SAN所能提供的真实的IOPS能力；2. 新的“缓存到RAM并且溢出到硬盘”：我们配置新的内存缓存到10G的RAM，然后运行IOMeter测试8GB文件，因此所有的I/O操作都在RAM中进行；3. 新的“缓存到RAM并且溢出到硬盘”：我们配置新的内存缓存到10G的RAM，然后运行IOMeter测试15 GB文件，因此至少有5 GB的数据会被溢出到硬盘中；4. 旧的PVS缓存模式：部署在Target Device的内存中。我们配置了10GB的RAM，然后运行IOMeter测试8GB文件，这样内存就不会被用尽，如果用尽虚拟机就垮啦；5. 旧的PVS缓存模式：部署在Target Device的硬盘中。配置PVS把缓存部署在硬盘上然后运行IOMeter测试8GB大小的文件。
除了IOMeter的测试文件时8GB大小之外，其他所有IOMeter的测试数据都是使用以下参数：l配置了4个Worker；l每个Worker设置深度队列为16；l4KB大小的块尺寸；l80%的读操作，20%的写操作；l90%的随机I/O，10%的顺序I/O；l30分钟测试持续时间；测试结果
Test #IOPS读IOPS写IOPSMBps读 MBps写MBps平均响应时间 (ms)
118,4123,6791473371.9214.3757.550.89
271,29914,25857,041278.5155.69222.810.86
3*68,93813,78955,149269.2853.86215.420.92
414,4982,89911,59956.6311.3245.31.1
58,3641,6726,69232.676.5326.141.91
说明：在第三次测试中，当写缓存首先开始溢出到磁盘的时候，IOPS技术降到了31,405，平均响应时间增高2ms持续了一段非常短暂的时间；随着测试进行下去，IOPS又慢慢的增加回来，同时响应时间下降。这是由于PVS机制在把大量的数据赶到磁盘上以在RAM中腾出足够的空间出来。即使是在溢出到磁盘的时候，总共的IOPS基本上都是几倍于其它方式。在上表中，我们可以看出来第三种方式取得了令人惊讶的结果。在我们的测试环境中，Tier 1的存储基本上能提供净IOPS达到18K还多，这已经是相当不错了。但是在我们的“缓存到RAM并且溢出到硬盘”模式下，当在RAM下时，基本上我们能获得7万多的IOPS，同时即使是有15GB的大文件，我们只有10GB的缓存是也仍然能得到6.9万的IOPS。还有一些其他的数据可以来看看：l旧的PVS Write Cache写入到Target Device的RAM模式不能够达到超过14K IOPS，，新的模式基本上是他的4倍多；l旧的PVS Write Cache写入到Target Device的硬盘模式使用的是旧的.vdisjcache仅能使用到SAN存储所能提供的实际能力的50%还不到。
结论：很明显，新的Write Cache模式在性能方面已经是最佳选择了。那么在实际场景中我该怎么是使用这个模式，我们下篇博文会继续和大家分享。
学习了:):):)
页:
[1]