On ne va pas se mentir : éteindre un cluster Nutanix complet, c’est toujours un moment un peu stressant. Même après 15 ans de métier. Pourquoi ? Parce qu’on a beau avoir la meilleure techno HCI du marché, couper le courant sur une infrastructure informatique n’est jamais anodin.

J’ai vu trop de « cowboys » tirer la prise ou faire un « Shutdown » brutal via l’IPMI en pensant que la résilience des données ferait le reste. Spoiler : ça finit souvent avec un support Nutanix niveau 3 pour récupérer des métadonnées Cassandra corrompues ou avec la perte d’un ou plusieurs disques.

Ce guide, c’est ma ligne de vie pour m’assurer que mon cluster redémarrera sans problème. Pas de GUI, pas de Prism Element pour les étapes critiques. On ouvre le terminal, on se connecte en SSH, et on fait ça proprement.

Phase 1 : Le Health Checks

Avant même de penser à arrêter la moindre VM, il faut s’assurer que le cluster est capable de s’arrêter (et surtout de redémarrer). Si votre cluster est déjà en souffrance, l’éteindre n’est pas toujours une bonne option.

1.1 Connexion en SSH a la CVM

Ouvrez votre terminal préféré (PuTTy fait très bien l’affaire) et connectez-vous en SSH à l’adresse IP virtuelle du cluster (Cluster VIP) avec l’utilisateur nutanix.

1.2 Nutanix Cluster Checks (NCC)

Pour s’assurer que le cluster est en bonne santé, il est nécessaire de lancer un NCC. Lancez un check complet :

ncc health_checks run_all

Mon conseil : Ne survolez pas le rapport. Si vous avez un « FAIL » sur la partie Cassandra, Zookeeper ou Metadata, STOP. On répare avant d’éteindre. Un warning sur un disque plein ou une vieille alerte NTP, ça passe. Mais l’intégrité des données, c’est non-négociable.

1.3 Vérification de la résilience

Le dashboard Prism est joli, il vous dit « Data Resiliency Status: OK ». C’est bien, mais ce n’est pas assez précis pour un arrêt total. Je veux savoir si mes données sont réellement synchronisées, maintenant.

Tapez cette commande et regardez-la dans les yeux :

ncli cluster get-domain-fault-tolerance-status type=node

Ce que vous devez voir : Une ligne indiquant Current Fault Tolerance: 2.

Si vous voyez un état indiquant une reconstruction en cours, n’éteignez pas le cluster et patientez pendant la reconstruction.

Phase 2 : L’extinction des machines virtuelles

Une fois le cluster validé comme sain, on passe aux machines virtuelles. L’erreur classique est de se précipiter sur l’arrêt des nœuds, mais il vous sera refusé si des machines virtuelles sont toujours allumées sur le cluster.

2.1 L’ordre de bataille

Commencez par éteindre vos environnements de test/dev, puis les serveurs applicatifs, et enfin les bases de données. C’est du bon sens, mais il est toujours bon de le rappeler.

Une fois l’ensemble des machines de production éteintes, vous pouvez maintenant éteindre le reste des machines virtuelles “outils” de votre infrastructure : AD, DNS, firewalls…

2.2 La gestion de Prism Central

Connectez vous à Prism Central en SSH avec le compte nutanix puis lancez la commande d’arrêt :

cluster stop

Patientez pendant l’arrêt des services de la PCVM et vérifiez que le cluster est bien éteint :

cluster status

Si l’ensemble des services sont éteints et que le statut du cluster est “stop”, nous pouvons maintenant procéder à l’arrêt de la PCVM :

sudo shutdown -h now

Phase 3 : L’arrêt des services Nutanix (« Cluster Stop »)

Vos VMs et Prism Central sont éteints. Vos hôtes ne font plus tourner que les CVMs (Controller VMs). C’est le moment critique. On ne fait jamais un shutdown de l’OS des CVMs sans avoir d’abord arrêté les services du cluster proprement.

Pourquoi ? Parce qu’un arrêt brutal des CVMs peut entrainer une corruption des données ou une inconsistances des métadonnées qui pourra nécessiter l’intervention du support.

3.1 L’arrêt du cluster

Reconnectez vous à la VIP de votre cluster Nutanix et tapez simplement :

cluster stop

Le système va demander une confirmation avant de lancer les opérations. Tapez Y.

