Best Practices für Floating-IP-Adressen

Diese Lösung beschreibt Alternativen, die Sie bei der Migration von Anwendungen zu Compute Engine aus einer lokalen Netzwerkumgebung anstelle von Floating-IP-Adressen verwenden können. Floating-IP-Adressen werden auch als "gemeinsam genutzte" 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, um ein Failover oder ein Upgrade der Produktionssoftware zu ermöglichen. Floating-IP-Adressen können jedoch nicht direkt in einer Compute Engine-Umgebung implementiert werden.

Floating-IP-Adressen in lokalen Umgebungen

Floating-IP-Adressen werden üblicherweise in lokalen Umgebungen verwendet. In der folgenden Liste sind einige der Anwendungsfälle für Floating-IP-Adressen aufgeführt:

  • Hochverfügbare physische Appliances, z. B. Firewalls oder Load-Balancer, verwenden häufig Floating-IP-Adressen für Failover.
  • Server, die hohe Verfügbarkeit erfordern, verwenden in der Regel Floating-IP-Adressen, z. B. Master-Slave-Datenbanken wie Microsoft SQL Server mit immer aktiven Verfügbarkeitsgruppen.
  • Linux-Umgebungen, die Load-Balancer oder Reverse-Proxys implementieren, verwenden Floating-IP-Adressen wie IPVS, HAProxy oder NGINX. Diese Umgebungen verwenden Daemons wie Heartbeat, Pacemaker oder Keepalived, um Knotenfehler zu erkennen und Floating-IP-Adressen zwischen Instanzen zu verschieben.
  • Floating-IP-Adressen ermöglichen eine hohe Verfügbarkeit von Windows-Diensten mithilfe von Windows Server Failover Clustering.

Es gibt mehrere Möglichkeiten zur Implementierung von Floating-IP-Adressen in einer lokalen Umgebung. In allen Fällen müssen die Server, die die IP-Adresse freigeben, auch deren Status mithilfe eines Heartbeat-Mechanismus freigeben. 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 verknüpfte Server ausfallen. Dieses Schema wird häufig mit dem Virtual Router Redundancy Protocol (VRRP) implementiert. Sie können aber auch andere ähnliche Mechanismen verwenden.

Nachdem ein IP-Failover initiiert wurde, fügt der Server, der die Floating-IP-Adresse übernimmt, die Adresse zu seiner Netzwerkschnittstelle hinzu. Der Server teilt diese Übernahme anderen Geräten mit, die Layer 2 verwenden, indem er ein Gratuitous Address Resolution Protocol (ARP)-Frame sendet. Alternativ kann die IP-Adresse durch ein Routingprotokoll wie Open Shortest Path First (OSPF) dem Upstream-Layer-3-Router mitgeteilt werden.

Das folgende Diagramm zeigt eine typische Einrichtung in einer lokalen Umgebung.

typische lokale Umgebung

Sie verwenden eine geringfügig abweichende Einrichtung bei lokalen Lösungen mit Lastenausgleichsmodulen, wie z. B. Windows Network Load Balancing oder Linux Load Balancing mit Direct Server-Antwort, zum Beispiel IP Virtual Server (IPVS). In diesen Fällen sendet der Dienst auch Gratuitous-ARP-Frames, jedoch mit der MAC-Adresse eines anderen Servers wie der Gratuitous-ARP-Quelle, vorwiegend durch "Spoofing" der ARP-Frames und durch Übernahme der Quelladresse eines anderen Servers. Diese Art von Einrichtung ist für diese Lösung nicht verfügbar. In fast allen Fällen ist die Migration zu Lastenausgleichsmodulen der bevorzugte Migrationspfad.

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

Compute Engine verwendet einen virtualisierten Netzwerkstapel in einem Virtual Private Cloud-Netzwerk (VPC), sodass typische Implementierungsmechanismen nicht unverändert angewandt werden können. Beispielsweise verarbeitet das VPC-Netzwerk ARP-Anfragen anhand der konfigurierten Routingtopologie 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.

Sie könnten ein Overlay-Netzwerk verwenden, um eine Konfiguration zu erstellen, die eine vollständige Kommunikation und IP-Übernahme auf Ebene 2 mit ARP-Anfragen ermöglicht. Die Einrichtung ist jedoch komplex und erschwert die Verwaltung von Compute Engine-Netzwerkressourcen. Dieser Ansatz ist außerdem für diese Lösung nicht vorgesehen. Stattdessen bietet diese Lösung alternative Ansätze zum Implementieren von Failover-Szenarien in einer nativen Compute Engine-Netzwerkumgebung.

