Erweitertes Load Balancing – Übersicht

Erweitertes Load Balancing umfasst Funktionen, mit denen Sie das globale Load Balancing und die Trafficverteilung optimieren können, um Ihre Ziele in Bezug auf Verfügbarkeit, Leistung und Kosteneffizienz bestmöglich zu erreichen. Dieses Dokument richtet sich an Nutzer, die zumindest über grundlegende Kenntnisse von Cloud Service Mesh und Load-Balancing-Konzepten verfügen.

Wenn Sie erweitertes Load-Balancing implementieren möchten, erstellen Sie eine Load-Balancing-Richtlinie für Dienste (serviceLbPolicies-Ressource), die Werte enthält, die die Auswahl eines Backends beeinflussen. Anschließend hängen Sie die Load-Balancing-Richtlinie für Dienste an einen Backend-Dienst an. Die Load-Balancing-Richtlinie für Dienste gibt den Algorithmus an, der verwendet wird, um zu bestimmen, wie der Traffic auf die Back-Ends verteilt wird.

Für das erweiterte Load-Balancing stehen die folgenden Algorithmusoptionen zur Auswahl:

  • Waterfall-by-Region-Algorithmus (Standardalgorithmus).
  • Spray-to-Region-Algorithmus
  • Spray-to-World-Algorithmus
  • Waterfall-by-Zone-Algorithmus

Folgende zusätzliche Optionen sind verfügbar:

  • Bevorzugte Back-Ends festlegen Cloud Service Mesh sendet Traffic an diese MIGs oder NEGs, bevor es Traffic an andere Back-Ends sendet.
  • Automatischen Kapazitätsausgleich einrichten
  • Failover-Verhalten anpassen

Bevor Sie eine der erweiterten Load-Balancing-Optionen konfigurieren, empfehlen wir, die Dokumentation zur Backend-Dienstressource zu lesen.

So leitet Cloud Service Mesh Traffic weiter und führt ein Load-Balancing aus

Das folgende Diagramm zeigt, wie Cloud Service Mesh Traffic weiterleitet.

So trifft Cloud Service Mesh Entscheidungen zum Load Balancing
Wie Cloud Service Mesh Load-Balancing-Entscheidungen trifft (zum Vergrößern klicken)

Zuerst wählt Cloud Service Mesh einen Backend-Dienst anhand von Anfragecharakteristiken und Routingregeln in der Route-Ressource oder URL-Zuordnung aus, je nachdem, welche API für die Bereitstellung verwendet wird.

Zweitens wählt Cloud Service Mesh eine Backend-MIG oder ‑NEG aus, die dem Backend-Dienst zugeordnet ist. Die Auswahl erfolgt anhand des Clientstandorts, des Standorts, des Zustands und der Kapazität der MIG oder NEG sowie anhand von Informationen in der Richtlinie für den Dienst-Load-Balancer, die dem Backend-Dienst zugeordnet ist.

Schließlich wählt Cloud Service Mesh eine Instanz oder einen Endpunkt innerhalb der MIG oder NEG aus. Diese Auswahl basiert auf Informationen in der Load-Balancing-Richtlinie für den Ort in den Back-End-Diensten.

Unterstützte und nicht unterstützte Back-Ends

Die folgenden Backend-Typen werden für das erweiterte Load Balancing unterstützt:

  • Nicht verwaltete Instanzgruppen
  • Verwaltete Instanzgruppen (MIGs)
  • Zonale Netzwerk-Endpunktgruppen (GCE_VM_IP_PORT-NEGs)
  • Netzwerk-Endpunktgruppen mit Hybridkonnektivität (NON_GCP_PRIVATE_IP_PORT-NEG)

Die folgenden Backend-Typen werden für erweitertes Load Balancing nicht unterstützt:

  • Regional verwaltete Instanzgruppen
  • Internet-NEGs (INTERNET_FQDN_PORT-Netzwerk-Endpunktgruppen)

Anwendungsfälle

In den folgenden Abschnitten wird beschrieben, wie die einzelnen Algorithmen funktionieren und welcher für Ihre speziellen geschäftlichen Anforderungen am besten geeignet ist.