Cette commande ordonne à chaque CVM d’arrêter ses services dans un ordre précis. Le service Stargate (qui gère les I/O de stockage) s’assure que tout est « flushé » sur disque avant de s’éteindre.

Vous allez voir des lignes défiler indiquant l’arrêt de Zeus, Scavenger, Cassandra, etc. Soyez patient. Selon la taille du cluster, cela peut prendre 2 à 5 minutes.

3.2 La vérification

Une fois l’opération terminée, vérifiez l’état réel des services :

cluster status

Ce que vous devez voir : Une liste de services pour chaque CVM. Ils doivent tous être en état DOWN, à l’exception potentielle du service Genesis qui peut rester UP , c’est normal.

Si vous voyez d’autres services encore UP, patientez une minute et relancez la vérification. Ne passez pas à la suite tant que le cluster n’est pas totalement à l’arrêt logique.

Phase 4 : Extinction des CVMs et des Nœuds physiques

Nous voici au bout du tunnel. Le cluster est arrêté logiciellement. Il ne reste plus que les coquilles vides : les CVMs (qui sont des VMs Linux, ne l’oublions pas) et les hyperviseurs.

4.1 Arrêt des CVMs

Il faut maintenant se connecter sur chaque CVM individuellement (via son IP, plus via la VIP) et lancer la commande d’extinction.

La commande officielle :

cvm_shutdown -P now

La commande cvm_shutdown contient des hooks spécifiques pour notifier l’hyperviseur. Répétez l’opération sur chaque nœud du cluster.

4.2 Arrêt des Hyperviseurs

Une fois les CVMs éteintes, connectez-vous à vos hôtes (en SSH ou via IPMI) et sur chacun d’entre eux tapez la commande suivante :

shutdown -h now

La Pépite Expert : Le Script d’Automatisation ⚡

Vous avez un cluster de 16 nœuds et la flemme de vous connecter 32 fois (16 CVM + 16 Hosts) ? Je vous comprends.

Voici un script à lancer depuis n’importe quelle CVM du cluster qui va éteindre toutes les CVMs, puis tous les hôtes AHV.

⚠️ AVERTISSEMENT : Ce script ne pose pas de questions. Assurez-vous d’avoir validé la Phase 3 (cluster stop) avant de lancer ça, sinon c’est le crash assuré.

Le script « Kill Switch » (Pour AHV)

Depuis une CVM, ce script récupère les IPs des autres CVMs et des hôtes, puis envoie l’ordre d’extinction en séquence.

for svmip in `svmips`; do ssh -q nutanix@$svmip "sudo /usr/sbin/shutdown +1 ; hostname"; done
for hostip in `hostips`; do ssh -q root@$hostip "/usr/sbin/shutdown +3 ; hostname"; done

• La première commande ordonne l’extinction des CVMs après un délai d’une minute.
• La seconde commande ordonne l’extinction des noeuds après un délai de 3 minutes.

Une fois que vous aurez lancé les commandes, vous perdrez la connexion au bout d’une minute. Vous pouvez alors suivre l’extinction de vos noeuds depuis leurs interfaces IPMI respectives.

Phase 5 : Le Rallumage (Cold Boot)

La période de maintenance est terminée. On fait quoi ? On appuie sur ON et on prie ? Non, on respecte l’ordre inverse.

1. Réseau Physique : Allumez vos switchs Top-of-Rack en premier. Si le réseau n’est pas là, les nœuds ne se verront pas au démarrage.
2. IPMI / Physique : Allumez les nœuds physiques.
3. Patience : AHV va booter, puis démarrer automatiquement la CVM.
   • Astuce : Ne touchez à rien pendant 10 minutes. Laissez les CVMs former le cluster.
4. Démarrage du Cluster : Connectez-vous en SSH sur une CVM. Vérifiez que toutes les CVMs sont up (svmips doit toutes les lister). Puis :cluster start
5. Vérifier que le cluster est bien démarré avec la commande :cluster status
6. Démarrage des Workloads : Une fois le cluster UP, rallumez d’abord la PCVM puis vos VMs (Infra d’abord, Appli ensuite).

Conclusion

L’arrêt d’un cluster Nutanix est une procédure simple mais qui nécessite un bon séquençage. Ce n’est pas compliqué, mais ça ne pardonne pas l’impatience. Si vous suivez ces étapes, vous dormirez tranquille pendant la coupure électrique.