Diese Lösung beschreibt Möglichkeiten zum Migrieren der Mehrzahl der beschriebenen Anwendungsfälle in Compute Engine.

Folgende Schritt-für-Schritt-Anleitungen sind bereits für spezifischere Anwendungsfälle vorhanden:

Anwendungsfall für Migration – Beispiel

Diese Lösung beschreibt vier verschiedene Migrationsoptionen für den Wechsel von lokalen Floating-IP-Adressen zu Compute Engine.

Der Anwendungsfall umfasst das Migrieren von zwei internen HAProxy-Servern, die den Traffic an verschiedene Back-Ends weiterleiten, abhängig vom komplexen Abgleich und Ersetzen des Layer-7-Headers. Aufgrund der komplexen Regeln können diese Server nicht durch internes TCP/UDP-Load-Balancing und auch nicht durch HTTP-Load-Balancing ersetzt werden. In der folgenden Abbildung sehen Sie einen Überblick über diesen Anwendungsfall.

Anwendungsfall für Migration

Die HAProxy-Server verwenden die Keepalived-Software vor Ort, um die Verfügbarkeit mithilfe eines separaten Cross Connect zu überprüfen und die Floating-IP-Adressen zwischen den beiden Servern zu übertragen.

Für diesen Anwendungsfall können die vier Optionen, die in den folgenden Abschnitten beschrieben werden, als gültiger lokaler Ersatz für Floating-IP-Adressen verwendet werden. Für andere, möglicherweise komplexere Anwendungsfälle können weniger Optionen relevant sein. Zusätzlich zur Beschreibung dieser Optionen bietet diese Lösung eine Anleitung zu bevorzugten Optionen anhand bestimmter Anwendungsfälle.

Im nächsten Abschnitt wird die Migration dieses Anwendungsfallszenarios zu Compute Engine erläutert.

Implementierung mit Compute Engine

In diesem Abschnitt werden verschiedene Möglichkeiten zum Migrieren des lokalen Szenarios zu Compute Engine beschrieben. Alle Anfragen werden an eine einzelne Gruppe von NGINX-Back-Ends mit einer minimalen Back-End-Konfiguration weitergeleitet, um die Komplexität zu reduzieren. Dieser Ansatz wird anstelle des zuvor beschriebenen headerbasierten Abgleichs verwendet.

In allen Beispielen wird der Traffic von HAProxy an eine Gruppe von Compute Engine-Back-Ends weitergeleitet, die in einer Instanzgruppe für automatische Skalierung platziert sind. Der Zugriff auf diese Back-Ends erfolgt über einen internen TCP/UDP-Load-Balancer. In der Beispielkonfiguration dienen diese Back-Ends der NGINX-Standardkonfiguration.

Verwenden Sie ein dediziertes Projekt zum Testen, um den Beispielanwendungsfall zu implementieren.

Back-Ends konfigurieren

In diesem Abschnitt konfigurieren Sie die NGINX-Back-Ends, auf die über die HAProxy-Knoten zugegriffen wird. Als Best Practice erstellen Sie diese Back-Ends in einer für diese Bereitstellung vorgesehenen VPC, anstelle des Standardnetzwerks.

So richten Sie die Back-Ends ein:

  1. Legen Sie Ihre Standardzone fest, z. B.:

    gcloud config set compute/zone us-central1-f
    
  2. Richten Sie ein Netzwerk zum Testen ein und konfigurieren Sie die Firewallregeln so, dass interner Traffic zugelassen wird. Verwenden Sie außerdem den Befehl ssh, um mit dem Netzwerk zu kommunizieren:

    gcloud compute networks create ip-failover
    
    gcloud compute firewall-rules create failover-internal \
        --network ip-failover --allow all --source-ranges 10.128.0.0/11
    
    gcloud compute firewall-rules create failover-ssh \
        --network ip-failover --allow tcp:22 --source-ranges 0.0.0.0/0
    
  3. Erstellen Sie eine Instanzvorlage für die NGINX-Back-Ends:

    gcloud compute instance-templates create www \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata startup-script="apt-get -y install nginx"
    
  4. Erstellen Sie eine zonal verwaltete Instanzgruppe mit automatischer Skalierung anhand der Vorlage:

    gcloud compute instance-groups managed create www \
        --template www --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed set-autoscaling www \
        --max-num-replicas 10 --min-num-replicas 1 \
        --target-cpu-utilization 0.8 --zone us-central1-f
    
  5. Hängen Sie einen internen TCP/UDP-Load-Balancer mit einer festen IP-Adresse (10.128.2.2) an diese Instanzgruppe an:

    gcloud compute health-checks create http simple-check
    
    gcloud compute backend-services create www-lb \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks simple-check \
        --protocol tcp
    
    gcloud compute backend-services add-backend www-lb\
        --instance-group www \
        --instance-group-zone us-central1-f \
        --region us-central1
    
    gcloud compute forwarding-rules create www-rule \
        --load-balancing-scheme internal \
        --ports 80 \
        --network ip-failover \
        --region us-central1 \
        --address 10.128.2.2 \
        --backend-service www-lb
    
  6. Erstellen Sie eine Instanz zum Testen und stellen Sie mit dem Befehl ssh eine Verbindung her. Überprüfen Sie, ob Sie die IP-Adresse für das interne TCP/UDP-Load-Balancing erreichen können:

    gcloud compute instances create testing \
        --machine-type n1-standard-1 --zone us-central1-f \
        --network ip-failover --scopes compute-ro
    
    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.128.2.2
    <!DOCTYPE html> [...]
    username@testing:~$ exit