Traffic auf Backends in einer Region gleichmäßig verteilen

Der Standard-Load-Balancing-Algorithmus „Waterfall by region“ (Wasserfall nach Region) verteilt den Traffic gleichmäßig auf alle MIGs oder NEGs in Zonen in einer Region. Wir empfehlen, den Standardalgorithmus zu verwenden, sofern Sie keine besonderen Anforderungen haben.

Beim Wasserfall nach Region erhalten Back-Ends Traffic entsprechend ihrer Kapazität, was vor einer Überlastung der Back-Ends schützt. Der Traffic wird bei Bedarf zonenübergreifend gesendet, um die Back-Ends in der Region gleichmäßig auszulasten. Auch wenn die Zone, die sich in der Nähe des Clients befindet, noch Kapazität hat, gibt es zonenübergreifenden Traffic. Die Anfragen jedes Clients können auf mehrere zonale MIGs oder NEGs in der Region verteilt werden. So lässt sich die Last auf den MIGs oder NEGs gleichmäßig verteilen, wenn die Trafficlast der Clients nicht gleichmäßig ist.

Resilienz durch Verteilung des Traffics von einem Client auf Zonen erhöhen

Der Standardalgorithmus für den Wasserfall nach Region versucht, die Kapazitätsauslastung über mehrere zonale MIGs oder NEGs hinweg auszugleichen. Bei diesem Algorithmus werden Anfragen, die von einem einzelnen Client stammen, jedoch nicht immer an alle Zonen gesendet. Anfragen von einem einzelnen Client werden in der Regel an MIGs oder NEGs in einer einzelnen Zone weitergeleitet.

Verwenden Sie den Algorithmus „Spray to region“, wenn Clients ihre Anfragen auf alle MIGs oder NEGs in einer Region verteilen sollen. Dadurch wird das Risiko einer Überlastung von MIGs oder NEGs in einer einzelnen Zone bei einem schnellen, lokalisierten Anstieg des Trafficvolumens verringert.

Wenn Sie mit dem Algorithmus „Spray to region“ zwei Zonen (A und B) haben und es in Zone B zu einem Traffic-Spike kommt, wird der Traffic auf die beiden Zonen aufgeteilt. Mit dem Standardalgorithmus kann ein Anstieg in Zone B eine Überlastung in Zone A auslösen, bevor Cloud Service Mesh auf die Änderung reagieren kann.

Wenn Sie den Algorithmus „Spray to region“ verwenden, wird der Traffic für jeden Client immer auf die Backend-Zonen in einer Region verteilt. Dies führt zu einem konstant höheren zonenübergreifenden Traffic, auch wenn in der lokalen Zone noch Kapazität vorhanden ist. Außerdem kann der betroffene Bereich für den Traffic von Cloud Service Mesh größer sein, wenn zwei Cloud Service Mesh-Clients Traffic an dieselben Zonen senden.

Traffic von Ihrem Client auf alle Backends in mehreren Regionen verteilen

Wie in den vorherigen Abschnitten beschrieben, verteilt der Algorithmus „Spray to Region“ den Traffic von jedem Client auf alle Zonen in einer Region. Bei Diensten mit MIGs oder NEGs in mehreren Regionen optimiert Cloud Service Mesh weiterhin die Gesamtlatenz, indem Traffic an die nächstgelegene Region gesendet wird.

Wenn Sie einen größeren Radius bevorzugen, verwenden Sie den Algorithmus „Spray to World“. Mit diesem Algorithmus verteilen Clients ihre Anfragen auf alle MIGs oder NEGs weltweit in mehreren Regionen.

Bei diesem Algorithmus wird der gesamte Traffic weltweit auf alle Back-Ends verteilt. Eine fehlerhafte Anfrage kann alle Backends in Ihren Bereitstellungen beschädigen. Der Algorithmus führt auch zu mehr regionsübergreifendem Traffic, was die Anfragelatenz erhöhen und zusätzliche Kosten verursachen kann.

Zonenübergreifenden Traffic minimieren

