View a markdown version of this page

Migrer des systèmes de fichiers partagés dans un AWS migration de grande envergure - Recommandations AWS
RésuméConditions préalables et limitationsArchitectureOutilsBonnes pratiquesÉpopéesRésolution des problèmesRessources connexesPièces jointes

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.

Migrer des systèmes de fichiers partagés dans un AWS migration de grande envergure

Amit Rudraraju, Sam Apa, Bheemeswararao Balla, Wally Lu et Sanjeev Prakasam, Amazon Web Services

Résumé

La migration de 300 serveurs ou plus est considérée comme une migration de grande envergure. L'objectif d'une migration de grande envergure est de faire migrer les charges de travail de leurs centres de données locaux existants vers le AWS Cloud, et ces projets se concentrent généralement sur les charges de travail des applications et des bases de données. Cependant, les systèmes de fichiers partagés nécessitent une attention particulière et un plan de migration distinct. Ce modèle décrit le processus de migration des systèmes de fichiers partagés et fournit les meilleures pratiques pour réussir leur migration dans le cadre d'un projet de migration de grande envergure.

Un système de fichiers partagé (SFS), également appelé réseau ou système de fichiers en cluster, est un partage de fichiers monté sur plusieurs serveurs. Les systèmes de fichiers partagés sont accessibles via des protocoles tels que NFS (Network File System), CIFS (Common Internet File System) ou SMB (Server Message Block).

Ces systèmes ne sont pas migrés à l'aide d'outils de migration standard, par exemple AWS Transform MGN parce qu'ils ne sont ni dédiés à l'hôte à migrer ni représentés sous forme de périphérique en mode bloc. Bien que la plupart des dépendances de l'hôte soient migrées de manière transparente, la coordination et la gestion des systèmes de fichiers dépendants doivent être gérées séparément.

Vous migrez des systèmes de fichiers partagés selon les phases suivantes : découverte, planification, préparation, découpe et validation. À l'aide de ce modèle et des classeurs joints, vous migrez votre système de fichiers partagé vers un service de AWS stockage, tel qu'Amazon Elastic File System (Amazon EFS), Amazon FSx NetApp pour ONTAP ou Amazon FSx for Windows File Server. Pour transférer le système de fichiers, vous pouvez utiliser AWS DataSync un outil tiers, tel que NetApp SnapMirror.

Note

Ce modèle fait partie d'une série de directives AWS prescriptives sur les grandes migrations vers le. AWS Cloud Ce modèle inclut les meilleures pratiques et les instructions pour intégrer les SFS dans vos plans de vague pour les serveurs. Si vous migrez un ou plusieurs systèmes de fichiers partagés en dehors d'un projet de migration de grande envergure, consultez les instructions de transfert de données figurant dans la AWS documentation d'Amazon EFS, d'Amazon FSx pour Windows File Server et d'Amazon FSx pour ONTAP. NetApp

Conditions préalables et limitations

Conditions préalables

Les prérequis peuvent varier en fonction de vos systèmes de fichiers partagés source et cible et de votre cas d'utilisation. Les plus courants sont les suivants :

Limites

  • Ce modèle est conçu pour migrer les SFS dans le cadre d'un projet de migration de grande envergure. Il inclut les meilleures pratiques et les instructions pour intégrer les SFS dans vos plans de migration d'applications. Si vous migrez un ou plusieurs systèmes de fichiers partagés en dehors d'un projet de migration de grande envergure, consultez les instructions de transfert de données figurant dans la AWS documentation d'Amazon EFS, d'Amazon FSx pour Windows File Server et d'Amazon FSx pour ONTAP. NetApp

  • Ce modèle est basé sur les architectures, les services et les modèles de migration couramment utilisés. Cependant, les grands projets et stratégies de migration peuvent varier d'une organisation à l'autre. Vous devrez peut-être personnaliser cette solution ou les classeurs fournis en fonction de vos besoins.

Architecture

Pile technologique source