Diese Beispielkonfiguration verwendet n1-standard-1-Instanzen, die durch einen Netzwerkdurchsatz von zwei Gigabyte pro Sekunde pro Instanz begrenzt sind. In einer echten Bereitstellung würden Sie die Größe der Instanzen entsprechend Ihren Anforderungen anpassen.

Darüber hinaus werden Instanzen mit externen IP-Adressen erstellt, sodass Sie die erforderlichen Pakete mithilfe von Startup-Skripts herunterladen können. In einer Produktionsumgebung würden Sie benutzerdefinierte Images erstellen und die Instanzen ohne externe IP-Adressen erstellen.

Option 1: Internes TCP/UDP-Load-Balancing verwenden

Sie können das lokale Szenario in Compute Engine implementieren. Fügen Sie dazu die beiden HAProxy-Server hinter dem internen TCP/UDP-Load-Balancing in eine verwaltete Instanzgruppe ein und verwenden Sie die IP-Adresse für das interne TCP/UDP-Load-Balancing als virtuelle IP-Adresse (siehe folgende Abbildung).

Option 1: Internes TCP/UDP-Load-Balancing

Es wird davon ausgegangen, dass der lokal migrierte Dienst nur intern verfügbar ist. Wenn der zu migrierende Dienst extern verfügbar ist, können Sie dieses Szenario auf ähnliche Weise mit HTTP(S)-Load-Balancing, TCP-Proxy, SSL-Proxy oder Netzwerk-Load-Balancing implementieren.

Die folgenden Optionen sind als Betaversionen ebenfalls verfügbar:

Unterschiede im Vergleich zu einer lokalen Einrichtung

Die interne IP-Adresse des internen TCP/UDP-Load-Balancing funktioniert ähnlich wie die Floating-IP-Adressen in der lokalen Umgebung, mit einigen bedeutenden Abweichungen:

  • Trafficverteilung

    Der bedeutendste Unterschied besteht darin, dass der Traffic zwischen den beiden Knoten geteilt wird, während der Traffic in der ursprünglichen Einrichtung immer nur jeweils einen Knoten erreicht. Dieser Ansatz eignet sich zwar in einem Szenario, in dem Traffic abhängig von den Inhalten der Anfrage weitergeleitet wird, funktioniert aber nicht bei einem Gerätestatus, der nicht kontinuierlich synchronisiert wird (z. B. eine Master/Slave-Datenbank).

  • Failover-Zeit

    Die Verwendung von Keepalived in einer lokalen Umgebung in Verbindung mit Gratuitous-ARP kann innerhalb weniger Sekunden zu einem Failover einer IP-Adresse führen. In der Compute Engine-Umgebung hängt die mittlere Wiederherstellungszeit vom Fehlermodus 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, kann jedoch bei Anpassung der Parameter reduziert werden. In Compute Engine benötigen Failover innerhalb oder zwischen Zonen die gleiche Zeit.

  • Systemdiagnose

    Bei der lokalen Verwendung kann Keepalived nicht nur auf ein Lebenssignal warten, sondern darüber hinaus den Systemstatus der Maschine auf unterschiedliche Weise überprüfen, zum Beispiel durch Überwachung der Verfügbarkeit des HAProxy-Prozesses. In Compute Engine muss die Systemdiagnose außerhalb des Hosts über einen HTTP/HTTPS/TCP- oder SSL-Port zugänglich sein. Wenn die Hostdetails überprüft werden müssen, installieren Sie einen einfachen Dienst auf der Instanz, um diese Details offenzulegen, oder wählen Sie eine andere Option.

  • Ports

    In einer lokalen Konfiguration akzeptieren die Floating-IP-Adressen den gesamten Traffic. Für den internen TCP/UDP-Load-Balancer müssen Sie in der internen Weiterleitungsregel eine der folgenden Portspezifikationen auswählen:

    • Geben Sie mindestens einen und bis zu fünf Ports mit Nummer an
    • Geben Sie ALL an, um Traffic an allen Ports weiterzuleiten

