Mise à jour de vCNS vers NSX Manager : des Edge Gateways récalcitrantes

Il y a quelques semaines, je vous avais présenté la migration d’une appliance vShield Manager vers NSX Manager (voir ce billet). A l’époque, je n’avais pas décelé de problème particulier, tout s’était bien déroulé, autant sur notre bac à sable que sur la production … sauf que, depuis, nous avons constaté un problème post-update qui affectait certaines Edges Gateways déployées via vCloud Director.

Petit résumé du souci rencontré et de la solution trouvée pour y remédier.

Quel est donc le problème ?

En fait, une fois mis à jour réalisée, tout semblait fonctionner parfaitement, pas d’alertes, pas de problèmes de connectivité. Par contre, certaines Edges Gateways déployées n’étaient plus manageables via l’interface vCD. Voici l’écran “classique” d’un menu contextuel de Edge Gateway fonctionnelle :


… et voici comment apparaissaient certaines Edges, après la mise à jour :

Comme vous le voyez, on a un léger souci, impossible de gérer les services associés. Evidemment, la première chose que l’on a tenté, sur certains environnements non critiques, c’est de redéployer celles-ci, étant donné que c’était la seule option disponible via vCloud. Malheureusement, on obtenait à chaque fois une fin de non recevoir avec beau un message d’erreur comme seul vCD peut vous en présenter, nous signifiant en gros que l’ID de vm correspondante était invalide.

Panique à bord, évidemment, car malgré le redémarrage en règle des divers appliances et composants participant à l’opération (NSX Manager, vCloud Director et même le vCenter), on obtenait pas plus de succès. Alors, certes, il n’y avait aucun impact production, mais impossible de modifier quelque règle que ce soit. Il faut noter que malgré tout, cela se produisait exclusivement sur des Edges Gateways déjà déployées AVANT la mise à jour de vCNS vers NSX. En effet, si l’on tentait le déploiement d’une nouvelle gateway, pas de souci, l’opération de création se passait bien et les opérations de modification ultérieures étaient parfaitement intégrées et réalisées par vCloud.

Nous avions donc affaire à un bug de migration et avons dans la foulée contacté VMware (après les nombreux googlages de rigueur ^^). Après analyse, le support nous a confirmé que cela “pouvait” se produire dans certains cas (plus de la moitié de nos Edges étaient en vrac tout de même … effectivement, ça pouvait se produire ^^). La solution proposée était de forcer le redéploiement complet de chaque edge affectée par le problème non pas depuis l’interface vCloud, mais directement depuis le gestionnaire NSX (dans l’onglet Network & Security du Web client). Et, en effet, après cela, les gateways étaient à nouveau totalement reconnues et gérées à travers vCloud.

Evidemment, il nous a fallu un peu de temps pour réaliser les correctifs nécessaires, car il nous avons du planifier ces opérations avec nos hébergés et les équipes projets pour nos infrastructures internes, du fait de l’aspect disruptif du redéploiement (on “perd” la connectivité assurée par la EG pendant quelques secondes, voir quelques dizaines dans le pire des cas).

A priori, la “root cause” est effectivement un bug pendant la phase de mise à jour de la base de données des Edges, qui “perd” des ID de Gateways. Je n’ai pas pu en apprendre d’avantage jusqu’à présent, mais je vais scruter les releases notes de NSX à la recherche de références à ce type de dysfonctionnement.

Au final, plus de peur que de mal, mais tout de même du travail de planification pour retourner en nominal, surtout si vous disposez de plusieurs dizaines/centaines de Edges Gateway ! Pensez-y si vous vous lancez dans cette mise à jour ;)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *