保护在 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 的应用程序，可以使用来宾内代理来保护应用程序数据、操作系统配置以及存储在卷上的数据。

使用来宾内代理进行备份

使用来宾 OS 代理备份 VM 通常包括捕获操作系统配置、文件/文件夹、磁盘、应用程序二进制文件或应用程序数据。

从代理恢复应用程序需要以手动方式重新创建 VM，并安装操作系统和来宾代理。 然后就可以将数据还原到来宾 OS 或直接还原到应用程序。

使用已停止的 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，以便与原始设置相匹配。 可能需要考虑 VNET 是否与可能使用了该 IP 地址的外部环境建立了 S2S VPN 连接。
• 不需要的项目
  如果 VM 已在其他平台（例如 VMware vSphere）上备份，则你需要执行一些额外的步骤来清理源中所有不需要的项目。

后续步骤

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

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