Sie können einen Backend-Dienst-basierten externen Passthrough-Network-Load-Balancer konfigurieren, um Verbindungen zwischen VM-Instanzen in primären Backends zu verteilen und dann bei Bedarf auf Failover-Backends wechseln. Failover stellt eine Methode zur Erhöhung der Verfügbarkeit bereit und bietet Ihnen 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 externe Passthrough-Network-Load-Balancer erläutert. Sie sollten mit den konzeptionellen Informationen in den folgenden Artikeln vertraut sein, bevor Sie den Failover für externe Passthrough-Network-Load-Balancer konfigurieren:
Sie sollten diese Konzepte unbedingt verstehen, da durch das Konfigurieren des Failovers der Standardalgorithmus zur Trafficverteilung des Load-Balancers geändert wird.
Wenn Sie ein Backend zu einem Backend-Dienst eines externen Passthrough-Network-Load-Balancers hinzufügen, ist dieses Backend standardmäßig ein 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 Back-Ends
Instanzgruppen (verwaltet und nicht verwaltet) und zonale NEGs (mit GCE_VM_IP-Endpunkten) 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 ein Failback zwischen dem primären und dem Failover-Back-End aus. Google Cloud hindert Sie nicht daran, ein Failover mit verwalteten Instanzgruppen zu konfigurieren, da Ihre Bereitstellung von dieser Einrichtung profitieren könnte.
Architektur
Das folgende Beispiel zeigt einen externen 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 externen 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 sind. 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
Die Instanzgruppen in externen 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 externen Passthrough-Network-Load-Balancer konfigurieren. Fügen Sie sie dazu dem Backend-Dienst des Load Balancers hinzu.
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. Die Anzahl fehlerhafter primärer VMs, die einen Failover auslösen, ist ein konfigurierbarer Prozentsatz.
Limits
- Instanzgruppen. Bis zu 50 primäre Back-End-Instanzgruppen und bis zu 50 Failover-Back-End-Instanzgruppen sind möglich.
Aktiver Pool
Der aktive Pool ist eine Sammlung von Backend-VMs, an die ein externer Passthrough-Network-Load-Balancer neue Verbindungen sendet. Die Mitgliedschaft von Backend-VMs im aktiven Pool wird automatisch berechnet, je nachdem, welche Backends fehlerfrei sind, und auf Basis von Bedingungen, die Sie festlegen können (siehe Failover-Richtlinie).
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 externe 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 externer 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 Sicherungs-VMs fehlerhaft sind, verteilt Google Cloud standardmäßig neue Verbindungen zwischen allen primären VMs. Dies geschieht nur als letztes Mittel.
Wenn Sie möchten, können Sie Ihren externen Passthrough-Network-Load-Balancer so konfigurieren, dass neue Verbindungen unterbrochen werden, wenn alle primären und Backup-VMs fehlerhaft sind.
Verbindungsausgleich bei Failover und Failback
Wenn der Verbindungsausgleich für die Failover-Richtlinie aktiviert ist, werden bestehende Verbindungen zu Instanzen in der primären oder Failover-Instanzgruppen weiterhin an die Instanzen gesendet, mit denen sie eingerichtet wurden, auch nach einem Failover oder Failback, wodurch ein Verbindungsabbruch verhindert wird. Wenn der Verbindungsausgleich für die Failover-Richtlinie deaktiviert ist, werden bestehende Verbindungen während eines Failovers oder Failbacks sofort beendet.
Wenn das Protokoll für Ihren Load-Balancer TCP ist, gilt Folgendes:
Standardmäßig ist der Verbindungsausgleich aktiviert. Vorhandene TCP-Sitzungen können auf ihren aktuellen Back-End-VMs bestehen bleiben, auch wenn sich die Back-End-VM 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 Sie dafür sorgen müssen, dass nur eine VM das Ziel für alle Verbindungen ist, deaktivieren Sie den Verbindungsausgleich. So bleiben beim Wechsel von einer primären zu einer Backup-VM bestehende Verbindungen nicht auf beiden bestehen. 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 externen 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
- Informationen zum Konfigurieren und Testen eines externen Passthrough-Network-Load-Balancers, der Failover verwendet, finden Sie unter Failover für externe Passthrough-Network-Load-Balancer konfigurieren.
- Informationen zum Konfigurieren und Testen eines externen Passthrough-Network-Load-Balancers mit einem Backend-Dienst finden Sie unter Externen Passthrough-Network-Load-Balancer einrichten.