Partager via

Utiliser RoboCopy pour migrer vers des partages de fichiers Azure

  • Article

Cet article décrit l’utilisation de RoboCopy pour déplacer ou migrer des fichiers vers un partage de fichiers Azure SMB. RoboCopy est un utilitaire de copie de fichiers fiable et connu qui présente un ensemble de fonctionnalités qui lui permet d’être adapté aux migrations. Il utilise le protocole SMB, qui le rend largement applicable à toute combinaison source/cible prenant en charge SMB.

  • Sources de données : toute source prenant en charge le protocole SMB, telle que le stockage NAS (Network Attached Storage), les serveurs Windows ou Linux, un autre partage de fichiers Azure et de nombreuses autres
  • Itinéraire de migration : stockage source ⇒ ordinateur Windows avec RoboCopy ⇒ partage de fichiers Azure
  • Aucun fichier de mise en cache en local : étant donné que l’objectif final est d’utiliser les partages de fichiers Azure directement dans le cloud, il n’est pas prévu d’utiliser Azure File Sync.

Il existe de nombreuses routes de migration différentes pour différentes combinaisons de sources et de déploiements. Consultez le tableau des guides de migration pour trouver la migration qui correspond le mieux à vos besoins.

S’applique à

Type de partage de fichiers SMB NFS
Partages de fichiers Standard (GPv2), LRS/ZRS Oui Non
Partages de fichiers Standard (GPv2), GRS/GZRS Oui Non
Partages de fichiers Premium (FileStorage), LRS/ZRS Oui Non

AzCopy ou RoboCopy

AzCopy et RoboCopy sont deux outils de copie de fichiers fondamentalement différents. RoboCopy utilise n’importe quelle version du protocole SMB. AzCopy est un outil « né dans le cloud » qui peut être utilisé pour déplacer des données tant que la cible est dans le stockage Azure. AzCopy dépend d’un protocole REST.

RoboCopy, en tant qu’outil de copie approuvé basé sur Windows, prend l’avantage quand il s’agit de copier des fichiers avec une fidélité totale. RoboCopy prend en charge de nombreux scénarios de migration grâce à son ensemble complet de fonctionnalités et à son aptitude à copier des fichiers et des dossiers avec une fidélité totale. Consultez la section sur la fidélité des fichiers dans l’article Vue d’ensemble de la migration pour en savoir plus sur l’importance de copier des fichiers avec la fidélité la plus optimale possible.

En revanche, ce n’est que récemment qu’AzCopy a été développé pour prendre en charge la copie de fichiers avec une certaine fidélité et que les premières fonctionnalités nécessaires pour être considéré comme un outil de migration ont été ajoutées. Malgré tout, il existe toujours des écarts et il peut être facile de mal comprendre les fonctionnalités lors de la comparaison des indicateurs AzCopy aux indicateurs RoboCopy.

Exemple : RoboCopy /MIR met la source en miroir sur la cible, ce qui signifie que les fichiers ajoutés, modifiés et supprimés sont pris en compte. Une différence importante dans l’utilisation d’AzCopy -sync réside dans le fait que les fichiers supprimés de la source ne sont pas supprimés de la cible. Cela rend l’ensemble de fonctionnalités de copie différentielle incomplet. AzCopy va continuer à évoluer. Pour l’instant, nous ne recommandons pas l’utilisation d’AzCopy pour les scénarios de migration avec les partages de fichiers Azure en tant que cible.

Objectifs de la migration

L’objectif est de déplacer les données des emplacements de partage de fichiers existants vers Azure. Dans Azure, vous allez stocker vos données dans des partages de fichiers Azure natifs que vous pourrez utiliser sans avoir besoin d’un serveur Windows Server. Cette migration doit être effectuée de manière à garantir l’intégrité des données de production et la disponibilité pendant la migration. Garantir la disponibilité implique de garder les temps d’arrêt à un niveau minimal pour qu’ils respectent les fenêtres de maintenance habituelles ou ne les dépassent que légèrement.

Vue d’ensemble de la migration

Le processus de migration se compose de plusieurs phases : Tout d’abord, vous devez déployer des comptes de stockage et partages de fichiers Azure. Ensuite, vous allez configurer les réseaux, envisager un déploiement d’espace de noms DFS (DFS-N) ou mettre à jour le vôtre. Une fois qu’il est temps de copier les données actuelles, vous devez prendre en compte les exécutions répétées et différentielles de RoboCopy pour réduire les temps d’arrêt, et enfin, diriger vos utilisateurs vers les nouveaux partages de fichiers Azure créés. Les sections suivantes décrivent en détail les phases du processus de migration.

Phase 1 : Déployer les ressources de stockage Azure

Au cours de cette phase, vous allez provisionner les comptes de stockage Azure et les partages de fichiers Azure SMB qu’ils contiennent.

