Server Setup · 6 min read · Oct 08, 2025

Der perfekte Lastenausgeglichene & Hochverfügbarkeits-Webcluster mit 2 Servern, die Xen auf Ubuntu 8.04 Hardy Heron ausführen - Seite 6

12. Einrichtung der Lastenausgleicher (lb1, lb2)

12.1 IPVS auf den Lastenausgleichern aktivieren

Zuerst müssen wir IPVS auf unseren Lastenausgleichern aktivieren. IPVS (IP Virtual Server) implementiert Lastenausgleich auf Transportschicht innerhalb des Linux-Kernels, das sogenannte Layer-4 Switching.

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 machen wir Folgendes:

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

12.2 Ultra Monkey (Pakete) auf den Lastenausgleichern installieren

Installieren Sie Ultra Monkey (Pakete) auf den Lastenausgleichern, indem Sie Folgendes tun:

apt-get install ipvsadm ldirectord heartbeat

12.3 Paketweiterleitung auf den Lastenausgleichern aktivieren

Die Lastenausgleicher müssen in der Lage sein, den Verkehr zu den Apache-Knoten zu leiten. Daher müssen wir die Paketweiterleitung auf den Lastenausgleichern aktivieren. Fügen Sie die folgenden Zeilen zu /etc/sysctl.conf hinzu:

vi /etc/sysctl.conf

# Aktiviert die Paketweiterleitung
net.ipv4.ip_forward = 1

Dann machen Sie Folgendes:

sysctl -p

12.4 Heartbeat und ldirectord konfigurieren

Jetzt müssen wir drei Konfigurationsdateien für Heartbeat erstellen (vorsichtig mit Leerzeichen und Tabs, wenn Sie in einigen Texteditoren bearbeiten, ldirectord ist sehr wählerisch!):

auf lb1 und lb2

vi /etc/ha.d/ha.cf

logfacility local0
bcast eth0 # Linux
mcast eth0 225.0.0.1 694 1 0
auto_failback on
node lb1.example.com
node lb2.example.com
respawn hacluster /usr/lib/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster

Wichtig: Als Knotennamen müssen wir die Ausgabe von beiden verwenden:

uname -n

vi /etc/ha.d/haresources

lb1.example.com \
 ldirectord::ldirectord.cf \
 LVSSyncDaemonSwap::master \
 IPaddr2::192.168.1.106/24/eth0/192.168.1.255 \
 IPaddr2::192.168.1.107/24/eth0/192.168.1.255

Die IPs 192.168.1.106 und 107 werden später für Websites (example.com und yoursite.com) verwendet.

Diese Datei sollte auf beiden Knoten identisch sein, egal ob Sie die Datei auf lb1 oder lb2 erstellen!

vi /etc/ha.d/authkeys

auth 3 3 md5 somerandomstring

somerandomstring ist ein Passwort, das die beiden Heartbeat-Daemons auf lb1 und lb2 verwenden, um sich gegenseitig zu authentifizieren. Verwenden Sie hier Ihren eigenen String. Sie haben die Wahl zwischen drei Authentifizierungsmechanismen. Ich verwende md5, da ich glaube, dass es der sicherste ist.

/etc/ha.d/authkeys sollte nur für root lesbar sein, daher machen wir Folgendes:

chmod 600 /etc/ha.d/authkeys

ldirectord ist der eigentliche Lastenausgleicher. Wir werden unsere beiden Lastenausgleicher (lb1.example.com und lb2.example.com) in einem aktiven/passiven Setup konfigurieren, was bedeutet, dass wir einen aktiven Lastenausgleicher haben und der andere ein Hot-Standby ist und aktiv wird, wenn der aktive ausfällt. Damit es funktioniert, müssen wir die ldirectord-Konfigurationsdatei /etc/ha.d/ldirectord.cf erstellen, die wiederum auf lb1 und lb2 identisch sein muss.

vi /etc/ha.d/ldirectord.cf

checktimeout=5
checkinterval=5
autoreload=no
logfile="/var/log/ldirectord.log"
quiescent=no
#fork=yes

#FÜR SMTP
virtual=192.168.1.106:25
        real=192.168.1.104:25 gate
        fallback=192.168.1.105:25 gate
        service=none
        scheduler=wlc
        protocol=tcp
        checktype=connect
