三. 真实场景
由于之前的两个测试已经给我们提供了宝贵的数据，他们都是在受限制和可控的环境中测试出来的，同时用户的我的文档目录也包含在内，而不是仅仅使用了Citrix Profile Management 以及 Redirected Folders。
而在我的最后一个场景中我找到了一个真实的使用场景，这是一个XenDesktop的生产环境，已经完整运行了一年半的时间，其他情况介绍如下：
l 桌面均由XenDesktop提供，峰值使用人数是每天450个并发；
l 虚拟桌面均是由PVS方式发布的Pool型桌面；
l 已经按照我们在上一讲介绍的Citrix Profile Management和Redirected Folders配置原则实施；
l Profile Management 和Redirected Folders使用了后台Windows 2008 R2的虚拟机作为文件服务器保存用户数据。用户的个人文件夹“我的文档”放在另外一台服务器上；
l 大部分的用户都是标准的Office型用户，虽然也使用了很多其他程序，但是大部分的应用都是Office 2010、Internet Explorer、 Firefox、 Media Players、Adobe Acrobat，以及QQ等；
我在每天的早晨6点开始直到晚上6点结束，一直追踪性能数据。每天我搜集到的数据基本上都是类似的规律，以保证数据的可靠性。同时在12个小时之内搜集也保证不会遗漏波峰和波谷数值。根据我的观察结果，每天有两个提供我们数据的最佳时间点：
1. 07:00 – 09:30，大部分用户都在这个期间登录；
2. 10:30 – 16:00，大部分的用户都在这个期间最频繁的使用电脑
接下去看看我在这期间整理的数据：
07:00 – 09:30，大部分用户的登录期
在上述时间段，我们观察到07:00时间点已经开启了103个桌面，在接下去的150分钟内逐渐增加了243个用户登录，这243个用户基本上保持了恒定的37秒一个用户的登录速度。到09:30的时间点总共有346个用户已登录。平均的用户登录数十225个。
| 平均总IOPS |
平均读IOPS |
平均写IOPS |
最大读IOPS |
最大写IOPS |
| 127 |
50 |
77 |
962 |
663 |
| 平均 RX Mbps |
平均 TX Mbps |
最大 RX Mbps |
最大 TX Mbps |
| 4.58 Mbps |
15.92 Mbps |
230 Mbps |
360 Mbps |
在上述登录时间段中，每用户的平均的IOPS和网络带宽数据如下表所示：
| 平均总IOPS |
读/写比例 |
平均网络带宽 |
| 0.5 |
40/60% |
0.07 Mbps |
10:30 – 16:00，持续使用时间段
在持续使用时间段，我们有364个虚拟桌面登录，同时峰值时444个登录用户。在早晨11点到达了峰值点，直到下午15:30开始由用户注销桌面。在这段时间期间，平均的用户连接数是420个。
| 平均总IOPS |
平均读IOPS |
平均写IOPS |
最大读IOPS |
最大写IOPS |
| 472 |
78 |
394 |
1058 |
3925 |
| 平均 RX Mbps |
平均 TX Mbps |
最大 RX Mbps |
最大 TX Mbps |
| 5.95 Mbps |
6.43 Mbps |
159 Mbps |
348 Mbps |
在上述登录时间段中，每用户的平均的IOPS和网络带宽数据如下表所示：
| 平均总IOPS |
读/写比例 |
平均网络带宽 |
| 1.1 |
17/83% |
0.02 Mbps |
我们已经有了一个实际环境的数字，现在让我们对这些IOPS的数字做一下分析吧。在早晨的登录高峰时间段，文件服务器上的读写比例基本上是40:60的读写IOPS比例。这个结果和我们在第二个LoginVSI场景中测到的中等负荷压力测试数字保持一致，也和我们第一种的64分钟重负荷测试环境接近。第一种场景我的桌面是60：40，LoginVSI是50：50，而实际环境是40：60。
但是，但我们回过头来看持续使用的这5个小时，读写比例却发生了很大的改变，读写比例是17：83%。为什么读写比例发生如此大的转变呢？答案就是文件服务器的读缓存能力，也就是说每个虚拟桌面链接到文件服务器时，文件服务器为该桌面开辟了读缓存区域。
一旦文件从磁盘中读取，Windows就会将它加载到系统的RAM内存中。文件实际上是被缓存到了两个地方，一个就是文件服务器，另外一个就是读取他的Windows客户端，也就是我们的虚拟桌面。因此，随着时间的推移，越来越多的读操作实际上是由最初申请读取此文件的虚拟桌面系统的RAM内存或者是由文件服务器的RAM内存来完成的。这也是为什么要给你的文件服务配置器更高的内存的重要性了。这就有点类似于我们的PVS服务器把vDisk读到内存中进行操作的原理类似。有关于Windows的缓存原理，可以看看其他的两篇Blog文章：
http://support.citrix.com/article/ctx125126
http://blogs.citrix.com/2010/11/05/provisioning-services-and-cifs-stores-tuning-for-performance
正式因为Windows的读缓存机制，所以我们推荐在RAID控制器上配置25：75的读写缓存比例。由于Windows有内建的读操作缓存机制，所以我们希望将更多的RAID控制器的资源分配给写操作。
接下去，当我们看看登录期间和工作期间的IOPS变化，你就会注意到IOPS的负荷在登录期间非常轻，完全看不到所谓的因文件服务器的IOPS读写要求太高而导致的启动风暴问题。哈哈，我相信你肯定会想这个数字估计是错了。其实没有错，原因也很简单，因为我们已经根据我们第一讲的原则，通过正确的配置Profile Management和Redirected Folders而有效的消除了启动风暴。更重要的是，我已经重定向了所有的文件夹，包括AppData，因此从文件服务器上最初加载的读取Profile的内容其实非常的小。实际上，经过18个月的实践，下面就是文件服务器上Profile和Redirected Folders的统计数字：
| 文件夹类型 |
用户使用数 |
每用户平均大小 |
| Profile文件夹 |
5617 |
14.6 MB |
| 重定向文件夹 |
5617 |
89M |
请注意的是我们配置后的Citrix Profile是不到15MB的，如果你曾经配置过Profile的重定向，应该知道这个值是不可思议的小的。我们是通过正确配置Profile Management，并且通过Windows 7的GPO策略重定向所有的可用文件夹，最后排除了不必要的文件和文件夹，通过这三者才实现了这个目标。此外，你应该也可以看到我们的重定向文件夹平均大小是89MB。在前文我们曾经提及过，在该客户的实际环境中，我的文档、视频以及音乐目录是没有重定向到这台文件服务器上。这些目录被重定向到用户的个人数据主目录下，而该目录是在另外一台文件服务器上。经过我们进一步分析，不难发现在重定向的文件夹中有差不多80%的数据都是来自于AppData。如果我们没有重定向AppData，那么每个用户在启动时平均就要下载超过70MB或者更多的数据。这才会对文件服务器的造成性能上的冲击，进而造成IOPS的启动风暴问题。
我不想再继续谈重定向AppData的优点和缺点，在上一讲我们已经详细讨论过这个问题。总之，我们目前的情况就是该客户的重定向的AppData几乎没有任何性能上，亦或者是兼容性上的问题。想要证明这一点也很简单，你只要把AppData设置成漫游模式，或者设置成流化模式，然后看看随之出现的性能问题，以及文件服务器上的IOPS负荷就知道了。事实就是在AppData中有超过80%的文件在一天中从来不曾被读过，既然如此，读取这些文件也好，下载这些文件也好，无疑会增加网络的开销，也会增加文件服务器上的RAM内存开销，也会增加虚拟桌面的RAM内存的开销，更重要的是，这些完全是没有任何意义的。
网络数据的意义
那么Citrix Profiles 和Folder Redirection到底需要多少网络带宽呢？在我们第二个场景的LoginVSI测试中，我们测算出来大概需要每用户0.36 Mbps，真实环境的客户在启动峰值时大概消耗0.07 Mbps。两者之间主要的区别在于LoginVSI的负荷中所有的用户都在工作状态，而在真实环境中，总有那么些个用户是出于桌面的闲置状态，或者是他的当前工作根本不需要用到文件服务器的网络传输条件的，所以数字会小这么多。其实我测试出来的这些数字和微软公司写的一篇关于文件服务器容量测算工具的文章有异曲同工之处，你可以点击下面的链接去看看这篇文章：
http://blogs.technet.com/b/josebda/archive/2011/04/08/fsct-test-results-detail-the-performance-of-windows-server-2008-r2-file-server-configurations-23-000-users-with-192-spindles.aspx
微软的这个测试主要是设计用来仿真用户主文件目录的使用情况，因此，他的结论和Profiles 以及Folder Redirection的使用情况很类似。它得出的结论是0.22 Mbps/用户。
我到底需要多少网络带宽和IOPS呢？
在谈这个问题之前，首先你要清楚的知道你的用户是哪一种类型的。在我们的真实环境中，和我的第一种重负荷桌面，以及第二种LoginVSI中等负荷昼眠比较，真实环境的IOPS和网络吞吐量都远远小于前两者。主要原因就是因为我们的真实环境中的用户的主要工作都是基于Office操作的，而不是重负荷的工作方式。以此类推，大部分公司的办公环境的使用者其实经常会出现中途休息、吃中午饭、坐着开会、讲电话、和其他同事聊天，等等。每天中很多时间该用户的桌面其实都是闲置状态，对文件服务器机会没有操作的请求，当然更加就没有IOPS和网络的需求了。不信的话，你自己去任何一家公司找一些桌面型用户看看就知道了，看看这些用户是不是已经登陆桌面，但是完全没有使用桌面。反正我是屡见不鲜的。我的经验是有超过50%的情况都是如此。
话要说回来，在某些场景，可能使用率反而会更高，例如呼叫中心的环境。很有可能有超过80%的用户是始终处于工作状态。不过即使是如此，大部分的公司的IT部门一般都会超量估算真实需求的一倍有余。有时候也是为了怕担负责任。
还要说一下就是这个PST和OST文件的问题，对Pool类型的桌面来说，Exchange服务器应当和虚拟桌面在一个数据中心为最佳，这样离线缓存就不用启用了。
好了，说了那么多了，还是回到现实来吧，我们来估算一下显示环境中IOPS和网络带宽的需求把，暂时以办公环境用户为主，前提还是按照我们第一讲的内容正确配置了Citrix Profile Management 和 Folder Redirection。下面的表格就是我的最后推荐值：
| 文件夹类型 |
IOPS |
读/写比例 |
网络带宽 |
| Profile和重定向文件夹 |
1.5 |
35/65 |
0.25 Mbps |
| 用户数据主目录 |
1.5 |
35/65 |
0.25 Mbps |
如果你正在做一个VDI项目，假设你有1000个用户，你正准备将用户的个人数据、profile以及重定向的文件夹都迁移到一个新的NAS存储上，那么你的NAS需要支持3,000 IOPS，以及支持 500 Mbps的网络吞吐量。
IOPS = (1K x 1.5 Profile/Folder IOPS) + (1K x 1.5 主目录 IOPS)
网络带宽 = (1K x .25 Mbps Profile/Folder 带宽) + (1K x .25 Mbps 主目录带宽)
最后一个问题我想谈的是，到底要不要将Profile和重定向文件夹的文件服务器和存储用户个人数据空间的文件服务器合并呢？就是说放在一台服务器上呢？一般来说，如果公司都已经为他们的用户部署了用户数据个人空间，那么我就建议还是分开来部署比较好。以免造成现有的文件服务器的过载可能性，最好还是搭建一个专门的文件服务器群集，或者是NAS储存用来专门存储Profile和重定向的文件夹。分开放的好处很明显，就是性能会更好。
当然，分开放的做法不是必须的。如果环境并不大，经过计算你觉得IOPS和网络都不是问题，那就可以把它们放在一起。唯一需要注意的就是存储Profile和重定向文件夹的文件服务器和虚拟桌面应该在同一个数据中心，如果是连在同一台核心交换机上那当然是求之不得。
第二讲就结束了，希望你对我的文章感兴趣，也希望提供宝贵意见。