TOC

So erstellen Sie ein Hochverfügbarkeits-HAProxy-Setup mit Corosync, Pacemaker und Floating IPs unter Ubuntu 14.04

Einführung

In diesem Tutorial erfahren Sie, wie Sie ein HAProxy-Load-Balancer-Setup für hohe Verfügbarkeit auf DigitalOcean erstellen, das Floating IP und den Corosync / Pacemaker-Cluster-Stack unterstützt. Die HAProxy-Load-Balancer sind jeweils so konfiguriert, dass der Datenverkehr zwischen zwei Back-End-Anwendungsservern 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.

image: https://assets.digitalocean.com/articles/high_availability/ha-diagram-animated.gif [HAProxy-Setup für hohe Verfügbarkeit]

Voraussetzungen

Um dieses Handbuch zu vervollständigen, müssen Sie die https://www.digitalocean.com/community/tutorials/how-to-create-a-high-availability-setup-with-corosync-pacemaker-and- ausgefüllt haben. floating-ips-on-ubuntu-14-04 [So erstellen Sie ein Setup für hohe Verfügbarkeit mit Corosync, Pacemaker und Floating IPs unter Ubuntu 14.04] (Sie sollten den optionalen Abschnitt * Nginx-Ressource hinzufügen * überspringen). Auf diese Weise erhalten Sie zwei Droplets, die wir als * primäre * und * sekundäre * bezeichnen, mit einer Floating-IP, die zwischen ihnen wechseln kann. Zusammen bezeichnen wir diese Server als * Load Balancer *. In diesen Droplets installieren wir den Load Balancer HAProxy.

Sie müssen außerdem in der Lage sein, zwei zusätzliche Ubuntu 14.04-Droplets im selben Datencenter mit aktiviertem privaten Netzwerk zu erstellen, um zu demonstrieren, dass das HA-Load-Balancer-Setup funktioniert. Dies sind die Server, die von HAProxy Lastenausgleich erhalten. Wir bezeichnen diese Anwendungsserver, auf denen wir Nginx installieren, als * app-1 * und * app-2 *. Wenn Sie bereits Anwendungsserver haben, die Sie ausgleichen möchten, können Sie diese stattdessen verwenden.

Auf jedem dieser Server benötigen Sie einen Nicht-Root-Benutzer, der mit "+ sudo +" - Zugriff konfiguriert ist. Sie können unserer Ubuntu 14.04 Einrichtungsanleitung für Server folgen, um zu erfahren, wie Sie diese Benutzer einrichten.

Erstellen Sie App Droplets

Der erste Schritt besteht darin, zwei Ubuntu-Droplets mit aktiviertem Private Networking im selben Datencenter wie Ihre Load Balancer zu erstellen, die als die oben beschriebenen * app-1 * - und * app-2 * -Server fungieren. Wir werden Nginx auf beiden Droplets installieren und deren Indexseiten durch Informationen ersetzen, die sie eindeutig identifizieren. Auf diese Weise können wir auf einfache Weise demonstrieren, dass das HA-Load-Balancer-Setup funktioniert. Wenn Sie bereits Anwendungsserver haben, die Sie ausgleichen möchten, können Sie die entsprechenden Teile dieses Lernprogramms anpassen, damit dies funktioniert (und alle Teile überspringen, die für Ihr Setup irrelevant sind).

Wenn Sie dem Beispiel-Setup folgen möchten, erstellen Sie zwei Ubuntu 14.04-Droplets, * app-1 * und * app-2 *, und verwenden Sie dieses Bash-Skript als Benutzerdaten:

Beispiel Benutzerdaten

#!/bin/bash

