Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Fehlerbehebung beim Classic Load Balancer: Zustandsprüfungen

Ihr Load Balancer prüft den Zustand der registrierten Instances mit der Standard-Zustandsprüfungskonfiguration von Elastic Load Balancing oder mit einer benutzerdefinierten Zustandsprüfungskonfiguration, die Sie angeben. Die Zustandsprüfungskonfiguration enthält Informationen wie Protokoll, Ping-Port, Ping-Pfad, Reaktionszeitüberschreitung und Zustandsprüfungsintervall. Eine Instance wird als fehlerfrei betrachtet, wenn der Antwortcode 200 innerhalb des Zustandsprüfungsintervalls zurückgegeben wird. Weitere Informationen finden Sie unter Zustandsprüfungen für die Instances für Ihren Classic Load Balancer.

Wenn der aktuelle Status einiger oder aller Ihrer Instances OutOfService ist und das Beschreibungsfeld folgende Nachricht anzeigt: Instance has failed at least the Unhealthy Threshold number of health checks consecutively, sind die Instances bei der Load Balancer-Zustandsprüfung fehlgeschlagen. Nachfolgend finden Sie mögliche Probleme, die potenziellen Ursachen und was Sie tun müssen, um das Problem zu lösen.

Zustandsprüfungs-Zielseitenfehler

Problem: Eine HTTP GET-Anforderung für die Instance auf dem angegebenen Ping-Port und dem Ping-Pfad (z. B. HTTP:80/index.html) erhält einen anderen Antwortcode als 200.

Cause 1: Es ist keine Zielseite in der Instance konfiguriert.

Solution 1: Erstellen Sie eine Zielseite (z. B. index.html) auf jeder registrierten Instance und geben Sie den Pfad als Ping-Pfad an.

Cause 2: Der Wert des Inhaltslängen-Headers (Content-Length) ist in der Antwort nicht festgelegt.

Solution 2: Wenn die Antwort einen Textkörper (body) enthält, setzen Sie den Inhaltslängen-Header entweder auf einen Wert größer als oder gleich null oder legen Sie den Wert für „Transfer-Encoding“ auf „Chunked“ fest.

Cause 3: Die Anwendung ist nicht für den Empfang von Anfragen aus dem Load Balancer oder für die Rückgabe eines 200-Antwortcodes konfiguriert.

Solution 3: Überprüfen Sie die Anwendung auf Ihrer Instance, um die Ursache herauszufinden.

Zeitlimit bei der Verbindung zu den Instances ist überschritten

Problem: Zustandsprüfungsanforderungen aus Ihrem Load Balancer an Ihre EC2-Instances überschreiten das Zeitlimit oder schlagen zwischendurch fehl.

Überprüfen Sie zunächst das Problem, indem Sie eine direkte Verbindung mit der Instance herstellen. Wir empfehlen, dass Sie eine Verbindung mit Ihrer Instance innerhalb des Netzwerks über die private IP-Adresse der Instance herstellen.

Verwenden Sie den folgenden Befehl für eine TCP-Verbindung:

telnet private-IP-address-of-the-instance port

Verwenden Sie den folgenden Befehl für eine HTTP- oder HTTPS-Verbindung:

curl –I private-IP-address-of-the-instance:port/health-check-target-page

Wenn Sie eine HTTP/HTTPS Verbindung verwenden und eine Antwort erhalten, die nicht 200 ist, finden Sie weitere Informationen unter. Zustandsprüfungs-Zielseitenfehler Wenn Sie eine direkte Verbindung mit der Instance herstellen können, überprüfen Sie Folgendes:

Cause 1: Die Instance reagiert nicht innerhalb des konfigurierten Antwort-Zeitüberschreitungslimits.

Solution 1: Passen Sie die Antwort-Zeitüberschreitungseinstellungen in Ihrer Load Balancer-Zustandsprüfungskonfiguration an.

Cause 2: Die Instance ist stark ausgelastet und benötigt länger als das konfigurierte Antwort-Zeitüberschreitungslimit, um zu reagieren.

Lösung 2:

Cause 3: Wenn Sie eine HTTP- oder eine HTTPS-Verbindung verwenden und die Zustandsprüfung auf einer im Ping-Pfad angegebenen Zielseite durchgeführt wird (z. B. HTTP:80/index.html), braucht die Zielseite möglicherweise länger als Ihre konfigurierte Zeitüberschreitung.

Solution 3: Verwenden Sie eine einfachere Zustandsprüfungs-Zielseite oder passen Sie das Intervall für die Integritätsprüfungseinstellungen an.

Authentifizierung mit öffentlichem Schlüssel schlägt fehl

