Cluster Networking mit Proxmox

Die Macher von Proxmox gehen in den meisten Fällen davon aus, dass die Knoten des Clusters in einem gemeinsamen Rechenzentrum stehen. Das ist sicherlich der Normalfall, bei Ausnahmen lässt die Dokumentation aber etwas zu wünschen übrig.

Daher an dieser Stelle die Beschreibung einer einfachen, performanten und preiswerten Lösung eines VLan-fähigen „Backbone“ über unterscheidliche Standorte.

Aktuelle Situation

Es existiert ein Cluster auf drei Root-Servern bei Hetzner. Dieser soll erweitert werden um zwei im eigenen kleinen RZ gehostete Knoten.

Ziel ist die performante Anbindung des Clusters mit der Möglichkeit, VMs im Gesamtcluster umziehen zu können ohne an der Netzwerkkonfiguration schrauben zu müssen.

Darüber hinaus sollen die einzelnen VMs in diversen VLANs gruppiert werden können.

Anbindung

Zur Anbindung von Hetzner muss man nicht viel sagen – schnell und zuverlässig. Dass das Peering ins Netz der Deutschen Telekom eine Katastrophe ist und Magenta zu Hetzner nur einen nassen Schnürsenkel vorweisen kann, ist allein der Telebimm zuzuschreiben. Das bremst den Zugriff aus dem Netz der Telebimm schon mal auf <1MBit aus… Schwaches Bild, liebe Telekom, aber genau aus diesem Grund bin ich ja auch kein Kunde mehr! 🙂

Die Anbindung des heimischen RZ hängt an einer sehr zuverlässigen 1000MBit-Glasfaser der GGEW. Typische Performancewerte: 928MBit Download, 278MBit Upload!

Den Anschluss an die Faser übernimmt eine FritzBox 7490 mit PPPoE, dahinter hängt als „Exposed Host“ eine pfsense. Diese wiederum verteilt auf ein Admin- und ein Work-LAN, in dem die beiden PVE sitzen.

Firewall

Was muss ich aufreißen?

Die Zerotier-Dokumentation ist da recht einfach:

What ports does ZeroTier use?

It listens on three 3 UDP ports:

  • 9993 – The default
  • A random, high numbered port derived from your ZeroTier address
  • A random, high numbered port for use with UPnP/NAT-PMP mappings

That means your peers could be listening on any port. To talk with them directly, you need to be able send to any port.

Should I forward any ports in my router?

No. Let ZeroTier and UPnP, NAT-PMP, and IPv6 handle it automatically.

Also recht einfach, ich muss pfsense nur sagen, dass UPnP zugelassen werden soll und die Maschinen im Work-LAN Rechte auf die notwendigen Dienste haben sollen.

Inter-Node-Connectivity mit zerotier

Um die Knoten miteinander zu verbinden, erzeugen wir in in der zerotier-GUI ein neues Netzwerk und wählen IPv4-Auto-assign.

Nach dem Join verändern wir die Einstellungen der verbundenen Knoten und aktivieren die Bridge-Funktion

Damit „sehen“ sich die Knoten gegenseitig, unabhängig vom Standort.

VLAN einrichten

Die Wahl des VLAN fiel auf das seit 6.3 recht stabile VXLAN-Paket von Proxmox, das aber immer noch als experimentell eingestuft wird!

Um das Paket zu benutzen, muss auf den teilnehmenden Knoten ein

apt install libpve-network-perl

ausgeführt werden. Ein Neustart zumindest des pve-cluster ist danach notwendig.

Danach taucht auf RZ-Ebene der Menueintrag „SDN“ auf.

Unter „Zonen“ legen wir jetzt eine neue Zone vom Typ VXLAN an.

Danach können wir unter „Vnets“ ein Netz in dieser Zone definieren

Jetzt müssen wir alle Zonen noch anwenden. Damit werden die Konfigurationen auf die Knoten in die Datei /etc/network/interfaces.d/sdn exportiert und die Netzwerkkonfiguration neu erstellt.

