Exigences relatives à AWS Server Migration Service - AWS Server Migration Service

Mise à jour produit

Il est recommandé :AWSApplication Migration Service(AWSMGN) en tant que service de migration principal pour lift-and-shift Migration. SiAWSMGN n'est pas disponible dans unAWS, vous pouvez utiliser laAWS SMSAPIjusqu'en mars 2023.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Exigences relatives à AWS Server Migration Service

Votre environnement VMware vSphere, Microsoft Hyper-V/SCVMM ou Microsoft Azure doit respecter les exigences suivantes pour pouvoir utiliser Server Migration Service afin de migrer vos serveurs virtualisés sur site vers Amazon EC2.

Conditions requises générales

Avant de configurer AWS SMS, assurez-vous d'avoir fait le nécessaire pour répondre à l'ensemble des exigences suivantes.

Tous les VMs

  • Désactivez tout logiciel anti-virus ou de détection d'intrusions sur la machine virtuelle que vous migrez. Ces services peuvent être réactivés une fois le processus de migration terminé.

  • Déconnectez tous les lecteurs de CD-ROM (virtuels ou physiques) connectés à la machine virtuelle.

Machines virtuelles Windows

  • Activez Bureau à distance (Remote Desktop, RDP) pour un accès distant.

  • Installez la version appropriée de .NET Framework sur la machine virtuelle. Notez que .NET Framework 4.5 ou supérieur est installé automatiquement sur votre machine virtuelle si nécessaire.

    Version Windows Version .NET Framework
    Windows Server 2008 ou version antérieure 3.5 ou version ultérieure
    Windows Server 2008 R2 ou version ultérieure 4.5 ou version ultérieure
    Windows 8 ou version antérieure 3.5 ou version ultérieure
    Windows 8.1 ou version ultérieure 4.5 ou version ultérieure
  • Pendant la préparation d'une machine virtuelle Microsoft Windows à la migration, configurez une taille de fichier d'échange fixe et assurez-vous d'avoir au moins 6 Gio d'espace disponible sur le volume racine. Ceci est nécessaire pour que les pilotes soient correctement installés.

  • Assurez-vous que le pare-feu hôte (comme le pare-feu Windows) autorise l'accès à RDP. Autrement, vous serez dans l'incapacité d'accéder à votre instance une fois la migration terminée.

  • Appliquez les correctifs logiciels suivants :

  • Les types d'instances suivants sont les seuls qui prennent en charge les AMIs 32 bits : t2.nano, t2.micro, t2.small, t2.medium, c3.large, t1.micro, m1.small, m1.medium et c1.medium. Si vous migrez une instance 32 bits, vous êtes limité à ces types d'instance et aux régions qui les prennent en charge.

Machines virtuelles Linux

  • Activez Secure Shell (SSH) pour un accès distant.

  • Assurez-vous que le pare-feu hôte (comme iptables) autorise l'accès à SSH. Autrement, vous serez dans l'incapacité d'accéder à votre instance une fois la migration terminée.

  • Assurez-vous que vous avez configuré un utilisateur non-racine pour utiliser SSH basé sur une clé publique afin d'accéder à votre instance après son importation. L'utilisation du SSH basé sur un mot de passe et la connexion racine via SSH sont possibles, mais nous ne le recommandons pas. Nous recommandons d'utiliser des clés publiques et un utilisateur non-racine car ceux-ci sont plus sécurisés. Votre machine virtuelle Linux ne disposera pas d'unec2-usercompte créé dans le cadre du processus de migration.

  • Assurez-vous que votre machine virtuelle Linux utilise GRUB (GRUB hérité) ou GRUB 2 comme chargeur de démarrage.

  • Veillez à ce que le volume racine de votre machine virtuelle Linux utilise l'un des systèmes de fichiers suivants :

    • EXT2

    • EXT3

    • EXT4

    • Btrfs

    • JFS

    • XFS

  • Les machines virtuelles Linux migrées doivent utiliser des images 64 bits. La migration d'images Linux 32 bits n'est pas prise en charge.

  • Les machines virtuelles Linux migrées doivent utiliser des noyaux par défaut pour de meilleurs résultats. La migration de machines virtuelles qui utilisent des noyaux Linux personnalisés risque d'échouer.

  • Lorsque vous préparez des machines virtuelles Amazon EC2 Linux pour la migration, assurez-vous d'avoir au moins 250 MiB d'espace disque disponible sur le volume racine pour installer les pilotes et les autres logiciels.

