Fehlerbehebung bei internen Passthrough-Network Load Balancern

In dieser Anleitung wird beschrieben, wie Sie Probleme mit der Konfiguration eines internen Google Cloud-Passthrough-Network Load Balancers 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

Wenn Sie keine Verbindung zu Ihrem internen Passthrough-Network Load Balancer herstellen können, überprüfen Sie Ihr System auf folgende häufige Probleme.

Firewallregeln bestätigen

  • Sorgen Sie dafür, dass Firewallregeln für zulässigen eingehenden Traffic definiert sind, durch die Systemdiagnosen von Backend-VMs erlaubt werden.
  • Achten Sie darauf, dass Firewallregeln eingehenden Traffic von den Clients zu den Backend-VMs zulassen.
  • Sorgen Sie dafür, dass relevante Firewallregeln vorhanden sind, damit Traffic die Backend-VMs an den vom Load-Balancer verwendeten Ports erreichen kann.
  • Wenn Sie Zieltags für die Firewallregeln verwenden, achten Sie darauf, dass die Backend-VMs des Load-Balancers entsprechend getaggt sind.

Informationen zum Konfigurieren von Firewallregeln, die für Ihren internen Passthrough-Network Load Balancer erforderlich sind, finden Sie unter Firewallregeln konfigurieren.

Prüfen Sie, ob die Gastumgebung auf der Backend-VM ausgeführt wird.

Wenn Sie eine Verbindung zu einer fehlerfreien Backend-VM, aber keine Verbindung zum Load-Balancer herstellen können, wird die Gastumgebung (früher Windows-Gastumgebung oder Linux-Gastumgebung) auf der VM möglicherweise nicht ausgeführt oder kann nicht mit dem Metadatenserver (metadata.google.internal, 169.254.169.254) kommunizieren.

Überprüfen Sie Folgendes:

  • Stellen Sie sicher, dass die Gastumgebung auf der Back-End-VM installiert ist und ausgeführt wird.
  • Stellen Sie sicher, dass die Firewallregeln im Gastbetriebssystem der Backend-VM (iptables oder Windows Firewall) den Zugriff auf den Metadatenserver nicht blockieren.

Prüfen Sie, ob Backend-VMs an den Load-Balancer gesendete Pakete akzeptieren

Jede Backend-VM muss so konfiguriert sein, dass sie Pakete akzeptiert, die an den Load-Balancer gesendet werden. Das heißt, das Ziel von Paketen, die an die Backend-VMs geliefert werden, ist die IP-Adresse des Load-Balancers. In den meisten Fällen wird dies mit einer lokalen Route getan.

Bei VMs, die aus Google Cloud-Images erstellt wurden, installiert der Gast-Agent die lokale Route für die IP-Adresse des Load-Balancers. Google Kubernetes Engine-Instanzen, die auf Container-Optimized OS basieren, implementieren dies stattdessen mit iptables.

Auf einer Linux-Back-End-VM können Sie prüfen, ob die lokale Route vorhanden ist, indem Sie den folgenden Befehl ausführen. Ersetzen Sie LOAD_BALANCER_IP durch die IP-Adresse des Load-Balancers:

sudo ip route list table local | grep LOAD_BALANCER_IP

Prüfen Sie die Dienst-IP-Adresse und die Portbindung auf den Backend-VMs.

Pakete, die an einen internen Passthrough-Network Load Balancer gesendet werden, kommen bei Backend-VMs mit der Ziel-IP-Adresse des Load-Balancers selbst an. Diese Art von Load-Balancer ist kein Proxy. Dies ist das erwartete Verhalten.

Die auf der Back-End-VM ausgeführte Software muss Folgendes tun:

  • Die IP-Adresse des Load-Balancers oder eine beliebige IP-Adresse überwachen (0.0.0.0 oder ::)
  • Überwachung eines Ports, der in der Weiterleitungsregel des Load-Balancers enthalten ist

