> 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/learn-the-platform/fr/module-1-fondamentaux-de-larchitecture/04-core-fabric.md). # Fabric principal et réseau ## Qu'est-ce que le Core Fabric ? Le **core fabric** est un maillage réseau privé à haut débit qui interconnecte tous les nœuds d’un système VergeOS. C’est l’épine dorsale de chaque déploiement VergeOS — tout le trafic interne du cluster transite par ce maillage. Le Core Fabric n’est jamais exposé au trafic externe. Les types de trafic transportés par le Core Fabric comprennent : * **réplication vSAN** — Écritures de blocs de données primaires et redondantes entre les nœuds participant au stockage * **Coordination du cluster** — Vérifications de l’état des nœuds, élection du leader et synchronisation de l’état du système * **Migration à chaud des VM** — Transfert de l’état mémoire et CPU lors du déplacement de VM en cours d’exécution entre nœuds * **Plan de contrôle** — Appels API, mises à jour de configuration et communication de gestion entre les services VergeOS Le Core Fabric est conçu pour **une faible latence et un débit élevé**. Parce que les performances de vSAN dépendent directement de la vitesse et de la fiabilité des communications entre nœuds, le Core Fabric est le réseau le plus critique en matière de performances dans un système VergeOS. {% hint style="info" %} **Pont VMware** Dans VMware, vMotion, la réplication vSAN, la gestion et les autres trafics entre nœuds disposent chacun de leur propre groupe de ports VMkernel sur un vDS, avec des VLAN et des politiques de basculement des liaisons montantes par type de trafic. Le Core Fabric de VergeOS transporte tout le trafic entre nœuds sur une seule maille privée redondante — aucun groupe de ports par type à planifier. {% endhint %} {% hint style="info" %} **Pont Nutanix** Le réseau de backplane CVM-à-CVM de Nutanix nécessite une configuration explicite VLAN/IP pour le backplane, la CVM et la gestion de l’hyperviseur. Le Core Fabric de VergeOS est une maille privée de couche 2 sans IP ni VLAN — les nœuds se découvrent automatiquement. {% endhint %} ## Redondance à double commutateur Pour la tolérance aux pannes, le Core Fabric s’étend sur **deux réseaux physiques indépendants** — appelés **Core Fabric 1** et **Core Fabric 2** (ou Core 1 / Core 2). Chaque réseau de Core Fabric constitue son propre domaine de diffusion isolé de couche 2. Chaque nœud est connecté aux **les deux** réseaux de maillage. Si un commutateur ou un chemin de câble tombe en panne, l’autre réseau de maillage maintient une connectivité complète entre nœuds, sans interruption de la réplication vSAN, de la migration à chaud ou de la coordination du cluster. {% hint style="info" %} **Commutateurs de couche 2, couche 3 gérée par VergeOS** Vous configurez les commutateurs physiques du Core Fabric en **couche 2 uniquement** — domaines de diffusion isolés sans routage. VergeOS gère tout l’adressage et le routage de couche 3 (la superposition du réseau central décrite ci-dessous) au-dessus de ces réseaux de couche 2. Il n’y a aucune configuration de couche 3 à effectuer sur les commutateurs eux-mêmes. {% endhint %} ```mermaid graph TB subgraph "Infrastructure physique des commutateurs" SW1["Commutateur A
Core Fabric 1
VLAN 900"] SW2["Commutateur B
Core Fabric 2
VLAN 901"] end subgraph "Nœud 1 (contrôleur)" N1_CF1["NIC 1 → Core Fabric 1"] N1_CF2["NIC 2 → Core Fabric 2"] end subgraph "Nœud 2 (contrôleur)" N2_CF1["NIC 1 → Core Fabric 1"] N2_CF2["NIC 2 → Core Fabric 2"] end subgraph "Nœud 3 (scale-out)" N3_CF1["NIC 1 → Core Fabric 1"] N3_CF2["NIC 2 → Core Fabric 2"] end N1_CF1 --- SW1 N2_CF1 --- SW1 N3_CF1 --- SW1 N1_CF2 --- SW2 N2_CF2 --- SW2 N3_CF2 --- SW2 style SW1 fill:#e3f2fd,stroke:#1565c0 style SW2 fill:#e8f5e9,stroke:#2e7d32 ``` ### Règles de conception clés | Exigence | Détail | | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Isolation** | Core Fabric 1 et Core Fabric 2 doivent chacun être sur leur propre réseau de couche 2 dédié, complètement isolé l’un de l’autre et du trafic externe | | **Trames jumbo** | MTU 9216 ou supérieur sur tous les ports de commutateur du Core Fabric (9216 prend en charge la charge utile de 9000 octets, plus les balises VLAN, les en-têtes et la surcharge locataire) | | **Aucun saut de commutateur** | Tous les nœuds doivent être sur la même matrice de commutation, sans saut entre commutateurs sur le chemin du Core Fabric — des sauts supplémentaires introduisent une latence qui dégrade les performances vSAN | | **Mode de port** | Ports d’accès (non tagués, un seul VLAN par réseau de Core Fabric) | | **Spanning tree** | Désactivé sur les ports du Core Fabric (BPDU guard désactivé, portfast désactivé) — STP ne doit pas être utilisé pour les liens Core Fabric. Idéalement, ce trafic ne devrait pas quitter le commutateur. | | **Rapidité** | 10 Gbps ou plus recommandé | > **Note du playground :** Le playground Terraform utilise une MTU de 9142 pour ses réseaux virtuels Core Fabric. Les déploiements de production doivent utiliser une MTU de 9216 ou plus, conformément à la documentation officielle de VergeOS. ## Superposition du réseau central Au-dessus des deux réseaux de maillage physiques, VergeOS crée un **réseau central virtuel** — une superposition logique avec la plage d’adresses `100.96.0.0/24`. Ce réseau central fournit à chaque nœud une adresse IP interne stable utilisée par les services VergeOS. La relation est la suivante : * **Core Fabric 1 et Core Fabric 2** sont les transports de couche physique (réseaux de couche 2) * **Réseau central (`100.96.0.0/24`)** est la superposition logique qui repose sur les deux commutateurs de maillage Le réseau central abstrait la redondance sous-jacente à double chemin, de sorte que les services VergeOS communiquent en utilisant une seule adresse par nœud, quel que soit le maillage physique actif. ### Attributions d’adresses IP | Réseau | Nœud 1 | Nœud 2 | Nœud 3+ | | -------------------- | -------------------- | -------------------- | ---------------- | | **Réseau principal** | 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** | Statique (configuré) | Statique (configuré) | DHCP ou statique | > Pour le **réseau central**, `100.96.0.1` est réservé comme passerelle du cluster ; les adresses par nœud commencent à `.2` pour le nœud 1 et augmentent à partir de là. > Le `172.16.1.0/24` et `172.16.2.0/24` les sous-réseaux du Core Fabric sont ceux attribués par défaut lorsque les réseaux centraux sont configurés **avant** le réseau externe pendant l’installation. Si le réseau externe est attribué en premier, VergeOS alloue des sous-réseaux différents aux Core Fabrics. ```mermaid graph TB subgraph "Superposition logique" CORE["Réseau central
100.96.0.0/24
MTU 9000"] end subgraph "Transport physique" CF1["Core Fabric 1
172.16.1.0/24
MTU 9216"] CF2["Core Fabric 2
172.16.2.0/24
MTU 9216"] end CORE -->|"repose sur"| CF1 CORE -->|"repose sur"| CF2 style CORE fill:#fff3e0,stroke:#e65100 style CF1 fill:#e3f2fd,stroke:#1565c0 style CF2 fill:#e8f5e9,stroke:#2e7d32 ``` ## Connexions réseau des nœuds Un nœud VergeOS typique dispose de **quatre interfaces réseau** — deux pour le Core Fabric et deux pour l’externe : | des NIC | Connexion | Rôle | | --------- | -------------- | ------------------------------------------------------------------------------------------- | | NIC 1 | Core Fabric 1 | Chemin principal pour tout le trafic entre nœuds | | NIC 2 | Core Fabric 2 | Chemin redondant pour tout le trafic entre nœuds | | NIC 3 + 4 | Réseau externe | Accès à l’interface utilisateur/l’API de gestion, trafic utilisateur, connectivité Internet | Les noms réels des périphériques NIC varient selon le matériel (par ex. `eno1`, `enp3s0f0`, `eth0`). Lors de l’installation, vous choisissez quelle NIC physique correspond à chaque rôle. Les NIC externes sont généralement **agrégées** (LACP ou active-backup) pour la redondance. VergeOS prend en charge à la fois l’agrégation basée sur le commutateur (LACP) et sa propre **agrégation logicielle** — aucune configuration de commutateur n’est requise. Les deux NIC du Core Fabric **ne doivent pas** être agrégées — un LAG physique ou une agrégation de ports interfère avec la redondance intégrée de la matrice, qui détecte une gamme plus large de problèmes (paquets perdus, incompatibilités de MTU, blocages de NIC, micrologiciels défectueux) au niveau applicatif, plus largement que ne le peut un LAG. Chaque NIC du Core Fabric se connecte à son propre commutateur indépendant. ```mermaid graph LR subgraph "Nœud" NIC1["NIC 1
Core Fabric 1"] NIC2["NIC 2
Core Fabric 2"] NIC3["NIC 3
Externe"] NIC4["NIC 4
Externe"] end NIC1 --- CF1["Core Fabric 1
MTU 9216+"] NIC2 --- CF2["Core Fabric 2
MTU 9216+"] NIC3 --- BOND["Agrégation (LACP / active-backup)"] NIC4 --- BOND BOND --- EXT["Réseau externe
MTU 1500"] CF1 -.- CORE["Superposition du réseau central"] CF2 -.- CORE style EXT fill:#fce4ec,stroke:#c62828 style BOND fill:#fce4ec,stroke:#c62828 style CF1 fill:#e3f2fd,stroke:#1565c0 style CF2 fill:#e8f5e9,stroke:#2e7d32 style CORE fill:#fff3e0,stroke:#e65100 ``` ## Séparation entre réseau externe et Core Fabric VergeOS impose une séparation stricte entre le trafic orienté vers l’extérieur et le trafic interne du cluster. Il s’agit de deux domaines réseau fondamentalement différents : ### Réseaux externes * Connecte VergeOS à l’infrastructure LAN/WAN existante * Transporte le trafic destiné aux utilisateurs : accès à l’interface de gestion, connectivité des charges de VM, accès à Internet * Utilise une MTU standard (1500) sauf si les charges de travail exigent des trames jumbo * Configuré comme des trunks VLAN (802.1Q tagués) pour prendre en charge plusieurs VLAN pour la séparation des locataires et des charges de travail * Généralement agrégés (LACP ou active-backup) pour la redondance * Peut disposer de plusieurs réseaux externes par système (par ex. VLAN de gestion, VLAN de production, VLAN DMZ) ### Réseaux Core Fabric * Totalement privés — jamais exposés au trafic externe ni aux utilisateurs * Transportent tout le trafic système entre nœuds (vSAN, migration, coordination) * Nécessitent des trames jumbo (MTU 9216+) pour l’efficacité du stockage * Configurés comme ports d’accès (non tagués, un seul VLAN par maillage) * Toujours deux maillages indépendants pour la redondance * Doivent avoir zéro saut de commutateur entre les nœuds pour une faible latence ### Le réseau DMZ VergeOS crée automatiquement un **réseau DMZ** réseau DMZ pendant l’installation. La DMZ sert de point de connexion central pour tous les réseaux virtuels du système. Chaque cloud VergeOS (qu’il s’agisse du système hôte ou d’un locataire) possède exactement un réseau DMZ. La DMZ fournit **le routage de couche 3** entre les réseaux. Chaque type de réseau (externe, interne, central) possède son propre routeur virtuel, avec une interface sur son propre réseau et une interface sur la DMZ. Lorsqu’un réseau interne doit joindre un réseau externe, le trafic passe par la DMZ, où les règles réseau et les politiques de pare-feu sont appliquées à la frontière de routage. La DMZ utilise `100.64.0.0/16` la plage d’adresses. Chaque routeur de réseau virtuel — réseaux externes, réseaux internes, réseau central et tout cloud locataire imbriqué — dispose d’une interface DMZ à laquelle est attribuée une adresse de ce sous-réseau : ```mermaid graph TB FAI["FAI / Routeur amont"] EXT["Routeur du réseau externe
Eth0 : IP externe
Eth1/DMZ : 100.64.0.3"] DMZ["Réseau DMZ
100.64.0.0/16
(hub de routage de couche 3)"] CORE["Routeur du réseau central
Eth0 : 100.96.0.1/24
Eth1/DMZ : 100.64.0.2"] INT1["Routeur du réseau interne
Eth0 : 192.168.0.1/24
Eth1/DMZ : 100.64.0.4"] TENANT["Réseau locataire
(du point de vue de l’hôte)
Eth0 : 100.96.0.1/24
Eth1/DMZ : 100.64.0.5"] ["VM"] subgraph tenant_inside["À l’intérieur du locataire (son propre VDC)"] T_EXT["Routeur externe du locataire
Eth0 : 100.96.0.2/24
Eth1/DMZ : 100.64.0.3"] T_DMZ["DMZ du locataire
100.64.0.0/16"] T_INT["Routeur interne du locataire
Eth0 : 192.168.0.1/24
Eth1/DMZ : 100.64.0.4"] T_VM["VM du locataire"] T_EXT <--> T_DMZ T_INT <--> T_DMZ T_INT <--> T_VM end FAI <--> EXT EXT <--> DMZ CORE <--> DMZ INT1 <--> DMZ TENANT <--> DMZ INT1 <--> VM1 TENANT <--> T_EXT style ISP fill:#fce4ec,stroke:#c62828 style EXT fill:#fce4ec,stroke:#c62828 style DMZ fill:#fff3e0,stroke:#e65100 style CORE fill:#e3f2fd,stroke:#1565c0 style INT1 fill:#e8f5e9,stroke:#2e7d32 style VM1 fill:#e8f5e9,stroke:#2e7d32 style TENANT fill:#e8eaf6,stroke:#283593 style tenant_inside fill:#e8eaf6,stroke:#283593 style T_EXT fill:#fce4ec,stroke:#c62828 style T_DMZ fill:#fff3e0,stroke:#e65100 style T_INT fill:#e8f5e9,stroke:#2e7d32 style T_VM fill:#e8f5e9,stroke:#2e7d32 ``` Du point de vue de l’hôte, un locataire apparaît comme un autre réseau connecté à la DMZ. À l’intérieur, le locataire dispose de sa propre pile réseau complète — sa propre DMZ, son propre routeur externe, ses réseaux internes et ses VM — un centre de données virtuel entièrement imbriqué. {% hint style="info" %} **Pont VMware** VergeFabric regroupe ce que VMware répartit entre les groupes de ports vDS, les segments NSX-T et le pare-feu physique : le Core Fabric remplace les groupes VMkernel pour vSAN/vMotion/la gestion, les réseaux externes remplacent les liaisons montantes vDS pour le trafic des VM, le réseau DMZ remplace les fonctions de routeur/pare-feu NSX Edge, et les réseaux internes remplacent les segments NSX-T avec DHCP/DNS/routage/pare-feu intégrés. {% endhint %} {% hint style="info" %} **Pont Nutanix** Nutanix s’appuie sur des VLAN standard, le module complémentaire Flow pour la micro-segmentation et des appliances externes pour le routage/le pare-feu. VergeOS fournit l’équivalent nativement : le Core Fabric remplace le backplane CVM (sans configuration VLAN), les réseaux externes remplacent les liaisons montantes basées sur VLAN, le réseau DMZ gère le routage/le pare-feu, et les réseaux internes regroupent DHCP/DNS/routage/pare-feu. {% endhint %} ## Modèles de conception du réseau de production En production, VergeOS prend en charge plusieurs modèles de conception de réseau selon le nombre de NIC par nœud et les exigences du réseau externe. Tous les modèles conservent la double matrice principale pour la redondance. ### Modèle à 4 NIC (recommandé) La configuration de production standard utilise 4 NIC par nœud : | NIC | Affectation | Configuration | | ----- | --------------------------------- | ---------------------------------- | | NIC 1 | Core Fabric 1 | Port d’accès, VLAN dédié, MTU 9216 | | NIC 2 | Core Fabric 2 | Port d’accès, VLAN dédié, MTU 9216 | | NIC 3 | Externe 1 (agrégation principale) | Port trunk, LACP, MTU 1500 | | NIC 4 | Externe 2 (agrégation secondaire) | Port trunk, LACP, MTU 1500 | Cela offre une redondance complète à la fois sur le Core Fabric (deux chemins indépendants) et sur le réseau externe (paire agrégée). ### Modèle à 2 NIC Un modèle à 2 NIC combine le trafic du Core Fabric et le trafic externe sur les mêmes ports physiques à l’aide du marquage VLAN : | NIC | Affectation | Configuration | | ----- | ----------------------------- | --------------------------------------------------- | | NIC 1 | Core Fabric 1 + VLAN externes | VLAN natif pour le Core, VLAN tagués pour l’externe | | NIC 2 | Core Fabric 2 + VLAN externes | VLAN natif pour le Core, VLAN tagués pour l’externe | Ce modèle fonctionne bien pour **ports réseau 100 GbE** où deux interfaces à large bande passante offrent largement assez de débit pour le Core Fabric et le trafic externe. Il convient aussi aux sites en périphérie et aux déploiements de preuve de concept. L’agrégation logicielle VergeOS peut être utilisée dans ce modèle pour assurer la redondance du réseau externe sur les deux NIC, tout en conservant la redondance double du Core Fabric. ## Comment le Terraform Playground modélise cela Dans le playground Terraform, le Core Fabric est modélisé comme deux `vergeio_network` ressources sur le système VergeOS hôte : * `core_fabric_1` — réseau de couche 2, MTU 9142, sans DHCP * `core_fabric_2` — réseau de couche 2, MTU 9142, sans DHCP Chaque VM de nœud reçoit trois NIC : 1. **NIC 1** → Réseau externe (gestion et accès utilisateur) 2. **NIC 2** → Core Fabric 1 3. **NIC 3** → Core Fabric 2 Le playground utilise une MTU de 9142 (au lieu de la 9216 recommandée en production) parce que l’infrastructure réseau virtuelle du système hôte introduit une surcharge supplémentaire. La superposition du réseau central (`100.96.0.0/24`) s’appuie sur les deux réseaux de maillage, tout comme en production. ## Points clés | Concept | Résumé | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Core Fabric** | Maillage privé entre nœuds — transporte vSAN, migration, coordination et trafic du plan de contrôle | | **Double redondance** | Deux réseaux de maillage indépendants (Core 1 + Core 2) sur des domaines de couche 2 distincts | | **Exigences MTU** | 9216+ en production (9142 dans le playground) — les trames jumbo sont obligatoires | | **Superposition du réseau central** | Logique `100.96.0.0/24` réseau reposant sur les deux commutateurs de maillage, fournissant des IP internes stables | | **3 NIC par nœud** | Minimum : 1 externe + 2 Core Fabric. La production utilise généralement 4 NIC ou plus avec un externe agrégé | | **Aucun saut de commutateur** | Les ports du Core Fabric doivent être sur la même matrice de commutation — aucun saut entre commutateurs n’est autorisé | | **Isolation du trafic** | Le Core Fabric n’est jamais exposé au trafic externe ; les réseaux externes sont complètement séparés | | **réseau DMZ** | Point central de routage de couche 3 créé automatiquement et reliant tous les réseaux virtuels du système | ## Étapes suivantes Maintenant que vous comprenez comment les nœuds VergeOS sont interconnectés, le prochain sujet explique comment ces nœuds sont organisés en clusters : [**Clusters et types de nœuds →**](/learn-the-platform/fr/module-1-fondamentaux-de-larchitecture/05-clusters-nodes.md) --- # 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/learn-the-platform/fr/module-1-fondamentaux-de-larchitecture/04-core-fabric.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.