Modifications par programmation apportées aux machines virtuelles

Lors de l'importation d'une machine virtuelle,AWSmodifie le système de fichiers pour rendre la VM importée accessible au client. Les actions suivantes peuvent avoir lieu :

  • [Linux] Installation de pilotes PV Citrix directement dans le système d'exploitation ou modification de initrd/initramfs pour les contenir.

  • [Linux] Modification des scripts réseau pour remplacer les adresses IP statiques par des adresses IP dynamiques.

  • [Linux] Modification de /etc/fstab, en mettant en commentaire les entrées non valides et en remplaçant les noms d'appareil par des UUID. Si aucun UUID correspondant n'est trouvé pour un appareil, l'option nofail est ajoutée à la description de l'appareil. Vous devrez corriger les noms d'appareil et supprimer nofail après l'importation. Comme bonne pratique lors de la préparation de vos machines virtuelles pour l'importation, nous vous recommandons d'utiliser des UUID pour spécifier vos périphériques de disques de machine virtuelle plutôt que des noms d'appareil.

    Les entrées dans /etc/fstab qui contiennent des types de système de fichiers distribués (cifs, smbfs, vboxsf, sshfs, etc.) seront désactivées.

  • [Linux] Modification de paramètres de programme d'amorçage grub, comme le délai d'attente et l'entrée par défaut.

  • [Windows] Modification des paramètres du registre pour rendre la machine virtuelle démarrable.

Lorsque vous écrivez un fichier modifié,AWSconserve le fichier d'origine au même emplacement sous un nouveau nom.

Operating systems

Les systèmes d'exploitation suivants peuvent être migrés vers EC2 à l'aide de SMS :

Windows (32 bits et 64 bits)

  • Microsoft Windows Server 2003 (Standard, Datacenter, Enterprise) avec le Service Pack 1 (SP1) ou ultérieur (32 et 64 bits)

  • Microsoft Windows Server 2003 R2 (Standard, Datacenter, Enterprise) (32 et 64 bits)

  • Microsoft Windows Server 2008 (Standard, Datacenter, Enterprise) (32 et 64 bits)

  • Microsoft Windows Server 2008 R2 (Standard, Web Server, Datacenter, Enterprise) (64 bits uniquement)

  • Microsoft Windows Server 2012 (Standard, Datacenter) (64 bits uniquement)

  • Microsoft Windows Server 2012 R2 (Standard, Datacenter) (64 bits uniquement) (installation de serveur Nano non prise en charge)

  • Microsoft Windows Server 2016 (Standard, Datacenter) (64 bits uniquement)

  • Microsoft Windows Server 1709 (Standard, Datacenter) (64 bits uniquement)

  • Microsoft Windows Server 1803 (Standard, Datacenter) (64 bits uniquement)

  • Microsoft Windows Server 2019 (Standard, Datacenter) (64 bits uniquement)

  • Microsoft Windows 7 (Famille, Professionnel, Entreprise, Édition Intégrale) (Français, France) (32 et 64 bits)

  • Microsoft Windows 8 (Famille, Professionnel, Entreprise) (Français, France) (32 et 64 bits)

  • Microsoft Windows 8.1 (Professionnel, Entreprise) (Français, France) (64 bits uniquement)

  • Microsoft Windows 10 (Famille, Professionnel, Entreprise, Education) (Français, France) (64 bits uniquement)

