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 Dokumentation zu Cloud Service Mesh.

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 einem Backend-Dienst zugeordnet sind:

    • 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 Ausgleich von Kapazitäten: 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 gilt. So kann Traffic zu einem anderen Backend weitergeleitet werden; fehlerhafte Backends werden so vermieden.
    • Trafficisolierung: Kaskadierende Fehler verhindern, indem Sie regionenübergreifenden Traffic-Überlauf begrenzen 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.

So trifft Cloud Load Balancing Entscheidungen zur Routing- und Trafficverteilung.
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 Load-Balancer und Back-Ends

Die folgenden Load-Balancer unterstützen Load-Balancing-Richtlinien für Dienste 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:

Backend Unterstützt?
Instanzgruppen
Zonale nicht verwaltete und zonale verwaltete Instanzgruppen werden unterstützt, regionale verwaltete Instanzgruppen jedoch nicht.
Zonale NEGs (GCE_VM_IP_PORT-Endpunkte)
Zonale NEGs (GCE_VM_IP-Endpunkte)
Diese Arten von NEGs werden von Application Load Balancern und Proxy-Network Load Balancern nicht unterstützt.
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 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 ihr konfiguriertes Kapazitätslimit erreicht haben, wird der Traffic an die nächstgelegene Region weitergeleitet, wobei die Netzwerklatenz optimiert wird.

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.

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 und Abbau von Kapazitäten

Beim automatischen Kapazitätsausgleich und ‑wiederherstellung werden die Konzepte von Systemdiagnosen und Backend-Kapazität kombiniert. Beim automatischen Kapazitätsausgleich werden Systemdiagnosen als zusätzliches Signal verwendet, um die effektive Backend-Kapazität auf null zu setzen. Beim automatischen Aufheben des Kapazitätstrainings werden Health-Checks als zusätzliches Signal verwendet, um die effektive Backend-Kapazität auf den vorherigen Wert zurückzusetzen.

Ohne automatisches Reduzieren und Wiederherstellen der Kapazität müssen Sie die effektive Kapazität jedes Back-Ends in einer bestimmten Region manuell auf null setzen, wenn Sie Anfragen von allen Back-Ends in dieser Region weiterleiten möchten. Dazu können Sie beispielsweise den Kapazitätsskalierer verwenden.

Mit dem automatischen Kapazitätsausgleich und -rückgängigmachen können Systemdiagnosen als Signal verwendet werden, um die Kapazität eines Back-Ends durch Ausgleich oder Rückgängigmachen des Ausgleichs anzupassen.

Informationen zum Aktivieren des automatischen Leeren und Wiederherstellen von Kapazitäten finden Sie unter Dienst-Load-Balancing-Richtlinie konfigurieren.

Automatischer Ausgleich von Kapazitäten

Mit Auto-capacity draining wird die Kapazität jeder drainable candidate backend-Instanzgruppe oder jedes NEG auf null gesetzt, solange das Verhältnis von drainable candidate backend-Instanzgruppen oder NEGs zu allen Backend-Instanzgruppen oder NEGs weniger als 50 % beträgt. Bei der Berechnung des Verhältnisses von 50% werden Back-Ends mit einer Kapazität von null nicht im Zähler berücksichtigt. Alle Back-Ends werden jedoch im Nenner berücksichtigt.

Ein Backend-Kandidat für den Ausgleich ist eine Backend-Instanzgruppe oder NEG, bei der weniger als 25% der Mitgliedsinstanzen oder ‑endpunkte die Systemdiagnosen des Load Balancers bestehen.

Die folgenden Back-Ends haben keine Kapazität:

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

Automatisch geleerte Backend-Kapazität entspricht funktional dem manuellen Festlegen von backendService.backends[].capacityScaler eines Backends auf 0, jedoch ohne Festlegen des Kapazitätsskalierungswerts.

Automatischer Ausgleich von Kapazitäten

Beim automatischen Kapazitätsausgleich wird die Kapazität eines Back-Ends auf den Wert zurückgesetzt, der vom Kapazitätsskalierer des Back-Ends gesteuert wird, wenn mindestens 35% der Back-End-Instanzen oder -Endpunkte mindestens 60 Sekunden lang Systemdiagnosen bestehen. Die Anforderung von 60 Sekunden verringert die Wahrscheinlichkeit, dass das Gerät bei aufeinanderfolgenden fehlgeschlagenen und bestandenen Systemdiagnosen schnell entladen und wieder aufgeladen wird.

Failover-Schwellenwert

