PVS让存储颤抖，系列博文之四：PVS的写缓存新技术之XenApp方式实测篇

XenApp运行环境

XenApp 6.5运行在Windows 2008 R2上

和运行VDI的测试类似，XenApp的测试方式如出一辙。LoginVSI还是设置为中等负荷，使用同样的用户帐号设置，也是同样的用户配置文件设置。不过用户配置文件我们使用的是优化了的配置文件管理。另外，XenApp虚拟机一般来说数量较少而内存较大，所以我们侧视了几种Cache in RAM with Hard Disk Overflow的大小，包括1GB、3GB以及12GB的内存，测试结果在下面。

XenApp 6.5运行在Windows 2008 R2上

我们继续使用Hyper-V主机，和上面的VDI测试场景一样。主机配置如下：

• 四核超线程CPU，32G内存，Hyper-V平台；
• Hyper-V 2012 R2
• 一块专用的7200转SATA 3硬盘（带64M缓存），用户存放XenApp虚拟机的写缓存；
• 2个Windows 2008 R2平台的XenApp 6.5虚拟机，配置如下：
  • 4个vCPU，14GB内存
  • 60个LoginVSI发起的会话（每虚拟机30秒）

测试场景1：PVS XenApp Target Device的RAM Cache设置为1GB

这次测试我们配置LoginVSI每30秒钟发起一个会话，登录持续时间30分钟。

从上面的数据看到30个用户的登录过程的平均IOPS开销少于11个IOPS，要知道这个数据仅仅比XenApp虚拟机在启动阶段的峰值IOPS开销5个IOPS只打了一点点。

下面是稳定状态的数字：

在45分钟之内的稳定状态下的IOPS的平均开销是6个，这就意味着每个XenApp虚拟机的开销是3个IOPS，而每个用户的开销是0.1个IOPS。

这个结果对于只设置了1GB缓存的14GB内存的XenApp虚拟机来说是非常有震撼力的。在测试的XenApp的峰值点的时候，LoginVSI启动了30个激活有效状态的中等负荷的会话在同时运行，虚拟机仅仅使用了10GB多一点的内存。所以我们决定增加RAM Cache到3GB并且重新运行测试。

测试场景2：PVS XenApp Target Device的RAM Cache设置为3GB

这次测试和刚才的测试使用完全相同的配置，除了LoginVSI发起会话的时间改为了20秒钟一次（上面是30秒钟一次）。

下面是稳定状态的数字：

只设置1GB缓存的XenApp虚拟机所产生的IOPS结果已经让我们很兴奋了，然而增加到3GB的缓存还能减少更多的IOPS需求。我们能为XenApp虚拟机在30个用户连接的状态下平均只有2个IOPS。

上面还只是一个实验室里的Hyper-V的测试环境，在用户的生产环境下更大规模的XenApp会表现如何呢？

XenApp 6.5 2008R2运行在VMware vSphere 5.5上

• 48核心的AMD CPU，512GB内存；
• NFS LUN连接到SAN
• vSphere 5.5
• 10个2008R2平台上的XenApp 6.5虚拟机，配置如下
  • 6个vCPU，48GB内存
  • 写缓存磁盘放在NFS LUN上
  • PVS 7.1标准镜像文件，设置RAM Cache为12GB（PVS运行在单独的主机上）
  • 用户配置文件使用UPM优化和文件夹重定向策略；

在这次测试中我们在服务器上运行了10个XenApp虚拟机，每个虚拟机配置了48GB的内存，PVS的RAM Cache设置为12GB。我们发起了300个LoginVSI中等负荷的会话，这样每个虚拟机能承载30个用户的会话。在LoginVSI上配置每用户启动间隔为8秒钟，这样整个启动时间可以控制在40分钟左右。下面是测试结果。

下面是稳定状态下的数字：

从上面的数字可以看出来，登录过程和稳定状态的过程都是相似的，跨越10个XenApp虚拟机的300个用户的两个阶段都是在7个IOPS左右，这比每个XenApp虚拟机分配1个IOPS还要少。很显然这些数字表明在PVS配置的RAM缓存中的数据完全没有溢出到磁盘中。

PVS让存储颤抖，系列博文之四：PVS的写缓存新技术之XenApp方式实测篇