virtual=192.168.1.107:25
        real=192.168.1.104:25 gate
        fallback=192.168.1.105:25 gate
        service=none
        scheduler=wlc
        protocol=tcp
        checktype=connect

#FÜR DNS - CONNECT FUNKTIONIERT NICHT, MUSS PATCHEN, ABER PING IST OK
virtual=192.168.1.106:53
        real=192.168.1.104:53 gate
        fallback=192.168.1.105:53 gate
        service=none
        scheduler=wlc
        checktype=ping
        protocol=udp
virtual=192.168.1.106:53
        real=192.168.1.104:53 gate
        fallback=192.168.1.105:53 gate
        service=dns
        scheduler=wlc
        checktype=ping
        protocol=tcp
#FÜR HTTP
virtual=192.168.1.106:80
        real=192.168.1.104:80 gate
        real=192.168.1.105:80 gate
        service=http
        request="ldirectord.php"
        receive="Verbunden mit MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
        persistent=28800
virtual=192.168.1.107:80
        real=192.168.1.104:80 gate
        real=192.168.1.105:80 gate
        service=http
        request="ldirectord.php"
        receive="Verbunden mit MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
        persistent=28800

#FÜR WEBMAIL
virtual=192.168.1.106:81
        real=192.168.1.104:81 gate
        fallback=192.168.1.105:81 gate
        service=http
        request="ldirectord.php"
        receive="Verbunden mit MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
virtual=192.168.1.107:81
        real=192.168.1.104:81 gate
        fallback=192.168.1.105:81 gate
        service=http
        request="ldirectord.php"
        receive="Verbunden mit MySQL"
        scheduler=wlc
        protocol=tcp
        checktype=negotiate
#FÜR POP3
virtual=192.168.1.106:110
        real=192.168.1.104:110 gate
        fallback=192.168.1.105:110 gate
        service=pop
        checktype = connect
        scheduler=wlc
        protocol=tcp
#FÜR IMAP
virtual=192.168.1.106:143
        real=192.168.1.104:143 gate
        fallback=192.168.1.105:143 gate
        service=imap
        scheduler=wlc
        protocol=tcp
#FÜR HTTPS
###Kommentieren Sie diesen Teil aus, wenn Sie HTTPS verwenden möchten
#virtual=192.168.1.106:443
#        real=192.168.1.104:443 gate
#        real=192.168.1.105:443 gate 2
#        service=http
#        request="ldirectord.php"
#        receive="Verbunden mit MySQL"
#        scheduler=wlc
#        protocol=tcp
#        checktype=negotiate
#        persistent=28800
#
#virtual=192.168.1.107:443
#        real=192.168.1.104:443 gate
#        real=192.168.1.105:443 gate 2
#        service=http
#        request="ldirector.html"
#        receive="Testseite"
#        scheduler=wlc
#        protocol=tcp
#        checktype=negotiate
#        persistent=28800
#FÜR IMAP SSL
virtual=192.168.1.106:993
        real=192.168.1.104:993 gate
        fallback=192.168.1.105:993 gate
        service=imaps
        scheduler=wlc
        protocol=tcp
#FÜR POP3 SSL
virtual=192.168.1.106:995
        real=192.168.1.104:995 gate
        fallback=192.168.1.105:995 gate
        service=pops
        checktype = ping
        scheduler=wlc
        protocol=tcp
#FÜR MONIT ÜBERWACHUNG #1
virtual=192.168.1.106:10001
        real=192.168.1.104:10001 gate
        checktype = on
#FÜR MONIT ÜBERWACHUNG #2
virtual=192.168.1.106:20001
        real=192.168.1.105:20001 gate
        checktype = on

virtual ist die virtuelle IP der Dienste (z. B. 192.168.1.106 und 107)

real sind die realen Server-IP im Cluster (192.168.1.104 und 105)

fallback ist der Backup-Server. Wenn die reale IP ausfällt, werden die Anfragen an die Fallback-IP weitergeleitet, aber sie werden nicht lastenausgeglichen.

