Migration de StorSimple 8100 et 8600 vers Azure File Sync

La série StorSimple 8000 est représentée par les appliances physiques locales 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.

StorSimple série 8000 atteindra sa fin de vie en décembre 2022. Il est important de planifier votre migration le plus tôt possible. 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.

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.

Inventaire

Lorsque vous commencez à planifier votre migration, identifiez tout d’abord toutes les appliances et tous les volumes StorSimple à migrer. Une fois que vous avez terminé, vous pouvez choisir le chemin de migration qui vous convient le mieux.

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 déplacez vers un compte de stockage qui se trouve dans la même région Azure, il n’y aura aucun coût de sortie. Dans le cadre de cette migration, vous pouvez déplacer vos fichiers vers un compte de stockage situé dans une autre région. Dans ce cas, des coûts de sortie vous seront facturés.
  • 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 suivantes vous le signaleront au moment opportun.
  • 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 deviendront 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 : Tant que vous n’avez pas déprovisionné les appareils StorSimple et les comptes de stockage, les coûts de StorSimple pour le stockage, les sauvegardes et les appliances continueront à être facturés.

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

Les partages de fichiers Azure ouvrent un tout nouveau monde de possibilités pour structurer le déploiement de vos services de fichiers. Un partage de fichiers Azure désigne simplement un partage SMB dans le cloud, que vous pouvez configurer pour que les utilisateurs y accèdent directement via le protocole SMB avec l’authentification Kerberos habituelle et les autorisations NTFS existantes (listes de contrôle d’accès de fichiers et de dossiers) fonctionnant en mode natif. 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 d’importants aspects de fidélité sur les fichiers stockés comme 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 en mode natif via des protocoles et des clients familiers, tels que l’Explorateur de fichiers Windows. 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. La sauvegarde d’un partage de fichiers Azure est une fonctionnalité intégrée qui peut être améliorée par Sauvegarde Azure.

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 :

Clé de chiffrement des données de service StorSimple

Lorsque vous avez configuré votre appliance StorSimple pour la première fois, celle-ci a généré une « clé de chiffrement des données de service » et vous a demandé de stocker cette clé de façon sécurisée. 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 de service » est nécessaire pour une migration réussie. Le moment est venu de récupérer cette clé dans vos dossiers, pour chacune des appliances 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.
  • Une connexion directe à la console série de l’appareil est sécurisée, mais une connexion à la console 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é.

Limites connues

StorSimple Data Manager et les partages de fichiers Azure présentent quelques limitations que vous devez prendre en compte avant de commencer la migration, car elles 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.
  • Les volumes placés sur des disques dynamiques Windows Server ne sont pas pris en charge (déconseillé pour les versions antérieures à Windows Server 2012).
  • 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.
  • Des options réseau spéciales, telles que les pare-feu ou la communication avec point de terminaison privé uniquement, ne peuvent pas être activées sur le compte de stockage source dans lequel 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 connues n’empêche une migration, il existe quand même des limitations sur ce qui peut être stocké dans les partages de fichiers Azure que vous devez connaître. 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é de fichier indique dans quelle mesure les informations sur la source (volume StorSimple) peuvent être correctement traduites (migrées) vers la cible (partage de fichiers Azure). Azure Files prend en charge un sous-ensemble des propriétés de fichier NTFS. Les listes de contrôle d’accès, les métadonnées communes et certains horodatages seront 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 :

  • Horodatages : L’heure de changement des fichiers ne sera pas définie, elle est actuellement en lecture seule sur le protocole REST. L’horodatage du dernier accès à un fichier ne sera pas déplacé. Actuellement, ce n’est pas 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 listent chaque élément ignoré, accompagné d’une raison.
  • La copie des fichiers chiffrés EFS échoue. Les journaux de copie indiquent l’élément qui n’a pas pu être copié avec « L’accès est refusé ».
  • Les fichiers endommagés sont ignorés. Les journaux de copie peuvent lister différentes erreurs pour chaque élément endommagé sur le disque StorSimple : « Échec de la requête en raison d’une grave erreur matérielle de l’appareil. » ou « Le fichier ou le répertoire est endommagé ou illisible » ou « Structure de liste de contrôle de l’accès non 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 les dossiers avec des chemins plus longs sont ignorés.

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, pas les données du volume actif. Par conséquent, la sauvegarde la plus récente doit toujours figurer dans la liste des sauvegardes déplacées lors d'une migration.

