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:

  1. Drei virtuelle Server (Applikationsserver) mit laufenden Webservice (Apache2)
  2. Ein virtuellen Server mit laufenden LoadBalancer ldirectord
  1. 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:

Dieses Bild hat ein leeres Alt-Attribut. Der Dateiname ist image.png

Nachher:

Dieses Bild hat ein leeres Alt-Attribut. Der Dateiname ist image-1.png

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