Il y a quelques années, suite à une panne de courant sur l’un de nos 2 sites, j’ai dû faire face à certaines problématiques applicatives après le redémarrage du cluster Nutanix. Sur le papier, tout aurait dû bien se passer : l’onduleur avait repris le relais, aucun impact sur la production mais c’était sans compter sur une mauvaise manipulation du technicien qui a coupé l’onduleur. Le cluster s’est brutalement arrêté.

Une fois le courant revenu, le cluster a redémarré automatiquement et l’ensemble des VMs a redémarré dans la foulée. Le problème, c’est que certains serveurs de bases de données ont pris leur temps… Trop de temps pour certaines applications métiers…

C’est exactement pour vous éviter ces sueurs froides nocturnes que nous allons explorer aujourd’hui les VM Startup Policies sur Nutanix AHV.

Si le concept d’ordonnancer le démarrage de ses serveurs peut paraître simple, la mécanique sous-jacente mérite qu’on s’y attarde.

Que sont les “VM Startup Policies” ?

Les VM Startup Policies sont une fonctionnalité native de l’hyperviseur AHV qui agit comme un ordonnanceur lors de l’allumage de vos machines virtuelles. Cette fonctionnalité a été ajoutée avec la version 7.5 dont je vous avais parlé il y a quelques temps sur le blog.

Au lieu de subir l’ordre de démarrage et de laisser la main au cluster, vous définissez précisément des groupes de VMs et des règles de dépendances strictes. Ainsi, vous garantissez que vos services d’infrastructure (comme un Active Directory par exemple) et vos bases de données soient pleinement opérationnels avant d’autoriser le démarrage des serveurs applicatifs.

Pour bien comprendre l’importance de ces règles, un petit rappel du comportement par défaut d’Acropolis HA s’impose. En l’absence de Startup Policy, lors d’un crash de nœud ou d’un redémarrage de cluster, le redémarrage des VMs s’effectue en mode best-effort. Le cluster Prism Element se concentre sur l’allocation rapide des ressources (CPU/RAM) et déclenche l’allumage des VMs de manière totalement asynchrone et concurrente et n’a nativement aucune conscience de vos dépendances applicatives.

Dans quels cas ces règles s’activent-elles vraiment ?

Il est important de préciser que ces stratégies ne s’appliquent pas si vous décidez de redémarrer une VM manuellement depuis l’interface de Prism Central en pleine journée. L’orchestration AHV se réveille et applique vos Startup Policies dans deux cas de figure :

1. Un événement de Haute Disponibilité (HA) : Un ou plusieurs nœuds physiques de votre cluster tombent en panne. L’hyperviseur AHV va rapatrier et redémarrer les VMs affectées sur les nœuds survivants, en respectant scrupuleusement l’ordre que vous avez défini.
2. Un redémarrage complet du cluster (Full Cluster Restart) : Exactement le cas de mon anecdote ! Suite à une coupure électrique totale par exemple.

Décryptage de la mécanique : Les 3 piliers fondamentaux

L’approche de Nutanix a le mérite d’être extrêmement visuelle et très simple à prendre en main depuis Prism Central. Elle repose sur trois concepts fondamentaux.

1. Les Catégories

La mécanique de Nutanix s’appuie exclusivement sur les Catégories de Prism Central. Vous ne liez pas « Serveur-SQL-01 » à « Serveur-Web-01 », mais vous liez la catégorie AppMetier:Database par exemple aux VMs hébergeant des bases des données et vos VMs applicatives à la catégorie AppMetier:Applicatif.

C’est ici que réside la vraie puissance de cette architecture. Si demain vous déployez trois nouveaux serveurs applicatifs en scale-out pour absorber une charge imprévue, il vous suffit de leur assigner la bonne catégorie. Ils seront automatiquement intégrés dans le bon ordre de votre Startup Policy sans que vous n’ayez à ouvrir ou modifier la moindre règle.

2. Les niveaux de dépendances

C’est grâce à ça que vous dessinez votre chaîne logique : la catégorie B ne peut démarrer que si la catégorie A a terminé. Il y a tout de même une petite subtilité à garder en tête : Nutanix autorise un maximum de 6 niveaux de dépendance consécutifs par policy. Dans 99 % des cas, c’est largement suffisant pour une application classique (ex: Infra > BDD > Web), mais cela demande de bien regrouper ses services sans faire de micro-management.

