Erweitertes Load-Balancing

Erweitertes Load-Balancing umfasst Features, 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 bereits grundlegende Kenntnisse über Cloud Service Mesh und Load-Balancing-Konzepte haben.

Zur Implementierung des erweiterten Load-Balancings erstellen Sie eine Dienst-Load-Balancing-Richtlinie (serviceLbPolicies-Ressource). Diese enthält Werte, die die Auswahl eines Back-Ends beeinflussen. Anschließend hängen Sie die Load-Balancing-Richtlinie für den Dienst an einen Back-End-Dienst an. Die Dienst-Load-Balancing-Richtlinie gibt den Algorithmus an, mit dem bestimmt wird, wie der Traffic auf die Back-Ends verteilt wird.

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

  • Wasserfall nach Region (Standardalgorithmus).
  • Sprühen auf die Stelle.
  • Auf die Welt sprühen.
  • Wasserfall nach Zone.

Die folgenden zusätzlichen Optionen sind verfügbar:

  • Legen Sie bevorzugte Back-Ends fest. Cloud Service Mesh sendet Traffic an diese MIGs oder NEGs, bevor er Traffic an andere Back-Ends sendet.
  • Richten Sie den automatischen Kapazitätsausgleich ein.
  • Passen Sie das Failover-Verhalten an.

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

Weiterleitung und Load-Balancing von Traffic durch Cloud Service Mesh

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

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

Zuerst wählt Cloud Service Mesh einen Back-End-Dienst anhand der Anfrageeigenschaften und der Routingregeln in der Route-Ressource oder der URL-Zuordnung aus, je nachdem, welche API Ihre Bereitstellung verwendet.

Zweitens wählt Cloud Service Mesh eine Back-End-MIG oder -NEG aus, die dem Back-End-Dienst zugeordnet ist, basierend auf dem Clientstandort, dem Standort, dem Zustand und der Kapazität der verwalteten Instanzgruppe oder der NEG sowie Informationen in der mit dem Back-End-Dienst verknüpften Dienst-Load-Balancing-Richtlinie.

Zuletzt wählt Cloud Service Mesh 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 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 Back-End-Typen werden für das erweiterte Load-Balancing nicht unterstützt:

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

Anwendungsfälle

In den folgenden Abschnitten wird beschrieben, wie die einzelnen Algorithmen funktionieren und welchen Sie für Ihre speziellen Geschäftsanforderungen auswählen sollten.

Traffic auf Back-Ends in einer Region ausgleichen

Der Standard-Load-Balancing-Algorithmus, nach Region als Wasserfall, verteilt den Traffic gleichmäßig auf alle MIGs oder NEGs in Zonen in einer Region. Wir empfehlen, den Standardalgorithmus zu verwenden, sofern keine besonderen Anforderungen gelten.

Bei der Vermittlungsabfolge nach Region empfangen Back-Ends Traffic proportional zu ihrer Kapazität, was einen Back-End-Überlastungsschutz bietet. Der Traffic wird bei Bedarf über Zonengrenzen hinweg gesendet, damit die Back-Ends innerhalb der Region gleichmäßig geladen werden. Selbst wenn die lokale Zone des Clients 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. Dadurch bleibt die Last der MIGs oder NEGs einheitlich, wenn die Trafficlast von den Clients nicht einheitlich ist.

Höhere Ausfallsicherheit durch Verteilung des Traffics von einem Client auf mehrere Zonen

Der Standardalgorithmus „Wasserfall nach Region“ versucht, die Kapazitätsnutzung auf mehrere zonale MIGs oder NEGs auszugleichen. Mit diesem Algorithmus werden Anfragen von einem einzelnen Client jedoch nicht konsistent 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 Sie möchten, dass Clients ihre Anfragen auf alle MIGs oder NEGs in einer Region verteilen. Dadurch wird das Risiko einer Überlastung von MIGs oder NEGs in einer einzelnen Zone reduziert, wenn das Trafficvolumen schnell lokalisiert wird.

Wenn Sie mit dem Spray-to-Region-Algorithmus zwei Zonen A und B haben und in Zone B eine Trafficspitze auftritt, wird der Traffic auf die beiden Zonen aufgeteilt. Mit dem Standardalgorithmus könnte ein Anstieg in Zone B eine Überlastung in der Zone auslösen, bevor Cloud Service Mesh auf die Änderung reagieren kann.

Wenn Sie den Spray-to-Region-Algorithmus 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, selbst wenn in der lokalen Zone noch Kapazität vorhanden ist, und kann zu einem größeren betroffenen Bereich für den Traffic aus Cloud Service Mesh führen, wenn zwei Cloud Service Mesh-Clients Traffic an dieselben Zonen senden.

