Migration de StorSimple 8100 et 8600 vers Azure File Sync

La série StorSimple 8000 comprend les appareils électroménagers physiques sur site 8100 ou 8600 et leurs composants de service cloud. Les appliances virtuelles StorSimple 8010 et 8020 sont également traitées dans ce guide de migration. Il est possible de migrer les données de l’une ou l’autre de ces appliances vers des partages de fichiers Azure avec éventuellement Azure File Sync. Azure File Sync est le service Azure à long terme stratégique et par défaut qui remplace la fonctionnalité locale StorSimple. Cet article donne les étapes à suivre pour effectuer correctement une migration vers Azure File Sync, en fournissant toutes les connaissances générales nécessaires.

Notes

Le support du service StorSimple (notamment StorSimple Device Manager pour les séries 8000 et 1200 et StorSimple Data Manager) est terminé. La fin du support de StorSimple a fait l’objet d’une publication en 2019 sur les pages Stratégie de cycle de vie Microsoft et Communications Azure. Des notifications supplémentaires ont été envoyées par e-mail et publiées sur le portail Azure et dans la vue d’ensemble StorSimple. Pour obtenir des informations supplémentaires, contactez le support Microsoft.

Cette vidéo offre une vue d’ensemble des éléments suivants :

• Azure Files
• Azure File Sync
• Comparaison de StorSimple et Azure Files
• Vue d’ensemble des processus et de l’outil de migration StorSimple Data Manager

Phase 1 : Préparation de la migration

Cette section contient les étapes à suivre au début de la migration des volumes StorSimple vers des partages de fichiers Azure.

Cette vidéo aborde les questions suivantes :

• Sélection du niveau de stockage
• Sélection d’options de redondance de stockage
• Sélection de l’accès direct au partage ou d’Azure File Sync
• Clé de cryptage des données du service StorSimple et numéro de série
• Migration de sauvegarde de volume StorSimple
• Mappage des volumes et partages StorSimple avec des partages de fichiers Azure
• Regroupement de partages à l’intérieur de partages de fichiers Azure
• Considérations relatives au mappage
• Feuille de calcul de planification de la migration
• Feuille de calcul de mappage d’espaces de noms

Inventaire

Lorsque vous commencez à planifier votre migration, identifiez tout d’abord toutes les appliances et tous les volumes StorSimple à migrer. Ensuite, vous pourrez décider du meilleur chemin de migration.

• Pour les appliances physiques StorSimple (série 8000) : utilisez ce guide de migration.
• Les appareils électroménagers virtuelles StorSimple (série 1200) utilisent un guide de migration différent.

Résumé des coûts de migration

Les migrations vers des partages de fichiers Azure à partir de volumes StorSimple et via des tâches de migration dans une ressource StorSimple Data Manager sont gratuites. Toutefois, d’autres coûts peuvent être appliqués pendant et après une migration :

• Sortie réseau : Vos fichiers StorSimple résident dans un compte de stockage au sein d’une région Azure spécifique. Si vous provisionnez les partages de fichiers Azure que vous migrez vers un compte de stockage dans la même région Azure, aucun coût de sortie n’est généré. Toutefois, si vous déplacez vos fichiers vers un compte de stockage dans une autre région dans le cadre de cette migration, des frais de sortie s'appliqueront.
• Transactions de partage de fichiers Azure : Lorsque des fichiers sont copiés dans un partage de fichiers Azure (dans le cadre d’une migration ou autre cas de figure), des coûts de transaction s’appliquent à l’écriture des fichiers et des métadonnées. La meilleure pratique consiste à démarrer votre partage de fichiers Azure sur le niveau Transaction optimisée pendant la migration. Basculez sur le niveau souhaité une fois la migration terminée. Les phases décrites dans cet article le soulignent au moment approprié.
• Modification d’un niveau de partage de fichiers Azure : La modification du niveau d’un partage de fichiers Azure entraîne des coûts de transaction. Dans la plupart des cas, il est plus rentable de suivre les conseils du point précédent.
• Coût du stockage : lorsque cette migration commence à copier des fichiers dans un partage de fichiers Azure, le stockage est consommé et facturé. Les sauvegardes migrées deviennent des instantanés de partage de fichiers Azure. Les instantanés de partage de fichiers ne consomment de la capacité de stockage que pour les différences qu'ils contiennent.
• StorSimple : jusqu'à ce que vous annuliez la gestion des appareils et des comptes de stockage StorSimple, les coûts de StorSimple pour le stockage, les sauvegardes et les appareils électroménagers continueront à se produire.

Accès direct au partage par rapport à Azure File Sync

Les partages de fichiers Azure ouvrent un nouveau monde d’opportunités pour structurer le déploiement de vos services de fichiers. Un partage de fichiers Azure est un partage TPE/PME dans le cloud que vous pouvez configurer pour permettre aux utilisateurs d'accéder directement via le protocole TPE/PME avec l'authentification Kerberos familière et les autorisations NTFS existantes (ACL de fichiers et de dossiers) fonctionnant de manière native. En savoir plus sur l’accès aux partages de fichiers Azure en fonction de l’identité.

Une alternative à l’accès direct est Azure File Sync. Azure File Sync est un équivalent direct de la mise en cache locale des fichiers fréquemment utilisés proposée par StorSimple.

Azure File Sync est un service cloud Microsoft basé sur deux composants principaux :

• Synchronisation des fichiers et hiérarchisation cloud pour créer un cache d'accès/performances sur n'importe quel serveur Windows.
• Partages de fichiers comme stockage natif dans Azure, accessibles par le biais de différents protocoles comme SMB et File REST.

Les partages de fichiers Azure conservent des aspects importants de la fidélité des fichiers tels que les attributs, les autorisations et les horodatages. Grâce aux partages de fichiers Azure, il n’est plus nécessaire qu’une application ou un service interprète les fichiers et dossiers stockés dans le cloud. Vous pouvez y accéder de manière native via des protocoles et des clients familiers. Les partages de fichiers Azure vous permettent de stocker dans le cloud des données d’applications et des données de serveurs de fichiers à usage général.

Cet article est consacré aux étapes de migration. Si vous souhaitez en savoir plus sur Azure File Sync avant d’effectuer la migration, consultez les articles suivants :

• Guide de planification Azure File Sync
• Guide de déploiement d’Azure File Sync

Clé de chiffrement des données de service StorSimple

Lorsque vous avez configuré pour la première fois votre appareil StorSimple, celle-ci a généré une clé de chiffrement des données de service et vous a demandé de stocker la clé en toute sécurité. Cette clé est utilisée pour chiffrer toutes les données du compte de stockage Azure associé dans lequel l’appliance StorSimple stocke vos fichiers.

La clé de chiffrement des données du service est nécessaire pour une migration réussie. Récupérez cette clé dans vos dossiers, une pour chacun des appareils électroménagers de votre inventaire.

Si vous ne trouvez pas les clés dans vos dossiers, vous pouvez générer une nouvelle clé à partir de l’appliance. Chaque appliance a une clé de chiffrement unique.

Modifier la clé de chiffrement des données de service

Les clés de chiffrement des données de service permettent de chiffrer les données client confidentielles, telles que les identifiants du compte de stockage, qui sont envoyées à partir votre service StorSimple Manager sur le périphérique StorSimple. Vous devrez modifier ces clés périodiquement si votre service informatique applique une politique de rotation des clés sur les périphériques de stockage. Le processus de modification de la clé peut être légèrement différent selon qu'il y a un ou plusieurs périphériques gérés par le service StorSimple Manager. Pour plus d’informations, accédez à StorSimple security and data protection (Sécurité et protection des données StorSimple).

La modification de la clé de chiffrement est un processus en 3 étapes :

1. À l’aide des scripts Windows PowerShell pour Azure Resource Manager, autorisez un appareil à modifier la clé de chiffrement des données de service.
2. Utiliser Windows PowerShell pour StorSimple pour démarrer la modification de la clé de chiffrement des données du service.
3. Si vous avez plusieurs périphériques StorSimple, mettez à jour la clé de chiffrement des données sur les autres périphériques.

Étape 1 : Utiliser un script Windows PowerShell pour autoriser un appareil à modifier la clé de chiffrement des données de service

En règle générale, l’administrateur de l’appareil demande que l’administrateur du service autorise un appareil à modifier les clés de chiffrement des données du service. Ensuite, l’administrateur du service autorise l’appareil à modifier la clé.

Cette étape est effectuée en utilisant le script basé sur Azure Resource Manager. L’administrateur de services fédérés peut sélectionner un appareil pouvant être autorisé. Après cela, l’appareil est autorisé à démarrer le processus de modification de la clé de chiffrement des données du service.

Pour plus d’informations sur l’utilisation du script, accédez à Authorize-ServiceEncryptionRollover.ps1.

Quels appareils peuvent être autorisés à modifier les clés de chiffrement des données du service ?

Un appareil doit respecter les critères suivants avant d’être autorisé à démarrer des modifications de clé de chiffrement des données du service :

• L’appareil doit être en ligne pour bénéficier de l’autorisation de modification de clé de chiffrement des données du service.
• Si le changement de clé n’a pas été démarré, vous devez attendre 30 minutes avant d’autoriser à nouveau le même appareil.
• Vous pouvez autoriser un autre appareil, sous réserve que la modification de la clé n’a pas été démarrée par l’appareil précédemment autorisé. Une fois le nouvel appareil autorisé, l’ancien appareil ne peut plus démarrer la modification.
• Vous ne pouvez pas autoriser un appareil alors que la substitution de la clé de chiffrement des données du service est en cours.
• Vous pouvez autoriser un appareil lorsque certains appareils inscrits auprès du service ont substitué le chiffrement tandis que d’autres ne l’ont pas fait.

Étape 2 : Utiliser Windows PowerShell pour StorSimple pour démarrer la modification de la clé de chiffrement des données du service

Cette étape s’effectue dans l’interface Windows PowerShell pour StorSimple, sur l’appareil StorSimple autorisé.

Notes

Aucune opération ne peut être effectuée dans le portail Azure de votre service StorSimple Manager avant la fin de la substitution de la clé.

Si vous utilisez la console série de l’appareil pour vous connecter à l’interface Windows PowerShell, procédez comme suit.

Pour démarrer la modification de la clé de chiffrement des données du service

1. Sélectionnez Option 1 pour vous connecter avec un accès complet.

2. À l’invite de commandes, tapez :

   Invoke-HcsmServiceDataEncryptionKeyChange

3. Une fois l’applet de commande terminée, vous obtenez une nouvelle clé de chiffrement des données du service. Copiez et enregistrez cette clé pour l’utiliser lors de l’étape 3 de cette procédure. Cette clé permet de mettre à jour tous les appareils restants inscrits auprès du service StorSimple Manager.

   Notes

   Ce processus doit être démarré dans les quatre heures suivant l’autorisation d’un appareil StorSimple.

   Cette nouvelle clé est ensuite envoyée au service pour être transmise à tous les appareils inscrits auprès du service. Une alerte s’affiche alors sur le tableau de bord du service. Le service désactive toutes les opérations sur les appareils inscrits et l’administrateur de l’appareil doit alors mettre à jour la clé de chiffrement des données du service sur les autres appareils. Toutefois, les E/S (hôtes envoyant des données vers le cloud) ne sont pas interrompues.

   Si vous avez un seul appareil inscrit auprès de votre service, le processus de substitution est maintenant terminé et vous pouvez ignorer l’étape suivante. Si vous avez plusieurs appareils inscrits auprès de votre service, passez à l’étape 3.

Étape 3 : Mettre à jour la clé de chiffrement sur les autres appareils StorSimple

Si vous avez plusieurs appareils inscrits auprès du service StorSimple Manager, cette procédure s’effectue dans l’interface Windows PowerShell de votre appareil StorSimple. La clé que vous avez obtenue à l’étape 2 doit être utilisée pour mettre à jour tous les appareils StorSimple restant inscrits auprès du service StorSimple Manager.

Procédez comme suit pour mettre à jour le chiffrement des données du service sur votre appareil.

Pour mettre à jour la clé de chiffrement des données de service sur des appareils physiques

1. Utilisez Windows PowerShell pour StorSimple pour vous connecter à la console. Sélectionnez Option 1 pour vous connecter avec un accès complet.
2. À l’invite de commandes, tapez : Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey
3. Fournir la clé de chiffrement de données de service que vous avez obtenue à l’étape 2 : Utiliser Windows PowerShell pour StorSimple pour démarrer la modification de la clé de chiffrement des données du service.

Pour mettre à jour la clé de chiffrement des données de service sur toutes les appliances cloud 8010/8020

1. Téléchargez et installez le script PowerShell Update-CloudApplianceServiceEncryptionKey.ps1.
2. Ouvrez PowerShell et, à l’invite de commandes, tapez : Update-CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device manager]

Ce script permet de garantir que la clé de chiffrement des données de service est définie sur toutes les appliances cloud 8010/8020 sous Device Manager.

Attention

Lorsque vous décidez de la façon de vous connecter à votre appliance StorSimple, prenez en compte les points suivants :

• La connexion via une session HTTPS est l’option la plus sûre et celle qui est recommandée.
• La connexion directe à la console série du périphérique est sécurisée, mais la connexion à la console série via des commutateurs réseau ne l'est pas.
• Les connexions de session HTTP sont possibles, mais elles ne sont pas chiffrées. Elles ne sont donc pas recommandées, sauf si vous les utilisez au sein d’un réseau approuvé et fermé.

Limitations connues

Les partages de fichiers StorSimple Data Manager et Azure présentent quelques limitations que vous devez prendre en compte avant de commencer, car ils peuvent empêcher une migration :

• Seuls les volumes NTFS de votre appliance StorSimple sont pris en charge. Les volumes ReFS ne sont pas pris en charge.
• Tout volume placé sur les disques dynamiques Windows Server n'est pas pris en charge.
• Le service ne fonctionne pas avec des volumes chiffrés par BitLocker ou pour lesquels la Déduplication des données est activée.
• Les sauvegardes StorSimple endommagées ne peuvent pas être migrées.
• Les options de mise en réseau spéciales, telles que les pare-feu ou la communication privée réservée aux points de terminaison, ne peuvent être activées ni sur le compte de stockage source où les sauvegardes StorSimple sont stockées, ni sur le compte de stockage cible qui contient vos partages de fichiers Azure.

Fidélité de fichier

Si aucune des limitations indiquées dans Limitations connues n’empêche une migration, il existe toujours des limitations sur ce qui peut être stocké dans les partages de fichiers Azure.

La Fidélité de fichier fait référence à la multitude d’attributs, d’horodatages et de données qui composent un fichier. Dans une migration, la fidélité des fichiers est une mesure de la manière dont les informations sur la source (volume StorSimple) peuvent être traduites (migrées) vers le partage de fichiers Azure cible.

Azure Files prend en charge un sous-ensemble des propriétés de fichier NTFS. Les ACL Windows, les métadonnées communes et certains horodatages sont migrés.

