Partager via

Migrer vers des partages de fichiers Azure SMB

Cet article traite des aspects de base d’une migration vers des partages de fichiers SMB Azure et contient une table des guides de migration. Ces guides vous aident à déplacer vos fichiers vers des partages de fichiers Azure. Les guides sont organisés en fonction de l’emplacement de vos données et du modèle de déploiement (cloud uniquement ou hybride) vers lequel vous vous déplacez.

S’applique à

Type de partage de fichiers PME Système de fichiers en réseau (NFS)
Partages de fichiers Standard (GPv2), LRS/ZRS Oui Non
Partages de fichiers Standard (GPv2), GRS/GZRS Oui Non
Partages de fichiers Premium (FileStorage), LRS/ZRS Oui Non

Notions de base de la migration

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

Azure offre différents types de stockage en ligne. Un aspect fondamental de la migration de fichiers vers Azure consiste à déterminer l’option de stockage Azure adaptée à vos données.

Les partages de fichiers Azure sont bien adaptés aux données de fichiers à usage général. Ces données incluent tout ce que vous utilisez avec un partage SMB local. Avec Azure File Sync, vous pouvez mettre en cache le contenu de plusieurs partages de fichiers Azure sur des serveurs Windows, localement ou dans Azure.

Pour une application qui s’exécute actuellement sur un serveur local, le stockage de fichiers dans un partage de fichiers Azure peut être un bon choix. Vous pouvez déplacer l’application vers Azure et utiliser des partages de fichiers Azure comme stockage partagé. Vous pouvez également envisager d’utiliser des disques Azure dans ce scénario.

Certaines applications cloud ne dépendent pas de SMB, de l’accès local aux données de l’ordinateur ou de l’accès partagé. Pour ces applications, le stockage d’objets tels que les objets blob Azure est souvent le meilleur choix.

Préservation de la fidélité des fichiers

Un aspect clé de toute migration de partage de fichiers capture autant de fidélité de fichier que possible lors du déplacement de vos fichiers de leur emplacement de stockage actuel vers Azure.

Voici les deux composants de base d’un fichier :

  • Flux de données : le flux de données d’un fichier stocke le contenu du fichier.
  • Métadonnées de fichier : contrairement au stockage d’objets blob Azure, un partage de fichiers Azure peut stocker en mode natif les métadonnées de fichier prises en charge. Traditionnellement, les données de fichiers à usage général dépendent des métadonnées de fichier. Ce n’est pas forcément le cas des données d’application. Les métadonnées de fichier comportent les sous-composants suivants :
    • Attributs de fichier tels que En lecture seule
    • Autorisations de fichier, généralement appelées autorisations NTFS ou listes de contrôle d’accès de fichiers et de dossiers
    • Horodatages, en particulier, les horodatages de création et de dernière modification
    • Un autre flux de données, qui est un espace pour stocker de grandes quantités de propriétés non standard. Ce flux de données de remplacement ne peut pas être stocké sur un fichier dans un partage de fichiers Azure. Il est conservé localement quand Azure File Sync est utilisé.

La fidélité des fichiers dans une migration peut être définie comme la capacité à :

Pour garantir une migration sans accroc, identifiez le meilleur outil de copie selon vos besoins et associez une cible de stockage à votre source.

Important

Si vous effectuez la migration des serveurs de fichiers locaux vers Azure File, définissez les listes de contrôle d’accès pour le répertoire racine du partage de fichiers avant de copier un grand nombre de fichiers, car la propagation des modifications apportées aux autorisations pour les listes de contrôle d’accès racines peut prendre longtemps, si elles sont effectuées après une migration de fichiers volumineux.

Les utilisateurs qui se servent d’Active Directory Domain Services (AD DS) comme contrôleur de domaine local peuvent accéder en mode natif à un partage de fichiers Azure. Il en va de même pour les utilisateurs de Microsoft Entra Domain Services. Chacun utilise son identité actuelle pour y accéder en fonction des autorisations du partage et des listes de contrôle d’accès des fichiers et des dossiers. Ce comportement est similaire à celui d’un utilisateur qui se connecte à un partage de fichiers local.

