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 mindestens über grundlegendes Wissen zu Cloud Service Mesh und Load Balancing verfügen.

Wenn Sie ein 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 Richtlinie für das Dienst-Load Balancing gibt den Algorithmus an, mit dem bestimmt wird, wie der Traffic auf die Backends verteilt wird.

Für das erweiterte Load Balancing stehen die folgenden Algorithmen 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 er an andere Back-Ends gesendet wird.
  • Richten Sie den automatischen Kapazitätsausgleich ein.
  • Failover-Verhalten anpassen

Bevor Sie eine der erweiterten Load Balancing-Optionen konfigurieren, sollten Sie sich die Dokumentation für die Ressource „Back-End-Dienst“ ansehen.

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

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

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

Zuerst wählt Cloud Service Mesh einen Back-End-Dienst aus, basierend auf den Anfragemerkmalen und den Routingregeln in der Route-Ressource oder URL-Zuordnung, je nachdem, welche API für Ihre Bereitstellung verwendet wird.

Zweitens wählt Cloud Service Mesh eine Back-End-MIG oder NEG aus, die mit dem Back-End-Dienst verknüpft ist. Dabei werden der Standort des Clients, der Standort, der Zustand und die Kapazität der MIG oder NEG sowie Informationen in der mit dem Back-End-Dienst verknüpften Service-Load-Balancing-Richtlinie berücksichtigt.

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

Unterstützte und nicht unterstützte Back-Ends

Die folgenden Backendtypen werden für das erweiterte Load Balancing unterstützt:

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

Die folgenden Backendtypen werden für das erweiterte Load Balancing nicht unterstützt:

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

Anwendungsfälle

In den folgenden Abschnitten wird die Funktionsweise der einzelnen Algorithmen beschrieben und erläutert, welcher für Ihre spezifischen Geschäftsanforderungen am besten geeignet ist.

Traffic auf Backends in einer Region gleichmäßig verteilen

Der standardmäßige Load Balancing-Algorithmus, die abfolgebasierte Verteilung nach Region, verteilt den Traffic gleichmäßig auf alle MIGs oder NEGs in Zonen einer Region. Wir empfehlen, den Standardalgorithmus zu verwenden, es sei denn, Sie haben spezielle Anforderungen.

Bei der abfolgebasierten Zuordnung nach Region erhalten Back-Ends Traffic proportional zu ihrer Kapazität. Das bietet Schutz vor Überlastungen. Bei Bedarf wird Traffic über Zonengrenzen hinweg gesendet, um die Back-Ends innerhalb der Region gleichmäßig auszulasten. Auch wenn die Zone, die dem Client lokal zugeordnet ist, noch Kapazität hat, gibt es zonenübergreifenden Traffic. Die Anfragen der einzelnen 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 halten, wenn die Trafficlast von den Clients nicht gleichmäßig ist.

Ausfallsicherheit erhöhen, indem Traffic von einem Client auf Zonen verteilt wird

Der standardmäßige Abfolgealgorithmus nach Region versucht, die Kapazitätsnutzung auf mehrere zonale MIGs oder NEGs zu verteilen. Bei diesem Algorithmus werden Anfragen, die von einem einzelnen Client stammen, jedoch nicht konsequent 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 verringert, dass MIGs oder NEGs in einer einzelnen Zone überlastet werden, wenn es zu einem schnellen, lokal begrenzten Anstieg des Traffic-Volumens kommt.

Wenn Sie mit dem Algorithmus „Spray to Region“ zwei Zonen (A und B) haben und es in Zone B zu einem Traffic-Anstieg 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 Back-End-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. Wenn zwei Cloud Service Mesh-Clients Traffic an dieselben Zonen senden, kann dies zu einem größeren betroffenen Bereich für den Traffic von Cloud Service Mesh führen.

Traffic von Ihrem Client auf alle Backends in mehreren Regionen verteilen

Wie in den vorherigen Abschnitten erläutert, 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 Streuradius bevorzugen, verwenden Sie den Algorithmus „Spray to World“. Mit diesem Algorithmus verteilen Clients ihre Anfragen auf alle MIGs oder NEGs der Welt in mehreren Regionen.

Bei diesem Algorithmus wird der gesamte Traffic global auf alle Backends verteilt. Eine fehlerhafte Abfrage kann alle Backends in Ihren Bereitstellungen beschädigen. Der Algorithmus führt außerdem zu mehr regionsübergreifendem Traffic, was die Anfragelatenz erhöhen und zusätzliche Kosten verursachen kann.

Zonenübergreifenden Traffic minimieren

