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:

  • Abfolge nach Region (Standardalgorithmus).
  • Spray-to-Region-Algorithmus
  • Spritzt in die Welt.
  • Wasserfall nach Zone.

Die folgenden zusätzlichen Optionen sind verfügbar:

  • Bevorzugte Back-Ends festlegen Cloud Service Mesh sendet Traffic an diese MIGs oder NEGs erstellen, bevor sie Traffic an andere Back-Ends sendet.
  • Richten Sie den automatischen Kapazitätsausgleich ein.
  • Failover-Verhalten anpassen

Bevor Sie eine der erweiterten Load-Balancing-Optionen konfigurieren, sollten Sie sollten Sie die Dokumentation zur Back-End-Dienstressource lesen.

Weiterleitung von Traffic und Load-Balancing durch Cloud Service Mesh

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

Wie Cloud Service Mesh Load-Balancing-Entscheidungen trifft
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 die Bereitstellung verwendet wird.

Zweitens wählt Cloud Service Mesh eine Backend-MIG oder NEG aus, die mit dem Backend-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 Backend-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 Back-End-Typen werden für erweitertes 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 Back-End-Typen werden für erweitertes Load-Balancing nicht unterstützt:

  • Regional verwaltete Instanzgruppen
  • Internetnetzwerk-Endpunktgruppen (INTERNET_FQDN_PORT-NEGs)

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 verteilt nach Region gleichmäßig über alle MIGs oder NEGs in Zonen in einer Region verteilt. Wir empfehlen, dass Sie den Standardalgorithmus verwenden, es sei denn, Sie haben besondere Anforderungen.

Bei der Vermittlungsabfolge nach Region empfangen Back-Ends Traffic im Verhältnis zu ihrer und bietet Back-End-Überlastungsschutz. Traffic wird über wenn dies erforderlich ist, um die Back-Ends gleichmäßig im Region Auch wenn die Zone des Kunden vor Ort noch Kapazität hat, ist zonenübergreifender 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.

Erhöhen Sie die Ausfallsicherheit, indem Sie Traffic von einem Client auf mehrere Zonen verteilen

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 Spray-to-Region-Algorithmus die beiden Zonen A und B haben und es bei einer Zugriffsspitze in Zone B, wird der Traffic auf die beiden Zonen aufgeteilt. Mit Standardalgorithmus kann eine Spitze in Zone B eine Überlastung in der Zone auslösen, Cloud Service Mesh kann auf die Änderung reagieren.

Wenn Sie den Spray-zu-Region-Algorithmus verwenden, ist 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. Außerdem kann es zu einem größeren betroffenen Bereich für den Traffic von Cloud Service Mesh kommen, wenn zwei Cloud Service Mesh-Clients Traffic an dieselben Zonen senden.

Traffic von Ihrem Client über alle Back-Ends 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. Für Dienste mit MIGs oder NEGs in mehreren Regionen haben, optimiert Cloud Service Mesh trotzdem 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.

Wichtig: Bei diesem Algorithmus wird der gesamte Traffic weltweit 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, Clienttraffic wird an die nächstgelegene MIG oder NEG in der Zone weitergeleitet, bis zu ihrer Kapazität, bevor Traffic an die nächste MIG oder NEG in der Zone gesendet wird bis die gesamte MIG- oder NEG-Kapazität in der Zone aufgebraucht ist. Erst dann wird Traffic weitergeleitet. mit der nächstnächsten Zone erreichen.

Mit diesem Algorithmus können Sie unnötigen zonenübergreifenden Traffic minimieren. Gesamt die Latenz etwas verbessert, da die nächstgelegenen lokalen Back-Ends bevorzugt werden. Dies kann jedoch auch zu ungleichmäßigen Traffic zwischen den NEGs innerhalb einer Region.

Load-Balancing-Algorithmen vergleichen

Die folgende Tabelle enthält einen detaillierten Vergleich der vier Cloud Service Mesh-Netzwerke Load-Balancing-Algorithmen.

Verhalten Abrechnungsabfolge nach Region Spray-to-Region-Algorithmus Sprüh zur Welt Wasserfall nach Zone
Einheitliche Kapazitätsnutzung innerhalb einer Region im stabilen Zustand Ja Ja Ja Nein
Einheitliche Kapazitätsnutzung über mehrere Regionen 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. Zugriffe können über Zonen bei Bedarf hinzufügen. Ja Ja Ja, der Verkehr füllt die nächstgelegene Zone voll aus. Dann geht in die nächste Zone.
Empfindlichkeit gegenüber Trafficspitzen in lokalen Zonen Durchschnitt: je nachdem, wie viel Traffic bereits zonenübergreifend. Weniger: Spitzen einzelner Zonen sind auf alle Zonen in der Region verteilt. Niedrigerer Wert da Spitzen in einer Zone über alle Regionen verteilt werden. 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 der Cloud Service Mesh-Last erläutert für ein ausgewogenes Verhältnis.

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.

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

Ein Anwendungsfall ist ein Überlauf zu Google Cloud, wo Sie lokale Computing-Ressourcen Ressourcen, dargestellt durch eine Hybridkonnektivitäts-NEG, die vor dem Anfragen werden an automatisch skalierte Google Cloud-Back-End-MIGs oder -NEGs weitergeleitet. Dieses kann der Compute-Verbrauch von Google Cloud minimieren die die nötige Ausfallsicherheit bieten können, Google Cloud, wenn nötig.

Automatischer Kapazitätsausgleich

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

