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.
Migration avec le service de migration d'applications AWS
La plupart des grandes migrations « lift-and-shift » à utiliser. AWS AWS Transform MGN
Cette méthode de réplication au niveau des blocs ne prend pas en charge le stockage rattaché au réseau (NAS), les disques partagés tels que les partages NFS (Network File System) ou les partages Common Internet File System (CIFS) /Server Message Block (SMB). Il prend uniquement en charge le stockage au niveau des blocs directement connecté au système migré au moment de la migration. (Pour plus d'informations, consultez la FAQ MGN sur le SAN/NAS support.) Cela limite l'applicabilité de la réplication via MGN pour la plupart des systèmes en cluster, car la majorité des clusters reposent sur le stockage partagé de différentes implémentations. Pour plus d'informations, consultez les sections Avantages et inconvénients de cette page.
La méthode de réplication au niveau des blocs nécessite l'installation d'un agent de AWS réplication au niveau du système d'exploitation (OS), et cet agent ne prend en charge que les plateformes x86 basées sur le système d'exploitation Windows ou Linux (voir Systèmes d'exploitation pris en charge par MGN). Non-x86 les plateformes ne sont pas couvertes par cette méthode de migration. Il s'agit notamment d'ARM, des RISC/CISC systèmes, des variantes PowerPC, des systèmes IBM tels que pSeries, iSeries, zSeries, et de leurs systèmes d'exploitation respectifs tels que AIX, Solaris HP-UX, Linux pour PowerPC, ZLinux sur mainframes et d'autres architectures non x86.
L'agent de AWS réplication fonctionne au niveau d'un pilote de périphérique de système de fichiers virtuel* dans la pile du système d'exploitation, capturant tous les blocs de données à écrire sur les périphériques de niveau bloc sous-jacents (y compris les disques, les disques durs et les périphériques SAN directement connectés), comme expliqué sur la page FAQ MGN sous les questions suivantes :
* Voir les définitions du système de fichiers, du système
Avantages
Pour les migrations « lift-and-shift » de n'importe quelle échelle, MGN présente de nombreux avantages :
-
La réplication est facile à configurer (elle ne nécessite pas une longue période d'apprentissage).
-
Il est rapide à mettre à l'échelle, en déployant des agents sur les machines sources.
-
Vous pouvez utiliser Cloud Migration Factory
pour automatiser la plupart des tâches manuelles, gérer plusieurs machines et orchestrer les vagues de migration. -
Il prend en charge un large éventail d'architectures de systèmes d'exploitation x86.
-
Il prend en charge tout type d'environnement source (centre de données sur site, tout autre cloud ou autre Région AWS).
-
Il est indépendant des applications, il prend donc en charge toutes les applications exécutées sur les serveurs sources.
-
Aucune licence ou achat n'est requis. AWS propose une tarification à l'utilisation, de sorte que vous ne payez pour le service que tant que vous l'utilisez, sans contrats à long terme ni licences complexes. MGN offre une période gratuite de 90 jours par serveur, ce qui est suffisant pour la plupart des migrations. Pour plus de détails, consultez AWS Transform MGN les tarifs
sur le AWS site Web.
Inconvénients
Lorsque vous utilisez des outils de réplication au niveau des blocs tels que MGN, vous pouvez être confronté aux situations critiques et aux facteurs suivants à prendre en compte :
-
MGN ne prend pas en charge les systèmes de fichiers partagés montés ni les périphériques de stockage partagés tels que le NAS, y compris CIFS/SMB les systèmes de fichiers NFS. Pour plus d'informations sur les méthodes de réplication pour les NAS ou les systèmes de fichiers partagés, consultez l'agent de réplication MGN pour migrer NFS Share
(article AWS Re:Post) et Migrer les systèmes de fichiers partagés lors d'une migration de AWS grande envergure (modèle de directives AWS prescriptives). -
MGN ne prend pas en charge la plupart des configurations de serveurs de fichiers ou de clusters de bases de données en cluster avec stockage partagé en raison des limites de représentation de ce stockage partagé au niveau du système d'exploitation via les couches de pilotes de périphériques. Par exemple, les clusters Microsoft SQL Server dotés de l'option Storage Space Direct (S2D) ne sont pas pris en charge. Cependant, vous pouvez toujours utiliser MGN pour répliquer d'autres types de systèmes en cluster dotés d'un stockage par blocs partagé, tels que le stockage partagé dans les configurations FCI (Failover Cluster) de Windows Server Failover Cluster (WSFC), comme décrit dans le billet de blog Migration de vos clusters Microsoft Windows vers l' AWS utilisation de la CloudEndure migration, le stockage exposé par des baies SAN externes (connexions iSCSI) et certains clusters
du groupe de disponibilité Microsoft SQL Server Always On (AAG) dans étuis d'angle spécifiques. En général, MGN prend en charge la réplication d'un périphérique de niveau bloc à partir d'un serveur où le périphérique de stockage est entièrement présent sur le serveur pendant la migration. (L'agent de AWS réplication doit être installé sur le serveur et le périphérique doit être visible par l'agent pour la réplication.) Cependant, tous ces scénarios nécessitent des procédures très spécifiques et entraînent des périodes de transition plus longues. -
Les systèmes dont le taux de modification des données est élevé (tels que les bases de données OLTP) peuvent avoir des exigences plus élevées en termes de performances ou de réseau, ce qui complique les efforts de migration.
-
La bande passante du réseau doit être suffisante pour la quantité de données à transférer au cours de la période de migration et de basculement planifiée. Cela est dû au fait que MGN ne propose pas d'option d'expédition hors ligne, contrairement à AWS Snowball
. -
La migration nécessite une courte période d'indisponibilité, en l'espace de quelques minutes. MGN utilise des instantanés EBS dans le cadre du processus de migration, et les nouveaux disques EBS créés à partir de tels instantanés présentent initialement de moins bonnes performances. Avec certains modèles de lecture de base de données, cela peut augmenter la période de basculement effective jusqu'à ce que les performances de la base de données migrée soient optimales.
Best-fit scénarios
MGN couvre entièrement presque toutes les migrations de type « lift-and-shift », avec quelques inconvénients, comme indiqué dans les deux sections précédentes. Cet outil peut gérer la plupart des cas particuliers, tels que les clusters de bases de données, à condition que la période de basculement plus longue requise pour ces systèmes réponde à vos exigences de migration.
Les sections suivantes abordent deux scénarios de manière plus approfondie :
-
Large-scale migration avec plusieurs vagues de migration
-
Migration d'une seule application nécessitant un temps d'arrêt minimum
Large-scale migration avec plusieurs vagues de migration
Un exemple de migration à grande échelle est une sortie de centre de données caractérisée par des exigences de taille et de rapidité. Cela implique également généralement une contrainte de temps spécifique, telle que la fin du contrat de location du centre de données. Dans ce cas, c'est l'échelle qui dicte l'approche. Les vagues de migration sont déterminées et regroupées par applications, y compris les bases de données, tandis que chaque vague comporte une phase de préparation, de migration et de basculement final planifiée présentant des exigences d'indisponibilité spécifiques.
Au cours de chaque vague de migration, il est préférable de déplacer les serveurs de base de données à grande échelle en utilisant la réplication MGN au niveau des blocs, à quelques exceptions près pour les cas particuliers suivants qui peuvent nécessiter une approche de migration distincte :
-
La plupart des systèmes de bases de données en cluster
-
Systèmes de base de données où le taux de modification dépasse le débit réseau disponible (ce qui peut entraîner un retard de réplication)
Pour chaque cas particulier, réfléchissez au compromis entre vos exigences en matière de temps d'arrêt et le niveau d'effort requis pour utiliser un autre outil de migration. Dans certains cas, il est beaucoup plus facile d'utiliser la même approche de migration pour tous les systèmes au lieu d'utiliser des outils distincts et de créer des processus différents pour des systèmes spécifiques. Si MGN ne répond pas aux exigences d'indisponibilité d'un système spécifique, nous vous recommandons d'utiliser plutôt l'une des méthodes décrites dans la section Migration avec des outils de base de données natifs.
Migration d'application unique
Le scénario de l'application unique représente une approche détaillée pour la migration d'une seule application stratégique nécessitant un temps d'arrêt minimal ou quasiment nul pendant la migration, ou de quelques-unes de ces applications. L'étendue de la migration peut varier en fonction de la criticité de l'entreprise et des exigences relatives aux interruptions de service, contrairement aux exigences de vitesse et d'échelle du scénario précédent (migration à grande échelle). Si l'application autorise une interruption de service dans le RTO de MGN, elle doit être gérée de la même manière que toute migration à grande échelle décrite précédemment.
Toutefois, dans les cas où le temps de transition doit être aussi proche que possible du minimum (par exemple, lorsque la base de données migrée possède des modèles de lecture qui nécessitent un certain temps pour fonctionner à pleine capacité et que les fenêtres de transition doivent rester petites), vous devez envisager une approche plus détaillée et plus granulaire. En général, cette approche implique des étapes et des exigences supplémentaires, qui nécessitent plus d'efforts et de temps. L'une des étapes consiste à séparer la migration de la base de données de la migration du serveur d'applications et à utiliser les outils de migration de base de données décrits dans la section suivante pour que les bases de données source et cible restent synchronisées. Pour effectuer la synchronisation, vous pouvez utiliser différentes méthodes. Chaque méthode présente des avantages et des inconvénients, et implique différents compromis entre le temps d'arrêt et la complexité de la synchronisation. Néanmoins, le maintien de la synchronisation de la base de données entre les environnements source et cible vous permet de dissocier la couche de base de données de la couche d'application. En supposant que les serveurs d'applications ne stockent pas les données persistantes localement mais les transmettent à la couche de base de données, la synchronisation supprime également les restrictions relatives aux temps d'arrêt de la couche application.
Le découplage des couches de base de données et d'application vous permet de migrer des serveurs d'applications à l'aide de MGN comme dans le scénario précédent. Les serveurs d'applications cibles peuvent être démarrés dans l'environnement cible alors que les systèmes source sont encore en cours d'exécution, traitent les données et les stockent dans la couche de base de données. La couche de base de données étant déjà synchronisée avec la cible, le temps de transition est minime : il suffit de changer de réseau et de rediriger les demandes des clients de l'ancien système source vers l'environnement cible. Pour ce faire, vous pouvez utiliser plusieurs méthodes, en suivant les instructions relatives aux blue/green déploiements, généralement en changeant de point de terminaison DNS, en utilisant des zones DNS pondérées, en utilisant des méthodes AWS Global Accelerator
