Für die Testumgebung mit der Softwarelösung ldirectord als LoadBalancer wurden vier Server mit openSUSE Leap 15.3 installiert. Namentlich werden die Server wie folgt aufgeteilt:
- Drei virtuelle Server (Applikationsserver) mit laufenden Webservice (Apache2)
- Ein virtuellen Server mit laufenden LoadBalancer ldirectord
- Applikationsserver
hyper-v-client01 – openSUSE Leap 15.3
hyper-v-client02 – openSUSE Leap 15.3
hyper-v-client03 – openSUSE Leap 15.3
Folgende Softwaresammlungen wurden auf den Applikationsservern installiert:
zypper se -t pattern
Um etwaige Schwierigkeiten bezüglich der Freigabe der Ports zu vermeiden, wurde die Linux basierte Firewall deaktiviert und sollte auch nach einem Neustart nicht mehr gestartet werden:
systemctl status firewalld.service
systemctl disable firewalld.service
systemctl stop firewalld.service
systemctl status firewalld.service
Unsere Applikationsserver können leider nicht ohne Weiteres die Anfragen, die vom Load Balancer kommen verarbeiten. Immerhin wird ja die Anfrage direkt an die IP 192.168.178.250 gestellt, welche ja auf den Systemen nicht bekannt ist. Damit das funktioniert, muss die Service-IP auf den Applikationsservern noch als Loopbackdevice gebunden werden, damit sich der Applikationsserver auch angesprochen fühlt. Jedoch Vorsicht: Nicht einfach so die Service IP als Loopback einbinden! Das würde dazu führen, dass der Applikationsserver ARP-Anfragen mit seiner MAC-Adresse beantwortet, was wir ja nicht wollen. Das könnte den gesamten Dienst still legen. Hier muss im Vorfeld noch folgendes in die /etc/sysctl.conf eingetragen und mit sysctl -p übernommen werden, was das Verhalten unterbindet:
Nachdem die Kernelparameter übernommen wurden, kann jetzt die Service IP als Loopbackdevice gestartet werden:
ip address show
ip address add 192.168.178.250/32 brd + dev lo
und erneut anzeigen mit
ip address show
Damit der die IP Adresse auch nach einem Neustart gesetzt wird, sollte man die Service IP im OS fest verankern. Ich persönlich bevorzuge das Editieren der Konfigurationsdatei des entsprechenden Netzwerkinterfaces. Dazu wechselt man, unter openSUSE Leap 15.3, in das Verzeichnis /etc/sysconfig/network und editiert die Datei ifcfg-lo.
Vorher:
Nachher:
Nach einem Neustart des Servers sollte die Netzwerkumgebung jetzt so aussehen:
ip addr show
Als nächstes wenden wir uns den Webservice zu, damit wir den LoadBalancer später auch sinnvoll nutzen können. Dafür benötigen wir ein HTTP Server. In unserem Fall Fall nutze ich den Apache Server, welcher in den Installationssourcen von openSUSE enthalten ist.
zypper in apache2
Nach der Installation muss der Webservice gestartet werden. In der Regel sollte dieser Webservice auch nach einen Neustart automatisch gestartet sein:
systemctl status apache2
systemctl enable apache2
systemctl start apache2
systemctl status apache2
Je nach der Wahl des Betriebssystemes ist der Pfad zu den darzustellenden Webinhalten unterschiedlich. Im Fall von Leap 15.3 befindet sich das Homeverzeichnis für die Webdateien unter /srv/www/htdocs. In diesem Verzeichnis erzeugen wir nun eine Datei mit den Namen test.html und den Inhalt „still alive“. Warum? Dazu später.
Nun kann man sich die Datei im Browser anzeigen lassen:
http://hyper-v-client01:80/test.html
Diese Einstellungen sollten für alle drei Applikationsserver gleich sein.
2. LoadBalancer
hyper-v-client04 – openSUSE Leap 15.3
Folgende Softwaresammlungen wurden auf den LoadBalancer (analog zu den Applikationsservern) installiert:
Zur Vorbereitung des LoadBalancer müssen zwei Pakete zusätzlich installiert werden. Ich habe mich bewusst für den ldirectord entschieden. Zum Einem, weil die Pakete auch in der Softwaresammlung von SUSE enthalten sind. Und außerdem ist in der Dokumentation „openSUSE / Kubernetes“ immer vom LoadBalancer ldirectord die Rede.
zypper in ipvsadm
zypper in ldirectord
Die Konfiguration für den ldirectord ist überraschend einfach. Man wechselt in das Verzeichnis /etc/ha.d und editiert die Datei ldirectord.cf wie folgt:
Nun wird die Service IP 192.168.178.250/32 (analog zu den Applikationsservern) als zusätzliches Loopbackdevice gesetzt:
ip addr add 192.168.178.250/32 brd + dev lo
Um das Loopbackdevice nach einem Neustart nutzen zu können, müssen wir in das Verzeichnis /etc/sysconfig/network wechseln und müssen die Datei ifcfg-lo editieren:
Vorher:
Nachher:
Dasselbe gilt auch für den LoadBalancer ldirectord:
Anzeigen Status: systemctl status ldirectord
Aktivieren nach den Neustart: systemctl enable ldirectord
Anzeigen Status: systemctl status ldirectord
Starten des LoadBalancer: systemctl start ldirectord
Erneutes Anzeigen: systemctl status ldirectord
Mit den Tool ipvsadm kann man sich eine Übersicht über Service IP und den Applikationsserver anzeigen lassen:
ipvsadm -L -n
Wenn man die Serviceadresse im Browser mehrfach aufruft, sollte dieses nun zu sehen sein:
Und in der Konsole sollte auch eine Änderung in der Übersicht zu sehen sein:
Quellen:
Load Balancing mit dem Raspberry Pi – ein kleines Praxisbeispiel mit ldirectord – NETWAYS GmbH