vSphere reste en 2026 un socle de virtualisation très répandu dans les infrastructures d’entreprise, y compris lorsque les équipes exploitent parallèlement du cloud public, du Kubernetes ou des appliances métier. Dans un cluster de plusieurs hôtes, l’enjeu ne se limite plus à créer des machines virtuelles et à les déplacer à chaud. Il faut maintenir une capacité disponible malgré une panne, absorber les fenêtres de maintenance, appliquer des correctifs de manière cohérente, respecter les contraintes de licences par cœur et préserver des performances prévisibles pour les applications. vCenter Server est le plan de contrôle de cet ensemble : il centralise l’inventaire, l’automatisation, les politiques de disponibilité, la gestion du cycle de vie et une grande partie des contrôles opérationnels.

Le contexte a toutefois changé. Les versions historiques de vSphere arrivent progressivement en fin de support, les modèles de licences perpétuelles ne constituent plus la référence commerciale, et le portefeuille Broadcom est désormais structuré autour d’abonnements et de bundles, notamment VMware vSphere Foundation (VVF) et VMware Cloud Foundation (VCF). Pour les administrateurs, cela implique de revisiter les architectures qui avaient été conçues à une époque où l’ajout d’une option vSphere semblait trivial. Les décisions de design doivent maintenant intégrer la consommation de cœurs, les minimums de souscription, les fonctions réellement nécessaires et les dépendances entre produits.

Ce guide propose une lecture opérationnelle de vCenter Server Appliance, des mécanismes DRS, HA et vMotion, du dimensionnement d’un cluster de production, de la migration depuis des environnements plus anciens et de la gestion des mises à jour avec vSphere Lifecycle Manager. L’objectif n’est pas de présenter vSphere comme une plateforme abstraite, mais de fournir des repères utilisables sur un cluster réel, exploité par une équipe d’administration avec des contraintes de disponibilité, de budget et de maintien en conditions opérationnelles.

Comprendre le rôle de vCenter Server Appliance

vCenter Server Appliance, généralement désigné par VCSA, est une appliance virtuelle basée sur Photon OS qui héberge vCenter Server. Elle remplace depuis longtemps le déploiement Windows historique et constitue le format de référence pour les environnements vSphere modernes.

Un vCenter ne se place pas dans le chemin de données des machines virtuelles. Une VM continue de s’exécuter sur son hôte ESXi même si vCenter devient momentanément indisponible. En revanche, plusieurs opérations de gestion et d’orchestration ne sont alors plus possibles : migration vMotion initiée par l’administrateur, décisions DRS, déploiements centralisés, modifications de configuration, tâches Lifecycle Manager, inventaire consolidé et gestion de nombreuses intégrations.

Les services essentiels du VCSA

Le VCSA regroupe plusieurs composants dans une même appliance :

Dans une architecture standard, un seul VCSA peut administrer plusieurs datacenters virtuels, dossiers, clusters et hôtes, sous réserve de respecter les limites de configuration de la version installée. Les grandes organisations peuvent déployer plusieurs vCenter pour des raisons de séparation administrative, de domaine de panne, de latence, de conformité ou de limites d’échelle.

Le choix du placement et de la disponibilité

Le VCSA doit être hébergé sur une infrastructure suffisamment fiable. Dans la plupart des cas, il est placé dans le cluster qu’il administre. Cette configuration est courante et acceptable, mais elle impose de documenter une procédure de redémarrage si tous les hôtes du cluster sont arrêtés.

Dans un environnement avec plusieurs sites ou plusieurs clusters, héberger vCenter dans un cluster de management distinct apporte une meilleure isolation. Ce cluster peut également accueillir les services de sauvegarde, les outils de supervision, les bastions d’administration et les appliances de sécurité. Il devient alors lui-même un composant critique, à dimensionner et protéger avec autant de rigueur que les clusters de production.

Ne confondez pas haute disponibilité des VM et disponibilité native de vCenter. vCenter Server High Availability, ou VCHA, existe mais ajoute une architecture active, passive et témoin, ainsi qu’une complexité opérationnelle non négligeable. Dans beaucoup d’environnements, une sauvegarde cohérente et testée du VCSA, associée à une procédure de restauration maîtrisée, offre un meilleur rapport bénéfice/complexité.

Sauvegarder le VCSA correctement

La sauvegarde image de la VM VCSA peut être utile, mais elle ne doit pas être votre seule stratégie. Le VCSA fournit un mécanisme de sauvegarde intégré au niveau applicatif, vers une cible compatible, par exemple FTPS, SFTP, HTTPS, NFS ou SMB selon les possibilités de la version et de l’environnement.

