Vous avez un projet ?
Temps de lecture 6 minutes

Cloud Provider : A vos marques, prêts, feu … migrez !

Publié le 5 June 2021
scroll
N’oubliez pas
de partager
cet article

NSX Never dies

NSX nerver dies mais quand même … À partir du 16 janvier 2023, NSX-V mourra de sa belle vie. Mais attention, à compter du 16 janvier 2022 : plus aucun patch de sécurité ou de correction de bug, plus de ticket au support pour une sévérité élevée. La fin de support de NSX-V approche à grand pas. Difficile d’avaler la pilule pour tous les Cloud Providers (et pas qu’eux d’ailleurs) qui ont investi dessus notamment avec VMware Cloud Director pour fournir une offre IaaS.

NSX-V est mort (enfin presque), vive NSX-T ! Car oui, depuis la version 9.7, VMware Cloud Director est compatible avec NSX-T, le successeur de NSX-V. Et même si ce sont deux produits totalement différents, ils remplissent la même fonction pour VMware Cloud Director (VCD) : fournir la couche SDN[1] du SDDC[2].

Comment migrer ?

Plusieurs options s’offrent à vous pour migrer vers NSX-T. Toutes ne se valent pas. La première c’est de ne pas migrer du tout… On fait coexister les deux infrastructures (V et T) en faisant en sorte que les nouveaux clients arrivent sur une offre de service sous NSX-T. Les anciens clients restent sous NSX-V jusqu’à ce que leur offre de service expire.

Ce n’est franchement pas la meilleure idée car cela fait prendre un risque à tout le monde, Provider comme client (pas de support = risque) et à un moment il faudra bien migrer (véritablement). Voici donc deux autres méthodes :

  • NSX-T Datacenter Migration Coordinator. C’est un outil natif à NSX-T depuis la version 2.4. Il fait très bien le travail dès lors qu’il n’y a pas de VMware Cloud Director qui pilote NSX-V et NSX-T. Cela va rompre toutes les liaisons avec VCD sans retour arrière possible. Si vous avez un VCD, passez votre chemin !
  • Autre méthode : le « Lift & Shit ». On crée une infrastructure sous NSX-T juste à côté de celle sous NSX-V et on y calque la configuration du NSX-V. Cette étape de configuration se fait à la main et par script. S’il y a peu de clients cela reste gérable même à la main. Mais le risque d’erreur reste important. Mais si on parle d’un environnement plus conséquent ça risque de devenir une horreur à reconfigurer ou à scripter pour prendre en compte chaque spécificité.

Et pour ceux qui ne veulent pas prendre de risque, automatiser leur migration, qui veulent pouvoir faire un retour arrière et qui ont une infrastructure avec plus de trois ou quatre clients ? Il existe une quatrième option : « NSX Migration for VMware Cloud Director Tool ».

Cet outil permet de migrer un par un chaque Organization VDC[3] vers un nouveau Provider VDC sous NSX-T. On garde ainsi la même topologie réseau et les services sont redéployés (Distributed Firewall sur NSX-T, Load Balancer sous AVI…). L’outil permet de disposer d’une fonction d’évaluation permettant de valider les prérequis avant de démarrer la migration ainsi que d’une fonction de retour arrière qui peut désormais être appelée à n’importe quelle étape du processus de migration.

Bien, maintenant que nous avons une base d’informations pour choisir la méthode de migration, êtes-vous prêt à avaler cette pilule et entrer plus profondément dans « NSX Migration for VMware Cloud Director Tool » ?!

NSX Migration for VMware Cloud Director Tool

L’outil se présente sous la forme d’une CLI (en python) à installer sur un poste d’administrateur (Linux ou Windows) ayant accès au vCenter, à NSX-T et à VMware Cloud Director évidement. Il utilise les APIs pour communiquer avec chacun de ces composants.

Il supporte bon nombre de topologies/fonctions réseau comme :

  • Les VRF comme Externel Network (tout comme les T0)
  • Plusieurs External Network
  • Plusieurs Edge Gateway
  • Les réseaux « Direct Connect »
  • Du DHCP sur un réseau (Isolated, Routed ou en Direct Connect)

Je vous invite tout de même à lire le User Guide de la dernière version pour y consulter la liste des fonctions et des services sur les Edge Gateway que l’outil ne sait pas traiter.

Notez que l’outil a un très bon cycle de développement. C’est sa quatrième version depuis Avril 2020 et le cycle de mise à jour est décorrélé de celui de VMware Cloud Director ou NSX-T. VMware a donc clairement l’intention de faire vivre cet outil afin de réduire au maximum cette liste de fonctions encore non supportées.

Pour récupérer l’outil, il faut le télécharger dans la section « Drivers & Tools » de la page de téléchargement de VMware Cloud Director.

Vous y trouvez le User Guide, la Release Note et les fichiers d’installation pour Linux ou Windows.