Option 1 implementieren:

So implementieren Sie diese Lösung:

  1. Erstellen Sie eine Instanzvorlage für Ihre HAProxy-Server zur Weiterleitung der Anfragen:

    gcloud compute instance-templates create haproxy \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
    sudo apt-get install -y haproxy
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    service haproxy restart"
    
  2. Erstellen Sie eine zonale Instanzgruppe anhand der Instanzvorlagen mit der statischen Größe 2. Fügen Sie den Instanzen mithilfe der zuvor generierten Systemdiagnose eine Richtlinie zur automatischen Reparatur hinzu:

    gcloud compute instance-groups managed create haproxy \
        --template haproxy --size 2 --zone us-central1-f
    
    gcloud compute instance-groups managed update \
        haproxy --health-check simple-check --zone us-central1-f
    
  3. Fügen Sie den HAProxy-Servern mithilfe einer Systemdiagnose einen internen TCP/UDP-Load-Balancer hinzu.

    gcloud compute backend-services create haproxy-lb \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks simple-check \
        --protocol tcp
    gcloud compute backend-services add-backend haproxy-lb\
        --instance-group haproxy \
        --instance-group-zone us-central1-f \
        --region us-central1
    
    gcloud compute forwarding-rules create haproxy-rule \
        --load-balancing-scheme internal \
        --ports 80 \
        --network ip-failover \
        --region us-central1 \
        --address 10.128.1.1 \
        --backend-service haproxy-lb
    
  4. Testen Sie, ob Sie den HAProxy durch internes TCP/UDP-Load-Balancing erreichen können:

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.128.1.1
    <!DOCTYPE html> [...]
    username@testing:~$ exit

Nach dem Löschen einer der HAProxy-Instanzen über die Konsole oder dem Beenden des HAProxy-Prozesses auf einer der Instanzen ist curl nach einer kurzen Failover-Zeit weiterhin erfolgreich.

Option 2: Einzelne verwaltete Instanz

Abhängig von den Anforderungen an die Wiederherstellungszeit ist die Migration mit einer einzelnen VM-Instanz möglicherweise eine funktionsfähige Compute Engine-Option, selbst wenn mehrere Server lokal verwendet wurden. Dies liegt daran, dass Sie innerhalb von Minuten eine neue Compute Engine-Instanz starten können, während lokale Fehler normalerweise Stunden oder gar Tage in Anspruch nehmen.

Option 2: Einzelne verwaltete Instanz

Option 2 im Vergleich zu Option 1: Internes TCP/UDP-Load-Balancing

Option 2 hat im Vergleich zu Option 1 große Vor- und Nachteile.

Vorteile:

  • Trafficverteilung

    Da es nur eine Instanz gibt, trifft der gesamte Traffic auf eine einzelne Instanz, ähnlich wie bei einem lokalen Master-Slave-Szenario.

  • Kosteneinsparungen

    Mit der Verwendung einer einzelnen VM-Instanz anstelle von zwei Instanzen können die Kosten der Implementierung um die Hälfte reduziert werden.

  • Einfachheit

    Diese Lösung ist einfach und ohne großen Aufwand zu implementieren.

Nachteile:

  • Failover-Zeit

    Nachdem die Systemdiagnose einen Maschinenausfall erkannt hat, dauert das Löschen und Wiederherstellen der fehlgeschlagenen Instanz mindestens eine Minute, häufig jedoch erheblich länger. Dieser Prozess ist viel langsamer als das Entfernen einer Instanz aus dem internen TCP/UDP-Load-Balancing.

  • Reaktion auf Zonenausfälle

    Eine verwaltete Instanzgruppe der Größe 1 überlebt keinen Zonenausfall. Um auf Zonenausfälle reagieren zu können, fügen Sie eine Stackdriver Monitoring-Warnung hinzu, wenn der Dienst ausfällt, und erstellen Sie bei Zonenausfall manuell eine Instanzgruppe in einer anderen Zone.