Les éléments suivants n’empêchent pas la migration, mais entraînent des problèmes par élément au cours d’une migration :

• Horodatage : l'heure de changement de fichier ne sera pas définie. Il est actuellement en lecture seule via le protocole REST. L’horodatage du dernier accès sur un fichier ne sera pas déplacé, car il ne s’agit pas d’un attribut pris en charge sur les fichiers stockés dans un partage de fichiers Azure.
• Des flux de données alternatifs ne peuvent pas être stockés dans les partages de fichiers Azure. Les fichiers qui contiennent des flux de données alternatifs sont copiés, mais les flux de données alternatifs sont supprimés du fichier pendant le processus.
• Les liens symboliques, les liens physiques, les jonctions et les points d’analyse sont ignorés pendant une migration. Les journaux de copie de migration répertorient chaque élément ignoré et une raison.
• Les fichiers cryptés EFS ne parviennent pas à être copiés. Les journaux de copie indiquent que l'élément n'a pas pu être copié avec « Accès refusé ».
• Les fichiers endommagés sont ignorés. Les journaux de copie peuvent répertorier différentes erreurs pour chaque élément corrompu sur le disque StorSimple : « La demande a échoué en raison d'une erreur matérielle fatale du périphérique » ou « Le fichier ou le répertoire est corrompu ou illisible » ou « La liste de contrôle d'accès (ACL) la structure n'est pas valide".
• Les fichiers qui dépassent 4 TiO sont ignorés.
• Les longueurs de chemin de fichier doivent être inférieures ou égales à 2 048 caractères. Les fichiers et dossiers avec des chemins plus longs sont ignorés.
• Les points d'analyse sont ignorés. Les points d'analyse de déduplication de données Microsoft/SIS ou ceux de tiers ne peuvent pas être résolus par le moteur de migration et empêcheront une migration des fichiers et dossiers concernés.

La section de résolution des problèmes à la fin de cet article contient plus de détails sur les codes d’erreur au niveau de l’élément et au niveau du travail de migration et, dans la mesure du possible, leurs options d’atténuation.

Sauvegardes de volume StorSimple

StorSimple propose des sauvegardes différentielles au niveau du volume. Les partages de fichiers Azure ont également cette capacité, appelée « instantanés de partage ».

Vos tâches de migration ne peuvent déplacer que les sauvegardes, jamais les données du volume actif. Par conséquent, la sauvegarde la plus récente est la plus proche des données actives et doit donc toujours figurer sur la liste des sauvegardes à déplacer dans le cadre d'une migration.

Déterminez si vous devez déplacer les anciennes sauvegardes au cours de la migration. Il est recommandé de conserver cette liste aussi petite que possible afin que vos tâches de migration se terminent plus rapidement.

Pour identifier les sauvegardes critiques qui doivent être migrées, établissez une liste de vérification de vos stratégies de sauvegarde. Par exemple :

• la sauvegarde la plus récente.
• Une sauvegarde par mois pendant 12 mois.
• Une sauvegarde par an pendant trois ans.

Lorsque vous créez vos tâches de migration, vous pouvez utiliser cette liste pour identifier les sauvegardes de volume StorSimple exactes qui doivent être migrées pour répondre à vos besoins.

Il est préférable de suspendre toutes les stratégies de rétention de sauvegarde StorSimple avant de sélectionner une sauvegarde pour la migration. La migration de vos sauvegardes peut prendre plusieurs jours ou semaines. StorSimple propose des politiques de conservation des sauvegardes qui suppriment les sauvegardes. Les sauvegardes que vous avez sélectionnées pour cette migration peuvent être supprimées avant d'avoir eu la possibilité d'être migrées.

Attention

La sélection de plus de 50 sauvegardes de volume StorSimple n'est pas prise en charge.

Mapper vos volumes StorSimple existants à des partages de fichiers Azure

Dans cette étape, vous allez déterminer le nombre de partages de fichiers Azure dont vous avez besoin. Une seule instance Windows Server (ou cluster) peut synchroniser jusqu’à 30 partages de fichiers Azure.

Vous pouvez avoir plus de dossiers dans vos volumes que ce que vous partagez actuellement localement en tant que partages SMB pour vos utilisateurs et applications. La solution la plus simple pour décrire ce scénario consiste à envisager un mappage 1:1 entre un partage local et un partage de fichiers Azure. Si vous avez un nombre suffisamment petit de partages, inférieur à 30 pour une seule instance Windows Server, nous vous recommandons un mappage 1:1.

Si vous avez plus de 30 partages, il est souvent inutile de mapper un partage local 1:1 à un partage de fichiers Azure. Tenez compte des options suivantes.

Regroupement de partages

Par exemple, si votre service des ressources humaines (RH) a 15 partages, vous pouvez envisager de stocker toutes les données RH dans un seul partage de fichiers Azure. Le stockage de plusieurs partages locaux dans un partage de fichiers Azure ne vous empêche pas de créer les 15 partages SMB habituels sur votre instance locale de Windows Server. Cela signifie simplement que vous organisez les dossiers racine de ces 15 partages en sous-dossiers sous un dossier commun. Vous synchronisez ensuite ce dossier commun avec un partage de fichiers Azure. Ainsi, un seul partage de fichiers Azure dans le cloud est nécessaire pour ce groupe de partages locaux.

Synchronisation de volume

Azure File Sync prend en charge la synchronisation de la racine d’un volume avec un partage de fichiers Azure. Si vous synchronisez la racine du volume, tous les sous-dossiers et fichiers se retrouvent dans le même partage de fichiers Azure.

La synchronisation de la racine du volume n’est pas toujours la meilleure option. Il y a des avantages à synchroniser plusieurs emplacements. Par exemple, cela permet de maintenir un nombre d’éléments plus bas par étendue de synchronisation. Nous testons les partages de fichiers Azure et Azure File Sync avec 100 millions d’éléments (fichiers et dossiers) par partage. Cela dit, la bonne pratique est d’essayer de garder le nombre au-dessous de 20 ou 30 millions dans un même partage. La configuration d’Azure File Sync avec un nombre d’éléments inférieur n’est pas seulement avantageuse pour la synchronisation de fichiers. Un nombre inférieur d’éléments présente également des avantages pour d’autres scénarios comme :

• L’analyse initiale du contenu cloud peut se terminer plus rapidement, ce qui réduit l’attente de l’affichage de l’espace de noms sur un serveur activé pour Azure File Sync.
• La restauration côté cloud à partir d’un instantané de partage de fichiers Azure sera plus rapide.
• La reprise d’activité d’un serveur local peut être considérablement accélérée.
• Les modifications apportées directement dans un partage de fichiers Azure (en dehors de la synchronisation) peuvent être détectées et synchronisées plus rapidement.

Conseil

Si vous ne savez pas combien de fichiers et de dossiers vous avez, consultez l’outil d’arborescence de JAM Software GmbH.

Approche structurée d’un plan de déploiement

Avant de déployer un stockage cloud par la suite, vous devez créer un mappage entre des dossiers locaux et des partages de fichiers Azure. Ce mappage indique le nombre et la nature des ressources de groupe de synchronisation Azure File Sync à provisionner. Un groupe de synchronisation lie le partage de fichiers Azure et le dossier sur votre serveur et établit une connexion de synchronisation.

Pour déterminer le nombre de partages de fichiers Azure dont vous avez besoin, passez en revue les limites et bonnes pratiques suivantes. Cela vous permet d’optimiser votre mappage.

• Un serveur sur lequel l’agent Azure File Sync est installé peut se synchroniser avec un maximum de 30 partages de fichiers Azure.

• Un partage de fichiers Azure est déployé dans un compte de stockage. Cet arrangement fait du compte de stockage une cible de mise à l’échelle pour les chiffres des performances comme les IOPS et le débit.

  Lors du déploiement de partages de fichiers Azure, soyez attentif aux limitations d’IOPS d’un compte de stockage. Dans l’idéal, une correspondance 1:1 doit être respectée entre les partages de fichiers et les comptes de stockage. Mais cela n’est pas toujours possible en raison des différentes limites et restrictions imposées par votre organisation et Azure. Lorsqu’il est impossible de déployer un seul partage de fichiers dans un seul compte de stockage, il convient d’identifier les partages qui seront plus ou moins actifs afin de veiller à ce que les plus actifs ne soient pas regroupés sur le même compte de stockage.

  Si vous envisagez d’intégrer une application dans Azure qui utilisera le partage de fichiers Azure en mode natif, vous devrez peut-être augmenter les performances de votre partage de fichiers Azure. Si ce type d’utilisation est une éventualité, même future, il est préférable de créer un partage de fichiers Azure standard dans son propre compte de stockage.

• Il existe une limite de 250 comptes de stockage par abonnement et par région Azure.

Conseil

Au vu de ces informations, il est souvent nécessaire de regrouper plusieurs dossiers de niveau supérieur sur vos volumes dans un nouveau répertoire racine commun. Vous synchronisez ensuite ce nouveau répertoire racine et tous les dossiers que vous y avez regroupés dans un seul partage de fichiers Azure. Cette technique vous permet de rester dans la limite de 30 synchronisations de partage de fichiers Azure par serveur.

Ce regroupement sous une racine commune n’affecte pas l’accès à vos données. Vos listes de contrôle d’accès restent telles quelles. Vous avez seulement besoin d’ajuster les chemins de partage (par exemple, des partages SMB ou NFS) que vous pouvez avoir sur les dossiers de serveur locaux et que vous avez maintenant changés en racine commune. Rien d’autre ne change.

Important

Le vecteur d’échelle le plus important pour Azure File Sync est le nombre d’éléments (fichiers et dossiers) qui doivent être synchronisés. Pour plus d’informations, consultez Cibles de mise à l’échelle Azure File Sync.

Il est recommandé de maintenir un petit nombre d’éléments par étendue de synchronisation. C’est un facteur important à prendre en compte quand vous mappez des dossiers aux partages de fichiers Azure. Azure File Sync est testé avec 100 millions d’éléments (fichiers et dossiers) par partage. Cela dit, il est souvent préférable de garder le nombre d’éléments au-dessous de 20 ou 30 millions dans un même partage. Fractionnez votre espace de noms en plusieurs partages si vous commencez à dépasser ces nombres. Vous pouvez continuer à regrouper plusieurs partages locaux dans le même partage de fichiers Azure, à condition que vous restiez plus ou moins en dessous de ces chiffres. Cette méthode vous donne de la marge pour évoluer.

Dans votre situation, il est possible qu’un ensemble de dossiers puisse logiquement se synchroniser avec le même partage de fichiers Azure (en utilisant la nouvelle approche de dossier racine commun mentionnée plus haut). Toutefois, il peut être préférable de regrouper les dossiers de manière à ce qu’ils se synchronisent avec deux partages de fichiers Azure au lieu d’un. Vous pouvez utiliser cette approche pour conserver l’équilibre entre le nombre de fichiers et de dossiers par partage de fichiers sur le serveur. Vous pouvez également diviser vos partages locaux et synchroniser sur d’autres serveurs locaux, en ajoutant la possibilité de synchroniser avec 30 autres partages de fichiers Azure par serveur supplémentaire.

Scénarios fréquents de synchronisation de fichiers et observations

#	Scénario de synchronisation	Prise en charge	Observations (ou limitations)	Solution (ou solution de contournement)
1	Serveur de fichiers avec plusieurs disques/volumes et plusieurs partages sur le même partage de fichiers Azure cible (consolidation)	Non	Un partage de fichiers Azure cible (point de terminaison cloud) ne prend en charge la synchronisation qu’avec un seul groupe de synchronisation. Un groupe de synchronisation ne prend en charge qu’un seul point de terminaison de serveur par serveur inscrit.	1) Commencez par synchroniser un disque (son volume racine) pour cibler le partage de fichiers Azure. Le fait de commencer par le disque/volume le plus important aidera à déterminer les besoins de stockage au niveau local. Configurez la hiérarchisation cloud pour répartir toutes les données sur le cloud, libérant ainsi de l’espace sur le disque du serveur de fichiers. Déplacez les données d’autres volumes/partages vers le volume actuel qui est synchronisé. Suivez les étapes une par une jusqu’à ce que toutes les données soient transférées vers le cloud ou migrées. 2) Ciblez un volume racine (disque) à la fois. Utilisez la hiérarchisation cloud pour répartir toutes les données dans le partage de fichiers Azure cible. Supprimez le point de terminaison de serveur du groupe de synchronisation, recréez le point de terminaison avec le volume/disque racine suivant, synchronisez et répétez le processus. Remarque : il peut être nécessaire de réinstaller l’agent. 3) Recommandez l’utilisation de plusieurs partages de fichiers Azure cibles (compte de stockage identique ou différent en fonction des exigences de performances)
2	Serveur de fichiers avec un volume unique et plusieurs partages sur le même partage de fichiers Azure cible (consolidation)	Oui	Impossible de synchroniser plusieurs points de terminaison de serveur par serveur inscrit avec le même partage de fichiers Azure cible (identique à celui ci-dessus)	Synchronisez la racine du volume contenant plusieurs partages ou dossiers de niveau supérieur. Pour plus d’informations, consultez Concept de regroupement de partages et Synchronisation du volume.
3	Serveur de fichiers avec plusieurs partages et/ou volumes vers plusieurs partages de fichiers Azure sous un seul compte de stockage (mappage de partage 1:1)	Oui	Une seule instance Windows Server (ou cluster) peut synchroniser jusqu’à 30 partages de fichiers Azure. Un compte de stockage est une cible de mise à l’échelle pour les performances. Les IOPS et le débit sont partagés entre les partages de fichiers. Conservez le nombre d’éléments par groupe de synchronisation dans les 100 millions d’éléments (fichiers et dossiers) par partage. Dans l’idéal, il est préférable de rester en dessous de 20 ou 30 millions par partage.	1) Utilisez plusieurs groupes de synchronisation (nombre de groupes de synchronisation = nombre de partages de fichiers Azure à synchroniser). 2) Seuls 30 partages à la fois peuvent être synchronisés dans ce scénario. Si vous avez plus de 30 partages sur ce serveur de fichiers, utilisez le Concept de regroupement de partages et la Synchronisation du volume pour réduire le nombre de dossiers racine ou de niveau supérieur à la source. 3) Utilisez des serveurs File Sync supplémentaires locaux et fractionnez/déplacez les données vers ces serveurs pour contourner les limitations sur le serveur Windows source.
4	Serveur de fichiers avec plusieurs partages et/ou volumes vers plusieurs partages de fichiers Azure sous un compte de stockage différent (mappage de partage 1:1)	Oui	Une seule instance Windows Server (ou cluster) peut synchroniser jusqu’à 30 partages de fichiers Azure (compte de stockage identique ou différent). Conservez le nombre d’éléments par groupe de synchronisation dans les 100 millions d’éléments (fichiers et dossiers) par partage. Dans l’idéal, il est préférable de rester en dessous de 20 ou 30 millions par partage.	Même approche que précédemment
5	Plusieurs serveurs de fichiers avec un seul (volume ou partage racine) sur le même partage de fichiers Azure cibles (consolidation)	Non	Un groupe de synchronisation ne peut pas utiliser le point de terminaison cloud (partage de fichiers Azure) déjà configuré dans un autre groupe de synchronisation. Bien qu’un groupe de synchronisation puisse avoir des points de terminaison de serveur sur des serveurs de fichiers différents, les fichiers ne peuvent pas être distincts.	Suivez les instructions du scénario n° 1 ci-dessus en tenant compte de la nécessité de cibler un serveur de fichiers à la fois.

