vMotion, DRS et DPM : les fondamentaux de l'orchestration dynamique vSphere

Dans un cluster de virtualisation moderne, vMotion, DRS et DPM répondent à trois besoins différents mais complémentaires : déplacer une machine virtuelle sans interruption, répartir intelligemment les charges entre hôtes, puis réduire la consommation électrique lorsque la capacité disponible devient excédentaire. Bien configurés, ils permettent d’exploiter un cluster de production avec davantage de souplesse. Mal configurés, ils peuvent au contraire créer des migrations inutiles, des réveils trop lents ou une capacité insuffisante lors d’une pointe de charge.

Le principe à retenir est simple : vMotion est le mécanisme de déplacement, DRS est le décideur de placement et d’équilibrage, tandis que DPM pilote le nombre d’hôtes actifs. DRS et DPM s’appuient donc sur vMotion, mais ils ne poursuivent pas le même objectif.

Les rôles respectifs de vMotion, DRS et DPM

vMotion est la technologie de migration à chaud d’une machine virtuelle d’un hôte ESXi vers un autre. Pour les utilisateurs et les applications, l’opération est généralement transparente : la VM continue de s’exécuter, son état mémoire est copié progressivement vers l’hôte cible, puis une courte phase de bascule transfère l’exécution CPU et les dernières pages mémoire modifiées.

Une migration vMotion exige notamment :

• une compatibilité CPU suffisante entre les hôtes, généralement assurée par EVC ;
• une connectivité réseau vMotion dédiée ou correctement isolée ;
• un accès au stockage des disques virtuels depuis les deux hôtes, sauf scénario de migration incluant le stockage ;
• des réseaux de machines virtuelles disponibles sur la source et la cible ;
• des ressources CPU et mémoire disponibles sur l’hôte de destination.

vMotion ne décide pas seul qu’une VM doit être déplacée. Il fournit le moyen technique de le faire, à la demande d’un administrateur ou d’une fonction d’automatisation comme DRS.

DRS, pour Distributed Resource Scheduler, analyse les ressources disponibles dans le cluster et détermine le meilleur emplacement pour les VM. Il intervient à deux moments principaux :

1. Lors de la mise sous tension d’une VM, pour choisir l’hôte le plus approprié.
2. Pendant l’exploitation, pour recommander ou exécuter des migrations vMotion afin de réduire un déséquilibre de charge.

DRS ne cherche pas uniquement à répartir un pourcentage CPU identique sur tous les hôtes. Son objectif est de fournir une allocation de ressources cohérente avec les demandes des VM, les réservations, les limites, les parts, les règles d’affinité, les contraintes de licences et les besoins de disponibilité.

DPM, pour Distributed Power Management, va plus loin. Lorsqu’il estime que le cluster peut satisfaire la charge avec moins d’hôtes actifs, il évacue les VM d’un ou plusieurs hôtes via vMotion, puis place ces hôtes en veille. En cas de hausse de charge ou de besoin de capacité supplémentaire, il réveille les hôtes nécessaires, habituellement via Wake-on-LAN, iLO, iDRAC, IPMI ou une autre interface de gestion compatible.

La relation entre les trois mécanismes peut se résumer ainsi :

• vMotion déplace ;
• DRS place et équilibre ;
• DPM consolide et économise l’énergie.

Comment les mécanismes s’articulent dans un cluster

Prenons un cluster composé de huit hôtes. Durant les heures ouvrées, six hôtes peuvent être nécessaires pour absorber les charges applicatives, les environnements VDI, les traitements planifiés et la marge de tolérance aux pannes. La nuit, il est possible que trois hôtes suffisent à héberger toutes les VM en tenant compte des réservations et de la politique HA. Pour aller plus loin, consultez l’architecture vSphere et vCenter.

