Kern-Fabric & Netzwerk

Verstehen Sie die VergeOS-Kern-Fabric — das private Knoten-Mesh, das vSAN-Replikation, VM-Migration und Control-Plane-Traffic transportiert — sowie das Modell der Trennung externer Netzwerke.

Was ist die Core Fabric?

Das Core Fabric ist ein privates, Hochgeschwindigkeits-Netzwerkmesh, das alle Knoten in einem VergeOS-System miteinander verbindet. Es ist das Rückgrat jeder VergeOS-Bereitstellung — die gesamte interne Clusterkommunikation läuft über dieses Fabric. Die Core Fabric wird niemals externem Traffic ausgesetzt.

Zu den Verkehrstypen, die über die Core Fabric laufen, gehören:

• vSAN-Replikation — Primäre und redundante Schreibvorgänge von Datenblöcken zwischen speicherbeteiligten Knoten
• Cluster-Koordination — Knoten-Gesundheitsprüfungen, Führungswahl und Synchronisierung des Systemzustands
• Live-Migration von VMs — Übertragung von Speicher- und CPU-Zustand beim Verschieben laufender VMs zwischen Knoten
• Kontrollebene — API-Aufrufe, Konfigurationsaktualisierungen und Verwaltungskommunikation zwischen VergeOS-Diensten

Die Core Fabric ist ausgelegt auf geringe Latenz und hohen Durchsatz. Da die vSAN-Leistung direkt von der Geschwindigkeit und Zuverlässigkeit der Kommunikation zwischen den Knoten abhängt, ist die Core Fabric das Netzwerk mit der höchsten Leistungsrelevanz in einem VergeOS-System.

VMware Bridge

In VMware erhalten vMotion, vSAN-Replikation, Verwaltung und anderer Verkehr zwischen Knoten jeweils eine eigene VMkernel-Portgruppe auf einem vDS, mit VLANs und Uplink-Failover-Richtlinien pro Verkehrstyp. Die VergeOS Core Fabric transportiert den gesamten Verkehr zwischen den Knoten über ein redundantes privates Mesh — es müssen keine Portgruppen pro Typ geplant werden.

Nutanix Bridge

Nutanix' CVM-zu-CVM-Backplane-Netzwerk benötigt eine explizite VLAN/IP-Konfiguration für die Backplane, die CVM und das Hypervisor-Management. Die VergeOS Core Fabric ist ein privates Layer-2-Mesh ohne IPs oder VLANs — Knoten erkennen sich automatisch.

Dual-Switch-Redundanz

Zur Fehlertoleranz läuft die Core Fabric über zwei unabhängige physische Netzwerke — bezeichnet als Core Fabric 1 und Core Fabric 2 (oder Core 1 / Core 2). Jedes Fabric-Netzwerk ist eine eigene isolierte Layer-2-Broadcast-Domäne.

Jeder Knoten verbindet sich mit sowohl Fabric-Netzwerken. Fällt ein Switch- oder Kabelpfad aus, hält das andere Fabric-Netzwerk die vollständige Konnektivität zwischen den Knoten ohne Unterbrechung der vSAN-Replikation, Live-Migration oder Cluster-Koordination aufrecht.

Layer-2-Switches, Layer 3 von VergeOS übernommen

Sie konfigurieren die physischen Core-Fabric-Switches für nur Layer 2 — isolierte Broadcast-Domänen ohne Routing. VergeOS übernimmt die gesamte Layer-3-Adressierung und das Routing (das unten beschriebene Core-Netzwerk-Overlay) über diese Layer-2-Netzwerke. Auf den Switches selbst ist keine Layer-3-Konfiguration erforderlich.

Wichtige Designregeln

Anforderung	Details
Isolation	Core Fabric 1 und Core Fabric 2 müssen auf ihren eigenen dedizierten Layer-2-Netzwerken liegen, vollständig voneinander und vom externen Verkehr isoliert
Jumbo Frames	MTU 9216 oder höher auf allen Core-Fabric-Switch-Ports (9216 berücksichtigt die 9000-Byte-Nutzlast plus VLAN-Tags, Header und Tenant-Overhead)
Keine Switch-Hops	Alle Knoten müssen sich auf derselben Switching-Fabric befinden, ohne Switch-Hops im Pfad der Core Fabric — zusätzliche Hops führen zu Latenz, die die vSAN-Leistung beeinträchtigt
Port-Modus	Access-Ports (untagged, ein VLAN pro Core-Fabric-Netzwerk)
Spanning Tree	Auf Core-Fabric-Ports deaktiviert (BPDU Guard deaktivieren, PortFast deaktivieren) — STP sollte nicht für Core-Fabric-Verbindungen verwendet werden. Idealerweise würde dieser Verkehr den Switch nicht verlassen.
Geschwindigkeit	10 Gbit/s oder höher empfohlen

