SDN Fabrics in Proxmox: wann der Mittelstand das braucht — und wann nicht

/01Was eine Fabric ist — und was sie nicht ist

Die Proxmox-Dokumentation definiert Fabrics in einem Satz: „Fabrics in Proxmox VE SDN provide automated routing between nodes in a cluster. They simplify the configuration of underlay networks between nodes to form the foundation for SDN deployments." Das Wort, das zählt, ist Underlay. Eine Fabric ist kein Netz für virtuelle Maschinen. Sie ist das Netz zwischen den Proxmox-Knoten selbst — die Schicht, auf der Ceph-Replikation, VXLAN-Tunnel und EVPN-Steuerverkehr laufen. Proxmox konfiguriert dafür FRRouting auf jedem Knoten und lässt ein Routing-Protokoll die Wege zwischen den Knoten selbst finden.

Was das im Alltag ändert: Bisher war das Netz zwischen den Knoten Sache des Switches. Ein VLAN für Corosync, eines für Ceph, eines für die Live-Migration, alle als Trunk auf jedem Port, gepflegt vom Netzwerkteam. Mit einer Fabric routet der Cluster zwischen seinen Knoten selbst — der Switch sieht nur noch geroutete Punkt-zu-Punkt-Verbindungen oder ist im einfachsten Fall gar nicht mehr im Pfad. Die Roadmap zur 9.0 ergänzt, dass Fabrics im Ressourcenbaum erscheinen und dort Routen und Nachbarn melden — die Fehlersuche findet also in der Oberfläche statt, nicht nur in vtysh.

Was dieser Artikel nicht behandelt: die Zonen selbst. Welche Zone wofür taugt, wie eine EVPN-Zone konfiguriert wird und warum das VLAN für die meisten Cluster reicht, steht in Proxmox SDN: VXLAN und EVPN für die Mandantentrennung. Hier geht es um die Schicht darunter.

/02Vier Protokolle, zwei davon für den Mittelstand

Proxmox VE 9.2 kennt vier Fabric-Protokolle. Zwei kamen mit 9.0, zwei mit 9.2, und sie lösen unterschiedliche Aufgaben.

Für den Mittelstand zählen OpenFabric und WireGuard. OpenFabric, weil es für genau den Fall gebaut ist, der in kleinen Clustern vorkommt — wenige Knoten, direkt verkabelt, ohne Netzwerkteam, das OSPF-Areas pflegt. WireGuard, weil es die eine Frage beantwortet, die bei zwei Standorten immer kommt: Wie koppeln wir die Knoten über eine Strecke, die uns nicht gehört. OSPF ist die Wahl, wenn das Netzwerkteam ohnehin OSPF spricht und die Fabric mit vorhandenen Routern reden soll. BGP ist die Wahl, wenn die Switches bereits eine BGP-Fabric bilden — das ist im Mittelstand die Ausnahme.

/03Der Fall, in dem Fabrics die Switch-Konfiguration ersetzen: Ceph ohne Switch

Der Anwendungsfall, den die Dokumentation an erster Stelle nennt, ist „a full-mesh network for Ceph": drei Knoten, jeder mit jedem direkt verkabelt, das Ceph-Netz läuft über diese Direktverbindungen, kein Switch im Storage-Pfad. Das war schon vor Fabrics möglich — über eine von Hand gepflegte FRR-Konfiguration oder statische Routen —, und genau diese Handarbeit ist es, die die Upgrade-Anleitung auf Version 9 als Bruchstelle führt: Ein bedingungsloses post-up /usr/bin/systemctl restart frr.service in /etc/network/interfaces bricht unter 9, die Anleitung nennt die korrigierte Form mit is-active --quiet. Wer die Fabric aus der Oberfläche nutzt, hat diese Zeile nicht mehr.

Warum das für einen Drei-Knoten-Cluster interessant ist: Zwei Switches mit 25- oder 100-GbE-Ports nur für das Ceph-Netz sind ein Posten, der bei drei Knoten unverhältnismäßig ist. Drei Direktverbindungen mit zwei Ports je Knoten kosten Kabel und Netzwerkkarten, sonst nichts. Fällt ein Kabel aus, routet OpenFabric den Verkehr über den dritten Knoten — langsamer, aber ohne Ausfall. Das ist der Unterschied zum statischen Routing: Dort ist ein Kabelbruch ein Ausfall der Verbindung, bis jemand eingreift.

