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

Azure 虚拟桌面灾难恢复

  • 项目

为确保组织数据的安全，需要采用和管理业务连续性和灾难恢复 (BCDR) 策略。 合理的 BCDR 策略可以让应用和工作负载在执行计划内和计划外维护或 Azure 中断期间仍能保持正常运行。 这些计划应涵盖由客户管理的会话主机虚拟机 (vm)，而不是由 Microsoft 管理的 Azure 虚拟桌面服务。 有关管理区域的详细信息，请参阅 Azure 虚拟桌面灾难恢复概念。

Azure 虚拟桌面服务旨在考虑到高可用性。 Azure 虚拟桌面是由 Microsoft 管理的全局服务，其独立组件的多个实例分布在多个 Azure 区域。 如果任何组件发生意外中断，流量将转移到剩余实例之一，Microsoft 将启动对另一个 Azure 区域中冗余基础结构的完全故障转移。

若要确保用户在会话主机 VM 发生区域中断期间仍可以连接，需要考虑到高可用性和灾难恢复设计基础结构。 典型的灾难恢复计划包括将虚拟机 (VMs) 复制到其他位置。 在中断期间，主站点将故障转移到次要位置中复制的 VM。 用户则可以继续从次要位置访问应用，而不会出现中断。 在 VM 复制的基础上，需要保持用户标识在次要位置处于可访问状态。 因此，如果要使用配置文件容器，则还需要复制它们。 最后，请确保依赖于主要位置数据的业务应用可与其余数据一起进行故障转移。

总而言之，要使用户在中断期间仍保持连接状态，需要执行下列操作：

  • 将 VM 复制到某个辅助位置。
  • 如果使用的是配置文件容器，请在次要位置设置数据复制。
  • 确保在主要位置设置的用户标识在次要位置中可用。 若要确保可用性，请确保 Active Directory 域控制器在辅助位置可用或可从辅助位置获得。
  • 确保主要位置中的数据和任何业务线应用程序会故障转移到辅助位置。

主动-被动和主动-主动灾难恢复计划

有两种不同类型的灾难恢复基础结构：主动-被动和主动-主动。 每种基础结构的工作方式不同，因此让我们看看这些差异是什么。

主动-被动计划是指一个区域的一组资源处于主动状态，而另一组资源在需要时才打开（被动)。 如果活动区域因故障或灾难而脱机，则组织可以通过启用区域并移动其所有用户来切换到被动区域。

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

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

有关可以使用的灾难恢复计划类型的详细信息，请参阅 Azure 虚拟桌面灾难恢复概念。

确定哪种方法最适合组织，这是在开始之前应做的第一件事。 制定计划后，可以开始构建恢复计划。

VM 复制

首先，需要将 VM 复制到次要位置。 执行此操作的选项取决于 VM 的配置方式：

  • 可以通过 Azure Site Recovery 为共用和个人主机池中的所有 VM 配置复制。 有关此过程工作原理的详细信息，请参阅将 Azure VM 复制到其他 Azure 区域。 但是，如果你有从同一映像生成的共用主机池，并且没有本地存储的任何个人用户数据，则可以选择不复制它们。 相反，可以选择提前生成 VM 并使其关闭。 还可以选择仅在发生灾难时在次要区域中预配新 VM。 如果选择这些方法，只需设置一个主机池及其相关的应用程序组和工作区。
  • 可以在故障转移区域创建新的主机池，同时使故障转移位置的所有资源保持关闭状态。 对于此方法，需要在故障转移区域设置新的应用程序组和工作区。 然后，可以使用 Azure Site Recovery 计划打开主机池。
  • 可以创建一个填充主要区域和故障转移区域内置 VM 的主机池，同时保持故障转移区域中的 VM 处于关闭状态。 这种情况下，只需设置一个主机池及其相关的应用程序组和工作区。 对于此方法，可以使用 Azure Site Recovery 计划开启主机池。

建议使用 Azure Site Recovery 来管理将 VM 复制到其他 Azure 位置中，如 Azure 到 Azure 灾难恢复体系结构中所述。 我们特别建议对个人主机池使用 Azure Site Recovery，因为顾名思义，个人主机池往往会为用户提供一些个人信息。 Azure Site Recovery 支持基于服务器和基于客户端的 SKU。

如果使用 Azure Site Recovery，则无需再手动注册这些 VM。 次要 VM 中的 Azure 虚拟桌面代理将自动使用最新的安全令牌连接到最靠近它的服务实例。 次要位置的 VM（会话主机）将自动成为主机池的一部分。 在此过程中，最终用户必须重新连接，但除此之外，再无其他手动操作。

如果在中断期间已存在用户连接，则在管理员开始故障转移到次要区域之前，需要先结束当前区域的用户连接。

要在 Azure 虚拟桌面（经典版）中断开用户连接，请运行以下 cmdlet：

Invoke-RdsUserSessionLogoff

要在 Azure 虚拟桌面中断开用户连接，请运行以下 cmdlet：

Remove-AzWvdUserSession

在主要区域中注销所有用户后，则可以对主要区域的 VM 进行故障转移，让用户连接到次要区域中的 VM。

虚拟网络

接下来，考虑中断期间的网络连接。 需要确保已在次要区域设置虚拟网络 (VNET)。 如果用户需要访问本地资源，则需要配置此 VNET 来访问它们。 可以使用 VPN、ExpressRoute 或虚拟 WAN 建立本地连接。

建议使用 Azure Site Recovery 在故障转移区域设置 VNET，因为它会保留主网络的设置，并且不需要对等互连。

用户标识

接下来，确保域控制器在次要位置可用。

可以通过三种方式来使域控制器保持可用：

  • 辅助位置有一个或多个 Active Directory 域控制器
  • 使用本地 Active Directory 域控制器
  • 使用 Azure Site Recovery 复制 Active Directory 域控制器

用户配置文件

建议使用 FSLogix 来管理用户配置文件。 有关详细信息，请参阅适用于 FSLogix 的业务连续性和灾难恢复选项。

备份数据

还可以选择备份数据。 可以选择以下方法之一来备份 Azure 虚拟桌面数据：

应用依赖项

最后，请确保依赖于主要区域中数据的任何业务应用均可故障转移到次要位置。 此外，确保配置好应用在新位置需要使用的设置。 例如，如果其中一款应用依赖于 SQL 后端，则务必确保在次要位置复制 SQL。 应将应用使用次要位置配置为故障转移进程的一部分或默认配置。 可以模仿 Azure Site Recovery 计划中的应用依赖项。 有关详细信息，请参阅恢复计划。

灾难恢复测试

设置完灾难恢复后，需要测试计划以确保其正常运行。

下面是有关如何测试计划的一些建议：

  • 如果测试 VM 具有联网权限，它们将接管现有的任何会话主机进行新的连接，但与原始会话主机的所有现有连接仍将保持活动状态。 确保运行测试的管理员在测试计划前先注销所有活动用户。
  • 只应在维护时段执行完全的灾难恢复测试，以免干扰用户。
  • 请确保测试涵盖了所有业务关键应用程序和数据。
  • 建议一次最多对 100 个 VM 进行故障转移。 如果 VM 数量超过 100，建议分批对它们进行故障转移，每批间隔 10 分钟。

后续步骤

如果对如何确保数据安全以及服务中断计划存有疑问，请参阅我们的安全指南。