Citrix Profile Management 和 VDI系列讲座之二：Profile漫游需要怎么配置存储和网络
上一期《Citrix Profile Management 和 VDI系列讲座之一：如何正确管理Profile》我们谈到了如何正确配置Citrix Profile Management 以及Folder Redirection使之可以适应各种规模的企业。在这一期讲座中，我将主要谈一下为Citrix Profile Management 和 Folder Redirection所配置的后台文件服务器或者是NAS设备上所需要的IOPS和网络带宽问题，希望能为你将来在规划单个文件服务器或者是NAS设备上能承载多少个用户提供帮助。
当然，必须首先指出的是我这里只是提出一个建议，并非一个固定值，就好象我可以推荐一在一台二路六核的服务器上运行40-60个VM，但是如果是研发用户的使用场景，也有可能只能运行20-40个VM。同样道理，我这里所说的一些结论和数据都需要你根据实际场景来进行调整。
当然，为了让我的结论更有说服力，我在实验环境中用不同的方法做了两个测试，同时又在另外一个实际的XenDesktop环境中进行实际数据捕获，以得到一个更精确的结果。
文件服务器的性能和扩展性
在我们开始具体计算Citrix Profile Management 和 Folder Redirection需要多少后台资源之前，首先看看有哪些因素可能会影响到后台的性能。这其中包括了：
物理存储设备能提供多少IOPS：
多少块磁盘？
使用了什么RAID设置（RAID1，5，0，10？）
RAID控制器的缓存有多大? 是如何配置的？
有没有配置写优化？例如分层存储，SSD存储？
提供给CIFS的读缓存有多大的RAM？
网络适配器的速度是多少？
CPU配置情况如何？
正在使用哪一个版本的CIFS/SMB，1.0？2.0？还是2.1？
CIFS协议有没有调优过？
有关CIFS调优的方法，可以参考Citrix Blog的文章：
http://blogs.citrix.com/2010/10/21/smb-tuning-for-xenapp-and-file-servers-on-windows-server-2008/
如果你使用的是Windows2008 R2操作系统的文件服务器或者Cluster（无关是物理的还是虚拟的），请至少以下面为最低条件来配置：
文件服务器至少是32G内存（最好是64G）
文件服务器至少是2个core/vCPU（建议配置4个或更高配置）；
按照上面CIFS调优的建议完成所有关于SMB的调优建议；
如果是本地存储（虽然最好是别这样。。。），至少也要配置15k转的SAS硬盘，以及RAID卡。
如果你的NAS设备是从NetApp或者是EMC购买的，那就谢天谢地，至少我不用担心CPU、内存以及RAID的设置和是否经过优化了。不过，即使是NAS设备，我建议还是要去验证一下CIFS的版本号，至少要支持SMB2，而且正确调优过。
正如我刚才所提出的建议，有很多因素决定了文件服务器的性能。但是我这篇讲座不想去就如何文件服务器的存储系统的调优和设计，而会集中在以下两个方面去讨论：
每个用户的需要多少个IOPS，以及读写的比例各是多少？
每个用户需要多大的网络带宽？
当然，上述议题的前提是你已经按照我的第一篇讲座所要求的那样去正确配置了Citrix Profile Management 和 Folder Redirection的设置，在这个基础之上我们才有可能计算出来准确的IOPS和网络带宽数值。
需要多少IOPS呢？
我相信你更加关心的是Profile 和 Folder Redirection所需要的IOPS该如何计算。所以我准备通过三个途径去获得这个数据：
我自己的桌面需要多少IOPS
使用LoginVSI自动化脚本计算出来的中等负荷的IOSP
在一个真实场景中需要多少IOPS和网络带宽
再次强调一点，我计算的是文件服务器上的IOPS，不是VM的C盘上的IOPS。J
一．我自己的桌面需要多少IOPS
在第一个场景中，首先我们来看看我自己的虚拟桌面的IOPS的使用情况。在我的桌面设置中，我将我的所有的目录、Profile，以及我的个人文件夹都重定向到了一个专门的主机上。这个服务器除了为我提供服务以外不作任何其他事情，这样以便于我们追踪到底Profile和文件夹重定向需要多少IOPS。
我运行了64分钟，在此期间，我打开了所有的我平时使用的应用程序，并且尽可能的去执行操作。在这64分钟内，我没有停过，始终保持工作状态。一边运行更多的程序，执行更多的操作。其实我这么做很明显比大家平时的操作占用了更多的资源。但是我相信这样做能最大程度的模拟在负荷最重的情况下这些常用软件所能产生的后台开销。顺便说一下，在测试之前，我把所有系统都重启过一次，以保证我要测试的应用程序和数据都没有驻留在内存中。
我做了以下的操作：
登录Windows以后立即打开Windows Media Player，开始从我的文档文件夹中播放MP3，并且持续整个测试时间段；
打开Internet Explorer 和 Firefox，然后打开一些常见的页面，例如新浪网、网易等。，然后将这些页面保持到测试结束。在测试的64分钟内，我不停的将页面切换到Internet Explorer 和 Firefox打开的不同Tab页面，并且执行上下滚动操作。
打开腾讯QQ，并且保持在线状态；
打开Outlook，并连接到我公司自己的Citrix Exchange Server。当前我的OST文件是1.3GB大小，同时Outlook设置为缓存模式，另外还有一个1.7G大小的PST文件；
发送和接收邮件，像正常那样；
从收件箱中打开邮件，正常操作，创建日历等等；
从pst文件按中打开电子邮件；
将收件箱中的邮件清理到pst文件中；
清空Deleted items，原来这里有三千多封以#Support开头的邮件（Citrite你懂的。。。）；
关闭Outlook，然后通过我的个人邮件帐户使用MAPI的Profile运行Outlook两次，我的个人邮件帐户有超过1G的pst文件；
打印几封邮件到pdf格式，然后保存到我的文档中；
在检查了我的个人邮箱后，再次打开公司的Outlook，连接到 公司的Exchange MAPI Profile；
Outlook保持打开状态，并且时不时用一下；
从我的文档中打开然后编辑几个Excel文件；
从我的文档中打开然后编辑几个Word文件；
从ShareFile中下载一个108M大小的视频文件到我的文档中；
从Outlook中保存一个6M大小的PPT文件到我的文档，然后打开它；
注销Windows系统；
下面的表格列出来了保存了“我的Profile、重定向的文件夹以及我的文档目录”的磁盘上的IOPS的使用情况：
保存我的“Profile、重定向的文件夹以及我的文档目录”的磁盘是一块单个的SATA7200转磁盘，在测试的时候只运行了我的测试系统。因此，所有的IOPS可以认为是全部是我的操作所产生。最后的结果可以看到是总计 5.7个IOPS，读写比例是55：45。
在对我的行为作了更细节的分析之后，我找到了我的操作中产生的大部分的IOPS都是来自于Outlook，因为Outlook不断的读和写到我的离线缓存文件（outlook ost文件）以及我的pst文件中。
二．使用LoginVSI自动化脚本计算出来的中等负荷的IOSP
在我的第二个测试中，我决定使用LoginVSI这个工具来测试。如果你还不熟悉LoginVSI，你可以参考一下我在2011年6月13日早上发给你的一封邮件，标题是《如何进行 XenDesktop5 的压力测试？》。
LoginVSI是一家叫做Login Consultants开发出来的测试工具。他们公司的主页是：http://www.loginvsi.com/
还是和第一个场景一样，我把共享目录都放在这个文件服务器上，所有I/O操作都是在这个服务器上完成的。包括我的“Profile、重定向的文件夹以及我的文档目录”。
我选择了中等负荷的压力，由该压力测试软件执行了15分钟的中等压力测试脚本，该脚本包含了一下内容：
登录Windows；
打开使用pst的Outlook；
打开、创建和编辑Word文档；
打开、创建和编辑Excel文档；
打开、创建和编辑PPT文档；
打开IE浏览器；
打开Flash和多媒体文件；
注销Windows；
测试持续了15分钟，包含了3个测试帐号，每个帐号都执行了完整的中等负荷测试脚本，下面的表格显示了三个用户后的平均IOPS结果：
下一个表格显示的是文件服务器上的网络使用情况，该文件服务器是安装了一块千兆网卡：
当我们在查看网络利用率的时候，很重要一点是主要网卡其实是工作在全双工模式下。对于我使用的这张千兆网卡来说，它可以同时发送和接受1 Gb的数据，由于我们限制在任何的单向上的最大速度1 Gig，所以我们从任何的单向上只取最高值，并且用这个值来决定我们的每用户平均带宽。基于上述的测试，每用户平均的IOPS和网络带宽应该是如下表所示：
三. 真实场景
由于之前的两个测试已经给我们提供了宝贵的数据，他们都是在受限制和可控的环境中测试出来的，同时用户的我的文档目录也包含在内，而不是仅仅使用了Citrix Profile Management 以及 Redirected Folders。
而在我的最后一个场景中我找到了一个真实的使用场景，这是一个XenDesktop的生产环境，已经完整运行了一年半的时间，其他情况介绍如下：
桌面均由XenDesktop提供，峰值使用人数是每天450个并发；
虚拟桌面均是由PVS方式发布的Pool型桌面；
已经按照我们在上一讲介绍的Citrix Profile Management和Redirected Folders配置原则实施；
Profile Management 和Redirected Folders使用了后台Windows 2008 R2的虚拟机作为文件服务器保存用户数据。用户的个人文件夹“我的文档”放在另外一台服务器上；
大部分的用户都是标准的Office型用户，虽然也使用了很多其他程序，但是大部分的应用都是Office 2010、Internet Explorer、 Firefox、 Media Players、 Adobe Acrobat，以及QQ等；
我在每天的早晨6点开始直到晚上6点结束，一直追踪性能数据。每天我搜集到的数据基本上都是类似的规律，以保证数据的可靠性。同时在12个小时之内搜集也保证不会遗漏波峰和波谷数值。根据我的观察结果，每天有两个提供我们数据的最佳时间点：
07:00 �C 09:30，大部分用户都在这个期间登录；
10:30 �C 16:00，大部分的用户都在这个期间最频繁的使用电脑
接下去看看我在这期间整理的数据：
07:00 �C 09:30，大部分用户的登录期
在上述时间段，我们观察到07:00时间点已经开启了103个桌面，在接下去的150分钟内逐渐增加了243个用户登录，这243个用户基本上保持了恒定的37秒一个用户的登录速度。到09:30的时间点总共有346个用户已登录。平均的用户登录数十225个。
在上述登录时间段中，每用户的平均的IOPS和网络带宽数据如下表所示：
10:30 �C 16:00，持续使用时间段
在持续使用时间段，我们有364个虚拟桌面登录，同时峰值时444个登录用户。在早晨11点到达了峰值点，直到下午15:30开始由用户注销桌面。在这段时间期间，平均的用户连接数是420个。
在上述登录时间段中，每用户的平均的IOPS和网络带宽数据如下表所示：
我们已经有了一个实际环境的数字，现在让我们对这些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文章：
Advanced Memory and Storage Considerations for Provisioning Services
Provisioning Services and CIFS Stores �C Tuning For Performance
正式因为Windows的读缓存机制，所以我们推荐在RAID控制器上配置25：75的读写缓存比例。由于Windows有内建的读操作缓存机制，所以我们希望将更多的RAID控制器的资源分配给写操作。
接下去，当我们看看登录期间和工作期间的IOPS变化，你就会注意到IOPS的负荷在登录期间非常轻，完全看不到所谓的因文件服务器的IOPS读写要求太高而导致的启动风暴问题。哈哈，我相信你肯定会想这个数字估计是错了。其实没有错，原因也很简单，因为我们已经根据我们第一讲的原则，通过正确的配置Profile Management 和Redirected Folders而有效的消除了启动风暴。更重要的是，我已经重定向了所有的文件夹，包括AppData，因此从文件服务器上最初加载的读取Profile的内容其实非常的小。实际上，经过18个月的实践，下面就是文件服务器上Profile和Redirected Folders的统计数字：
请注意的是我们配置后的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的负荷中所有的用户都在工作状态，而在真实环境中，总有那么些个用户是出于桌面的闲置状态，或者是他的当前工作根本不需要用到文件服务器的网络传输条件的，所以数字会小这么多。其实我测试出来的这些数字和微软公司写的一篇关于文件服务器容量测算工具的文章有异曲同工之处，你可以点击下面的链接去看看这篇文章：
FSCT test results detail the performance of Windows Server 2008 R2 File Server configurations - 23,000 users with 192 spindles
微软的这个测试主要是设计用来仿真用户主文件目录的使用情况，因此，他的结论和Profiles 以及Folder Redirection的使用情况很类似。它得出的结论是0.22 Mbps/用户。
我到底需要多少网络带宽和IOPS呢？
在谈这个问题之前，首先你要清楚的知道你的用户是哪一种类型的。在我们的真实环境中，和我的第一种重负荷桌面，以及第二种LoginVSI中等负荷昼眠比较，真实环境的IOPS和网络吞吐量都远远小于前两者。主要原因就是因为我们的真实环境中的用户的主要工作都是基于Office操作的，而不是重负荷的工作方式。以此类推，大部分公司的办公环境的使用者其实经常会出现中途休息、吃中午饭、坐着开会、讲电话、和其他同事聊天，等等。每天中很多时间该用户的桌面其实都是闲置状态，对文件服务器机会没有操作的请求，当然更加就没有IOPS和网络的需求了。不信的话，你自己去任何一家公司找一些桌面型用户看看就知道了，看看这些用户是不是已经登陆桌面，但是完全没有使用桌面。反正我是屡见不鲜的。我的经验是有超过50%的情况都是如此。
话要说回来，在某些场景，可能使用率反而会更高，例如呼叫中心的环境。很有可能有超过80%的用户是始终处于工作状态。不过即使是如此，大部分的公司的IT部门一般都会超量估算真实需求的一倍有余。有时候也是为了怕担负责任。
还要说一下就是这个PST和OST文件的问题，对Pool类型的桌面来说，Exchange服务器应当和虚拟桌面在一个数据中心为最佳，这样离线缓存就不用启用了。
好了，说了那么多了，还是回到现实来吧，我们来估算一下显示环境中IOPS和网络带宽的需求把，暂时以办公环境用户为主，前提还是按照我们第一讲的内容正确配置了Citrix Profile Management 和 Folder Redirection。下面的表格就是我的最后推荐值：
如果你正在做一个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和重定向文件夹的文件服务器和虚拟桌面应该在同一个数据中心，如果是连在同一台核心交换机上那当然是求之不得。
第二讲就结束了，希望你对我的文章感兴趣，也希望提供宝贵意见。