# Drei Knoten, Full Mesh, OpenFabric — Verkabelung
#   pve01 ens1f0 <──> pve02 ens1f0
#   pve01 ens1f1 <──> pve03 ens1f0
#   pve02 ens1f1 <──> pve03 ens1f1
#
# Fabric "ceph" mit IPv4-Praefix 10.99.0.0/24
#   Router-IDs: pve01 10.99.0.1, pve02 10.99.0.2, pve03 10.99.0.3
#   Schnittstellen je Knoten: die beiden Direktverbindungen, ohne eigene IP
#
# Nach dem Anwenden: Routen je Knoten pruefen
vtysh -c "show openfabric route"
vtysh -c "show openfabric neighbor"
#  System Id     Interface   L  State   Holdtime  SNPA
#  pve02         ens1f0      2  Up      28        2020.2020.2020
#  pve03         ens1f1      2  Up      27        2020.2020.2020

# Ceph auf die Router-IDs legen
# /etc/pve/ceph.conf: cluster_network = 10.99.0.0/24

Der Aufbau eines Ceph-Clusters selbst — OSDs, Pools, Replikation, Kapazitätsplanung — steht in Ceph Storage: Enterprise-Storage ohne Lizenzkosten; die Fabric ist nur die Leitung darunter.

/04Der zweite Fall: Underlay für EVPN über Standorte

Die Dokumentation nennt als zweiten Einsatz das Underlay „in the EVPN controller and VXLAN zone". Eine EVPN-Zone braucht ein geroutetes Netz zwischen allen Knoten, über das die VXLAN-Tunnel laufen und über das BGP die MAC- und IP-Adressen der Gäste verteilt. Innerhalb eines Standorts liefert das der Switch. Über zwei Standorte — Hauptsitz und Colocation, Werk und Verwaltung — liefert es niemand von allein: Die Knoten müssen einander über die Standortkopplung erreichen, mit stabilen Adressen, die ein Ausfall einer Leitung nicht ändert.

Genau das ist eine Fabric: Die Router-ID jedes Knotens ist die stabile Adresse, das Routing-Protokoll findet den Weg über die vorhandenen Leitungen, und die EVPN-Zone setzt darauf auf. Proxmox VE 9.2 ergänzt dafür laut Roadmap Route Maps und Prefix Lists für die BGP/EVPN-Filterung und ein IPv6-Underlay für EVPN — Werkzeuge, die man braucht, sobald die Fabric nicht mehr alleine im Netz ist, sondern mit Routern des Standorts Routen austauscht.

Ehrlich dazu: Das ist der Fall, in dem der Aufwand am höchsten ist und die Wahrscheinlichkeit, ihn im Mittelstand zu brauchen, am niedrigsten. Ein Cluster über zwei Standorte ist zuerst eine Quorum- und Latenzfrage und erst danach eine Netzfrage. Wer zwei Standorte hat, um ein Ausfallrechenzentrum zu betreiben, fährt in der Regel zwei getrennte Cluster mit Replikation — und braucht die Fabric nicht, sondern eine Standortkopplung und den Proxmox Datacenter Manager.

/05Der dritte Fall: verschlüsselte Kopplung per WireGuard

Mit 9.2 kommt WireGuard als Fabric-Protokoll; die Roadmap beschreibt es als verschlüsselte Verbindung zwischen Knoten, in der Dokumentation mit Listen-Port, Schlüsselpaar und optionalem Persistent Keepalive. Das ist der Baustein für den Fall, in dem Knoten über eine Strecke gekoppelt werden, die nicht dem Unternehmen gehört: ein Knoten in der Colocation, einer im eigenen Serverraum, dazwischen eine Internetleitung. Oder ein Erweiterungsknoten in einer Cloud, den man für Lastspitzen mitlaufen lässt — ein Hybrid-Cloud-Modell mit eigenen Latenzfragen.

WireGuard allein routet nicht; die Dokumentation nennt es „often used with dynamic routing protocols like OSPF or BGP". Die Fabric baut also den Tunnel und lässt darüber OSPF oder BGP die Wege finden — zwei Schichten, beide aus der Oberfläche. Wer bisher ein Site-to-Site-VPN auf der Firewall gebaut und den Cluster darüber hat sprechen lassen, verschiebt damit die Verschlüsselung vom Firewall-Team zum Cluster. Das ist eine organisatorische Entscheidung, keine technische: Beide Wege funktionieren, aber nur einer davon steht im Ressourcenbaum von Proxmox mit Nachbarn und Routen.

