Malheureusement, si vous ne voulez pas investir dans une solution telle que SRM, Zerto ou VPLEX ou encore si vous aspirez à plus de simplicité, le failback des VM peut rapidement se transformer en cauchemar (register de vmx à la main par exemple). En effet, depuis vSphere 5.0, HA (aka FDM) est capable à lui seul d’assurer le redémarrage des VM (failover) dans un stretched cluster tant que le stockage d’un site est répliqué sur l’autre site et présenté aux ESX après un crash (extrais tiré de VMware vSphere 5 Clustering Technical Deepdive) :

The master [agent] will also attempt to take ownership of any datastores it discovers along the way, and it will periodically retry any it could not take ownership of previously.

Il est donc possible d’envisager un cluster étendu sur 2 sites où HA serait capable de redémarrer les VM d’un site crashé après une simple manipulation coté stockage. Après de nombreux tests, il s’avère que cette solution est parfaitement fonctionnelle mais elle souffre néanmoins d’un gros problème : le failback. En effet, lorsqu’il est question de renvoyer les VM sur leur site initial, il est nécessaire d’arrêter les VM pour re-synchroniser le stockage et redémarrer les VM sur le site primaire. Lors de cette opération, on se retrouve inévitablement confronté à des VM “inaccessible” :

A partir de ce moment, il n’est plus possible de faire autre chose que d’enregistrer les VM manuellement sur un des ESX (directement) du site primaire et laisser l’agent vpx faire le reste. Evidemment, c’est l’un des pires scénarios mais il existe des solutions comme celle de faire un storage vmotion pour déplacer les VM sur un autre espace de stockage avant de faire les opérations sur les baies mais bien qu’il soit possible de faire le failback à chaud dans ce cas, il faut prévoir un espace supplémentaire non négligeable et trop de manipulations à nos yeux.

Après avoir travaillé un certain temps sur le sujet avec notre ami vmdude.fr, nous avons trouvé LA solution la plus élégante pour qu’un passage en production soit envisageable. Elle nécessite quelques manipulations simples et parfaitement scriptables. A vrai dire, la solution était sous notre nez depuis le début et existe depuis longtemps car utilisé dans un autre cas de figure. Il y a même de forte chance pour que vous vous en soyez déjà servi une fois… Lorsqu’une VM est configurée pour ne pas être redémarrée par HA, elle apparaît comme “disconnected” tant que l’ESX n’est pas redémarré (lui aussi est “disconnected” d’ailleurs “not responding”) et dans cet état, vous pouvez démarrer cette VM car vcenter va automatiquement enregistrer la VM ailleurs alors qu’il ne peut plus communiquer avec l’ESX pour “unregister” la VM. Nous avons donc utiliser cette fonctionnalité pour “cacher” au vcenter les manipulations de stockage en regroupant les VM sur un ESX que l’on déconnectera avant. Ouvrez grand les yeux :

La liste des commandes PowerCLI utilisées est disponible ici, elles doivent évidement être modifiées pour correspondre à votre environnement (nom de cluster, ESX et resource pool). Voici un récapitulatif des étapes post crash :

• <==failover==>
• présentation du stockage aux ESX
• montage des snapshot VMFS ou des shares NFS
• <==failback==>
• shutdown des VM
• move des VM sur l’ESX helper
• enter maintenance mode de l’ESX helper
• disconnect de l’ESX helper
• *disable SIOC*
• démontage des snapshot VMFS (ou des share NFS)
• failover du stockage
• Power on des VM
• reconnect de l’ESX helper
• exit maintenance mode de l’ESX helper

Une autre solution consiste à présenter un petit espace temporairement à tous les ESX (un share NFS est ideal dans ce cas) afin d’y déplacer uniquement la “home” de la VM (vmx, log, etc…) avec un svmotion scripté afin d’éviter l’état “inaccessible” et pouvoir facilement redémarrer les VM après la re-synchronisation du stockage. L’avantage est qu’il n’est pas nécessaire de “sacrifier” un ESX mais cela rajoute des manipulations au PRA et un espace de stockage à gérer en plus.