Sur chaque nœud, une VM réserve des vCPU et de la RAM sans héberger aucune application : la CVM (Controller VM). Avant de la voir comme une taxe à réduire pour caser une VM de plus, il faut savoir ce qui tourne dedans et pour qui elle travaille.
Ce qu’est la CVM
La Nutanix Bible la présente comme la VM qui porte la logique de la plateforme : I/O de stockage et transformations (déduplication, compression, erasure coding), UI et API, upgrades, réplication et DR. Les contrôleurs de stockage lui sont passés en direct : « all storage I/O bypasses the hypervisor ».
En faire une VM a deux conséquences d’exploitation, selon la Bible : si une CVM tombe, le nœud continue de tourner avec les I/O servies par les autres CVM, et une CVM redémarre pendant un upgrade AOS sans impact sur les VM de l’hôte.
Les services, une ligne chacun
Tous tournent sur chaque nœud, sauf Zookeeper. Rôles d’après la Nutanix Bible :
- Stargate : gestionnaire des I/O de données, interface avec l’hyperviseur (NFS, iSCSI ou SMB), présent partout pour servir les I/O en local.
- Cassandra : magasin de métadonnées distribué en anneau, cohérence stricte par Paxos, accédé via l’interface Medusa.
- Zookeeper : configuration du cluster (hôtes, IP, états), accédée via Zeus, avec un leader élu. Le cluster en conserve 3 copies, et 5 en redundancy factor 3 (voir RF2, RF3 et capacité utile).
- Curator : gestion MapReduce et nettoyage (équilibrage disque, scrubbing proactif…), piloté par un leader élu ; ses scans sont détaillés dans ce billet.
- Chronos : planifie et bride les tâches issues des scans Curator.
- Cerebro : réplication et DR (snapshots planifiés, sites distants, failover).
- Pithos : configuration des vdisks, construit sur Cassandra.
- Prism : passerelle de gestion, UI HTML5, API REST et ncli, avec un leader élu.
- Genesis : démarre et arrête les services, gère la configuration initiale ; il tourne indépendamment du cluster et n’exige que Zookeeper.
- Acropolis : un worker par CVM et un leader élu, côté hyperviseur : ordonnancement des tâches, statistiques, contrôleur réseau, proxy VNC, HA.
Le trajet des I/O dans Stargate est décrit dans ce billet, la mesure de sa latence dans celui-ci.
Où partent les vCPU
Un article technique Nutanix de 2025 donne les ordres de grandeur : une CVM a normalement 8 ou 12 vCPU, parfois 6. Sa charge stockage dépend du nombre et de la taille des I/O, et pas seulement de l’hôte local : les données répliquées par les autres nœuds sont traitées par la CVM de l’hôte qui les reçoit.
Le Sizer Nutanix suppose qu’environ la moitié des vCPU de la CVM servent au stockage : pour une CVM de 12 vCPU, « on average 6 physical cores would not be available » pour les VM. Ces cœurs ne sont pas confisqués : hors contention, la CVM est ordonnancée comme une VM ordinaire ; en contention, AHV lui donne un poids 4 fois supérieur à une VM utilisateur.
Le scheduler dynamique surveille aussi Stargate, selon la Bible : quand un Stargate dépasse son seuil (actuellement 85 % de la CPU qui lui est allouée) et qu’une contention est attendue, il déplace des VM ou des volumes ABS. Voir aussi affinité et anti-affinité sur AHV.
Où part la RAM
L’Unified Cache, cache de lecture des données, métadonnées et données dédupliquées, vit dans la mémoire de la CVM. La Bible donne sa taille :
Unified Cache = (RAM CVM - 12 Go) x 0,45
CVM de 32 Go : (32 - 12) x 0,45 = 9 GoRéduire la RAM d’une CVM réduit donc mécaniquement son cache.
En 2018, Josh Odgers ajoutait que plus de RAM agrandit le cache de métadonnées Medusa, ce qui réduit la latence de lecture.
Ce qu’il faut retenir
- La CVM travaille pour toutes les VM du cluster, pas seulement pour celles de son hôte.
- Normalement 8 ou 12 vCPU, avec un poids d’ordonnancement 4 fois supérieur à une VM, appliqué uniquement en contention.
- Le Sizer compte environ la moitié des vCPU de la CVM pour le stockage ; une mesure sur charge réelle fait mieux.
- Unified Cache = (RAM CVM – 12 Go) x 0,45 : toute réduction de RAM se paie en cache de lecture.
In English
Stargate, Cassandra, Curator, Zookeeper, Prism, Genesis: the role of each CVM service, and why its vCPUs and RAM work for every VM in the cluster. The CVM carries the platform logic and receives the storage controllers in passthrough, and the AHV scheduler gives it a weight four times that of a VM, only under contention.
Sources & vérification
Relevé sur : Documentation publique Nutanix (Nutanix Bible, blog technique Nutanix) et blog de Josh Odgers, relevé 2026-10
- Nutanix Bible, Basics – Cluster Components nutanixbible.com
- Nutanix Bible, Basics – Hyperconverged Platform nutanixbible.com
- Nutanix Bible, AOS Architecture (Dynamic Scheduler) nutanixbible.com
- Nutanix Bible, Data I/O Path nutanixbible.com
- Nutanix Community, Redundancy Factor vs Replication Factor (2020) next.nutanix.com
- Understanding CPU Resource Management in Nutanix AHV (blog Nutanix, 2025) nutanix.com
- Josh Odgers, Nutanix Scalability Part 3 (2018) joshodgers.com