Mit der Einstellung „Wasserfall nach Zone“ können Sie die Gesamtlatenz optimieren und zonenübergreifenden Traffic reduzieren. Wenn mehrere MIGs oder NEGs in einer Zone konfiguriert sind, wird der Client-Traffic an die nächstgelegene MIG oder NEG in der Zone weitergeleitet, bis deren Kapazität erreicht ist. Anschließend wird der Traffic an die nächste MIG oder NEG in der Zone gesendet, bis die gesamte MIG- oder NEG-Kapazität in der Zone genutzt ist. Erst dann wird der Traffic in die nächstgelegene Zone weitergeleitet.

Mit diesem Algorithmus können Sie unnötigen zonenübergreifenden Traffic minimieren. Die Gesamtlatenz kann sich leicht verbessern, da die nächstgelegenen lokalen Backends bevorzugt werden. Dies kann jedoch auch zu ungleichmäßigem Traffic über die MIGs oder NEGs in einer Region hinweg führen.

Vergleich der Load-Balancing-Algorithmen

Die folgende Tabelle bietet einen detaillierten Vergleich der vier Cloud Service Mesh-Load-Balancing-Algorithmen.

Verhalten Waterfall-by-Region-Algorithmus Spray-to-Region-Algorithmus Spray-to-World-Algorithmus Waterfall-by-Zone-Algorithmus
Einheitliche Kapazitätsnutzung innerhalb einer Region im stabilen Zustand Ja Ja Ja Nein
Einheitliche Kapazitätsnutzung über mehrere Regionen hinweg im stabilen Zustand Nein Nein Ja Nein
Einheitliche Trafficaufteilung innerhalb einer Region im stabilen Zustand Nein Ja Ja Nein
Zonenübergreifender Traffic Ja. Mit diesem Algorithmus wird der Traffic gleichmäßig auf die Zonen in einer Region verteilt und gleichzeitig die Netzwerklatenz optimiert. Der Traffic wird möglicherweise zonenübergreifend gesendet. Ja Ja Ja, der Traffic wird die nächstgelegene Zone bis zur Kapazitätsgrenze auslasten. Danach geht es zur nächsten 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. Weniger: Spitzen einzelner Zonen sind auf alle Regionen verteilt. Höher: Spitzen bei einzelnen Zonen werden wahrscheinlich vollständig von derselben Zone bereitgestellt, bis Cloud Service Mesh reagieren kann.

Zusätzliche erweiterte Load-Balancing-Optionen

In den folgenden Abschnitten werden Optionen zum Ändern des Load-Balancing von Cloud Service Mesh beschrieben.

Bevorzugte Back-Ends

Sie können das Load-Balancing so konfigurieren, dass eine Gruppe von Back-Ends eines Back-End-Dienstes als bevorzugt festgelegt wird. Diese Back-Ends werden vollständig genutzt, bevor nachfolgende Anfragen an die verbleibenden Back-Ends weitergeleitet werden. Cloud Service Mesh leitet Client-Traffic zuerst an die bevorzugten Backends weiter, um die Anfragelatenzen für Ihre Clients zu minimieren.

Der gesamte Traffic, der die konfigurierte Kapazität der bevorzugten Back-Ends überschreitet, wird an nicht bevorzugte Back-Ends weitergeleitet. Der Load-Balancing-Algorithmus verteilt den Traffic auf die nicht bevorzugten Backends.

Ein Anwendungsfall ist der Überlauf zu Google Cloud, bei dem Sie lokale Computeressourcen angeben, die durch ein Hybridkonnektivitäts-NEG dargestellt werden. Diese Ressourcen werden vollständig genutzt, bevor Anfragen an automatisch skalierte Google Cloud Backend-MIGs oder NEGs weitergeleitet werden. Mit dieser Konfiguration kann der Google Cloud Rechenaufwand minimiert werden. Bei Bedarf kann jedoch weiterhin schrittweise aufGoogle Cloud übergegangen oder ein Failover zuGoogle Cloud durchgeführt werden.

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 des Back-Ends wird verhindert, dass Anfragen an das fehlerhafte Back-End gesendet werden. Außerdem wird der Traffic auf fehlerfreie Back-Ends verteilt, um eine Überlastung der Back-Ends zu verhindern und die Gesamtlatenz zu optimieren.

