你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 虚拟桌面灾难恢复概念

  • 项目

近年来，Azure 虚拟桌面作为远程和混合工作解决方案得到了极大的发展。 由于现在有很多用户远程工作，因此组织需要部署速度快和成本低的解决方案。 用户还需要有一个保证可用性和复原能力的远程工作环境，以便在发生灾难时也能访问虚拟机。 本文档介绍了我们建议的灾难恢复计划用以保持组织正常运行。

为了防止系统中断或停机，Azure 虚拟桌面部署中的每个系统和组件都必须是容错的。 容错是在另一个 Azure 区域中具有重复的配置或系统，该配置在服务中断期间会接管主配置。 此次要配置或系统减少了本地化服务中断的影响。 有多种方式可以设置容错，但本文将重点介绍 Azure 中当前可用的方法。

Azure 虚拟桌面基础结构

为了找出哪些区域需要容错，我们首先需要知道谁负责维护每个区域。 可以将 Azure 虚拟桌面服务中的职责划分为两个方面：Microsoft 托管和客户管理。 主机池、应用程序组和工作区等元数据由 Microsoft 控制。 元数据始终可用，客户不需要额外的设置来复制主机池数据或配置。 我们设计了网关基础结构，可将人员连接到其会话主机，使其成为 Microsoft 托管的全局的、高复原性服务。 同时，客户管理区域涉及 Azure 虚拟桌面中使用的虚拟机 (VM) ，以及客户部署特有的设置和配置。 下表更清楚地说明了哪些区域由哪一方管理。

由 Microsoft 管理 由客户管理
负载均衡器 网络
会话代理 会话主机
网关 存储
诊断 用户配置文件数据
云标识平台 标识

在本文中，我们将重点介绍客户管理的组件，因为这些设置可以自行配置。

灾难恢复基础知识

在本部分中，我们将讨论可以保护数据的操作和设计原则，并防止在发生小中断或全面灾难后进行大量的数据恢复工作。 对于较小的服务中断，遵循某些较小的步骤可以帮助防止它们变成更大的灾难。 让我们了解一些基本术语，帮助你开始设置灾难恢复计划。

当设计灾难恢复计划时，应牢记以下三点：

  • 高可用性：分布基础设施，这样较小的、更本地化的中断不会影响整个部署。 设计时将 HA 考虑在内，可以最大程度地减少中断 影响，并避免进行全面的灾难恢复。
  • 业务连续性：组织如何在任何规模的中断期间保持运营。
  • 灾难恢复：全面中断后恢复操作的过程。

Azure 具有许多内置的免费功能，可在多个级别提供高可用性。 第一项功能是可用性集，它将 VM 分布到 Azure 中的不同容错域和更新域。 接下来是可用性区域，这些区域是物理隔离和地理分散的数据中心组，可以减少中断的影响。 最后，跨多个 Azure 区域分布会话主机可提供更多的地理分散性，从而进一步减少服务中断影响。 这三项功能在 Azure 虚拟桌面中提供一定级别的保护，应仔细考虑它们以及任何成本影响。

基本上，我们建议为 Azure 虚拟桌面使用灾难恢复策略，以跨区域中的多个可用性区域部署资源。 如果需要更多保护，还可以跨多个配对的 Azure 区域部署资源。

主动-被动和主动-主动部署

你应该记住的其他事项是主动-被动和主动-主动计划之间的差异。 主动-被动计划是指一个区域的一组资源处于主动状态，而另一组资源在需要时才打开（被动）。 如果活动区域因紧急情况而脱机，则组织可以通过启用区域并移动其所有用户来切换到被动区域。

另一个选项是主动-主动部署，可在此同时使用这两组基础结构。 虽然某些用户可能会受到中断的影响，但影响仅限于发生故障区域中的用户。 其他区域中的用户仍处于联机状态，不会受到影响，恢复仅限于受影响区域中的用户重新连接到正常运行的活动区域。 主动-主动部署可以采用多种形式，包括：

  • 如果其中一个区域发生故障，则在每个区域中超量预配基础结构以容纳受影响的用户。 此方法的潜在缺点是，维护额外资源的成本更高。
  • 在两个活动区域中都有额外的会话主机，但在不需要它们的时候解除分配，从而降低成本。
  • 仅在灾难恢复期间预配新基础结构，并允许受影响的用户连接到新预配的会话主机。 此方法需要使用基础结构即代码工具进行常规测试，以便在灾难发生期间尽快部署新基础结构。