Problem: Ein Load Balancer, der zur Verwendung des HTTPS- oder SSL-Protokolls mit aktivierter Backend-Authentifizierung konfiguriert ist, schlägt bei Authentifizierung mit öffentlichem Schlüssel fehl.

Cause: Der öffentliche Schlüssel im SSL-Zertifikat stimmt nicht mit dem öffentlichen Schlüssel auf dem Load Balancer überein. Verwenden Sie den Befehl s_client, um die Liste der Serverzertifikate in der Zertifikatkette anzuzeigen. Weitere Informationen finden Sie unter s_client in der OpenSSL-Dokumentation.

Solution: Sie müssen möglicherweise Ihr SSL-Zertifikat aktualisieren. Wenn Ihr SSL-Zertifikat auf dem neuesten Stand ist, versuchen Sie, es erneut auf Ihrem Load Balancer zu installieren. Weitere Informationen finden Sie unter Ersetzen des SSL-Zertifikats für Ihren Classic Load Balancer.

Instance empfängt keinen Datenverkehr vom Load Balancer

Problem: Die Sicherheitsgruppe für die Instance blockiert den Datenverkehr vom Load Balancer.

Führen Sie eine Paketerfassung auf der Instance durch, um das Problem zu bestätigen. Verwenden Sie den folgenden Befehl:

# tcpdump port health-check-port

Cause 1: Die der Instance zugeordnete Sicherheitsgruppe lässt keinen Datenverkehr vom Load Balancer zu.

Solution 1: Bearbeiten Sie die Instance-Sicherheitsgruppe, um Datenverkehr vom Load Balancer zu ermöglichen. Fügen Sie eine Regel hinzu, die den gesamten Datenverkehr aus der Load Balancer-Sicherheitsgruppe zulässt.

Ursache 2: Die Sicherheitsgruppe für Ihren Load Balancer lässt keinen Datenverkehr zu den EC2-Instances zu.

Solution 2: Bearbeiten Sie die Sicherheitsgruppe für Ihren Load Balancer, um Datenverkehr an die Subnetze und die EC2-Instances zu ermöglichen.

Weitere Informationen über das Verwalten von Sicherheitsgruppen finden Sie unter Konfigurieren von Sicherheitsgruppen für Ihren Classic Load Balancer.

Ports auf Instance sind nicht offen

Problem: Die vom Load Balancer an die EC2-Instance gesendete Zustandsprüfung wird vom Port oder einer Firewall blockiert.

Überprüfen Sie das Problem, indem Sie den folgenden Befehl eingeben:

netstat –ant

Cause: Der angegebene Zustandsprüfungs-Port oder der Listener-Port (sofern anders konfiguriert) ist nicht offen. Sowohl der für die Zustandsprüfung angegebene Port als auch der Listener-Port muss geöffnet und im Überwachungsmodus sein.

Solution: Öffnen Sie den Listener-Port und die in der Zustandsprüfung angegebene Port-Konfiguration (falls anders konfiguriert) auf Ihren Instances, um Datenverkehr vom Load Balancer zu erhalten.

Instances in einer Auto-Scaling-Gruppe schlagen bei der ELB-Zustandsprüfung fehl

Problem: Instances in Ihrer Auto Scaling-Gruppe bestehen die standardmäßige Auto-Scaling-Zustandsprüfung, aber nicht die ELB-Zustandsprüfung.

Cause (Ursache): Auto Scaling verwendet EC2-Statusüberprüfungen zur Erkennung von Hardware- und Softwareproblemen bei den Instances, aber der Load Balancer führt Zustandsprüfungen durch, indem er eine Anforderung an die Instance sendet und auf einen 200-Antwortcode wartet oder durch Herstellen einer TCP-Verbindung (für eine TCP-basierte Zustandsprüfung) mit der Instance.

Eine Instance kann bei einer ELB-Zustandsprüfung fehlschlagen, weil eine Anwendung, die in der Instance ausgeführt wird, Probleme verursacht, die dazu führen, dass der Load Balancer die Instance außer Betrieb nimmt. Diese Instance würde die Auto-Scaling-Zustandsprüfung bestehen; sie kann nicht von der Auto-Scaling-Richtlinie ersetzt werden, da sie basierend auf der EC2-Zustandsprüfung als fehlerfrei gilt.

Solution (Lösung): Verwenden Sie die ELB-Zustandsprüfung für Ihre Auto-Scaling-Gruppe. Wenn Sie die ELB-Zustandsprüfung verwenden, bestimmt Auto Scaling den Zustand Ihrer Instances anhand der Ergebnisse der Instance-Zustandsprüfung und der ELB-Zustandsprüfung. Weitere Informationen finden Sie unter Anhängen von Zustandsprüfungen für Elastic Load Balancing an Ihre Auto-Scaling-Gruppe im Benutzerhandbuch zu Amazon EC2 Auto Scaling.