Quand vCenter Inventory Service déraille …

Une fois n’est pas coutume, je vous propose un petit “débrieffing” d’une belle frayeur qui vient de nous arriver (aujourd’hui même, en fait) sur notre vCenter de production. Nous avons procédé il y a quelques semaines à sa mise à jour en 5.5 “update 2”, cette maintenance sortie début Septembre dernier. Jusque là, pas d’ennui particulier avec cette version, plutôt stable.

Et puis, il y a eu la nuit dernière. Vers 19h30, le fameux (mais assez obscure avant ce jour) service vCenter Inventory Service s’est mis à dérailler et produire des Go de logs de transaction. Malheureusement, ce soir, nous ne savons toujours pas ce qui a causé cet emballement, mais les investigations ne sont pas encore terminées… par contre, nous en avons subit les effets durant toute la journée ! En effet, à force de remplir le disque sur lequel était installé ce module de vCenter, il l’a saturé, vers 4h du matin après avoir généré plus de 55 Go, tout de même. Comme toujours dans ces moments là, on peste sur les choix effectués lors de l’installation, car bien entendu, le disque en question était le disque C: du Windows 2008R2 hébergeant notre instance vCenter. La saturation a entrainé dans sa chute l’ensemble des services et vCenter est donc tombé, peu de temps après 4h.

Vous le savez sans doute si vous êtes administrateurs d’ensemble virtualisés VMWare, une perte de vCenter n’est pas “problématique en soit” pour une production, heureusement. Notre équipe de MCO embauchant à 6h du matin, elle a tout de suite constaté le problème et a tenté de redémarrer la machine, sans succès bien entendu. Le Windows démarrait, mais guère plus.

Je ne vais pas m’étendre sur le déroulement de la journée – assez éprouvante – que nous avons passé, avec le support VMWare, pour finalement relancer notre principal outil de production (90% de nos applications sont virtualisées). Par contre, je peux vous dresser le bilan de ce gros incident et les nombreuses conclusions que nous en avons tiré. En effet, de mon point de vue, un problème de ce type est TOUJOURS l’occasion d’apprendre et d’améliorer la robustesse de nos infrastructures, a posteriori. C’est un mal pour un bien, en quelque sorte.

Première conclusion : il faut absolument porter une attention toute particulière à la sauvegarde régulière et au fonctionnement général du service “Inventory”. On pourrait penser en première approximation que l’ensemble de la configuration se trouve dans la base de données sur lequel vCenter est connecté, mais ce n’est pas le cas. En particulier, la partie “tag” et “policies” est en partie hébergée par le service d’inventaire et la perte de celui-ci entraine à coup sûr une perte de ces métadonnées. En environnement “full vCenter” ce n’est pas crucial (au pire vous perdez les tags que vous avez pu poser sur divers éléments de l’infrastructure virtuelle), mais dès que vous commencez à manipuler les storage policies notamment avec vCloud Director, cet élément est critique et il DOIT être sauvegardé régulièrement.

Deuxième conclusion : il est très confortable de sauvegarder une VM via un système intégré comme Veeam ou Avamar et c’est évidemment une fonction importante au quotidien, mais lorsque c’est précisément la VM de vCenter que vous voulez restaurer … vous êtes dans une boucle sans fin : il vous faut un vCenter opérationnel pour restaurer une VM avec ces outils, mais le vCenter est cassé. En conclusion, pour vCenter, pensez à faire d’autres type de sauvegarde plus classique, plus “oldschool” serais-je tenté de dire, pour le cas où. Un “system state” sous Windows ou même un clone de VM hebdomadaire sur un ESXi bien identifié.

Troisième conclusion : quand un système met du temps à démarrer mais “ne plante pas”, laissez lui le temps de se remettre en ordre ! Lorsque nous avons constaté que vCenter ne démarrait plus ce matin, nous avons essayé plusieurs fois (avec VMWare aussi, au passage) de lancer les services les uns après les autres, avant d’identifier le fautif. Inventory service se lançait, mais ne nous rendait pas la main dans un délai que nous estimions raisonnable (une quinzaine de minutes tout de même). Au bout de ce temps d’attente (les minutes sont longues à ces moments là ;) ), en désespoir de cause nous cassions le processus et tentions tout de suite d’autres approches. Après de longues heures d’investigation nous sommes finalement arrivés à la conclusion que le service d’inventaire n’était pas planté, il prenait juste BEAUCOUP de temps à démarrer. Et pour cause : rappelez-vous qu’il avait généré dans la nuit environ 55 Go de log… malgré XtremIO et des CPUs performants, il à fallu du temps au logiciel pour passer en revue ses transactions, les purger et enfin démarrer. Plus exactement, c’est au bout d’une heure environ que le service a fini par démarrer et éradiquer du même coup les 55 Go.

Quatrième conclusion : il est vraiment temps de nous occuper de vCenter et refondre son architecture actuelle, relativement basique. Il va falloir du temps pour construire un environnement vraiment redondant et réparti (séparation des services sur plusieurs VM, mise en place, sans doute, d’un cluster ESXi dédié pour cet ensemble, etc. …). Il va falloir nous atteler à faire des tests de restauration COMPLETs de nos vCenters, voir d’un test de ré-installation à partir d’un kit de survie digne de ce nom. Pas une mince affaire !

Enfin, pour terminer sur une note plus technique, sachez que Inventory Service est une brique relativement simple à sauvegarder (des scripts de backup/restauration sont disponibles directement dans le répertoire “scripts” de l’installation) et ne pèse que quelques Go en tout. Donc, la première chose à faire dès demain, messieurs les virtual-admins : faite des backups réguliers de votre base “Inventory” et mettez là de coté, en dehors des outils de sauvegarde “VM”, pour pouvoir aller les chercher très facilement en cas de besoin ! Au passage, faites-en aussi pour tous les certificats SSL et autres fichiers de configuration disséminés sur les briques de vCenter. Il existe plusieurs KB qui traitent de ces aspects spécifiques.