Linux/Unix (64 bits)

  • Ubuntu 12.04, 12.10, 13.04, 13.10, 14.04, 14.10, 15.04, 16.04, 16.10, 17.04, 18.04

  • Red Hat Enterprise Linux (RHEL) 5.1-5.11, 6.1-6.9, 7.0-7.6 (6.0 ne dispose pas des pilotes requis)

  • SUSE Linux Enterprise Server 11 avec le Service Pack 1 et le noyau 2.6.32.12-0.7

  • SUSE Linux Enterprise Server 11 avec le Service Pack 2 et le noyau 3.0.13-0.27

  • SUSE Linux Enterprise Server 11 avec le Service Pack 3 et le noyau 3.0.76-0.11, 3.0.101-0.8 ou 3.0.101-0.15

  • SUSE Linux Enterprise Server 11 avec le Service Pack 4 et le noyau 3.0.101-63

  • SUSE Linux Enterprise Server 12 avec le noyau 3.12.28-4

  • SUSE Linux Enterprise Server 12 avec le Service Pack 1 et le noyau 3.12.49-11

  • SUSE Linux Enterprise Server 12 avec le Service Pack 2 et le noyau 4.4

  • SUSE Linux Enterprise Server 12 avec le Service Pack 3 et le noyau 4.4

  • CentOS 5.1-5.11, 6.1-6.6, 7.0-7.6 (6.0 ne dispose pas des pilotes requis)

  • Debian 6.0.0-6.0.8, 7.0.0-7.8.0, 8.0.0

  • Oracle Linux 5.10-5.11 avec suffixe de noyau el5uek

  • Oracle Linux 6.1-6.10 avec noyau compatible RHEL 2.6.32 ou noyaux UEK 3.8.13, 4.1.12

  • Oracle Linux 7.0-7.6 avec noyau compatible RHEL 3.10.0 ou noyaux UEK 3.8.13, 4.1.12, 4.14.35

  • Fedora Server 19-21

Types de volumes et systèmes de fichiers

AWS Server Migration Service prend en charge la migration d'instances Windows et Linux avec les systèmes de fichiers suivants :

Système d'exploitation Système de fichiers Architecture Table de partition Types de données pris en charge Volumes de démarrage pris en
Windows NTFS 32 bits MBR
GPT
64 bits MBR
GPT ✔ (VHDX uniquement)
ReFS 32 bits MBR
GPT
64 bits MBR
GPT
Linux/Unix Ext2, ext3, ext4, Btrfs, JFS, XFS 64 bits MBR
GPT

Les AMI avec des volumes utilisant le chiffrement EBS ne sont pas prises en charge. Lors de la migration des serveurs avec AWS SMS, n’activez pas le chiffrement par défaut. Si le chiffrement par défaut est déjà activé et que vous rencontrez des échecs de réplication delta, désactivez cette fonction.

Configurer un utilisateur IAM pour Server Migration Connector

Pour créer un utilisateur IAM pour Server Migration Connector dans votreAWScompte

  1. Créez un utilisateur IAM avec lequel votre connecteur peut communiquer avecAWS. Enregistrez la clé d'accès et la clé secrète générées pour les utiliser au cours de la configuration initiale du connecteur. Pour plus d'informations sur la gestion des utilisateurs et des autorisations IAM, consultezCréation d'un utilisateur IAM dans votreAWSCompte.

  2. Attachez la stratégie gérée IAMServerMigrationConnectorpour l'utilisateur IAM. Pour en savoir plus, consultez Stratégies gérées et stratégies en ligne.

Limites

Les limites suivantes s'appliquent.