apt-get -y update
apt-get -y install nginx
export HOSTNAME=$(curl -s http://169.254.169.254/metadata/v1/hostname)
export PUBLIC_IPV4=$(curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
echo Droplet: $HOSTNAME, IP Address: $PUBLIC_IPV4 > /usr/share/nginx/html/index.html

Diese Benutzerdaten installieren Nginx und ersetzen den Inhalt von index.html durch den Hostnamen und die öffentliche IP-Adresse des Droplets (unter Bezugnahme auf den Metadatendienst). Wenn Sie auf eines der Droplets zugreifen, wird eine einfache Webseite mit dem Hostnamen und der öffentlichen IP-Adresse des Droplets angezeigt. Dies ist hilfreich, um zu testen, an welchen App-Server die Load Balancer den Datenverkehr weiterleiten.

Sammeln 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:

  • * App-Server *: Private IP-Adresse

  • * Load Balancer * Private und Anchor IP-Adressen

Private IP-Adressen suchen

Der einfachste Weg, die private IP-Adresse Ihres Droplets zu finden, ist die Verwendung von "+ curl +", um die private IP-Adresse aus dem 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:

Private IP address:10.132.20.236

Führen Sie diesen Schritt für alle vier Droplets aus und kopieren Sie die privaten IP-Adressen an eine Stelle, auf die Sie leicht verweisen können.

Suchen Sie nach 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äre Adresse "+ eth0 +", die auf Hypervisor-Ebene implementiert ist.

Die einfachste und am wenigsten fehleranfällige Methode zum Abrufen dieses Werts ist der DigitalOcean-Metadatendienst. Mit + curl + 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

Führen Sie diesen Schritt für beide Load-Balancer-Droplets aus und kopieren Sie die Anker-IP-Adressen an eine Stelle, auf die Sie leicht verweisen können.

App-Server konfigurieren

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

Note

Zunächst richten wir unsere Backend-App-Server ein. Diese beiden Server werden lediglich ihren Namen und ihre öffentliche IP-Adresse bereitstellen. In einer realen Umgebung würden diese Server identische Inhalte bereitstellen. Sie akzeptieren nur Webverbindungen über ihre privaten IP-Adressen. Dadurch wird sichergestellt, dass der Datenverkehr ausschließlich über einen der beiden HAProxy-Server geleitet wird, die wir später konfigurieren werden.

Durch das Einrichten von App-Servern hinter einem Load Balancer können wir die Anforderungslast auf eine Reihe von identischen App-Servern verteilen. Wenn sich unsere Datenverkehrsanforderungen ändern, können wir einfach skalieren, um den neuen Anforderungen gerecht zu werden, indem wir dieser Ebene App-Server hinzufügen oder daraus entfernen.

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

Wenn Sie dem Beispiel folgen und beim Erstellen Ihrer App-Server die angegebenen * Benutzerdaten * verwendet haben, ist Nginx auf Ihren Servern bereits installiert. Der nächste Schritt besteht darin, einige Konfigurationsänderungen vorzunehmen.

Wir möchten Nginx so konfigurieren, dass es nur auf Anfragen nach der privaten IP-Adresse des Servers wartet. Darüber hinaus bearbeiten wir nur Anfragen, die von den privaten IP-Adressen unserer beiden Load Balancer stammen. Dadurch werden Benutzer gezwungen, über Ihre Load Balancer auf Ihre App-Server zuzugreifen (die wir so konfigurieren, dass sie nur über die Floating-IP-Adresse zugänglich sind).

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

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

Zu Beginn werden wir die Direktiven + listen + modifizieren. Ändern Sie die Anweisung "+ listen ", um die private IP-Adresse des aktuellen * App-Servers * an Port 80 abzuhören. Löschen Sie die zusätzliche Zeile ` listen +`. Es sollte ungefähr so ​​aussehen:

/ etc / nginx / sites-available / default (1 von 2)

server {
   listen :80;

   . . .

Direkt unter der Direktive "+ listen " werden zwei Direktiven " allow " eingerichtet, um Datenverkehr zuzulassen, der von den privaten IP-Adressen unserer beiden Load Balancer stammt. Wir werden dem mit einer " alle verweigern +" -Regel folgen, um allen anderen Verkehr zu verbieten:

/ etc / nginx / sites-available / default (2 von 2)

   allow ;
   allow ;
   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

Denken Sie daran, alle diese Schritte (mit den entsprechenden privaten IP-Adressen des App-Servers) auf beiden App-Servern auszuführen.

Testen der Änderungen

Um zu testen, ob Ihre App-Server ordnungsgemäß eingeschränkt sind, können Sie Anforderungen mit der Tastenkombination "+ locken" an verschiedenen Standorten stellen.

Auf Ihren App-Servern 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 einem der * Load Balancer * eine Anfrage für eine der öffentlichen IP-Adressen unseres App-Servers stellen:

curl

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

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

Wenn wir den Aufruf jedoch so ändern, dass die Anforderung unter Verwendung der privaten IP-Adresse des App-Servers erfolgt, sollte dies ordnungsgemäß funktionieren:

curl

Die Nginx + index.html Seite sollte zurückgegeben werden. Wenn Sie die Beispielbenutzerdaten verwendet haben, sollte die Seite den Namen und die öffentliche IP-Adresse des App-Servers enthalten, auf den zugegriffen wird:

app server index.htmlDroplet: app-1, IP Address: 159.203.130.34

Testen Sie dies von beiden Load Balancern auf beiden App-Servern. 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-App-Server-Konfiguration ist nun abgeschlossen.

Entfernen Sie Nginx von Load Balancers

Wenn Sie das Lernprogramm für das * HA-Setup mit Corosync, Pacemaker und Floating IPs * befolgen, wird auf Ihren Load-Balancer-Servern Nginx installiert. Da wir HAProxy als Reverse-Proxy-Load-Balancer verwenden, sollten wir Nginx und alle zugehörigen Cluster-Ressourcen löschen.

Entfernen Sie die Nginx-Clusterressourcen

Wenn Sie eine Nginx-Cluster-Ressource hinzugefügt haben, während Sie das Lernprogramm befolgt haben, beenden und löschen Sie die Ressource + Nginx + mit diesen Befehlen auf einem Ihrer Load Balancer *:

sudo crm resource stop Nginx
sudo crm configure delete Nginx

Hierdurch sollten auch alle Cluster-Einstellungen gelöscht werden, die von der Ressource "+ Nginx +" abhängen. Wenn Sie beispielsweise einen Klon oder eine Colocation erstellt haben, die auf die Ressource Nginx verweist, werden diese ebenfalls gelöscht.

Entfernen Sie das Nginx-Paket

Jetzt können wir Nginx auf * beiden Load-Balancer-Servern * deinstallieren.

Beenden Sie zunächst den Nginx-Dienst:

sudo service nginx stop

Dann lösche das Paket mit diesem Befehl:

sudo apt-get purge nginx

Möglicherweise möchten Sie auch die Nginx-Konfigurationsdateien löschen:

sudo rm -r /etc/nginx

Jetzt können wir HAProxy installieren und konfigurieren.

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 Back-End-App-Server auf. Diese Load Balancer sind in einer Aktiv-Passiv-Konfiguration vollständig redundant. Es wird immer nur einer den 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

Dieser Abschnitt muss auf * beiden Load-Balancer-Servern * ausgeführt werden.

Wir werden HAProxy 1.6 installieren, das nicht in den Standard-Ubuntu-Repositories enthalten ist. Mit dem folgenden Befehl können wir jedoch weiterhin einen Paket-Manager zum Installieren von HAProxy 1.6 verwenden, wenn wir einen PPA verwenden:

sudo add-apt-repository ppa:vbernat/haproxy-1.6

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

HAProxy ist jetzt installiert, aber wir müssen es jetzt konfigurieren.

Konfigurieren Sie HAProxy

Öffnen Sie die HAProxy-Hauptkonfigurationsdatei:

sudo vi /etc/haproxy/haproxy.cfg

Suchen Sie den Abschnitt "+ Defaults +" und fügen Sie die beiden folgenden Zeilen darunter hinzu:

/etc/haproxy/haproxy.cfg (1 von 3)

   option forwardfor
   option http-server-close

Die Option forwardfor setzt HAProxy so, dass jeder Anfrage "+ X-Forwarded-For +" -Header hinzugefügt werden. Dies ist hilfreich, wenn Ihre App-Server wissen sollen, von welcher IP-Adresse ursprünglich eine Anfrage gesendet wurde, und die Option http-server-close verringert die Latenz zwischen HAProxy und Ihre Benutzer, indem Sie Verbindungen schließen, aber die Keep-Alives beibehalten.

Als nächstes müssen wir am Ende der Datei unsere Frontend-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 "http" nennen. Wir werden auch ein Standard-Backend angeben, + app_pool +, an das der Datenverkehr weitergeleitet werden soll (das wir gleich konfigurieren werden):

/etc/haproxy/haproxy.cfg (2 von 3)

frontend http
   bind    :80
   default_backend app_pool

Als nächstes können wir die Backend-Konfiguration definieren. 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-App-Server:

/etc/haproxy/haproxy.cfg (3 von 3)

backend app_pool
   server app-1 :80 check
   server app-2 :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

Stellen Sie auch hier sicher, dass Sie alle Schritte in diesem Abschnitt auf beiden Load-Balancer-Servern ausführen.

Testen der Änderungen

Wir können sicherstellen, dass Ihre Konfiguration gültig ist, indem wir erneut mit "+ curl" 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
curl

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

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

Wenn Sie jedoch eine Anforderung an die anchor IP-Adresse des Load Balancers senden, sollte diese erfolgreich ausgeführt werden:

curl

Sie sollten die Nginx-Seite "+ index.html" eines der App-Server sehen:

app server index.htmlDroplet: app-1, IP Address: app1_IP_address

Führen Sie die gleiche Wellung erneut durch:

curl

Sie sollten die Seite "+ index.html" des anderen App-Servers sehen, da HAProxy standardmäßig einen Round-Robin-Lastenausgleich verwendet:

app server index.htmlDroplet: app-2, IP Address: app2_IP_address

Wenn dieses Verhalten mit dem Ihres Systems übereinstimmt, sind Ihre Load Balancer korrekt konfiguriert. Sie haben erfolgreich getestet, dass Ihre Load-Balancer-Server den Datenverkehr zwischen beiden Back-End-App-Servern ausgleichen. Außerdem sollte Ihre Floating-IP bereits einem der Load-Balancer-Server zugewiesen sein, wie dies im vorausgesetzten Tutorial * HA-Setup mit Corosync, Pacemaker und Floating-IPs * festgelegt wurde.

Laden Sie den HAProxy OCF Resource Agent herunter

Zu diesem Zeitpunkt haben Sie ein grundlegendes Failover auf Hostebene, aber wir können das Setup verbessern, indem wir HAProxy als Clusterressource hinzufügen. Dadurch kann Ihr Cluster sicherstellen, dass HAProxy auf dem Server ausgeführt wird, dem Ihre Floating IP zugewiesen ist. Wenn Pacemaker feststellt, dass HAProxy nicht ausgeführt wird, kann er den Dienst neu starten oder die Floating-IP dem anderen Knoten zuweisen (auf dem HAProxy ausgeführt werden soll).

Pacemaker ermöglicht das Hinzufügen von OCF-Ressourcenagenten, indem diese in einem bestimmten Verzeichnis abgelegt werden.

Laden Sie auf beiden Load-Balancer-Servern den HAProxy-OCF-Ressourcenagenten mit den folgenden Befehlen herunter:

cd /usr/lib/ocf/resource.d/heartbeat
sudo curl -O https://raw.githubusercontent.com/thisismitch/cluster-agents/master/haproxy

Machen Sie es auf * beiden Load-Balancer-Servern * ausführbar:

sudo chmod +x haproxy

Sie können den Inhalt der Ressource überprüfen, bevor Sie fortfahren. Es ist ein Shell-Skript, mit dem der HAProxy-Dienst verwaltet werden kann.

Jetzt können wir den HAProxy-OCF-Ressourcenagenten verwenden, um unsere "+ haproxy +" - Clusterressource zu definieren.

Haproxy-Ressource hinzufügen

Mit unserem installierten HAProxy-OCF-Ressourcenagenten können wir jetzt eine "+ haproxy +" - Ressource konfigurieren, mit der der Cluster HAProxy verwalten kann.

Erstellen Sie auf * einem Load-Balancer-Server * die primitive Ressource + haproxy + mit dem folgenden Befehl:

sudo crm configure primitive haproxy ocf:heartbeat:haproxy op monitor interval=15s

Die angegebene Ressource weist den Cluster an, HAProxy alle 15 Sekunden zu überwachen und neu zu starten, wenn es nicht mehr verfügbar ist.

Überprüfen Sie den Status Ihrer Cluster-Ressourcen mit + sudo crm_mon oder` + sudo crm status`:

crm_mon:...
Online: [ primary secondary ]

FloatIP    (ocf::digitalocean:floatip):    Started
Nginx  (ocf::heartbeat:nginx): Started

Leider könnte sich Pacemaker dazu entschließen, die Ressourcen + haproxy + und + FloatIP + auf separaten Knoten zu starten, da wir keine Ressourcenbeschränkungen definiert haben. Dies ist ein Problem, da die Floating-IP möglicherweise auf ein Droplet verweist, während der HAProxy-Dienst auf dem anderen Droplet ausgeführt wird. Wenn Sie auf die Floating IP zugreifen, werden Sie auf einen Server verwiesen, auf dem der Dienst nicht ausgeführt wird und der hoch verfügbar sein sollte.

Um dieses Problem zu beheben, erstellen wir eine * Klon * -Ressource, die angibt, dass eine vorhandene primitive Ressource auf mehreren Knoten gestartet werden soll.

Erstellen Sie mit diesem Befehl einen Klon der Ressource "+ haproxy +" mit dem Namen "haproxy-clone":

sudo crm configure clone haproxy-clone haproxy

Der Clusterstatus sollte nun ungefähr so ​​aussehen:

crm_mon:Online: [ primary secondary ]

FloatIP (ocf::digitalocean:floatip):    Started primary
Clone Set: haproxy-clone [Nginx]
    Started: [ primary secondary ]

Wie Sie sehen, wird die Klonressource "+ haproxy-clone +" jetzt auf beiden Knoten gestartet.

Der letzte Schritt ist das Konfigurieren einer Colocation-Einschränkung, um anzugeben, dass die Ressource "+ FloatIP " auf einem Knoten mit einer aktiven Ressource " haproxy-clone +" ausgeführt werden soll. Verwenden Sie diesen Befehl, um eine Colocation-Einschränkung mit dem Namen "FloatIP-haproxy" zu erstellen:

sudo crm configure colocation FloatIP-haproxy inf: FloatIP haproxy-clone

Sie werden keinen Unterschied in der crm-Statusausgabe sehen, aber Sie können sehen, dass die Colocation-Ressource mit diesem Befehl erstellt wurde:

sudo crm configure show

Jetzt sollte auf beiden Servern HAProxy ausgeführt werden, während auf nur einem die FloatIP-Ressource ausgeführt wird.

Beenden Sie den HAProxy-Dienst auf einem der beiden Load Balancer-Server:

sudo service haproxy stop

Sie werden bemerken, dass es innerhalb der nächsten 15 Sekunden wieder hochfährt.

Als Nächstes testen wir Ihr HA-Setup, indem wir Ihren aktiven Load-Balancer-Server neu starten (den, auf dem die Ressource "+ FloatIP +" derzeit "gestartet" ist).

Testen Sie die Hochverfügbarkeit von Load Balancern

Mit Ihrem neuen Hochverfügbarkeits-HAProxy-Setup möchten Sie testen, ob alles wie beabsichtigt funktioniert.

Um den Übergang zwischen den Load Balancern besser zu veranschaulichen, können wir die Nginx-Protokolle des App-Servers 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.

Überwachen Sie den Clusterstatus

Während der bevorstehenden Tests möchten Sie möglicherweise den Echtzeitstatus der Clusterknoten und -ressourcen anzeigen. Sie können dies mit diesem Befehl auf einem der beiden Load Balancer-Server tun (solange dieser ausgeführt wird):

sudo crm_mon

Die Ausgabe sollte ungefähr so ​​aussehen:

crm_mon output:Last updated: Thu Nov  5 13:51:41 2015
Last change: Thu Nov  5 13:51:27 2015 via cibadmin on primary
Stack: corosync
Current DC: secondary (2) - partition with quorum
Version: 1.1.10-42f2063
2 Nodes configured
3 Resources configured

Online: [ primary secondary ]

FloatIP (ocf::digitalocean:floatip):    Started primary
Clone Set: haproxy-clone [haproxy]
    Started: [ primary secondary ]

Hier sehen Sie, welche Load-Balancer-Knoten online sind und auf welchen Knoten die Ressourcen + FloatIP + und + haproxy + gestartet werden.

Beachten Sie, dass der Knoten, auf dem die Ressource "+ FloatIP " " Started +" ist (im obigen Beispiel * primary *), der Load-Balancer-Server ist, dem die Floating-IP derzeit zugewiesen ist. Wir bezeichnen diesen Server als * aktiven Load-Balancer-Server *.

Automatisieren Sie Anfragen an die Floating IP

Auf Ihrem lokalen Computer fordern wir den Webinhalt alle 2 Sekunden unter der Floating-IP-Adresse an. Auf diese Weise können wir leicht erkennen, wie der aktive Load Balancer eingehenden Datenverkehr verarbeitet. Das heißt, wir werden sehen, an welche Back-End-App-Server der Datenverkehr gesendet wird. Geben Sie in Ihrem lokalen Terminal den folgenden Befehl ein:

while true; do curl ; sleep 2; done

Alle zwei Sekunden sollte eine Antwort von einem der Back-End-App-Server angezeigt werden. Es wird wahrscheinlich zwischen * app-1 * und * app-2 * wechseln, da der von uns nicht angegebene Standard-Balance-Algorithmus von HAProxy auf * round-robin * eingestellt ist. Ihr Terminal sollte also ungefähr so ​​aussehen:

[secondary_label curl loop output:
Droplet: app-1, IP Address:
Droplet: app-2, IP Address:
...

Lassen Sie dieses Terminalfenster geöffnet, damit ständig Anfragen an Ihre Server gesendet werden. Sie werden in unseren nächsten Testschritten hilfreich sein.

Verfolgen Sie die Protokolle auf den Webservern

Auf jedem unserer Back-End-App-Server können wir den Speicherort "+ / var / log / nginx / access.log +" mit einem Tail versehen. 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-App-Server etwa die Hälfte der gestellten Anforderungen sehen.

Die Client-Adresse ist das allererste Feld im Zugriffsprotokoll, sodass es leicht zu finden ist. Führen Sie auf * beiden * Nginx-App-Servern (in separaten Terminalfenstern) Folgendes aus:

sudo tail -f /var/log/nginx/access.log

Das erste Feld sollte alle vier Sekunden die private IP-Adresse Ihres aktiven Load-Balancer-Servers anzeigen (wir gehen davon aus, dass es sich um den * primären * Load-Balancer handelt, in Ihrem Fall jedoch auch um den * sekundären *):

Output. . .
- - [05/Nov/2015:14:26:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
- - [05/Nov/2015:14:26:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

Halten Sie den Befehl "+ tail +" auf beiden App-Servern aktiv.

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

Starten Sie jetzt den primären Load Balancer neu, um sicherzustellen, dass das Floating IP-Failover funktioniert:

sudo reboot

Beachten Sie nun die Nginx-Zugriffsprotokolle auf beiden App-Servern. Sie sollten beachten, dass nach dem Floating IP-Failover in den Zugriffsprotokollen angezeigt wird, dass auf die App-Server über eine andere IP-Adresse zugegriffen wird als zuvor. Die Protokolle sollten anzeigen, dass der * sekundäre * Load Balancer-Server die Anforderungen sendet:

Output. . .
- - [05/Nov/2015:14:27:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
- - [05/Nov/2015:14:27:37 -0500] "GET / HTTP/1.1" 200 43 "-" "curl/7.43.0"
. . .

Dies zeigt, dass der Ausfall des primären Lastausgleichs erkannt und die Floating-IP erfolgreich dem sekundären Lastausgleich zugewiesen wurde.

Möglicherweise möchten Sie auch die Ausgabe Ihres lokalen Terminals überprüfen (das alle zwei Sekunden auf die Floating-IP zugreift), um sicherzustellen, dass der sekundäre Load Balancer Anforderungen an beide Back-End-App-Server sendet:

[secondary_label curl loop output:
Droplet: app-1, IP Address:
Droplet: app-2, IP Address:
...

Sie können das Failover auch in die andere Richtung versuchen, sobald der andere Load Balancer wieder online ist.

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 Anforderers anstelle des Load-Balancer-Servers zu protokollieren. Dies lässt sich leicht erreichen, indem Sie auf allen Back-End-App-Servern einige Änderungen an der Nginx-Konfiguration vornehmen.

Öffnen Sie auf beiden * App-Servern * die Datei + nginx.conf + in einem Editor:

sudo vi /etc/nginx/nginx.conf

Suchen Sie den Abschnitt "Logging Settings" (im Block "+ http +") und fügen Sie die folgende Zeile hinzu:

Fügen Sie /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 Namen "+ haproxy_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, das ist die IP-Adresse des Reverse-Proxy-Load-Balancers (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 App-Servern * die Serverkonfiguration + default +:

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

Fügen Sie innerhalb des "+ server" -Blocks (direkt unter der "+ listen" -Direktive eine gute Stelle) 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 im Protokollformat "+ haproxy_log +" zu schreiben, das wir kürzlich erstellt haben.

Starten Sie Nginx auf * beiden App-Servern * 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:  - ClientIP:  - - [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 App-Servern im Backend verteilen kann. Sie können diesen Pool leicht skalieren, wenn Ihre Nachfrage wächst oder schrumpft.

Die Floating IP- und Corosync / Pacemaker-Konfiguration beseitigt den Single Point of Failure 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 Anwendungsstapel hinter den HAProxy-Servern einrichten.

Related