Cette sauvegarde contient la configuration, l’inventaire, les données d’identité et, selon les options retenues, les statistiques et historiques. Planifiez-la avant chaque mise à niveau majeure et testez périodiquement une restauration isolée. Une sauvegarde non restaurée est seulement une hypothèse. Pour aller plus loin, consultez l’administration quotidienne d’un hôte ESXi.

Architecture d’un cluster : HA, DRS et vMotion

Un cluster vSphere regroupe plusieurs hôtes ESXi afin de mutualiser les ressources de calcul et de mettre en œuvre des mécanismes de disponibilité. Les trois fonctions les plus souvent associées au cluster sont vSphere HA, DRS et vMotion. Elles sont complémentaires, mais répondent à des événements différents. Le portail TechDocs Broadcom reste la source de référence pour les paramètres exacts de chaque version de vSphere.

Fonction Événement traité Action principale Dépendance majeure
vSphere HA Panne d’un hôte ou isolement Redémarrage des VM sur un autre hôte Capacité disponible, stockage accessible
vMotion Maintenance ou rééquilibrage Migration à chaud d’une VM Réseau vMotion, compatibilité CPU et stockage
DRS Déséquilibre de ressources Recommandation ou migration vMotion vCenter, vMotion, métriques de ressources

vSphere HA : redémarrer, pas continuer l’exécution

vSphere HA détecte l’indisponibilité d’un hôte et redémarre les machines virtuelles concernées sur les hôtes survivants. Il ne préserve pas l’état mémoire de la VM : les systèmes invités redémarrent, comme après une coupure brutale. La durée de reprise dépend de la détection de panne, de l’élection HA, du démarrage des VM et du temps de boot applicatif.

La qualité de HA dépend directement de la conception du cluster :

La surveillance des datastores par HA mérite une attention particulière. Elle complète la surveillance réseau pour éviter qu’une panne de communication isolée soit confondue avec une panne totale. Utilisez plusieurs chemins de détection lorsque l’architecture réseau et stockage le permet.

DRS : automatiser le placement avec des garde-fous

Distributed Resource Scheduler, ou DRS, analyse la pression CPU et mémoire au sein du cluster. Il peut proposer ou effectuer des migrations vMotion afin de répartir les charges. Dans un cluster de production homogène, le mode entièrement automatisé simplifie fortement l’exploitation, à condition que les règles soient propres.

DRS ne remplace pas le capacity planning. Un cluster saturé ne devient pas sain parce que DRS déplace les VM. Il répartit une pénurie, sans créer de capacité. De même, DRS n’a pas connaissance de toutes les dépendances applicatives, des licences logicielles, des contraintes de latence ou des flux réseau entre VM.

Les règles de placement sont donc essentielles :

vMotion : une migration à chaud qui repose sur le réseau

vMotion déplace l’état d’exécution d’une VM d’un hôte ESXi vers un autre. La mémoire est copiée pendant que la VM continue de fonctionner, puis une courte phase de bascule finalise la migration. Pour que cette opération reste invisible ou presque pour l’application, le réseau vMotion doit être correctement conçu.

Utilisez un réseau dédié, routé ou non selon votre design, avec une bande passante adaptée au volume de mémoire déplacé et au nombre de migrations simultanées attendues. Dans les clusters modernes, 10 Gb/s constitue souvent un plancher raisonnable pour le trafic vMotion, tandis que 25 Gb/s ou davantage se justifie lorsque les hôtes portent beaucoup de mémoire, des VM volumineuses ou des fenêtres de maintenance très contraintes.

La compatibilité CPU doit être vérifiée. Des hôtes de générations différentes peuvent cohabiter dans un même cluster, mais les migrations peuvent nécessiter Enhanced vMotion Compatibility, ou EVC. Activez EVC au niveau du cluster avant de mélanger des générations de processeurs. Ne vous contentez pas de tester une migration isolée après l’ajout d’un nouvel hôte.

Un administrateur expérimenté supervise un cluster vSphere depuis l'allée du datacenter.
Un administrateur expérimenté supervise un cluster vSphere depuis l'allée du datacenter.

Concevoir les réseaux et le stockage du cluster

La majorité des incidents vSphere complexes trouvent leur origine dans des dépendances réseau ou stockage mal documentées. Un cluster doit pouvoir supporter une panne d’hôte, une maintenance planifiée et une perte partielle de connectivité sans comportements imprévisibles.

