… ben ça veut pas ! Contrairement à ce que nous espérions, nous ne sommes toujours pas officiellement en production sur notre nouvelle architecture NSX-T (dont j’ai looonguement parlé depuis plus de 3/4 mois). Vraiment désolé pour ceux que ça n’intéresse pas, au passage, mais c’est vrai que c’est un peu le centre de mes préoccupations en ce moment. D’autant que “les clients attendent” pendant ce temps là. Ce n’est pas comme si nous nous engagions dans la virtualisation de réseau pour les dix prochaines années …

Cette fois-ci, petit retour sur notre campagne de tests unitaires et tests d’intégration depuis le tout début de ce mois de Juin.

Des débuts prometteurs

Nous avons commencé cette campagne de tests de la nouvelle infrastructure NSX-T en nous appuyant sur le document “Test Plan” fourni par l’équipe projet VMware qui est particulièrement exhaustif. Nous avions également demandé l’aide d’Axians, notre partenaire dans ce projet, de nous aider aussi pour cette partie : toutes les compétences étaient là pour un maximum d’efficacité (VMware, Axians, nous). Durant les 3 et 4 Juin derniers, tous les éléments actifs de NSX-T ont été testés avec succès et ont permis de corriger quelques coquilles dans la phase d’implémentation (c’est le but aussi, en même temps). Pas de problème particulier donc, mais la dernière séquence était la plus critique : réaliser un backup ainsi qu’un test complet de restauration.

NDLR : Tiens, d’ailleurs, si vous avez déjà tenté un test complèt de restauration d’une infra vSphere (vCenter, vROps + un petit NSX-V dessus par exemple) ? Non ? Oui ? je suis curieux d’avoir vos retours là dessus, n’hésitez pas à me contacter, qu’on se prépare un RETEX sur vBlog !

Le principe consiste à casser complètement les 3 VMs NSX Manager (avec NSX controlers intégrés, depuis NSX-T 2.4), puis dérouler “la procédure” pour reconstruire entièrement le cluster de management à partir du dernier backup. Sans rentrer trop dans le détail, nous sommes arrivés à nos fins ! Mais il est vrai que la doc officielle de restauration ne semblait pas encore totalement “sêche” car il aura fallut s’y reprendre à deux fois dans la reconstruction des VMs. La principal difficultés réside dans le fait qu’il faut re-générer le premier NSX Manager et lui donner l’ip de celui qui a fait le backup (c’est indiqué dans le nom du répertoire de sauvegarde, sur le repo sftp indiqué lors du backup). Ensuite, le process se déroule sans trop de problème.

Nous avons malgré tout noté que les certificats SSL (qui nous ont déjà posé des petits soucis, voir mes articles précédents) ne sont pas ré-implantés correctement, en tout cas dans notre version 2.4.1. Nous avons du les ré-activer sur les bons éléments via l’API ReST.

Au final, cette première phase a été un succès et nous étions confiants pour la suite !

Des lendemains qui déchantent

Sauf que. Nous nous sommes rendus compte le lendemain que … les backups automatiques ne marchaient plus ! Certes, la resto avait fonctionnée, ça oui. Mais on ne pouvait plus sauvegarder ensuite… un peu ballot ^^

S’en est suivi pas mal de discussions, l’ouverture d’un SR spécifique pour ce problème puis de nombreuses recherches dans les logs NSX-T, sans beaucoup de succès et d’avancées au final. Entre temps j’avais planifié bien en avance un “request for change” (oui, ça fait riche, mais bon, tout le monde parle anglais maintenant, dans les process ITIL/ISO) pour déclarer NSX-T bon pour le service et le passer officiellement en production. Bien évidemment, avec cet incident de dernière minute, impossible d’avoir un Go en l’état. Il fallait se rendre à l’évidence : tant que la sauvegarde NSX-T n’est pas fiabilisée, point de montée en charge.

Les jours s’égrainants comme les grains de sable dans une clepsydre et pas vraiment d’infos de la hotline, il fallait tenter quelque chose. Et si la restauration s’était mal passée, pour une raison ou une autre ? Ca vallait le coup de retenter cette procédure, pour être sûr que nous n’avions pas loupé quelque chose la première fois. Et … magique, nous avions retrouvé nos backups ! Tout le monde sautait de joie, c’était l’allégresse, les embrassades, les chiens et chats dormaient ensemble … on était content quoi ^^

Oui mais non

… comme toujours, Murphy tout ça … c’était trop beau. Après quelques backups réussis, le “machin” est retombé en panne le soir même et nous étions revenu à la case départ ou presque. Rien à faire, sans cette fichue sauvegarde, pas question de démarrer.

Nous en sommes là, ce 19 Juin, et nous attendons maintenant que les ingénieurs de VMware nous trouvent des solutions. A certains moments, l’envie m’a pris de faire un “Rognotudju” à ce sujet (pour ceux qui sont nouveaux, faites un petit tour dans la section “coups de gueule” ^^). Mais, finalement, non. Après-tout, les tests sont là pour cela, c’est juste que le temps passe vite, que nos échéances de livraison sont complexes à repousser aujourd’hui … et surtout, que c’est extrêmement frustrant d’être bloqué “seulement” pour un souci de backup !

Je vous tiens au courant dès qu’on voit l’éclaircie arriver…
En attendant, je me consolerai au Hellfest 2019 ce week-end, BIEN ENTENDU !!