Probleme mit internen Anwendungs-Load-Balancern beheben

In dieser Anleitung wird beschrieben, wie Sie Probleme beim Konfigurieren eines internen Google Cloud Application Load Balancers beheben können. Bevor Sie sie durchgehen, machen Sie sich mit folgenden Themen vertraut:

• Übersicht über internen Application Load Balancer
• Proxy-only-subnets
• Logging und Monitoring für internen Application Load Balancer

Häufige Probleme mit dem Network Analyzer beheben

Der Network Analyzer überwacht automatisch die Konfiguration Ihres VPC-Netzwerks und erkennt sowohl suboptimale Konfigurationen als auch Fehlkonfigurationen. Der Analyzer ermittelt Netzwerkfehler, bietet mögliche Ursacheninformationen und schlägt Lösungen vor. Informationen zu den verschiedenen Fehlkonfigurationsszenarien, die automatisch von Network Analyzer erkannt werden, finden Sie in der Dokumentation zu Network Analyzer unter Load-Balancer-Statistiken.

Network Analyzer ist in der Google Cloud Console als Teil von Network Intelligence Center verfügbar.

Network Analyzer aufrufen

Back-Ends haben nicht kompatible Balancing-Modi

Beim Erstellen eines Load-Balancers kann der folgende Fehler auftreten:

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

Dies ist der Fall, wenn Sie versuchen, dasselbe Back-End in zwei verschiedenen Load-Balancern zu verwenden, und die Back-Ends keine kompatiblen Balancing-Modi haben.

Hier finden Sie weitere Informationen:

• Einschränkungen und Richtlinien für Instanzgruppen
• Loading-Modus eines Load-Balancers ändern

Load-Balancing-Traffic hat nicht die Quelladresse des ursprünglichen Clients

Das ist ganz normal. Ein interner Application Load Balancer fungiert als HTTP(S)-Reverse-Proxy (Gateway). Wenn ein Clientprogramm eine Verbindung zur IP-Adresse einer INTERNAL_MANAGED-Weiterleitungsregel herstellt, wird die Verbindung bei einem Proxy beendet. Der Proxy verarbeitet die Anfragen, die über diese Verbindung eingehen. Der Proxy wählt für jede Anfrage ein Back-End aus, um die Anfrage anhand der URL-Zuordnung und anderer Faktoren zu empfangen. Der Proxy sendet die Anfrage dann an das ausgewählte Back-End. Aus der Sicht des Back-Ends ist also die Quelle eines eingehenden Pakets eine IP-Adresse aus dem Proxy-Only-Subnetz der Region.

Anfragen werden vom Load-Balancer abgelehnt

Der Proxy wählt für jede Anfrage ein Back-End aus, um sie anhand eines Pfad-Matchers in der URL-Zuordnung des Load-Balancers zu empfangen. Wenn für die URL-Zuordnung kein Pfad-Matcher für eine Anfrage definiert ist, kann kein Back-End-Dienst ausgewählt werden. Daher wird der HTTP-Antwortcode 404 (nicht gefunden) zurückgegeben.

Load-Balancer stellt keine Verbindung zu Back-Ends her

Die Firewalls, die Ihre Back-End-Server schützen, müssen so konfiguriert sein, dass eingehender Traffic von den Proxys im Proxy-Only-Subnetzbereich zugelassen wird, den Sie der Region des internen HTTP(S)-Load-Balancers zugewiesen haben.

Die Proxys stellen über die Verbindungseinstellungen, die in der Konfiguration Ihres Back-End-Dienstes festgelegt sind, eine Verbindung zu Back-Ends her. Wenn diese Werte nicht mit der Konfiguration der Server übereinstimmen, die auf Ihren Back-Ends ausgeführt werden, kann der Proxy keine Anfragen an die Back-Ends weiterleiten.

Systemdiagnosetests können die Back-Ends nicht erreichen

Wenn Sie prüfen möchten, ob der Systemdiagnose-Traffic Ihre Back-End-VMs erreicht, aktivieren Sie das Logging für Systemdiagnosen und suchen Sie nach erfolgreichen Logeinträgen.

Clients können keine Verbindung zum Load-Balancer herstellen

Die Proxys überwachen Verbindungen zu der IP-Adresse und dem Port des Load-Balancers, die in der Weiterleitungsregel konfiguriert sind, z. B. 10.1.2.3:80. Dabei ist das Protokoll in der Weiterleitungsregel festgelegt (HTTP oder HTTPS). Wenn Ihre Clients keine Verbindung herstellen können, prüfen Sie, dass sie die richtige Adresse, den richtigen Port und das richtige Protokoll verwenden.

Achten Sie darauf, dass keine Firewall den Traffic zwischen Ihren Clientinstanzen und der IP-Adresse mit Load-Balancing blockiert.

Achten Sie darauf, dass sich die Clients in derselben Region wie der Load-Balancer befinden. Das interne HTTP(S)-Load-Balancing ist ein regionales Produkt. Daher müssen sich alle Clients und Back-Ends in derselben Region wie die Load-Balancer-Ressource befinden.

Beschränkung der Organisationsrichtlinie für freigegebene VPC