Déterminez si vous devez déplacer les anciennes sauvegardes au cours de la migration. La meilleure pratique consiste à réduire le plus possible cette liste, afin que vos tâches de migration soient traitées plus rapidement.

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

  • la sauvegarde la plus récente. (Remarque : la sauvegarde la plus récente doit toujours figurer dans cette liste).
  • Une sauvegarde par mois pendant 12 mois.
  • Une sauvegarde par an pendant trois ans.

Plus tard, lors de la création de vos tâches de migration, vous pourrez utiliser cette liste pour identifier précisément les sauvegardes de volume StorSimple qui doivent être migrées afin de répondre aux exigences de votre liste.

Attention

Il est impossible de sélectionner plus de 50 sauvegardes de volume StorSimple. 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.

Attention

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 prend plusieurs jours ou semaines. StorSimple offre des stratégies de rétention de sauvegarde qui suppriment les sauvegardes. Les sauvegardes que vous avez sélectionnées pour cette migration peuvent être supprimées avant qu’elles aient pu être migrées.

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.

    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.

Nombre de comptes de stockage

Votre migration est susceptible de tirer parti d’un déploiement de plusieurs comptes de stockage, qui contiennent 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 conséquent, la meilleure pratique consiste à effectuer une migration vers plusieurs comptes de stockage, chacun disposant de 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 effectuer une migration lift-and-shift d'une application vers le cloud, avec accès direct à un partage de fichiers. Ce scénario pourrait permettre de bénéficier d'un nombre 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.

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

Important

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. 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. La liste de vérification suivante doit être utilisée pour confirmer les configurations de votre compte de stockage. Vous pouvez par exemple modifier la configuration de mise en réseau une fois la 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és. Ne configurez pas de restrictions d’adresse IP ou ne limitez pas l’accès au 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 manière.
  • Points de terminaison privés : pris en charge. Vous pouvez activer des points de terminaison privés, mais le point de terminaison public est utilisé pour la migration et doit rester disponible. Cette considération 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é votre « clé de chiffrement des données de 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.

Déployer des comptes de stockage

Vous aurez probablement besoin de déployer plusieurs comptes de stockage Azure. Chacun d’eux contiendra un plus petit nombre de partages de fichiers Azure, conformément au plan de déploiement vous avez terminé dans la section précédente de cet article. 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 les paramètres de pare-feu de 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 utilisé pour votre déploiement StorSimple ou en utiliser un autre. La seule limitation est que votre abonnement doit se trouver dans le même locataire Azure Active Directory que l’abonnement StorSimple. Avant toute migration, pensez à déplacer l'abonnement StorSimple vers le locataire approprié. Vous êtes obligé de déplacer l'intégralité de l'abonnement ; il est en effet impossible de déplacer des ressources StorSimple individuelles vers un autre locataire ou abonnement.

Resource group

Les groupes de ressources aident à l’organisation des ressources et à la gestion administrative des autorisations. En savoir plus sur les groupes de ressources dans Azure.

Nom du compte de stockage

Le nom de votre compte de stockage devient partie intégrante d’une URL et présente certaines limitations de caractère. Dans votre convention de nommage, considérez que les noms de compte de stockage doivent être uniques au monde. N’autorisez que des lettres minuscules et des chiffres, exigez entre 3 et 24 caractères, et interdisez les caractères spéciaux tels que les tirets ou les traits de soulignement. Pour plus d’informations, consultez Règles de nommage des ressources de stockage Azure.

Emplacement

La localisation, ou région Azure, d’un compte de stockage est très important. Si vous utilisez Azure File Sync, tous vos comptes de stockage doivent se trouver dans la même région que votre ressource de service de synchronisation de stockage. La région Azure que vous sélectionnez doit être proche ou centrale par rapport à vos serveurs et utilisateurs locaux. Une fois que votre ressource a été déployée, vous ne pouvez plus changer sa région.

Vous pouvez choisir une région différente de celle où résident actuellement vos données StorSimple (compte de stockage).

Important

Si vous choisissez une région différente de celle où se trouve votre compte de stockage StorSimple, 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.