En savoir plus sur l’authentification basée sur l’identité pour Azure Files sur SMB.

Métadonnées prises en charge

Le tableau suivant répertorie les métadonnées prises en charge pour Azure Files.

Important

L’horodatage LastAccessTime n’est actuellement pas pris en charge pour les fichiers ou les répertoires sur le partage cible. Toutefois, Azure Files retourne la valeur LastAccessTime d’un fichier lorsqu’il est demandé. Étant donné que l’horodatage LastModifiedTime n’est pas mis à jour sur les opérations de lecture, il est toujours égal à l’horodatage CreationTime.

Source Cible
Structure de répertoire La structure de répertoires d’origine de la source peut être conservée sur le partage cible.
Autorisations d’accès Azure Files prend en charge les listes de contrôle d’accès Windows et doit être définie sur le partage cible, même si aucune intégration AD n’est configurée au moment de la migration. Les listes de contrôle d’accès suivantes doivent être conservées : identificateur de sécurité du propriétaire (SID), SID du groupe, listes d’accès discrétionnaires (DACL), listes de contrôle d’accès système (SACL).
Créez un horodatage L’horodatage de création d’origine du fichier source peut être conservé sur le partage cible.
Modifiez l’horodatage L’horodatage de modification d’origine du fichier source peut être conservé sur le partage cible.
Horodatage modifié L’horodatage modifié d’origine du fichier source peut être conservé sur le partage cible.
Attributs de fichier Les attributs courants tels que les indicateurs en lecture seule, masqués et archive peuvent être conservés sur le partage cible.

Phase de détection

La première phase d’une migration est la phase de découverte, dans laquelle vous déterminez tous les partages de fichiers SMB existants qui doivent être migrés, y compris leur taille, leur nombre et toutes les dépendances. Cela peut être une tâche difficile et fastidieuse, en particulier pour les organisations avec de grands environnements distribués. Pour les clients disposant de plus de 100 Tio de données de fichiers, nous vous recommandons d’utiliser Komprise, un outil tiers qui peut vous aider à découvrir et analyser vos partages de fichiers. Pour plus d’informations, consultez La migration de fichiers Komprise.

N’oubliez pas que vos partages de fichiers SMB existants peuvent ne pas être limités aux serveurs Windows locaux. Ils peuvent se trouver sur des serveurs Linux, dans le cloud ou sur des appareils NAS externes.

Phase d’évaluation

Une fois la découverte terminée, la phase d’évaluation implique la compréhension des options disponibles pour le stockage de fichiers, le déploiement des ressources Azure dont vous aurez besoin et la préparation à l’utilisation des partages de fichiers Azure.

Déployer des ressources de stockage Azure

Dans le cadre de la phase d’évaluation, vous allez provisionner les comptes de stockage Azure et les partages de fichiers Azure SMB dans ceux-ci.

Un partage de fichiers Azure est déployé dans le cloud dans un compte de stockage Azure. Pour les partages de fichiers standard, cet arrangement fait du compte de stockage une cible de mise à l’échelle pour les chiffres des performances comme les IOPS et le débit. Si vous placez plusieurs partages de fichiers dans un seul compte de stockage, vous créez un pool partagé d’IOPS et de débit pour ces partages.

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

Pour plus d’informations sur les performances et les coûts, consultez Comprendre les performances et comprendre la facturation.

Remarque

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

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

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

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

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

Préparer l’utilisation des partages de fichiers Azure

Vous devez également décider de la façon dont vos serveurs et utilisateurs dans Azure et en dehors d’Azure seront activés pour utiliser vos partages de fichiers Azure. Voici quelles sont les décisions les plus importantes à prendre :

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

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

Guides de migration

La sélection des outils appropriés pour votre scénario de migration est cruciale. Le diagramme suivant montre l’outil de migration ou la combinaison d’outils que vous devez utiliser en fonction de votre source de données SMB et si vous souhaitez ou non utiliser Azure File Sync.

