在Hyper-V 2012 R2平台上的PVS 7.1 RAM Cache 256M方式发布的Windows 7 VDI桌面
备注：以下测试和上面的MCS环境的测试是在同一个硬件平台上完成。
- 四核超线程CPU，32G内存，Hyper-V平台；
- 一块专用的7200转SATA 3硬盘（带64M缓存），用户存放Windows 7虚拟机的写缓存；
- Windows 7 X64虚拟机配置：2 vCPU，2.5G内存；
- PVS 7.1标准镜像，RAM Cache设置为256MB（PVS在单独的主机上）；
- 用户配置文件使用UPM优化和文件夹重定向策略（用户配置文件存放在单独的主机上）；
这次的测试我们直接启动11个虚拟机，这是在32GB的主机上能启动的最多数量的VM；
|
虚拟机数量 |
启动持续时间 |
全部IO读写 |
每虚拟机IOPS |
每虚拟机 读IOPS |
每虚拟机写IOPS |
读写比例 |
|
11个 |
3.5分钟 |
每虚拟机 536 |
2.5 |
1.4 |
1.1 |
56% / 44% |
这个结果实在是太棒了！在每个虚拟机仅仅分配了256MB内存用于缓存的情况下，我们把启动风暴的IOPS要求戏剧性的减小到了2.5个IOPS。
我们以前都是知道PVS服务器可以把读的IO操作都offload到PVS服务器的内存中所以可以几乎不使用共享存储的读操作，现在从上面的结果中可以看出来Target Device的写操作基本上也可以被消除了！
我们现在来看看登录阶段。
|
虚拟机数量 |
登录持续时间 |
全部IO读写 |
每虚拟机IOPS |
每虚拟机 读IOPS |
每虚拟机写IOPS |
读写比例 |
|
11个 |
3分钟 |
每虚拟机 101 |
0.56 |
0.05 |
0.51 |
9% / 91% |
我以每15秒钟的间隔启动了这11个会话。基本上每个会话也只花了15秒钟就完成了完整的登录过程并且启动了应用程序。从结果中可以看到我们追踪的这11个虚拟机的登录IOPS的全部持续时间大概持续了180秒钟。在这段时间中，每个虚拟机只产生了不到1个IOPS的需求！
接下去再看看稳定状态的数字吧。
|
虚拟机数量 |
会话持续时间 |
全部IO读写 |
每虚拟机IOPS |
每虚拟机 读IOPS |
每虚拟机写IOPS |
读写比例 |
|
11个 |
45分钟 |
每虚拟机 290 |
0.1 |
0.001 |
0.1 |
1% / 99% |
这真是个很神奇的结果，基本上每个虚拟机每秒钟只产生了十分之一的IO读写。全部11个虚拟机也只产生了1.1 IOPS的需求。读的IOPS太低了，几乎可以认为是0，在整个45分钟的连续运行实践中，每分钟只产生了一个读的IO需求。
看到这里你可能会说你这仅是一个实验室的数据，在实际场景中，用户的个人配置文件不可能像上面那样优化到只有10M之少。很多时候用户都会把AppData目录放到配置文件中而不是做重定向，这么做就会显著增加启动加载的数据量，甚至超过RAM缓存的大小。基于以上的考虑，我们重新运行了一次测试，这次测试我们没有重定向AppData文件夹，而是把AppData目录放在UMP的共享目录上本地，文件夹大小在260MB，包含了6390个文件和212个目录。除此之外，就能用了UPM的Profile Streaming属性这样登录过程就会完整的等待用户配置文件被全部下载。由于我们现在是256MB的内存缓存，这个数字是小于270M的Profile的大小的，也就是说内存的大小是无法存放所有的Profile文件，再来看看到底会对结果有什么影响。
由于所有的虚拟机都是运行在Hyper-V平台上而网卡却只有100Mb的限制，所以登录过程毫无疑问会因为下载Profile文件而增加时间。从数据上看，每个用户大概会增加3:30秒来完成启动过程和启动第一次的应用程序。基于这个理由，我们设定每分钟一次的频率来登录。下面就是浮动Profile的登录和稳定状态的测试结果。
|
虚拟机数量 |
登录持续时间 |
全部IO读写 |
每虚拟机IOPS |
每虚拟机 读IOPS |
每虚拟机写IOPS |
读写比例 |
|
11个 |
16分钟 |
每虚拟机 4390 |
4.56 |
0.22 |
4.34 |
5% / 95% |
就算是浮动Profile我们看到每个用户在启动过程也是小于5个IOPS，下面是稳定状态下的结果：
|
虚拟机数量 |
会话持续时间 |
全部IO读写 |
每虚拟机IOPS |
每虚拟机 读IOPS |
每虚拟机写IOPS |
读写比例 |
|
11个 |
45分钟 |
每虚拟机 2301 |
0.85 |
0.02 |
0.83 |
2% / 98% |
稳定状态下的浮动Profile的结果同样比优化过的Profile的数字结果要高，但是即使如此，每个虚拟机的也仍然是小于1个IOPS。
现在我们看看在一个更高端的服务器上运行VMware得出的结果。
在vSphere 5.5平台上的PVS 7.1 RAM Cache 512MB方式发布的Windows 7 VDI桌面
备注：以下测试和上面的MCS环境的测试是在同一个硬件平台上完成。
- 48核心的AMD CPU，512GB内存；
- NFS LUN连接到SAN
- vSphere 5.5
- 150个Windows 7 X64虚拟机配置：2 vCPU，3G内存；
- 在Windows 7虚拟机上运行了McAfee防病毒软件
- PVS 7.1标准镜像，RAM Cache设置为512MB（PVS在单独的主机上）；
- 用户配置文件使用UPM优化和文件夹重定向策略；
测试时我们在服务器上同时启动这150个Windows 7的虚拟机。如果你做过桌面虚拟化的项目应该知道如果你想在一台服务器上同时启动这么多个虚拟机很可能会把服务器直接弄宕机，不过我们还是想试一下，让我们感到开心的事，所有150个Windows 7虚拟机在8分钟内全部连接到了XenDesktop DDC服务器上。下面就是150个虚拟机的启动测试数据：
|
虚拟机数量 |
启动持续时间 |
全部IO读写 |
每虚拟机IOPS |
每虚拟机 读IOPS |
每虚拟机写IOPS |
读写比例 |
|
150个 |
8分钟 |
每虚拟机 655 |
1.36 |
0.5 |
0.86 |
37% / 63% |
对于登录过程的测试，我们配置LoginVSI每12秒钟发起一个会话。按照这个比例，所有的会话在30分钟多一点之内登录完毕，下面是测试结果：
|
虚拟机数量 |
登录持续时间 |
全部IO读写 |
每虚拟机IOPS |
读IOPS |
写IOPS |
读写比例 |
|
150个 |
32分钟 |
每虚拟机 1,144 |
0.59 |
0.01 |
0.58 |
2% / 98% |
最后看看稳定状态下的数据：
|
虚拟机数量 |
会话持续时间 |
全部IO读写 |
每虚拟机IOPS |
读IOPS |
写IOPS |
读写比例 |
|
150个 |
30分钟 |
每虚拟机 972 |
0.535 |
0.03 |
0.532 |
1% / 99% |
从上面的数据看到无论是登录过程还是稳定状态阶段，我们都能够保证每台Windows 7虚拟机的全部IOPS都要小于1。
PVS的新特性Cache in RAM with Hard Disk Overflow就是这么神奇，就算是我们只设置256MB的内存缓存，即使我们的浮动Profile体积超过了256M，结果还是那么的神奇。
那么这个特性对于XenApp来说是不是也是同样适用呢？我们也运行了几个测试在Hyper-V和vSphere上，请访问下一篇博客：PVS让存储颤抖，系列博文之四：PVS的写缓存新技术之XenApp方式实测篇
PVS让存储颤抖，系列博文之三：PVS的写缓存新技术之Win7桌面实测篇