Fabric de base et mise en réseau

Comprendre le fabric de base VergeOS — la maille privée inter-nœuds qui transporte la réplication vSAN, la migration des VM et le trafic du plan de contrôle — ainsi que le modèle de séparation du réseau externe.

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.

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.

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.

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.

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.

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.

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.

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 :

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é.

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.

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.

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 →