Diese Option ähnelt dem Festlegen von capacityscalar auf null. Cloud Service Mesh wird aufgefordert, die Back-End-Kapazität automatisch auf null zu reduzieren, wenn weniger als 25% der einzelnen Instanzen oder Endpunkte eines Back-Ends Systemdiagnosen bestehen. Mit dieser Option werden fehlerhafte Backends aus dem globalen Load-Balancing entfernt.

Wenn die automatisch geleerten Backends wieder fehlerfrei sind, werden sie entleert, wenn mindestens 35% der Endpunkte oder Instanzen 60 Sekunden lang fehlerfrei sind. Cloud Service Mesh beendet nicht mehr als 50% der Endpunkte in einem Backend-Dienst, unabhängig vom Systemstatus des Backends.

Ein Anwendungsfall ist, dass Sie den automatischen Kapazitätsausgleich mit bevorzugten Back-Ends verwenden können. Wenn eine Backend-MIG oder -NEG bevorzugt wird und viele der Endpunkte darin fehlerhaft sind, schützt diese Einstellung die verbleibenden Endpunkte in der MIG oder NEG, indem der Traffic von der MIG oder NEG weggeleitet wird.

Failover-Verhalten anpassen

Cloud Service Mesh leitet Traffic in der Regel unter Berücksichtigung mehrerer Faktoren an Backends weiter. Im stabilen Zustand leitet Cloud Service Mesh Traffic an Back-Ends weiter, die anhand der oben beschriebenen Algorithmen ausgewählt werden. Die ausgewählten Backends gelten als optimal in Bezug auf Latenz und Kapazitätsauslastung. Sie werden als primäre Back-Ends bezeichnet.

Cloud Service Mesh verfolgt auch Back-Ends, die verwendet werden können, wenn die primären Back-Ends fehlerhaft sind und keinen Traffic empfangen können. Diese Back-Ends werden als Failover-Back-Ends bezeichnet. In der Regel handelt es sich dabei um Back-Ends in der Nähe mit verfügbaren Kapazitäten.

Wenn ein Backend fehlerhaft ist, versucht Cloud Service Mesh, keinen Traffic an dieses Backend zu senden, und leitet den Traffic stattdessen an fehlerfreie Backends weiter.

Die serviceLbPolicy-Ressource enthält das Feld failoverHealthThreshold, dessen Wert angepasst werden kann, um das Failover-Verhalten zu steuern. Der von Ihnen festgelegte Schwellenwert bestimmt, wann der Traffic von primären Back-Ends zu Failover-Back-Ends verschoben wird.

Wenn einige Endpunkte im primären Backend fehlerhaft sind, leitet Cloud Service Mesh den Traffic nicht unbedingt sofort um. Stattdessen leitet Cloud Service Mesh den Traffic möglicherweise an fehlerfreie Endpunkte im primären Back-End weiter, um den Traffic zu stabilisieren.

Wenn zu viele Endpunkte im Backend fehlerhaft sind, können die verbleibenden Endpunkte zusätzlichen Traffic nicht verarbeiten. In diesem Fall wird anhand des Fehlerschwellenwerts entschieden, ob ein Failover ausgelöst wird. Cloud Service Mesh toleriert Fehler bis zum Schwellenwert und leitet dann einen Teil des Traffics von den primären Backends zu den Failover-Backends um.

Der Fehlerschwellenwert für Failover ist ein Prozentwert. Der von Ihnen festgelegte Wert bestimmt, wann Cloud Service Mesh Traffic an die Failover-Back-Ends weiterleitet. Sie können den Wert auf eine Ganzzahl zwischen 1 und 99 festlegen. Der Standardwert für Cloud Service Mesh ist 70 mit Envoy und 50 für proxyloses gRPC. Bei einem größeren Wert wird das Traffic-Failover früher gestartet als bei einem kleineren Wert.

Fehlerbehebung

Traffic-Verteilungsmuster können sich ändern, je nachdem, wie Sie die neue serviceLbPolicy mit dem Backend-Dienst einrichten.

