> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/plan-and-deploy/de/implementierungsleitfaden/network-design.md). # Netzwerkdesign Bitte überprüfen Sie die [Kernkonzepte](/plan-and-deploy/de/implementierungsleitfaden/concepts.md) zuerst, um mehr über die VergeOS-Netzwerktypen zu erfahren, bevor Sie dieses Dokument lesen. {% hint style="info" %} **Die folgenden Netzwerkmodelle sind für Redundanz ausgelegt** {% endhint %} ## Allgemeine Anforderungen (alle Netzwerkdesignmodelle) {% hint style="info" %} **Für Umgebungen mit mehr als 2 Knoten sind Switches erforderlich für** [**Core-Fabric-Netzwerke**](/overview/de/glossary.md#core-fabric-network) {% endhint %} ### Anforderungen an das Core-Fabric-Netzwerk * Jumbo-Frames auf allen Switchports des Core-Fabric-Netzwerks konfiguriert * Minimale MTU-Größe 9000 * Empfohlene MTU-Größe von **9216** und höher * Broadcast-Traffic zwischen Knoten erlaubt * Core-Fabric-Netzwerke 1 und 2 auf ihren **eigenen** dedizierten Layer-2-Netzwerken * Die Core-Fabric-Netzwerke für im selben Standort befindliche VergeOS-Systeme müssen vollständig voneinander isoliert sein * Die Netzwerklatenz zwischen Knoten in Core-Fabric-Netzwerken sollte <0,05 ms betragen (keine Switch-Hops) {% hint style="warning" %} **Core-Fabric-Netzwerk - Keine Switch-Hops zwischen Knoten** Alle Knoten müssen mit derselben Switching-Fabric verbunden sein mit **null Switch-Hops** zwischen ihnen. Das Hinzufügen von Switch-Hops im Core-Fabric-Pfad führt zu Latenz, die die Clusterleistung und -stabilität erheblich beeinträchtigen kann. Diese Anforderung gilt für alle Core-Fabric-Netzwerke. {% endhint %} ### Anforderungen an externe Netzwerke * Standard-MTU (1500) auf allen Switchports des externen Netzwerks konfiguriert * Jumbo-Frames (9000-9216) optional, falls von Workloads erforderlich * Externe Netzwerke als VLAN-Trunks konfiguriert (802.1Q-getaggt) * Mehrere VLANs auf Trunk-Ports für Workload-/Mandantentrennung erlaubt * LACP-(802.3ad)-Bonding für Redundanz und Bandbreitenbündelung empfohlen * Active-Backup-Bonding als Alternative unterstützt * Netzwerklatenz <1 ms für die meisten Workloads akzeptabel * Zu vorgelagerten Netzwerken routbar (Gateways, Internet, andere Infrastruktur) * Spanning-Tree-Protokoll erlaubt (standardmäßiger Layer-2-Betrieb) ## Layer-2-statisch + dediziertes Core-Fabric Dieses Modell verwendet ein gebündeltes Layer-2-Netzwerk für die externen, UI- und API-Management-Netzwerke, während dedizierte Layer-2-Netzwerke für den Core-Fabric-Traffic beibehalten werden. ### Anwendungsfälle * Hochleistungs-Produktionsumgebungen * Bestehende VMware-Umgebungen mit einem Distributed Switch * Umgebungen, in denen Sie VMs direkt in VLANs bereitstellen möchten, die extern zu VergeOS sind ### Anforderungen * 4 x 10/25/40/100GbE-Netzwerkports pro Knoten * Switching-Infrastruktur, die Stacking (MLAG) unterstützt - für das externe Netzwerk ### Netzwerkkonfiguration * 4 physische VergeOS-Netzwerke: * Core-Fabric-Netzwerk 1 * Core-Fabric-Netzwerk 2 * Externes Netzwerk 1 - Primärer Bond * Externes Netzwerk 2 - Sekundärer Bond * Core-Fabric-Netzwerke 1 und 2 auf ihren **eigenen** dedizierten Layer-2-Netzwerken * Ein einzelnes VLAN für UI-/API-Management (auf dem primär gebündelten externen Netzwerk) * Alle weiteren für Ihre Workloads erforderlichen VLANs (auf dem primär gebündelten externen Netzwerk) ### Diagramm ![Auf Layer 2 gebündelt + dediziertes Core](/files/821541dadae7f9c739bf487dde1086b7a91edfa8) ## Dynamisch auf Layer 3 + dediziertes Core-Fabric Dieses Modell verwendet dynamisch angekündigte Layer-3-Netzwerke für die externen, UI- und API-Management-Netzwerke, während dedizierte Layer-2-Netzwerke für den Core-Fabric-Traffic beibehalten werden. ### Anwendungsfälle für L3+DC * Hochleistungs-Produktionsumgebungen * Groß angelegte Bereitstellungen * Umgebungen, die eine erweiterte Netzsegmentierung erfordern ### Anforderungen * 4 x 10/25/40/100Gb-Netzwerkadapterports pro Controller-Knoten * Ein Layer-3-Netzwerk außerhalb des Systems, mit dem VergeOS peeren kann * BGP-, OSPF- oder EIGRP-Funktionen * Verwendung interner VergeOS-Netzwerke für Workloads ### Netzwerkkonfiguration * 4 physische VergeOS-Netzwerke: * Core-Fabric-Netzwerk 1 * Core-Fabric-Netzwerk 2 * Externes Netzwerk 1 * Externes Netzwerk 2 * Core-Fabric-Netzwerke 1 und 2 auf ihren **eigenen** dedizierten Layer-2-Netzwerken * Ein einzelnes dynamisch angekündigtes Netzwerk für UI-/API-Management * Alle weiteren dynamisch angekündigten Netzwerke, die für Ihre Workloads erforderlich sind ### Diagramm ![Gebündelt auf Layer 3 + dediziertes Core](/files/432e47d34326a053ae7a0ba26ba005d229540def) ## Statisch auf Layer 3 + dediziertes Core-Fabric Dieses Modell verwendet ein gebündeltes Layer-3-Netzwerk für die externen, UI- und API-Management-Netzwerke, während dedizierte Layer-2-Netzwerke für den Core-Fabric-Traffic beibehalten werden. ### Anwendungsfälle für L3+DC * Hochleistungs-Produktionsumgebungen * Groß angelegte Bereitstellungen * Umgebungen, die eine erweiterte Netzsegmentierung erfordern ### Anforderungen * 4 x 10/25/40/100Gb-Netzwerkadapterports pro Controller-Knoten * Switching-Infrastruktur, die Stacking (MLAG) unterstützt - für das externe Netzwerk * Switching-Infrastruktur mit Layer-3-Fähigkeit für das externe Netzwerk * Verwendung interner VergeOS-Netzwerke für Workloads ### Netzwerkkonfiguration * 4 physische VergeOS-Netzwerke: * Core-Fabric-Netzwerk 1 * Core-Fabric-Netzwerk 2 * Externes Netzwerk 1 - Primärer Bond * Externes Netzwerk 2 - Sekundärer Bond * Core-Fabric-Netzwerke 1 und 2 auf ihren **eigenen** dedizierten Layer-2-Netzwerken * Ein einzelnes statisch geroutetes Netzwerk für UI-/API-Management * Alle weiteren statisch gerouteten Netzwerke, die für Ihre Workloads erforderlich sind ### Diagramm ![Gebündelt auf Layer 3 + dediziertes Core](/files/ff522514ab2957bd94d7492231d4b120e1d6e1c9) ## Statisch auf Layer 2 mit 2 Netzwerkports In diesem Modell werden alle Netzwerke (Core Fabric, Extern/Management, Workloads) in einem einzigen gebündelten VergeOS Physical Network zusammengeführt. ### Anwendungsfälle - 2 Netzwerkports * Proof-of-Concepts * Kleine Edge-Bereitstellungen * Disaster-Recovery-Setups * Entwicklungs-Workloads * Bare-Metal-Cloud-Anbieter {% hint style="info" %} **Jedes statisch zugewiesene Netzwerk, das Sie in diesem Systemdesign zu VergeOS routen, ist nicht redundant** {% endhint %} ### Anforderungen - 2 Netzwerkports * 2 x 10/25/40/100GbE-Netzwerkadapterports pro Knoten * Fähigkeit, VLANs zu trunkieren und am Switch ein natives VLAN festzulegen ### Netzwerkkonfiguration - 2 Netzwerkports * 2 physische Netzwerke * Core-Fabric-Netzwerk 1 * Core-Fabric-Netzwerk 2 * Alle Netzwerke VLAN-getaggt * Core-Netzwerk-VLANs als native festgelegt * Ein einzelnes VLAN für UI-/API-Management (jeweils Core-Fabric-Netzwerk) * Alle weiteren für Ihre Workloads erforderlichen VLANs (jeweils Core-Fabric-Netzwerk) ### Diagramm - 2 Netzwerkports ![Auf Layer 2 gebündelt](/files/65b4ca839b2ef19d61ca54f03ced3569d7418e1e) Durch die Wahl des geeigneten Netzwerkdesignmodells auf Basis Ihres spezifischen Anwendungsfalls und Ihrer Anforderungen können Sie optimale Leistung und Skalierbarkeit für Ihre VergeOS-Bereitstellung sicherstellen. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verge.io/plan-and-deploy/de/implementierungsleitfaden/network-design.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.