Migrer depuis une plateforme de virtualisation vers une solution de cloud hybride : présentation pratique

De nombreuses entreprises et organisations délaissent leurs plateformes de virtualisation traditionnelles au profit de solutions de cloud hybride. Récemment, une équipe d'ingénierie Red Hat s'est lancée dans une migration à grande échelle depuis Red Hat Virtualization vers Red Hat OpenShift à l'aide de la boîte à outils de migration pour la virtualisation, un outil avancé de migration des charges de travail virtuelles vers OpenShift.

Notre environnement Red Hat Virtualization a exécuté avec succès des centaines de machines virtuelles pendant plus de 10 ans, certaines utilisées par des ingénieurs à des fins de développement et de test, et d'autres pour des charges de travail de production. La fin de vie de Red Hat Virtualization nous a poussés à décider qu'il était temps de migrer nos machines virtuelles vers OpenShift.

Compte tenu de la nature des machines virtuelles qui s'exécutaient dans Red Hat Virtualization et de notre volonté de limiter les perturbations pour les utilisateurs finaux, nous avons décidé de continuer à exécuter les charges de travail au sein de machines virtuelles sur OpenShift par le biais d'OpenShift Virtualization. Pour ce faire, nous avons effectué la migration à l'aide de la version 2.4 de la boîte à outils de migration pour la virtualisation, la version la plus avancée à l'époque, avec des fonctions de migration améliorées.

Notre transition depuis Red Hat Virtualization vers OpenShift nous a confrontés à de nombreuses difficultés, aussi bien les nôtres que celles de nos utilisateurs. La suite de cet article explique comment nous les avons résolues et offre d'autres conseils issus de notre expérience.

Préparation et planification

Une planification minutieuse a été cruciale pour réussir la migration. Lorsque nous avons planifié la migration, nous nous sommes rendu compte que nous avions plusieurs difficultés à surmonter.

D'une part, nous devions nous assurer que le cluster OpenShift disposait de ressources suffisantes pour gérer les charges de travail migrées. Nous avons commencé par identifier les machines virtuelles qui n'avaient pas été utilisées récemment dans Red Hat Virtualization et celles dont les propriétaires avaient demandé qu'elles ne soient pas migrées vers le nouvel environnement OpenShift. Ces machines virtuelles n'ont pas été incluses dans la migration. Nous nous sommes ensuite assurés de disposer de suffisamment d'espace de stockage dans OpenShift pour les disques des machines virtuelles que nous prévoyions de migrer. Nous avons également veillé à ce qu'il y ait suffisamment d'adresses IP à allouer aux machines virtuelles que nous avions l'intention de migrer dans le VLAN cible d'OpenShift.

D'autre part, nous avons compris qu'il nous fallait faire le lien entre le modèle de provisionnement que nous utilisions dans Red Hat Virtualization et celui de l'environnement OpenShift Virtualization. Dans Red Hat Virtualization, les nouvelles machines virtuelles sont attribuées aux utilisateurs par les administrateurs. En revanche, dans OpenShift Virtualization, les utilisateurs sont affectés à des projets par les administrateurs et peuvent créer eux-mêmes des machines virtuelles dans leurs projets.

Enfin, les fournisseurs source et cible sont définis avec les informations d'identification de l'utilisateur dans la boîte à outils de migration pour la virtualisation. De cette façon, les utilisateurs définissent un fournisseur source à partir duquel migrer les machines virtuelles pour lesquelles ils ont des autorisations, et un fournisseur cible sur lequel créer des machines virtuelles en leur nom. Dans notre cas, nous avons préféré migrer toutes les machines virtuelles en même temps plutôt que de demander à chaque utilisateur de migrer la sienne. Nous avons donc dû faire appel à des utilisateurs qui avaient des privilèges d'administrateur sur les deux plateformes, ce qui leur a permis d'accéder à toutes les machines virtuelles dans Red Hat Virtualization et d'en créer au sein de tous les projets dans OpenShift.

Nous avons découvert qu'il n'était pas aisé d'identifier les machines virtuelles récemment utilisées (en l'occurrence, l'an dernier) ainsi que la taille de leurs disques pour déterminer si le cluster OpenShift cible disposait d'une capacité de stockage suffisante. En outre, il a fallu fournir des efforts supplémentaires pour que les propriétaires des machines virtuelles de Red Hat Virtualization créent des projets dans OpenShift afin de correspondre au modèle de provisionnement différent. Pour pallier ces difficultés, nous avons mis en œuvre des scripts Python.