Créer une table de mappage

Utilisez les informations précédentes pour déterminer le nombre de partages de fichiers Azure dont vous avez besoin, ainsi que les parties de vos données existantes finissant dans ces différents partages.

Créez un tableau regroupant vos réflexions pour pouvoir vous y référer quand vous en avez besoin. Veillez à rester organisé pour ne perdre aucun détail de votre plan de mappage quand vous approvisionnez simultanément un grand nombre de ressources Azure. Téléchargez le fichier Excel suivant à utiliser comme modèle pour vous aider à créer votre mappage.

Téléchargez un modèle de mappage d’espace de noms.

Nombre de comptes de stockage

Votre migration bénéficiera probablement du déploiement de plusieurs comptes de stockage contenant chacun un plus petit nombre de partages de fichiers Azure.

Si vos partages de fichiers sont très actifs (utilisés par de nombreux utilisateurs ou applications), seuls deux partages de fichiers Azure peuvent atteindre la limite de performances de votre compte de stockage. Pour cette raison, il est souvent préférable de migrer vers plusieurs comptes de stockage, chacun avec ses propres partages de fichiers individuels, et généralement pas plus de deux ou trois partages par compte de stockage. Une meilleure pratique consiste à déployer les comptes de stockage avec un partage de fichiers pour chaque. Vous pouvez regrouper plusieurs partages de fichiers Azure dans le même compte de stockage s’ils sont destinés à l’archivage.

Ces considérations s’appliquent davantage à l’accès direct au cloud (par le biais d’une machine virtuelle ou d’un service Azure) qu’à Azure File Sync. Si vous envisagez d'utiliser exclusivement Azure File Sync sur ces partages, vous pouvez regrouper plusieurs partages sur le même compte de stockage Azure. À l’avenir, vous souhaiterez peut-être déplacer une application vers le cloud qui accéderait ensuite directement à un partage de fichiers, car ce scénario bénéficierait d’IOPS et d’un débit plus élevés. Ou vous pourriez commencer à utiliser un service Azure qui permettrait également de bénéficier d'un nombre d'IOPS et d'un débit plus élevés.

Après avoir dressé une liste de vos partages, mappez chaque partage au compte de stockage où il résidera. Choisissez une région Azure, puis vérifiez que chaque compte de stockage et chaque ressource Azure File Sync correspondent à la région que vous avez sélectionnée.

Important

Ne configurez pas les paramètres réseau et les paramètres de pare-feu des comptes de stockage pour le moment. À ce stade, ces configurations rendraient la migration impossible. Vous configurerez ces paramètres de stockage Azure une fois la migration terminée.

Paramètres du compte de stockage

Différentes configurations peuvent être appliquées sur un compte de stockage. Utilisez la liste de contrôle suivante pour confirmer les configurations de votre compte de stockage. Vous pouvez modifier la configuration réseau une fois votre migration terminée.

• Partages de fichiers volumineux : activé – Les partages de fichiers volumineux améliorent les performances et vous permettent de stocker jusqu'à 100 Tio dans un partage. Ce paramètre s’applique aux comptes de stockage cibles avec des partages de fichiers Azure.
• Pare-feu et réseaux virtuels : désactivé - ne configurez aucune restriction IP et ne limitez pas l'accès du compte de stockage à un réseau virtuel spécifique. Le point de terminaison public du compte de stockage est utilisé pendant la migration. Toutes les adresses IP des machines virtuelles Azure doivent être autorisées. Il est préférable de configurer les règles de pare-feu sur le compte de stockage après la migration. Configurez vos comptes de stockage source et cible de cette façon.
• Points de terminaison privés : pris en charge – Vous pouvez activer les points de terminaison privés, mais le point de terminaison public est utilisé pour la migration et doit rester disponible. Cela s'applique à vos comptes de stockage source et cible.

Récapitulatif de la phase 1

À la fin de la phase 1 :

• Vous avez une bonne vue d’ensemble de vos appareils et volumes StorSimple.
• Le service Data Manager est prêt à accéder à vos volumes StorSimple dans le cloud car vous avez récupéré la clé de chiffrement des données de votre service pour chaque appareil StorSimple.
• Vous disposez d'un plan pour les volumes et les sauvegardes (s'il y en a au-delà de la plus récente) qui doivent être migrés.
• Vous savez comment mapper vos volumes avec le nombre approprié de partages de fichiers et de comptes de stockage Azure.

Phase 2 : Déployer des ressources de stockage et de migration Azure

Cette section décrit les considérations relatives au déploiement des différents types de ressources nécessaires dans Azure. Certaines conserveront vos données après la migration et d’autres sont nécessaires uniquement pour la migration. Ne commencez pas à déployer les ressources avant d’avoir finalisé votre plan de déploiement. Il est difficile, parfois impossible, de modifier certains aspects de vos ressources Azure une fois qu’elles ont été déployées.

Cette vidéo traite du déploiement des éléments suivants :

• Comptes de stockage
• Abonnement(s) et groupes de ressources
• Comptes de stockage
• Types et nom(s)
• Niveau de performance et taille de partage
• Emplacement et types de réplication
• Partages de fichiers Azure
• Service StorSimple Data Manager

Déployer des comptes de stockage

Vous aurez probablement besoin de déployer plusieurs comptes de stockage Azure. Chacun contiendra un plus petit nombre de partages de fichiers Azure, selon votre plan de déploiement. Rendez-vous sur le portail Azure pour déployer les comptes de stockage que vous avez planifiés. Vous pouvez utiliser les paramètres de base suivants pour tout nouveau compte de stockage.

Important

Ne configurez pas les paramètres réseau et pare-feu pour vos comptes de stockage pour le moment. À ce stade, ces configurations rendraient la migration impossible. Vous configurerez ces paramètres de stockage Azure une fois la migration terminée.

Abonnement

Vous pouvez utiliser le même abonnement que celui que vous avez utilisé pour votre déploiement StorSimple, ou vous pouvez en utiliser un autre. La seule limitation est que votre abonnement doit se trouver dans le même locataire Microsoft Entra que l’abonnement StorSimple. Avant toute migration, pensez à déplacer l'abonnement StorSimple vers le locataire approprié. Vous pouvez uniquement déplacer l'intégralité de l'abonnement, car les ressources StorSimple individuelles ne peuvent pas être déplacées vers un autre locataire ou un autre abonnement.

Resource group

Les groupes de ressources dans Azure facilitent l’organisation des ressources et les autorisations de gestion des administrateurs. En savoir plus.

Nom du compte de stockage

Le nom de votre compte de stockage fera partie d'une URL utilisée pour accéder à votre partage de fichiers et comporte certaines limitations de caractères. Dans votre convention de dénomination, considérez que les noms de compte de stockage doivent être uniques au monde, autoriser uniquement les lettres minuscules et les chiffres, nécessiter entre 3 et 24 caractères et n'autoriser pas les caractères spéciaux tels que les traits d'union ou les traits de soulignement. Consultez Règles de dénomination des ressources de stockage Azure.

Emplacement

La région Azure d’un compte de stockage est importante. Si vous utilisez Azure File Sync, tous vos comptes de stockage doivent se trouver dans la même région que votre ressource Storage Sync Service. La région Azure que vous sélectionnez doit être proche ou centrale par rapport à vos serveurs et utilisateurs locaux. Après avoir déployé votre ressource, vous ne pouvez pas modifier sa région.

Vous pouvez choisir une région différente de celle où résident actuellement vos données StorSimple (compte de stockage). Toutefois, si vous le faites, des frais de sortie s'appliqueront pendant la migration. Les données quitteront la région StorSimple et entreront dans la région de votre compte de stockage. Aucuns frais de bande passante ne s’appliquent si vous restez dans la même région Azure.

Performances

Vous avez la possibilité de choisir entre le stockage Premium (SSD) et le stockage Standard pour les partages de fichiers Azure. Le stockage Standard comprend plusieurs niveaux pour un partage de fichiers. Le stockage Standard est l’option qui convient à la plupart des clients qui migrent depuis StorSimple.

• Choisissez le stockage Premium si vous avez besoin des performances d’un partage de fichiers Azure Premium.
• Choisissez le stockage Standard pour les charges de travail du serveur de fichiers à usage général, y compris les données chaudes et les données d’archivage. Choisissez également le stockage Standard si la seule charge de travail sur le partage dans le cloud sera Azure File Sync.
• Pour les partages de fichiers premium, choisissez Partages de fichiers dans l’Assistant de création de compte de stockage.

Réplication

Plusieurs paramètres de réplication sont disponibles. Choisissez uniquement parmi les deux options suivantes :

• Stockage localement redondant (LRS) .
• Stockage redondant interzone (ZRS) , qui n’est pas disponible dans toutes les régions Azure.

Remarque

Le stockage géoredondant (GRS) et le stockage redondant par zone géographique ne sont pas pris en charge.

Activer les partages de fichiers d’une capacité de 100 Tio

Dans la section Avancé de l’Assistant Nouveau compte de stockage du portail Azure, vous pouvez activer la prise en charge des partages de fichiers volumineux dans ce compte de stockage. Si cette option n'est pas disponible, vous avez probablement sélectionné le mauvais type de redondance. Veillez à sélectionner LRS ou ZRS pour que cette option soit disponible.

L'utilisation de partages de fichiers volumineux présente plusieurs avantages :

• Les performances sont considérablement améliorées par rapport aux partages de fichiers plus petits de 5 Tio (par exemple, 10 fois les IOPS).
• Votre migration se terminera plus rapidement.
• Vous vous assurez qu'un partage de fichiers dispose d'une capacité suffisante pour contenir toutes les données que vous y migrerez, y compris la capacité de stockage requise par les sauvegardes différentielles.
• La croissance future est couverte.

Important

N'appliquez pas de mise en réseau spéciale à votre compte de stockage avant ou pendant votre migration. Le point de terminaison public doit être accessible sur les comptes de stockage source et cible. La limitation à des plages IP ou à des réseaux virtuels spécifiques n'est pas prise en charge. Vous pouvez modifier les configurations de mise en réseau du compte de stockage après la migration.

Partages de fichiers Azure

Après avoir créé vos comptes de stockage, accédez à la section Partage de fichiers du ou des comptes de stockage et déployez le nombre approprié de partages de fichiers Azure conformément à votre plan de migration de la phase 1. Envisagez d’utiliser les paramètres de base suivants pour tout nouveau partage de fichiers dans Azure.

Les lettres minuscules, les chiffres et les tirets sont pris en charge.



Le quota ici est comparable à un quota dur SMB sur une instance Windows Server. Selon les bonnes pratiques, vous ne devez pas définir de quota ici, car votre migration et vos autres services échoueront lorsque ce quota sera atteint.



Sélectionnez
pour votre nouveau partage de fichiers. Au cours de la migration, de nombreuses transactions seront exécutées. Il sera plus économique de remplacer votre niveau actuel plus tard par un niveau mieux adapté à votre charge de travail.

StorSimple Data Manager

La ressource Azure qui contient vos tâches de migration est appelée StorSimple Data Manager. Sélectionnez Nouvelle ressource, puis recherchez-la. Sélectionnez ensuite Créer.

Cette ressource temporaire est utilisée pour l’orchestration. Vous la déprovisionnerez une fois la migration terminée. Assurez-vous de le déployer dans le même abonnement, groupe de ressources et région que votre compte de stockage StorSimple.

Azure File Sync

Azure File Sync vous permet d’ajouter la mise en cache locale des fichiers les plus fréquemment consultés. À l’instar des capacités de mise en cache de StorSimple, la fonctionnalité de hiérarchisation cloud d’Azure File Sync offre une latence d’accès local combinée à un meilleur contrôle de la capacité de cache disponible sur l’instance Windows Server et à une synchronisation multisite. Si votre objectif est de disposer d’un cache local, préparez dans votre réseau local une machine virtuelle Windows Server (les serveurs physiques et les clusters de basculement sont également pris en charge) avec une capacité suffisante de stockage en attachement direct.

Important

Ne configurez pas encore Azure File Sync. Le déploiement d’Azure File Sync ne doit pas démarrer avant la phase 4 d’une migration.

Récapitulatif de la phase 2

À la fin de la phase 2, vous aurez déployé vos comptes de stockage et tous les partages de fichiers Azure sur lesdits comptes. Vous aurez également une ressource StorSimple Data Manager. Vous utiliserez cette dernière dans la phase 3, lorsque vous configurerez vos tâches de migration.

Phase 3 : Création et exécution d’une tâche de migration

Cette section décrit comment configurer une tâche de migration et mapper les répertoires sur un volume StorSimple qui doit être copié dans le partage de fichiers Azure cible que vous sélectionnez.

Cette vidéo aborde les questions suivantes :

• Création d’un travail de migration
• Résumé
• Source
• Sélectionner les sauvegardes de volume à migrer
• Cible
• Mappage de répertoires
• Règles sémantiques
• Exécution d’un travail de migration
• Exécuter une définition de travail
• Affichage de l’état du travail
• Exécution de travaux en parallèle
• Interprétation des fichiers journaux

Pour commencer, accédez à StorSimple Data Manager, recherchez Définitions de tâches dans le menu, puis sélectionnez + Définition de tâche. Le type de stockage cible qui convient est le type par défaut : Partage de fichiers Azure.

Nom de définition de tâche
Ce nom doit indiquer l’ensemble des fichiers que vous déplacez. Donnez-lui un nom similaire à celui de votre partage de fichiers Azure.



Lorsque vous sélectionnez une région, vous devez sélectionner celle de votre compte de stockage StorSimple ou, si cela n’est pas possible, une région proche de celui-ci.

Source

Abonnement source
Sélectionnez l’abonnement dans lequel vous stockez votre ressource StorSimple Device Manager.



Sélectionnez la ressource StorSimple Device Manager auprès de laquelle votre appliance est inscrite.



Consultez la
si vous ne trouvez pas la clé dans vos dossiers.



Sélectionnez l’appareil StorSimple contenant le volume vers lequel vous souhaitez effectuer la migration.



Sélectionnez le volume source. Plus tard, vous déciderez si vous souhaitez migrer l’ensemble du volume ou des sous-répertoires vers le partage de fichiers Azure cible.

Sauvegardes du volume
Vous pouvez sélectionner Sélectionner des sauvegardes de volume pour choisir des sauvegardes spécifiques et vous déplacer comme faisant partie de cette tâche. Une section dédiée de cet article sera prochainement disponible. Celle-ci couvrira le processus en détail.

Cible

