Probleme mit externen Application Load Balancern beheben

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:

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:

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:

  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 statusDetails-Wert, der mit failed_to_pick_backend übereinstimmt, was darauf hinweist, dass der Load Balancer kein fehlerfreies Backend für die Verarbeitung der Anfrage auswählen konnte.

  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-Antwort 200 OK vom Backend erhalten hat.

  3. 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:

    1. 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.

    2. Prüfen Sie den Wert des Felds statusDetails:

      • Wenn statusDetails eine Erfolgsmeldung wie response_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.

  4. 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:

So konfigurieren Sie Apache-Back-Ends für die Bereitstellung komprimierter Antworten, die über einen externen Application Load Balancer weitergeleitet werden:

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:

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 externer INTERNET_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 von INTERNET_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:

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.