Der Load-Balancer bestimmt die Verteilung des Traffics auf die Back-Ends auf mehrstufige Weise. Im stabilen Zustand wird der Traffic an Back-Ends gesendet, die anhand eines der zuvor beschriebenen Load-Balancing-Algorithmen ausgewählt wurden. Diese Back-Ends werden als primäre Back-Ends bezeichnet und gelten in Bezug auf 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 Fehler im primären Back-End bis zum Failover-Schwellenwert. Danach wird der Traffic vom primären Backend 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 Standardgrenzwert für das Failover 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. Es liegt in Ihrer Verantwortung, dafür zu sorgen, dass Ihre Failover-Back-Ends den zusätzlichen Traffic bewältigen können.

Failover-Traffic kann zu überlasteten Backends führen. Auch wenn ein Backend fehlerhaft ist, kann der Load Balancer weiterhin Traffic dorthin senden. 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 Nutzer-Traffic weitergeleitet werden soll. Mit 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 ausgelastet oder fehlerhaft sind. Wenn Sie die Traffic-Isolation aktivieren, leitet der Load-Balancer den Traffic nur an die Region weiter, die dem Nutzer am nächsten ist, auch wenn alle Back-Ends in dieser Region an ihrem konfigurierten Kapazitätslimit ausgeführt werden. Wenn Sie die Traffic-Isolation aktivieren, können Sie kaskadierende regionale Fehler verhindern und potenzielle Ausfälle auf eine einzelne Region beschränken.

