Erweitertes Load Balancing

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.

Zur Implementierung des erweiterten Load-Balancings erstellen Sie eine Richtlinie für das Dienst-Load-Balancing. (serviceLbPolicies-Ressource), die Werte enthält, die die Auswahl beeinflussen eines Back-Ends. 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.

Sie können aus den folgenden Algorithmusoptionen für erweitertes Load Balancing wählen:

  • Abfolge nach Region (Standardalgorithmus).
  • Spray-to-Region-Algorithmus
  • Spray-to-World-Algorithmus
  • 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 sich die Dokumentation für die Ressource „Back-End-Dienst“ ansehen.

Weiterleitung von Traffic und Load-Balancing durch Cloud Service Mesh

Das folgende Diagramm zeigt, wie Cloud Service Mesh entscheidet, Traffic weiterzuleiten.

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 basierend auf der Anfrage einen Back-End-Dienst aus Eigenschaften und basierend auf Routingregeln in der Route-Ressourcen- oder URL-Zuordnung je nachdem, welche API in Ihrer 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 Backendtypen 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 (NEG vom Typ NON_GCP_PRIVATE_IP_PORT)

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

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

Anwendungsfälle

In den folgenden Abschnitten wird beschrieben, wie die einzelnen Algorithmen funktionieren und welche Auswahl sie treffen sollten. für Ihre speziellen Geschäftsanforderungen anzupassen.

Traffic zwischen Back-Ends in einer Region ausgleichen

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, dass Sie den Standardalgorithmus verwenden, es sei denn, Sie haben besondere Anforderungen.

Bei der abfolgebasierten Zuordnung nach Region erhalten Back-Ends Traffic proportional zu ihrer Kapazität. Das bietet Schutz vor Überlastungen. Traffic wird über wenn dies erforderlich ist, um die Back-Ends gleichmäßig im Region Auch wenn die Zone, die dem Client lokal zugeordnet ist, noch Kapazität hat, gibt es zonenübergreifenden Traffic. Die Anfragen der einzelnen Kunden können mehrere zonale MIGs oder NEGs in der Region, wodurch die Last auf Die MIGs oder NEGs werden einheitlich, 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 Algorithmus für die Vermittlungsabfolge nach Region versucht, die Kapazitätsnutzung auszugleichen für mehrere zonale MIGs oder NEGs. 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. Daraus ergeben sich Durchweg höherer zonenübergreifender Traffic, auch bei verbleibender Kapazität in der lokalen Zone, was zu einer größeren Beeinträchtigung des Verkehrsaufkommens führen kann vom Cloud Service Mesh, wenn zwei Cloud Service Mesh-Clients Daten senden in dieselben Zonen.

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. 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 mithilfe dieses Algorithmus ihre Anfragen an alle MIGs oder NEGs weltweit verteilen, in mehreren Regionen.

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

Zonenübergreifenden Traffic minimieren

Sie können die Gesamtlatenz optimieren und den zonenübergreifenden Traffic reduzieren, indem Sie die „Wasserfall“ nach Zoneneinstellung. 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. Gesamt die Latenz etwas verbessert, da die nächstgelegenen lokalen Back-Ends 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 Wasserfall nach Region In eine Region sprühen 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 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 Verkehr füllt die nächstgelegene Zone voll aus. Danach geht es zur nächsten Zone.
Empfindlichkeit gegenüber Traffic-Spitzen in lokalen Zonen Durchschnitt: hängt davon ab, wie viel Traffic bereits über Zonen verteilt wurde. Niedrigerer Wert da Spitzen in einer Zone auf alle Zonen im Region Niedrigerer Wert da Spitzen in einer Zone über alle Regionen verteilt werden. Höher; da Spitzen in einer einzelnen Zone eher vollständig bedient werden 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, werden nachfolgende Anfragen an die verbleibenden Back-Ends weitergeleitet. 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 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. Durch den Ausschluss des Backends werden Anfragen verhindert an das fehlerhafte Back-End gesendet werden. 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 ähnelt der Einstellung des capacityscalar auf null setzen. 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 entleert nicht mehr als 50% der Endpunkte in einem Back-End-Dienst, unabhängig davon, des Back-End-Systemstatus.

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 Back-Ends. Dabei werden mehrere Faktoren berücksichtigt. 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 Backends gelten als optimal in Bezug auf Latenz und Kapazitätsauslastung. Sie werden als primäre Back-Ends bezeichnet.

Cloud Service Mesh verfolgt auch die Back-Ends, die verwendet werden sollen, wenn die primären Back-Ends verwendet werden. 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 Ressource serviceLbPolicy enthält das Feld failoverHealthThreshold, dessen kann angepasst werden, 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.

Wenn zu viele Endpunkte im Back-End fehlerhaft sind, werden die verbleibenden Endpunkte zusätzlichen Traffic nicht verarbeiten kann. 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. 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. Einen höheren Wert startet das Traffic-Failover früher als ein kleinerer Wert.

Fehlerbehebung

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

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 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. Beachte bitte, 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, wird das Cloud Service Mesh angezeigt bevorzugt ein Back-End mit der niedrigsten RTT-Latenz beim Senden von Anfragen an die gesamte RTT-Latenz zu optimieren.

In den folgenden Abschnitten werden Probleme beschrieben, die bei der Dienstauslastung auftreten können. Balancing-Richtlinie und bevorzugte Back-End-Einstellungen.

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 in der bevorzugtes Backends-Feld.

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 dieses Verhalten nicht erwünscht ist, können Sie die autoCapacityDrain-Funktion deaktivieren. Einstellung. Dies bedeutet jedoch, dass Traffic an MIGs oder NEGs mit vielen Endpunkte fehlerhaft, sodass Anfragen möglicherweise aufgrund von Fehlern fehlschlagen.

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

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

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 einzigen 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. Ziehen Sie in diesem Fall die Verwendung anderer z. B. „Wasserfall nach Region“.

Traffic wird an einen Remote-Cluster gesendet, wenn sich der Systemzustand des Back-Ends ändert

Wenn failoverHealthThreshold auf einen hohen Wert festgelegt ist, ist dies die 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 auf die verbleibenden Endpunkte in derselben MIG oder NEG. 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.

Waterfall-by-Zone

  • Während transparenter Wartungsereignisse ist es möglich, dass der Traffic 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 zugeordnet sein in Google-Rechenzentren; 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-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, 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. Das kann passieren, selbst wenn es andere MIGs oder NEGs gibt, die für die Clients mit geringerer Latenz.

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