DRS observe que plusieurs hôtes sont faiblement sollicités. Il peut alors proposer des migrations afin de regrouper les VM sur un nombre réduit de serveurs. DPM utilise cette consolidation pour identifier un hôte devenu évacuable. Il demande alors le déplacement de ses VM par vMotion, vérifie que les contraintes de placement sont respectées, puis ordonne la mise en veille de l’hôte.

Le matin, lorsque de nouvelles VM sont démarrées ou que la demande augmente, DRS peut constater que la capacité active est insuffisante. DPM réveille alors un hôte. Une fois celui-ci reconnecté au cluster et opérationnel, DRS peut y placer de nouvelles VM ou y redistribuer des charges existantes via vMotion.

Ce cycle n’est efficace que si les décisions sont stables. Un cluster ne doit pas mettre un hôte en veille à 02:00 pour le réveiller à 02:10, puis le rendormir à 02:25. Ces oscillations augmentent le risque opérationnel, sollicitent inutilement le réseau de migration et réduisent le bénéfice énergétique.

La stabilité dépend principalement de trois éléments :

• la qualité des métriques de charge ;
• les seuils de déclenchement DPM ;
• une capacité de réserve suffisamment réaliste.

Il faut également distinguer la consommation CPU instantanée de la capacité réellement nécessaire. Une VM peu consommatrice peut disposer d’une forte réservation mémoire. Une autre peut appartenir à un groupe d’affinité qui limite les hôtes de destination possibles. Un hôte apparemment vide peut aussi être indispensable au respect de la politique N+1 ou N+2.

Préparer correctement l’infrastructure

Avant d’activer les automatismes, il convient de valider les fondations du cluster. Les difficultés rencontrées avec DRS ou DPM sont souvent la conséquence d’une architecture réseau, stockage ou capacité insuffisamment maîtrisée.

Réseau vMotion

Le réseau vMotion mérite une attention particulière. Il doit disposer d’une bande passante adaptée au volume mémoire des VM et au nombre de migrations simultanées prévu. En production, 25 GbE est devenu un minimum confortable pour des hôtes denses, tandis que 10 GbE peut rester pertinent pour des environnements de taille modérée et des fenêtres de migration limitées.

Quelques recommandations pratiques :

• isoler le trafic vMotion sur un VLAN ou un réseau dédié ;
• prévoir de la redondance physique ;
• vérifier une MTU cohérente de bout en bout si les jumbo frames sont utilisées ;
• limiter le nombre de migrations simultanées selon la capacité réseau et stockage ;
• surveiller la latence et la saturation des liens pendant les périodes de rééquilibrage.

Un vMotion trop lent n’empêche pas toujours la migration, mais il allonge la durée de convergence DRS et peut dégrader les performances des VM lors de forts taux de modification mémoire.

Compatibilité CPU et EVC

Dans un cluster composé de générations matérielles différentes, EVC est un prérequis opérationnel important. Il masque certaines instructions CPU récentes afin de présenter un jeu d’instructions homogène aux VM. Sans cette compatibilité, une migration à chaud peut être refusée entre deux hôtes pourtant membres du même cluster.

Avant d’introduire de nouveaux serveurs, il faut vérifier :

• le mode EVC du cluster ;
• la compatibilité des processeurs existants ;
• l’impact d’un changement de niveau EVC sur les VM déjà exécutées ;
• la stratégie de redémarrage éventuelle des VM.

La compatibilité CPU ne se limite pas à EVC. Les périphériques attachés directement, certaines fonctions de virtualisation matérielle et des configurations spécifiques peuvent également empêcher une migration.

Stockage et capacité

DRS fonctionne mieux lorsque les hôtes disposent d’un accès uniforme aux datastores nécessaires. Si certaines VM ne peuvent être exécutées que sur une partie des hôtes en raison de contraintes de stockage, le périmètre réel de DRS est réduit. Pour aller plus loin, consultez le fonctionnement du cluster HA.