Sélectionnez l’abonnement, le compte de stockage et le partage de fichiers Azure comme cible de cette tâche de migration.

Mappage de répertoires

Une section dédiée de cet article traite de tous les détails pertinents.

Sélectionner les sauvegardes de volume à migrer

Le choix des sauvegardes à migrer repose sur différents aspects importants :

• Vos tâches de migration peuvent uniquement déplacer des sauvegardes, pas les données de volume actives. La sauvegarde la plus récente est donc la plus proche des données actives et doit toujours figurer dans la liste des sauvegardes déplacées lors d'une migration. Lorsque vous ouvrez la boîte de dialogue Sélection de sauvegarde, elle est sélectionnée par défaut.
• Vérifiez que votre dernière sauvegarde est récente afin de réduire au maximum le delta sur le partage actif. Il peut être intéressant de procéder manuellement au déclenchement et à la sauvegarde d'un autre volume avant de créer une tâche de migration. Un petit delta par rapport au partage en direct améliore votre expérience de migration. Si ce delta peut être nul, ce qui signifie qu'aucune modification supplémentaire n'a été apportée au volume StorSimple après la sauvegarde la plus récente de votre liste, le basculement de l'utilisateur sera alors considérablement simplifié et accéléré.
• Sur le partage de fichiers Azure, les sauvegardes doivent être lues dans l'ordre suivant : de la plus ancienne à la plus récente. Une sauvegarde plus ancienne ne peut pas être « triée » dans la liste des sauvegardes sur le partage de fichiers Azure après l’exécution d’une tâche de migration. Par conséquent, vous devez vous assurer que votre liste de sauvegardes est terminée avant de créer une tâche.
• Cette liste de sauvegardes ne peut pas être modifiée une fois la tâche créée, même si celle-ci n'a jamais été exécutée.
• Pour pouvoir sélectionner des sauvegardes, le volume StorSimple à migrer doit être en ligne.

Pour sélectionner des sauvegardes de votre volume StorSimple dans le cadre de votre tâche de migration, sélectionnez le bouton Sélectionner des sauvegardes de volume sur le formulaire de création de tâche.

Lorsque le panneau de sélection de sauvegarde s'ouvre, il est séparé en deux listes. La première liste répertorie toutes les sauvegardes disponibles. Vous pouvez développer et réduire le jeu de résultats en filtrant la liste selon un intervalle de temps spécifique. (voir section suivante)

Une sauvegarde sélectionnée s'affichera en grisé et sera ajoutée à une deuxième liste dans la moitié inférieure de la lame. La deuxième liste répertorie toutes les sauvegardes sélectionnées pour la migration. Une sauvegarde sélectionnée par erreur peut également être retirée.

Attention

Vous devez sélectionner toutes les sauvegardes que vous souhaitez migrer. Vous ne pouvez pas ajouter d'anciennes sauvegardes ultérieurement. Vous ne pouvez pas modifier le travail pour changer votre sélection une fois le travail créé.

Par défaut, la liste est filtrée pour montrer les sauvegardes de volume StorSimple des sept derniers jours. La sauvegarde la plus récente est sélectionnée par défaut, même si elle n’a pas eu lieu au cours des sept derniers jours. Pour les sauvegardes plus anciennes, utilisez le filtre d’intervalle de temps en haut du panneau. Vous pouvez effectuer une sélection à partir d'un filtre existant ou définir un intervalle de temps personnalisé pour filtrer uniquement les sauvegardes effectuées au cours de cette période.

Attention

La sélection de plus de 50 sauvegardes de volume StorSimple n'est pas prise en charge. Les tâches comportant un grand nombre de sauvegardes peuvent échouer. Assurez-vous que vos stratégies de rétention de sauvegardes ne suppriment pas une sauvegarde sélectionnée avant de pouvoir la migrer.

Mappage de répertoires

Le mappage de répertoires est facultatif pour votre tâche de migration. Si vous laissez la section vide, tous les fichiers et dossiers à la racine de votre volume StorSimple seront déplacés vers la racine de votre partage de fichiers Azure cible. Dans la plupart des cas, le stockage du contenu d’un volume entier dans un partage de fichiers Azure n’est pas la meilleure approche. Il est souvent préférable de fractionner le contenu d’un volume sur plusieurs partages de fichiers dans Azure. Si vous n’avez pas encore créé de plan, consultez d’abord Mapper votre volume StorSimple à des partages de fichiers Azure.

Dans le cadre de votre plan de migration, vous avez peut-être décidé que les dossiers présents sur un volume StorSimple doivent être répartis entre plusieurs partages de fichiers Azure. Si tel est le cas, vous pouvez les répartir en :

1. Définissant plusieurs tâches afin d’effectuer la migration des dossiers d’un volume. Chacune aura la même source de volume StorSimple, mais un partage de fichiers Azure différent comme cible.
2. Il convient de spécifier précisément les dossiers du volume StorSimple qui doivent être déplacés vers le partage de fichiers spécifié, à l’aide de la section Mappage des répertoires du formulaire de création de tâche, et en respectant la sémantique de mappage.

Important

Les chemins et les expressions de mappage de ce formulaire ne peuvent pas être validés lorsque le formulaire est envoyé. Si les mappages ne sont pas spécifiés correctement, une tâche peut échouer intégralement ou produire un résultat indésirable. Dans ce cas, il est généralement préférable de supprimer le partage de fichiers Azure, de le recréer, puis de corriger les instructions de mappage dans une nouvelle tâche de migration pour le partage. L’exécution d’une nouvelle tâche avec des instructions de mappage corrigées peut résoudre les dossiers omis et les placer dans le partage existant. Toutefois, seuls les dossiers qui ont été omis en raison d’un chemin d’accès mal orthographié peuvent être résolus de cette façon.

Éléments sémantiques

Un mappage est exprimé de gauche à droite : [\source path] > [\target path].

Caractère sémantique	Signification
\	Indicateur de niveau racine.
>	Opérateur de mappage [source] et [cible].
| ou RETOUR (nouvelle ligne)	Séparateur de deux instructions de mappage de dossiers. Vous pouvez également omettre ce caractère et sélectionner pour afficher l’expression de mappage suivante sur sa propre ligne.

Exemples

Déplace le contenu du dossier Données utilisateur à la racine du partage de fichiers cible :

\User data > \

Déplace l’intégralité du contenu du volume vers un nouveau chemin d’accès sur le partage de fichiers cible :

\ > \Apps\HR tracker

Déplace le contenu du dossier source vers un nouveau chemin sur le partage de fichiers cible :

\HR resumes-Backup > \Backups\HR\resumes

Trie plusieurs emplacements sources dans une nouvelle structure de répertoires :

\HR\Candidate Tracker\v1.0 > \Apps\Candidate tracker
\HR\Candidates\Resumes > \HR\Candidates\New
\Archive\HR\Old Resumes > \HR\Candidates\Archived

Règles sémantiques

• Spécifiez toujours des chemins de dossier relatifs au niveau racine.
• Commencez chaque chemin de dossier par l’indicateur de niveau racine « \ ».
• N’incluez pas la lettre du lecteur.
• Lorsque vous spécifiez plusieurs chemins d’accès, les chemins d’accès source ou cible ne peuvent pas se chevaucher :
  Exemple de chevauchement du chemin d’accès source non valide :
  
  
  
  
  Exemple de chevauchement du chemin d’accès cible non valide :
  >
  
  
  
• Les dossiers sources qui n'existent pas sont ignorés.
• Des structures de dossiers qui n'existent pas sur la cible sont créées.
• Tout comme Windows, les noms de dossiers ne respectent pas la casse, mais la conservent.

Notes

Le contenu du dossier \System Volume Information et de $Recycle.Bin sur votre volume StorSimple ne sera pas copié par la tâche de migration.

Exécuter une tâche de migration

Vos tâches de migration sont répertoriées sous Définitions des tâches dans la ressource Data Manager que vous avez déployée dans un groupe de ressources. Dans la liste des définitions de tâches, sélectionnez la tâche que vous souhaitez exécuter.

Dans le panneau de tâche qui s’ouvre, vous pouvez voir l’état actuel de votre tâche et une liste des sauvegardes que vous avez sélectionnées. La liste des sauvegardes est triée de la plus ancienne à la plus récente et est migrée vers votre partage de fichiers Azure dans cet ordre.

Au départ, la tâche de migration aura l’état Jamais exécuté.
Lorsque vous êtes prêt, démarrez la tâche de migration. Sélectionnez l'image pour une version avec une résolution plus élevée.
Lorsqu’une sauvegarde est migrée avec succès, un instantané automatique du partage de fichiers Azure est pris. La date de sauvegarde d'origine de votre sauvegarde StorSimple est placée dans la section Commentaires de l'instantané du partage de fichiers Azure. L'utilisation de ce champ vous permet de voir quand les données ont été initialement sauvegardées par rapport à l'heure à laquelle l'instantané du partage de fichiers a été pris.

Attention

Les sauvegardes doivent être traitées de la plus ancienne à la plus récente. Une fois qu’une tâche de migration est créée, vous ne pouvez pas modifier la liste des sauvegardes de volume StorSimple sélectionnées. Ne démarrez pas la tâche si la liste des sauvegardes est incorrecte ou incomplète. Supprimez la tâche et créez-en une nouvelle avec les sauvegardes appropriées sélectionnées. Pour chaque sauvegarde sélectionnée, vérifiez les planifications de rétention. Les sauvegardes peuvent être supprimées par une ou plusieurs de vos politiques de rétention avant d'avoir la possibilité d'être migrées !

Erreurs par élément

Les tâches de migration comportent deux colonnes dans la liste des sauvegardes qui répertorient tous les problèmes pouvant survenir lors de la copie :

• Copier les erreurs
  Cette colonne répertorie les fichiers ou dossiers qui auraient dû être copiés mais qui ne l’ont pas été. Ces erreurs sont souvent récupérables. Quand une sauvegarde répertorie des problèmes d’élément dans cette colonne, consultez les journaux de copie. Si vous devez migrer ces fichiers, sélectionnez Réessayer la sauvegarde. Cette option devient disponible une fois le traitement de la sauvegarde terminé. La section Gestion d’une tâche de migration décrit vos options plus en détail.
• Fichiers non pris en charge
  Cette colonne répertorie les fichiers ou dossiers qui ne peuvent pas être migrés. Le Stockage Azure présente des limitations dans les noms de fichier, les longueurs de chemin et les types de fichier qui ne peuvent pas être stockés actuellement ou logiquement dans un partage de fichiers Azure. Une tâche de migration ne s’interrompt pas pour ce type d’erreur. Toute nouvelle tentative de migration de la sauvegarde ne changera pas le résultat. Quand une sauvegarde répertorie des problèmes d’élément dans cette colonne, consultez les journaux de copie et prenez des notes. Si de tels problèmes surviennent lors de votre dernière sauvegarde et que vous avez constaté dans le journal de copie que l'échec était dû à un nom de fichier, à la longueur du chemin ou à un autre problème sur lequel vous avez une influence, vous souhaiterez peut-être remédier au problème dans le volume StorSimple actif, prenez une sauvegarde de volume StorSimple et créez une nouvelle tâche de migration avec uniquement cette sauvegarde. Vous pouvez ensuite migrer cet espace de noms corrigé et il deviendra la version la plus récente/en direct du partage de fichiers Azure. Il s’agit d’un processus manuel et long. Examinez attentivement les journaux de copie et évaluez s’il en vaut la peine.

Ces journaux de copie sont des fichiers *.csv qui listent les éléments d’espace de noms qui ont pu être copiés et ceux qui n’ont pas pu l’être. Les erreurs sont ensuite réparties dans les catégories présentées précédemment. À partir de l’emplacement du fichier journal, vous pouvez trouver les journaux des fichiers ayant échoué en recherchant « échec ». Le résultat devrait être un ensemble de journaux pour les fichiers qui n’ont pas pu être copiés. Triez ces journaux par taille. Des journaux supplémentaires peuvent être produits avec une taille de 17 octets. Ils sont vides et peuvent être ignorés. Ce tri vous permet de vous concentrer sur les journaux avec du contenu.

Le même processus s’applique pour l’enregistrement des copies réussies des fichiers journaux.

Gérer une tâche de migration

Les tâches de migration ont les états suivants :

• Jamais exécuté
  Un nouveau travail qui a été défini mais qui n'a jamais été exécuté.
• Attente
  Une tâche avec cet état attend que les ressources soient provisionnées dans le service de migration. Elle passe automatiquement à un autre état quand elle est prête.
• Échec
  Une tâche ayant échoué rencontre une erreur irrécupérable qui l’empêche de traiter d’autres sauvegardes. On ne s’attend pas à ce qu’un travail entre dans cet état. Une demande de support est la meilleure marche à suivre.
• Annulée / Annulation
  Il est possible d’annuler une tâche de migration en entier ou des sauvegardes individuelles dans la tâche. Les sauvegardes annulées ne seront pas traitées, car une tâche de migration annulée arrêtera le traitement des sauvegardes. Attendez-vous à ce que l’annulation d’une tâche dure longtemps. Cela ne vous empêche pas de créer une nouvelle tâche. La meilleure solution consiste à laisser une tâche arriver entièrement à l'état Annulé. Vous pouvez soit ignorer les tâches ayant échoué/annulées, soit les supprimer ultérieurement. Vous n’aurez pas à supprimer les tâches avant de pouvoir supprimer la ressource Data Manager à la fin de votre migration StorSimple.

Exécution

Une tâche en cours d’exécution est en train de traiter une sauvegarde. Reportez-vous au tableau situé dans la partie inférieure du panneau pour voir quelle sauvegarde est en cours de traitement et quelles sont celles qui ont éventuellement déjà été migrées.
Les sauvegardes déjà migrées ont une colonne avec un lien vers un journal de copie. Si une sauvegarde signale des erreurs, vous devez consulter son journal de copie.

Mis en pause

Une tâche de migration est en pause lorsqu’une décision est à prendre. Cette condition active deux boutons de commande en haut du panneau.
Choisissez
lorsque la sauvegarde montre des fichiers qui étaient censés être déplacés mais qui ne l’ont pas été (colonne Erreur de copie).
Choisissez
lorsque la sauvegarde est manquante (a été supprimée par la stratégie depuis que vous avez créé la tâche de migration) ou lorsque la sauvegarde est endommagée. Vous trouverez des informations détaillées sur l’erreur dans le panneau qui s’ouvre lorsque vous cliquez sur la sauvegarde qui a échoué.

Lorsque vous
ou
la sauvegarde actuelle, le service de migration crée un nouvel instantané dans votre partage de fichiers Azure cible. Vous souhaiterez peut-être supprimer le précédent plus tard, car il est probablement incomplet.

Terminée et Terminée avec des avertissements

Une tâche de migration est marquée Terminée lorsque toutes les sauvegardes qu’elle contient ont été traitées avec succès.
Terminé avec des avertissements est un état qui se produit lorsque :