N’oubliez pas qu’un partage de fichiers Azure est déployé dans le cloud dans un compte de stockage Azure. Pour les partages de fichiers standard, 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. Si vous placez plusieurs partages de fichiers dans un seul compte de stockage, vous créez un pool partagé d’IOPS et de débit pour ces partages.

En règle générale, vous pouvez regrouper plusieurs partages de fichiers Azure dans le même compte de stockage s’ils sont destinés à l’archivage ou si vous pensez qu’ils feront l’objet d’une activité quotidienne réduite. Toutefois, si vous avez des partages très actifs (partages utilisés par de nombreux utilisateurs et/ou applications), vous souhaiterez déployer des comptes de stockage avec un partage de fichiers chacun. Ces limitations ne s’appliquent pas aux comptes de stockage FileStorage (Premium), où les performances sont explicitement provisionnées et garanties pour chaque partage.

Notes

Il existe une limite de 250 comptes de stockage par abonnement et par région Azure. Avec une augmentation du quota, vous pouvez créer jusqu’à 500 comptes de stockage par région. Pour plus d’informations, consultez Augmenter de quotas du compte de stockage Azure.

Quand vous déployez un compte de stockage, vous devez également tenir compte de la redondance. Voir Redondance de Azure Files.

Si vous avez établi la liste de vos partages, vous devez mapper chaque partage au compte de stockage dans lequel il sera créé.

Le nom des ressources est également important. Par exemple, si vous regroupez plusieurs partages pour le service RH dans un compte de stockage Azure, vous devez nommer le compte de stockage de manière appropriée. De même, quand vous nommez vos partages de fichiers Azure, vous devez utiliser des noms similaires à ceux de leurs équivalents locaux.

Déployez maintenant le nombre approprié de comptes de stockage Azure avec le nombre approprié de partages de fichiers Azure, en suivant les instructions fournies dans Créer un partage de fichiers SMB. Dans la plupart des cas, vous devez vous assurer que la région de chacun de vos comptes de stockage est la même.

Phase 2 : Préparation à l’utilisation des partages de fichiers Azure

Les informations obtenues lors de cette phase vous permettront de décider comment vos serveurs et utilisateurs, dans Azure et en dehors d’Azure, seront activés pour utiliser vos partages de fichiers Azure. Voici quelles sont les décisions les plus importantes à prendre :

  • Mise en réseau : autorisez vos réseaux à acheminer le trafic SMB.
  • Authentification : configurez les comptes de stockage Azure pour l’authentification Kerberos. L’utilisation de l’authentification basée sur l’identité et de la jonction de domaine pour votre compte de stockage permettront à vos applications et utilisateurs d’utiliser leur identité AD pour l’authentification.
  • Autorisation : les listes de contrôle d’accès au niveau du partage pour chaque partage de fichiers Azure permettent aux utilisateurs et aux groupes Active Directory d’accéder à un partage donné. Dans un partage de fichiers Azure, les listes ACL NTFS natives prendront le relais. L’autorisation basée sur les listes de contrôle d’accès des fichiers et des dossiers fonctionne alors comme sur des partages SMB locaux.
  • Continuité de l’activité : l’intégration des partages de fichiers Azure dans un environnement existant implique souvent de conserver les adresses de partage existantes. Si vous n’utilisez pas déjà DFS-Namespaces, nous vous conseillons de l’établir dans votre environnement. Vous pourrez ainsi conserver les adresses de partage que vos utilisateurs et scripts utilisent, sans les modifier. DFS-N fournit un service de routage d’espace de noms pour SMB en redirigeant les clients vers des partages de fichiers Azure.

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. Si vous souhaitez obtenir d’autres informations, consultez Nouveau nom pour Azure AD.

Montage d’un partage de fichiers Azure

Avant de pouvoir utiliser RoboCopy, vous devez rendre le partage de fichiers Azure accessible sur SMB. Le moyen le plus simple consiste à monter le partage en tant que lecteur réseau local sur l’instance Windows Server que vous envisagez d’utiliser avec RoboCopy.

Important

Veillez à monter le partage de fichiers Azure à l’aide de la clé d’accès du compte de stockage. N’utilisez pas d’identité de domaine. Avant de pouvoir monter correctement un partage de fichiers Azure sur une instance Windows Server locale, vous devez avoir terminé la Phase 2 : Préparation à l’utilisation des partages de fichiers Azure.

Une fois que vous êtes prêt, consultez Utilisation d’un partage de fichiers Azure avec Windows. Ensuite, montez le partage de fichiers Azure pour lequel vous souhaitez démarrer RoboCopy.

Phase 3 : RoboCopy

La commande RoboCopy suivante copie uniquement les différences (fichiers et dossiers mis à jour) de votre stockage source vers votre partage de fichiers Azure.

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

Conseil

Si Robocopy a un impact sur votre environnement de production, signale un grand nombre d’erreurs ou ne progresse pas aussi vite que prévu, consultez la section d’aide à la résolution de problèmes.

Phase 4 : Basculement utilisateur