Format d'image

  • Lors de la migration de machines virtuelles gérées par Hyper-V/SCVMM, SMS prend en charge les machines virtuelles de génération 1 (utilisant le format de disque VHD ou VHDX) et de génération 2 (VHDX uniquement).

  • AWS SMS ne prend pas en charge les machines virtuelles sur Hyper-V exécutant n'importe quelle version de RHEL 5 basée sur un disque VHDX. Nous vous recommandons de convertir les disques de ce format en VHD pour la migration.

  • AWS SMS ne prend pas en charge les machines virtuelles qui combinent des fichiers au format de disque VHD et VHDX.

  • Sur VMware, AWS SMS ne prend pas en charge les machines virtuelles qui utilisent RDM (Raw Device Mapping). Seules les images de disque VMDK sont prises en charge.

Démarrage

  • Les partitions de démarrage UEFI/EFI sont prises en charge uniquement pour les volumes de démarrage Windows avec VHDX comme format d'image. Sinon, le volume de démarrage d'une machine virtuelle doit utiliser des partitions MBR (enregistrement de démarrage principal). Dans les deux cas, le volume de démarrage ne peut pas dépasser 2 Tio (non compressé) en raison de limitations liées à MBR.

    Note

    QuandAWSdétecte un volume de démarrage GPT Windows avec une partition de démarrage UEFI, il le convertit on-the-fly sur un volume de démarrage MBR avec une partition de démarrage BIOS. Cela est dû au fait qu'EC2 ne prend pas directement en charge les volumes de démarrage GPT.

  • Une machine virtuelle importée peut ne pas démarrer si la partition racine ne se trouve pas sur le même disque dur virtuel que le MBR.

  • Une machine virtuelle migrée peut ne pas démarrer si la partition racine ne se trouve pas sur le même disque dur virtuel que le MBR.

  • La migration de machines virtuelles avec des configurations à double démarrage n'est pas prise en charge.

Réseaux

  • Les interfaces réseau multiples ne sont pas prises en charge actuellement. Une fois la migration terminée, votre machine virtuelle aura une seule interface réseau virtuelle qui utilise DHCP pour attribuer des adresses. Votre instance reçoit une adresse IP privée.

  • Une VM migrée dans un VPC ne reçoit pas d'adresse IP publique, quel que soit le réglage d'auto-attribution d'adresse IP publique pour le sous-réseau. Sinon, vous pouvez attribuer une adresse IP Elastic à votre compte et l'associer à votre instance.

  • Les adresses IP Internet Protocol version 6 (IPv6) ne sont pas prises en charge.

Importation d'applications depuis Migration Hub

  • SMS importe les serveurs liés aux applications depuis AWS Migration Hub uniquement s'ils existent dans le catalogue de serveurs SMS. Par conséquent, certaines applications peuvent être importées partiellement uniquement.

  • Si aucun des serveurs d'une application Migration Hub n'existe dans le catalogue de serveurs SMS, l'importation échoue silencieusement et l'application n'est pas visible dans SMS.

  • Les applications importées peuvent être migrées, mais ne peuvent pas être modifiées dans SMS. Elles peuvent toutefois être modifiées dans Migration Hub.

