Le Blog Amazon Web Services

Comment utiliser le nouveau service AWS Application Migration Service pour les migrations “Lift-and-Shift” ?

Depuis qu’AWS a acquis CloudEndure en 2019, nos nouveaux collègues ont mis à disposition CloudEndure Migration et CloudEndure Disaster Recovery. CloudEndure Migration permet de migrer gratuitement des applications depuis n’importe quelle infrastructure physique, virtuelle ou basée sur le cloud vers AWS. Cela complète AWS Server Migration Service (AWS SMS), qui est un service sans agent pour la migration d’infrastructures on-premises vers AWS. CloudEndure Disaster Recovery est une offre de continuité d’activité distincte, conçue pour vous aider à minimiser les temps d’arrêt et la perte de données. Il réplique en continu le contenu de vos systèmes on-premises, virtuels ou basés sur le cloud vers une zone de transit à faible coût dans la région AWS de votre choix, dans les limites de votre compte AWS. Cette offre est disponible pour tous les clients et partenaires AWS.

En 2021, nous avons lancé AWS Application Migration Service (AWS MGN), que nous recommandons dorénavant comme service principal pour vos migrations “lift-and-shift” sur AWS. Si vous utilisez aujourd’hui CloudEndure Migration ou AWS SMS, nous vous encourageons à employer AWS MGN pour vos prochaines migrations. Pour savoir quel outil de migration choisir, vous pouvez consulter cette FAQ. AWS MGN vous permet de migrer vos applications sur AWS sans avoir à modifier vos applications, leurs architectures, ou les serveurs migrés. 

Avec AWS MGN, vous pouvez minimiser les processus manuels, chronophages, ou sujets aux erreurs humaines en répliquant, et convertissant automatiquement vos serveurs pour qu’ils s’exécutent nativement sur AWS. Ce service simplifie votre migration en vous permettant d’utiliser le même processus de migration automatique pour un large éventail d’applications. En complément, vous pouvez lancer des tests non-disruptifs avant votre migration, et vous assurer que vos applications les plus critiques telles que SAP, Oracle et SQL Server fonctionneront de manière transparente sur AWS.

AWS MGN réduit le coût total de migration puisque vous n’avez pas besoin d’investir dans de multiples solutions de migration, dans des outils propres au développement Cloud ou dans des compétences spécifiques à l’application. Cela est rendu possible par le fait que AWS MGN peut migrer tout type d’applications, depuis n’importe quelles infrastructures sources basé sur un système d’exploitation compatible.

Comment AWS MGN fonctionne ?

Pour migrer vers AWS, vous installez l’agent de réplication AWS MGN sur vos serveurs sources, puis vous définissez les paramètres de réplication dans la console du service. AWS MGN utilise cette configuration pour créer et gérer une zone de transit. Cette zone se compose d’un sous-réseau hébergeant des instances Amazon Elastic Compute Cloud (Amazon EC2), agissant comme serveurs de réplication pour répliquer les données entre la source et AWS.

Les serveurs de réplication reçoivent les données depuis les agents déployés sur les serveurs sources, puis écrivent ces données dans des volumes Amazon Elastic Block Store (EBS). Les données répliquées sont compressées et chiffrées durant le transfert et au repos avec le chiffrement par Amazon KMS. AWS MGN garde vos répliquas à jour sur AWS en utilisant une réplication continue au niveau du bloc de données. Le système utilise vos paramètres de lancement pour démarrer vos instances lorsque vous exécutez des tests non-disruptifs ou lors de la bascule. 

Lors du test ou de la bascule d’instance, le service convertit vos serveurs sources en une version native et fonctionnelle sur le cloud AWS. Après avoir confirmé que l’instance fonctionne correctement sur AWS, vous pouvez décommissiez vos serveurs d’origine. Vous serez ensuite en mesure de moderniser vos applications en utilisant les services AWS et leurs fonctionnalités.

AWS MGN  – Mise en route

Pour démarrer, créer un modèle de paramètre de réplication dans la console AWS MGN. Ce modèle détermine comment fonctionnera la réplication pour chaque nouveau serveur source ajouté. Avant de configurer ce modèle, assurez-vous que vous répondez aux exigences réseaux nécessaires au fonctionnement d’AWS MGN.

Dans la console AWS MGN, choisissez Get Started pour créer le modèle.

Vous pouvez modifier les paramètres à tout moment pour n’importe quel serveur source individuel ou groupe de serveurs source.

Les serveurs de réplication sont des instances EC2 légères qui sont utilisées pour répliquer des données entre vos serveurs sources et AWS. Ils sont automatiquement lancés et terminés selon les besoins. Vous pouvez utiliser les paramètres de routage et limiter la bande passante allouée à la réplication pour contrôler la manière dont les données sont acheminées de vos serveurs sources vers les serveurs de réplication.

Après avoir créé votre modèle, vous pouvez ajouter vos serveurs sources. Pour modifier votre modèle, dans le volet de navigation de gauche, choisissez Settings. Vous pouvez modifier les paramètres de réplication de serveur individuel après avoir ajouté vos serveurs sources.