Wenn Sie Trafficprobleme beheben möchten, verwenden Sie die vorhandenen Überwachungssysteme, um zu sehen, wie Traffic zu Ihren Back-Ends fließt. Zusätzliche Cloud Service Mesh- und Netzwerkmesswerte können Ihnen helfen, die Entscheidungen zum Load Balancing besser nachzuvollziehen. In diesem Abschnitt finden Sie allgemeine Vorschläge zur Fehlerbehebung und Risikominderung.

Insgesamt versucht Cloud Service Mesh, Traffic so zuzuweisen, dass Back-Ends unter ihrer konfigurierten Kapazität bleiben. Beachten Sie, dass dies nicht garantiert werden kann. Weitere Informationen finden Sie in der Dokumentation zum Back-End-Dienst.

Der Traffic wird dann basierend auf dem verwendeten Algorithmus zugewiesen. Beim Algorithmus WATERFALL_BY_ZONE versucht Cloud Service Mesh beispielsweise, den Traffic in der nächstgelegenen Zone zu halten. Wenn Sie die Netzwerkmesswerte prüfen, sehen Sie, dass Cloud Service Mesh ein Backend mit der niedrigsten RTT-Latenz bevorzugt, wenn Anfragen gesendet werden, um die gesamte RTT-Latenz zu optimieren.

In den folgenden Abschnitten werden Probleme beschrieben, die bei der Load-Balancing-Richtlinie für Dienste und den Einstellungen für bevorzugte Backends auftreten können.

Traffic wird vor näher aneinanderliegenden MIGs oder NEGs an weiter entfernte gesendet

Dies ist das vorgesehene Verhalten, wenn bevorzugte Back-Ends mit weiter entfernten MIGs oder NEGs konfiguriert sind. Wenn Sie dies nicht wünschen, ändern Sie die Werte im Feld „Bevorzugte Backends“.

Traffic wird nicht an MIGs oder NEGs mit vielen fehlerhaften Endpunkten gesendet

Dies ist das vorgesehene Verhalten, wenn die MIGs oder NEGs geleert werden, weil eine autoCapacityDrain konfiguriert ist. Mit dieser Einstellung werden MIGs oder NEGs mit vielen fehlerhaften Endpunkten aus Load-Balancing-Entscheidungen entfernt und somit vermieden. Wenn dieses Verhalten nicht gewünscht ist, können Sie die Einstellung autoCapacityDrain deaktivieren. Das bedeutet jedoch, dass Traffic an MIGs oder NEGs mit vielen fehlerhaften Endpunkten gesendet werden kann und Anfragen daher mit Fehlern fehlschlagen können.

Traffic wird nicht an einige MIGs oder NEGs gesendet, wenn einige MIGs oder NEGs bevorzugt werden

Dies ist das beabsichtigte Verhalten, wenn MIGs oder NEGs, die als bevorzugt konfiguriert sind, noch nicht die Kapazität erreicht haben.

Wenn bevorzugte Back-Ends konfiguriert sind und ihr Kapazitätslimit noch nicht erreicht ist, wird kein Traffic an andere MIGs oder NEGs gesendet. Die bevorzugten MIGs oder NEGs werden zuerst basierend auf der RTT-Latenz (Round-Trip Time) diesen Back-Ends zugewiesen.

Wenn Sie möchten, dass Traffic an einen anderen Ort gesendet wird, können Sie den zugehörigen Back-End-Dienst entweder ohne bevorzugte Back-Ends oder mit konservativeren Kapazitätsschätzungen für die bevorzugten MIGs oder NEGs konfigurieren.

Traffic von einer einzelnen Quelle wird an zu viele verschiedene MIGs oder NEGs gesendet

Dies ist das vorgesehene Verhalten, wenn „Spray-to-Region“ oder „Spray-to-World“ verwendet wird. 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 „Wasserfall nach Region“ verwenden.

Traffic wird an einen Remote-Cluster gesendet, wenn sich der Backend-Status ändert

Wenn failoverHealthThreshold auf einen hohen Wert gesetzt ist, ist dies das beabsichtigte Verhalten. Wenn der Traffic bei vorübergehenden Statusänderungen weiter an die primären Back-Ends weitergeleitet werden soll, setzen Sie failoverHealthThreshold auf einen niedrigeren Wert.

