Muster für die Verwendung von Floating-IP-Adressen in Compute Engine

Last reviewed 2024-01-29 UTC

In diesem Dokument wird beschrieben, wie Sie Muster für die Implementierung von Floating-IP-Adressen verwenden, wenn Sie Anwendungen aus einer lokalen Netzwerkumgebung zu Compute Engine migrieren. Dieses Dokument richtet sich an Netzwerkentwickler, Systemadministratoren und Betriebstechniker, die Anwendungen zu Google Cloud migrieren.

Floating-IP-Adressen werden auch als freigegebene oder virtuelle IP-Adressen bezeichnet und häufig verwendet, um lokale Netzwerkumgebungen hochverfügbar zu machen. Mithilfe von Floating-IP-Adressen können Sie eine IP-Adresse zwischen mehreren identisch konfigurierten physischen oder virtuellen Servern übergeben. Diese Vorgehensweise ermöglicht ein Failover oder ein Upgrade der Produktionssoftware. Floating-IP-Adressen können jedoch nicht direkt in einer Compute Engine-Umgebung implementiert werden, ohne die Architektur in eines der in diesem Dokument beschriebenen Muster zu ändern.

Das zu diesem Dokument gehörende GitHub-Repository enthält Beispielbereitstellungen für die einzelnen Muster, die Sie automatisch mit Terraform bereitstellen können.

Floating-IP-Adressen in lokalen Umgebungen

Floating-IP-Adressen werden üblicherweise in lokalen Umgebungen verwendet. Beispielanwendungsfälle:

Es gibt mehrere Möglichkeiten zur Implementierung von Floating-IP-Adressen in einer lokalen Umgebung. Server, die Floating-IP-Adressen freigeben, teilen in der Regel auch Statusinformationen über einen Heartbeat-Mechanismus. Dieser Mechanismus ermöglicht es den Servern, ihren Systemstatus untereinander zu kommunizieren. Außerdem kann der sekundäre Server die Floating-IP-Adresse übernehmen, sollte der primäre Server ausfallen. Dieses Schema wird häufig mit dem Virtual Router Redundancy Protocol implementiert. Sie können aber auch andere ähnliche Mechanismen verwenden.

Nachdem ein IP-Adressen-Failover initiiert wurde, fügt der Server, der die Floating-IP-Adresse übernimmt, die Adresse seiner Netzwerkschnittstelle hinzu. Der Server teilt diese Übernahme anderen Geräten mit, die Layer 2 verwenden. Dazu sendet er ein Gratuitous Address Resolution Protocol (ARP)-Frame. Alternativ meldet ein Routingprotokoll wie Open Shortest Path First (OSPF) die IP-Adresse an den vorgelagerten Layer 3-Router.

Dieses Diagramm zeigt eine typische Einrichtung in einer lokalen Umgebung.

Typische lokale Umgebung.

Das obige Diagramm zeigt, wie ein primärer Server und ein sekundärer Server, der mit demselben Switch verbunden ist, über einen Heartbeat-Mechanismus Informationen zur Reaktionsfähigkeit austauschen. Wenn der primäre Server ausfällt, sendet der sekundäre Server einen Gratuitous-ARP-Frame an den Switch, um die Floating-IP-Adresse zu übernehmen.

Die Einrichtung ist bei lokalen Load-Balancing-Lösungen, darunter Windows Network Load Balancing oder Linux-Load-Balancing mit Direct Server-Antwort wie IPVS, geringfügig anders. In solchen Fällen sendet der Dienst auch Gratuitous-ARP-Frames, jedoch mit der MAC-Adresse eines anderen Servers als der Gratuitous-ARP-Quelle. Diese Aktion spooft im Wesentlichen die ARP-Frames und übernimmt die Quell-IP-Adresse eines anderen Servers.

Mit dieser Aktion wird die Last für eine IP-Adresse auf verschiedene Server verteilt. Diese Art von Einrichtung wird in diesem Dokument jedoch nicht behandelt. In fast allen Fällen, in denen Floating-IP-Adressen für das lokale Load Balancing verwendet werden, wird die Migration zu Cloud Load Balancing bevorzugt.

Herausforderungen bei der Migration von Floating-IP-Adressen zu Compute Engine

Compute Engine verwendet einen virtualisierten Netzwerk-Stack in einem VPC-Netzwerk (Virtual Private Cloud), sodass typische Implementierungsmechanismen nicht ohne Veränderungen in Google Cloud funktionieren. Beispielsweise verarbeitet das VPC-Netzwerk ARP-Anfragen im softwarebasierten Netzwerk und ignoriert Gratuitous-ARP-Frames. Darüber hinaus ist es nicht möglich, die Routingtabelle des VPC-Netzwerks direkt mit Standard-Routingprotokollen wie OSPF oder Border Gateway Protocol (BGP) zu ändern. Die typischen Mechanismen für Floating-IP-Adressen beruhen auf ARP-Anfragen, die durch den Wechsel der Infrastruktur verarbeitet werden, oder auf Netzwerken, die von OSPF oder BGP programmiert werden. Daher wird für IP-Adressen kein Failover mithilfe dieser Mechanismen in Google Cloud durchgeführt. Wenn Sie ein VM-Image (Virtual Machine) mit einer lokalen Floating-IP-Adresse migrieren, kann die Floating-IP-Adresse ohne Failover der Anwendung ein Failover ausführen.

Sie könnten ein Overlay-Netzwerk verwenden, um eine Konfiguration zu erstellen, die eine vollständige Kommunikation und IP-Übernahme auf Ebene 2 über ARP-Anfragen ermöglicht. Die Einrichtung ist jedoch komplex und erschwert die Verwaltung von Compute Engine-Netzwerkressourcen. Auch dieser Ansatz wird in diesem Dokument nicht besprochen. Stattdessen werden in diesem Dokument Muster zum Implementieren von Failover-Szenarien in einer Compute Engine-Netzwerkumgebung beschrieben, wobei keine Overlay-Netzwerke erstellt werden müssen.