Il faut également surveiller la capacité mémoire. En pratique, c’est souvent la mémoire, et non le CPU, qui limite la consolidation. Un cluster peut présenter une consommation CPU moyenne faible tout en étant incapable d’évacuer un hôte, faute de mémoire disponible ou en raison de réservations importantes.

Une approche prudente consiste à calculer la capacité non seulement sur la consommation observée, mais aussi sur :

• les réservations de VM ;
• la tolérance de panne prévue ;
• les pics saisonniers ;
• les opérations de maintenance ;
• la croissance à court terme ;
• les contraintes applicatives qui empêchent certains placements.

Configuration recommandée pour DRS

DRS peut fonctionner en mode manuel, partiellement automatisé ou entièrement automatisé. En 2026, pour un cluster de production homogène et correctement supervisé, le mode entièrement automatisé est généralement le plus cohérent. Il permet une réponse rapide aux variations de charge sans dépendre d’une validation humaine permanente.

Le mode manuel reste utile lors de la phase initiale : il permet d’observer les recommandations, d’identifier les contraintes oubliées et de mesurer le volume réel de migrations proposées. C’est une bonne étape de validation avant d’activer l’automatisation complète.

La configuration recommandée suit souvent cette progression :

1. Activer DRS en mode recommandations.
2. Observer les décisions pendant plusieurs cycles de charge représentatifs.
3. Corriger les règles d’affinité, réservations et limites incohérentes.
4. Passer en automatisation partielle ou complète.
5. Ajuster la sensibilité de migration si le cluster génère trop peu ou trop de déplacements.

Une sensibilité trop élevée peut provoquer du micro-équilibrage : les VM migrent pour des gains marginaux, augmentant le trafic réseau et le bruit opérationnel. À l’inverse, une sensibilité trop faible peut laisser persister des situations où un hôte est fortement sollicité alors que d’autres disposent de capacité.

Les règles DRS doivent être documentées avec soin. Les règles d’anti-affinité sont particulièrement importantes pour séparer des nœuds applicatifs redondants, par exemple deux contrôleurs de domaine, deux nœuds de base de données ou plusieurs serveurs d’une même application critique. Mais une accumulation excessive de règles réduit la liberté de placement et peut empêcher DPM d’éteindre des hôtes.

Les règles “must run” doivent être utilisées avec parcimonie. Elles imposent une contrainte stricte qui peut empêcher le redémarrage d’une VM si l’hôte requis est indisponible. Lorsque le besoin est seulement préférentiel, une règle de type “should run” est souvent plus adaptée.

DPM : intérêt réel et précautions indispensables

DPM est pertinent lorsque la charge varie fortement selon les horaires et que l’énergie économisée compense la complexité supplémentaire. C’est souvent le cas dans des environnements de développement, de test, de formation, de VDI avec activité diurne marquée, ou dans certains clusters applicatifs dont la charge nocturne est faible.

L’économie réalisée dépend du matériel. Un serveur moderne en veille consomme beaucoup moins qu’un serveur actif, mais la différence entre un hôte peu chargé et un hôte inactif doit être mesurée. Il faut aussi considérer la consommation des équipements réseau, du stockage et du refroidissement : éteindre deux hôtes ne réduit pas nécessairement la consommation globale de la salle informatique dans les mêmes proportions.

DPM doit être précédé d’un test du réveil hors bande. Un hôte qui ne redémarre pas automatiquement annule l’intérêt de la fonction et peut mettre le cluster sous pression. Il faut valider, pour chaque modèle de serveur :

• le mode de réveil supporté ;
• la configuration BIOS ou UEFI ;
• l’accès réseau de l’interface de gestion ;
• les délais de démarrage ;
• le retour correct de l’hôte dans le cluster ;
• la reconnexion des interfaces réseau et du stockage ;
• la stabilité après plusieurs cycles veille-réveil.

Un test minimal peut être réalisé à partir d’un hôte placé manuellement en maintenance puis en veille, avant de vérifier sa remise sous tension et sa disponibilité complète. Les commandes exactes dépendent de l’outillage de gestion et du matériel, mais la logique reste la même : ne jamais activer DPM à grande échelle sans validation matérielle.

