Failover-Cloud-Szenario Teil 2

Bei diesem Text handelt es sich um eine maschinell erstellte Übersetzung. Eine überarbeitete Version ist in Planung.

In Teil 1, diskutierten wir mit minimalen Ressourcen, um ein Load Balancing und Failover Cloud Szenario mit Keepalived zu erstellen. In diesem Blogbeitrag möchte ich auf ein komplexeres Setup eingehen, das die Vorteile der Keepalived-Funktionen bei der Verwendung von NAT und LVS besser nutzt.

Um das gewünschte Setup zu erreichen, erstellen wir zwei Gateway-Server (für doppelte Redundanz) in zwei verschiedenen Verfügbarkeitszonen. Als Betriebssystem werden wir Debian 7 verwenden, aber Sie können auch eine andere Linux-Distribution verwenden.

Das Grundkonzept

In komplexeren, gesicherten Umgebungen ist es üblich (und empfohlen), den eigentlichen Server zu betreiben, ohne ihn dem öffentlichen Internet auszusetzen, und über ein gemeinsames Gateway (z.B. eine DMZ) zu veröffentlichen. Das Gateway wird NAT-ing-fähig sein, um den Zugriff auf die Systeme im privaten Netzwerk zu ermöglichen, und betreibt die gewünschten Dienste über DNAT. Verschiedene Gateway-Sicherheitskonfigurationen können mit unterschiedlichen iptables-Regeln implementiert werden.

Im folgenden Beispiel habe ich ein einfaches Setup (nicht redundant) erstellt, nur um die wichtigsten architektonischen Unterschiede zu dem im Detail vorgestellten HA-Setup in diesem Artikel zu betonen. Nehmen wir an, wir haben verschiedene Dienste, die auf einzelnen virtuellen Maschinen gehostet werden, die in einem privaten Netzwerk sitzen, wie folgt:

  • Ein Webserver mit der IP-Adresse 10.14.58.11
  • Ein E-Mail-Server mit der IP-Adresse 10.14.58.17
  • Ein zentraler Management Server (SSH) mit der IP-Adresse 10.14.58.14
  • Die öffentliche IP-Adresse des Gateways lautet 162.254.27.24.26.
  • Die interne IP des Gateways lautet 10.14.58.15.

In dieser Konfiguration wird die interne IP des Gateways (als Standard-Gateway eingestellt) auf den Netzwerkschnittstellen des Servers im privaten Netzwerk registriert. Wir leiten die notwendigen Netzwerkanforderungen mit den folgenden iptables-Regeln um:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j DNAT –to 10.14.58.11:80
iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 25 -j DNAT –to 10.14.58.17:25
iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 22 -j DNAT –to 10.14.58.14:22 

HA-Einrichtung

Um sicherzustellen, dass das obige Setup hochverfügbar ist, müssen die virtuellen Maschinen verschiedenen Verfügbarkeitszonen zugeordnet werden - daher benötigen wir in jeder Verfügbarkeitszone ein Gateway, einen Webserver und einen SMTP-Server. In dieser Situation, wenn ein Server in einer der beiden Zonen ausfällt, müssen die anderen Server bereit sein, den Schlupf zu beseitigen. Der Management Server ist nicht auf Hochverfügbarkeit ausgelegt und dient als Administrationswerkzeug. Sie ist nicht Bestandteil der erbrachten Leistung. Alternativ können Sie auch die im Data Center Designer verfügbare Remote Console verwenden, die den Zugriff auf alle Server zu jedem Zeitpunkt (unabhängig vom Status) ermöglicht. Wenn der Management Server ausfällt, ist es eine schnelle Arbeit, ihn neu zu erstellen oder ihn aus einem Snapshot wieder einzurichten.

Das obige Diagramm mag etwas komplizierter erscheinen, als Sie vielleicht erwartet haben, aber keine Sorge - ich werde Sie Schritt für Schritt durch den Prozess führen. Wenn Sie möchten, dass Ihr Betrieb hochverfügbar ist, müssen Sie absolut sicher sein, dass die vom jeweiligen Dienst bereitgestellten Daten für alle Server synchron sind.

