ADMIN
2023
09
2023-08-30T12:00:00
Hochverfügbarkeit und Monitoring
SCHWERPUNKT
071
Loadbalancing
Hochverfügbarkeit
Loadbalancing mit Seesaw v2
Schnelles Hin und Her
von Dr. Holger Reibold
Veröffentlicht in Ausgabe 09/2023 - SCHWERPUNKT
Ein Aspekt der Hochverfügbarkeit ist sicherzustellen, dass auch bei Höchstlast die maximale Performance eines Systems gegeben ist. Das leisten Tools, die die Zugriffe intelligent auf die verschiedenen Server verteilen. Ist besonders performantes Loadbalancing gefragt, kommt Seesaw v2 ins Spiel. Denn der von Google entwickelte Lastverteiler arbeitet nur bis Layer 4 und kann somit schneller agieren als die Kollegen HAProxy oder Nginx.

Lastverteilung ist ein Muss, um die Verfügbarkeit und Skalierbarkeit von Geschäftsanwendungen sicherzustellen. Das Prinzip ist im Grunde genommen einfach, aber genial zugleich: Der Loadbalancer stellt den Zugriff auf die Server über einen Lastausgleichsalgorithmus bereit und bei Bedarf lässt sich der Serverpool um zusätzliche Server erweitern – der Endanwender bekommt von all dem nichts mit.
Der Loadbalancer agiert dabei als Reverse-Proxy und erlaubt den Serverzugriff über virtuelle IP-Adressen. Die Einsatzmöglichkeiten sind vielfältig: Neben der eigentlichen Lastverteilung sind Loadbalancer in der Lage, Serverausfälle automatisch zu erkennen und den Traffic entsprechend umzuleiten. Auch die Wartung einzelner Server vereinfacht sich, da Admins diese aus dem Pool lösen, die notwendigen Wartungsarbeiten ohne Beeinträchtigungen der Umgebung durchführen und dann wieder in die Struktur einfügen können. Außerdem lassen sich Backupserver automatisch einbinden und Applikationsserver ohne Unterbrechungen aus dem Verbund hinzufügen oder entfernen.
Lastenausgleich auf Layer 4
Der Name unseres Loadbalancers Seesaw [1] bedeutet so viel wie das "Hin und Her", und damit ist im Grunde auch schon erklärt, was dieser Open-Source-Spezialist macht. Die Software ist eine Loadbalancer-Implementierung, die auf dem Linux-Virtual-Server-Projekt basiert. Aus diesem Grund unterscheidet sich Seesaw von HAProxy oder Nginx, die bis zur OSI-Schicht 7 arbeiten können, während Seesaw als OSI-Layer-4-Loadbalancer funktioniert. Das bedeutet, dass dieses Tool zwar UDP-, TCP-, SCTP-, AH- und ESP-Verkehr verarbeiten kann, aber nicht weit genug in den OSI-Stack vordringt, um Funktionen wie HTTP-Header-Introspektion, TLS-Terminierung und so weiter zu verarbeiten. Der Vorteil beim Einsatz auf Layer 4 ist jedoch ein sehr schnelles Loadbalancing.
Lastverteilung ist ein Muss, um die Verfügbarkeit und Skalierbarkeit von Geschäftsanwendungen sicherzustellen. Das Prinzip ist im Grunde genommen einfach, aber genial zugleich: Der Loadbalancer stellt den Zugriff auf die Server über einen Lastausgleichsalgorithmus bereit und bei Bedarf lässt sich der Serverpool um zusätzliche Server erweitern – der Endanwender bekommt von all dem nichts mit.
Der Loadbalancer agiert dabei als Reverse-Proxy und erlaubt den Serverzugriff über virtuelle IP-Adressen. Die Einsatzmöglichkeiten sind vielfältig: Neben der eigentlichen Lastverteilung sind Loadbalancer in der Lage, Serverausfälle automatisch zu erkennen und den Traffic entsprechend umzuleiten. Auch die Wartung einzelner Server vereinfacht sich, da Admins diese aus dem Pool lösen, die notwendigen Wartungsarbeiten ohne Beeinträchtigungen der Umgebung durchführen und dann wieder in die Struktur einfügen können. Außerdem lassen sich Backupserver automatisch einbinden und Applikationsserver ohne Unterbrechungen aus dem Verbund hinzufügen oder entfernen.
Lastenausgleich auf Layer 4
Der Name unseres Loadbalancers Seesaw [1] bedeutet so viel wie das "Hin und Her", und damit ist im Grunde auch schon erklärt, was dieser Open-Source-Spezialist macht. Die Software ist eine Loadbalancer-Implementierung, die auf dem Linux-Virtual-Server-Projekt basiert. Aus diesem Grund unterscheidet sich Seesaw von HAProxy oder Nginx, die bis zur OSI-Schicht 7 arbeiten können, während Seesaw als OSI-Layer-4-Loadbalancer funktioniert. Das bedeutet, dass dieses Tool zwar UDP-, TCP-, SCTP-, AH- und ESP-Verkehr verarbeiten kann, aber nicht weit genug in den OSI-Stack vordringt, um Funktionen wie HTTP-Header-Introspektion, TLS-Terminierung und so weiter zu verarbeiten. Der Vorteil beim Einsatz auf Layer 4 ist jedoch ein sehr schnelles Loadbalancing.
Ursprünglich stammt Seesaw aus dem Hause Google, das 2012 zwei verschiedene Loadbalancer einsetzte, die sich allerdings angesichts spezifischer Management- und Stabilitätsherausforderungen als ungeeignet erwiesen. Da sich keine brauchbare Alternative fand, entwickelte Google kurzerhand eine eigenes Werkzeug, das in der Lage sein sollte, den Datenverkehr für Unicast- und Anycast-VIPs (virtuelle IP-Adressen) zu verarbeiten, einen Lastausgleich sowie angemessene Gesundheitsprüfungen für die Backends durchzuführen.
Außerdem sollte die Plattform einfach zu administrieren sein und beispielsweise automatisierte Deployments von Konfigurationsänderungen unterstützen. Die Entwickler entschieden sich, das Tool in Go zu programmieren, das sich aufgrund der leistungsstarken Optionen zur Implementierung von Parallelroutinen und der einfachen Interprozess-Kommunikation besonders eignet. Für den Einsatz von Go sprach auch, dass sich eine modulare Multiprozessarchitektur implementieren ließ und sich Prozesse einfach abbrechen beziehungsweise beenden lassen, was im Idealfall einen Failover und die Selbstwiederherstellung ermöglicht. Und somit steht Seesaw seit 2016 quelloffen über GitHub zur Verfügung.
Für Seesaw notwendige Module laden
Bevor Sie Seesaw v2 einsetzen, müssen Sie verschiedene Voraussetzungen erfüllen. Zunächst benötigen Sie mindestens zwei Seesaw-Knoten, wobei es sich um physische Maschinen oder virtuelle Instanzen handeln kann. Jeder Knoten muss über zwei Netzwerkschnittstellen verfügen – eine für den Host selbst und die andere für die Cluster-VIP. Alle Schnittstellen sollten mit demselben Layer-2-Netz- werk verbunden sein. Außerdem müssen Sie sicherstellen, dass folgende Kernel-Module geladen werden:
- ip_vs: Hierbei handelt es sich um das IP-Virtual-Server-Modul, das der Transportschichtumschaltung innerhalb des Linux-Kernels dient.
- nf_conntrack_ipv4: Dieses Modul nutzt der Linux-Kernel, um den Status aller logischen Netzwerkverbindungen aufrechtzuerhalten und Pakete den Sitzungen zuzuordnen.
- Dummy: Schließlich benötigen Sie ein virtuelles Netzwerkgerät, dem sich Routen zuweisen lassen, das jedoch keine Pakete überträgt.
Jedes dieser Kernel-Module sollte vorhanden sein, bevor der Seesaw-Prozess startet. Sie laden diese manuell mit den folgenden Befehlen:
modprobe ip_vs
modprobe nf_conntrack_ipv4
modprobe dummy numdummies=1
Allerdings werden in diesem Fall die Module nicht dauerhaft geladen und wären bei jedem Kernel-Start neu zu laden. Stattdessen können Sie auch mit Modprobe-Konfigurationsdateien arbeiten. Diese befinden sich üblicherweise unter dem Pfad "/etc/modprobe.d". Hier legen Sie für jedes Modul eine Datei mit der Bezeichnung "modulname.conf" an:
echo options ip_vs > /etc/modprobe.d/ip_vs.conf
echo options nf_conntrack_ipv4 > /etc/modprobe.d/nf_conntrack_ipv4.conf
echo options dummy numdummies=1 > /etc/modprobe.d/dummy.conf
Beachten Sie bei dieser Vorgehensweise, dass die verschiedenen Module nur beim Booten des Systems geladen werden.
Noch einfacher und zuverlässiger funktioniert der Vorgang mit "systemd". Dazu bedienen Sie sich des "/etc/modules.load.d"-Mechanismus. Damit systemd die drei Module automatisch lädt, gehen Sie wie folgt vor:
echo ip_vs > /etc/modules.load.d /ip_vs.conf
echo nf_conntrack_ipv4 > /etc/modules.load.d/nf_conntrack_ipv4.conf
echo dummy numdummies=1 > /etc/modules.load.d/dummy.conf
Damit haben Sie die Konfigurationsdateien zum Laden der Kernel-Module beim Booten angelegt. Sie können diese Modifikationen auch unmittelbar vornehmen:
systemctl restart systemd-modules-load.service
Anwender von RHEL- und CentOS-Systemen sollten beachten, dass dieser Dienst standardmäßig nur mit der Kernel-Fähigkeit "CAP_SYS_MODULE" ausgestattet ist. Dieser genügt nicht für das Laden des Kernel-Moduls "ip_vs".
Nachdem Sie die drei Module geladen haben, startet Seesaw, was Sie mit folgendem Befehl prüfen:
seesaw_watchdog -logtostderr
Go in Betrieb nehmen
Da Seesaw v2 auf Go basiert, müssen Sie vor der eigentlichen Installation die Verfügbarkeit verschiedener Go-Pakete sicherstellen und sie gegebenenfalls einspielen:
- golang.org/x/crypto/ssh
- github.com/dlintw/goconf
- github.com/golang/glog
- github.com/golang/protobuf/proto
- github.com/miekg/dns
Zusätzlich bestehen Kompilier- und Laufzeitabhängigkeiten von "libnl" [2]. Die notwendigen Voraussetzungen schaffen Sie auf einem Debian-basierten System mit den Kommandos:
apt-get install golang
apt-get install libnl-3-dev libnl-genl-3-dev
Wichtig ist außerdem, dass Sie eine Go-Version ab 1.18 benötigen [3]. Stellen Sie als Nächstes sicher, dass sich "${GOPATH}/bin" in Ihrem "${PATH}"- und im Seesaw-Verzeichnis befindet:
make test
make install
Optional können Sie die Funktionsweise der Golang-Umgebungen mit go
oder go env
testen. Damit sind die wesentlichen Voraussetzungen für die Seesaw-Installation erfüllt.
Seesaw einspielen
Vor der eigentlichen Installation raten die Seesaw-Entwickler dazu, den Protobuf-Code neu zu generieren. Beim Protocol Buffer handelt es sich um einen sprach- und plattformneutralen, erweiterbaren Mechanismus zur Serialisierung strukturierter Daten und er wird insbesondere für Programme für die Kommunikation und Datenspeicherung über bestimmte Netzwerke verwendet.
Seesaw nutzt den Protobuf-Compiler, um die erforderlichen Daten von einem Webbrowser zu verarbeiten. Der Compiler kombiniert die ".proto"-Dateien und sprachspezifische Bibliotheken, um eine Datei zu schreiben, die über eine Netzwerkverbindung gesendet werden kann. Installieren Sie zunächst den Protobuf-Compiler:
apt-get install protobuf-compiler
Den protobuf-Code regenerieren Sie dann über make proto
.
Zur Installation erzeugen Sie das Skript "seesaw_install" (Listing 1) in diesem Verzeichnis und führen es aus. Anschließend ist Seesaw grundsätzlich einsatzbereit und Sie können sich an die notwendigen Anpassungen der Konfiguration machen.
Listing 1: Installatiosskript
SEESAW_BIN="/usr/local/seesaw"
SEESAW_ETC="/etc/seesaw"
SEESAW_LOG="/var/log/seesaw"
INIT=`ps -p 1 -o comm=`
install -d "${SEESAW_BIN}" "${SEESAW_ETC}" "${SEESAW_LOG}""
install "${GOPATH}/bin/seesaw_cli" /usr/bin/seesaw
for component in {ecu,engine,ha,healthcheck,ncc,watchdog}; do install "${GOPATH}/bin/seesaw_${component}" "${SEESAW_BIN}"
done
if [ $INIT = "init" ]; then install "etc/init/seesaw_watchdog.conf" "/etc/init"
elif [ $INIT = "systemd" ]; then install "etc/systemd/system/seesaw_watchdog.service" "/etc/systemd/system" systemctl --system daemon-reload
fi
install "etc/seesaw/watchdog.cfg" "${SEESAW_ETC}"
# Aktivieren Sie CAP_NET_RAW für Seesaw-Binärdateien, die Raw-Sockets benötigen.
/sbin/setcap cap_net_raw+ep "${SEESAW_BIN}/seesaw_ha"
/sbin/setcap cap_net_raw+ep "${SEESAW_BIN}/seesaw_healthcheck"
Integration in Anthos
Seesaw eröffnet eine Fülle von Anwendungsmöglichkeiten und es verwundert nicht, dass es inzwischen auch in verschiedenen kommerziellen Produkten zum Einsatz kommt. So ist Seesaw beispielsweise im "Anthos Cluster on VMware" integriert. Anthos ist eine cloudbasierte Containerplattform, die drei Formen des Loadbalancing unterstützt: integriert, manuell oder gebündelt. Im gebündelten Modus verwendet Anthos den Seesaw-Loadbalancer. Unter Anthos stellt Seesaw verschiedene Messwerte bereit, beispielsweise den Datendurchsatz sowie die CPU- und RAM-Auslastung. Die Messdaten lassen sich leicht mit Werkzeugen visualisieren, die das Prometheus-Format unterstützen.
Seesaw einrichten
Sie müssen für jeden Seesaw-Knoten eine eigene Konfigurationsdatei "/etc/seesaw/seesaw.cfg" anlegen, in der die zentralen Informationen über den Knoten selbst und seine Peers enthalten sind. Außerdem benötigt jeder Loadbalancer eine Cluster-Konfiguration in Form einer textbasierten Datei namens "/etc/seesaw/cluster.pb". Die Seesaw-Konfigurationsdatei "seesaw.cfg" hinterlegen Sie im Verzeichnis "/etc/seesaw/" – ein einfaches Beispiel zeigt Listing 2.
Listing 2: Seesaw-Konfigurationsdatei
[cluster]
anycast_enabled = false
name = ita
node_ipv4 = 192.168.10.2
node_ipv6 = 2000:ita::2
peer_ipv4 = 192.168.10.3
peer_ipv6 = 2000:ita::3
vip_ipv4 = 192.168.10.1
vip_ipv6 = 2000:ita::1
[config_server]
primary = seesaw-config1.beispiel1.de
secondary = seesaw-config2.beispiel2.de
tertiary = seesaw-config3.beispiel32.de
[interface]
node = eth0>"
lb = eth1
Für das File ist von Bedeutung, dass eine minimale Seesaw-Konfiguration zumindest fünf Informationen beinhalten muss:
- anycast_enabled: Setzen Sie diese Option auf "True", um Anycast für diesen Cluster zu aktivieren. In der Regel ist Anycast mit dem Wert "False" deaktiviert, da es primär von IPv6-Netzwerken unterstützt wird.
- name: Sie müssen jedem Cluster eine Kurzbezeichnung zuweisen.
- node_ipv4: Spezifiziert die IPv4-Adresse des Seesaw-Knotens.
- peer_ipv4. Definiert die IPv4-Adresse des Seesaw-Peer-Knotens.
- vip_ipv4: Hinterlegt die IPv4-Adresse für diese Cluster-VIP.
Die virtuelle IP-Adresse wird zwischen den Seesaw-Knoten hin- und hergeschoben, ist aber immer nur auf dem aktuellen Master-Knoten aktiv. Wichtig für die Konfiguration ist, dass diese Adresse demselben Netz wie die Knoten- und die Peer-IP-Adresse zugewiesen werden muss. Wenn Sie Anycast verwenden, müssen Sie zudem sicherstellen, dass der Quagga-BGP-Daemon installiert und konfiguriert ist.
Für die Cluster-Konfiguration verwenden Sie die Datei "/etc/seesaw/cluster.pb.", die sich ebenfalls durch gewisse Mindestanforderungen auszeichnet. Sie muss zumindest einen "seesaw_vip"-Eintrag und zwei Knoteneinträge umfassen. Außerdem ist für den Dienst, für den die Lastverteilung bereitgestellt werden soll, ein separater "vserver"-Eintrag notwendig.
Loadbalancing in Aktion
Nun ist Seesaw einsatzbereit und lässt sich über seine Konsole steuern. Hier steht Ihnen eine interaktive Eingabeaufforderung zur Verfügung. Über config reload
laden Sie die Clusterkonfiguration neu. Der Befehl show vservers
listet alle auf diesem Cluster konfigurierten virtuellen Server. Um den Status eines Servers anzuzeigen, verwenden Sie show vserver <Name>
. Die Liste weiterer Seesaw-Befehle rufen Sie mit der Eingabe eines Fragezeichens ab.
Auch wenn Seesaw als stabile und zuverlässige Umgebung gilt, wird der Loadbalancer doch immer wieder wegen seiner Fehleranfälligkeit in der Konfiguration kritisiert. Bei der Fehlersuche liefert Ihnen die Prozesstabelle, die Sie via ps
aufrufen, wichtige Informationen. Diese sollte folgende Prozesse aufführen:
- seesaw_ecu
- seesaw_engine
- seesaw_ha
- seesaw_gesundheitsprüfung
- seesaw_ncc
- seesaw_watchdog
Die Umgebung erzeugt zudem verschiedene Protokolle, die Ihnen bei der Fehlersuche wertvolle Dienste leisten. Zum einen erfolgt eine Protokollierung durch den Watchdog, dann generiert Seesaw für alle Komponenten eigene Protokolle. Sollte einer der Prozesse nicht laufen, prüfen Sie die Protokolldatei "/var/log/seesaw". Dort liefert Ihnen beispielsweise der Eintrag "seesaw_engine.{log,INFO}" relevante Informationen.
Fazit
Loadbalancer sind in stark frequentierten Netzwerken ein Muss. Damit der Lastausgleich in der Praxis zuverlässig funktioniert, bedarf es einer ausgeklügelten Technologie. In Bezug auf diese Anforderungen müssen Sie sich bei Seesaw v2 kaum Sorgen machen – schließlich setzt Google das Tool selbst ein. Einziges Manko ist die bislang spärliche Dokumentation und zum Leidwesen interessierter Administratoren steuern auch Onlineforen wenig zum Informationsbedarf bei.
(jp)
Link-Codes
[2] Netlink Protocol Library Suite (libnl):
https://www.infradead.org/~tgr/libnl/