Zum Testen stellen Sie eine Verbindung zu einer Back-End-VM über SSH oder RDP her. Führen Sie dann die folgenden Tests mit curl, telnet oder einem ähnlichen Tool aus:

  • Versuchen Sie, den Dienst zu erreichen, indem Sie ihn über die interne IP-Adresse der Back-End-VM selbst, 127.0.0.1, oder localhost, kontaktieren.
  • Versuchen Sie, den Dienst über die IP-Adresse der Weiterleitungsregel des Load-Balancers zu erreichen.

Prüfen Sie, ob sich die Client-VM in derselben Region wie der Load-Balancer befindet.

Wenn sich der Client, der eine Verbindung zum Load-Balancer herstellt, in einer anderen Region befindet, achten Sie darauf, dass der globale Zugriff aktiviert ist.

Prüfen Sie, ob der Traffic der Systemdiagnose Backend-VMs erreichen kann.

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

Sie können auch prüfen, ob die Funktionalität des Load-Balancers fehlerfrei ist, indem Sie den Status "Fehlerfrei" für das Backend aufrufen.

Wenn das Backend keine fehlerfreien Instanzen enthält, prüfen Sie, ob die entsprechende Systemdiagnose konfiguriert ist und jede VM im Backend die Ports für die Systemdiagnose überwacht.

Führen Sie von einem Client im selben VPC-Netzwerk den folgenden Befehl aus, um zu prüfen, ob die Backend-VM einen bestimmten TCP-Port überwacht:

telnet SERVER_IP_ADDRESS PORT

Dabei gilt:

  • SERVER_IP_ADDRESS: Die IP-Adresse der Backend-VM.
  • PORT: Der Port, den Sie für Ihre Systemdiagnose konfiguriert haben. Der Port der Systemdiagnose ist standardmäßig 80.

Alternativ können Sie eine SSH-Verbindung zur Backend-VM herstellen und den folgenden Befehl ausführen:

curl localhost:PORT

Ersetzen Sie wieder PORT durch den Port, den Sie für die Systemdiagnose konfiguriert haben.

Eine weitere Möglichkeit zum Testen ist das Ausführen des folgenden Befehls:

netstat -npal | grep LISTEN

Prüfen Sie in der Ausgabe Folgendes:

  • <var>LB_IP_ADDRESS</var>:<var>PORT</var>
  • 0.0.0.0:<var>PORT</var>
  • :::<var>PORT</var>

Dies entscheidet nicht darüber, ob das Routing korrekt eingerichtet ist, um auf die IP-Adresse des Load-Balancers zu reagieren. Dies ist ein separates Problem mit einem ähnlichen Symptom. Führen Sie zum Routing den Befehl ip route list table local aus und prüfen Sie, ob die IP-Adresse des Load-Balancers aufgeführt wird, wie unter Prüfen, ob Backend-VMs an den Load-Balancer gesendete Pakete akzeptieren beschrieben.

Leistungsprobleme beheben

Wenn Sie Leistungsprobleme und eine erhöhte Latenz bemerken, prüfen Sie auf die folgenden häufigen Probleme.

Serverfunktionalität prüfen

Wenn alle Backend-Server auf Systemdiagnosen reagieren, prüfen Sie, ob Anfragen vom Client ordnungsgemäß funktionieren, wenn sie direkt auf dem Server ausgegeben werden. Wenn der Client beispielsweise HTTP-Anfragen über den Load-Balancer an den Server sendet und keine Antwort eingeht oder die Antwort erheblich langsamer als normal ist, senden Sie dieselbe HTTP-Anfrage auf jedem der Backend-Server und beobachten Sie das Verhalten.

Wenn sich einer der Backend-Server nicht ordnungsgemäß verhält, wenn die Anfrage vom Server selbst ausgegeben wird, können Sie davon ausgehen, dass der Serveranwendungs-Stack nicht ordnungsgemäß funktioniert. Sie können die weitere Fehlerbehebung dann auf die Anwendung selbst konzentrieren. Wenn sich alle Server korrekt verhalten, besteht der nächste Schritt darin, den Client und das Netzwerk zu betrachten.

Netzwerkverbindung und Latenz prüfen

Wenn alle Backend-Server ordnungsgemäß auf Anfragen antworten, prüfen Sie die Netzwerklatenz. Führen Sie auf einer Client-VM so einen konstanten Ping-Befehl an jeden Server aus:

ping SERVER_IP_ADDRESS

Dieser Test zeigt die integrierte Netzwerklatenz und ob das Netzwerk Pakete verwirft. In einigen Fällen blockieren Firewallregeln möglicherweise ICMP-Traffic. Wenn dies der Fall ist, führt dieser Test zu keinem Ergebnis. Erkundigen Sie sich beim Administrator der Firewallregeln, ob dies der Fall ist.

Wenn der Befehl ping eine deutlich höhere Latenz als normal oder erheblichen Paketverlust zeigt, senden Sie eine Google Cloud-Supportanfrage, um dieses Problem weiter zu untersuchen.

Problematische Client-Server-Kombinationen bestimmen

Wenn der Netzwerktest ping eine niedrige Latenz und keinen Paketverlust angibt, müssen Sie als Nächstes ermitteln, welche Client-Server-Kombination gegebenenfalls problematische Ergebnisse erzeugt. Dazu können Sie die Anzahl der Backend-Server um die Hälfte reduzieren, bis die Anzahl der Server 1 erreicht, und gleichzeitig das problematische Verhalten reproduzieren (z. B. hohe Latenz oder keine Antworten).

Wenn Sie eine oder mehrere problematische Client-Server-Kombinationen bestimmen, führen Sie die Trafficerfassung und -analyse durch.

Wenn keine problematische Kombination aus Client und Server erkannt wird, fahren Sie mit Leistungstests fort.

Traffic-Erfassung und -Analyse durchführen

Wenn Sie eine problematische Kombination aus Client und Server finden, können Sie mit der Paketerfassung den Teil der Kommunikation ermitteln, der zu Verzögerungen oder Fehlern führt. Die Paketerfassung kann mit tcpdump durchgeführt werden. Gehen Sie dazu so vor:

  1. Installieren Sie tcpdump auf dem Server.
  2. Starten Sie die TCP-Erfassung auf dem Server.

  3. Senden Sie über einen Client eine Beispielanfrage wie diese:

    curl URL

  4. Analysieren Sie die tcpdump-Ausgabe, um das Problem zu bestimmen.

Leistungstests durchführen

Wenn Sie keine problematischen Client-Server-Kombinationen finden und die Gesamtleistung aller Clients und Server niedriger als erwartet ist, sollten Sie die folgenden Tests in Betracht ziehen:

  1. Ein Client und ein Server ohne Load-Balancing.

  2. Ein Client und ein Server mit Load-Balancing.

    Ergebnis: Die Kombination der Ergebnisse aus den Tests [1] und [2] gibt an, ob der Load-Balancer das Problem verursacht.

  3. Ein Client und mehrere Server mit Load-Balancing.

    Ergebnis: Die Leistungsgrenze eines Clients bestimmen.

  4. Mehrere Clients und ein Server mit Load-Balancing.

    Ergebnis: Die Leistungsgrenze eines Servers bestimmen.

  5. Mehrere Clients und mehrere Server ohne Load-Balancing.

    Ergebnis: Das Leistungslimit des Netzwerks bestimmen.

Bei der Ausführung eines Belastungstests mit mehreren Clients und Servern können Client- oder Serverressourcen (CPU, Arbeitsspeicher, E/A) zu Engpässen führen und die aggregierten Ergebnisse reduzieren. Verschlechterte aggregierte Ergebnisse können auch dann auftreten, wenn sich jeder Client und Server ordnungsgemäß verhält.

Fehlerbehebung bei Problemen mit freigegebenen VPC

Wenn Sie eine freigegebene VPC verwenden und keinen neuen internen Passthrough-Network Load Balancer in einem bestimmten Subnetz erstellen können, ist möglicherweise eine Organisationsrichtlinie die Ursache. 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 in der Einschränkung constraints/compute.restrictSharedVpcSubnetworks.

Fehlerbehebung bei Failover-Problemen

Für den Fall, dass Sie ein Failover für einen internen Passthrough-Network Load Balancer konfiguriert haben, finden Sie in den folgenden Abschnitten mögliche Probleme, die auftreten können.

