Der fünfte Teil der Artikelreihe: Hochverfügbarkeit und Lastverteilung mit keepalived und ipvsadm unter Debian GNU/Linux

Konfiguration des Webservers

Wir gehen davon aus, dass auf den Servern die als Webserver eingesetzt werden sollen, bereits das Linux-Betriebssystem, Apache2, PHP5 usw. installiert ist. Nun folgt die Erweiterung des Netzwerkkonfiguration.

Zunächst muss das dummy-Modul geladen werden, so daß auf dem System auch das Interface dummy0 zur Verfügung steht.

root@webserver01:~# modprobe dummy
root@webserver01:~# echo dummy >> /etc/modules

Die Datei /etc/network/interfaces muss nun um die Konfiguration für dummy0-Interfaces erweitert werden:

auto dummy0
iface dummy0 inet static
address 198.19.253.1
netmask 255.255.255.255
up /sbin/ifconfig dummy0 add 198.19.254.1/32
up /sbin/ifconfig dummy0 inet6 add 2a00:e10:1000:7:124::a1/128
up /sbin/ifconfig dummy0 inet6 add 2a00:e10:1000:7:124::b1/128
pre-up sysctl -p > /dev/null

Jetzt müssen einige Kernelparameter in der Datei /etc/sysctl.conf geändert werden, damit diese nach einem Neustart wieder zur Verfügung stehen:

net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.dummy0.arp_ignore = 1
net.ipv4.conf.dummy0.arp_announce = 2

Als nächstes folgt die Konfiguration der VHost, worauf ich aber nicht näher eingehen möchte.

Im DocumentRoot-Verzeichnes des Default-VHost lege ich die Datei ldcheck.php ab. Diese Datei ist ein kleines PHP-Skript. Das Skript überprüft die Verbindung zu einem lokalen MySQL-Server. Ist die Verbindung erfolgreich, wird der Status „running“ als Rückgabewert ausgegeben. Dieses Skript wird zur Überprüfung der Erreichbarkeit des Zielhosts benötigt. Siehe dazu „4. Block – Virtuelle Server“.

Hier der Sourcecode des Skriptes:

<?php

@header(„Content-Type: text/plain“);

$active = true;
#$active = false;

if ($active && ($link = @mysql_connect(‚localhost‘, ‚dbuser‘, ‚dbpass‘, ‚test‘)) !== false)
{
@mysql_close($link);
echo „running“;
}
else
{
echo „error“;
}

?>

Dies Konfiguration ist nun abgeschlossen. Zum Schluss möchte ich noch kurz auf den Funktionsablauf beim Load Balancing per „direct routing“ eingehen:

Die Anfragen kommen am Load Balancer an, der die Ziel MAC-Adresse in den Paketen abändert. Sehen wir uns diesen Prozess im Detail an:

1. Eine Anfrage kommt beim Load Balancer auf Port 80 an, da er auf seinem Interface die angefragte IP-Adresse gebunden hat.

2. Der Load Balancer ändert das Paket ab, in dem er die MAC-Adresse eines der Web-Server als Ziel einträgt. Anschließend kommt das geänderte Paket wieder auf das Ethernet.

3. Einer der Web-Server erhält das Paket auf z.B. eth0, jedoch mit einer IP die auf einem dummy-Interface gebunden ist, tut was ein Web-Server eben tut und schickt die Antwort an an den Client zurück. Das Paket erhält als Absender-IP die auf dummy gebundene IP.

4. Je nach Konfiguration (persistent=) behält der Load Balancer die Information auf welchen Web-Server er den Client geschickt hat eine Weile bei oder entfernt diesen Eintrag aus der Adress-Tabelle.

Notwendig für die Funktion dieses Workflows ist, daß alle Maschinen sich im gleichen Layer 2 Segment befinden. Zwischen dem Load Balancer und den Web-Servern darf bei „direct routing“ kein Router stehen. [Z. 1]

Zitatquelle:
1.  http://blogs.interdose.com/sebastian/2011/03/07/hochverfugbarkeit-mit-linux-teil-6/

Ein Kommentar

  1. 1

    […] hier den Originalbeitrag weiterlesen: Hochverfügbarkeit und Lastverteilung mit keepalived und ipvsadm … […]

Was denkst du?


Zustimmung zur Datenspeicherung lt. DSGVO