为什么我的 EC2 Linux 实例无法访问并且其状态检查失败？

3 分钟阅读

我的 Amazon Elastic Compute Cloud（Amazon EC2）Linux 实例无法访问，且有一项或两项状态检查失败。

简短描述

Amazon EC2 使用两种状态检查来监控 EC2 实例的运行状况：

系统状态检查

系统状态检查会检测实例底层硬件的问题。如果由于网络、硬件或软件问题，底层硬件无响应或无法访问，则系统状态检查便会失败。

实例状态检查

实例状态检查失败表示无法访问实例。下列常见问题会导致实例状态检查失败：

未能启动操作系统（OS）
未能正确挂载卷
CPU 和内存耗尽
内核崩溃
网络故障

**警告：**下面介绍的某些解决方法要求先停止实例，然后再启动实例。在停止并启动您的实例之前，请注意下列条件：

当实例停止时，存储在实例存储卷中的数据会丢失。在停止实例之前，请务必备份数据。与 Amazon Elastic Block Store（Amazon EBS）支持的卷不同，实例存储卷是临时性的，不支持数据持久化。
Amazon EC2 在启动或开始时自动分配给实例的静态公有 IPv4 地址在停止并启动后会发生变化。若要保留公有 IPv4 地址，让其在停止实例后不会发生变化，请使用弹性 IP 地址。

有关详细信息，请参阅停止实例的先决条件。

解决方法

若要确定实例状态检查或系统状态检查是否失败，请查看实例的状态检查指标。

如果系统状态检查失败，请参阅我的 EC2 Linux 实例未通过系统状态检查。如何解决此问题？

如果实例状态检查失败，请查看实例的系统日志以确定失败的原因。然后，使用以下解决方法之一来解决问题。

未能启动操作系统

如果系统日志包含启动错误，请参阅如何对因操作系统问题而未能通过实例状态检查的 EC2 Linux 实例进行故障排除？

未能正确挂载卷

挂载点故障可能会导致实例状态检查失败。

挂载点故障示例：

[FAILED] Failed to mount /
See 'systemctl status mnt-nvme0n1p1.mount' for details.
[DEPEND] Dependency failed for Local File Systems.

有关详细信息，请参阅下列 AWS Knowledge Center 文章：

“依赖项失败”错误：为什么当我尝试启动 EC2 Linux 实例时，它进入紧急模式？
“挂载失败”或“依赖项失败”错误：如何对因操作系统问题而未能通过实例状态检查的 EC2 Linux 实例进行故障排除？

当您将实例类型从 Xen 更改为 Nitro 时，卷挂载可能会失败。挂载失败是因为 Amazon EBS 卷在基于 Nitro 的实例上暴露为 NVMe 块设备。设备名称是 /dev/nvme0n1、/dev/nvme1n1 等。您在块设备映射中指定的设备名称将重命名为 NVMe 设备名称（/dev/nvme[0-26]n1）。块设备驱动程序可能会按与您在块设备映射中指定的原始顺序不同的顺序分配 NVMe 设备名称。为避免在基于 Nitro 的实例上挂载失败，最佳做法是使用标签或 UUID 作为设备名称。有关详细信息，请参阅使 Amazon EBS 卷可在 Linux 上使用。

CPU 和内存耗尽

CPU 利用率高

如果 CPUUtilization 指标等于或接近 100%，则实例可能没有足够的计算容量来运行内核。

对于 T2 或 T3 实例，请查看 Amazon CloudWatch CPU 积分指标以确定 UPC 积分是否等于或接近零。如果 CPU 积分为零，则 CPUUtilization 指标显示实例的基准性能处于饱和稳定状态。基准性能可能为 20%、40% 等，具体取决于实例类型。

CPU 利用率等于或接近 100%，或者 T2 或 T3 实例处于饱和稳定状态，表示由于资源过度使用，状态检查失败。若要解决此问题，请参阅由于资源过度使用，我的 EC2 Linux 实例未通过实例状态检查。如何解决此问题？

块设备错误、软件错误或内核崩溃可能会导致 CPU 使用率异常激增。如果 CPU 利用率为 100%，请检查系统日志中是否存在块设备或内存问题错误或者其他异常系统错误。然后，重启或者停止并启动实例。

内存不足

内存压力过高可能会导致实例状态检查失败。在以下示例日志条目中，操作系统内存不足。若要解决此错误，请停止内存消耗最多的进程。

[115879.769795] Out of memory: kill process 20273 (httpd) score 1285879 or a child
[115879.769795] Killed process 1917 (php-cgi) vsz:467184kB, anon-rss:101196kB, file-rss:204kB

默认情况下，EC2 实例内存和磁盘指标不会发送到 Amazon CloudWatch。但是，您可以使用 CloudWatch 代理程序来收集和监控其他指标。

若要排查并解决内存不足问题，请将实例升级到更大的实例类型。或者，向实例添加交换存储空间以缓解内存压力。有关详细信息，请参阅下列 AWS Knowledge Center 文章：

磁盘已满错误

如果系统日志包含磁盘已满错误，则由于根设备已满，实例处于紧急模式。

系统日志示例：

$: service apache2 restart
Error: No space left on device

$: /etc/init.d/mysql restart
[....] Restarting mysql (via systemctl): mysql.serviceError: No space left on device


root@example:~# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.7G  7.7G     0 100% /

有关如何排查和解决磁盘已满错误的详细说明，请参阅下列 AWS Knowledge Center 文章：

内核崩溃

当内核在操作过程中检测到内部致命错误时，就会发生内核崩溃。如果在操作系统启动期间发生错误，则内核可能无法正常加载。这会导致操作系统启动失败。

内核崩溃错误消息示例：

Linux version
2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 20050727 (Red Hat4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007
Kernel command
line:  root=/dev/sda1 ro 4
Registering block device major 8
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

有关如何排查和解决内核崩溃错误的信息，请参阅以下 AWS Knowledge Center 文章：

网络故障

以下常见原因可能导致您的网络出现故障。

实例上未安装 cloud-init 包

cloud-init 包用于在启动时更新网络配置。

若要更正此错误，请运行以下命令在您的实例上安装 cloud-init 包：

$ sudo yum install cloud-init

MAC 地址硬编码在配置文件中

硬编码的 MAC 地址位于 Linux 配置文件和 udev 配置文件中。这些文件通常位于下列位置：

/etc/udev/rules.d/
/etc/udev/rules.d/70-persistent-net.rules
/etc/udev/rules.d/80-net-name-slot.rules

若要解决由硬编码 MAC 地址引起的网络问题，请删除这些条目或者配置文件。例如，运行下列命令：

mv /etc/udev/rules.d/70-persistent-net.rules/root/

IP 地址硬编码在配置文件中

当您从具有静态配置 IP 地址的实例创建亚马逊机器映像（AMI）时，配置文件可能包含硬编码的 IP 地址。

若要更正此错误，请将您的网络接口设置为使用 DHCP。

**注意：**您无法更新现有 AMI。在创建新的 AMI 之前，您必须将网络接口设置为使用 DHCP。

缺少 ENA 或 Intel 增强型网络驱动程序

有关缺少弹性网络适配器（ENA）或 Intel 增强型网络驱动程序的详细信息，请参阅 Linux 上的增强联网。

网络接口在启动时被重命名

若要修复此问题，请在内核命令行中添加 net.ifnames=0，以停用可预测的网络接口名称。若要执行此变量，您必须激活具有 ENA 的增强联网。

有关网络问题的详细信息，请参阅配置网络接口的最佳实践。