

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
<a name="migrate-shared-file-systems-in-an-aws-large-migration"></a>

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

## Résumé
<a name="migrate-shared-file-systems-in-an-aws-large-migration-summary"></a>

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](https://aws.amazon.com/prescriptive-guidance/large-migrations/). 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](https://docs.aws.amazon.com/efs/latest/ug/trnsfr-data-using-datasync.html), d'[Amazon FSx pour Windows File](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/migrate-to-fsx.html) Server et d'[Amazon FSx](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/migrating-fsx-ontap.html) pour ONTAP. NetApp 

## Conditions préalables et limitations
<a name="migrate-shared-file-systems-in-an-aws-large-migration-prereqs"></a>

**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 :
+ Un actif Compte AWS.
+ Vous avez terminé la découverte du portefeuille d'applications pour votre projet de migration de grande envergure et vous avez commencé à élaborer des plans de vague. Pour plus d'informations, consultez le [manuel Portfolio pour les migrations de AWS grande envergure](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-portfolio-playbook/welcome.html).
+ Clouds privés virtuels (VPC) et groupes de sécurité qui autorisent le trafic entrant et sortant entre le centre de données sur site et votre environnement. AWS Pour plus d'informations, consultez les [options de connectivité Network-to Amazon VPC et les exigences AWS DataSync](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html) [du réseau](https://docs.aws.amazon.com/datasync/latest/userguide/datasync-network.html).
+ Autorisations pour créer des AWS CloudFormation piles ou autorisations pour créer des ressources Amazon EFS ou Amazon FSx. Pour plus d'informations, consultez la [CloudFormation documentation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html), la documentation [Amazon EFS ou la](https://docs.aws.amazon.com/efs/latest/ug/security-iam.html) documentation [Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/security-iam.html).
+ Si vous utilisez AWS DataSync pour effectuer la migration, vous avez besoin des autorisations suivantes :
  + Autorisations permettant AWS DataSync d'envoyer des journaux à un groupe de CloudWatch journaux Amazon Logs. Pour plus d'informations, consultez [Autoriser DataSync le téléchargement de journaux vers des groupes de CloudWatch journaux](https://docs.aws.amazon.com/datasync/latest/userguide/monitor-datasync.html#cloudwatchlogs).
  + Autorisations d'accès au groupe de CloudWatch journaux Logs. Pour plus d'informations, voir [Présentation de la gestion des autorisations d'accès à vos ressources CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/iam-access-control-overview-cwl.html).
  + Autorisations permettant de créer des agents et des tâches dans DataSync. Pour plus d'informations, consultez la section [Autorisations IAM requises pour l'utilisation AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/permissions-requirements.html).

**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](https://docs.aws.amazon.com/efs/latest/ug/trnsfr-data-using-datasync.html), d'[Amazon FSx pour Windows File](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/migrate-to-fsx.html) Server et d'[Amazon FSx](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/migrating-fsx-ontap.html) 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
<a name="migrate-shared-file-systems-in-an-aws-large-migration-architecture"></a>

**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.](https://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/images/pattern-img/a30cf791-7a8a-4f71-8927-bc61f3b332f2/images/13232433-7d33-44c8-8998-b720f33f67b3.png)


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.

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

1. 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.](https://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/images/pattern-img/a30cf791-7a8a-4f71-8927-bc61f3b332f2/images/f1e0c94d-0eea-46a8-bdec-3297b34c1d43.png)


La section [Epics](#migrate-shared-file-systems-in-an-aws-large-migration-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.<br />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.<br />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.<br />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,<br />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.<br />9. Dans le service de transfert de données, effectuez une synchronisation finale des données.<br />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.<br />12. Redémarrez et validez les applications. | 

## Outils
<a name="migrate-shared-file-systems-in-an-aws-large-migration-tools"></a>

**Services AWS**
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 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 DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)est 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)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) vous aide à créer et à configurer des systèmes de fichiers partagés dans le AWS Cloud.
+ [Amazon FSx](https://docs.aws.amazon.com/fsx/?id=docs_gateway) 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**
+ [SnapMirror](https://library.netapp.com/ecmdocs/ECMP1196991/html/GUID-BA1081BE-B2BB-4C6E-8A82-FB0F87AC514E.html)est 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](https://library.netapp.com/ecmdocs/ECMP1154894/html/GUID-8F084F85-2AB8-4622-B4F3-2D9E68559292.html) 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](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/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
<a name="migrate-shared-file-systems-in-an-aws-large-migration-best-practices"></a>

**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.

1. **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.

1. **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](https://d1.awsstatic.com/events/Summits/awsnycsummit/Choosing_the_right_AWS_file_storage_service_for_your_deployment_STG302.pdf) (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](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html). Pour un aperçu du processus d'utilisation DataSync pour transférer vos fichiers, consultez [Comment fonctionnent AWS DataSync les transferts](https://docs.aws.amazon.com/datasync/latest/userguide/how-datasync-transfer-works.html).

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](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/migrating-fsx-ontap-snapmirror.html). 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](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/migrate-files-to-fsx.html) à l'aide de Robocopy.

