PlateSpin Migrate prend en charge la migration des workloads Windows et Linux suivants vers des plates-formes non-cloud, telles que des machines physiques et des machines virtuelles sur des hyperviseurs compatibles. Reportez-vous à la section Plates-formes de virtualisation cibles prises en charge.
Les fonctionnalités de migration prises en charge pour la migration vers des plates-formes non-cloud sont les suivantes :
Migrations homologue à homologue (P2V, V2V, V2P, P2P).
Synchronisation des workloads homologue à homologue (P2V, V2V, P2P, V2P).
REMARQUE :
tous les workloads ne sont pas pris en charge sur toutes les plates-formes de virtualisation cibles. La migration de workloads vers une plate-forme de virtualisation cible est soumise à la prise en charge du système d'exploitation invité sur l'hôte cible par le fournisseur de l'hôte.
Avant d'installer des pilotes de transfert par bloc sur les workloads Windows sources, assurez-vous d'avoir appliqué les dernières mises à jour Windows sur ces workloads.
Les workloads BIOS doivent avoir au moins une partition sur le disque de démarrage et un chargeur de démarrage installé dans le secteur d'amorçage principal (MBR).
La conversion d'un système Linux BIOS vers UEFI n'est pas prise en charge.
La conversion d'un workload UEFI Linux source en cible BIOS Linux requiert qu'une partition /boot soit disponible sur le workload source.
La création d'image de workload n'est pas prise en charge dans les workloads Linux.
Reportez-vous aux sections suivantes :
PlateSpin Migrate prend en charge les plates-formes Microsoft Windows suivantes pour la migration vers des machines virtuelles sur des hôtes de virtualisation ou vers des machines physiques, sauf indication contraire dans le Tableau 2-1. Reportez-vous également aux sections Stockage des workloads pris en charge et Architectures de workload prises en charge.
Tableau 2-1 Plates-formes non-cloud : workloads Windows pris en charge
|
Système d'exploitation |
Remarques |
|---|---|
|
Serveurs |
|
|
Windows Server 2016 |
La migration vers une VM VMware nécessite VMware vCenter 6.0 ou version ultérieure. |
|
|
|
Y compris les systèmes DC (contrôleur de domaine) et les versions SBS (Small Business Server). Ne prend pas en charge la migration de Windows Server 2008 R2 SP0 vers Hyper-V, étant donné que Microsoft ne la prend plus en charge. Reportez-vous au site Web TechNet de Microsoft. |
|
|
|
Grappes |
|
|
Grappe (Cluster) Windows Server 2016 Prend en charge les modèles de quorum :
|
L'interface Web et le client Migrate prennent en charge la migration automatisée de grappes Windows vers des plates-formes de virtualisation VMware vCenter. Le client Migrate prend également en charge la migration semi-automatisée des grappes Windows vers des machines physiques à l'aide du workflow X2P. Reportez-vous à la section Préparation de la migration de grappes Windows. La migration de grappes Windows Server 2016 vers VMware nécessite VMware 6.0 ou version ultérieure. PlateSpin Migrate ne prend pas en charge la migration de grappes Windows Server pour les infrastructures cibles suivantes :
PlateSpin Migrate prend en charge uniquement la réplication par bloc pour les grappes. La réplication par fichier n'est pas prise en charge. PlateSpin Migrate fournit des méthodes de transfert par bloc sans pilote et avec pilote. Reportez-vous à la section Transfert par bloc pour les grappes. PlateSpin Migrate prend en charge l'utilisation de disques RDM (Raw Device Mapping) partagés (SAN FC) sur les machines virtuelles cibles pour la migration semi-automatisée d'une grappe de basculement Windows Server (WSFC) vers VMware, où chaque noeud de machine virtuelle cible se trouve sur un hôte différent dans une grappe VMware. Reportez-vous à la section Migration avancée de grappe Windows vers des machines virtuelles VMware comportant des disques RDM. |
Prend en charge les modèles de quorum :
|
|
Prend en charge les modèles de quorum :
|
|
Prend en charge le modèle de quorum :
|
|
|
Postes de travail |
|
|
Windows 8 et 8.1 |
Nécessite le mode de gestion de l'alimentation Performances élevées. |
|
Windows 7 |
Prend en charge uniquement les éditions Professionnel, Enterprise et Intégrale. |
PlateSpin Migrate prend en charge les plates-formes Linux suivantes pour la migration vers des machines virtuelles sur des hôtes de virtualisation ou vers des machines physiques, sauf indication contraire dans le Tableau 2-2. Reportez-vous également aux sections Stockage des workloads pris en charge et Architectures de workload prises en charge.
Tableau 2-2 Plates-formes non-cloud : workloads Linux pris en charge
|
Distribution Linux |
Versions |
Remarques |
|---|---|---|
|
Red Hat Enterprise Linux (RHEL) |
AS/ES/WS 4.x, 5.0 à 5.11, 6.0 à 6.9 et 7.0 à 7.5 |
Pour les workloads Red Hat Enterprise Linux 6.7, Oracle Linux 6.7 et CentOS 6.7 avec des volumes LVM, PlateSpin Migrate prend en charge une réplication incrémentielle uniquement pour la dernière version du kernel disponible (version 2.6.32-642.13.1.el6.) pour la distribution 6.7. Pour les workloads Red Hat Enterprise Linux 6.8, Oracle Linux 6.8 et CentOS 6.8 avec des volumes LVM, PlateSpin Migrate prend en charge une réplication incrémentielle uniquement pour la dernière version du kernel disponible (version 2.6.32-696.20.1.el6.x86_64) pour la distribution 6.8. La migration d'un workload source paravirtualisé vers une plate-forme cible en tant que workload entièrement virtualisé est prise en charge pour RHEL 5. Reportez-vous à la section Workloads sources paravirtualisés. |
|
SUSE Linux Enterprise Server (SLES) |
9, 10, 11 (SP1, SP2, SP3 et SP4) |
SLES 11 SP2 (32 bits) avec kernel 3.0.13-0.27-pae n'est pas pris en charge. Le kernel de cette version de SLES doit être mis à niveau vers 3.0.51-0.7.9-pae afin que la conversion fonctionne. La migration d'un workload source paravirtualisé vers une plate-forme cible en tant que workload entièrement virtualisé est prise en charge pour SLES 10 et 11. Reportez-vous à la section Workloads sources paravirtualisés. La migration d'un workload source SLES 11 SP4 32 bits vers une cible Hyper-V n'est pas prise en charge. |
|
CentOS |
Voir Red Hat Enterprise Linux. |
Même niveau de prise en charge que pour les workloads exécutant RHEL si ce n'est que CentOS 4.x n'est pas pris en charge pour Hyper-V. La migration de CentOS 7.x vers VMware nécessite VMware vCenter 5.5 ou version ultérieure. |
|
Oracle Linux (OL) (anciennement Oracle Enterprise Linux) |
Voir Red Hat Enterprise Linux. |
Même niveau de prise en charge pour les kernels standard que pour les workloads exécutant RHEL si ce n'est qu'OEL 4.x n'est pas pris en charge pour Hyper-V. Même niveau de prise en charge pour les kernels UEK (Unbreakable Enterprise Kernel) sur les distributions RHEL prises en charge pour OL 6.7 et versions ultérieures. |
Utilisez l'interface Web de PlateSpin Migrate pour migrer les workloads vers Amazon Web Services, Microsoft Azure, VMware vCloud Director et VMware Cloud sur AWS.
Migrate prend en charge les migrations P2C et V2C vers des plates-formes cloud cibles. Migration prend en charge les migrations C2C de workloads sources entre des plates-formes cloud prises en charge. Pour plus d'informations sur les scénarios de déploiement C2C direct pris en charge, reportez-vous au Section 12.0, Conditions préalables pour les migrations de cloud à cloud.
REMARQUE :
Tous les workloads ne sont pas pris en charge sur toutes les plates-formes cloud cibles. La migration de workloads vers une plate-forme cloud est soumise à la prise en charge du système d'exploitation invité sur la plate-forme cloud cible par le fournisseur de services cloud.
Avant d'installer des pilotes de transfert par bloc sur les workloads Windows sources, assurez-vous d'avoir appliqué les dernières mises à jour Windows sur ces workloads.
Les workloads BIOS doivent avoir au moins une partition sur le disque de démarrage et un chargeur de démarrage installé dans le secteur d'amorçage principal (MBR).
Les workloads UEFI Windows et Linux sont migrés en tant que workloads UEFI vers les plates-formes vCloud cibles. Toutefois, pour les autres plates-formes cloud cibles, comme Azure et AWS, qui ne prennent pas en charge les workloads UEFI, les workloads UEFI Windows et Linux sont migrés en tant que workloads BIOS.
La conversion d'un workload UEFI Linux source en cible BIOS Linux requiert qu'une partition /boot soit disponible sur le workload source.
Avant de migrer un workload source Linux paravirtualisé en cours d'exécution sous Citrix XenServer ou KVM vers une plate-forme cible en tant qu'invité entièrement virtualisé, consultez la section Workloads sources paravirtualisés.
Reportez-vous aux sections suivantes :
PlateSpin Migrate prend en charge les plates-formes suivantes pour la migration vers Amazon Web Services. Reportez-vous également aux sections Section 2.1.3, Stockage des workloads pris en charge et Section 2.1.4, Architectures de workload prises en charge.
Pour plus d'informations sur la migration de workloads vers Amazon Web Services, reportez-vous aux parties suivantes :
Tableau 2-3 AWS : plates-formes Windows prises en charge
|
Système d'exploitation |
Remarques |
|---|---|
|
Microsoft Windows Server 2016 |
|
|
Microsoft Windows Server 2012 R2 |
|
|
Microsoft Windows Server 2012 |
|
|
Microsoft Windows Server 2008 R2 |
|
|
Microsoft Windows Server 2008 |
|
|
Microsoft Windows Server 2003 R2 |
|
|
Microsoft Windows Server 2003 avec le Service Pack 1 ou une version ultérieure |
|
Tableau 2-4 AWS : plates-formes Linux prises en charge
|
Distribution Linux |
Versions |
Remarques |
|---|---|---|
|
Red Hat Enterprise Linux (RHEL) |
5.1 à 5.11, 6.1 à 6.9 et 7.0 à 7.5 |
Pour les workloads Red Hat Enterprise Linux 6.7, Oracle Linux 6.7, CentOS 6.7 avec des volumes LVM, une réplication incrémentielle est prise en charge uniquement pour la dernière version du kernel disponible (version 2.6.32-642.13.1.el6) pour la distribution 6.7. Pour les workloads Red Hat Enterprise Linux 6.8, Oracle Linux 6.8 et CentOS 6.8 avec des volumes LVM, PlateSpin Migrate prend en charge une réplication incrémentielle uniquement pour la dernière version du kernel disponible (version 2.6.32-696.20.1.el6.x86_64) pour la distribution 6.8. La migration d'un workload source paravirtualisé vers une plate-forme cible en tant que workload entièrement virtualisé est prise en charge pour RHEL 5. Reportez-vous à la section Workloads sources paravirtualisés. |
|
SUSE Linux Enterprise Server (SLES) |
11 (SP1 à SP4) |
La migration d'un workload source paravirtualisé vers une plate-forme cible en tant que workload entièrement virtualisé est prise en charge pour SLES 11. Reportez-vous à la section Workloads sources paravirtualisés. |
|
CentOS |
Voir Red Hat Enterprise Linux. |
Même niveau de prise en charge que pour les workloads exécutant RHEL. |
|
Oracle Linux (OL) (anciennement Oracle Enterprise Linux) |
Voir Red Hat Enterprise Linux. |
Même niveau de prise en charge pour les kernels standard que pour les workloads exécutant RHEL. Même niveau de prise en charge pour les kernels UEK (Unbreakable Enterprise Kernel) sur les distributions RHEL prises en charge pour OL 6.7 et versions ultérieures. |
PlateSpin Migrate prend en charge les plates-formes suivantes pour la migration vers Microsoft Azure Cloud pour l'environnement global et l'environnement Azure Chine souverain. Reportez-vous également aux sections Stockage des workloads pris en charge et Architectures de workload prises en charge.
Pour plus d'informations sur la migration de workloads vers Microsoft Azure, reportez-vous aux parties suivantes :
Tableau 2-5 Azure : plates-formes Windows prises en charge
|
Système d'exploitation |
Remarques |
|---|---|
|
Microsoft Windows Server 2016 |
|
|
Microsoft Windows Server 2012 R2 |
|
|
Microsoft Windows Server 2012 |
|
|
Microsoft Windows Server 2008 R2 |
|
Tableau 2-6 Azure : plates-formes Linux prises en charge
|
Distribution Linux |
Versions |
Remarques |
|---|---|---|
|
Red Hat Enterprise Linux (RHEL) |
6.7 à 6.9 et 7.1 à 7.5 |
Pour les workloads Red Hat Enterprise Linux 6.7, Oracle Linux 6.7, CentOS 6.7 avec des volumes LVM, une réplication incrémentielle est prise en charge uniquement pour la dernière version du kernel disponible (version 2.6.32-642.13.1.el6) pour la distribution 6.7. Pour les workloads Red Hat Enterprise Linux 6.8, Oracle Linux 6.8 et CentOS 6.8 avec des volumes LVM, PlateSpin Migrate prend en charge une réplication incrémentielle uniquement pour la dernière version du kernel disponible (version 2.6.32-696.20.1.el6.x86_64) pour la distribution 6.8. |
|
SUSE Linux Enterprise Server (SLES) |
11 (SP3 et SP4) |
La migration d'un workload source paravirtualisé vers une plate-forme cible en tant que workload entièrement virtualisé est prise en charge pour SLES 11. Reportez-vous à la section Workloads sources paravirtualisés. |
|
CentOS |
Voir Red Hat Enterprise Linux. |
Même niveau de prise en charge que pour les workloads exécutant RHEL. |
|
Oracle Linux (OL) (anciennement Oracle Enterprise Linux) |
Voir Red Hat Enterprise Linux. |
Même niveau de prise en charge pour les kernels standard que pour les workloads exécutant RHEL. Même niveau de prise en charge pour les kernels UEK (Unbreakable Enterprise Kernel) sur les distributions RHEL prises en charge pour OL 6.7 et versions ultérieures. |
REMARQUE :Si la partition de démarrage (/boot) se trouve sur un autre disque que celui de la partition root (/), PlateSpin Migrate migre les deux partitions vers le premier disque sur la machine virtuelle cible dans Azure.
PlateSpin Migrate prend en charge les plates-formes suivantes pour la migration vers VMware vCloud Director. Reportez-vous également aux sections Section 2.1.3, Stockage des workloads pris en charge et Section 2.1.4, Architectures de workload prises en charge.
Pour plus d'informations sur la migration des workloads vers VMware Cloud Director, reportez-vous aux parties suivantes :
Tableau 2-7 vCloud : plates-formes Windows prises en charge
|
Système d'exploitation |
Remarques |
|---|---|
|
Microsoft Windows Server 2016 |
Requiert vCloud 8.20 ou version ultérieure. Les hôtes de sauvegarde de la réserve de ressources VMware doivent prendre en charge les machines virtuelles avec du matériel version 10 ou ultérieure. La stratégie VDC du fournisseur pour la version matérielle la plus récente prise en charge doit être définie au moins sur la version de matériel 10. |
|
Microsoft Windows Server 2012 R2 |
|
|
Microsoft Windows Server 2012 |
|
|
Microsoft Windows Server 2008 R2 |
|
|
Microsoft Windows Server 2008 |
|
|
Microsoft Windows Server 2003 R2 |
Le paramètre DoNotReplaceSysFiles doit être défini sur True. |
|
Microsoft Windows Server 2003 avec le Service Pack 1 ou une version ultérieure |
Le paramètre DoNotReplaceSysFiles doit être défini sur True. |
Tableau 2-8 vCloud : plates-formes Linux prises en charge
|
Distribution Linux |
Versions |
Remarques |
|---|---|---|
|
Red Hat Enterprise Linux (RHEL) |
4.x, 5.0 à 5.11, 6.0 à 6.9 et 7.0 à 7.5 |
Migrate prend en charge le système de fichiers XFS v5 sur les workloads UEFI Linux sources pour les migrations utilisant l'environnement PRE vCloud basé sur SLES 12 SP3. En revanche, Migrate ne prend pas en charge XFS v5 sur les workloads BIOS Linux sources migrés à l'aide de l'environnement PRE vCloud basé sur SLES 11 SP4. Pour les workloads Red Hat Enterprise Linux 6.7, Oracle Linux 6.7, CentOS 6.7 avec des volumes LVM, une réplication incrémentielle est prise en charge uniquement pour la dernière version du kernel disponible (version 2.6.32-642.13.1.el6) pour la distribution 6.7. Pour les workloads Red Hat Enterprise Linux 6.8, Oracle Linux 6.8 et CentOS 6.8 avec des volumes LVM, PlateSpin Migrate prend en charge une réplication incrémentielle uniquement pour la dernière version du kernel disponible (version 2.6.32-696.20.1.el6.x86_64) pour la distribution 6.8. La migration d'un workload source paravirtualisé vers une plate-forme cible en tant que workload entièrement virtualisé est prise en charge pour RHEL 5. Reportez-vous à la section Workloads sources paravirtualisés. La migration des workloads Red Hat Enterprise Linux 7.x est prise en charge uniquement vers VMware vCloud Director 5.5.x, 5.6.x et 9.1. |
|
SUSE Linux Enterprise Server (SLES) |
10 et 11 (SP1, SP2, SP3 et SP4) |
La migration d'un workload source paravirtualisé vers une plate-forme cible en tant que workload entièrement virtualisé est prise en charge pour SLES 10 et 11. Reportez-vous à la section Workloads sources paravirtualisés. |
|
CentOS |
Voir Red Hat Enterprise Linux. |
Même niveau de prise en charge que pour les workloads exécutant RHEL. |
|
Oracle Linux (OL) (anciennement Oracle Enterprise Linux) |
Voir Red Hat Enterprise Linux. |
Même niveau de prise en charge pour les kernels standard que pour les workloads exécutant RHEL. Même niveau de prise en charge pour les kernels UEK (Unbreakable Enterprise Kernel) sur les distributions RHEL prises en charge pour OL 6.7 et versions ultérieures. |
Pour la migration vers VMware Cloud sur AWS, PlateSpin Migrate prend en charge les mêmes plates-formes que pour la migration de grappes DRS VMware vers VMware. Reportez-vous à la section Section 2.1.1, Workloads sources pris en charge pour la migration vers des plates-formes non-cloud.
Reportez-vous également aux sections Section 2.1.3, Stockage des workloads pris en charge et Section 2.1.4, Architectures de workload prises en charge.
Pour plus d'informations sur la migration des workloads vers VMware Cloud sur AWS, reportez-vous aux parties suivantes :
Les directives de stockage de workloads suivantes s'appliquent à toutes les migrations :
PlateSpin Migrate prend en charge les modèles de partitionnement MBR (Master Boot Record) et GPT (GUID Partition Table) pour les workloads Windows et Linux. Les workloads et le stockage pour la migration doivent être configurés sur des disques partitionnés avec le modèle MBR ou GPT. Bien que GPT autorise jusqu'à 128 partitions par disque, PlateSpin Migrate prend en charge un maximum de 57 partitions GPT par disque.
PlateSpin Migrate ne prend en charge le système de fichiers NTFS que sur les systèmes Windows compatibles. Il ne prend pas en charge les systèmes de fichiers Windows FAT ou ReFS pour la migration.
REMARQUE :si les volumes sont codés avec la fonctionnalité de chiffrement de disque BitLocker, ils doivent être déverrouillés (déchiffrés) pour la migration.
PlateSpin Migrate prend en charge les systèmes de fichiers EXT2, EXT3, EXT4, REISERFS et XFS.
REMARQUE :
PlateSpin Migrate prend en charge le système de fichiers XFS version 5 (v5) sous RHEL 7.3 et versions ultérieures et sur les distributions basées sur ces versions. Toutefois, la prise en charge de XFS v5 ne s'applique pas aux workloads BIOS sur les plates-formes VMware vCloud cibles.
La migration des volumes codés n'est pas prise en charge. Si les volumes sont chiffrés, ils doivent être déverrouillés (déchiffrés) pour la migration.
PlateSpin Migrate prend en charge plusieurs types de disques de stockage, notamment des disques de base, des disques dynamiques Windows sources, mais aussi LVM2, RAID matériel, NAS et SAN.
REMARQUE :les avertissements suivants s'appliquent pour les disques de stockage :
Disques dynamiques Windows : PlateSpin Migrate ne prend pas en charge les disques dynamiques Windows sur la cible.
Pour les disques dynamiques, le stockage ne respecte pas la stratégie d'assignation Identique à la source. Tant les volumes dynamiques simples que les volumes dynamiques fractionnés résident sur le workload cible en tant que disques de volumes de base simples. Le disque cible est partitionné en tant que GPT si la taille totale combinée des disques membres du volume dynamique dépasse la limite de taille de partition MBR. Pour plus d'informations, reportez-vous au document Microsoft TechNet: Understanding the 2 TB limit in Windows Storage (Microsoft TechNet : présentation de la limite de 2 To du stockage Windows).
RAID logiciel : PlateSpin Migrate prend en charge le RAID matériel, mais pas le RAID logiciel. Cela s'applique aux workloads Windows et Linux.
La migration prend en charge les chargeurs de démarrage GRUB et GRUB 2 pour les workloads Linux.
Migrate prend en charge les workloads Linux dont le volume /boot est situé sur le premier disque (sda).
La partition de démarrage d'un workload Linux source doit disposer d'au moins 100 Mo d'espace libre. Au cours du processus de migration, PlateSpin Migrate utilise l'espace disponible pour créer une image initrd avec tous les pilotes requis afin que la machine soit prête pour le processus de démarrage initial.
Une zone de stockage (autre qu'un volume), telle qu'une partition d'échange associée au workload source, est recréée dans le workload migré.
La disposition des groupes de volumes et des volumes logiques pour LVM2 est conservée dans la stratégie d'assignation Identique à la source, de sorte que vous pouvez la recréer pendant la migration.
Les volumes de disques bruts LVM sont pris en charge de la même manière que les configurations sources sur les workloads Linux.
Pour les workloads Linux, Migrate prend uniquement en charge le transfert de données à chaud par bloc avec un pilote blkwatch. Pour obtenir une liste des pilotes blkwatch précompilés, reportez-vous à la Section E.2.2, Liste des distributions.
Certaines des versions de Linux prises en charge requièrent la compilation du module blkwatch PlateSpin pour votre kernel spécifique. Ces workloads sont appelés explicitement.
Les pilotes blkwatch précompilés sont disponibles pour le kernel standard et les kernels UEK (Unbreakable Enterprise Kernel) comme indiqué à la Section E.2.2, Liste des distributions. Pour les autres distributions Linux d'Oracle, des pilotes précompilés sont disponibles uniquement pour le kernel Red Hat compatible correspondant (RHCK).
PlateSpin Migrate prend en charge le protocole de communication SAN FC (Fibre Channel).
FCoE (Fibre Channel over Ethernet) est pris en charge pour les migrations P2P et P2V pour les workloads répertoriés dans le Tableau 2-9. La migration a été testée à l'aide de périphériques FCoE de Qlogic.
Tableau 2-9 Workloads sources pris en charge pour FCoE
|
Workloads sources avec FCoE |
Version |
Remarques |
|---|---|---|
|
|
Serveurs autonomes uniquement ; aucune grappe. |
|
SUSE Linux Enterprise Server |
11 SP4 |
|
Les pilotes FCoE et les fonctionnalités de prise en charge sont disponibles dans l'image ISO PlateSpin. Reportez-vous à la section Téléchargement des images ISO PlateSpin.
PlateSpin Migrate prend en charge la migration d'un workload source configuré pour MPIO (Multipath I/O) dans un environnement SAN FC. Le workload cible peut se trouver dans le même environnement SAN ou dans un autre. Les workloads source et cible doivent disposer de tous les disques SAN.
REMARQUE :le workload doit démarrer à partir d'un disque SAN. Les workloads comportant un mélange de disques locaux et SAN ne sont pas pris en charge, sauf indication contraire dans le Tableau 2-10.
La fonctionnalité de prise en charge de MPIO est disponible dans l'image ISO PlateSpin. Reportez-vous à la section Téléchargement des images ISO PlateSpin.
Reportez-vous au Tableau 2-10 pour obtenir la liste des plates-formes qui ont été testées pour les migrations dans des environnements MPIO.
Tableau 2-10 Workloads sources pris en charge pour MPIO
|
Plate-forme |
Versions |
Remarques |
|---|---|---|
|
Microsoft Windows Server |
|
|
|
Serveur Microsoft Windows dans une grappe de basculement |
2012 R2 |
La migration de grappes a également été testée à l'aide d'un disque système local avec tous les disques de données dans un SAN FC. |
|
Red Hat Enterprise Linux (RHEL) |
|
Pour les workloads Red Hat Enterprise Linux 6.8, Oracle Linux 6.8 et CentOS 6.8 avec des volumes LVM, PlateSpin Migrate prend en charge une réplication incrémentielle uniquement pour la dernière version du kernel disponible (version 2.6.32-696.20.1.el6.x86_64) pour la distribution 6.8. |
|
SUSE Linux Enterprise Server |
11 SP4 |
|
MPIO requiert l'installation d'un logiciel multipath supplémentaire sur le système d'exploitation, sous la forme d'une fonctionnalité Windows ou d'un paquetage ou module Linux. Les outils de gestion MPIO permettent d'activer MPIO et de configurer des stratégies MPIO pour les périphériques SAN avec plusieurs chemins d'accès. Reportez-vous à la documentation du fournisseur pour plus d'informations sur la configuration du matériel pour fournir plusieurs chemins d'accès à un périphérique de stockage et sur l'installation et la configuration de MPIO.
Reportez-vous au Tableau 2-11 pour plus d'informations sur les scénarios de migration MPIO pris en charge et les attentes relatives aux workloads cibles.
Tableau 2-11 Scénarios de migration MPIO pris en charge
|
Workload source |
Workload cible |
|
|---|---|---|
|
Logiciel MPIO |
Plusieurs chemins de stockage disponibles |
Un seul chemin de stockage disponible |
|
Le logiciel MPIO est installé. MPIO est activé et configuré. |
Le logiciel MPIO est automatiquement reconfiguré sur le workload cible pour l'environnement MPIO cible. Pour désactiver MPIO, vous devez le reconfigurer manuellement sur le workload. |
Le logiciel MPIO est conservé et reconfiguré pour un chemin d'accès unique. Vous pouvez laisser le logiciel ou le supprimer manuellement, en fonction du réseau prévu. Si vous ajoutez du matériel MPIO une fois la migration terminée, vous devez reconfigurer manuellement MPIO sur le workload. |
|
Le logiciel MPIO est installé. MPIO est désactivé. |
Le logiciel MPIO reste installé, mais est désactivé. Pour activer MPIO, vous devez le configurer manuellement sur le workload. |
Le logiciel MPIO reste installé, mais est désactivé. Vous pouvez laisser le logiciel ou le supprimer manuellement, en fonction du réseau prévu. Si vous ajoutez du matériel MPIO une fois la migration terminée, vous devez configurer manuellement MPIO sur le workload. |
|
Le logiciel MPIO n'est pas installé. |
Le logiciel MPIO n'est pas installé. Pour activer MPIO, vous devez l'installer et le configurer manuellement sur le workload. |
Aucun changement relatif à MPIO n'est apporté pour le workload. |
Les directives d'architecture de workloads suivantes s'appliquent à toutes les migrations :
Les workloads sources Linux doivent exécuter un serveur Secure Shell (SSH).
PlateSpin Migrate prend en charge la migration des workloads physiques et virtuels x86 dans votre datacenter :
64 bits
32 bits
Pour les plates-formes de virtualisation de machine virtuelle utilisant VMware 5.1, 5.5 et 6.0 avec un matériel de machine virtuelle de niveau 8 minimum, PlateSpin Migrate vous permet de spécifier le nombre de sockets, ainsi que le nombre de noyaux par socket pour le workload cible. Il calcule automatiquement le nombre total de noyaux. Ce paramètre s'applique lors de la configuration initiale d'un workload avec un paramètre de réplication initiale défini sur Réplication complète.
REMARQUE :le nombre maximal de noyaux que le workload peut utiliser est soumis à des facteurs externes tels que le système d'exploitation invité, la version du matériel de machine virtuelle, la licence VMware pour l'hôte ESXi et les ressources informatiques maximales de l'hôte ESXi pour vSphere (voir l'article de la base de connaissances VMware n° 1003497 « ESXi/ESX Configuration Maximums » (Configurations maximales pour ESXi/ESX).
Certaines distributions d'un système d'exploitation invité risquent de ne pas respecter la configuration des noyaux et des noyaux par socket. Par exemple, les systèmes d'exploitation invités utilisant SLES 10 SP4 conservent leurs paramètres de noyaux et de sockets d'origine, tels qu'à l'installation, tandis que d'autres distributions SLES et RHEL adoptent la nouvelle configuration.
Pour les plates-formes de virtualisation de machine virtuelle utilisant VMware 4.1, PlateSpin Migrate vous permet de spécifier le nombre requis de vCPU (processeurs virtuels) à assigner au workload cible. Ce paramètre s'applique lors de la configuration initiale d'un workload avec un paramètre de réplication initiale défini sur Réplication complète. Chaque vCPU est présenté au système d'exploitation invité sur la plate-forme de machine virtuelle en tant que coeur unique, socket unique.
La migration des workloads sources Windows et Linux basés sur UEFI est prise en charge pour toutes les plates-formes cibles. Le workload cible est configuré en tant qu'UEFI ou BIOS, selon ce qui est pris en charge par le fournisseur de la plate-forme cible. Par exemple :
Pour les plates-formes vCloud Director cibles, les workloads UEFI Windows et Linux sont migrés en tant que workloads UEFI vers les plates-formes vCloud cibles.
Pour les plates-formes cloud cibles, comme Azure et AWS, qui ne prennent pas en charge les workloads UEFI, les workloads UEFI Windows et Linux sont migrés en tant que workloads BIOS.
Migrate transfère des workloads de la source vers la cible afin d'appliquer le microprogramme pris en charge pour les systèmes d'exploitation source et cible respectifs. Lorsqu'une migration a été lancée entre des systèmes UEFI et BIOS, PlateSpin Migrate analyse la transition et vous informe sur sa validité.
REMARQUE :si vous migrez un workload UEFI sur un plate-forme de virtualisation cible vSphere et souhaitez continuer à utiliser le même mode de démarrage du microprogramme, vous devez cibler une plate-forme vSphere 5.0 ou plus récente.
Vous trouverez, ci-dessous, des exemples du comportement de PlateSpin Migrate lors d'une conversion entre des systèmes UEFI et BIOS :
Lorsque vous migrez un workload source UEFI vers une plate-forme qui ne prend pas en charge UEFI, par exemple, vers VMware vSphere 4.x, AWS ou Azure, Migrate fait migrer le microprogramme UEFI du workload vers le microprogramme BIOS.
Lors de la migration d'un workload source UEFI vers une cible BIOS, Migrate convertit les disques de démarrage du système UEFI, qui étaient de type GPT, vers MBR.
(Pour les workloads Windows) Lorsque vous migrez un workload BIOS vers une cible UEFI, PlateSpin Migrate convertit les disques de démarrage du système BIOS, qui sont de type MBR, vers GPT.
La conversion de workloads paravirtualisés en workloads entièrement virtualisés est prise en charge pour les workloads sources suivants s'exécutant sur un hôte virtuel Citrix XenServer ou KVM :
Red Hat Enterprise Linux (RHEL) 6.0 et les distributions Linux basées sur RHEL 6.0
Red Hat Enterprise Linux (RHEL) 5.x et distributions Linux basées sur RHEL 5.x
SUSE Linux Enterprise Server 10 et 11
Seules les conversions par bloc sont prises en charge.
Avant de migrer un workload source Linux paravirtualisé en cours d'exécution sous Citrix XenServer ou KVM vers une plate-forme cible en tant qu'invité entièrement virtualisé, effectuez les tâches suivantes :
Vérifiez que les kernels paravirtuel et standard sont installés sur le workload source paravirtualisé.
Compilez manuellement les pilotes par bloc du kernel Xen.
PlateSpin Migrate prend en charge les plates-formes de virtualisation cibles suivantes.
Le Tableau 2-12 liste les plates-formes VMware cibles prises en charge pour l'interface Web de PlateSpin Migrate et le client Migrate. Le client Migrate prend en charge la migration automatisée ou la migration semi-automatisée à l'aide du workflow X2P. L'interface Web prend en charge la migration automatisée. Voir :
Reportez-vous également aux sections Conditions préalables pour la migration vers VMware et Conditions préalables pour la migration vers VMware Cloud sur AWS.
REMARQUE :pour plus d'informations sur la création du disque de machine virtuelle cible sur les plates-formes VMware à l'aide de l'option RDM (Raw Device Mapping), reportez-vous à la section Migration vers VMware.
Le Tableau 2-14 liste les plates-formes de virtualisation cibles prises en charge pour le client PlateSpin Migrate à l'aide du workflow X2P semi-automatisé.
REMARQUE :
La migration de workloads vers une plate-forme de virtualisation cible est soumise à la prise en charge du système d'exploitation invité sur l'hôte cible par le fournisseur de l'hôte.
Une licence de système d'exploitation est nécessaire pour le workload cible migré.
Tableau 2-12 Plates-formes VMware cibles prises en charge pour l'interface Web de PlateSpin Migrate et le client Migrate
|
Plate-forme |
Versions |
Remarques |
|---|---|---|
|
VMware vCenter |
|
Le stockage SAN virtuel (vSAN) VMware est pris en charge sur une plate-forme de virtualisation cible vCenter comme suit :
L'option RDM (Raw Device Mapping) pour les machines virtuelles cibles est prise en charge à l'aide du workflow X2P. Reportez-vous également au Tableau 2-13, Banques de données VMware prises en charge. |
|
VMware ESXi |
|
Toutes les versions d'ESXi doivent avoir une licence payante ; la migration n'est pas prise en charge pour ces systèmes s'ils fonctionnent avec une licence gratuite. L'option RDM (Raw Device Mapping) pour les machines virtuelles cibles est prise en charge à l'aide du workflow X2P. Reportez-vous également au Tableau 2-13, Banques de données VMware prises en charge. |
|
VMware ESX |
|
L'option RDM (Raw Device Mapping) pour les machines virtuelles cibles est prise en charge à l'aide du workflow X2P. Reportez-vous également au Tableau 2-13, Banques de données VMware prises en charge. |
Tableau 2-13 Banques de données VMware prises en charge
|
Type de banque de données |
Configurations prises en charge |
|---|---|
|
VMFS |
Prise en charge pour toutes les versions prises en charge des plates-formes VMware vCenter, ESXi et ESX. |
|
NFS |
|
|
Autre |
Les autres types de banque de données ne sont pas pris en charge, notamment Virtual Volumes (vVols) et vFlash. |
Tableau 2-14 Plates-formes de virtualisation cibles prises en charge pour le client Migrate uniquement
|
Plate-forme |
Versions |
Remarques |
|---|---|---|
|
Microsoft Hyper-V Server |
|
Prise en charge pour le workflow X2P ou le workflow automatisé. Voir : Reportez-vous également à la section Conditions préalables pour la migration vers Microsoft Hyper-V. |
|
Microsoft Windows Server avec Hyper-V |
|
Prise en charge pour le workflow X2P ou le workflow automatisé. Voir : Reportez-vous également à la section Conditions préalables pour la migration vers Microsoft Hyper-V. |
|
Citrix XenServer |
|
Les invités entièrement virtualisés sont pris en charge. Prise en charge par le biais du workflow X2P. Reportez-vous à la section Migration vers des machines virtuelles sous Citrix XenServer. Reportez-vous également à la section Conditions préalables pour la migration vers des machines virtuelles sous Citrix XenServer. |
|
SUSE Linux Enterprise Server avec Xen |
11 SP3 et SP4 |
Les invités entièrement virtualisés sont pris en charge. Prise en charge par le biais du workflow X2P. Reportez-vous à la section Migration vers des machines virtuelles sous Xen. Reportez-vous également à la section Conditions préalables pour la migration vers des machines virtuelles sous Xen. |
|
SUSE Linux Enterprise Server (SLES) avec KVM |
11 SP4 et 12 SP1 |
Les invités entièrement virtualisés sont pris en charge. Les périphériques Virtio sont pris en charge. Prise en charge par le biais du workflow X2P. Reportez-vous à la section Migration vers des machines virtuelles sur KVM. Reportez-vous également à la section Conditions préalables pour la migration vers des machines virtuelles sous KVM. |
|
Red Hat Enterprise Linux (RHEL) avec KVM |
7.4 |
Les invités entièrement virtualisés sont pris en charge. Les périphériques Virtio sont pris en charge. Prise en charge par le biais du workflow X2P. Reportez-vous à la section Migration vers des machines virtuelles sur KVM. Reportez-vous également à la section Conditions préalables pour la migration vers des machines virtuelles sous KVM. |
PlateSpin Migrate prend en charge la migration de workloads vers des plates-formes cloud cibles dans l'interface Web de PlateSpin Migrate.
Tableau 2-15 Plates-formes cloud cibles prises en charge pour l'interface Web de PlateSpin Migrate
|
Plate-forme |
Versions |
Remarques |
|---|---|---|
|
Amazon Web Services (AWS) |
Environnement Amazon EC2 |
Reportez-vous également au Section 8.0, Conditions préalables pour une migration vers Amazon Web Services. |
|
Microsoft Azure |
|
Un serveur Migrate peut avoir plusieurs plates-formes cibles Cloud Azure. Vous spécifiez l'environnement Cloud Azure et l'emplacement lorsque vous créez la plate-forme cible. |
|
VMware vCloud Director |
|
Reportez-vous également à la section Conditions préalables pour la migration vers VMware vCloud Director. Téléchargez l'environnement de réplication PlateSpin pour vCloud à partir du site de téléchargement pour PlateSpin Migrate 2018.11. Reportez-vous à la section Section 10.4, Présentation de l'environnement de réplication PlateSpin utilisé pour la migration de workloads vers vCloud. |
|
VMware Cloud sur AWS |
Reportez-vous également à la section Conditions préalables pour la migration vers VMware Cloud sur AWS. |
En plus de l'anglais, PlateSpin Migrate prend en charge des langues nationales : chinois simplifié (ZH-CN), chinois traditionnel (ZH-TW), français (FR-FR), allemand (DE-DE) et japonais (JA-JP).
La documentation en ligne localisée est disponible dans ces langues, ainsi qu'en espagnol (ES-ES) et en portugais du Brésil (PT-BR).
L'interface Web de PlateSpin Migrate, les options de configuration de PlateSpin et les fichiers d'aide sont disponibles à partir d'un navigateur Web pris en charge :
Google Chrome 34.0 et versions ultérieures
Microsoft Internet Explorer 11.0 et versions ultérieures
Mozilla Firefox 29.0 et versions ultérieures
REMARQUE :JavaScript (Active Scripting) doit être activé dans votre navigateur.
Pour utiliser l'interface Web dans une des langues internationales prises en charge, reportez-vous à la section Configuration des paramètres de langue pour les versions internationales.