Um hochverfügbare und zuverlässige Anwendungen in Compute Engine zu implementieren sind horizontal skalierbare Architekturen geeignet. Diese Art Architektur minimiert die Auswirkungen einzelner Knotenausfälle.

In diesem Dokument werden mehrere Muster zum Migrieren einer vorhandenen Anwendung mit Floating-IP-Adressen von lokalen Standorten zu Compute Engine beschrieben, einschließlich der folgenden:

Die Verwendung von Alias-IP-Adressen, die zwischen VM-Instanzen verschoben werden, wird als Failover-Mechanismus nicht empfohlen, da dies die Hochverfügbarkeitsanforderungen nicht erfüllt. In bestimmten Fehlerszenarien, beispielsweise bei einem zonalen Ausfallereignis, können Sie möglicherweise Alias-IP-Adresse nicht aus einer Instanz entfernen. Daher können Sie sie möglicherweise nicht zu einer anderen Instanz hinzufügen, wodurch ein Failover unmöglich wird.

Muster für Ihren Anwendungsfall wählen

Je nach Ihren Anforderungen kann eines oder mehrere der in dieser Lösung beschriebenen Muster beim Implementieren von Floating-IP-Adressen in einer lokalen Umgebung hilfreich sein.

Berücksichtigen Sie folgende Faktoren, wenn Sie entscheiden, welches Muster für eine Anwendung ideal ist:

  • Interne oder externe Floating-IP-Adressen: Die meisten Anwendungen, die Floating-IP-Adressen erfordern, verwenden interne Floating-IP-Adressen. Einige Anwendungen verwenden externe Floating-IP-Adressen, da der Traffic an externe Anwendungen in der Regel durch Load-Balancing gesteuert wird.

    Die Tabelle weiter unten in diesem Abschnitt empfiehlt Muster, die Sie für interne und externe Floating-IP-Adressen verwenden können. Für Anwendungsfälle, die Floating-IP-Adressen erfordern, kann eines dieser Muster für Ihre Anforderungen geeignet sein. Es wird jedoch empfohlen, Anwendungsfälle, die auf externe Floating-IP-Adressen angewiesen sind, zu einem der Muster mit Load-Balancing zu migrieren.

  • Anwendungsprotokolle: Wenn Ihre VM nur TCP und UDP verwendet, können Sie alle Muster in der Tabelle verwenden. Wenn andere Protokolle über IPv4 verwendet werden, um eine Verbindung herzustellen, sind nur einige Muster geeignet.

  • Kompatibilität mit der Aktiv/Aktiv-Bereitstellung: Einige Anwendungen verwenden zwar einen lokalen Gleitkomma-IP-Adressbereich, können jedoch in einem Aktiv/Aktiv-Bereitstellungsmodus verwendet werden. Diese Funktion bedeutet, dass kein Failover vom primären Server auf den sekundären Server erforderlich ist. Sie haben mehr Möglichkeiten, Muster zu verschieben, um diese Arten von Anwendungen nach Compute Engine zu verschieben. Anwendungen, die jederzeit nur einen Anwendungsserver benötigen, um Traffic zu empfangen, sind nicht mit der Aktiv-Aktiv-Bereitstellung kompatibel. Sie können diese Anwendungen nur mit einigen Mustern in der folgenden Tabelle implementieren.

  • Failback-Verhalten nach der Wiederherstellung der primären VM: Wenn die ursprüngliche primäre VM nach einem Failover wiederhergestellt wird, führt der Traffic je nach verwendetem Muster zu zwei Aktionen. Entweder wird sie sofort zurück zur ursprünglichen primären VM verschoben oder auf der neuen primären VM verbleibt, bis das Failback manuell initiiert wird oder die neue primäre VM fehlschlägt. In allen Fällen schlagen nur neu initiierte Verbindungen fehl. Vorhandene Verbindungen bleiben auf der neuen primären VM, bis sie geschlossen werden.

  • Kompatibilität mit Systemdiagnosen: Wenn Sie mit Systemdiagnosen von Compute Engine nicht problemlos prüfen können, ob Ihre Anwendung responsiv ist, können Sie manche der in der folgenden Tabelle beschriebenen Muster nicht nutzen.

  • Instanzgruppen: Jedes Muster, das mit Systemdiagnosen kompatibel ist, ist auch mit Instanzgruppen kompatibel. Wenn fehlgeschlagene Instanzen automatisch neu erstellt werden sollen, können Sie eine verwaltete Instanzgruppe mit automatischer Reparatur verwenden. Wenn Ihre VMs den Status beibehalten, können Sie eine zustandsorientierte verwaltete Instanzgruppe verwenden. Wenn Ihre VMs nicht automatisch neu erstellt werden können oder Sie ein manuelles Failover benötigen, verwenden Sie eine nicht verwaltete Instanzgruppe und erstellen Sie die VMs während des Failovers manuell neu.

  • Vorhandene Heartbeat-Mechanismen: Wenn die Hochverfügbarkeitseinrichtung für Ihre Anwendung bereits einen Heartbeat-Mechanismus verwendet, um ein Failover auszulösen (Heartbeat, Pacemaker, Keepalived, usw.), können Sie einige der in der folgenden Tabelle beschriebenen Muster nutzen.

In folgender Tabelle sind die Musterfunktionen aufgeführt. Die einzelnen Muster werden in folgenden Abschnitten beschrieben.

