Erweiterte Load-Balancing-Optimierungen

Auf dieser Seite wird beschrieben, wie Sie eine Dienst-Load-Balancing-Richtlinie nutzen, um erweiterte Kosten-, Latenz- und Ausfallsicherheitsoptimierungen für die folgenden Load-Balancer zu unterstützen:

• Globaler externer Application Load Balancer
• Regionsübergreifender interner Application Load Balancer
• Globaler externer Proxy-Network Load Balancer
• Regionsübergreifender interner Proxy-Network Load Balancer

Cloud Service Mesh unterstützt auch erweiterte Load-Balancing-Optimierungen. Weitere Informationen finden Sie unter Erweitertes Load Balancing – Übersicht in der Cloud Service Mesh-Dokumentation.

Eine Load-Balancing-Richtlinie für Dienste (serviceLbPolicy) ist eine Ressource, die dem Backend-Dienst des Load Balancers zugeordnet ist. Mit einer Load-Balancing-Richtlinie für Dienste können Sie die Parameter anpassen, die beeinflussen, wie der Traffic innerhalb der Backends verteilt wird, die einem Backend-Dienst zugeordnet sind:

• Passen Sie den Load-Balancing-Algorithmus an, um zu bestimmen, wie der Traffic innerhalb einer bestimmten Region oder Zone verteilt wird.
• Aktivieren Sie den automatischen Kapazitätsausgleich, damit der Load Balancer Traffic von fehlerhaften Back-Ends schnell leeren kann.
• Legen Sie einen Failover-Schwellenwert fest, um zu bestimmen, wann ein Back-End als fehlerhaft gilt. So kann Traffic zu einem anderen Backend weitergeleitet werden; fehlerhafte Backends werden so vermieden.

Außerdem können Sie bestimmte Back-Ends als bevorzugte Back-Ends festlegen. Diese Back-Ends müssen für die Kapazität verwendet werden, bevor Anfragen an die verbleibenden Back-Ends gesendet werden.

Das folgende Diagramm zeigt, wie Cloud Load Balancing Routing, Load-Balancing und Trafficverteilung auswertet.

So trifft Cloud Load Balancing Entscheidungen zur Routing- und Trafficverteilung.

Hinweise

Lesen Sie sich den Inhalt dieser Seite sorgfältig durch, bevor Sie sich mit dem Thema befassen.Verteilungsprozess anfordern, der auf der Übersichtsseite zum externen Application Load Balancer beschrieben wird. Bei Load Balancern, die sich immer in der Premium-Stufe befinden, unterstützen alle auf dieser Seite beschriebenen Load-Balancing-Algorithmen das Weiterleiten zwischen Regionen, wenn eine Region der ersten Wahl bereits voll ist.

Unterstützte Back-Ends

Load-Balancing-Richtlinien für Dienste und bevorzugte Back-Ends können nur auf Load-Balancern konfiguriert werden, die die unterstützten Back-Ends verwenden. Diese sind in der folgenden Tabelle aufgeführt.

Backend	Unterstützt?
Instanzgruppen Nicht verwaltet Zonal verwaltet
Regionale MIGs
Zonale NEGs (GCE_VM_IP_PORT-Endpunkte)
Hybrid-NEGs (NON_GCP_PRIVATE_IP_PORT-Endpunkte)
Serverlose NEGs
Internet-NEGs
Private Service Connect-NEGs

Load-Balancing-Algorithmen

In diesem Abschnitt werden die Load-Balancing-Algorithmen beschrieben, die Sie in einer Load-Balancing-Richtlinie für Dienste konfigurieren können. Wenn Sie keinen Algorithmus oder keine Load-Balancing-Richtlinie für Dienste konfigurieren, verwendet der Load Balancer standardmäßig WATERFALL_BY_REGION.

Wasserfall nach Region

WATERFALL_BY_REGION ist der standardmäßige Load-Balancing-Algorithmus. Zusammen mit diesem Algorithmus versuchen alle Google Front Ends (GFEs) in einer Region, Back-Ends gemäß ihrer konfigurierten Zielkapazität (geändert durch ihre Kapazitätsskalierer) zu füllen.