• Une sauvegarde a rencontré un problème récupérable. Cette sauvegarde est marquée comme partiellement réussi ou en échec.
• Vous avez décidé de poursuivre la tâche en pause, en ignorant la sauvegarde avec les problèmes cités. (Vous avez choisi Ignorer la sauvegarde au lieu de Réessayer la sauvegarde.)

Si la tâche de migration se termine avec des avertissements, vous devez toujours examiner le journal de copie des sauvegardes associées.

Exécuter des tâches en parallèle

Vous disposerez probablement de plusieurs volumes StorSimple, chacun avec ses propres partages qui doivent être migrés vers un partage de fichiers Azure. Il est important de bien comprendre ce que vous pouvez faire en parallèle. Certaines limitations ne sont pas appliquées dans l’expérience utilisateur et dégradent ou empêchent une migration complète si les tâches sont exécutées en même temps.

Il n’existe aucune limite dans la définition des tâches de migration. Vous pouvez définir le même volume source StorSimple, le même partage de fichiers Azure, sur des appliances StorSimple identiques ou différentes. Toutefois, leur exécution présente des limitations :

• Une seule tâche de migration avec le même volume source StorSimple peut s’exécuter en même temps.
• Une seule tâche de migration avec le même partage de fichiers Azure cible peut s’exécuter en même temps.
• Avant de commencer la tâche suivante, assurez-vous que l'une des tâches précédentes est dans le copy stage et affiche la progression du déplacement des fichiers pendant au moins 30 minutes.
• Vous pouvez exécuter jusqu'à quatre tâches de migration en parallèle par gestionnaire de périphériques StorSimple, à condition de respecter les règles précédentes.

Lorsque vous tentez de démarrer une tâche de migration, les règles précédentes sont vérifiées. Si des tâches sont en cours d'exécution, vous ne pourrez peut-être pas en démarrer une nouvelle. Vous recevrez une alerte qui liste le nom de la ou des tâches en cours d’exécution qui doivent être finies avant de pouvoir démarrer la nouvelle tâche.

Conseil

C'est une bonne idée de vérifier régulièrement vos tâches de migration dans l'onglet Définition de la tâche de votre ressource Data Manager pour voir si l'une d'entre elles est en pause et nécessite votre contribution pour se terminer.

Récapitulatif de la phase 3

À la fin de la phase 3, vous aurez exécuté au moins une de vos tâches de migration entre les volumes StorSimple et le(s) partage(s) de fichiers Azure. Avec votre exécution, vous aurez migré vos sauvegardes spécifiées dans des instantanés de partage de fichiers Azure. À présent, vous pouvez soit configurer Azure File Sync pour le partage (une fois que les tâches de migration d’un partage seront terminées) ou l’accès direct au partage pour vos applications et vos travailleurs de l’information vers le partage de fichiers Azure.

Phase 4 : Accéder aux partages de fichiers Azure

Il existe deux stratégies principales pour accéder à vos partages de fichiers Azure :

• Azure File Sync : Déployez Azure File Sync sur une instance locale de Windows Server. Azure File Sync offre tous les avantages d’un cache local, tout comme StorSimple.
• Accès direct au partage : Déployez l’accès direct au partage. Utilisez cette stratégie si votre scénario d’accès pour un partage de fichiers Azure donné ne bénéficiera pas de la mise en cache locale ou si vous n’avez plus la possibilité d’héberger une instance Windows Server locale. Ici, vos utilisateurs et vos applications continuent d’accéder aux partages SMB via le protocole SMB. Ces partages ne se trouvent plus sur un serveur local, mais directement dans le cloud.

Vous devez déjà avoir choisi l’option qui vous convient le mieux dans la phase 1 de ce guide.

Le reste de cette section se concentre sur les instructions de déploiement.

Cette vidéo aborde les questions suivantes :

• Approches pour accéder aux partages de fichiers Azure
• Azure File Sync
• Accès direct au partage
• Déploiement d’Azure File Sync
• Déployer la ressource cloud Azure File Sync
• Déployer une instance locale de Windows Server
• Préparation de l'instance Windows Server pour Azure File Sync
• Configuration d’Azure File Sync sur l’instance Windows Server
• Supervision de la synchronisation initiale
• Test d’Azure File Sync
• Création des partages SMB

Déployer Azure File Sync

Il est temps de déployer une partie d’Azure File Sync.

1. Créez la ressource cloud Azure File Sync.
2. Déployez l’agent Azure File Sync sur votre serveur local.
3. Inscrivez le serveur auprès de la ressource cloud.

Ne créez pas encore de groupes de synchronisation. La configuration de la synchronisation avec un partage de fichiers Azure doit se produire uniquement lorsque vos tâches de migration vers un partage de fichiers Azure sont terminées. Si vous commencez à utiliser Azure File Sync avant la fin de votre migration, cela rendra votre migration inutilement difficile, car vous ne pourrez pas facilement savoir quand il est temps de lancer un basculement.

Déployer la ressource cloud Azure File Sync

Pour terminer cette étape, vous avez besoin des informations d’identification de votre abonnement Azure.

La ressource principale permettant de configurer Azure File Sync est un service de synchronisation de stockage. Nous vous recommandons d’en déployer un seul pour tous les serveurs synchronisant le même ensemble de fichiers maintenant ou à l’avenir. Ne créez plusieurs services de synchronisation de stockage que si vous avez des ensembles de serveurs distincts qui ne doivent jamais échanger de données. Par exemple, vous pouvez avoir des serveurs qui ne doivent jamais synchroniser le même partage de fichiers Azure. Dans le cas contraire, la meilleure pratique consiste à utiliser un seul service de synchronisation de stockage.

Pour votre service de synchronisation de stockage, choisissez une région Azure proche de votre emplacement. Toutes les autres ressources cloud doivent être déployées dans la même région. Afin de simplifier la gestion, créez un nouveau groupe de ressources dans votre abonnement pour héberger les ressources de synchronisation et de stockage.

Pour plus d’informations, consultez la section concernant le déploiement du service de synchronisation de stockage dans l’article sur le déploiement d’Azure File Sync. Suivez uniquement cette section de l’article. Des liens vers d’autres sections de l’article sont proposés dans des étapes ultérieures.

Conseil

Si vous souhaitez modifier la région Azure dans laquelle vos données résident une fois que la migration est terminée, déployez le service de synchronisation de stockage dans la même région que les comptes de stockage cibles pour cette migration.

Déployer une instance locale de Windows Server

• Créez une instance Windows Server 2019 (au minimum 2012 R2) en tant que machine virtuelle ou serveur physique. Un cluster de basculement Windows Server est également pris en charge. Ne réutilisez pas le serveur qui précède l’appliance StorSimple 8100 ou 8600.
• Provisionnez ou ajoutez un stockage en attachement direct. Le stockage attaché au réseau n’est pas pris en charge.

La meilleure méthode consiste à attribuer à votre nouvelle instance Windows Server une quantité de stockage égale ou supérieure à celle dont votre appliance StorSimple 8100 ou 8600 dispose localement pour la mise en cache. Vous utiliserez l’instance Windows Server de la même façon que vous avez utilisé l’appliance StorSimple. Si elle dispose de la même quantité de stockage que l’appliance, l’expérience de mise en cache sera similaire, voire identique. Vous pouvez ajouter ou supprimer autant d’espace de stockage que vous le souhaitez sur l’instance Windows Server. Cela vous permet de mettre à l’échelle la taille de votre volume local, ainsi que la quantité de stockage local disponible pour la mise en cache.

Préparer l’instance Windows Server pour la synchronisation de fichiers

Dans le cadre de cette section, vous allez installer l’agent Azure File Sync sur votre instance Windows Server.

Le Guide de déploiement explique que vous devez désactiver la configuration de sécurité renforcée d’Internet Explorer. Cette mesure de sécurité n’est pas applicable avec Azure File Sync. La désactivation de cette option vous permet de vous authentifier auprès d’Azure sans aucun problème.

Ouvrez PowerShell. Installez les modules PowerShell nécessaires à l’aide des commandes suivantes. Veillez à installer le module complet et le fournisseur NuGet quand vous y êtes invité.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

Si vous rencontrez des problèmes pour accéder à Internet à partir de votre serveur, vous devez les résoudre dès à présent. Azure File Sync peut utiliser n’importe quelle connexion réseau à Internet disponible. L’exigence d’un serveur proxy pour accéder à Internet est également prise en charge. Vous pouvez configurer un proxy au niveau des machines dès maintenant ou spécifier un proxy que la fonctionnalité Azure File Sync sera la seule à utiliser lors de l’installation de l’agent.

Si la configuration d’un proxy implique l’ouverture de vos pare-feu pour le serveur, cette approche est peut-être acceptable pour vous. À la fin de l’installation du serveur, une fois l’inscription du serveur effectuée, un rapport de connectivité réseau indique les URL de point de terminaison exactes dans Azure avec lesquelles Azure File Sync doit communiquer pour la région que vous avez sélectionnée. Le rapport indique également la raison pour laquelle la communication est nécessaire. Vous pouvez utiliser le rapport pour verrouiller les pare-feu autour du serveur sur des URL spécifiques.

Vous pouvez également adopter une approche plus conservatrice dans laquelle vous n’ouvrez pas les pare-feu en grand. Vous pouvez à la place limiter le serveur pour qu’il communique avec des espaces de noms DNS de niveau supérieur. Pour plus d’informations, consultez Paramètres de proxy et de pare-feu d’Azure File Sync. Appliquez vos bonnes pratiques relatives aux réseaux.

À la fin de l’Assistant Installation du serveur, un Assistant Inscription du serveur s’affiche. Inscrivez le serveur auprès de la ressource Azure de votre service de synchronisation du stockage déployée précédemment.

Le guide de déploiement décrit ces étapes plus en détail et traite notamment des modules PowerShell que vous devez installer en premier : Installation de l’agent Azure File Sync.

Utilisez l’agent le plus récent. Vous pouvez aussi le télécharger à partir du Centre de téléchargement Microsoft : Agent Azure File Sync.

Une fois l’installation et l’inscription du serveur terminées, vous pouvez confirmer que vous avez correctement accompli cette étape. Accédez à la ressource du service de synchronisation de stockage dans le portail Azure. Dans le menu de gauche, accédez à Serveurs inscrits. Votre serveur y est répertorié.

Configurer Azure File Sync sur l’instance Windows Server

Votre instance Windows Server locale inscrite doit être prête et connectée à Internet pour ce processus.

Important

Votre migration StorSimple de fichiers et de dossiers vers le partage de fichiers Azure doit être terminée avant de continuer. Assurez-vous qu’aucune autre modification n’est effectuée sur le partage de fichiers.

Cette étape lie l’ensemble des ressources et dossiers que vous avez configurés sur votre instance Windows Server au cours des étapes précédentes.

1. Connectez-vous au portail Azure.
2. Localisez votre ressource de service de synchronisation de stockage.
3. Créez un groupe de synchronisation au sein de la ressource de service de synchronisation de stockage pour chaque partage de fichiers Azure. Dans la terminologie Azure File Sync, le partage de fichiers Azure devient un point de terminaison cloud dans la topologie de synchronisation que vous décrivez lors de la création d’un groupe de synchronisation. Lorsque vous créez le groupe de synchronisation, donnez-lui un nom familier qui vous permette de reconnaître le groupe de fichiers qui se synchronise ici. Veillez à référencer le partage de fichiers Azure avec un nom correspondant.
4. Une fois que vous avez créé le groupe de synchronisation, une ligne apparaît pour lui dans la liste des groupes de synchronisation. Cliquez sur le nom (un lien) du groupe de synchronisation pour afficher son contenu. Votre partage de fichiers Azure apparaît sous Points de terminaison cloud.
5. Recherchez le bouton Ajouter un point de terminaison de serveur. Le dossier situé sur le serveur local que vous avez approvisionné devient le chemin d’accès pour ce point de terminaison de serveur.

Important

Veillez à activer la hiérarchisation cloud. La hiérarchisation cloud désigne la fonctionnalité Azure File Sync qui permet au serveur local d’avoir moins de capacité de stockage que ce qui est stocké dans le cloud, tout en ayant l’espace de noms complet disponible. Les données localement intéressantes sont également mises en cache localement pour des performances rapides. Une autre raison d’activer la hiérarchisation cloud à cette étape est que nous ne souhaitons pas synchroniser le contenu des fichiers à ce stade, mais seulement l’espace de noms.

Déployer l’accès direct au partage

Cette vidéo montre comment exposer directement et de façon sécurisée les partages de fichiers Azure aux travailleurs de l’information et aux applications, en cinq étapes simples.
La vidéo fait référence à une documentation dédiée aux sujets suivants. Notez qu'Azure Active Directory est désormais Microsoft Entra ID. Pour plus d’informations, consultez Nouveau nom pour Azure AD.

• Vue d’ensemble de l’identité
• Comment joindre un domaine à un compte de stockage
• Présentation de la mise en réseau pour les partages de fichiers Azure
• Comment configurer des points de terminaison publics et privés
• Comment configurer un VPN site à site
• Comment configurer un VPN point à site Windows
• Comment configurer un VPN point à site Linux
• Procédure de configuration du transfert DNS
• Configurer DFS-N

Récapitulatif de la phase 4

À la fin de cette phase, vous avez créé et exécuté plusieurs tâches de migration dans StorSimple Data Manager. Ces tâches ont migré vos fichiers et dossiers, et leurs sauvegardes, vers des partages de fichiers Azure. Vous avez également déployé Azure File Sync ou préparé votre réseau et vos comptes de stockage pour un accès direct au partage.

Phase 5 : Transfert de l’utilisateur

Au cours de cette phase, vous terminerez votre migration :

• Planifiez votre temps d’arrêt.
• Découvrez les modifications qui ont été apportées par vos utilisateurs et vos applications côté StorSimple pendant que les tâches de migration de la phase 3 étaient en cours d'exécution.
• Faites basculer vos utilisateurs vers la nouvelle instance Windows Server avec Azure File Sync ou vers les partages de fichiers Azure via un accès direct au partage.

Cette vidéo aborde les questions suivantes :

• Étapes à suivre avant le basculement de votre charge de travail
• Exécution de votre basculement
• Étapes post-basculement

Planifier votre temps d’arrêt

Cette approche de migration nécessite un temps d’arrêt pour vos utilisateurs et vos applications. L’objectif est de réduire au maximum le temps d’arrêt. Voici certains points qui pourront vous aider :

• Gardez vos volumes StorSimple disponibles pendant l'exécution de vos tâches de migration.
• Lorsque vous avez terminé d’exécuter vos tâches de migration des données pour un partage, vous devez supprimer l’accès utilisateur (au moins l’accès en écriture) des volumes ou partages StorSimple. Une RoboCopy finale récupèrera les modifications de votre partage de fichiers Azure. Vous pourrez alors faire basculer vos utilisateurs. L’emplacement où vous exécutez RoboCopy varie selon que vous avez choisi d’utiliser Azure File Sync ou l’accès direct au partage. La section à venir couvre ce sujet.
• Une fois que vous avez terminé la récupération RoboCopy, vous êtes prêt à exposer le nouvel emplacement à vos utilisateurs, soit directement par le biais du partage de fichiers Azure, soit par le biais d’un partage SMB présent sur une instance Windows Server avec Azure File Sync. Souvent, un déploiement DFS-N permet d’effectuer une opération de basculement rapide et efficace. Il conserve la cohérence de vos adresses de partage existantes et les redirigent vers un nouvel emplacement où se trouvent vos fichiers et vos dossiers déplacés.

