Fehlerbehebung beim HTTP(S)-Load-Balancing

In dieser Anleitung wird beschrieben, wie Sie Probleme mit der Konfiguration eines externen HTTP(S)-Load-Balancers von Google Cloud beheben können.

Übersicht

Folgende Arten von Problemen werden in dieser Anleitung behandelt:

  • Einrichtungsprobleme, wenn Back-Ends inkompatible Balancing-Modi haben
  • Allgemeine Verbindungsprobleme
  • Probleme mit HTTP/2-Verbindungen zu den Back-Ends
  • Probleme mit externem Back-End und Internet-NEG
  • Probleme mit serverlosen NEG

Hinweis

Machen Sie sich vor der Untersuchung von Problemen mit den folgenden Seiten vertraut.

Zu allgemeinen Verbindungen:

Für Logging und Monitoring:

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:

Fehlerbehebung allgemeiner Verbindungsprobleme

Ungeklärte Fehler 502

Wenn 502-Fehler länger als einige Minuten nach Abschluss der Load-Balancer-Konfiguration bestehen, trifft wahrscheinlich eines hiervon zu:

Führen Sie die folgenden Schritte aus, um den Fehler 502 zu beheben:

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

  2. Prüfen Sie, ob die Antwort 502 vom Load-Balancer bereitgestellt wird oder ob sie von den Back-Ends stammt. 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 502-Antwortcodes sucht.

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

      • Wenn statusDetails eine Erfolgsmeldung wie response_sent_by_backend zurückgibt, stellt das Back-End 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 502-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 Back-End 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 Back-End-Dienstes ausgeführt wird. 
        
$ netstat -tnl | grep PORT
      failed_to_pick_backend

      Der Load-Balancer konnte kein Back-End 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 Back-End-Dienst erhöhen oder prüfen, warum Ihr Dienst so lange für eine Antwort braucht.

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

Traffic vom Load-Balancer an die Instanzen hat eine IP-Adresse im Bereich von 130.211.0.0/22 bis 35.191.0.0/16. Wenn Sie sich Logs für die Instanzen mit Load-Balancing ansehen, wird die Quelladresse des ursprünglichen Clients nicht aufgeführt. Stattdessen erscheinen die Quelladressen aus diesem Bereich.

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

HTTP(S)-Load-Balancing komprimiert oder dekomprimiert die Antworten nicht selbst, kann jedoch von Ihrem Back-End-Dienst generierte Antworten ausliefern, die mit Tools wie gzip oder DEFLATE komprimiert wurden.

Wenn per HTTP(S)-Load-Balancing ausgelieferte Antworten nicht komprimiert sind, aber komprimiert sein sollten, prüfen Sie, ob die auf Ihren Instanzen ausgeführte Webserver-Software dafür konfiguriert ist, Antworten zu komprimieren. 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 HTTP(S)-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 HTTP(S)-Load-Balancer weitergeleitet werden:

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

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 Back-End-Dienst erhöhen.

Fehlerbehebung von HTTP/2 zu den Back-Ends

Ungültiger Wert für das Feld resource.loadBalancingScheme: "EXTERNAL"

Dieses Problem kann auftreten, wenn Sie einen Back-End-Dienst erstellen, ohne die globale Option auszuwählen. Wenn Sie den Befehl gcloud wie unten beschrieben verwenden, werden Sie aufgefordert, eine Region auszuwählen oder den Load-Balancer als global festzulegen:

gcloud beta compute backend-services create service-test \
    --health-checks=hc-test \
    --project=test1 \
    --protocol=http2

Für den folgenden Back-End-Dienst:

- [service-test] choose a region or global:
[1] global
[2] region: [REGION_A_NAME]
[3] region: [REGION_B_NAME]
....
Please enter your numeric choice:

Für den HTTP(S)-Load-Balancer müssen die Back-End-Dienste global sein. Wählen Sie daher Option 1 aus oder geben Sie den Befehl gcloud mit der Option --global aus:

gcloud beta compute backend-services create service-test \
    --health-checks=hc-test \
    --project=test \
    --protocol=http2 \
    --global

Ungeklärte Fehler 502

Prüfen Sie, ob das Back-End 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.

Fehlerbehebung bei Problemen mit externem Back-End und Internet-NEG

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 HTTP(S)-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 bei HTTP(S) zu einem 502-Fehlercode. Prüfen Sie in diesem Fall Folgendes:

  • Fragen Sie 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 Back-End konfiguriert haben, sind Anfragen an das externe Back-End 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 HTTP(S)-Load-Balancer zugreifen und Ihr Quell-Webserver einen Hostnamen erwartet, müssen Sie einen gültigen HTTP-Host-Header an Ihr Back-End senden. Dazu konfigurieren Sie einen benutzerdefinierten Anfrageheader.
  • Sorgen Sie bei der Kommunikation mit einem Back-End über HTTPS oder HTTP2 (wie im Feld protocol des Back-End-Dienstes festgelegt), das als externer INTERNET_FQDN_PORT-Back-End-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-Back-End-Endpunkte werden selbst signierte Zertifikate vom HTTPS-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

Fehlerbehebung bei Problemen mit serverlosen NEGs

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 Functions- 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 HTTP(S)-Load-Balancer weiterhin, Anfragen an den nicht vorhandenen Dienst weiterzuleiten. Dies führt zu einer 404-Antwort.

Im Allgemeinen kann ein externer HTTP(S)-Load-Balancer nicht erkennen, ob die zugrunde liegende serverlose Ressource erwartungsgemäß funktioniert. Dies bedeutet, dass Ihr externer HTTP(S)-Load-Balancer den Traffic nicht automatisch in andere Regionen weiterleitet, wenn Ihr Dienst in einer Region Fehlermeldungen ausgibt, aber die gesamte Cloud Run-, Cloud Functions- 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 Functions: 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.