Un ou plusieurs des éléments suivants :

  • serveur de fichiers Linux (NFS)

  • Serveur de fichiers Windows (SMB)

  • NetApp baie de stockage

  • Unité multidisque de stockage Dell EMC Isilon

Pile technologique cible

Un ou plusieurs des éléments suivants :

  • Amazon Elastic File System

  • Amazon FSx pour ONTAP NetApp

  • Amazon FSx for Windows File Server

Architecture cible

Schéma d'architecture de l'utilisation d'AWS DataSync pour migrer des systèmes de fichiers partagés sur site vers AWS.

Le schéma montre le processus suivant :

  1. Vous établissez une connexion entre le centre de données sur site et le AWS Cloud en utilisant un Service AWS tel que AWS Direct Connect ou AWS Site-to-Site VPN.

  2. Vous installez l' DataSync agent dans le centre de données local.

  3. Selon votre plan de vague, vous pouvez DataSync répliquer les données du système de fichiers partagé source vers le partage de AWS fichiers cible.

Phases de migration

L'image suivante montre les phases et les étapes de haut niveau de la migration d'un SFS dans le cadre d'un projet de migration de grande envergure.

Découvrez, planifiez, préparez, supprimez et validez les phases de migration des systèmes de fichiers partagés vers AWS.

La section Epics de ce modèle contient des instructions détaillées sur la façon de terminer la migration et d'utiliser les classeurs joints. Voici un aperçu général des étapes de cette approche progressive.

Phase

Étapes

Découvrez

1. À l'aide d'un outil de découverte, vous collectez des données sur le système de fichiers partagé, notamment les serveurs, les points de montage et les adresses IP.

2. À l'aide d'une base de données de gestion de configuration (CMDB) ou de votre outil de migration, vous collectez des informations sur le serveur, notamment des informations sur la vague de migration, l'environnement, le propriétaire de l'application, le nom du service de gestion des services informatiques (ITSM), l'unité organisationnelle et l'ID de l'application.

Plan

3. À l'aide des informations collectées sur les SFS et les serveurs, créez le plan de vague SFS.

4. À l'aide des informations contenues dans la feuille de travail de génération, pour chaque SFS, choisissez une cible Service AWS et un outil de migration.

Préparation

5. Configurez l'infrastructure cible dans Amazon EFS, Amazon FSx pour NetApp ONTAP ou Amazon FSx for Windows File Server.

6. Configurez le service de transfert de données, par exemple DataSync, puis lancez la synchronisation initiale des données. Lorsque la synchronisation initiale est terminée, vous pouvez configurer des synchronisations récurrentes pour qu'elles s'exécutent selon un calendrier,

7. Mettez à jour le plan de vague SFS avec des informations sur le partage de fichiers cible, telles que l'adresse IP ou le chemin.

Découper

8. Arrêtez les applications qui accèdent activement au SFS source.

9. Dans le service de transfert de données, effectuez une synchronisation finale des données.

10. Lorsque la synchronisation est terminée, vérifiez qu'elle s'est parfaitement déroulée en consultant les données du journal dans CloudWatch Logs.

Valider

11. Sur les serveurs, remplacez le point de montage par le nouveau chemin SFS.

12. Redémarrez et validez les applications.

Outils

Services AWS

  • Amazon CloudWatch Logs vous aide à centraliser les journaux de tous vos systèmes et applications, Services AWS afin que vous puissiez les surveiller et les archiver en toute sécurité.

  • AWS DataSyncest un service de transfert et de découverte de données en ligne qui vous permet de déplacer des fichiers ou des données d'objets vers, depuis et entre les services AWS de stockage.

  • Amazon Elastic File System (Amazon EFS) vous aide à créer et à configurer des systèmes de fichiers partagés dans le AWS Cloud.

  • Amazon FSx fournit des systèmes de fichiers qui prennent en charge les protocoles de connectivité standard du secteur et offrent une disponibilité et une réplication élevées entre eux. Régions AWS