Traffic von Ihrem Client auf alle Back-Ends in mehreren Regionen verteilen

Wie in den vorherigen Abschnitten erläutert, verteilt der Spray-to-Region-Algorithmus 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 Spray to World-Algorithmus. Mit diesem Algorithmus verteilen Clients ihre Anfragen auf alle MIGs oder NEGs weltweit in mehreren Regionen.

Beachten Sie, dass bei diesem Algorithmus der gesamte Traffic auf alle Back-Ends global verteilt wird. Eine fehlerhafte Abfrage kann alle Back-Ends 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 Zonen“ können Sie die Gesamtlatenz optimieren und den zonenübergreifenden Traffic reduzieren. Wenn in einer Zone mehrere MIGs oder NEGs konfiguriert sind, wird Clienttraffic bis zu ihrer Kapazität an die nächstgelegene MIG oder NEG in der Zone weitergeleitet. Erst dann wird Traffic an die nächste MIG oder NEG in der Zone gesendet, bis die gesamte MIG- oder NEG-Kapazität in der Zone aufgebraucht 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 geringfügig verbessert werden, da die nächstgelegenen lokalen Back-Ends bevorzugt werden. Dies kann jedoch auch zu einem ungleichmäßigen Traffic zwischen den verwalteten Instanzgruppen oder NEGs innerhalb einer Region führen.

Vergleich der Load-Balancing-Algorithmen

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

Verhalten Wasserfall nach Region In einen bestimmten Bereich sprühen Beten auf die Welt Wasserfall nach Zone
Einheitliche Kapazitätsnutzung innerhalb einer Region in stabilem Zustand Yes Yes Yes Nein
Einheitliche Kapazitätsnutzung über mehrere Regionen hinweg bei gleichbleibendem Status Nein Nein Yes Nein
Einheitliche Traffic-Aufteilung innerhalb einer Region im stabilen Zustand Nein Yes Yes Nein
Zonenübergreifender Traffic Ja. Dieser Algorithmus verteilt den Traffic gleichmäßig auf Zonen in einer Region und optimiert gleichzeitig die Netzwerklatenz. Bei Bedarf kann Traffic zonenübergreifend gesendet werden. Yes Yes Ja, der Traffic füllt die Zone, die seiner Kapazität am nächsten kommt. Dann geht es in die nächste Zone.
Sensibilität bei Trafficspitzen in der lokalen Zone Durchschnitt; abhängig davon, wie viel Traffic bereits zum Ausgleich zwischen Zonen verschoben wurde. Niedriger: Spitzenwerte in einer einzelnen Zone werden auf alle Zonen in der Region verteilt. Niedriger; da Spitzen in einer einzelnen Zone über alle Regionen verteilt werden. Höher; da Spitzen in einer einzelnen Zone mit höherer Wahrscheinlichkeit vollständig von einer einzelnen Zone bereitgestellt 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 erläutert.

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 verwendet, bevor nachfolgende Anfragen an die verbleibenden Back-Ends weitergeleitet werden. Cloud Service Mesh verteilt den Clienttraffic zuerst auf die bevorzugten Back-Ends und minimiert so die Anfragelatenzen für Ihre Clients.

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 lokale Rechenressourcen angeben, die durch eine Hybridkonnektivitäts-NEG dargestellt werden, die vollständig verwendet werden sollen, bevor Anfragen an automatisch skalierte Google Cloud-Back-End-MIGs oder -NEGs weitergeleitet werden. Diese Konfiguration kann den Google Cloud-Computing-Verbrauch minimieren und dennoch die Ausfallsicherheit haben, um bei Bedarf schrittweise auf Google Cloud zu übertragen oder ein Failover durchzuführen.

Automatischer Kapazitätsausgleich

Wenn ein Back-End fehlerhaft ist, empfiehlt es sich in der Regel, es so schnell wie möglich von Load-Balancing-Entscheidungen auszuschließen. Durch den Ausschluss des Back-Ends werden Anfragen nicht an das fehlerhafte Back-End gesendet. Außerdem wird der Traffic zwischen fehlerfreien Back-Ends ausgeglichen, um eine Überlastung des Back-Ends zu vermeiden 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 bei einem Back-End weniger als 25% seiner einzelnen Instanzen oder Endpunkte Systemdiagnosen bestehen. Mit dieser Option werden fehlerhafte Back-Ends aus dem globalen Load-Balancing entfernt.