3. Les conditions de démarrage

C’est la question à un million : comment l’hyperviseur AHV sait-il que la base de données est réellement prête pour autoriser la suite ? L’outil vous propose 2 options :

• VM Power On : Dès que la VM est sous tension au niveau matériel, on lance l’étape suivante. L’OS Windows ou Linux n’est même pas encore chargé. À éviter pour des dépendances fortes.
• Guest Boot up : Le top du top ! Nutanix attend patiemment que l’OS soit complètement chargé et que la couche réseau réponde.

Pour que la condition « Guest Boot up » fonctionne, les Nutanix Guest Tools (NGT) doivent impérativement être installés et à jour sur la VM. Mon conseil (et la recommandation éditeur) : ne faites pas l’impasse sur le déploiement des NGT !

Il y a également une option qui complète l’une ou l’autre :

• Delay (Délai en secondes) : On attend « bêtement » un temps donné (ex: 60 secondes) avant de passer à la suite.

Tutoriel : créer une startup policy

Je vous propose de modéliser l’exemple le plus courant : nous voulons démarrer nos contrôleurs de domaine, attendre qu’ils soient prêts, démarrer nos bases de données, puis enfin nos serveurs applicatifs.

Pour l’occasion, j’ai créé 3 catégories : AppType:ActiveDirectory, AppMetier:Database et enfin AppMetier:Applicatif

1. Connectez-vous à Prism Central.
2. Allez dans le menu Infrastructure > Compute > VMs > Policies > VM Startup Policies.
3. Cliquez sur Create VM Startup Policy.
4. Donnez-lui un nom explicite (ex: Policy-Tiering-Metier).
5. Dans l’interface visuelle, ajoutez votre première catégorie (ex: AppType:ActiveDirectory).
6. Ajoutez un second bloc pour AppMetier:Database et un troisième pour AppMetier:Applicatif.
7. Cliquez sur + Configure Start Conditions pour définir les conditions de démarrage. Choisissez Guest Boot up et ajoutez éventuellement un délai de sécurité de 30 secondes pour laisser le temps aux services internes de l’OS de bien s’initialiser.

Cliquez sur “Create”, et le tour est joué !

Il ne vous restera plus qu’à ajouter vos VMs aux bonnes catégories.

Les pièges à éviter

L’outil est formidable, mais voici 3 retours terrains pour vous éviter de tomber dans certains pièges :

1. Gérer la limite des 6 niveaux intelligemment

Ne tombez pas dans le piège du micro-management ! Si vous essayez de faire une policy pour chaque micro-application, vous allez vite saturer l’interface, atteindre la fameuse limite des 6 niveaux et vous retrouver avec une usine à gaz impossible à maintenir dans le temps. Groupez intelligemment vos ressources et faites simple !

2. Attention à l’interaction avec les mécanismes de PRA

Les Startup Policies gèrent la résilience locale d’un cluster (HA ou reboot). Mais attention, si vous utilisez Nutanix Disaster Recovery pour basculer vers un site distant, ce système a son propre mécanisme de plans de reprise. Lors d’un failover inter-sites, c’est le Recovery Plan de Prism Central qui prend la main sur l’ordre de démarrage, et non plus votre Startup Policy locale. Veillez donc à maintenir une cohérence logique entre les deux outils.

3. Cela ne concerne que les VMs invitées

Inutile d’essayer de séquencer les VMs “Nutanix” (Prism Central, CVM, ou autres…), cela ne fonctionnera pas. Le mécanisme n’est applicable que sur vos machines virtuelles, pas celles du système.

Conclusion

Les VM Startup Policies sur Nutanix AHV sont le genre de fonctionnalité que l’on configure une fois, que l’on oublie, et qui peuvent faire gagner un temps et une sérénité précieux le jour où l’impensable se produit. Grâce à une interface visuelle intuitive basée sur des catégories, Nutanix a rendu la résilience applicative accessible à tous.

Si ce n’est pas déjà fait, je vous invite vivement à vérifier l’état de vos NGT (état de déploiement et versions) et à catégoriser vos VMs les plus critiques dès aujourd’hui. Votre futur « vous », réveillé à 3h du matin lors du prochain incident de prod, vous remerciera !