Jedes einzelne GFE auf Ebene der zweiten Ebene bevorzugt Backend-Instanzen oder Endpunkte in einer Zone, die so nah wie möglich am Netzwerkzeitpunkt der zweiten Ebene (Netzwerkumlaufzeit) definiert ist. Da mit WATERFALL_BY_REGION die Latenz zwischen den Zonen minimiert wird, sendet das GFE auf niedriger Ebene möglicherweise Anfragen an Back-Ends in der bevorzugten Zone des GFE der zweiten Ebene.

Region besprühen

Der SPRAY_TO_REGION-Algorithmus ändert das Einzelverhalten jedes GFE der zweiten Ebene in dem Maße, dass jedes GFE der zweiten Ebene keine Präferenz für die Auswahl hat. Backend-Instanzen oder Endpunkte, die sich in einer Zone befinden, die dem GFE auf der zweiten Ebene möglichst nahe kommt. Mit SPRAY_TO_REGION sendet jedes GFE der zweiten Ebene Anfragen an alle Backend-Instanzen oder -Endpunkte in allen Zonen der Region ohne kürzere Umlaufzeit zwischen dem GFE der zweiten Ebene und den Backend-Instanzen oder Endpunkten.

Wie WATERFALL_BY_REGION füllen insgesamt alle GFE der zweiten Ebene in der Region die Back-Ends proportional zu ihren konfigurierten Zielkapazitäten (geändert durch ihre Kapazitätsskalierer).

SPRAY_TO_REGION bietet zwar eine gleichmäßigere Verteilung zwischen Back-Ends in allen Zonen einer Region, insbesondere bei niedrigen Anfrageraten, allerdings gilt für diese einheitliche Verteilung Folgendes:

• Wenn Back-Ends ausfallen (aber weiterhin ihre Systemdiagnosen bestehen), sind mehr GFE der zweiten Ebene betroffen, obwohl die einzelnen Auswirkungen nicht so stark sind.
• Da jedes GFE der zweiten Ebene keine Zone gegenüber einer anderen bevorzugt, generieren die GFE der zweiten Ebene mehr zonenübergreifenden Traffic. Je nach Anzahl der verarbeiteten Anfragen kann jedes GFE der zweiten Ebene möglicherweise weitere TCP-Verbindungen zu den Back-Ends herstellen.

Wasserfall nach Zone

Der WATERFALL_BY_ZONE-Algorithmus ändert das Einzelverhalten jedes GFE der zweiten Ebene in dem Maße, dass jedes GFE der zweiten Ebene eine sehr starke Präferenz zur Auswahl von Backend-Instanzen oder Endpunkten hat, die sich in der Zone befinden, die dem GFE der zweiten Ebene möglichst nahe kommt. Bei WATERFALL_BY_ZONE sendet jedes GFE der zweiten Ebene nur Anfragen an Backend-Instanzen oder Endpunkte in anderen Zonen der Region, wenn das GFE der zweiten Ebene Backend-Instanzen oder Endpunkte in Ihrer bevorzugten Zone gefüllt (oder proportional überfüllt hat).

Wie WATERFALL_BY_REGION füllen insgesamt alle GFE der zweiten Ebene in der Region die Back-Ends proportional zu ihren konfigurierten Zielkapazitäten (geändert durch ihre Kapazitätsskalierer).

Der WATERFALL_BY_ZONE-Algorithmus minimiert die Latenz unter Berücksichtigung folgender Überlegungen:

• WATERFALL_BY_ZONE minimiert keine zonenübergreifenden Verbindungen. Der Algorithmus wird nur nach Latenz gesteuert.
• WATERFALL_BY_ZONE garantiert nicht, dass jedes GFE der zweiten Ebene immer seine bevorzugte Zone füllt, bevor andere Zonen gefüllt werden. Wartungsereignisse können vorübergehend dazu führen, dass der gesamte Traffic von einem GFE der zweiten Ebene an Backend-Instanzen oder Endpunkte in einer anderen Zone gesendet wird.
• WATERFALL_BY_ZONE kann zu einer weniger einheitlichen Verteilung von Anfragen zwischen allen Backend-Instanzen oder Endpunkten innerhalb der Region führen. Beispiel: Backend-Instanzen oder Endpunkte in der bevorzugten Zone des GFE der zweiten Ebene können überlastet werden, während Backends in anderen Zonen nicht vollständig gefüllt werden.

