Serveur d'impression

faites attention à la compatibilité de vos VMs – Serveur d’impression

Le 24 mai 2020 - 5 minutes de lecture

Dans des conditions idéales, tout cloud public doit être compatible avec toutes les machines virtuelles. Amazon Web Services (AWS) et Google Cloud Platform (GCP) prétendent prendre en charge un grand nombre de formats source, mais la compatibilité n'est ni universelle ni garantie. Les problèmes de compatibilité les plus courants concernent les versions du système d'exploitation, les formats spécifiques et la façon d'exécuter des instances.

Suite de l'article ci-dessous

Il convient de vérifier la compatibilité du cloud cible avec le système utilisé sur site, avant de tenter une migration. Et d'une manière générale, les vérifications de compatibilité avec le cloud doivent toujours être intégrées au processus de migration des machines virtuelles, pour garantir leur mise en ligne en douceur.

Par exemple, les instances d'Amazon Elastic Compute Cloud (EC2) prennent en charge une large gamme de systèmes d'exploitation, mais pas tous: EC2 accepte uniquement les versions de Windows 7 et versions ultérieures pour les bureaux virtuels, ainsi que Windows Server 2003 avec Service Pack 1 minimum ou version ultérieure versions en 32 et 64 bits pour serveurs virtuels. La prise en charge d'un système 64 bits ne démarre qu'à partir de Windows 8.1 et Windows Server 2008 R2.

Pour Linux, EC2 n'est compatible qu'avec les versions 64 bits et il doit s'agir d'une distribution avec au moins le noyau 2.6.32.12-0.7, c'est-à-dire 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.

Côté GCP, vous aurez besoin d'au moins 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 entraîner des problèmes de démarrage et d'arrêt des instances de Google.

Compatibilité des partitions et de l'impact sur le système de fichiers

Les systèmes d'exploitation Windows doivent utiliser les partitions MBR (Master Boot Record) traditionnelles avec le système de fichiers NTFS. Les technologies de stockage plus modernes, telles que les volumes qui ont des tables de partition uniques au monde, sont mal prises en charge.

Pour Linux, AWS nécessite des partitions MBR formatées avec les systèmes de fichiers ext2, ext3, ext4, btrfs, jfs ou xfs. GCP recommande une partition MBR avec le périphérique GRUB (GRand Unified Bootloader) installé.

Ensuite, pour migrer une machine virtuelle, nous créons généralement un fichier image, nous le téléchargeons sur une ressource de stockage en ligne, nous effectuons une série de conversions censées permettre à cette image de fonctionner correctement dans le cloud public et nous déployons enfin cette image convertie dans un instance de calcul. Problème, le fournisseur de cloud public peut imposer des limites à ces formats d'image.

Ainsi, AWS autorise l'importation et l'exportation de machines virtuelles 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 dans un format dit brut format. 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 maintenant la décision de ne travailler sur site qu'avec des machines virtuelles dans un format directement exportable vers le cloud public.

Comme autre exemple, GCP ne peut pas importer d'images de machines virtuelles Windows configurées avec plusieurs disques. Chaque disque nécessite des étapes distinctes pour importer et joindre les images.

Le diable est dans les détails

D'autres problèmes de compatibilité potentiels avec les machines virtuelles Linux peuvent survenir lorsque Secure Shell (SSH) ne s'exécute pas sur le port 22. GCP, généralement, utilise le port 22 pour SSH, et les clients tels que la console cloud et l'interface de ligne de commande gcloud peuvent ne pas fonctionner si SSH utilise un port différent.

Faites également attention au type d'instances que le fournisseur de cloud public utilise selon le cas, c'est-à-dire les configurations typiques de ses machines virtuelles. Bien que la majorité des types d'instances de cloud public soient censés accepter des machines virtuelles de votre centre de données, les types d'instances possibles peuvent être limités par le système d'exploitation.

Par exemple, pour les utilisations classiques, AWS limite les machines virtuelles 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 pour le calcul, la mémoire ou le stockage.

En fin de compte, il est important d'évaluer les limites de compatibilité de toute machine virtuelle potentielle par rapport à chaque fournisseur de cloud public et de prendre des mesures pour résoudre et résoudre 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 détecter les problèmes susceptibles d'interférer avec l'importation de la machine virtuelle ou de provoquer des problèmes une fois la machine virtuelle importée. Mais gardez à l'esprit que même avec une évaluation minutieuse et des processus rigoureux, certaines machines virtuelles refuseront toujours d'importer ou de fonctionner correctement dans le cloud public.

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.