Autres outils

  • SnapMirrorest un outil de réplication de NetApp données qui réplique les données provenant de volumes sources ou de qtrees spécifiés vers des volumes cibles ou des qtrees, respectivement. Vous pouvez utiliser cet outil pour migrer un système de fichiers NetApp source vers Amazon FSx for NetApp ONTAP.

  • Robocopy, abréviation de Robust File Copy, est un répertoire de ligne de commande et une commande pour Windows. Vous pouvez utiliser cet outil pour migrer un système de fichiers source Windows vers Amazon FSx for Windows File Server.

Bonnes pratiques

Approches de planification des vagues

Lorsque vous planifiez des vagues pour votre projet de migration de grande envergure, tenez compte de la latence et des performances des applications. Lorsque le SFS et les applications dépendantes fonctionnent dans différents emplacements, tels que l'un dans le cloud et l'autre dans le centre de données sur site, cela peut augmenter la latence et affecter les performances des applications. Les options disponibles lors de la création de plans de vagues sont les suivantes :

  1. Migrez le SFS et tous les serveurs dépendants au sein de la même vague : cette approche permet d'éviter les problèmes de performances et de minimiser les retouches, telles que la reconfiguration des points de montage à plusieurs reprises. Il est recommandé lorsqu'une très faible latence est requise entre l'application et le SFS. Cependant, la planification des vagues est complexe et l'objectif est généralement de supprimer des variables des groupes de dépendances, et non d'en ajouter. De plus, cette approche n'est pas recommandée si de nombreux serveurs accèdent au même SFS, car cela rend la vague trop importante.

  2. Migrer le SFS après la migration du dernier serveur dépendant : par exemple, si plusieurs serveurs accèdent à un SFS et que la migration de ces serveurs est planifiée au cours des vagues 4, 6 et 7, planifiez le SFS pour qu'il migre au cours de la vague 7.

    Cette approche est souvent la plus logique pour les grandes migrations et elle est recommandée pour les applications sensibles à la latence. Il réduit les coûts associés au transfert de données. Cela minimise également la période de latence entre le SFS et les applications de niveau supérieur (telles que la production), car les applications de niveau supérieur sont généralement programmées pour migrer en dernier, après les applications de développement et d'assurance qualité.

    Cependant, cette approche nécessite toujours de la découverte, de la planification et de l'agilité. Il se peut que vous deviez migrer le SFS lors d'une vague précédente. Vérifiez que les applications peuvent supporter la latence supplémentaire pendant la période comprise entre la première vague dépendante et la vague contenant le SFS. Organisez une session de découverte avec les propriétaires de l'application et faites migrer l'application la plus sensible à la latence en même temps. Si des problèmes de performances sont découverts après la migration d'une application dépendante, préparez-vous à effectuer une transition rapide pour migrer le SFS le plus rapidement possible.

  3. Migrer le SFS à la fin d'un projet de migration de grande envergure : cette approche est recommandée si la latence n'est pas un facteur, par exemple lorsque les données du SFS sont rarement consultées ou qu'elles ne sont pas essentielles aux performances de l'application. Cette approche rationalise la migration et simplifie les tâches de transfert.

Vous pouvez combiner ces approches en fonction de la sensibilité à la latence de l'application. Par exemple, vous pouvez migrer les SFS sensibles à la latence en utilisant les approches 1 ou 2, puis migrer le reste des SFS en utilisant l'approche 3.

Choix d'un service AWS de système de fichiers

AWS propose plusieurs services cloud pour le stockage de fichiers. Chacune offre des avantages et des limites différents en termes de performances, d'évolutivité, d'accessibilité, d'intégration, de conformité et d'optimisation des coûts. Il existe des options par défaut logiques. Par exemple, si votre système de fichiers sur site actuel fonctionne sous Windows Server, Amazon FSx for Windows File Server est le choix par défaut. Ou si le système de fichiers sur site utilise NetApp ONTAP, Amazon FSx for NetApp ONTAP est le choix par défaut. Toutefois, vous pouvez choisir un service cible en fonction des exigences de votre application ou pour bénéficier d'autres avantages liés à l'exploitation du cloud. Pour plus d'informations, voir Choisir le service de stockage de AWS fichiers adapté à votre déploiement (présentation AWS du sommet).

