Azure 本地虚拟机（VM）上运行的工作负荷的灾难恢复需要一种分层方法，使基础结构级保护与特定于应用程序的连续性策略保持一致。 无论是托管 SQL Server 数据库还是通过 Azure 虚拟桌面传送虚拟桌面，每个工作负荷类型都具有独特的恢复要求和依赖项。 Azure Local 支持各种灾难恢复技术，使你可以根据业务连续性目标定制恢复计划，并确保从中断中快速恢复。
SQL Server
Azure 本地 VM 可以托管高性能 SQL Server 部署，包括使用 Always-On 可用性组来增强恢复能力的。 SQL Server 灾难恢复的主要目标是在发生中断时满足应用程序的特定恢复时间目标（RTO）和恢复点目标（RPO）。 SQL Server 提供了一组丰富的内置功能，用于在单个站点/群集中实现高可用性（HA），以及灾难恢复到辅助站点/群集。
对于在 Azure 本地 VM 上运行的 SQL Server 工作负荷，全面的灾难恢复策略必须将主机级保护机制与 SQL Server 自己的本机高可用性/灾难恢复功能相结合。 虽然服务器级别保护能保护整个服务器实例（包括操作系统和 SQL Server 二进制文件），但 SQL原生解决方案（如 Always-On 可用性组和日志传送）可提供更精细的数据库可用性控制、应用程序一致的数据保护，并且通常可以实现较低的恢复点目标（RPO），尤其是在高度事务性数据库中。 通过使用 SQL Server 自己的灾难恢复功能，除了 Azure Local 的主机级保护之外，组织还可以实现更可靠的数据保护和更快的恢复时间。
Azure 本地 VM 上的 SQL Server 灾难恢复功能
SQL Server 提供了一系列经验证的灾难恢复技术，所有这些技术在 Azure 本地部署上完全受支持。 可以根据应用程序要求和恢复点目标（RPO）/恢复时间目标（RTO）目标选择一个或组合多个目标。
有关在 Azure Local 上使用的关键 SQL Server 灾难恢复功能及其最佳实践建议包括：
AlwaysOn 可用性组（AG）
- Always On AG 是一项高级高可用性/灾难恢复功能，它通过将事务从主副本复制到一个或多个次要副本来保护一组用户数据库。
- 在 Azure 本地环境中，可以在单个群集中使用 AG 以实现高可用性，并且可以跨群集或站点进行灾难恢复。 对于自动故障转移，请在 Windows Server 故障转移群集（WSFC）上部署 AG，并在邻近（低延迟网络）的副本之间使用同步提交模式。 对远程副本（更高的延迟）的副本使用异步提交模式，以最大程度地提高性能。 分布式可用性组 还可以跨多个群集实现高级方案。 Azure 本地环境的 Always On 可用性组在适当配置时支持自动和手动故障转移，是推荐用于保护需要最短停机时间的关键数据库的解决方案。
- 有关详细信息，请参阅 什么是 AlwaysOn 可用性组。
始终启用故障转移群集实例 （FCI）：
- AlwaysOn 故障转移群集实例是基于 WSFC 的实例级高可用性解决方案，它提供整个 SQL Server 实例（包括所有数据库）到群集中另一个节点的故障转移。
- Azure 本地上的 FCI 使用群集的共享存储（由 Azure 本地 S2D 卷提供）来确保 SQL 实例可以在具有相同数据的第二个节点上重启。
- 最佳做法：使用 FCI 保护需要实例级故障转移或共享存储可用的应用程序。
- 有关详细信息，请参阅 AlwaysOn 故障转移群集实例。
日志传送：
- 日志传送会定期从主数据库备份事务日志，并将其还原到辅助数据库。 这将建立一个在灾难时可启动和联机的热备用服务器。 在 Azure 本地上，日志传送完全受支持，对于不太敏感的数据库，日志传送可能是低成本的灾难恢复选项。
- 最佳做法：确保日志备份频率与 RPO 保持一致。 此外，监控次要副本上的还原延迟，以评估故障转移时间。 有关详细信息，请参阅 关于日志传送。
数据库镜像：
- 镜像维护数据库的两个副本，并且可以同步或异步配置。 但是，最近 SQL 版本中弃用镜像，不建议用于新部署。 请改用基本可用性组或完整的 Always On AG，这些功能在 Azure 本地提供类似的功能，而不受镜像的限制。
- 有关详细信息，请参阅 数据库镜像。
备份和还原：
- 常规数据库备份（包括完整备份、差异备份和事务日志备份）是任何灾难恢复策略的基础。 SQL Server 支持备份到磁盘或 URL，例如 Azure Blob 存储。 客户可以使用 Microsoft Azure 备份服务器 （MABS）或非Microsoft合作伙伴工具将整个 VM 或应用程序备份到本地磁盘和云存储。 SQL Server 还提供 到 Azure 的托管备份，无需 MABS 或任何非Microsoft备份解决方案即可自动计划到云存储的备份。
- 最佳做法：无论哪种工具对你的环境都有意义，采取频繁的备份来满足 RPO 目标，并定期测试还原。
- 有关详细信息，请参阅 SQL Server 数据库的备份和还原
复制：
- SQL Server 复制（事务性、合并或快照）允许以近乎实时的方式将数据从一个数据库复制到另一个数据库以及将数据分发给其他数据库。 虽然通常用于分发只读副本或同步数据，但复制也可以作为灾难恢复策略的一部分。 在 Azure Local 上，支持所有类型的 SQL Server 复制。
- 注意：复制不会自动接管整个数据库系统，并且在灾难发生时可能需要手动重新配置。
- 有关详细信息，请参阅 SQL Server 数据复制。
上述所有功能都可以混合，以实现所需的结果。 例如，使用 Always on AG 在主站点中实现零数据丢失高可用性，并同时使用异步复制到辅助 Azure 本地实例异地进行灾难恢复。 选择应遵循应用程序的 RPO/RTO 要求，以及解决方案是提供自动故障转移还是需要手动过程。
已启用 Arc 的 SQL Server 优势
启用的每个来宾 Azure 本地虚拟机都支持 Arc，因此虚拟机内的 SQL Server 将自动成为支持 Arc 的 SQL Server。 通过 Azure Arc 集成，可获取本地 SQL Server 灾难恢复设置的基于云的可见性和管理。 Azure Arc 不会取代上述 SQL 本机灾难恢复功能，但它提供统一的工具，用于从 Azure 门户监视、管理和增强这些功能。
用于灾难恢复的关键已启用 Azure Arc 的 SQL Server 功能包括：
AlwaysOn 可用性组管理：
- 在 Azure 门户中查看和管理已启用 Arc 的 SQL Server 上的 Always-On AG。 这包括查看可用性组的列表、其副本和同步状态，以及根据需要执行手动故障转移。
- 有关详细信息，请参阅 管理 AlwaysOn 可用性组。
故障转移群集实例可见性：
- Azure Arc 在门户中显示 SQL Server FCI，使你能够在混合环境中识别和监视 FCI 部署。
- 有关详细信息，请参阅 Azure Arc 中查看 AlwaysOn 故障转移群集实例。
自动备份和还原：
使用托管标识备份到 URL：
- Arc 允许本地 SQL Server 在备份到 Azure Blob 存储时使用 Azure 托管标识进行身份验证。 这样就无需使用 SAS 令牌或帐户密钥。
- 有关详细信息，请参阅备份到具有托管标识的 URL（预览版）。
Azure 虚拟桌面
Azure 虚拟桌面 提供了一个全面的平台，用于安全地将虚拟化的 Windows 桌面和应用程序交付给任何地方的用户，并与云和本地环境无缝集成。
Azure 虚拟桌面体系结构包括多个核心组件，包括会话主机虚拟机、Azure 虚拟桌面控制平面（用于管理云中的用户连接、中转和网关服务）、用户配置文件存储（如 FSLogix）以及共同提供无缝虚拟桌面体验的网络配置。 Azure 本地的 Azure 虚拟桌面灾难恢复策略必须考虑各组件的恢复和连续性，以确保故障转移后的顺利过渡。
Azure 虚拟桌面会话主机是在访问 Azure 虚拟桌面时运行实际桌面和应用程序环境的虚拟机。 每个会话主机都提供资源、管理用户会话，并确保工作负荷是隔离且高性能的。 因此，为 Azure 本地 VM 列出的许多 VM 恢复选项也适用于 Azure 虚拟桌面，但需要其他注意事项来考虑虚拟桌面解决方案的其他核心组件。
共用主机池
在共用模型中，用户分配到池中的任何可用会话主机，VM 理想情况下是无状态的。 用户特定的数据和设置是使用 FSLogix 配置文件容器漫游的，该容器将整个用户配置文件存储在登录时动态附加的 VHD（X） 文件中。 对于灾难恢复，共用主机的主要重点是确保用于部署会话主机、FSLogix 配置文件容器和任何 MSIX 应用附加包以重新生成映像的黄金映像的可用性。 由于 VM 不会直接映射到用户，因此可能不需要完整 VM 备份和故障转移方法（如 Hyper-V 副本）。
建议用于共用会话主机的灾难恢复方法是在辅助站点（Azure 或其他群集）上创建主机池，并将其配置为与主主机池匹配。 这些主机可以保持休眠状态，并在故障转移时打开，也可以始终处于活动状态。 请务必确保辅助主机池可以访问相同的 FSLogix 配置文件，并由主主机使用的同一映像生成，以便为用户提供一致的体验。 可以使用 OneDrive 重定向来确保 FSLogix 配置文件在两个站点之间保持同步。
在故障转移时，如果主机处于休眠状态，则必须开机，并且用户需要重新分配到备用主机池。 如果系统始终处于活跃状态，则在切换时无需管理员干预。 故障回复在主群集的运行状况恢复后，以类似的方式执行，只要原始主机重新联机。
个人主机池
使用个人会话主机时，每个用户将分配到特定的专用会话主机 VM。 这些 VM 是有状态的，因为用户可以安装应用程序或直接在它们上存储数据。 因此，个人会话主机的灾难恢复通常需要完整的 VM 级备份和复制（使用 Hyper-V 副本）来保留每个用户桌面的唯一状态。
使用 Hyper-V 副本故障转移到另一个本地 Azure 群集
辅助 Azure 本地群集可用作故障转移站点，以在本地保留会话主机。 该策略主要遵循有关使用 Hyper-V 副本的虚拟机弹性建议，以及针对个人会话主机的特殊注意事项。
该策略主要遵循上述 Hyper-V 副本部分中的建议，并特别考虑共用会话主机和个人会话主机。
准备群集进行故障转移：确保辅助群集具有足够的计算和存储容量来支持故障转移、具有匹配的网络配置，并且可路由到主群集。 确保在辅助群集上配置 AD DC 和 DNS 设置相同，以便复制的 VM 能够顺利进行身份验证。
启用 Hyper-V 副本：Hyper-V 副本必须使用 PowerShell 或故障转移群集管理器进行配置，因此无法从 Azure 门户完成。 必须在主群集和辅助群集上启用复制，并且必须为每个 VM 定义复制设置，包括恢复频率和初始复制方法。
复制会话主机：对于个人会话主机，请确保每个 VM 定期复制到辅助群集，并且用户to-VM 映射与主群集一致。 建议在故障转移之前保留预配并分配给主机池的复制 VM，但如果不是，则必须在故障转移时分配这些 VM。
Hyper-V 副本故障转移
在故障转移时，第一步是确认域控制器正常运行，并且 DNS 设置在启动任何主机之前是最新的。 个人会话主机应启动并验证最新的复制功能，以确保配置文件被适当分配。
请务必注意，使用 Hyper-V 副本进行故障转移后，在辅助站点上的 VM 将是不受管理的。 最终用户能够像平常一样使用 Azure 虚拟桌面，但故障转移后无法像以前那样从门户管理虚拟机。 为了恢复管理能力，建议在主站点可以还原后尽快切换回主站点。
Hyper-V 副本故障回复
建议安排维护时间窗口，在主站点恢复正常和功能完善时将 VM 切换回主站点。 将 VM 反向复制回主站点，并验证主机是否可访问，DNS 设置是否按预期进行。
多群集复原能力
共用主机池的灾难恢复的另一种方法是将主机池中的会话主机划分为多个群集。 如果单个群集故障且冗余有限，则提供无缝重定向。
若要配置此方法，请：
- 确保以相同的方式配置这两个群集，并具有匹配的 AD 和 DNS 设置。
- 在两个群集上部署会话主机，然后使用 Azure 虚拟桌面门户、PowerShell 或 Azure CLI 手动将它们添加到主机池 。
- 会话会根据需要自动跨群集进行负载均衡。 在这种情况下，请使用 Scale-Out 文件服务器来存储 FSLogix 配置文件，供两个群集访问。
若要了解详细信息，请参阅 适用于 Azure 本地的 Azure 虚拟桌面。
后续步骤
了解有关以下方面的详细信息：