恢复计划与自动故障转移

Azure Site Recovery 中的Recovery Plan是一组结构化且有顺序的步骤，用于协调多个 VM 一起执行故障转移。恢复计划不会让每个 VM 单独进行故障转移，而是将它们分成多个组，按顺序执行故障转移，确保基础设施（数据库、中间件、Web）按照正确顺序启动，就像初次部署时一样。

要创建恢复计划，请选择源站点（主要区域）和目标站点（辅助区域），然后添加要包含的 VM。计划向导会自动创建一个默认组，但您可以添加更多组来控制故障转移顺序。同一组中的 VM 会同时进行故障转移；各组按照编号顺序执行。

对于典型的三层应用程序，恢复计划应包含三个组：

• 组 1——数据库层 VM（必须首先启动）
• 组 2——应用程序/中间件层 VM
• 组 3——Web 前端 VM（最后启动）

每个组都会等待前一个组成功完成故障转移后再启动。这与正确的启动顺序一致，可以防止 Web 层 VM 在数据库准备好接受连接之前启动。

恢复计划支持在每个组边界处配置前置操作和后置操作。这些操作可以是：

• 手动操作——暂停故障转移，等待人员确认（例如“验证数据库已准备就绪”）
• Azure Automation 运行手册——自动执行脚本（例如更新 DNS 记录、禁用维护模式）

使用 Automation 运行手册可以为第 1 层工作负载实现无需人工干预的全自动故障转移。

Azure Site Recovery 支持两种故障转移类型：

• 计划内故障转移——在已知事件发生前启动（例如数据中心维护）。主要 VM 会正常关闭，数据完成同步后，辅助 VM 启动。不会丢失数据。
• 非计划内故障转移——在实际灾难期间触发。主要 VM 可能不可用，因此 ASR 会使用最新的复制检查点。根据 RPO 的不同，可能会丢失部分数据。

故障转移后，辅助区域中恢复的 VM 会处于等待提交状态。您必须Commit故障转移，以确认辅助站点现在是活动站点，并且不再需要回滚。提交后，您可以设置反向复制来保护辅助站点，待主要区域恢复后，最终再切回主要区域。

提交故障转移后，原主要区域中的复制项将不再处于活动复制状态。要恢复保护，您必须对这些项执行重新保护——这会反转复制方向，使新的主要区域（原辅助区域）向原主要区域进行复制。重新保护需要一定时间，应在原主要区域再次可用后尽快启动。

恢复计划中的每个步骤都会增加总 RTO。常见的耗时环节包括：

• VM 启动时间（每个 VM 需要 2–5 分钟）
• 应用预热时间（数据库连接池初始化、缓存预热）
• IP 更改后的 DNS 传播时间
• 手动审批关卡的等待时间

请在测试故障转移期间测量每个步骤的耗时，并将它们相加，以计算您的实际 RTO，然后与目标值进行比较。

发生故障转移后，次要区域中的 VM 会拥有不同的 IP 地址。对于公开 DNS 名称的应用，您必须更新 DNS，使其指向新的 IP。请使用 Azure 自动化运行手册作为故障转移后的操作，以更新 Azure DNS 或 Traffic Manager 终结点的运行状况，从而自动重定向流量，避免因手动操作延迟 RTO。

在故障转移期间，Recovery 服务保管库中的 Azure 门户作业视图会显示恢复计划中每个步骤的实时进度。您可以查看正在执行的组、已成功启动的 VM，以及是否有脚本或手动操作处于等待状态。监视此视图可以帮助恢复团队在某个步骤失败时迅速介入。

恢复计划的关键最佳实践包括：

• 保持组规模较小（5–10 个 VM），以便在组失败时限制影响范围
• 尽可能使用自动化运行手册代替手动操作，以降低 RTO
• 记录每个组的预期启动时间，以便计算 RTO
• 至少每季度运行一次测试故障转移，验证计划是否有效
• 每当添加新的 VM 或应用架构发生变化时，都要检查并更新计划

请测试您对本课 Microsoft Azure Fundamentals (AZ-900) 概念的理解。

本课介绍了：恢复计划会协调多个 VM 按顺序进行故障转移，并在每个组执行预操作和后操作；计划外故障转移使用最后一个复制检查点，而计划内故障转移不会造成数据丢失；故障转移后，您必须提交并重新保护，才能恢复 DR 保护。接下来，我们将探讨如何在不影响生产环境的情况下测试 DR 计划。