Mustername IP-Adresse Unterstützte Protokolle Bereitstellungsmodus Failback Kompatibilität zum Anwendungs-Systemcheck erforderlich Kann einen Heartbeat-Mechanismus einbinden
Muster mit Load-Balancing
Aktiv/Aktiv-Load-Balancing Intern oder extern Nur TCP/UDP Aktiv/Aktiv – Ja Nein
Load-Balancing mit Failover-Gruppen und von der Anwendung bereitgestellten Systemdiagnosen Intern oder extern Nur TCP/UDP Aktiv/Passiv Sofort (außer vorhandene Verbindungen) Ja Nein
Load-Balancing mit Failover und von Heartbeat bereitgestellten Systemdiagnosen Intern oder extern Nur TCP/UDP Aktiv/Passiv Konfigurierbar Nein Ja
Muster mit Google Cloud-Routen
ECMP-Routen verwenden Intern Alle IP-Protokolle Aktiv/Aktiv – Ja Nein
Unterschiedliche Prioritätsrouten verwenden Intern Alle IP-Protokolle Aktiv/Passiv Sofort (außer vorhandene Verbindungen) Ja Nein
Heartbeat-Mechanismus verwenden, um den nächsten Hop der Route zu wechseln Intern Alle IP-Protokolle Aktiv/Passiv Konfigurierbar Nein Ja
Muster mit automatischer Reparatur
Einzelinstanz mit automatischer Reparatur verwenden Intern Alle IP-Protokolle – – Ja Nein

Die Entscheidung, welches Muster für Ihren Anwendungsfall geeignet ist, kann von mehreren Faktoren abhängen. Mit folgendem Entscheidungsbaum können Sie die möglichen geeigneten Optionen einschränken.

Ein Entscheidungsbaum, der Ihnen bei der Auswahl eines Load-Balancers hilft.

Das obige Diagramm veranschaulicht die folgenden Schritte:

  1. Bietet eine Einzelinstanz mit automatischer Reparatur eine ausreichende Verfügbarkeit für Ihre Anforderungen?
    1. Falls ja, finden Sie weiter unten in diesem Dokument unter Einzelinstanz mit automatischer Reparatur verwenden weitere Informationen. Die automatische Reparatur verwendet einen Mechanismus in einer VM-Instanzgruppe, um fehlerhafte VM-Instanzen automatisch zu ersetzen.
    2. Falls nicht, fahren Sie mit dem nächsten Entscheidungspunkt fort.
  2. Erfordert Ihre Anwendung Protokolle über IPv4, außer TCP und UDP?
    1. Falls ja, fahren Sie mit dem nächsten Entscheidungspunkt fort.
    2. Falls nicht, fahren Sie mit dem nächsten Entscheidungspunkt fort.
  3. Kann Ihre Anwendung im Aktiv/Aktiv-Modus arbeiten?
    1. Wenn ja, werden zusätzlich zu TCP und UDP Protokolle auf IPv4 benötigt, die weiter unten in diesem Dokument unter ECMP-Routen (Equal Cost Multipath) verwenden beschrieben werden. ECMP-Routen verteilen den Traffic auf die nächsten Hops aller Routenkandidaten.
    2. Wenn ja, benötigen Sie neben TCP und UDP keine anderen Protokolle als IPv4. Weitere Informationen finden Sie weiter unten in diesem Dokument unter Aktiv/Aktiv-Load-Balancing. Aktiv-Aktiv-Load-Balancing verwendet Ihre VMs als Back-Ends für einen internen TCP/UDP-Load-Balancer.
    3. Falls nicht, fahren Sie (in beiden Fällen) mit dem nächsten Entscheidungspunkt fort.
  4. Kann Ihre Anwendung Google Cloud-Systemdiagnosen bereitstellen?
    1. Wenn ja, und falls außer TCP und UDP Protokolle zusätzlich zu IPv4 benötigt werden, finden Sie weiter unten in diesem Dokument unter Load-Balancing mit Failover und von der Anwendung bereitgestellten Systemdiagnosen weitere Informationen. Load-Balancing mit Failover und von der Anwendung bereitgestellten Systemdiagnosen verwenden Ihre VMs als Back-Ends für einen internen TCP/UDP-Load-Balancer. Außerdem wird die IP-Adresse des internen TCP/UDP-Load-Balancing als virtuelle IP-Adresse verwendet.
    2. Wenn ja, und außer TCP und UDP keine anderen Protokolle über IPv4 benötigt werden, lesen Sie den Abschnitt Verschiedene Prioritätsrouten verwenden weiter unten in diesem Dokument. Die Verwendung unterschiedlicher Prioritätsrouten garantiert, dass der Traffic immer zu einer primären Instanz fließt, es sei denn, diese Instanz schlägt fehl.
    3. Wenn dies nicht der Fall ist und außer TCP und UDP andere Protokolle über IPv4 benötigt werden, lesen Sie den Abschnitt Load Balancing mit Failover und von Heartbeat bereitgestellten Systemdiagnosen weiter unten in diesem Dokument. Beim Load-Balancing mit Failover und von Heartbeat bereitgestellten Systemdiagnosen werden Systemdiagnosen nicht von der Anwendung selbst bereitgestellt, sondern von einem Heartbeat-Mechanismus, der zwischen beiden VMs ausgeführt wird.
    4. Wenn die Antwort hier „Nein“ ist und KEINE Protokolle über IPv4 außer TCP und UDP benötigt werden, finden Sie weiter unten in diesem Dokument unter Heartbeat-Mechanismus verwenden, um den nächsten Hop einer Route zu ändern zusätzliche Informationen. Wird ein Heartbeat-Mechanismus genutzt, um den nächsten Hop einer Route zu wechseln, wird eine einzelne statische Route verwendet, wobei der nächste Hop auf die primäre VM-Instanz verweist.