Pour ajouter des serveurs sources à AWS MGN, installez l’agent de réplication AWS MGN sur ceux-ci. Vous pouvez installer l’agent sur des serveurs exécutant les systèmes d’exploitation Linux et Windows. Pour plus d’informations, consultez l’ajout de serveurs sources dans la documentation.

Par exemple, téléchargez le programme d’installation de l’agent aws-replication-installer-init.py avec la commande wget et exécutez le script d’installation sur votre serveur source Linux.

Une fois l’agent de réplication AWS installé, le serveur sera ajouté à la console AWS MGN et débutera le processus de synchronisation initial. 

La page Source Servers affiche une liste de serveurs sources. Chaque ligne de la liste représente un seul serveur. La colonne du cycle de vie de la migration affiche l’état actuel de chaque serveur source. Une fois le processus de synchronisation initial terminé avec succès, la réplication des données démarre automatiquement.

Après avoir ajouté vos serveurs sources, vous devez configurer les paramètres de lancement pour chaque serveur. Les paramètres de lancement sont un ensemble d’instructions qui déterminent comment une instance de test ou de basculement sera lancée pour chaque serveur source sur AWS.

Vous devez configurer les paramètres de lancement avant de lancer des instances de test ou de bascule. Pour accéder aux paramètres de lancement, choisissez le nom d’hôte d’un serveur source, puis accédez à l’onglet Launch Settings.

Après avoir ajouté vos serveurs sources et configuré leurs paramètres de lancement, vous êtes prêt à lancer une instance de test. Vous devez tester la migration de vos serveurs source vers AWS avant de lancer un basculement, afin de vérifier que vos serveurs source fonctionnent correctement dans l’environnement AWS.

Pour lancer une instance de test ou de basculement pour un serveur source unique ou plusieurs serveurs source, sur la page Source Servers, cochez la case de chaque serveur pour lequel vous souhaitez lancer une instance de test.

Vous pouvez tester un serveur source à la fois ou plusieurs serveurs sources simultanément. Pour chaque serveur source, vous serez informés de la réussite ou de l’échec du test. Choisissez Launch test instances pour démarrer le test, puis choisissez Launch.

Une fois le test démarré, la console AWS affiche un message Launch job started. Pour afficher la tâche spécifique pour le lancement du test, choisissez View jobs details de la tâche.

Utilisez l’onglet Migration dashboard de la migration pour surveiller la progression par rapport au cycle de vie de la migration.

En tant que bonne pratique, effectuez un test au moins une semaine avant de planifier la migration de vos serveurs sources. Cela vous laisse le temps d’identifier et de résoudre les problèmes avant que la bascule n’ait rellement lieu. Après avoir lancé les instances de test, utilisez SSH(Linux) ou RDP (Windows) pour vous connecter à votre instance et assurez-vous que tout fonctionne correctement.

Après avoir finalisé les tests de vos serveurs sources, vous êtes prêt pour une transition. Il est recommandé de planifier l’heure de transition à l’avance. Une fois l’action de basculement effectuée, le serveur est considéré comme migré et vous devez rediriger vos utilisateurs de vos serveurs sources d’origine vers les serveurs migrés.

Si vous avez terminé votre migration et effectué une bascule avec succès, vous pouvez finaliser celle-ci. Cela changera l’état du cycle de vie de la migration de vos serveurs sources en Cutover complete, indiquant que la bascule est terminée et que la migration a été effectuée avec succès.

Surveillance et dépannage

Vous pouvez surveiller AWS MGN à l’aide d’Amazon CloudWatch, d’Amazon EventBridge et d’AWS CloudTrail, qui collectent des données brutes et les traitent en métriques lisibles en quasi temps réel. Pour plus d’informations, consultez Monitoring Application Migration Service dans la documentation.

Si vous rencontrez des problèmes et souhaitez lancer de nouvelles instances de test ou de bascule, vous pouvez annuler l’action de test ou de basculement. Cela ramènera l’état du cycle de vie de vos serveurs sources à l’étape précédente, indiquant que ces serveurs n’ont pas subi de basculement. Lors d’un retour arrière, vous aurez également la possibilité de supprimer vos instances de test ou de basculement à des fins de réduction des coûts. Pour plus d’informations, voir Troubleshooting dans la documentation.

Bien que l’utilisation d’AWS MGN soit gratuite pendant 90 jours, des frais vous seront facturés pour toute infrastructure AWS provisionnée pendant la migration et après le basculement. Pour plus d’informations, consultez la page de tarification AWS MGN.

Commencez dès aujourd’hui avec AWS Application Migration Service. 

Pour une présentation des avantages, des services et des détails de l’architecture réseau d’AWS MGN, regardez la vidéo sous Youtube

Article original de Channy YunPrincipal Developer Advocate chez AWS, traduit en français par Baptiste Michaud, Senior Solution Architect dans les équipes AWS France.

Tags: AWS Application Migration Service, AWS Server Migration Service, CloudEndure Migration