Jetzt können wir den VMs ein Interface aus den erzeugten Vnets zuweisen, mit oder ohne VLAN-Tag und uns an performantem Traffic innerhalb des clusterweiten VLAN erfreuen! 🙂

Ein immer wiederkehrender Quell großer Freude ist eine falsch gesetzte MTU!

Ping funktioniert fast immer, die meisten Websites ebenfalls, Downloads o.ä. hangen – viel Spaß beim Suchen! 🙂

Da die Interfaces Bridges darstellen, muss die MTU der Guest-Interfaces geringer als der Standard von 1500 gewählt werden. 1480 ist hier der Wert der Wahl!

Hetzner + Proxmox + Migration

Eine VM, die auf einem Hetzner-Rootserver unter virsh läuft, soll in einen existierenden Proxmox-Cluster umgezogen werden. Soweit kein Problem, aaaaber: die offizielle IP-Adresse, eine Hetzner-Zusatz-IP soll erhalten bleiben.

Da Hetzner die Zusatz-IPs nur maschinenspezifisch vergibt und keinen Umzug auf eine andere Maschine ermöglicht, muss der Traffic von der alten IP zur neuen VM im PVE umgeleitet werden. Nach Möglichkeit sollte das mit Bordmitteln (und zerotier) ohne iptables-Umleitungen funktionieren.

Zerotier

Das Mittel der Wahl, diverse Hosts performant miteinander zu verbinden, ist hier zerotier.

Unter der GUI wird ein neues Netzwerk angelegt, das alle teilnehmenden Hosts joinen.

Für den alten Virtualisierungshost (im Folgenden VH, wie Virsh-Host) genannt, sowie alle teinehmenden PVEs wird ein Eintrag in dieser Form angelegt:

VM-Networking

Auf dem alten Host wird eine Bridge mit einer privaten IP und einer Route zur Zusatz-IP angelegt:

auto vmbr1001
iface vmbr1001
         address 10.111.222.1/24
         bridge-ports none
         bridge-stp off
         bridge-fd 0
         up brctl addif vmbr1001 ztks553soy
         up ip link set ztks553soy up
         up ip route add <Zusatz-IP>/32 dev vmbr1001
         # bridge fuer alte VM

Die Zusatz-IP wird also auf diese Bridge geroutet

Auf den teilnehmenden PVEs wird eine ähnliche Bridge gleichen Namens (muss nicht!) angelegt, allerdings ohne IP-Adresse und Route.

auto vmbr1001
iface vmbr1001
         bridge-ports none
         bridge-stp off
         bridge-fd 0
         # siehe if-up.d/vmbr1001
         # bridge fuer alte VM

Beide Bridges werden über das vorher erzeugte Zerotier-Interface verbunden.

Da die Zerotier-Interfaces erst nach dem kompletten Netzwerk-Setup gestartet werden, muss das weitere Setup zeitverzögert erfolgen. Leider unterstützt zerotier bislang keine Script-hooks, ähnlich if-up.d, sonst könnte das weitere Setup dort erfolgen. So erledigt diese Aufgabe das Script if-up.d/vmbr1001 mit dem etwas unschönen „sleep“.

!/bin/sh
[ "$IFACE" != "vmbr1001" ] && exit 0
# Interface ztks553soy kommt erst mit zerotier hoch,
# ist also jetzt noch nicht bereit.
# Daher muss der folgende Block verzögert ausgeführt werden.
(
 sleep 30
 brctl addif vmbr1001 ztks553soy
 ip link set ztks553soy up
 ip r add <guest ip>/32 dev vmbr1001
) &

Guest Setup

Im portierten Guest wird als externes Interface jetzt die (auf dem PVE erzeugte) Bridge zugewiesen.

Im Gast wird jetzt die Hetzner Zusatz-IP dem externen Interface zugewiesen.

Im Guest muss jetzt noch das Gateway bekannt gemacht werden.

ip route add <private-ip-von-vmbr1001> dev eth0
ip route add default via <private-ip-von-vmbr1001> dev eth0

