Azure 虚拟桌面是在 Microsoft Azure 中运行的综合性桌面和应用虚拟化服务。 虚拟桌面有助于实现安全的远程桌面体验，从而帮助组织增强业务复原能力。 它提供简化的管理、Windows 10 和 11 企业版多会话和针对 Microsoft 365 企业应用版的优化。 借助虚拟桌面，只需几分钟时间，即可在 Azure 上部署和缩放 Windows 桌面和应用，并提供集成的安全性和合规性功能来帮助确保应用和数据的安全。
随着继续使用虚拟桌面为组织启用远程工作，你必须要了解其灾难恢复 (DR) 功能和最佳做法。 这些做法可增强跨区域的可靠性，以帮助保持数据安全并让员工高效工作。 本文提供有关业务连续性和灾难恢复 (BCDR) 先决条件、部署步骤和最佳做法的注意事项。 你将了解选项、策略和体系结构指导。 本文档中的内容使你能够准备成功的 BCDR 计划，并可以帮助你在计划内和计划外的停机事件期间为业务提供更大的复原能力。
有几种类型的灾难和中断，其中每一种都会产生不同的影响。 深入讨论了针对本地和区域范围内的事件的复原能力和恢复，包括在不同的远程 Azure 区域中恢复服务。 此类恢复被称为异地灾难恢复。 构建虚拟桌面体系结构以实现复原能力和可用性，这一点至关重要。 你应提供最大的本地复原能力，以减少故障事件的影响。 此复原能力还可减少关于执行恢复过程的要求。 本文还将介绍高可用性和最佳做法。
虚拟桌面控制平面
虚拟桌面为其控制平面提供 BCDR，以便在中断期间保留客户元数据。 当某个区域发生服务中断时，服务基础结构组件会故障转移到次要位置，并继续正常运行。 你仍可以访问与服务相关的元数据，并且用户仍可以连接到可用的主机。 如果租户环境或主机仍保持可访问状态，最终用户连接将保持联机状态。 Azure 虚拟桌面的数据位置与主机池会话主机虚拟机 (VM) 部署的位置不同。 可在其中一个受支持的区域中查找虚拟桌面元数据，然后在其他位置部署 VM。 无需执行其他操作。
目标和范围
本指南的目标是：
- 确保最大的可用性、复原能力和异地灾难恢复功能，同时将重要的选定用户数据的数据丢失降至最低。
- 将恢复时间降至最短。
这些目标也称为恢复点目标 (RPO) 和恢复时间目标 (RTO)。
建议的解决方案可提供本地高可用性、防范单个可用性区域故障和整个 Azure 区域故障。 它依赖于不同或次要 Azure 区域中的冗余部署来恢复服务。 虽然这仍是一种很好的做法，但虚拟桌面和用于构建 BCDR 的技术不需要将 Azure 区域配对。 如果网络延迟允许，主要和次要位置可以是任何 Azure 区域组合。
若要减少单个可用性区域故障的影响，请使用复原能力来提升高可用性：
- 在计算层，将虚拟桌面会话主机分布在不同的可用性区域中。
- 在存储层，请尽量使用区域复原能力。
- 在网络层，部署区域可复原 Azure ExpressRoute 和虚拟专用网络 (VPN) 网关。
- 对于每个依赖项，查看单个区域中断产生的影响并计划缓解措施。 例如，跨多个区域部署由虚拟桌面用户访问的 Active Directory 域控制器和其他外部资源。
根据所使用的可用性区域数量，评估过度预配会话主机的数量，以补偿其中一个区域的损失。 例如，即使有 (n-1) 个可用区域，你也可以确保良好的用户体验和性能。
注意
Azure 可用性区域是一项可提高复原能力的高可用性功能。 但是，请不要将其视为能够防范区域范围内灾难的灾难恢复解决方案。
由于某些区域可能存在类型、复制选项、服务功能和可用性限制的组合，因此请使用来自 FSLogix 的云缓存组件而不是特定的存储复制机制。
本文未介绍 OneDrive。 有关冗余和高可用性的详细信息，请参阅 Microsoft 365 中的 SharePoint 和 OneDrive 数据复原能力。
本文的其余部分介绍针对两种不同虚拟桌面主机池类型的解决方案。 它还提供了一些观察结果，以便可以将此体系结构与其他解决方案进行比较：
- 个人：在此类主机池中，用户拥有永久分配的会话主机，它永远不会更改。 由于它是个人的，因此，此 VM 可以存储用户数据。 假定使用复制和备份技术来保存和保护状态。
- 共用：直接通过桌面应用程序组或使用远程应用为用户暂时分配池中可用的其中一个会话主机 VM。 VM 是无状态的，用户数据和配置文件存储在外部存储或 OneDrive 中。
讨论了成本影响，但主要目标是在减少数据丢失的情况下提供高效的异地灾难恢复部署。 有关更多 BCDR 详细信息，请参阅以下资源：
先决条件
部署核心基础结构，并确保它在主要和次要 Azure 区域中可用。 有关网络拓扑的指导，可使用 Azure 云采用框架网络拓扑和连接模型：
在这两种模型中，将主要虚拟桌面主机池和次要灾难恢复环境部署在不同的分支虚拟网络中，并将它们连接到同一区域中的每个中心中。 将一个中心置于主要位置，将另一个中心置于次要位置，然后在两者之间建立连接。
中心最终提供与本地资源、防火墙服务、标识资源（如 Active Directory 域控制器）和管理资源（如 Log Analytics）的混合连接。
当故障转移到次要位置时，你应考虑任何业务线应用程序和依赖项资源的可用性。
主动-主动与主动-被动
如果不同用户集的 BCDR 要求不同，Microsoft 建议使用具有不同配置的多个主机池。 例如，具有任务关键型应用程序的用户可能会分配具有异地灾难恢复功能的完全冗余主机池。 但是，开发和测试用户可以使用完全没有灾难恢复功能的单独主机池。
对于每个单一虚拟桌面主机池，可将 BCDR 策略基于主动-主动或主动-被动模型。 在此上下文中，假设一个地理位置的同一组用户由特定的主机池提供服务。
主动-主动
对于主要区域中的每个主机池，需在次要区域中部署第二个主机池。
此配置可提供几乎为零的 RTO，但 RPO 会产生额外的费用。
不需要管理员干预或故障转移。 在正常操作过程中，辅助主机池为用户提供虚拟桌面资源。
每个主机池都有自己的存储帐户，用于持久存储用户配置文件。
你应基于用户的物理位置和可用的连接来评估延迟。 对于某些 Azure 区域（例如西欧和北欧），在访问主要区域或次要区域时，差异可以忽略不计。 可使用 Azure 虚拟桌面体验评估器工具验证此场景。
将用户分配到主要和辅助主机池中的不同应用程序组，例如桌面和远程应用。 在本例中，他们将在其虚拟桌面客户端源中看到重复的条目。 为避免混淆，请使用单独的虚拟桌面工作区，并使用反映每个资源用途的明确名称和标签。 告知用户关于这些资源的使用情况。
如果需要用于管理 FSLogix 配置文件和 Office 容器的存储，请使用云缓存来确保 RPO 几乎为零。
- 为避免配置文件冲突，不要允许用户同时访问这两个主机池。
- 由于此场景的主动-主动性质，你应让用户了解如何以正确的方式使用这些资源。
主动-被动
- 与主动-主动一样，对于主要区域中的每个主机池，需在次要区域中部署第二个主机池。
- 与主要区域相比，次要区域中可用的计算资源量将减少，具体取决于可用预算。 你可以使用自动缩放来提供更多的计算容量，但它需要更多的时间，并且不能保证 Azure 容量。
- 与主动-主动方法相比，此配置可提供更高的 RTO，但成本更低。
- 如果发生 Azure 服务中断，则需要管理员干预才能执行故障转移过程。 辅助主机池通常不会向用户提供对虚拟桌面资源的访问权限。
- 每个主机池都有自己的存储帐户，用于持久存储用户配置文件。
- 只有在发生 Azure 服务中断时，使用具有最佳延迟和性能的虚拟桌面服务的用户才会受到影响。 你应使用 Azure 虚拟桌面体验评估器工具验证此场景。 对于次要灾难恢复环境，即使性能下降，性能也应该是可以接受的。
- 仅将用户分配到一组应用程序组，例如桌面和远程应用。 在正常操作过程中，这些应用位于主要主机池中。 在服务中断期间和故障转移之后，会将用户分配到辅助主机池中的应用程序组。 用户的虚拟桌面客户端源中不显示重复的条目，他们可以使用同一工作区，并且一切内容对他们来说都是透明的。
- 如果需要用于管理 FSLogix 配置文件和 Office 容器的存储，请使用云缓存来确保 RPO 几乎为零。
- 为避免配置文件冲突，不要允许用户同时访问这两个主机池。 由于此场景是主动-被动场景，因此管理员可在应用程序组级别强制实施此行为。 只有在故障转移过程之后，用户才能访问辅助主机池中的每个应用程序组。 撤销了对主要主机池应用程序组的访问权限，并重新分配给辅助主机池中的应用程序组。
- 需对所有应用程序组执行故障转移，否则，在不同主机池中使用不同应用程序组的用户如果管理不当，可能会导致配置文件冲突。
- 用户的特定子集可以选择性地故障转移到辅助主机池，并提供有限的主动-主动行为和测试故障转移功能。 也可以对特定的应用程序组进行故障转移，但应让用户知道不要同时使用来自不同主机池的资源。
对于特定情况，可以搭配使用位于不同区域的会话主机来创建单个主机池。 此解决方案的好处在于，如果你有单个主机池，则无需为桌面和远程应用重复定义和分配。 可惜的是，此解决方案有几个缺点。
- 对于共用主机池，无法强制用户使用同一区域中的会话主机。
- 当连接到远程区域中的会话主机时，用户可能会遇到更高的延迟和更低性能。
- 如果需要用户配置文件存储，则需要复杂的配置以管理主要和次要区域中会话主机的分配。
- 可使用排出模式暂时禁用对位于次要区域中的会话主机的访问权限。 但此方法会带来更多的复杂性、管理开销和更低的资源利用率。
- 可在次要区域中使会话主机处于脱机状态，但这会带来更多的复杂性和管理开销。
注意事项和建议
常规
要使用多个主机池和 FSLogix 云缓存机制部署主动-主动或主动-被动配置，可以在同一工作区或其他工作区中创建主机池，具体取决于模型。 此方法要求保持一致和更新，并使两个主机池保持同步，同时处于相同的配置级别。 除了用于次要灾难恢复区域的新主机池之外，还需要执行以下操作：
- 为新主机池创建新的不同应用程序组和相关应用程序。
- 撤销对主要主机池的用户分配，然后在故障转移过程中手动将其重新分配给新主机池。
- 本文档未涵盖任何配置文件恢复。
- 云缓存（主动/被动） 包含在本文档中，但使用相同的主机池实现。
- 本文档的其余部分介绍了云缓存（主动/主动）。
虚拟桌面资源存在一些限制。 有关详细信息，请参阅 Azure 虚拟桌面服务限制。
对于诊断和监视，请对主要主机池和辅助主机池使用同一 Log Analytics 工作区。
计算
对于在主要和次要灾难恢复区域中部署这两个主机池，你应使用 Azure 可用性区域并将 VM 机群分布在所有可用性区域中。 如果本地区域中没有可用性区域，则可以使用 Azure 可用性集。
用于次要灾难恢复区域中的主机池部署的黄金映像应与用于主要区域中的相同。 你应将映像存储在 Azure Compute Gallery 中，并在主要和次要位置配置多个映像副本。 每个映像副本可以支持最大数量的 VM 的并行部署，并且可能需要多个 VM，具体取决于所需的部署批量大小。 有关详细信息，请参阅在 Azure Compute Gallery 中存储和共享映像。
Azure Compute Gallery 不是全球资源，因此建议在次要区域中至少有一个辅助库。 在主要区域中创建库、VM 映像定义和 VM 映像版本后，还应在次要区域中创建相同的三个对象。 创建 VM 映像版本时，有可能复制在主要区域中创建的 VM 映像版本。 为此，必须从次要区域指定在主要区域中使用的库、VM 映像定义和 VM 映像版本，Azure 将复制映像并创建本地 VM 映像版本。 可以使用 Azure 门户或 Azure CLI 命令执行此操作，如下所示：
并非次要灾难恢复位置中的所有会话主机 VM 都必须始终处于活动状态并正常运行。 必须首先创建足够数量的 VM，然后使用自动缩放机制，例如缩放计划。 通过这些机制，可使大多数计算资源保持脱机或解除分配状态，以降低成本。
也可以仅在需要时使用自动化在次要区域中创建会话主机。 此方法可优化成本，但根据所使用的机制，可能需要更长的 RTO。 此方法不允许在没有新部署的情况下进行故障转移测试，也不允许对特定的用户组进行选择性的故障转移。
重要
必须每隔 90 天至少打开一次每个会话主机 VM 几个小时，以刷新连接到虚拟桌面控制平面所需的虚拟桌面令牌。 还应定期应用安全修补程序和应用程序更新。
- 如果次要区域中的会话主机处于脱机或已解除分配状态，这并不能保证在主要区域范围内发生灾难时容量可用。 如果在需要时按需部署新会话并使用 Site Recovery，则它也适用。 如果满足以下条件，则可以保证计算容量：
- 会话主机在次要区域中保持活动状态。
- 使用新的 Azure 功能按需容量预留。
注意
Azure 虚拟机预留实例不提供容量保证，但可与按需容量预留集成以降低成本。
- 由于使用云缓存，你应执行以下操作：
- 你应对会话主机 VM OS 托管磁盘使用高级层。
- 你应将云缓存移动到临时 VM 驱动器并使用本地固态硬盘 (SSD) 存储。
存储
在本指南中，为每个虚拟桌面主机池使用至少两个独立的存储帐户。 一个用于 FSLogix 配置文件容器，另一个用于 Office 容器数据。 还需要一个用于 MSIX 的存储帐户。 请注意以下事项：
- 可以使用 Azure 文件存储共享和 Azure NetApp 文件作为存储替代方案。
- Azure 文件存储共享可通过使用区域复制的存储复原能力选项来提供区域复原能力（如果它在该区域中可用）。
- 在以下情况下，不能使用异地冗余存储功能：
- 需要非配对区域。 针对异地冗余存储的区域对是固定的，不能更改。
- 使用的是高级层。
- 与 FSLogix 云缓存机制相比，RPO 和 RTO 更高。
- 在生产环境中测试故障转移和故障回复并不容易。
- Azure NetApp 文件需要其他注意事项：
- 区域冗余尚不可用。 如果复原能力要求比性能更重要，请使用 Azure 文件存储共享。
- Azure NetApp 文件具有区域性，即客户可以决定在哪个（单个）Azure 可用性区域进行分配。
- 可以在卷级别建立跨区域复制。 复制是异步（RPO>0）的，需要手动故障转移（RTO>0）。 在使用此功能之前，建议查看本文中的要求和注意事项。
- 现在可以将 Azure NetApp 文件与区域冗余 VPN 和 ExpressRoute 网关结合使用（如果使用可能用于实现网络复原能力的标准网络功能）。 有关详细信息，请参阅受支持的网络拓扑。
- Azure 虚拟 WAN 现已受支持，但需要 Azure NetApp 文件标准网络功能。 有关详细信息，请参阅受支持的网络拓扑。
- Azure NetApp 文件具有跨区域复制机制，以下注意事项适用：
- 它并未在所有区域推出。
- 区域对是固定的。
- 故障转移不是透明的，故障回复需要重新配置存储。
- 限制
- Azure 文件存储共享和 Azure NetApp 文件存储帐户和卷的大小、每秒输入/输出操作 (IOPS)、带宽 MBps 都存在限制。 如有必要，可通过 FSLogix 中的每组设置对虚拟桌面中的同一主机池使用多个限制。 但是，此配置需要更多的计划和配置。
用于 MSIX 应用程序包的存储帐户应不同于配置文件和 Office 容器的其他帐户。 可使用以下异地灾难恢复选项：
- 主要区域中一个启用了异地冗余存储的存储帐户
- 次要区域是固定的。 如果存在存储帐户故障转移，则此选项不适合本地访问。
- 两个独立的存储帐户，一个位于主要区域，另一个位于次要区域（建议）
- 至少对主要区域使用区域冗余存储。
- 每个区域中的每个主机池都可以低延迟访问 MSIX 包的本地存储。
- 在两个位置复制 MSIX 包两次，并在两个主机池中注册该包两次。 将用户分配到应用程序组两次。
FSLogix
Microsoft 建议使用以下 FSLogix 配置和功能：
如果配置文件容器内容需要单独的 BCDR 管理，并且与 Office 容器相比有不同的要求，则应该对它们进行拆分。
- Office 容器仅缓存了发生灾难时可从源重新生成或重新填充的内容。 使用 Office 容器，可能不需要保留备份，从而降低成本。
- 使用不同的存储帐户时，只能在配置文件容器上启用备份。 或者，必须具有不同的设置，例如保持期、使用的存储、频率和 RTO/RPO。
云缓存是一个 FSLogix 组件，可在其中指定多个配置文件存储位置并异步复制配置文件数据，所有这些都不依赖于任何基础存储复制机制。 如果第一个存储位置发生故障或无法访问，云缓存将自动进行故障转移以使用次要存储位置，并有效地添加复原能力层。 使用云缓存在主要和次要区域的不同存储帐户之间复制配置文件和 Office 容器。
必须在会话主机 VM 注册表中启用云缓存两次，一次用于配置文件容器，一次用于 Office 容器。 可以不为 Office 容器启用云缓存，但如果存在故障转移和故障回复，则不启用该组件可能会导致主要和次要灾难恢复区域之间的数据错位。 在生产环境中使用该组件之前，请仔细测试此场景。
云缓存与配置文件拆分和每组设置兼容。 每组需要仔细设计和计划活动目录组和成员身份。 必须确保每个用户都完全属于一个组，并且该组用于授予对主机池的访问权限。
与主要区域中的设置相比，在注册表中为次要灾难恢复区域中的主机池指定的 CCDLocations 参数将按顺序还原。 有关详细信息，请参阅教程：配置云缓存以将配置文件容器或 Office 容器重定向到多个提供程序。
以下示例显示云缓存配置和相关的注册表项：
主要区域 = 北欧
配置文件容器存储帐户 URI = \northeustg1\profiles
- 注册表项路径 = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles
- CCDLocations 值 = type=smb,connectionString=\northeustg1\profiles;type=smb,connectionString=\westeustg1\profiles
注意
如果之前下载了 FSLogix 模板，则可以通过 Active Directory 组策略管理控制台完成相同的配置。 有关如何为 FSLogix 设置组策略对象的更多详细信息，请参阅使用 FSLogix 组策略模板文件指南。
Office 容器存储帐户 URI = \northeustg2\odcf
注册表项路径 = HKEY_LOCAL_MACHINE > SOFTWARE >Policy > FSLogix > ODFC
CCDLocations 值 = type=smb,connectionString=\northeustg2\odfc;type=smb,connectionString=\westeustg2\odfc
注意
在上面的屏幕截图中，为简洁起见，并未报告所有建议的针对 FSLogix 和云缓存的注册表项。 有关详细信息，请参阅 FSLogix 配置示例。
次要区域 = 西欧
- 配置文件容器存储帐户 URI = \westeustg1\profiles
- 注册表项路径 = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles
- CCDLocations 值 = type=smb,connectionString=\westeustg1\profiles;type=smb,connectionString=\northeustg1\profiles
- Office 容器存储帐户 URI = \westeustg2\odcf
- 注册表项路径 = HKEY_LOCAL_MACHINE > SOFTWARE >Policy > FSLogix > ODFC
- CCDLocations 值 = type=smb,connectionString=\westeustg2\odfc;type=smb,connectionString=\northeustg2\odfc
云缓存复制
云缓存配置和复制机制可在减少数据丢失的情况下保证在不同区域之间复制配置文件数据。 由于同一用户配置文件只能由一个进程以 ReadWrite 模式打开，因此应避免并发访问，用户不应同时打开与两个主机池的连接。
下载此体系结构的 Visio 文件。
数据流
虚拟桌面用户启动虚拟桌面客户端，然后打开分配给主要区域主机池的已发布桌面或远程应用应用程序。
FSLogix 检索用户配置文件和 Office 容器，然后从位于主要区域的存储帐户装载基础存储 VHD/X。
同时，云缓存组件会初始化主要区域中和次要区域中的文件之间的复制。 对于此过程，主要区域中的云缓存会获取对这些文件的独占读写锁。
同一个虚拟桌面用户现在想要启动在次要区域主机池上分配的另一个已发布应用程序。
在次要区域中的虚拟桌面会话主机上运行的 FSLogix 组件尝试从本地存储帐户装载用户配置文件 VHD/X 文件。 但是装载失败，因为这些文件由在主要区域中的虚拟桌面会话主机上运行的云缓存组件锁定。
在默认的 FSLogix 和云缓存配置中，用户无法登录，并且在 FSLogix 诊断日志中跟踪错误 ERROR_LOCK_VIOLATION 33 (0x21)。
标识
虚拟桌面最重要的依赖项之一是用户标识的可用性。 若要从会话主机访问虚拟桌面和远程应用，用户需要能够进行身份验证。 Microsoft Entra ID 是 Microsoft 的集中式云标识服务，可以实现此功能。 始终使用 Microsoft Entra ID 对 Azure 虚拟桌面的用户进行身份验证。 可将会话主机加入同一个 Microsoft Entra 租户，或者使用 Active Directory 域服务或 Microsoft Entra 域服务（Microsoft Entra 域服务）将其加入 Active Directory 域，这样你就可以获得灵活的配置选项。
Microsoft Entra ID
- 这是一项具有高可用性的全球多区域、可复原服务。 作为虚拟桌面 BCDR 计划的一部分，在此上下文中不需要其他操作。
Active Directory 域服务
- 若要使 Active Directory 域服务具有复原能力和高可用性，即使在某个区域范围内发生灾难，你也应该在主要 Azure 区域中部署至少两个域控制器 (DC)。 如果可能的话，这些域控制器应位于不同的可用性区域中，并且你应确保使用次要区域中的基础结构进行正确复制，并最终在本地进行。 你应在次要区域中至少创建一个具有全局目录和 DNS 角色的域控制器。 有关详细信息，请参阅在 Azure 虚拟网络中部署 AD DS。
Microsoft Entra Connect
如果将 Microsoft Entra ID 与 Active Directory 域服务结合使用，然后使用 Microsoft Entra Connect 在 Active Directory 域服务和 Microsoft Entra ID 之间同步用户标识数据，则应考虑此服务的复原能力和恢复，以防范永久性灾难。
可通过在次要区域安装第二个服务实例并启用暂存模式来提供高可用性和灾难恢复。
如果具有恢复，管理员需要通过将辅助实例退出暂存模式来提升辅助实例。 它们必须遵循与将服务器置于暂存模式相同的过程。 需要 Microsoft Entra 全局管理员凭据才能执行此配置。
Microsoft Entra 域服务
体系结构关系图
个人主机池
下载此体系结构的 Visio 文件。
共用主机池
下载此体系结构的 Visio 文件。
故障转移和故障回复
个人主机池场景
注意
本部分仅介绍主动-被动模型，主动-主动不需要任何故障转移或管理员干预。
针对个人主机池进行故障转移和故障回复是不同的，因为配置文件和 Office 容器没有使用云缓存和外部存储。 你仍可使用 FSLogix 技术将会话主机中的数据保存到容器中。 灾难恢复区域中没有辅助主机池，因此无需创建更多用于复制和对齐的工作区和虚拟桌面资源。 可使用 Site Recovery 复制会话主机 VM。
可在多个不同的场景中使用 Site Recovery。 对于虚拟桌面，请使用使用 Azure Site Recovery 执行 Azure 到 Azure 的灾难恢复体系结构。
以下注意事项和建议适用：
- Site Recovery 故障转移不是自动的，管理员必须使用 Azure 门户或 Powershell/API 触发它。
- 可使用 PowerShell 编写脚本并自动执行整个 Site Recovery 配置和操作。
- Site Recovery 在其服务级别协议 (SLA) 中声明了 RTO。 大多数情况下，Site Recovery 可以在几分钟内对 VM 进行故障转移。
- 可以将 Site Recovery 与 Azure 备份结合使用。 有关详细信息，请参阅支持将 Site Recovery 与 Azure 备份结合使用。
- 必须在 VM 级别启用 Site Recovery，因为虚拟桌面门户体验中不提供直接集成。 同样，也必须在单个 VM 级别触发故障转移和故障回复。
- Site Recovery 在单独的子网中为通用 Azure VM 提供测试故障转移功能。 不要将此功能用于虚拟桌面 VM，因为两个相同的虚拟桌面会话主机将同时调用虚拟桌面控制平面。
- 在复制过程中，Site Recovery 不维护虚拟机扩展。 如果为虚拟桌面会话主机 VM 启用了任何自定义扩展，则必须在故障转移或故障回复后重新启用该扩展。 只有在创建会话主机 VM 时才使用虚拟桌面内置扩展 joindomain 和 Microsoft.PowerShell.DSC。 在进行第一次故障转移后，这些扩展将会丢失。
- 请务必查看 Azure 区域之间 Azure VM 灾难恢复的支持对照表，并检查有关 Site Recovery Azure 到 Azure 灾难恢复方案的要求、限制和兼容性对照表，尤其是受支持的 OS 版本。
- 将 VM 从一个区域故障转移到另一个区域后，VM 将在目标灾难恢复区域中启动，但处于不受保护状态。 可以进行故障回复，但用户必须重新保护次要区域中的 VM，然后启用复制回主要区域。
- 在故障转移和故障回复过程中执行定期测试。 然后，根据特定的虚拟桌面环境记录步骤和恢复操作的确切列表。
注意
Site Recovery 现已与按需容量预留相集成。 通过此集成，可将容量预留的强大功能与 Site Recovery 结合使用，以在灾难恢复区域中保留计算容量并保证故障转移。 当为受保护的 VM 分配容量预留组时，Site Recovery 会将 VM 故障转移到该组。
共用主机池场景
主动-主动灾难恢复模型的理想特征之一是，如果出现服务中断，则无需管理员干预即可恢复服务。 只有在主动-被动体系结构中才需要故障转移过程。
在主动-被动模型中，次要灾难恢复区域应处于空闲状态，其配置的资源最少且可用。 配置应与主要区域保持一致。 如果进行故障转移，会同时将所有用户重新分配到辅助灾难恢复主机池中远程应用的所有桌面和应用程序组。
可以进行主动-主动模型和部分故障转移。 如果主机池仅用于提供桌面和应用程序组，则可将用户划分到多个不重叠的 Active Directory 组，并将该组重新分配给主要或辅助灾难恢复主机池中的桌面和应用程序组。 用户不应同时访问两个主机池。 如果有多个应用程序组和应用程序，用于分配用户的用户组可能会重叠。 在这种情况下，很难实施主动-主动策略。 每当用户在主要主机池中启动远程应用时，FSLogix 都会在会话主机 VM 上加载用户配置文件。 如果尝试在辅助主机池上执行相同操作，这可能会导致基础配置文件磁盘发生冲突。
警告
默认情况下，FSLogix 注册表设置将禁止从多个会话对同一用户配置文件进行并发访问。 在此 BCDR 方案中，不应更改此行为，并将注册表项 ProfileType 的值保留为 0。
下面是初始情况和配置假设：
- 主要区域和次要灾难恢复区域中的主机池在配置过程中保持一致，包括云缓存。
- 在主机池中，DAG1 桌面以及 APPG2 和 APPG3 远程应用应用程序组都将提供给用户。
- 在主要区域的主机池中，Active Directory 用户组 GRP1、GRP2 和 GRP3 用于将用户分配给 DAG1、APPG2 和 APPG3。 这些组可能具有重叠的用户成员身份，但由于此处的模型使用具有完全故障转移的主动-被动模型，因此这无关紧要。
以下步骤描述在进行计划内或计划外灾难恢复之后何时发生故障转移。
- 在主要主机池中，删除由组 GRP1、GRP2 和 GRP3 对应用程序组 DAG1、APPG2 和 APPG3 的用户分配。
- 所有连接的用户都与主要主机池强制断开连接。
- 在配置了相同应用程序组的辅助主机池中，必须使用组 GRP1、GRP2 和 GRP3 向用户授予对 DAG1、APPG2 和 APPG3 的访问权限。
- 查看并调整次要区域中主机池的容量。 在此处，建议依靠自动缩放计划来自动启动会话主机。 也可以手动启动必要的资源。
故障回复步骤和流程类似，你可以多次执行整个过程。 云缓存和配置存储帐户可确保复制配置文件和 Office 容器数据。 在进行故障回复之前，请确保主机池配置和计算资源都将恢复。 对于存储部分，如果主要区域中存在数据丢失，云缓存将从次要区域存储中复制配置文件和 Office 容器数据。
也可以在不影响生产环境的情况下通过一些配置更改来实现测试故障转移计划。
- 在 Active Directory 中创建一些用于生产环境的新用户帐户。
- 创建名为 GRP-TEST 的新 Active Directory 组并分配用户。
- 使用 GRP-TEST 组分配对 DAG1、APPG2 和 APPG3 的访问权限。
- 为 GRP-TEST 组中的用户提供关于测试应用程序的指导。
- 使用 GRP-TEST 组测试故障转移过程，以删除对主要主机池的访问权限并授予对辅助灾难恢复池的访问权限。
重要建议：
- 使用 PowerShell、Azure CLI 或其他可用 API 或工具自动执行故障转移过程。
- 定期测试整个故障转移和故障回复过程。
- 定期进行配置对齐检查，确保主要灾难区域和次要灾难区域中的主机池同步。
备份
本指南中的假设是配置文件容器和 Office 容器之间存在配置文件拆分和数据分离情况。 FSLogix 允许此配置和使用单独的存储帐户。 在单独的存储帐户中，可使用不同的备份策略。
对于 Office 容器，如果内容仅表示可以从 Office 365 等联机数据存储中重新生成的缓存数据，则无需备份数据。
如果需要备份 Office 容器数据，则可使用成本较低的存储或不同的备份频率和保持期。
对于个人主机池类型，你应在会话主机 VM 级别执行备份。 此方法仅在本地存储数据时适用。
如果使用 OneDrive 和已知文件夹重定向，则不需要将数据保存在容器内部。
注意
本文和方案不考虑 OneDrive 备份。
除非有其他要求，否则主要区域中的存储备份就足够了。 通常不使用灾难恢复环境的备份。
对于 Azure 文件存储共享，请使用 Azure 备份。
- 对于保管库复原能力类型，如果不需要异地或区域备份存储，请使用区域冗余存储。 如果需要这些备份，请使用异地冗余存储。
Azure NetApp 文件提供了自己的备份解决方案。 此解决方案目前为预览版，它可提供区域冗余存储复原能力。
- 请务必检查该区域的功能可用性，以及要求和限制。
如果无法轻松重新生成应用程序包存储库，则还应将用于 MSIX 的单独存储帐户包含在备份中。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Ben Martin Baur | 云解决方案架构师
- Igor Pagliai | FastTrack for Azure (FTA) 首席工程师
其他参与者：
- Nelson Del Villar | 云解决方案架构师，Azure Core 基础结构
- Jason Martinez | 技术文档撰写人