Sie können einen internen Passthrough-Network-Load-Balancer konfigurieren, damit Verbindungen zwischen VM-Instanzen in primären Back-Ends verteilt und bei Bedarf auf Failover-Back-Ends gewechselt wird. Failover bietet eine Methode zur Erhöhung der Verfügbarkeit und ermöglicht gleichzeitig eine bessere Kontrolle darüber, wie Ihre Arbeitslast verwaltet wird, wenn Ihre primären Backend-VMs nicht fehlerfrei sind.
Auf dieser Seite werden Konzepte und Anforderungen zum Failover für interne Passthrough-Network-Load-Balancer des Netzwerks erläutert. Bevor Sie das Failover für den internen Passthrough-Network-Load-Balancer konfigurieren, sollten Sie sich mit dem zugehörigen Konzept über die folgenden Artikeln vertraut machen:
Sie sollten diese Konzepte unbedingt verstehen, da durch das Konfigurieren des Failovers der Standardalgorithmus zur Trafficverteilung des Passthrough-Network-Load-Balancers geändert wird.
Wenn Sie ein Backend zu einem Backend-Dienst des internen Passthrough-Network-Load-Balancers hinzufügen, gilt dieses Backend standardmäßig als primäres Backend. Sie können ein Backend als Failover-Backend festlegen, wenn Sie es dem Backend-Dienst des Load-Balancers hinzufügen oder den Backend-Dienst später bearbeiten. Failover-Back-Ends empfangen nur dann Verbindungen vom Load-Balancer, wenn Systemdiagnosen bei einer konfigurierbaren Quote primärer VMs fehlschlagen.
Unterstützte Instanzgruppen
Verwaltete und nicht verwaltete Instanzgruppen werden als Back-Ends unterstützt. Der Einfachheit halber enthalten die Beispiele auf dieser Seite nicht verwaltete Instanzgruppen.
Wenn verwaltete Instanzgruppen mit Autoscaling und Failover verwendet werden, führt der aktive Pool möglicherweise wiederholt ein Failover und Failback zwischen dem primären und dem Failover-Back-End aus. Google Cloud ermöglicht die Konfiguration eines Failovers mit verwalteten Instanzgruppen, da dessen Einrichtung für Ihre Bereitstellung hilfreich sein kann.
Architektur
Das folgende einfache Beispiel zeigt einen internen Passthrough-Network-Load-Balancer mit einem primären Backend und einem Failover-Backend.
- Das primäre Backend ist eine nicht verwaltete Instanzgruppe in
us-west1-a. - Das Failover-Backend ist eine andere nicht verwaltete Instanzgruppe in
us-west1-c.
Das nächste Beispiel zeigt einen internen Passthrough-Network-Load-Balancer mit zwei primären Back-Ends und zwei Failover-Back-Ends, die beide auf zwei Zonen in der Region us-west1 verteilt werden. Diese Konfiguration erhöht die Zuverlässigkeit, da sie nicht von einer einzelnen Zone für alle primären oder alle Failover-Back-Ends abhängt.
- Primäre Back-Ends sind die nicht verwalteten Instanzgruppen
ig-aundig-d. - Failover-Back-Ends sind die nicht verwalteten Instanzgruppen
ig-bundig-c.
Beim Failover werden die beiden primären Back-Ends inaktiv und die fehlerfreien VMs in den beiden Failover-Back-Ends aktiv. Eine umfassende Beschreibung der Funktionsweise des Failovers in diesem Beispiel finden Sie im Abschnitt Failover-Beispiel.
Backend-Instanzgruppen und -VMs
Nicht verwaltete Instanzgruppen in internen Passthrough-Network-Load-Balancern sind entweder primäre Back-Ends oder Failover-Back-Ends. Sie können ein Backend als Failover-Backend festlegen, wenn Sie es dem Backend-Dienst hinzufügen oder wenn Sie ein hinzugefügtes Backend bearbeiten. Andernfalls sind nicht verwaltete Instanzgruppen standardmäßig primär.
Sie können mehrere primäre Backends und Failover-Backends in einem einzelnen internen Passthrough-Network-Load-Balancer konfigurieren. Dazu müssen Sie sie dem Backend-Dienst des Load Balancers hinzufügen.
Eine primäre VM ist Mitglied einer Instanzgruppe, die Sie als primäres Backend definiert haben. Die VMs in einem primären Back-End gehören zum aktiven Pool des Load-Balancers (siehe der nächste Abschnitt), solange der Load-Balancer nicht seine Failover-Back-Ends nutzt.
Eine Sicherungs-VM ist Mitglied einer Instanzgruppe, die Sie als Failover-Back-End definiert haben. Die VMs in einem Failover-Back-End sind Mitglied im aktiven Pool des Load-Balancers, wenn primäre VMs fehlerhaft werden. Sie können die Anzahl der fehlerhaften VMs, die Failover auslösen, als Prozentwert konfigurieren.
Limits
VMs. Bis zu 250 VMs sind im aktiven Pool möglich. Mit anderen Worten, Ihre primären Back-End-Instanzgruppen können insgesamt bis zu 250 primäre VMs und Ihre Failover-Back-End-Instanzgruppen insgesamt bis zu 250 Sicherungs-VMs haben.
Nicht verwaltete Instanzgruppen Bis zu 50 primäre Back-End-Instanzgruppen und bis zu 50 Failover-Back-End-Instanzgruppen sind möglich.
Beispielsweise kann eine maximale Bereitstellung fünf primäre Back-Ends und fünf Failover-Back-Ends haben, wobei jede Instanzgruppe 50 VMs enthält.
Aktiver Pool
Der aktive Pool ist eine Sammlung von Backend-VMs, an die ein interner Passthrough-Network-Load-Balancer neue Verbindungen sendet. Die Mitgliedschaft von Backend-VMs im aktiven Pool wird automatisch anhand der fehlerfreien Backends und der von Ihnen festgelegten Bedingungen (siehe Failover-Quote) berechnet.
Der aktive Pool kombiniert nie primäre VMs und Sicherungs-VMs. Mit den folgenden Beispielen werden die Möglichkeiten für eine Mitgliedschaft dargestellt. Während des Failovers enthält der aktive Pool nur Sicherungs-VMs. Während des normalen Betriebs (Failback) enthält der aktive Pool nur primäre VMs.
Failover und Failback
Failover und Failback sind die automatischen Prozesse, mit denen Back-End-VMs in den oder aus dem aktiven Pool des Load-Balancers gewechselt werden. Wenn Google Cloud primäre VMs aus dem aktiven Pool entfernt und dem aktiven Pool fehlerfreie Failover-VMs hinzufügt, wird dieser Vorgang als Failover bezeichnet. Wird dieser Vorgang von Google Cloud rückgängig macht, wird der Schritt als Failback bezeichnet.
Failover-Richtlinie
Eine Failover-Richtlinie ist eine Sammlung von Parametern, die Google Cloud für Failover und Failback verwendet. Jeder interne Passthrough-Network-Load-Balancer hat eine Failover-Richtlinie mit mehreren Einstellungen:
- Failover-Quote
- Traffic wird gelöscht, wenn alle Back-End-VMs fehlerhaft sind
- Verbindungsausgleich bei Failover und Failback
Failover-Quote
Eine konfigurierbare Failover-Quote legt fest, wann Google Cloud ein Failover oder Failback ausführt und sich dadurch die Mitgliedschaft im aktiven Pool ändert. Das Verhältnis kann 0.0 bis einschließlich 1.0 betragen.
Wenn Sie keine Failover-Quote angeben, verwendet Google Cloud den Standardwert 0.0. Es empfiehlt sich, die Failover-Quote auf eine Zahl zu setzen, die für Ihren Anwendungsfall geeignet ist, anstatt sich auf diese Standardeinstellung zu verlassen.
| Bedingungen | VMs im aktiven Pool |
|---|---|
|
Alle fehlerfreien primären VMs |
Wenn mindestens eine Sicherungs-VM fehlerfrei ist und:
|
Alle fehlerfreien Sicherungs-VMs |
| Wenn alle primären und alle Sicherungs-VMs fehlerhaft sind und wenn Sie Ihren Load-Balancer nicht so konfiguriert haben, dass der Traffic in dieser Situation unterbrochen wird | Alle primären VMs als letztes Mittel |
In den folgenden Beispielen wird die Mitgliedschaft im aktiven Pool verdeutlicht. Ein Beispiel mit Berechnungen finden Sie unter Failover-Beispiel.
- Bei einer Failover-Quote von
1.0müssen alle primären VMs fehlerfrei sein. Wenn mindestens eine primäre VM fehlerhaft wird, führt Google Cloud ein Failover aus und verschiebt die Sicherungs-VMs in den aktiven Pool. - Bei einer Failover-Quote von
0.1müssen mindestens 10 % der primären VMs fehlerfrei sein. Andernfalls führt Google Cloud ein Failover aus. - Eine Failover-Quote von
0.0bedeutet, dass Google Cloud nur dann ein Failover ausführt, wenn alle primären VMs fehlerhaft sind. Sie führt kein Failover durch, wenn mindestens eine primäre VM fehlerfrei ist.
Ein interner Passthrough-Network-Load-Balancer verteilt Verbindungen zwischen VMs im aktiven Pool gemäß dem Algorithmus zur Trafficverteilung.
Traffic wird gelöscht, wenn alle Backend-VMs fehlerhaft sind
Wenn alle primären und Backup-VMs fehlerhaft sind, verteilt Google Cloud neue Verbindungen standardmäßig nur auf die primären VMs. Dies wird als letztes Mittel verwendet. Die Backup-VMs sind von dieser „letztes-Mittel”-Verteilung der Verbindungen ausgeschlossen.
Wenn Sie möchten, können Sie Ihren internen Passthrough-Network-Load-Balancer so konfigurieren, dass neue Verbindungen unterbrochen werden, wenn alle primären und Sicherungs-VMs fehlerhaft sind.
Verbindungsausgleich bei Failover und Failback
Durch den Verbindungsausgleich können vorhandene TCP-Sitzungen bis zu einem konfigurierbaren Zeitraum aktiv bleiben, auch nachdem Back-End-VMs fehlerhaft werden. Wenn Ihr Load-Balancer das Protokoll TCP verwendet, gilt Folgendes:
Standardmäßig ist der Verbindungsausgleich aktiviert. Bereits vorhandene TCP-Sitzungen können auf einer Back-End-VM für bis zu 300 Sekunden (5 Minuten) bestehen bleiben, auch wenn die Back-End-VM fehlerhaft wird oder sich nicht im aktiven Pool des Load-Balancers befindet.
Sie können den Verbindungsausgleich während Failover- und Failback-Ereignissen deaktivieren. Das Deaktivieren des Verbindungsausgleichs während des Failovers und Failbacks sorgt dafür, dass alle TCP-Sitzungen, einschließlich der eingerichteten, schnell beendet werden. Verbindungen zu Back-End-VMs können mit einem TCP-Rücksetzpaket geschlossen werden.
Das Deaktivieren des Verbindungsausgleichs bei Failover und Failback ist in folgenden Fällen hilfreich:
Back-End-VMs patchen. Konfigurieren Sie vor dem Patchen Ihre primären VMs so, dass Systemdiagnosen fehlschlagen, damit der Load-Balancer ein Failover ausführt. Durch das Deaktivieren des Verbindungsausgleichs wird sichergestellt, dass alle Verbindungen schnell und in geplanter Weise auf die Sicherungs-VMs übertragen werden. Dadurch können Sie Updates installieren und die primären VMs neu starten, ohne dass bereits vorhandene Verbindungen bestehen bleiben. Nach dem Patchen kann Google Cloud ein Failback ausführen, wenn Systemdiagnosen für eine ausreichende Anzahl primärer VMs (definiert durch die Failover-Quote) erfolgreich sind.
Einzelne Back-End-VMs für Datenkonsistenz. Wenn nur eine primäre VM das Ziel für alle Verbindungen sein soll, deaktivieren Sie den Verbindungsausgleich. So wird verhindert, dass beim Wechsel von einer primären zu einer Sicherungs-VM vorhandene Verbindungen auf beiden VMs bestehen bleiben. Dadurch wird die Wahrscheinlichkeit von Dateninkonsistenzen verringert, da immer nur eine Back-End-VM aktiv ist.
Failover-Beispiel
Im folgenden Beispiel wird das Failover-Verhalten für das im Abschnitt Architektur dargestellte Beispiel eines internen Passthrough-Network-Load-Balancers mit mehreren Zonen beschrieben.
Die primären Back-Ends für diesen Load-Balancer sind die nicht verwalteten Instanzgruppen ig-a in us-west1-a und ig-d in us-west1-c. Jede Instanzgruppe enthält zwei VMs. Alle vier VMs aus beiden Instanzgruppen sind primäre VMs:
vm-a1inig-avm-a2inig-avm-d1inig-dvm-d2inig-d
Die Failover-Back-Ends für diesen Load-Balancer sind die nicht verwalteten Instanzgruppen ig-b in us-west1-a und ig-c in us-west1-c. Jede Instanzgruppe enthält zwei VMs. Alle vier VMs aus beiden Instanzgruppen sind Sicherungs-VMs:
vm-b1inig-bvm-b2inig-bvm-c1inig-cvm-c2inig-c
Angenommen, Sie möchten eine Failover-Richtlinie für diesen Load-Balancer so konfigurieren, dass neue Verbindungen an Sicherungs-VMs gesendet werden, wenn die Zahl der fehlerfreien primären VMs kleiner als zwei ist. Legen Sie dazu für die Failover-Quote den Wert 0.5 (50%) fest. Google Cloud ermittelt anhand der Failover-Quote die Mindestanzahl an primären VMs, die fehlerfrei sein müssen. Dazu wird die Failover-Quote mit der Anzahl der primären VMs multipliziert: 4 × 0.5 = 2.
Wenn alle vier primären VMs fehlerfrei sind, verteilt Google Cloud neue Verbindungen an alle VMs. Wenn für primäre VMs die Systemdiagnosen nicht erfolgreich sind:
Falls
vm-a1undvm-d1fehlerhaft werden, verteilt Google Cloud neue Verbindungen zwischen den beiden verbleibenden fehlerfreien primären VMs (vm-a2undvm-d2), da die Anzahl der fehlerfreien primären VMs den Mindestwert darstellt.Wenn für
vm-a2die Systemdiagnosen ebenfalls fehlschlagen und nur eine fehlerfreie primäre VM (vm-d2) übrig bleibt, erkennt Google Cloud, dass die Anzahl der fehlerfreien primären VMs unter dem Mindestwert liegt. Als Folge wird ein Failover ausgeführt. Der aktive Pool besteht aus den vier fehlerfreien Sicherungs-VMs, auf die neue Verbindungen in den Instanzgruppenig-bundig-cverteilt werden. Auch wenn die VMvm-d2fehlerfrei bleibt, wird sie aus dem aktiven Pool entfernt und erhält keine neuen Verbindungen.Wenn
vm-a2wiederhergestellt wird und die Systemdiagnose dazu erfolgreich ist, erkennt Google Cloud, dass der Mindestwert von zwei für die Anzahl der fehlerfreien primären VMs erreicht ist, sodass ein Failback ausgeführt wird. Für den aktiven Pool werden die beiden fehlerfreien primären VMsvm-a2undvm-d2festgelegt und neue Verbindungen werden zwischen ihnen verteilt. Alle Sicherungs-VMs werden aus dem aktiven Pool entfernt.Wenn andere primäre VMs wiederhergestellt werden und ihre Systemdiagnosen erfolgreich sind, fügt Google Cloud sie dem aktiven Pool hinzu. Beispiel: Wenn
vm-a1fehlerfrei wird, legt Google Cloud für den aktiven Pool die drei fehlerfreien primären VMsvm-a1,vm-a2undvm-d2fest und verteilt neue Verbindungen zwischen ihnen.
Nächste Schritte
- Mehr über das Konfigurieren und Testen eines internen Passthrough-Network-Load-Balancers, der Failover verwendet, unter Failover für den internen Passthrough-Network-Load-Balancer konfigurieren erfahren
- Informationen zum Konfigurieren und Testen eines internen Passthrough-Network-Load-Balancers finden Sie unter Internen Passthrough-Network-Load-Balancer einrichten.
- Failover-Probleme mit dem internen Passthrough-Netzwerk-Load-Balancer können Sie unter Fehlerbehebung bei internen Passthrough-Netzwerk-Load-Balancern beheben.