Utiliser DataBox pour migrer d’un NAS vers des partages de fichiers Azure

Cet article sur la migration fait partie d’une série d’articles traitant de mots clés tels que NAS et Azure DataBox. Vérifiez qu’il s’applique à votre scénario :

  • Source de données : stockage NAS (Network-Attached Storage)
  • Itinéraire de migration : NAS ⇒ DataBox ⇒ Partage de fichier Azure
  • Mise en cache de fichiers locaux : non, l’objectif final est d’utiliser les partages de fichiers Azure directement dans le cloud. Cette procédure n’implique pas l’utilisation de la fonctionnalité Azure File Sync.

Si votre scénario est différent, consultez le tableau des guides de migration.

Cet article vous guide tout au long des étapes de planification, de déploiement et de mise en réseau nécessaires à la migration de votre appliance NAS vers des partages de fichiers Azure fonctionnels. Dans ce guide, nous utiliserons Azure DataBox pour le transport de données en bloc (transport de données hors connexion).

S’applique à

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

Objectifs de la migration

L’objectif est de déplacer les partages de votre appliance NAS vers Azure et de les convertir en partages de fichiers Azure natifs. Vous pouvez utiliser des partages de fichiers Azure natifs sans avoir besoin d’un serveur Windows. 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 : Vous devez déployer des comptes de stockage et des partages de fichiers Azure, et configurer la mise en réseau. Ensuite, vous allez migrer vos fichiers à l’aide d’Azure DataBox et RoboCopy pour rattraper les modifications. Enfin, vous allez transférer vos utilisateurs et applications vers les partages de fichiers Azure que vous venez de créer. Les sections suivantes décrivent en détail les phases du processus de migration.

Conseil

Si vous revenez à cet article, utilisez la navigation de droite pour accéder à la phase de migration là où vous vous étiez arrêté.

Phase 1 : Identifier le nombre de partages de fichiers Azure dont vous avez besoin

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.

    Un partage de fichier standard Azure peut théoriquement saturer les performances maximales d’un compte de stockage. Si vous placez plusieurs partages dans un seul compte de stockage, vous créez un pool partagé d’IOPS et de débit pour ces partages. Si vous envisagez de joindre uniquement Azure File Sync à ces partages de fichiers, le regroupement de plusieurs partages de fichiers Azure dans le même compte de stockage n’est pas un problème. Examinez les objectifs de performances du partage de fichiers Azure pour avoir une idée plus précise des mesures appropriées. Ces limitations ne s’appliquent pas au stockage Premium, où les performances sont explicitement provisionnées et garanties pour chaque partage.

    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.

Créer une table de mappage

Diagram that shows an example of a mapping table. Download the following file to experience and use the content of this image.

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.


Excel icon that sets the context for the download. Téléchargez un modèle de mappage d’espace de noms.

Phase 2 : Déployer des ressources de stockage Azure

Au cours de cette phase, consultez la table de mappage de la phase 1 et utilisez-la pour configurer le nombre correct de comptes de stockage Azure et de partages de fichiers dans ceux-ci.

Un partage de fichiers Azure est stocké dans le cloud dans un compte de stockage Azure. Les performances doivent être considérées à un autre niveau ici.

Si vous avez des partages très actifs (utilisés par de nombreux utilisateurs et/ou applications), la limite de performances d’un compte de stockage peut être atteinte avec deux partages de fichiers Azure.

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 ou si vous pensez qu’ils feront l’objet d’une activité quotidienne réduite.

Ces considérations s’appliquent davantage à l’accès direct au cloud (par le biais d’une machine virtuelle Azure) qu’à Azure File Sync. Si vous envisagez d’utiliser Azure File Sync sur ces partages uniquement, le regroupement de plusieurs partages dans le même compte de stockage Azure est une bonne idée.

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

Durant la phase précédente, vous avez déterminé le nombre de partages approprié. Au cours de cette étape, vous avez un mappage des comptes de stockage aux partages de fichiers. Déployez maintenant le nombre approprié de comptes de stockage Azure avec le nombre approprié de partages de fichiers Azure contenus.

