Hello tout le monde ! Je profite de cette matinée assez calme chez nous pour vous faire un petit compte-rendu de la migration de notre gros stretched cluster VxRail. Rappelez-vous (voir ici), à l’automne dernier, nous avions fait une grosse mise à jour assez rocambolesque, qui s’était bien passée au final, mais avait duré 5 jours. Aujourd’hui, en prévision de la mise en production de notre nouveau NSX-T 2.4 sur ce cluster dans les semaines qui viennent, nous avions une nouvelle séquence de mise à jour majeure en 4.7 (ESXi 6.7) à réaliser pour le rendre compatible.
La migration
Plus techniquement il s’agissait de faire passer nos 20 serveurs sous VxRail 4.5.225 (ESXi 6.5 EP09) à la nouvelle version 4.7.111 (ESXi 6.7 EP07). Tiens, d’ailleurs, j’en profite pour vous remettre les liens vers les pages du support VMware qui vous permettent de corréler les build numbers de vos ESXi ainsi que ceux de vos VxRail, ça peut toujours servir n’est-ce pas ^^ : pour ESXi c’est le KB#2143832, pour VxRail c’est le KB#52075.
L’opération a été beaucoup plus rapide qu’en Octobre dernier, principalement pour les raisons suivantes : on a noté que l’ordonnanceur VxRail, avant de passer chaque host en maintenance, procédait à l’upgrade de tous les packages qui pouvaient l’être à chaud. Il en profitait aussi pour télécharger et préparer les packages EFI que le serveur aurait à traiter lors du reboot. Seule la partie dédiée à l’upgrade VMware proprement dite était réalisée sous maintenance. Avec cette optimisation, on gagne sur deux tableaux : d’une part le temps nécessaire aux update à chaud est également mis à profit par le cluster VSAN lui-même pour reconstruire/resynchroniser les données du précédent host déjà upgradé (cette phase peu peser assez lourd dans le temps global), d’autre part on limite l’opération à un seul reboot, la partie matérielle (firmwares) et logicielle (VMware) étant réalisée de manière séquentielle, en une seule passe. Résultat, au lieu de 2h30 voire 3h pour chaque ESXi précédemment, on tombe à environ 1h/1h30. Au final c’est plusieurs dizaines d’heures de gagnées sur un cluster de 20 machines !
Au final le séquençage lui-même s’est très bien passé – sans pannes hardwares ^^ – mais il nous reste encore quelques points à vérifier autour du witness (qui refuse de passer en 6.7) ainsi qu’une petite alerte de synchro sur le dvSwitch principal du cluster, mais rien de méchant je pense. Je mettrai à jour ce billet dès que ces points seront réglés.
UPDATE 11h30 : le problème de synchro dvSwitch concerne la dernière machine upgradée et n’est pas si simple que cela. J’ai lu deux articles qui ressemblent furieusement à notre souci et sont liés à l’upgrade dvs en 6.6 apparemmet. Escalade en cours chez Dell EMC… je vous tiens au courant ^^. Cf les deux KB#52621 et KB#66816.
UPDATE 15h45 : malgré tous nos efforts, impossible de remettre le serveur d’aplomb (toute la couche réseau de l’ESXi semblait vraiment mal en point, demande de rootcause à VMware du coté de Dell EMC). On a finalement décidé de le sortir complètement du cluster et de le ré-intégrer après réinstallation. Facile avec VxRail, qui s’occupe de tout ou presque (remove node/add node).
Changements ergonomiques
Un des apports visibles de VxRail 4.7 est son intégration avec le client vSphere HTML5. Alors que précédemment, l’interface d’administration était constitué d’un portail web sur le VxRail Manager, désormais, le produit est gérable directement sous vCenter via un nouveau plugin. Les menus spécifiques sont intégrés à la console des cluster et des hyperviseurs. Voici quelques screenshots rien que pour vous. Pour le reste, il suffit de regarder les évolutions de vSphere 6.7 par rapport à la 6.5.
VxRail est clairement dans la bonne direction aujourd’hui, vers le tout “customer upgradable”, les mises à jours suivent de très près les annonces et patchs coté VMware (deux/trois semaines environ entre ESXi 6.7 EP7 et VxRail 4.7.111). Le cahier des charges de départ en terme de simplicité est désormais en ligne de mire !
Nous sommes désormais parés pour le lancement de NSX-T 2.4 ! A suivre …
Bonjour Cédric,
Donc tu as eu besoin de réinstaller complètement un ESX suite à la mise à jour et tu es quand même satisfait ? :) Moi c’est le genre de truc que je ne comprends pas trop sur un système vendu clé en main et automatisé. Heureusement que la réinstallation est facile comme tu dis et heureusement que tu n’as eu le problème que sur un seul ESX ;)
J’appréhende mon upgrade vers la 4.5.311 pour ma part car de mon côté j’ai toujours eu un problème suite aux mises à jours.
Bon courage pour la suite !
En fait ça a été beaucoup plus compliqué que cela, finalement. Mais je ferai un gros update sur le billet dès que j’aurai un moment :)
On me pose souvent la question de l’intérêt de VxRail et je réponds souvent les même choses… mais les arguments en faveur de VxRail ne sont clairement pas techniques (enfin, pas que, disons). Ils sont avant tout vis à vis de la responsabilité du client et de son engagement à résoudre les problème éventuels. Je ferais peut-être un billet pour rappeler cela, un de ces quatres :)