在今天，Citrix发布了期待已久的XenApp/XenDesktop新版本7.12，在7.12中有许多值得期待的新功能（访问Citrix edocs查看7.12文档）。其中，本文将在此处解读新功能：Local Host Cache，简称LHC，中文名为本地主机缓存。虽然我们中的许多人都熟悉XenApp 6.5中的LHC功能，但那是基于IMA管理架构下的LHC。作为FMA管理架构下的LHC，和IMA管理架构下的LHC是不同的架构，下面我们就来说说这些关于LHC的内容。

一、IMA架构简述

IMA全称为Independent Management Architecture。中文名为：独立管理架构，其即是一个管理框架的简称，也是一种协议的的通信框架。因为IMA为服务器后端系统之间的通信提供了框架，也是MetaFrame Presentation Server（XenApp的前身，后续到XenApp6.5，其架构都沿用IMA）的管理基础。 IMA是一种集中式管理服务，包括定义和控制服务器场中产品执行的核心子系统集合。 IMA允许将服务器任意分组到不依赖于服务器的物理位置或服务器是否位于不同网络子网上的服务器场中。

IMA在服务器场中的所有服务器上运行。 IMA子系统通过默认TCP端口2512和2513通过IMA服务传递的消息通信。IMA服务在服务器启动时自动启动。 IMA服务可以通过操作系统服务实用程序手动启动或停止。

IMA可以定义为SERVICE（服务），PROTOCAL（协议）和DATASTORE（存储）：

IMA服务：IMA服务是XenApp的中枢神经系统。此服务负责与服务器相关的所有事务，包括跟踪用户，会话，应用程序，许可证和服务器负载。

IMA数据存储：存储服务器配置信息，如已发布的应用程序，总许可证，负载平衡配置，安全权限，管理员帐户，打印机配置等。IMA数据存储不是真正的关系数据库。它实际上是一个LDAP数据库。 每个服务器的IMA数据存储大小为1MB。

IMA协议：用于在XenApp服务器之间传递通信消息，包括服务器负载，当前用户连接以及正在使用的许可证等。IMA协议不会替代ICA协议。ICA协议是用于客户端到服务器的用户会话连接所用。 而IMA协议是将IMA服务执行诸如许可和服务器负载更新的状态信息提交到控制器中，也就是IMA协议是XenApp服务器到ZDC服务器之间的通信协议，所有的这些都在后端发生，也可以说是后端协议或幕后协议。

IMA使用的端口：

2512：用于服务器到服务器通信

2513：用于数据存储通信

MetaFrame XP是使用Citrix IMA架构的第一个Citrix产品。接下来我们根据XenDesktop 4（基于IMA架构）来看一下IMA架构下各个组件是如何工作的。

二、IMA架构下各个组件如何工作以及LHC起着什么作用？

在XenDesktop 4 版本中。DDC包括四种角色，DDC Master、XML、VDA和Slave。

• DDC Master主要用于数据收集（Data Collector）、同步和控制；

• DDC Slave是潜在的DDC Master（Potential Data Collector and Control），当DDC Master故障后，DDC Slave升为DDC Master。一般情况下，默认安装XenDesktop，首台DDC即为Farm Master。（注：由于XenDesktop5架构的改变，XenDesktop5已经没有必要来独立设置Master了。）

• DDC XML主要用于跟WI进行交互；

• DDC VDA主要用于跟虚拟机进行交互；在部署的时候XML和VDA都是合并在一起的，都是Member Server，他们都是通过IMA Service和DDC Master进行通信。

上述说明了在IMA架构下各个组件的运作，那么在IMA中LHC起着什么作用呢？首先我们从IMA架构下DDC主备数据同步机制开始说起。

DDC上的数据包括静态信息和动态信息：

• 静态配置信息会存储在DB数据库和LHC（Local Host Cache）中，包括Farm 配置信息，策略配置，用户和桌面组、桌面组和虚拟机的绑定关系等静态信息。

• 动态会话信息会存储在本地的LHC中，不会更新到DB中。LHC即Imalhc.mdb（本地的磁盘文件），是一个Access database。动态信息包括虚拟机的注册状态、Session状态，license利用率等动态信息。

DDC角色之间数据同步机制：

• 静态信息同步机制：DDC XML_VDA（Member Server）和DDC Master（Data Collector），通过IMA Service连接DB（Data Store），用于同步静态信息，如图中的黄色箭头所示；当配置信息发生改变时，例如用户在AppCenter)更改策略配置时，更新本地的LHC，然后更新到DB中，同时通过IMA Service本地的LHC信息同步到DDC Master，DDC Master将变化同步到其他的DDC XML_VDA中。

