In dieser Anleitung wird beschrieben, wie Sie Probleme bei der Konfiguration externer Load Balancer beheben können. Machen Sie sich vor der Untersuchung von Problemen mit den folgenden Seiten vertraut:
- Übersicht über externen Application Load Balancer
- Logging und Monitoring für externen 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 aufrufenBack-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:
Allgemeine Verbindungsprobleme beheben
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-Fehlerantwortcode (5XX) und gibt diesen Fehlerantwortcode 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 statusDetails
der Load-Balancer-Logs.
Wenn statusDetails
den Logstring response_sent_by_backend
zurückgibt, leitet der Load-Balancer nur den Antwortcode weiter, der vom Backend an ihn gesendet wurde. In diesem Fall müssen Sie die Fehler bei HTTP-Fehlerantworten auf Ihren Backends beheben.
Für HTTP-Fehlerantworten mit statusDetails
, die nicht mit dem Logstring response_sent_by_backend
übereinstimmen:
Der globale externe Application Load Balancer und der regionale externe Application Load Balancer generieren aussagekräftige HTTP-Antwortfehlercodes wie 503 (Service nicht verfügbar) und 504 (Gateway-Zeitüberschreitung).
Der klassische Application Load Balancer verwendet immer den HTTP-Antwortfehlercode 502.
Konfigurationsänderungen am globalen externen Application Load Balancer, z. B. das Hinzufügen oder Entfernen eines Backend-Dienstes, können dazu führen, dass Nutzer für eine kurze Zeit den HTTP-Antwortfehlercode 502 sehen. Während diese Konfigurationsänderungen global auf GFEs angewendet werden, sehen Sie Logeinträge, bei denen das statusDetails
-Feld mit dem failed_to_pick_backend
-Logstring übereinstimmt.
Wenn HTTP 5XX-Fehler 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:
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
statusDetails
-Wert, der mitfailed_to_pick_backend
übereinstimmt, was darauf hinweist, dass der Load Balancer kein fehlerfreies Backend für die Verarbeitung der Anfrage auswählen konnte.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-Antwort 200 OK vom Backend erhalten hat.Prüfen Sie, ob die Software auf den Back-Ends ausgeführt wird. Prüfen Sie dazu, ob die Antwort 5xx vom Load Balancer bereitgestellt wird oder ob sie von den Backends generiert wurde. Führen Sie diese Schritte aus:
- Verwenden Sie Cloud Logging, um Logs für den Load-Balancer aufzurufen. Außerdem haben Sie die Möglichkeit, eine Abfrage zu erstellen, die nur nach 5xx-Antwortcodes sucht.
Prüfen Sie den Wert des Felds
statusDetails
:- Wenn
statusDetails
eine Erfolgsmeldung wieresponse_sent_by_backend
zurückgibt, stellt das Backend die HTTP 502-Antworten bereit. Prüfen Sie die Logs im Back-End und führen Sie je nach Dienst, der im Back-End ausgeführt wird, weitere Fehlerbehebung aus. - Wenn
statusDetails
eine Fehlermeldung zurückgibt, finden Sie in der folgenden Liste Lösungen für einige häufige Fehler, die 5xx-Antworten verursachen:
Fehlermeldung für statusDetail Mögliche Ursachen und Lösungen failed_to_connect_to_backend
Der Load-Balancer konnte keine Verbindung mit dem Back-End herstellen. Dies kann bedeuten, dass der im Back-End ausgeführte Dienst den im Back-End-Dienst definierten Port nicht überwacht.
Empfehlungen:
- Legen Sie den Port der Systemdiagnose so fest, dass er den Bereitstellungsport verwendet. Das bedeutet, dass das Backend als fehlerhaft erkannt wird, bevor es für die Bereitstellung von realem Traffic zugelassen ist.
- Prüfen Sie mit dem folgenden Befehl, ob ein Dienst auf dem benannten Port des Backend-Dienstes ausgeführt wird:
$ netstat -tnl | grep PORT
failed_to_pick_backend
Der Load-Balancer konnte kein Backend auswählen. Dies kann bedeuten, dass alle Back-Ends fehlerhaft sind. Prüfen Sie, ob Sie die richtigen Firewallregeln für die Systemdiagnosen konfiguriert haben.
backend_connection_closed_before_data_sent_to_client
Das Back-End hat die Verbindung mit dem Load-Balancer unerwartet geschlossen, bevor die Antwort an den Client weitergeleitet wurde. Dies kann passieren, wenn der Load-Balancer Traffic an eine andere Entität sendet. Dabei kann es sich um einen Load-Balancer von einem Drittanbieter handeln, der ein TCP-Zeitlimit aufweist, das kürzer ist als das Zeitlimit des Load-Balancers. Weitere Informationen finden Sie unter Zeitüberschreitungen und Wiederholungsversuche. backend_timeout
Die Antwort des Back-Ends dauerte zu lange. Das Zeitlimit für den Back-End-Dienst ist möglicherweise zu niedrig, sodass der entsprechende Dienst nicht antworten kann. Sie können das Zeitlimit für den Backend-Dienst erhöhen oder prüfen, warum Ihr Dienst so lange für eine Antwort braucht. - Wenn
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).
HTTP-Fehler 408
beheben
Bei HTTP-Traffic entspricht die maximale Zeit, die der Client zum Senden seiner Anfrage benötigt, dem Zeitlimit des Back-End-Diensts. Wenn Sie die HTTP-Antworten 408
mit dem jsonPayload.statusDetail
client_timed_out
sehen, bedeutet dies, dass beim Weiterleiten der Anfrage vom Client oder der Antwort vom Back-End kein ausreichender Fortschritt erzielt wurde. Wenn das Problem auf Clients zurückzuführen ist, die Leistungsprobleme haben, können Sie dieses Problem beheben, indem Sie das Zeitlimit für den Backend-Dienst erhöhen.
Load-Balancing-Traffic hat nicht die Quelladresse des ursprünglichen Clients
Die Quell-IP-Adresse für Pakete, die von den Back-Ends erkannt wird, ist nicht die externe IP-Adresse des Load Balancers. Proxybasierte Load Balancer wie die externen Anwendungs-Load-Balancer verwenden zwei TCP-Verbindungen, um Traffic vom Client an die Back-Ends zu übertragen:
- Verbindung 1, vom ursprünglichen Client zum Load Balancer (GFE- oder Nur-Proxy-Subnetz)
- Verbindung 2, vom Load Balancer (GFE- oder Nur-Proxy-Subnetz) zur Backend-VM oder zum Backend-Endpunkt
Die Quell- und Ziel-IP-Adressen für jede Verbindung unterscheiden sich je nach Typ des verwendeten externen Anwendungs-Load-Balancers. Weitere Informationen finden Sie unter Quell-IP-Adressen für Clientpakete .
Berechtigungsfehler beim Versuch, ein Objekt im Cloud Storage-Bucket anzuzeigen
Um Objekte über das Load-Balancing bereitzustellen, müssen die Cloud Storage-Objekte öffentlich zugänglich sein. Aktualisieren Sie die Berechtigungen der bereitgestellten Objekte, damit sie öffentlich lesbar sind.
URL stellt nicht das erwartete Cloud Storage-Objekt bereit
Das bereitzustellende Cloud Storage-Objekt wird anhand der URL-Zuordnung und der angeforderten URL bestimmt. Wenn der Anfragepfad in der URL-Zuordnung einem Back-End-Bucket zugeordnet ist, wird das Cloud Storage-Objekt bestimmt, indem der vollständige Anfragepfad an den Cloud Storage-Bucket, der in der URL-Zuordnung angegeben ist, angehängt wird.
Beispiel: Wenn Sie /static/*
zu gs://[EXAMPLE_BUCKET]
zuordnen, versucht die Anfrage an https://<GCLB IP or Host>/static/path/to/content.jpg
gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg
bereitzustellen. Wenn das Objekt nicht vorhanden ist, erhalten Sie anstelle des Objekts die folgende Fehlermeldung:
NoSuchKey
The specified key does not exist.
Komprimierung funktioniert nicht
Ein externer Application Load Balancer komprimiert oder dekomprimiert die Antworten nicht selbst, kann jedoch von Ihrem Backend-Dienst generierte Antworten ausliefern, die mit Tools wie gzip oder DEFLATE komprimiert wurden.
Wenn die vom Load-Balancer bereitgestellten Antworten nicht komprimiert sind, obwohl sie dies sein sollten, prüfen Sie, ob die Webserver-Software für Ihre Instanzen so konfiguriert ist, dass Antworten komprimiert werden. Manche Webserver-Software deaktiviert standardmäßig die Komprimierung für Anfragen, die einen Via
-Header enthalten, der angibt, dass die Anfrage von einem Proxy weitergeleitet wurde. Da der externe Application Load Balancer ein Proxy ist, wird jeder Anfrage gemäß HTTP-Spezifikation ein Via
-Header hinzugefügt.
Um die Komprimierung zu aktivieren, müssen Sie womöglich die Standardkonfiguration des Webservers überschreiben, um diesen anzuweisen, Antworten auch dann zu komprimieren, wenn die Anfrage einen Via
-Header beinhaltet.
So konfigurieren Sie nginx-Back-Ends für die Bereitstellung komprimierter Antworten, die über einen externen Application Load Balancer weitergeleitet werden:
- Legen Sie die Anweisung
gzip_proxied
entsprechend fest (z. B. aufany
). - Legen Sie die Anweisung
gzip_vary
aufon
fest.
So konfigurieren Sie Apache-Back-Ends für die Bereitstellung komprimierter Antworten, die über einen externen Application Load Balancer weitergeleitet werden:
- Verwenden Sie den Filter
DEFLATE
. - Fügen Sie dem Antwortheader über das Modul
mod_headers
Vary Accept-Encoding
hinzu.
Fehlerbehebung bei fehlerhaften Back-Ends
Probleme von HTTP/2 mit den Back-Ends beheben
Prüfen Sie, ob das Backend fehlerfrei ist und das HTTP/2-Protokoll unterstützt. Testen Sie dazu die Verbindung zur Back-End-Instanz über HTTP/2. Sorgen Sie dafür, dass die VM HTTP/2-spezifikationskonforme Chiffresammlungen verwendet. Beispielsweise werden bestimmte TLS 1.2-Chiffresammlungen von HTTP/2 nicht zugelassen. Weitere Informationen können Sie der TLS 1.2 Cipher Suite Black List entnehmen.
Nachdem Sie festgestellt haben, dass die VM das HTTP/2-Protokoll verwendet, sollten Sie sich vergewissern, dass die Einstellung Ihrer Firewall den Traffic von Systemdiagnose und Load-Balancer durchlässt.
Wenn keine Probleme mit der Einstellung der Firewall vorliegen, prüfen Sie, ob der Load-Balancer entsprechend der Konfiguration mit dem richtigen Port auf der VM kommuniziert.
Probleme mit externem Backend und Internet-NEG beheben
Machen Sie sich vor der Untersuchung von Problemen mit den folgenden Seiten vertraut:
- Internet-NEGs – Übersicht
- Globalen externen Anwendungs-Load-Balancer mit einem externen Backend einrichten (Internet-NEG)
Traffic erreicht die Endpunkte nicht
Nachdem Sie einen Dienst konfiguriert haben, wird der neue Endpunkt in folgenden Fällen über den externen Application Load Balancer erreichbar:
- Der Endpunkt ist mit der Internet-NEG verknüpft.
- Der verknüpfte FQDN kann erfolgreich DNS-aufgelöst werden, wenn Sie den FQDN-Endpunkttyp verwenden.
- Der Endpunkt ist über das Internet zugänglich.
Wenn der Traffic den Endpunkt nicht erreicht, führt dies zu einem 502-Fehlercode. Fragen Sie dann den DNS-TXT-Eintrag _cloud-eoips.googleusercontent.com
mit einem Tool wie Dig oder nslookup ab. Notieren Sie sich die CIDRs (nach ip4:
). Ihre Firewall oder Cloud Access Control List (ACL) muss diese Bereiche zulassen.
Nachdem Sie ein externes Backend konfiguriert haben, sind Anfragen an das externe Backend mit einem 5xx-Fehler fehlgeschlagen
- Prüfen Sie Logging.
- Sorgen Sie dafür, dass die Netzwerk-Endpunktgruppe mit dem richtigen IP:Port oder FQDN:Port für Ihr externes Back-End konfiguriert wurde.
- Achten Sie bei Verwendung von FQDN darauf, dass er über Google Public DNS aufgelöst werden kann. Mithilfe dieser Schritte oder direkt auf der Weboberfläche können Sie dafür sorgen, dass der FQDN über Google Public DNS aufgelöst werden kann.
- Wenn Sie nur über die externe IP-Adresse auf den Load Balancer zugreifen und Ihr Quell-Webserver einen Hostnamen erwartet, müssen Sie einen gültigen HTTP-Host-Header an Ihr Backend senden. Dazu konfigurieren Sie einen benutzerdefinierten Anfrageheader.
- Sorgen Sie bei der Kommunikation mit einem Backend über HTTPS oder HTTP2 (wie im Feld
protocol
des Backend-Dienstes festgelegt), das als externerINTERNET_FQDN_PORT
-Backend-Endpunkt konfiguriert ist, dafür, dass Ihre Quelle ein gültiges TLS (SSL)-Zertifikat vorlegt und der konfigurierte FQDN mit einem SAN (Subject Alternative Name) in der Zertifikatsliste der SANs übereinstimmt. Ein Zertifikat gilt als gültig, wenn es von einer öffentlichen Zertifizierungsstelle signiert wurde und es nicht abgelaufen ist. - Bei der Verwendung externer
INTERNET_FQDN_PORT
-Backend-Endpunkte werden selbst signierte Zertifikate vom Load Balancer nicht akzeptiert und werden abgelehnt. - Bei der Verwendung von HTTPS oder HTTP/2 mit Endpunkten des Typs
INTERNET_IP_PORT
wird keine SSL-Zertifikats-/SAN-Prüfung durchgeführt. Sie können daher selbstsignierte Zertifikate verwenden. Bei der Verwendung von SSL empfehlen wir die Nutzung vonINTERNET_FQDN_PORT
-Endpunkten, um dafür zu sorgen, dass Serverzertifikate und SANs validiert werden können.
Antworten aus meinem externen Back-End werden nicht von Cloud CDN im Cache gespeichert
Diese Voraussetzungen müssen erfüllt sein:
- Sie haben Cloud CDN im Back-End-Dienst aktiviert. Dieser muss die NEG enthalten, die auf Ihr externes Back-End verweist, indem Sie enableCDN auf "true" setzen.
- Antworten, die von Ihrem externen Back-End bereitgestellt werden, erfüllen die Caching-Anforderungen von Cloud CDN. Sie versenden beispielsweise folgende Antwort-Header von der Quelle:
Cache-Control: public, max-age=3600
Probleme mit serverlosen NEG-Problemen beheben
Machen Sie sich vor der Untersuchung von Problemen mit den folgenden Seiten vertraut:
- Übersicht über serverlose NEGs
- Globalen externen Anwendungs-Load-Balancer mit serverlosen NEGs einrichten
Anfragen führen zu einem 404-Fehler
Stellen Sie sicher, dass die zugrunde liegende serverlose Ressource (z. B. ein App Engine-, Cloud Run-Funktionen- oder Cloud Run-Dienst) noch ausgeführt wird. Wenn die serverlose Ressource gelöscht wird, aber die serverlose NEG noch vorhanden ist, versucht der externe Application Load Balancer weiterhin, Anfragen an den nicht vorhandenen Dienst weiterzuleiten. Dies führt zu einer 404-Antwort.
Im Allgemeinen kann ein externer Application Load Balancer nicht erkennen, ob die zugrunde liegende serverlose Ressource erwartungsgemäß funktioniert. Dies bedeutet, dass Ihr externer Application Load Balancer den Traffic nicht automatisch in andere Regionen weiterleitet, wenn Ihr Dienst in einer Region Fehlermeldungen ausgibt, aber die gesamte Cloud Run-, Cloud Run-Funktionen- oder App Engine-Infrastruktur in dieser Region ordnungsgemäß funktioniert. Testen Sie neue Versionen Ihrer Dienste gründlich, bevor Sie den Nutzer-Traffic an sie weiterleiten.
Umgang mit nicht übereinstimmenden URL-Masken
Wenn das Anwenden der konfigurierten URL-Maske auf eine Nutzeranfrage-URL nicht zu einem Dienstnamen oder aber zu einem nicht vorhandenen Dienstnamen führt, behandelt der Load-Balancer diese Abweichungen je nach der verwendeten serverlosen Computing-Plattform möglicherweise unterschiedlich.
Cloud Run: Bei einer nicht übereinstimmenden URL-Maske gibt der Load-Balancer den HTTP-Fehler 404 (Not Found) aus.
Cloud Run-Funktionen: Bei einer nicht übereinstimmenden URL-Maske gibt der Load-Balancer den HTTP-Fehler 404 (Not Found) aus.
App Engine: Bei einer nicht übereinstimmenden URL-Maske verwendet App Engine dispatch.yaml
und die Standard-Routinglogik von App Engine, um zu ermitteln, an welchen Dienst die Anfrage gesendet werden soll.