Divers

  • Une tâche de réplication SMS échouera pour les machines virtuelles avec plus de 22 volumes attachés.

  • Les AMI avec des volumes utilisant le chiffrement EBS ne sont pas prises en charge. Lors de la migration des serveurs avec AWS SMS, n’activez pas le chiffrement par défaut. Si le chiffrement par défaut est déjà activé et que vous rencontrez des échecs de réplication delta, désactivez cette fonction.

  • AWS SMS crée des AMI qui utilisent la virtualisation HVM. Il ne peut pas créer d'AMI qui utilisent la virtualisation PV. Les pilotes PVHVM Linux sont pris en charge au sein des machines virtuelles migrées.

  • Les machines virtuelles qui sont créées suite à une conversion P2V ne sont pas prises en charge. Une conversion P2V a lieu lorsqu'une image de disque est créée en effectuant un processus d'installation Linux ou Windows sur une machine physique, puis en important une copie de cette installation Linux ou Windows dans une machine virtuelle.

  • AWS SMS n'installe pas les pilotes Single-Root I/O virtualization (SR-IOV), sauf avec les importations de machine virtuelles Microsoft Windows Server 2012 R2. Ces pilotes ne sont pas nécessaires, sauf si vous envisagez d'utiliser la mise en réseau améliorée qui offre des performances (paquet par seconde) plus élevées, ainsi qu'une instabilité et une latence réseau réduites. Pour les machines virtuelles Microsoft Windows Server 2012 R2, les pilotes SR-IOV sont installés automatiquement dans le cadre du processus de migration.

  • Les disques indépendants n'étant pas affectés par les instantanés, AWS SMS ne prend pas en charge la réplication avec intervalle pour les VMDK en mode indépendant.

  • Les packs de langues Windows qui utilisent des caractères UTF-16 (ou non-ASCII) ne sont pas pris en charge pour l'importation. Nous vous recommandons d'utiliser le pack de langue anglaise lors de l'importation de machines virtuelles Windows Server 2003, Windows Server 2008 et Windows Server 2012 R1.

  • Pour Windows Server 2003, désactivez les vérifications de signature de pilote Windows avant la migration.

Options de licence pourAWS SMS

Lorsque vous créez une nouvelle tâche de réplication, leAWS Server Migration ServiceAPI etAWS CLIinclut une option License type. Si vous choisissez un type de licence incompatible avec votre VM, la tâche de réplication échoue et un message d'erreur apparaît. Les valeurs possibles sont :

  • Auto (par défaut)

    Détecte le système d'exploitation (OS) source-système et applique la licence adéquate à la machine virtuelle (VM) migrée.

  • AWS

    Remplace la licence du système source par unAWSlicence, le cas échéant, sur la VM migrée.

  • BYOL

    Conserve la licence source-système, le cas échéant, sur la VM migrée.

AWS CLIexemple :

aws sms create-replication-job --license-type value

La valeur du--license-typeparamètre peut êtreAWSouBYOL. La valeur par défaut est Auto.

Choix de licence pour Linux

Les systèmes d'exploitation Linux prennent en charge les licences BYOL uniquement. ChoixAuto(valeur par défaut) signifie que SMS utilise une licence BYOL.

Les machines virtuelles Red Hat Enterprise Linux (RHEL) migrées doivent utiliser des licences Cloud Access (BYOL). Pour plus d'informations, voir Red Hat Cloud Access sur le site Web de Red Hat.

Les machines virtuelles SUSE Linux Enterprise Server migrées doivent utiliser des licences SUSE Public Cloud Program (BYOS). Pour plus d'informations, consultez le document SUSE Public Cloud Program—Bring Your Own Subscription.

Choix de licence pour Windows

Les systèmes d'exploitation Windows Server prennent en charge BYOL ouAWSlicences. Les systèmes d'exploitation de client Windows (par exemple, Windows 10) prennent en charge les licences BYOL uniquement.

Si vous choisissezAuto(valeur par défaut),AWS SMSutilise leAWSsi la VM dispose d'un système d'exploitation de serveur. Si la VM dispose d'un système d'exploitation client, la licence BYOL est utilisée.