Pour les données d'archives, il est tout à fait viable de réduire les temps d'arrêt sur votre volume (ou sous-dossier) StorSimple, d'effectuer une sauvegarde supplémentaire du volume StorSimple, de migrer, puis d'ouvrir la destination de migration pour que les utilisateurs et les applications puissent y accéder. Cela vous évitera d’avoir à effectuer une RoboCopy de rattrapage. Toutefois, cette approche s’accompagne d’une fenêtre de temps d’arrêt prolongée qui peut s’étendre sur plusieurs jours ou plus, en fonction du nombre de fichiers et de sauvegardes à migrer. Il s’agit vraisemblablement d’une option pour les charges de travail d’archivage seules, qui peut convenir sans avoir d’accès en écriture pendant des périodes prolongées.

Déterminer le moment où votre espace de noms est entièrement synchronisé à votre serveur

Lorsque vous utilisez Azure File Sync pour un partage de fichiers Azure, il est important de déterminer que l'intégralité de votre espace de noms a terminé le téléchargement sur le serveur avant de démarrer une RoboCopy locale. Le temps nécessaire au téléchargement de votre espace de noms dépend du nombre d’éléments dans votre partage de fichiers Azure. Il existe deux méthodes permettant de déterminer si votre espace de noms a été entièrement téléchargé sur le serveur.

Portail Azure

Vous pouvez utiliser le portail Azure pour voir à quel moment votre espace de noms est entièrement arrivé.

• Connectez-vous au portail Azure et accédez à votre groupe de synchronisation. Vérifiez l’état de synchronisation de votre groupe de synchronisation et de votre point de terminaison de serveur.
• Le sens le plus important est celui du téléchargement. Si le point de terminaison de serveur vient d’être provisionné, il affiche Synchronisation initiale, ce qui indique que l’espace de noms est toujours en cours de téléchargement. Lorsqu’il n’affiche plus l’état Synchronisation initiale, cela signifie que votre espace de noms a été entièrement copié sur le serveur.

Vous pouvez maintenant procéder à une copie RoboCopy locale.

Observateur d’événements Windows Server

Vous pouvez également utiliser l’observateur d’événements sur l’instance Windows Server pour savoir quand l’espace de noms est entièrement téléchargé.

1. Ouvrez l’observateur d’événements et accédez à Applications et services.
2. Ouvrez Microsoft\FileSync\Agent\Telemetry.
3. Recherchez l’événement 9102 le plus récent, qui correspond à une session de synchronisation terminée.
4. Sélectionnez Détails et vérifiez que vous consultez bien un événement dans lequel la valeur SyncDirection est Télécharger.
5. Lorsque votre espace de noms aura été téléchargé sur le serveur, il y aura un événement unique avec Scenario, la valeur FullGhostedSync et HResult = 0.
6. S’il vous manque cet événement, vous pouvez également rechercher d’autres événements 9102 où SyncDirection = Télécharger et Scenario = « RegularSync ». Le fait de trouver l’un de ces événements indique aussi que l’espace de noms a terminé son téléchargement et que la synchronisation est passée à des sessions de synchronisation régulières, qu’il y ait quelque chose à synchroniser ou non, pour le moment.

Une RoboCopy finale

À ce stade, il existe des différences entre votre instance locale de Windows Server et l’appliance StorSimple 8100 ou 8600.

1. Vous devez récupérer les modifications apportées par les utilisateurs ou les applications côté StorSimple pendant la migration.
2. Pour les cas où vous utilisez Azure File Sync : L’appliance StorSimple dispose d’un cache rempli, alors que l’instance Windows Server n’a qu’un espace de noms sans contenu de fichier stocké localement pour l’instant. Par conséquent, la RoboCopy finale peut vous aider à démarrer votre cache Azure File Sync local en récupérant le contenu du fichier mis en cache localement dans la mesure où il est disponible et peut tenir sur le serveur Azure File Sync.
3. Certains fichiers peuvent avoir été ignorés par la tâche de migration en raison de caractères non valides. Si c’est le cas, copiez-les sur l’instance Windows Server avec Azure File Sync. Plus tard, vous pourrez les ajuster pour qu’ils se synchronisent. Si vous n’utilisez pas Azure File Sync pour un partage en particulier, il est préférable de renommer les fichiers avec des caractères non valides sur le volume StorSimple. Ensuite, vous pourrez exécuter la RoboCopy directement sur le partage de fichiers Azure.

Avertissement

Robocopy dans Windows Server 2019 a rencontré un problème qui entraînait la recopie des fichiers hiérarchisés par Azure File Sync sur le serveur cible à partir de la source et leur nouveau téléchargement sur Azure lors de l'utilisation de la fonction /MIR. Nous vous recommandons d'exécuter Robocopy sur un serveur Windows autre que 2019, tel que Windows Server 2016.

Avertissement

Vous ne devez pas démarrer la RoboCopy avant que le serveur ait téléchargé complètement l’espace de noms pour un partage de fichiers Azure. Pour plus d’informations, consultez Déterminer le moment où votre espace de noms est entièrement synchronisé à votre serveur.

Vous souhaitez uniquement copier les fichiers qui ont été modifiés après la dernière exécution de la tâche de migration et les fichiers qui n’ont pas été déplacés par lesdites tâches auparavant. Vous pouvez comprendre pourquoi ils n’ont pas été déplacés plus tard sur le serveur, une fois la migration terminée. Pour plus d’informations, consultez Résolution des problèmes Azure File Sync.

RoboCopy a plusieurs paramètres. L’exemple suivant montre une commande terminée, ainsi que la liste des raisons pour lesquelles vous devez choisir ces paramètres.

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName> 

Commutateur	Signification
/MT:n	Autorise Robocopy à fonctionner en multithread. La valeur par défaut de n est 8. La valeur maximale est de 128 threads. Bien qu’un nombre élevé de threads permette de saturer la bande passante disponible, cela ne signifie pas que votre migration sera toujours plus rapide avec plus de threads. Les tests avec Azure Files indiquent qu’entre 8 et 20 threads affichent des performances équilibrées pour une exécution de copie initiale. Les exécutions suivantes de /MIR sont progressivement affectées par le calcul disponible par rapport à la bande passante réseau disponible. Pour les exécutions suivantes, associez votre valeur de nombre de threads avec plus de précision au nombre de cœurs du processeur et au nombre de threads par cœur. Déterminez si les cœurs doivent être réservés pour les autres tâches qu’un serveur de production peut prendre en charge. Les tests avec Azure Files ont montré qu’un nombre maximal de 64 threads offraient de bonnes performances, mais uniquement si vos processeurs peuvent les maintenir actifs en même temps.
/R:n	Nombre maximal de tentatives pour un fichier dont la copie échoue à la première tentative. Robocopy s’y prendra à n reprises avant que la copie du fichier n’échoue définitivement lors de l’exécution. Vous pouvez optimiser les performances de votre exécution : choisissez une valeur de deux ou trois si vous pensez que des problèmes de dépassement de délai ont causé des défaillances dans le passé. Cela peut être plus courant sur les liaisons WAN. Choisissez de ne faire aucune nouvelle tentative ou choisissez la valeur 1 si vous pensez que le fichier n’a pas pu être copié parce qu’il était activement utilisé. Une nouvelle tentative quelques secondes plus tard risque de ne pas suffire pour que l’état d’utilisation du fichier change. Les utilisateurs ou les applications qui maintiennent le fichier ouvert peuvent avoir besoin de plus de temps. Dans ce cas, accepter que le fichier n’ait pas été copié et l’intercepter dans l’une de vos exécutions Robocopy ultérieures peut aboutir à la copie du fichier. Cela permet à l’exécution en cours de se terminer plus rapidement sans être prolongée par de nombreuses tentatives qui se terminent principalement en échecs de copie en raison de fichiers toujours ouverts au-delà du délai d’expiration de la nouvelle tentative.
/W:n	Spécifie la durée d’attente de Robocopy, avant de tenter la copie d’un fichier qui n’a pas pu être copié à la dernière tentative. n est le nombre de secondes d’attente entre les tentatives. /W:n est souvent utilisé avec /R:n.
/B	Exécute Robocopy dans le même mode qu’une application de sauvegarde. Ce commutateur permet à Robocopy de déplacer des fichiers pour lesquels l’utilisateur actuel n’a pas d’autorisations. Le commutateur de sauvegarde dépend de l’exécution de la commande Robocopy dans une console administrateur avec élévation de privilèges ou une fenêtre PowerShell. Si vous utilisez Robocopy pour Azure Files, veillez à monter le partage de fichiers Azure à l’aide de la clé d’accès du compte de stockage et d’une identité de domaine. Si vous ne le faites pas, les messages d’erreur peuvent ne pas vous amener à résoudre le problème de manière intuitive.
/MIR	(Mettre en miroir la source sur la cible) Permet à Robocopy de n’avoir à copier que les deltas entre la source et la cible. Les sous-répertoires vides sont copiés. Les éléments (fichiers ou dossiers) qui ont été modifiés ou qui n’existent pas sur la cible sont copiés. Les éléments qui existent sur la cible, mais pas sur la source, sont vidés (supprimés) de la cible. Lorsque vous utilisez ce commutateur, faites correspondre exactement les structures de dossiers source et cible. Correspondance signifie que vous copiez du niveau de source et de dossier qui convient vers le niveau de dossier correspondant sur la cible. C’est la conditions requise pour qu’une copie de « rattrapage » aboutisse. Si la source et la cible ne correspondent pas, l’utilisation de /MIR entraîne des suppressions et des recopies à grande échelle.
/IT	Garantit la fidélité dans certains scénarios de mise en miroir. Par exemple, si un fichier fait l’objet d’une modification de liste de contrôle d’accès et d’une mise à jour d’attribut entre deux exécutions de Robocopy, il est également marqué masqué. Sans /IT, la modification de la liste de contrôle d’accès peut être ignorée par Robocopy et pas transférée vers l’emplacement cible.
/COPY:[copyflags]	Fidélité de la copie de fichier. Par défaut : /COPY:DAT. Indicateurs de copie : D=Données, A=Attributs, T=Horodatages, S=Sécurité=ACL NTFS, O=Informations propriétaire, U=Informations aDdit. Les informations d’audit ne peuvent pas être stockées dans un partage de fichiers Azure.
/DCOPY:[copyflags]	Fidélité pour la copie de répertoires. Par défaut : /DCOPY:DA. Indicateurs de copie : D = Données, A = Attributs, T = Horodatages.
/NP	Spécifie que la progression de la copie de chaque fichier et dossier ne s’affiche pas. L’affichage de la progression réduit considérablement les performances de copie.
/NFL	Indique que les noms de fichiers ne sont pas enregistrés dans le journal. Améliore les performances de copie.
/NDL	Indique que les noms de répertoires ne sont pas enregistrés dans le journal. Améliore les performances de copie.
/XD	Spécifie les répertoires à exclure. Quand vous exécutez Robocopy à la racine d’un volume, envisagez d’exclure le dossier System Volume Information masqué. S’il est utilisé comme il a été conçu, toutes les informations contenues dans celui-ci sont spécifiques au volume exact sur ce système exact et peuvent être reconstruites à la demande. La copie de ces informations n’est pas utile dans le cloud ou lorsque les données sont recopiées sur un autre volume Windows. Le fait de laisser ce contenu ne doit pas être considéré comme une perte de données.
/UNILOG:<file name>	Écrit l’état dans le fichier journal au format Unicode. (Remplace le journal existant.)
/L	Seulement pour une série de tests Les fichiers sont seulement répertoriés. Ils ne sont pas copiés ni supprimés, et ne sont pas horodatées. Souvent utilisé avec /TEE pour la sortie de console. Les indicateurs de l’exemple de script, comme /NP, /NFL et /NDL, peuvent devoir être supprimés pour obtenir des résultats de tests dûment documentés.
/LFSM	Uniquement pour les cibles avec stockage hiérarchisé. Non pris en charge lorsque la destination est un partage SMB distant. Spécifie que Robocopy fonctionne en « mode espace libre faible ». Ce commutateur est utile uniquement pour les cibles avec stockage hiérarchisé, susceptibles de manquer de capacité locale avant que Robocopy ne finisse. Il a été spécifiquement ajouté à des fins d’utilisation avec une cible de hiérarchisation cloud Azure File Sync activée. Il peut être utilisé indépendamment d’Azure File Sync. Dans ce mode, Robocopy s’interrompt chaque fois qu’une copie de fichier réduit l’espace libre du volume de destination en dessous d’une valeur « plancher ». Cette valeur peut être spécifiée par la forme /LFSM:n de l’indicateur. Le paramètre n est spécifié en base 2 : nKB, nMB ou nGB. Si /LFSM est spécifié sans valeur plancher explicite, le plancher est défini sur 10 % de la taille du volume de destination. Le mode d’espace libre faible n’est pas compatible avec /MT, /EFSRAW ou /ZB. La prise en charge de /B a été ajoutée à Windows Server 2022. Pour plus d’informations, consultez la section Windows Server 2022 et RoboCopy LFSM ci-dessous pour plus d’informations, notamment sur un bogue associé et une solution de contournement.
/Z	Utiliser avec prudence Copie les fichiers en mode redémarrage. Ce commutateur est recommandé uniquement dans un environnement réseau instable. Elle réduit considérablement les performances de copie en raison d’une journalisation supplémentaire.
/ZB	Utiliser avec prudence Utilise le mode redémarrage. En cas d’accès refusé, cette option utilise le mode de sauvegarde. Cette option réduit considérablement les performances de copie en raison des points de contrôle.

Important

Nous vous recommandons d’utiliser un Windows Server 2022. Lors de l’utilisation d’un Windows Server 2019, vérifiez que le niveau de correctif le plus récent ou au minimum la mise à jour du système d’exploitation KB5005103 est installée. Celle-ci contient des correctifs importants pour certains scénarios Robocopy.

Quand vous configurez les emplacements source et cible de la commande RoboCopy, veillez à examiner la structure de la source et de la cible pour être sûr qu’elles correspondent. Si vous avez utilisé la fonctionnalité de mappage de répertoires de la tâche de migration, la structure de votre répertoire racine peut être différente de celle de votre volume StorSimple. Si c’est le cas, vous pouvez avoir besoin de plusieurs tâches RoboCopy, une pour chaque sous-répertoire. Si vous ne savez pas si la commande s’exécute comme prévu, vous pouvez utiliser le paramètre /L, qui simulera la commande sans apporter de modification.

