> 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/fr/guide-de-mise-en-oeuvre/network-design.md). # Conception réseau Veuillez consulter les [concepts de base](/plan-and-deploy/fr/guide-de-mise-en-oeuvre/concepts.md) d’abord pour en savoir plus sur les types de réseau VergeOS avant de consulter ce document. {% hint style="info" %} **Les modèles de réseau suivants sont conçus pour la redondance** {% endhint %} ## Exigences génériques (tous les modèles de conception réseau) {% hint style="info" %} **Pour les environnements comptant plus de 2 nœuds, des commutateurs sont requis pour** [**réseaux Core Fabric**](/overview/fr/glossary.md#core-fabric-network) {% endhint %} ### Exigences du réseau Core Fabric * Des trames jumbo configurées sur tous les ports de commutation du réseau Core Fabric * Taille MTU minimale de 9000 * Taille MTU recommandée de **9216** et plus * Le trafic de diffusion est autorisé entre les nœuds * Les réseaux Core Fabric 1 et 2 sur leurs **propres** réseaux dédiés de couche 2 * Les réseaux Core Fabric pour les systèmes VergeOS situés sur le même site doivent être totalement isolés les uns des autres * La latence réseau entre les nœuds sur les réseaux Core Fabric doit être <0,05 ms (aucun saut de commutateur) {% hint style="warning" %} **Réseau Core Fabric - Aucun saut de commutateur entre les nœuds** Tous les nœuds doivent être connectés au même tissu de commutation avec **zéro saut de commutateur** entre eux. L’ajout de sauts de commutateur dans le chemin du core fabric introduira une latence qui peut avoir un impact important sur les performances et la stabilité du cluster. Cette exigence s’applique à tous les réseaux Core Fabric. {% endhint %} ### Exigences des réseaux externes * MTU standard (1500) configuré sur tous les ports de commutation du réseau externe * Trames jumbo (9000-9216) facultatives si requises par les charges de travail * Réseaux externes configurés en trunks VLAN (balises 802.1Q) * Plusieurs VLAN autorisés sur les ports trunk pour la séparation des charges de travail/locataires * La liaison LACP (802.3ad) est recommandée pour la redondance et l’agrégation de bande passante * La liaison actif/veille est prise en charge comme alternative * Une latence réseau <1 ms est acceptable pour la plupart des charges de travail * Routable vers les réseaux amont (passerelles, Internet, autre infrastructure) * Le protocole Spanning Tree est autorisé (fonctionnement standard de couche 2) ## Couche 2 statique + Core Fabric dédié Ce modèle utilise un réseau de couche 2 agrégé pour les réseaux Externe, UI et de gestion API, tout en conservant des réseaux de couche 2 dédiés pour le trafic Core Fabric. ### Cas d'utilisation * Environnements de production haute performance * Environnements VMware existants utilisant un Distributed Switch * Environnements dans lesquels vous souhaitez déployer des VM directement dans des VLAN externes à VergeOS ### Exigences * 4 ports réseau 10/25/40/100 GbE par nœud * Infrastructure de commutation prenant en charge le stacking (MLAG) - pour le réseau externe ### Configuration réseau * 4 réseaux physiques VergeOS : * Réseau Core Fabric 1 * Réseau Core Fabric 2 * Réseau externe 1 - liaison principale * Réseau externe 2 - liaison secondaire * Les réseaux Core Fabric 1 et 2 sur leurs **propres** réseaux dédiés de couche 2 * Un seul VLAN pour la gestion UI/API (sur le réseau externe principal agrégé) * Tout autre VLAN requis pour vos charges de travail (sur le réseau externe principal agrégé) ### Schéma ![Couche 2 agrégée + Core dédié](/files/c3c51916f90a25a50a14c8e177dd9900ced45d52) ## Couche 3 dynamique + Core Fabric dédié Ce modèle utilise des réseaux de couche 3 annoncés dynamiquement pour les réseaux Externe, UI et de gestion API, tout en conservant des réseaux de couche 2 dédiés pour le trafic Core Fabric. ### Cas d'utilisation pour L3+DC * Environnements de production haute performance * Déploiements à grande échelle * Environnements nécessitant une segmentation réseau avancée ### Exigences * 4 ports d’adaptateur réseau 10/25/40/100 Gb par nœud contrôleur * Un réseau de couche 3 externe au système avec lequel VergeOS peut établir un peering * Fonctionnalités BGP, OSPF ou EIGRP * Utilisation des réseaux internes VergeOS pour les charges de travail ### Configuration réseau * 4 réseaux physiques VergeOS : * Réseau Core Fabric 1 * Réseau Core Fabric 2 * Réseau externe 1 * Réseau externe 2 * Les réseaux Core Fabric 1 et 2 sur leurs **propres** réseaux dédiés de couche 2 * Un seul réseau annoncé dynamiquement pour la gestion UI/API * Tout autre réseau annoncé dynamiquement requis pour vos charges de travail ### Schéma ![Couche 3 agrégée + Core dédié](/files/c2f0ed9080c30f21800db13b0de8e8386eab9ebc) ## Couche 3 statique + Core Fabric dédié Ce modèle utilise un réseau de couche 3 agrégé pour les réseaux Externe, UI et de gestion API, tout en conservant des réseaux de couche 2 dédiés pour le trafic Core Fabric. ### Cas d'utilisation pour L3+DC * Environnements de production haute performance * Déploiements à grande échelle * Environnements nécessitant une segmentation réseau avancée ### Exigences * 4 ports d’adaptateur réseau 10/25/40/100 Gb par nœud contrôleur * Infrastructure de commutation prenant en charge le stacking (MLAG) - pour le réseau externe * Infrastructure de commutation compatible couche 3 pour le réseau externe * Utilisation des réseaux internes VergeOS pour les charges de travail ### Configuration réseau * 4 réseaux physiques VergeOS : * Réseau Core Fabric 1 * Réseau Core Fabric 2 * Réseau externe 1 - liaison principale * Réseau externe 2 - liaison secondaire * Les réseaux Core Fabric 1 et 2 sur leurs **propres** réseaux dédiés de couche 2 * Un seul réseau routé statiquement pour la gestion UI/API * Tout autre réseau routé statiquement requis pour vos charges de travail ### Schéma ![Couche 3 agrégée + Core dédié](/files/ab6ae8bafb041cf91cb3b4aadafc985cc07c277a) ## Couche 2 statique utilisant 2 ports réseau Dans ce modèle, tous les réseaux (Core Fabric, Externe/Gestion, Charges de travail) sont regroupés en un seul réseau physique VergeOS agrégé. ### Cas d'utilisation - 2 ports réseau * Preuves de concept * Petits déploiements Edge * Configurations de reprise après sinistre * Charges de travail de développement * Fournisseurs de cloud bare metal {% hint style="info" %} **Chaque réseau attribué statiquement que vous acheminez vers VergeOS dans cette conception système sera non redondant** {% endhint %} ### Exigences - 2 ports réseau * 2 ports d’adaptateur réseau 10/25/40/100 GbE par nœud * Capacité à trunker des VLAN et à définir un VLAN natif sur le commutateur ### Configuration réseau - 2 ports réseau * 2 réseaux physiques * Réseau Core Fabric 1 * Réseau Core Fabric 2 * Tous les réseaux marqués par VLAN * Les VLAN des réseaux cœur définis comme natifs * Un seul VLAN pour la gestion UI/API (sur l’un ou l’autre des réseaux Core Fabric) * Tout autre VLAN requis pour vos charges de travail (sur l’un ou l’autre des réseaux Core Fabric) ### Schéma - 2 ports réseau ![Couche 2 agrégée](/files/b1cd520ec4657ade9c30c86bf087221cdd6d0d17) En choisissant le modèle de conception réseau approprié en fonction de votre cas d’utilisation et de vos exigences spécifiques, vous pouvez garantir des performances optimales et une évolutivité optimale pour votre déploiement VergeOS. --- # 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/fr/guide-de-mise-en-oeuvre/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.