Choix d'un outil de migration

Amazon EFS et Amazon FSx prennent en charge l'utilisation de AWS DataSync pour migrer des systèmes de fichiers partagés vers le. AWS Cloud Pour plus d'informations sur les systèmes et services de stockage pris en charge, les avantages et les cas d'utilisation, voir Qu'est-ce que c'est AWS DataSync. Pour un aperçu du processus d'utilisation DataSync pour transférer vos fichiers, consultez Comment fonctionnent AWS DataSync les transferts.

Plusieurs outils tiers sont également disponibles, notamment les suivants :

  • Si vous choisissez Amazon FSx pour NetApp ONTAP, vous pouvez l'utiliser pour NetApp SnapMirror migrer les fichiers du centre de données sur site vers le cloud. SnapMirror utilise la réplication au niveau des blocs, qui peut être plus rapide que le processus de transfert de données DataSync et en réduire la durée. Pour plus d'informations, consultez la section Migration vers FSx pour ONTAP à l'aide de. NetApp SnapMirror

  • Si vous choisissez Amazon FSx for Windows File Server, vous pouvez utiliser Robocopy pour migrer des fichiers vers le cloud. Pour plus d'informations, voir Migration de fichiers existants vers FSx for Windows File Server à l'aide de Robocopy.

Épopées

Sous-tâcheDescriptionCompétences requises

Préparez le classeur de découverte SFS.

  1. Téléchargez les classeurs dans la section Pièces jointes de ce modèle. Il contient deux fichiers, SFS-Discovery-Workbook.xlsxet SFS-Wave-Plan-Workbook.xlsx.

  2. Ouvrez le SFS-Discovery-Workbookfichier dans Microsoft Excel.

  3. Dans la feuille de travail du tableau de bord, procédez comme suit :

    • Dans la colonne A, mettez à jour le nom de l'environnement.

    • Dans la colonne B, mettez à jour l'ordre des environnements pour les classer de la priorité la plus faible (1) à la priorité la plus élevée.

    • Dans les colonnes D—E, mettez à jour le calendrier des vagues.

    • Dans les colonnes C et K, mettez à jour les noms des comptes AWS.

    • Dans la colonne L, mettez à jour les identifiants VPC.

    • Dans les colonnes M—O, mettez à jour les ID de sous-réseau.

  4. Passez en revue le reste du modèle de classeur et mettez à jour toutes les autres valeurs nécessaires à votre organisation ou à votre cas d'utilisation.

  5. Enregistrez le classeur.

Ingénieur en migration, responsable de la migration

Collectez des informations sur le SFS source.

  1. À l'aide de votre outil de découverte préféré, identifiez tous les montages SFS sur tous les périphériques de stockage, serveurs Linux et serveurs Windows applicables. En règle générale, vous devez collecter les informations suivantes :

    • Appareils clients

    • Adresses IP client

    • Détails du SFS

    • Point de montage

      Note

      Vous pouvez ajouter les détails du point de montage à votre runbook de migration pour le remontage du SFS après la migration.

  2. Ouvrez le fichier SFS-Discovery-Workbook.

  3. Sur la Wave-Sheetfeuille de travail, procédez comme suit :

    • Dans la colonne Emplacement du serveur (D), dans la formule, vérifiez que le format de la plage CIDR pour la source locale fonctionne pour votre plage. Par exemple, si votre plage CIDR est égale à10.0.0.0/8, entrez10.*.*.*.

    • Dans la colonne Emplacement SFS (E), dans la formule, vérifiez que le format de la plage CIDR pour le VPC cible convient à votre plage. Par exemple, si votre plage CIDR est égale à176.16.0.0/16, entrez176.16.*.*.

  4. Sur la SFS-Datafeuille de travail, procédez comme suit :

    • Dans la colonne Nom du serveur (A), entrez le nom du serveur sur lequel le SFS est monté.

    • Dans la colonne SFS path (B), entrez le nom du SFS.

    • Dans la colonne Adresse IP (C), entrez l'adresse IP du serveur.

    • Ajoutez toutes les autres informations pertinentes que vous avez collectées lors de la découverte, telles que le point de montage et la taille du SFS. Vous pourrez utiliser ces données ultérieurement pour modifier les calculs de planification des vagues.

  5. Enregistrez le classeur.