Zwei Grenzen. Erstens ist WireGuard eine Verschlüsselung für Knoten-zu-Knoten-Verkehr, keine Fernzugangslösung für Mitarbeiter — dafür bleiben Werkzeuge wie NetBird zuständig, beschrieben in Mesh-VPN auf WireGuard-Basis. Zweitens kostet jeder Tunnel IPv6- oder IPv4-Overhead und MTU: Ein VXLAN über WireGuard über eine 1500er-Leitung lässt für den Gast deutlich weniger übrig, und die Rechnung dazu gehört vor die Inbetriebnahme, nicht in die Fehlersuche.

/06Eine OpenFabric-Fabric anlegen und prüfen

Die Konfiguration läuft unter Rechenzentrum → SDN → Fabrics in vier Schritten, und die Reihenfolge ist nicht beliebig.

Voraussetzungen

Auf jedem Knoten müssen die Pakete frr und frr-pythontools installiert sein — die Dokumentation nennt beide ausdrücklich. Die Schnittstellen, die in die Fabric gehen, dürfen keine anderweitige Konfiguration in /etc/network/interfaces tragen, und bei IPv6-Fabrics muss das IPv6-Forwarding global aktiv sein.

# Auf jedem Knoten
apt install frr frr-pythontools
systemctl status frr --no-pager | head -3

# Schnittstellen fuer die Fabric identifizieren (Direktverbindungen, keine IP)
ip -br link show | grep -E 'ens1f0|ens1f1'

Fabric anlegen

Fabric hinzufügen, Protokoll OpenFabric, ID mit höchstens 8 Zeichen, IPv4-Präfix — die Dokumentation beschreibt ihn als Bereich, gegen den die Router-IDs geprüft werden, etwa 192.0.2.0/24. Hello- und CSNP-Intervall können auf den Werkswerten 3 und 10 Sekunden bleiben; kürzere Hello-Intervalle beschleunigen die Erkennung eines Kabelbruchs auf Kosten von Steuerverkehr.

Knoten hinzufügen

Je Knoten: Router-ID aus dem Präfix, eindeutig im Cluster, und die Schnittstellen, über die der Knoten mit den anderen spricht. Optional bekommt jede Schnittstelle eine eigene Adresse in CIDR-Schreibweise; für ein Full Mesh mit OpenFabric ist das nicht nötig, weil das Protokoll ohne Schnittstellenadressen auskommt.

Anwenden und prüfen

# SDN-Konfiguration clusterweit anwenden (entspricht dem Knopf "Apply")
pvesh set /cluster/sdn

# FRR-Konfiguration, die Proxmox erzeugt hat
cat /etc/frr/frr.conf

# Nachbarn und Routen der Fabric
vtysh -c "show openfabric neighbor"
vtysh -c "show openfabric route"
vtysh -c "show ip route openfabric"

# Erreichbarkeit ueber die Router-IDs
ping -c 3 10.99.0.2
ping -c 3 10.99.0.3

# Ausfalltest: ein Kabel ziehen, Route muss ueber den dritten Knoten laufen
vtysh -c "show ip route 10.99.0.2"

Der Ausfalltest ist kein optionaler Schritt. Eine Fabric, deren Umweg nie geprüft wurde, ist ein statisches Netz mit mehr Software. Erst wenn der Ping über den dritten Knoten läuft, während ein Kabel gezogen ist, hat die Fabric ihren Zweck bewiesen.

/07Wo es hakt: MTU, FRR, Reifegrad, Fehlersuche

MTU

Die Dokumentation nennt die MTU als Anpassung „based on protocol overhead requirements". Für ein Ceph-Netz auf Direktverbindungen heißt das: Jumbo Frames auf allen Fabric-Schnittstellen, einheitlich, auf jedem Knoten — eine Schnittstelle mit 1500 bei sonst 9000 fällt nicht sofort auf, sondern als sporadische Ceph-Langsamkeit. Für WireGuard und VXLAN darüber gilt die umgekehrte Rechnung: Der Gast muss kleiner werden, nicht das Underlay größer.

FRR gehört jetzt Proxmox

Mit einer Fabric schreibt Proxmox die FRR-Konfiguration. Eigene Anpassungen in /etc/frr/frr.conf werden beim nächsten Anwenden überschrieben. Wer FRR bisher von Hand gepflegt hat — für Ceph-Full-Mesh, für BGP zum Provider —, muss sich entscheiden: Fabric oder Handarbeit, nicht beides auf demselben Knoten. Wer trotzdem lokale Ergänzungen braucht, dokumentiert sie, sonst sucht der nächste Administrator die Herkunft einer Route stundenlang.