Load-Balancing-Algorithmen vergleichen

In der folgenden Tabelle werden die verschiedenen Load-Balancing-Algorithmen verglichen.

Verhalten	Wasserfall nach Region	Region besprühen	Wasserfall nach Zone
Einheitliche Kapazitätsnutzung innerhalb einer Region	Ja	Ja	Nein
Einheitliche Kapazitätsnutzung über mehrere Regionen hinweg	Nein	Nein	Nein
Einheitliche Trafficaufteilung von Load Balancern	Nein	Ja	Nein
Zonenübergreifende Trafficverteilung	Ja. Der Traffic wird gleichmäßig auf die Zonen in einer Region verteilt und gleichzeitig die Netzwerklatenz optimiert. Der Traffic wird möglicherweise zonenübergreifend gesendet.	Ja	Ja. Der Traffic wird erst in die nächste Zone geleitet, bis die Kapazität erreicht ist. Danach geht es zur nächstgelegenen Zone.
Empfindlichkeit gegenüber Trafficspitzen in einer lokalen Zone	Durchschnitt: hängt davon ab, wie viel Traffic bereits über Zonen verteilt wurde.	Weniger: Spitzen einzelner Zonen sind auf alle Zonen in der Region verteilt.	Höher: Spitzen bei einzelnen Zonen werden wahrscheinlich vollständig von derselben Zone bereitgestellt, bis der Load Balancer reagieren kann.

Automatischer Ausgleich von Kapazitäten

Wenn ein Backend fehlerhaft ist, sollten Sie es in der Regel so schnell wie möglich von Load-Balancing-Entscheidungen ausschließen. Durch das Ausschließen fehlerhafter Back-Ends wird die Gesamtlatenz optimiert, da Traffic nur an fehlerfreie Back-Ends gesendet wird.

Wenn Sie den automatischen Kapazitätsausgleich aktivieren, skaliert der Load Balancer die Kapazität eines Back-Ends automatisch auf null, wenn weniger als 25 % der Instanzen oder Endpunkte des Back-Ends Systemdiagnosen bestehen. Dadurch wird das fehlerhafte Backend aus dem globalen Load-Balancing-Pool entfernt. Diese Aktion entspricht funktional dem Festlegen von backendService.capacityScaler auf 0 für ein Backend, wenn Sie vermeiden möchten, dass Traffic an dieses Backend weitergeleitet wird.

Wenn 35 % (10 % über dem Schwellenwert) der Instanzen oder Endpunkte eines zuvor automatisch leeren Backends 60 Sekunden lang Systemdiagnosen bestehen, wird das Backend automatisch entleert und wieder dem Load-Balancing-Pool hinzugefügt. Dadurch wird sichergestellt, dass das Backend fehlerfrei ist und nicht zwischen dem leeren und Drain-Zustand wechselt.

Auch bei aktiviertem automatischen Kapazitätsausgleich beendet der Load-Balancer nicht mehr als 50 % der Backends, die unabhängig vom Systemstatus eines Backends an einen Backend-Dienst angehängt sind. Wenn 50 % der Back-Ends angehängt sind, verringern Sie das Risiko einer Überlastung fehlerfreier Back-Ends.

Ein Anwendungsfall des automatischen Kapazitätsausgleichs ist die Verwendung dieses Risikos, um das Risiko einer Überlastung Ihrer bevorzugten Back-Ends zu minimieren. Wenn ein Backend beispielsweise als bevorzugt gekennzeichnet ist, die meisten Instanzen oder Endpunkte jedoch fehlerhaft sind, entfernt das automatische Leeren von Backend das Backend aus dem Load-Balancing-Pool. Anstatt die verbleibenden fehlerfreien Instanzen oder Endpunkte im bevorzugten Backend zu überlasten, wird der Traffic durch das automatische Leeren von Kapazitäten auf andere Backends verschoben.

Sie können das automatische Leeren von Kapazitäten als Teil der Richtlinie zum Dienst-Load-Balancing aktivieren. Weitere Informationen finden Sie unter Dienst-Load-Balancing-Richtlinie konfigurieren.

