Upgradons un vCenter en 4.1…

… dans la joie et la bonne humeur. Enfin, non, pas vraiment dans la joie et la bonne humeur.
Comme je l’ai dit dans mon message précédent, VMware a décidé de modifier sérieusement les prérequis pour l’installation d’un vCenter et impose un OS 64 bits désormais. Pas d’OS 64 bits ? Pas de vCenter 4.1.
Aujourd’hui, même si les processeurs 64 bits et les OS 64 bits existent depuis maintenant quelques années, le besoin réel de tels architectures ne se fait pas vraiment sentir et si il n’y avait pas quelques constructeurs ou éditeurs – genre Microsoft et la dernière version de certains produits type Exchange – pour forcer plus ou moins leurs adoptions.

Pourquoi VMware force cette adoption du 64 bits pour son vCenter ? Excellente question. En recherchant sur le site de l’éditeur, vous trouverez sans doute la réponse. Une bonne grosse réponse langue de bois à n’en pas douter. Pour ma part, je pense que c’et surtout parce qu’une faible partie du vCenter a besoin, dans certaines configurations, de plus de 4 Go de RAM pour fonctionner. Et, évidement, pour gérer de telles quantités de mémoire, il faut du 64 bits. Mais bon, ça, c’est pour les grosses infrastructures. Pour les petites, comme chez mon client actuel, ce besoin n’est pas présent.

Pourquoi je m’embête à vouloir upgrader le vCenter de mon client alors que je vais bientôt le quitter, et que je pourrais laisser cela à la charge de mon successeur ?
– Parce que c’est une opération que je serais amener à faire pour mes futurs clients.
– Parce que je veux laisser une infrastructure à jour à mon client en partant. Je fais les choses correctement jusqu’à la fin.
– Parce que je n’ai aucune confiance en mon éventuel successeur pour faire les choses correctement. C’est malheureux d’en arriver là, mais bon… En l’état actuel des choses, quand on se renseigne un peu sur le marché et sur les autres boites, on constate que le taux de tocards branleurs est de plus en plus élevé en informatique. – Non, je n’ai pas honte de dire ça. –

