Citrix XenDesktop 中VDA向DDC注册机制解析

Posted 2020-06-17

直接切入正题吧，至于什么是VDA？什么是DDC之类的我就不用做过多介绍了。

众所周知用户如果需要使用虚拟桌面，那么必须将虚拟桌面部署在DDC的交付组中并将虚拟桌面交付给用户、而且虚拟桌面在DDC中是已注册的状态。这其中，VDA向DDC的注册过程是比较有讲究的。

我们把VDA注册也叫做DDC发现，这个过程指的是VDA在通过特定的机制寻找到DDC并与DDC建立通信的过程。

Citrix的XenDesktop中，VDA注册或者是DDC发现主要有3中注册类型：

• Soft / Hard Registration

• Registry base registration

• AD base registration

 

一、Soft / Hard registration(软/硬注册)机制

  Softregistration(软注册)机制首次出现在XenDesktop3.0的版本中，它的目的只有一个，就是解决延迟注册的问题。那么这个延迟指的是什么呢？如果了解XenDesktop运行机制的工程师都清楚，VDA在开机之后启动服务，首先获取IP地址，然后VDA的服务会根据相应的配置信息查找DDC并发起注册请求。如果这个时候该VDA还没有加入到交付组(以前版本叫桌面组)，那么显然这个VDA是不能够被注册的，理所应当被DDC拒绝掉。但是当我们把这个VDA添加到了交付组呢？这个时候VDA发起到DDC的注册显然就会被DDC接受。但是会存在延迟的情况。因为VDA在向DDC发起注册请求被拒绝之后，是按照设计好的时间点定时的向DDC再次发起注册请求的。在XenDesktop 3.0的版本以及之前的版本，默认为10分钟，在XenDesktop4.x到5.x的时候变更为5分钟。这个过程无疑就是延迟的过程。这几分钟时间是我们无法进行手动更改的，只有等待下一次时间点VDA主动向DDC发起注册请求了。 Citrix为了是注册的过程中，在这一步加快注册的的等待时间，因而开发集成了这样软注册机制。这个机制可以在为将VDA加入桌面组或着交付组之前，只要VDA通过配置信息找到了DDC并建立了通信，那么这个时候DDC也接受来自VDA的注册行为，但是这个注册行为并不包含所有的注册行为，只有部分注册操作完成。比如没有将VDA配置发送（XML）过来或状态监测没有启动，这种注册状态下不允许会话启动或着管理该VDA的会话。下图揭示了这一机制：

  上图中，我们仔细看的话就会发现，03的这台VDA在Studio中的状态并没有显示，但在下面的详细信息中，我们就会发现在注册的这一栏，注册的状态是已注册的状态。

  那么什么是硬注册机制呢？

  促使软注册机制到硬注册机制的诱因是该VDA被加入到桌面组或着交付组。

这个时候我们将03这台VDA加入到桌面组或着交付组，在Studio中查看这个VDA时，其显示状态就会变成已注册，这个时候就是全部注册信息都已注册完毕，Citrix将这个有软注册到硬注册的过程称之为硬注册，即全部注册信息已经全部注册完毕的意思。

那么我们上面说了，有了这个软注册机制之后，可以节省VDA向DDC注册的时间，但是实质上呢好处还不止这个，有了这个软注册机制，可以避免不必要的网络流量，即VDA在像DDC申请注册的时候被DDC拒绝，如果我们一直不将该VDA加入到桌面组的话，VDA一直会定时向DDC发送注册请求。同时，在没有这个机制之前，VDA向DDC申请注册被拒绝之后，是会在是事件日志里面留下错误日志记录的，软注册机制当然也避免这个问题。

 

 

二、Registry base registration(注册表注册)机制

注册表注册机制是VDA向DDC注册的默认方法，即通过VDA的特定注册表键值找到DDC。这个注册表的键值里面是DDC的FQDN，VDA需要通过DNS服务解析出DDC的IP地址并与之进行通信。这个键值是我们在安装VDA的时候，填写的DDC的FQDN。

其注册表具体的路径和键值如下图所示：

