Vous l’attendiez tous, la voilà, la fameuse explication de nos problèmes de backups sur notre production NSX-T ! Il aura fallut du temps et de l’énergie, autant de notre coté que de celui de VMware, pour mettre le doigt sur la source de nos misères. Toute la lumière dans ce billet !

Rappel des faits sur le mois de Juin

Je ne vais pas reprendre en détail le déroulement de ce mois d’investigation, car j’en est déjà parlé lors d’un précédent billet (voir ici), mais voila en somme ce qui s’est passé entre le 4 Juin et le 1er Juillet.
– Les 03-04 Juin : déroulement du cahier de test, qui se termine par une restauration complète de l’environnement (kit de survie)
– Le 07 Juin : on se rend compte que le backup programmé ne fonctionne plus et termine systématiquement en erreur. Date du dernier backup complet, le 4 Juin.
– Entre le 08 Juin et le 17 Juin dernier : nombreux tests de restauration et investigation locale (avec le groupe projet) sans succès
– 14 Juin : Ouverture du SR sur les conseils de David, notre VTAM
– Les 17-18 Juin : travail avec le support et le groupe projet durant quasi 2 jours plein, sans arriver à trouver une solution
– Entre le 19 et le 24 Juin : toujours des échanges avec le support, sans grande avancée
– Le 29 Juin, retour du support indiquant que le SR (déjà escaladé depuis quelques temps à l’ingeenering ) avec des demandes plus précises se focalisant sur la base de données de gestion du cluster NSX-T, corfuDB (open source, pour ceux qui sont intéressés). Nous devions tenter de supprimer la liaison AD-NSX qui nous permet en théorie d’utiliser des règles dite “identity-based firewall rules” pour autoriser ou pas certains users AD à certaines ressources (voir ici). Souvent utilisé dans des environnements VDI, nous l’avions mise en place en toute fin d’implémentation, pour le cas où. Ce n’était pas très important de toutes façons chez nous, elle ne faisait pas partie de notre cahier des charges. Apparemment, cette liaison générait, dans notre cas, des centaines de milliers d’enregistrements, provoquant du même coup des temps de dump dépassant les timeouts du script de backup. Nous avions une piste ! Pour autant, a l’issue de celle-ci, le backup tombe toujours en erreur…

Résolution de l’incident, le 1er Juillet

Au final, le 1er Juillet David, l’engeenering et moi-même réalisont une purge de deux tables particulières de la base de donnée directement via des outils de gestion BDD. En effet, il semble que le script sensé purger la base des enregistrements suite à la suppression du lien AD-NSX n’ai pas fonctionné correctement… et, MIRACLE, BONHEUR ET FELICITE, le backup fonctionne !

Petite analyse de fond

Quand vous établissez une liaison AD-NSX, le cluster de management va “aspirer” les Users et les Groupes AD, mais aussi leurs liens entre eux : qui est membre de quoi. Sauf que dans notre cas, si nous ne possédons pas tant de User/Groupes que cela (26k Users contre environ 20k groupes), nous sommes visiblement assez spécifique concernant nos nombreuses liaisons entre eux (certains Users peuvent appartenir à plusieurs dizaines de groupes, facilement). Au final, cela a généré des dizaines de miliers d’enregistrements dans la base corfuDB qui aujourd’hui est protégée avec des limites non suffisantes pour nous …

Résultat, les limites imposées ajoutées aux timeout de backup, sans doute trop optimistes conduisaient à une erreur systématique. Je ne peux pas vous en dire plus aujourd’hui publiquement, mais sachez que ces limites étaient déjà en cours de révision avant notre escalade et qu’elles seront certainement levées dans les prochaines releases … 2.5 annoncée cet été, 3.0, là je ne sais pas du tout, mais en tout cas c’est dans la to-do-list !

Au final, nous avons joué de malchance en ayant un AD particulièrement fourni en hiérarchie (historiquement lié à notre méta-annuaire interne) et un temps de sauvegarde juste hors limite de temps … On peut malgré tout se consoler en se disant qu’on a un peu essuyé les plâtres pour vous et que cela ne se reproduira sans doute plus, la connaissance ayant progressé :)

Et, au fait…. du coup, GO PROD sur NSX-T 2.4.1 durant les prochains jours !
Chouette :)

PS: Grand merci à toutes les personnes ayant contribué à résoudre ce problème :
Côté VMware : Sirisha, Pavan, Houssem, David, Matthieu
Côté Axians : Mikael, Nicolas
De notre côté : Antoine