Quand vous exécutez la commande RoboCopy pour la première fois, les utilisateurs et applications ont toujours accès aux fichiers sur la source de votre migration et peuvent éventuellement les modifier. Il est possible que RoboCopy traite un répertoire, passe au répertoire suivant, puis qu’un utilisateur accédant à l’emplacement source ajoute, modifie ou supprime un fichier qui ne sera pas traité durant cette exécution de RoboCopy. Il s’agit du comportement attendu.

La première exécution consiste à déplacer la majeure partie des données évolutives vers votre partage de fichiers Azure. Cette première copie peut prendre beaucoup de temps. Pour en savoir plus sur les éléments susceptibles d’affecter la vitesse de Robocopy, consultez cette section d’aide à la résolution de problèmes.

Une fois l’exécution initiale terminée, réexécutez la commande.

Elle se termine plus rapidement la deuxième fois que vous exécutez RoboCopy pour le même partage. En effet, elle doit déplacer uniquement les éléments modifiés depuis la dernière exécution. Vous pouvez exécuter des travaux répétés pour le même partage.

Après avoir considéré la durée du temps d’arrêt acceptable, vous devez supprimer l’accès utilisateur à vos partages sources. Pour ce faire, vous pouvez utiliser n’importe quelle étape empêchant les utilisateurs de modifier la structure des fichiers et des dossiers, ainsi que leur contenu. Par exemple, vous pouvez faire pointer votre DFS-Namespace vers un emplacement non existant ou modifier les listes de contrôle d’accès sur chaque partage.

Exécutez une dernière fois la commande RoboCopy pour traiter toutes les modifications qui n’ont pas encore été prises en compte. La durée de cette dernière étape dépend de la vitesse d’analyse de Robocopy. Vous pouvez estimer la durée d’exécution (correspondant au temps d’arrêt) en mesurant la durée de l’exécution précédente.

Dans la phase 2, vous avez configuré vos utilisateurs pour qu’ils accèdent au partage avec leur identité et avez dû établir une stratégie leur permettant d’utiliser les chemins établis vers vos nouveaux partages de fichiers Azure (DFS-N).

Vous pouvez essayer d’exécuter quelques-unes de ces copies entre différents partages sources et cibles en parallèle. Lorsque vous procédez ainsi, gardez en tête le débit de votre réseau et le ratio du nombre de threads pour ne pas surcharger le système.

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 de votre espace de noms, comme le déplacement de fichiers entre des répertoires, la modification de propriétés à grande échelle ou la modification des autorisations de registre ou au niveau du fichier (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 plusieurs exécutions d’un outil de copie comme RoboCopy : une exécution initiale, par exemple d’un NAS vers DataBox ou d’un serveur vers un partage de fichiers Azure, et une ou plusieurs exécutions supplémentaires avec le commutateur /MIR pour intercepter et réessayer 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.

Estimation des frais de transaction de stockage

Lorsque vous commencez votre migration vers Azure Files, RoboCopy copie vos fichiers et dossiers dans Azure. Selon votre modèle de facturation pour Azure Files, des frais de transaction peuvent s’appliquer. Voir Présentation de la facturation.

Si vous utilisez un modèle de facturation de paiement à l’utilisation pour les partages de fichiers Azure standard, il peut être difficile d’estimer le nombre de transactions générées par votre migration.

  • Vous ne pouvez pas estimer le nombre de transactions en fonction de la capacité de stockage utilisée par la source. Le nombre de transactions dépend du nombre d’éléments d’espace de noms (fichiers et dossiers) et leurs propriétés qui sont migrés, pas de leur taille. Par exemple, il faut plus de transactions pour migrer 1 Gio de petits fichiers que 1 Gio de fichiers plus grands.
  • Pour réduire le temps d’arrêt, vous pouvez avoir besoin d’exécuter plusieurs fois des opérations de copie entre une source et sa cible. Tous les éléments source et cible sont traités dans chaque opération de copie, bien que les exécutions suivantes se terminent plus rapidement. Après les opérations initiales, seules les différences introduites entre les exécutions de copie sont transportées sur le réseau. Vous devez bien comprendre que même si une quantité moindre de données est transportée, le nombre de transactions nécessaires peut rester identique.
  • La copie du même fichier deux fois peut ne pas entraîner le même nombre de transactions. Le traitement d’un élément migré dans une exécution de copie précédente peut entraîner un petit nombre seulement de transactions de lecture. En revanche, des changements de métadonnées ou de contenu entre les exécutions de copie peuvent nécessiter un plus grand nombre de transactions pour mettre à jour la cible. Chaque fichier de votre espace de noms peut avoir des exigences uniques, aboutissant à un nombre différent de transactions.

Il est conseillé d’exécuter des tests initiaux sur vos propres données pour mieux comprendre le nombre de transactions engagées. Vous aurez une meilleure idée du nombre total de transactions qu’une migration de fichiers peut générer.

Étapes suivantes

Les articles suivants vous aideront à comprendre les options avancées et les meilleures pratiques.