Erweitertes Load Balancing

Erweitertes Load-Balancing besteht aus Funktionen, mit denen Sie die globale Last genauer abstimmen können. und Traffic-Verteilung, um Verfügbarkeit, Leistung, und Kosteneffizienz-Ziele. Dieses Dokument richtet sich an Nutzer mit mit Cloud Service Mesh und Load-Balancing-Konzepten.

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. Dann hängen Sie die Load-Balancing-Richtlinie des Dienstes an ein Back-End an. . Die Load-Balancing-Richtlinie des Dienstes gibt den Algorithmus an, ermitteln, wie der Traffic auf die Back-Ends verteilt wird.

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

  • Abfolge nach Region (Standardalgorithmus).
  • In die Region spritzen.
  • 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 entscheidet, Traffic weiterzuleiten.

<ph type="x-smartling-placeholder">
</ph> 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 basierend auf der Anfrage einen Back-End-Dienst aus Eigenschaften und basierend auf Routingregeln in der Ressourcen- oder URL-Zuordnung Route, je nachdem, welche API in Ihrer Bereitstellung verwendet wird.

Zweitens wählt Cloud Service Mesh eine Back-End-MIG oder -NEG aus, die Back-End-Dienst, basierend auf Clientstandort, Standort, Zustand und Kapazität der MIG oder NEG und Informationen im Dienst-Load-Balancing Richtlinie, die dem Back-End-Dienst zugeordnet ist.

Schließlich wählt Cloud Service Mesh eine Instanz oder einen Endpunkt innerhalb der MIG oder NEG. 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 beschrieben, wie die einzelnen Algorithmen funktionieren und welchen Sie auswählen sollten. für Ihre speziellen Geschäftsanforderungen anzupassen.

Traffic zwischen Back-Ends in einer Region ausgleichen

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 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. Mit diesem Algorithmus wird jedoch die von einem einzelnen Client stammen, nicht einheitlich an alle Zonen gesendet werden. Anfragen von einem einzelnen Client werden in der Regel in einem einzigen .

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 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 verwendet, könnte ein Anstieg 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. 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 „Spray to World“-Algorithmus. Mit mithilfe dieses Algorithmus ihre Anfragen auf alle MIGs oder NEGs weltweit in mehreren Regionen.

Bei diesem Algorithmus wird der gesamte Traffic auf alle Back-Ends weltweit zu erstellen. Eine fehlerhafte Abfrage kann alle Back-Ends in Ihrem Bereitstellungen. 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, 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.

Vergleich der Load-Balancing-Algorithmen

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

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 im stabilen Zustand Nein Nein Ja Nein
Einheitliche Trafficaufteilung innerhalb einer Region im stabilen Zustand Nein Ja Ja Nein
Zonenübergreifender Traffic Ja. Dieser Algorithmus verteilt den Traffic gleichmäßig auf Zonen in einer und gleichzeitig die Netzwerklatenz optimieren. 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 Traffic-Spitzen in lokalen Zonen Durchschnitt: je nachdem, wie viel Traffic bereits zonenübergreifend. 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 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-Ends Dienst als bevorzugt gekennzeichnet ist. Diese Back-Ends werden vollständig genutzt, werden nachfolgende Anfragen an die verbleibenden Back-Ends weitergeleitet. Cloud-Service-Mesh verteilt den Client-Traffic zuerst an die bevorzugten Back-Ends und minimiert so die Anfrage Latenzen für Ihre Kunden.

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 zwischen den 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 haben, nach und nach über 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. Durch den Ausschluss des Backends werden Anfragen verhindert an das fehlerhafte Back-End gesendet werden. 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 ä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 globalen Lastenausgleich.

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 erläuterten 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 verfolgt auch die Back-Ends, die verwendet werden sollen, wenn die primären Back-Ends fehlerhaft sind und keinen Traffic empfangen können. Diese Back-Ends werden als failover-Back-Ends. Sie sind normalerweise Back-Ends in der Nähe, die über eine gewisse Kapazität verfügen verbleibend.

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 Schwellenwert, der legt fest, wann der Traffic von primären Back-Ends zum Failover verlagert wird Back-Ends.

Wenn einige Endpunkte im primären Back-End fehlerhaft sind, macht Cloud Service Mesh Traffic nicht unbedingt sofort verlagern. Stattdessen kann Cloud Service Mesh Traffic an fehlerfreie Endpunkte im primären Back-End verlagern, um sich zu stabilisieren, Zugriffe.

Wenn zu viele Endpunkte im Back-End fehlerhaft sind, werden die verbleibenden Endpunkte zusätzlichen Traffic nicht verarbeiten kann. In diesem Fall ist der Fehlerschwellenwert wird verwendet, um zu entscheiden, ob ein Failover ausgelöst wird oder nicht. 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 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 mit 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.

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. Dieser Abschnitt enthält allgemeine Vorschläge zur Fehlerbehebung.

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. Ich können Sie sich die Dokumentation für den Back-End-Dienst ansehen. .

Dann wird der Traffic basierend auf dem von Ihnen verwendeten Algorithmus zugewiesen. Beispiel: Mit mithilfe des Algorithmus von WATERFALL_BY_ZONE, versucht Cloud Service Mesh, den Traffic 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 an weiter entfernte MIGs oder NEGs gesendet, bevor sie näher aneinander liegen

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 Endpunkte gesendet

Dies ist das beabsichtigte Verhalten, wenn die MIGs oder NEGs per Drain beendet werden, weil ein autoCapacityDrain ist konfiguriert. Mit dieser Einstellung können MIGs oder NEGs mit vielen werden fehlerhafte Endpunkte aus den Load-Balancing-Entscheidungen entfernt und zu vermeiden. 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, 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 ihre Kapazität nicht erreicht ist wird der 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 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 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 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 gesetzt ist, ist dies die 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

Beachten Sie die folgenden Einschränkungen und Überlegungen. wenn Sie erweitertes Load-Balancing konfigurieren.

Wasserfall-nach-Zone

  • Während transparenter Wartungsereignisse ist es möglich, dass der Traffic 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 befindet wie der wird der zonenübergreifende Traffic reduziert.

  • 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-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 in erheblichem Maße.

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

  • 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 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 (Wasserfall nach Region, Spray-zu-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 ist.

  • Damit eine MIG oder NEG nach einem Draining wieder herunterfällt, müssen mindestens 35% der Instanzen oder Endpunkte müssen fehlerfrei sein. Dies ist erforderlich, damit eine verwaltete Instanzgruppe oder die NEG wechselt nicht zwischen Drain- und Undrained-Zuständen.

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

Nächste Schritte