Wie man ein hochverfügbares Apache Cluster (inkl. Loadbalancer) aufsetzt

Version 1.0
Author: Falko Timme

Diese Anleitung veranschaulicht, wie man ein Apache Web Server Cluster, bestehend aus zwei Systemen aufsetzt, das hochverfügbar ist. Vor dem Apache Cluster erstellen wir einen Load Balancer, der eingehende Anfragen auf die beiden Apache Systeme aufteilt. Da wir nicht wollen, dass der Load Balancer ein weiterer "Single Point Of Failure" wird, müssen wir auch für den Load Balancer eine Hochverfügbarkeit bereitstellen. Daher wird unser Load Balancer tatsächlich aus zwei Load Balancer Systemen bestehen, die sich gegenseitig mittels heartbeat überwachen. Wenn ein Load Balancer ausfällt,  übernimmt der anders stillschweigend.

Der Vorteil gegenüber dem Load Balancer im Vergleich zu round robin DNS besteht darin, dass er auf die Last auf den Web Server Systemen aufpasst und versucht, Anfragen an das System mit der niedrigsten Last zu leiten. Weiterhin passt er auf Verbindungen/Sitzungen auf. Viele Web Anwendungen (z.B. Forum Software, Einkaufswagen, etc.) machen von Sessions Gebrauch. Wenn Du Dich in einer Session auf dem Apache System 1 befindest, würdest Du dieses Session verlieren, wenn System 2 plötzlich Deine Anfragen bedienen würde. Falls eines der Apache Systeme ausfällt, bermerkt das der Load Balancer und leitet alle eingehende Anfragen an das anders System weiter, was mit round robin DNS nicht möglich wäre.

Für dieses Setup benötigen wir vier Systeme (zwei Apache Systeme und zwei Load Balancer Systeme) und fünf IP Adressen: Eine für jedes System und eine virtuelle IP Adresse, die sich die Load Balancer Systeme teilen und die für eingehende HTTP Anfragen verwendet wird.

Ich werde folgendes Setup verwenden:

  • Apache System 1: webserver1.example.com (webserver1) - IP Adresse: 192.168.0.101; Apache Dokumenten-Root: /var/www
  • Apache System 2: webserver2.example.com (webserver2) - IP Adresse: 192.168.0.102; Apache Dokumenten-Root: /var/www
  • Load Balancer System 1: loadb1.example.com (loadb1) - IP Adresse: 192.168.0.103
  • Load Balancer System 2: loadb2.example.com (loadb2) - IP Adresse: 192.168.0.104
  • Virtuelle IP Adresse: 192.168.0.105 (für eingehende Anfragen)

Sieh Dir die Zeichnung http://www.linuxvirtualserver.org/docs/ha/ultramonkey.html an um nachvollziehen zu können, wie dieses Setup aussieht.

In dieser Anleitung werde ich für alle vier Systeme Debian Sarge verwenden. Ich gehe davon aus, dass Du auf allen vier Systemen Debian grundinstalliert hast und dass Du Apache auf webserver1 und webserver2 mit /var/www als Dokumenten-Root der Haupt-Webseite installiert hast.

Ich möchte darauf hinweisen, dass dies nicht der einzige Weg ist, ein solches System einzurichten. Es gibt viele Möglichkeiten dieses Ziel zu erreichen - dies ist der Weg, den ich gewählt habe. Ich übernehme keine Garantie, dass dies auch bei Dir funktioniert!

1 IPVS auf den Load Balancern aktivieren

Zuerst müssen wir IPVS auf unseren Load Balancern aktivieren. IPVS (IP Virtual Server) implementiert transport-layer load balancing im Linux Kernel, sogenanntes Layer-4 switching.

loadb1/loadb2:

echo ip_vs_dh >> /etc/modules
echo ip_vs_ftp >> /etc/modules
echo ip_vs >> /etc/modules
echo ip_vs_lblc >> /etc/modules
echo ip_vs_lblcr >> /etc/modules
echo ip_vs_lc >> /etc/modules
echo ip_vs_nq >> /etc/modules
echo ip_vs_rr >> /etc/modules
echo ip_vs_sed >> /etc/modules
echo ip_vs_sh >> /etc/modules
echo ip_vs_wlc >> /etc/modules
echo ip_vs_wrr >> /etc/modules

Dann führen wir dies aus:

loadb1/loadb2:

modprobe ip_vs_dh
modprobe ip_vs_ftp
modprobe ip_vs
modprobe ip_vs_lblc
modprobe ip_vs_lblcr
modprobe ip_vs_lc
modprobe ip_vs_nq
modprobe ip_vs_rr
modprobe ip_vs_sed
modprobe ip_vs_sh
modprobe ip_vs_wlc
modprobe ip_vs_wrr

Wenn Du Fehlermeldungen erhältst,  dann wurde Dein Kernel vermutlich nicht mit IPVS Untertsützung kompiliert, also musst Du jetzt einen neuen Kernel mit IPVS Unterstützung kompilieren (oder ein Kernel Image mit IPVS Unterstützung installieren).