Vous ne savez toujours pas ?

  • 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. En savoir plus sur les différents types de réplication.

Choisissez l’une des deux options suivantes :

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

Notes

Seuls les types de redondance LRS et ZRS sont compatibles avec les grands partages de fichiers Azure d’une capacité de 100 Tio.

Le stockage globalement redondant, toutes variantes confondues, n’est pas pris en charge pour le moment. Vous pouvez changer de type de redondance plus tard et passer à GRS lorsqu’Azure le prendra en charge.

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

An image showing the Advanced tab in the Azure portal for the creation of a storage account.

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.

Opter pour les grands partages de fichiers d’une capacité de 100 Tio présente plusieurs avantages :

  • Vos performances sont considérablement accrues par rapport aux partages de fichiers plus petits d’une capacité de 5 Tio (par exemple, 10 fois plus d’IOPS).
  • La migration se terminera beaucoup plus rapidement.
  • Le partage de fichiers disposera d'une capacité suffisante pour contenir toutes les données que vous migrerez vers celui-ci, 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écifique à votre compte de stockage avant ou pendant la migration. Le point de terminaison public doit être accessible sur les comptes de stockage source et cible. Aucune limitation en termes d’adresses IP ou de réseaux virtuels spécifiques n’est 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

Une fois les comptes de stockage créés, accédez à la section Partage de fichiers du compte de stockage, puis déployez le nombre approprié de partages de fichiers Azure selon votre plan de migration (voir phase 1). Envisagez d’utiliser les paramètres de base suivants pour tout nouveau partage de fichiers dans Azure.

An Azure portal screenshot showing the new file share UI.




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 contiendra vos tâches de migration s’appelle 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. Elle doit être déployée dans le même abonnement, le même groupe de ressources et la même 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. Il est préférable de configurer Azure File Sync une fois la migration de votre partage terminée. 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 avec soin les répertoires sur un volume StorSimple qui doit être copié dans le partage de fichiers Azure cible que vous sélectionnez. 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.

StorSimple 8000 series migration job types.

Screenshot of the new job creation form for a migration job.

Nom de définition de tâcheCe 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 sourceSé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 de sélection de sauvegarde, celle-ci 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 delta réduit sur le partage actif améliorera votre expérience de migration. Si ce delta peut être égal à zéro = aucune autre modification du volume StorSimple n'a eu lieu après la dernière sauvegarde de votre liste - alors en phase 5 : Le basculement des utilisateurs sera 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 ancienne ne peut pas être « triée » dans la liste des sauvegardes du 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.

A screenshot of the new job creation form detailing the portion where StorSimple backups are selected for migration.

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.

An image showing that the upper half of the blade for selecting backups lists all available backups. A selected backup will be grayed-out in this list and added to a second list on the lower half of the blade. There it can also be deleted again.

Lorsque le panneau de sélection des sauvegardes s'ouvre, il est divisé 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 la section suivante)

Une sauvegarde sélectionnée sera grisée et ajoutée à une deuxième liste dans la moitié inférieure du panneau. 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. Il sera ensuite impossible d'ajouter des sauvegardes plus anciennes. Une fois la tâche créée, vous ne pouvez pas la modifier pour changer votre sélection.

A screenshot showing the selection of a time range of the backup selection blade.

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

Il est impossible de sélectionner plus de 50 sauvegardes de volume StorSimple. 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 seront ignorés.
  • Les structures de dossiers qui n’existent pas sur la cible seront 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.

Screenshot of the migration job blade with a highlight around the command to start the job. It also displays the selected backups scheduled for migration.

Au départ, la tâche de migration aura l’état Jamais exécuté.
Lorsque vous êtes prêt, vous pouvez démarrer cette tâche de migration. (Sélectionnez l’image d’une version avec offrant une résolution plus élevée.)
Quand une sauvegarde a été migrée avec succès, une capture instantanée du partage de fichiers Azure est prise automatiquement. La date de sauvegarde d’origine de votre sauvegarde StorSimple est placée dans la section Commentaires de l’instantané de partage de fichiers Azure. L’utilisation de ce champ vous permet de voir quand les données ont été sauvegardées au départ par rapport à l’heure à laquelle l’instantané de 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 stratégies de rétention avant de pouvoir être migrées.

Erreurs par élément