Die automatische Kapazität wird nicht für Back-Ends unterstützt, die keinen Balancing-Modus verwenden. Dazu gehören Back-Ends wie Internet-NEGs, serverlose NEGs und PSC-NEGs.

Failover-Schwellenwert

Der Load-Balancer bestimmt die Verteilung des Traffics auf Back-Ends auf mehrere Ebenen. Im stabilen Zustand sendet es Traffic an Back-Ends, die basierend auf einem der zuvor beschriebenen Load-Balancing-Algorithmen ausgewählt werden. Diese Back-Ends, die als primäre Back-Ends bezeichnet werden, werden in Bezug auf Latenz und Kapazität als optimal angesehen.

Der Load-Balancer verfolgt auch andere Back-Ends, die verwendet werden können, wenn die primären Back-Ends fehlerhaft werden und den Traffic nicht verarbeiten können. Solche Back-Ends werden als Failover-Back-Ends bezeichnet. Solche Back-Ends sind in der Regel Back-Ends in der Nähe mit verfügbaren Kapazitäten.

Wenn Instanzen oder Endpunkte im primären Back-End fehlerhaft werden, verschiebt der Load-Balancer den Traffic nicht sofort auf andere Back-Ends. Stattdessen verschiebt der Load-Balancer zuerst den Traffic zu anderen fehlerfreien Instanzen oder Endpunkten im selben Backend, um die Trafficlast zu stabilisieren. Sind zu viele Endpunkte in einem primären Backend fehlerhaft, sodass die verbleibenden Endpunkte in einem Backend den zusätzlichen Traffic nicht mehr verarbeiten können, bestimmt der Load-Balancer über den Failover-Schwellenwert, wann Sie Traffic an ein Failover-Backend senden möchten. Der Load Balancer toleriert einen fehlerhaften Zustand des primären Back-Ends bis zum Failover-Schwellenwert. Danach wird der Traffic vom primären Back-End weggeleitet.

Der Failover-Schwellenwert ist ein Wert zwischen 1 und 99, ausgedrückt als Prozentsatz der Endpunkte in einem Backend, der fehlerfrei sein muss. Wenn der Prozentsatz fehlerfreier Endpunkte unter den Failover-Schwellenwert fällt, versucht der Load-Balancer, Traffic an ein Failover-Backend zu senden. Der Failover-Schwellenwert beträgt standardmäßig 70.

Ist ein Failover-Schwellenwert zu hoch, können unnötige Traffic-Spills aufgrund vorübergehender Statusänderungen auftreten. Ist der Failover-Schwellenwert zu niedrig, sendet der Load-Balancer weiterhin Traffic an die primären Back-Ends, obwohl es viele fehlerhafte Endpunkte gibt.

Failover-Entscheidungen sind lokal. Jedes lokale GFE (Google Front End) verhält sich unabhängig vom anderen. Sie sind dafür verantwortlich, dass Ihre Failover-Back-Ends den zusätzlichen Traffic bewältigen können.

Failover-Traffic kann zu überlasteten Back-Ends führen. Auch wenn ein Back-End nicht betriebsbereit ist, sendet der Load Balancer möglicherweise weiterhin Traffic dorthin. Wenn Sie fehlerhafte Back-Ends aus dem Pool der verfügbaren Back-Ends ausschließen möchten, aktivieren Sie das Feature zum automatischen Entladen von Kapazitäten.

Bevorzugte Back-Ends

Bevorzugte Back-Ends sind Back-Ends, deren Kapazität Sie vollständig nutzen möchten, bevor Traffic an andere Back-Ends weitergeleitet wird. Der gesamte Traffic über die konfigurierte Kapazität bevorzugter Back-Ends wird an die verbleibenden, nicht bevorzugten Back-Ends weitergeleitet. Der Load-Balancing-Algorithmus verteilt dann den Traffic auf die nicht bevorzugten Backends eines Backend-Dienstes.

Sie können Ihren Load Balancer so konfigurieren, dass ein oder mehrere Backends, die an einen Backend-Dienst angehängt sind, bevorzugt und vollständig verwendet werden, bevor Sie nachfolgende Anfragen an die verbleibenden Backends weiterleiten.