Die Traffic-Isolation wird als Teil der Richtlinie zum Dienst-Load-Balancing konfiguriert. Es gibt zwei Isolierungsmodi:

  • NEAREST (Standard): Der Load-Balancer (entweder das GFE der zweiten Ebene 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 unter Berücksichtigung der Netzwerklatenz an die nächstgelegene Region weitergeleitet. Dies wird fortgesetzt, bis in jeder Region die Bereitstellungskapazität erschöpft ist.

    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 Back-Ends in der nächstgelegenen Region fehlerhaft sind und keine Anfragen verarbeiten können, wird der Traffic verworfen 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 regionenübergreifende Load Balancer verhalten, wenn die Traffic-Isolation nicht aktiviert ist.

Verhalten von Cloud Load Balancing, wenn die Traffic-Isolation nicht aktiviert ist.
Verhalten von Cloud Load Balancing, wenn die Traffic-Isolation nicht aktiviert ist.

Nächstgelegen

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

Verhalten von Cloud Load Balancing, wenn die Traffic-Isolation im NEAREST-Modus aktiviert ist.
Verhalten von Cloud Load Balancing, wenn die Traffic-Isolation im NEAREST-Modus aktiviert ist.

Strikt

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

Verhalten von Cloud Load Balancing, wenn die Traffic-Isolation im STRICT-Modus aktiviert ist.
Verhalten von Cloud Load Balancing, wenn die Traffic-Isolation im STRICT-Modus aktiviert ist.

Beachten Sie Folgendes, bevor Sie dieses Feature 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 Backends in jeder einzelnen Region aufgrund des zusätzlichen Traffics eher überlastet werden. Sie müssen dies entsprechend berücksichtigen.

  • Auch wenn die Isolation aktiviert ist, wird Ihr Traffic weiterhin über eine globale Steuerungsebene weitergeleitet. Das bedeutet, dass es immer noch die Möglichkeit globaler Fehler in mehreren Regionen gibt. 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, um regionsübergreifende Traffic-Überläufe zu verhindern. Wenn die Granularität 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.

Console

Führen Sie die folgenden Schritte aus, um eine Load-Balancing-Richtlinie für Dienste zu erstellen.

  1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

    Load-Balancing aufrufen

  2. Klicken Sie auf Richtlinie für das Dienst-Load Balancing erstellen.

  3. Geben Sie einen Namen für die Load Balancing-Richtlinie für Dienste ein.

  4. Wenn Sie den automatischen Kapazitätsausgleich aktivieren möchten, wählen Sie Traffic von fehlerhaften Back-Ends leeren aus.

  5. Geben Sie für Schwellenwert für Failover eine Zahl zwischen 1 und 99 ein.

  6. Wählen Sie unter Trafficverteilung den Load-Balancing-Algorithmus aus, den Sie verwenden möchten.

  7. Klicken Sie auf Erstellen.

gcloud

  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
isolationConfig:
  isolationGranularity: ISOLATION_GRANULARITY
  isolationMode: ISOLATION_MODE

    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.
    • ISOLATION_GRANULARITY: Der Detaillierungsgrad für die Einschränkung der Isolation. Um einen regionsübergreifenden Traffic-Überlauf zu verhindern, legen Sie diesen Wert auf REGION fest. Wenn nichts angegeben ist, wird keine Isolation erzwungen.
    • ISOLATION_MODE: das Isolationsverhalten. Die möglichen Werte sind entweder NEAREST oder STRICT.

    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 den folgenden Befehl, 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.

    Verwenden Sie den folgenden Befehl, um die Traffic-Isolation (Vorschau) zu konfigurieren:

    gcloud beta network-services service-lb-policies create SERVICE_LB_POLICY_NAME \
   --isolation-config-granularity=ISOLATION_GRANULARITY \
   --isolation-config-mode=ISOLATION_MODE \
   --location=global

    Ersetzen Sie Folgendes:

    • ISOLATION_GRANULARITY: Der Detaillierungsgrad für die Einschränkung der Isolation. Um einen regionsübergreifenden Traffic-Überlauf zu verhindern, legen Sie diesen Wert auf REGION fest. Wenn nichts angegeben ist, wird keine Isolation erzwungen.
    • ISOLATION_MODE: das Isolationsverhalten. Die möglichen Werte sind NEAREST und STRICT.

  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 auch 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

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

Verwenden Sie den folgenden Befehl, um den Load-Balancing-Algorithmus zurückzusetzen und auf den Standardwert WATERFALL_BY_REGION festzulegen:

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

Failover-Grenzwert zurücksetzen

Verwenden Sie den folgenden Befehl, um den Failover-Schwellenwert auf den Standardwert von 70 Sekunden zurückzusetzen:

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

Automatischen Ausgleich von Kapazitäten deaktivieren

Verwenden Sie den folgenden Befehl, um die automatische Kapazitätsreduzierung zu deaktivieren:

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

Trafficisolierung deaktivieren

Wenn Sie die Verkehrsflussisolierung (Vorabversion) deaktivieren möchten, setzen Sie beide Konfigurationsparameter für die Isolierung 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.

Console

Sie können ein Backend als bevorzugtes Backend festlegen, wenn Sie einen globalen oder regionenübergreifenden Load Balancer in der Google Cloud Console erstellen.

Legen Sie das Feld Backend-Einstellungsebene auf Bevorzugt fest, wenn Sie das Backend dem Backend-Dienst hinzufügen.

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 auftreten können, wenn Sie die einzelnen 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 vorgesehene 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 vorgesehene Verhalten, wenn der Failover-Schwellenwert auf einen niedrigen Wert festgelegt ist. Wenn Endpunkte fehlerhaft sind, wird der für diese Endpunkte bestimmte Traffic stattdessen auf die verbleibenden Endpunkte im selben Backend verteilt. Wenn das Failover-Verhalten früher ausgelöst werden soll, legen Sie für dieses Feld einen höheren Wert fest.

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, die an Ihren regionenübergreifenden internen Load Balancer gesendet werden, schlagen fehl

Wenn der STRICT-Isolationsmodus aktiviert ist und keine Back-Ends in derselben Region wie der Load Balancer konfiguriert sind, schlägt der Traffic erwartungsgemäß fehl. Wenn das nicht das gewünschte Verhalten ist, müssen Sie dafür sorgen, dass Sie Back-Ends in der Region haben, in die Traffic gesendet werden soll. Sie können den Isolationsmodus auch auf NEAREST festlegen, damit der Traffic an die nächstgelegene Region weitergeleitet werden kann.

Traffic wird von einer Remote-Region an eine näher gelegene Region weitergeleitet

Durch die Anforderungsisolierung wird ein Traffic-Überlauf aufgrund von Kapazitätsüberschreitung verhindert. Wenn Ihre Back-Ends also bereits vor der Aktivierung dieser Funktion überlastet waren, wurde der Traffic möglicherweise schon an eine Remote-Region gesendet. In diesem Fall kann das Aktivieren dieser Funktion dazu führen, dass dieser Traffic an die nächstgelegene Region zurückgeleitet wird.

Traffic wurde nach dem Aktivieren der Traffic-Isolation nicht umgeleitet

Durch die Anforderungsisolierung wird ein Traffic-Überlauf aufgrund von Kapazitätsüberschreitung verhindert. Wenn Ihre Back-Ends in der nächstgelegenen Region vor der Aktivierung dieses Features nicht überlastet waren, ist es wahrscheinlich, dass die nächstgelegene Region den gesamten Traffic verarbeiten kann. In diesem Fall ist es wahrscheinlich, dass Sie kurzfristig keine Änderungen an den Verkehrsrouten sehen. Das kann sich ändern, wenn sich das Trafficvolumen ändert.

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

Das ist das erwartete Verhalten, da Load Balancer versuchen, den Traffic so weiterzuleiten, dass die gesamte Netzwerklatenz optimiert wird. Wenn also neue Back-Ends in einer näheren 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 Anfragetrennung Overflow-Traffic an eine weiter entfernte Region.

Beschränkungen

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