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.

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 Load-Balancing-Richtlinie des Dienstes gibt den Algorithmus an, ermitteln, wie der Traffic auf die Back-Ends verteilt wird.

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

  • Waterfall-by-Region-Algorithmus (Standardalgorithmus)
  • Spray-to-Region-Algorithmus
  • Spritzt in die Welt.
  • Waterfall-by-Zone-Algorithmus

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.

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 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 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 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, 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. 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 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 Spray-to-Region-Algorithmus, wenn die Kunden ihre an alle MIGs oder NEGs in einer Region, MIGs oder NEGs in einer einzelnen Zone überlastet, das Traffic-Volumen zu steigern.

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 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 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 über alle Back-Ends in mehreren Regionen verteilen

Wie in den vorherigen Abschnitten erläutert, verteilt sich der Spray-to-Region-Algorithmus Traffic von jedem Client zu allen 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.

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, was 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, 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 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 Abrechnungsabfolge nach Region In eine Region sprühen Spray-to-World-Algorithmus Abfolgebasierte Vermittlung 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. 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: hängt davon ab, wie viel Traffic bereits über Zonen verteilt wurde. 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 den Client-Traffic zuerst an die bevorzugten Back-Ends und minimiert so die Anfrage Latenzen für Ihre Kunden.

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 Backendkapazität automatisch auf null zu skalieren, wenn bei einem Backend weniger als 25 % der einzelnen Instanzen oder Endpunkte die Systemdiagnosen bestehen. Mit dieser Option werden fehlerhafte Back-Ends aus globalen Lastenausgleich.

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 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. 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-Back-Ends. 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 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.

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 Unregelmäßigkeiten bis zum Grenzwert, sodass ein Teil des Traffics den primären Back-Ends zu den Failover-Back-Ends.

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 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 Traffic-Verteilungsmuster können sich ändern, je nachdem, wie Sie die neue serviceLbPolicy mit dem Backend-Dienst einrichten.

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. 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. 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 mehr entfernten MIGs oder NEGs. 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 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, wenn 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 basierend auf der RTT-Latenz für diese Back-Ends zuerst 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 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 die abfolgebasierte Auslieferung nach Region verwenden.

Traffic wird an einen Remote-Cluster gesendet, wenn sich der Systemzustand des Back-Ends ä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 auf die verbleibenden Endpunkte in derselben MIG oder NEG. 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.

Wasserfall-nach-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 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, hat dies in der Regel folgende Konsequenzen: auf eine größere Kundengruppe verteilt; mit anderen Worten, eine größere Zahl der Mesh-Clients sind möglicherweise betroffen, aber weniger stark.

  • 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 für Endpunkte geöffneten Verbindungen kann zunehmen, erhöhter Ressourcennutzung.

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. Das kann passieren, selbst wenn es andere MIGs oder NEGs gibt, die für die Clients mit geringerer Latenz.

  • 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 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. Dies ist erforderlich, damit eine verwaltete Instanzgruppe oder die NEG wechselt nicht zwischen Drain- und Undrained-Zuständen.

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

Nächste Schritte