Vérifiez que la région est la même pour tous vos comptes de stockage et qu’elle correspond à la région de la ressource de service de synchronisation de stockage que vous avez déjà déployée.

Attention

Si vous créez un partage de fichiers Azure limité à 100 Tio, il peut utiliser deux options de redondance seulement : un stockage localement redondant ou un stockage redondant interzone. Tenez compte de vos besoins en termes de redondance du stockage avant d’utiliser des partages de fichiers de 100 Tio.

Les partages de fichiers Azure sont toujours créés avec une limite de 5 Tio par défaut. Suivez les étapes de la section Créer un partage de fichiers Azure pour créer un partage de fichiers volumineux.

Quand vous déployez un compte de stockage, vous devez également tenir compte de la redondance du stockage Azure. Consultez Options de redondance de stockage Azure.

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.

Phase 3 : Déterminer le nombre d’appliances Azure DataBox dont vous avez besoin

Ne suivez cette étape qu’après avoir terminé la phase précédente. À ce stade, vos ressources de stockage Azure (comptes de stockage et partages de fichiers) doivent être créées. Lors de la commande de votre DataBox, vous devez spécifier les comptes de stockage vers lesquels la DataBox déplace les données.

Au cours de cette phase, vous devez mapper les résultats du plan de migration de la phase précédente aux limites des options DataBox disponibles. Ces considérations vous aideront à établir un plan correspondant aux options DataBox que vous devez choisir et combien d’entre elles vous seront nécessaires pour déplacer vos partages NAS vers des partages de fichiers Azure.

Pour déterminer le nombre d’appareils dont vous avez besoin, tenez compte des limites importantes suivantes :

  • Une DataBox Azure peut déplacer des données dans un maximum de 10 comptes de stockage.
  • Chaque option DataBox dispose de sa propre capacité utilisable. Consultez Options de DataBox.

Consultez votre plan de migration pour obtenir le nombre de comptes de stockage que vous avez décidé de créer, ainsi que les partages dans chacun d’entre eux. Examinez ensuite la taille de chaque partage sur votre NAS. La combinaison de ces informations vous sera utile à des fins d’optimisation, ainsi que pour choisir appliance qui devra envoyer des données vers les comptes de stockage. Vous pouvez faire en sorte que deux appareils DataBox déplacent des fichiers dans le même compte de stockage, sans fractionner le contenu d’un partage de fichiers unique sur deux DataBox.

Options de DataBox

Pour une migration standard, une option de DataBox, voire les trois peuvent être choisies :

  • DataBox Disks Microsoft vous enverra d’un à cinq disques SSD avec une capacité de 8 Tio chacun, pour un total maximal de 40 Tio. La capacité utilisable est d’environ 20 % inférieure en raison du chiffrement et de la surcharge du système de fichiers. Pour plus d’informations, consultez la documentation DataBox Disks.
  • DataBox Correspond à l’option la plus courante. Une appliance DataBox robuste, qui fonctionne de façon similaire à un NAS, vous sera expédiée. Elle dispose d’une capacité utilisable de 80 Tio. Pour plus d’informations, consultez la documentation DataBox.
  • DataBox Heavy Cette option offre une appliance DataBox robuste sur roues, qui fonctionne de façon similaire à un NAS, avec une capacité de 1 Pio. La capacité utilisable est d’environ 20 % inférieure en raison du chiffrement et de la surcharge du système de fichiers. Pour plus d’informations, consultez la documentation DataBox Heavy.

Phase 4 : Configurer une instance Windows Server temporaire

En attendant l’arrivée de votre ou vos DataBox Azure, vous pouvez déjà déployer une ou plusieurs instances Windows Server dont vous aurez besoin pour exécuter des tâches RoboCopy.

  • Ces serveurs vous serviront d’abord à copier vos fichiers sur le DataBox.
  • Puis ils vous serviront à récupérer les modifications qui se sont produites sur l’appliance NAS pendant la livraison de votre ou vos DataBox. Cette approche permet de réduire au minimum le temps d’arrêt côté source.

