确定正确的灾难恢复方案
组织必须准备正确的灾难恢复保护，以限制数据中心故障或区域性中断的影响。 设置正确的保护策略主要取决于哪些各种故障方案可能会影响 Azure 虚拟桌面的功能。
目标和指标
灾难恢复过程需要协调所采取的每个程序，以使组织恢复全面运作。 将这些程序集合在一起的是存在共同的、明确定义的服务水平目标。 灾难恢复 (DR) 服务应包含以下指标：
- 恢复点目标 （RPO）：必须根据被视为已恢复的备份资产，将最小允许的数据量传递回服务的客户端。 反之，这一数额可视为可接受的最大数据损失，表示为从 100 减去的百分比。
- 恢复时间目标 （RTO）：允许进行还原过程的最长时间段，也可以将其视为组织愿意承受的停机时间的度量值。
- 保留期： 需要刷新和替换备份集之前保留的最长允许时间段。
RPO 和 RTO 可能被视为相互平衡，以便客户可能决定允许更长的恢复时间来获得更高的恢复点。 如果恢复时间是客户由于可用带宽或停机风险而导致的问题，则客户可能无法实现高 RPO。
本单元的其余部分探讨了三种不同的故障方案，以及如何为 Azure 虚拟桌面准备业务连续性和灾难恢复 （BCDR）：
- 方案 1：数据、元数据或资源的本地损坏
- 方案 2：Azure 区域中可用性区域故障的单个数据中心
- 方案 3：Azure 区域中断
注意
若要详细了解如何保护 Azure 虚拟桌面的各个组件，请参阅 "了解详细信息>本模块的"摘要"单元中的部分。
方案 1：数据、元数据或资源的本地损坏
假设 Azure 虚拟桌面环境受到会话主机故障或 FSLogix 配置文件损坏的影响。 在这种情况下，最常见的恢复方法是从备份中恢复配置文件或重建会话主机。 本单元回顾了这些方法如何适用于每个 Azure 虚拟桌面环境组件。
Azure 虚拟桌面服务
Azure 虚拟桌面服务仍然完全正常运行，不受这些故障类型的影响。 Microsoft 负责在所提供的服务水平协议 (SLA) 范围内使一切恢复正常运行。
AD DS 和 Microsoft Entra 域服务
Active Directory 域控制器是 Azure 虚拟桌面的关键组件，必须始终可访问。 若要确保故障不会影响其功能，请确保已创建多个域控制器。 如果 Azure 虚拟机中有域控制器，请确保已将它们配置为位于同一可用性集中。 如果域控制器是作为本地计算机运行的，则应该设计本地网络和 Azure 虚拟网络之间的连接，并提供冗余。 使用 Azure ExpressRoute 来管理冗余的路径和连接。 备份 Active Directory 系统状态并根据需要还原。 如果使用 Microsoft Entra 域服务，Microsoft 负责维护冗余域控制器并帮助保护它们免受计划外故障的影响。
主机池
主机池在正常运行过程中可能变得不可用。 主机池向用户提供 Azure 虚拟桌面和应用程序。 它们是从桌面映像设置的，因此如果发生故障且桌面映像可用，则可以重新创建它们。 还可以为通过 Azure 虚拟桌面使用的应用程序使用单独的主机池。 也应该考虑对这个主机池采取类似的灾难恢复方法。
虚拟网络
虚拟网络是不受此类故障影响的托管服务。 Azure 虚拟网络提供了一个私有的 IP 区块，可以在那里部署所有的资源进行私有连接，然后可以在边界内保护这些资源。 因此，如果资源在单个数据中心发生本地故障，则虚拟网络永远不会关闭或发生中断。
FSLogix 配置文件和 MSIX 应用附加
根据选择的 FSLogix 存储技术，可以为 Azure 文件共享和 Azure NetApp 文件快照配置 Azure 备份。 另外，可以使用备份服务来保护服务器虚拟机上的文件和文件夹。
图像
在 Azure 虚拟桌面环境的正常维护过程中，可能经常对桌面映像进行修改。 应维护映像的备份，以便在发生任何损坏时快速恢复映像。
方案 2：Azure 区域中可用性区域故障的单个数据中心
Azure 区域是部署在延迟定义的外围内并通过专用区域低延迟网络连接的一组数据中心。 如果 Azure 区域的数据中心或区域发生故障，则 Azure 虚拟桌面的 BCDR 应包括以下各节中列出的建议。
Azure 虚拟桌面服务
Azure 虚拟桌面服务仍然完全正常工作，不受此类故障的影响。 Microsoft 负责在所提供的服务水平协议内使一切恢复正常并运行。
AD DS 和 Microsoft Entra 域服务
为了避免单一数据中心的故障，在一个可用区至少部署两个域控制器。 如果使用 Microsoft Entra 域服务，Microsoft 将在单独的可用性区域中管理租户的两个域控制器（如果受该区域支持）。
主机池
对于主机池虚拟机的复原能力，可以使用虚拟机的可用性区域部署 Azure 虚拟桌面主机池。 可以将主机池中的虚拟机分布在不同的数据中心，但仍在同一区域内。
虚拟网络
虚拟网络是托管服务，不受此故障类型的影响。 应该确保可靠的资源总是配置成适当的网络连接。 例如，使用基本负载均衡器可能会受到此类故障的影响，因为它不支持区域可用性。
FSLogix 配置文件和 MSIX 应用附加
将Azure 文件存储与高级区域冗余存储配合使用，以利用对可用性区域的支持。 在这种情况下，如果数据中心发生故障，FSLogix 配置文件和 MSIX 应用附加的 VHDs 仍然可用。
图像
这种故障不会影响映像，因为它们在另一个区域中可用。
方案 3：Azure 区域中断
整个 Azure 区域发生故障的可能性很大，而且很少见。 但也应该做好准备，以防发生这种故障。 请考虑实施以下建议，为 Azure 虚拟桌面实施 BCDR。
Azure 虚拟桌面服务
Azure 虚拟桌面服务仍然完全正常运行，不受此类故障的影响。 Microsoft 负责在所提供的服务水平协议内使一切恢复正常并运行。
AD DS 和 Microsoft Entra 域服务
若要为此类故障做好准备，可以扩展托管域，为每个 Microsoft Entra 租户设置多个副本。 副本集可以添加到支持 Microsoft Entra 域服务的任何 Azure 区域中的任何对等互连虚拟网络。
如果使用本地域控制器，则需要使用 VPN、ExpressRoute 或虚拟广域网 (虚拟 WAN) 来配置与新区域中虚拟网络的连接。 如果使用 Microsoft Entra 域服务，则可以在另一个区域中创建其他副本集。 托管新副本集的其他区域中的虚拟网络必须能够与托管 Microsoft Entra 域服务主集的网络通信。 建议使用虚拟网络之间的对等互连在副本集之间进行站点内复制。
主机池
可以在主动-主动和主动-被动配置中部署 Azure 虚拟桌面主机池：
主动-主动：使用主动-主动配置，单个主机池可以具有来自多个区域的 VM。 必须结合云缓存功能，在多个区域的存储中主动复制用户的 FSLogix 配置文件。 对于 MSIX 应用附加，请在其他区域中的其他文件共享上使用另一个副本。 每个区域的虚拟机都应该包含云计算缓存注册表，以指定位置。 此外，必须配置组策略，使其优先考虑本地存储位置。 从用户的角度来看，这种 Azure 虚拟桌面部署提供了最高的效率。 这是因为如果出现故障，剩余区域的用户可以继续使用服务，而不必再次登录。 然而，这种配置的成本更高，部署起来更复杂，而且没有对性能进行优化。
主动-被动：对于主动-被动配置，可以使用Azure Site Recovery通过域控制器复制次要区域中的 VM。 如果使用 Azure Site Recovery，则无需手动注册虚拟机。 相反，辅助 VM 中的 Azure 虚拟桌面代理会自动使用最新的安全令牌连接到离它最近的服务实例。 这可确保会话主机自动加入主机池，并且用户只需重新连接即可访问其 VM。 对于这种配置，也可以在故障转移区域创建一个二级主机池 (称为 热备)，并关闭所有资源。 然后，可以使用 Azure Site Recovery 中的恢复计划来开启主机池，并创建一个协调的流程。 还需要在故障转移区域创建一个新的应用程序组，并将用户分配给他们。
虚拟网络
区域故障会影响虚拟网络和在虚拟网络中部署的服务。 必须在辅助区域规划一个虚拟网络。 可以手动创建虚拟网络，然后使用与主网络的对等互连对其进行设置。 还可以使用 Azure Site Recovery 在故障转移区域中设置虚拟网络并保留主网络的设置。
在与本地网络连接的 Azure 虚拟桌面中，应该在辅助区域配置与本地网络连接的虚拟网络。
FSLogix 配置文件和 MSIX 应用附加
可以使用 Azure NetApp 文件作为 FSXlogix 配置文件和 MSIX 应用附加的存储选项，因为它们支持跨区域复制。 具有标准性能的 Azure 文件也支持跨区域复制。 可以配置 FSLogix 代理来支持多个配置文件位置，这有助于确保在出现故障时的可用性。 如果主位置失败，FSLogix 代理将作为 VM Azure Site Recovery 的一部分进行复制。 代理会自动尝试使用指向次要区域的配置文件路径。
对于“主动-主动”场景，如果 RTO/RTA 小于一天，我们建议使用 FSLogix 配置文件来使用云缓存。 云缓存是 FSLogix 的一项功能，必须专门启用和配置。 它允许你使用多个远程位置，这些位置都在用户会话期间不断更新。
图像
每次修改主桌面映像后，都应在次要区域中复制映像。 可以使用 Azure 计算库跨区域共享自定义映像。 在主区域故障期间，可以使用克隆的桌面映像作为创建主机池的来源。
应用依赖项
依赖于主要区域中可用资源的应用程序需要辅助位置中的相同资源。 例如，如果某些应用程序与部署在一个区域中的 SQL 后端连接，请务必在辅助位置复制 SQL。 对于 Azure 虚拟机上的 SQL Server，可以使用 Azure Site Recovery。 对于 SQL 即平台即服务 （PaaS） 解决方案，可以使用活动异地复制或自动故障转移组。 应该把这些资源包括在整个 BCDR 计划中。 此外，应该包括一个可以在保护计划中模拟应用程序的依赖性的 Azure 站点恢复计划。