Migration vSphere 6.5 de notre bac à sable OK après expertise VMware

Il y a quelques semaines, je vous avais présenté la première étape de notre chantier de migration vers vSphere 6.5 qui consistait à upgrader notre PSC externe Windows vers une PSC 6.5 en VCSA. A l’époque tout s’était bien déroulé et nous étions go pour passer à l’étape suivant : la migration de notre vCenter 6.0 Windows/Oracle vers vCenter 6.5 VCSA (avec base intégrée en PostgreSQL).

Sur le principe, rien de bien compliqué grâce à un assistant limpide, mais dans la pratique j’ai été confronté à une erreur lors de l’export des données de notre instance Oracle. Après quelques semaines d’investigation avec le support VMware (merci à Brice pour son implication et ses nombreuses escalades à l’engineering !), tout est rentré dans l’ordre et notre bac à sable est désormais en vCenter 6.5 VCSA.

Petit récit des événements.

Lors de la migration du vCenter vers VCSA, plusieurs étapes sont enclenchées les unes après les autres:
– déploiement de la VCSA sur l’infrastructure cible,
– préparation de celle-ci,
– export des données de l’ancien vCenter
– ré-injection de la base dans la VCSA
– reboot et récupération de l’identité du serveur originel (IP et nom logique)
Comme indiqué, lors de l’export des données de notre vCenter 6.0, les scripts VMware ont renvoyé une erreur python/sql parlant d’un souci avec l’encodage des données, interdisant du même coup à l’assistant de terminer ses opérations :
"Error while exporting VDCS data: sqlite3.ProgrammingError: You must not use 8-bit bytestrings unless you use a text_factory that can interpret 8-bit bytestrings (like text_factory = str). It is highly recommended that you instead just switch your application to Unicode strings."

Il faut noter ici que VMware a très bien fait les choses, car à cette étape, votre vCenter originel est encore parfaitement opérationnel et il a suffit d’un redémarrage des services pour que celui-ci retrouve son état original. Bien vu et fiable :)

Malgré quelques recherches googliennes, je n’ai pas pu identifier le souci et j’ai donc fait appel au support VMware. S’en est suivi un échange assez long, mais très fructueux, sur plusieurs semaines. Après avoir fourni les logs de l’assistant, du vCenter ainsi qu’une extraction partielle de notre base de données, un des ingénieurs de l’équipe de développement a trouvé la cause de cette erreur : il s’agissait en fait d’un problème très spécifique visiblement. N’étant pas du tout DBA, je vous transmets les informations telles que je les ai compris, à prendre avec les clefs de douze d’usage, donc ^^

Notre base Oracle support de vCenter n’est pas configurée en UTF8 mais en AL16UTF16. Or, il se trouve qu’un des enregistrements de celle-ci contenait malgré tout une chaîne de caractère avec de l’UTF8, ce qui provoquait le plantage du script d’export. Oracle est tout à fait capable de gérer de l’encodage UTF8 bien sûr, mais dans ce cas, les paramètres de la base doivent être correctement positionnés, ce qui n’était pas le cas chez nous.

Voici la réponse du support, en anglais dans le texte : “According to Oracle’s documentation (https://docs.oracle.com/cd/B19306_01/server.102/b14225/ch6unicode.htm#CACHCAHF), Unicode can be stored in CLOB field. This however has a requirement such Oracle DB should be configured with UTF-8. Currently the VCDB has no such requirement.”

Au final, la solution chez nous était relativement simple : il suffisait de modifier l’enregistrement contenant la chaîne invalide grâce à un petit “update”, fourni directement par le dba VMware. En l’occurence, la partie qui posait problème était “Microsoft Windows 7 (32 bits)” qui contenait deux espaces encodés en UTF8. Voici cette commande :

Une fois cette commande SQL passée (et son petit copain “commit” de bon aloi ^^), j’ai relancé l’ensemble de la migration et cette fois-ci, tout s’est parfaitement déroulé. Au bout d’une quinzaine de minutes, l’ensemble du vCenter bac sable était migré sur VCSA 6.5. Comble de joie et d’allégresse, la sortie très récente de NSX 6.3 (voir ici) m’a permis de faire aussi l’upgrade de notre NSX Manager et disposer d’une infrastructure full vSphere 6.5 !

En conclusion, que peut-on retenir de notre expérience ? En premier lieu, il faut rappeler que cette erreur est liée à une entrée parasite très spécifique au sein de notre base Oracle, dont il faut préciser qu’elle a subit de nombreuses migrations/évolutions depuis vSphere 5.0 ; à ce titre, il ne faut pas généraliser ce contexte et donc il est peu probable que vous le rencontriez vous-même.

En second lieu, si, malgré tout, vous êtes dans un cas similaire au nôtre (Windows/Oracle) et que vous rencontrez ce type d’erreur lors de la migration, VMware est désormais au courant de ce “bug” spécifique et a prévu d’intégrer un patch correctif dans une future mise à jour de vSphere 6.5. Dans l’intervalle, n’hésitez pas à les contacter, pourquoi pas en indiquant mon petit billet comme référence au bug en question ! Ils vous donnerons très vite les quelques modifications à réaliser sur votre base.

Enfin, rappelez vous que même si nous pestons de temps en temps face à un support VMware pas toujours très réactif ou constructif, dans l’ensemble, celui-ci est tout de même très efficace et est capable de mobiliser des énergies importantes en interne pour résoudre les problèmes des clients. Ca va mieux en le disant ^^