En ce moment, le sort s’acharne sur notre belle production :(
Après une coupure de 3 fibres noires sur 4 (ouf !) fin Mai pendant plusieurs heures entraînant de nombreuses perturbations, voici que ce midi même, une de nos salle informatique a perdu ses deux alimentations électriques simultanément ! Toute la salle s’est donc retrouvée dans le “noir” pendant environ 10 minutes. L’effet fut immédiat sur l’ensemble de nos infrastructures : une bascule PRA en bonne et due forme. Certes, nous effectuons des campagnes de test et d’entretien régulières de nombreux composants servant de support à ces situations d’urgence, mais jamais tous en même temps (réseau, fibre channel, serveurs et baies). Un élément extérieur nous en a donc donné l’occasion, bien malgré nous !
Sans rentrer dans le détail des causes réelles de cette double rupture d’alimentation et du déroulement global des opérations, sachez finalement que le PRA s’est bien déroulé et en moins d’une heure, une grande partie de la production avait automatiquement déménagée sur notre salle restante. Notre bien-aimé VPlex a lui aussi parfaitement joué son rôle (oserais-je dire comme d’habitude … oui, j’ose !) et son witness a choisi le bon cluster sur lequel maintenir les I/O. Malgré tout, je vous en reparlerai spécifiquement dans un prochain billet : le cluster ayant perdu ses alimentations n’a pas redémarré automatiquement et il a fallu relancer les directeurs “à la main” pour récupérer notre VPlex Metro en nominal.
Coté VMWare aussi, nous avons subit un déclenchement HA massif de la moitié de nos VM (car nous avons de-facto perdu la moitié des ESXi de nos stretched clusters !). Pour autant, nous étions dubitatif sur quelques dizaines de VM (sur un peu plus de 1000 aujourd’hui) : en effet, nous pensions qu’elles seraient redémarrées comme les autres, sur les serveurs ESXi restants, mais ce ne fut pas le cas. Nous les avons retrouvées éteintes sur les ESXi initiaux sur lesquelles elles tournaient avant la coupure. J’ai donc repris la bonne vieille méthode du RTFM (Read The Fucking Manual) au sujet du comportement de HA et DRS pour essayer de comprendre.
Et c’est là que j’ai retrouvé des informations cruciales au sujet du comportement de HA/DRS. Il arrive régulièrement que nous utilisions des règles DRS permettant de forcer le fonctionnement de VM sur des salles spécifiques : c’est quasiment tout le temps le cas lorsque plusieurs VM délivrent un service global et se backup l’une l’autre. On peut citer chez nous : nos DNS, nos serveurs DHCP, nos serveurs Exchange 2013, nos serveurs d’équilibrage XenApp, nos cellules vCloud Director etc, etc. … Nous étions passé à coté d’une subtilité lors de la construction des groupes DRS. Lorsque vous voulez indiquer qu’une VM doit tourner sur un certain nombre de serveurs (situés sur une salle spécifique, par exemple), vous avez deux règlages différents : “VM Must run on hosts in group” et “VM should run on hosts in group”. La différence est subtile, mais elle a un impact important en cas de HA, précisément : dans le premier cas “Must run”, HA ne redémarre PAS les VM concernées alors que dans le second “Should run”, HA s’en occupe et accepte de déroger à cette règle plus souple.
Nous tenions notre explication : toutes les VM qui n’ont pas redémarré, sans exception, étaient membre d’un groupe DRS où la règle du “must run” était appliquée.
Comme quoi, même les pires incidents de production sont toujours source d’enrichissement et d’amélioration de la robustesse des infrastructures !