Le premier groupe de scripts a collecté des données de Red Hat Virtualization à l'aide du SDK oVirt. Ces données nous ont permis de déterminer la dernière fois que les machines virtuelles ont été utilisées et d'exclure celles qui n'ont pas été utilisées depuis un an. Une fois que nous avons obtenu la liste finale des machines virtuelles à migrer, nous avons recueilli les informations détaillées sur la taille de leurs disques et leur propriétaire. Les données que nous avons obtenues de Red Hat Virtualization nous ont montré que nous ne disposions pas de suffisamment d'espace de stockage dans le cluster OpenShift pour stocker les données des machines virtuelles migrées. Pour remédier à ce problème, nous avons augmenté la capacité de stockage du cluster OpenShift en ajoutant une nouvelle classe de stockage.

Un deuxième groupe de scripts a été utilisé pour préparer les projets sur le cluster OpenShift à l'aide de l'API Kubernetes. Grâce aux données fournies par le premier ensemble de scripts, nous avons identifié l'ensemble des propriétaires de chacune des machines virtuelles migrées. Pour chaque groupe de propriétaires, nous avons ensuite créé un projet dans le cluster OpenShift et l'avons attribué à ces propriétaires en leur accordant le ClusterRole avec des autorisations d'administration.

Pour illustrer ce point, prenons une machine virtuelle appelée shared_vm appartenant à deux utilisateurs de Red Hat Virtualization, Alice et Bob. Dans OpenShift, nous créons un projet nommé alice-bob-ns pour lequel Alice et Bob disposent tous deux d'autorisations. Nous migrons ensuite la machine virtuelle shared_vm vers le projet alice_bob_ns. Les autres machines virtuelles appartenant à Alice et Bob dans Red Hat Virtualization peuvent également être migrées vers le même projet, alice_bob_ns. Alice et Bob peuvent être affectés à d'autres projets avec des machines virtuelles de Red Hat Virtualization qu'ils possèdent seuls ou avec d'autres utilisateurs. Cette approche nous permet de prendre en compte différents modèles de provisionnement dans les environnements Red Hat Virtualization et OpenShift.

Une fois ce problème résolu, nous nous sommes lancés dans la migration des machines virtuelles.

Exécution

La migration elle-même s'est déroulée en plusieurs étapes.

1. Nous avons déployé la boîte à outils de migration pour la virtualisation sur le cluster OpenShift vers lequel nous avons migré. La boîte à outils de migration pour la virtualisation peut migrer les machines virtuelles vers le cluster OpenShift sur lequel elle s'exécute ou vers des clusters OpenShift distants qui sont ajoutés en tant que fournisseurs de destination. En l'occurrence, nous avons migré toutes les machines virtuelles vers un seul cluster OpenShift, ce qui a conduit à l'installation de l'opérateur de la boîte à outils de migration pour la virtualisation sur ce cluster.
2. Dans la console web OpenShift, nous avons utilisé un utilisateur administrateur pour configurer le cluster OpenShift en vue de la migration grâce à :
   1. la création d'un projet de gestion désigné pour l'effort de migration ;
   2. la création du fournisseur source Red Hat Virtualization, du cluster OpenShift local en tant que fournisseur cible et des mises en correspondance de stockage et de réseau au sein du projet de gestion.
3. En raison du grand nombre de plans de migration nécessaires pour migrer vers les projets cibles, nous avons automatisé leur création et leur exécution à l'aide de scripts que nous avons mis en œuvre et exécutés avec des privilèges d'administrateur. Ces scripts ont effectué les actions suivantes :
   1. Création d'un plan de migration à froid par projet cible. Nous avons choisi la migration à froid, car nous ne nous souciions pas des temps d'arrêt des machines virtuelles, et les migrations à froid sont généralement plus rapides que les migrations intermédiaires.
   2. Création d'un plan de migration par migration pour déclencher les plans de migration.

La plupart des plans de migration de machines virtuelles ont abouti, mais nous avons été confrontés à deux défis intéressants au cours du processus.

Tout d'abord, en attendant la fin de la première migration de machine virtuelle, nous avons remarqué que celle-ci avait pris plus de temps que prévu. Cela était dû à l'exécution simultanée d'un grand nombre de plans de migration.

Dans la boîte à outils de migration pour la virtualisation, il est possible de limiter le nombre de migrations de machines virtuelles exécutées en parallèle dans le cadre d'un plan de migration, mais il est impossible de limiter le nombre de migrations de machines virtuelles exécutées dans différents plans de migration. En exécutant plusieurs plans de migration simultanément, nous avons surutilisé la bande passante du réseau et ainsi ralenti la migration des machines virtuelles.

