Étape 8 : tester la solution à l'aide des scripts d'automatisation - Cloud Migration Factory sur AWS

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.

Étape 8 : tester la solution à l'aide des scripts d'automatisation

Importer les métadonnées de migration dans l'usine

Pour démarrer le processus de migration, téléchargez le server-list.csvfichier depuis le GitHub référentiel. Le server-list.csv fichier est un exemple de formulaire de demande de migration du service AWS MGN permettant d'importer les attributs des serveurs source concernés.

Note

Le fichier .csv et les exemples de scripts d'automatisation faisaient partie du package provenant du même GitHub référentiel.

Vous pouvez personnaliser le formulaire pour votre migration en remplaçant les exemples de données par des données spécifiques à votre serveur et à votre application. Le tableau suivant détaille les données à remplacer pour personnaliser cette solution en fonction de vos besoins de migration.

Nom de champ Obligatoire ? Description
nom_onde Oui Le nom de la vague est basé sur la priorité et les dépendances du serveur d'applications. Obtenez cet identifiant dans votre plan de migration.
app_name Oui Les noms des applications concernées par la migration. Vérifiez que votre groupe d'applications inclut toutes les applications partageant les mêmes serveurs.
aws_account id Oui Un identifiant à 12 chiffres qui Compte AWS se trouve dans le profil de votre compte. Pour y accéder, sélectionnez le profil de votre compte dans le coin supérieur droit du, AWS Management Console puis sélectionnez Mon compte dans le menu déroulant.
aws_region Oui Région AWS code. Par exemple, us-east-1. Consultez la liste complète des codes de région.
nom_serveur Oui Nom des serveurs locaux concernés par la migration.
server_os_family Oui Système d'exploitation (OS) qui s'exécute sur les serveurs sources concernés. Utilisez Windows ou Linux, car cette solution ne prend en charge que ces systèmes d'exploitation.
version du système d'exploitation du serveur Oui

Version du système d'exploitation exécutée sur les serveurs source concernés.

Note

Utilisez la version du système d'exploitation, pas la version du noyau. Par exemple, utilisez RHEL 7.1, Windows Server 2012 R2 ou CentOS 7.5, 7.6. N'utilisez pas Linux 3.xx, 4.xx ou Windows 8.1.x.

server_fqdn Oui Le nom de domaine complet du serveur source, qui est le nom du serveur suivi du nom de domaine. Par exemple, server123.company.com.
niveau du serveur Oui Étiquette permettant d'identifier si le serveur source est un serveur Web, d'application ou de base de données. Nous recommandons de désigner le serveur source comme application s'il fonctionne à plusieurs niveaux, par exemple s'il exécute simultanément les niveaux Web, d'application et de base de données.
environnement_serveur Oui Une étiquette pour identifier l'environnement du serveur. Par exemple, dev, test, prod, QA ou pre-prod.
r_type Oui Une étiquette pour identifier la stratégie de migration. Par exemple, Retire, Retain, Relocalise, Rehost, Redpurchase, Replatform, Rearchitect, TBC.
ID de sous-réseau Oui L'ID de sous-réseau de l'instance Amazon EC2 cible pour la migration après le passage.
Identifiants du groupe de sécurité Oui L'ID du groupe de sécurité pour l'instance Amazon EC2 cible pour la migration après le passage.
Sous-réseau IDS_Test Oui ID de sous-réseau cible pour le serveur source qui sera testé.
Groupe de sécurité _IDS_Test Oui ID du groupe de sécurité cible pour le serveur source qui sera testé.
instanceType Oui Type d'instance Amazon EC2 identifié lors de l'effort de découverte et de planification. Pour plus d'informations sur les types d'instances EC2, reportez-vous à la section Types d'instances Amazon EC2.
location Oui Le type de location, qui est identifié lors des efforts de découverte et de planification. Utilisez l'une des valeurs suivantes pour identifier la location : hôte partagé, dédié ou dédié. Vous pouvez utiliser Shared comme valeur par défaut, sauf si la licence d'une application nécessite un type spécifique.
Balises Non Les balises pour les ressources du serveur, telles que CostCenter =123 ; BU=IT ; Location=US
private_ip Non L'adresse IP privée de l'instance cible. Si elle n'est pas incluse, l'instance obtiendra une adresse IP du DHCP.
Je suis un rôle Non Rôle IAM pour l'instance cible. S'il n'est pas inclus, aucun rôle IAM ne sera attaché à l'instance cible.
  1. Connectez-vous à la console Web Cloud Migration Factory.

  2. Sous Gestion de la migration, sélectionnez Importer, puis sélectionnez Sélectionner un fichier. Sélectionnez le formulaire d'admission que vous avez rempli précédemment, puis cliquez sur Suivant.

  3. Passez en revue les modifications et assurez-vous qu'aucune erreur ne s'affiche (le message d'information est normal), puis choisissez Next.

  4. Choisissez Upload to upload servers.

Accédez aux domaines

Les exemples de scripts d'automatisation inclus dans cette solution se connectent aux serveurs sources concernés pour automatiser les tâches de migration, telles que l'installation de l'agent de réplication et l'arrêt des serveurs sources. Pour tester la solution, un utilisateur de domaine disposant d'autorisations d'administrateur local sur les serveurs source est requis, pour les serveurs Windows et Linux (autorisations sudo). Si Linux n'est pas dans le domaine, d'autres utilisateurs tels qu'un utilisateur LDAP avec des autorisations sudo ou un utilisateur sudo local peuvent être utilisés. Pour plus d'informations sur les tâches de migration automatisées, reportez-vous aux sections Activités de migration automatisées à l'aide de la console Web Migration Factory et Activités de migration automatisées à l'aide d'une invite de commande.

Procéder à un test de l'automatisation de la migration

Cette solution vous permet de tester l'automatisation de la migration. À l'aide de scripts d'automatisation, le processus de migration importe les données du fichier CSV de migration dans la solution. Des vérifications préalables sont effectuées pour les serveurs sources, l'agent de réplication est envoyé aux serveurs sources, l'état de réplication est vérifié et le serveur cible est lancé depuis l'interface Web de Migration Factory. Pour step-by-step obtenir des instructions sur l'exécution d'un test, reportez-vous aux sections Activités de migration automatisées à l'aide de la console Web Migration Factory et Activités de migration automatisées à l'aide d'une invite de commande.