TOC

So richten Sie hochverfügbare HAProxy-Server mit Keepalived- und Floating-IPs unter Ubuntu 14.04 ein

Einführung

Hochverfügbarkeit ist eine Funktion des Systemdesigns, die es einer Anwendung ermöglicht, die Arbeit bei einem Ausfall automatisch neu zu starten oder auf ein anderes fähiges System umzuleiten. In Bezug auf Server sind einige unterschiedliche Technologien erforderlich, um ein hochverfügbares System einzurichten. Es muss eine Komponente vorhanden sein, die die Arbeit umleiten kann, und es muss ein Mechanismus zur Überwachung auf Fehler und zum Übergang des Systems vorhanden sein, wenn eine Unterbrechung festgestellt wird.

Der Daemonkeepalived kann verwendet werden, um Dienste oder Systeme zu überwachen und bei Problemen automatisch ein Failover in einen Standby-Modus durchzuführen. In diesem Handbuch wird gezeigt, wie Sie mitkeepalived eine hohe Verfügbarkeit für Ihre Load Balancer einrichten. Wir werden einfloating IP address konfigurieren, das zwischen zwei fähigen Load Balancern verschoben werden kann. Diese werden jeweils so konfiguriert, dass der Datenverkehr zwischen zwei Back-End-Webservern aufgeteilt wird. Wenn der primäre Load Balancer ausfällt, wird die Floating-IP automatisch auf den zweiten Load Balancer verschoben, sodass der Dienst fortgesetzt werden kann.

High Availability diagram

[.note] #Note:DigitalOcean Load Balancers sind ein vollständig verwalteter, hochverfügbarer Lastausgleichsdienst. Der Load Balancer-Dienst kann dieselbe Rolle übernehmen wie das hier beschriebene manuelle Hochverfügbarkeits-Setup. Folgen Sie unserenguide on setting up Load Balancers, wenn Sie diese Option bewerten möchten.
#

Voraussetzungen

Um dieses Handbuch zu vervollständigen, müssen Sie vier Ubuntu 14.04-Server in Ihrem DigitalOcean-Konto erstellen. Alle Server müssen sich im selben Datencenter befinden und das private Netzwerk muss aktiviert sein.

Auf jedem dieser Server benötigen Sie einen Nicht-Root-Benutzer, der mitsudoZugriff konfiguriert ist. Sie können unserenUbuntu 14.04 initial server setup guide folgen, um zu erfahren, wie Sie diese Benutzer einrichten.

Suchen von Server-Netzwerkinformationen

Bevor wir mit der eigentlichen Konfiguration unserer Infrastrukturkomponenten beginnen, sollten Sie zunächst einige Informationen zu jedem Ihrer Server sammeln.

Um dieses Handbuch zu vervollständigen, benötigen Sie die folgenden Informationen zu Ihren Servern:

  • web servers: Private IP-Adresse

  • load balancers Private und Anchor IP-Adressen

Private IP-Adressen suchen

Der einfachste Weg, die private IP-Adresse Ihres Droplets zu ermitteln, besteht darin,curl zu verwenden, um die private IP-Adresse vom DigitalOcean-Metadatendienst abzurufen. Dieser Befehl sollte in Ihren Droplets ausgeführt werden. Geben Sie für jedes Droplet Folgendes ein: 

curl 169.254.169.254/metadata/v1/interfaces/private/0/ipv4/address && echo

Die richtige IP-Adresse sollte im Terminalfenster ausgedruckt werden: 

Output10.132.20.236

Suchen von Anker-IP-Adressen

Die „Anker-IP“ ist die lokale private IP-Adresse, an die die Floating-IP gebunden wird, wenn sie an einen DigitalOcean-Server angeschlossen wird. Es ist einfach ein Alias ​​für die reguläreeth0-Adresse, die auf Hypervisor-Ebene implementiert ist.

Die einfachste und am wenigsten fehleranfällige Methode zum Abrufen dieses Werts ist der DigitalOcean-Metadatendienst. Mitcurl können Sie diesen Endpunkt auf jedem Ihrer Server erreichen, indem Sie Folgendes eingeben: 

curl 169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address && echo

Die Anker-IP wird in einer eigenen Zeile gedruckt: 

Output10.17.1.18

Installieren und konfigurieren Sie den Webserver

Nachdem wir die oben genannten Daten gesammelt haben, können wir mit der Konfiguration unserer Dienste fortfahren.

Note

[.note] # In diesem Setup ist die für die Webserverschicht ausgewählte Software ziemlich austauschbar. In diesem Handbuch wird Nginx verwendet, da es allgemein gehalten und recht einfach zu konfigurieren ist. Wenn Sie sich mit Apache oder einem (produktionsfähigen) sprachspezifischen Webserver besser auskennen, können Sie diesen auch verwenden. HAProxy leitet Client-Anforderungen einfach an die Back-End-Webserver weiter, die die Anforderungen ähnlich wie direkte Client-Verbindungen verarbeiten können.
#

Zunächst richten wir unsere Backend-Webserver ein. Diese beiden Server liefern genau den gleichen Inhalt. Sie akzeptieren nur Webverbindungen über ihre privaten IP-Adressen. Dadurch wird sichergestellt, dass der Datenverkehr über einen der beiden HAProxy-Server geleitet wird, die wir später konfigurieren werden.