Séparer les flux critiques

Au minimum, distinguez logiquement les flux suivants :

La séparation peut reposer sur des VLAN, des interfaces physiques dédiées ou une combinaison des deux. Le choix dépend du débit requis, de la redondance des commutateurs, des besoins de sécurité et des capacités des cartes réseau. Un design avec deux uplinks redondants peut convenir dans de nombreux cas, mais le partage des flux doit être validé face aux pics réalistes : sauvegardes, évacuations d’hôtes, resynchronisations de stockage et migrations simultanées.

Documentez les MTU de bout en bout. Les jumbo frames peuvent réduire la charge CPU sur certains flux, mais un MTU incohérent produit des pannes difficiles à diagnostiquer. Ne les activez pas partiellement. Vérifiez hôte, vSwitch ou vDS, ports physiques, trunks, interfaces de stockage et équipements intermédiaires.

Stockage partagé et conséquences opérationnelles

HA et vMotion sont plus simples lorsque les VM reposent sur un stockage partagé accessible à tous les hôtes. Ce stockage peut être fourni par une baie SAN, du NFS, une architecture hyperconvergée ou une autre plateforme compatible.

Le stockage n’est pas seulement une question de capacité brute. Pour chaque datastore, mesurez :

Les snapshots prolongés constituent une cause fréquente de dégradation. Ils ne sont pas des sauvegardes. Leur croissance peut saturer un datastore, augmenter les temps de consolidation et affecter la latence des VM. Mettez en place une alerte sur leur âge, leur taille et la capacité libre des datastores.

Licences vSphere en 2026 : raisonner en cœurs et en bundles

Le changement le plus visible dans les pratiques d’achat et de renouvellement concerne le modèle Broadcom. Les licences perpétuelles historiques ne constituent plus le modèle courant pour les nouveaux besoins. Les organisations doivent principalement raisonner en souscriptions, facturées selon le nombre de cœurs physiques des hôtes.

La conséquence opérationnelle est simple : le choix d’un serveur avec beaucoup de cœurs peut modifier fortement le coût de la plateforme, même si le nombre d’hôtes reste identique. Le choix matériel, le dimensionnement et la licence ne peuvent plus être décidés dans des silos séparés.

VVF et VCF : deux périmètres différents

VMware vSphere Foundation, ou VVF, vise les besoins de virtualisation d’entreprise avec les fonctions vSphere attendues pour opérer des clusters de production. VMware Cloud Foundation, ou VCF, ajoute une plateforme plus large, pensée pour intégrer de façon cohérente calcul, stockage défini par logiciel, réseau défini par logiciel, automatisation et opérations de cloud privé.

Les droits précis, les éditions disponibles et les minimums contractuels peuvent évoluer. Il faut donc valider les conditions applicables au moment du renouvellement avec les documents contractuels fournis à votre organisation. D’un point de vue technique, la distinction est la suivante : Pour aller plus loin, consultez l’automatisation via PowerCLI.

Sujet VVF VCF
Usage principal Virtualisation vSphere d’entreprise Cloud privé intégré et automatisé
vCenter et vSphere Inclus dans le périmètre du bundle Inclus dans le périmètre du bundle
vSAN Présent dans le périmètre Foundation selon l’offre souscrite Composant central de la pile intégrée
Réseau défini par logiciel Pas nécessaire pour un usage vSphere classique Généralement intégré au design VCF
Complexité d’exploitation Modérée Plus élevée, mais plus intégrée

Pour un cluster classique connecté à une baie SAN ou NAS, VVF est souvent le point de départ logique. Pour une stratégie de cloud privé avec vSAN, réseau virtualisé, automatisation et exploitation standardisée à grande échelle, VCF peut être cohérent. Le mauvais choix consiste à acquérir un bundle plus large sans équipe, processus ni architecture capables d’exploiter les composants supplémentaires.

Méthode de calcul et pièges courants

Commencez par inventorier les cœurs physiques de chaque processeur de chaque hôte. Ne basez pas le calcul sur les vCPU attribués aux VM. Ajoutez les hôtes de secours, les hôtes de management et les hôtes destinés à absorber la croissance ou la maintenance.

Exemple de collecte côté ESXi :

esxcli hardware cpu global get
esxcli hardware cpu list | grep -E "Package Id|Core Id"

Côté PowerCLI, un inventaire de base peut être obtenu ainsi :