La vitesse de fonctionnement de vos tâches RoboCopy dépend principalement de ces facteurs :

  • Les IOPS sur le stockage source et le stockage cible
  • la largeur de bande passante disponible du réseau entre eux
    Vous trouverez plus de détails dans la section Dépannage : Remarques relatives à la bande passante et aux IOPS
  • la possibilité de traiter rapidement les fichiers et les dossiers dans un espace de noms
    Vous trouverez plus de détails dans la section Dépannage : Vitesse de traitement
  • le nombre de modifications entre les exécutions de RoboCopy
    . Vous trouverez plus de détails dans la section Dépannage : Éviter le travail inutile

Il est important de noter les informations référencées. Elles vous serviront à décider quelle quantité de mémoire RAM et combien de threads vous fournirez à votre ou vos instances Windows Server temporaires.

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

Pour gagner du temps, vous devez passer à cette phase pendant que vous attendez la livraison de votre DataBox. 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. AdConnect et 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é. Puis, une fois dans un partage de fichiers Azure, les listes de contrôle d’accès 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é des activités : 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-N (pour DFS-Namespaces, ou « Espaces de noms DFS »), 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. Vous pouvez utiliser DFS-N comme service de routage d’espace de noms pour SMB, en redirigeant les cibles DFS-Namespace vers des partages de fichiers Azure après leur migration.

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 pour certains sujets :

Phase 6 : Copier des fichiers sur votre DataBox

Une fois votre DataBox reçue, vous devez la configurer dans la ligne de vue de votre appliance NAS. Suivez la documentation relative au type de DataBox que vous avez commandé.

Selon le type de DataBox, des outils de copie DataBox peuvent être mis à votre disposition. À ce stade, ils ne sont pas recommandés pour effectuer des migrations vers des partages de fichiers Azure, car ils ne copient pas vos fichiers assez fidèlement vers la DataBox. Privilégiez RoboCopy.

La DataBox reçue est dotée de partages SMB préconfigurés disponibles pour chaque compte de stockage spécifié au moment de la commande.

  • Si vos fichiers sont placés dans un partage de fichiers Azure Premium, vous disposerez d’un partage SMB par compte de stockage « stockage de fichiers » Premium.
  • Si vos fichiers sont placés dans un compte de stockage standard, vous disposerez de trois partages SMB par compte de stockage standard (GPv1 et GPv2). Seuls les partages de fichiers se terminant par _AzFiles sont pertinents pour votre migration. Ignorez les partages d’objets blob de blocs et de pages.

Suivez les étapes décrites dans la documentation Azure DataBox :

  1. Se connecter à Data Box
  2. Copier des données sur Data Box
  3. Préparer votre DataBox pour Azure

La documentation DataBox connexe spécifie une commande RoboCopy. Toutefois, la commande ne permet pas de préserver la fidélité complète des fichiers et des dossiers. Utilisez plutôt la commande suivante :

Robocopy /MT:32 /NP /NFL /NDL /B /MIR /IT /COPY:DATSO /DCOPY:DAT /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path> 
  • Pour en savoir plus sur les détails des différents indicateurs RoboCopy, consultez le tableau dans la section Robocopy.
  • Pour en savoir plus sur la façon de dimensionner correctement le nombre de threads /MT:n, d’optimiser la vitesse de Robocopy et de faire de Robocopy un bon adjuvant pour votre centre de données, consultez la section d’aide à la résolution des problèmes affectant Robocopy.

Conseil

En guise d’alternative à Robocopy, Data Box a créé un service de copie de données. Vous pouvez utiliser ce service pour charger des fichiers sur votre Data Box avec une fidélité totale. Suivez ce tutoriel de service de copie de données et veillez à définir la bonne cible de partage de fichiers Azure.

Phase 7 : Mettre à jour RoboCopy à partir de votre NAS

Une fois que votre DataBox signale que tous les fichiers et dossiers ont été placés dans les partages de fichiers Azure planifiés, vous pouvez poursuivre cette phase. Un RoboCopy de récupération est seulement nécessaire si les données sur le NAS ont pu être modifiées depuis le démarrage de la copie vers DataBox. Dans certains scénarios où vous utilisez un partage à des fins d’archivage, vous pouvez être en mesure d’arrêter les modifications du partage sur votre NAS jusqu’à la fin de la migration. Vous pouvez aussi être en mesure de répondre aux besoins de votre entreprise en définissant les partages NAS en lecture seule pendant la migration.

