ile Management的高可用性，我们考虑Active Directory(AD)和UPM存储空间的高可用性即可，当然还有他们之间传输的网路，这个层面就需要依靠网络设备去进行保障了。

对于Active Directory (AD)的高可用，采用本身Windows ActiveDirectory (AD)架构的高可用技术即可。

因此在项目设计的时候重点考虑点就是UPM存储空间的高可用性。对于这一点我们首先来看，UPM存储的空间提供的方式有多种：

1、基于Windows Server的文件服务器；

2、基于NAS文件存储设备提供的CIFS/NAS文件存储空间；

3、基于分布式存储多副本技术的文件存储空间。

当然还有很多种类型和方式可以提供UPM的存储空间。但是就现在实施项目来说，因为客户经费或着利旧等原因，最常使用的是基于WindowsServer的文件服务器和基于NAS存储设备提供的文件存储空间来存储我们的UPM。

下面我们就来说说这3点我们如果设计来达到UPM存储空间的高可用、负载均衡和灾难恢复。

基于NAS文件存储设备提供的CIFS/NAS文件存储空间，对于UPM的存储空间来说，其高可用性就主要在NAS文件设备上，比如NetApp的统一存储系统，本身其设备到主机服务器之间的链路就是多路径的，所以在网络部分就不需要我们再关心，而对于其提供的存储空间，由于只有一份存储在磁盘上，因此数据损坏就需要依靠其自身自带的一系列高级特×××来进行保障。对于灾难恢复来说，其只有备份一途。

基于分布式存储多副本技术的文件存储空间。这种类似的存储系统类似于Nutanix的NDFS分布式文件系统，其底层采用了目前分布式文件系统大多数采用的多副本技术来保证数据的高可用性，而不是传统的RAID技术。多副本技术相对于RAID技术来说，减少了数据恢复的时间和性能。我们知道在进行RAID5的数据恢复和写入等过程中，每一次对磁盘的写入数据都需要所有的磁盘进行参与，在写入数据之后所有的磁盘都会将所有的数据从新读取出来进行RX计算值的校验。而多副本技术就不会存在这样的问题，多副本技术的前提是承载存储空间的服务器是分布式架构的。一份数据存储在里面的多份数据的相互备份。每一个副本都会存在在不同的服务器上面以保证当其中的一台服务器坏了之后在其他的服务器之上还有这个数据的备份存在，以便于及时进行恢复。最棒的是比如我们的UPM存储在分布式文件系统上面，当我们的UPM数据损坏时，即其中一台服务器上的数据存储副本损坏，分布式文件系统有一个自动校验和自动恢复的技术可以帮助我们进行恢复。即在其他存在相同UPM数据的存储副本中将其数据重新复制到损坏的这台服务器上，将损坏的数据进行自动修复。这是基于底层数据保护，因此比较之前是NAS存储设备来说，使用分布式文件系统我的UPM空间本身就具备了高可用性和灾难恢复，当然还具有负载均衡，即请求到达分布式存储，分布式存在会将距离用户最近的服务器的副本给用户。

基于Windows Server的文件服务器来说，对于其高可用我们需要采用Windows本身提供的高可用技术和Citrix的UPM进行集成和融合来达到对于UPM存储空间高可用和灾难恢复的目的。

基于Windows Server的文件服务器应该是我们在项目中最为常见和实施的。对于WindowsServer文件服务器提供的UPM高可用，可以有以下几种方式：

  • 具有故障转移群集化功能的双节点Windows Server文件服务器；

  • DFS 命名空间；

  • DFS 多文件夹目标以及DFS 复制；

通过对Windows Server的文件服务器添加故障转移群集，我们可以提供基本的高可用性。此方案的要点在于将文件服务器转换为故障转移群集，以便文件夹目标托管在故障转移群集中的共享存储上，同时提供存储空间的文件服务器本身也因为故障转移集群而达到高可用性。这应该是现目前实施最常见的方式之一。但是这种方式只能实现基本高可用性，在比较大规模的环境下，一台Windows Server文件服务器构建可能性能无法满足需要。这个时候就需要设备不同的OU不同的桌面组来进行UPM存储空间的分配了。