Ingénieur en migration, responsable de la migration

Collectez des informations sur les serveurs.

  1. À l'aide de votre CMDB ou des données enregistrées dans votre outil de migration, identifiez toutes les informations suivantes concernant les serveurs dotés de montages SFS :

    • Server name

    • Adresse IP

    • Vague

    • Unité d'organisation (UO)

    • Environnement de serveur, tel que DEVQA, ou PROD

    • Application name (Nom de l'application)

    • Propriétaire de l'application et coordonnées

  2. Ouvrez le fichier SFS-Discovery-Workbook.

  3. Dans la Server-Datafeuille de travail, dans les colonnes A à H, entrez les informations que vous avez collectées sur les serveurs sources. Notez ce qui suit :

    • Dans la colonne Wave # (C), entrez le nom de la vague (tel queWave1), out-of-scope (OOS) ouRetire.

    • Si la colonne de contact du propriétaire de l'application (H) est indiquée, vérifiez que l'adresse e-mail est correcte. Cette adresse e-mail est automatiquement générée en fonction du nom que vous avez indiqué dans la colonne Propriétaire de l'application (G). Si nécessaire, mettez à jour manuellement la valeur pour qu'elle reflète la bonne adresse e-mail.

    • Ne modifiez pas les colonnes I—J, qui contiennent des formules.

  4. Enregistrez le classeur.

Ingénieur en migration, responsable de la migration
Sous-tâcheDescriptionCompétences requises

Élaborez le plan de vague SFS.

  1. Ouvrez le fichier SFS-Discovery-Workbook.

  2. Vérifiez que toutes les informations collectées lors de la phase de découverte sont exactes et à jour.

  3. Sur la Wave-Sheetfeuille de travail, filtrez la colonne SFS wave (K) en fonction de la valeur. 1 Voici une liste de tous les SFS de la première vague.

    Note

    Une valeur de 0 dans cette colonne indique que le SFS n'est pas concerné par la migration. Cela peut être dû au fait que le SFS est déjà hébergé sur AWS ou parce que les serveurs qui accèdent au partage ne sont pas concernés par la migration.

  4. Vérifiez que vous souhaitez migrer ces SFS au cours de cette vague. Pour plus d'informations sur la façon d'attribuer des SFS aux vagues, consultez les approches de planification des vagues dans la section Meilleures pratiques.

  5. Sélectionnez et copiez les cellules contenant les valeurs filtrées. Ne copiez pas la ligne d'en-tête contenant les titres des colonnes.

  6. Ouvrez le SFS-Wave-Plan-Workbookfichier que vous avez précédemment téléchargé.

  7. Dans la Export-from-Discoveryfeuille de travail, sélectionnez la cellule A2.

  8. Collez les données copiées.

  9. Enregistrez les SFS-Wave-Plan-Workbookfichiers SFS-Discovery-Workbooket.

Responsable du développement, Responsable du transfert, Ingénieur de migration, Responsable de la migration

Choisissez la cible Service AWS et l'outil de migration.

  1. Dans le SFS-Wave-Plan-Workbook fichier, sur la Exported-from-Discovery feuille de travail, sélectionnez et copiez les valeurs de la colonne Ancien chemin (C).

  2. Dans la Build-Wavefeuille de travail, sélectionnez la cellule A2.

  3. Collez les données copiées. Les colonnes B à M de cette feuille de travail sont automatiquement mises à jour pour refléter les autres données associées à ce chemin.

  4. Supprimez toutes les valeurs dupliquées dans la colonne A. Pour obtenir des instructions, voir Supprimer les valeurs dupliquées (site Web du Microsoft Support).

  5. Dans la colonne Modèle ou service cible (F), passez en revue la cible recommandée Service AWS et mettez-la à jour si nécessaire. Pour plus d'informations, consultez la section Choix d'un service de système de AWS fichiers dans la section Meilleures pratiques de ce modèle.

  6. Dans la colonne Méthode de migration (G), passez en revue l'outil de migration recommandé et mettez-le à jour si nécessaire. Pour plus d'informations, consultez la section Choix d'un outil de migration dans la section Meilleures pratiques de ce modèle.

  7. Enregistrez le fichier SFS-Discovery-Workbook. Vous avez fini de créer un plan de vague pour cette vague.

  8. Répétez ces instructions pour préparer un plan de vagues pour chaque vague. Les plans de vagues étant susceptibles de changer au cours de la migration, nous vous recommandons de ne pas planifier plus de 5 vagues à l'avance.

Ingénieur en migration, responsable de la migration
Sous-tâcheDescriptionCompétences requises

Configurez le système de fichiers cible.

Selon les détails enregistrés dans votre plan de vague, configurez les systèmes de fichiers cibles dans la cible Compte AWS, le VPC et les sous-réseaux. Pour obtenir des instructions, consultez la AWS documentation suivante :

Ingénieur en migration, responsable de la migration, administrateur AWS

Configurez l'outil de migration et transférez les données.

  1. Si vous utilisez AWS DataSync, configurez la journalisation des DataSync tâches. Pour obtenir des instructions, consultez la section Enregistrement des activités de vos AWS DataSync tâches.

  2. Configurez l'outil de migration et effectuez un transfert de données initial conformément aux instructions de l'outil sélectionné :

  3. Des modifications peuvent être apportées au SFS source pendant ou après le transfert initial. Configurez des transferts de données récurrents entre les systèmes de fichiers source et cible pour assurer la synchronisation des données :

    • Si vous utilisez DataSync, consultez la section Planification de votre AWS DataSync tâche. DataSync transfère uniquement les fichiers modifiés ou nouveaux dans le SFS source.

    • Si vous utilisez un outil tiers, consultez la documentation de l'outil sélectionné.

Administrateur AWS, administrateur cloud, ingénieur de migration, responsable de la migration

Mettez à jour le plan des vagues.

  1. Ouvrez le SFS-Wave-Plan-Workbookfichier correspondant à la vague en cours.

  2. Dans la feuille de travail Build—Wave, dans la colonne New path IP address (N), entrez l'adresse IP du système de fichiers cible. Procédez de l'une des manières suivantes pour localiser l'adresse IP :

  3. Dans la colonne Nouveau chemin (O), entrez le nouveau chemin de montage. Le chemin de montage est le nom DNS du système de fichiers. Procédez de l'une des manières suivantes pour localiser le chemin de montage :

    • Pour FSx for Windows File Server, sur la console Amazon FSx, choisissez Systèmes de fichiers, choisissez votre système de fichiers, puis choisissez Attacher.

    • Pour FSx for ONTAP, consultez la page de détails du système de fichiers. Pour obtenir des instructions, reportez-vous à la section Montage des volumes.

    • Pour Amazon EFS, consultez la section Collecter des informations.

  4. Sur la Remount-Summaryfeuille de travail, vérifiez que les colonnes Nouveau chemin (C) et Adresse IP du nouveau chemin (D) reflètent les valeurs mises à jour.

  5. Vérifiez que votre organisation a préparé des runbooks pour le remontage des systèmes de fichiers Linux et Windows après le transfert. Pour obtenir des instructions générales, consultez les rubriques suivantes :

  6. Si aucun serveur dépendant n'est inclus dans cette vague, enregistrez-le sur la App-Team-Communicationfeuille de travail. Informez les propriétaires de l'application ou du serveur concernés, car ils risquent de ne pas être inclus dans les communications par ondes standard.

  7. Si les SFS sont retirés de la vague une fois le plan de vague terminé, suivez-les sur la feuille de travail Descoped.

Ingénieur en migration, responsable de la migration
Sous-tâcheDescriptionCompétences requises

Arrêtez les applications.

Si des applications ou des clients effectuent activement des opérations de lecture et d'écriture dans le SFS source, arrêtez-les avant de procéder à la synchronisation finale des données. Pour obtenir des instructions, consultez la documentation de l'application ou vos processus internes pour arrêter les activités de lecture et d'écriture. Par exemple, consultez Démarrer ou arrêter le serveur Web (IIS 8) (documentation Microsoft) ou Gestion des services système avec systemctl (documentation Red Hat).

Propriétaire de l'application, développeur de l'application

Effectuez le transfert de données final.

  1. Dans l'outil de migration, exécutez manuellement une tâche ou une tâche de transfert de données finale pour synchroniser le système de fichiers cible avec le SFS source. Pour obtenir des instructions, consultez la section Démarrer votre DataSync tâche ou consultez la documentation de l'outil de migration tiers que vous avez sélectionné.

  2. Attendez que la tâche de transfert de données soit terminée. Pour plus d'informations, consultez Surveillance de AWS DataSync l'activité avec Amazon CloudWatch et Surveillance de votre DataSync tâche depuis la ligne de commande.

Ingénieur en migration, responsable de la migration

Validez le transfert de données.

Si vous utilisez AWS DataSync, procédez comme suit pour valider le transfert de données final effectué avec succès :

  1. Dans la AWS DataSync console, notez la tâche et l'ID d'exécution, tels quetask-0000-exec-1111.

  2. Accédez à la section Enregistrement des tâches de la DataSync tâche.

  3. Choisissez le lien du groupe de CloudWatch journaux.

  4. Dans les journaux, recherchez la tâche et l'ID d'exécution.

  5. Prenez note de toute erreur de transfert. Pour plus d'informations, consultez la section Erreurs courantes dans la DataSync documentation.

  6. Validez les éléments suivants :

    • Comparez les listes de fichiers des SFS source et cible pour confirmer que toutes les données ont été transférées

    • Comparez les autorisations d'accès aux fichiers entre les SFS source et cible.

Si vous utilisez un outil tiers, consultez les instructions de validation du transfert de données dans la documentation de l'outil de migration sélectionné.

Ingénieur en migration, responsable de la migration
Sous-tâcheDescriptionCompétences requises

Remontez le système de fichiers et validez le fonctionnement et les performances de l'application.

  1. Si des serveurs dépendants ont été migrés au cours de cette vague, dans le SFS-Wave-Plan-Workbookfichier, sur la Remount-Summaryfeuille de travail, entrez la nouvelle adresse IP du serveur dans la colonne Nouvelle adresse IP du serveur (F).

  2. Sur tous les serveurs, mettez à jour le point de montage du système de fichiers de l'ancien chemin vers le nouveau. Utilisez le runbook de votre organisation pour le remontage dont il a été question précédemment dans la phase de préparation.

  3. Vérifiez que le système de fichiers est correctement monté et qu'il est accessible en vérifiant les montages et en vérifiant la présence de fichiers. L'équipe chargée de l'infrastructure effectue généralement ces activités.

  4. Redémarrez les applications et demandez aux propriétaires de l'application ou à l'équipe d'assurance qualité d'effectuer des tests fonctionnels et de performance sur l'application, selon les besoins de l'application.

Administrateur système AWS, propriétaire de l'application

Résolution des problèmes

ProblèmeSolution

Les valeurs des cellules dans Microsoft Excel ne sont pas mises à jour.

Copiez les formules dans les lignes d'exemple en faisant glisser la poignée de remplissage. Pour plus d'informations, consultez les instructions pour Windows ou pour Mac (site Web du Support Microsoft).

Ressources connexes

AWS documentation

Résolution des problèmes

Pièces jointes

Pour accéder au contenu supplémentaire associé à ce document, téléchargez et décompressez le fichier suivant : attachment.zip