Mettre un nœud en maintenance est un geste banal : les VM migrables partent à chaud sur les autres nœuds, les autres (épinglées, GPU, passthrough, agent VM) sont arrêtées le temps de la maintenance. Pour la latence, en revanche, tout dépend du tier de stockage du cluster.
Ce qu’on a mesuré
Observé sur AOS 7.3, sur environ 3 heures de maintenance d’un nœud d’un cluster hybride (SSD + HDD SATA) :
- latence de lecture du cluster : 1,2 ms en temps normal, 1 862 ms en moyenne sur la pire heure, 13,7 s au maximum ;
- latence d’écriture : inchangée ;
- IOPS de lecture : d’environ 1 000 à 244, ressenti côté applications comme des problèmes de VM ;
- tous les autres nœuds touchés, sauf le nœud en maintenance, évacué ; retour à la normale dès sa sortie.
Quatre mises en maintenance de nœuds sur des clusters full-flash sont restées autour de 2 ms. Sur douze mois d’historique, seize fenêtres de maintenance croisées avec la latence n’ont produit qu’un seul cas grave : celui-ci.
Le mécanisme
En maintenance, la CVM du nœud entre elle aussi en maintenance puis s’arrête (séquence décrite par Mike Dent) : ses disques ne sont plus accessibles, et Josh Odgers rappelle que les copies qu’ils portent deviennent indisponibles. Les VM évacuées, elles, perdent leur localité : la Nutanix Bible indique que la lecture d’anciennes données, restées sur un nœud désormais distant, « will be forwarded by the local CVM to the remote CVM ». Chaque lecture traverse donc le réseau vers une autre copie.
Sur un cluster hybride, la flash est le tier 0 et le HDD le tier 1. ILM (Intelligent Lifecycle Management) descend sur HDD les données choisies « using last access time ». L’explication retenue par notre analyse : les lectures redirigées de données froides tombent sur des HDD SATA d’autres nœuds, en accès aléatoire, qui saturent. La Bible ne détaille pas ce chemin précis. En full-flash, la Bible précise que « no tier ILM will occur as only a single flash tier exists » : la lecture distante reste une lecture flash.
L’analyse a aussi évoqué une reprotection par Curator ; la Bible ne la décrit qu’en cas de panne, et sa part, si elle a joué, n’a pas été mesurée.
Évaluer un cluster avant d’y toucher
Voici la grille utilisée, cluster par cluster, sur sept jours de tendances :
- Tier : hybride signifie risque de latence en lecture, quel que soit le reste.
- Taille : un petit cluster full-flash de 3-4 nœuds marquait environ 20 ms sur la pire heure à chaque opération. Un cluster mono-nœud, c’est une coupure.
- RAM en N-1 : pic de RAM utilisée divisé par la RAM totale moins celle du plus gros nœud. Seuils retenus : 90 % et plus en rouge, 75 % et plus en orange. Un cluster de 3 nœuds à 60 % passe à environ 90 %. Même principe pour le CPU.
- Très grosses VM : facteur aggravant, à signaler à part.
- Historique : croisez les fenêtres de maintenance passées avec la latence au niveau cluster. Nos items par nœud, découverts automatiquement, ne couvraient qu’une partie des nœuds.
Un cluster hybride se maintient hors heures ouvrées, flux critiques basculés sur l’autre site si l’application le permet, CVM arrêtée le moins longtemps possible.
Avant et après l’opération, contrôlez la résilience des données, visible sur le tableau de bord Prism ou par :
ncli cluster get-domain-fault-tolerance-status type=nodeCe qu’il faut retenir
- Sur hybride, la maintenance d’un nœud peut faire exploser la latence de lecture sans toucher l’écriture.
- Nœud en maintenance, les VM évacuées lisent sur des copies distantes ; sur hybride, les données froides sont sur HDD.
- Sur hybride : hors heures ouvrées, flux critiques basculés, CVM arrêtée le moins longtemps possible.
- Évaluez chaque cluster sur le tier, la taille, la RAM en N-1 et l’historique de latence en lecture.
In English
Same operation, opposite effects. Putting one node in maintenance raised the read latency of a hybrid cluster from 1.2 ms to more than one second, while full-flash clusters stayed around 2 ms. Evacuated VMs lose data locality and read remote copies, and on hybrid, cold data lives on HDD. The mechanism, and how to assess a cluster before maintenance.
Sources & vérification
Testé sur : AOS 7.3, clusters hybrides SSD + HDD SATA et full-flash
- Nutanix Bible, Data Resilience and HA nutanixbible.com
- Nutanix Bible, Data I/O Path nutanixbible.com
- Nutanix Bible, AOS Architecture (Storage Tiering and Prioritization) nutanixbible.com
- Josh Odgers, Read I/O during CVM maintenance or failures (2018) joshodgers.com
- Mike Dent, Mastering Maintenance Mode Operations in Nutanix (2023) mikedent.io
- Expérience directe de l’auteur, en production (versions ci-dessus)