Option 2 implementieren

So installieren Sie Option 2:

  1. Erstellen Sie eine Instanzvorlage für die HAProxy-VM-Instanz:

    gcloud compute instance-templates create haproxy-single \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
    sudo apt-get install -y haproxy
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    service haproxy restart"
    
  2. Erstellen Sie eine verwaltete Instanzgruppe der Größe 1 für die HAProxy-VM-Instanz und fügen Sie eine Richtlinie zur automatischen Reparatur hinzu:

    gcloud compute instance-groups managed create haproxy-single \
        --template haproxy-single --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed update \
        haproxy-single --health-check simple-check --zone us-central1-f
    
  3. Testen Sie, ob Sie den HAProxy über die IP-Adresse des internen TCP/UDP-Load-Balancing erreichen können:

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ instance=$(gcloud compute instances list |awk '$1 ~ /^haproxy-single/ { print $1 }')
    
    username@testing:~$ curl $instance
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    Wenn Sie die HAProxy-Instanz löschen oder den HAProxy-Instanzprozess über die Konsole beenden, wird die Instanz automatisch nach einer Verzögerung mit derselben IP-Adresse und demselben Instanznamen wiederhergestellt.

Option 3: Failover mit verschiedenen Prioritätsrouten

Zwei Compute Engine-Routen mit unterschiedlichen Prioritäten stellen eine weitere Möglichkeit dar, um Traffic-Failover zwischen zwei Instanzen zu ermöglichen, wenn das interne TCP/UDP-Load-Balancing nicht verwendet werden kann.

In diesem Abschnitt erstellen Sie zwei VM-Instanzen und platzieren diese in einer verwalteten Instanzgruppe mit automatischer Reparatur und der statischen Größe 1, wodurch das System automatisch repariert werden kann.

Aktivieren Sie die IP-Weiterleitung auf beiden Instanzen. Nachdem Sie die Instanzen erstellt haben, leiten Sie den gesamten Floating-IP-Traffic an diese beiden Instanzen um. Dazu richten Sie zwei Routen mit unterschiedlichen Prioritäten für die Verarbeitung des Traffics ein.

Option 3: Unterschiedliche Prioritätsrouten

Option 3 im Vergleich zu Option 1: Internes TCP/UDP-Load-Balancing

Mithilfe der Option 3 können Sie Anwendungsfälle migrieren, in denen das interne TCP/UDP-Load-Balancing nicht einfach verwendet werden kann. Diese Option hat folgende Vorteile:

  • Trafficverteilung

    Der Traffic fließt immer an die VM-Instanz mit der niedrigsten Priorität. Wenn diese VM-Instanz nicht verfügbar ist, verwendet der Traffic die nächstbeste Route. Diese Architektur ähnelt einer lokalen Umgebung, in der zu einem bestimmten Zeitpunkt nur ein (1) Server aktiv ist.

  • Protokolle

    Das interne TCP/UDP-Load-Balancing wird nur auf einen bestimmten Satz von Protokollen oder Ports angewendet, während Routen auf den gesamten Traffic zu einem bestimmten Ziel angewendet werden.

  • Regionalität

    Internes TCP/UDP-Load-Balancing ist nur innerhalb einer Region verfügbar, Routen hingegen können weltweit erstellt werden.

Option 3 ist im Vergleich zu Option 1, die internes TCP/UDP-Load-Balancing verwendet, mit Nachteilen verbunden.

  • Systemdiagnose

    Mit Option 3 wird keiner der beiden Routen eine Systemdiagnose hinzugefügt. Routen werden unabhängig vom Systemstatus der zugrunde liegenden VM-Dienste verwendet. Der Traffic wird auch dann an Instanzen weitergeleitet, wenn der Dienst fehlerhaft ist. Wenn den Instanzen eine Richtlinie zur automatischen Reparatur hinzugefügt wird, werden sie gelöscht, nachdem der Systemstatus eine bestimmte Zeit fehlerhaft war. Nach einem Neustart dieser Instanzen wird der Traffic jedoch fortgesetzt, selbst vor Aktivierung des Dienstes. Dies kann zu potenziellen Servicefehlern führen, wenn fehlerhafte Instanzen weiterhin Traffic bedienen oder ein Neustart ausgeführt wird.

  • Failover-Zeit

    Nachdem Sie eine VM-Instanz gelöscht oder beendet haben, wird die Route automatisch zurückgezogen. Aufgrund fehlender Systemdiagnosen wird die Route jedoch solange weiterhin verwendet, wie die Instanz verfügbar ist. Darüber hinaus nimmt das Beenden der Instanz Zeit in Anspruch, sodass die Failover-Zeit erheblich höher ist als bei Verwendung des internen TCP/UDP-Load-Balancing.

  • Auswahl einer Floating-IP-Adresse

    Es können nur Routen zu IP-Adressen festgelegt werden, die nicht Teil eines Subnetzes sind. Die ausgewählte Floating-IP-Adresse muss außerhalb aller vorhandenen Subnetzbereiche liegen.

  • VPC-Netzwerk-Peering

    VM-Instanzen können nur Routen aus ihrem eigenen VPC-Netzwerk und keine Routen aus Peering-VPC-Netzwerken verwenden.