• 动态信息同步机制：DDC XML_VDA通过IMA Service将LHC信息同步到DDC Master，DDC Master将信息同步到其他的DDC XML_VDA。当注册到这台DDC XML_VDA的虚拟机的会话状态等动态信息发生改变时DDC XML_VDA更新本地的LHC信息，然后通过IMAService将LHC同步到DDC Master，DDC Master将变化同步到其他的DDC XML_VDA。如图蓝色箭头所示。

也就是说，在IMA架构下，LHC存储着DDC的所有数据信息（包括静态数据和动态数据）。其中，静态数据会写入到DB中，而动态数据不会写入到DB中，只存储于LHC中。然后LHC在所有的服务器之间进行同步。值得注意的是，这里的DB(Data Store)是指的IMA数据存储。IMA数据存储支持很多数据库,包括Access、SQL、Oracle以及DB2等数据库。也因此，XenApp6.x及以下产品版本的数据库总是比较小的，因为其存储的只是静态的数据信息，而数据量大的动态信息被留存于LHC中。同时，因为LHC中包括了DDC的所有数据信息（静态数据和动态数据），因此在DB出现故障的时候，并不会影响到用户的会话连接。除非在特殊情况下（将所有的服务器全部重启了，导致LHC数据全部清除）才会出现登录问题。

三、FMA架构简述以及针对高依赖数据库的解决方案

FMA管理架构(FlexCast Management Architecture)最早出现在Citrix XenDesktop 5.x系列的产品中，这种架构区别于传统IMA架构，更加的易于管理和便捷。FlexCast管理体系结构（FMA）是一种面向服务的架构，允许Citrix技术的互操作性和管理模块化。在FMA架构下，DDC不在有主备之分，所有的DDC角色都是主，共同分担、处理所有的负载会话。其后端的通信也不在基于IMA协议进行，而是基于Windows的WCF通信机制，将安装于客户端操作系统或者服务器端操作系统的VDA组件的信息传递到DDC服务器中。同时不在将VDA组件和XML组件集成在一起，将XML组件单独抽离出来，和DDC组件集成在一起，使其专门和WI或SF进行通信。FMA通过这种方式使得安装部署以及管理都变得十分便捷和灵活。

简要介绍完FMA之后，我们继续看看FMA架构下，不再将 IMA 数据存储用作存储配置信息的中央数据库，而是使用 Microsoft SQL Server 数据库作为配置信息和会话信息的数据存储。那么就意味着不管是静态的数据还是动态的数据，都会存储到Microsoft SQL Server 中。出于对 Microsoft SQL Server 的信赖，为确保在数据库不可用时能进行故障转移，解决方案本身必须使用 SQL 群集或镜像，或者将数据库作为虚拟机进行部署，并改用虚拟机监控程序的高可用性功能。

但是在这种情况下依然会导致数据库高可用失效的情况，网络问题和数据库本身中断可能会阻止 Controller（DDC）访问数据库，从而使用户无法连接到其应用程序或桌面。因此在XenApp/XenDesktop 7.6版本中，推出了连接租用的解决方案。通过连接租用功能，用户可以连接以及重新连接到其最近使用的应用程序和桌面，即使在站点数据库不可用时也能连接，补充了 SQL Server 高可用性最佳实践。启用连接租用后，在正常操作期间，每个 Controller 都会缓存用户最近使用的应用程序和桌面的连接（前提是数据库可用）。在每个 Controller 上生成的租用将上载到站点数据库，以便定期同步到站点上的其他 Controller。 除了租用外，每个 Controller 的缓存还会保存应用程序、桌面、图标和工作进程信息。 租用及相关信息存储在每个 Controller 的本地磁盘上。 如果数据库变为不可用，Controller 将进入租用连接模式，并在用户尝试从 StoreFront 连接或重新连接到最近使用的应用程序或桌面时“重播”缓存的操作。这个解决方案是其中一个劣势是这个保存的租用信息只会在 Controller 的本地磁盘上保留两个星期，如果超过了两个星期，那么所以的应用程序或桌面都将不在可用。注意，如果该场景下用户的会话没有一直处于活动状态或已断开连接，在两个星期之后就会被视为租用过期而被关掉会话。

因此基于上述提供的这些解决方案都有一定的劣势，这个时候将该FMA架构下的LHC出场了！鼓掌！！！

四、FMA架构下的LHC

LHC（本地主机缓存）是XenApp和XenDesktop中最全面的数据库高可用性功能。它是XenApp 7.6中引入的连接租赁功能的更强大的替代解决方案。

