Compte-rendu d’upgrade NSX-T vers 2.5

Bonjour à tous ! On ne s’arrête pas en si bon chemin, après un mois de septembre particulièrement intense, nous avions convenu avec VMware qu’il serait bon de procéder à une mise à jour de notre plateforme NSX-T 2.4.1, afin de bénéficier des nombreux correctifs apportés depuis la sortie de cette release en Mai dernier. La question qui restait en suspens était : vers quelle version migrer ? Petit retour sur l’upgrade en question.

Grande question, en effet. NSX-T 2.5 vient de sortir depuis à peine plus d’une semaine. Pour autant, il existe une version NSX-T 2.4.2, sortie en Août dernier qui a apporté son lot de correctifs. Il nous aura fallu en discuter en interne, peser le pour et le contre par rapport aux échéances, mais aussi avec VMware, pour trancher. Au final, c’est VMware qui aura su nous convaincre qu’une mise à jour en 2.5 était, de loin, la solution la plus souhaitable aux vues des priorités internes de l’entreprise axées sur une stabilisation du code, quitte à rester un peu conservateur en matière de nouvelles fonctionnalités. Le cycle de développement de NSX-T est extrêmement rapide dans tous les cas, mais il y a un moment où il faut aussi apporter de la confiance ;)

Au final, c’est donc vers la 2.5 que nous nous sommes tournés. Je ne vais pas teaser plus que cela, l’opération s’est passée parfaitement bien, sans aucune erreur ni alerte d’aucune sorte du début à la fin. L’assistant de migration intégré à la plateforme a joué son rôle d’orchestrateur à la perfection. Nous avons même utilisé, pour cette fois en tout cas, l’option d’une migration des transport nodes (les ESXi) dite “In Place”. Cette option permet d’indiquer à NSX de ne pas passer en maintenance l’hyperviseur avant de mettre à jour les binaires de NSX. La seule conséquence est une perte de connectivité des VMs connectées à des segments NSX a peu près équivalente à un VMotion, mais guère plus. En tout cas, c’est ce que nous avons constaté. Peu d’impact donc, mais un gain de temps particulièrement important, surtout sur un cluster VSAN, si vous souhaitez conserver votre niveau de service en matière de stockage. Le non passage en maintenance nous aura permis d’upgrader nos 20 machines en à peine plus de 2 heures, là où il aurait fallu plutôt 24-36 heures (comme vécu entre la 2.4.0 et la 2.4.1).

Pour upgrader, vous devez vous connecter sur le noeud NSX Manager maître de votre cluster (son IP apparaît dans la vue system de NSX). Il vous l’indique de toutes façons, si vous oubliez ce détail. Par contre, l’ordre de l’upgrade entre 2.4 et 2.5 a changé. Désormais, l’assistant vous propose de migrer en premier les edges nodes, puis les hosts et enfin terminer par le management cluster. Une séquence que je trouve plus logique, personnellement, que la précédente qui consistait, si ma mémoire est bonne, à upgrader le cluster, les hosts et enfin les edge nodes.

Un autre point important qu’il faut retenir c’est une modification du port de connexion entre le management cluster et les transport nodes. Si vous disposez de routeurs filtrants ou de pare-feux entre vos NSX managers et vos compute clusters, soyez vigilent et consultez les release notes de la 2.5 ainsi que le guide d’upgrade (liens en fin d’article).

La seule chose un peu déstabilisante concerne la fin de l’upgrade du management cluster. Si vous disposez de 3 nœuds comme nous (et beaucoup de clients, je pense), l’assistant va d’abord procéder à l’upgrade des deux nœuds non maîtres simultanément, en ne conservant actif que celui où vous procédez au suivi de l’upgrade. Ensuite, ces deux appliances reboot quasi simultanéement mais ne lancent pas la partie manager au départ (par contre, d’après ce que j’ai vu, le controller plane est relancé, donc la gestion de la production reste assurée en haute disponibilité). L’assistant termine enfin l’opération en mettant à jour le dernier nœud et le reboot. Vous vous retrouvez donc dans le noir pendant plusieurs minutes, le temps que l’appliance en question redémarre et ordonne aux deux premiers de faire de même avec les services de manager. C’est donc environ 10 minutes d’attente sans visibilité aucune sur le process qu’il faut “supporter”.

Au bout de ces longues minutes, enfin, la webUI est à nouveau accessible et vous retrouver l’assistant de migration jusqu’à la fin, quelques minutes plus tard.

Après toutes nos péripéties de rentrée, j’avoue que nous n’étions pas “sereins”, forcément. Pour autant, comme déjà dit, tout cela a été d’une fluidité et d’une rapidité déconcertante. Nous voici donc avec un environnement NSX-T en 2.5 en parfait état de fonctionnement.

Comble du bonheur, cela a réglé du même coup un autre problème. Il faut savoir que nous traînions un SR chez VMware concernant des alertes très régulières polluant nos logs NSX sur l’ensemble des transport Nodes. Voici à quoi elles ressemblaient :

.. Ces erreurs étaient tellement nombreuses qu’elles embolisaient littéralement notre Log Insight avec plus de 160k alertes toutes les dix/quinze minutes. Depuis la mise à jour, ces alertes ont totalement disparu ! Bon ne vous inquiétez pas hein, il reste d’autres erreurs bizarre qu’on va essayer d’éradiquer aussi- ou comprendre d’où elles viennent au moins – ça serait pas drôle, sinon ^^

Il nous reste à tester NSX Intelligence… avec sa monster-VM de 64 Giga de RAM et 16 vCPU. Ben oui, hein, c’est de l’IA, on est pas la pour tricoter comme dit l’autre !.. Antoine – il se reconnaîtra – est en train de faire le pied de grue devant mon bureau pour déployer, c’est vous dire que la fonction est attendue … toute la question est de savoir si le résultat sera à la hauteur de l’investissement technique et de la motivation mettre en oeuvre ce service. Je vous dirais cela bientôt, soyez sans crainte ^^

Cette fois, nous sommes dans la dernière ligne droite pour enfin démarrer une production critique sur nos nouvelles infrastructures de virtualisation de réseau ! “It’s about time” comme disent les anglos-saxons :)

La release note de NSX-T 2.5, à consulter ici.
La doc de mise à jour 2.x vers 2.5, à consulter ici.
Un autre billet très intéressant et plus détaillé que le mien sur le déroulement d’une mise à jours vers 2.5, à lire d’urgence ici.