直接切入正题吧,至于什么是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的会话。下图揭示了这一机制:

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

  上图中,我们仔细看的话就会发现,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。

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

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

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

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

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

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

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

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

Citrix XenDesktop 中VDA向DDC注册机制解析_支持机制_05

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

Citrix XenDesktop 中VDA向DDC注册机制解析_支持机制_06

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

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

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

Citrix XenDesktop 中VDA向DDC注册机制解析_支持机制_07

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”

Citrix XenDesktop 中VDA向DDC注册机制解析_支持机制_08

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

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

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

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

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

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

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

 在使用了上述步骤建立起基于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。

Citrix XenDesktop 中VDA向DDC注册机制解析_支持机制_13

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!