保护 Azure Stack Hub 上部署的 VM

使用本文作为指南，可帮助你为 Azure Stack Hub 上部署的用户部署的 IaaS 虚拟机（VM）制定数据保护和灾难恢复策略。

为了防止数据丢失和延长停机时间，请为用户应用程序及其数据实施备份恢复或灾难恢复计划。 每个应用程序都必须作为组织全面业务连续性和灾难恢复（BC/DR）策略的一部分进行评估。

保护 IaaS VM 的注意事项

角色和职责

首先，请确保在保护和恢复上下文中清楚地了解应用程序所有者和作员所赋予的角色和职责。

用户负责保护 VM。 作员负责使 Azure Stack Hub 保持联机和正常运行。 Azure Stack Hub 包含一项服务，该服务从基础结构服务备份内部服务数据， 不包括 任何用户数据，包括用户创建的 VM、具有用户或应用程序数据的存储帐户或用户数据库。

源/目标组合

需要防范数据中心或站点中断的用户可以使用另一个 Azure Stack Hub 或 Azure 来提供高可用性或快速恢复。 使用主位置和辅助位置，用户可以在两个环境中采用主动/主动或主动/被动配置来部署应用程序。 对于不太关键的工作负荷，用户可以使用备用地点的容量按需从备份中恢复应用程序。

可将一个或多个 Azure Stack Hub 云部署到数据中心。 为了在重大灾难中存活下来，可以在另一个数据中心内部署至少一个 Azure Stack Hub 云，确保能够对工作负载进行故障转移，并最大程度地缩短计划外停机时间。 如果只有一个 Azure Stack Hub，应考虑使用 Azure 公有云作为恢复云。 应用程序可以运行的位置的确定将由政府法规、公司策略和严格的延迟要求决定。 可以灵活地确定每个应用程序的相应恢复位置。 例如，可以在一个订阅中让应用程序将数据备份到另一个数据中心，在另一个订阅中将数据复制到 Azure 公有云。

应用程序恢复目标

应用程序所有者主要负责确定应用程序和组织可以容忍的停机时间和数据丢失量。 通过量化可接受的停机时间和可接受的数据丢失，可以创建一个恢复计划，以最大程度地减少灾难对组织的影响。 对于每个应用程序，请考虑以下事项：

• 恢复时间目标 (RTO)
  RTO 是应用在事件发生后可能不可用的最大可接受时间。 例如，RTO 为 90 分钟意味着你必须能够在灾难开始后的 90 分钟内将应用还原到正在运行的状态。 如果 RTO 低，可以持续运转一个后备部署，以防范区域性服务中断。
• 恢复点目标 (RPO)
  RPO 是灾难期间可接受的数据丢失的最大持续时间。 例如，如果将数据存储在单个数据库中，该数据库按小时备份，并且没有复制到其他数据库，则最多可能会丢失一小时的数据。

另一个指标是 “恢复平均时间 ”（MTTR），这是故障后还原应用程序所需的平均时间。 MTTR 是系统的实证值。 如果 MTTR 超过 RTO，则系统中的故障会导致无法接受的业务中断，因为无法还原定义的 RTO 中的系统。

保护选项

备份-恢复

通过备份应用程序和数据集，可以因数据损坏、意外删除或灾难而快速从停机恢复。 对于基于 IaaS VM 的应用程序，可以使用来宾内代理来保护应用程序数据、操作系统配置以及存储在卷上的数据。

使用来宾内代理进行备份

使用客户操作系统代理备份虚拟机通常包括捕获操作系统配置、文件/文件夹、磁盘、应用程序的二进制文件或数据。

从代理恢复应用程序需要手动重新创建 VM、安装操作系统和安装客户代理。 此时，可以将数据还原到客户端操作系统或直接还原到应用程序。

使用已停止 VM 的磁盘快照进行备份

备份产品可以保护附加到已停止 VM 的 IaaS VM 配置和磁盘。 使用与 Azure Stack Hub API 集成的备份产品来捕获 VM 配置和创建磁盘快照。 如果应用程序的计划停机时间可能，请确保 VM 处于停止状态，然后再启动备份工作流。

使用磁盘快照备份正在运行的 VM

规模集或可用性集中的 VM

规模集或可用性组中被视为临时资源的 VM 不应在 VM 级别备份，尤其是在应用程序无状态时。 对于在规模集或可用性集中部署的有状态应用程序，请考虑保护应用程序数据（例如，存储池中的数据库或卷）。

复制/手动故障转移

对于需要最少数据丢失或最短停机时间的应用程序，可以在来宾 OS 或应用程序级别启用数据复制，以将数据复制到其他位置。 某些应用程序（例如 Microsoft SQL Server）本地支持复制。 如果应用程序不支持复制，则可以使用来宾 OS 中的软件来复制磁盘，或作为来宾 OS 中的代理安装的合作伙伴解决方案。

使用此方法，应用程序部署在一个云中，并将数据复制到本地或其他云或 Azure。 触发故障转移时，需要启动目标中的应用程序并将其连接到复制的数据，然后才能开始处理请求。

高可用性/自动故障转移

对于只能容忍几秒钟或几分钟停机的无状态应用程序，请考虑高可用性配置。 高可用性应用程序设计为部署在活动/活动拓扑中的多个位置，其中所有实例都可以为请求提供服务。 对于本地硬件故障，Azure Stack Hub 基础结构使用两个机架交换机在物理网络中实现高可用性。 对于计算级别故障，Azure Stack Hub 会在一个缩放单元中使用多个节点并会自动对 VM 进行故障转移。 在 VM 级别，可以使用规模集，也可以使用可用性集中的 VM，以确保节点故障不会导致应用程序无法使用。 需要将同一应用程序部署到同一配置中的辅助位置。 若要使应用程序处于活动状态/主动，可以使用负载均衡器或 DNS 将请求定向到所有可用实例。

无恢复

环境中的某些应用可能不需要防止计划外停机或数据丢失。 例如，通常不需要恢复用于开发和测试的 VM。 是否对某个应用程序或数据集进行保护由你自行决定。

建议的拓扑

Azure Stack Hub 部署的重要注意事项：

还原的 IaaS VM 的注意事项

从备份还原计算机后，需要对 VM 进行一些更改。 这些包括：

• MAC 地址
  虚拟网络适配器将获取新的 MAC 地址。 没有保留原始 MAC 地址的方法。
• IP 地址
  如果 VM 在内部设置了静态 IP，则可以将虚拟网络适配器上的内部 IP 设置为与原始 IP 匹配。 可能需要考虑 VNET 是否与可能使用了该 IP 地址的外部环境建立了 S2S VPN 连接。
• 不需要的工件
  如果在其他平台上（例如 VMware vSphere）上备份了 VM，则需要执行一些其他步骤，从源中清理任何不需要的项目。

后续步骤

本文提供了保护 Azure Stack Hub 上部署的用户 VM 的一般准则。 有关使用 Azure 服务保护用户 VM 的信息，请参阅：

• Azure Stack IaaS - 第四部分 - 保护你的内容
• 使用 Azure 备份在 Azure Stack Hub 上备份文件和应用
• Azure 备份服务器对 Azure Stack Hub 的支持
• Azure Stack Hub 的 Azure Site Recovery 支持
• Azure Stack Hub 数据中心集成合作伙伴生态系统数据表