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 AWS Application Migration Service
La plupart lift-and-shift des grandes migrations à AWS utiliser AWS Application Migration Service
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 par blocs directement connecté au système migré au moment de la migration. (Pour plus d'informations, consultez la FAQ du service de migration d'applications sur le support SAN/NAS.) Cela limite l'applicabilité de la réplication via le service de migration d'applications 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 le service de migration d'applications). Les plateformes non x86 ne sont pas concernées par cette méthode de migration. Il s'agit notamment d'ARM, RISC/CISC des 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, HP-UX, Solaris, Linux pour PowerPC, ZLinux sur les 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 du service de migration des applications sous les questions suivantes :
* Voir les définitions du système de fichiers, du système
Avantages
Pour les lift-and-shift migrations de toute envergure, le service de migration d'applications 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 et prend donc en charge toutes les applications exécutées sur les serveurs sources.
-
Aucune licence ou achat n'est requis. AWS propose pay-as-you-go des tarifs, de sorte que vous ne payez pour le service que tant que vous l'utilisez, sans contrats à long terme ni licences complexes. Le service de migration d'applications fournit 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 Application Migration Service les tarifs
sur le AWS site Web.
Inconvénients
Lorsque vous utilisez des outils de réplication au niveau des blocs tels que Application Migration Service, vous pouvez être confronté aux situations critiques et aux facteurs suivants à prendre en compte :
-
Le service de migration d'applications 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). -
Application Migration Service 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 le service de migration d'applications 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 des cas particuliers. En général, le service de migration d'applications prend en charge la réplication d'un périphérique au niveau des blocs à 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 le service de migration d'applications 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. Le service de migration des applications 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.
Scénarios optimaux
Le service de migration d'applications couvre presque toutes les lift-and-shift migrations dans leur intégralité, 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 :
-
Migration à grande échelle avec plusieurs vagues de migration
-
Migration d'une seule application nécessitant un temps d'arrêt minimum
Migration à grande échelle 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 au niveau des blocs d'Application Migration Service, à 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 le service de migration d'applications ne prend pas en charge les 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 du service de migration des applications dans le RTO, elle doit être traité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 les serveurs d'applications à l'aide du service de migration d'applications, 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 déploiements bleu/vert, généralement en changeant de point de terminaison DNS, en utilisant des zones DNS pondérées, en utilisant AWS Global Accelerator