Hinweis zum Playground: Der Terraform-Playground verwendet MTU 9142 für seine virtuellen Core-Fabric-Netzwerke. Produktionsbereitstellungen sollten gemäß der offiziellen VergeOS-Dokumentation MTU 9216 oder höher verwenden.

Core-Netzwerk-Overlay

Auf Basis der beiden physischen Fabric-Netzwerke erstellt VergeOS ein virtuelles Core-Netzwerk — eine logische Überlagerung mit dem Adressbereich 100.96.0.0/24. Dieses Core-Netzwerk stellt jedem Knoten eine stabile interne IP-Adresse bereit, die von den VergeOS-Diensten verwendet wird.

Die Beziehung ist:

• Core Fabric 1 und Core Fabric 2 sind die Übertragungen auf physischer Ebene (Layer-2-Netzwerke)
• Core-Netzwerk (100.96.0.0/24) ist das logische Overlay, das auf beiden Fabric-Switches aufsetzt

Das Core-Netzwerk abstrahiert die zugrunde liegende Redundanz mit doppeltem Pfad, sodass VergeOS-Dienste eine einzelne Adresse pro Knoten verwenden, unabhängig davon, welches physische Fabric aktiv ist.

IP-Adresszuweisungen

Netzwerk	Knoten 1	Knoten 2	Knoten 3+
Kernnetzwerk	100.96.0.2	100.96.0.3	100.96.0.(N+1)
Core Fabric 1	172.16.1.1	172.16.1.2	172.16.1.N
Core Fabric 2	172.16.2.1	172.16.2.2	172.16.2.N
Externe	Statisch (konfiguriert)	Statisch (konfiguriert)	DHCP oder statisch

Für das Core-Netzwerk, 100.96.0.1 ist als Cluster-Gateway reserviert; die Adressen pro Knoten beginnen bei .2 für Knoten 1 und steigen von dort aus.

Das 172.16.1.0/24 und 172.16.2.0/24 Core-Fabric-Subnetze sind die Standardwerte, die zugewiesen werden, wenn die Core-Netzwerke konfiguriert werden vor dem das externe Netzwerk während der Installation. Wenn das externe Netzwerk zuerst zugewiesen wird, weist VergeOS den Core Fabrics andere Subnetze zu.

Knoten-Netzwerkverbindungen

Ein typischer VergeOS-Knoten hat vier Netzwerkschnittstellen — zwei für die Core Fabric und zwei für extern:

NICs	Verbindung	Zweck
NIC 1	Core Fabric 1	Primärer Pfad für den gesamten Verkehr zwischen Knoten
NIC 2	Core Fabric 2	Redundanter Pfad für den gesamten Verkehr zwischen Knoten
NIC 3 + 4	Externes Netzwerk	Zugriff auf Management-UI/API, Benutzerverkehr, Internetverbindung

Die tatsächlichen NIC-Gerätenamen variieren je nach Hardware (z. B. eno1, enp3s0f0, eth0). Während der Installation wählen Sie aus, welche physische NIC welcher Rolle zugeordnet wird.

Die externen NICs sind typischerweise gebündelt (LACP oder Active-Backup) zur Redundanz. VergeOS unterstützt sowohl switchbasiertes Bonding (LACP) als auch sein eigenes softwarebasiertes Bonding — keine Switch-Konfiguration erforderlich. Die beiden Core-Fabric-NICs dürfen nicht gebündelt werden — physisches LAG oder Port-Bonding beeinträchtigt die eingebaute Redundanz der Fabric, die eine breitere Palette von Problemen (verlorene Pakete, MTU-Mismatches, NIC-Blockierungen, fehlerhafte Firmware) auf Anwendungsebene erkennt, als LAG es kann. Jede Core-Fabric-NIC verbindet sich mit ihrem eigenen unabhängigen Switch.