Muster mit Load-Balancing

In der Regel können Sie Ihre Anwendung mithilfe von Floating-IP-Adressen zu einer Architektur in Google Cloud migrieren, die Cloud Load Balancing verwendet. Sie können einen internen Passthrough-Network Load Balancer verwenden. Diese Option eignet sich für die meisten Anwendungsfälle, in denen der lokal migrierte Dienst nur intern verfügbar ist. Diese Load-Balancing-Option wird für alle Beispiele in diesem Abschnitt und in den Beispiel-Deployments auf GitHub verwendet. Wählen Sie die globale Zugriffsoption aus, wenn Sie Clients haben, die von anderen Regionen auf die Floating-IP-Adresse zugreifen.

Wenn Ihre Anwendung über Protokolle neben IPv4 außer TCP oder UDP kommuniziert, müssen Sie ein Muster auswählen, das kein Load-Balancing verwendet. Diese Muster werden weiter unten in diesem Dokument beschrieben.

Wenn Ihre Anwendung HTTP(S) verwendet, können Sie ein internen Anwendungs-Load-Balancer verwenden, um das Aktiv-Aktiv-Muster zu implementieren.

Ist der Dienst, den Sie migrieren möchten, extern verfügbar, können Sie alle in diesem Abschnitt beschriebenen Muster mithilfe eines externen Network Load Balancers implementieren. Für Aktiv/Aktiv-Bereitstellungen können Sie auch einen externen Application Load Balancer, einen TCP-Proxy oder einen SSL-Proxy verwenden, wenn Ihre Anwendung Protokolle und Ports verwendet, die von diesen Load-Balancing-Optionen unterstützt werden.

Beachten Sie folgende Unterschiede zwischen lokalen Floating-IP-Adress-basierten Implementierungen und den Load-Balancing-basierten Mustern:

  • Failover-Zeit: Das Koppeln von Keepalived mit Gratuitous-ARP in einer lokalen Umgebung kann innerhalb weniger Sekunden zu einem Failover einer IP-Adresse führen. In der Compute Engine-Umgebung hängt die mittlere Wiederherstellungszeit nach dem Failover von den festgelegten Parametern ab. Wenn die VM-Instanz oder der VM-Instanzdienst fehlschlägt, hängt die mittlere Betriebszeit bis zum Failover (Mean Time To Failover) von Systemdiagnoseparametern wie Check Interval und Unhealthy Threshold ab. Wenn diese Parameter auf ihre Standardwerte festgelegt sind, dauert das Failover ca. 15 bis 20 Sekunden. Sie können die Zeit reduzieren, indem Sie diese Parameterwerte verringern.

    In Compute Engine benötigen Failover innerhalb von Zonen und zwischen Zonen die gleiche Zeit.

  • Protokolle und Ports: In einer lokalen Einrichtung akzeptieren die Floating-IP-Adressen den gesamten Traffic. Wählen Sie in der internen Weiterleitungsregel für den internen Passthrough-Network Load Balancer eine der folgenden Portspezifikationen aus:

    • Geben Sie mindestens einen und maximal fünf Ports per Nummer an.
    • Geben Sie ALL an, um Traffic für TCP oder UDP an alle Ports weiterzuleiten.
    • Verwenden Sie mehrere Weiterleitungsregeln mit derselben IP-Adresse, um eine Mischung aus TCP- und UDP-Traffic weiterzuleiten oder mehr als fünf Ports mit einer einzelnen IP-Adresse zu verwenden:
      • Nur TCP oder UDP und 1–5 Ports: Verwenden Sie eine Weiterleitungsregel.
      • TCP und UDP und 1–5 Ports: Verwenden Sie mehrere Weiterleitungsregeln.
      • 6 oder mehr Ports und TCP oder UDP: Verwenden Sie mehrere Weiterleitungsregeln.

  • Systemdiagnose: Lokal können Sie die Reaktionsfähigkeit einer Anwendung auf einer Maschine auf folgende Arten prüfen:

Aktiv/Aktiv-Load-Balancing

Im Aktiv-Aktiv-Load-Balancing-Muster sind Ihre VMs Back-Ends für einen internen Passthrough-Network-Load-Balancer. Sie verwenden die interne IP-Adresse des Passthrough-Network-Load-Balancers als virtuelle IP-Adresse. Der Traffic wird gleichmäßig auf die beiden Backend-Instanzen verteilt. Traffic, der zur selben Sitzung gehört, wird an dieselbe Backend-Instanz weitergeleitet, wie in den Einstellungen für die Sitzungsaffinität definiert.

Verwenden Sie das Aktiv-Aktiv-Load-Balancing-Muster, wenn Ihre Anwendung nur Protokolle verwendet, die auf TCP und UDP basieren und kein Failover zwischen Rechnern erfordern. Verwenden Sie das Muster in einem Szenario, in dem Anwendungen abhängig vom Inhalt der Anfrage Anfragen beantworten können. Verwenden Sie das Muster nicht, wenn ein Maschinenstatus vorhanden ist, der nicht kontinuierlich synchronisiert wird, .z. B. in einer primären oder sekundären Datenbank,

Das folgende Diagramm zeigt eine Implementierung des Aktiv-Aktiv-Load-Balancing-Musters:

Gibt an, wie ein interner Client mit dem Aktiv-Aktiv-Load-Balancing-Muster umgeht.

Das obige Diagramm zeigt, wie ein interner Client auf einen Dienst zugreift, der auf zwei VMs über einen internen passthrough-Netzwerk-Load-Balancer ausgeführt wird. Beide VMs sind Teil einer Instanzgruppe.

