Wieso kann meine EC2-Linux-Instance nicht erreicht werden und mindestens eine der beiden Statusprüfungen schlägt fehl?

Lesedauer: 8 Minute

Meine Amazon-Elastic-Compute-Cloud-Linux-Instance (Amazon EC2) ist nicht erreichbar und eine oder beide Statusprüfungen schlagen fehl.

Kurzbeschreibung

Amazon EC2 überwacht den Zustand jeder EC2-Instance mit zwei Statusprüfungen:

Überprüfung des Systemstatus

Die Systemstatusprüfung erkennt Probleme mit dem zugrunde liegenden Host, auf dem Ihre Instance ausgeführt wird. Wenn der zugrunde liegende Host aufgrund von Netzwerk-, Hardware- oder Softwareproblemen nicht reagiert oder nicht erreichbar ist, schlägt diese Statusprüfung fehl.

Überprüfung des Instance-Status

Der Fehler bei der Instance-Statusprüfung weist auf ein Problem mit der Erreichbarkeit der Instance hin. Dieses Problem tritt aufgrund von Fehlern auf Betriebssystemebene wie den folgenden auf:

Fehler beim Hochfahren des Betriebssystems
Fehler bei der korrekten Bindungsbereitstellung der Volumes
CPU und Speicher erschöpft
Kernel-Panik
Netzwerk konnte nicht gestartet werden

Warnung: Einige dieser Auflösungen erfordern einen Stopp und Start der Instance. Beachten Sie vor dem Stoppen und Starten Ihrer Instance die folgenden Bedingungen:

Instance-Speicherdaten gehen verloren, wenn Sie eine Instance anhalten. Wenn Ihre Instance durch den Instance-Speicher gesichert ist oder über Instance-Speicher-Volumes verfügt, die Daten enthalten, gehen die Daten verloren, wenn Sie die Instance stoppen. Weitere Informationen finden Sie unter Bestimmen des Root-Gerätetyps Ihrer Instance.
Wenn Ihre Instance Teil einer Amazon EC2-Auto-Scaling-Gruppe ist, kann das Stoppen der Instance die Instance beenden. Wenn Sie die Instance mit Amazon EMR, AWS CloudFormation oder AWS Elastic Beanstalk gestartet haben, ist Ihre Instance möglicherweise Teil einer AWS-Auto-Scaling-Gruppe. Die Beendigung der Instance in diesem Szenario hängt von den Instance-Skalierungsschutzeinstellungen für Ihre Auto-Scaling-Gruppe ab. Wenn Ihre Instance Teil einer Auto-Scaling-Gruppe ist, entfernen Sie die Instance vorübergehend aus der Auto-Scaling-Gruppe, bevor Sie mit den Auflösungsschritten beginnen.
Durch das Stoppen und Starten einer Instance wird die öffentliche IP-Adresse wieder im dynamischen IP-Pool von AWS freigegeben. Es ist eine bewährte Methode, beim Weiterleiten von externem Datenverkehr an Ihre Instance eine Elastic-IP-Adresse anstelle einer öffentlichen IP-Adresse zu verwenden. Wenn Sie Amazon Route 53 verwenden, müssen Sie möglicherweise die Route-53-DNS-Datensätze aktualisieren, wenn sich die öffentliche IP ändert.

Weitere Informationen finden Sie unter Stoppen und starten Sie Ihre Instance.

Auflösung

1. Ermitteln Sie, ob die Instance-Statusprüfung oder die Systemstatusprüfung fehlgeschlagen ist, indem Sie die Metriken der Instance-Statusprüfung anzeigen.

2. Wenn die Systemstatusprüfung fehlgeschlagen ist, lesen Sie Die Systemstatusprüfung für meine EC2-Linux-Instance ist fehlgeschlagen. Wie kann ich dies beheben?