Cette commande RoboCopy utilise /MIR, elle ne déplacera donc pas les fichiers identiques (fichiers hiérarchisés, par exemple). Mais si vous obtenez des chemins source et cible erronés, /MIR purge également les structures de répertoires sur votre instance Windows Server ou votre partage de fichiers Azure qui ne sont pas présentes sur le chemin source StorSimple. Elles doivent donc correspondre exactement pour que la tâche RoboCopy atteigne son objectif, à savoir la mise à jour du contenu déplacé avec les dernières modifications apportées pendant la migration.

Consultez le fichier journal RoboCopy pour voir si des fichiers ont été ignorés. Si des problèmes existent, corrigez-les, puis réexécutez la commande RoboCopy. Ne déprovisionnez pas les ressources StorSimple avant d’avoir corrigé les problèmes en suspens pour les fichiers ou dossiers qui vous intéressent.

Si vous n’utilisez pas Azure File Sync pour mettre en cache le partage de fichiers Azure en question, mais que vous avez plutôt opté pour un accès direct au partage :

1. Montez votre partage de fichiers Azure en tant que lecteur réseau sur un ordinateur Windows local.
2. Exécutez RoboCopy entre votre volume StorSimple et le partage de fichiers Azure monté. Si les fichiers ne sont pas copiés, corrigez leurs noms côté StorSimple pour supprimer les caractères non valides. Ensuite, réessayez RoboCopy. La commande RoboCopy mentionnée précédemment peut être exécutée plusieurs fois sans provoquer de rappel inutile vers StorSimple.

Dépanner et optimiser

La vitesse et le taux de réussite d’une exécution de RoboCopy donnée dépendent de plusieurs facteurs :

• les IOPS sur le stockage source et le stockage cible ;
• la bande passante réseau disponible entre la source et la cible ;
• la capacité de traiter rapidement des fichiers et des dossiers dans un espace de noms ;
• le nombre de modifications entre les exécutions de RoboCopy.
• la taille et le nombre de fichiers que vous devez copier

Remarques relatives à la bande passante et aux IOPS

Dans cette catégorie, vous devez prendre en compte les capacités du stockage source, du stockage cible et du réseau qui les connecte. Le débit maximal possible est déterminé par le plus lent de ces trois composants. Vérifiez que votre infrastructure réseau est configurée pour prendre en charge des vitesses de transfert optimales au mieux de ses possibilités.

Attention

Si la copie la plus rapide est souvent la plus souhaitée, envisagez l’utilisation de votre réseau local et de votre appliance NAS pour d’autres tâches, généralement critiques pour l’entreprise.

Une copie aussi rapide que possible peut ne pas être souhaitable lorsqu’il existe un risque de monopolisation des ressources disponibles par la migration.

• Réfléchissez au moment qui sera le plus approprié dans votre environnement pour effectuer des migrations : dans la journée, pendant les heures creuses ou au cours des week-ends.
• Pensez également à la mise en réseau de la Qualité de service sur un serveur Windows pour limiter la vitesse de RoboCopy.
• Évitez les tâches inutiles pour les outils de migration.

RoboCopy peut insérer des délais inter-paquets, en spécifiant le commutateur /IPG:n, sachant que n est mesuré en millisecondes entre les paquets de Robocopy. L’utilisation de ce commutateur permet d’éviter la monopolisation des ressources à la fois sur les appareils limités en E/S et sur les liens réseau encombrés.

/IPG:n ne peut pas être utilisé pour limiter avec précision le réseau à un certain nombre de Mbits/s près. Utilisez plutôt la Qualité de service du réseau Windows Server. RoboCopy s’appuie entièrement sur le protocole SMB pour tous les besoins réseau. Cette utilisation de SMB est la raison pour laquelle RoboCopy ne peut pas influer sur le débit du réseau lui-même, par contre il peut ralentir son utilisation.

Un raisonnement similaire s’applique aux E/S par seconde (IOPS) observées sur l’appliance NAS. La taille du cluster sur le volume NAS, les tailles de paquets et un ensemble d’autres facteurs affectent les IOPS observées. L’introduction d’un délai entre des paquets constitue souvent le moyen le plus simple de contrôler la charge sur le NAS. Testez plusieurs valeurs, par exemple, à partir d’environ 20 millisecondes (n=20) jusqu’aux multiples de ce nombre. Dès lors qu’un délai est intercalé, vous pouvez évaluer si vos autres applications peuvent désormais fonctionner comme prévu. Cette stratégie d’optimisation vous permettra de trouver la vitesse optimale de RoboCopy dans votre environnement.

Vitesse de traitement

RoboCopy parcourra l’espace de noms qui lui est désigné et évaluera tous les fichiers et les dossiers en vue de leur copie. Chaque fichier sera évalué lors d’une copie initiale et au cours des copies de rattrapage. Prenons l’exemple des exécutions répétées de RoboCopy/MIR sur les mêmes emplacements de stockage source et cible. Ces exécutions répétées sont utiles pour réduire au minimum le temps d’interruption des utilisateurs et des applications, et pour améliorer le taux de réussite global des fichiers migrés.

Nous avons souvent tendance à considérer la bande passante comme le facteur le plus limitatif dans une migration, et cela peut être vrai. Toutefois, la possibilité d’énumérer un espace de noms peut influencer encore plus la durée totale de la copie pour les espaces de noms plus grands avec des fichiers de plus petite taille. Considérez que la copie de 1 Tio comportant des petits fichiers prendra beaucoup plus de temps que la copie de 1 Tio contenant des fichiers moins nombreux, mais plus volumineux, en supposant que toutes les autres variables restent identiques. Par conséquent, le transfert peut être lent si vous migrez un grand nombre de petits fichiers. Ce comportement est normal.

La cause de cette différence réside dans la puissance de traitement nécessaire pour parcourir un espace de noms. RoboCopy prend en charge les copies multithread par le biais du paramètre /MT:n, où n représente le nombre de threads à utiliser. Ainsi, lors du provisionnement d’une machine plus particulièrement destinée à RoboCopy, tenez compte du nombre de cœurs de processeur et de leur relation avec le nombre de threads qu’ils fournissent. Le plus souvent, il est question de deux threads par cœur. Le nombre de cœurs et de threads d’une machine constitue un point de données important pour déterminer les valeurs multithread /MT:n que vous devez spécifier. Tenez également compte du nombre de tâches de RoboCopy que vous prévoyez d’exécuter en parallèle sur une machine donnée.

Des threads plus nombreux copieront notre exemple de 1 Tio de petits fichiers beaucoup plus rapidement que des threads moins nombreux. En même temps, l’investissement en ressources supplémentaires sur notre 1 Tio de fichiers volumineux peut ne pas produire d’avantages, en proportion. Un nombre élevé de threads tentera de copier simultanément un plus grand nombre de fichiers volumineux sur le réseau. Cette activité réseau supplémentaire augmente la probabilité d’être limité par les IOPS de débit ou de stockage.

Pendant une première RoboCopy dans une cible vide ou une exécution différentielle avec un grand nombre de fichiers modifiés, vous êtes probablement limité par le débit de votre réseau. Démarrez avec un nombre élevé de threads pour une série initiale. Un nombre élevé de threads, même au-delà des threads actuellement disponibles sur votre machine, permet de saturer la bande passante réseau disponible. Les exécutions suivantes de /MIR sont affectées progressivement par les éléments traités. Un nombre moindre de modifications dans une exécution différentielle signifie moins de transport des données sur le réseau. Votre vitesse est désormais plus dépendante de votre capacité à traiter les éléments d’espace de noms que de leur déplacement sur la liaison réseau. Pour les exécutions suivantes, associez votre valeur de nombre de threads au nombre de cœurs du processeur et au nombre de threads par cœur. Déterminez si les cœurs doivent être réservés pour les autres tâches qu’un serveur de production peut prendre en charge.

Conseil

Règle générale : la première exécution de RoboCopy, qui déplace un grand nombre de données d’un réseau à latence plus élevée, bénéficie de l’approvisionnement excédentaire du nombre de threads (/MT:n). Les exécutions ultérieures copient moins de différences et vous êtes plus susceptible de passer du débit réseau limité au calcul limité. Dans ces circonstances, il est souvent préférable de faire correspondre le nombre de threads RoboCopy avec les threads réellement disponibles sur la machine. L’approvisionnement excédentaire dans ce scénario peut entraîner davantage de décalages de contexte dans le processeur, ce qui peut ralentir votre copie.

Éviter les tâches inutiles

Évitez les modifications à grande échelle dans votre espace de noms. Par exemple, le déplacement de fichiers entre des répertoires, la modification de propriétés à grande échelle ou la modification des autorisations (ACL NTFS). En particulier, les modifications de liste de contrôle d’accès (ACL, access-control list) peuvent avoir un impact important, car elles ont souvent un effet de modification en cascade sur les fichiers situés plus bas dans l’arborescence des dossiers. Les conséquences peuvent être les suivantes :

• Un temps d’exécution de la tâche RoboCopy prolongé, car chaque fichier et dossier concerné par une modification ACL doit être mis à jour
• La réutilisation de données déplacées auparavant demandera peut-être que celles-ci soient recopiées. Par exemple, une plus grande quantité de données devra être copiée lorsque des structures de dossiers seront modifiées après une copie de fichiers déjà effectuée antérieurement. Une tâche RoboCopy ne peut pas « lire » une modification d’espace de noms. La tâche suivante doit donc purger les fichiers précédemment transportés vers l’ancienne structure de dossiers, et charger de nouveau les fichiers dans la nouvelle structure de dossiers.

Un autre aspect important consiste à utiliser efficacement l’outil RoboCopy. Avec le script RoboCopy recommandé, vous allez créer et enregistrer un fichier journal d’erreurs. Des erreurs de copie peuvent se produire, cela est normal. Ces erreurs rendent souvent nécessaire l’exécution de plusieurs séquences d’un outil de copie tel que RoboCopy. Une exécution initiale, par exemple d’un appareil NAS vers DataBox ou d’un serveur vers un partage de fichiers Azure. À cela, ajouter une ou plusieurs exécutions supplémentaires avec le commutateur/MIR pour intercepter et refaire une tentative sur les fichiers qui n’ont pas été copiés.

Vous devez être prêt à exécuter plusieurs séquences de RoboCopy sur une étendue d’espace de noms déterminée. Les exécutions successives se terminent plus rapidement, car elles ont moins à copier, mais elles sont progressivement limitées par la vitesse de traitement de l’espace de noms. Lorsque vous exécutez plusieurs séquences, vous pouvez accélérer chacune d’elles en évitant que RoboCopy n’essaie exagérément de tout copier dans une exécution donnée. Ces commutateurs RoboCopy peuvent faire une grande différence :

• /R:n n = fréquence à laquelle vous réessayez de copier un fichier ayant échoué et
• /W:n n = fréquence d’attente, en secondes, entre les tentatives

/R:5 /W:5 est un paramètre raisonnable que vous pouvez adapter à votre convenance. Dans cet exemple, un fichier ayant échoué sera retenté cinq fois, avec un délai d’attente de cinq secondes entre chaque tentative. Si la copie du fichier échoue toujours, la tâche RoboCopy suivante fera une nouvelle tentative. Souvent les fichiers en échec, du fait de leur utilisation en cours ou de problèmes de délai d’attente, peuvent au final être correctement copiés de cette façon.

Windows Server 2022 et RoboCopy LFSM

Le commutateur /LFSM RoboCopy peut être utilisé pour éviter l’échec d’un travail RoboCopy avec une erreur volume plein. RoboCopy s’interrompt chaque fois qu’une copie de fichier réduit l’espace libre du volume de destination en dessous d’une valeur « plancher ».

Utilisez RoboCopy avec Windows Server 2022. Seule cette version de RoboCopy contient des correctifs de bogues importants et des fonctionnalités qui rendent le commutateur compatible avec des indicateurs supplémentaires nécessaires dans la plupart des migrations. Par exemple, la compatibilité avec l’indicateur /B.

/B exécute RoboCopy dans le même mode qu’une application de sauvegarde. Ce commutateur permet à RoboCopy de déplacer des fichiers pour lesquels l’utilisateur actuel n’a pas d’autorisations.

Normalement, RoboCopy peut être exécuté sur la source, la destination ou une troisième machine.

Important

Si vous envisagez d’utiliser /LFSM, RoboCopy doit être exécuté sur le serveur Azure File Sync Windows Server 2022 cible.

Notez également qu’avec /LFSM, vous devez également utiliser un chemin local pour la destination, et non un chemin UNC. Par exemple, en tant que chemin de destination, vous devez utiliser E:\Foldername plutôt qu’un chemin UNC comme \\ServerName\FolderName.

Attention

La version actuellement disponible de RoboCopy sur Windows Server 2022 présente un bogue qui provoque le décompte des pauses dans le nombre d’erreurs par fichier. Appliquez la solution de contournement suivante.

Les indicateurs /R:2 /W:1 recommandés augmentent la probabilité qu’un fichier échoue en raison d’une pause provoquée par /LFSM. Dans cet exemple, un fichier qui n’a pas été copié après 3 pauses, car /LFSM a provoqué la pause, fait échouer RoboCopy de manière incorrecte pour le fichier. La solution de contournement consiste à utiliser des valeurs plus élevées pour /R:n et /W:n. Un bon exemple est /R:10 /W:1800 (10 nouvelles tentatives de 30 minutes chacune). Cela devrait donner à l'algorithme de hiérarchisation d'Azure File Sync le temps de créer de l'espace sur le volume de destination.

Ce bogue a été résolu, mais le correctif n’est pas encore disponible publiquement. Consultez ce paragraphe pour vérifier les informations à jour sur la disponibilité du correctif et son déploiement.

Transfert de l’utilisateur

Si vous utilisez Azure File Sync, vous devrez probablement créer des partages SMB sur cette instance Windows Server avec Azure File Sync correspondant aux partages que vous aviez sur les volumes StorSimple. Vous pouvez commencer par cette étape, et le plus tôt possible pour ne pas perdre de temps. Toutefois, vous devez garantir que personne ne pourra apporter des modifications à l’instance Windows Server avant la fin de cette étape.

Si vous avez un déploiement DFS-N, vous pouvez faire pointer les espaces de noms DFN vers les emplacements des nouveaux dossiers du serveur. Si vous ne disposez pas d’un déploiement DFS-N et que vous avez déjà relié votre appliance 8100 ou 8600 localement à une instance Windows Server, vous pouvez retirer ce serveur du domaine. Joignez ensuite le domaine à votre nouvelle instance Windows Server avec Azure File Sync. Au cours de ce processus, donnez au serveur le même nom de serveur et les mêmes noms de partage que l’ancien serveur, afin que le basculement reste transparent pour vos utilisateurs, votre stratégie de groupe et vos scripts.

En savoir plus sur DFS-N.

Phase 6 : Déprovisionner

Lorsque vous déprovisionnez une ressource, vous perdez l’accès à la configuration de cette ressource, ainsi qu’à ses données. Le déprovisionnement ne peut pas être annulé. Ne poursuivez pas tant que vous n’avez pas vérifié les points suivants :