Durch das Einrichten von Webservern hinter einem Lastenausgleich können wir die Anforderungslast auf eine Anzahl identischer Webserver verteilen. Wenn sich die Anforderungen an den Datenverkehr ändern, können wir problemlos skalieren, um die neuen Anforderungen zu erfüllen, indem wir Webserver zu dieser Ebene hinzufügen oder daraus entfernen.

Nginx installieren

Wir werden Nginx auf unseren Web-Servern installieren, um diese Funktionalität bereitzustellen.

Melden Sie sich zunächst mit dem Benutzer Ihressudobei den beiden Computern an, die Sie als Webserver verwenden möchten. Aktualisieren Sie den lokalen Paketindex auf jedem Ihrer Webserver und installieren Sie Nginx, indem Sie Folgendes eingeben: 

sudo apt-get update
sudo apt-get install nginx

Konfigurieren Sie Nginx so, dass nur Anforderungen von den Load Balancern zugelassen werden

Als nächstes werden wir unsere Nginx-Instanzen konfigurieren. Wir möchten Nginx anweisen, nur auf Anfragen an die private IP-Adresse des Servers zu warten. Darüber hinaus bearbeiten wir nur Anfragen, die von den privaten IP-Adressen unserer beiden Load Balancer stammen.

Öffnen Sie zum Vornehmen dieser Änderungen die Standard-Nginx-Serverblockdatei auf jedem Ihrer Webserver: 

sudo nano /etc/nginx/sites-available/default

Zu Beginn werden wir die Direktiven vonlistenändern. Ändern Sie die Anweisunglisten, um die aktuellenweb server’s private IP address an Port 80 abzuhören. Löschen Sie die zusätzliche Zeilelisten. Es sollte ungefähr so ​​aussehen:

/etc/nginx/sites-available/default

