Architecturer le futur : le réseau VCF 9 et la fin de l'ère L2 héritée

VMware Cloud Foundation (VCF) 9 n'est plus un choix, c'est une directive. Dans le paysage post-Broadcom, l'ère du « pick-and-choose » des licences individuelles vSphere ou vSAN est révolue, remplacée par un mandat monolithique « full-stack » qui force les ingénieurs réseau à traiter le data center comme une seule entité programmable. Si vous essayez toujours de concevoir votre fabric physique avec des VLANs faits à la main et des extensions L2 héritées, vous n'êtes pas seulement en retard ; vous êtes en train d'architecturer un point de défaillance qui s'effondrera sous le poids de l'intégration obligatoire de NSX et vSAN ESA de VCF 9.

La réalité post-Broadcom : VCF 9 comme plancher stratégique

La transition vers VCF 9 représente un changement fondamental dans notre approche du SDDC (Software-Defined Data Center). Auparavant, NSX était souvent traité comme une « option d'overlay » pour les entreprises avancées. Dans VCF 9, NSX est le moteur, la transmission et le tableau de bord. Broadcom a rationalisé les licences au point que l'écart de coût entre vSphere-only et VCF est conçu pour forcer la migration. Pour l'ingénieur réseau, cela signifie que l'underlay physique doit devenir invisible, robuste et purement L3.

Nous sommes face à une philosophie de conception où le réseau est défini par les VCF Services plutôt que par des interfaces matérielles. Avec la dépréciation de l'ancien vSAN (Original Storage Architecture - OSA) au profit de l'Express Storage Architecture (ESA), les exigences réseau ont explosé. Si vous n'utilisez pas de 25GbE comme point d'entrée minimum absolu – avec 100GbE étant la norme pour les clusters VCF 9 – vous privez le vSAN ESA basé sur NVMe du débit dont il a besoin pour atteindre son potentiel d'IOPS.

NSX-T est mort, vive NSX Project Antrea et les VPC

Dans VCF 9, les concepts de mise en réseau ont évolué. Nous assistons à une forte poussée vers le modèle NSX Virtual Private Cloud (VPC). Ce n'est pas seulement une nomenclature marketing ; c'est un changement structurel dans la façon dont la multi-location est gérée. Au lieu d'une imbrication complexe de Tier-0/Tier-1 que les ingénieurs avaient du mal à visualiser, VCF 9 traite chaque locataire ou limite d'application comme un VPC, en abstrayant le routeur T1 dans un modèle de consommation en libre-service.

Du point de vue de la conception, cela nécessite une refonte de l'Edge Cluster. Dans les versions antérieures, nous aurions pu nous contenter de petits Edge VMs. Dans VCF 9, surtout pour supporter le trafic vSAN ESA haute performance et le failover multi-AZ, vos nœuds Edge doivent être dimensionnés en « Large » ou « X-Large » pour gérer les exigences DPDK (Data Plane Development Kit). Pour un cluster de management standard à 4 nœuds, nous recommandons un minimum de deux nœuds Edge 100GbE pour éviter que la limite nord-sud ne devienne un goulot d'étranglement.

L'Underlay VCF 9 : Fabric L3 ou rien

Si vous utilisez toujours MLAG/VPC (Virtual Port Channels) vers vos hôtes ESXi pour autre chose que le démarrage PXE initial ou la gestion OOB, vous créez une dette de complexité que vous ne pourrez pas rembourser. VCF 9 prospère sur une architecture leaf-spine L3-only. Nous préconisons un modèle BGP-to-the-Host utilisant le modèle NSX Federated ou, à tout le moins, EBGP entre vos Tier-0 Gateways et vos commutateurs Top-of-Rack (ToR).

Considérez un déploiement VCF 9 typique avec des nœuds Dell VxRail ou HPE Synergy. Votre configuration physique devrait ressembler à ceci :

! Sample Leaf Switch BGP Configuration (Arista EOS style)
router bgp 65001
   router-id 10.0.0.1
   maximum-paths 64
   neighbor VCF_EDGE_PEERS peer-group
   neighbor VCF_EDGE_PEERS remote-as 65002
   neighbor VCF_EDGE_PEERS bfd
   neighbor 10.1.1.2 peer-group VCF_EDGE_PEERS
   neighbor 10.1.1.3 peer-group VCF_EDGE_PEERS
   redistribute connected
! Ensure MTU 9000 is set everywhere for vSAN ESA and Geneve Overlays

Sans un MTU de 9000 (Jumbo Frames) de bout en bout, la surcharge d'encapsulation Geneve dans NSX fragmentera, entraînant une perte de performance de 30 à 40 %. Dans VCF 9, ce n'est pas seulement « recommandé », c'est obligatoire pour les vérifications de l'état de santé de vSAN ESA.

vSAN ESA : Le réseau est le fond de panier

La dépendance de VCF 9 vis-à-vis de vSAN ESA modifie le calcul du débit. Contrairement à l'ancien modèle de groupe de disques, ESA utilise une architecture à un seul niveau où chaque disque est un disque de performance. Cela crée des rafales massives de trafic East-West pendant les événements de resynchronisation. Nous ne concevons plus pour des pics de 10 Gbit/s. Nous concevons pour des charges soutenues de 40 à 60 Gbit/s lors d'une défaillance de nœud.