Wenn Sie eine freigegebene VPC verwenden und keinen neuen internen Application Load Balancer in einem bestimmten Subnetz erstellen können, kann eine Organisationsrichtlinie die Ursache sein. Fügen Sie in der Organisationsrichtlinie das Subnetz der Liste zulässiger Subnetze hinzu oder wenden Sie sich an den Administrator Ihrer Organisation. Weitere Informationen finden Sie unter constraints/compute.restrictSharedVpcSubnetworks.

Load-Balancer verteilt Traffic nicht gleichmäßig auf Zonen

Möglicherweise stellen Sie ein Ungleichgewicht beim Traffic des internen Application Load Balancers zwischen Zonen fest. Dies kann insbesondere bei einer geringen Auslastung (< 10%) Ihrer Backend-Kapazität passieren.

Dieses Verhalten kann sich auf die Gesamtlatenz auswirken, da Traffic nur an wenige Server in einer einzigen Zone gesendet wird.

Um den Traffic gleichmäßiger über die Zonen zu verteilen, können Sie folgende Konfigurationsänderungen vornehmen:

• Verwenden Sie den Balancing-Modus RATE mit einer niedrigen max-rate-per-instance-Zielkapazität.
• Verwenden Sie die Trafficrichtlinie LocalityLbPolicy des Back-Ends mit dem Load-Balancing-Algorithmus LEAST_REQUEST.

Ungeklärte 5xx Fehler

Bei Fehlerbedingungen, die durch ein Kommunikationsproblem zwischen dem Load-Balancer-Proxy und seinen Back-Ends verursacht werden, generiert der Load-Balancer einen HTTP-Statuscode (5xx) und gibt diesen Statuscode an den Client zurück. Nicht alle HTTP 5xx-Fehler werden vom Load-Balancer generiert. Wenn ein Backend beispielsweise eine HTTP 5xx-Antwort an den Load-Balancer sendet, leitet der Load-Balancer diese Antwort an seinen Client weiter. Informationen dazu, ob eine HTTP-5xx-Antwort von einem Backend weitergeleitet wurde oder ob sie vom Load-Balancer-Proxy generiert wurde, finden Sie im Feld proxyStatus der Load-Balancer-Logs.

Konfigurationsänderungen am internen Anwendungs-Load-Balancer, z. B. das Hinzufügen oder Entfernen eines Backend-Dienstes, können dazu führen, dass Nutzer den HTTP-Statuscode 503 innerhalb eines kurzen Zeitraums sehen. Während diese Konfigurationsänderungen global auf Envoys angewendet werden, sehen Sie Logeinträge, bei denen das proxyStatus-Feld mit dem connection_refused-Logstring übereinstimmt.

Wenn die HTTP-Statuscodes 5xx länger als einige Minuten nach Abschluss der Load-Balancer-Konfiguration bestehen, führen Sie die folgenden Schritte aus, um HTTP-5xx-Antworten zu beheben:

1. Prüfen Sie, ob eine Firewallregel konfiguriert ist, die Systemdiagnosen zulässt. Ist dies nicht der Fall, enthalten die Load Balancer-Logs in der Regel einen proxyStatus-Wert, der mit destination_unavailable übereinstimmt, was darauf hinweist, dass der Load Balancer das Backend als nicht verfügbar betrachtet.

2. Prüfen Sie, ob der Systemdiagnose-Traffic Ihre Backend-VMs erreicht. Aktivieren Sie dazu das Logging der Systemdiagnose und suchen Sie nach erfolgreichen Logeinträgen.

   Bei neuen Load-Balancern bedeutet das Fehlen erfolgreicher Logeinträge für Systemdiagnosen nicht, dass der Systemdiagnose-Traffic Ihre Back-Ends nicht erreicht. Dies kann bedeuten, dass der anfängliche Systemstatus des Back-Ends noch nicht von UNHEALTHY in einen anderen Status geändert wurde. Erfolgreiche Systemdiagnose-Logeinträge werden erst angezeigt, wenn der Systemdiagnose-Prober eine HTTP-200 OK-Antwort vom Backend erhalten hat.

3. Prüfen Sie, ob der Keepalive-Konfigurationsparameter für die auf der Backend-Instanz ausgeführte HTTP-Serversoftware nicht kleiner als die Keepalive-Zeitüberschreitung des Load-Balancers ist, dessen Wert auf 10 Minuten (600 Sekunden) fest eingestellt und nicht konfigurierbar ist.

   Der Load-Balancer generiert einen HTTP-5xx-Antwortcode, wenn die Verbindung zum Backend beim Senden der HTTP-Anfrage unerwartet geschlossen wurde oder bevor die vollständige HTTP-Antwort empfangen wurde. Dies kann vorkommen, weil der Keepalive-Konfigurationsparameter für die auf der Backend-Instanz ausgeführte Webserver-Software unter dem festen Keepalive-Zeitlimit des Load-Balancers liegt. Achten Sie darauf, dass die Keepalive-Zeitlimitkonfiguration für HTTP-Serversoftware auf jedem Backend auf etwas mehr als 10 Minuten festgelegt ist (der empfohlene Wert beträgt 620 Sekunden).

Beschränkungen

Wenn bei der Verwendung eines internen Application Load Balancers mit anderen Google Cloud-Netzwerkfunktionen Probleme auftreten, beachten Sie die aktuellen Beschränkungen hinsichtlich der Kompatibilität.