Dans une infrastructure VMware, le vSphere Distributed Switch (vDS) est souvent perçu comme l’évolution logique du réseau virtuel : centralisation, automatisation et fonctionnalités avancées. Tout semble parfait sur le papier.
Pourtant, une erreur de conception très répandue consiste à placer la VM vCenter Server sur un vDS sans précaution particulière. Sans le savoir, de nombreux administrateurs tendent un véritable piège à leur propre infrastructure : la dépendance circulaire ou le deadlock by design.
Cette approche introduit une dépendance circulaire critique capable de paralyser totalement votre plan de management.
Décryptons pourquoi ce design peut devenir votre pire cauchemar en cas d’incident.
Dans cet article, nous allons voir pourquoi ce choix de design peut vous « enfermer dehors » en cas d’incident et comment configurer votre réseau pour que vCenter reste toujours accessible, même quand tout semble figé.
Le paradoxe du vDS : Centralisation vs Dépendance
Le vDS est un outil puissant, mais il souffre d’un paradoxe intrinsèque : il est entièrement piloté par vCenter. C’est vCenter qui gère :
- La création et la modification des portgroups.
- L’attribution des ports aux machines virtuelles.
- La synchronisation de la configuration entre tous les hôtes ESXi du cluster.
Tant que vCenter est opérationnel, tout fonctionne à merveille. Mais dès qu’il tombe, le « cerveau » du réseau distribué disparaît.
Si vCenter lui-même dépend du vDS pour sa propre connectivité, vous créez une dépendance où le gestionnaire a besoin du composant qu’il gère pour pouvoir fonctionner, donc un SPOF et pire encore un deadlock by design.
Le scénario catastrophe : Voici un cas réel fréquemment rencontré en support ou lors d’audits d’infrastructure :
- L’état initial : La VM vCenter est connectée à un portgroup vDS configuré en Static Binding (le mode par défaut).
- L’incident : Une coupure réseau, vMotion de la VM vCenter, une erreur de manipulation sur un VLAN ou un crash de l’hôte provoque la déconnexion de vCenter.
- Le blocage : Vous tentez de reconnecter la VM vCenter via l’interface de l’hôte ESXi (Host Client).
- Le résultat : ❌ Échec. L’hôte ESXi ne peut pas attribuer de port sur un portgroup statique sans l’ordre de vCenter, qui est précisément celui que vous essayez de reconnecter.
Résultat : vCenter est isolé, inaccessible, et vous n’avez aucun moyen de lui rendre son réseau via les outils standards, c’est exactement ce que nous appelons un deadlock by design.
Pourquoi l’hôte ESXi ne peut-il pas vous sauver seul ?
Une idée reçue consiste à croire que l’accès direct à l’hôte ESXi suffit pour corriger le tir, c’est faux dans le cas d’un vDS non éphémère.
Sur un portgroup statique, ESXi est passif, donc, il attend les instructions du plan de gestion (vCenter).
Sans lui, l’hôte est incapable de créer ou d’attribuer dynamiquement un port, c’est précisément ce qui rend cette panne si critique : vous avez la main sur l’hôte, mais vous êtes pieds et poings liés face au réseau virtuel.
vCenter n’est pas une VM comme les autres
Il est vital de changer de perspective : vCenter est un composant d’infrastructure, pas une simple charge applicative.
À ce titre, son design doit obéir à trois règles d’or :
- Récupérabilité : Il doit pouvoir être restauré ou reconnecté sans dépendre de ses propres services.
- Accessibilité : On doit pouvoir modifier son réseau via un accès direct à l’hôte ESXi.
- Résilience : Sa simplicité réseau est sa meilleure protection.
Les architectures recommandées pour dormir serein
Pour casser cette dépendance circulaire, deux options s’offrent à vous :
Option 1 : Le Portgroup Ephemeral (Le compromis vDS)
C’est la recommandation officielle si vous souhaitez garder vCenter sur un vDS.
- Le principe : Utiliser un portgroup dédié avec un binding de type Ephemeral.
- L’avantage : L’hôte ESXi peut attribuer un port de manière autonome, même si vCenter est éteint ou injoignable.
- Idéal pour : Les environnements qui veulent uniformiser leur gestion sur vDS.
Option 2 : Le vSwitch Standard (La robustesse ultime)
Une approche plus conservatrice mais extrêmement fiable.
- Le principe : Conserver un vSwitch standard (vSS) sur chaque hôte, dédié uniquement au management (vCenter et interfaces VMkernel de gestion).
- L’avantage : Indépendance totale vis-à-vis de la base de données vCenter. C’est simple, prévisible et dépannable en quelques clics.
- Idéal pour : Les infrastructures critiques et les environnements hautement sécurisés.
Erreurs de conception et bonnes pratiques
❌ À éviter absolument :
- Connecter vCenter à un portgroup vDS par défaut (Static) sans analyse.
- Penser que le vDS est une solution « universelle » sans exception.
- Ne jamais tester le redémarrage de vCenter après une coupure totale du réseau.
✅ À mettre en place :
- Identifier les composants critiques qui ne doivent jamais être isolés.
- Tester l’accès direct ESXi (Host Client) et vérifier si vous pouvez modifier le réseau de vCenter.
- Documenter la procédure de secours en cas de perte du plan de management.
Conclusion
Le vSphere Distributed Switch est un outil exceptionnel pour simplifier l’administration réseau, mais il ne doit jamais devenir un piège pour votre vCenter.
Un design pragmatique, privilégiant la résilience sur la fonctionnalité, vous évitera des heures de stress lors de votre prochain incident de production.
Pour bien comprendre la mécanique technique derrière ces choix, je vous invite à lire mon article précédent : vSphere Distributed Switch : Binding (Static vs Ephemeral)