Trennung von externem Netzwerk und Core Fabric

VergeOS erzwingt eine strikte Trennung zwischen extern gerichtetem Verkehr und internem Clusterverkehr. Dies sind zwei grundlegend unterschiedliche Netzwerkdomänen:

Externe Netzwerke

• VergeOS mit vorhandener LAN/WAN-Infrastruktur verbinden
• Benutzergerichteten Verkehr übertragen: Zugriff auf die Management-UI, VM-Workload-Konnektivität, Internetzugang
• Standard-MTU (1500) verwenden, sofern Workloads keine Jumbo Frames erfordern
• Als VLAN-Trunks konfiguriert (802.1Q-getaggt), um mehrere VLANs für Tenant- und Workload-Trennung zu unterstützen
• Typischerweise gebündelt (LACP oder Active-Backup) für Redundanz
• Kann mehrere externe Netzwerke pro System geben (z. B. Management-VLAN, Produktions-VLAN, DMZ-VLAN)

Core-Fabric-Netzwerke

• Vollständig privat — niemals externem Verkehr oder Benutzern ausgesetzt
• Transportieren den gesamten Systemverkehr zwischen den Knoten (vSAN, Migration, Koordination)
• Erfordern Jumbo Frames (MTU 9216+) für Speichereffizienz
• Als Access-Ports konfiguriert (untagged, ein VLAN pro Fabric)
• Immer zwei unabhängige Fabrics für Redundanz
• Müssen zwischen den Knoten null Switch-Hops aufweisen, um geringe Latenz zu gewährleisten

Das DMZ-Netzwerk

VergeOS erstellt automatisch eine DMZ-Netzwerk während der Installation. Die DMZ dient als zentraler Verbindungspunkt für alle virtuellen Netzwerke im System. Jede VergeOS-Cloud (ob Host-System oder Tenant) hat genau ein DMZ-Netzwerk.

Die DMZ bietet Layer-3-Routing zwischen Netzwerken. Jeder Netzwerktyp (extern, intern, Core) hat seinen eigenen virtuellen Router mit einer Schnittstelle in seinem eigenen Netzwerk und einer Schnittstelle in der DMZ. Wenn ein internes Netzwerk ein externes Netzwerk erreichen muss, fließt der Verkehr durch die DMZ, wo Netzwerkregeln und Firewall-Richtlinien an der Routing-Grenze angewendet werden.

Die DMZ verwendet den 100.64.0.0/16 Adressbereich. Jeder Router eines virtuellen Netzwerks — externe Netzwerke, interne Netzwerke, das Core-Netzwerk und alle verschachtelten Tenant-Clouds — hat eine DMZ-Schnittstelle, der eine Adresse aus diesem Subnetz zugewiesen wird:

Aus Sicht des Hosts erscheint ein Tenant als ein weiteres Netzwerk, das mit der DMZ verbunden ist. Intern verfügt der Tenant über seinen eigenen vollständigen Netzwerk-Stack — seine eigene DMZ, seinen eigenen externen Router, interne Netzwerke und VMs — ein vollständig verschachteltes virtuelles Rechenzentrum.

VMware Bridge

VergeFabric fasst zusammen, was VMware über vDS-Portgruppen, NSX-T-Segmente und physische Firewall aufteilt: Die Core Fabric ersetzt VMkernel-Gruppen für vSAN/vMotion/Verwaltung, externe Netzwerke ersetzen vDS-Uplinks für VM-Verkehr, das DMZ-Netzwerk ersetzt die Funktionen von NSX-Edge-Router/Firewall und interne Netzwerke ersetzen NSX-T-Segmente mit integriertem DHCP/DNS/Routing/Firewall.

Nutanix Bridge

Nutanix setzt auf Standard-VLANs, das Flow-Add-on für Mikrosegmentierung und externe Appliances für Routing/Firewalling. VergeOS bietet das Äquivalent nativ: Die Core Fabric ersetzt die CVM-Backplane (keine VLAN-Konfiguration), externe Netzwerke ersetzen VLAN-basierte Uplinks, das DMZ-Netzwerk übernimmt Routing/Firewalling und interne Netzwerke bündeln DHCP/DNS/Routing/Firewall.

Modelle für das Produktionsnetzwerkdesign

