一、Zones的概念
Zones这个概念在Citrix的产品中存在于两个出处，第一个出处是在原来的XenApp系列产品中，用于进行大规模部署的时候，分区域进行统一管理。第二个是出现在XenApp/XenDestop 7.7中，同样用于多区域部署。纵观Citrix的产品线，一致保持着稳定更新和增长的产品是NetScaler，至于XenApp和XenDesktop，这两个产品最初采用的都是一致的架构IMA，也是Citrix最初深耕和起家的产品。后来在XenDesktop 5.x的时候Citrix改由FMA架构，IMA架构的天生短板制约了她对于虚拟桌面的支持和后续的扩展。因此Citrix改为更适合虚拟桌面的FMA架构是完全可以理解的。后来微软对Windows Server 2012 RDS架构性的改变，让Citrix XenApp被动的放弃掉IMA架构转而采用FMA架构。截止到XenApp 6.5，Citrix对于IMA架构已经深耕二十多年，各项产品功能和组件以及稳定性都比较完善，但是FMA在XenDesktop 5.x的时候才推出，至今也就经历两次比较大的版本迭代，各种功能模块以及稳定性都需要慢慢磨合，因此我们可以发现，在转向FMA架构之后，Citrix之前在IMA架构所积累的产品功能以及组件都需要在FMA架构下重新再来一次，比如监控的功能：EdgeSight，在IMA架构时代完善程度FMA架构的监控工具Director至今都没有做到。相应的，对于全球部署以及大规模部署的情况下，基于Zones这个概念来对区域进行划分，统一管理是Citrix在IMA时代所积累下来的优秀思想，因此在新的FMA架构下，必然的重新开发基于FMA架构的Zones。
那么FMA架构下的Zones和IMA架构下的Zones是一样的吗？如果我们熟悉FMA架构和IMA架构，那么自然地，基于理论知识为基础的推论，我们就会明白，他们之间Zones是非常相似，但也有不同。例如，在FMA的Zones实现中，不包含数据收集器。此外，FMA站点中的所有 Controller 都与主Zone中的一个站点数据库进行通信。此外故障转移和首选区域的工作方式实现也不同。
二、FMA架构下的Zones
首先我们需要明白，Citrix在XenApp/XenDesktop 7.7 版本的时候推出这个Zones是为了干什么？如上述所说，为了解决多区域部署统一管理的问题！那么我们需要多少个Zones？换句话说，我们的Zones边界在哪里，如何来进行划分？此时，有几点需要考虑到：
用户分布在哪里？
用户怎么接入系统？
Site的数据库是如何建立的？
我们根据这些因素来确认和判断，我们在进行多区域部署的时候，到底需要多少个Zone的问题。建立了多个Zone，那我的Zone与Zone之间是互联桌面实现？以及内部多个Zone之间，谁听谁的？
首先我们来说明，谁听谁的问题。Citrix在设计Zones的时候，所考虑来解决这个问题的思路是Master/Slave模式。也就是说，在我们进行多区域部署的时候，我们所设计的多个Zone之间，必定会有一个Master，这个Master在FMA架构下成称为Primary zone，中文我们可以称为主区域或者主Zone。其余的区域称之为satellite zone，中文我们可以称之为卫星区域。
Primary zone
主区域的默认名称为“Primary zone”，该区域中包含 SQL Server 站点数据库（高可用性 SQL Server）、Citrix Studio、Citrix Director、Citrix StoreFront、Citrix 许可证服务器和 NetScaler Gateway。其中只带说明的是，在Citrix下的设计中，Zones的站点数据库应始终位于主区域中，也就是说，在这一个大的统一的多区域环境下，只存在一个数据库，这个数据库之部署在主区域内，其他的区域就需要通过网络远程来读取这个数据库的数据信息，以保证数据始终真实有效。
主区域在设计的时候数据库必须要高可用设计，同时至少包含两个 Controller 以实现冗余。这个时候，如果是在一个大型的跨国企业部署这样的架构，那么主区域必然的就部署在该集团的总部数据中心，主区域内的Controller以及StoreFront等等基础架构服务器所提供的服务就是给到总部的用户所使用。
Satellite Zone
一个卫星区域包含一个或多个 VDA、Controller、StoreFront 服务器和 NetScaler Gateway 服务器。在正常情况下，卫星区域中的 Controller 直接与主区域中的数据库进行通信。同时在卫星区域（特别是大型卫星区域）可能还包含虚拟机管理程序，用于置备和存储该区域的计算机的计算以及存储资源。也就是说，卫星区域内部署的Citrix虚拟桌面或者虚拟应用的架构，除了数据库没有之外，其他的和我们平时在多区域部署的时候，进行独立部署是一样的。
一个站点内至少需要有一个主区域。同时可以有一个或者多个卫星区域，卫星区域取决于用户的规模以及用户的分布情况。比如可以为灾难恢复、地理位置相隔很远的数据中心、分支机构、或云中的可用性区域使用卫星区域。
需要值得强调的是，主区域包含两个 Controller、Studio、Director、StoreFront、许可证服务器和站点数据库（以及高可用性 SQL Server 部署）。主区域还包含多个 VDA 和一个或多个 NetScaler Gateway。
而对于卫星区域呢？
Citrix的设计思路需要解决两个问题：一是如何解决WAN链路出现问题的情况下卫星区域内的环境正常运行？假设在卫星区域内包含一个 Controller、多个 VDA 和一个 StoreFront 服务器。此卫星区域中的 VDA 注册到本地卫星区域的 Controller 中。本地卫星区域的 Controller 与主区域站点中的站点数据库和许可证服务器进行通信。如果WAN链路出现故障，位于卫星区域本地的Controller连接租用功能将允许该卫星区域中的 Controller 继续代理与该区域中的 VDA 的连接。如果办公室里的工作人员使用本地 StoreFront 站点和本地 Controller 访问其本地资源，则此类部署会非常有效。因此通过连接租用功能以及License的豁免期功能，完全可以使得卫星区域的环境主一定时间内正常运行。
但是这种情况下出现的问题是什么？如果在Wan链路断开的情况下，卫星区域的环境无法访问到主区域中的数据库，那么也就意味着说，卫星区域的环境的缓存本地Controller的数据只能够进行读取而不能写入。换句话说就是我们的本地管理员是对于环境的所以变更操作都是无效的，不产生作用。同时另一个问题就是如何保证卫星区域环境下，本地Controller或者StoreFront服务器出现故障不可用的情况？
这就是Citrix的设计思路需要解决的问题之二，如何在WAN出现链路断开的情况下而本地卫星区域的环境本地Controller或者StoreFront服务器出现故障时还继续可用?
假设卫星区域包含两个 Controller、多个 VDA 和两个 StoreFront 服务器。毫无疑问的是这是复原能力最强的区域类型，能够在 WAN 和其中一个本地 Controller或者StoreFront服务器同时出现故障时提供正常的运行保护。
三、Zones仅仅只是为了多区域统一管理？
上述我们说了Zone的概念以及新版本FMA架构下的Zones设计。在老的版本IMA架构下我们知道Zone还具有的另外一个功能是，当其中的某一个成员Zone内的XenApp服务器出现整体失效的情况下，我们还可以通过内置的负载均衡策略来到达这个区域的用户请求全部重定向到一个正常运行的Zone内，以达到区域基础架构服务器在全部失效的情况下桌面或者应用的高可用或者说是区域级别的高可用。
那么FMA架构下的Zones是不是也是按照这样的设计呢？答案是肯定的，但是其中的区别还是很大的。下面我们就来说说这个区别。
首先我们来说说所FMA架构下Zones是如何实现当其中的一个区域失效的情况下，将其重定向到别的区域的？在FMA架构下的Zones，其主区域中的 VDA 会注册到主区域中的 Controller。永远不会注册到卫星区域的站点中的 Controller。卫星区域中的 VDA 注册到本地 Controller 中（优先级）。这称为首选 Controller或者是默认Controller。如果本地 Controller 都不可用（例如，由于本地 Controller 无法接受更多 VDA 注册，或者本地 Controller 出现故障），VDA 将尝试注册到主区域中的 Controller。在这种情况下，VDA 会永远保持注册到主区域中的Controller，即使卫星区域中的 Controller 再次可用也是如此。同时，一个卫星区域中的 VDA 永远也不会尝试注册到另一个卫星站点中的 Controller。综上所述，我们就可以知道，如果卫星区域中的 Controller 出现故障，则会故障转移到另一个本地 Controller（如果有）。如果所有本地 Controller 都不可用，则会故障转移到主区域中的 Controller。通过这样的注册机制就保证了在卫星区域内本地Controller全部失效的情况下卫星区域的虚拟桌面或者虚拟应用还是可用的。一定程度上保证了多区域的高可用。
那么为什么在一个卫星区域出现本地Controller全部失效的情况下，其本地VDA不可以注册到其他的卫星区域呢？只能注册到主区域？原因是主区域中的 Controller 将保留所有区域的连接租用数据。卫星区域中的 Controller 保留各自的区域以及主区域的连接租用数据，但不保留任何其他卫星区域的数据。同时VDA所接受到的Controller的列表也只会包含卫星区域的本地Controller和主区域的本地Controller，不包含有其他卫星区域的本地Controller信息或者列表。那么我们可不可以让列表包含其他卫星区域的本地Controller列表呢？当然可以，但是在这种情况下，Citrix认为弊大于利，大家可以下去自己分析。
那么这上面所述的这种注册机制是我们在安装VDA的时候通过手动进行指定Controller地址的情况下完成的。如果我们采用的另外一种注册机制，即AD自动发现呢？如果为 Controller 的 VDA 发现启用了自动发现，并且在 VDA 安装期间指定了一个 Controller 地址列表，则会从该列表中随机选择一个 Controller 以完成初始注册（无论 Controller 驻留在哪个区域）。重新启动包含该 VDA 的计算机后，该 VDA 将启动，以便首先选择注册到其本地区域中的 Controller。那么VDA是如果知道哪个Controller是我的本地Controller呢？结论是Citrix里面有一个自动更新的功能，在我们启用了该功能之后，VDA 会收到更新后的列表，指出哪些属于本地的Controller，哪些是位于主区域中的Controller，这样就可以确定其能够注册到哪个 Controller 以及接受来自哪个 Controller 的连接。
四、Zones架构下许可证服务器部署方案优劣分析
上面我们说了这么多，都是基于许可证服务器部署在主区域做出的讨论，那么在这种架构模式下，许可证服务器的部署方案应该是有两种：
方案一：
这种部署方式只在主区域内部署，其余3个卫星区域不部署，共部署1台Citrix License服务器；每个区域内的XenApp/XenDestop和XenMobile服务器都通过×××与主区域的Citrix License服务通讯，Citrix License服务器可以不加入客户的域环境，便于冷备份。Citrix License服务器在出现故障时，Citrix环境都可以有长达30天的宽限期，可继续使用，所以备份可采取不备份或者使用冷备份方法。
方案特点：
1) Citrix都需要连接主区域的Citrix License服务器通讯，访问速度与×××专线繁忙程度相关；
2) 不需要每个区域都部署一台服务器，资源消耗较少；
3) 需要拆分Citrix License，部署快捷；
4) 从管理方面，管理员只需要维护一处Citrix License服务器，管理方便。
方案二：
这种部署方式需要在主区域与3个卫星区域各部署一台License，共部署4台Citrix License服务器。Citrix License数量拆分成4份，根据每区域用户数进行划分，分为4个License文件，每个区域内的Citrix服务器就近与本区域的Citrix License服务通讯；Citrix License服务器可以不加入客户的域环境，便于冷备份。
方案特点：
1) Citrix就近与区域内的Citrix License服务器通讯，速度有保证；
2) 需要每个区域都部署一台服务器，资源消耗较多；
3) 管理员需要管理多台License服务器和License文件。
五、卫星区域Controller与主区域数据库连接延迟
卫星区域的Controller直接与主区域的站点数据库SQL进行互动。我们假设这样一种情况，卫星区域的点数比较大，如果是超过了10000点，那么卫星区域的Controller与主区域的数据库进行互动时，他们之间的数据传输量是很多的。很多是多少呢？有无具体的值。为了体现这之间交互产生的巨大数据量，我们来说说这之间的数据传输量是如果计算的？
对其所需传递的数据库数据的增长量有一下几方面来进行计算：
Controller心跳服务信息
站点心跳服务信息
虚拟机工作心跳服务信息
Controller心跳服务信息：
每一台XD7 的Controller服务器都有10个WindowsService每隔30秒就进行一次心跳连接，以证明Controller服务器还活动并且正在运行。
每一个心跳是606 bytes，所以每一台Controller的心跳字节是6060bytes，一个小时是120个心跳，那么每一台Controller一个小时的心跳字节就是727200 bytes。
站点心跳服务信息：
有一个用户的登录请求等会话信息是由一台Controller来进行处理的，所以这种单独的站点服务所产生的字节不会生成双份，我们单独在这里进行计算；
Monitor: 6 site services= 384 header + 6 * 190 = 1524 bytes
Delegated Admin: 1 site service = 384 header+1* 190 = 574 bytes
Broker: 16 site services = 384 header + 16*190 = 3424 bytes
Hosting: 1 site service = 384 + 190 =574bytes
Desktop Update Manager: 1 site service = 384+190 = 574 bytes
Config Logging: 2 site services = 384 +2*190= 764 bytes
AD Identity: 1 site service = 384 + 190 =574bytes
由此我们可以计算出，一次Site Service请求消耗的心跳是8008 bytes，那么每一个小时就是960960 bytes，
虚拟机工作心跳服务信息：
对于XD7的2中模式（HSD和HVD）来说，每个虚拟机工作心跳是每5分钟进行一次，心跳的大小为1150bytes，每一个工作心跳一个小时大约为13800 bytes。
综上所述，我们来总结一下：
Controller心跳=Controller的数量乘于727200 bytes；
站点心跳=960960bytes；
虚拟机工作心跳=虚拟机的数量乘于 13800 bytes；
因此总数据的增量=“Controller心跳”+“站点心跳”+“虚拟机工作心跳”
例如，对于一个10000台VM的VDI环境中，有2的Controller，最低的增长将是：
Controller心跳=2*727200字节=1454400字节
站点心跳=960960字节
虚拟机工作心跳=10000*13800字节=138000000 字节
每小时总增长=1454400+960960+138000000=140415360字节或=134MB每小时
那么每天增长3.2GB。也就是说，如果我们的卫星区域内，部署了规模超过10000台VM的VDI，那么卫星区域的本地Controller每天将会将3.2GB的数据交付给主区域的数据库，这还只是单向的数据。如果在假设主区域的数据库向卫星区域返回的数据量，那么主区域和卫星区域之间的数据量级将是惊人的。如果主区域和卫星区域之间的链接是通过带宽有限的×××来进行的，那么势必影响环境的整体性能和用户体验。
基于这样的原因，Citrix针对于Zones架构下卫星区域有一些最佳实践。具体为根据主区域和卫星区域之间的链路带宽来决定卫星区域所部署的环境规模以及用户同时启动用户会话的数量。这些最佳实践是：