Fehlerfreie Endpunkte werden überlastet, wenn einige Endpunkte fehlerhaft sind

Wenn failoverHealthThreshold auf einen niedrigen Wert gesetzt ist, ist dies das beabsichtigte Verhalten. Wenn einige Endpunkte fehlerhaft sind, wird der Traffic für diese Endpunkte möglicherweise auf die verbleibenden Endpunkte in derselben MIG oder NEG verteilt. Wenn das Failover-Verhalten frühzeitig ausgelöst werden soll, legen Sie failoverHealthThreshold auf einen höheren Wert fest.

Einschränkungen und Überlegungen

Im Folgenden finden Sie Einschränkungen und Überlegungen, die Sie bei der Konfiguration von erweitertem Load-Balancing beachten sollten.

Waterfall-by-Zone-Algorithmus

  • Bei transparenten Wartungsereignissen kann es vorkommen, dass der Traffic vorübergehend außerhalb der lokalen Zone verteilt wird.

  • Es kann vorkommen, dass einige MIGs oder NEGs ausgelastet sind, während andere MIGs oder NEGs in derselben Region unterlastet sind.

  • Wenn sich die Quelle des Traffics für Ihren Dienst in derselben Zone wie seine Endpunkte befindet, wird der zonenübergreifende Traffic reduziert.

  • Eine Zone kann verschiedenen Clustern interner physischer Hardware in Google-Rechenzentren zugeordnet sein, z. B. aufgrund der Zonenvirtualisierung. In diesem Fall werden VMs in derselben Zone möglicherweise nicht gleichmäßig ausgelastet. Im Allgemeinen wird die Gesamtlatenz optimiert.

Spray-to-Region

  • Wenn die Endpunkte in einer MIG oder NEG ausfallen, verteilen sich die Folgen in der Regel auf eine größere Anzahl von Clients. Das bedeutet, dass eine größere Anzahl von Mesh-Clients betroffen sein kann, aber weniger schwerwiegend.

  • Da die Clients Anfragen an alle MIGs oder NEGs in der Region senden, kann dies in einigen Fällen den zonenübergreifenden Traffic erhöhen.

  • Die Anzahl der zu Endpunkten geöffneten Verbindungen kann zunehmen, was zu einer erhöhten Ressourcennutzung führt.

Bevorzugte Back-Ends

  • Die als bevorzugte Back-Ends konfigurierten MIGs oder NEGs können sich weit von den Clients entfernt befinden und zu einer höheren durchschnittlichen Latenz für Clients führen. Dies kann auch dann passieren, wenn andere MIGs oder NEGs vorhanden sind, die die Clients mit einer geringeren Latenz bereitstellen könnten.

  • Globale Load-Balancing-Algorithmen (Waterfall nach Region, Spray-to-Region, Waterfall nach Zone) gelten nicht für MIGs oder NEGs, die als bevorzugte Back-Ends konfiguriert sind.

Automatischer Kapazitätsausgleich

  • Die Mindestanzahl von MIGs, die nie geleert werden, unterscheidet sich vom Wert, der bei der Konfiguration mit serviceLbPolicies festgelegt wird.

  • Standardmäßig ist die Mindestanzahl von MIGs, die nie geleert werden, 1.

  • Wenn serviceLbPolicies festgelegt ist, beträgt der Mindestprozentsatz von MIGs oder NEGs, die nie geleert werden, 50%. Bei beiden Konfigurationen wird eine MIG oder ein NEG als fehlerhaft markiert, wenn weniger als 25% der Instanzen oder Endpunkte in der MIG oder im NEG fehlerfrei sind.

  • Damit eine MIG oder NEG nach dem Entleeren wieder gefüllt werden kann, müssen mindestens 35% der Instanzen oder Endpunkte fehlerfrei sein. Dies ist erforderlich, damit eine MIG oder NEG nicht zwischen den Zuständen „Drain“ und „Undrained“ wechselt.

  • Hier gelten dieselben Einschränkungen für den Kapazitätsskalierer für Back-Ends, die keinen Balancing-Modus verwenden.

Nächste Schritte