Failover für Netzwerk-Load-Balancing – Übersicht

Sie können einen Back-End-Dienst-basierten Netzwerk-Load-Balancer konfigurieren, um Verbindungen zwischen VM-Instanzen in primären Back-Ends zu verteilen und dann bei Bedarf auf Failover-Back-Ends 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 Back-End-VMs nicht fehlerfrei sind.

Auf dieser Seite werden Konzepte und Anforderungen beschrieben, die sich speziell auf den Failover für Netzwerk-Load-Balancer beziehen. Sie sollten mit den konzeptionellen Informationen in den folgenden Artikeln vertraut sein, bevor Sie den Failover für das Netzwerk-Load-Balancing konfigurieren:

Sie sollten diese Konzepte unbedingt verstehen, da durch das Konfigurieren des Failovers der Standardalgorithmus zur Trafficverteilung des Netzwerk-Load-Balancers geändert wird.

Wenn Sie ein Back-End zu einem Back-End-Dienst eines Netzwerk-Load-Balancers hinzufügen, ist dieses Back-End standardmäßig ein primäres Back-End. Sie können ein Back-End als Failover-Back-End festlegen, wenn Sie es dem Back-End-Dienst des Load-Balancers hinzufügen oder den Back-End-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 Netzwerk-Load-Balancer mit einem primären Back-End und einem Failover-Back-End.

  • Das primäre Back-End ist eine nicht verwaltete Instanzgruppe in us-west1-a.
  • Das Failover-Back-End ist eine andere nicht verwaltete Instanzgruppe in us-west1-c.
Einfaches Failover-Beispiel für Netzwerk-Load-Balancing (zum Vergrößern klicken)
Einfaches Failover-Beispiel für Netzwerk-Load-Balancing (zum Vergrößern klicken)

Das nächste Beispiel zeigt einen Netzwerk-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-a und ig-d.
  • Failover-Back-Ends sind die nicht verwalteten Instanzgruppen ig-b und ig-c.
Netzwerk-Load-Balancing mit mehreren Zonen (zum Vergrößern klicken)
Failover für Mehrzonen-Netzwerk-Load-Balancing (zum Vergrößern klicken)

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.

Back-End-Instanzgruppen und -VMs

Die Instanzgruppen im Netzwerk-Load-Balancing sind entweder primäre Back-Ends oder Failover-Back-Ends. Sie können ein Back-End als Failover-Back-End festlegen, wenn Sie es dem Back-End-Dienst hinzufügen oder wenn Sie ein hinzugefügtes Back-End bearbeiten. Andernfalls sind nicht verwaltete Instanzgruppen standardmäßig primär.

Sie können mehrere primäre Back-Ends und Failover-Back-Ends in einem einzelnen Netzwerk-Load-Balancer konfigurieren. Fügen Sie sie dazu dem Back-End-Dienst des Load-Balancers hinzu.

Eine primäre VM ist Mitglied einer Instanzgruppe, die Sie als primäres Back-End 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

  • Nicht verwaltete 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 Back-End-VMs, an die ein Netzwerk-Load-Balancer neue Verbindungen sendet. Die Mitgliedschaft von Back-End-VMs im aktiven Pool wird automatisch berechnet, je nachdem, welche Back-Ends 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.

Aktiver Pool bei Failover und Failback (zum Vergrößern anklicken)
Aktiver Pool bei Failover und Failback (zum Vergrößern anklicken)

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 Netzwerk-Load-Balancer hat eine Failover-Richtlinie mit mehreren Einstellungen:

  • Failover-Quote
  • Traffic wird unterbrochen, 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
  1. Failover-Quote (x) != 0.0.
    Quote fehlerfreier primärer VMs >= x.
  2. Failover-Quote (x) = 0.0.
    Anzahl fehlerfreier primärer VMs > 0.
Alle fehlerfreien primären VMs
Wenn mindestens eine Sicherungs-VM fehlerfrei ist und:
  1. Failover-Quote (x) != 0.0.
    Quote fehlerfreier primärer VMs < x.
  2. Failover-Quote = 0.0.
    Anzahl fehlerfreier primärer VMs = 0.
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.0 mü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.1 müssen mindestens 10 % der primären VMs fehlerfrei sein. Andernfalls führt Google Cloud ein Failover aus.
  • Eine Failover-Quote von 0.0 bedeutet, 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 Netzwerk-Load-Balancer verteilt Verbindungen zwischen VMs im aktiven Pool gemäß dem Algorithmus zur Trafficverteilung.

Traffic wird unterbrochen, wenn alle Back-End-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 Netzwerk-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 Netzwerk-Load-Balancers mit mehreren Zonen beschrieben.

Netzwerk-Load-Balancing mit mehreren Zonen (zum Vergrößern klicken)
Failover für Mehrzonen-Netzwerk-Load-Balancing (zum Vergrößern klicken)

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-a1 in ig-a
  • vm-a2 in ig-a
  • vm-d1 in ig-d
  • vm-d2 in ig-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-b1 in ig-b
  • vm-b2 in ig-b
  • vm-c1 in ig-c
  • vm-c2 in ig-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-a1 und vm-d1 fehlerhaft werden, verteilt Google Cloud neue Verbindungen zwischen den beiden verbleibenden fehlerfreien primären VMs (vm-a2 und vm-d2), da die Anzahl der fehlerfreien primären VMs den Mindestwert darstellt.

  • Wenn für vm-a2 die 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 Instanzgruppen ig-b und ig-c verteilt werden. Auch wenn die VM vm-d2 fehlerfrei bleibt, wird sie aus dem aktiven Pool entfernt und erhält keine neuen Verbindungen.

  • Wenn vm-a2 wiederhergestellt 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 VMs vm-a2 und vm-d2 festgelegt 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-a1 fehlerfrei wird, legt Google Cloud für den aktiven Pool die drei fehlerfreien primären VMs vm-a1, vm-a2 und vm-d2 fest und verteilt neue Verbindungen zwischen ihnen.

Weitere Informationen