Wie kann ich fehlgeschlagene Zustandsprüfungen für Classic Load Balancer beheben und korrigieren?

Lösung

Elastic Load Balancing (ELB) unterstützt Application Load Balancer, Network Load Balancer und Classic Load Balancer. Zur Fehlerbehebung bei fehlgeschlagenen Zustandsprüfungen für den Classic Load Balancer kannst du das Runbook AWSSupport-TroubleshootELBHealthChecks ausführen. Das Runbook automatisiert die Analyse der Zustandsprüfungsmetriken aus dem Amazon-CloudWatch-Dashboard und validiert Netzwerkkonfigurationen für Classic Load Balancer und deine Ziele. Für Ziele, die von AWS Systems Manager verwaltet werden, bietet das Runbook erweiterte Diagnosebefehle mit optionaler Protokollspeicherung in Amazon S3. Diese Lösung gilt für den Instance-Zieltyp.

Bei Instances, die auf Classic Load Balancern ausgeführt werden, können aus den folgenden Gründen Zustandsprüfungen fehlschlagen:

Konnektivitätsprobleme zwischen dem Load Balancer und dem Backend

• Stelle sicher, dass das Backend Datenverkehr für Zustandsprüfungen zulässt. Informationen zur Überprüfung der Sicherheitsgruppenregeln findest du unter Empfohlene Regeln für Load-Balancer-Sicherheitsgruppen. Informationen zur Backend-Instance findest du unter Sicherheitsgruppen für Instances in einer Virtual Private Cloud (VPC).
• Die Netzwerk-Zugriffssteuerungsliste (Netzwerk-ACL) für das Subnetz mit dem Load Balancer und dem Backend muss Datenverkehr für Zustandsprüfungen zulassen. Informationen zur Überprüfung der Netzwerk-ACLs findest du unter Netzwerk-ACLs für Load Balancer in einer VPC.
• Firewalls auf Instance- oder Betriebssystemebene im Backend müssen den Ein- und Ausgang von Datenverkehr für Zustandsprüfungen zulassen.
• Die Speicher- und CPU-Auslastung für die Backend-Instance muss innerhalb akzeptabler Grenzen liegen. Wenn die Speicher- oder CPU-Auslastung zu hoch ist, füge weitere Backends hinzu oder aktualisiere die Backends auf einen größeren Instance-Typ.
• Zusätzliche Ressourcen müssen den Datenverkehr für Zustandsprüfungen ermöglichen. Das Backend leitet die Zustandsprüfungsanforderung möglicherweise an eine zusätzliche Ressource weiter. Wenn die zusätzliche Abhängigkeit nicht reagiert oder zu lange dauert, überschreitet die Zustandsprüfung das Timeout und schlägt fehl. Stelle sicher, dass die zusätzliche Ressource auf die Zustandsprüfungsanforderungen reagiert.

Konfigurationsprobleme mit deiner Anwendung

• Stelle sicher, dass die Anwendung ausgeführt wird. Wenn du beispielsweise Apache auf einer Linux-Instance ausführst, verwende den Befehl sudo service httpd status, um dich zu vergewissern, dass Apache ausgeführt wird.
• Die Anwendung muss auf dem Zustandsprüfungs-Port lauschen. Führe den Befehl netstat -ant auf dem Server aus, um dich zu vergewissern, dass der Server auf dem Zustandsprüfungs-Port lauscht. Überprüfe den Port für die Anwendungskonfiguration, um sicherzustellen, dass er läuft. Um eine TCP-Verbindung zwischen dem Load Balancer und dem Backend zu simulieren, führe den telnet <backend private IP> <health-check port>-Befehl auf der Instance aus. Wenn die Ausgabe Connected (Verbunden) ist, überwacht das Backend den Zustandsprüfungs-Port.
• Die Anwendung muss so eingerichtet sein, dass sie auf Anforderungen mit einem benutzerdefinierten Host-Header reagiert. Für HTTP- und HTTPS-Zustandsprüfungen setzen Classic Load Balancer den Header auf die private IP-Adresse mit der primären Netzwerkschnittstelle des Backends. Sie haben auch den Benutzeragenten auf ELB-HealthChecker/1.0 gesetzt. Wenn das Backend nur auf Anforderungen mit einem benutzerdefinierten Host-Header oder einem Benutzeragenten reagiert, schlägt die Zustandsprüfungsanforderung fehl.
• Die Anwendung muss auf der primären Netzwerkschnittstelle des Backends lauschen. Classic Load Balancer stellen eine Verbindung zur primären Netzwerkschnittstelle der Backend-Instance her. Stelle sicher, dass die Anwendung auf der primären Netzwerkschnittstelle der Backend-Instance lauscht. Dadurch kann das Backend eine Antwort auf die Zustandsprüfungsanforderungen senden.

Fehlende „200 OK“-Antwort vom Backend auf eine Zustandsprüfungsanforderung

• Der Ping-Pfad muss gültig sein. Wenn du die Datei, die im Ping-Pfad im Backend angegeben ist, nicht konfigurierst, reagiert das Backend möglicherweise mit 404 Not Found. Dies führt dazu, dass die Zustandsprüfung fehlschlägt.
  Hinweis: Der Standardwert für den Ping-Pfad ist /index.html. Wenn du keine index.html-Datei im Backend hast, erstelle eine. Alternativ kannst du den Wert des Ping-Pfads in einen Dateinamen im Backend ändern.
• Du hast die Umleitung im Backend nicht richtig konfiguriert. Eine falsch konfigurierte Umleitung kann zu einem 301- oder 302-Antwortcode und zu fehlgeschlagenen Zustandsprüfungen führen. Wenn du beispielsweise im Backend eine Umleitung von HTTP:80 auf HTTPS:443 hast, schlagen die HTTP-Zustandsprüfungen auf Port 80 fehl. Du musst die Zustandsprüfung auf HTTPS und den Zustandsprüfungsport auf 443 ändern. 
  Hinweis: Du kannst die Zustandsprüfungsanforderung simulieren, die der Load Balancer sendet. Verwende den folgenden curl-Befehl von einer Instance im Subnetz, das dem Load Balancer zugeordnet ist:

  curl -Ivk http[s]://<private-IP-address-of-the-backend-instance>:<health-check-port>/<health-check-target-page>

Probleme mit SSL

• Alle Protokolle und Verschlüsselungen müssen übereinstimmen. Für HTTPS- oder SSL-Zustandsprüfungen müssen der Load Balancer und das Backend dasselbe Protokoll und dieselbe Verschlüsselung verwenden. Paketerfassungen, die auf der Backend-Instance aufgenommen werden, zeigen die Verschlüsselungen und Protokolle, die auf dem Load Balancer unterstützt werden. Dies ist in dem Client-Hello zu finden, das der Load Balancer sendet. Die registrierte Backend-Instance muss eine oder mehrere passende Verschlüsselungen und ein Protokoll unterstützen, die der Load Balancer sendet.
• Der Load Balancer sendet den Server Name Indication (SNI)-Header nicht, wenn er eine Zustandsprüfung durchführt. Die Zustandsprüfung ist beispielsweise HTTPS/SSL. Wenn die Backend-Instance so konfiguriert ist, dass sie auf der Grundlage der spezifischen SNI-Informationen auf den SSL-Handshake reagiert, schlägt der SSL-Handshake fehl. Dies liegt daran, dass der Server nach dem Client-Hello ein RST sendet. Konfiguriere den Backend-Server so, dass er unabhängig von der SNI reagiert. Oder du kannst stattdessen die TCP-Zustandsprüfung verwenden.

Ähnliche Informationen

Registrierte Instances für den Classic Load Balancer