Dans Prism, ajouter un nœud se résume à quelques clics : Josh Odgers (2016) parle d’une opération « basically a one click ». Les échecs se jouent avant, à la découverte et sur les versions. Après, il reste une question : quand les données se répartissent-elles ?
Avant : versions et réseau
Les versions. Un tableau repris sur le forum Nutanix résume les cas :
- même AOS et même hyperviseur : le nœud est ajouté sans réimage ;
- même hyperviseur, AOS différent : le nœud est réimagé automatiquement avant l’ajout. Si l’AOS du nœud est plus récent, on peut mettre le cluster à niveau d’abord, sinon le nœud est ramené à la version plus ancienne du cluster ;
- même AOS, hyperviseur différent : le nœud est réimagé avant l’ajout.
Le réseau. La découverte exige que les paquets multicast IPv6 traversent le switch physique. La documentation citée sur le forum précise qu’elle trouve les nœuds préparés en usine quel que soit l’état de leur VLAN. Le nœud doit être allumé, sa CVM démarrée ; un salarié Nutanix fait vérifier les services avec genesis status sur la CVM du nouveau nœud.
Pendant : découverte et plan B
L’assistant Expand Cluster de Prism Element liste les nœuds découverts. Un participant du forum suggère l’option Prepare Now and Expand Later pour valider la préparation avant l’ajout effectif.
Si la découverte échoue, un Nutanix Technology Champion décrit sa méthode sur le forum. Il câble le nouveau nœud comme ceux de production, en vérifiant le LACP. Il le repasse sous Foundation avec les versions du cluster, IP de l’AHV et de la CVM renseignées, création automatique de cluster décochée. Il étend enfin le cluster en saisissant l’IP de la CVM.
En ligne de commande, la Nutanix Bible donne la séquence depuis une CVM du cluster :
# lister les nœuds découvrables
ncli cluster discover-nodes
# one-liner de la Bible : ajoute TOUS les nœuds découverts
ncli cluster discover-nodes | egrep "Uuid" | awk '{print $4}' | xargs -I UUID ncli cluster add-node node-uuid=UUIDAprès : ce que font les données
Pas de déplacement massif. Selon Josh Odgers (2016), la capacité est disponible immédiatement et il n’y a « no mass movement of data ».
Les écritures s’y répartissent tout de suite. Le stockage distribué envoie des réplicas d’écriture vers tous les nœuds, nouveaux compris, sans déplacer de VM. Le placement tient compte de la performance et de la capacité. Odgers parle en 2020 d’« in-line balancing » : plus le cluster écrit, plus vite il s’équilibre. En attendant qu’on y migre des VM, le nouveau nœud se comporte en nœud de stockage seul.
Les métadonnées suivent. La Bible indique que les nouveaux nœuds sont insérés tout au long de l’anneau de métadonnées. Le hachage cohérent limite la redistribution de clés.
Curator finit le travail. Le disk balancing tourne périodiquement et dès qu’un seuil est franchi. Il déplace les données les plus froides, dans le même tier uniquement. Ses tâches passent par des files de priorité et sont régulées par Chronos pour ne pas toucher la latence des VM. Odgers citait en 2020 des réglages internes par défaut : 15 % d’écart d’utilisation toléré, 20 à 100 Go déplacés par scan Curator. La Bible ne chiffre pas ce seuil.
Les VM ne viennent pas seules. Le Dynamic Scheduler ne déplace des VM qu’en cas de contention ; la Bible donne le seuil : actuellement 85 % du CPU de l’hôte. Sur un cluster calme, le nouveau nœud reste sans VM tant qu’on n’en migre pas.
Vérifications
cluster status
ncc health_checks run_all
curator_cli get_under_replication_info summary=trueContrôlez aussi la résilience des données, comme avant une maintenance (commande dans ce billet).
Ce qu’il faut retenir
- Alignez AOS et hyperviseur avant l’ajout : tout écart déclenche une réimage du nœud.
- Sans multicast IPv6 sur le switch, pas de découverte : Foundation puis ajout par IP.
- Le nœud reçoit des réplicas d’écriture dès son arrivée ; Curator rééquilibre ensuite en tâche de fond, régulé pour épargner les I/O des VM.
- Les VM ne migrent pas d’elles-mêmes vers le nouveau nœud hors contention.
- Laissez le rééquilibrage se terminer avant de compter sur une reconstruction rapide.
In English
Discovery relies on IPv6 multicast, a version mismatch means a reimage, and the node arrives empty. Writes are spread to it immediately, then Curator rebalances in the background. Without multicast across the physical switch, the node is prepared with Foundation and added by IP, and until rebalancing completes, lightly filled nodes contribute little to a rebuild.
Sources & vérification
Relevé sur : Documentation publique Nutanix (Nutanix Bible, nutanix.dev, forum next.nutanix.com) et billets de Josh Odgers, relevé 2026-10
- Nutanix Bible, AOS Administration (Cluster add node from cmdline, Curator) nutanixbible.com
- Nutanix Bible, AOS Architecture (Disk Balancing, Dynamic Scheduler) nutanixbible.com
- Nutanix Bible, Data I/O Path (anneau de métadonnées) nutanixbible.com
- Nutanix Community, Nutanix Cluster upgrade and expansion (2022) next.nutanix.com
- Nutanix Community, Not able to discover the new nodes to expand the cluster (2019) next.nutanix.com
- Nutanix Community, Expand Cluster with New Node (2024) next.nutanix.com
- Nutanix Community, Node expansion on a cluster (2022) next.nutanix.com
- Josh Odgers, Heterogeneous Cluster Support, Nutanix vs VMware vSAN (2020) next.nutanix.com
- Josh Odgers, Expanding Capacity on a Nutanix environment (2016) joshodgers.com
- Josh Odgers, Nutanix Resiliency Part 3, rebuild performance with RF3 (2018) joshodgers.com
- Bhavik Desai, Seamless Cluster Management for Performance and Capacity (2022) nutanix.dev