Beachten Sie bei der Verwendung bevorzugter Back-Ends die folgenden Beschränkungen:

• Die als bevorzugten Back-Ends konfigurierten Back-Ends können sich weiter von den Clients entfernt befinden und führen zu einer höheren durchschnittlichen Latenz für Clientanfragen. Dies ist auch der Fall, wenn andere Back-Ends vorhanden sind, die die Clients mit einer geringeren Latenz bereitstellen könnten.
• Bestimmte Load-Balancing-Algorithmen (WATERFALL_BY_REGION, SPRAY_TO_REGION und WATERFALL_BY_ZONE) gelten nicht für Back-Ends, die als bevorzugte Back-Ends konfiguriert sind.

Informationen zum Festlegen bevorzugter Back-Ends finden Sie unter Bevorzugte Back-Ends festlegen.

Load-Balancing-Richtlinie für Dienste konfigurieren

Hinweis: In diesem Abschnitt wird davon ausgegangen, dass Sie sich mit Cloud Load Balancing vertraut machen. Die Schritte führen Sie nicht durch das Erstellen eines Backend-Dienstes oder durch eine andere grundlegende Load-Balancer-Konfiguration. Informationen zum Einrichten finden Sie in der entsprechenden Load Balancer-Dokumentation.

Mit der Load-Balancing-Richtlinienressource für Dienste können Sie die folgenden Felder konfigurieren:

• Load-Balancing-Algorithmus
• Automatischer Ausgleich von Kapazitäten
• Failover-Schwellenwert

Informationen zum Festlegen eines bevorzugten Back-Ends finden Sie unter Bevorzugte Back-Ends festlegen.

Richtlinie erstellen

Führen Sie die folgenden Schritte aus, um eine Dienst-Load-Balancing-Richtlinie zu erstellen und zu konfigurieren:

1. Erstellen Sie eine Load-Balancing-Richtlinienressource für Dienste. Dazu können Sie entweder eine YAML-Datei oder direkt mit den Parametern gcloud verwenden.

   • Mit einer YAML-Datei. Die Load-Balancing-Richtlinien für Dienste legen Sie in einer YAML-Datei fest. Die folgende YAML-Beispieldatei zeigt, wie Sie einen Load-Balancing-Algorithmus konfigurieren, die automatische Kapazitätsentladung aktivieren und einen benutzerdefinierten Failover-Schwellenwert festlegen:

     name: projects/PROJECT_ID/locations/global/serviceLbPolicies/SERVICE_LB_POLICY_NAME
     autoCapacityDrain:
         enable: True
     failoverConfig:
         failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
     loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
     

     Ersetzen Sie Folgendes:

     • PROJECT_ID: Projekt-ID.
     • SERVICE_LB_POLICY_NAME: der Name der Load-Balancing-Richtlinie für Dienste.
     • FAILOVER_THRESHOLD_VALUE: Der Failover-Schwellenwert. Dies muss eine Zahl zwischen 1 und 99 sein.
     • LOAD_BALANCING_ALGORITHM: der zu verwendende Load-Balancing-Algorithmus. Dies kann entweder SPRAY_TO_REGION, WATERFALL_BY_REGION oder WATERFALL_BY_ZONE sein.

     Nachdem Sie die YAML-Datei erstellt haben, importieren Sie die Datei in eine neue Load-Balancing-Richtlinie für Dienste.

     gcloud network-services service-lb-policies import SERVICE_LB_POLICY_NAME \
      --source=PATH_TO_POLICY_FILE \
      --location=global
     

   • Ohne YAML-Datei. Alternativ können Sie Features für Load-Balancing-Richtlinien für Dienste ohne YAML-Datei konfigurieren.

     Verwenden Sie die folgenden Parameter, um den Load-Balancing-Algorithmus festzulegen und die automatische Schnellentladung zu aktivieren:

     gcloud network-services service-lb-policies create SERVICE_LB_POLICY_NAME \
      --load-balancing-algorithm=LOAD_BALANCING_ALGORITHM \
      --auto-capacity-drain \
      --failover-health-threshold=FAILOVER_THRESHOLD_VALUE \
      --location=global
     

     Ersetzen Sie Folgendes:

     • SERVICE_LB_POLICY_NAME: der Name der Load-Balancing-Richtlinie für Dienste.
     • LOAD_BALANCING_ALGORITHM: der zu verwendende Load-Balancing-Algorithmus. Dies kann entweder SPRAY_TO_REGION, WATERFALL_BY_REGION oder WATERFALL_BY_ZONE sein.
     • FAILOVER_THRESHOLD_VALUE: Der Failover-Schwellenwert. Dies muss eine Zahl zwischen 1 und 99 sein.

