实现桌面虚拟化的障碍来自于哪里？你可以列举出很多因素，包括实施的复杂性，要替换掉前端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的硬盘中。
我们这篇文章将会是第一讲，介绍该特性，下一篇博文将会详细通过实际数据来验证该特性，以及介绍如何使用该方式。
回顾一下PVS的技术特性在我们介绍这个新特性之前，你必须对PVS的写缓存技术有一点的了解。好在这几年都陆陆续续写过一点心得，有时间的话推荐你去看看我之前写的几篇博文：
PVS写缓存容量设计和部署位置的考虑
http://virtualworld.blog.51cto.com/1412963/1441381
PVS的内存和存储规划设
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 LayoutRandomization ，简称叫做ASLR，该功能把已知的操作系统的系统模块随机的放到内存地址空间中，当我们把WriteCache设置为“Write Cache on Target Hard Disk”时，就会出现应用程序随机崩溃的情况，因为应用程序可能在调用一个操作系统的服务，也可能是一个explorer的shell。
这个问题只要你把Write Cache设置为放在内存中，又或者是放在服务器的内存中，又或者是私有模式，都不会出现此问题，所以，Citrix的研发部门特意开发了一个新的Write Cache的存放位置称之为“Cache in RAM with Disk Overflow”，也就是说Write Cache优先放在TargetDevice的RAM中，当RAM放满了之后再把不常用的数据放在Target Device的硬盘中。
关于此问题的详细解释可以参考Citrix的知识库文章：
http://support.citrix.com/article/CTX139627
没想到这个新特性的最大”副作用”就是带来了极大的IOPS上的性能提升，大幅度的减少，甚至消除了对物理存储设备的需求！
Citrix的顾问团队最近对该新特性做了一些详细的实验室测试，同时也在客户的生产环境中实际测试并捕捉了大量的数据，我已经迫不及待的要把这些数据及时的分享给你了！
PVS Write Cache类型详解当我们决定采用PVS方式来发布虚拟桌面时，一个最为重要的因素就是通过确认Write Cache的摆放位置来达到最大化性能。虽然上面两篇博文都已经有所论述，但我们还是做一简单回顾把。
缓存到服务器上，就是说放在PVS的服务器上，缺省和vDisk的摆放位置一样，只不过是不同路径；和其它方式相比这种方式性能最差，也没有高可用配置，所以在VDI方式中坚决杜绝使用，只是在Streaming到物理机或者是无盘瘦客户机时才使用；
缓存到Target Device的硬盘上。这种方式会在Target Device的硬盘上创建一个写缓存文件.vdiskcache。所以在Target Device的硬盘是需要NTFS的文件分区别格式来创建这个.vdiskcache文件。到目前为止这种方式是Citrix最佳实践的推荐部署方式，虽然并非是性能最好的方式，但是他在成本和性能之间达到了一个平衡，所以在大部分项目中都是采用这种方式部署。
备注：这种模式下为了让写缓存磁盘达到最高的吞吐量，建议打开Intermediate Buffering（中间缓冲）这个配置选项。默认下该选项是禁用的，如何启用该选项可以参考CTX126042.
缓存到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使用。
缓存到RAM并且溢出到硬盘，这是一种新的Write Cache形式，其实就是第二和第三种方式的组合，默认状态下Write Cache是写入到Target Device的内存中，当内存写满了时在写入到Target Device的硬盘中。他的工作方式如下。
在过去版本相同，缓存的大小是在vDisk的属性中配置，缺省状态下，缓存的大写是64MB，并且可以设置为任何大小。
该模式并不是像方式“缓存到RAM（内存）中”那样预留一部分Target Device的内存，“缓存到RAM并且溢出到硬盘”方式的Write Cache是被映射到内存中的非页面池中，并且按照需求来使用，如果系统不再需要时，内存是可以被释放到系统的；
在Target Device的硬盘上，“缓存到RAM并且溢出到硬盘”方式并不是使用旧方式的.vdiskcache文件，而是使用一个VHDX格式的文件：vdiskdif.vhdx文件。
在启动的时候，该VHDX文件的文件头是4M大小；
数据是首先写入到内存中的缓存，一旦缓存满了，不活动的数据将溢出到磁盘上；
数据写入到VHDX时是以2MB一个块写入，而不是以前的以4K一个块写入。在开始的时候，看起来Write Cache貌似比旧的.vdiskcache这个缓存文件增长的要快，但是随着时间的推移，新格式的文件所消耗的空间却不会显著增大，这是因为数据最终将会被填充到保留的2M数据块中；
最初开始时，Write Cache的VHDX文件会比.vdiskcahce文件格式增长的更快。这是由于VHDX格式使用2MB的数据块而不是4K的数据块，但是随着时间的推移，新格式的文件所消耗的空间却不会显著增大，这是因为数据最终将会被填充到保留的2M数据块中；
“Intermediate buffering”选项不适用于这种Write Cache模式，实际上，“缓存到RAM并且溢出到硬盘”这种Write Cache方式其实就是用来取代“Intermediate buffering”方式的；
系统缓存（System Cache）和vDisk的内存缓存（vDisk RAM Cache）是同时在工作。这句话的意思其实就是说如果有一个块数据从Target Device的内存缓存中被移动到了磁盘的溢出文件上，这个数据时期实际上还是存在于Windows的系统缓存（System Cache）中，再读取时它还是从内存中读取而不是从磁盘中读取；
“缓存到RAM并且溢出到硬盘”这种Write Cache方式仅适用于Windows 7/Windows 2008 R2以及之后的操作系统版本；
“缓存到RAM并且溢出到硬盘”这种Write Cache方式需要安装一个PVS 7.1的补丁，请参考：