Pour prendre en charge cela, votre conception de réseau VCF 9 doit donner la priorité au Network Partitioning. Même si nous utilisons un N-VDS (NSX Virtual Distributed Switch) consolidé sur les hôtes, vous devez utiliser des NIOC (Network I/O Control) pour garantir la bande passante pour le trafic système vSAN. Ne pas correctement prioriser le trafic vSAN par rapport au trafic vMotion ou Overlay entraînera des timeouts SCSI et des scénarios « All Paths Down » (APD) lorsque le réseau sera congestionné.

Conception Multi-AZ et Fédération Régionale

Un pilier central de VCF 9 est l'architecture Multi-Availability Zone (Multi-AZ) simplifiée. Broadcom a rationalisé le déploiement des clusters étendus, mais les exigences réseau sous-jacentes restent strictes. Pour un cluster étendu VCF 9, vous avez besoin :

• Moins de 5 ms de Round Trip Time (RTT) pour les plans de management et de workload.
• Moins de 1 ms de RTT pour le trafic étendu vSAN ESA (c'est la limite stricte).
• Un minimum de 10 Gbit/s de bande passante dédiée entre les sites pour le trafic du témoin et la réplication.

Dans VCF 9, nous nous éloignons des VLANs étendus L2 au niveau physique. Au lieu de cela, nous utilisons NSX Federation pour étendre les segments entre les sites. Cela permet une optimisation locale de l'ingestion/de l'égression (en utilisant la préférence locale BGP) afin que le trafic ne « hairpin » pas vers le site principal si une VM a été déplacée vers la deuxième AZ. Si vous n'avez pas lu notre article détaillé sur les architectures NSX Federation, vous devez revoir la façon dont Global Manager gère les pannes de site avant de vous engager dans un déploiement VCF 9.

Sécurité : Pare-feu distribués basés sur l'identité (IDFW)

La sécurité dans VCF 9 ne concerne pas seulement la micro-segmentation ; il s'agit de l'intégration du Distributed Firewall (DFW) avec les fournisseurs d'identité modernes. Le cadre de conformité VCF 9 exige que tout le trafic de management soit isolé par des règles NSX DFW dès la mise en service. Vous n'utilisez plus de pare-feu matériels pour le trafic East-West entre les VM de management. La surcharge de faire passer le trafic par une appliance Palo Alto ou FortiGate physique est inacceptable dans un environnement VCF 9 haute densité.

Au lieu de cela, tirez parti de NSX Distributed IDS/IPS. Avec VCF 9, ces signatures sont mises à jour automatiquement via Broadcom Cloud, permettant au réseau de réagir aux menaces de mouvement latéral en temps réel sans changer une seule étiquette de VLAN ou règle de pare-feu. C'est l'architecture « Zero-Trust » que les projets promettent depuis une décennie, enfin réalisée grâce au moteur d'automatisation VCF 9.

Le Coût de l'Ignorance : Licences et Alignement Matériel

Parlons chiffres. Une licence VCF 9 est chère — souvent 2 à 3 fois le coût de l'ancien vSphere Enterprise Plus par cœur (avec un minimum de 16 cœurs). Si vous déployez ce logiciel sur un réseau 10GbE vieillissant, vous payez en fait une « taxe d'idiot ». Vous payez pour un logiciel hautes performances qui est bridé par des commutateurs Top-of-Rack à 500 $.

Pour réaliser le ROI d'un investissement VCF 9, le matériel doit être aligné. Cela signifie des CPU Intel Ice Lake ou Sapphire Rapids, au moins 1 To de RAM par nœud, et des NICs Mellanox ConnectX-6 ou supérieurs. Ces NICs prennent en charge les Uptane/Hardware Offloads qui sont essentiels pour les performances de NSX. Sans déchargement matériel, le CPU de l'hôte passera 20 à 30 % de ses cycles à traiter les paquets d'encapsulation Geneve, ce qui réduira votre ratio de consolidation de VM.

Conclusion

La conception réseau de VCF 9 est un exercice de simplification impitoyable de la couche physique pour permettre une complexité et une agilité extrêmes dans la couche virtuelle. L'époque du trunking manuel et du réglage du Spanning Tree est révolue. Votre travail consiste désormais à fournir un « dark pipe » L3 solide comme le roc qui permet à NSX et vSAN ESA de faire ce pour quoi ils ont été conçus : fournir une plateforme cloud haute performance, auto-réparatrice et sécurisée.

Chez TechLeague, nous nous spécialisons dans l'accompagnement des organisations pour naviguer dans ces migrations à enjeux élevés. Que vous ayez des difficultés avec la transition vers les VPC NSX ou que vous ayez besoin de ré-architecturer votre fabric pour vSAN ESA, nous fournissons l'expertise d'ingénierie approfondie que la documentation de Broadcom omet. Explorez nos packages de consultation et de formation sur mesure pour vous assurer que votre parcours VCF 9 ne se solde pas par un goulot d'étranglement de performance.