Bonding - Ausfallschutz für Netzwerk, Redundantes Netzwerk

Dieser Artikel ergänzt mein YouTube-Video zum Thema „Bonded Netzwerk“ (Link füge ich später ein). Ziel ist es, ein ausfallsicheres Netzwerk zu schaffen – zumindest soweit das mit vertretbarem Aufwand möglich ist. In der Praxis bedeutet das: Wenn eine Netzwerkkarte ausfällt, soll der Datenverkehr automatisch über die zweite weiterlaufen, ohne dass der Cluster oder Dienste wie Ceph unterbrochen werden.

Ich verstehe, dass dieses Thema auf den ersten Blick nicht ganz einfach zu durchschauen ist – vor allem dann, wenn im Video alles recht schnell gezeigt wird. Deshalb möchte ich hier im Artikel noch einmal in Ruhe und Schritt für Schritt erklären, wie mein Setup funktioniert, welche Probleme auftreten können und warum man trotz virtueller Umgebung genau hinschauen sollte. 

Die technische Ausgangslage sieht bei mir so aus

Ein zentraler Mutter-PVE stellt zwei virtuelle Bridges bereit – vmbr4 und vmbr5. Diese repräsentieren zwei separate Netzwerkpfade zu den vier Kind-PVEs, die als virtuelle Maschinen auf dem Mutter-PVE laufen. Innerhalb dieser Kind-PVEs erscheinen die Netzwerke folgendermaßen:

• vmbr4 entspricht dem Netzwerkgerät net1 in der VM-Konfiguration, welches im Kind-PVE als ens19 erkannt wird
• vmbr5 entspricht dem Netzwerkgerät net2, welches im Kind-PVE als ens20 erscheint

Auf den Kind-PVEs sind ens19 und ens20 in einem Bond (bond0) zusammengefasst, um aktives Failover im Modus „active-backup“ zu ermöglichen.

Getrennte Pfade im virtuellen Netzwerk-Setup 

Im ersten Schritt habe ich vmbr4 und vmbr5 getrennt voneinander eingerichtet – also zwei virtuelle Switches auf dem Mutter-PVE. Diese stellen jeweils eine eigene Verbindung zu den vier Kind-PVEs dar. In meinem Video habe ich beide Wege separat getestet, indem ich die Kind-PVEs jeweils direkt über ens19 (also vmbr4 bzw. net1) und ens20 (also vmbr5 bzw. net2) per Ping angesprochen habe. Jeder einzelne Server war auf beiden Wegen erreichbar, was mir gezeigt hat: Die physikalischen Verbindungen funktionieren zuverlässig, und die Pfade sind grundsätzlich einsatzbereit. 

Anschließend habe ich auf den vier Kind-PVE-Servern ein Bonding eingerichtet: ens19 und ens20 wurden zu einem gemeinsamen Interface (bond0) zusammengefasst. Konfiguriert wurde der Bond im Modus active-backup, wobei ens19 (also net1 / vmbr4) als bevorzugter Pfad definiert ist. Die Idee dahinter ist simpel: Solange ens19 verfügbar und funktionstüchtig ist, wird ausschließlich dieser Pfad genutzt. Erst wenn ens19 physikalisch oder logisch als „nicht verfügbar“ erkannt wird – etwa durch ein fehlendes Link-Signal –, übernimmt automatisch ens20 (also net2 / vmbr5). Dieses Umschalten geschieht ohne manuelles Eingreifen und ist transparent für das System sowie für darüberliegende Dienste wie Ceph. Voraussetzung dafür ist jedoch, dass der Ausfall klar erkannt wird – was im Standard meist nur bei tatsächlichem Linkverlust der Fall ist. 

Warum Bonding und Umschalten hier nicht funktioniert