Organigramme de décision montrant l’outil de migration que vous devez choisir en fonction de votre source de données SMB.

Le tableau suivant répertorie les combinaisons d’outils de migration suggérées et inclut des liens vers des guides de migration spécifiques à l’outil.

Comment utiliser la table :

  1. Recherchez la ligne du système source sur lequel vos fichiers se trouvent actuellement.

  2. Choisissez l’une de ces cibles :

    • Déploiement hybride : Utilisez Azure File Sync pour mettre en cache le contenu des partages de fichiers Azure localement et hiérarchiser les fichiers moins fréquemment utilisés dans le cloud.
    • Déploiement cloud uniquement : partages de fichiers Azure dans le cloud, sans mise en cache locale.

    Sélectionnez la colonne cible qui correspond à votre choix.

  3. À l’intersection de la source et de la cible, la cellule répertorie les scénarios de migration disponibles. Sélectionnez-en un pour afficher le guide de migration.

Les scénarios sans lien n’ont pas encore de guide de migration. Consultez régulièrement cette table pour découvrir les mises à jour.

Origine Cible :
déploiement hybride
(Azure Files + Azure File Sync)		 Cible :
déploiement cloud uniquement
(Azure Files)
Association d’outils recommandée : Association d’outils recommandée :
Windows Server 2012 R2 et versions ultérieures
Windows Server 2012 et versions antérieures
Linux (SMB)
  • N/D
NAS (Network-attached storage)

Outils de copie de fichiers

Pour sélectionner l’outil le mieux adapté à votre scénario de migration, tenez compte de ces questions fondamentales :

  • L’outil prend-il en charge l’emplacement source et l’emplacement cible pour votre copie de fichier ?

  • L’outil prend-il en charge le chemin de votre réseau et/ou les protocoles disponibles (par exemple REST ou SMB) entre les emplacements de stockage source et cible ?

  • L’outil préserve-t-il la fidélité de fichier nécessaire prise en charge par vos emplacements sources/cibles ?

    Dans certains cas, votre stockage cible ne prend pas en charge le même niveau de fidélité que votre source. Si le stockage cible est suffisant pour répondre à vos besoins, l’outil doit correspondre uniquement aux fonctionnalités de fidélité de fichier de la cible.

  • L’outil dispose-t-il de fonctionnalités permettant de l’adapter à votre stratégie de migration ?

    Par exemple, déterminez si l’outil vous permet de réduire vos temps d’arrêt.

    Quand un outil prend en charge une option pour mettre en miroir une source sur une cible, vous pouvez souvent l’exécuter plusieurs fois sur la même source et la même cible, tandis que la source reste accessible.

    La première fois que vous exécutez l’outil, il copie le bloc de données. Cette exécution initiale peut prendre un certain temps. Vous trouvez souvent que la mise hors connexion de la source de données pour vos processus métier dure trop longtemps.

    En mettant en miroir une source sur une cible (comme avec robocopy /MIR), vous pouvez réexécuter l’outil sur la même source et la même cible. Cette deuxième exécution est beaucoup plus rapide, car seules les modifications de la source intervenues après l’exécution précédente doivent être transportées. Réexécuter un outil de copie de cette façon peut réduire considérablement les temps d’arrêt.

Le tableau suivant classe les outils Microsoft et leurs aptitudes actuelles pour les partages de fichiers SMB Azure :