Mit der Einstellung „Abfolge nach Zone“ können Sie die Gesamtlatenz optimieren und den zonenübergreifenden Traffic reduzieren. Wenn in einer Zone mehrere MIGs oder NEGs konfiguriert sind, wird der Client-Traffic bis zur Kapazität an die nächstgelegene MIG oder NEG in der Zone weitergeleitet, bevor er an die nächste MIG oder NEG in der Zone gesendet wird, bis die gesamte MIG- oder NEG-Kapazität in der Zone ausgeschöpft ist. Erst dann wird der Traffic auf die nächstgelegene Zone verteilt.

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äßigen Zugriffen auf die MIGs oder NEGs innerhalb einer Region führen.

Load-Balancing-Algorithmen vergleichen

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

Verhalten Abfolge nach Region Spray-to-Region-Algorithmus Spray-to-World-Algorithmus Abfolge nach Zone
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 füllt die nächstgelegene Zone bis zur Kapazität aus. Danach geht es zur nächsten Zone.
Empfindlichkeit gegenüber Trafficspitzen in lokalen Zonen 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 mit höherer Wahrscheinlichkeit vollständig von einer einzelnen Zone bereitgestellt, bis Cloud Service Mesh reagieren kann.

Zusätzliche erweiterte Load Balancing-Optionen

In den folgenden Abschnitten werden Optionen zum Ändern des Cloud Service Mesh-Load Balancings 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 verteilt Client-Traffic zuerst an die bevorzugten Backends, um die Anfragelatenz 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 Back-Ends.

Ein Anwendungsfall ist der Überlauf zu Google Cloud, bei dem Sie angeben, dass lokale Rechenressourcen, die durch eine NEG für die Hybridkonnektivität dargestellt werden, vollständig genutzt werden sollen, bevor Anfragen an automatisch skalierte Google Cloud-Backend-MIGs oder NEGs weitergeleitet werden. Mit dieser Konfiguration lässt sich der Google Cloud-Rechenbedarf minimieren und gleichzeitig die Ausfallsicherheit erhöhen, um bei Bedarf nach und nach auf Google Cloud umzustellen oder ein Failover durchzuführen.

Automatischer Kapazitätsausgleich

Wenn ein Backend fehlerhaft ist, sollten Sie es in der Regel so schnell wie möglich von Load-Balancing-Entscheidungen ausschließen. Wenn Sie das Back-End ausschließen, werden keine Anfragen an das fehlerhafte Back-End gesendet. Außerdem wird der Traffic auf fehlerfreie Back-Ends verteilt, um eine Überlastung des Back-Ends zu verhindern und die Gesamtlatenz zu optimieren.

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

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

Ein Anwendungsfall ist die Verwendung des automatischen Kapazitätsausgleichs mit bevorzugten Back-Ends. Wenn eine bevorzugte MIG oder NEG des Backends viele fehlerhafte Endpunkte enthält, 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 sendet in der Regel Traffic an Backends, wobei mehrere Faktoren berücksichtigt werden. Im Steady State sendet Cloud Service Mesh Traffic an Back-Ends, die anhand der zuvor 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 überwacht auch Back-Ends, die verwendet werden, wenn die primären Back-Ends fehlerhaft sind und keinen Traffic empfangen können. Diese Back-Ends werden als failover bezeichnet. In der Regel sind es Back-Ends in der Nähe, die noch Kapazitäten haben.

Wenn ein Backend fehlerhaft ist, versucht Cloud Service Mesh, Traffic nicht an dieses zu senden, sondern leitet ihn 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 Grenzwert bestimmt, wann Traffic von primären zu Failover-Backends umgeleitet wird.

Wenn einige Endpunkte im primären Backend nicht betriebsbereit sind, leitet Cloud Service Mesh den Traffic nicht unbedingt sofort um. Stattdessen kann Cloud Service Mesh den Traffic an fehlerfreie Endpunkte im primären Back-End weiterleiten, um den Traffic zu stabilisieren.

Sind zu viele Endpunkte im Backend fehlerhaft, können die verbleibenden Endpunkte keinen zusätzlichen Traffic verarbeiten. In diesem Fall wird anhand des Fehlergrenzwerts entschieden, ob der Failover ausgelöst wird. Cloud Service Mesh toleriert eine Unzuverlässigkeit bis zum Grenzwert und verlagert dann einen Teil des Traffics von den primären zu den Failover-Backends.

Der Fehlerschwellenwert für Failover ist ein Prozentsatz. Der von Ihnen festgelegte Wert bestimmt, wann Cloud Service Mesh den 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. Je höher der Wert, desto früher wird das Traffic-Failover gestartet.

Fehlerbehebung

Die 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 zu verstehen, wie Load Balancing-Entscheidungen getroffen werden. In diesem Abschnitt finden Sie allgemeine Vorschläge zur Fehlerbehebung und Risikominimierung.

