Déménagement d’un cluster VxRail d’un vCenter à un autre

Bonjour à tous, ravi de vous retrouver en cette période de pré-rentrée ! L’été est souvent un moment propice pour réaliser des opérations de maintenance et d’optimisation sur nos infrastructures. Et, justement, à l’occasion de ce mois de Juillet, j’ai enfin pris le temps de déménager un cluster VxRail de son vCenter initial vers notre vCenter principal de production. Petit RETEX sur cette opération.

Pourquoi donc ?

Historiquement, le cluster en question fait partie des premiers VxRail déployés chez nous. A l’époque, nous avions préféré le rattacher à un vCenter dédié, pour le rendre le plus autonome possible (notamment au regard des phases de mise à jour, dont nous ne maîtrisions pas encore complètement les impacts potentiels). Depuis, nous avons beaucoup appris, forcément, et la multiplication des vCenter de production ne se justifie plus (accessoirement, on économise des licences vCenter : en effet, toutes nos instances vCenter sont reliés à une PSC externe afin d’utiliser l’Enhanced Linked Mode). Décision a donc été prise de consolider tout cela.

En plus, depuis quelques temps déjà, il existe une procédure officielle chez Dell EMC pour réaliser cette opération de déménagement. C’est supporté, c’est procéduré, on en a besoin, donc, en avant !

Les déménageurs bretons en action

Globalement, cette opération, même si elle est documentée et ne pose pas de problème majeur, doit être réalisée en respectant scrupuleusement les étapes décrites. Pour l’essentiel, il s’agit en fait de déplacer un cluster VSAN, la partie spécifique de reconfiguration VxRail étant en majorité assurée par un script Python exécuté sur le VxRail Manager.

J’ai déroulé ce chantier sur un VxRail en 4.7.111, la procédure Dell EMC indique une version minimum supportée en 4.7.110 et, pour le moment (j’ai envie de dire “bouuuuh”), ce n’est pas applicable si vous voulez déménager d’un vCenter 6.7 à un 7.0.

Les grandes étapes sont logiques et assez simples :
– Sauvegarde du maximum de paramètres Cluster (pour ré-appliquer la même configuration le plus strictement possible sur le nouveau vCenter) : copies d’écran, backups divers etc.
– Export du dvSwitch attaché au cluster VxRail
– Préparation du cluster (modification de quelques paramètres VSAN, désactivation des fonctions DRS et HA, suppression de eSRS coté Dell EMC)
– Création du nouveau cluster sur le nouveau vCenter
– Import de la configuration du dvSwitch sur le nouveau vCenter
– Déconnexion des ESXi de l’ancien vCenter puis reconnexion sur le nouveau et placement dans le nouveau cluster VMware
– Reconfiguration de tous les éléments réseaux
– Vérifications diverses
– Recréation des VSAN storage profiles et ré-application sur les VMs (normalement, aucun impact)
– Execution du script de migration python sur le VxRail Manager
– Reconfiguration de eSRS coté VxRail

Le nerf de la guerre, si vous réalisez ça sur un cluster en production, concerne l’export du dvSwitch original présent sur l’ancien vCenter et son import sur le nouveau. Sans rentrer dans le détail, une fois réalisé, faites très attention à raccrocher vos vmnic ESXi et bien entendu chaque VM étape par étape. Je vous conseille également de conserver jusqu’au dernier moment une patte réseau sur l’ancien dvSwitch et une patte sur le nouveau (notamment pour les vmkernel VSAN). En gros, prenez votre temps pour être certain que tout se passe bien. Les procédures (que ce soit via les KB VMware ou via la procédure officielle Dell EMC) sont très détaillées et vous guident pas à pas de toutes façons.

En outre, ce n’est pas une opération si simple. Si vous n’êtes pas sûr de vous coté vSphere, ne vous lancez pas vous-même dans ce chantier, faites-vous aider par un intégrateur expert. Il me semble que le support Dell EMC n’assure pas lui-même ce genre de chose, mais à vérifier. Pensez aussi AVANT de migrer comment vous allez gérer vos sauvegardes de VM. En effet, suivant les produits, vous serez peut-être contraints de relancer un backup full, même si vos VM ne changent pas d’UID (ça a été notre cas sur Avamar/Datadomain, par contre je pense que sur Veeam, ça doit bien se passer en mode continuité).

Reconfiguration VxRail Manager

Comme déjà évoqué, cette partie est à faire en dernier et consiste à passer un script Python sur votre manager. Celui-ci va vous poser tout un tas de questions concernant la configuration cible sur votre nouveau vCenter. De mon coté, j’ai eu un souci d’exécution : le script s’est arrêté lors de la checklist de la BDD mysticmanager en indiquant une erreur de contrainte relationnelle sur l’index esrs_cluster_id_fkey.

Etant donné que la procédure nous demande de supprimer eSRS préalablement au déménagement, je me suis dit que supprimer le seul enregistrement qui posait problème ne risquait pas de casser quoi que ce soit. J’ai donc pris l’initiative de faire un petit delete sur la table en question :

…. bingo, après relance, le script est allé au bout sans erreur. Après relance de l’appliance, je retrouvais les fonctions intégrées VxRail sur le vCenter cible (via le plugin VxRail, réinstallé automatiquement).

Bilan

Même si ce genre de chose parait impressionnant, ça reste relativement maîtrisé si on parle des technologies VMware pures. De même, le script python pour la reconfiguration de VxRail manager rend la partie Dell EMC assez simple finalement. Ceci étant et histoire d’enfoncer le clou, soyez très vigilant avec les changements réseau. J’ai eu des mauvaises surprises lors de changement de portgroups sur quelques VMs. D’autre part, si vous êtes capable de le faire “production arrêtée”, c’est mieux, forcément.

Pour plus d’information, et avant toute tentative, lisez bien (plusieurs fois ^^) le KB#215610 chez VMware, qui détaille l’opération générique pour tout cluster VSAN. Ensuite, lisez la documentation qui m’a été fourni sans souci par la hotline Dell EMC et qui est issue directement du Solve Desktop (si vous y avez accès, vous pourrez la créer facilement). Je vous la mets en pièce attachée, à télécharger ICI.

Bonne rentrée à tous !