• Votre migration est terminée.
• Il n’existe aucune dépendance vis-à-vis des fichiers, dossiers ou sauvegardes de volume StorSimple que vous allez déprovisionner.

Avant de commencer, il est recommandé d’observer quelque temps votre nouveau déploiement Azure File Sync en production. Cette période d’observation vous donne l’occasion de corriger tout problème que vous pourriez rencontrer. Une fois que vous avez observé votre déploiement Azure File Sync pendant au moins quelques jours, vous pouvez commencer à déprovisionner les ressources dans cet ordre :

1. Déprovisionnez votre ressource StorSimple Data Manager via le portail Azure. Toutes vos tâches DTS seront supprimées avec elle. Vous ne pourrez pas récupérer facilement les journaux de copie. S’ils sont importants pour vos dossiers, récupérez-les avant de déprovisionner la ressource.
2. Vérifiez que vos appliances physiques StorSimple ont été déplacées, puis désinscrivez-les. Si vous n’êtes pas sûr qu’elles ont été migrées, ne poursuivez pas. Si vous déprovisionnez ces ressources alors qu’elles sont encore nécessaires, vous ne pourrez pas récupérer les données ni leur configuration.
   Si vous le souhaitez, vous pouvez d’abord déprovisionner la ressource de volume StorSimple, ce qui nettoiera les données de l’appliance. Ce processus peut prendre plusieurs jours et n’aura pas comme effet de supprimer l’intégralité des données de l’appliance. Si cela est important pour vous, supprimez l’intégralité des données d’un disque dans un cadre autre que celui du déprovisionnement des ressources, et conformément à vos stratégies.
3. S’il ne reste plus d’appareils inscrits dans une ressource StorSimple Device Manager, vous pouvez supprimer cette dernière.
4. Il est maintenant temps de supprimer le compte de stockage StorSimple dans Azure. Là encore, avant de poursuivre, vérifiez que la migration est terminée, et que rien ni personne ne dépend de ces données.
5. Débranchez l’appliance physique StorSimple de votre centre de données.
6. Si vous êtes propriétaire de l’appliance StorSimple, vous êtes libre de la recycler. Si votre appareil est loué, informez le bailleur et retournez l’appareil comme il se doit.

Votre migration est terminée.

---

Notes

Vous avez des questions ou rencontrez des problèmes ?
Nous sommes là pour vous aider :

Résolution des problèmes

Lorsque vous utilisez le service de migration StorSimple Data Manager, un travail de migration entier ou des fichiers individuels peuvent échouer pour diverses raisons. La section sur la fidélité du fichier contient plus de détails sur les scénarios pris en charge/non pris en charge. Les tableaux suivants répertorient les codes d’erreur, les détails de l’erreur et, le cas échéant, les options d’atténuation.

Erreurs au niveau du travail

Phase	Erreur	Détails/atténuation
Sauvegarde	Impossible de trouver une sauvegarde pour les paramètres spécifiés	La sauvegarde sélectionnée pour l’exécution du travail est introuvable au moment de l’opération « Estimation » ou « Copie ». Vérifiez que la sauvegarde est toujours présente dans le catalogue de sauvegarde StorSimple. Parfois, les stratégies de rétention de sauvegarde automatique suppriment les sauvegardes entre le moment où elles sont sélectionnées pour la migration et l’exécution réelle du travail de migration. Envisagez de désactiver les planifications de rétention de sauvegarde avant de démarrer une migration.
Estimation Configurer le calcul	Échec de l’installation des clés de chiffrement	Votre clé de chiffrement des données de service est incorrecte. Pour plus d’informations, consultez la section sur la clé de chiffrement de cet article qui vous aidera à récupérer la clé correcte.
	Erreur de lot	Il est possible que le démarrage de toute l'infrastructure interne requise pour effectuer une migration rencontre un problème. Plusieurs autres services sont impliqués dans ce processus. Ces problèmes se résolvent généralement lorsque vous tentez de réexécuter le travail.
	StorSimple Manager a rencontré une erreur interne. Patientez quelques minutes et recommencez l’opération. Si le problème persiste, contactez le support technique Microsoft. (Code d’erreur : 1074161829)	Cette erreur générique a plusieurs causes, mais l’une des possibilités rencontrées est que la limite de 50 appliances du gestionnaire d’appareils StorSimple a été atteinte. Vérifiez si les travaux les plus récents exécutés dans le gestionnaire d’appareils ont soudainement commencé à échouer avec cette erreur, ce qui peut suggérer qu’il s’agit bien du problème. L’atténuation de ce problème spécifique consiste à supprimer toutes les appliances StorSimple 8001 hors connexion créées et utilisées par le service Data Manager. Vous pouvez créer un ticket de support ou les supprimer manuellement dans le portail. Veillez à ne supprimer que les appliances de la série 8001 hors connexion.
Estimation des fichiers	Échec du travail de clonage du volume	Cette erreur indique que vous avez probablement spécifié une sauvegarde qui a été endommagée d’une manière ou d’une autre. Le service de migration ne peut pas la monter ou la lire. Vous pouvez essayer d’effectuer la sauvegarde manuellement ou créer un ticket de support.
	Impossible de continuer, car le volume est au format non NTFS	Seuls les volumes NTFS, sur lesquels la déduplication n’est pas activée, peuvent être utilisés par le service de migration. Si vous avez un volume mis en forme différemment, comme ReFS ou un format tiers, le service de migration ne pourra pas migrer ce volume. Consultez la section Limitations connues.
	Contactez le support technique. Aucune partition appropriée trouvée sur le disque	Le disque StorSimple censé avoir le volume spécifié pour la migration ne semble pas avoir de partition pour ce volume. Cela est inhabituel et peut indiquer une altération ou un mauvaise alignement de la gestion. Votre seule option pour examiner ce problème plus en détail consiste à créer un ticket de support.
	Délai dépassé	L’échec de la phase d’estimation avec expiration du délai dénote généralement un problème avec l’appliance StorSimple ou le fait que la sauvegarde de volume source est lente et parfois même endommagée. Si la réexécution de la sauvegarde ne fonctionne pas, la meilleure solution est de créer un ticket de support.
	Impossible de trouver le <chemin d’accès>au fichier Impossible de trouver une partie du chemin d’accès	La définition du travail vous permet de fournir un sous-chemin d’accès source. Cette erreur s’affiche quand ce chemin n’existe pas. Par exemple : \Share1 > \Share\Share1 Dans cet exemple, vous avez spécifié \Share1 comme sous-chemin dans la source, en le mappant à un autre sous-chemin dans la cible. Toutefois, le chemin source n’existe pas (mal orthographié ?). Remarque : Windows conserve la casse mais ne dépend pas de la casse. Cela signifie que spécifier \Share1 et \share1 est équivalent. En outre : les chemins d’accès cibles qui n’existent pas sont automatiquement créés.
	Cette requête n’est pas autorisée à effectuer cette opération	Cette erreur s’affiche quand le compte de stockage StorSimple source ou le compte de stockage cible avec le partage de fichiers Azure a un paramètre de pare-feu activé. Vous devez autoriser le trafic sur le point de terminaison public et ne pas le restreindre avec d’autres règles de pare-feu. Sinon, le service de transformation des données ne pourra pas accéder à l’un ou l’autre des comptes de stockage, même si vous l’y avez autorisé. Désactivez les règles de pare-feu et réexécutez le travail.
Copie de fichiers	Le compte auquel vous accédez ne prend pas en charge HTTP	Désactivez le routage Internet sur le compte de stockage cible ou utilisez le point de terminaison de routage Microsoft.
	Le partage spécifié est plein	Si la cible est un partage de fichiers Azure premium, assurez-vous que vous avez provisionné une capacité suffisante pour le partage. Le surprovisionnement temporaire est une pratique courante. Si la cible est un partage de fichiers Azure Standard, vérifiez que la fonctionnalité « partage de fichiers volumineux » est activée sur le partage cible. Le stockage Standard croît à mesure que vous utilisez le partage. Toutefois, si vous utilisez un compte de stockage hérité comme cible, vous pourriez être confronté à une limite de partage de 5 Tio. Vous devrez activer manuellement la fonctionnalité « Partage de fichiers volumineux ». Corrigez les limites de la cible et réexécutez le travail.

Erreurs au niveau de l’élément

Pendant la phase de copie de l’exécution d’un travail de migration, des éléments d’espace de noms individuels (fichiers et dossiers) peuvent rencontrer des erreurs. Le tableau suivant répertorie les erreurs les plus courantes et suggère des options d’atténuation lorsque cela est possible.

Phase	Error	Limitation des risques
Copy	-2146233088 Le serveur est occupé.	Réexécutez le travail s’il y a trop d’échecs. S’il n’y a que très peu d’erreurs, vous pouvez essayer de réexécuter le travail, mais il est souvent plus rapide d’effectuer une copie manuelle des éléments ayant échoué. Ensuite, reprenez la migration en passant au traitement de la sauvegarde suivante.
	-2146233088 Impossible d’exécuter l’opération dans le temps imparti.	Réexécutez le travail s’il y a trop d’échecs. S’il n’y a que très peu d’erreurs, vous pouvez essayer de réexécuter le travail, mais il est souvent plus rapide d’effectuer une copie manuelle des éléments ayant échoué. Ensuite, reprenez la migration en passant au traitement de la sauvegarde suivante.
	Chargement expiré ou copie non démarrée	Réexécutez le travail s’il y a trop d’échecs. S’il n’y a que très peu d’erreurs, vous pouvez essayer de réexécuter le travail, mais il est souvent plus rapide d’effectuer une copie manuelle des éléments ayant échoué. Ensuite, reprenez la migration en passant au traitement de la sauvegarde suivante.
	-2146233029 L’opération a été annulée.	Réexécutez le travail s’il y a trop d’échecs. S’il n’y a que très peu d’erreurs, vous pouvez essayer de réexécuter le travail, mais il est souvent plus rapide d’effectuer une copie manuelle des éléments ayant échoué. Ensuite, reprenez la migration en passant au traitement de la sauvegarde suivante.
	1920 Le système ne peut pas accéder au fichier.	Il s’agit d’une erreur courante lorsque le moteur de migration rencontre un point d’analyse, une liaison ou une jonction. Elles ne sont pas prises en charge. Ces types de fichiers ne peuvent pas être copiés. Consultez la section Limitations connues et la section Fidélité de fichier de cet article.
	-2147024891 Accès refusé	Il s’agit d’une erreur concernant les fichiers chiffrés d’une manière qui les rend inaccessibles sur le disque. Les fichiers qui peuvent être lus à partir du disque, mais qui ont simplement du contenu chiffré ne sont pas affectés et peuvent être copiés. Votre seule option consiste à les copier manuellement. Vous trouverez ces éléments en montant le volume affecté et en exécutant la commande suivante : get-childitem <path> [-Recurse] -Force -ErrorAction SilentlyContinue | Where-Object {$_.Attributes -ge "Encrypted"} | format-list fullname, attributes
	Valeur Win32 FileTime non valide. Nom du paramètre : fileTime	Dans ce cas, le fichier est accessible, mais ne peut pas être évalué pour la copie, car un horodatage dont dépend le moteur de migration est endommagé ou a été écrit par une application dans un format incorrect. Il n’y a pas grand chose à faire, car vous ne pouvez pas modifier l’horodatage dans la sauvegarde. S’il est important pour vous de conserver ce fichier, peut-être que sur la dernière version (dernière sauvegarde contenant ce fichier) vous pouvez copier manuellement le fichier, corriger l’horodatage, puis le déplacer vers le partage de fichiers Azure cible. Cette option n’est pas très compatible avec la mise à l’échelle, mais elle concerne les fichiers à valeur élevée dont vous souhaitez conserver au moins une version dans votre cible.
	-2146232798 Le handle sécurisé a été fermé	Il s’agit souvent d’une erreur temporaire. Réexécutez le travail s’il y a trop d’échecs. S’il n’y a que très peu d’erreurs, vous pouvez essayer de réexécuter le travail, mais il est souvent plus rapide d’effectuer une copie manuelle des éléments ayant échoué. Ensuite, reprenez la migration en passant au traitement de la sauvegarde suivante.
	-2147024413 Erreur matérielle irrécupérable	Il s’agit d’une erreur rare et non réellement signalée pour un appareil physique, mais plutôt pour les appliances virtualisées de la série 8001 utilisées par le service de migration. L’appliance a rencontré un problème. Les fichiers avec cette erreur n’empêchent pas la migration de passer à la sauvegarde suivante. Cela vous pose des difficultés si vous voulez effectuer une copie manuelle ou réessayer la sauvegarde qui contient des fichiers avec cette erreur. Si les fichiers non pris en compte sont très importants ou s’il y a beaucoup de fichiers, vous devrez peut-être recommencer la migration de toutes les sauvegardes. Ouvrez un ticket de support pour une analyse plus approfondie.
Supprimer (purge miroir)	Le répertoire spécifié n'est pas vide.	Cette erreur se produit lorsque le mode de migration est défini sur miroir et que le processus qui supprime des éléments du partage de fichiers Azure a rencontré un problème qui l’a empêché de supprimer des éléments. La suppression ne se produit que dans le partage en direct, pas à partir d’instantanés précédents. La suppression est nécessaire, car les fichiers affectés ne sont pas dans la sauvegarde actuelle et doivent donc être supprimés du partage en direct avant l’instantané suivant. Il existe deux options : Option 1 : montez le partage de fichiers Azure cible et supprimez manuellement les fichiers avec cette erreur. Option 2 : vous pouvez ignorer ces erreurs et continuer le traitement de la sauvegarde suivante en espérant que la cible n'est pas identique à la source et comporte des éléments supplémentaires qui n'étaient pas dans la sauvegarde StorSimple d'origine.
	Demande incorrecte	Cette erreur indique que le fichier source présente certaines caractéristiques qui n’ont pas pu être copiées sur le partage de fichiers Azure. Plus particulièrement, un nom de fichier peut contenir des caractères de contrôle invisibles ou le nom de fichier ou le chemin d’accès du fichier peut contenir un 1 octet d’un caractère à double octet. Vous pouvez utiliser les journaux de copie pour obtenir les noms des chemins d’accès, copier les fichiers dans un emplacement temporaire, renommer les chemins d’accès pour supprimer les caractères non pris en charge, puis effectuer une robocopy dans le partage de fichiers Azure. Vous pouvez ensuite reprendre la migration en passant à la sauvegarde suivante à traiter.

Étapes suivantes

• Comprenez la flexibilité des stratégies de hiérarchisation cloud.
• Activez Sauvegarde Azure sur vos partages de fichiers Azure pour planifier des instantanés et définir des planifications de conservation de sauvegardes.
• Si vous constatez dans le portail Azure que certains fichiers ne se synchronisent jamais, consultez le guide de résolution des problèmes pour connaître les mesures à prendre pour les résoudre.