2. Aktualisieren Sie einen Backend-Dienst so, dass das Feld --service-lb-policy auf die neu erstellte Load-Balancing-Richtlinienressource für Dienste verweist. Ein Backend-Dienst kann nur einer einzigen Load-Balancing-Richtlinienressource für Dienste zugeordnet werden.

   gcloud compute backend-services update BACKEND_SERVICE_NAME \
     --service-lb-policy=SERVICE_LB_POLICY_NAME \
     --global
   

   Sie können eine Load-Balancing-Richtlinie für Dienste beim Erstellen des Backend-Dienstes mit einem Backend-Dienst verknüpfen.

   gcloud compute backend-services create BACKEND_SERVICE_NAME \
       --protocol=PROTOCOL \
       --port-name=NAMED_PORT_NAME \
       --health-checks=HEALTH_CHECK_NAME \
       --load-balancing-scheme=LOAD_BALANCING_SCHEME \
       --service-lb-policy=SERVICE_LB_POLICY_NAME \
       --global
   

Richtlinie entfernen

Verwenden Sie den folgenden Befehl, um eine Load-Balancing-Richtlinie für Dienste von einem Backend-Dienst zu entfernen:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-service-lb-policy \
    --global

Bevorzugte Back-Ends festlegen

Sie können bevorzugte Back-Ends mithilfe der Google Cloud CLI oder der API konfigurieren.

gcloud

Bevorzugtes Backend hinzufügen

Verwenden Sie zum Festlegen eines bevorzugten Backends den Befehl gcloud compute backend-services add-backend, um das Flag --preference festzulegen, wenn Sie das Backend dem Backend-Dienst hinzufügen.

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

Ersetzen Sie PREFERENCE durch die Präferenzebene, die Sie dem Backend zuweisen möchten. Dies kann entweder PREFERRED oder DEFAULT sein.

Der Rest des Befehls hängt vom Typ des verwendeten Back-Ends ab (Instanzgruppe oder NEG). Informationen zu allen erforderlichen Parametern finden Sie im Befehl gcloud compute backend-services add-backend.

Einstellung eines Back-Ends aktualisieren

Verwenden Sie den Befehl gcloud compute backend-services update-backend, um den Parameter --preference eines Back-Ends zu aktualisieren.

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

Der Rest des Befehls hängt vom Typ des verwendeten Back-Ends ab (Instanzgruppe oder NEG). Mit dem folgenden Beispielbefehl wird die Einstellung einer Backend-Instanzgruppe aktualisiert und auf PREFERRED gesetzt:

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    --instance-group=INSTANCE_GROUP_NAME \
    --instance-group-zone=INSTANCE_GROUP_ZONE \
    --preference=PREFERRED \
    --global

API

Um ein bevorzugtes Backend festzulegen, legen Sie das Flag preference für jedes Backend mithilfe der globalen backendServices-Ressource fest.

Das folgende Beispiel zeigt, wie Sie die Backend-Einstellung konfigurieren:

  name: projects/PROJECT_ID/locations/global/backendServices/BACKEND_SERVICE_NAME
  ...
  - backends
      name: BACKEND_1_NAME
      preference: PREFERRED
      ...
  - backends
      name: BACKEND_2_NAME
      preference: DEFAULT
      ...

Ersetzen Sie Folgendes:

• PROJECT_ID: die Projekt-ID
• BACKEND_SERVICE_NAME: der Name des Backend-Dienstes
• BACKEND_1_NAME: der Name des bevorzugten Back-Ends
• BACKEND_2_NAME: der Name des Standard-Back-Ends

Fehlerbehebung

