实例自动恢复 - Amazon Elastic Compute Cloud
实例自动恢复的关键概念简化的自动恢复机制和基于 CloudWatch 操作的恢复机制之间的区别构建弹性系统
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

实例自动恢复

重要

本节旨在介绍如何在 EC2 实例上主动配置恢复机制。这些恢复机制专门用于在 Amazon 检测到导致系统状态检查失败的底层硬件或软件问题时恢复实例可用性。如果目前存在实例访问问题，请参阅 EC2 实例问题排查。

如果 Amazon 检测到某个实例因底层硬件或软件问题而不可用，有两种机制可以用来自动恢复实例的可用性：简化的自动恢复和基于 Amazon CloudWatch 操作的恢复。恢复实例可用性又称实例恢复。

在实例恢复过程中，Amazon 会尝试将实例从存在底层硬件或软件问题的主机移至另一台主机。恢复成功后，实例恢复过程会在实例中显示为计划外重启。您可以验证是否已进行实例恢复。

如果恢复过程不成功，实例可能会继续在存在底层硬件或软件问题的主机上运行。此时需要手动加以干预。如果实例无法访问，或者系统状态检查仍然失败，建议手动停止并启动实例。启动实例时，实例通常会迁移到新的底层主机。不过，与实例自动恢复（即实例保留原有公有 IPv4 地址）不同，除非重启的实例具有弹性 IP 地址，否则其会收到新的公有 IPv4 地址。

要从自动恢复机制中受益，必须在系统状态检查失败之前，在实例上预先对机制进行配置。启动实例期间，默认会启用简化的自动恢复机制。您也可以选择在启动后配置基于 Amazon CloudWatch 操作的恢复机制。配置其中一种机制可以让实例更具弹性。

简化的自动恢复机制和基于 Amazon CloudWatch 操作的恢复机制仅适用于支持的实例。有关更多信息，请参阅启用简化的自动恢复的要求和启用基于 CloudWatch 操作的恢复的要求。

警告

在 Amazon 因底层硬件或软件问题而恢复实例后，须注意以下后果：存储在易失性存储器（RAM）中的数据会丢失，操作系统的正常运行时间会从零开始计算。此外，若使用基于 CloudWatch 操作的恢复机制，实例存储卷上的数据也会丢失。为协助防止数据丢失，我们建议您定期创建宝贵数据的备份。有关 EC2 实例备份和恢复最佳实践的更多信息，请参阅 Amazon EC2 最佳实践。

实例自动恢复机制是为单个实例设计的。有关构建弹性系统的指导，请参阅构建弹性系统。

主题

实例自动恢复的关键概念

实例自动恢复是 Amazon EC2 的一项功能，可在底层硬件或软件发生故障时自动恢复实例可用性，从而增强 EC2 实例的弹性和可靠性。

以下是实例自动恢复的关键概念：

配置选项

可以配置两种机制来支持实例自动恢复：

系统状态检查

系统状态检查会自动监控运行 EC2 实例的 Amazon 基础设施。

  • 如果系统状态检查失败，Amazon 会启动实例自动恢复，尝试将受影响的实例迁移到别的硬件。

  • 系统状态检查失败表示主机的硬件或软件存在问题，而不是实例本身有问题。实例自动恢复机制可以恢复未通过系统状态检查的实例。不过，如果只有实例状态检查失败，则无法进行实例自动恢复。

  • 有关实例状态检查和系统状态检查这二者间的区别，请参阅状态检查类型。

底层硬件或软件问题示例

可能导致系统状态检查失败的硬件或软件问题包括：网络连接丢失、系统电源损耗、物理主机上的软件问题以及物理主机上影响到网络连接状态的硬件问题。

已恢复实例的特性

除了丢失的元素外，已恢复实例与原始的实例完全相同。

保留的元素：

  • 实例 ID

  • 公有、私有和弹性 IP 地址

  • 实例元数据

  • 置放群组

  • 附加的 EBS 卷

  • 可用区

丢失的元素：

  • 存储在易失性存储器（RAM）中的数据

  • 存储在实例存储卷中的数据（仅适用于基于 CloudWatch 操作的恢复机制）

  • 操作系统的正常运行时间重置为零

使用 CloudWatch 监控系统状态检查情况

CloudWatch 中的 StatusCheckFailed_System 指标表明系统状态检查通过与否。

指标值：

  • 0：系统状态检查通过。

  • 1：系统状态检查失败。

Amazon Health Dashboard 中的事件

在尝试执行实例自动恢复期间，Amazon 会根据配置的恢复机制以及相应结果向 Amazon Health Dashboard 发送事件：

  • 简化的自动恢复

    • 成功事件：AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_SUCCESS

    • 失败事件：AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_FAILURE

  • CloudWatch 基于操作的恢复

    • 成功事件：AWS_EC2_INSTANCE_AUTO_RECOVERY_SUCCESS

    • 失败事件：AWS_EC2_INSTANCE_AUTO_RECOVERY_FAILURE

简化的自动恢复机制和基于 CloudWatch 操作的恢复机制之间的区别

下表比较了简化的自动恢复和基于 CloudWatch 操作的恢复这两种机制间的主要区别。

比较点 简化的自动恢复 CloudWatch 基于操作的恢复
配置 默认在支持的实例上启用 必须手动配置 CloudWatch 警报和操作
弹性 修复由 Amazon 管理的恢复行为 可自定义的操作和条件
通知 通过 Amazon Health Dashboard 发送基本通知 通过 SNS 发送自定义通知
裸机实例大小 排除 包含
启动实例时附加的实例存储卷 不支持在启动时附加实例存储卷的实例 在选定的实例类型上受支持。请注意，在实例恢复过程中，实例存储卷上的数据会丢失。
恢复时间 标准恢复尝试 恢复尝试速度比简化的自动恢复更快
迁移期间解决了主机问题 迁移可以取消，并且实例仍保留在原主机上 继续迁移到新主机
成本 无额外费用 CloudWatch 可能会产生费用

构建弹性系统

虽然简化的自动恢复机制和基于 CloudWatch 操作的恢复机制都可以有效维护单个实例的可用性，但 Amazon 建议实施高可用性架构，允许流量失效转移到运行状况良好的实例。

为实现该目的，可以考虑使用 Elastic Load Balancing（在多个 EC2 实例之间分配传入流量）和 Amazon EC2 Auto Scaling（根据需求和运行状况自动调整实例数量）等 Amazon 服务。

有关使用 EC2 实例构建具备容错能力的弹性系统的更多信息，请参阅以下资源：