Verbindung

  • Stellen Sie sicher, dass Sie mindestens ein Failover-Back-End festgelegt haben.
  • Prüfen Sie die Richtlinieneinstellungen für Failover:
    • Failover-Quote
    • Traffic wird gelöscht, wenn alle Back-End-VMs fehlerhaft sind
    • Verbindungsausgleich bei Failover ist deaktiviert

Probleme mit verwalteten Instanzgruppen und Failovers

  • Symptom: Der aktive Pool wechselt zwischen dem primären und dem Failover-Back-End hin und her ("flapping").
  • Mögliche Ursache: Die Verwendung von verwalteten Instanzgruppen mit Autoscaling und Failover kann dazu führen, dass der aktive Pool wiederholt ein Failover und ein Failback zwischen dem primären und dem Failover-Back-End ausführt. Google Cloud hindert Sie nicht daran, ein Failover mit verwalteten Instanzgruppen zu konfigurieren, da Ihre Bereitstellung von dieser Einrichtung profitieren könnte.

Deaktivieren Sie die Beschränkung des Verbindungsausgleichs für Failover-Gruppen

Das Deaktivieren des Verbindungsausgleichs funktioniert nur, wenn der Backend-Dienst mit TCP-Protokoll eingerichtet ist.

Die folgende Fehlermeldung wird angezeigt, wenn Sie einen Backend-Dienst mit UDP erstellen, während der Verbindungsausgleich deaktiviert ist:

gcloud compute backend-services create my-failover-bs \
    --global-health-checks \
    --load-balancing-scheme=internal \
    --health-checks=my-tcp-health-check \
    --region=us-central1 \
    --no-connection-drain-on-failover \
    --drop-traffic-if-unhealthy \
    --failover-ratio=0.5 \
    --protocol=UDP
ERROR: (gcloud.compute.backend-services.create) Invalid value for
[--protocol]: can only specify --connection-drain-on-failover if the protocol is
TCP.

Traffic wird an unerwartete Backend-VMs gesendet

Kontrollieren Sie zunächst Folgendes: Wenn die Client-VM auch eine Back-End-VM des Load-Balancers ist, wird erwartet, dass Verbindungen, die an die IP-Adresse der Weiterleitungsregel des Load-Balancers gesendet werden, immer von der Back-End-VM selbst beantwortet werden. Weitere Informationen finden Sie unter Verbindungen von einem einzelnen Client testen und Anfragen von VMs mit Load-Balancing senden.

Wenn die Client-VM keine Back-End-VM des Load-Balancers ist:

  • Für Anfragen von einem einzelnen Client finden Sie unter Verbindungen von einem einzelnen Client testen weitere Informationen, um die Einschränkungen dieser Methode kennenzulernen.

  • Achten Sie darauf, dass Ihre Konfiguration der Firewallregeln für zulässigen eingehenden Traffic Systemdiagnosen erlaubt.

  • Achten Sie im Falle einer Failover-Konfiguration darauf, dass Sie genau verstehen, wie die Mitgliedschaft im aktiven Pool funktioniert und wann Google Cloud Failover und Failback ausführt. Überprüfen Sie die Konfiguration des Load-Balancers:

    • Verwenden Sie die Google Cloud Console, um die Anzahl der fehlerfreien Backend-VMs in jeder Backend-Instanzgruppe zu überprüfen. In der Google Cloud Console sehen Sie auch, welche VMs sich im aktiven Pool befinden.

    • Sorgen Sie dafür, dass die Failover-Quote des Load-Balancers richtig eingestellt ist. Wenn Sie beispielsweise zehn primäre VMs und ein auf 0.2 festgelegtes Failover-Verhältnis haben, führt Google Cloud ein Failover durch, wenn weniger als zwei (10 × 0.2 = 2) primäre VMs intakt sind. Ein Failover-Verhältnis von 0.0 hat eine besondere Bedeutung: Google Cloud führt ein Failover durch, wenn keine primären VMs fehlerfrei sind.

Vorhandene Verbindungen werden während eines Failovers oder Failbacks beendet