我们建议使用的灾难恢复方法有：

  • 跨多个可用性区域配置和部署 Azure 资源。

  • 在主动-主动或主动-被动配置中跨多个区域配置和部署 Azure 资源。 这些配置通常位于共享主机池中。

  • 对于具有专用 VM 的个人主机池，使用 Azure Site Recovery 将 VM 复制到另一个区域。

  • 在次要区域中配置单独的“灾难恢复”主机池。 在灾难期间，可以将用户切换到次要区域。

在下面的部分中，我们将更详细地介绍用于共享和个人主机池的两种主要方法。

共享主机池的灾难恢复

在本部分中，我们将讨论使用主动-被动方法的共享 (或“共用”) 主机池。 主动-被动方法是指将现有资源划分为主要区域和次要区域。 通常，组织会在主要 (或“主动”) 区域中执行所有工作，但在发生灾难期间，切换到次要 (或“被动”) 区域需要关闭主要区域中的资源（如果可以这样做，这取决于中断的范围）并打开次要区域中的资源。

下图显示了次要区域中具有冗余基础结构的部署示例。 “冗余”表示原始基础结构的副本存在于另一个区域，并且在部署中是标准的，用于为所有组件提供复原能力。 单个 Microsoft Entra ID 下存在两个区域：美国西部和美国东部。 每个区域包括两台运行多会话操作系统 (OS) 的会话主机、运行 Microsoft Entra Connect 的服务器、Active Directory 域控制器、用于 FSLogix 配置文件的 Azure 文件存储高级版文件共享、存储帐户以及虚拟网络 (VNET)。 在主要区域（美国西部）所有资源都已打开。 在次要区域（美国东部）中，主机池中的会话主机处于关闭或排出模式，而 Microsoft Entra Connect 服务器则处于暂存模式。 这两个区域中的两个 VNET 都通过对等互连进行连接。

A diagram of a deployment using the recommended shared host pool disaster recovery strategy described in the previous paragraph.

在大多数情况下，如果某个组件出现故障或主要区域不可用，则客户需要执行的唯一操作是在次要区域中打开主机或删除排空模式以启用最终用户连接。 此方案侧重于减少故障时间。 但是，基于冗余的灾难恢复计划可能会花费更多成本，因为必须维护次要区域中的这些额外组件。

此计划的潜在优势如下：

  • 从灾难中恢复的时间更少。 例如，你将在预配、配置、集成和验证新部署的资源上花费更少的时间。
  • 无需使用复杂的过程。
  • 在灾难之外测试故障转移很容易。

潜在缺点如下：

  • 由于要维护的基础结构更多，例如存储帐户、主机等，可能会花费更多费用。
  • 需要花费更多时间配置部署以适应此计划。
  • 即使不需要该基础结构，也需要维护所设置的额外基础结构。

共享主机池恢复的重要信息

使用此灾难恢复策略时，请务必牢记以下事项：

  • 跨多个区域拥有多个联机会话主机可能会影响用户体验。 托管网络负载均衡器不考虑地理邻近度，而是平等地对待主机池中的所有主机。

  • 在灾难期间，用户将在次要区域中创建新的配置文件。 应将任何业务或任务关键数据存储在 OneDrive（使用已知文件夹重定向）或 Sharepoint 中。 在此处存储数据可让用户快速访问其应用程序，同时对用户体验的影响很小。

  • 请确保在主机池中使用完全相同的方式配置虚拟机 (VM)。 此外，请确保主机池中的所有 VM 大小相同。 如果 VM 不相同，则托管网络负载均衡器会将用户连接均匀分布到所有可用的 VM 上。 与较大的 VM 相比，较小的 VM 可能比预期更早受到资源约束，从而导致消极的用户体验。

  • 区域可用性会影响数据或工作区监视。 如果某个区域不可用，则服务可能会在灾难期间丢失所有历史监视数据。 建议使用自定义导出或转储历史监视数据。

  • 建议每月至少更新一次会话主机。 此建议适用于长时间关闭的会话主机。

  • 至少每六个月运行一次受控故障转移来测试部署。 部分受控故障转移可能意味着辅助位置将成为主位置，直至下一次受控故障转移为止。 通过将辅助位置更改为主位置，用户可以在发生实际灾难时拥有几乎相同的配置文件。

