La (vraie) recette du stretched cluster avec VMware HA
Posted by NiTRo | Filed under HowTo, Tips & Tricks, VMware
Le stretched cluster c’est un peu l’ultime fantasme de tous les admin VMware car il permet de couvrir le crash d’un serveur ou d’un site avec un seul et même design.
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.
Loading ...
September 29th, 2013 at 21:06
Juste impeccable NiTRo
L’ESX helper pourrait même être un vESX, dont c’est l’unique fonction.
September 29th, 2013 at 21:32
Content que ça te plaise Benoit!
Très bonne idée sur du NFS ou iSCSI par contre FC ou infiniband ça risque d’être plus compliqué
October 31st, 2013 at 17:33
Pour info et compléter votre très intéressante analyse, à propos d’autres technos de continuité d’accès au stockage VMWare. J’ai plusieurs infra en production de type VMWare Metro Storage Cluster sur des socles Datacore ou 3Par Peer Persistence et ce problème de failback ne s’est pas présenté durant les recettes ou tests programmés, la resynchronisation des volumes est une tâche d’arrière plan et le mécanisme de redondance d’accès étant fondé sur le MPIO et surtout l’ALUA, les chemins du site primaire redeviennent actif une fois les volumes resynchronisés (et healthy), côté VMWare il s’agit du même Datastore de toute façon. De plus, pour la configuration des banques de pulsation HA, j’utilise à minima deux datastore dédiés (tout petit), dont un primaire sur chaque site, cela évite la double modification d’un volume VMFS (par l’agent HA) où résident des VM lors de micro coupures ou split-brain passagers qui ont une durée inférieure au seuil de basculement des différentes couches (ca peut résulter en double failure du LUN sur certaines technos de miroring).
Attention, avis perso: pour le moment, je dois avouer que la solution 3Par (avec le Port persistence de surcroît) est vraiment celle que je trouve la plus simple et efficace pour les environnement VMWare en géo cluster, pas besoin d’équipements supplémentaires (type vplex) car tout est géré par les contrôleurs des baies (hormis le nœud votant indispensable pour éviter le split brain, mais c’est une VM rikiki).
Très bon post…comme toujours ici.
Bon week end
November 4th, 2013 at 18:36
Merci pour votre commentaire Eric.
Si je comprend bien, tant que la resyncro n’est pas terminée, c’est l’ISL qui est utilisé pour accéder aux data ?
Et une fois la resyncro terminée, le switch est vraiment seamless ?
November 6th, 2013 at 10:19
C’est exactement cela, total seamless, à l’aller et au retour. Plus l’infra est conséquente, plus on trunk sur l’ISL pour garantir un bon niveau d’accès durant la perte d’une baie
Pour Datacore c’est assez simple car chaque nœud correspond en fait à un contrôleur d’une baie virtuelle qui serait à cheval sur les deux sites. Des que la resynchro est finie, le chemin passe de dead à healthy.
Pour 3Par,les deux baies utilisent L’ALUA sur des volumes communs (du point de vue des ESXi c’est la même baie avec plusieurs chemin alternatifs pour accéder au LUN, certains actifs et d’autre standby, en fonction de là ou l’on se trouve). Il y a aussi une techno qui permet de ne pas déclencher le MPIO pour éviter que les flux des hôtes basculent quand un controleur d’une baie tombe en panne ou subit une maintenance. le controleur restant prend possession des WWN du controleur absent à la volée.. il faut y penser lors du zonning !
Vous pouvez jouer avec l’appliance iSCSi HP StoreVirtual (VSA) il y a une version demo. Avec elle vous pouvez faire exactement la même chose en créant des volumes en network RAID10. Là aussi les aller/retour sont seamless, y compris lorsqu’il faut resynchroniser les volumes.
November 14th, 2013 at 23:27
Pour les tests de ce genre, nous utilisons QUADStor qui permet de nombreux scénarios.
Merci pour ces infos Eric !
November 26th, 2013 at 12:39
[...] ceux qui auraient besoin d’expliquer à leur DSI le design que nous avons détaillé dans notre précédent post, voici le fichier powerpoint (avec les commentaires) qui vous [...]
December 3rd, 2013 at 9:31
[...] le setupage du premier super stretched cluster maison en production avec notre cher confrère vmdude.fr, ce dernier a émis une judicieuse remarque sur [...]