Hinweis: Die Konfiguration der Datensynchronisation für die bereitgestellten Dienste ist in diesem Blogbeitrag nicht enthalten.

HA-Setup - DCD-Konfiguration

Das DCD-Setup, das das obige Diagramm beschreibt, ist in unserem Data Center Designer wie folgt konfiguriert:

 

Es gibt zwei wichtige Aspekte in dieser Konfiguration zu beachten:

Für die hochverfügbaren Komponenten (in unserem Beispiel Webserver 1 und Webserver2) müssen die Verfügbarkeitszonen vor der Bereitstellung des Setups zugeordnet werden; (Zone1 oder Zone2). Sie können auch jederzeit geändert werden.

    • Eine zusätzliche, reservierte IP-Adresse wird benötigt, um die öffentliche Netzwerkschnittstelle eines der beiden Gateway-Systeme anzusprechen. Die erforderlichen offenen Dienste werden über dieses IP veröffentlicht.

     

    Im nächsten Schritt wird eine IP-Failover-Gruppe für die virtuelle IP-Adresse des öffentlichen LANs erstellt.
    Wählen Sie in DCD das öffentliche LAN aus und gehen Sie zu Inspektor > IP Failover.

    Klicken Sie auf Create Failover Group, um das Dialogfenster zu öffnen, in dem Sie ein IP-Failover in DCD einrichten können.

    Wählen Sie aus dem Dropdown-Menü IP die virtuelle IP aus, für die Sie einen Failover erstellen. Wählen Sie alle NICs aus, die diese IP-Adresse verwenden dürfen. Was unsere Beispielkonfiguration betrifft, so umfasst dies alle im öffentlichen LAN verfügbaren NICs. Definieren Sie den Masterknoten Ihres Failover-Setups, indem Sie den Master-Radio-Button für das entsprechende NIC aktivieren. Wenn alles gesetzt ist, klicken Sie auf Create Failover Group und stellen Sie Ihre Änderungen bereit, um die Failover Group zu erstellen.

    HA-Setup mit Keepalived

    Die Kernkomponente für die HA-Funktionalität ist Keepalived.

    Was ist Keepalived? Laut ihrer Website: "Keepalived ist eine in C geschriebene Routing-Software. Das Hauptziel dieses Projekts ist es, einfache und robuste Einrichtungen für den Lastausgleich und die Hochverfügbarkeit für Linux-Systeme und Linux-basierte Infrastrukturen bereitzustellen. Keepalived implementiert eine Reihe von Checkern, um den Load Balanced Server Pool dynamisch und adaptiv zu warten und zu verwalten, je nach Zustand. Darüber hinaus implementiert Keepalived eine Reihe von Hooks für den VRRP-Zustandsautomaten, die Low-Level- und Hochgeschwindigkeitsprotokollinteraktionen ermöglichen. Keepalived Frameworks können unabhängig oder zusammen verwendet werden, um robuste Infrastrukturen bereitzustellen."

    Mit Keepalived können Sie:

    • Richten Sie einen oder mehrere redundante Router (Gateways) über VRRP ein.
    • Konfigurieren Sie einen oder mehrere Pools basierend auf den umfangreichen Parametern, die auf den entsprechenden Backends geroutet werden, für eine gezielte Lastverteilung.

    Gateway-Konfiguration

    In diesem Schritt werden wir ein Gateway mit Keepalived und VRRP einrichten. Alle folgenden Konfigurationen sind für die beiden Gateway-Systeme (VRRP-Master und VRRP-Slave) sehr ähnlich und identisch mit denen, die im letzten Blogbeitrag erstellt wurden, sofern nicht anders angegeben.

    • System-Updates und Paket-Installation

    Zunächst wird das System aktualisiert und die notwendigen, zusätzlichen Softwarekomponenten installiert. Keepalived wird in diesem Schritt installiert. Die zusätzliche Installation von lpvsadm ist die Vorbereitung für den weiteren Lastausgleich.

    • System-Updates mit apt-get update und apt-get upgrade
    • Keepalived installieren: apt-get install keepalived installieren
    • Installation von ipvsadm: apt-get installation von ipvsadm

    Anpassung der Systemkonfiguration

    • Es wird empfohlen, eindeutige Hostnamen für Ihre Systeme anzugeben (z.B. vrrp-master und vrrp-slave).
    • Die IP-Weiterleitung muss eingeschaltet sein. Die folgenden Informationen müssen in dieser Datei /etc/sysctl.conf angepasst werden:
      # Entkommentieren Sie die nächste Zeile, um die Paketweiterleitung für IPv4 zu aktivieren.
      net.ipv4.ip_forward=1

      Überprüfen Sie die Konfigurationsänderungen mit sysctl -p.
    • Die iptables-basierte NAT-Regel muss implementiert werden, die bei jedem Systemstart gestartet werden muss. Zu diesem Zweck erstellen wir die folgende Datei: /etc/iptables.rules:
    *nat
    :PREROUTING ACCEPT [50:2000]
    :INPUT ACCEPT [0:0]
    :OUTPUT ACCEPT [1:120]
    :POSTROUTING ACCEPT [0:0]
    -A POSTROUTING -o eth0 -j MASQUERADE
    COMMIT

    Dies kann mit einem von Ihnen bevorzugten Editor erledigt werden. Alternativ können Sie die Regel auch mit aktivieren:

    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

    Am Ende speichern wir die Konfiguration von iptables mit iptables-save > /etc/iptables.rules. Um sicher zu sein, dass diese Regel bei jedem Start beginnt, fügen wir hinzu:

    #!/bin/bash/sbin/iptables-restore < /etc/iptables.rules to /etc/network/if-pre-up.d/iptables
    • Aufrechterhaltung der VRRP-Konfiguration

    Ziel dieser Konfiguration ist es, eine VRRP-Routing-Gruppe zu erstellen. Diese Routinggruppe umfasst zwei VRRP-Instanzen. Eine Instanz für die Virtual Public IP Address (162.254.27.26) und eine Instanz für die Virtual Private Gateway IP Adresse (10.14.58.254).

    Alle folgenden Konfigurationen sind in dieser Datei vorgenommen worden: /etc/keepived/keepalived/keepalived.conf.

    Die Änderungen, die Sie am Backup-System vornehmen müssen, werden im folgenden Code als Kommentare zur Verfügung gestellt. Die globale Keepalived-Konfiguration muss mindestens einen Eintrag pro eindeutigem Host (lvs_id) enthalten:

    !
    ! Global Config for keepalived
    !
    global_defs {
       # uncomment the next line for the Master System
       lvs_id LVS_MASTER
       # uncomment the next line for the Backup System
       # lvs_id LVS_BACKUP
    }

    Um die gewünschte Konfiguration mit der virtuellen, öffentlichen IP und einer virtuellen, privaten Gateway-IP zu erreichen, konfigurieren wir die VRRP-Gruppe VGROUP1.

    • Die erste VRRP-Instanz VI_PUBLIC_1 wird der virtuellen, offenen IP bei eth0 zugeordnet.
    • Die zweite VRRP-Instanz VI_GATEWAY_1 ist der Virtual Private Gateway IP an eth1 zugeordnet.

    Der folgende Code muss zu Ihrer Keepalived-Konfiguration hinzugefügt werden:

    !
    ! VRRP Config for keepalived
    !
    ! define a vrrp group
    vrrp_sync_group VGROUP1 {
       group {
         VI_PUBLIC_1
         VI_GATEWAY_1
       }
    } 
    ! vrrp instance for the public interface
    vrrp_instance VI_PUBLIC_1 {
       ! uncomment the next line for the Master System
       state MASTER
       ! uncomment the next line for the Backup System
       ! state BACKUP
       interface eth0
       lvs_sync_daemon_inteface eth0
       virtual_router_id 51
       ! uncomment the next line for the Master System
       priority 100
       ! uncomment the next line for the Backup System
       ! priority 50
       advert_int 1
       authentication {
           auth_type PASS
           auth_pass MySuperSecretPassword
       }
       virtual_ipaddress {
           162.254.27.26
       }
    }
    ! vrrp instance for the internal gateway interface
    vrrp_instance VI_GATEWAY_1 {
       ! uncomment the next line for the Master System
       state MASTER
       ! uncomment the next line for the Backup System
       ! state BACKUP
       interface eth1
       lvs_sync_daemon_inteface eth1
       virtual_router_id 52
       ! uncomment the next line for the Master System
       priority 100
       ! uncomment the next line for the Backup System
       ! priority 50
       advert_int 1
       authentication {
           auth_type PASS
           auth_pass MySuperSecretPassword
       }
       virtual_ipaddress {
           10.14.58.254
       }
    }

    Damit ist die VRRP-Gateway-Konfiguration abgeschlossen.

    Keepalived kann auf beiden Systemen mit /etc/init.d/keepalived start gestartet werden. Das Mastersystem wird dann automatisch durch das Slave-System ersetzt. Dies kann durch Stoppen des Mastersystems überprüft werden, um zu sehen, was passiert. Die Statusmeldungen finden Sie im Debian-System unter /var/log/syslog (für weitere Details lesen Sie bitte meinen vorherigen Beitrag hier).

    Der Status der IP-Konfiguration kann über die IP-Adressliste überprüft werden. Beide virtuellen IP-Adressen sind nun auf den spezifischen Netzwerkschnittstellen des Mastersystems aktiv.

    root@vrrp-master:~# ip addr list
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
       link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
       inet 127.0.0.1/8 scope host lo
       inet6 ::1/128 scope host
           valid_lft forever preferred_lft forever
       inet6 ::1/128 scope host
           valid_lft forever preferred_lft forever
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 64000 qdisc pfifo_fast state UP qlen 1000
       link/ether 02:01:1c:32:1d:28 brd ff:ff:ff:ff:ff:ff
       inet 162.254.27.24/32 brd 162.254.27.24 scope global eth0
       inet 162.254.27.26/32 scope global eth0
       inet6 fe80::1:1cff:fe32:1d28/64 scope link
           valid_lft forever preferred_lft forever
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 64000 qdisc pfifo_fast state UP qlen 1000
       link/ether 02:01:4d:2d:0a:c5 brd ff:ff:ff:ff:ff:ff
       inet 10.14.58.15/24 brd 10.14.58.255 scope global eth1
       inet 10.14.58.254/32 brd 10.14.58.255 scope global eth1
       inet6 fe80::1:4dff:fe2d:ac5/64 scope link
           valid_lft forever preferred_lft forever
    • HA Setup - Das Backend-System

    Eine zwingende Voraussetzung für eine einwandfrei funktionierende Lastausgleichsanordnung mit Keepalivd und IPVS ist, dass Ihr System das HA-Gateway IP (10.14.58.254) als Standard-Gateway verwendet. Die Netzwerkschnittstellen werden zu diesem Zweck manuell in /etc/ network/interfaces konfiguriert. Als Beispiel ist hier die Schnittstellenkonfiguration des Webservers 1 zu sehen:

    auto eth0
    iface eth0 inet static
           address 10.14.58.11
           netmask 255.255.255.0
           gateway 10.14.58.254
           dns-nameservers 69.194.131.41
           pre-up /sbin/ifconfig $IFACE mtu 64000
    • Wenn diese Netzwerkkonfiguration aktiv ist, verfügen Ihre entsprechenden Systeme über einen Internetzugang. System-Updates und andere notwendige Anwendungen können nun installiert werden. In unserem Fall können wir mit der Installation von Apache auf den Webservern (apt-get install apache2) und Postfix auf den Mailserver (apt-get install postfix) fortfahren.

    • HA-Setup - Lastausgleich

    Die Lastausgleichskomponenten werden von Keepalived gesteuert. Es steuert die Lastausgleichskonfiguration von IPVS. Der Konfigurationscode von keepalived.conf für den Lastausgleich besteht aus der Definition eines virtuellen Servers (der sich mit der virtuellen öffentlichen IP verbindet) sowie der Definition der realen Server im privaten Netzwerk (bis zu N). Mehr als ein Load Balancer kann in einer keepalived.conf konfiguriert werden. Je nach verwendetem Anwendungsprotokoll gibt es viele verschiedene Methoden, um den Betriebszustand der realen Server zu überprüfen. Wird der aktuelle Status eines realen Servers nicht mehr als verfügbar angesehen, werden keine weiteren Anfragen an ihn weitergeleitet, bis Probleme behoben sind.

    SMTP Lastausgleicher

    Der SMTP-Lastausgleich sollte Anfragen von der öffentlichen IP 162.254.27.26 auf dem TCP-Port 25 (virtual_server) entgegennehmen und beide Server (real_server) 10.14.58.17 und 10.14.58.1 teilen sich diese im Round Robin-Verfahren (lb_algo rr) im privaten Netz (lb_kind_NAT). Der Betriebsstatus des realen Servers wird getestet, um festzustellen, ob er sich mit Port 25 verbindet.

    Um diese Konfiguration zu erstellen, wird der folgende Code in /etc/keepived/keepived/keepived.conf hinzugefügt (identisch auf beiden Gateway-Systemen).

    virtual_server 162.254.27.26 25 {
       delay_loop 6
       lb_algo rr
       lb_kind NAT
       nat_mask 255.255.255.0
       protocol TCP
       
       real_server 10.14.58.17 25
        {
            weight 1
            TCP_CHECK {
                connect_timeout 3
                connect_port 25
             }
         }
    
       real_server 10.14.58.12 25
       {
            weight 1
            TCP_CHECK {
                 connect_timeout 3 
                 connect_port 25
            }
        }
    }
    • Der Load Balancer ist nach dem Neustart des Keepalived aktiv. Der Status der IPVS-Lastausgleicher kann mit ipvsadm -l überprüft werden.

    root@vrrp-master:~# ipvsadm -l
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags
     -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
    TCP ip162.254.27.24.26.pbiaas.com:sm rr
     style="font-family: Georgia, 'Times New Roman', 'Bitstream Charter', Times, serif; font-size: 13px; line-height: 19px;">-> 10.14.58.17:smtp             Masq   1     0         0
    -> 10.14.58.12:smtp             Masq   1     0         0
    • HTTP-Lastausgleich

    • Der HTTP-Lastausgleich sollte Anfragen in sehr ähnlicher Weise von der öffentlichen IP 162.254.27.26 auf dem TCP-Port 80 (virtual_server) entgegennehmen, und beide Server (real_server) 10.14.58.11 und 10.14.58.13 sollten sie über die Round Robin-Methode (lb_algo rr) im privaten Netz (lb_kind_NAT) teilen. Der Betriebsstatus des realen Servers wird getestet, um festzustellen, ob er sich über HTTP-GET mit einer Test-URL verbindet. Dieser Test prüft nicht nur, ob ein HTTP-Aufruf an die URI möglich ist, sondern auch, ob der Hash-Wert des zurückgegebenen Dokuments korrekt ist - nicht der gespeicherte Hash-Wert - (d.h. das Dokument wurde geändert oder es liegt ein HTTP-Fehler vor). Es prüft, ob sie eine Verbindung zum Server erhalten können, andernfalls gilt der Server als defekt.

      Um den Hash-Wert zu erzeugen, verwenden wir den folgenden Befehl:

    genhash -s [real server IP] -p 80 –u [document to check]
    • In unserem Fall:

    root@vrrp-master:~# genhash -s 10.14.58.11 -p 80 -u /alive.txt
    MD5SUM = ea53b3baf477a283376779a3c1985085
    • Um diese Konfiguration zu erstellen, müssen wir den folgenden Code in /etc/keepalived/keepived.conf einfügen (identisch auf beiden Gateway-Systemen):

    virtual_server 162.254.27.26 80 {
       delay_loop 6
       lb_algo rr 
       lb_kind NAT
       nat_mask 255.255.255.0
       protocol TCP
    
       real_server 10.14.58.11 80
       {
          weight 1
          HTTP_GET {
            url {
               path /alive.txt
                   digest ea53b3baf477a283376779a3c1985085
               }
               connect_timeout 10
               connect_port 80
               nb_get_retry 3
               delay_before_retry 10
               }
        }
    
        real_server 10.14.58.13 80
        {
          weight 1
          HTTP_GET {
            url {
               path /alive.txt
                   digest 01bc6b572ba171d4d3bd89abe9cb9a4c
               }    
               connect_timeout 10
               connect_port 80
               nb_get_retry 3
               delay_before_retry 10
              }
          }
    }
    • Der konfigurierte Lastausgleich ist nach dem Neustart des Systems in Keepalived aktiv. Der Status des IPVS-Lastausgleichs kann dann mit ipvsadm -l überprüft werden.

    root@vrrp-master:~# ipvsadm -l
    IP Virtual Server version 1.2.1 (size=4096)
    Prot LocalAddress:Port Scheduler Flags
     -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
    TCP ip162.254.27.24.26.pbiaas.com:sm rr
     -> 10.14.58.17:smtp             Masq   1     0         0
     -> 10.14.58.12:smtp             Masq   1     0         0
    TCP ip 162.254.27.24.26.pbiaas.com:ht rr
     -> 10.14.58.11:http             Masq   1     0         0
     -> 10.14.58.13:http             Masq   1     0         0
    • Die beiden Load Balancer sind aktiv und die realen Server sind in Betrieb.

      Das HA-System ist fertig!

      Das ist es! Ihr Ergebnis ist ein hochverfügbares System, das auf verschiedene Verfügbarkeitszonen verteilt ist. Für dieses horizontal skalierbare, hochverfügbare System ist es auch wahrscheinlich, dass Sie mehr als zwei echte Server pro Load Balancer haben. Je nach Lastverhalten können Sie bei Bedarf weitere Server hoch- oder herunterfahren.

    Was ist mit dem Management Server?

    • Der Management-Server kann auf verschiedene Arten zur Verfügung gestellt werden. Die Veröffentlichung kann entweder über ein Gateway-System (mit iptables - Methode 1) oder über den Load Balancer (ein echter Server in der keepalived.conf - Methode2) erfolgen.

      Verfahren 1

      Aktivieren Sie auf beiden Gateway-Hosts iptables -t nat -A PREROUTING -i eth0 -p tcp -dport 22 -j DNAT -to 10.14.58.14:22 run und speichern Sie die aktive Konfiguration der iptables /etc/iptables.rules mit iptables-save > /etc/iptables.rules.

      Verfahren 2

      Die keepalived.conf wird auf einem zusätzlichen Load Balancer platziert. Dieser Load Balancer sollte Anfragen von der Public IP 162.254.27.26 auf Port 22 (virtual_server) und auf dem einzelnen Server (real_server 10.14.58.14) im privaten Netzwerk (lb_kind NAT) annehmen. Der Betriebszustand des realen Servers wird getestet, um sicherzustellen, dass er sich mit Port 22 verbinden kann. Um diese Konfiguration zu erstellen, fügen Sie den folgenden Code zu dieser Datei /etc/keepived/keepived/keepalived.conf hinzu (dies ist auf beiden Gateways identisch):

    virtual_server 162.254.27.26 22 {
       delay_loop 6
       lb_algo rr
       lb_kind NAT
       nat_mask 255.255.255.0
       protocol TCP
     
       real_server 10.14.58.14 22
       {
           weight 1
           TCP_CHECK {
                   connect_timeout 3
                   connect_port 22
           }
       }
    }
    • Die komplette keepalived.conf

      In meinem Beispiel habe ich mich für die Methode 2 für den Central Management Server entschieden. Die komplette keepalived.conf meiner Konfiguration finden Sie unten:

    !
    ! Global Config for keepalived
    !
    global_defs {
       ! uncomment the next line for the Master System
       lvs_id LVS_MASTER
       ! uncomment the next line for the Backup System
       ! lvs_id LVS_BACKUP
    }
     
    !
    ! VRRP Config for keepalived
    !
     
    ! define a vrrp group
    vrrp_sync_group VGROUP1 {
       group {
         VI_PUBLIC_1
         VI_GATEWAY_1
       }
    }
     
    ! vrrp instance for the public interface
    vrrp_instance VI_PUBLIC_1 {
       ! uncomment the next line for the Master System
       state MASTER
       ! uncomment the next line for the Backup System
       ! state BACKUP
       interface eth0
       lvs_sync_daemon_interface eth0
       virtual_router_id 51
       ! uncomment the next line for the Master System
       priority 100
       ! uncomment the next line for the Backup System
       ! priority 50
       advert_int 1
       authentication {
           auth_type PASS
           auth_pass MySuperSecretPassword
       }
       virtual_ipaddress {
           162.254.27.26
       }
    }
     
    ! vrrp instance for the internal gateway interface
    vrrp_instance VI_GATEWAY_1 {
       ! uncomment the next line for the Master System
       state MASTER
       ! uncomment the next line for the Backup System
       ! state BACKUP
       interface eth1
       lvs_sync_daemon_inteface eth1
       virtual_router_id 52
       ! uncomment the next line for the Master System
       priority 100
       ! uncomment the next line for the Backup System
       ! priority 50
       advert_int 1
       authentication {
           auth_type PASS
           auth_pass MySuperSecretPassword
       }
       virtual_ipaddress {
           10.14.58.15
       }
    } 
    
    !
    ! LVS loadbalancing configuration for keepalived
    !
     
    ! first virual Server
    virtual_server 162.254.27.26 80 {
       delay_loop 6
       lb_algo rr
       lb_kind NAT
       nat_mask 255.255.255.0
       protocol TCP
     
       real_server 10.14.58.11 80
       {
           weight 1
           HTTP_GET {
               url {
                   path /alive.txt
                           digest ea53b3baf477a283376779a3c1985085
                   }
                   connect_timeout 10
                   connect_port 80
                   nb_get_retry 3
                   delay_before_retry 10
           }
       }
       real_server 10.14.58.13 80
       {
           weight 1
           HTTP_GET {
               url {
                   path /alive.txt
                           digest 01bc6b572ba171d4d3bd89abe9cb9a4c
                   }
                   connect_timeout 10
                   connect_port 80
                   nb_get_retry 3
                   delay_before_retry 10
           }
       }
    }
    
    ! second virual Server
    virtual_server 162.254.27.26 25 {
       delay_loop 6
       lb_algo rr
       lb_kind NAT
       nat_mask 255.255.255.0
       protocol TCP
     
       real_server 10.14.58.17 25
       {
           weight 1
           TCP_CHECK {
                   connect_timeout 3
                   connect_port 25
           }
       }
       real_server 10.14.58.12 25
       {
           weight 1
           TCP_CHECK {
                   connect_timeout 3
                   connect_port 25
           }
       }
    }
     
    ! third virtual Server
    virtual_server 162.254.27.26 22 {
       delay_loop 6
       lb_algo rr
       lb_kind NAT
       nat_mask 255.255.255.0
       protocol TCP
     
       real_server 10.14.58.14 22
       {
           weight 1
           TCP_CHECK {
                   connect_timeout 3
                    connect_port 22
           }
       }
    }
    • Wir hoffen, dass diese Failover-Cloud-Szenario-Serie Ihnen geholfen hat.

    Nützliche Links