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 überprüft den Zustand seiner registrierten Instances entweder mit der von ELB bereitgestellten Standardkonfiguration für die Zustandsprüfung oder mit einer von Ihnen angegebenen benutzerdefinierten Integritätsprüfungskonfiguration. 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: Bei Anfragen zur Integritätsprüfung von Ihrem Load Balancer an Ihre EC2 Instances kommt es zu Zeitüberschreitungen oder sie schlagen zeitweise 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 mit einem Wert von weniger als 200 erhalten, 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.

Lösung 2: Bearbeiten Sie die Sicherheitsgruppe Ihres Load Balancers, um den Datenverkehr zu den Subnetzen und den Instances zuzulassen. EC2

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 Integritätsprüfung wird durch den Port oder eine 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.

Ursache: Auto Scaling verwendet EC2 Statuschecks, um Hardware- und Softwareprobleme mit den Instances zu erkennen, aber der Load Balancer führt Integritätsprüfungen durch, indem er eine Anfrage an die Instance sendet und auf einen 200-Antwortcode wartet oder indem er eine TCP-Verbindung (für eine TCP-basierte Zustandsprüfung) mit der Instance herstellt.

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 könnte die Auto Scaling Scaling-Zustandsprüfung bestehen. Sie würde nicht durch die Auto Scaling Scaling-Richtlinie ersetzt werden, da sie aufgrund der EC2 Statusprüfung als fehlerfrei eingestuft wird.

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 Hinzufügen von ELB-Zustandsprüfungen zu Ihrer Auto Scaling Scaling-Gruppe im Amazon EC2 Auto Scaling Scaling-Benutzerhandbuch.