这个注册表键值在注册表中有2个地方，64系统的可能有所区别。

VDA通过注册表注册机制向DDC注册的流程具体如下：

1、当虚拟机启动电源，获取到了IP地址之后，上面的Citrix Desktop Service服务启动；

2、Citrix Desktop Service首先查找本地注册表HKLM\Software\Policies\Citrix\VirtualDesktopAgent\ListOfDDCs和HKLM\Software\Citrix\VirtualDesktopAgent\ListOfDDCs，查询注册表ListOfDDCs项以获取DDC的地址。如果在这个注册表键值中没有DDC的地址或者查询不到，那么该服务会在本地文件系统中的c:\Personality.ini文件中的[VdaData]项里面去查找‘ListOfDDCs’的键值一获取DDC的地址。

3、VDA拿到ListOfDDCs键值后，会同时向AD检验DDC的FQDN是否合法，验证通过后，AD将合法的DDC对应的SID返回给VDA，VDA根据AD的检验结果，得出最终可用于注册的DDC FQDN，若存在多个合法值，则随机选择其中一个DDC，调用其IRegistrar接口向其发起注册请求。VDA和DDC服务之间通过WCF进行通信。VDA发起尝试注册的请求包后，如果没有收到DDC的回应包，即超时。VDA会在超时后的7和10秒之间选择一个启动新的注册请求并尝试注册。

4、DDC收到VDA的注册请求后，首先向AD检验VDA的FQDN是否合法。验证通过后，AD将VDA对应的SID返回给DDC，DDC与VDA机器完成互信。然后DDC brokerservice会接受或拒绝注册的请求，并将通知返回VDA。

5、如果VDA注册失败，然后等待超时；VDA将无限期地重复这个过程，直到注册成功。

6、如果注册成功，注册信息（例如Win7-pooled01与XD01注册）更新到站点数据库。