Les tâches de migration ont deux colonnes dans la liste des sauvegardes, qui répertorient les problèmes qui se sont éventuellement produits 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 dans votre dernière sauvegarde et que vous avez trouvé dans le journal de copie que c’était dû à un nom de fichier, une longueur de chemin ou un autre problème sur lequel vous avez une influence, vous voudrez peut-être remédier au problème dans le volume StorSimple actif, effectuer une sauvegarde de volume StorSimple et créer une nouvelle tâche de migration juste avec cette sauvegarde. Vous migrerez ensuite cet espace de noms réparé, lequel deviendra la version la plus récente/active 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. Il peut y avoir d’autres journaux générés 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éeNouvelle tâche qui a été définie, mais jamais exécutée.
  • AttenteUne 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.
  • ÉchecUne tâche ayant échoué rencontre une erreur irrécupérable qui l’empêche de traiter d’autres sauvegardes. Une tâche n’est pas censée entrer dans cet état. Une demande de support est la meilleure marche à suivre.
  • AnnuléeAnnulationIl est possible d’annuler une tâche de migration en entier ou des sauvegardes individuelles dans la tâche. Les sauvegardes annulées ne sont pas traitées, une tâche de migration annulée arrête le traitement d’autres 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 marche à suivre pour laisser une tâche arriver complètement à l’état Annulé est la patience. Vous pouvez ignorer les tâches ayant échoué/annulées ou 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.

Screenshot of the migration job blade with a large status icon on the top in the running state.

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 des erreurs sont signalées pour une sauvegarde, vous devez consulter le journal de copie.

Screenshot of the migration job blade with a large status icon on the top in the paused state.

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 la précédente plus tard, qui sera probablement incomplète.

An image showing the migration job blade with a large status icon on the top in the complete state.

Terminée et Terminée avec des avertissementsUne tâche de migration est marquée Terminée lorsque toutes les sauvegardes qu’elle contient ont été traitées avec succès.

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 aurez probablement plusieurs volumes StorSimple, chacun avec des 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, vous avez vérifié que les tâches précédentes se trouvent dans le copy stage et affichent 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 d’appareil 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 démarrer la tâche actuelle. 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

Il est judicieux de vérifier régulièrement vos tâches de migration sous l’onglet Définition de la tâche de votre ressource Data Manager, afin de voir si l’une d’entre elles est en pause et a besoin de votre intervention 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 tirera pas parti de la mise en cache locale, ou si vous n’avez plus la possibilité d’héberger une instance locale de Windows Server. 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.

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 avez commencé à utiliser Azure File Sync avant la fin de votre migration, cela rendra votre migration inutilement difficile, car vous ne pourrez pas facilement dire quand il sera temps de lancer une opération de 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 intéressantes localement sont également mises en cache localement pour des performances d’accès local 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 pour certains sujets :

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

Cette phase est consacrée à la finalisation de 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.

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 prochaine section sur RoboCopy aborde 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’archivage, il s’agit d’une approche entièrement viable pour mettre en place un temps d’arrêt sur votre volume StorSimple (ou sous-dossier), faire une sauvegarde de volume StorSimple, migrer puis ouvrir la destination de migration pour que les utilisateurs et les applications puissent y accéder. Ainsi, vous n’aurez pas besoin d’un RoboCopy de récupération comme décrit dans cette section. 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 d’attendre que l’espace de noms entier ait été entièrement téléchargé 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 HResult0.
  6. S’il vous manque cet événement, vous pouvez également rechercher d’autres événements 9102SyncDirectionTé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 rencontre actuellement un problème qui entraîne la recopie des fichiers hiérarchisés par Azure File Sync sur le serveur cible à partir de la source, puis le rechargement vers Azure lors de l’utilisation de la fonction /MIR de Robocopy. Il est impératif d’utiliser Robocopy sur un serveur Windows Server autre que 2019. Le choix par défaut est Windows Server 2016. Cette note sera mise à jour en cas de résolution du problème via Windows Update.

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

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éplace donc pas les fichiers qui sont identiques (fichiers hiérarchisés, par exemple). Toutefois, si le chemin source et le chemin cible sont incorrects, /MIR vide également les structures de répertoires qui sont présentes sur votre instance Windows Server ou sur le partage de fichiers Azure, mais pas 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.

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.

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 :

Étapes suivantes