Aller au contenu
6 minutes

Shadow clones : comment AOS sert un disque de base VDI en local sur chaque nœud

Quand plusieurs CVM ne font que lire le même vDisk, AOS le marque immuable et chaque nœud en garde une copie locale. Conditions de déclenchement, fin du mode et vérification.

Shadow clones : comment AOS sert un disque de base VDI en local sur chaque nœud

Dans un pool VDI en linked clones, des centaines de bureaux lisent le même disque de base. Sans mécanisme dédié, toutes ces lectures convergent vers les nœuds qui portent ce disque, et la localité des données ne joue plus.

Le problème : un disque, des centaines de lecteurs

Dans VMware Horizon (View Composer), le replica disk était lu par tous les linked clones ; Citrix MCS parle de master image. Kees Baggerman résume le schéma MCS : toutes les lectures viennent de l’image maître, les écritures partent dans un disque de différence propre à chaque VM.

Sur un cluster Nutanix, les blocs de ce disque sont répartis sur quelques nœuds. Andre Leibovici le rappelait dès 2014 : chaque hôte doit alors aller chercher ces blocs à travers le réseau. C’est exactement la lecture distante que la data locality cherche à éviter : ce billet-là décrit comment AOS relocalise les données d’une VM ordinaire, celui-ci traite le cas d’un disque lu par tout le cluster.

Les conditions de déclenchement

La Nutanix Bible décrit le mécanisme. AOS surveille les tendances d’accès aux vDisks, comme il le fait pour la data locality. Deux conditions doivent être réunies :

  • les requêtes viennent de plus de deux CVM distantes, en plus de la CVM locale ;
  • toutes ces requêtes sont des lectures.

AOS marque alors le vDisk comme immuable. Chaque CVM qui le lit peut ensuite le mettre en cache localement : ce sont les shadow clones du vDisk de base. Les VM de chaque nœud lisent le disque de base en local.

Les données ne migrent qu’au moment d’une lecture. Rien n’est poussé d’avance sur tous les nœuds, ce qui évite d’inonder le réseau et réserve le cache aux blocs réellement utilisés.

Le VDI n’est pas le seul cas : la Bible cite les serveurs de déploiement et les dépôts, et plus largement tout scénario « multi-reader ». À l’inverse, un vDisk qui reçoit des écritures ne remplit pas la seconde condition.

Ce qui met fin au mode

Si la VM de base est modifiée, les shadow clones sont supprimés et le processus repart de zéro. Après une mise à jour de l’image maître, le gain ne revient donc qu’une fois le motif « plusieurs CVM, lecture seule » de nouveau constaté par AOS. La Bible ne donne pas de délai pour cette nouvelle détection.

Conséquence pratique : garder le disque de base strictement en lecture. Une écriture sur la VM de base suffit à défaire ce qui a été construit.

Activer, désactiver, vérifier

La Bible et la page Nutanix de 2024 sur la data locality l’indiquent : les shadow clones sont activés par défaut. Ce n’était pas le cas au départ. En 2014, Andre Leibovici décrivait une fonction à activer à la main ; Kees Baggerman la donnait activée par défaut à partir de NOS 4.0.2.

Depuis une CVM, l’activation se pilote ainsi :

ncli cluster edit-params enable-shadow-clones=<true/false>

Pour voir si des shadow clones existent, la Bible donne cette commande. Elle les liste au format name#id@svm_id :

vdisk_config_printer | grep '#'

Si rien ne sort, aucun vDisk n’a de shadow clone à cet instant.

Ce qu’il faut retenir

  • Les shadow clones visent un vDisk lu par de nombreuses VM réparties sur le cluster : replica disk de VMware Horizon (View Composer), image maître MCS, dépôt de déploiement.
  • Déclenchement : plus de deux CVM distantes en plus de la locale, uniquement des lectures ; le vDisk passe alors immuable.
  • Chaque nœud ne met en cache que ce qu’il lit, au fil des lectures.
  • Toute modification de la VM de base supprime les shadow clones : le cycle de détection recommence.
  • Activés par défaut ; vdisk_config_printer | grep '#' montre s’ils sont en place.

In English

When several CVMs only read the same vDisk, AOS marks it immutable and each node keeps a local copy. Trigger conditions, end of the mode and verification: in VDI, the base disk becomes a shadow clone when more than two remote CVMs only read it, any change to the base VM removes the shadow clones, and vdisk_config_printer lists existing ones.

Sources & vérification

Relevé sur : Documentation publique Nutanix (Nutanix Bible) et billets d'ingénieurs Nutanix, relevé 2026-10

Comment les billets sont vérifiés et corrigés