Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
✔️ S’applique à : partages de fichiers NFS classiques créés avec le fournisseur de ressources Microsoft.Storage
✖️ Ne s’applique pas à : partages de fichiers NFS créés avec le fournisseur de ressources Microsoft.FileShares ou partages de fichiers SMB classiques créés avec le fournisseur de ressources Microsoft.Storage
Cet article traite des aspects fondamentaux de la migration de serveurs de fichiers Linux vers des partages de fichiers Azure NFS, qui sont disponibles uniquement en tant que partages de fichiers SSD (Premium). Il compare également les outils open source de copie de fichiers fpsync et rsync pour vous aider à comprendre leur comportement lors de la copie de données vers des partages de fichiers Azure.
Note
Azure Files ne prend pas en charge les listes de contrôle d’accès (ACL) NFS.
Prerequisites
Vous avez besoin d’au moins un partage de fichiers Azure NFS monté sur une machine virtuelle Linux (VM). Pour en créer un, consultez Créer un partage de fichiers Azure Classic. Montez le partage en utilisant nconnect pour utiliser plusieurs connexions TCP afin de meilleures performances. Pour plus d’informations, consultez Améliorer les performances du partage de fichiers Azure NFS.
Outils de migration
De nombreux outils sont disponibles pour transférer des données vers des partages de fichiers NFS. Toutefois, tous ne sont pas efficaces lorsqu’il s’agit d’un système de fichiers distribué avec des considérations distinctes en matière de performances par rapport aux configurations locales. Dans un système de fichiers distribué, chaque appel réseau implique un aller-retour vers un serveur qui peut ne pas être local. Par conséquent, l’optimisation du temps consacré aux appels réseau est essentielle pour obtenir des performances optimales et un transfert de données efficace sur le réseau.
Utiliser stockage Azure Mover
Vous pouvez maintenant utiliser stockage Azure Mover pour migrer vos partages de fichiers NFSv3 et NFSv4 vers des partages de fichiers Azure NFSv4.1. stockage Azure Mover est un service de migration entièrement managé qui vous permet de migrer des fichiers et dossiers locaux vers Azure tout en réduisant les temps d’arrêt.
Utilisation de fpsync et rsync
Bien qu’il soit monothread, rsync est un outil de copie de fichiers open source polyvalent. Il peut copier localement, vers/à partir d’un autre hôte sur n’importe quel interpréteur de commandes distant, ou vers/à partir d’un démon rsync distant. Il offre de nombreuses options et permet une spécification flexible de l’ensemble de fichiers à copier. Toutefois, fpsync est une application multithread et offre donc quelques avantages, notamment la possibilité d’exécuter des travaux rsync en parallèle.
Cet article explique comment utiliser fpsync pour transférer des données d’un serveur de fichiers Linux vers des partages de fichiers NFS Azure.
Pour copier les données, fpsync utilise les outils rsync (par défaut), cpio, ou tar. Il calcule les sous-ensembles du src_dir/ du répertoire source et génère des travaux de synchronisation pour les synchroniser avec le dst_dir/ du répertoire de destination. Il exécute des travaux de synchronisation à la volée tout en analysant le système de fichiers, ce qui en fait un outil utile pour migrer efficacement de grands systèmes de fichiers et copier de grands jeux de données contenant plusieurs fichiers.
Note
Fpsync synchronise uniquement le contenu du répertoire, et non le répertoire source lui-même. Contrairement à rsync, fpsync applique le dernier « / » sur le répertoire source, ce qui signifie que vous n’obtiendrez pas de sous-répertoire avec le nom du répertoire source dans le répertoire cible après la synchronisation.
Installer fpart
Pour utiliser fpsync, vous devez installer le partitionneur du système de fichiers fpart. Installez fpart sur la distribution Linux de votre choix. Après l’installation, fpsync apparaît sous /usr/bin/.
Sur Ubuntu, utilisez le gestionnaire de package apt pour installer fpart.
sudo apt-get install fpart
Copier des données de la source vers la destination
Vérifiez que votre partage de fichiers Azure de destination (cible) est monté sur une machine virtuelle Linux. Consultez les Conditions préalables.
Si vous effectuez une migration complète, vous allez copier vos données en trois phases :
- Copie de référence : copie de la source vers la destination lorsqu’aucune donnée n’existe sur la destination. Pour la copie de référence, nous vous recommandons d’utiliser fpsync avec cpio comme outil de copie.
-
Copie incrémentielle : copie uniquement les modifications incrémentielles de la source à la destination. Pour une synchronisation incrémentale, utilisez
fpsyncrsyncWITH comme outil de copiage. Exécutez cette commande plusieurs fois pour capturer tous les changements. - Passe finale : une passe finale est nécessaire pour supprimer les fichiers sur la destination qui n’existent pas à la source.
La copie de données avec fpsync implique toujours une version de cette commande :
fpsync -m <specify copy tool - rsync/cpio/tar> -n <parallel transfers> <absolute source path> <absolute destination path>
Copie de référence
Pour la copie de référence, utilisez fpsync avec cpio.
fpsync -m cpio -n <parallel transfers> <absolute source path> <absolute destination path>
Pour plus d’informations, consultez le Support Cpio et Tar.
Copie incrémentielle
Pour la synchronisation incrémentale, utilisez fpsync l’outil de copie par défaut (rsync). Exécutez cette commande plusieurs fois pour capturer tous les changements.
fpsync -n <parallel transfers> <absolute source path> <absolute destination path>
Par défaut, fpsync spécifie les options suivantes rsync : -lptgoD -v --numeric-ids. Ajoutez -o option à la fpsync commande pour spécifier des options supplémentaires rsync .
Passe finale
Après plusieurs synchronisations incrémentielles, vous devez effectuer une passe finale pour supprimer les fichiers sur cette destination qui n’existent pas à la source. Vous pouvez effectuer cette opération manuellement avec rsync --delete pour supprimer des fichiers supplémentaires du répertoire /data/dst/, ou utiliser fpsync avec l’option -E. Pour plus d’informations, consultez La passe finale.
Comparaison de rsync et fpsync avec différents jeux de données
Cette section compare les performances de rsync et fpsync avec différents jeux de données.
Jeux de données et configuration
Le tableau suivant liste les différents ensembles de données utilisés pour comparer la performance des outils de copie sous différentes charges de travail.
| Config # | Type de copie | Nombre de fichiers | Nombre de répertoires | Taille du fichier | Taille totale |
|---|---|---|---|---|---|
| 1.1 | Copie de référence | 1 million | 1 | 0-32 Kio | 18 Gio |
| 1.2 | Incrémentielle (modification différentielle) | 1 million | 1 | 0-32 Kio | 18 Gio |
| 2 | Copie de référence | 191 345 | 3906 | 0-32 Kio | 3 Gio |
| 3 | Copie de référence | 5 000 | 1 | 10 Mio | 50 Gio |
Les tests ont été effectués sur des machines virtuelles Azure Standard_D8s_v3 avec 8 processeurs virtuels, 32 Gio de mémoire et plus de 1 Tio d’espace disque pour les jeux de données volumineux. Pour la cible, nous avons configuré des partages de fichiers Azure NFS avec une taille provisionnée de plus de 1 Tio.
Expériences et résultats : rsync et fpsync
Les tests montrent que fpsync fonctionne mieux lorsque vous utilisez 64 threads avec rsync et 16 threads avec cpio pour un partage de fichiers NFS Azure monté avec nconnect=8. Les résultats réels varient selon votre configuration et vos ensembles de données.
Note
Le débit pour Azure Files peut être beaucoup plus élevé que représenté dans les graphiques suivants. Certaines expériences ont été délibérément menées avec de petits jeux de données par souci de simplicité.
Configuration 1
Pour un répertoire unique avec 1 million de petits fichiers totalisant 18 Gio, nous avons exécuté ce test à la fois comme copie de référence et copie incrémentielle.
Le graphique suivant montre les résultats d’une copie de référence de la source à la destination.
Le graphique suivant montre les résultats d’une copie incrémentale (changement delta).
« Configuration 2 »
Le graphique suivant montre les résultats d’une copie de référence de 191 345 petits fichiers dans 3 906 annuaires, d’une taille totale de 3 Gio.
Configuration 3
Le graphique suivant montre les résultats d’une copie de référence de 5 000 gros fichiers (10 Mio) dans un seul répertoire d’une taille totale de 50 Gio.
Résumé des résultats
L’utilisation d’applications multithread comme fpsync peut améliorer le débit et les IOPS lors de la migration vers des partages de fichiers Azure NFS par rapport aux outils de copie monothread comme rsync. Nos tests montrent que :
- La distribution de données dans le répertoire permet de paralléliser le processus de migration et d’obtenir ainsi de meilleures performances.
- La copie de données à partir de fichiers de plus grande taille est plus performante que la copie de données à partir de fichiers de plus petite taille.
Le tableau suivant récapitule les résultats :
| Config # | Nombre de fichiers | Nombre de répertoires | Taille du fichier | Taille totale | durée rsync | débit rsync | durée fpsync | débit fpsync | Gain de débit |
|---|---|---|---|---|---|---|---|---|---|
| 1.1 (référence) | 1 million | 1 | 0-32 Kio | 18 Gio | 837,06 minutes | 0,33 Mio/s | 228,16 minutes | 1,20 Mio/s | 267 % |
| 1,2 (incrémentiel) | 1 million | 1 | 0-32 Kio | 18 Gio | 84,02 minutes | 3,25 Mio/s | 7,5 minutes | 36,41 Mio/s | 1020 % |
| 2 (référence) | 191 345 | 3906 | 0-32 Kio | 3 Gio | 191,86 minutes | 0,27 Mio/s | 8,47 min | 6,04 Mio/s | 2164 % |
| 3 (référence) | 5 000 | 1 | 10 Mio | 50 Gio | 8,12 minutes | 105,04 Mio/s | 2,76 minutes | 308,90 Mio/s | 194 % |
Exclusion d’informations tierces
Les outils open source mentionnés dans cet article sont des solutions tierces connues. Microsoft ne développe, ne possède pas et ne prend pas en charge ces outils, ni directement ni indirectement. Vous êtes responsable d’examiner la licence logicielle et la mention de support fournies dans la documentation du tiers.