Migrer vers des partages de fichiers Azure NFS
Cet article traite des aspects de base de la migration à partir de serveurs de fichiers Linux vers des partages de fichiers Azure NFS, qui sont uniquement disponibles en tant que partages de fichiers Premium (type de compte FileStorage). Nous allons également comparer les outils de copie de fichiers open source fpsync et rsync pour comprendre comment ils fonctionnent lors de la copie de données dans des partages de fichiers Azure.
Remarque
Azure Files ne prend pas en charge les listes de contrôle d’accès (ACL) NFS.
S’applique à
| Type de partage de fichiers | SMB | NFS |
|---|---|---|
| Partages de fichiers Standard (GPv2), LRS/ZRS |  |
|
| Partages de fichiers Standard (GPv2), GRS/GZRS | |
|
| Partages de fichiers Premium (FileStorage), LRS/ZRS | |
 |
Prérequis
Vous aurez besoin d’au moins un partage de fichiers Azure NFS monté sur une machine virtuelle Linux. Pour en créer un, consultez Créer un partage de fichiers Azure NFS et le monter sur une machine virtuelle Linux. Nous vous recommandons de monter le partage avec nconnect pour utiliser plusieurs connexions TCP. Pour plus d’informations, consultez l’article Améliorer les performances du partage de fichiers Azure NFS.
Outils de migration
De nombreux outils open source 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.
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.
Dans cet article, nous allons utiliser fpsync pour déplacer des données d’un serveur de fichiers Linux vers des partages de fichiers Azure NFS.
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.
Remarque
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 de système de fichiers fpart. Installez fpart sur la distribution Linux de votre choix. Une fois qu’il est installé, vous devriez voir fpsync 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 la synchronisation incrémentielle, nous vous recommandons d’utiliser fpsync avec rsync comme outil de copie. Cette opération doit être effectuée plusieurs fois pour capturer toutes les modifications.
- 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émentielle, utilisez fpsync avec l’outil de copie par défaut (rsync). Pour capturer toutes les modifications, nous vous recommandons d’exécuter cette opération plusieurs fois.
fpsync -n <parallel transfers> <absolute source path> <absolute destination path>
Par défaut, fpsync spécifie les options rsync suivantes : -lptgoD -v --numeric-ids. Vous pouvez spécifier des options rsync supplémentaires en ajoutant -o option à la commande fpsync.
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 répertorie les différents jeux de données que nous avons utilisés pour comparer les performances 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 GiB |
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
Sur la base de nos expériences avec les configurations ci-dessus, nous avons observé que fpsync était le plus performant lorsqu’il était utilisé avec 64 threads avec rsync et 16 threads avec cpio pour un partage de fichiers Azure NFS monté avec nconnect=8. Les résultats réels varient en fonction de votre configuration et de vos jeux de données.
Remarque
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.
Nous avons observé les résultats suivants en effectuant une copie de référence de la source vers la destination.
Nous avons observé les résultats suivants en effectuant une copie incrémentielle (modification différentielle).
« Configuration 2 »
Nous avons observé les résultats suivants en effectuant une copie de référence de 191 345 petits fichiers dans 3906 répertoires avec une taille totale de 3 Gio.
Configuration 3
Nous avons observé les résultats suivants en effectuant une copie de référence de 5000 fichiers volumineux (10 Mio) dans un répertoire unique avec 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 GiB | 8,12 minutes | 105,04 Mio/s | 2,76 minutes | 308,90 Mio/s | 194 % |
Exclusion de responsabilité de tiers
Les outils open source mentionnés dans cet article sont des solutions tierces connues. Ils ne sont pas développés, détenus ou pris en charge par Microsoft, directement ou indirectement. Il incombe au client d’examiner la licence du logiciel et la déclaration de support fournies dans la documentation du tiers.