Oracle RAC ou un cluster de basculement Windows veulent des disques partagés que l’hyperviseur ne fournit pas toujours. Nutanix Volumes expose le stockage du cluster en iSCSI, avec une haute disponibilité qui ne repose pas sur le multipath du client.
Ce que fait Volumes
La Nutanix Bible définit Volumes comme l’exposition du stockage DSF (Distributed Storage Fabric) à des consommateurs externes : l’OS parle directement à Nutanix, sans passer par l’hyperviseur. Cas d’usage cités : disques partagés (Oracle RAC, Microsoft Failover Clustering), disques gérés comme entités de premier rang (conteneurs, OpenStack), iSCSI initié depuis l’invité, serveurs physiques.
Quatre objets à connaître :
- Data Services IP (DSIP) : IP unique à l’échelle du cluster pour les connexions iSCSI, introduite en AOS 4.7.
- Volume Group (VG) : cible iSCSI regroupant des disques, avec gestion et snapshots centralisés.
- Attachment : autorise un IQN d’initiateur (ou une VM) à accéder au VG. Un initiateur inconnu est rejeté.
- Secret : authentification CHAP ou Mutual CHAP.
La DSIP, portail unique
La DSIP se configure avant tout VG : c’est le portail de découverte et de connexion. Elle est portée par le leader iSCSI ; s’il tombe, un nouveau leader est élu et reprend l’adresse. Le client n’a donc jamais à connaître les IP des CVM.
À la connexion, la plateforme effectue une redirection de login iSCSI vers un Stargate sain. Si ce Stargate tombe, l’initiateur refait un login sur la DSIP et la plateforme le redirige vers un autre Stargate sain. Le retour est piloté par le cluster, pas par l’initiateur : une fois le Stargate d’origine sain depuis le délai prévu, 120 secondes par défaut, le Stargate actif suspend les I/O et ferme les sessions ; au login suivant, la DSIP renvoie l’initiateur vers son Stargate d’origine. La santé des Stargates est suivie par Zookeeper, avec le même mécanisme que DSF.
Pas de MPIO, mais des cibles virtuelles
Conséquence directe, selon la Bible : le MPIO côté client n’est plus nécessaire pour la haute disponibilité des chemins, et il n’y a pas à cocher « Enable multi-path » à la connexion.
Reste la performance. La norme iSCSI impose une seule session par cible. Depuis AOS 4.7, 32 cibles virtuelles sont créées par défaut pour chaque initiateur attaché : chaque disque a sa propre session, et ces sessions se répartissent sur plusieurs Stargates. La répartition se fait au login, par hachage, et depuis AOS 5.0 le Dynamic Scheduler peut rééquilibrer les sessions. Un nœud préféré peut être imposé tant qu’il reste sain.
Sous Windows, la Bible identifie les Stargates qui hébergent les cibles en listant les connexions établies vers le port 3205 ; la sortie donne l’IP de la CVM :
Get-NetTCPConnection -State Established -RemotePort 3205Volumes supporte aussi SCSI UNMAP (TRIM).
Sur AHV : attachement direct et VG Load Balancer
Sur AHV, un VG s’attache directement à une VM, sans iSCSI dans l’invité. Josh Odgers y voit l’avantage d’écarter les problèmes de pilote et de configuration. Côté hôte, la Bible décrit un iscsi_redirector en écoute sur 127.0.0.1:3261, utilisé par QEMU comme portail, qui redirige vers un Stargate sain, de préférence local.
Par défaut, les vDisks d’un VG attaché directement sont servis par la CVM locale. Le VG Load Balancer répartit leur propriété sur toutes les CVM ; si une CVM consacre plus de 85 % de son CPU au trafic stockage, ADS (Acropolis Dynamic Scheduler) déplace des sessions. Commandes documentées par la communauté Nutanix, en SSH sur une CVM avec l’utilisateur nutanix :
acli vg.create <vg> load_balance_vm_attachments=true
acli vg.update <vg> load_balance_vm_attachments=true
acli vg.get <vg>Contraintes relevées dans le même fil (2021) : 10 VG load-balancés au plus par VM ; timeout SCSI à 60 secondes sur les invités Linux ; chaque vDisk étant servi par une seule CVM, il faut plusieurs vDisks et un volume agrégé (striping) côté OS pour profiter de plusieurs CVM. Josh Odgers déconseille d’exclure des CVM du load balancer.
En automatisation, la référence actuelle de l’API v4 demande PC 7.3 / AOS 7.3 pour le namespace volumes (qui sert quelle API).
Ce qu’il faut retenir
- Volumes expose DSF en iSCSI à un OS invité ou physique, pour les disques partagés et les clusters invités.
- Les initiateurs pointent sur la DSIP ; la redirection de login assure la haute disponibilité, sans MPIO côté client.
- Une session par disque : pour répartir la charge, multipliez les disques dans le VG.
- Sur AHV, l’attachement direct évite l’iSCSI dans l’invité ; le VG Load Balancer s’active VG détaché et suppose plusieurs vDisks agrégés dans l’OS.
In English
A volume group exposes cluster storage over iSCSI to a VM or a physical server. The role of the Data Services IP, why MPIO becomes unnecessary, and the VG load balancer on AHV. The Data Services IP acts as a single portal and sessions are redirected to a healthy Stargate, while enabling the load balancer on an existing VG requires detaching the VMs.
Sources & vérification
Relevé sur : Documentation publique Nutanix (Nutanix Bible, nutanix.dev, Nutanix Community) et blog d'ingénieur Nutanix, relevé 2026-10
- Nutanix Bible, Volumes (Block Services) nutanixbible.com
- Nutanix Bible, AHV How It Works nutanixbible.com
- Nutanix Community Blog, Scaling Up VM Storage Performance on AHV – Volume Group Load Balancer (2018) next.nutanix.com
- Nutanix Community, Enabling Load balancing of vdisks in a volume Group (2021) next.nutanix.com
- Josh Odgers, Nutanix Scalability Part 4, Storage Performance for Monster VMs with AHV (2018) joshodgers.com
- nutanix.dev, API Reference v4 Introduction nutanix.dev