Dans les cas où vous avez besoin d’un partage en lecture-écriture pendant la migration et que vous devez réduire au minimum le temps d’arrêt, il est important pour vous de terminer cette étape de récupération avant le basculement de l’accès des utilisateurs directement vers le partage de fichiers Azure.

Dans cette étape, vous allez exécuter des travaux RoboCopy pour intercepter vos partages cloud avec les dernières modifications apportées à votre NAS depuis la duplication de vos partages sur la DataBox. Cette mise à jour RoboCopy peut se terminer rapidement ou prendre un certain temps selon le volume de modifications intervenues sur vos partages NAS.

Exécutez la première copie locale vers votre dossier Windows Server cible :

  1. Identifiez le premier emplacement sur votre appliance NAS.
  2. Identifiez le partage de fichiers Azure correspondant.
  3. Montez le partage de fichiers Azure en tant que lecteur réseau local sur votre instance Windows Server temporaire.
  4. Démarrez la copie à l’aide de RoboCopy, comme indiqué.

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

Avant de pouvoir monter correctement un partage de fichiers Azure sur une instance Windows Server locale, vous devez avoir terminé la phase : Préparation à l’utilisation des partages de fichiers Azure.

Lorsque vous êtes prêt, consultez l’article Utiliser un partage de fichiers Azure avec Windows et montez le partage de fichiers Azure pour lequel vous souhaitez démarrer la tâche de récupération de NAS Robocopy.

Robocopy

La commande RoboCopy suivante copie uniquement les différences (fichiers et dossiers mis à jour) de votre stockage NAS 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.
/LFSM Uniquement pour les cibles avec stockage hiérarchisé. Uniquement pour les cibles avec stockage hiérarchisé.
Spécifie que Robocopy fonctionne en « mode espace libre réduit ». Ce commutateur est utile uniquement pour les cibles avec stockage hiérarchisé, susceptibles de manquer de capacité locale avant que Robocopy puisse se terminer. 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.
/Z Utiliser avec prudenceCopie 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 prudenceUtilise 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 cette section d’aide à la résolution de problèmes.

Transfert de l’utilisateur

Quand vous exécutez la commande RoboCopy pour la première fois, les utilisateurs et applications ont toujours accès aux fichiers sur l’appliance NAS 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 (NAS) 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.

Dès lors que vous considérez que le temps d’arrêt est acceptable, vous devez supprimer l’accès utilisateur à vos partages NAS. 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 racine sur le 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.

Créez un partage dans le dossier Windows Server et, le cas échéant, ajustez votre déploiement DFS-N pour qu’il pointe vers celui-ci. Veillez à définir les mêmes autorisations au niveau du partage que celles de votre partage SMB NAS. Si vous aviez un NAS joint à un domaine d’entreprise, les SID de l’utilisateur correspondent automatiquement à mesure que la présence des utilisateurs est vérifiée dans Active Directory et que RoboCopy copie fidèlement les fichiers et les métadonnées. Si vous avez utilisé des utilisateurs locaux sur votre emplacement NAS, vous devez recréer ces utilisateurs en tant qu’utilisateurs locaux de Windows Server et mapper les SID existants que RoboCopy a déplacés sur votre Windows Server avec les SID de vos nouveaux utilisateurs locaux de Windows Server.

Vous avez terminé la migration d’un partage/groupe de partages vers une racine ou un volume commun (selon votre mappage à partir de la phase 1)

Vous pouvez essayer d’exécuter quelques-unes de ces copies en parallèle. Nous vous recommandons de traiter l’étendue d’un partage de fichiers Azure à la fois.

Dépanner

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.

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 demeurent inchangées.

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.

Étapes suivantes

Vous pouvez en apprendre davantage sur les partages de fichiers Azure. Les articles suivants vous aident à comprendre les options avancées et les meilleures pratiques et contiennent également des aides pour la résolution des problèmes. Ces articles sont liés à la documentation relative aux partages de fichiers Azure, le cas échéant.