下面我们通过对FMA架构下LHC运行机制的了解来知晓LHC在FMA架构下起着什么作用？

LHC组件成功运行的依靠着FMA架构中很多的服务：

• Principal Broker Service

• Secondary Broker Service（High Availability Service）

• Citrix Config Synchronizer Service (CSS)

Broker Service充当XML服务和STA的安全票据以及许多资源的调度管理。当涉及LHC时，它被称为Principal Broker Service。在（主体）Broker Service旁边，我们有两个新的FMA服务：Config Synchronizer Service（CSS）和High Availability Service（也称为Secondary Broker Service）。如下图所示：

向以前一样，（主体）Broker Service接受StoreFront的连接请求，并与Controller站点数据库通信，然后代理连接，负责平衡负载等工作。之后，通过每两分钟对（主体）Broker Service进行一次检查以确定（主体）Broker Service的配置是否进行了更改或变化。这些更改或变化是由PowerShell/Citrix Studio操作（例如更改交付组属性）或系统操作（如计算机分配）启动的。上述配置更改包括但不限于发布图标，对交付组和计算机目录的更改，某些Citrix策略等。它不包括关于那个用户连接到哪个服务器（负载平衡），使用什么应用程序等当前状态下的信息。如果此时检测到了（主体）Broker Service的配置发生了更改，那么（主体）Broker Service就会使用Citrix Config Synchronizer Service (CSS)配置同步服务将数据（所有的）同步（复制）到Controller上的Secondary Broker Service（Citrix High Availability Service）。这种复制同步是将代理所有的配置全部复制同步，而不是仅仅只复制发生更改的那部分数据。Controller上的Secondary Broker Service（Citrix High Availability Service）得到这个数据之后，将数据导入到Controller上的Microsoft SQL Server Express LocalDB数据库中。Citrix Config Synchronizer Service (CSS)通过每次复制数据都将Secondary Broker Service（Citrix High Availability Service）的LocalDB数据库重新创建，以此来保证每次数据同步都与Controller站点数据库中的信息一致。因此在这种机制下，集群DDC的服务器每台之需要通过共享的Controller站点数据库，就可以保证集群DDC上的LHC数据是同步的。

根据上述的机制说明，我们明白：LHC是通过在Controller上的Microsoft SQL Server Express来构建一个数据库用户缓存Controller站点的数据信息，其信息和数据库完全一致。因此，在上述所说的场景（Controller与站点数据库断开连接）下，Controller本地还有一个LHC可以让用户继续登录使用应用程序或桌面。

那么在Controller与站点数据库断开连接的情况下，LHC是如果保证用户继续使用应用程序和桌面的呢？

在发生Controller与站点数据库断开连接的情况下，（主体）Broker Service将无法再与Controller站点数据库通信，因此该服务将会停止侦听StoreFront或VDA传送的请求信息，然后指示Secondary Broker Service（Citrix High Availability Service）开始侦听StoreFront或VDA传入的连接请求并相应地处理它们（比如这个时候用户有登录虚拟桌面的情况，那么该服务就会去LHC数据库里面查询该用户的应用程序以及桌面信息并返回）。当中断开始时，Secondary Broker Service（Citrix High Availability Service）没有当前VDA的注册数据，但是一旦VDA与其通信，就触发重新注册过程。在此过程中，Secondary Broker Service（Citrix High Availability Service）还会获取有关该VDA的当前会话信息（那些用户连接到这台机器）。这个过程中，（主体）Broker Service也不是什么事都不做了，而是继续监视和Controller站点数据库的通信。一旦和Controller站点数据库的通信恢复了，那么他就会立即叫停Secondary Broker Service（Citrix High Availability Service）的侦听行为，然后自己接管过来继续侦听。而这个时候，（主体）Broker Service也没有当前VDA的注册数据，只能等到下一次VDA与Broker Service的通信（该通信是VDA和DDC之间的心跳，默认每5分钟一次）时再次出发其注册过程，然后获取注册数据以及当前该VDA的当前会话信息。这个时候Secondary Broker Service（Citrix High Availability Service）就会删除剩余的VDA注册信息，并使用从CSS接收的配置更改恢复更新LocalDB数据库。如果正在复制数据来进行同步的时候，发送了网络事故或者别的中断原因，那么Secondary Broker Service（Citrix High Availability Service）就会丢弃掉着一次的复制同步数据，之保留最后成功的那次数据同步数据。