Option 3 implementieren

Bei der Implementierung verwenden Sie die IP-Adresse 10.191.1.1, die sich außerhalb aller aktiven Subnetze im Netzwerk ip-failover befindet. Führen Sie die folgenden Schritte aus:

  1. Erstellen Sie eine Instanzvorlage für Ihre HAProxy-Server zur Weiterleitung der Anfragen:

    gcloud compute instance-templates create haproxy-route \
        --machine-type n1-standard-1 --network ip-failover \
        --metadata "startup-script=
    apt-get update
    apt-get install -y haproxy
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    cat << EOF >> /etc/network/interfaces
    auto eth0:0
    iface eth0:0 inet static
        address 10.191.1.1
        netmask 255.255.255.255
    EOF
    service haproxy restart
    service networking restart" --can-ip-forward
    
  2. Erstellen Sie zwei verwaltete Instanzgruppen der Größe 1 für die HAProxy-VM-Instanz und fügen Sie eine Richtlinie zur automatischen Reparatur hinzu:

    gcloud compute instance-groups managed create haproxy-r1 \
        --template haproxy-route --size 1 --zone us-central1-f
    
    gcloud compute instance-groups managed update \
        haproxy-r1 --health-check simple-check --zone us-central1-f
    
    gcloud compute instance-groups managed create haproxy-r2 \
        --template haproxy-route --size 1 --zone us-central1-b
    
    gcloud compute instance-groups managed update \
        haproxy-r2 --health-check simple-check --zone us-central1-b
    
  3. Erstellen Sie eine primäre und sekundäre Route zu diesen VM-Instanzen, nachdem sie gestartet wurden:

    haproxy1=$(gcloud compute instances list |awk '$1 \
        ~ /^haproxy-r1/ { print $1 }')
        #save the instance name of the first HAproxy instance
    
    haproxy2=$(gcloud compute instances list |awk '$1 \
        ~ /^haproxy-r2/ { print $1 }')
        #save the instance name of the second HAproxy instance
    
    gcloud compute routes create haproxy-route1 \
        --destination-range 10.191.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-f \
        --next-hop-instance $haproxy1
    
    gcloud compute routes create haproxy-route2 \
        --destination-range 10.191.1.1/32 --network ip-failover \
        --priority 600 --next-hop-instance-zone us-central1-b \
        --next-hop-instance $haproxy2
    
  4. Testen Sie, ob Sie den HAProxy über die Route erreichen können:

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.191.1.1
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    Wenn Sie die primäre HAProxy-Instanz über die Konsole löschen, wird die Route zur sekundären Instanz verwendet, sobald die Instanz vollständig ausfällt.

Option 4: Failover mit API-Aufrufen für Routen

Wie auch Option 3 verwendet Option 4 Routen, unterscheidet sich jedoch in wichtigen Punkten. Anstelle der automatischen Reparatur und der Neuerstellung von Instanzen verwenden Keepalived oder andere Skripts API-Aufrufe, um eine Route zu einer neuen intakten Instanz hinzuzufügen oder eine Route aus einer fehlerhaften Instanz zu entfernen. Dieser Ansatz ist in Situationen sinnvoll, in denen Sie keine Compute Engine-Systemdiagnosen zum Erfassen des Systemstatus verwenden oder bestimmen können, welche virtuelle Maschine primär ist. Jede Anwendungslogik kann eine dynamische Neuprogrammierung von Routen auslösen.

Die Verwendung von API-Aufrufen für Routen als Failover-Methode ist auch nützlich, wenn Anwendungsfehler manuell untersucht und Instanzen manuell wieder online geschaltet werden. Da VMs jedoch in der Lage sein müssen, alle Fehler zu protokollieren und automatisch ersetzt zu werden, sobald sie fehlerfrei sind, sollten Fehler in Compute Engine nicht manuell untersucht werden.