Donc comment upgrader un vCenter de la version 4.0.0 à la version 4.1 ?
Contexte : deux serveurs ESX 4, en cluster DRS et HA, avec une baie iSCSI et un vCenter virtuel sur un OS 32 bits. Le vCenter héberge la base de données, qui est sous SQL Express 2005. Peu ou pas de prod sur les VMs. Peu d’utilisation du vCenter en cette période, à part l’espèce de con qui veut le migrer. Donc possibilité de faire la migration de vCenter en pleine journée sans problème.
Le but : migrer le vCenter sur un serveur à OS 64 bits, sans perdre toute la configuration. (les pools de ressources, l’organisation de l’inventaire, le cluster, la configuration d’Update Manager, etc, etc…)
Les tests, méthodes, outils et autres utilisés :
VMware, dans sa grande générosité – j’ai vraiment envie de les pendre par les couilles avec cette histoire –, fournit un petit outil permettant de faire cette migration. "vCenter Server Data Migration Tool". Ce petit outil permet de faire un backup de la configuration du vCenter, de sa base et d’Update Manager. (même des patchs récupérés par Update Manager)
Sauf que… Ca ne migre que les bases SQL Express 2005 – là, j’ai bon – et que ça conserve le nom du serveur vCenter et son IP dans les fichiers de configuration. (Voir les gentils kbs chez VMware et ) Et là… Vous haïssez encore plus VMware… Parce que si vous migrez, c’est vers un autre serveur histoire d’avoir un downtime minimum et un minimum de sécurité en conservant l’ancien serveur le temps de la migration. Donc serveur différent, nom différent et IP différente. – dans une architecture un minimum sérieuse, avec genre un AD… –
Le backup avec leur gentil outil : arrêt des services VMware du vCenter, exécution de la ligne de commande adéquate, interaction minimum vu que la question la plus critique doit être d’indiquer si oui ou non vous voulez sauvegarder les mppppfff Go de patchs. Au final, j’ai obtenu un peu moins de 2 Go de backup, base comprise.
Que j’ai gentillement copié sur mon nouveau serveur tout neuf en Windows 2008 R2 64 bits. Et j’ai fait un snapshot – serveur virtuel, c’est mieux pour faire des tests – avant de faire l’installation, histoire de pouvoir la rejouer en cas de problème. Et j’ai bien fait.
J’ai donc lancé l’installation à l’aide du gentil outil de VMware. Qui me signale rapidement que le nom du serveur n’est pas le même que l’ancien. Mais proposer de le changer, ça doit être trop demander… L’installation / restauration se fait sans trop de problème, avec quand même pas mal de question de la part du programme. Puis arrive la restauration de la partie Update Manager. Et le drame. Il faut lui préciser si il utilise une nouvelle base ou si il doit pointer sur une ancienne. L’option 1 permettra de finir l’installation, mais si vous essayez d’utiliser Update Manager, ça ne marchera pas. L’option 2 vous permet de pointer vers votre base qui vient d’être restaurée – si vous êtes en SQL Express – ou vers une autre base si elle est déportée. Pour se faire, il faut créer un lien ODBC. Et accrochez-vous… Un lien ODBC 32 bits. Et là, la politesse n’est même plus une option la prochaine fois que vous parlerez à un représentant de VMware. Ils imposent un passage au 64 bits mais pour certains composants, il faut rester au 32 bits. Tas de *BIPS* !!!!!!
Donc, pour créer un lien ODBC sur Windows 2008 R2, il ne faut pas passer par l’exécutable habituel car il ne crée que des liens 64 bits. Il faut lancer %windir%SysWOW64odbcad32.exe. Et si votre base n’est pas déportée, il faut le faire entre le moment où vCenter et sa base sont restaurés et le moment où Update Manager s’installe.
Donc, au bout de quatre tentatives d’installation, j’ai eu un vCenter fonctionnel, reconnaissant mes serveurs ESX, reconnaissant le cluster, ayant récupéré toutes les informations nécessaires. Mais… Qui croit s’appeler du nom de l’ancien serveur, y compris pour la partie licenses. Autant dire, un truc totalement bancal et impossible à utiliser et à maintenir en production.

Après ces différentes tentatives de migration, il faut être réaliste.
Si vous avez une base déportée, vous pouvez vous en sortir assez bien, avec un downtime minimum.
Si vous avez une base SQL Express sur le même serveur que le vCenter, vous serez obligé de migrer sur un serveur du même nom avec la même IP.
C’est ce que je vais faire demain.
1- Backup du serveur vCenter 4.0, avec l’outil Data Migration de VMware, avec votre solution de sauvegarde favorite et un snapshot si votre serveur est virtuel. On est jamais trop prudent.
2- Copie du résultat du Data Migration vers le nouveau serveur.
3- Arrêt du vCenter 4.0
4- Renommage du nouveau serveur avec le nom de l’ancien. – si votre serveur est dans un AD, vous voyez les problèmes qui vont se poser si il faut faire retour arrière. – Ne surtout pas rebooter à ce moment là.
5-Changement d’IP du nouveau serveur pour celle de l’ancien.
6- Reboot.
7- Installation / restauration de vCenter, avec les galères de lien ODBC.
8- On prie, on teste et on constate.

Solution de retour arrière : vous éteignez le nouveau serveur. Vous rallumez l’ancien. Et si vous êtes en AD, ben… disjoin / join au domaine. En espérant que la base SQL Express n’explose pas pour des problèmes d’authentification…

 

Encore une fois, merci à VMware pour cette migration forcée, merci pour l’outil de migration merdique. Quand on voit ce que l’on paye en maintenance obligatoire annuelle, c’est franchement du foutage de gueule…

Laisser un commentaire

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

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.