Beim Aktiv-Aktiv-Load-Balancing-Muster muss Ihr Dienst Systemdiagnosen über eines der unterstützten Systemdiagnoseprotokolle verfügbar machen, um sicherzustellen, dass nur responsive VMs Traffic empfangen.

Eine vollständige Beispielimplementierung dieses Musters finden Sie unter Beispielbereitstellung mit Terraform auf GitHub.

Load-Balancing mit Failover-Gruppen und von der Anwendung bereitgestellten Systemdiagnosen

Ähnlich wie das Aktiv-Aktiv-Muster verwendet das Muster "Load-Balancing durch Failover und von der Anwendung bereitgestellte Systemdiagnosen" Ihre VMs als Back-Ends für einen internen passthrough-Netzwerk-Load-Balancer. Außerdem wird die interne IP-Adresse des passthrough-Netzwerk-Load-Balancers als virtuelle IP-Adresse verwendet. Damit jeweils nur eine VM Traffic empfängt, nutzt dieses Muster das Failover für interne passthrough-Netzwerk-Load-Balancer.

Dieses Muster wird empfohlen, wenn Ihre Anwendung nur TCP- oder UDP-Traffic unterstützt, aber keine Aktiv-Aktiv-Bereitstellung unterstützt. Wenn Sie dieses Muster anwenden, fließt der gesamte Traffic entweder an die primäre VM oder die Failover-VM.

Das folgende Diagramm zeigt eine Implementierung des Load-Balancings mit einem Failover und einem anwendungfreigegebenen Systemdiagnosemuster:

Wie ein interner Client einen Dienst hinter einem internen Passthrough-Netzwerk-Load-Balancer navigiert.

Das obige Diagramm zeigt, wie ein interner Client auf einen Dienst hinter einem internen Passthrough-Netzwerk-Load Balancer zugreift. Zwei VMs befinden sich in separaten Instanzgruppen. Eine Instanzgruppe wird als primäres Backend festgelegt. Die andere Instanzgruppe wird als Failover-Backend für einen internen Passthrough-Network Load Balancer festgelegt.

Wenn der Dienst auf der primären VM nicht mehr reagiert, wird der Traffic auf die Failover-Instanzgruppe umgestellt. Sobald die primäre VM wieder reagiert, wechselt der Traffic automatisch zum primären Backend-Dienst.

Eine vollständige Beispielimplementierung dieses Musters finden Sie unter Beispielbereitstellung mit Terraform auf GitHub.

Load-Balancing mit Failover und von Heartbeat bereitgestellten Systemdiagnosen

Das Load-Balancing mit Failover- und Heartbeat-veröffentlichten Systemdiagnosen entspricht dem vorherigen Muster. Der Unterschied besteht darin, dass Systemdiagnosen nicht von der Anwendung selbst bereitgestellt werden, sondern von einem Heartbeat-Mechanismus, der zwischen beiden VMs ausgeführt wird.

Das folgende Diagramm zeigt eine Implementierung des Load-Balancings mit Failover und von Heartbeat bereitgestellten Systemdiagnosen:

Art des Zugriffs eines internen Clients auf einen Dienst hinter einem internen Load-Balancer mit zwei VMs in separaten Instanzgruppen.

Dieses Diagramm zeigt, wie ein interner Client auf einen Dienst hinter einem internen Load-Balancer zugreift. Zwei VMs befinden sich in separaten Instanzgruppen. Eine Instanzgruppe wird als primäres Backend festgelegt. Die andere Instanzgruppe wird als Failover-Backend für einen internen Passthrough-Network Load Balancer festgelegt. Keepalived wird als Heartbeat-Mechanismus zwischen den VM-Knoten verwendet.

Die VM-Knoten tauschen mithilfe des ausgewählten Heartbeat-Mechanismus Informationen zum Status des Dienstes aus. Jeder VM-Knoten prüft seinen eigenen Status und kommuniziert diesen Status an den Remote-Knoten. Abhängig vom Status des lokalen Knotens und des vom Remote-Knoten empfangenen Status wird ein Knoten als primärer Knoten und ein Knoten als Sicherungsknoten ausgewählt. Sie können diese Statusinformationen verwenden, um ein Systemdiagnoseergebnis verfügbar zu machen, das gewährleistet, dass der Knoten als primär im Heartbeat-Mechanismus gilt, der auch Traffic vom internen passthrough-Netzwerk-Load-Balancer empfängt.

Mit Keepalived können Sie beispielsweise Skripts mit den Konfigurationsvariablen notify_master, notify_backup und notify_fault aufrufen, die den Systemdiagnosestatus ändern. Beim Übergang zum primären Status (in Keepalived wird dieser Status als master bezeichnet) können Sie eine Anwendung starten, die einen benutzerdefinierten TCP-Port überwacht. Wenn Sie zu einem Sicherungs- oder Fehlerzustand wechseln, können Sie diese Anwendung beenden. Die Systemdiagnose kann dann eine TCP-Systemdiagnose sein, die erfolgreich ist, wenn dieser benutzerdefinierte TCP-Port geöffnet ist.

Dieses Muster ist komplexer als das Muster mit Failover und von der Anwendung bereitgestellten Systemdiagnosen. Es ermöglicht Ihnen jedoch mehr Kontrolle. Beispielsweise können Sie es so konfigurieren, dass es im Rahmen der Implementierung des Heartbeat-Mechanismus sofort oder manuell ein Failback ausführt.

Eine vollständige Beispielimplementierung dieses Musters, das Keepalived verwendet, finden Sie unter Beispielbereitstellung mit Terraform auf GitHub.

Muster mit Google Cloud-Routen

In Fällen, in denen Ihre Anwendung neben TCP oder UDP andere Protokolle auf IPv4 verwendet, können Sie Ihre Floating-IP-Adresse basierend auf Routen zu einem Muster migrieren.

