Erweiterte Load-Balancing-Optimierungen

Auf dieser Seite wird beschrieben, wie Sie erweiterte Kosten-, Latenz- und Ausfallsicherheitsoptimierungen für Application Load Balancer und Proxy-Network Load Balancer konfigurieren.

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.

Cloud Load Balancing bietet die folgenden erweiterten Funktionen:

• Richtlinie für das Dienst-Load Balancing. 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 folgenden Parameter anpassen, um zu beeinflussen, wie der Traffic zwischen den Backends verteilt wird, die zu einem Backend-Dienst gehören:

  • Load-Balancing-Algorithmen Passen Sie den Load Balancing-Algorithmus an, um zu bestimmen, wie der Traffic innerhalb einer bestimmten Region oder Zone verteilt wird.
  • Automatischer Kapazitätsausgleich Aktivieren Sie den automatischen Kapazitätsausgleich, damit der Load Balancer Traffic von fehlerhaften Back-Ends schnell leeren kann.
  • Failover-Schwellenwert Legen Sie einen Failover-Schwellenwert fest, um zu bestimmen, wann ein Back-End als fehlerhaft eingestuft wird. So kann Traffic zu einem anderen Backend weitergeleitet werden; fehlerhafte Backends werden so vermieden.
  • Trafficisolierung Sie können kaskadierende Fehler verhindern, indem Sie den regionenübergreifenden Traffic-Überlauf einschränken oder verbieten.

• Bevorzugte Back-Ends Sie können 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.

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 Load Balancer und Back-Ends

Die folgenden Load Balancer unterstützen Richtlinien für das Dienst-Load Balancing und bevorzugte Back-Ends:

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

Für die auf dieser Seite beschriebenen Funktionen sind kompatible Back-Ends erforderlich, die einen Balancing-Modus unterstützen. Die unterstützten Back-Ends sind in der folgenden Tabelle zusammengefasst:

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 der Region, die dem Nutzer am nächsten ist, 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.

Wenn alle Back-Ends in der nächstgelegenen Region ihre konfigurierte Kapazitätsgrenze erreichen, wird der Traffic in die nächstgelegene Region weitergeleitet und gleichzeitig die Netzwerklatenz optimiert.

Spray-to-Region-Algorithmus

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.

Automatischer Ausgleich und Abbau von Kapazitäten

Beim automatischen Kapazitätsabbau und -aufbau werden die Konzepte der Systemdiagnose und der Backendkapazität kombiniert. Beim automatischen Kapazitätsausgleich werden Systemdiagnosen als zusätzliches Signal verwendet, um die effektive Backendkapazität auf null zu setzen. Bei der automatischen Kapazitätsrücknahme werden Gesundheitschecks als zusätzliches Signal verwendet, um die effektive Back-End-Kapazität auf den vorherigen Wert zurückzusetzen.

Wenn Sie Anfragen ohne automatisches Entladen und Aufladen der Kapazität von allen Back-Ends in einer bestimmten Region weiterleiten möchten, müssen Sie die effektive Kapazität jedes Back-Ends in dieser Region manuell auf null setzen. Sie können dazu beispielsweise den Kapazitätsskalar verwenden.

Bei der automatischen Kapazitätsauslastung und -wiederherstellung können Systemdiagnosen als Signal verwendet werden, um die Kapazität eines Back-Ends anzupassen, entweder durch Auslastung oder Wiederherstellung.

Informationen zum Aktivieren des automatischen Leerens und Auffüllens der Kapazität finden Sie unter Dienst-Load-Balancing-Richtlinie konfigurieren.

Automatischer Ausgleich von Kapazitäten

Beim automatischen Kapazitätsausgleich wird die Kapazität jeder Instanzgruppe oder NEG des ausgleichsfähigen Back-End-Kandidaten auf null gesetzt, solange das Verhältnis der ausgleichsfähigen Back-End-Instanzgruppen oder NEGs im Vergleich zu allen Back-End-Instanzgruppen oder NEGs unter 50 % liegt. Bei der Berechnung des Verhältnisses von 50% werden Back-Ends mit null Kapazität nicht in den Nenner einbezogen. Alle Backends sind jedoch im Nenner enthalten.

Ein ausgleichsfähiges Back-End-Kandidat ist eine Back-End-Instanzgruppe oder NEG, bei der weniger als 25% der Mitgliedsinstanzen oder ‑endpunkte die Systemdiagnosen des Load Balancers bestehen.

Folgende Back-Ends haben eine Kapazität von null:

• Backend-Instanzgruppen ohne Mitgliedsinstanzen, bei denen die Kapazität der Instanzgruppe pro Instanz definiert ist
• Backend-NEGs ohne Mitgliedsendpunkte, bei denen die NEG-Kapazität pro Endpunkt definiert ist
• Back-End-Instanzgruppen oder NEGs, deren Kapazitätsskalare Sie auf null gesetzt haben

Die automatisch entladene Backendkapazität entspricht funktional dem manuellen Festlegen von backendService.backends[].capacityScaler auf 0 für ein Backend, ohne den Wert für den Kapazitätsskalator festzulegen.