Danach sollte die Verbindung über die Bridge funktionieren.

Zerotier going berserk!

Der Proxmox-Cluster verliert einzelne Knoten, diese rebooten und reißen damit die verbleibenden Knoten ebenfalls ins Jenseits. Das passiert nicht nur einmal, sondern in bunter Reihenfolge!

Symptome

Nach Isolation eines Knoten mittels pvecm expected 1 lässt sich dieser vom Dauerboot abhalten. Zu beobachten ist, dass der zerotier-Prozess mehrere CPUs voll belegt und sein Speicherbedarf stetig steigt. Bei 120GB ist dann Schluss, das OS schießt den Prozess ab.

Schleife

Da der Heartbeat des corosync über einen mittels zerotier aufgebauten Tunnel läuft, ist der Knoten jetzt isoliert und das Fencing reißt ihn nach 60 Sekunden in den Abgrund… Nach dem Reboot passiert das Gleiche wieder und wieder…

Analyse

Zerotier greift sich zum Aufbau des Tunnels alle verfügbaren physischen Interfaces.

Wenn also ein Zerotier-Interface Teil einer Bridge ist, geht der Zerotier-Traffic auch über diese Bridge und damit rekursiv wieder über das Zerotier-Interface – eine perfekte Schleife, die alles verfügbare RAM aufbraucht!

Abhilfe

Man kann zerotier das Verhalten abgewöhnen, indem man die kritischen Interfaces in eine blacklist einträgt. Das geschieht mittels der Datei /var/lib/zerotier-one/local.conf

Falls diese noch nicht existiert, muss sie angelegt werden.

{
     "physical": {
         "172.16.0.0/16": {
             "blacklist": true
         },
         "10.0.0.0/8": {
             "blacklist": true
         }
     },
     "settings": {
         "interfacePrefixBlacklist": [ "eth100","vmbr10","vmbr666","vmbr999" ]
     }
 }

Es sollten alle nicht nach draußen führenden Interfaces – und alle privaten IP-Ranges ausgeschlossen werden. Danach zerotier neu starten und sich über den moderaten Ressourcenverbrauch freuen…

Fazit

Kleine Ursache, große Wirkung, lange Analyse, lange Downtime -> nicht schön!

Davon abgesehen ist es keine sehr gute Idee, den Heartbeat über zerotier laufen zu lassen, die Latenzen sind bisweilen gigantisch, was der Stabilität des Clusters nicht gut bekommt.

Mittlerweile kommt auch für den Heartbeat tinc zum Einsatz, der Cluster ist damit deutlich stabiler geworden!

Proxmox, tinc und VLANs

Über mehrere Proxmox-Nodes soll ein VPN gespannt werden, über das mehrere VLANs den VMs zur Verfügung gestellt werden. Dies sollte mit Bordmitteln geschehen.

Das VPN wird mit tinc aufgesetzt, weil es schnell, einfach und mesh-fähig ist.

Ziel ist, einen einzigen tinc-Tunnel für mehrere VLANs zu verwenden.

Konfiguration

Die Konfiguration ist am Standard angelehnt, Besonderheiten sind fett.

Device=/dev/net/tun
 DeviceType=tap
 Forwarding=kernel
 PMTUDiscovery=yes
 PriorityInheritance=yes
 Interface=eth200
 AddressFamily=any
 Mode=switch
 ProcessPriority=high
 Name=v0
 PrivateKeyFile=/etc/tinc/pvebridge/rsa_key.priv
 ConnectTo=v1
 ConnectTo=v2
 ConnectTo=...

tinc wird mit systemctl enable tinc@pvebridge ins System eingebunden und dann mit systemctl start tinc@pvebridge gestartet.

Das Start-script tinc-up bindet das Interface an die Bridge.

!/bin/sh
BRIDGE=vmbr666
ip address add 10.66.66.2/24 dev $INTERFACE
ip link set $INTERFACE master $BRIDGE
ip link set $BRIDGE up
ip link set $INTERFACE up
bridge vlan add vid 2-4094 dev $INTERFACE