In diesem Abschnitt beziehen sich Erwähnungen von Routen immer auf Google Cloud-Routen, die Teil eines VPC-Netzwerk sind. Verweise auf statische Routen beziehen sich immer auf statische Routen in Google Cloud.

Mit einem dieser Muster legen Sie mehrere statische Routen für eine bestimmte IP-Adresse mit den verschiedenen Instanzen als nächste Hops fest. Diese IP-Adresse wird zur Floating-IP-Adresse, die alle Clients verwenden. Sie muss sich außerhalb aller VPC-Subnetz-IP-Adressbereiche befinden, da statische Routen keine vorhandenen Subnetzrouten überschreiben können. Sie müssen die IP-Adressweiterleitung für die Zielinstanzen aktivieren. Durch die Aktivierung der IP-Adressweiterleitung können Sie Traffic für IP-Adressen akzeptieren, die den Instanzen nicht zugewiesen sind – in diesem Fall die Floating-IP-Adresse.

Wenn die Floating-IP-Adressrouten aus Peering-VPC-Netzwerken verfügbar sein sollen, exportieren Sie benutzerdefinierte Routen, damit die Floating-IP-Adressrouten an alle Peer-VPC-Netzwerke weitergegeben werden.

Wenn Sie eine Verbindung von einem lokalen Netzwerk aus herstellen möchten, das über Cloud Interconnect oder Cloud VPN verbunden ist, müssen Sie das benutzerdefinierte IP-Adressrouten-Advertising nutzen, um die Floating-IP-Adresse lokal anzubieten.

Routenbasierte Muster haben folgenden Vorteil gegenüber Load-Balancing-Mustern:

  • Protokolle und Ports: Routenbasierte Muster gelten für den gesamten an ein bestimmtes Ziel gesendeten Traffic. Load-Balancing-basierte Muster lassen nur TCP- und UDP-Traffic zu.

Routenbasierte Muster haben folgende Nachteile gegenüber Load-Balancing-Mustern:

  • Systemdiagnose: Systemdiagnosen können nicht an Google Cloud-Routen angehängt werden. Routen werden unabhängig vom Systemstatus der zugrunde liegenden VM-Dienste verwendet. Leiten Sie Traffic bei jeder Ausführung der VM an Instanzen weiter, auch wenn der Dienst fehlerhaft ist. Wenn Sie diesen Instanzen eine Richtlinie zur automatischen Reparatur hinzufügen, werden die Instanzen nach einem von Ihnen festgelegten Zeitraum ersetzt. Sobald diese Instanzen jedoch neu gestartet werden, wird der Traffic sofort fortgesetzt, selbst vor dem Start des Dienstes. Diese Dienstlücke kann zu potenziellen Dienstfehlern führen, wenn fehlerhafte Instanzen weiterhin Traffic bereitstellen oder neu gestartet werden.
  • Failover-Zeit: Nachdem Sie eine VM-Instanz gelöscht oder beendet haben, ignoriert Compute Engine alle statischen Routen, die auf diese Instanz verweisen. Da aber keine Systemdiagnosen für Routen vorhanden sind, verwendet Compute Engine die statische Route so lange, wie die Instanz noch verfügbar ist. Darüber hinaus nimmt das Beenden der Instanz Zeit in Anspruch, sodass die Failover-Zeit erheblich höher ist als bei Load-Balancing-basierten Mustern.
  • Nur interne Floating-IP-Adressen: Sie können Muster mithilfe von Load-Balancing mit einem externen passthrough-Netzwerk-Load-Balancer implementieren, um eine externe Floating-IP-Adresse zu erstellen. Routenbasierte Muster funktionieren jedoch nur mit internen Floating-IP-Adressen.
  • Auswahl einer Floating-IP-Adresse: Sie können Routen nur auf interne Floating-IP-Adressen festlegen, die nicht Teil eines Subnetzes sind. Subnetzrouten können in Google Cloud nicht überschrieben werden. Überwachen Sie diese Floating-IP-Adressen, damit Sie sie nicht versehentlich einem anderen Netzwerk zuzuweisen.
  • Erreichbarkeit von Routen: Damit interne Floating-IP-Adressen von lokalen Netzwerken oder Peering-Netzwerken aus erreichbar sind, müssen Sie diese statischen Routen wie zuvor beschrieben verteilen.

ECMP-Routen (Equal Cost Multipath) verwenden

Das ECMP-Routenmuster gleicht dem Aktiv-Aktiv-Load-Balancing-Muster. Der Traffic wird gleichmäßig auf die beiden Backend-Instanzen verteilt. Wenn Sie statische Routen verwenden, verteilt ECMP den Traffic auf die nächsten Hops aller Routenkandidaten. Dabei wird ein 5-Tupel-Hash für Affinität verwendet.

Zum Implementieren dieses Musters erstellen Sie zwei statische Routen mit gleicher Priorität, mit den Compute-Instanzen als nächsten Hops.

Das folgende Diagramm zeigt eine Implementierung des ECMP-Routenmusters:

Zugriff eines internen Clients auf einen Dienst über eine von zwei ECMP-Routen.

Das obige Diagramm zeigt, wie ein interner Client über eine von zwei Routen auf einen Dienst zugreift, wobei der nächste Hop auf die VM-Instanzen verweist, die den Dienst implementieren.

Wenn der Dienst auf einer VM nicht mehr reagiert, versucht die automatische Reparatur, die nicht reagierende Instanz neu zu erstellen. Sobald die automatische Reparatur die Instanz löscht, wird die Route, die auf die Instanz verweist, inaktiv, bevor die neue Instanz erstellt wurde. Sobald die neue Instanz vorhanden ist, wird die auf diese Instanz weisende Route sofort automatisch verwendet, und der Traffic wird gleichmäßig auf die Instanzen verteilt.