Vérifiez tout de même au préalable votre matrice d’interopérabilité avec les différents produits. Une mise à jour d’un des composants sera peut-être nécessaire car cette matrice est une véritable passoire (même si ça va déjà mieux en version 1.2.1).

Une fois téléchargés et décompressés, vous trouverez deux fichiers YAML :

  • yml : qui permet de renseigner les informations nécessaires à l’évaluation (à minima l’URL et identifiants du VCD)
  • yml : qui permet renseigner les paramètres nécessaires pour les Precheck, la migration, le Cleanup ou le Rollback

Vous pouvez récupérer toutes les opérations réalisables avec l’outil à l’aide de la commande vcdNSXMigrator –help :

  • –filepath : pour renseigner le chemin d’accès au fichier YAML. Si aucun autre commutateur n’est utilisé, cela démarre l’opération de migration.
  • –v2tAssessment : pour réaliser l’évaluation de l’environnement et connaitre la masse de travail à fournir avant d’initier une migration. Ce mode n’a besoin que de la connexion vers VMware Cloud Director.
  • –preChek : pour vérifier la faisabilité de la migration (vérification de l’ensemble des composants source et cible).
  • –CleanUp : pour initier la phase de CleanUP
  • –Rollback : pour réaliser un RollBack

Le mode Assessment

Vous pouvez utiliser la ligne de commande vcdNSXMigrator –v2tAssessment sans même que NSX-T ne soit déployé. Ce mode permet de parcourir tout ou partie de l’environnement VMware Cloud Director et d’en sortir un rapport d’audit pour évaluer les opérations à réaliser avant même d’envisager la migration. Le résultat de l’opération génère deux fichiers d’informations plus ou moins détaillés.

Dans le rapport résumé, vous trouverez la liste des fonctionnalité utilisées qui peuvent être migrées par l’outil, celle qui nécessite des modifications pour être prise en charge par l’outil et celles que l’outil ne sait pas traiter (un relai DHCP par exemple).

Dans le rapport détaillé, on retrouvera pour chaque Organization VDC un statut indiquant la capacité de migration et les raisons d’une non-conformité.

La phase de migration

Elle nécessite d’avoir un NSX-T opérationnel pour pouvoir créer un nouveau Provider VDC dans VCD. Ce Provider VDC cible (sous NSX-T donc) doit être dans le même vCenter que celui de la source (sous NSX-V). Les sous-réseaux IP utilisés pour les External Networks doivent être dans le même plan IP sans se chevaucher.

Voici en résumé les principales étapes de migration que réalise l’outils :

  1. Création de l’Organization VDC cible
  2. Recopie de la topologie réseau ainsi que les services associés
  3. Création des Bridges L2 via NSX-T
  4. Bascule du trafic Nord-Sud
  5. Migration des VMs dans le nouvel Organzation VDC

Dans les faits, il réalise plus de 50 opérations dont la liste est visible dans la documentation.

A la fin, toutes les VMs sont déplacées dans l’Organization VDC cible sur un segment réseau de NSX-T via vMotion (et Storage vMotion si nécessaire) et l’architecture devrait ressemble à cela :

La phase de Cleanup

Une fois la migration réalisée, il reste un nettoyage à faire. Certains éléments sont toujours présents mais ne sont plus nécessaires (les Bridges L2 par exemple). Ils ont été conservés pour faciliter le retour arrière. Dès lors que vous êtes certain du succès de votre migration, vous pouvez initier le Cleanup via la commande vcdNSXMigrator –Cleanup. L’outil réalisera alors les opérations suivantes :

  1. Migration du catalogue
  2. Suppression des Bridge L2
  3. Suppression de l’Organization VDC source (réseaux et Edge Gateway compris)
  4. Renommage de l’Organization VDC cible

En conclusion

S’il n’y a qu’une chose à retenir c’est que vous n’avez plus le choix, vous devez migrer de NSX-V vers NSX-T.

NSX Migration for VMware Cloud Director Tool est probablement l’outil le plus approprié si vous disposez d’un environnement VMware Cloud Director.

Avant de commencer :

  • Vérifiez la matrice de d’interopérabilité.
  • Lisez le User Guide et la Release Note.

Enfin retenez que :

  • Le mode Assessment ne fait que de la lecture (aucune modification de votre production) et ne nécessite pas le déploiement préalable de NSX-T.
  • L’outil permet d’automatiser les migrations de vos Organization VDC une part une.
  • NSX Migration for VMware Cloud Director Tool est la méthode de migration vers NSX-T qui minimise le Downtime, sans casser la liaison NSX-V/VCD pour permettre un éventuel retour arrière.

[1] Software-Defined Network

[2] Software-Defined DataCenter

[3] Virtual Datacenter

par Stéphane HEBERLE, Expert VMware