Wenn die Statusprüfung der Instance fehlgeschlagen ist, überprüfen Sie die Systemprotokolle der Instance, um die Ursache des Fehlers zu ermitteln. Verwenden Sie abhängig von den Daten in den Systemprotokollen eine dieser Auflösungen:

Fehler beim Hochfahren des Betriebssystems

Wenn die Systemprotokolle Startfehler enthalten, lesen Sie Die Instance-Statusprüfung für meine EC2-Linux-Instance ist aufgrund von Problemen mit dem Betriebssystem fehlgeschlagen. Wie kann ich dies beheben?

Fehler bei der korrekten Bindungsbereitstellung der Volumes

Eine Instance-Statusprüfung kann aufgrund eines Bindungsbereitstellungs-Punktes fehlschlagen, der nicht korrekt mounten kann, wie in diesem Beispiel gezeigt:

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

CPU und Speicher erschöpft

Hohe CPU-Auslastung

Wenn die CPU-Auslastungs-Metrik bei oder nahe 100 % liegt, dann verfügt die Instance möglicherweise nicht über genügend Rechenkapazität zum Ausführen des Kernels.

Überprüfen Sie für T2- oder T3-Instances die CPU-Kreditmetriken in der Tabelle Amazon-CloudWatch-Metriken, um festzustellen, ob die CPU-Guthaben bei oder nahe Null liegen. Wenn die CPU-Credits bei Null liegen, zeigt die CPU-Auslastungs-Metrik ein Sättigungsplateau bei der Basisleistung für die Instance. Die Basisleistung kann je nach Instance-Typ 20 %, 40 % usw. betragen.

CloudWatch-Metriken, welche die CPU-Auslastung bei oder nahe 100 % oder auf einem Sättigungsplateau für T2- oder T3-Instances anzeigen, weisen darauf hin, dass die Statusüberprüfung aufgrund einer Überauslastung der Ressourcen der Instance fehlgeschlagen ist. Anweisungen zur Behebung dieses Problems finden Sie unter Die Instance-Statusprüfung für meine EC2-Linux-Instance ist aufgrund einer Überlastung ihrer Ressourcen fehlgeschlagen. Wie kann ich dies beheben?

Blockgerätefehler, Softwarefehler oder Kernel-Panik können zu einem ungewöhnlichen Anstieg der CPU-Auslastung führen. Wenn die CPU-Auslastungs-Metrik bei 100 % liegt und die Systemprotokolle Fehler im Zusammenhang mit Blockgeräten oder Speicherproblemen oder andere ungewöhnliche Systemfehler enthalten, starten Sie die Instance neu oder stoppen und starten Sie sie.

Nicht genügend Speicher

Ein hoher Speicherdruck kann dazu führen, dass die Instance-Statusprüfung fehlschlägt. In diesem Beispiel hat das Betriebssystem nicht genügend Speicher und stoppt 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

EC2-Speicher- und Festplattenmetriken werden standardmäßig nicht an CloudWatch gesendet. Sie können jedoch zusätzliche Metriken mit dem CloudWatch-Agenten zur Überwachung an CloudWatch senden.

Um das Speicherproblem zu beheben, sollten Sie die Instance auf einen größeren Instance-Typ aktualisieren. Oder fügen Sie zur Instance Swap-Speicher hinzu, um den Speicherdruck zu verringern. Weitere Informationen finden Sie in diesen Themen:

Festplatten-Fehler

Wenn die Systemprotokolle Festplatte-voll-Fehler enthalten, ist die Instance möglicherweise in den Notfallmodus gewechselt, da das Root-Gerät voll ist.

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

Ausführliche Anweisungen zum Beheben von Festplatte-voll-Fehlern finden Sie unter:

Kernel-Panik