Beim ECMP-Routenmuster muss der Dienst Systemdiagnosen mithilfe unterstützter Protokolle verfügbar machen, damit die automatische Reparatur nicht reagierende VMs automatisch ersetzen kann.

Eine Beispielimplementierung dieses Musters, die Terraform verwendet, finden Sie im GitHub-Repository, das diesem Dokument zugeordnet ist.

Unterschiedliche Prioritätsrouten verwenden

Das Muster für Routen mit unterschiedlicher Priorität ähnelt dem vorherigen Muster, mit der Ausnahme, dass es statische Routen mit unterschiedlicher Priorität verwendet, sodass der Traffic immer zu einer primären Instanz fließt, es sei denn, diese Instanz schlägt fehl.

Führen Sie die gleichen Schritte wie im ECMP-Routenmuster aus, um dieses Muster zu implementieren. Geben Sie beim Erstellen der statischen Routen die Route mit dem nächsten Hop an, der auf die primäre Instanz verweist, einen niedrigeren Prioritätswert (primäre Route). Weisen Sie der Instanz mit dem nächsten Hop, der auf die sekundäre Instanz verweist, einen höheren Prioritätswert zu (sekundäre Route).

Das folgende Diagramm zeigt eine Implementierung des Musters mit verschiedenen Prioritäten:So nutzt ein interner Client, der auf einen Dienst zugreift, basierend auf den Netzwerkbedingungen eine primäre oder sekundäre Route.

Das vorhergehende Diagramm zeigt, wie ein interner Client, der auf einen Dienst zugreift, eine primäre Route mit einem Prioritätswert von 500 verwendet, der auf VM 1 als nächsten Hop unter normalen Umständen verweist. Eine zweite Route mit einem Prioritätswert von 1.000 ist auch verfügbar. Diese verweist auf VM 2, die sekundäre VM, als nächsten Hop.

Wenn der Dienst auf der primären VM nicht mehr reagiert, versucht die automatische Reparatur, die Instanz neu zu erstellen. Sobald die automatische Reparatur die Instanz löscht und bevor die neue Instanz, die sie erstellt, gestartet wird, wird die primäre Route mit der primären Instanz als nächsten Hop inaktiv. Das Muster verwendet dann die Route mit der sekundären Instanz als nächsten Hop. Sobald die neue primäre Instanz eingerichtet ist, wird die primäre Route wieder aktiv und der gesamte Traffic fließt an die primäre Instanz.

Wie beim vorherigen Muster erfordert das Muster mit Routen verschiedener Priorität, dass der Dienst Systemdiagnosen mithilfe unterstützter Protokolle bereitstellt, sodass die automatische Reparatur nicht reagierende VMs automatisch ersetzen kann.

Eine Beispielimplementierung dieses Musters, die Terraform verwendet, finden Sie im GitHub-Repository, das zu diesem Dokument gehört.

Heartbeat-Mechanismus verwenden, um den nächsten Hop einer Route zu wechseln

Wenn Ihre Anwendung einen Heartbeat-Mechanismus wie Keepalived implementiert, um die Reaktionsfähigkeit der Anwendung zu überwachen, können Sie das Heartbeat-Mechanismus anwenden, um den nächsten Hop der statischen Route zu ändern. In diesem Fall verwenden Sie nur eine einzelne statische Route, wobei der nächste Hop auf die primäre VM-Instanz verweist. Bei einem Failover verweist der Heartbeat-Mechanismus den nächsten Hop der Route auf die sekundäre VM.

Das folgende Diagramm zeigt eine Implementierung des Heartbeat-Mechanismus, deren Ziel es ist, das Nächstes-Hop-Muster einer Route zu wechseln:

Art des Zugriffs eines internen Client auf einen Dienst, bei dem die primäre und sekundäre VM Heartbeat-Informationen austauschen.

Das obige Diagramm zeigt, wie ein interner Client über eine Route auf den Dienst zugreift, wobei der nächste Hop auf die primäre VM verweist. Die primäre VM tauscht mithilfe von Keepalived Heartbeat-Informationen mit der sekundären VM aus. Bei einem Failover ruft Keepalived eine Cloud Run-Funktion auf, die API-Aufrufe verwendet, um den nächsten Hop auf die sekundäre VM zu verweisen.

Die Knoten verwenden den ausgewählten Heartbeat-Mechanismus, um Informationen über den Status des Dienstes miteinander auszutauschen. Jeder VM-Knoten prüft seinen eigenen Status und kommuniziert ihn mit dem Remote-VM-Knoten. Je nach Status des lokalen VM-Knotens und des vom Remote-Knoten empfangenen Status wird ein VM-Knoten als primärer Knoten und ein VM-Knoten als Sicherungsknoten ausgewählt. Sobald ein Knoten primärer Knoten ist, verweist er auf den nächsten Hop der Route für die Floating-IP-Adresse. Wenn Sie Keepalived verwenden, können Sie ein Script mit der Konfigurationsvariable notify_master aufrufen, die die statische Route über einen API-Aufruf oder die Google Cloud CLI ersetzt.

Beim Heartbeat-Mechanismus, um das Muster des nächsten Hops einer Route zu ändern, müssen die VMs nicht Teil einer Instanzgruppe sein. Wenn Sie möchten, dass die VMs bei einem Fehler automatisch ersetzt werden, können Sie sie in eine Instanzgruppe für die automatische Reparatur aufnehmen. Sie können nicht reagierende VMs auch manuell reparieren und neu erstellen.