Bearbeiten Sie die Failover-Richtlinie Ihres Back-End-Dienstes. Achten Sie darauf, dass der Verbindungsausgleich bei Failover aktiviert ist.

Probleme mit dem Load-Balancer als nächstem Hop

Wenn Sie einen internen Passthrough-Network Load Balancer als nächsten Hop einer benutzerdefinierten statischen Route festlegen, können folgende Probleme auftreten:

Verbindungsprobleme

  • Wenn Sie keine IP-Adresse im Zielbereich einer Route kontaktieren können, deren nächster Hop eine Weiterleitungsregel für einen internen Passthrough-Network Load Balancer ist, beachten Sie, dass eine Route, die diesen Typ eines nächsten Hops verwendet, möglicherweise ICMP-Traffic nicht verarbeitet, abhängig davon, wann die Route erstellt wurde. Wenn die Route vor dem 15. Mai 2021 erstellt wurde, werden TCP- und UDP-Traffic nur bis zum 16. August 2021 verarbeitet. Ab dem 16. August 2021 leiten alle Routen automatisch den gesamten Protokolltraffic (TCP, UDP und ICMP) weiter, unabhängig davon, wann eine Route erstellt wurde. Wenn Sie nicht bis dahin warten möchten, können Sie die Ping-Funktion jetzt aktivieren, indem Sie neue Routen erstellen und die alten löschen.

  • Wenn Sie einen internen Passthrough-Network Load Balancer als nächsten Hop für eine benutzerdefinierte statische Route verwenden, wird der gesamte Traffic an die fehlerfreien Backend-VMs des Load Balancers weitergeleitet. Dabei ist es unerheblich, welches Protokoll für den internen Backend-Dienst des Load Balancers konfiguriert ist und welcher Port oder welche Ports in der internen Weiterleitungsregel des Load Balancers konfiguriert sind.

  • Sorgen Sie dafür, dass Sie Firewallregeln für zulässigen eingehenden Traffic erstellt haben, welche in der Lage sind, die Traffic-Quellen korrekt zu identifizieren, die an Backend-VMs über den nächsten Hop der benutzerdefinierten statischen Route gesendet werden sollen. Pakete, die auf Back-End-VMs ankommen, behalten ihre Quell-IP-Adressen bei, auch wenn sie über eine benutzerdefinierte statische Route gesendet werden.

Ungültiger Wert für Zielbereich

Der Zielbereich einer benutzerdefinierten statischen Route kann nicht spezifischer sein als eine Subnetzroute in Ihrem VPC-Netzwerk. Die folgenden Lösungen können Ihnen helfen, wenn beim Erstellen einer benutzerdefinierten statischen Route diese Fehlermeldung angezeigt wird:

Invalid value for field 'resource.destRange': [ROUTE_DESTINATION].
[ROUTE_DESTINATION] hides the address space of the network .... Cannot change
the routing of packets destined for the network.

  • Sie können keine benutzerdefinierte statische Route mit einem Ziel erstellen, das genau mit einer Subnetzroute übereinstimmt oder spezifischer als diese ist (eine längere Maske hat). Weitere Informationen finden Sie unter Anwendbarkeit und Reihenfolge.

  • Wenn Pakete an ein unerwartetes Ziel gelangen, entfernen Sie andere Routen mit spezifischeren Zielen aus Ihrem VPC-Netzwerk. Sehen Sie sich die Routing-Reihenfolge an, um mehr über die Routenauswahl von Google Cloud zu erfahren.

Logging-Probleme beheben

Wenn Sie das Logging für einen internen Passthrough-Network Load Balancer konfigurieren, können die folgenden Probleme auftreten:

  • RTT-Messungen wie Bytewerte können in einigen Logs fehlen, wenn nicht genügend Pakete zur Erfassung von RTT geprüft werden. Bei Verbindungen mit geringem Volumen ist dies wahrscheinlicher.
  • RTT-Werte sind nur für TCP-Flüsse verfügbar.
  • Einige Pakete werden ohne Nutzlast gesendet. Wenn Nur-Header-Pakete abgetastet werden, ist der Bytewert 0.

Nächste Schritte