## Épopées
<a name="migrate-shared-file-systems-in-an-aws-large-migration-epics"></a>

### Découvrez
<a name="discover"></a>


| Sous-tâche | Description | Compétences requises | 
| --- | --- | --- | 
| Préparez le classeur de découverte SFS. | 1. Téléchargez les classeurs dans la section [Pièces jointes](#attachments-a30cf791-7a8a-4f71-8927-bc61f3b332f2) de ce modèle. Il contient deux fichiers, **SFS-Discovery-Workbook.xlsx**et **SFS-Wave-Plan-Workbook.xlsx**.<br />2. Ouvrez le **SFS-Discovery-Workbook**fichier dans Microsoft Excel.<br />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.<br />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.<br />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 clientsAdresses IP clientDétails du SFSPoint de montageVous pouvez ajouter les détails du point de montage à votre runbook de migration pour le remontage du SFS après la migration.<br />2. Ouvrez le fichier **SFS-Discovery-Workbook**.<br />3. Sur la **Wave-Sheet**feuille 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`, entrez`10.*.*.*`.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`, entrez`176.16.*.*`.<br />4. Sur la **SFS-Data**feuille 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.<br />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 nameAdresse IPVagueUnité d'organisation (UO)Environnement de serveur, tel que `DEV``QA`, ou `PROD`Application name (Nom de l'application)Propriétaire de l'application et coordonnées<br />2. Ouvrez le fichier **SFS-Discovery-Workbook**.<br />3. Dans la **Server-Data**feuille 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 que`Wave1`), out-of-scope (`OOS`) ou`Retire`.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.<br />4. Enregistrez le classeur. | Ingénieur en migration, responsable de la migration | 

### Plan
<a name="plan"></a>


| Sous-tâche | Description | Compétences requises | 
| --- | --- | --- | 
| Élaborez le plan de vague SFS. | 1. Ouvrez le fichier **SFS-Discovery-Workbook**.<br />2. Vérifiez que toutes les informations collectées lors de la phase de découverte sont exactes et à jour.<br />3. Sur la **Wave-Sheet**feuille 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.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.<br />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](#migrate-shared-file-systems-in-an-aws-large-migration-best-practices). <br />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.<br />6. Ouvrez le **SFS-Wave-Plan-Workbook**fichier que vous avez précédemment téléchargé.<br />7. Dans la **Export-from-Discovery**feuille de travail, sélectionnez la cellule **A2**.<br />8. Collez les données copiées.<br />9. Enregistrez les **SFS-Wave-Plan-Workbook**fichiers **SFS-Discovery-Workbook**et. | 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).<br />2. Dans la **Build-Wave**feuille de travail, sélectionnez la cellule **A2**.<br />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.<br />4. Supprimez toutes les valeurs dupliquées dans la colonne **A.** Pour obtenir des instructions, voir [Supprimer les valeurs dupliquées](https://support.microsoft.com/en-us/office/find-and-remove-duplicates-00e35bea-b46a-4d5d-b28e-66a552dc138d#ID0EDF) (site Web du Microsoft Support).<br />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](#migrate-shared-file-systems-in-an-aws-large-migration-best-practices) de ce modèle.<br />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](#migrate-shared-file-systems-in-an-aws-large-migration-best-practices) de ce modèle.<br />7. Enregistrez le fichier **SFS-Discovery-Workbook**. Vous avez fini de créer un plan de vague pour cette vague.<br />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 | 

### Préparation
<a name="prepare"></a>


| Sous-tâche | Description | Compé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 :+ [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/gs-step-two-create-efs-resources.html)<br />+ [Amazon FSx pour ONTAP NetApp ](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/getting-started-step1.html)<br />+ [Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/getting-started-step1.html) | 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](https://docs.aws.amazon.com/datasync/latest/userguide/configure-logging.html).<br />2. Configurez l'outil de migration et effectuez un transfert de données initial conformément aux instructions de l'outil sélectionné :Pour Amazon EFS, consultez les rubriques suivantes :[Transférez des fichiers vers Amazon EFS à l'aide de AWS DataSync](https://docs.aws.amazon.com/efs/latest/ug/gs-step-four-sync-files.html)Pour Amazon FSx for NetApp ONTAP, consultez ce qui suit :[Migration vers FSx pour ONTAP à l'aide de NetApp SnapMirror](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/migrating-fsx-ontap-snapmirror.html#transfer-data)[Migration vers FSx pour ONTAP à l'aide de AWS DataSync](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/migrate-files-to-fsx-datasync.html)Pour Amazon FSx for Windows File Server, consultez les informations suivantes :[Migration de fichiers existants vers FSx for Windows File Server à l'aide de AWS DataSync](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/migrate-files-to-fsx-datasync.html)[Migration de fichiers existants vers FSx for Windows File Server à l'aide de Robocopy](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/migrate-files-to-fsx.html)<br />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](https://docs.aws.amazon.com/datasync/latest/userguide/task-scheduling.html). 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-Workbook**fichier correspondant à la vague en cours.<br />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 :Pour FSx for Windows File Server, sur la console Amazon FSx, choisissez Systèmes de **fichiers, choisissez** votre système de fichiers, puis consultez **la section Réseau** et sécurité.[Pour FSx for ONTAP, voir Montage de volumes.](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/attach-volumes.html)Pour Amazon EFS, consultez la section [Montage avec une adresse IP](https://docs.aws.amazon.com/efs/latest/ug/mounting-fs-mount-cmd-ip-addr.html).<br />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](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/attach-volumes.html).Pour Amazon EFS, consultez la section [Collecter des informations](https://docs.aws.amazon.com/efs/latest/ug/wt1-test.html#wt1-connect-test-gather-info).<br />4. Sur la **Remount-Summary**feuille de travail, vérifiez que les colonnes **Nouveau chemin** (C) et **Adresse IP du nouveau chemin** (D) reflètent les valeurs mises à jour.<br />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 :[Montage des systèmes de fichiers Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/mounting-fs.html)[Accès aux partages de fichiers FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-file-shares.html#accessing-file-shares)[Montage de FSx pour les volumes ONTAP](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/attach-volumes.html)<br />6. Si aucun serveur dépendant n'est inclus dans cette vague, enregistrez-le sur la **App-Team-Communication**feuille 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.<br />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 | 

### Découper
<a name="cut-over"></a>


| Sous-tâche | Description | Compé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)](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj635851(v=ws.11)) (documentation Microsoft) ou [Gestion des services système avec systemctl](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/managing-systemd_configuring-basic-system-settings#managing-system-services-with-systemctl_managing-systemd) (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](https://docs.aws.amazon.com/datasync/latest/userguide/run-task.html#starting-task) ou consultez la documentation de l'outil de migration tiers que vous avez sélectionné.<br />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](https://docs.aws.amazon.com/datasync/latest/userguide/monitor-datasync.html) et [Surveillance de votre DataSync tâche depuis la ligne de commande](https://docs.aws.amazon.com/datasync/latest/userguide/monitor-datasync.html#monitor-task-command-line). | 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 que`task-0000-exec-1111`.<br />2. Accédez à la section **Enregistrement des tâches** de la DataSync tâche.<br />3. Choisissez le lien du **groupe de CloudWatch journaux**.<br />4. Dans les journaux, recherchez la tâche et l'ID d'exécution.<br />5. Prenez note de toute erreur de transfert. Pour plus d'informations, consultez la section [Erreurs courantes](https://docs.aws.amazon.com/datasync/latest/userguide/CommonErrors.html) dans la DataSync documentation.<br />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éesComparez les autorisations d'accès aux fichiers entre les SFS source et cible.<br />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 | 

### Valider
<a name="validate"></a>


| Sous-tâche | Description | Compé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-Workbook**fichier, sur la **Remount-Summary**feuille de travail, entrez la nouvelle adresse IP du serveur dans la colonne **Nouvelle adresse IP du serveur** (F).<br />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.*<br />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.<br />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
<a name="migrate-shared-file-systems-in-an-aws-large-migration-troubleshooting"></a>


| Problème | Solution | 
| --- | --- | 
| 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](https://support.microsoft.com/en-us/office/fill-a-formula-down-into-adjacent-cells-041edfe2-05bc-40e6-b933-ef48c3f308c6) ou pour [Mac](https://support.microsoft.com/en-au/office/copy-a-formula-by-dragging-the-fill-handle-in-excel-for-mac-dd928259-622b-473f-9a33-83aa1a63e218) (site Web du Support Microsoft). | 

## Ressources connexes
<a name="migrate-shared-file-systems-in-an-aws-large-migration-resources"></a>

**AWS documentation**
+ [AWS DataSync documentation](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)
+ [Documentation Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)
+ [Documentation Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/index.html)
+ [Importantes migrations vers le AWS Cloud](https://aws.amazon.com/prescriptive-guidance/large-migrations/)
  + [Guide pour les AWS grandes migrations](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/welcome.html)
  + [Guide de portefeuille pour les AWS grandes migrations](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-portfolio-playbook/welcome.html)

**Résolution des problèmes**
+ [AWS DataSync Problèmes de résolution des problèmes](https://docs.aws.amazon.com/datasync/latest/userguide/troubleshooting-datasync.html)
+ [Résolution des problèmes liés à Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/troubleshooting.html)
+ [Résolution des problèmes liés au serveur de fichiers Amazon FSx for Windows](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/troubleshooting.html)
+ [Résolution des problèmes liés à Amazon FSx pour ONTAP NetApp ](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/troubleshooting.html)

## Pièces jointes
<a name="attachments-a30cf791-7a8a-4f71-8927-bc61f3b332f2"></a>

[Pour accéder au contenu supplémentaire associé à ce document, téléchargez et décompressez le fichier suivant : attachment.zip](samples/p-attach/a30cf791-7a8a-4f71-8927-bc61f3b332f2/attachments/attachment.zip)