server {
    listen web_server_private_IP:80;

    . . .

Anschließend richten wir zweiallow-Richtlinien ein, um Datenverkehr zuzulassen, der von den privaten IP-Adressen unserer beiden Load Balancer stammt. Wir werden dem mit einerdeny all-Regel folgen, um jeglichen anderen Verkehr zu verbieten:

/etc/nginx/sites-available/default

server {
    listen web_server_private_IP:80;

    allow load_balancer_1_private_IP;
    allow load_balancer_2_private_IP;
    deny all;

    . . .

Speichern und schließen Sie die Dateien, wenn Sie fertig sind.

Testen Sie, ob die von Ihnen vorgenommenen Änderungen eine gültige Nginx-Syntax darstellen, indem Sie Folgendes eingeben: 

sudo nginx -t

Wenn keine Probleme gemeldet wurden, starten Sie den Nginx-Daemon neu, indem Sie Folgendes eingeben: 

sudo service nginx restart

Testen der Änderungen

Um zu testen, ob Ihre Webserver korrekt eingeschränkt sind, können Sie Anforderungen mitcurl von verschiedenen Standorten aus stellen.

Auf Ihren Webservern selbst können Sie eine einfache Anforderung des lokalen Inhalts versuchen, indem Sie Folgendes eingeben: 

curl 127.0.0.1

Aufgrund der Einschränkungen, die wir in unseren Nginx-Serverblockdateien festgelegt haben, wird diese Anforderung tatsächlich abgelehnt: 

Outputcurl: (7) Failed to connect to 127.0.0.1 port 80: Connection refused

Dies wird erwartet und spiegelt das Verhalten wider, das wir implementieren wollten.

Jetzt können wir von jedem derload balancers eine Anfrage nach einer der öffentlichen IP-Adressen unseres Webservers stellen: 

curl web_server_public_IP

Dies sollte erneut fehlschlagen. Die Webserver lauschen nicht auf die öffentliche Schnittstelle und außerdem werden unseren Webservern bei Verwendung der öffentlichen IP-Adresse die zulässigen privaten IP-Adressen in der Anforderung unserer Load Balancer nicht angezeigt: 

Outputcurl: (7) Failed to connect to web_server_public_IP port 80: Connection refused

Wenn wir den Aufruf jedoch so ändern, dass die Anforderung mitprivate IP addressdes Webservers erfolgt, sollte dies ordnungsgemäß funktionieren: 

curl web_server_private_IP

Die Standardseite von Nginxindex.htmlollte zurückgegeben werden: 

Output


Welcome to nginx!

. . .

Testen Sie dies von beiden Load Balancern auf beiden Webservern. Jede Anforderung für die private IP-Adresse sollte erfolgreich sein, während jede Anforderung an die öffentlichen Adressen fehlschlagen sollte.

Sobald das obige Verhalten demonstriert ist, können wir weitermachen. Unsere Backend-Webserverkonfiguration ist nun abgeschlossen.

Installieren und konfigurieren Sie HAProxy

Als Nächstes richten wir die HAProxy-Load-Balancer ein. Diese sitzen jeweils vor unseren Webservern und teilen die Anforderungen auf die beiden Backend-Server auf. Diese Load Balancer sind vollständig redundant. Es wird immer nur einer Verkehr empfangen.

Die HAProxy-Konfiguration leitet Anforderungen an beide Webserver weiter. Die Load Balancer warten auf Anfragen nach ihrer Anker-IP-Adresse. Wie bereits erwähnt, ist dies die IP-Adresse, an die die Floating-IP-Adresse gebunden wird, wenn sie an das Droplet angehängt wird. Dadurch wird sichergestellt, dass nur Datenverkehr weitergeleitet wird, der von der Floating-IP-Adresse stammt.

Installieren Sie HAProxy

Der erste Schritt, den wir für unsere Load Balancer unternehmen müssen, ist die Installation deshaproxy-Pakets. Wir können dies in den Standard-Ubuntu-Repositories finden. Aktualisieren Sie den lokalen Paketindex auf Ihren Load Balancern und installieren Sie HAProxy, indem Sie Folgendes eingeben: 

sudo apt-get update
sudo apt-get install haproxy

Konfigurieren Sie HAProxy

Das erste Element, das wir beim Umgang mit HAProxy ändern müssen, ist die/etc/default/haproxy-Datei. Öffnen Sie diese Datei jetzt in Ihrem Editor: 

sudo nano /etc/default/haproxy

Diese Datei legt fest, ob HAProxy beim Booten gestartet wird. Da der Dienst bei jedem Einschalten des Servers automatisch gestartet werden soll, müssen wir den Wert vonENABLED auf "1" ändern:

/etc/default/haproxy

# Set ENABLED to 1 if you want the init script to start haproxy.
ENABLED=1
# Add extra flags here.
#EXTRAOPTS="-de -m 16"

Speichern und schließen Sie die Datei, nachdem Sie die obigen Änderungen vorgenommen haben.

Als nächstes können wir die Haupt-HAProxy-Konfigurationsdatei öffnen: 

sudo nano /etc/haproxy/haproxy.cfg

Das erste Element, das angepasst werden muss, ist der Modus, in dem HAProxy ausgeführt wird. Wir möchten TCP oder Layer 4 für den Lastenausgleich konfigurieren. Dazu müssen wir die Zeilemode im Abschnittdefault ändern. Wir sollten auch die Option unmittelbar danach ändern, die sich mit dem Protokoll befasst:

/etc/haproxy/haproxy.cfg

. . .

defaults
    log     global
    mode    tcp
    option  tcplog

. . .

Am Ende der Datei müssen wir unsere Front-End-Konfiguration definieren. Dies bestimmt, wie HAProxy auf eingehende Verbindungen wartet. Wir binden HAProxy an die IP-Adresse des Load Balancer-Ankers. Auf diese Weise kann es auf Datenverkehr warten, der von der Floating-IP-Adresse stammt. Wir werden unser Frontend der Einfachheit halber "www" nennen. Wir werden auch ein Standard-Backend festlegen, an das der Datenverkehr weitergeleitet wird (das wir gleich konfigurieren werden):

/etc/haproxy/haproxy.cfg

. . .

defaults
    log     global
    mode    tcp
    option  tcplog

. . .

frontend www
    bind    load_balancer_anchor_IP:80
    default_backend nginx_pool

Als nächstes können wir unseren Backend-Bereich konfigurieren. Hiermit werden die Downstream-Standorte angegeben, an denen HAProxy den empfangenen Datenverkehr weiterleitet. In unserem Fall sind dies die privaten IP-Adressen der beiden von uns konfigurierten Nginx-Webserver. Wir werden das traditionelle Round-Robin-Balancing spezifizieren und den Modus wieder auf "tcp" setzen:

/etc/haproxy/haproxy.cfg

. . .

defaults
    log     global
    mode    tcp
    option  tcplog

. . .

frontend www
    bind load_balancer_anchor_IP:80
    default_backend nginx_pool

backend nginx_pool
    balance roundrobin
    mode tcp
    server web1 web_server_1_private_IP:80 check
    server web2 web_server_2_private_IP:80 check

Wenn Sie mit den obigen Änderungen fertig sind, speichern und schließen Sie die Datei.

Überprüfen Sie, ob die von uns vorgenommenen Konfigurationsänderungen eine gültige HAProxy-Syntax darstellen, indem Sie Folgendes eingeben: 

sudo haproxy -f /etc/haproxy/haproxy.cfg -c

Wenn keine Fehler gemeldet wurden, starten Sie Ihren Dienst neu, indem Sie Folgendes eingeben: 

sudo service haproxy restart

Testen der Änderungen

Wir können sicherstellen, dass unsere Konfiguration gültig ist, indem wir erneut mitcurl testen.

Versuchen Sie auf den Load Balancer-Servern, den lokalen Host, die eigene öffentliche IP-Adresse des Load Balancer oder die eigene private IP-Adresse des Servers anzufordern: 

curl 127.0.0.1
curl load_balancer_public_IP
curl load_balancer_private_IP

Diese sollten alle mit Nachrichten fehlschlagen, die ungefähr so ​​aussehen: 

Outputcurl: (7) Failed to connect to address port 80: Connection refused

Wenn Sie jedoch eine Anfrage ananchor IP addressdes Load Balancers stellen, sollte diese erfolgreich abgeschlossen werden: 

curl load_balancer_anchor_IP

Sie sollten die Standardseite von Nginxindex.htmlehen, die von einem der beiden Backend-Webserver weitergeleitet wird: 

Output


Welcome to nginx!

. . .

Wenn dieses Verhalten mit dem Ihres Systems übereinstimmt, sind Ihre Load Balancer korrekt konfiguriert.

Erstellen und installieren Sie Keepalived

Unser eigentlicher Service ist jetzt in Betrieb. Unsere Infrastruktur ist jedoch noch nicht hoch verfügbar, da wir keine Möglichkeit haben, den Datenverkehr umzuleiten, wenn bei unserem aktiven Load Balancer Probleme auftreten. Um dies zu korrigieren, installieren wir den Daemonkeepalived auf unseren Load Balancer-Servern. Dies ist die Komponente, die Failover-Funktionen bereitstellt, wenn unser aktiver Load Balancer nicht mehr verfügbar ist.

Es gibt eine Version vonkeepalived in den Standard-Repositorys von Ubuntu, diese ist jedoch veraltet und weist einige Fehler auf, die verhindern würden, dass unsere Konfiguration funktioniert. Stattdessen installieren wir die neueste Version vonkeepalived aus dem Quellcode.

Bevor wir beginnen, sollten wir die Abhängigkeiten ermitteln, die wir zum Erstellen der Software benötigen. Das Meta-Paketbuild-essentialbietet die Kompilierungswerkzeuge, die wir benötigen, während das Paketlibssl-devdie SSL-Entwicklungsbibliotheken enthält, gegen diekeepalivedbauen muss: 

sudo apt-get install build-essential libssl-dev

Sobald die Abhängigkeiten vorhanden sind, können wir den Tarball fürkeepalived herunterladen. Besuchen Siethis page, um die neueste Version der Software zu finden. Klicken Sie mit der rechten Maustaste auf die neueste Version und kopieren Sie die Linkadresse. Wechseln Sie auf Ihren Servern in Ihr Ausgangsverzeichnis und verwenden Siewget, um den von Ihnen kopierten Link abzurufen: 

cd ~
wget http://www.keepalived.org/software/keepalived-1.2.19.tar.gz

Verwenden Sie den Befehltar, um das Archiv zu erweitern. In das resultierende Verzeichnis verschieben: 

tar xzvf keepalived*
cd keepalived*

Erstellen und installieren Sie den Daemon, indem Sie Folgendes eingeben: 

./configure
make
sudo make install

Der Dämon sollte jetzt auf beiden Load-Balancer-Systemen installiert sein.

Erstellen Sie ein Keepalived-Upstart-Skript

Durch die Installation vonkeepalivedwurden alle Binärdateien und unterstützenden Dateien auf unserem System verschoben. Ein Teil, der jedoch nicht enthalten war, war ein Upstart-Skript für unsere Ubuntu 14.04-Systeme.

Wir können ein sehr einfaches Upstart-Skript erstellen, das den Dienst vonkeepalivedverarbeiten kann. Öffnen Sie eine Datei mit dem Namenkeepalived.conf im Verzeichnis/etc/init, um loszulegen: 

sudo nano /etc/init/keepalived.conf

Im Inneren können wir mit einer einfachen Beschreibung der Funktionalität beginnen, diekeepalived bietet. Wir verwenden die Beschreibung auf der Seite mit dem enthaltenenman. Als nächstes geben wir die Runlevel an, in denen der Dienst gestartet und gestoppt werden soll. Wir möchten, dass dieser Dienst unter allen normalen Bedingungen aktiv ist (Runlevel 2-5) und für alle anderen Runlevel angehalten wird (wenn beispielsweise ein Neustart, ein Ausschalten oder ein Einzelbenutzermodus eingeleitet wird):

/etc/init/keepalived.conf

description "load-balancing and high-availability service"

start on runlevel [2345]
stop on runlevel [!2345]

Da dieser Service für die Verfügbarkeit unseres Web-Service von entscheidender Bedeutung ist, möchten wir diesen Service im Falle eines Fehlers neu starten. Wir können dann die tatsächlicheexec-Zeile angeben, mit der der Dienst gestartet wird. Wir müssen die Option--dont-fork hinzufügen, damit Upstart diepid korrekt verfolgen kann:

/etc/init/keepalived.conf

description "load-balancing and high-availability service"

start on runlevel [2345]
stop on runlevel [!2345]

respawn

exec /usr/local/sbin/keepalived --dont-fork

Speichern und schließen Sie die Dateien, wenn Sie fertig sind.

Erstellen Sie die Keepalived-Konfigurationsdatei

Mit unseren Upstart-Dateien können wir nun mit der Konfiguration vonkeepalived fortfahren.

Der Dienst sucht nach seinen Konfigurationsdateien im Verzeichnis/etc/keepalived. Erstellen Sie dieses Verzeichnis jetzt auf beiden Load Balancern: 

sudo mkdir -p /etc/keepalived

Erstellen der Konfiguration des primären Lastenausgleichs

Erstellen Sie als Nächstes auf dem Load Balancer-Server, den Sie alsprimary-Server verwenden möchten, die Hauptkonfigurationsdatei vonkeepalived. Der Dämon sucht im Verzeichnis/etc/keepalivednach einer Datei mit dem Namenkeepalived.conf: 

sudo nano /etc/keepalived/keepalived.conf

Im Inneren definieren wir zunächst einen Gesundheitscheck für unseren HAProxy-Service, indem wir einenvrrp_script-Block öffnen. Auf diese Weise kannkeepalived unseren Load Balancer auf Fehler überwachen, um zu signalisieren, dass der Prozess ausgefallen ist, und mit den Wiederherstellungsmaßnahmen beginnen.

Unsere Prüfung wird sehr einfach sein. Alle zwei Sekunden überprüfen wir, ob ein Prozess namenshaproxy immer nochpid beansprucht:

/Etc/keepalived/keepalived.conf des Primärservers 

vrrp_script chk_haproxy {
    script "pidof haproxy"
    interval 2
}

Als nächstes öffnen wir einen Block namensvrrp_instance. Dies ist der Hauptkonfigurationsabschnitt, der definiert, wiekeepalived Hochverfügbarkeit implementiert.

Wir beginnen damit,keepalived anzuweisen, mit seinen Kollegen übereth1, unsere private Schnittstelle, zu kommunizieren. Da wir unseren Primärserver konfigurieren, setzen wir die Konfiguration vonstateauf "MASTER". Dies ist der Anfangswert, denkeepalived verwendet, bis der Dämon seinen Peer kontaktieren und eine Wahl abhalten kann.

Während der Wahl wird mit der Optionpriorityentschieden, welches Mitglied gewählt wird. Die Entscheidung basiert einfach darauf, welcher Server die höchste Nummer für diese Einstellung hat. Wir werden "200" für unseren Primärserver verwenden:

/Etc/keepalived/keepalived.conf des Primärservers 

vrrp_script chk_nginx {
    script "pidof nginx"
    interval 2
}

vrrp_instance VI_1 {
    interface eth1
    state MASTER
    priority 200


}

Als Nächstes weisen wir eine ID für diese Clustergruppe zu, die von beiden Knoten gemeinsam genutzt wird. Wir werden für dieses Beispiel "33" verwenden. Wir müssenunicast_src_ip auf die private IP-Adresse unseresprimaryLoad Balancers setzen. Wir setzenunicast_peer auf die private IP-Adresse unseressecondaryLoad Balancers:

/Etc/keepalived/keepalived.conf des Primärservers 

vrrp_script chk_haproxy {
    script "pidof haproxy"
    interval 2
}

vrrp_instance VI_1 {
    interface eth1
    state MASTER
    priority 200

    virtual_router_id 33
    unicast_src_ip primary_private_IP
    unicast_peer {
        secondary_private_IP
    }


}

Als Nächstes können wir eine einfache Authentifizierung für diekeepalived-Dämonen einrichten, um miteinander zu kommunizieren. Dies ist nur eine grundlegende Maßnahme, um sicherzustellen, dass der Peer, mit dem Kontakt aufgenommen wird, legitim ist. Erstellen Sie einenauthentication-Unterblock. Geben Sie im Inneren die Kennwortauthentifizierung an, indem Sieauth_type festlegen. Legen Sie für den Parameterauth_pass ein gemeinsames Geheimnis fest, das von beiden Knoten verwendet wird. Leider sind nur die ersten acht Zeichen von Bedeutung:

/Etc/keepalived/keepalived.conf des Primärservers 

vrrp_script chk_haproxy {
    script "pidof haproxy"
    interval 2
}

vrrp_instance VI_1 {
    interface eth1
    state MASTER
    priority 200

    virtual_router_id 33
    unicast_src_ip primary_private_IP
    unicast_peer {
        secondary_private_IP
    }

    authentication {
        auth_type PASS
        auth_pass password
    }


}

Als Nächstes weisen wirkeepalived an, die oben in der Datei erstellte Prüfung mit der Bezeichnungchk_haproxy zu verwenden, um den Zustand des lokalen Systems zu bestimmen. Schließlich setzen wir einnotify_master-Skript, das immer dann ausgeführt wird, wenn dieser Knoten zum „Master“ des Paares wird. Dieses Skript ist für das Auslösen der Neuzuweisung der Floating-IP-Adresse verantwortlich. Wir werden dieses Skript gleich erstellen:

/Etc/keepalived/keepalived.conf des Primärservers 

vrrp_script chk_haproxy {
    script "pidof haproxy"
    interval 2
}

vrrp_instance VI_1 {
    interface eth1
    state MASTER
    priority 200

    virtual_router_id 33
    unicast_src_ip primary_private_IP
    unicast_peer {
        secondary_private_IP
    }

    authentication {
        auth_type PASS
        auth_pass password
    }

    track_script {
        chk_haproxy
    }

    notify_master /etc/keepalived/master.sh
}

Speichern und schließen Sie die Datei, nachdem Sie die obigen Informationen eingerichtet haben.

Erstellen der Konfiguration des sekundären Lastenausgleichs

Als Nächstes erstellen wir das Begleitskript auf unserem sekundären Load Balancer. Öffnen Sie eine Datei bei/etc/keepalived/keepalived.conf auf Ihrem sekundären Server: 

sudo nano /etc/keepalived/keepalived.conf

Im Inneren entspricht das Skript, das wir verwenden, weitgehend dem Skript des Primärservers. Folgende Elemente müssen geändert werden:

  • state: Dies sollte auf dem sekundären Server in "BACKUP" geändert werden, damit der Knoten vor den Wahlen in den Sicherungsstatus initialisiert wird.

  • priority: Dies sollte auf einen niedrigeren Wert als der Primärserver eingestellt werden. In diesem Handbuch wird der Wert "100" verwendet.

  • unicast_src_ip: Dies sollte die private IP-Adresse dessecondary-Servers sein.

  • unicast_peer: Dies sollte die private IP-Adresse desprimary-Servers enthalten.

Wenn Sie diese Werte ändern, sollte das Skript für den sekundären Server folgendermaßen aussehen:

/Etc/keepalived/keepalived.conf des sekundären Servers 

vrrp_script chk_haproxy {
    script "pidof haproxy"
    interval 2
}

vrrp_instance VI_1 {
    interface eth1
    state BACKUP
    priority 100

    virtual_router_id 33
    unicast_src_ip secondary_private_IP
    unicast_peer {
        primary_private_IP
    }

    authentication {
        auth_type PASS
        auth_pass password
    }

    track_script {
        chk_haproxy
    }

    notify_master /etc/keepalived/master.sh
}

Speichern und schließen Sie die Datei, nachdem Sie das Skript eingegeben und die entsprechenden Werte geändert haben.

Erstellen Sie die Floating IP Transition Scripts

Als Nächstes müssen wir ein Skriptpaar erstellen, mit dem wir die schwebende IP-Adresse dem aktuellen Droplet neu zuweisen können, wenn die lokalekeepalived-Instanz zum Master-Server wird.

Laden Sie das Floating IP Assignment Script herunter

Zunächst laden wir ein generisches Python-Skript herunter (geschrieben vonDigitalOcean community manager), mit dem eine schwebende IP-Adresse mithilfe der DigitalOcean-API einem Droplet neu zugewiesen werden kann. Wir sollten diese Datei in das Verzeichnis/usr/local/binherunterladen: 

cd /usr/local/bin
sudo curl -LO http://do.co/assign-ip

Mit diesem Skript können Sie eine vorhandene unverankerte IP-Adresse neu zuweisen, indem Sie Folgendes ausführen: 

python /usr/local/bin/assign-ip floating_ip droplet_ID

Dies funktioniert nur, wenn für eine Umgebungsvariable namensDO_TOKENein gültiges DigitalOcean-API-Token für Ihr Konto festgelegt ist.

Erstellen Sie ein DigitalOcean-API-Token

Um das obige Skript verwenden zu können, müssen wir ein DigitalOcean-API-Token in unserem Konto erstellen.

Klicken Sie in der Systemsteuerung oben auf den Link „API“. Klicken Sie auf der rechten Seite der API-Seite auf "Neues Token erstellen":

DigitalOcean generate API token

Wählen Sie auf der nächsten Seite einen Namen für Ihr Token und klicken Sie auf die Schaltfläche "Token generieren":

DigitalOcean make new token

Auf der API-Seite wird Ihr neues Token angezeigt:

DigitalOcean token

Kopieren Sie das Tokennow. Aus Sicherheitsgründen kann dieses Token später nicht mehr angezeigt werden. Wenn Sie dieses Token verlieren, müssen Sie es zerstören und ein neues erstellen.

Konfigurieren Sie eine Floating IP für Ihre Infrastruktur

Als Nächstes werden wir eine Floating-IP-Adresse erstellen und zuweisen, die für unsere Server verwendet wird.

Klicken Sie in der DigitalOcean-Systemsteuerung auf die Registerkarte "Netzwerk" und wählen Sie das Navigationselement "Floating IPs". Wählen Sie Ihren primären Load Balancer aus dem Menü für die anfängliche Zuordnung aus:

DigitalOcean add floating IP

Eine neue Floating-IP-Adresse wird in Ihrem Konto erstellt und dem angegebenen Droplet zugewiesen:

DigitalOcean floating IP assigned

Wenn Sie die Floating-IP in Ihrem Webbrowser aufrufen, sollte die Standard-Nginx-Seite angezeigt werden, die von einem der Back-End-Webserver bereitgestellt wird:

DigitalOcean default index.html

Kopieren Sie die Floating-IP-Adresse nach unten. Sie benötigen diesen Wert im folgenden Skript.

Erstellen Sie das Wrapper-Skript

Jetzt haben wir die Elemente, die wir zum Erstellen des Wrapper-Skripts benötigen, das unser/usr/local/bin/assign-ip-Skript mit den richtigen Anmeldeinformationen aufruft.

Erstellen Sie die Datei jetzt aufboth Ihrer Load Balancer, indem Sie Folgendes eingeben: 

sudo nano /etc/keepalived/master.sh

Beginnen Sie im Inneren mit dem Zuweisen und Exportieren einer Variablen namensDO_TOKEN, die das soeben erstellte API-Token enthält. Darunter können wir eine Variable namensIP zuweisen, die Ihre schwebende IP-Adresse enthält:

/etc/keepalived/master.sh

export DO_TOKEN='digitalocean_api_token'
IP='floating_ip_addr'

Als Nächstes werden wircurl verwenden, um den Metadatendienst nach der Droplet-ID des Servers zu fragen, auf dem wir uns gerade befinden. Dies wird einer Variablen namensID zugewiesen. Wir werden auch fragen, ob diesem Droplet derzeit die Floating-IP-Adresse zugewiesen ist. Wir werden die Ergebnisse dieser Anfrage in einer Variablen namensHAS_FLOATING_IP speichern:

/etc/keepalived/master.sh

export DO_TOKEN='digitalocean_api_token'
IP='floating_ip_addr'
ID=$(curl -s http://169.254.169.254/metadata/v1/id)
HAS_FLOATING_IP=$(curl -s http://169.254.169.254/metadata/v1/floating_ip/ipv4/active)

Jetzt können wir die obigen Variablen verwenden, um das Skriptassign-ipaufzurufen. Das Skript wird nur aufgerufen, wenn die Floating-IP noch nicht mit unserem Droplet verknüpft ist. Dies hilft, API-Aufrufe zu minimieren und Konflikte bei Anfragen an die API zu vermeiden, wenn der Masterstatus schnell zwischen Ihren Servern wechselt.

Um Fälle zu behandeln, in denen auf der schwebenden IP bereits ein Ereignis ausgeführt wird, wiederholen wir das Skriptassign-ipeinige Male. Im Folgenden wird versucht, das Skript zehnmal mit einem Intervall von drei Sekunden zwischen den einzelnen Aufrufen auszuführen. Die Schleife wird sofort beendet, wenn der Floating IP Move erfolgreich ist:

/etc/keepalived/master.sh

export DO_TOKEN='digitalocean_api_token'
IP='floating_ip_addr'
ID=$(curl -s http://169.254.169.254/metadata/v1/id)
HAS_FLOATING_IP=$(curl -s http://169.254.169.254/metadata/v1/floating_ip/ipv4/active)

if [ $HAS_FLOATING_IP = "false" ]; then
    n=0
    while [ $n -lt 10 ]
    do
        python /usr/local/bin/assign-ip $IP $ID && break
        n=$((n+1))
        sleep 3
    done
fi

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Jetzt müssen wir nur noch das Skript ausführbar machen, damitkeepalived es aufrufen kann: 

sudo chmod +x /etc/keepalived/master.sh

Starten Sie den Keepalived-Dienst und testen Sie das Failover

Derkeepalived-Daemon und alle zugehörigen Skripte sollten jetzt vollständig konfiguriert sein. Wir können den Service auf beiden Load Balancern starten, indem wir Folgendes eingeben: 

sudo start keepalived

Der Dienst sollte auf jedem Server gestartet werden und sich mit seinem Peer in Verbindung setzen, um sich mit dem von uns konfigurierten gemeinsamen Geheimnis zu authentifizieren. Jeder Daemon überwacht den lokalen HAProxy-Prozess und hört Signale vom Remote-Prozesskeepalivedab.

Ihr primärer Load Balancer, dem derzeit die Floating-IP-Adresse zugewiesen sein sollte, leitet die Anforderungen der Reihe nach an jeden der Back-End-Nginx-Server. Es gibt einige einfache Sitzungsprobleme, die normalerweise angewendet werden, sodass Sie wahrscheinlich dasselbe Backend erhalten, wenn Sie Anforderungen über einen Webbrowser stellen.

Wir können das Failover auf einfache Weise testen, indem wir HAProxy auf unserem primären Load Balancer einfach deaktivieren: 

sudo service haproxy stop

Wenn wir unsere Floating-IP-Adresse in unserem Browser aufrufen, wird möglicherweise vorübergehend ein Fehler angezeigt, der darauf hinweist, dass die Seite nicht gefunden wurde: 

http://floating_IP_addr

DigitalOcean page not available

Wenn wir die Seite einige Male aktualisieren, wird unsere Standard-Nginx-Seite in Kürze wieder angezeigt:

DigitalOcean default index.html

Unser HAProxy-Service ist auf unserem primären Load Balancer noch nicht verfügbar, was darauf hinweist, dass unser sekundärer Load Balancer übernommen wurde. Mitkeepalived konnte der sekundäre Server feststellen, dass eine Dienstunterbrechung aufgetreten ist. Anschließend ging es in den Status „Master“ über und beanspruchte die Floating-IP mithilfe der DigitalOcean-API.

Wir können jetzt HAProxy auf dem primären Load Balancer erneut starten: 

sudo service haproxy start

Der primäre Lastenausgleich kann die unverankerte IP-Adresse in einem Moment wieder steuern, obwohl dies für den Benutzer eher transparent sein sollte.

Den Übergang visualisieren

Um den Übergang zwischen den Load Balancern besser zu veranschaulichen, können wir einige unserer Serverprotokolle während des Übergangs überwachen.

Da Informationen darüber, welcher Proxyserver verwendet wird, nicht an den Client zurückgegeben werden, können die Protokolle am besten von den tatsächlichen Back-End-Webservern angezeigt werden. Jeder dieser Server sollte Protokolle darüber führen, welche Clients Assets anfordern. Aus der Sicht des Nginx-Dienstes ist der Client der Load Balancer, der Anforderungen im Namen des tatsächlichen Clients sendet.

Verfolgen Sie die Protokolle auf den Webservern

Auf jedem unserer Backend-Webserver können wirtailden Standort von/var/log/nginx/access.logangeben. Dies zeigt jede Anfrage an den Server. Da unsere Load Balancer den Datenverkehr mithilfe einer Round-Robin-Rotation gleichmäßig aufteilen, sollte jeder Back-End-Webserver etwa die Hälfte der gestellten Anforderungen sehen.

Die Client-Adresse ist zum Glück das allererste Feld im Zugriffsprotokoll. Wir können den Wert mit einem einfachen Befehlawk extrahieren. Führen Sie aufboth Ihrer Nginx-Webserver Folgendes aus: 

sudo tail -f /var/log/nginx/access.log | awk '{print $1;}'

Diese werden wahrscheinlich meistens eine einzelne Adresse anzeigen: 

Output. . .

primary_lb_private_IP
primary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP

Wenn Sie auf die IP-Adressen Ihres Servers verweisen, werden Sie feststellen, dass diese hauptsächlich von Ihrem primären Load Balancer stammen. Beachten Sie, dass die tatsächliche Verteilung aufgrund einiger einfacher Sitzungsprobleme, die HAProxy implementiert, wahrscheinlich etwas anders sein wird.

Lassen Sie den Befehltail auf beiden Webservern ausgeführt.

Automatisieren Sie Anfragen an die Floating IP

Jetzt fordern wir auf Ihrem lokalen Computer alle 2 Sekunden den Webinhalt an der Floating-IP-Adresse an. Auf diese Weise können wir die Lastausgleichsänderung leicht erkennen. Geben Sie in Ihr lokales Terminal Folgendes ein (wir werfen die eigentliche Antwort weg, da diese unabhängig vom verwendeten Load Balancer gleich sein sollte): 

while true; do curl -s -o /dev/null floating_IP; sleep 2; done

Auf Ihren Webservern sollten neue Anforderungen eingehen. Im Gegensatz zu Anforderungen, die über einen Webbrowser gestellt werden, weisen einfachecurl-Anfragen nicht dieselbe Sitzungsklebrigkeit auf. Sie sollten eine gleichmäßigere Aufteilung der Anforderungen an Ihre Back-End-Webserver sehen.

Unterbrechen Sie den HAProxy-Dienst auf dem primären Load Balancer

Jetzt können wir den HAProxy-Dienst auf unserem primären Load Balancer wieder herunterfahren: 

sudo service haproxy stop

Nach einigen Sekunden sollte auf Ihren Webservern die Liste der IP-Adressen angezeigt werden, die von der privaten IP-Adresse des primären Load Balancers zur privaten IP-Adresse des sekundären Load Balancers übergehen: 

Output. . .

primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP

Alle neuen Anforderungen werden von Ihrem sekundären Load Balancer gestellt.

Starten Sie jetzt die HAProxy-Instanz erneut auf Ihrem primären Load Balancer: 

sudo service haproxy start

Sie werden sehen, wie die Client-Anforderungen innerhalb weniger Sekunden zur privaten IP-Adresse des primären Load Balancers zurückkehren: 

Output. . .

primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
secondary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP
primary_lb_private_IP

Der Primärserver hat die Kontrolle über die Floating-IP-Adresse wiedererlangt und seine Funktion als Hauptlastverteiler für die Infrastruktur wieder aufgenommen.

Konfigurieren Sie Nginx, um die tatsächliche Client-IP-Adresse zu protokollieren

Wie Sie gesehen haben, zeigen die Nginx-Zugriffsprotokolle, dass alle Clientanforderungen von der privaten IP-Adresse des aktuellen Lastenausgleichs stammen und nicht von der tatsächlichen IP-Adresse des Clients, der die Anforderung ursprünglich gestellt hat (d. H. Ihre lokale Maschine). Es ist häufig nützlich, die IP-Adresse des ursprünglichen Clients anstelle des Load-Balancer-Servers zu protokollieren. Dies lässt sich leicht erreichen, indem Sie auf allen Back-End-Webservern einige Änderungen an der Nginx-Konfiguration vornehmen.

Öffnen Sie auf beiden Webservern die Dateinginx.confin einem Editor: 

sudo nano /etc/nginx/nginx.conf

Suchen Sie den Abschnitt "Protokollierungseinstellungen" (innerhalb des Blockshttp) und fügen Sie die folgende Zeile hinzu:

füge /etc/nginx/nginx.conf hinzu 

log_format haproxy_log 'ProxyIP: $remote_addr - ClientIP: $http_x_forwarded_for - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent "$http_referer" ' '"$http_user_agent"';

Speichern und schließen. Dies gibt ein neues Protokollformat mit dem Namenhaproxy_log an, das den Wert$http_x_forwarded_for - die IP-Adresse des Clients, der die ursprüngliche Anforderung gestellt hat - zu den Standardzugriffsprotokolleinträgen hinzufügt. Wir schließen auch$remote_addr ein, was die IP-Adresse des Reverse-Proxy-Load-Balancers ist (d. H. der aktive Load-Balancer-Server).

Um dieses neue Protokollformat zu verwenden, müssen wir als Nächstes unserem Standardserverblock eine Zeile hinzufügen.

Öffnen Sie auf beiden Webservern die Serverkonfiguration vondefault: 

sudo nano /etc/nginx/sites-available/default

Fügen Sie im Blockserver (direkt unter der Direktivelisten eine gute Stelle ein) die folgende Zeile hinzu:

füge / etc / nginx / sites-available / default hinzu 

        access_log /var/log/nginx/access.log haproxy_log;

Speichern und schließen. Dies weist Nginx an, seine Zugriffsprotokolle mit dem oben erstellten Protokollformathaproxy_logzu schreiben.

Starten Sie Nginx auf beiden Webservern neu, damit die Änderungen wirksam werden: 

sudo service nginx restart

Jetzt sollten Ihre Nginx-Zugriffsprotokolle die tatsächlichen IP-Adressen der Clients enthalten, die Anforderungen stellen. Überprüfen Sie dies, indem Sie die Protokolle Ihrer App-Server wie im vorherigen Abschnitt beschrieben nachverfolgen. Die Protokolleinträge sollten ungefähr so ​​aussehen: 

New Nginx access logs:. . .
ProxyIP: load_balancer_private_IP - ClientIP: local_machine_IP - - [05/Nov/2015:15:05:53 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

Wenn Ihre Protokolle gut aussehen, sind Sie fertig!

Fazit

In diesem Handbuch wurde der gesamte Prozess der Einrichtung einer hochverfügbaren Infrastruktur mit Lastenausgleich beschrieben. Diese Konfiguration funktioniert gut, da der aktive HAProxy-Server die Last auf den Pool von Webservern im Backend verteilen kann. Sie können diesen Pool einfach skalieren, wenn Ihre Nachfrage wächst oder schrumpft.

Die Konfiguration von Floating IP undkeepalivedbeseitigt den einzelnen Fehlerpunkt auf der Lastausgleichsebene, sodass Ihr Dienst auch dann weiter funktioniert, wenn der primäre Lastausgleich vollständig ausfällt. Diese Konfiguration ist ziemlich flexibel und kann an Ihre eigene Anwendungsumgebung angepasst werden, indem Sie Ihren bevorzugten Webstack hinter den HAProxy-Servern einrichten.

Related