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:
- Es wurde keine Firewallregel konfiguriert, die Systemdiagnosen zulässt.
- Die Software auf den Back-Ends wird nicht ausgeführt.
Führen Sie die folgenden Schritte aus, um den Fehler 502 zu beheben:
- 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.
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 vonUNHEALTHY
in einen anderen Status geändert wurde. Erfolgreiche Systemdiagnose-Logeinträge werden erst angezeigt, wenn der Systemdiagnose-Prober eine HTTP-Antwort 200 OK vom Back-End erhalten hat. 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:
- 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.
Prüfen Sie den Wert des Felds
statusDetails
.- Wenn
statusDetails
eine Erfolgsmeldung wieresponse_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. - Wenn
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:
- 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 HTTP(S)-Load-Balancer weitergeleitet werden:
- Verwenden Sie den Filter
DEFLATE
. - Fügen Sie dem Antwortheader über das Modul
mod_headers
Vary Accept-Encoding
hinzu.
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:
- Übersicht über externe Back-Ends
- Übersicht über Internet-NEGs
- HTTP(S)-Load-Balancer mit einem externen Back-End 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 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 (nachip4:
). 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 externerINTERNET_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 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
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.