Get-VMHost | Select-Object Name,
    @{N='Sockets';E={$_.ExtensionData.Hardware.CpuInfo.NumCpuPackages}},
    @{N='Cores';E={$_.ExtensionData.Hardware.CpuInfo.NumCpuCores}},
    @{N='Threads';E={$_.ExtensionData.Hardware.CpuInfo.NumCpuThreads}}

Les erreurs habituelles sont les suivantes :

Dimensionner un cluster de production

Le dimensionnement doit être basé sur les mesures de charge, pas sur le nombre de VM. Cent VM légères peuvent consommer moins qu’une poignée de bases de données exigeantes. Utilisez les métriques historiques de vCenter, d’un outil de supervision ou des deux, avec une période suffisamment représentative incluant les pics mensuels, les sauvegardes, les traitements de nuit et les périodes de clôture.

Prévoir la capacité N+1, voire N+2

Le modèle minimal le plus courant est N+1 : le cluster doit continuer à faire fonctionner les charges critiques après la perte d’un hôte. Cette réserve doit être réelle, pas théorique. Si les hôtes restants atteignent 95 % de CPU ou n’ont plus de mémoire libre après une panne, HA pourra redémarrer les VM, mais l’expérience applicative sera dégradée.

La réserve N+2 se justifie lorsque vous devez pouvoir perdre un hôte tout en maintenant un second hôte en maintenance, lorsque les hôtes sont très denses ou lorsque les périodes de maintenance sont courtes. Elle est également pertinente si le matériel présente des risques communs, par exemple plusieurs hôtes d’un même lot ou d’une même baie d’alimentation.

Prenez en compte :

CPU, mémoire et surallocation

La surallocation CPU est possible, mais elle doit être mesurée. Un ratio vCPU/pCPU élevé peut fonctionner pour des charges peu actives, mais il augmente le risque de CPU Ready et de co-stop pour les VM multi-vCPU. Ces métriques doivent être interprétées en tenant compte de l’intervalle de collecte et du comportement applicatif.

La mémoire est généralement moins tolérante. Les mécanismes comme le ballooning, la compression ou le swapping hyperviseur sont des protections de dernier recours, pas des outils de dimensionnement. Si le cluster les utilise de façon régulière, ajoutez de la mémoire ou réduisez la charge. Pour les applications critiques, définissez des réservations uniquement lorsque nécessaire : une réservation protège une VM, mais réduit la flexibilité globale de DRS et HA.

Homogénéité et génération matérielle

Des hôtes homogènes simplifient DRS, EVC, les profils Lifecycle Manager et les diagnostics de performance. Lorsque le renouvellement progressif impose une coexistence entre deux générations, créez un plan transitoire :

  1. activez ou ajustez EVC avant le mélange des générations ;
  2. validez les pilotes, firmwares et compatibilités de cartes réseau et HBA ;
  3. testez les migrations vMotion ;
  4. appliquez une image Lifecycle Manager compatible avec chaque modèle ;
  5. retirez les anciens hôtes dès que la capacité le permet.

Un cluster durablement hétérogène est exploitable, mais augmente le nombre d’exceptions. Ces exceptions deviennent coûteuses lors des mises à jour ou d’un incident.

Une rangée de baies serveurs connectées illustre l'architecture d'un cluster vSphere.
Une rangée de baies serveurs connectées illustre l'architecture d'un cluster vSphere.

Migrer depuis des versions anciennes de vSphere

La migration vers une version récente ne doit pas être abordée comme une mise à jour de routine. Il s’agit d’un projet comprenant la compatibilité matérielle, les dépendances de sauvegarde, les pilotes, les agents tiers, les méthodes d’authentification et les applications hébergées.

Établir un inventaire avant toute action

Avant de lancer le premier upgrade, recensez :

Vérifiez aussi la matrice de compatibilité de chaque éditeur tiers. Une mise à niveau vCenter peut rendre indisponible un plugin ancien ; une mise à jour ESXi peut nécessiter une nouvelle version de l’agent de sauvegarde ou du pilote de carte réseau.

Ordre de migration recommandé

L’ordre logique reste généralement :

  1. sauvegarder le VCSA via le mécanisme intégré et vérifier la restauration ;
  2. mettre à niveau vCenter Server vers la version cible ou une version intermédiaire requise ;
  3. mettre à niveau les hôtes ESXi un par un, après évacuation des VM ;
  4. mettre à niveau VMware Tools sur les VM selon une campagne contrôlée ;
  5. mettre à niveau le matériel virtuel lorsque les prérequis applicatifs sont validés ;
  6. relever les niveaux de compatibilité de cluster uniquement lorsque le retour arrière n’est plus nécessaire.

