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

浏览数：39 / 时间：2015年06月11日

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分钟。

虚拟机数量	登录持续时间	全部IO读写	IOPS	读IOPS	写IOPS	读写比例
60个	30分钟	每虚拟机 19687	10.9	0.1	10.8	1% / 99%

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

下面是稳定状态的数字：

虚拟机数量	会话持续时间	全部IO读写	IOPS	读IOPS	写IOPS	读写比例
60个	45分钟	每虚拟机 16411	6	3.7	2.3	61% / 39%

在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秒钟一次）。

用户数量	登录持续时间	全部IO读写	IOPS	读IOPS	写IOPS	读写比例
60个	20分钟	1673	1.4	0.1	1.3	7% / 93%

下面是稳定状态的数字：

用户数量	会话持续时间	全部IO读写	IOPS	读IOPS	写IOPS	读写比例
60个	45分钟	7947	2.95	0.05	2.9	2% / 98%

只设置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分钟左右。下面是测试结果。