Wenn die automatisch per Drain beendeten Back-Ends wieder fehlerfrei sind und mindestens 35% der Endpunkte oder Instanzen 60 Sekunden lang fehlerfrei sind, wird dies nicht ausgeführt. Cloud Service Mesh führt unabhängig vom Back-End-Systemstatus nicht mehr als 50% der Endpunkte in einem Back-End-Dienst aus.

Ein Anwendungsfall ist der automatische Kapazitätsausgleich mit bevorzugten Back-Ends. Wenn eine Back-End-MIG oder -NEG bevorzugt wird und viele der darin enthaltenen Endpunkte fehlerhaft sind, schützt diese Einstellung die verbleibenden Endpunkte in der MIG oder NEG, indem Traffic von der MIG oder NEG weggeleitet wird.

Failover-Verhalten anpassen

Cloud Service Mesh sendet in der Regel Traffic an Back-Ends. Dabei werden mehrere Faktoren berücksichtigt. In einem stabilen Zustand sendet Cloud Service Mesh Traffic an Back-Ends, die anhand der zuvor beschriebenen Algorithmen ausgewählt werden. Die ausgewählten Back-Ends gelten in Bezug auf Latenz und Kapazitätsauslastung als optimal. Sie werden als primäre Back-Ends bezeichnet.

Cloud Service Mesh verfolgt auch die zu verwendenden Back-Ends, wenn die primären Back-Ends fehlerhaft sind und keinen Traffic empfangen können. Diese Back-Ends werden als Failover-Back-Ends bezeichnet. Sie sind normalerweise nahe gelegene Back-Ends, auf denen noch Kapazität übrig ist.

Wenn ein Back-End fehlerhaft ist, versucht Cloud Service Mesh, keinen Traffic mehr an das Back-End zu senden, und verlagert den Traffic stattdessen an fehlerfreie Back-Ends.

Die Ressource serviceLbPolicy enthält das Feld failoverHealthThreshold, dessen Wert zur Steuerung des Failover-Verhaltens angepasst werden kann. Der festgelegte Grenzwert bestimmt, wann der Traffic von primären Back-Ends zu Failover-Back-Ends verschoben wird.

Wenn einige Endpunkte im primären Back-End fehlerhaft sind, verschiebt Cloud Service Mesh den Traffic nicht unbedingt sofort. Stattdessen kann Cloud Service Mesh den Traffic zu fehlerfreien Endpunkten im primären Back-End verschieben, um den Traffic zu stabilisieren.

Wenn zu viele Endpunkte im Back-End fehlerhaft sind, können die verbleibenden Endpunkte keinen zusätzlichen Traffic verarbeiten. In diesem Fall wird anhand des Fehlergrenzwerts entschieden, ob ein Failover ausgelöst wird oder nicht. Cloud Service Mesh toleriert Störungen bis zum Schwellenwert und verlagert dann einen Teil des Traffics von den primären Back-Ends auf die Failover-Back-Ends.

Der Schwellenwert für den Failover-Zustand ist ein Prozentsatz. 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 für Envoy und 50 für proxylose gRPC-Dienste. Bei einem höheren Wert wird das Traffic-Failover früher gestartet als bei einem niedrigeren Wert.

Fehlerbehebung

Die Trafficverteilungsmuster können sich ändern, je nachdem, wie Sie den neuen serviceLbPolicy mit dem Back-End-Dienst eingerichtet haben.

Verwenden Sie zum Beheben von Trafficproblemen die vorhandenen Monitoringsysteme, um zu prüfen, wie der 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 Abhilfe.

Insgesamt versucht Cloud Service Mesh, Traffic zuzuweisen, damit Back-Ends unter der konfigurierten Kapazität ausgeführt werden können. Das ist jedoch nicht garantiert. Weitere Informationen finden Sie in der Dokumentation zum Back-End-Dienst.

Der Traffic wird dann anhand des von Ihnen verwendeten Algorithmus zugewiesen. Mit dem Algorithmus WATERFALL_BY_ZONE versucht Cloud Service Mesh beispielsweise, den Traffic zur nächsten Zone zu leiten. Wenn Sie die Netzwerkmesswerte überprüfen, stellen Sie fest, dass Cloud Service Mesh beim Senden von Anfragen ein Back-End mit der geringsten RTT-Latenz bevorzugt, um die RTT-Gesamtlatenz zu optimieren.

In den folgenden Abschnitten werden Probleme beschrieben, die mit der Richtlinie für das Dienst-Load-Balancing und den bevorzugten Back-End-Einstellungen auftreten können.