Diese Konfiguration basiert auf meiner persönlichen Erfahrung. Einige Dienste sind lastenausgeglichen, andere nicht. Alles, was mit Mail zu tun hat, ist nicht lastenausgeglichen. Sie möchten nicht, dass eine Nachricht auf dem ersten Server ankommt und die zweite auf dem anderen (es sei denn, Sie haben einen gemeinsamen Speicher). Wenn Sie keinen sehr hohen Mailverkehr haben, macht es keinen Sinn, Mail lastenauszugleichen (aber es ist immer noch hochverfügbar), das gleiche gilt für DNS. Später werden wir die Nachrichten auf dem zweiten Server mit rsync synchronisieren, sodass wir ein Backup haben, falls der erste Server ausfällt.

Über Port 81. Wir werden ihn für Webmail verwenden. Ich verwende ihn auch für die Verwaltung unserer E-Commerce-Website wegen des Bilduploads. Später werden wir rsync von web1.example.com nach web2.example.com einrichten, aber nicht umgekehrt. Grundsätzlich möchten Sie keine Datei auf web2.example.com hochladen (es sei denn, Sie verwenden gemeinsamen Speicher).

Wenn Sie weitere Informationen zu diesem Thema suchen, suchen Sie nach “ldirectord man”.

Danach erstellen wir die Systemstartlinks für Heartbeat und entfernen die von ldirectord, da ldirectord vom Heartbeat-Daemon gestartet wird:

update-rc.d -f ldirectord remove

Schließlich starten wir Heartbeat (und damit ldirectord):

/etc/init.d/ldirectord stop
/etc/init.d/heartbeat start

12.5 Testen der Lastenausgleicher

Lassen Sie uns überprüfen, ob beide Lastenausgleicher wie erwartet funktionieren:

ip addr sh eth0

Der aktive Lastenausgleicher lb1.example.com sollte die virtuellen IP-Adressen (192.168.1.106 und 192.168.1.107) auflisten:

2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.102/24 brd 192.168.1.255 scope global eth0
    inet 192.168.1.106/24 brd 192.168.1.255 scope global eth0
    inet 192.168.1.107/24 brd 192.168.1.255 scope global secondary eth0

Der Hot-Standby (lb2.example.com) sollte etwas wie folgt anzeigen:

2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0c:29:34:d7:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.103/24 brd 192.168.1.255 scope global eth0

Versuchen Sie nun:

ldirectord ldirectord.cf status

Ausgabe auf dem aktiven Lastenausgleicher (lb1):

ldirectord für /etc/ha.d/ldirectord.cf läuft mit pid: 5321

Ausgabe auf dem Hot-Standby-Lastenausgleicher (lb2):

ldirectord ist gestoppt für /etc/ha.d/ldirectord.cf

Jetzt werden wir überprüfen, ob die Ports korrekt weitergeleitet werden:

ipvsadm -L -n | grep :80

Sie sollten etwas wie folgt auf lb1.example.com sehen:

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.1.106:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0
TCP  192.168.1.107:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0

Und nichts auf lb2.example.com.

Ein letzter Test:

/etc/ha.d/resource.d/LVSSyncDaemonSwap master status

Ausgabe auf dem aktiven Lastenausgleicher:

master läuft (ipvs_syncmaster pid: 5470)

Ausgabe auf dem Hot-Standby:

master gestoppt

12.6 Testen des Failovers der Lastenausgleicher

lb1.example.com

/etc/init.d/heartbeat stop

Der ipvsadm-Befehl:

ipvsadm -L -n | grep :80

sollte nichts ausgeben.

Auf lb2.example.com

ipvsadm -L -n | grep :80

und Sie sollten Folgendes sehen:

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.1.106:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0
TCP  192.168.1.107:80 wlc
  -> 192.168.1.104:80               Route   1      0          0         
  -> 192.168.1.105:80               Route   0      0          0

Starten Sie den Heartbeat-Dienst auf lb1.example.com:

/etc/init.d/heartbeat start

Wenn Sie den ipvsadm-Befehl auf beiden erneut versuchen, werden Sie sehen, dass lb1.example.com jetzt aktiv ist, während lb2.example.com wieder im Standby ist.

Wenn Ihr Test gut verlief, können Sie fortfahren.

Share: X/Twitter LinkedIn
#Server Setup

Erhalte neue Beiträge in deinem Posteingang.

Kein Spam. Jederzeit abmelden.