Migration des charges de travail : zone CloudEndure d'atterrissage (SALZ) - Guide du développeur d'applications AMS Advanced

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 des charges de travail : zone CloudEndure d'atterrissage (SALZ)

Cette section fournit des informations sur la configuration d'une zone d'atterrissage à compte unique (SALZ) de migration intermédiaire pour les instances de transition CloudEndure (CE) devant être disponibles pour une RFC d'ingestion de charge de travail (WIGS).

Pour en savoir plus CloudEndure, consultez la section CloudEndure Migration.

Note

Il s'agit d'une LZ et d'un modèle de migration prédéfinis et renforcés en termes de sécurité.

Prérequis :

  • Un compte client AMS

  • Intégration du réseau et des accès entre le compte AMS et le client sur site

  • Un CloudEndure compte

  • Un flux de travail de pré-approbation pour une révision et une approbation de la sécurité AMS, exécuté avec votre CA and/or CSDM (par exemple, une utilisation abusive des informations d'identification permanentes de l'utilisateur IAM permet d'accéder à des instances et à des groupes de sécurité) create/delete

Note

Les processus spécifiques de préparation et de migration sont décrits dans cette section.

AWS architecture diagram showing data flow between on-premises server and AWS cloud services.

Préparation : Vous et l'opérateur AMS :

  1. Préparez une demande de modification (RFC) avec le type de modification Management | Other | Other | Update vers AMS pour les ressources et mises à jour suivantes. Vous pouvez soumettre une mise à jour Autre | Autre mise à jour séparée RFCs, ou une seule. Pour plus de détails sur ce RFC/CT, voir Autre | Autre mise à jour avec les demandes suivantes :

    1. Attribuez un bloc d'adresse CIDR secondaire dans votre VPC AMS ; un bloc d'adresse CIDR temporaire qui sera supprimé une fois la migration terminée. Assurez-vous que le blocage n'entrera pas en conflit avec les itinéraires existants vers votre réseau sur site. Par exemple, si votre adresse CIDR VPC AMS est 10.0.0.0/16 et qu'il existe une route de retour vers votre réseau local de 10.1.0.0/16, le CIDR secondaire temporaire peut être 10.255.255.0/24. Pour plus d'informations sur les blocs d'adresse CIDR AWS, consultez la section Dimensionnement des VPC et des sous-réseaux.

    2. Créez un nouveau sous-réseau privé dans le VPC AMS du jardin initial. Exemple de nom :migration-temp-subnet.

    3. Créez une nouvelle table de routage pour le sous-réseau avec uniquement des routes VPC et NAT (Internet) locales, afin d'éviter les conflits avec le serveur source lors du transfert d'instance et d'éventuelles pannes. Assurez-vous que le trafic sortant vers Internet est autorisé pour le téléchargement des correctifs et que les prérequis d'AMS WIGS peuvent être téléchargés et installés.

    4. Mettez à jour votre groupe de sécurité Managed AD pour autoriser le trafic entrant et sortant. to/from migration-temp-subnet Demandez également que le groupe de sécurité de votre équilibreur de charge EPS (ELB) (ex :mc-eps-McEpsElbPrivateSecurityGroup-M79OXBZEEX74) soit mis à jour pour autoriser le nouveau sous-réseau privé (c'est-à-dire). migration-temp-subnet Si le trafic provenant du sous-réseau dédié CloudEndure (CE) n'est pas autorisé sur les trois ports TCP, l'ingestion du WIGS échouera.

    5. Enfin, demandez une nouvelle politique CloudEndure IAM et un nouvel utilisateur IAM. <Customer Application Subnet (s) + Temp Migration Subnet>La politique nécessite votre numéro de compte correct, et le sous-réseau indiqué IDs dans le RunInstances relevé doit être : votre.

      Pour consulter une CloudEndure politique IAM préapprouvée par AMS : décompressez le fichier d'exemple de zone d'atterrissage WIGS Cloud Endure et ouvrez le. customer_cloud_endure_policy.json

      Note

      Si vous souhaitez une politique plus permissive, discutez-en avec vous CloudArchitect/CSDM et obtenez, si nécessaire, un examen de sécurité AMS et une approbation avant de soumettre une RFC mettant en œuvre la politique.

  2. Les étapes de préparation à utiliser CloudEndure pour l'ingestion de la charge de travail AMS sont terminées et, si votre partenaire de migration a terminé ses étapes de préparation, la migration est prête à être effectuée. Le WIGS RFC est soumis par votre partenaire de migration.

Note

Les clés utilisateur IAM ne seront pas partagées directement, mais doivent être saisies dans la console de CloudEndure gestion par l'opérateur AMS lors d'une session de partage d'écran.

Préparation : partenaire de migration et opérateur AMS :

  1. Créez un projet de CloudEndure migration.

    1. Lors de la création du projet, demandez à AMS de saisir les informations d'identification utilisateur IAM lors des sessions de partage d'écran.

    2. Dans Paramètres de réplication -> Choisissez le sous-réseau dans lequel les serveurs de réplication seront lancés, sélectionnez le customer-application-xsous-réseau.

    3. Dans Paramètres de réplication -> Choisissez les groupes de sécurité à appliquer aux serveurs de réplication, sélectionnez les deux groupes de sécurité Sentinel (privé uniquement et EgressAll).

  2. Définissez les options de transfert pour les machines (instances).

    1. Sous-réseau : migration-temp-subnet.

    2. Groupe de sécurité : les deux groupes de sécurité « Sentinel » (privé uniquement et EgressAll).

      Les instances Cutover doivent être en mesure de communiquer avec l'AMS Managed AD et avec les points de terminaison publics AWS.

    3. IP élastique : aucune

    4. IP publique : non

    5. Rôle IAM : customer-mc-ec profil à 2 instances

      Le rôle IAM doit permettre la communication SSM. Mieux vaut utiliser AMS par défaut.

    6. Définissez les balises conformément à la convention.

Migration : Partenaire de migration :

  1. Créez une pile factice sur AMS. Vous utilisez l'identifiant de pile pour accéder aux bastions.

  2. Installez l'agent CloudEndure (CE) sur le serveur source. Pour plus de détails, consultez la section Installation des agents.

  3. Créez des informations d'identification d'administrateur local sur le serveur source.

  4. Planifiez une courte fenêtre de découpage et cliquez sur Découper lorsque vous êtes prêt. Cela finalise la migration et redirige les utilisateurs vers la région AWS cible.

  5. Demandez un accès administrateur à la pile fictive, voir Demande d'accès administrateur.

  6. Connectez-vous au bastion, puis à l'instance de transition à l'aide des informations d'identification d'administrateur local que vous avez créées.

  7. Créez une AMI à sécurité intégrée. Pour plus de détails sur la création AMIs, consultez AMI Create.

  8. Préparez l'instance pour l'ingestion, voirMigration des charges de travail : conditions préalables pour Linux et Windows.

  9. Exécutez WIGS RFC sur l'instance, voir. Workload Ingest Stack : création