Dans notre cas, le temps nécessaire à la migration de tous les plans de migration était plus important que le temps d'arrêt de chaque machine virtuelle migrée, et la durée globale de la migration n'a pas été affectée par ce choix. Toutefois, si la durée globale de la migration est affectée par l'utilisation excessive de la bande passante du réseau due à l'expiration des migrations de machines virtuelles ou aux temps d'arrêt à réduire pour chacune d'entre elles, il peut être préférable de mettre en œuvre les plans de migration progressivement ou d'effectuer des migrations à chaud.

Par ailleurs, 3 migrations de machines virtuelles sur 120 ont échoué. Notre enquête sur ces dysfonctionnements a révélé qu'ils étaient survenus en raison d'un bogue dans notre code base. Nous avons réussi à corriger le bogue rapidement et, grâce à une version corrigée de la boîte à outils de migration pour la virtualisation, nous avons été en mesure de migrer toutes les machines virtuelles. Le correctif pour ce problème est inclus dans la version 2.5 de la boîte à outils de migration pour la virtualisation.

Avec ces ajustements, nous sommes parvenus à migrer toutes les machines virtuelles vers OpenShift.

Validation de machines virtuelles sur OpenShift

Une fois toutes les migrations réalisées à l'aide de la boîte à outils de migration pour la virtualisation, nous avons effectué des contrôles de validité sur plusieurs machines virtuelles sélectionnées au hasard sur OpenShift Virtualization. Chaque contrôle a été une réussite. Nous avons ensuite attendu l'avis des propriétaires de machines virtuelles. Dans l'ensemble, les utilisateurs ont formulé des retours positifs sur la migration de leurs machines virtuelles vers OpenShift Virtualization, mais quelques problèmes nous ont été signalés.

Le démarrage de certaines machines virtuelles échouait, avec le message « no operating system found » (aucun système d'exploitation détecté). Nous avons découvert que ce phénomène s'est produit uniquement sur les machines virtuelles dotées de plusieurs disques, et uniquement lorsqu'un disque incorrect a été choisi pour procéder au démarrage. Nous avons résolu ce problème en modifiant manuellement l'ordre de démarrage des machines virtuelles, afin de nous assurer qu'elles démarrent à partir de leur disque de démarrage.Ce problème a été corrigé dans la version 2.5 de la boîte à outils de migration pour la virtualisation.

Quelques interruptions de service ont également été signalées. Au cours de la migration, les machines virtuelles ont changé leur VLAN en raison de contraintes d'infrastructure, et certains services et charges de travail au sein de ces machines virtuelles étaient inaccessibles au démarrage.Cela était dû au fait que des enregistrements DNS avaient été configurés avec des noms de domaine complets (FQDN) et des adresses IP différents sur le nouveau VLAN. Ce problème a été résolu en demandant aux utilisateurs d'adapter leurs charges de travail et leurs clients externes aux nouveaux paramètres de domaine complet.

Ce qu'il faut retenir

La transition à partir de datacenters traditionnels vers des solutions de cloud hybride est un véritable défi. Il existe différentes approches, prises en charge par différents outils, que les utilisateurs peuvent choisir.Dans cet article, nous avons décrit une migration de machines virtuelles de Red Hat Virtualization vers OpenShift, que nous avons effectuée en interne chez Red Hat.

Cette migration a nécessité une planification minutieuse et complète ainsi qu'une communication claire avec toutes les parties prenantes de l'entreprise. La boîte à outils de migration pour la virtualisation fournit des outils pour faciliter la migration vers OpenShift Virtualization, mais elle ne couvre pas toujours toutes les étapes techniques.

Dans cet article, nous avons partagé notre utilisation de la boîte à outils de migration pour la virtualisation ainsi que les scripts que nous avons mis en œuvre pour les opérations non gérées par cet outil. Ces scripts sont disponibles sur GitHub. Grâce à ces éléments, nous avons réussi à migrer 120 machines virtuelles avec 12 To de données, qui s'exécutent maintenant sur OpenShift.

Alors que la solution Red Hat Virtualization arrive en fin de vie, nous nous attendons à ce que de nombreuses entreprises envisagent une migration similaire. Nous espérons que notre expérience et nos outils vous aideront à migrer vos machines virtuelles vers OpenShift à l'aide de la boîte à outils de migration pour la virtualisation, qui comprend des correctifs pour les problèmes mentionnés dans cet article et apporte de nombreuses améliorations.