Durch das Aufrufen des folgenden Verfahrens bei einem Failover wird die Failover-Zeit minimiert, da der Traffic nach dem Abschluss eines einzelnen API-Aufrufs in Schritt 1 wechselt:

  1. Erstellen Sie eine neue statische Route mit der Floating-IP-Adresse als Ziel und der neuen primären Instanz als nächstem Hop. Die neue Route sollte einen anderen Routennamen und eine niedrigere Routenpriorität (z. B. 400) haben als die ursprüngliche Route.
  2. Löschen Sie die ursprüngliche Route zur zuvor primären VM.
  3. Erstellen Sie eine Route mit dem Namen und der Priorität der Route, die Sie gerade gelöscht haben. Verweisen Sie sie auf die neue primäre VM als nächsten Hop.
  4. Löschen Sie die neue statische Route, die Sie erstellt haben. Sie benötigen sie nicht, um sicherzustellen, dass der Traffic zur neuen primären VM fließt.

Da die ursprüngliche Route ersetzt wurde, sollte immer nur eine Route aktiv sein, auch wenn ein geteiltes Netzwerk genutzt wird.

Die Verwendung des Heartbeat-Mechanismus zum Wechsel des Routenprioritätsmuster statt anderer routenbasierter Muster kann die Failover-Zeit reduzieren. Sie müssen VMs nicht durch eine automatische Reparatur für ein Failover löschen und ersetzen. Außerdem haben Sie mehr Kontrolle darüber, wann ein Failover zurück auf den ursprünglichen primären Server erfolgen soll, nachdem er wieder reagiert.

Ein Nachteil des Musters ist, dass Sie den Heartbeat-Mechanismus selbst verwalten müssen. Die Verwaltung des Mechanismus kann zu komplexer werden. Ein weiterer Nachteil besteht darin, dass Sie Berechtigungen zum Ändern der globalen Routingtabelle an die VMs, auf denen der Heartbeat-Prozess ausgeführt wird, oder an eine serverlose Funktion, die über den Heartbeat-Prozess aufgerufen wird, erteilen müssen. Das Ändern der globalen Routingtabelle zu einer serverlosen Funktion ist sicherer, da sie den Umfang der Berechtigungen der VMs reduzieren kann. Dieser Ansatz ist jedoch komplexer zu implementieren.

Eine vollständige Beispielimplementierung dieses Musters mit Keepalived finden Sie unter Beispielbereitstellung mit Terraform auf GitHub.

Muster mit automatischer Reparatur

Abhängig von den Anforderungen an die Wiederherstellungszeit ist die Migration zu einer einzelnen VM-Instanz bei der Verwendung von Compute Engine möglicherweise eine interessante Option. Diese Option funktioniert auch, wenn mehrere Server, die eine Floating-IP-Adresse verwenden, lokal verwendet werden. Dieses Muster kann zuweilen verwendet werden, obwohl die Anzahl der reduzierten VMs reduziert wird, da eine neue Compute Engine-Instanz in Sekunden oder Minuten erstellt werden kann, während das Beheben lokaler Fehler Stunden oder sogar Tage in Anspruch nehmen kann.

Einzelinstanz mit automatischer Reparatur verwenden

Bei diesem Muster verwenden Sie den automatischen Reparaturmechanismus in einer VM-Instanzgruppe, um eine fehlerhafte VM-Instanz automatisch zu ersetzen. Die Anwendung stellt eine Systemdiagnose bereit. Wenn die Anwendung fehlerhaft ist, ersetzt die automatische Reparatur automatisch die VM.

Das folgende Diagramm zeigt eine Implementierung des Musters für die automatische Reparatur einer Einzelinstanz:

So baut ein interner Client direkt eine Verbindung zu einer Compute Engine-Instanz auf.

Das obige Diagramm zeigt, wie ein interner Client direkt mit einer Compute Engine-Instanz verbunden wird, die in einer verwalteten Instanzgruppe mit einer Größe von 1 bei aktivierter automatischer Reparatur platziert ist.

Im Vergleich zu Mustern mit Load-Balancing hat das Muster einer Einzelinstanz mit automatischer Reparatur folgende Vorteile:

  • Traffic-Verteilung: Es gibt nur eine Instanz, sodass diese Instanz immer den gesamten Traffic erhält.
  • Nutzerfreundlichkeit: Da es nur eine Instanz gibt, ist dieses Muster am einfachsten zu implementieren.
  • Kosteneinsparungen: Wird nur eine einzige VM-Instanz anstelle von zwei Instanzen verwendet, können die Kosten der Implementierung um die Hälfte reduziert werden.

Das Muster hat jedoch folgende Nachteile:

  • Failover-Zeit: Dieser Prozess ist viel langsamer als Load-Balancing-Muster. Nachdem die Systemdiagnose einen Maschinenausfall erkannt hat, dauert das Löschen und Wiederherstellen der fehlgeschlagenen Instanz mindestens eine Minute, dauert aber oft länger. Dieses Muster ist in Produktionsumgebungen nicht üblich. Die Failover-Zeit kann jedoch für einige interne oder experimentelle Dienste ausreichen.
  • Reaktion auf Zonenausfälle: Eine verwaltete Instanzgruppe der Größe 1 überlebt einen Zonenausfall niemals. Um auf Zonenausfälle reagieren zu können, fügen Sie eine Cloud Monitoring-Warnung hinzu, wenn der Dienst ausfällt, und erstellen Sie bei Zonenausfall eine Instanzgruppe in einer anderen Zone. Da Sie in diesem Fall nicht dieselbe IP-Adresse verwenden können, verwenden Sie eine private Cloud DNS-Zone, um die VM zu adressieren und den DNS-Namen auf die neue IP-Adresse zu ändern.

Eine Beispielimplementierung dieses Musters, die Terraform verwendet, finden Sie im GitHub-Repository.

Nächste Schritte