Das Interface benötigt eine IP-Adresse, bevor es in die Bridge aufgenommen wird!

Das bridge-Kommando mappt alle verfügbaren VLAN-IDs auf das darunterliegende Interface. Es funktioniert erst, nachdem das Interface in die bridge aufgenommen wurde.

Testen

Jetzt wird der erste Container (hier Ubuntu 18.04) angelegt und mit Netzwerk konfiguriert.

Nach der Generierung des zweiten Containers auf einem anderen Knoten

funktioniert der ping zwischen beiden Knoten über das VLAN.

Fallstricke

Bei Änderungen an der tinc-Konfiguration sollten die Instanzen auf den einzelnen Knoten mit zeitlichem Abstand gestartet werden, da sonst die einzelnen Instanzen ihre Gegenseite nicht finden und somit keine Verbindung zustande kommt.

Nicht vergessen, die evtl. vorhandene Zerotier-Konfiguration anzupassen und die VLAN-Interfaces auszusparen!

Performance in Proxmox

Die Performance der Guests in Proxmox hängt definitiv vom Setup der darunterliegenden Virtualisierung ab. Dass die Unterschiede aber so groß sind, überrascht…

Setup 1: NVME+Software-Mirror, Guest: Ubuntu 18.04 KVM

Setup 2: NVME als Log und Cache für einen mirrored ZFS-Pool, Guest wie in 1

GlusterFS Input/Output error

Heute Morgen war der virtualisierte Mailserver down. Die Console zeigte einen Fehler beim Zugriff auf das Swap-Device, sehr seltsam…

Ein Neustart der QEMU-Instanz brachte keine Besserung, es wurde keine bootbare Platte gefunden. Die Überprüfung des darunter liegenden GlusterFS förderte beim Lesen des Serverimages einen IO-Error zutage.

OK, hatte ich in der Form noch nicht, also eine Herausforderung. Das Anstoßen eines Healings brachte keine Besserung, der Fehler blieb. Hilfe brachte nach viel Rumprobieren schließlich diese Seite.

Das Geheimnis liegt darin, das nicht mehr lesbare File von der darunter liegenden Brick wegzukopieren und dann aus beiden Bricks sowohl die Datei als auch ihre Meta-Infos zu löschen. Die Metas finden wir über:

getfattr -m . -d -e hex /data/gluster/gv0/mailhost.img
trusted.afr.dirty=0x000000000000000000000000
trusted.afr.gv0-client-0=0x000000030000000000000000
trusted.afr.gv0-client-1=0x000000390000000000000000
trusted.bit-rot.version=0x08000000000000005c178f4d000a5cdc
trusted.gfid=0x4802075a4748467abc28c0fff9b108a9

Jetzt können wir die beiden Files löschen:

rm /data/gluster/gv0/mailhost.img /data/gluster/gv0/.glusterfs/48/02/075a4748467abc28c0fff9b108a9

Danach kopieren wir die vorher erstellte Kopie der Datei wieder in den GlusterFS-Mountpoint.

Man wird jeden Tag etwas klüger…

Qualitätsjournaille

Gestern textete der Focus:

Experten warnen – WhatsApp: Handwerkern drohen wegen neuer Verordnung massenhaft Bußgelder

Eine der zentralen Aussagen dieses Recherchewunders lautet dann auch:

Handwerker verwendeten WhatsApp als Kommunikationsmittel auf dem Bau sowie oft auch dafür, sich von Kunden Fotos von Stellen in der Wohnung schicken zu lassen, die repariert werden sollen.

„Da WhatsApp Zugriff auf dieses Bild erhält, handelt es sich hierbei um eine Datenübertragung an WhatsApp, für die der betroffene Kunde jedoch keine Einwilligung erteilt hat“, sagte ZDH-Datenschutzexperte Markus Pfeifer der „Welt“. Eine gesetzliche Grundlage für den Datentransfer bestehe nicht.