2 Installation von Ultra Monkey auf den Load Balancern

Mit dem Ultra Monkey Projekt kann man Load balanced und hoch-verfügbare Dienste auf einem lokalen Area Netzwerk mit Open Source Komponenten auf dem Linux Betriebssystem erstellen; das Ultra Monkey Paket stellt heartbeat (wird von den beiden Load Balancern verwendet um sich gegenseitig zu überwachen und zu überprüfen ob das anders System noch da ist) und ldirectord bereit, den eigentlichen Load Balancer.

Um Ultra Monkey zu installieren, müssen wir  /etc/apt/sources.list bearbeiten und diese beiden Zeilen (entferne nicht die anderen Paketdatenbanken) hinzufügen:

loadb1/loadb2:

vi /etc/apt/sources.list

 

deb http://www.ultramonkey.org/download/3/ sarge main
deb-src http://www.ultramonkey.org/download/3 sarge main
Danach führen wir dies aus:

loadb1/loadb2:

apt-get update

und installieren Ultra Monkey:

loadb1/loadb2:

apt-get install ultramonkey

Wenn diese Warnung auftaucht:
  ¦ libsensors3 not functional                                               ¦
¦ ¦ ¦ It appears that your kernel is not compiled with sensors support. As a ¦ ¦ result, libsensors3 will not be functional on your system. ¦ ¦ ¦ ¦ If you want to enable it, have a look at "I2C Hardware Sensors Chip ¦ ¦ support" in your kernel configuration. ¦
kannst Du sie ignorieren.

Während der Ultra Monkey Installation werden Dir ein paar Fragen gestellt. Antworte wie folgt:

Do you want to automatically load IPVS rules on boot?
No
Select a daemon method.
none

3 Paket-Weiterleitung auf den Load Balancern aktivieren

Die Load Balancer müssen in der Lage sein, Datenverkehr zu den Apache Systemen zu leiten. Dafür müssen wir die Paket-Weiterleitung auf den Load Balancern aktivieren. Füge folgende Zeilen /etc/sysctl.conf hinzu:

loadb1/loadb2:

vi /etc/sysctl.conf


# Enables packet forwarding
net.ipv4.ip_forward = 1
Führe dann dies aus:

loadb1/loadb2:

sysctl -p


4 Konfiguriere heartbeat und ldirectord

Nun müssen wir drei Konfigurationsdateien für heartbeat erstellen. Sie müssen auf loadb1 und loadb2 identisch sein!

loadb1/loadb2:

vi /etc/ha.d/ha.cf


logfacility        local0
bcast eth0 # Linux mcast eth0 225.0.0.1 694 1 0 auto_failback off node loadb1 node loadb2 respawn hacluster /usr/lib/heartbeat/ipfail apiauth ipfail gid=haclient uid=hacluster
Wichtig: Als Systemnamen müssen wir die Ausgabe von

uname -n

auf loadb1 und loadb2 verwenden.

loadb1/loadb2:

vi /etc/ha.d/haresources


loadb1
ldirectord::ldirectord.cf LVSSyncDaemonSwap::master IPaddr2::192.168.0.105/24/eth0/192.168.0.255
Das erste Wort ist die Ausgabe von

uname -n

auf loadb1, egal ob Du die Datei auf loadb1 oder loadb2 erstellst! Nach IPaddr2 fügen wir unsere virtuelle IP Adresse 192.168.0.105 ein.

loadb1/loadb2:

vi /etc/ha.d/authkeys


auth 3
3 md5 somerandomstring
somerandomstring ist ein Passwort, das die beiden heartbeat Daemons auf loadb1 und loadb2 verwenden, um sich gegeneinander zu authentifizieren. Verwende hier Deine eigene Zeichenfolge. Du hast die Wahl zwischen drei Authentifizierungsmechanismen. Ich verwende md5 da es der sicherste ist.

/etc/ha.d/authkeys sollte nur vom Root-Benutzer gelesen werden können, daher führen wir dies aus:

loadb1/loadb2:

chmod 600 /etc/ha.d/authkeys

ldirectord ist der eigentliche Load Balancer. Wir werden unsere beiden Load Balancer (loadb1.example.com und loadb2.example.com) in einem aktiven/passiven Setup konfigurieren, was bedeutet, dass wir einen aktiven Load Balancer haben, der andere ist ein Hot-standby und wird dann aktiv, wenn der aktive Load Balancer ausfällt. Damit dies funktioniert müssen wir die ldirectord Konfigurationsdatei /etc/ha.d/ldirectord.cf erstellen, die auch wieder auf loadb1 und loadb2 identisch sein muss.

1 Kommentar(e)

Zum Posten von Kommentaren bitte

Kommentare

Von: castro

Tolle Anleitung und ein gutes System, hab es auch unter lenny nach bauen können. Allerdings funktioniert bei mir das Session Management nicht, da ich wild auf alle Nodes verteilt werde. Hängt das mit "scheduler=rr" zusammen?