Automatischer Kapazitätsausgleich

Bei der automatischen Kapazitätsentleerung wird die Kapazität eines Backends auf den Wert zurückgesetzt, der vom Kapazitätsskalierungstool des Backends gesteuert wird, wenn mindestens 35% der Instanzen oder Endpunkte des Backends mindestens 60 Sekunden lang Systemdiagnosen bestehen. Durch die 60-Sekunden-Anforderung wird das Risiko verringert, dass der Akku nacheinander entladen und wieder aufgeladen wird, wenn die Systemdiagnosen in schneller Folge fehlschlagen und bestehen.

Failover-Schwellenwert

Der Load Balancer bestimmt die Verteilung des Traffics auf Back-Ends auf mehreren Ebenen. Im Steady State sendet er Traffic an Back-Ends, die anhand eines der zuvor beschriebenen Load-Balancing-Algorithmen ausgewählt werden. Diese Back-Ends, die als primäre Back-Ends bezeichnet werden, gelten hinsichtlich Latenz und Kapazität als optimal.

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, leitet der Load Balancer den Traffic nicht sofort an andere Back-Ends weiter. Stattdessen leitet der Load Balancer den Traffic zuerst an andere fehlerfreie Instanzen oder Endpunkte im selben Backend weiter, 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 der fehlerfreien Endpunkte unter den Failover-Schwellenwert fällt, versucht der Load Balancer, Traffic an ein Failover-Backend zu senden. Der Standardwert für den Failover-Schwellenwert ist 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 Backends 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.

Trafficisolierung

Standardmäßig verwendet Cloud Load Balancing den WATERFALL_BY_REGION-Algorithmus, um zu entscheiden, wohin der Nutzertraffic weitergeleitet werden soll. Bei WATERFALL_BY_REGION wird der Traffic auf andere Regionen umgeleitet, wenn die Back-Ends in der Region, die dem Nutzer am nächsten ist, entweder voll oder fehlerhaft sind. Wenn Sie die Traffic-Isolation aktivieren, kann der Load Balancer den Traffic nur an die Region weiterleiten, die dem Nutzer am nächsten ist, auch wenn alle Back-Ends in dieser Region ihre konfigurierte Kapazitätsgrenze erreichen. Wenn Sie die Traffic-Isolation aktivieren, können Sie kaskadierende regionale Ausfälle verhindern und potenzielle Ausfälle auf eine einzelne Region beschränken.

Die Traffic-Isolation wird als Teil der Richtlinie für das Dienst-Load Balancing konfiguriert. Es gibt zwei Isolationsmodi:

• NEAREST (Standardeinstellung): Der Load Balancer (d. h. entweder der GFE der zweiten Schicht oder der Envoy-Proxy, der die Verbindung verarbeitet) sendet Traffic an Back-Ends in der Region, die dem Nutzer am nächsten ist. Wenn in der nächstgelegenen Region keine Back-Ends konfiguriert sind oder die Back-Ends in der nächstgelegenen Region fehlerhaft sind, wird der Traffic an die nächstgelegene Region weitergeleitet und dabei die Netzwerklatenz optimiert. Sobald die Bereitstellungskapazität in einer Region erschöpft ist, wird der Vorgang fortgesetzt.

  Der Isolationsmodus NEAREST ist für alle unterstützten Load Balancer verfügbar.

• STRICT: Der Load Balancer (d. h. der Envoy-Proxy, der die Verbindung verarbeitet) sendet Traffic nur an Back-Ends in der Region, die dem Nutzer am nächsten ist. Wenn in der nächstgelegenen Region keine Back-Ends konfiguriert sind oder die Back-Ends in der nächstgelegenen Region nicht fehlerfrei sind und keine Anfragen bedienen können, wird der Traffic gelöscht und Anfragen schlagen fehl.

  Der Isolationsmodus STRICT ist nur für regionenübergreifende interne Application Load Balancer und regionenübergreifende interne Proxy-Network Load Balancer verfügbar.

Keine Isolation

Das folgende Diagramm zeigt, wie sich Load Balancer, die mehrere Regionen umfassen, verhalten, wenn die Traffic-Isolation nicht aktiviert ist.

Nächstgelegen

Das folgende Diagramm zeigt, wie sich Load Balancer zwischen Regionen verhalten, wenn die Traffic-Isolation mit dem Modus NEAREST aktiviert ist.

Strikt

Das folgende Diagramm zeigt, wie sich Load Balancer zwischen Regionen verhalten, wenn die Traffic-Isolation mit dem Modus STRICT aktiviert ist.

Beachten Sie Folgendes, bevor Sie diese Funktion aktivieren:

• Wenn Ihre Back-Ends in einer Region überlastet sind, sendet der Load Balancer möglicherweise weiterhin zusätzlichen Traffic an sie, auch wenn Back-Ends in anderen Regionen den Traffic verarbeiten können. Das bedeutet, dass die Backends in den einzelnen Regionen aufgrund des zusätzlichen Traffics mit größerer Wahrscheinlichkeit überlastet werden. Sie müssen also entsprechend planen.