Recommandé Outil Prise en charge des partages de fichiers Azure Préservation de la fidélité des fichiers
Oui, recommandé Azure Storage Mover Pris en charge. Fidélité totale.*
Oui, recommandé Azure Data Box Pris en charge. Fidélité totale.*
Oui, recommandé Robocopy Pris en charge. Les partages de fichiers Azure peuvent être montés comme lecteurs réseau. Fidélité totale.*
Oui, recommandé Azure File Sync Intégré en natif dans les partages de fichiers Azure. Fidélité totale.*
Oui, recommandé Programme de migration Stockage Azure Pris en charge. Fidélité totale.*
Oui, recommandé Service de migration de stockage Pris en charge de façon indirecte. Les partages de fichiers Azure peuvent être montés comme lecteurs réseau sur des serveurs cibles SMS. Fidélité totale.*
Oui, recommandé Data Box (y compris le service de copie de données pour charger des fichiers sur l’appareil) Pris en charge.
(Data Box Disks ne prend pas en charge les partages de fichiers volumineux)		 Data Box et Data Box Heavy prennent entièrement en charge les métadonnées.
Data Box Disks ne conserve pas les métadonnées de fichier.
Pas vraiment recommandé dernière version
d’AzCopy		 Pris en charge mais pas entièrement recommandé. La synchronisation AzCopy prend en charge jusqu’à 10 millions de fichiers par travail AzCopy et une fidélité de fichier peut être perdue, car AzCopy utilise les API REST Azure Files pour copier du contenu dans votre partage Azure Files.
Apprendre à utiliser AzCopy avec des partages de fichiers Azure
Pas vraiment recommandé dernière version
de l’Explorateur Stockage Azure		 Prise en charge mais non recommandée. La fidélité des fichiers est perdue en grande partie, par exemple les ACL. Prend en charge les timestamps.
Non recommandé Azure Data Factory. Pris en charge. Ne copie pas les métadonnées.

* Fidélité totale : respecte ou dépasse les capacités du partage de fichiers Azure.

Outils d’assistance à la migration

Cette section décrit les outils qui vous aident à planifier et à exécuter des migrations.

Azure Storage Mover

Azure Storage Mover est un service de migration relativement nouveau et entièrement managé qui vous permet de migrer des fichiers et des dossiers vers des partages de fichiers Azure SMB avec le même niveau de fidélité de fichier que le partage de fichiers Azure sous-jacent. Les valeurs de métadonnées et de structure de dossiers, telles que les horodatages de fichiers et de dossiers, les listes de contrôle d’accès et les attributs de fichier, sont conservées. Pour savoir comment utiliser Azure Storage Mover avec Azure Files, consultez Migrer vers des partages de fichiers Azure SMB à l’aide d’Azure Storage Mover.

Robocopy

Inclus dans Windows, RoboCopy est très utile pour les migrations de fichiers SMB. La documentation RoboCopy est une ressource utile pour les nombreuses options de cet outil.

Programme de migration du stockage Azure

Avant de choisir un service de stockage Azure et une stratégie de migration, vous devez d’abord avoir une bonne compréhension de vos données. Le programme de migration Stockage Azure propose différents outils capables d’analyser vos données et votre infrastructure de stockage et ainsi vous fournir des insights précieux. Ces outils peuvent vous aider à déterminer la taille et le type des données, le nombre de fichiers et de dossiers et les modèles d’accès. Ils offrent une vue centralisée de vos données et permettent la création de différents rapports personnalisés.

Ces informations peuvent vous aider à :

  • Identifier les jeux de données en double et redondants
  • Identifier les données plus froides qui peuvent être déplacées vers un stockage moins coûteux

Pour en savoir plus, consultez Matrice de comparaison pour les participants au programme de migration Stockage Azure.

TreeSize, de JAM Software GmbH

Azure File Sync est principalement mis à l’échelle avec le nombre d’éléments (fichiers et dossiers) et non avec la quantité totale de stockage. L’outil TreeSize vous permet de déterminer le nombre d’éléments sur vos volumes Windows Server.

Vous pouvez utiliser l’outil pour créer une perspective avant un déploiement Azure File Sync. Vous pouvez également l’utiliser lorsque la hiérarchisation dans le cloud est engagée après le déploiement. Dans ce scénario, vous voyez le nombre d’éléments et les répertoires qui utilisent le plus le cache de votre serveur.

La version testée de l’outil est la version 4.4.1. Elle est compatible avec les fichiers hiérarchisés dans le cloud. L’outil ne provoque pas le rappel des fichiers hiérarchisés pendant son fonctionnement normal.

Voir aussi

  • Last updated on