7、注册完成后，VDA将收到来自Broker Service注册成功的通知。该通知还包括用于维护DDC与VDA连接的心跳值。(默认的心跳值是30秒）

8、VDA收到这些通知之后开始使用‘ping‘包到DDC以检测连接心跳。这样双方之间就通过心跳来保持通信以确认对方都在活着，如果DDC在30秒之后还没有收到来自VDA的‘ping’包，那么DDC就会认为VDA已经处于关闭状态了。

9、心跳的失败意味着VDA关闭，那么DDC将取消VDA的注册和清理在Site数据库中的信息。

10、如果DDC发生故障时，DDC将无法回复VDA的ping包。‘ping‘包是一个返回值的API调用，因此，返回值从DDC-> VDA上每一个ping包都会存在。如果DDC关闭之后，WCF框架将无法运作，其API调用就将无法进行。如是单台DDC的情况下，这样的场景足以触发VDA再次重新启动整个注册过程。因为在生产环境中我们都需要搭建2台DDC用于保证高可用性。每个VDA其实上向DDC注册都只是向其中的一个DDC进行注册，而不会存在一个VDA同时向2个DDC同时注册的情况。因此在这种情况下，集群DDC不至于再次触发VDA重新启动整个注册流程，而在第二台DDC上，这些VDA是处于软注册状态，但DDC集群之间的心跳检测到第一台DDC以及关闭之后，该台活着的DDC就会将这些VDA的软注册全部升级为硬注册，即全部接管这些VDA，我感觉这些工作机制都和存储的双控制器类似呢？

11、如果VDA向DDC注册时不是第一次注册，那么DDC的Broker Service会向数据库检查VDA是否归属桌面组：DDC检查VDA是否归属于自身Site的某个桌面组下，数据库返回查询信息。如果是归属于某个桌面组或交付组下，即下发配置，DDC向VDA下发Policy配置，其中包括Site、交付组等配置信息。同时Broker Service更新Site下各DDC间更新虚拟机注册状态为“Ready”。

 

 

三、AD base registration(AD注册)机制

AD注册机制区别于本地计算机注册表注册的形式，其区别类似于Windows中工作组合域的关系。要让VDA使用AD注册机制来向DDC进行发起注册申请，我们需要做以下配置：

1. 必须首先在XD管理站点中的DDC上运行PS的脚本PS ScriptSet-ADControllerDiscovery，该脚本在安装路径%ProgramFiles%\Citrix\Broker\Service\SetupScripts下。使用Set-ADControllerDiscovery脚本使用AD DN（专有名称）来标识AD对象。比如：Set-ADControllerDiscovery –on –existingOuDn “OU=XD56DDCs,DC=Readiness, DC=APAC”

1. 该脚本会在AD中创建所有指定OU所需的AD对象（OU，SCP等）。因此SCP（服务连接点），每个包含的信息，包括DDC的FQDN，这将是由VDA可用于发现DDC。当运行PS的脚本后，我们需要重新启动所有的DDC的服务，以便VDA安装向导能够发现XD站点。

1. 然后运行VDA安装向导，在选择DDC地址的时候，现在来自AD，允许你从下拉列表中选择XD的站点。

1. 该向导将在VDA中创建一个的FarmGUID值，这是用来调用识别XD站点的。该注册表键值路径存在于HKLM\Software\Citrix\VirtualDesktopAgent\FarmGUID

 在使用了上述步骤建立起基于AD注册的环境后，基于AD的注册机制，其VDA通过AD注册机制向DDC注册的流程具体如下：

1、当虚拟机启动电源，获取到了IP地址之后，上面的Citrix Desktop Service服务启动；

2、它查找本地注册表HKLM\Software\Policies\Citrix\VirtualDesktopAgent\FarmGUID和HKLM\Software\Citrix\VirtualDesktopAgent\FarmGUID以获取信息。

3、VDA连接到AD域控制器，以验证该FarmGUID是否有效，并得到了存在于该OU AD的SCP（服务连接点）的名单。SCP的各自包含的信息，包括与DDC的FQDN。

1、VDA从DDC的列表中随机选择一个进行发起注册。之后的过程和上面我所述的注册表注册过程无任何区别，因此我就不在这里在复述一遍了。

现在，让我们来看看一些注册过程中的关键步骤

服务连接点(ServiceConnection Points)发布,详细参见微软官方网址：

http://msdn.microsoft.com/en-us/library/ms677638(v=vs.85).aspx

Active Directory架构定义了serviceConnectionPoint（SCP）对象类很容易让一个服务发布目录中的特定服务的数据。该服务的客户端使用在SCP中的数据来定位，连接和验证服务的一个实例。

SCP对象的更多详细信息：

http://msdn.microsoft.com/en-us/library/bb427286(v=vs.85).aspx

VDA注册DDC集群的更多说明：

在XenDesktop 5.5和更高版本中，虚拟桌面代理可以被配置为注册到DDC的一个子集中，并且允许通过在ListOfDDCs注册表值中将DDC FQDN进行分组，这两组DDC集群之间的会话通过的DDC的另一个子集来促成（即XML broker）。例如，如果一个VDA应该注册是的DDC1或DDC2，这需要在注册表值中填写，但DDC3和DDC4是XML broker的情况下，注册表键值是这样填写的HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Citrix\VirtualDesktopAgent -REG_SZ: “ListOfDDCs” = ”(DDC1.local.domain DDC2.local.domain)(DDC3.local.domain DDC4.local.domain)”

在此配置中，第一组中的DDC的用于VDA注册，除非该组中的所有的DDC不可用，那么VDA才会尝试注册到第二组中XML broker进行使用。

如果XML broker在不同的域环境下，ListOfSIDs可用于指定受信任XML broker的SID并使用空格分隔列表。如果一个DDC的SID添加到ListOfSIDs，所有XMLbroker的SID也必须添加到列表中。例如，如果你想使用DDC.DomainA登记，而使用DDC.DomainB作为XML broker，DDC.DomainA应在ListOfDDCs，两个DDC的域的SID应加到ListOfSIDs注册表

(HKLM\Software\WOW6432Node\Citrix\VirtualDesktopAgentREG_SZ ListOfSIDs = “域的SID空格分隔列表”)

如果你们对这个感兴趣，可以参阅http://support.citrix.com/article/CTX132536。

 

The End!

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