Guides Essentiels
Voir tous les articles de ce guide
Conseil
Cet article fait partie de notre guide: Réussir la migration des machines virtuelles en cloud

Migration en cloud : attention à la compatibilité de vos VMs

Bien qu’un cloud public utilise un système de virtualisation similaire à celui de votre datacenter, il n’accepte pas toutes les caractéristiques de vos machines virtuelles. Voici celles à vérifier.

Stephen J. Bigelow
par
Publié le: 27 avr. 2020

Dans des conditions idéales, tout cloud public devrait être compatible avec toutes les machines virtuelles. Amazon Web Services (AWS) et Google Cloud Platform (GCP) revendiquent prendre en charge un grand nombre de formats sources, mais la compatibilité n’est ni universelle ni garantie. Les problèmes de compatibilité les plus courants concernent les versions des systèmes d’exploitation, les formats spécifiques et la manière d’exécuter les instances.

Il vaut la peine de vérifier la compatibilité du cloud-cible avec le système utilisé sur site, avant de tenter une migration. Et, de manière générale, il faut toujours intégrer des contrôles de compatibilité avec le cloud dans le processus de migration des machines virtuelles, afin de s’assurer que leur mise en ligne se fera de manière fluide.

Par exemple, les instances d’Amazon Elastic Compute Cloud (EC2) prennent en charge un large éventail de systèmes d’exploitation, mais pas tous : EC2 n’accepte que les versions de Windows 7 et suivantes pour les postes virtuels, ainsi que Windows Server 2003 avec le Service Pack 1 minimum ou les versions ultérieures en 32 et 64 bits pour les serveurs virtuels. Le support d’un système 64 bits ne commence qu’à partir de Windows 8.1 et de Windows Server 2008 R2.

Concernant Linux, EC2 est uniquement compatible avec les versions 64 bits et il doit s’agir d’une distribution dotée au minimum du noyau 2.6.32.12-0.7, soit au moins Ubuntu 12.04, CentOS 5.1, Red Hat Enterprise Linux (RHEL) 5.1, SUSE Linux Enterprise Server 11 SP1, Oracle Linux 6.1 et Fedora Server 19.

Du côté de GCP, il faudra avoir au minimum Windows Server 2008 R2, RHEL, CentOS, Oracle Linux 6, Debian 8 et Ubuntu 14.04. Notez que les machines virtuelles Windows ne peuvent pas utiliser les versions de PowerShell antérieures à 3.0 car elles peuvent causer des problèmes de démarrage et d’arrêt des instances de Google.

Les partitions et le système de fichiers impactent la compatibilité

Les systèmes d’exploitation Windows doivent utiliser des partitions MBR (Master Boot Record) traditionnelles avec le système de fichiers NTFS. Les technologies de stockage plus modernes, comme les volumes qui ont des tables de partition à identifiant unique dans le monde, sont mal prises en charge.

Concernant Linux, AWS exige des partitions MBR formatées avec des systèmes de fichiers ext2, ext3, ext4, btrfs, jfs ou xfs. GCP recommande une partition MBR avec dispositif GRUB (GRand Unified Bootloader) installé.

Ensuite, pour migrer une VM, on crée généralement un fichier image, on le télécharge sur une ressource de stockage en ligne, on effectue une série de conversions censées permettre d’exécuter correctement cette image en cloud public et on déploie enfin cette image convertie dans une instance de calcul. Problème, le fournisseur du cloud public peut imposer des limites dans ces formats d’images.

Ainsi, AWS autorise l’import et l’export de VMs au format OVF, qui est pris en charge par VMware ESX et vSphere, ou au format d’un disque dur virtuel tel qu’utilisé par Microsoft Hyper-V et Citrix Xen, ou encore dans un format dit brut (« raw »). En pratique, cela permet à la grande majorité des machines virtuelles d’entreprise de migrer en ligne, mais ces formats ne sont pas nécessairement ceux utilisés par défaut sur site. Il peut être nécessaire de convertir le format d’image avant la migration ou de prendre le parti à présent de ne plus fonctionner sur site qu’avec des VMs dans un format directement exportable en cloud public.

Autre exemple, GCP ne peut pas importer d’images de VMs Windows configurées avec des disques multiples. Chaque disque nécessite des étapes distinctes pour importer et joindre les images.

Le diable se cache dans les détails

D’autres problèmes potentiels de compatibilité avec les VM Linux peuvent survenir lorsque Secure Shell (SSH) ne fonctionne pas sur le port 22. GCP, typiquement, utilise le port 22 pour SSH, et des clients tels que la console en cloud et l’interface de ligne de commande gcloud peuvent ne pas fonctionner si SSH utilise un port différent.

Prêtez également attention au type d’instances qu’utilise le fournisseur de cloud public selon les cas, c’est-à-dire aux configurations types de ses machines virtuelles. Bien que la majorité des types d’instances du cloud public sont censés accepter des VMs venues de votre datacenter, les types d’instances possibles peuvent être limités par systèmes d’exploitation.

Par exemple, pour les usages classiques, AWS limite les VMs Linux aux instances t2.micro, t2.small, t2.medium, m3.medium, m3.large, m3.xlarge et m3.2xlarge. Des limitations similaires existent pour les instances AWS optimisées en calcul, en mémoire, ou en stockage.

En fin de compte, il est important d’évaluer les limites de compatibilité de toute VM potentielle par rapport à chaque fournisseur de cloud public et de prendre des mesures pour résoudre et remédier à tout problème de compatibilité avec le cloud qui pourrait survenir. Des outils peuvent également être disponibles pour faciliter le processus d’évaluation.

Par exemple, GCP fournit un outil de précontrôle conçu pour trouver les problèmes qui interféreront avec l’importation de la VM ou qui causeront des problèmes une fois la VM importée. Mais gardez en tête que même avec une évaluation minutieuse et des processus rigoureux, certaines VMs refuseront toujours de s’importer ou de fonctionner correctement en cloud public.

Pour approfondir sur Administration et supervision du Cloud