Warum ist meine EC2 Linux-Instance nicht erreichbar und besteht eine oder beide Statusprüfungen nicht?

Kurzbeschreibung

Amazon EC2 verwendet zwei Statusprüfungen, um den Zustand von EC2-Instances zu überwachen:

Systemstatusüberprüfungen

Die Systemstatusprüfung erkennt Probleme mit der zugrunde liegenden Hardware einer Instanz. Wenn die zugrunde liegende Hardware aufgrund von Netzwerk-, Hardware- oder Softwareproblemen nicht reagiert oder nicht erreichbar ist, schlägt die Systemstatusprüfung fehl.

Überprüfung des Instanzstatus

Eine fehlgeschlagene Instanzstatusprüfung weist darauf hin, dass die Instance nicht erreichbar ist. Die folgenden häufigen Probleme führen dazu, dass die Überprüfung des Instanzstatus fehlschlägt:

• Fehler beim Booten des Betriebssystems (OS)
• Fehler beim korrekten Mounten der Volumes
• Erschöpfte CPU und Arbeitsspeicher
• Kernel Panic
• Netzwerkausfall

Warnung: Einige der folgenden Lösungen erfordern ein Stoppen und Starten der Instanz. Beachten Sie die folgenden Bedingungen, bevor Sie Ihre Instance beenden und starten:

• Daten, die auf Instance-Speicher-Volumes gespeichert sind, gehen verloren, wenn die Instance gestoppt wird. Bevor Sie die Instanz beenden, stellen Sie sicher, dass Sie die Daten sichern. Im Gegensatz zu Volumes, die von Amazon Elastic Block Store (Amazon EBS) unterstützt werden, sind Instance-Speicher-Volumes kurzlebig und unterstützen keine Datenpersistenz.
• Die statische öffentliche IPv4-Adresse, die Amazon EC2 der Instance beim Start automatisch zugewiesen hat, ändert sich nach dem Stopp und Start. Um eine öffentliche IPv4-Adresse beizubehalten, die sich nicht ändert, wenn die Instance gestoppt wird, verwenden Sie eine Elastic IP-Adresse.

Weitere Informationen finden Sie unter Voraussetzungen für das Stoppen einer Instanz.

Behebung

Um festzustellen, ob die Instanzstatusprüfung oder die Systemstatusprüfung fehlgeschlagen ist, sehen Sie sich die Statusprüfungsmetriken der Instance an.

Wenn die Systemstatusprüfung fehlgeschlagen ist, finden Sie weitere Informationen unter Meine EC2-Linux-Instance hat ihre Systemstatusprüfung nicht bestanden. Wie behebe ich dieses Problem?

Wenn die Überprüfung des Instanzstatus fehlgeschlagen ist, überprüfen Sie die Systemprotokolle der Instanz, um die Ursache des Fehlers zu ermitteln. Verwenden Sie dann eine der folgenden Lösungen, um das Problem zu beheben.

Fehler beim Starten des Betriebssystems

Wenn die Systemprotokolle Startfehler enthalten, finden Sie weitere Informationen unter Wie behebe ich eine EC2-Linux-Instance, die die Instance-Statusprüfung aufgrund von Betriebssystemproblemen nicht bestanden hat?

Fehler beim korrekten Mounten der Volumes

Ein Ausfall des Bereitstellungspunkts kann dazu führen, dass die Überprüfung des Instanzstatus fehlschlägt.

Beispiel für einen Fehler beim Einhängepunkt:

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

Weitere Informationen finden Sie in den folgenden Artikeln im AWS Knowledge Center:

• Fehler „Abhängigkeit fehlgeschlagen“: Warum wechselt meine EC2-Linux-Instance in den Notfallmodus, wenn ich versuche, sie zu starten?
• Fehler „Fehler beim Mounten“ oder „Abhängigkeit fehlgeschlagen“: Wie behebe ich eine EC2-Linux-Instance, die die Instance-Statusprüfung aufgrund von Betriebssystemproblemen nicht bestanden hat?

