Migration de notre production sur vSphere 6 !

Bonjour à tous,

Ceux qui me suivent sur Twitter l’ont sans doute vu, après plusieurs reports du à des événements extérieurs, nous avons finalement migré notre production VMWare sur vSphere 6 ! Après la mise à jour de notre bac à sable il y a quelques mois (voir mon billet ici) qui m’avait permis d’avoir une première expérience très enrichissante, il était temps pour se lancer sur la production.

Globalement, tout s’est bien passé, les principales difficultés que nous avons rencontré étaient liées à la re-génération du certificat auto-signé de notre serveur vCenter, car nous n’avons pas encore réalisé notre chantier de changement de ceux-ci pour épouser notre PKI Interne.

Un Compte-rendu macro de cette migration ? Allons-y :)

La première phase a consisté à faire le point exact sur toutes les versions en production pour vérifier que notre chemin de migration était bien supporté et sans “surprises” (il y en a presque toujours, mais au moins, on peut appeler le support VMWare ^^). Voici la liste des composants liés de près ou de loin à cette mise à jour majeure d’où nous sommes partis :
– vCloud Director 8.0.1
– vCloud Network and Security 5.5.4.1
– vCenter 5.5 update 3b Windows (sur Windows 2008R2 actuellement)
– vRealize Operations 6.2.0
– Avamar 7.2
– Oracle (BDD vCenter) 11.2.0.4

Nous avons utilisé les deux références VMWare suivantes présentant respectivement les chemins de migration recommandés ainsi que la matrice de compatibilité des composants VMWare :
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2109760
https://www.vmware.com/resources/compatibility/sim/interop_matrix.php

En outre, nous avons utilisé cette note pour pouvoir faire le lien entre les “build” et les version commerciales, afin d’être certain des versions de départ :
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1014508

Après ces vérifications, nous n’avions qu’à mettre à jour vCloud Network and Security, le reste des composants étant déjà compatible avec vSphere 6 update 2. Malgré tout, une petite note sur Avamar : aujourd’hui officiellement, Avamar 7.2 n’est pas validé avec l’update 2 (seulement avec la 1b), mais j’ai obtenu entre temps l’info que c’était juste une formalité et qu’il n’y avait que peu de risque à utiliser l’update 2 plutôt que l’update 1b étant donné que les API de sauvegarde n’ont quasiment pas changé entre ces deux versions.

D’autre part, lors de la mise à jour de vCNS, nous avons eu un petit souci de place sur l’appliance. En effet, lors de l’upload du package de mise à jour de 5.5.4.1 vers 5.5.4.2 via l’interface web, on a obtenu une erreur de type “not enough space”. En fait, il suffit juste de relancer la VM et les scripts de boot feront le ménage nécessaire pour vous permettre de réaliser l’upload et la mise à jour dans les meilleures conditions.

L’opération globale consistait à mettre à jour “in place” (sans autre modification de configuration particulière, sur la même machine) de vCenter 5.5 vers vCenter 6.0. Voici le déroulé les macro-tâches réalisées:
– Install de vCNS 5.5.4.2
– Arrêt de tous les services vCenter et Update Manager
– Passage des services vCenter et Update Manager en manuel.
– Arrêt à froid de la VM vCenter et de la VM Oracle portant la base de données.
– Snapshot à froid (donc cohérent) des deux machines
– Relance de VM Oracle
– Relance de VM vCenter et redémarrage des services
– Migration proprement dite de vCenter

La phase de migration s’est déroulée de manière quasiment identique à celle réalisée quelques mois plus tôt sur le bac à sable, avec les mêmes alertes et les mêmes remédiations, donc pas de problème de ce coté là. Par contre, toujours cette alerte de certificat auto-signé dont le niveau de sécurité ne correspondait plus aux best practices… on sent déjà à ce moment qu’il risque d’y avoir des ajustement à faire de ce coté là (reconnexion des différents outils avec la nouvelle signature), mais il fallait aller jusqu’au bout pour au moins valider la phase de migration d’autant plus que de toutes façons, nous devrons tôt ou tard changer ces certificats pour des officiels générés via notre PKI Intranet.

La mise à jour s’est terminée après plusieurs dizaines de minutes. Nous relançons les clients (web et lourd), l’inventaire est là, rien n’est perdu, c’est de bonne augure. La première chose, la plus importante, à laquelle nous nous sommes attaché était de vérifier que notre outil de sauvegarde Avamar fonctionnait bien avec ce nouveau vCenter. Après quelques sueurs froides (quelques messages d’erreur au sujet de la connexion à vCenter), notre Grid s’est finalement re-connecté et nous avons pu faire des tests de sauvegarde et restauration concluants (sans doute aurait-il été plus direct et rapide d’arrêter puis relancer le grid). Notez malgré tout que pour éviter toute surprise vis à vis justement de la re-génération de certificats, nous avons fait en sorte que la vérification desdits certificats soit bien désactivée sur Avamar. Pour cela, je vous conseille de lire ce billet qui indique comment désactiver cette option.

Ensuite, nous avons vérifié que vCNS voyait à nouveau ses “Edge Gateways” et communiquait bien avec vCenter. Et bien, non … Comme “pressenti”, il a fallut reconnecter manuellement (re-rentrer les paramètres de connexion dans la section settings et forcer la reconnexion), la faute au changement de certificat, évidemment. Après cette petite opération, tout rentre dans l’ordre et on constate que notre appliance vShield Manager fonctionne à nouveau parfaitement. A la suite de cela, il était clair qu’il allait falloir que nous forcions la reconnexion de tous les autres composants.

Pour continuer, nous nous sommes attelé à vCloud Director. Là, plus de difficultés, vCD refusait obstinément de se reconnecter, avec un message Java dont il a seul le secret (ceux qui utilisent vCloud Director me comprendront certainement …). Pourtant, nous avions bien vérifié que la checkbox spécifique de vérification du certificat de vCenter était bien décochée :

… Malgré de multiples tentatives, vCD n’arrivait toujours pas à synchroniser son inventaire avec vCenter. En désespoir de cause, nous avons ouvert un call chez VMWare. Ceci étant, comme nous avions déjà eu des problèmes de ce type quelques jours avant la migration, il était déjà clair que cela n’avait pas forcément de lien direct avec la mise à jour vCenter. Je vous ferai un billet spécifique sur nos ennuis de vCloud d’ici quelques jours, mais sachez juste qu’après quelques heures et sans rien modifier, vCD a finalement décidé de se reconnecter et que tout était nominal de ce coté là le lendemain matin…

Enfin, nous avons reconnecté vRealize Operations. Il a fallut, comme pour vShield Manager, procéder à la suppression de l’empreinte du certificat public de vCenter avant de relancer le plug-in correspondant. Pour le coup, c’était relativement simple car il y a une section spécifique dans l’interface d’administration pour gérer ces éléments :

Ouf ! C’était terminé. A 18h, nos batchs de sauvegarde Avamar redémarraient sans encombre et la production était migrée en vCenter 6 !

Evidemment, il reste à consolider tout cela et vérifier que l’ensemble des fonctions utilisées au quotidien chez nous fonctionne correctement, mais globalement, cette migration s’est bien passée. Comme vous avez pu le noter, si vous avez déroulé un chantier préalable de mise en conformité des certificats des divers composants impliqués avec votre PKI interne, la migration n’en sera que plus transparente pour l’écosystème des solutions clientes de vCenter ;)

Et enfin, n’oublions pas le chantier le plus long et au fil de l’eau : la mise à jours progressive de nos ESXi 5.5 en ESXi 6.0… mais ça, c’est une autre histoire !