Stellen wir uns vmbr4 und vmbr5 einmal wie zwei eigenständige Netzwerkswitches vor, die komplett getrennt voneinander stehen. In diesem Fall wären die Netzwerkkarten der Kind-PVEs mit zwei unterschiedlichen Netzwerkkabeln an genau diese beiden Switches angeschlossen. Fällt nun eine Route aus – sei es durch den Ausfall einer Netzwerkkarte auf einem der Kind-PVEs oder durch den Ausfall eines gesamten Switches – dann greift der Bonding-Mechanismus: Entweder nur ein einzelner Kind-PVE schaltet um (bei Netzwerkkarten-Ausfall), oder gleich alle vier (bei Switch-Ausfall). 

Doch damit dieses automatische Umschalten auch tatsächlich funktioniert, müssen die beiden Switches miteinander kommunizieren können. Sobald ein Gerät auf den Backup-Link wechselt, muss der neue Pfad im Netzwerk bekannt sein – das heißt, die Switches müssen in der Lage sein, die MAC-Adresse der umgeschalteten Schnittstelle dynamisch zu lernen und korrekt weiterzuleiten. Dieses sogenannte MAC-Learning muss schnell und zuverlässig funktionieren. 

Spezielle Switches notwendig

Hierfür werden spezielle Switches benötigt, die genau dieses Verhalten unterstützen – etwa durch aktiviertes Spanning Tree, Rapid Spanning Tree, oder dedizierte Bonding- bzw. Failover-Modi in der Switchkonfiguration. Ohne diese Funktionen verpufft das Bonding: Die Schnittstelle schaltet zwar um, aber der neue Datenpfad kommt am Ziel nie an, weil der Switch den geänderten Absender nicht erkennt. 

Es gibt verschiedene Ansätze, wie man ein solches Bonding-Szenario realisieren kann. Einer der einfacheren Wege ist der Einsatz nur eines Switches, an dem beide Netzwerkkarten eines Kind-PVEs angeschlossen sind. In diesem Fall geht es lediglich darum, den Ausfall einer Netzwerkkarte auf dem Server selbst abzufangen – also lokal auf einem einzelnen Kind-PVE. 

Was passiert beim Bonding, beim Umschalten? 

Wenn ich nun also die Konfiguration meiner Switches – also vmbr4 und vmbr5 – auf dem Mutter-PVE so belasse, wie ich sie zu Beginn angelegt habe, dann läuft das Bonding der Kindserver ins Leere. Warum? Weil vmbr4 und vmbr5 zwei völlig voneinander getrennte virtuelle Switches darstellen. Sie haben keinerlei Verbindung zueinander – weder logisch noch auf Layer-2-Ebene. 

Das bedeutet: Wenn ein Kind-PVE über seinen Bond von ens19 (also net1 / vmbr4) auf ens20 (also net2 / vmbr5) umschaltet, dann sendet er plötzlich in ein anderes Netzwerksegment. Der Mutter-PVE weiß davon aber nichts. Für ihn kommt das Paket aus einer anderen Richtung, ohne die erwartete MAC-Adresse, und ohne dass vmbr5 überhaupt weiß, was damit zu tun ist. 

Das Resultat: Der Datenverkehr verschwindet im Nichts. Der Kind-PVE glaubt, er hätte erfolgreich umgeschaltet, aber tatsächlich wird nichts mehr weitergeleitet, weil die neue Route auf dem Mutterserver nicht existiert – es fehlt schlicht die gemeinsame Brücke, über die der Failover funktionieren könnte. 

Eine physische Verbindung ist bei virtuellen Switches wie vmbr4 und vmbr5 natürlich nicht möglich – sie existieren ja nur innerhalb des Mutter-PVE und sind softwareseitig voneinander getrennt. Dennoch könnte ich beide virtuellen Netzwerkkarten der Kindserver – also ens19 (net1) und ens20 (net2) – an eine gemeinsame Bridge, zum Beispiel nur vmbr4, anschließen. Das käme einer physischen Verbindung über denselben Switch gleich. 

In diesem Fall würden beide Pfade – auch wenn es zwei unterschiedliche virtuelle Netzwerkkarten im Kind-PVE sind – im Hintergrund auf demselben virtuellen Switch enden. Der Bond auf dem Kindserver hätte also zwei Wege, die in derselben Layer-2-Umgebung landen. Und genau das ist entscheidend: Nur wenn der Datenverkehr bei einem Failover auf demselben virtuellen Switch ankommt, kann das Umschalten sauber funktionieren. 

