Die Failover-Cloud-Lösung Teil 1

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

UnserSLA garantiert unseren Kunden eine Verfügbarkeit von 99,95% für Hardware, Netzwerke und Daten auf unseren gehosteten Systemen. Kunden können ihre Verfügbarkeit erhöhen, indem sie sicherstellen, dass sie über zwei Maschinen verfügen, eine in jeder Feuerzone. Dieser Beitrag ist Teil einer Serie, die zeigt, wie man die Leistung eines Load Balancing nutzt, um eine Failover-Cloud-Lösung zu erstellen.

Für Systeme, die direkt mit dem Internet verbunden sind, kann dies auf den ersten Blick recht schwierig aussehen. Aber keine Sorge - dafür sorgt das Virtual Router Redundancy Protocol (VRRP), das Ihnen viel Geld einbringt, indem es Ihnen ermöglicht, nur eine IP-Adresse zwischen zahlreichen Rechnern zu teilen, indem Sie die eingehenden IP-Adressen nach dem Round-Robin-Verfahren zuweisen.

Wir werden in diesem Blogbeitrag ein Beispiel für diese einfache Lösung erstellen. Wir werden das Keepalived (http://www.keepalived.org) Tool als Failover- und Lastausgleichslösung einsetzen. Wir werden einen Webserver (Apache) direkt auf den VMs installieren. Dies gibt Ihnen eine Lösung (mit Keepalived), die mit minimalen Ressourcen einfach erstellt werden kann. Ein komplexeres Szenario wird in einem folgenden Blogbeitrag beschrieben.

Diese Art der Einrichtung wird für die produktive Verwendbarkeit für alle Ihre öffentlichen IP-Adressen empfohlen (wie hier unten beschrieben).

Unser grundlegendes DCD-Setup:

Für die Zwecke dieser Testumgebung werden wir zwei Debian-7-Maschinen verwenden, die identisch installiert und konfiguriert sind.

Alle Schritte müssen auf beiden Maschinen durchgeführt werden (sofern nicht anders angegeben), also stellen Sie bitte sicher, dass Sie Ihre IP-Adressen und die anderen unten genannten Änderungen an jede Konfiguration anpassen.

Für dieses spezielle Szenario benötigen wir zusätzliche IP-Adressen. Wir können leicht neue IP-Adressen im DCD reservieren (siehe Abschnitt "IP-Manager"):

Wir fügen dem VRRP-Master zusätzliche IP-Adressen (162.254.25.182) hinzu.

Ich habe die folgende Netzwerkkonfiguration in meinem Testaufbau.

VRRP-Master

Öffentliches geistiges Eigentum: eth0 162.254.26.26.80

Private IP: eth1 10.10.26.12

VRRP-Slave

Öffentliches geistiges Eigentum: eth0 162.254.26.81

Private IP: eth1 10.10.26.11

Virtuelle IP (VRRP Master)

Öffentliches geistiges Eigentum: eth0 162.254.25.182

Erstellen einer IP-Failover-Gruppe

In diesem 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. In unserem Beispiel-Setup sind dies alle im öffentlichen LAN verfügbaren NICs. Definieren Sie den Masterknoten Ihres Failover-Setups, indem Sie den Master-Radio-Button des entsprechenden NICs aktivieren. Wenn alles gesetzt ist, klicken Sie auf Create Failover Group und stellen Sie Ihre Änderungen bereit, um die IP-Failover-Gruppe zu erstellen.

Konfiguration des Betriebssystems

Nun kommen wir zu Ihrer Betriebssystemkonfiguration. Wir installieren Keepalived, eine Routing-Software für Load Balancing und Hochverfügbarkeit, die das VRR-Protokoll verwenden wird.

> apt-get update

> apt-get upgrade

> apt-get install apache2 installieren

> apt-get install keepalived installieren

> apt-get install ipvsadm installieren

Wir benötigen eindeutige Hostnamen, damit das Failover ordnungsgemäß funktioniert.

Ich habe die Hosts "vrrpmaster" und "vrrpslave" genannt.

> vi /etc/hostname

Dann führte er das folgende Skript aus:

> /etc/init.d/hostname.sh

Das folgende Bild wird in unseren Standardbildern verwendet und als Option angegeben, aber wenn Sie jetzt Ihr eigenes Bild verwenden möchten, können Sie es tun. Hier ist die Konfiguration Ihrer Netzwerkschnittstelle mit DHCP.

> vi /etc/network/interfaces

auto eth1

iface eth1 inet dhcp

> dhclient eth1

Wir haben gerade die Konfigurationsdaten für Keepalived erstellt.

** Denken Sie daran, die IP-Adressen Ihrer Umgebung anzupassen.

> vi /etc/keepived/keepalived/keepalived.conf

# Configuration File for Keepalived

global_defs {
  router_id LVS_MASTER # string identifying the machine
}

# describe virtual service ip
# VRRP Configuration
vrrp_instance VI_1 {
  state MASTER
  interface eth0
  virtual_router_id 1
  priority 100
  authentication {
    auth_type PASS
    auth_pass secretpassphrase
  }
  virtual_ipaddress {
    162.254.25.182/32
  }
  # Invoked to master transition
  notify_master "/etc/keepalived/bypass_ipvs.sh del 162.254.25.182"
  # Invoked to slave transition
  notify_backup "/etc/keepalived/bypass_ipvs.sh add 162.254.25.182"
  # Invoked to fault transition
  notify_fault "/etc/keepalived/bypass_ipvs.sh add 162.254.25.182"
  }

virtual_server 162.254.25.182 80 {
  delay_loop 30
  lb_algo rr
  lb_kind DR
  persistence_timeout 50
  protocol TCP

  real_server 10.10.26.12 80 {
    HTTP_GET {
      url {
        path /
        digest 21dde95d9d269cbb2fa6560309dca40c
      }
      connect_timeout 3
      nb_get_retry 3
      delay_before_retry 2
    }
  }
  real_server 10.10.26.11 80 {
    HTTP_GET {
      url {
        path /
        digest 21dde95d9d269cbb2fa6560309dca40c
      }
      connect_timeout 3
      nb_get_retry 3
      delay_before_retry 2
      }
    }
  }

Ersetzen Sie die folgenden Informationen durch Ihre IP-Adressen.

162.254.25.182 -> Virtuelle IP-Adresse
10.10.26.12 -> VRRP Master Private IP(eth1 IP)
10.10.26.11 -> VRRP Slave Private IP(eth1 IP)

In der VRRP-Slave-Konfigurationsdatei müssen wir die folgenden Änderungen vornehmen:

router_id LVS_MASTER -> router_id LVS_SLAVE
Zustand MASTER -> Zustand BACKUP
Priorität 100 -> Priorität 50

Unter auth_pass können Sie auch ein Passwort eingeben. Diese muss auf allen Ihren zusätzlichen VMs identisch sein.

Abhängig von diesen Werten überprüft Keepalived, ob der Host verfügbar ist. In unserem Fall ist dies der Pfad zur Indexseite. Dies sind die Standard-Hash-Werte des Apache für diese Standardseite. Wenn die index.html-Daten geändert werden, ändern sich auch die Hashwerte. Mit diesem Befehl können Sie die Werte überprüfen:

> cd /var/wwww/
> genhash -s 10.10.26.12 -p 80 -u /index.html
MD5SUM = 21dde95d9d269cbb2fa6560309dca40c

An dieser Stelle ist deine keepalived.conf vollständig.

In dieser minimalen Konfiguration ist es wichtig, dass die Maschine, in der sich der Modus "SLAVE" befindet, eine aktive NAT-Regel hat. Dies ist notwendig, um sicherzustellen, dass der aktive Webserver (mit der aktiven virtuellen IP - auf dem Masterknoten) tatsächlich erreichbar ist. Dazu verwenden wir das folgende Skript "/etc/keepalived/bypass_ipvs.sh" von Gael Charrière.

#! /bin/sh
#
# Gael Charriere <gael.charriere@gmail.com>
# 10.11.2008
#
# Invoked by keepalived from master/slave
# to slave/master transition to add or remove
# a PREROUTING rule
#
# Essential for slave to redirect incoming
# service packet to localhost. Otherwise a
# loop can appear between master and slave.
#
# The routing table is consulted when a packet
# that creates a new connection is encountered.
# PREROUTING rule alters packets as soon as they come in.
# REDIRECT statement redirects the packet to the machine
# itself by changing the destination IP to the primary
# address of the incoming interface (locally-generated
# packets are mapped to the 127.0.0.1 address).

# Check number of command line args
EXPECTED_ARGS=2
if [ $# -ne $EXPECTED_ARGS ]; then
  echo "Usage: $0 {add|del} ipaddress"
  exit 1
fi

# Check if second arg is a valid ip address
VIP=$2
OLD_IFS=$IFS
IFS="."
VIP=( $VIP )
IFS=$OLD_IFS
# Check that ip has 4 parts
  if [ ${#VIP[@]} -ne 4 ]; then
    echo "IP address must have 4 parts"
    echo "Usage: $0 {add|del} ipaddress"
    exit 1
fi 

# Check that each parts is a number which
# varies between 0 and 255
for oct in ${VIP[@]} ; do
    echo $oct | egrep "^[0-9]+$" >/dev/null 2>&1
  if [ $? -ne 0 ]; then
    echo "$oct: Not numeric"
    echo "Usage: $0 {add|del} ipaddress"
    exit 1
else
  if [ $oct -lt 0 -o $oct -gt 255 ]; then
    echo "$oct: Out of range"
    echo "Usage: $0 {add|del} ipaddress"
    exit 1
  fi
fi
done

# If we are here, ip address is validated
VIP="${VIP[0]}.${VIP[1]}.${VIP[2]}.${VIP[3]}"

# Add or remove the prerouting rule
case "$1" in
add)
        # check if the rule was already specified
        n=$(iptables -t nat -L| grep $VIP | wc -l)
  if [[ $n == 0 ]]; then
        # the rule was not found, add it
        iptables -A PREROUTING -t nat -d $VIP -p tcp -j REDIRECT
    fi
    ;;
    del)
        # check if the rule was already specified
      n=$(iptables -t nat -L| grep $VIP | wc -l)
      while [[ $n > 0 ]]; do
        # remove the rule
        iptables -D PREROUTING -t nat -d $VIP -p tcp -j REDIRECT
        n=$(($n-1))
      done
    ;;
    *)
    echo "Usage: $0 {add|del} ipaddress"
    exit 1
    esac
    exit 0

Wir setzen Berechtigungen, um sicherzustellen, dass die Datei ausgeführt werden kann:

> chmod 755 /etc/keepived/bypass_ipvs.sh

Die IP-Weiterleitung muss eingeschaltet und die IP-Rückwärtspfadfilterung deaktiviert sein. Dazu müssen wir die folgenden Änderungen vornehmen:

# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks

net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.eth0.rp_filter=0
net.ipv4.conf.eth1.rp_filter=0

# Entkommentieren Sie die nächste Zeile, um die Paketweiterleitung für IPv4 zu aktivieren.
net.ipv4.ip_forward=1

Füllen Sie die folgenden Felder aus:

> sysctl -p

Dies sind die Einstellungen, die wir für dieses Szenario benötigen.

Wir können Keepalived mit dem folgenden Befehl starten (Wenn Sie eine Fehlermeldung erhalten, bedeutet das, dass Keepalived bereits ausgeführt wird):

> service keepalived start

In Debian platziert Keepalived Nachrichten unter /var/log/Messages. Wenn Sie mehr Text in Ihren Debugging-Meldungen haben möchten, können Sie Keepalived auch manuell starten (unter Angabe der gewünschten Optionen):

> keepalived -d -log-detail

Wir können nun unsere virtuellen IP-Adressen unter eth0 auf VRRP Master sehen. Die Adresse sollte auf Ping reagieren, und der Apache Webserver ist auch unter dieser IP-Adresse verfügbar. Um Informationen über unsere Netzwerkschnittstellen zu erhalten, verwenden wir den folgenden Befehl:

> ip adressenliste

Fällt der VRRP-Master aus, übernimmt der VRRP-Slave die IP-Adresse; nach 1 oder 2 Pings ist die IP-Adresse wieder verfügbar.

Sie können einen ähnlichen Test durchführen, indem Sie Keepalived stoppen.

> service keepalived stop

Wenn Sie Keepalived erneut starten, wird die IP-Adresse automatisch an den VRRP-Master weitergegeben. Dies geschieht aufgrund der höheren Priorität für keepalived.conf-Dateien.

Die Load Balancing-Funktion basiert auf einem "Linux Virtual Server" und ist als Round Robin implementiert. Jede neue IP-Adresse wird an einen anderen Host weitergeleitet. Wenn der VRRP-Master ausfällt, nimmt der VRRP-Slave dann den Durchhang auf.

Es ist nun möglich, einen zusätzlichen Test auf unserem Apache2-Server durchzuführen. Wenn wir eine HTML-Datei auf beiden Webservern erstellen.

Bitte beachten Sie: Wenn Sie den Inhalt von "index.html" anpassen, ändert sich auch der Hash-Wert, also stellen Sie sicher, dass Sie die conf-Datei mit dem entsprechenden MD5SUM-Wert erzeugen und ändern.

> vi /var/wwww/index.html

Folgendes einfügen:

<HTML>
 <BODY>
   <H2>
   Test WebServer 1
   </H2>
 </BODY>
</HTML>

Ähnlich wie oben beschrieben, ändern wir die html-Datei in Test WebServer2 auf dem VRRP-Slave.

Wenn wir eine http-Anfrage über die virtuelle IP-Adresse (http://162.254.25.182/index.html) senden, können wir sehen, auf welchem Server wir gelandet sind. Eine zweite Verbindung (eine andere IP-Adresse) kann auf einem anderen Webserver eingerichtet werden. Mit dem folgenden Befehl können Sie dann den Status der Lastausgleichskomponente überprüfen:

> ipvsadm -l

Wir haben jetzt ein ausfallsicheres System eingerichtet. Wenn Ihr VRRP-Master (im ersten Feuerzonenbereich) abstürzt, ist der VRRP-Slave (im zweiten Feuerzonenbereich) da, um den Durchhang aufzuheben.

Im nächsten Tutorial werden wir Sie durch den Prozess der Einrichtung einer komplexeren Load Balancing-Lösung führen.