Pour suivre l’effet de la politique, il est utile de corréler les événements de mise en veille et de réveil avec les métriques CPU, mémoire, latence stockage et nombre de migrations. Une forte activité DPM n’est pas forcément un signe d’efficacité. Elle peut révéler des seuils trop agressifs. Pour aller plus loin, consultez l’impact d’EVC sur les performances.

Les cas où DPM est déconseillé

DPM n’est pas adapté à tous les clusters, notamment à ceux qui hébergent des workloads critiques 24/7. Un cluster de production permanent peut avoir besoin d’une capacité immédiatement disponible, sans attendre le démarrage d’un serveur physique, l’initialisation de ses interfaces, sa reconnexion au stockage et son admission par le cluster.

DPM est généralement déconseillé ou doit être très strictement encadré dans les cas suivants :

• applications critiques avec engagement de disponibilité élevé ;
• bases de données transactionnelles avec pics imprévisibles ;
• clusters avec faible marge de capacité ;
• environnements nécessitant une tolérance N+2 ou plus ;
• plateformes où le démarrage d’un hôte prend plusieurs minutes ;
• charges sensibles à la latence et aux migrations ;
• infrastructures avec de nombreuses VM utilisant le passthrough matériel ;
• clusters très contraints par les règles d’affinité ;
• environnements dont les hôtes possèdent des configurations hétérogènes ;
• plateformes où les équipes d’exploitation ne disposent pas d’une supervision continue.

Le principal risque n’est pas seulement le temps de réveil. Si DPM a consolidé agressivement les VM, une panne d’hôte peut laisser trop peu de capacité active pour redémarrer les charges selon la politique HA. La conception doit donc toujours intégrer le pire scénario plausible : panne d’un hôte actif au moment où plusieurs autres sont en veille.

Dans un environnement critique, il est souvent préférable de conserver tous les hôtes allumés et d’optimiser l’énergie autrement : profils d’alimentation serveur, paramétrage CPU, renouvellement matériel, densité raisonnée, amélioration du refroidissement et consolidation maîtrisée lors des évolutions de capacité.

Exploitation quotidienne et supervision

L’automatisation ne remplace pas l’observation. Une exploitation saine repose sur des tableaux de bord et des alertes portant sur les bons indicateurs :

• taux d’utilisation CPU et mémoire par hôte ;
• consommation mémoire réelle et pression mémoire ;
• temps et taux d’échec des migrations vMotion ;
• latence des datastores ;
• nombre de migrations DRS par période ;
• nombre de réveils et de mises en veille DPM ;
• capacité restante après prise en compte de la politique HA ;
• violations de règles d’affinité ;
• hôtes inéligibles à DPM ou incapables de se réveiller.

Il est aussi utile d’examiner les migrations récurrentes. Si une même VM change fréquemment d’hôte, il faut rechercher la cause : règle contradictoire, comportement applicatif particulier, pression mémoire locale, hôte présentant des performances dégradées ou seuil DRS trop sensible.

Enfin, les périodes de maintenance doivent être intégrées à la stratégie. Avant une mise à jour de firmware, un remplacement d’hôte ou une opération de stockage, il faut vérifier que le cluster peut évacuer les VM sans compromettre la réserve de capacité. DRS simplifie cette opération, mais ne corrige pas une capacité insuffisante.

vMotion, DRS et DPM forment donc une chaîne d’automatisation cohérente : déplacer sans interruption, placer intelligemment, puis réduire le parc actif lorsque cela reste compatible avec les objectifs de disponibilité. Dans un cluster de production, DRS est souvent un standard d’exploitation. DPM doit en revanche être considéré comme une optimisation conditionnelle, utile lorsque la variabilité de charge, la maturité de supervision et la capacité de réserve le justifient réellement.