• Auch wenn die Isolation aktiviert ist, wird Ihr Traffic weiterhin über eine globale Steuerungsebene weitergeleitet. Das bedeutet, dass es weiterhin zu globalen Ausfällen in mehreren Regionen kommen kann. Für eine bessere Isolation auf Infrastrukturebene wählen Sie einen regionalen Load Balancer aus.

Wenn Sie den Modus für die Traffic-Isolation konfigurieren, müssen Sie auch die Isolierungsgranularität auf REGION festlegen. Dadurch wird ein regionsübergreifender Traffic-Overflow verhindert. Wenn die Detaillierung nicht konfiguriert ist, wird die Traffic-Isolation nicht erzwungen. Weitere Informationen zum Aktivieren der Traffic-Isolation finden Sie unter Dienst-Load-Balancing-Richtlinie konfigurieren.

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

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
• Trafficisolierung

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.

In der Richtlinie konfigurierte Funktionen deaktivieren

In diesem Abschnitt erfahren Sie, wie Sie in der Load Balancing-Richtlinie für Dienste konfigurierte Funktionen zurücksetzen oder deaktivieren.

Load-Balancing-Algorithmus zurücksetzen

Mit dem folgenden Befehl können Sie den Load-Balancing-Algorithmus auf die Standardeinstellung WATERFALL_BY_REGION zurücksetzen:

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --load-balancing-algorithm=WATERFALL_BY_REGION \
    --location=global

Failover-Grenzwert zurücksetzen

Mit dem folgenden Befehl können Sie den Failover-Schwellenwert auf die Standarddauer von 70 Sekunden zurücksetzen:

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --failover-health-threshold=70 \
    --location=global

Automatischen Kapazitätsausgleich deaktivieren

Verwenden Sie den folgenden Befehl, um das automatische Entladen der Kapazität zu deaktivieren:

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --no-auto-capacity-drain \
    --location=global

Trafficisolierung deaktivieren

Wenn Sie die Traffic-Isolation (Vorabversion) deaktivieren möchten, setzen Sie beide Konfigurationsparameter für die Isolation auf UNSPECIFIED, wie im folgenden Befehl gezeigt:

gcloud beta network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --isolation-config-granularity=UNSPECIFIED \
    --isolation-config-mode=UNSPECIFIED \
    --location=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 compute backend-services add-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

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

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

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

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 auftreten können, wenn Sie eine dieser Funktionen aktivieren.

Load-Balancing-Algorithmen

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.

Automatischer Ausgleich von Kapazitäten

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.

Failover-Schwellenwert

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

Dies ist das beabsichtigte Verhalten, wenn der Failover-Grenzwert auf einen hohen Wert festgelegt 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.

Bevorzugte Back-Ends

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.

Trafficisolierung

Anfragen an Ihren regionenübergreifenden internen Load Balancer schlagen fehl

Wenn der Isolationsmodus STRICT aktiviert ist und keine Back-Ends in derselben Region wie der Load Balancer konfiguriert sind, ist mit einer Fehlfunktion des Traffics zu rechnen. Wenn dies nicht beabsichtigt ist, müssen Sie Backends in der Region haben, in die der Traffic gesendet werden soll. Sie können auch den Isolationsmodus auf NEAREST festlegen, damit Traffic an die nächstgelegene Region weitergeleitet werden kann.

Traffic wird von einer entfernten Region in eine näher gelegene Region weitergeleitet

Die Anfrageisolierung verhindert einen kapazitätsbasierten Traffic-Überlauf. Wenn Ihre Back-Ends also bereits überlastet waren, bevor Sie diese Funktion aktiviert haben, wurde der Traffic möglicherweise bereits an eine entfernte Region gesendet. In diesem Fall kann es passieren, dass dieser Traffic an die nächstgelegene Region zurückgeleitet wird, wenn Sie diese Funktion aktivieren.

Nachdem die Traffic-Isolation aktiviert wurde, wurde der Traffic nicht umgeleitet

Die Anfrageisolierung verhindert einen kapazitätsbasierten Traffic-Überlauf. Wenn Ihre Back-Ends in der nächstgelegenen Region vor der Aktivierung dieser Funktion nicht überlastet waren, ist es wahrscheinlich, dass die nächstgelegene Region den gesamten Traffic verarbeiten kann. In diesem Fall sind kurzfristig keine Änderungen an den Verkehrsrouten zu erwarten. Das kann sich ändern, wenn sich das Traffic-Volumen ändert.

Traffic wird umgeleitet, wenn einer Region Backends hinzugefügt oder daraus entfernt werden

Das ist ein normales Verhalten, da Load Balancer versuchen, den Traffic so zu leiten, dass die Gesamtlatenz des Netzwerks optimiert wird. Wenn also neue Back-Ends in einer näher gelegenen Region bereitgestellt werden, sendet der Load Balancer möglicherweise mehr Traffic an diese Region. Wenn Back-Ends entfernt werden, sendet der Load Balancer je nach Einstellung für die Anfrageisolierung Überlauf-Traffic an eine weiter entfernte Region.

Beschränkungen

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