Insgesamt versucht Cloud Service Mesh, Traffic so zuzuweisen, dass Back-Ends unter ihrer konfigurierten Kapazität laufen. Beachte bitte, 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. Mit dem Algorithmus WATERFALL_BY_ZONE versucht Cloud Service Mesh beispielsweise, den Traffic auf die nächstgelegene Zone zu beschränken. Wenn Sie die Netzwerkmesswerte prüfen, sehen Sie, dass Cloud Service Mesh beim Senden von Anfragen ein Backend mit der geringsten RTT-Latenz bevorzugt, um die Gesamt-RTT-Latenz zu optimieren.

In den folgenden Abschnitten werden Probleme beschrieben, die mit der Dienst-Load-Balancing-Richtlinie und den bevorzugten Backend-Einstellungen auftreten können.

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

Dies ist das beabsichtigte 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 Back-Ends“.

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

Dies ist das beabsichtigte Verhalten, wenn die MIGs oder NEGs aufgrund einer konfigurierten autoCapacityDrain geleert werden. Mit dieser Einstellung werden MIGs oder NEGs mit vielen fehlerhaften Endpunkten aus den Load Balancing-Entscheidungen entfernt und somit vermieden. Wenn Sie dieses Verhalten nicht wünschen, können Sie die Einstellung für autoCapacityDrain deaktivieren. Beachten Sie jedoch, dass Traffic an MIGs oder NEGs mit vielen fehlerhaften Endpunkten gesendet werden kann und Anfragen daher mit Fehlern enden können.

Traffic wird nicht an einige MIGs oder NEGs gesendet, obwohl 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 haben, wird Traffic nicht an andere MIGs oder NEGs gesendet. Die bevorzugten MIGs oder NEGs werden zuerst basierend auf der RTT-Latenz diesen Back-Ends zugewiesen.

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

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

Dies ist das beabsichtigte 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 die abfolgebasierte Auslieferung nach Region verwenden.

Traffic wird an einen Remote-Cluster gesendet, wenn sich der Status des Backends ä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 fehlerhaften Endpunkte möglicherweise auf die verbleibenden Endpunkte in derselben MIG oder NEG verteilt. Wenn das Failover-Verhalten frühzeitig ausgelöst werden soll, setzen Sie failoverHealthThreshold auf einen höheren Wert.

Einschränkungen und Überlegungen

Im Folgenden finden Sie Einschränkungen und Hinweise, die Sie beim Konfigurieren des erweiterten Load Balancings beachten sollten.

Waterfall-by-Zone

  • Bei transparenten Wartungsereignissen wird der Traffic möglicherweise vorübergehend außerhalb der lokalen Zone ausgeglichen.

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

  • Wenn sich die Quelle des Traffics zu Ihrem Dienst in derselben Zone wie seine Endpunkte befindet, wird weniger standortübergreifender Traffic angezeigt.

  • Eine Zone kann verschiedenen Clustern interner physischer Hardware in Google-Rechenzentren zugewiesen werden, 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, sind in der Regel mehr Clients betroffen. Mit anderen Worten: Eine größere Anzahl von Mesh-Clients ist möglicherweise betroffen, aber in geringerem Maße.

  • Da die Clients Anfragen an alle MIGs oder NEGs in der Region senden, kann dies in einigen Fällen zu einer Erhöhung des standortübergreifenden Traffics führen.

  • Die Anzahl der Verbindungen, die zu Endpunkten geöffnet werden, kann steigen und zu einer höheren Ressourcennutzung führen.

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 (Abfolge nach Region, Zufallsverteilung nach Region, Abfolge nach Zone) gelten nicht für MIGs oder NEGs, die als bevorzugte Back-Ends konfiguriert sind.

Automatischer Kapazitätsausgleich

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

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

  • Wenn serviceLbPolicies festgelegt ist, beträgt der Mindestprozentsatz der MIGs oder NEGs, die nie entladen werden, 50%. Bei beiden Konfigurationen wird eine MIG oder NEG als nicht gesund gekennzeichnet, wenn weniger als 25% der Instanzen oder Endpunkte in der MIG oder NEG gesund sind.

  • Damit eine MIG oder NEG nach einem Draining wieder entwässert werden kann, müssen mindestens 35% der Instanzen oder Endpunkte fehlerfrei sein. So wird sichergestellt, dass eine MIG oder NEG nicht zwischen dem Drain- und dem leeren Zustand wechselt.

  • Für Back-Ends ohne Balancing-Modus gelten dieselben Einschränkungen wie für den Kapazitätsskalierer.

Nächste Schritte