為什麼我的 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 知識中心文章：

「Dependency failed」錯誤：在我嘗試啟動 EC2 Linux 執行個體時，為什麼它會進入緊急模式？
「Failed to mount」或「Dependency failed」錯誤：如何對由於作業系統出現問題而未能通過執行個體狀態檢查的 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 積分指標，以確定 CPU 積分是否等於或接近零。如果 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 知識中心文章：

磁碟已滿錯誤

如果系統日誌包含磁碟已滿錯誤，則執行個體會因根裝置已滿而處於緊急模式。

系統日誌範例：

$: 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 知識中心文章：

核心程序危急

當核心程序在操作期間偵測到內部嚴重錯誤時，會發生核心程序危急。如果在作業系統開機期間發生錯誤，則核心程序可能無法正確載入。這會導致作業系統開機失敗。

核心程序危急錯誤訊息範例：

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 知識中心文章：

網路故障

下列常見原因可能會導致網路故障。

執行個體上未安裝 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 地址的執行個體建立 Amazon Machine Image (AMI) 時，組態檔案可能包含硬式編碼的 IP 地址。

若要更正此錯誤，請將您的網路介面設定為使用 DHCP。

**注意：**您無法更新現有的 AMI。在建立新的 AMI 之前，您必須先將網路介面設定為使用 DHCP。

遺失 ENA 或 Intel 增強型網路驅動程式

如需有關遺失彈性網路介面卡 (ENA) 或 Intel 增強型網路驅動程式的詳細資訊，請參閱 Linux 上的增強型聯網。

網路介面會在啟動時重新命名

若要修正此問題，請將 net.ifnames=0 新增至核心程序命令列，以停用可預測的網路介面名稱。若要執行變數，您必須啟用 ENA 的增強型聯網。

如需有關網路問題的詳細資訊，請參閱設定網路介面的最佳實務。