Beide Brücken meines Bonding-Netzwerkes verbinden

Da mein Setup vollständig auf virtueller Basis läuft, würde ein Bonding-Fall realistisch gesehen nur dann eintreten, wenn es ein Softwareproblem gibt – etwa ein Ausfall der virtuellen Netzwerkkarte in einem Kind-PVE oder ein interner Fehler im Proxmox-Netzwerkstack. Denn weder die Switches (vmbr4 und vmbr5) noch die Netzwerkkarten der Kind-PVEs sind physische Geräte – sie existieren rein virtuell innerhalb des Mutter-PVE. 

Das bedeutet: Ein echter Hardwareausfall, wie er bei physischen Switches oder Netzwerkkabeln auftreten kann, ist in diesem Szenario so gut wie ausgeschlossen. In der Praxis ist es also sehr unwahrscheinlich, dass das Bonding überhaupt jemals ausgelöst wird. Und streng genommen wird es in dieser Konstellation auch gar nicht benötigt. 

Dennoch habe ich das Setup genau so gewählt, um es zu testen und um zu zeigen, was passieren würde, wenn der Bond tatsächlich greifen müsste. Wenn ich nun möchte, dass vmbr4 und vmbr5 auf dem Mutterserver dieses Kind-Bonding korrekt unterstützen – also dass der Datenverkehr bei einem Umschalten zuverlässig weitergeleitet wird – müssten diese beiden Bridges virtuell miteinander verbunden werden. Das könnte man zum Beispiel über eine zusätzliche Linux-Bridge, eine Open vSwitch-Integration oder über ein internes Routing mit Bridge-Loopback-Anbindung realisieren. 

Das Ziel wäre, dass beide virtuellen Switches auf dem Mutter-PVE dieselbe Layer-2-Basis nutzen – so, als würden sie intern über ein virtuelles Kabel zusammengeschaltet. Nur dann kann ein Bond auf einem Kind-PVE, der zwischen net1 und net2 (also vmbr4 und vmbr5) wechselt, sicher sein, dass der neue Datenpfad auch am Ziel ankommt. Doch ob sich dieser Aufwand lohnt, steht auf einem anderen Blatt. 

Mein Fazit zum Networkbonding

Also meine Lieben, alles in allem zieht man mal nicht so eben ein Bonding aus dem Hut und es funktioniert alles. Man muss sich einmal ganz genau im Klaren sein, was man damit eigentlich erreichen will. Will man bloß eine Netzwerkkarte absichern, oder gleich mehrere Wege zum Ziel haben? Will man nur Redundanz oder auch mehr Durchsatz? 

Man muss seine Umgebung ganz genau kennen – nicht nur die VM-Konfiguration, sondern auch, wie Proxmox mit Netzwerken umgeht, wie die virtuellen Bridges arbeiten, wie die MAC-Adressen gehandhabt werden, was die Switches können und was nicht. Man muss wissen, wie Bonding wirklich funktioniert und wie die Failover-Erkennung überhaupt greift. Denn einfach nur zwei Netzwerkkarten zusammenklemmen reicht eben nicht. 

Es bleibt einem also nichts anderes übrig, als seine Hardware, seine Umgebung, seine Anforderungen und wirklich alles, was mit dem Setup zu tun hat, genau zu studieren. Analysieren, dokumentieren, durchdenken und dann erst planen – und zwar sauber. Sonst wird das nix. Und dann wundert man sich am Ende, warum der Failover ins Nirvana führt oder Ceph plötzlich nicht mehr spricht. 

Bonding ist kein Hexenwerk, aber es ist eben auch kein Kinderspiel. Wer es richtig macht, hat ein solides Fundament. Wer einfach drauflos klickt, fliegt beim nächsten Link-Down aus dem Cluster. So einfach ist das. 

Vielen Dank fürs lesen, Ihr und Euer #ComputerRalle