在DDC集群的情况下，CSS定期向Secondary Broker Service（Citrix High Availability Service）提供有关区域中所有控制器的信息。有了这些信息，每个Secondary Broker Service（Citrix High Availability Service）都知道所有对等的Secondary Broker Service（Citrix High Availability Service）是那些。这些Secondary Broker Service（Citrix High Availability Service）在单独的通道上彼此通信。他们使用他们正在运行的计算机的FQDN名称的字母顺序列表来确定（选择），如果发生中断，哪个Secondary Broker Service（Citrix High Availability Service）将负责区域中的代理操作。在中断期间，所有VDA向所选择的Secondary Broker Service（Citrix High Availability Service）重新注册。而区域中的其他Secondary Broker Service（Citrix High Availability Service）将主动拒绝该VDA的传入连接和注册请求。如果选择的Secondary Broker Service（Citrix High Availability Service）在中断期间失败，则选择另一个Secondary Broker Service（Citrix High Availability Service）接管，并且VDA将向新选择的Secondary Broker Service（Citrix High Availability Service）重新注册。

以上就是LHC的运行机制，因此我们明白：FMA架构下的LHC作用以及和IMA架构下的LHC是有所区别的。对于当前版本的LHC，请注意，LHC本地主机缓存仅支持服务器托管的应用程序和桌面以及静态桌面； 基于池的VDI桌面不受支持。

五、LHC的资源占用

服务器RAM的大小：

LocalDB服务需要使用大约1.2 GB的RAM（数据库缓存最多为1 GB，运行SQL Server Express LocalDB时为200 MB）。 如果中断持续时间延长（发生多次登录）（例如，12小时（10K用户）），高可用性服务可以使用高达1 GB的RAM。 这些内存要求是除了DDC正常RAM要求之外的，因此部署LHC可能需要增加RAM的大小。

请注意，如果对站点数据库也使用SQL Server Express安装，则服务器将有两个sqlserver.exe进程。

CPU核心和Socket配置

DDC的CPU配置，特别是SQL Server Express LocalDB可用的核心数量，直接影响本地主机缓存性能，甚至超过内存分配。 只有在数据库无法访问且高可用性服务处于活动状态时，才会在停机期间观察到此CPU开销。

虽然LocalDB可以使用多个内核（最多4个），但它仅限于一个Socket。 添加更多Socket不会提高性能（例如，具有4个Socket，每个Socket有1个核心）。 相反，Citrix建议使用具有多个内核的多个Socket。 在Citrix测试中，2x3（2个Socket，3个核心）配置提供比4x1和6x1配置更好的性能。

存储

当用户在中断期间访问资源时，LocalDB会迅速增长。例如，在以每秒10个登录速度运行的登录/注销测试期间，数据库每2-3分钟增加一个MB。 当正常操作恢复时，将重新创建本地数据库并回收所占空间。 但是，代理必须在安装LocalDB的驱动器上有足够的空间，以允许在中断期间数据库的增长。本地主机缓存在断电期间还会产生额外的I/O：每秒大约3 MB的写入以及几十万次读取操作。

性能

在中断期间，一个代理处理所有连接，因此在正常操作期间在多个DDC之间进行负载平衡的站点（或区域）中，选择的代理可能需要处理比正常情况下更多的请求。 因此，CPU需求将更高。 站点（区域）中的每个代理必须能够处理LocalDB和所有受影响的VDA所施加的额外负载，因为在中断期间选择的代理随时会更改。在此7.12版本中，在中断期间可以有效处理的VDA数量为5,000个。

在所有VDA向代理重新注册的期间，该代理可能不具有关于当前会话的完整信息。 因此，在该间隔期间的用户连接请求可能导致新会话被启动，即使重新连接到现有会话也是可能的。 这个间隔（当“新”代理在重新注册期间从所有VDA获取会话信息时）是不可避免的。 在中断启动时连接的会话在转换间隔期间不受影响，但新会话和会话重新连接受到影响。

六、LHC和连接租用功能重叠了，怎么置换

这里官方有个默认的表格，如下所示：

安装：在安装新的XenApp或XenDesktop后，默认情况下将禁用LHC，并启用连接租用。

升级：站点中的VDA数量会在升级后影响默认的LHC设置。 由于升级，连接租用设置不会更改。

如果您的站点少于5000个VDA：

在升级之前禁用连接租用，则会启用LHC。 连接租用保持禁用。

在升级之前启用了连接租用，则会禁用LHC。 连接租用保持启用。

如果您的站点有5000个或更多个VDA：

禁用LHC（无论连接租赁设置如何），并且连接租用保留与升级前相同的设置。

更多信息访问Citrix网站查看相关文档！

The End。

本文出自 “我拿流年乱了浮生” 博客，请务必保留此出处http://tasnrh.blog.51cto.com/4141731/1880882

XenApp/XenDesktop 7.12新功能LHC解读