Option 4: Failover mit API-Aufrufen für Routen

Unterschiede in Option 4 im Vergleich: Internes TCP/UDP-Load-Balancing

Im Vergleich zur Verwendung des internen TCP/UDP-Load-Balancing bietet Option 4 folgende Vorteile:

  • Trafficverteilung

    Wie bei den Optionen 2 und 3 trifft der Traffic auf jeweils nur eine VM-Instanz.

  • Keine Abhängigkeit von Compute Engine-Systemdiagnosen

    Failover können von jeder benutzerdefinierten Anwendungslogik ausgelöst werden. Mit Option 4 verwenden Sie ein Skript zum Verwalten von Keepalived-Reaktionen auf Kommunikationsfehler zwischen primären und sekundären HAProxys. Dies ist die einzige Option, die funktioniert, wenn Sie keine Compute Engine-Systemdiagnosen verwenden können oder möchten.

Option 4 hat auch bedeutende Nachteile:

  • Komplexität

    Diese Option muss mithilfe der Compute Engine API oder mithilfe von gcloud-Aufrufen kundenspezifisch angepasst werden, um eine Route zurückziehen und eine neue Route mithilfe der Compute Engine API erstellen zu können. Diese Logik auf zuverlässige Weise aufzubauen, ist in der Regel eine komplexe Aufgabe.

  • Failover-Zeit

    Da mindestens zwei Compute Engine API-Aufrufe von einem benutzerdefinierten Skript erforderlich sind, um eine Route zurückzuziehen und eine neue Route auf Compute Engine zu erstellen, ist das Failover etwas langsamer als bei einem internen Lastenausgleichsmodul.

  • Auswahl einer Floating-IP-Adresse

    Es können nur Routen zu IP-Adressen festgelegt werden, die nicht Teil eines Subnetzes sind. Die ausgewählten Floating-IP-Adressen müssen außerhalb aller vorhandenen Subnetzbereiche liegen.

  • VPC-Netzwerk-Peering

    VM-Instanzen können nur Routen aus ihrem eigenen VPC-Netzwerk und keine Routen aus Peering-VPC-Netzwerken verwenden.

Option 4 implementieren

Diese Implementierung verwendet die IP-Adresse 10.190.1.1, die sich außerhalb aller aktiven Subnetze im ip-failover-Netzwerk befindet. Die Route für diese Adresse wird automatisch von Keepalived erstellt und gelöscht.

Zuerst erstellen Sie zwei HAProxy-Instanzen mit HAProxy und Keepalived unter Verwendung von statischen internen IP-Adressen für beide Instanzen. Sie müssen auch die IP-Weiterleitung aktivieren, um die Route beenden zu können, und Sie benötigen Zugriff auf die Compute Engine API. Der Einfachheit halber verwenden Sie in diesem Beispiel keine Instanzvorlagen und -gruppen.