In der Produktion unterstützt VergeOS mehrere Netzwerkdesign-Modelle, abhängig von der Anzahl der NICs pro Knoten und den Anforderungen des externen Netzwerks. Alle Modelle behalten die doppelte Core Fabric für Redundanz bei.

4-NIC-Modell (empfohlen)

Die Standard-Produktionskonfiguration verwendet 4 NICs pro Knoten:

NIC	Zuordnung	Konfiguration
NIC 1	Core Fabric 1	Access-Port, dediziertes VLAN, MTU 9216
NIC 2	Core Fabric 2	Access-Port, dediziertes VLAN, MTU 9216
NIC 3	Extern 1 (primärer Bond)	Trunk-Port, LACP, MTU 1500
NIC 4	Extern 2 (sekundärer Bond)	Trunk-Port, LACP, MTU 1500

Dies bietet vollständige Redundanz sowohl auf der Core Fabric (zwei unabhängige Pfade) als auch im externen Netzwerk (gebündeltes Paar).

2-NIC-Modell

Ein 2-NIC-Modell kombiniert Core-Fabric- und externen Verkehr über dieselben physischen Ports mithilfe von VLAN-Tagging:

NIC	Zuordnung	Konfiguration
NIC 1	Core Fabric 1 + externe VLANs	Native VLAN für Core, getaggte VLANs für extern
NIC 2	Core Fabric 2 + externe VLANs	Native VLAN für Core, getaggte VLANs für extern

Dieses Modell eignet sich gut für 100-GbE-Netzwerkports wo zwei Schnittstellen mit hoher Bandbreite mehr als genug Durchsatz sowohl für die Core Fabric als auch für externen Verkehr bieten. Es eignet sich auch für Edge-Standorte und Proof-of-Concept-Bereitstellungen. In diesem Modell kann VergeOS-Software-Bonding verwendet werden, um die Redundanz des externen Netzwerks über beide NICs hinweg bereitzustellen, während die doppelte Core-Fabric-Redundanz erhalten bleibt.

Wie der Terraform-Playground dies modelliert

Im Terraform-Playground wird die Core Fabric als zwei vergeio_network Ressourcen auf dem Host-VergeOS-System modelliert:

• core_fabric_1 — Layer-2-Netzwerk, MTU 9142, kein DHCP
• core_fabric_2 — Layer-2-Netzwerk, MTU 9142, kein DHCP

Jede Knoten-VM erhält drei NICs:

1. NIC 1 → Externes Netzwerk (Management und Benutzerzugriff)
2. NIC 2 → Core Fabric 1
3. NIC 3 → Core Fabric 2

Der Playground verwendet MTU 9142 (anstelle der in der Produktion empfohlenen 9216), da die virtuelle Netzwerkinfrastruktur des Host-Systems zusätzlichen Overhead verursacht. Das Core-Netzwerk-Overlay (100.96.0.0/24)

Wichtige Erkenntnisse

Konzept	Zusammenfassung
Core Fabric	Privates Mesh zwischen den Knoten — transportiert vSAN-, Migrations-, Koordinations- und Kontrollverkehr
Doppelte Redundanz	Zwei unabhängige Fabric-Netzwerke (Core 1 + Core 2) auf separaten Layer-2-Domänen
MTU-Anforderungen	9216+ in der Produktion (9142 im Playground) — Jumbo Frames sind obligatorisch
Core-Netzwerk-Overlay	Logisch 100.96.0.0/24 Netzwerk, das auf beiden Fabric-Switches aufsetzt und stabile interne IPs bereitstellt
3 NICs pro Knoten	Minimum: 1 extern + 2 Core Fabric. In der Produktion werden typischerweise 4+ NICs mit gebündeltem externem Netzwerk verwendet
Keine Switch-Hops	Core-Fabric-Ports müssen sich auf derselben Switching-Fabric befinden — keine Switch-Hops erlaubt
Verkehrsisolation	Die Core Fabric wird niemals externem Verkehr ausgesetzt; externe Netzwerke sind vollständig getrennt
DMZ-Netzwerk	Automatisch erstellter Layer-3-Routing-Hub, der alle virtuellen Netzwerke im System verbindet

Nächste Schritte

Nachdem Sie nun verstanden haben, wie VergeOS-Knoten miteinander verbunden sind, behandelt das nächste Thema, wie diese Knoten in Cluster organisiert werden: Cluster & Knotentypen →