Vous souhaitez migrer vers Google Cloud des applications legacy reposant sur des systèmes d'exploitation en fin de vie ? Cet article est pour vous. Nous passons en revue les options pour importer vos machines virtuelles sous OS EOL dans Google Compute Engine.
La réalité des applications legacy en fin de vie
Chez DoiT International, nous accompagnons des clients à différents stades de leur trajectoire cloud. Certains sont déjà cloud-native et n'ont pas encore beaucoup de dette technique, tandis que d'autres conservent des applications legacy pour diverses raisons. Certains s'efforcent de les maintenir à jour, d'autres se retrouvent dans la situation que décrit cet article : héberger des applications legacy laissées pour compte sur des systèmes d'exploitation en fin de vie (EOL). Si vous avez ce type d'applications et souhaitez les migrer vers Google Cloud, cet article est pour vous. Vous y découvrirez les options qui s'offrent à vous, afin, nous l'espérons, de prendre les bonnes décisions pour vos workloads.
L'idée de cet article m'est venue en observant plusieurs clients se tourner vers Google Cloud VMware Engine (GCVE) pour exécuter leurs applications legacy sur Google Cloud. Reposant sur VMware, GCVE est un excellent moyen d'exécuter certaines VM, y compris celles dotées de systèmes d'exploitation EOL. Le bémol de GCVE, c'est qu'il se prête mal à un dimensionnement réduit pour de petits workloads, et il ne devient rentable qu'à condition d'exploiter les ressources dans la configuration la plus petite disponible.
Bien que GCVE soit indéniablement une option pour exécuter vos applications legacy sur Google Cloud, je ne le recommanderais pas en premier choix, sauf si vos workloads imposent une telle échelle. Nous y reviendrons plus loin.
J'ai cherché à comprendre pourquoi certains clients en concluaient que GCVE leur était nécessaire pour exécuter leurs applications legacy EOL, et j'ai relevé plusieurs obstacles :
D'abord, j'ai vu des clients tenter de créer de nouvelles machines virtuelles à partir de systèmes d'exploitation EOL, comme Centos 6. Vous constaterez vite que l'image ne figure plus dans les images publiques de Google. Bien, et ensuite ?
L'étape suivante consistait à utiliser la fonction d'import de Google Compute Engine, qui réalise des imports ponctuels d'images de VM. On pourrait s'attendre à ce que cela fonctionne avec d'anciennes versions d'OS, mais lorsque j'ai tenté d'importer un OS EOL — Centos 6 dans cet exemple — la nouvelle a été décevante :
$ gcloud compute instances import centos-6 --source-uri=gs://eol-migration1322/centos6 --zone=us-central1-a
WARNING: Importing OVF. This may take 40 minutes for smaller OVFs and up to a couple of hours for larger OVFs.
Created [https://cloudbuild.googleapis.com/v1/projects/johnd-test-01/locations/us-central1/builds/0e67bbb8-3389-4a34-adae-5f5566732085].
Logs are available at [https://console.cloud.google.com/cloud-build/builds;region=us-central1/0e67bbb8-3389-4a34-adae-5f5566732085?project=306419495665].
starting build "0e67bbb8-3389-4a34-adae-5f5566732085"
[import-ovf]: 2022-07-05T21:25:20Z Starting OVF import workflow.
[import-ovf]: 2022-07-05T21:25:21Z Found gs://eol-migration1322/centos6/centos6.ovf
[import-ovf]: 2022-07-05T21:25:21Z Found gs://eol-migration1322/centos6/centos6-disk1.vmdk
[import-ovf]: 2022-07-05T21:25:21Z Didn't find valid OS info in OVF descriptor. OS will be detected from boot disk.
[import-ovf]: 2022-07-05T21:25:21Z Will create instance of `g1-small` machine type.
[import-disk-1]: 2022-07-05T21:25:22Z Inspecting the image file...
[import-disk-1]: 2022-07-05T21:28:26Z Inspecting disk for OS and bootloader
[import-disk-1]: 2022-07-05T21:30:05Z Inspection result=os_release:{cli_formatted:"centos-6" distro:"centos" major_version:"6" minor_version:"10" architecture:X64 distro_id:CENTOS} elapsed_time_ms:98933 os_count:1
[import-ovf]: 2022-07-05T21:30:06Z Cleaning up.
[import-ovf]: 2022-07-05T21:30:06Z os `centos-6` is invalid. Allowed values: [centos-7 centos-8 debian-10 debian-11 debian-8 debian-9 opensuse-15 rhel-6 rhel-6-byol rhel-7 rhel-7-byol rhel-8 rhel-8-byol rocky-8 sles-12 sles-12-byol sles-15 sles-15-byol sles-sap-12 sles-sap-12-byol sles-sap-15 sles-sap-15-byol ubuntu-1404 ubuntu-1604 ubuntu-1804 ubuntu-2004 windows-10-x64-byol windows-10-x86-byol windows-2008r2 windows-2008r2-byol windows-2012 windows-2012-byol windows-2012r2 windows-2012r2-byol windows-2016 windows-2016-byol windows-2019 windows-2019-byol windows-2022 windows-2022-byol windows-7-x64-byol windows-7-x86-byol windows-8-x64-byol windows-8-x86-byol]
ERROR
ERROR: build step 0 "us-central1-docker.pkg.dev/compute-image-tools/wrappers/gce_ovf_import:release" failed: step exited with non-zero status: 1
ERROR: (gcloud.compute.instances.import) build 0e67bbb8-3389-4a34-adae-5f5566732085 completed with status "FAILURE"L'option d'import d'image ne prend donc en charge qu'une sélection d'OS et de versions, dont Centos-6 ne fait pas partie. Que vous procédiez depuis la console Google Cloud ou en ligne de commande, le résultat est identique. Adieu la solution de facilité consistant à importer directement les images disque dans Google Compute Engine (GCE).
À ce stade, on découvre parfois GCVE et l'on constate qu'il exécute tout ce que VMware sait exécuter. Un cluster est provisionné et configuré, les VM sont importées — comme on-prem. Mission accomplie, parfait ! Vraiment ?
État actuel du support Google Cloud pour les images d'OS EOL
L'essentiel de la documentation de support de Google sur les systèmes d'exploitation EOL recommande avant tout de mettre à jour le système concerné. C'est assurément la meilleure pratique, mais ce n'est pas à la portée de tous. Les développeurs de l'application peuvent ne plus être disponibles, des dépendances vis-à-vis de certaines bibliothèques peuvent exister, ou les ressources peuvent simplement manquer pour mener cette mise à jour.
Options pour importer vos machines virtuelles sous OS EOL dans GCE
Voici les options à votre disposition, sans ordre particulier. Chacune a ses avantages et ses inconvénients.
Option 1 : réinstaller l'application legacy à partir d'une image GCE publique dépréciée
Comme indiqué plus haut, j'ai vu des clients tenter d'utiliser des images Google Cloud natives sans en trouver dans un premier temps. En réalité, Google a conservé ces images, mais ne les met pas en évidence. En consultant la documentation de support pour les images EOL, j'ai découvert qu'elles sont disponibles, mais marquées comme dépréciées. Voici un exemple de documentation pour Centos 6.
Dans la console GCE de Google Cloud, sous Images, un commutateur permet d'afficher les images dépréciées. Activez-le et voilà, la liste de toutes les anciennes images GCE apparaît :
Filtrez selon ce que vous cherchez — dans mon cas, les images Centos 6 —, sélectionnez l'image voulue, et créez une instance GCE à partir de celle-ci.
En ligne de commande, le résultat équivalent s'obtient avec :
gcloud compute images list --show-deprecated
L'avantage de cette option : vous disposez d'une image Google d'origine, avec ses outils Google comme l'os-agent et les ajustements OS nécessaires à son exécution sur Compute Engine déjà appliqués. Si votre application se réinstalle facilement et que vous n'avez qu'un faible nombre d'instances à migrer, cette approche peut être séduisante.
Option 2 : convertir manuellement votre image VM existante dans un format compatible GCE puis l'importer manuellement
Google fournit une documentation pour importer manuellement des images puis effectuer les ajustements nécessaires sur les images importées afin qu'elles fonctionnent correctement dans GCE. Ce processus peut s'avérer utile si vous avez des appliances VM sur mesure ou un petit nombre de serveurs avec des volumes uniques à migrer vers GCE. Étant manuel, il introduit un risque d'erreur.
Voici les grandes étapes, en poursuivant l'exemple de Centos 6 :
Planifiez votre démarche. Vous devrez stocker une image exportée depuis votre environnement source et disposer d'un moyen de la démarrer pour y apporter des modifications, puis la convertir dans un format compatible GCE. Veillez à disposer de suffisamment d'espace disque pour accueillir l'image, l'image compressée et un peu de marge, afin d'éviter les erreurs de saturation d'espace.
Faites une copie de l'image, démarrez-la dans l'environnement source et apportez les modifications nécessaires à l'OS avant la conversion, par exemple :
Modifiez le fichier de configuration de boot Linux, /etc/grub.conf dans notre exemple, et supprimez la ligne configurant le splashimage de boot. Supprimez également les paramètres kernel rhgb et quiet. Ajoutez console=ttyS0,38400n8d aux paramètres kernel.
Assurez-vous de pouvoir vous connecter via la console avec un identifiant et un mot de passe. Cela peut s'avérer utile si l'interface réseau ne se lève pas correctement après le démarrage dans GCE.
Veillez aussi à disposer d'une clé ssh pour accéder à l'image, par précaution.
Vérifiez que vos dépôts Centos fonctionnent toujours. J'ai dû basculer les dépôts Centos vers vault.centos.org.
Mettez à jour la configuration de l'interface réseau par défaut. Pour centos-6, il s'agissait de /etc/sysconfig/network-scripts/ifcfg-eth0. Supprimez les lignes HW_ADDR et UUID, puis ajoutez ONBOOT=yes et MTU=1460 au fichier.
Supprimez les outils VMware ou ceux de tout autre hyperviseur.
Copiez l'image dans un emplacement où vous pourrez exécuter les étapes suivantes.
Convertissez l'image dans un format accepté par GCE.
Le moyen le plus simple que j'ai trouvé pour convertir une image est d'utiliser l'utilitaire qemu-img. Installez qemu.
Dans cet exemple, je prends un fichier VMware .vmdk et je le convertis au format raw, requis par GCE :
qemu-img convert -f vmdk -O raw PATH/TO/VM.VMDK PATH/TO/disk.raw
Maintenant que le fichier .VMDK est converti en .raw, il faut l'archiver au format oldgnu :
tar –format=oldgnu -Sczf compressed-image.tar.gz disk.raw- Téléversez le fichier compressed-image.tar.gz vers un bucket Google Cloud Storage (GCS) :
gsutil cp compressed-image.tar.gz gs://BUCKET\_NAMEEnfin, créez l'image GCE :
gcloud compute images create IMAGE_NAME --source-uri \ gs://BUCKET_NAME/compressed-image.tar.gz
Créez une VM à partir de l'image obtenue, installez l'os-agent Google et apportez les modifications nécessaires.
Créez une VM à partir de l'image obtenue à l'étape 3e.
gcloud compute instances create VM_NAME --zone ZONE --image IMAGE_NAME
Connectez-vous à l'image via la clé ssh suggérée à l'étape 2c.
Si la connexion à l'instance échoue, c'est probablement qu'une nouvelle interface réseau a été détectée au démarrage. Connectez-vous à votre instance via la console série avec identifiant/mot de passe et corrigez l'interface réseau en fonction de ce qui a été détecté.
Une fois connecté, installez l'os-agent Google.
Si la marche à suivre vous paraît trop fastidieuse, l'option suivante est peut-être faite pour vous. Je vous recommande de parcourir la documentation de support Google sur l'import manuel des images et les ajustements à apporter aux images importées. J'ai retracé ci-dessus les grandes étapes ainsi que certains des écueils rencontrés. Plusieurs prérequis et limitations s'appliquent : lisez attentivement.
Option 3 : utiliser Migrate to Virtual Machines si vous avez plusieurs VM à amener vers GCE
Migrate to Virtual Machines (anciennement Migrate for GCE) est un outil de migration conçu pour faire du lift-and-shift de serveurs on-prem vers GCE. La dernière version de Migrate to Virtual Machines met l'accent sur les migrations VMware. Si vos applications legacy tournent déjà sur VMware, c'est sans doute la meilleure option pour vous. Migrate to Virtual Machines demande un peu de configuration initiale, mais une fois en place, il permet de migrer un grand nombre de machines virtuelles facilement, de manière fiable et avec un temps d'arrêt minimal.
Migrate to Virtual Machines fonctionne en installant une appliance de migration dans votre environnement VMware existant. Cette appliance fait l'interface entre Google Cloud et votre vSphere on-prem, ce qui permet à Migrate to Virtual Machines de visualiser votre environnement vSphere, de sélectionner les VM à migrer, de mettre en place la réplication des données puis de gérer le clonage pour les tests ou les bascules au moment où vous êtes prêt à déplacer vos applications vers Google Cloud.
C'est, à mon sens, l'option la plus séduisante pour la plupart des utilisateurs. Contrairement à l'import manuel de l'option 2, elle automatise une grande partie des étapes et, d'après mon expérience, migre les images de façon fiable. Si vous avez plus que quelques serveurs à déplacer, c'est la voie la plus rapide. Migrate to Virtual Machines prend également en charge plusieurs systèmes d'exploitation actuels et legacy.
Migrate to Virtual Machines exige que le migrate connector puisse communiquer directement avec les API Google, que ce soit via Internet ou via une connectivité privée entre votre environnement VMware et Google Cloud. Cette page de support passe en revue les options à votre disposition.
Les grandes étapes pour utiliser Migrate to Virtual Machines sont :
- Mettre en place les prérequis, comme l'activation des API Google Cloud associées et le choix des projets et des permissions IAM à utiliser.
- Installer, configurer et enregistrer le migrate connector dans votre environnement VMware existant
- Démarrer la migration des VM. Le processus de migration se décompose ainsi :
- Onboarder les VM dans Migrate to Virtual Machines.
- Démarrer la réplication pour certaines VM ou pour toutes. La réplication peut s'effectuer pendant que vos VM sources sont toujours en service.
- Configurer les détails des VM cibles : choix des types d'instance, configuration réseau, etc.
- En option, vous pouvez tester une migration via la fonction de clonage. Je recommande de le faire dans un environnement cible isolé. Vos images sources continueront de tourner dans VMware.
- Bascule. Cela arrête la VM source, exécute une réplication finale, puis provisionne les VM cibles. Cette étape implique un temps d'arrêt. Sur les images que j'ai testées, j'observais environ 15 minutes d'indisponibilité entre l'arrêt de l'image source et la mise en service de la nouvelle instance sur Google Cloud. L'essentiel de ce temps était consacré au traitement de l'image, sa taille peut donc faire varier cette durée.
- Nettoyage.
Option 4 : utiliser Google Cloud VMware Engine pour héberger des applications legacy volumineuses ou nombreuses
Google Cloud VMware Engine est l'option par laquelle je vois la plupart des clients démarrer, parce que les autres sont peu mises en avant. GCVE est un excellent produit sur les bons cas d'usage, mais exécuter un petit nombre de machines virtuelles sur un cluster GCVE peut vite devenir onéreux.
La configuration GCVE minimale est un cluster de 3 nœuds. Chaque nœud est une instance ve1-standard-72, soit 72 cœurs hyperthreadés (36 physiques), 768 Go de RAM et plus de 20 To de SSD. Au tarif On-Demand, chaque nœud revient à 9,29 $/h, ce qui porte le cluster minimal de 3 nœuds à 20 345,10 $ par mois. Les remises sur engagement de 1 an et 3 ans peuvent réduire ce tarif de manière substantielle.
Google propose une configuration à 1 nœud, qui réduit un peu le tarif et les ressources, mais la limite à une période de 60 jours, car elle est principalement destinée aux POC. Ne faites pas tourner vos workloads de production sur cette configuration.
GCVE reste une option viable pour exécuter des applications legacy en fin de vie, à condition que vos besoins en ressources le justifient, que vos workloads aient des licences peu compatibles avec le Cloud (Windows Server, Oracle, etc.) ou que vous exploitiez déjà fortement VMware on-prem et souhaitiez continuer à l'utiliser pour certains workloads afin de préserver vos investissements en outillage et en exploitation.
Option bonus 5 : utiliser l'outil Migrate to Containers pour conteneuriser certaines applications legacy
L'outil Migrate to Containers de Google Cloud peut être une option pour certains workloads. Si vous êtes déjà à l'aise avec les conteneurs et que vous ne souhaitez pas multiplier les machines virtuelles GCE, Migrate to Containers peut être une option viable. Migrate for Containers analyse vos workloads et, s'ils se prêtent à la conteneurisation, produit un conteneur de votre workload basé sur VM, utilisable sur des plateformes telles que Google Kubernetes Engine et Cloud Run.
Une réserve avec cette méthode : tous les workloads ne se prêtent pas à la conversion. Google fournit des exemples de workloads qui conviennent et de ceux qui ne conviennent pas. Un outil d'analyse peut aussi aider à le déterminer. Quelques modifications peuvent par ailleurs s'avérer nécessaires. Plusieurs systèmes d'exploitation actuels et legacy sont pris en charge.
Quelle approche privilégier pour votre application legacy laissée pour compte ?
D'après ce que j'ai pu observer chez nos clients, Migrate to Virtual Machines reste, selon moi, la meilleure solution globale : un bon équilibre entre l'effort à fournir, l'automatisation, la fiabilité et un temps d'arrêt minimal pour les workloads à état.
Si vous n'avez qu'une ou deux images à traiter, réinstaller votre application sur une image Google Cloud dépréciée ou opter pour une conversion manuelle peut demander moins d'efforts pour faire tourner une machine virtuelle sur GCE. Ces options conviennent en revanche peu à la migration de workloads à état qui tolèrent mal les temps d'arrêt.
Si vos applications sont déjà conteneurisées, que vous êtes prêt à apporter quelques ajustements à vos workloads si besoin et que vous ne souhaitez pas introduire de machines virtuelles dans votre environnement, Migrate to Containers peut être une piste intéressante. Le revers : tous les workloads ne se prêtent pas à ce processus, et vos applications pourraient nécessiter quelques modifications pour fonctionner.
Enfin, si vos besoins sont à grande échelle, en particulier avec des environnements VMware existants susceptibles de poser des problèmes de licence dans le cloud, GCVE permet de préserver certains de vos accords de licence existants — ceux qui empêchent certains workloads de tourner de façon rentable sur GCE — tout en tirant parti des compétences et des outils déjà en place. Cela dit, GCVE n'est généralement pas une solution économique pour quelques petites applications seulement.