Combien de nœuds ajouter, et sur quels clusters, avant une campagne de migration ? La réponse sort d’une simulation de placement à N-1, à condition de valider le modèle avant de s’y fier et de le rejouer à chaque changement.
Le modèle : poser le plan sur les cibles, à N-1
Pour chaque cluster cible, on ajoute à sa consommation actuelle la RAM, le CPU et le disque des VM que le plan lui destine. On rapporte le total à la capacité restante après la perte d’un nœud, ressources des CVM déduites. Notre seuil d’ajout de nœud est de 80 % de cette capacité N-1 : c’est une règle d’équipe, pas une valeur Nutanix.
Pourquoi N-1 : en mode HA par défaut, AHV ne relance pas forcément toutes les VM d’un hôte perdu si les autres manquent de ressources. Le mode Guarantee réserve l’équivalent d’un hôte (deux si un conteneur est en RF3), sur la base de la mémoire du plus gros hôte, et refuse de démarrer une VM qui casserait cette réserve. Côté stockage, la Nutanix Bible définit la Resilient Capacity comme la capacité totale moins ce qu’il faut pour reconstruire après la panne tolérée, et recommande de ne jamais la dépasser.
On raisonne par cluster, pas par hôte : ADS choisit l’hôte au placement initial, défragmente le cluster si besoin et résout les points chauds.
Validez le modèle sur l’état du jour
Avant toute projection, rejouez les formules sur la situation actuelle : elles doivent redonner exactement les taux affichés par Prism. Tant qu’il reste un écart, ne simulez pas.
C’est ce contrôle qui a révélé notre piège. Dans notre modèle, validé sur les taux affichés par Prism, en tolérance à une panne (RF2) sur un cluster homogène :
capacite_resiliente = capacite_totale × (n − 1) / nL’exemple de la Nutanix Bible applique en plus le seuil de 95 % où Stargate passe en lecture seule, et un conteneur RF3 déduit deux nœuds au lieu d’un.
Sauf si Reserve Rebuild Capacity est activé. Cette option, facultative, réserve la capacité du plus gros nœud (ou bloc, ou rack, selon le domaine de panne), et les applications ne voient plus que la Resilient Capacity. La capacité remontée est donc déjà résiliente : lui appliquer (n − 1)/n déduit un nœud de trop, et tous les taux disque de ces clusters deviennent faux.
Deux hypothèses, pas une
Le paramètre le plus sensible a été le multiplicateur disque physique/logique. Nos clusters cibles récents affichaient un multiplicateur bien plus bas que la médiane du parc, qui porte l’historique des clusters plus anciens. D’où deux scénarios :
- nominal : les données migrées gardent le multiplicateur mesuré sur les cibles ;
- défavorable : elles retombent à la médiane du parc.
L’écart s’est compté en nœuds, et à un moment de la campagne le scénario défavorable vidait le stock d’un site. Mesurez le multiplicateur réel après chaque lot. Méfiez-vous aussi d’un tableau de bord qui plafonne ce ratio à l’affichage : chez nous, il masquait un cluster très au-dessus des autres.
Le seuil lui-même coûte cher : viser 75 % au lieu de 80 % aurait absorbé tout le stock de nœuds d’un site. À ne pas confondre avec le seuil d’alerte par défaut de Nutanix sur la Resilient Capacity, lui aussi à 75 %, ni avec les seuils qu’on applique avant une maintenance : ici, on dimensionne.
Rejouez après chaque extension
Le jour où un cluster cible a reçu ses nœuds, la simulation rejouée sur une collecte fraîche l’a ramené sous le seuil et a réduit son besoin restant. Le point dur s’est alors déplacé vers un autre cluster, dont l’extension déjà planifiée posait un nœud de moins que nécessaire.
Le plan bouge aussi. Des lots changent de cible, des VM disparaissent de l’inventaire et gonflent un sizing établi sur un vieux plan. Rafraîchissez les lots sur l’inventaire courant, par UUID (voir les noms de VM ne sont pas uniques). Un placement théorique calculé par un outil ne remplace pas non plus le plan : chez nous, il sous-estimait un cluster.
Ce qu’il faut retenir
- Simulez à N-1, CVM déduites, avec un seuil explicite et assumé.
- Un modèle qui ne retrouve pas les taux du jour ne doit pas servir à projeter.
- Avec Reserve Rebuild Capacity activé, ne déduisez pas un nœud une seconde fois.
- Calculez un scénario nominal et un défavorable ; le multiplicateur disque les départage.
- Chaque extension, et chaque révision du plan, impose de rejouer la simulation.
In English
Place the plan's VMs on the target clusters at N-1, validate the model against today's state, compute a nominal and an unfavorable scenario, and replay everything after each cluster expansion. A simulation is only valid if its formulas reproduce today's measured rates exactly, and with Reserve Rebuild Capacity enabled, deducting one more node skews every disk rate.
Sources & vérification
Testé sur : Inventaire Prism Central de production, 2026
- Nutanix Bible, AHV How It Works (HA) nutanixbible.com
- Nutanix Bible, AHV Architecture (ADS) nutanixbible.com
- Nutanix Bible, Data Resilience and HA (Resilient Capacity) nutanixbible.com
- Nutanix Community, Managing Storage Resiliency is now Simpler than Ever next.nutanix.com
- Nutanix Community, AOS 6 Advances Performance and Resilience next.nutanix.com
- Expérience directe de l’auteur, en production (versions ci-dessus)