Ne mettez pas à jour le matériel virtuel en masse le jour même de la montée de version ESXi. Ce changement est souvent irréversible ou difficile à annuler, et certaines appliances ou systèmes d’exploitation exigent une validation spécifique.

Gérer les hôtes non compatibles

Si un serveur physique n’est pas compatible avec la cible, ne forcez pas l’installation hors matrice pour gagner quelques mois. Créez plutôt un cluster ou un périmètre transitoire compatible, migrez les VM vers le nouveau matériel, puis retirez l’ancien hôte. La dette technique liée à un pilote non supporté se paie généralement lors d’une panne ou d’un correctif urgent.

Mettre à jour avec vSphere Lifecycle Manager

vSphere Lifecycle Manager, ou vLCM, est l’outil intégré de gestion du cycle de vie. Son intérêt principal est de réduire les écarts de configuration entre hôtes. Dans un cluster, l’objectif n’est pas seulement d’installer le dernier patch : il faut maintenir un état cohérent comprenant la version ESXi, les add-ons constructeur, les pilotes et parfois les firmwares.

Images de cluster et baselines

Les baselines historiques restent utiles dans certains scénarios, notamment pour des environnements existants ou des cas particuliers. Pour les clusters récents et homogènes, la gestion par image de cluster est généralement préférable. L’image définit l’état souhaité du cluster : Pour aller plus loin, consultez le fonctionnement d’un cluster VMware HA.

Avant toute remédiation, vLCM compare l’état réel de chaque hôte à l’état souhaité. Les écarts doivent être analysés : un pilote différent peut être légitime, mais il peut aussi révéler un hôte mis à jour manuellement ou une dérive de configuration. Pour aller plus loin, consultez l’évolution du licensing sous Broadcom.

Préparer une campagne de correctifs

Une stratégie de mise à jour robuste comprend les étapes suivantes :

  1. vérifier les notes de version et les correctifs retirés ou remplacés ;
  2. confirmer la compatibilité des pilotes, firmwares et outils tiers ;
  3. sauvegarder le VCSA ;
  4. tester la séquence sur un cluster de préproduction ou un hôte représentatif ;
  5. vérifier la capacité N+1 avant de mettre le premier hôte en maintenance ;
  6. évacuer les VM par vMotion ;
  7. remédier un hôte à la fois ou par petits lots maîtrisés ;
  8. contrôler les alarmes, le stockage, les chemins réseau et les performances après chaque lot ;
  9. documenter les versions réellement appliquées.

Une maintenance automatisée n’élimine pas le besoin de contrôle humain. Une évacuation DRS peut être bloquée par une règle d’affinité, une réservation, une VM avec périphérique attaché ou un datastore inaccessible. Identifiez ces exceptions avant la fenêtre.

Construire un rythme de mise à jour réaliste

Séparez les mises à jour de sécurité urgentes, les correctifs réguliers et les montées de version majeures. Un rythme trimestriel de revue peut convenir pour de nombreuses entreprises, complété par des campagnes exceptionnelles lorsqu’une vulnérabilité critique ou un défaut matériel le justifie.

Évitez les clusters qui restent sans patch pendant un an au motif qu’ils sont stables. L’écart entre versions augmente la difficulté des futures migrations, réduit les options de support et peut contraindre à une montée de version trop brutale. La stabilité n’est pas l’absence de changement : c’est la capacité à changer de manière répétable et contrôlée.

Exploitation quotidienne : contrôles qui évitent les incidents

L’exploitation d’un cluster vSphere ne se résume pas au tableau de bord vCenter. Mettez en place une routine de vérification qui relie l’état de l’infrastructure à la qualité de service des applications.

Surveillez notamment :

Les alarmes doivent être actionnables. Une alarme qui se déclenche chaque jour sans traitement finit ignorée. Préférez moins d’alertes, mais avec des seuils justifiés, un propriétaire identifié et une procédure de remédiation associée.

Enfin, conservez une documentation opérationnelle à jour : plan réseau, matrice des VLAN, inventaire matériel, règles DRS, groupes d’hôtes, dépendances applicatives, procédure de démarrage après arrêt complet et procédure de restauration vCenter. Lors d’un incident majeur, cette documentation vaut souvent davantage qu’une fonctionnalité avancée non maîtrisée.