如果我们采用Windows Server的另外一种高可用技术DFS 命名空间，我们为可以为UPM存储空间设置一个统一的命名空间，称之为\\UPM\Profile，此为命名空间的根目录。这个命名空间可以对应下面多台的Windows Server文件服务器。每个命名空间服务器都有文件夹与每个 ActiveDirectory 位置对应，而这些位置各自的服务器上都有与之对应的目标。但是就单独使用这个技术的话显然是不能够达到高可用和灾难恢复的需求的。使用这个技术DFS 命名空间我认为比较适宜的场景就是多区域部署的场景，比如现在最新XD7.7中出现的Zone的概念。比如北京为主站点，上海和广州为辅助站点，那么设置一个统一的DFS命名空间，在下面分别对应北京本地的文件服务器、上海本地的文件服务器和广州本地的文件服务器。可以使用如下排序规则对命名空间目标进行排序。当 DFS 命名空间决定了要使用的目标时，可以指定只选择本地站点中的目标。对于任何指定用户而言，只要确保每个桌面和每台服务器都保证属于同一个站点，这种方法即会非常有效。这样在北京的用户虽然使用的是统一的访问入口，但是其网路和文件服务器使用的北京本地的。这样可以显著的降低使用的带宽和提高性能。

多文件夹目标参照，参照是一列经过排序的对象，由用户设备依次尝试使用。参照专用于目标为只读对象的场景。目标之间不存在关联，因此，如果对配置文件采用此方法，可能会创建多个无法同步的配置文件。这个时候结合DFS复制的功能，来同步这些文件即可实现UPM文件的同步和复制，保证各UPM文件之间存在同步和关联性。

对于DFS复制来说，利用 DFS 复制功能可以在带宽有限的网络连接之间实现文件夹同步。表面看来，这可以解决使用多文件夹目标参照中遇到的问题，因为该功能可以将单个命名空间文件夹定义所参照的多个文件夹目标进行同步。但实际上，将文件夹作为目标添加到文件夹定义中时，可以将这些文件夹指定为属于复制组。

DFS支持两种形式的复制：

  • 单向复制（也称为主动-被动复制）专用于将关键数据备份到安全存储库中。这种复制可以帮助维护灾难恢复站点等。只要对参照禁用被动式目标，并仅在激活灾难恢复计划后才调用被动式目标，即可将单向复制与 Profile Management 结合使用。

  • 双向复制（也称为主动-主动复制）用于提供对全局共享数据的本地读写访问权限。此方案不需要使用即时复制功能。共享数据可能会频繁修改。

但是在这样使用的过程中会存在一个问题，就是有多个UPM文件，同时都在进行读写，就好比一个文件同时提供给多个人读写类似，我怎么保证我这个文件，即A写入和和B写入的不覆盖不冲突。这时候就需要一个锁机制，上面我提到的分布式文件系统中也会存在这样的锁机制。但是在Windows Server的DFS功能中，是不正常锁机制的，所以我们没法使用双向复制，即只能一对一进行复制，那么这样的化，其实在还是只能同时读写一个UPM文件。就是说，有多个UPM文件，这些UPM文件都是A用户的UPM文件，使用多文件夹目标参照加DFS复制功能实现，这个时候用户对UPM进行使用更新，通常在会话开始、会话结束以及会话进行期间发生（如果启用了活动写回功能）。这个时候每个UPM文件都会进行相互之间的读写，就上面说的双向复制。由于 DFS 复制不支持分布式文件锁定，因此 Profile Management 只能选择一个目标作为UPM的写入文件。这样双向复制（主动-主动复制）和UPM就无法结合使用。只能使用单向复制（主动-被动复制），即这么多个UPM文件用户其实只能同时读写一个，只能作为灾难恢复系统的一部分来进行使用。Citrix Consulting的测试结果是这样的部署情况只能保证启动一个会话，且已禁用活动写回。

那么要实现真正的Profile Management的灾难恢复，就需要使用我们上述提到这些技术进行综合起来进行：

  • DFS 命名空间。在此场景中，首选基于域的命名空间服务器，因为这些服务器允许 DR 站点拥有自己的命名空间服务器。（独立的命名空间服务器无法复制，但能够托管在故障转移群集上。）

  • 多文件夹目标和 DFS 复制。为每个UPM存储空间至少提供两个目标，但正常操作中只启用其中一个。设置单向 DFS 复制以确保禁用的目标（在 DR 站点中）保持最新。

  • 托管各个文件夹目标的故障转移群集。

如果构建两个数据中心的XD灾难恢复，即可使用以上提到的技术构建Profile Management的灾难恢复(DR) 。如果以此配置了 DR 计划，则 DR 站点的UPM存储空间为最新的UPM空间，其中包含从主站点UPM中复制的更改。对于每个文件夹，必须禁用主站点上的文件夹目标，启用 DR 站点上的文件夹目标。当灾难发生时，通过对AD更新，命名空间服务器即可准确找到 DR 文件夹目标，DR 站点即可随时供 Profile Management 使用，而且不需要更新 Profile Management 配置。