下表列出了主机池灾难恢复策略的部署建议：

技术 建议
网络 在另一个区域中创建和部署次要虚拟网络，并使用主虚拟网络配置 Azure 对等互连。
会话主机 使用多会话 OS SKU 创建和部署 Azure 虚拟桌面共享主机池，并包括来自其他可用性区域和其他区域的 VM。
存储 使用高层级帐户在多个区域中创建存储帐户。
用户配置文件数据 在多个区域中创建 SMB 存储位置。
标识 来自同一目录的 Active Directory 域控制器。

个人主机池的灾难恢复

对于个人主机池，灾难恢复策略应涉及使用 Azure Site Recovery 服务保管库将资源复制到次要区域。 如果主要区域在灾难期间出现故障，Azure Site Recovery 可以进行故障转移并打开次要区域中的资源。

例如，假设我们在美国西部部署了主要区域，在美国东部部署了次要区域。 主要区域有一个个人主机池，每个主机池有两个会话主机。 每个会话主机都有自己的本地磁盘，其中包含用户配置文件数据及其自己的 VNET，这些 VNET 未与任何内容配对。 如果发生灾难，可以使用 Azure Site Recovery 故障转移到美国东部的次要区域（或同一区域的不同可用性区域）。 与主要区域不同，次要区域没有本地计算机或磁盘。 在故障转移期间，Azure Site Recovery 从 Azure Site Recovery 保管库获取复制的数据，并使用它创建两个新的 VM，这些 VM 是原始会话主机的副本，包括本地磁盘和用户配置文件数据。 次要区域有自己独立的 VNET，因此主要区域中的 VNET 脱机不会影响功能。

下图显示了我们刚才描述的示例部署。

A diagram of a deployment using the recommended personal host pool disaster recovery strategy described in the previous paragraph.

此计划的优点包括更低的整体成本，不需要进行修补或更新的维护，因为仅在需要资源时才进行预配。 但是，一个潜在的缺点是，你将花费更多的时间预配、集成和验证故障转移基础结构，而不是使用共享主机池灾难恢复设置。

有关个人主机池恢复的重要信息

使用此灾难恢复策略时，请务必牢记以下事项：

  • 可能要求主机池 VM 需要在辅助站点（例如虚拟网络、子网、网络安全或 VPN）正常工作，这样才能访问本地 Active Directory 等目录。

    注意

    使用已加入 Microsoft Entra 的 VM 会自动满足其中一些要求。

  • 如果大规模灾难影响到多个客户或租户，则可能会遇到资源的集成、性能或争用问题。

  • 个人主机池使用一个用户专用的 VM，这意味着关联性负载负载均衡规则会将所有用户会话返回到特定的 VM。 用户与 VM 之间的这种一对一映射意味着，如果 VM 关闭，则在 VM 恢复联机或灾难恢复完成后 VM 恢复之前，用户将无法登录。

  • 个人主机池中的 VM 将用户配置文件存储在驱动器 C 上，这意味着不需要 FSLogix。

  • 区域可用性会影响数据或工作区监视。 如果某个区域不可用，则服务可能会在灾难期间丢失所有历史监视数据。 建议使用自定义导出或转储历史监视数据。

  • 建议在使用个人主机池配置时避免使用 FSLogix。

  • 无法保证在故障转移区域中进行虚拟机预配。

  • 每六个月至少运行一次受控故障转移和故障回复测试。

下表列出了主机池灾难恢复策略的部署建议：

技术 建议
网络 在另一个区域中创建和部署辅助虚拟网络，以遵循 Azure Site Recovery 默认命名方案之外的自定义命名约定或安全要求。
会话主机 为 VM 启用和配置 Azure Site Recovery。 （可选）可以手动预暂存映像，或使用 Azure 映像生成器服务进行持续预配。
存储 一个选项是创建 Azure 存储帐户来存储配置文件。
用户配置文件数据 用户配置文件数据将本地存储在驱动器 C 上。
标识 跨多个区域来自同一目录中的 Active Directory 域控制器。

后续步骤

有关 Azure 中灾难恢复的更深入信息，请查看以下文章：