Reifegrad

Die Dokumentation trennt deutlich: „Core SDN, which includes VNet management and its integration with the Proxmox VE stack, is fully supported", während „Complex routing via FRRouting and controller integration are in tech preview". Fabrics sind Routing über FRRouting. Für einen Cluster mit Enterprise-Abo heißt das: Der Support hilft, aber die Funktion ist nicht in dem Sinn freigegeben, in dem ein VLAN-VNet freigegeben ist. Das ist kein Ausschlusskriterium, aber ein Eintrag in der Risikobewertung.

Fehlersuche

Die Oberfläche zeigt Routen und Nachbarn je Fabric; darunter liegt vtysh. Die häufigsten Ursachen für eine Fabric, die nicht konvergiert, sind in dieser Reihenfolge: eine Schnittstelle, die noch in /etc/network/interfaces konfiguriert ist; eine doppelte Router-ID; ein FRR-Dienst, der nach dem Upgrade auf 9 mit der alten post-up-Zeile hängt; und ein Kabel, das nicht dort steckt, wo die Dokumentation es vermutet. Wie sich der Cluster verhält, wenn das Corosync-Netz mit über die Fabric läuft, diese kurz konvergiert und damit Fencing auslöst, steht in Warum Corosync nachts Knoten neu startet — die kurze Antwort: Corosync gehört auf ein eigenes, einfaches Netz, nicht auf die Fabric.

/08Fabric gegen VLAN am Switch: die Gegenüberstellung

Die letzte Zeile ist die, die zählt. Ein Drei-Knoten-Cluster an einem redundanten Switch-Stack mit VLANs für Corosync, Ceph und Migration hat kein Underlay-Problem. Eine Fabric würde dort dieselbe Erreichbarkeit mit mehr Software herstellen. Wer sie trotzdem einführt, führt eine Tech-Preview-Komponente in den Pfad ein, den jedes Storage-Paket nimmt — ohne dass irgendetwas besser wird.

/09Wann Fabrics die richtige Wahl sind — und wann das VLAN bleibt

Fabric, wenn

• Ceph auf drei bis vier Knoten ohne eigenen Storage-Switch laufen soll: Full Mesh mit OpenFabric spart die Switches und liefert den automatischen Umweg — der häufigste gute Grund im Mittelstand.
• Eine EVPN-Zone über mehr als einen Standort geplant ist: Dann braucht es ein geroutetes Underlay mit stabilen Knotenadressen, und die Fabric ist der vorgesehene Weg.
• Ein Knoten über eine fremde Strecke angebunden wird — Colocation, zweiter Standort, Cloud — und die Verschlüsselung beim Cluster statt bei der Firewall liegen soll: WireGuard-Fabric mit OSPF oder BGP darüber.
• FRR bisher von Hand gepflegt wurde: Die Fabric ersetzt die Handarbeit durch eine Konfiguration, die im Cluster-Dateisystem liegt und im Ressourcenbaum sichtbar ist.

VLAN, wenn

• Der Cluster an einem Standort an einem redundanten Switch-Stack hängt: Es gibt kein Problem, das die Fabric löst.
• Eine Vorgabe Tech-Preview-Funktionen im Storage- oder Cluster-Pfad ausschließt: Damit ist die Entscheidung gefallen.
• Niemand im Haus Routing-Protokolle liest: Eine Fabric, deren Ausgabe von show openfabric route niemand deuten kann, ist im Fehlerfall schlechter als ein VLAN, das jeder Netzwerker kennt.
• Die beiden Standorte ohnehin getrennte Cluster sind: Dann ist Replikation plus Datacenter Manager die Antwort, nicht ein gedehnter Cluster mit Fabric.

Unsere Praxis-Linie: Fabrics setzen wir dort ein, wo sie Hardware sparen oder eine Kopplung sauberer machen als die Alternative — Ceph-Full-Mesh bei kleinen Clustern, WireGuard für den Knoten außer Haus. Alles andere bleibt VLAN am Switch, bis Proxmox das Routing aus der Vorschau entlässt. Das ist keine Skepsis gegenüber der Funktion, sondern die Regel, dass der Storage-Pfad die langweiligste Komponente im Cluster sein sollte.

/10Häufige Fragen