So erstellen Sie Option 4:

  1. Erstellen Sie die primäre Instanz mit der statischen IP-Adresse 10.128.4.100:

    gcloud compute instances create haproxy-a \
        --machine-type n1-standard-1 --network ip-failover \
        --can-ip-forward --private-network-ip=10.128.4.100 \
        --scopes compute-rw --zone us-central1-f \
        --metadata 'startup-script=
    apt-get update
    apt-get install -y haproxy keepalived
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    cat << EOF >> /etc/network/interfaces
    auto eth0:0
    iface eth0:0 inet static
        address 10.190.1.1
        netmask 255.255.255.255
    EOF
    cat << EOF >> /etc/keepalived/keepalived.conf
    vrrp_script haproxy {
        script "/bin/pidof haproxy"
        interval 2
    }
    
    vrrp_instance floating_ip {
        state MASTER
        interface eth0
        track_script {
            haproxy
        }
        unicast_src_ip 10.128.4.100
        unicast_peer {
            10.128.4.200
        }
        virtual_router_id 50
        priority 100
        authentication {
            auth_type PASS
            auth_pass yourpassword
        }
        notify_master /etc/keepalived/takeover.sh
    }
    EOF
    cat << EOF >> /etc/keepalived/takeover.sh
    #!/bin/bash
    gcloud compute routes delete floating --quiet
    gcloud compute routes create floating \
        --destination-range 10.190.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-f \
        --next-hop-instance haproxy-a --quiet
    EOF
    chmod +x /etc/keepalived/takeover.sh
    service haproxy restart
    service networking restart
    service keepalived start'
    
  2. Erstellen Sie die sekundäre Instanz mit der statischen IP-Adresse 10.128.4.200:

    gcloud compute instances create haproxy-b \
        --machine-type n1-standard-1 --network ip-failover \
        --can-ip-forward --private-network-ip=10.128.4.200 \
        --scopes compute-rw --zone us-central1-c \
        --metadata 'startup-script=
    apt-get update
    apt-get install -y haproxy keepalived
    cat << EOF >> /etc/haproxy/haproxy.cfg
    frontend www
        bind :80
        option http-server-close
        default_backend web-backend
    backend web-backend
        server web-1 10.128.2.2:80 check
    EOF
    cat << EOF >> /etc/network/interfaces
    auto eth0:0
    iface eth0:0 inet static
        address 10.190.1.1
        netmask 255.255.255.255
    EOF
    cat << EOF >> /etc/keepalived/keepalived.conf
    vrrp_script haproxy {
        script "/bin/pidof haproxy"
        interval 2
    }
    
    vrrp_instance floating_ip {
        state BACKUP
        interface eth0
        track_script {
            haproxy
        }
        unicast_src_ip 10.128.4.200
        unicast_peer {
            10.128.4.100
        }
        virtual_router_id 50
        priority 50
        authentication {
            auth_type PASS
            auth_pass yourpassword
        }
        notify_master /etc/keepalived/takeover.sh
    }
    EOF
    cat << EOF >> /etc/keepalived/takeover.sh
    #!/bin/bash
    gcloud compute routes delete floating --quiet
    gcloud compute routes create floating \
        --destination-range 10.190.1.1/32 --network ip-failover \
        --priority 500 --next-hop-instance-zone us-central1-c \
        --next-hop-instance haproxy-b --quiet
    EOF
    chmod +x /etc/keepalived/takeover.sh
    service haproxy restart
    service networking restart
    service keepalived start'
    
  3. Testen Sie, ob Sie den HAProxy über die Route erreichen können:

    gcloud compute ssh testing --zone us-central1-f
    
    username@testing:~$ curl 10.190.1.1
    <!DOCTYPE html> [...]
    username@testing:~$ exit

    Wenn HAProxy auf der Instanz haproxy-a beendet wird oder die Instanz blockiert wird, fehlen VRRP-Herzschläge und die haproxy-b-Instanz ruft das Skript takeover.sh auf. Dieses Skript verschiebt die Route für 10.190.1.1 von haproxy-a zu haproxy-b und der Test funktioniert weiterhin.

Auswahl der besten Option für Ihren Anwendungsfall

In den Anwendungsbeispielen, in denen eine Reihe von HAProxy-Knoten komplexe Routingentscheidungen treffen, lautet die bevorzugte Compute Engine-Implementierung Option 1: Internes TCP/UDP-Load-Balancing. Dies liegt daran, dass die VM-Instanzen zustandslos sind und somit mühelos in einem Aktiv-Aktiv-Szenario eingesetzt werden können. Darüber hinaus können Compute Engine-Systemdiagnosen verwendet werden. In anderen Anwendungsfällen ist Option 1 möglicherweise nicht die beste Option.

Zusätzlich zu den zuvor aufgeführten Vor- und Nachteilen für jede Option kann der folgende Entscheidungsbaum Ihnen bei der Auswahl eines Implementierungsschemas helfen.

Entscheidungsbaum

Hochverfügbare und zuverlässige Anwendungen werden in Compute Engine am besten mit horizontal skalierenden Architekturen implementiert, um die Auswirkungen eines einzelnen Knotenausfalls zu minimieren. Die Migration eines typischen lokalen Szenarios, z. B. zweier Server mit Floating-IP-Adressen, stellt eine Herausforderung dar, da dieses Szenario in Compute Engine nicht dupliziert werden kann. Wie bereits erwähnt funktioniert das Verschieben von IP-Adressen zwischen verschiedenen Computern in Sekundenbruchteilen mithilfe einer Gratuitous-ARP nicht. Virtuelle Routing-Infrastrukturen sind hierfür ungeeignet.

Durch das interne TCP/UDP-Load-Balancing können viele Anwendungsfälle einfach und zuverlässig an Compute Engine übertragen werden. In Fällen, in denen Sie kein internes Lastenausgleichsmodul verwenden können, können Sie mehrere andere Optionen implementieren, die keine komplexen Overlay-Routingmechanismen erfordern.

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Compute Engine-Dokumentation