Wenn Sie einen Instance-Typ von Xen zu Nitro ändern, schlägt der Volume-Mount möglicherweise fehl. Ein Mount-Fehler tritt auf, weil Amazon EBS-Volumes als NVMe-Blockgeräte auf Nitro-basierten Instances verfügbar gemacht werden. Die Gerätenamen sind /dev/nvme0n1, /dev/nvme1n1 usw. Gerätenamen, die Sie in einer Blockgerätezuordnung angeben, werden in NVMe-Gerätenamen (/dev/nvme\ [0-26] n1) umbenannt. Der Blockgerätetreiber weist die NVMe-Gerätenamen möglicherweise in einer anderen Reihenfolge zu als der ursprünglichen Reihenfolge, die Sie in der Blockgerätezuordnung angegeben haben. Um Bereitstellungsfehler auf Nitro-basierten Instances zu vermeiden, empfiehlt es sich, entweder ein Label oder eine UUID für Gerätenamen zu verwenden. Weitere Informationen finden Sie unter Bereitstellen eines Amazon EBS-Volumes für die Verwendung unter Linux.

Erschöpfte CPU und Arbeitsspeicher

Hohe CPU-Auslastung

Wenn die CPUUtilization-Metrik bei oder nahe 100% liegt, verfügt die Instance möglicherweise nicht über genügend Rechenkapazität, um den Kernel auszuführen.

Überprüfen Sie für T2- oder T3-Instances anhand der Amazon CloudWatch-CPU-Kreditkennzahlen, ob die UPC-Gutschriften bei oder nahe Null liegen. Wenn die CPU-Guthaben bei Null liegen, zeigt der CPUUtilization-Messwert ein Sättigungsplateau bei der Basisleistung für die Instance an. Die Basisleistung kann je nach Instance-Typ 20 %, 40 % usw. betragen.

Eine CPU-Auslastung von oder nahe 100% oder bei einem Sättigungsplateau für T2- oder T3-Instances weist darauf hin, dass die Statusüberprüfung aufgrund einer Überauslastung der Ressourcen fehlgeschlagen ist. Informationen zur Behebung dieses Problems finden Sie unter Meine EC2-Linux-Instance hat die Instance-Statusprüfung aufgrund einer Überauslastung ihrer Ressourcen nicht bestanden. Wie behebe ich das Problem?

Blockierte Gerätefehler, Softwarefehler oder Kernel-Panik können zu einem ungewöhnlichen Anstieg der CPU-Auslastung führen. Wenn die CPU-Auslastung bei 100% liegt, überprüfen Sie die Systemprotokolle auf Blockgeräte- oder Speicherfehler oder andere ungewöhnliche Systemfehler. Starten Sie dann die Instanz neu oder beenden Sie sie und starten Sie sie.

Nicht genügend Speicher

Ein hoher Speicherdruck kann dazu führen, dass die Überprüfung des Instance-Status fehlschlägt. Im folgenden Beispielprotokolleintrag hat das Betriebssystem nicht genügend Arbeitsspeicher. Um diesen Fehler zu beheben, beenden Sie den Prozess, der den meisten Speicher verbraucht.

[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

Standardmäßig werden Speicher- und Festplattenmetriken der EC2-Instanz nicht an Amazon CloudWatch gesendet. Sie können den CloudWatch-Agenten jedoch verwenden, um zusätzliche Metriken zu sammeln und zu überwachen.

Um das Problem mit unzureichendem Arbeitsspeicher zu beheben und zu lösen, führen Sie ein Upgrade der Instance auf einen größeren Instance-Typ durch. Oder fügen Sie der Instance Swap-Speicher hinzu, um den Speicherdruck zu verringern. Weitere Informationen finden Sie in den folgenden Artikeln im AWS Knowledge Center:

• Wie ordne ich mithilfe einer Auslagerungsdatei Speicher zu, der als Auslagerungsspeicher in einer Amazon EC2-Instance fungiert?
• Wie ordne ich Speicher zu, der als Auslagerungsspeicher auf einer Amazon EC2-Instance dient, indem ich eine Partition auf meiner Festplatte verwende?

Fehler bei voller Festplatte

Wenn die Systemprotokolle Fehler enthalten, dass die Festplatte voll ist, befindet sich die Instanz aufgrund eines vollen Root-Geräts im Notfallmodus.

Beispiel für ein Systemprotokoll:

$: 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% /

Detaillierte Anweisungen zur Fehlerbehebung und Behebung von Fehlern bei voller Festplatte finden Sie in den folgenden Artikeln im AWS Knowledge Center:

• Meine EC2-Linux-Instance hat die Instance-Statusüberprüfung aufgrund einer Überlastung ihrer Ressourcen nicht bestanden. Wie behebe ich das Problem?
• Wie erhöhe ich die Größe meines EBS-Volumes, wenn ich die Fehlermeldung erhalte, dass auf meinem Dateisystem kein Speicherplatz mehr verfügbar ist?

Kernel Panic

Eine Kernel-Panik tritt auf, wenn der Kernel während des Betriebs einen internen schwerwiegenden Fehler feststellt. Wenn der Fehler während des Betriebssystemstarts auftritt, wird der Kernel möglicherweise nicht richtig geladen. Dies führt zu einem Betriebssystemstartfehler.

Beispiel für eine Kernel-Panik-Fehlermeldung:

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)

