Citrix Profile Management 和 VDI系列讲座之三：大规模环境下的扩展架构设计
说好了要写三期的，上周在出差，最后一期姗姗来迟，还望大家见谅，特别是那些给我回信问我问题的XD们。
咱们第一期讲了如何配置CitrixProfile Management 和 Folder Redirection，第二期讲了性能参数调优，这第三期就升华一下，探讨一下如何在大规模环境中做到文件服务器或者是NAS设备的扩展，同时如何管理用户使用这些设备？
相信你也知道，如果你的环境里面只有500个并发的XenApp用户，或者是500个VDI桌面，那我想这个环境的搭建不会太复杂，一台文件服务器或者是一台NAS设备只要磁盘足够，RAM足够，网卡做到了千兆聚合，我相信对于Citrix Profile Management 和 FolderRedirection的配置管理来说没有任何问题了。但是当你搭建更大规模的环境，例如1000、2000、5000，甚至更大规模的虚拟化环境是，那就不是一台单台的文件服务器或者NAS设备就可以满足需要了。
公司A：有2000个Windows 7的Pool虚拟桌面
我们假象有这样一家公司，如果这家公司需要部署2000个Pool类型的Windows 7虚拟桌面环境，并且所有桌面都是在一个数据中心中。接下去我们来看看这个环境中的Citrix Profile Management 和 Folder Redirection该怎么设计。
首先该环境作如下假设：
所有2000个虚拟桌面都是通过ProvisioningServices发布的标准型非永久型桌面；
所有的2000个虚拟桌面都是在一个数据中心发布；
所有的服务器都是虚拟的，所有的Hypervisor层和文件服务都是通过万兆网络（10Gb）连接；
所有的2000个用户都是使用同一个PVS的标准镜像，通用的应应用程序是安装在这个image中，其他程序通过XenApp来发布，包括使用XenApp的Streaming方式或者是通过虚拟应用发布的方式；
我们限制每个文件服务器或者是NAS设备支持不超过500个用户；
所有用来给Citrix Profile Management 和 Folder Redirection提供文件服务的设备都位于同一个数据中心，和我们2000个虚拟桌面都是内部局域网高速连接的；
场景一：创建单独的桌面组，或者是XenDesktop站点
由于CitrixProfile Management 和 Folder Redirection是通过组策略来配置的，所以最快速简单的办法就是把这2000个用户分为四个组，每个组包含了500个用户。你可以创建四个XenDesktop组，然后让这些桌面的每一个组都保存在一个单个的OU中。
不过由于OU是不同的，所以Citrix Profile Management 和 Folder Redirection的GPO组策略就要各自单独配置一次了。下面的截屏就是XenDesktop的控制台中的配置界面：
某个用户只能被分配到某一个桌面组中，并且每个桌面组都在一个独自的OU中，每个OU的GPO策略来配置Citrix ProfileManagement 和 Folder Redirection属性。
下面的截屏就是在GroupPolicy Management控制台中看到的配置界面：
通过这个办法，我们可以很轻松的将不同的用户分布在不同的文件服务器或者是NAS设备上。同时，这个办法还可以用在多个XenDesktop站点的环境下，而不是仅仅用在单站点多桌面组的环境下。可能你会问，为什么我要配置多个XenDesktop站点，而不是配置一个站点多个桌面组。答案是在真实环境中，或者是在非常关键的场景中，你需要通过多个XenDesktop站点来解决扩展性和可靠性的问题，当然，这个话题暂时和我这篇文章没有太大关系了。
接下去我们看看另外一个问题，最终用户连接到那一个桌面组是不是很重要的？回答应该是不重要。为什么呢？因为如果这个目录或者是为Group1服务器的Hypervisor服务器宕机时，用户应该可以连接到Group2、Group3或者是Group4上，只要有桌面可以连接就行了。由于这所有2000个桌面都是相同的，按照道理来说我可以把用户配置到任何一个组或者是任何一个XenDesktop站点中。但是，这个场景有个问题，就是当Group1不可用时，或者是没有多余的桌面可以提供时，我把新连接的Group1的用户送到Group2中，此时这个新连接的Group1的用户将无法访问到他们的profile以及重定向的文件夹。这些用户也无法得到在Group2组策略上配置的新的Profile和新的重定向的文件夹。这不是我们想看到的结果。理想状态下，我应该把相同的桌面组放到一个单独的XenDesktop站点中，或者是多个XenDesktop站点但是视之为一个统一的逻辑单元。只要虚拟桌面启动后，用户就能够连接到该桌面，并且可以使用它的Profile和重定向的文件夹。
为了让用户可以达到上述效果，我们需要一种更加智能户的办法来发布文件服务，这就给我们带来了下一个办法：
场景二：基于组和活动目录规划的智能负载分配系统
Citrix Profile Management
Citrix Profile Management 的路径和Folder Redirection的路径都是通过组策略来配置的，ProfileManagement的策略是通过一个计算机策略来分配的，Folder Redirection的策略是通过一个用户策略来分配的。这就意味着我们不能使用AD活动目录的组来设置CitrixProfile Management store的路径。由于虚拟桌面和XenApp服务器通过计算机策略都只能有一个路径，这个路径必须有所有登录到虚拟桌面或者是登录到XenApp服务器的用户所使用。
那么我们怎么能给每个用户一个独立的路径来解析到不同的文件服务器呢？答案是DFS-N，以及每个用户帐号中的唯一属性。其实之前CitrixBlog上已经有了两篇博客专门讲如何实现这种方式，甚至eDoc里面也有，还是中文的哦，大家就自己去看吧：
Migrating UPM Profiles �C Tips and tricks
Profile Management �C Load Balancing User Stores
场景 5 - 对用户存储执行负载平衡
DFS-N作为一个命令空间解决方案的最大好处就是在于它是和AD活动目录高度集成的，当然，他也可以和非Windows的NAS设备在一起工作。从我本人来说，我是NetApp的粉丝（也是Citrix全球的战略合作伙伴），他们的CIFS filer technology作为目标设备的也是和DFS命名空间完全兼容的。当然，类似于EMC的非Windows NAS设备也是被DFS所支持的。
回到我们的数据中心的2000个虚拟桌面环境。我们假设我们正在使用NAS设备，并且将它们命名为NYC-NAS1,NYC-NAS2, NYC-NAS3 以及 NYC-NAS4。我们想把用户平均分配到这四台设备上，因此我们创建了下面的AD活动目录DFS命名空间：
\\ABC.corp\NYCDataCenter
我们的四个NAS设备每个都会有一个CIFS共享叫做UserData，并且他们都会被按照以下方式添加为leaf node targets：
通过在每个用户的AD活动目录帐号的UID属性中配置特定的的NAS，我们将这2000个用户分配到这四台NAS设备上。我们配置该UID属性为NYC-NAS1, NYC-NAS2,NYC-NAS3 或者是 NYC-NAS4。其实在选择哪一个AD属性的问题上最有趣的事情是选择哪一个还没被使用的属性。我们可以使用ADSI Edit来查看完整的可用属性列表。有很多属性都可以用来使用但是一般都不会被使用，例如#UID# 或者是#InternationalISDNNumber#。想看完整的属性列表可以参考下面的链接：
All Attributes
User Attributes - Inside Active Directory
AD Attributes
如此说来，我们用来存储ProfileManagement的路径可以是下面的样子：
\\ABC.corp\NYCDataCenter\#UID#\%username%.%userdomain%\UPM
Folder Redirection
好啦，现在我们已经知道了怎么在多个文件服务器上去平均分配这2000个用户，同时又可以只配置一个UPM的路径的办法了。那怎么去在多个文件服务器上去分布配置重定向的文件夹呢？这个问题的答案就是AD的组成员属性（GroupMembership）。当我们通过GPO配置文件夹重定向策略时，我们可以根据用户组成员的不同指定一个不同的路径。
还是这个例子的ABC公司，有2000个桌面用户，那么我们就创建四个AD活动目录的组，把这些用户平均分配到这四个组中。然后将每个组按照数据中心和NAS设备的名字来命名：NYC-NAS1,NYC-NAS2, NCY-NAS3, NYC-NAS4。每个用户应该只能被分配到某一个组中。另外，不管这个用户被分配到哪个组中，他都应该和我们在之前配置Citrix Profile Management是使用的那个AD帐号的属性的值一致。举例来说，如果有一个用户是被分配到了NYC-NAS3组中，那么AD的帐号属性中就应当写入NYC-NAS3。
下面的GPO策略截图就定义了文件夹重定向策略，然后我们将该策略应用到所有ABC公司的2000台虚拟桌面上。
在这个AppData文件夹重定向的例子中，我们给每个组都指定了路径。因此，如果某一个用户是属于NYC-NAS1组的，那么该用户的AppData文件夹路径应当是像下面这样的：
\\ABC.corp\NYCDataCenter\NYC-NAS1\%username%.%userdomain%\FolderRedir\AppData\Roaming
每个文件夹的名字都应当在路径末尾被完整描述。再举个例子，某个属于NYC-NAS1组的用户，它的Desktop文件夹路径应当在GPO策略中被重定向为以下的格式：
\\ABC.corp\NYCDataCenter\NYC-NAS1\%username%.%userdomain%\FolderRedir\Desktop
聊到这里就差不多了，另外我们在设计CitrixProfile Management 和 Folder Redirection的基础架构的时候，还有一些其他的事情要考虑。首先要强调的是我们设计搭建的这套Citrix Profile Management 和 Folder Redirection系统是和虚拟桌面在同一个数据中心的，并且两者是通过高速网络连接的。唯一的例外可能就是用户的个人数据主目录的存放位置了。当然，大部分的情况这些目录也是在同一个数据中心的，不过也并不尽然。如果真的是这样，我还是建议，Citrix Profile Management 和 Folder Redirection还是要和虚拟桌面在同一个数据中心，如果实在不行，就只把用户的个人数据主目录放在其他数据中心。
最后一点要强调的是我在设计CitrixProfile Management 和 Folder Redirection的时候都是用了相同的根路径。也就是说我的Citrix Profile Management 和 Folder Redirection都是用了单独的顶级路径，两者是互不干涉的。千万要注意的是不要把你的Profile路径作为重定向的文件夹路径下的一个字路径，也不要把重定向的文件夹路径作为Profile的一个子路径。把两者都设置为相同的路径级别是最好的办法。在我这里例子中，我个人如果被分配到了NYC-NAS1服务器上，那么我就应该有两个独立的路径来分别存储Citrix Profile Management 和 Folder Redirection：
如果我的个人数据主目录也在这个NAS设备上，那么这个个人数据的路径应该是这样的：
\\ABC.corp\NYCDataCenter\NYC-NAS1\EricYao.ABC\Home
如果我的这个个人数据目录是H盘，那个这个H盘就只能看到Home目录下的文件和文件夹，而不能在H盘里面浏览UMP和FolderRedir文件夹下的内容。
通过本文介绍的办法，我们现在可以将更多更大规模的场景中设计Citrix Profile Management 和 Folder Redirection的架构了，不管用户是分配到那个桌面组或者是哪个XenDesktop的站点中，他都能拿到正确的Profile和重定向的文件夹。
好了，到此为止三部曲全部结束，从最基础的配置，到性能的调优，一直到最后的大规模扩展架构设计都涉及到了，有关这个系列讲座的问题欢迎来信探讨。
祝大家周末愉快！