Liebe Qualitätsschreiberlinge, was genau habt ihr an dem Begriff „Ende-zu-Ende-Verschlüsselung“ nicht verstanden?

Der verlinkte Artikel der Welt setzt noch einen drauf:

„Der Haken bei WhatsApp ist der Zugriff des Programms auf das Adressbuch im Smartphone der Nutzer. Die App des US-Internet-Konzerns Facebook nutzt die Kontaktdaten, um mit den eigenen Servern abzugleichen, wer bereits ebenfalls bei WhatsApp registriert ist – diesen Kontakten kann der Nutzer anschließend Nachrichten senden. Doch da sämtliche Kontakte geprüft werden, landen auch Daten von Personen bei der Facebook-Tochterfirma, die dieser Übermittlung niemals zugestimmt haben.“

Auch dieser Satz zeugt von der unglaublichem Fachkompetenz des Verfassers gegenüber technischen Sachverhalten:

Jetzt mal 30 Sekunden unter Einschaltung des Hirns über diesen Satz nachgedacht:

  • Ihr glaubt doch nicht im Ernst, dass, wenn ich auf einem Firmenhandy mit Zugang zum LDAP-Verzeichnis WhatsApp öffne, alle 8000 Kontakte übertragen werden? Really?
  • Dauert bei euch das Öffnen von WhatsApp deshalb immer 40 Minuten?
  • Und bekommt ihr danach immer Besuch von der internen Security wegen des Scannens des kompletten LDAP?
  • Ist nach dem Öffnen von WhatsApp bei euch immer das Monatsdatenkontingent aufgebraucht?
  • Habt ihr mal einen Programmierer gefragt, wie man sowas lösen könnte?
  • Seid ihr lernfähig? Falls ja, eine kurze Information, wie man so etwas realisiert:
  1. Erzeuge aus den bisher kontaktierten Telefonnummern eine Prüfsumme.
  2. Sende diese Prüfsumme an den Server.
  3. Kennt der Server die Prüfsumme, hat der Inhaber der entsprechenden Telefonnummer einen Account bei WhatsApp und somit der Datenverarbeitung bereits zugestimmt.
  4. Kennt der Server die Prüfsumme nicht, kann er auch keine personenbezogenen Daten daraus ableiten, da die Prüfsummenfunktion eine Einbahnstraße ist.
  5. Somit ist die Prüfsumme kein personenbezogenes Datum.

Das kann euch jedes Erstsemester Informatik erklären.

Aber mit Fakten sind heutzutage ja keine Klickzahlen mehr zu generieren. Mit postfaktischen Behauptungen aber sehr wohl.

Das nennt sich dann Qualitätsjournaille.

fail2ban gegen Serientäter

fail2ban ist ein unentbehrliches Tool um Serverinstallationen gegen Einbruchsversuche zu immunisieren.

Was dabei immer wieder auffällt, ist, dass nach Verstreichen der BanTime die gleiche IP wiederkommt und es sofort weiter versucht.

Diese „Serientäter“ möchte man dann doch gerne für längere Zeit sperren.

Dank der weitgehenden Konfigurationsmöglichkeiten von fail2ban ist das kein großes Problem; man muss nur das Logfile von fail2ban zu Hilfe nehmen und alle wiederholten Bans für eine IP über einen längeren Zeitraum filtern und dann mit einer eigenen Regel länger am Wiederkehren hindern.

Wir erstellen die Datei /etc/fail2ban/filter.d/serialkiller.conf

# Fail2Ban configuration file

[Definition]

failregex = fail2ban.actions: WARNING .* Ban <HOST>

ignoreregex =

/etc/fail2ban/jail.local wird um folgenden Absatz erweitert

[serialkiller]
enabled = true
port = any
logpath = /var/log/fail2ban.log
filter = serialkiller
findtime = 3600
bantime = 7200
maxretry = 3

Ein darauf folgendes

fail2ban-client reload

aktiviert die erstellte Regel und alle Serientäter, die in der letzten Stunde dreimal geblockt wurden, werden jetzt für 2 Stunden blockiert.