Der Traffic wird vor weiter entfernten MIGs oder NEGs gesendet

Dies ist das gewünschte Verhalten, wenn bevorzugte Back-Ends mit weiter entfernten MIGs oder NEGs konfiguriert sind. Wenn Sie dieses Verhalten 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, da ein 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 erwünscht ist, können Sie die Einstellung autoCapacityDrain deaktivieren. Beachten Sie jedoch, dass Traffic an MIGs oder NEGs mit vielen fehlerhaften Endpunkten gesendet werden kann und daher Fehler bei den Anfragen auftreten können.

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

Dies ist das gewünschte Verhalten, wenn als bevorzugt konfigurierte MIGs oder NEGs die Kapazität noch nicht erreicht haben.

Wenn bevorzugte Back-Ends konfiguriert sind und ihr Kapazitätslimit nicht erreicht haben, wird Traffic nicht an andere MIGs oder NEGs gesendet. Die bevorzugten MIGs oder NEGs werden basierend auf der RTT-Latenz zu diesen Back-Ends zuerst zugewiesen.

Wenn der Traffic lieber an eine andere Stelle gesendet werden soll, können Sie den Back-End-Dienst entweder ohne bevorzugte Back-Ends oder mit konservativen 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 gewünschte Verhalten, wenn das Spray-to-Region oder das Spray-to-World verwendet wird. Es können jedoch Probleme mit einer breiteren Verteilung Ihres Traffics auftreten. Beispielsweise können die Cache-Trefferraten sinken, wenn Back-Ends Traffic von einer größeren Auswahl von Clients empfangen. Ziehen Sie in diesem Fall die Verwendung anderer Algorithmen in Betracht, z. B. der Wasserfall-Methode nach Region.

Traffic wird an einen Remote-Cluster gesendet, wenn sich der Back-End-Zustand ändert

Wenn failoverHealthThreshold auf einen hohen Wert festgelegt ist, ist dies das beabsichtigte Verhalten. Wenn der Traffic bei vorübergehenden Systemänderungen auf den primären Back-Ends verbleiben soll, setzen Sie failoverHealthThreshold auf einen niedrigeren Wert.

Fehlerfreie Endpunkte sind überlastet, wenn einige Endpunkte fehlerhaft sind

Wenn failoverHealthThreshold auf einen niedrigen Wert festgelegt 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 Überlegungen, die Sie beim Konfigurieren des erweiterten Load-Balancings beachten sollten.

Wasserfall-nach-Zone

  • Bei transparenten Wartungsereignissen ist es möglich, dass der Traffic vorübergehend außerhalb der lokalen Zone ausgeglichen wird.

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

  • Wenn sich die Quelle des Traffics zu Ihrem Dienst in derselben Zone wie seine Endpunkte befindet, sehen Sie weniger zonenübergreifenden Traffic.

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

Sprühbereich

  • Wenn die Endpunkte in einer MIG oder NEG ausfallen, wirken sich die Folgen in der Regel auf eine größere Gruppe von Clients aus. Es kann also sein, dass eine größere Anzahl von Mesh-Clients betroffen ist, aber weniger stark.

  • Wenn die Clients Anfragen an alle MIGs oder NEGs in der Region senden, kann sich dadurch der zonenübergreifende Traffic erhöhen.

  • Die Anzahl der offenen Verbindungen zu Endpunkten kann ansteigen, was zu einer erhöhten Ressourcennutzung führt.

Bevorzugte Back-Ends

  • Die als bevorzugte Back-Ends konfigurierten MIGs oder NEGs sind möglicherweise weit von den Clients entfernt und können eine höhere durchschnittliche Latenz für Clients verursachen. Dies kann auch dann passieren, wenn andere MIGs oder NEGs vorhanden sind, die die Clients mit geringerer Latenz bedienen könnten.

  • Globale Load-Balancing-Algorithmen (Wasserfall nach Region, Spray-to-Region, Wasserfall 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 dem Wert, der bei der Konfiguration mit serviceLbPolicies festgelegt wurde.

  • Standardmäßig beträgt die Mindestanzahl von MIGs, die nie per Drain beendet wird, 1.

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

  • Damit eine verwaltete Instanzgruppe oder NEG nach einem Drain beendet wird, müssen mindestens 35% der Instanzen oder Endpunkte fehlerfrei sein. Dies ist erforderlich, um sicherzustellen, dass eine MIG oder NEG nicht zwischen dem Status „Drain“ und „Nicht abgeschützt“ wechselt.

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

Nächste Schritte