Les règles suivantes s'appliquent lorsque vous utilisez votre licence Microsoft BYOL, soit par MSDN, soit par Windows Software Assurance Per User :

  • Vos instances BYOL sont facturées selon la tarification des instances Linux Amazon EC2 en vigueur, dans la mesure où vous entrez dans les conditions suivantes :

    • Exécutez sur un hôte dédié (Hôtes dédiés)

    • Lancez depuis les VM provenant de binaires logiciels fournis par vous-même à l'aide d'AWS SMS, sujet aux termes et capacités actuels d'AWS SMS

    • Désignez les instances en tant qu'instance BYOL

    • Exécutez les instances au sein de votre instance désignéeAWSRégions et oùAWSpropose le modèle BYOL

    • Activez à l'aide des clés Microsoft que vous fournissez ou qui sont utilisées dans votre système de gestion de clé

  • Vous devez tenir compte du fait que lorsque vous démarrez une instance Amazon EC2, celle-ci peut s'exécuter sur n'importe quel des nombreux serveurs au sein d'une zone de disponibilité. Cela signifie que chaque fois que vous démarrez une instance Amazon EC2 (y compris avec un arrêt/démarrage), celle-ci peut s'exécuter sur un serveur différent au sein d'une zone de disponibilité. Vous devez tenir compte de ce fait en gardant à l'ESPRIT les limitations concernant la réaffectation de licence décrites dans les conditions relatives aux produits de licences en volume de Microsoft, disponibles sur l'Conditions de licence, ou consultez vos droits d'utilisation spécifiques pour déterminer si ceux-ci sont cohérents avec cette utilisation.

  • Vous devez être éligible pour utiliser le programme BYOL pour le logiciel Microsoft applicable dans le cadre de votre ou vos accords avec Microsoft, par exemple, dans le cadre de vos droits d'utilisateur MSDN ou de vos droits Windows Software Assurance par utilisateur. Vous assumez l'entière responsabilité d'obtenir toutes les licences requises et de vous conformer à toutes les exigences concernant les licences, y compris les PUR/PT. En outre, vous devez avoir accepté le Contrat de Licence Utilisateur Final de Microsoft (CLUF Microsoft), et en utilisant le logiciel Microsoft dans le cadre du programme BYOL, vous acceptez le CLUF Microsoft.

  • AWSvous recommande de consulter vos propres conseillers juridiques et autres pour comprendre les exigences relatives aux licences Microsoft applicables et vous y conformer. L'utilisation du paramètre Services (y compris l'utilisation du paramètre licenseType et de l'indicateur BYOL) en violation de vos accords avec Microsoft n'est pas autorisée.

Autres exigences

Prise en charge de VMware vMotion

AWS Server Migration Service prend partiellement en charge vMotion, Storage vMotion et d'autres fonctions basées sur la migration de machines virtuelles (comme DRS et Storage DRS) soumises aux limitations suivantes :

  • La migration d'une machine virtuelle vers un nouvel hôte ESXi ou un magasin de données une fois qu'un cycle de réplication est terminé et avant que le prochain cycle ne démarre, est prise en charge tant que le compte du service vCenter du Server Migration Connector du Server Migration Connector dispose des autorisations nécessaires sur l'hôte ESXi, les magasins de données et le centre de données et sur le machine virtuelle elle-même au nouvel emplacement.

  • La migration d'une machine virtuelle vers un nouvel hôte ESXi, un magasin de données et/ou un centre de données n'est pas prise en charge quand un cycle de réplication est en cours, c'est-à-dire pendant le chargement d'une machine virtuelle.

  • L'utilisation de Cross vCenter vMotion n'est pas prise en charge avecAWS SMS.

Prise en charge de VMware vSAN

Les machines virtuelles sur les magasins de données vSAN sont uniquement prises en charge lorsque le paramètre Replication job type de la page Configure replication jobs settings est défini sur One-time migration.

Prise en charge des volumes virtuels VMware (VVol)

AWSne prend pas en charge la migration des volumes virtuels VMware. Cependant, certaines implémentations peuvent fonctionner.

Machines virtuelles VMware avec des instantanés

AWS SMS prend en charge que la migration unique sur les machines virtuelles où un logiciel de sauvegarde basé sur un instantané est utilisé. De plus, évitez de créer des instantanés sur des machines virtuelles répliquées via AWS SMS.

Points de contrôle Hyper-V

AWS SMSne prend pas en charge les machines virtuelles dotées de points de contrôle existants.

Disque de différenciation Hyper-V

AWS SMSne prend pas en charge les machines virtuelles dotées de disques différenciés.