Traffic-Verteilungsmuster können sich ändern, wenn Sie eine neue Load-Balancing-Richtlinie für Dienste an einen Backend-Dienst anhängen.

Wenn Sie Trafficprobleme beheben möchten, verwenden Sie Cloud Monitoring, um zu sehen, wie Traffic zwischen dem Load Balancer und dem Backend fließt. Die Logs und Messwerte von Cloud Load Balancing helfen Ihnen auch, das Load-Balancing-Verhalten zu verstehen.

In diesem Abschnitt werden einige gängige Szenarien zusammengefasst, die in der neu bereitgestellten Konfiguration auftreten können.

Traffic von einer einzelnen Quelle wird an zu viele verschiedene Back-Ends gesendet

Dies ist das vorgesehene Verhalten des SPRAY_TO_REGION-Algorithmus. Es können jedoch Probleme auftreten, die durch eine größere Verteilung des Traffics verursacht werden. Beispielsweise können die Cache-Trefferraten sinken, da Back-Ends Traffic von einer größeren Auswahl von Clients sehen. In diesem Fall sollten Sie andere Algorithmen wie WATERFALL_BY_REGION verwenden.

Traffic wird nicht an Back-Ends mit vielen fehlerhaften Endpunkten gesendet

Dies ist das vorgesehene Verhalten, wenn autoCapacityDrain aktiviert ist. Back-Ends mit vielen fehlerhaften Endpunkten werden geleert und aus dem Load-Balancing-Pool entfernt. Wenn Sie dieses Verhalten nicht wünschen, können Sie das automatische Leeren von Kapazitäten deaktivieren. Das bedeutet jedoch, dass Traffic an viele Back-Ends mit vielen fehlerhaften Endpunkten gesendet werden kann und Anfragen fehlschlagen können.

Traffic wird vor näher aneinanderliegenden Back-Ends an weiter entfernte gesendet

Dies ist das vorgesehene Verhalten, wenn Ihre bevorzugten Back-Ends weiter als Ihre standardmäßigen Back-Ends entfernt sind. Wenn Sie dies nicht wünschen, aktualisieren Sie die Präferenzeinstellungen für jedes Backend entsprechend.

Traffic wird nicht an einige Back-Ends gesendet, wenn bevorzugte Back-Ends verwendet werden

Dies ist das beabsichtigte Verhalten, wenn Ihre bevorzugten Back-Ends noch nicht die Kapazität erreicht haben. Die bevorzugten Back-Ends werden zuerst basierend auf der Umlaufzeitlatenz diesen Back-Ends zugewiesen.

Wenn Sie Traffic an andere Back-Ends senden möchten, haben Sie folgende Möglichkeiten:

• Aktualisieren sie die Präferenzeinstellungen für die anderen Back-Ends.
• Legen Sie eine niedrigere Einstellung für die Zielkapazität für Ihre bevorzugten Back-Ends fest. Die Zielkapazität wird abhängig von dem Balancing-Modus des Backend-Dienstes entweder mit den Feldern max-rate oder max-utilization konfiguriert.

Traffic wird während vorübergehender Statusänderungen an ein Remote-Backend gesendet

Dies ist das vorgesehene Verhalten, wenn der Failover-Schwellenwert auf einen hohen Wert gesetzt ist. Wenn der Traffic bei vorübergehenden Statusänderungen weiter an die primären Back-Ends weitergeleitet werden soll, setzen Sie dieses Feld auf einen niedrigeren Wert.

Fehlerfreie Endpunkte werden überlastet, wenn andere Endpunkte fehlerhaft sind

Dies ist das beabsichtigte Verhalten, wenn der Failover-Schwellenwert auf einen niedrigen Wert festgelegt ist. Wenn Endpunkte fehlerhaft sind, wird der Traffic, der für diese fehlerhaften Endpunkte bestimmt ist, stattdessen auf die verbleibenden Endpunkte im selben Backend verteilt. Wenn das Failover-Verhalten früher ausgelöst werden soll, setzen Sie in diesem Feld einen höheren Wert.

Beschränkungen

• Jeder Backend-Dienst kann nur einer einzigen Load-Balancing-Richtlinienressource für Dienste zugeordnet werden.