Informationen zur Behebung und Behebung eines Kernel-Panikfehlers finden Sie in den folgenden Artikeln im AWS Knowledge Center:

• Warum erhalte ich die Fehlermeldung „Kernel-Panic“, nachdem ich den Kernel aktualisiert oder meine EC2-Linux-Instance neu gestartet habe?
• Wie kehre ich zu einem bekannten stabilen Kernel zurück, nachdem ein Update verhindert hat, dass meine Amazon EC2-Instance erfolgreich neu gestartet wird?

Netzwerkausfall

Die folgenden häufigen Gründe können dazu führen, dass Ihr Netzwerk ausfällt.

Das Cloud-Init-Paket ist nicht auf der Instanz installiert

Das Cloud-Init-Paket wird verwendet, um Netzwerkkonfigurationen beim Start zu aktualisieren.

Um diesen Fehler zu korrigieren, führen Sie den folgenden Befehl aus, um das Cloud-Init-Paket auf Ihrer Instanz zu installieren:

$ sudo yum install cloud-init

Die MAC-Adresse ist in einer Konfigurationsdatei fest codiert

Hartcodierte MAC-Adressen befinden sich in den Linux-Konfigurationsdateien und den Udev-Konfigurationsdateien. Diese Dateien befinden sich normalerweise an den folgenden Speicherorten:

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

Um Netzwerkprobleme zu beheben, die durch eine hartcodierte MAC-Adresse verursacht werden, entfernen Sie die Einträge oder Konfigurationsdateien. Führen Sie beispielsweise den folgenden Befehl aus:

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

Die IP-Adresse ist in einer Konfigurationsdatei fest codiert

Wenn Sie ein Amazon Machine Image (AMI) aus einer Instance mit einer statisch konfigurierten IP-Adresse erstellen, kann die Konfigurationsdatei eine hartcodierte IP-Adresse enthalten.

Um diesen Fehler zu korrigieren, stellen Sie Ihre Netzwerkschnittstelle so ein, dass sie DHCP verwendet.

Hinweis: Sie können bestehende AMIs nicht aktualisieren. Sie müssen die Netzwerkschnittstelle so einrichten, dass sie DHCP verwendet, bevor Sie ein neues AMI erstellen.

Es fehlen ENA- oder Intel-erweiterte Netzwerktreiber

Weitere Informationen zu fehlenden Elastic Network Adaptern (ENAs) oder von Intel erweiterten Netzwerktreibern finden Sie unter Erweitertes Netzwerk unter Linux.

Die Netzwerkschnittstelle wird beim Start umbenannt

Um dieses Problem zu beheben, fügen Sie net.ifnames=0 zur Kernel-Befehlszeile hinzu, um vorhersehbare Netzwerkschnittstellennamen zu deaktivieren. Um die Variable auszuführen, müssen Sie Verstärkte Vernetzung mit der ENA aktivieren.

Weitere Informationen zu Netzwerkproblemen finden Sie unter Bewährte Methoden für die Konfiguration von Netzwerkschnittstellen.

Ähnliche Informationen

Probleme bei Instances mit fehlgeschlagenen Statusüberprüfungen beheben

Warum ist meine EC2-Windows-Instance aufgrund eines Fehlers bei der Systemstatusprüfung oder der Statusprüfung 0/2 ausgefallen?

Warum ist meine EC2-Windows-Instance aufgrund einer fehlgeschlagenen Instanzstatusprüfung ausgefallen?

Arten von Statusprüfungen