Ein Kernel-Panikfehler tritt auf, wenn der Kernel während des Betriebs einen schwerwiegenden, internen Fehler erkennt. Wenn der Fehler beim Hochfahren des Betriebssystems auftritt, kann der Kernel möglicherweise nicht richtig geladen werden. Dies kann zu einem Betriebssystemstart-Fehler führen. Dies ist ein 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 zum Beheben eines Kernel-Panik-Fehlers finden Sie unter:

Netzwerk konnte nicht gestartet werden

Das Netzwerk kann aus folgenden Gründen nicht verfügbar sein:

„cloudInit“-Paket fehlt

Wenn in der Instance das Paket cloud-init fehlt, kann dies dazu führen, dass das Netzwerk nicht gestartet wird. Das Paket cloud-init ist nützlich, um die Netzwerkkonfiguration beim Start zu aktualisieren.

Um diesen Fehler zu beheben, können Sie das Paket cloud-init in Ihrer Instance installieren.

$ sudo yum install cloud-init

Die MAC-Adresse ist in einer Konfigurationsdatei fest codiert

Wenn Ihre MAC-Adresse in einer Konfigurationsdatei fest codiert ist, können Probleme auftreten, die dazu führen, dass Ihr Netzwerk nicht angezeigt wird.

Hartcodierte MAC-Adressen finden Sie in den Linux-Konfigurationsdateien und „udev“ -Konfigurationsdateien, z. B. in 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, wenn Ihre MAC-Adresse in Ihrer Instance fest codiert ist, müssen Sie die Einträge oder Konfigurationsdateien entfernen. Beispiel:

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

Die IP-Adresse ist in einer Konfigurationsdatei fest codiert

Wenn Ihre IP-Adresse in einer Konfigurationsdatei fest codiert ist, können Probleme auftreten, die dazu führen, dass Ihr Netzwerk nicht angezeigt wird. Dies tritt auf, wenn ein Amazon Machine Image (AMI) von einer Instance mit einer statisch konfigurierten IP-Adresse abgerufen wird.

Um diesen Fehler zu beheben, stellen Sie Ihre Netzwerkschnittstelle auf die Verwendung von DHCP ein.

Hinweis: Sie können bestehende AMIs nicht aktualisieren. Das Einstellen der Netzwerkschnittstelle für die Verwendung von DHCP muss auf der Instance erfolgen, bevor ein neues AMI erstellt wird.

Fehlende ENA- oder Intel Enhanced-Netzwerktreiber

Wenn in der Instance die Elastic Network Adapter (ENA) oder Intel-Enhanced-Netzwerktreiber fehlen, kann dies dazu führen, dass das Netzwerk fehlschlägt.

Weitere Informationen finden Sie unter Enhanced Networking unter Linux.

Die Netzwerkschnittstelle wird beim Start umbenannt

Wenn die Netzwerkschnittstelle beim Start der Instance umbenannt wird, kann dies zu Netzwerkproblemen führen. Um diesen Fehler zu beheben, deaktivieren Sie vorhersehbare Netzwerkschnittstellennamen, indem Sie net.ifnames=0 zur Kernel-Befehlszeile hinzufügen. Dazu müssen Sie Enhanced Networking mit der ENA aktivieren.

Weitere Informationen zu Netzwerkproblemen finden Sie unter Best Practices für die Konfiguration von Netzwerkschnittstellen.

Relevanter Inhalt

Wie kann ich häufige Probleme beheben, die dazu führen, dass meine Lightsail-Instance nicht mehr reagiert?
AWS OFFICIALAktualisiert vor 2 Jahren
Warum schlägt mein TransactWriteItems-API-Aufruf in Amazon DynamoDB fehl?
AWS OFFICIALAktualisiert vor 9 Monaten
Warum kann ich mich nicht mit meiner EC2-Instance verbinden?
AWS OFFICIALAktualisiert vor 2 Jahren
Wie funktionieren ELB-DNS und Verkehrsfluss mit verschiedenen zonenübergreifenden Load-Balancing-Konfigurationen?
AWS OFFICIALAktualisiert vor einem Monat