Après une migration à chaud, une VM tourne sur un nœud qui ne porte pas forcément ses données. AOS ne déplace jamais ses disques en bloc : il rapatrie ce qui est lu, selon des seuils précis qu’il vaut mieux connaître avant d’interpréter une courbe de latence.
Le principe
Sur Nutanix, la CVM (Controller VM) de chaque hôte sert toutes les lectures et écritures des VM qui tournent à côté d’elle. En régime établi, les données d’une VM sont sur les disques de sa CVM locale, et la Nutanix Bible précise que les lectures sont alors servies localement « in most cases », sans toucher le réseau.
Quand la VM change d’hôte, que ce soit par migration ou lors d’un événement HA, c’est la CVM du nouvel hôte qui prend le relais.
Les écritures : locales tout de suite
Dès l’arrivée sur le nouvel hôte, les écritures se font localement et sont répliquées de façon synchrone vers d’autres CVM avant acquittement, comme détaillé dans le chemin d’une écriture et l’OpLog.
Les lectures : distantes, puis relocalisées
Les données écrites avant la migration sont restées sur l’ancien nœud. La CVM locale transfère ces lectures à la CVM distante. AOS détecte ces I/O venues d’un autre nœud et rapatrie les données en arrière-plan, uniquement à la lecture, pour ne pas saturer le réseau.
La Bible décrit deux mécanismes distincts :
| Cache locality | Extent group locality | |
|---|---|---|
| Ce qui bouge | données copiées dans le cache unifié du Stargate local | extent groups migrés dans l’Extent Store local |
| Granularité | 4 Ko | extent group |
| Déclencheur | temps réel, si la CVM locale possède le vDisk | 3 touches aléatoires ou 10 séquentielles en 10 minutes, sauf réplique déjà locale |
Deux précisions comptent pour le délai :
- Le jeton du vDisk. Le cache exige la propriété du vDisk. L’ancien Stargate ne rend le jeton qu’après avoir vu des I/O distantes pendant plus de 300 secondes ; le Stargate local le prend alors. Avant, le cache reste côté ancien hôte.
- L’échantillonnage. La relocalisation des extent groups est échantillonnée : plusieurs lectures dans un même échantillon de 10 secondes ne comptent que pour une touche.
Josh Odgers ajoutait sur son blog, en 2017, deux points : les données lues froides ne sont pas relocalisées, et quand un extent l’est, une des répliques redondantes est marquée pour suppression. La relocalisation ne laisse donc pas une copie des données en plus. Selon lui, elle consomme autant de réseau qu’une simple lecture distante.
L’effet sur la latence
Juste après une migration, une partie des lectures traverse le réseau vers une autre CVM tant que les seuils ne sont pas atteints, et le cache reste côté ancien hôte pendant plus de 300 secondes. Les données rarement lues peuvent rester distantes durablement.
Odgers indiquait en 2017 qu’à partir d’AOS 4.5, AOS mesure la latence locale et distante et peut servir une lecture depuis la réplique distante quand elle répond plus vite, un gain qu’il disait surtout visible sur les tiers SATA.
Sur un cluster hybride, ces lectures distantes peuvent finir sur des HDD : c’est le mécanisme détaillé dans maintenance d’un nœud, hybride contre full-flash. Pour établir qu’une latence vient bien du stockage, voir mesurer avant d’accuser le stockage.
L’exception : les disques lus par beaucoup de VM
Un disque de base lu par beaucoup de VM, comme une image VDI, ne peut être local partout. AOS le traite à part avec les shadow clones, décrits dans ce billet.
Ce qu’il faut retenir
- Après une migration, les écritures sont locales immédiatement, mais toujours répliquées de façon synchrone vers d’autres CVM.
- Les lectures de données anciennes passent par la CVM distante jusqu’à leur relocalisation, qui n’a lieu qu’à la lecture.
- Seuils : 3 touches aléatoires ou 10 séquentielles en 10 minutes par extent group, plus de 300 secondes d’I/O distantes pour le jeton du vDisk.
- Les données froides restent distantes : la localité se reconstruit sur le jeu actif, pas sur tout le disque.
In English
Writes become local immediately, reads stay remote for a while, and relocation is triggered by precise thresholds. How AOS data locality works after a live migration and what it changes for latency: an extent group is relocated after 3 random or 10 sequential touches within 10 minutes, and data read cold is not relocated.
Sources & vérification
Relevé sur : Documentation publique Nutanix (Nutanix Bible) et blog de Josh Odgers, relevé 2026-10
- Nutanix Bible, AOS Architecture (Data Locality, Shadow Clones) nutanixbible.com
- Nutanix Bible, Data I/O Path nutanixbible.com
- Nutanix Bible, Data Resilience and HA (Data Path Resiliency) nutanixbible.com
- Josh Odgers, Evaluating Nutanix' original & unique implementation of Data Locality (2017) joshodgers.com