Diese Option entspricht dem Festlegen von capacityscalar auf null. Er fordert Cloud Service Mesh auf, die Back-End-Kapazität automatisch auf null zu reduzieren. Ein Back-End hat weniger als 25% seiner einzelnen Instanzen oder Endpunkte Systemdiagnosen bestanden. Mit dieser Option werden fehlerhafte Back-Ends aus dem globalen Load Balancing entfernt.

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

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

Failover-Verhalten anpassen

Cloud Service Mesh sendet in der Regel Traffic an Backends, wobei mehrere Faktoren berücksichtigt werden. In einem stabilen Zustand sendet Cloud Service Mesh Traffic an Back-Ends die anhand der zuvor besprochenen Algorithmen ausgewählt werden. Die ausgewählten Back-Ends werden hinsichtlich Latenz und Kapazitätsauslastung als optimal angesehen. 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-Back-Ends. In der Regel sind es Back-Ends in der Nähe, die noch Kapazitäten haben.

Wenn ein Back-End fehlerhaft ist, versucht Cloud Service Mesh, das Senden von Traffic an und leitet den Traffic stattdessen an fehlerfreie Back-Ends 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 Schwellenwert für den Failover-Zustand ist ein Prozentwert. Der von Ihnen festgelegte Wert legt fest, wann Cloud Service Mesh Traffic an die Failover-Back-Ends weiterleitet. Ich können Sie den Wert auf eine Ganzzahl zwischen 1 und 99 festlegen. Der Standardwert für Cloud Service Mesh ist 70 für Envoy und 50 für proxylose gRPC-Dienste. Je höher der Wert, desto früher wird das Traffic-Failover gestartet.

Fehlerbehebung

Die Muster für die Trafficverteilung können sich ändern, je nachdem, wie Sie das neue serviceLbPolicy durch den Back-End-Dienst.

Verwenden Sie zur Behebung von Traffic-Problemen die vorhandenen Überwachungssysteme, um zu untersuchen, wie an Ihre Back-Ends fließt. Zusätzliche Cloud Service Mesh- und Netzwerkmesswerte damit Sie 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 zuzuweisen, damit Back-Ends weiter ausgeführt werden unter der konfigurierten Kapazität liegt. Beachten Sie, dass dies nicht garantiert werden kann. Weitere Informationen finden Sie in der Dokumentation zum Back-End-Dienst.

Dann wird der Traffic basierend auf dem von Ihnen verwendeten Algorithmus zugewiesen. Beispiel: Mit dem Algorithmus von WATERFALL_BY_ZONE, versucht Cloud Service Mesh, den Traffic aufrechtzuerhalten, zur nächstgelegenen Zone. 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 mehr entfernten MIGs oder NEGs. 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 per Drain beendet werden, weil ein autoCapacityDrain ist konfiguriert. Mit dieser Einstellung werden MIGs oder NEGs mit vielen fehlerhaften Endpunkten aus den Load Balancing-Entscheidungen entfernt und somit vermieden. Wenn dieses Verhalten nicht erwünscht ist, können Sie die autoCapacityDrain-Funktion deaktivieren. Einstellung. 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, 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 ihre Kapazität nicht erreicht ist wird der 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 der Traffic an eine andere Stelle gesendet werden soll, können Sie Back-End-Dienst ohne bevorzugte Back-Ends oder mit konservativerer Kapazität Schätzungen für die bevorzugten MIGs oder NEGs.

Traffic wird von einer einzelnen Quelle 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 mit einer breiteren Verteilung Ihrer Zugriffe. Beispielsweise können die Cache-Trefferraten sinken, wenn Back-Ends Traffic empfangen. einer breiteren Palette von Kunden. 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 in den primären Back-Ends verbleiben soll, Vorübergehende Integritätsänderungen, legen Sie einen niedrigeren Wert für failoverHealthThreshold fest.

Fehlerfreie Endpunkte werden überlastet, wenn einige Endpunkte fehlerhaft sind

Wenn failoverHealthThreshold auf einen niedrigen Wert festgelegt ist, ist dies die 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 Sie Wenn das Failover-Verhalten vorzeitig ausgelöst werden soll, legen Sie failoverHealthThreshold fest. 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.

Wasserfall-nach-Zone

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

  • Es ist zu erwarten, dass einige MIGs oder NEGs ausgelastet sind, während andere NEGs in derselben Region werden nicht ausgelastet.

  • 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 geladen. Im Allgemeinen dass die Gesamtlatenz optimiert wird.

Spray-zu-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, was zu einer höheren Ressourcennutzung führt.

Bevorzugte Back-Ends

  • Die als bevorzugte Back-Ends konfigurierten MIGs oder NEGs sind möglicherweise weit entfernt vom und eine höhere durchschnittliche Latenz für Clients verursachen kann. 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 (Wasserfall nach Region, Spray-to-Region, abfolgebasierte Daten) gelten nicht für MIGs oder NEGs, die als bevorzugt konfiguriert sind. Back-Ends.

Automatischer Kapazitätsausgleich

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

  • Standardmäßig ist die Mindestanzahl von MIGs, die nie per Drain beendet werden, 1.

  • Wenn serviceLbPolicies festgelegt ist, ist der Mindestprozentsatz der MIGs oder NEGs, die niemals 50 % entladen sind. In beiden Konfigurationen ist eine MIG oder NEG als Fehler, wenn weniger als 25% der Instanzen oder Endpunkte in der MIG oder NEG sind 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.

  • Dieselben Einschränkungen für den Kapazitätsskalierer für Back-Ends, die keinen findet auch hier Anwendung.

Nächste Schritte