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.
Élaborer un plan de migration
L'étape de planification de la migration de AWS Transform for VMware est une expérience collaborative basée sur le chat pour planifier des migrations de grande envergure. AWS Les agents de transformation appliquent des directives AWS prescriptives pour guider les clients depuis l'analyse des données sur site jusqu'à la finalisation des plans de vague de migration.
Une fois la tâche de découverte des données sur site terminée avec succès, AWS Transform utilise les données de découverte pour regrouper les applications en vagues de migration. AWS Transform vous guide tout au long des étapes à suivre pour analyser et dimensionner vos serveurs, les regrouper en applications, générer des groupes de déménagement et créer des vagues de migration. Lorsque vous analysez votre environnement sur site, vous pouvez poser des questions pour mieux comprendre comment AWS Transform a analysé les logiciels installés, par exemple les dépendances des serveurs et l'architecture réseau.
AWS Transform prend en charge les ajustements de portée au sein des groupes d'applications et des vagues. Vous pouvez télécharger à nouveau les données de découverte à tout moment, et AWS Transform traitera, dédupliquera et fusionnera automatiquement les nouveaux enregistrements avec les données existantes. Lorsque des modifications sont détectées, telles que des dépendances récemment découvertes ou des ajouts d'infrastructure, AWS Transform signale les groupes de dépendances concernés et fournit des recommandations pour les ajustements du plan de vague. La planification de la migration peut également utiliser des données textuelles non structurées pour enrichir le processus de planification.
Il existe quatre étapes de planification de la migration :
Dans Étendue et analyse, vous pouvez consulter vos données de découverte, poser des questions sur votre environnement logiciel et réseau et déterminer les ressources concernées par la migration.
Dans les applications de groupe, vous pouvez fournir une combinaison de règles commerciales et techniques concernant, par exemple, l'analyse des noms d'hôte, les dépendances du réseau et les règles commerciales, afin que la planification de la migration puisse regrouper votre infrastructure en applications. Si vous disposez déjà d'un inventaire de vos applications, la planification de la migration peut l'utiliser à la place.
Dans Generate move groups, vous pouvez définir les exigences techniques et commerciales de la planification de la migration afin qu'elle puisse déterminer quelles applications doivent être déplacées ensemble. Les dépendances techniques incluent les bases de données, les files de messages ou d'autres ressources partagées entre plusieurs applications. Les dépendances commerciales et opérationnelles incluent la criticité commerciale, le RPO et le RTO, l'emplacement des centres de données et les propriétaires d'applications.
Enfin, dans Build waves, vous pouvez donner un contexte à la planification de la migration concernant vos délais et vos priorités afin qu'il puisse élaborer un plan de vague que vous pouvez migrer. Vous pouvez sélectionner des groupes de déménagement à inclure dans une vague en fonction de facteurs tels que le score de priorité, la taille du groupe de déménagement, le nombre d'utilisateurs et la complexité de l'application.
Terminologie de planification de la migration :
Les vagues de migration sont des groupes logiques qui migrent ensemble. Les vagues de migration sont composées d'un ou de plusieurs groupes de déménagement.
Un groupe de déménagement est un ensemble d'applications dépendantes qui doivent être déplacées ensemble. Ils peuvent avoir des dépendances techniques telles qu'une base de données partagée ou des dépendances commerciales telles que la prise en charge d'une fonction commerciale partagée.
Une dépendance est une relation entre des systèmes. Il existe plusieurs types de dépendances, notamment :
Dépendances critiques ou strictes, dans lesquelles les systèmes ne peuvent pas fonctionner sans dépendance. Les applications qui dépendent de bases de données, d'autres applications ou de services en sont des exemples courants.
Dépendances souples, qui ne sont pas essentielles au fonctionnement du système. Parmi les exemples courants, citons les dépendances insensibles à la latence qui peuvent être migrées indépendamment.
Non-technical les dépendances incluent les dépendances commerciales, organisationnelles, opérationnelles et de conformité. Il s'agit de dépendances liées à votre organisation et à ses priorités. Cela inclut le partage des fonctions commerciales et de la propriété organisationnelle.
Flux de travail
La planification de la migration est un flux de travail interactif et itératif. Vous pouvez revenir en arrière et modifier les étapes précédentes à tout moment. Un flux de travail typique de planification de migration est le suivant :
La planification de la migration commence par la synthèse des données de découverte disponibles. Passez en revue les données disponibles et revenez à l'étape de découverte à tout moment pour fournir des données supplémentaires.
Au cours de l'étape de cadrage et d'analyse, vous pouvez poser des questions sur votre environnement sur site afin de valider les données que vous avez collectées. Voici des exemples de questions :
Répertorier mes serveurs par système d'exploitation
Résumez la topologie de mon réseau sur site
Répertoriez les technologies les plus courantes exécutées dans mon environnement.
Lors de l'analyse de votre environnement, si vous identifiez des serveurs qui ne devraient pas être concernés par la migration, vous pouvez demander à AWS Transform d'exclure ces ressources. En voici quelques exemples :
Supprimez tous les serveurs dont le nom d'hôte contient un héritage
Supprimez tous les serveurs de la version 10.0.2. 0/24 sous-réseau
Supprimez tous les serveurs exécutant des versions de Windows antérieures à 2022
Une fois que vous avez suffisamment exploré votre environnement et déterminé l'étendue de votre migration, vous pouvez demander à AWS Transform de passer à l'étape suivante de planification de la migration.
L'étape suivante est le regroupement des applications. Si vos serveurs sont déjà mappés à des applications, vous pouvez demander à AWS Transform d'utiliser ce mappage et d'ignorer cette étape. Si vos applications ne sont pas prédéfinies, vous pouvez fournir la logique technique et commerciale qui définit vos applications. AWS Transform vous guidera tout au long du processus de regroupement d'applications et vous proposera les points de données que vous pouvez fournir pour regrouper efficacement vos serveurs en applications. Plus vous pouvez fournir d'informations sur vos applications sur site, plus AWS Transform peut regrouper efficacement vos serveurs en applications. Une fois que vous avez fourni suffisamment d'informations, vous pouvez demander à AWS Transform de regrouper les applications.
Une fois le regroupement des applications effectué, passez en revue les groupes d'applications. Vous pouvez demander à AWS Transform d'apporter les modifications nécessaires, par exemple :
Déplacer le serveur example-server vers application-5
Renommer l'application-5 « HR App Test Environment »
Supprimer tous les serveurs Linux de IIS Dev Farm
Une fois vos applications groupées, demandez à AWS Transform de passer à l'étape suivante
L'étape suivante consiste à déplacer le regroupement. À l'étape de regroupement des déplacements, vous identifiez les applications qui doivent être déplacées ensemble. Fournissez le contexte de vos dépendances techniques et non techniques. AWS Transform vous guidera tout au long du processus et vous proposera des points de données que vous pouvez fournir pour regrouper vos applications. Plusieurs considérations doivent être prises en compte à ce stade, notamment :
Quelle doit être la taille cible du groupe de déménagement ?
Voulez-vous combiner les environnements, par exemple de développement, de test et de production, pour chaque application, ou les scinder ?
Comment souhaitez-vous prendre en compte les dépendances du réseau ? Toutes les dépendances sont-elles critiques ou certaines dépendances peuvent-elles être considérées comme des dépendances souples et réparties entre les groupes de déménagement ?
-
Une fois que vous avez défini vos règles pour le regroupement de mouvements, demandez à AWS Transform d'exécuter votre stratégie de regroupement de mouvements. Vous pouvez ensuite revoir et modifier vos groupes de déménagement. Une fois que vous avez passé en revue vos groupes de déménagement, vous pouvez demander à AWS Transform de passer à l'étape finale de planification de la migration.
La planification des vagues est la dernière étape de la planification de la migration. Au cours de cette étape, vous regroupez vos groupes de déménagement en vagues de migration et vous hiérarchisez ces vagues. Au cours de l'étape de planification des vagues, AWS Transform vous aidera à établir les priorités commerciales nécessaires pour regrouper vos groupes de déménagement en vagues, puis hiérarchiser ces vagues. Les considérations relatives à la planification des vagues incluent :
L'importance commerciale de chacun de vos groupes de déménagement
Les délais de migration et les délais pour chaque groupe de déménagement
Les risques associés à chaque groupe de déménagement
Le nombre de serveurs à migrer par vague
Une fois que vous avez fourni des conseils suffisants sur la façon de les regrouper en vagues, demandez à AWS Transform d'exécuter la planification des vagues. Vous pouvez ensuite revoir vos vagues et les modifier.
Une fois que vous avez finalisé votre plan de vague, vous pouvez terminer la planification de la migration et passer à l'exécution. Vous pouvez revenir à la planification de la migration à tout moment pour affiner et modifier votre plan.
Pour chaque vague, vous pouvez attribuer une stratégie de migration : réhébergement (migration des serveurs vers Amazon EC2) et conteneurisation (conteneurisation du code source et déploiement sur Amazon Elastic Container Service ou Amazon Elastic Kubernetes Service). Lorsque vous attribuez à une vague la conteneurisation de la stratégie, AWS Transform exécute le flux de travail de conteneurisation du code source pour cette vague lors de l'exécution de la migration. Pour de plus amples informations, veuillez consulter Conteneurisation du code source. Pour obtenir les stratégies AWS recommandées dans le framework 7R avant de les attribuer, voir. Recommandations relatives à la stratégie de migration (7R)
