Améliorer les performances des partages de fichiers Azure NFS

Cet article explique comment améliorer les performances des partages de fichiers Azure NFS (Network File System).

S’applique à

Modèle de gestion	Modèle de facturation	Échelon médiatique	Redondance	PME	Système de fichiers en réseau (NFS)
Microsoft.Storage	V2 approvisionné	SSD (Premium)	Local (LRS)
Microsoft.Storage	V2 approvisionné	SSD (Premium)	Zone (ZRS)
Microsoft.Storage	V2 approvisionné	HDD (standard)	Local (LRS)
Microsoft.Storage	V2 approvisionné	HDD (standard)	Zone (ZRS)
Microsoft.Storage	V2 approvisionné	HDD (standard)	Géo (GRS)
Microsoft.Storage	V2 approvisionné	HDD (standard)	GeoZone (GZRS)
Microsoft.Storage	V1 approvisionné	SSD (Premium)	Local (LRS)
Microsoft.Storage	V1 approvisionné	SSD (Premium)	Zone (ZRS)
Microsoft.Storage	Paiement à l’utilisation	HDD (standard)	Local (LRS)
Microsoft.Storage	Paiement à l’utilisation	HDD (standard)	Zone (ZRS)
Microsoft.Storage	Paiement à l’utilisation	HDD (standard)	Géo (GRS)
Microsoft.Storage	Paiement à l’utilisation	HDD (standard)	GeoZone (GZRS)

Augmenter la taille de lecture anticipée pour améliorer le débit de lecture

Le paramètre de noyau read_ahead_kb dans Linux représente la quantité de données qui doit être « lue en avance » ou prérécupérée lors d’une opération de lecture séquentielle. Les versions du noyau Linux antérieures à la version 5.4 définissent la valeur de lecture anticipée sur l’équivalent de 15 fois le rsize du système de fichiers monté, ce qui représente l’option de montage côté client pour la taille de mémoire tampon de lecture. Cette valeur est suffisamment élevée pour améliorer le débit de lecture séquentielle du client dans la plupart des cas.

Toutefois, à compter de la version 5.4 du noyau Linux, le client NFS Linux utilise une valeur read_ahead_kb par défaut de 128 Kio. Cette petite valeur peut réduire la quantité de débit de lecture pour les fichiers volumineux. Les clients effectuant une mise à niveau à partir de mises en production de Linux avec la plus grande valeur de lecture anticipée vers celles avec la valeur par défaut de 128 Kio peuvent observer une diminution des performances de lecture séquentielle.

Pour les noyaux Linux 5.4 ou ultérieur, nous vous recommandons de définir de façon permanente read_ahead_kb sur 15 Mio pour améliorer les performances.

Pour modifier cette valeur, définissez la taille de lecture anticipée en ajoutant une règle dans udev, un gestionnaire d’appareils de noyau Linux. Procédez comme suit :

1. Dans un éditeur de texte, créez le fichier /etc/udev/rules.d/99-nfs.rules en entrant et en enregistrant le texte suivant :

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. Dans une console, appliquez la règle udev en exécutant la commande udevadm en tant que superutilisateur et en rechargeant les fichiers de règles et d’autres bases de données. Vous n’avez besoin d’exécuter cette commande qu’une seule fois pour qu’udev prenne en compte le nouveau fichier.

   sudo udevadm control --reload
   

NFS nconnect

NFS nconnect est une option de montage côté client pour les partages de fichiers NFS qui vous permet d’utiliser plusieurs connexions TCP entre le client et votre partage de fichiers NFS.

Avantages

Avec nconnect, vous pouvez augmenter les performances à grande échelle à l’aide de moins de machines clientes pour réduire le coût total de possession (TCO). La fonctionnalité nconnect augmente les performances à l’aide de plusieurs canaux TCP sur une ou plusieurs cartes réseau, à l’aide d’un ou plusieurs clients. Sans nconnect, vous avez besoin d’environ 20 ordinateurs clients pour atteindre les limites d’échelle de bande passante (10 Gio/s) offertes par la plus grande taille d’approvisionnement de partage de fichiers SSD. Avec nconnect, vous pouvez atteindre ces limites en utilisant seulement 6 à 7 clients, ce qui réduit les coûts de calcul de près de 70 % tout en fournissant des améliorations significatives des opérations d’E/S par seconde (IOPS) et du débit à grande échelle. Consultez le tableau suivant.

Métrique (opération)	Taille des E/S	Amélioration des performances
IOPS (écriture)	64 Kio, 1 024 Kio	3x
IOPS (lecture)	Toutes les tailles d’E/S	2 à 4 fois
Débit (écriture)	64 Kio, 1 024 Kio	3x
Débit (lecture)	Toutes les tailles d’E/S	2 à 4 fois

Prérequis

• Les dernières distributions Linux prennent entièrement en charge nconnect. Pour les distributions Linux plus anciennes, assurez-vous que la version du noyau Linux est 5.3 ou ultérieure.
• La configuration par montage n’est prise en charge que lorsqu’un partage de fichiers unique est utilisé par compte de stockage sur un point de terminaison privé.

Impact sur les performances

Nous avons obtenu les résultats de performances suivants lors de l’utilisation de l’option de montage nconnect avec des partages de fichiers Azure NFS sur les clients Linux à grande échelle. Pour plus d’informations sur la façon dont nous avons obtenu ces résultats, consultez Configuration des tests de performances.

Recommandations

Suivez ces recommandations pour obtenir les meilleurs résultats de nconnect.

Définissez nconnect=4

Bien qu’Azure Files prenne en charge la définition de nconnect jusqu’au paramètre maximal de 16, nous vous recommandons de configurer les options de montage avec le paramètre optimal de nconnect=4. Actuellement, il n’y a pas de gains au-delà de quatre canaux pour l’utilisation de nconnect dans l’implémentation d'Azure Files. En fait, le dépassement de quatre canaux vers un seul partage de fichiers Azure à partir d’un seul client peut nuire aux performances en raison de la saturation du réseau TCP.

Dimensionner les machines virtuelles avec soin

En fonction des besoins de votre charge de travail, il est important de dimensionner correctement les machines virtuelles clientes pour éviter d’être limitées par leur bande passante réseau attendue. Vous n’avez pas besoin de plusieurs cartes réseau pour atteindre le débit réseau attendu. Bien qu’il soit courant d’utiliser des machines virtuelles à usage général avec Azure Files, différents types de machines virtuelles sont disponibles en fonction des besoins de votre charge de travail et de la disponibilité de votre région. Pour plus d’informations, consultez Sélecteur de machine virtuelle Azure.

Conserver une profondeur de file d’attente inférieure ou égale à 64

La profondeur de file d’attente correspond au nombre de requêtes d’E/S en attente qu’une ressource de stockage peut traiter. Nous vous déconseillons de dépasser la profondeur de file d’attente optimale de 64, car vous ne constaterez plus de gains de performances. Pour plus d’informations, consultez Profondeur de file d’attente.

Configuration par montage

Si une charge de travail nécessite le montage de plusieurs partages avec un ou plusieurs comptes de stockage avec des paramètres nconnect différents d’un seul client, nous ne pouvons pas garantir que ces paramètres persistent lors du montage sur le point de terminaison public. La configuration par montage est prise en charge uniquement lorsqu’un partage de fichiers Azure unique est utilisé par compte de stockage sur le point de terminaison privé, comme décrit dans le scénario 1.

Scénario 1 : configuration par montage sur un point de terminaison privé avec plusieurs comptes de stockage (prise en charge)

• StorageAccount.file.core.windows.net = 10.10.10.10
• StorageAccount2.file.core.windows.net = 10.10.10.11
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Scénario 2 : configuration par montage sur un point de terminaison public (non prise en charge)

• StorageAccount.file.core.windows.net = 52.239.238.8
• StorageAccount2.file.core.windows.net = 52.239.238.7
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Remarque

Même si le compte de stockage se résout en une autre adresse IP, nous ne pouvons pas garantir la persistance de cette adresse, car les points de terminaison publics ne sont pas des adresses statiques.

Scénario 3 : configuration par montage sur un point de terminaison privé avec plusieurs partages sur un seul compte de stockage (non prise en charge)

• StorageAccount.file.core.windows.net = 10.10.10.10
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

Configuration des performances test

Nous avons utilisé les ressources et les outils d’évaluation suivants pour atteindre et mesurer les résultats décrits dans cet article.

• Client unique : machine virtuelle Azure (série DSv4) avec une seule carte réseau
• OS : Linux (Ubuntu 20.40)
• Stockage NFS : partage de fichiers SSD (30 Tio approvisionnés, nconnect=4 défini)

Taille	Processeur virtuel	Mémoire	Stockage temporaire (SSD)	Disques de données max	Cartes réseau maximales	Bande passante réseau attendue
Standard_D16_v4	16	64 Gio	Stockage distant uniquement	32	8	12 500 Mbits/s

Outils et tests d’évaluation

Nous avons utiliser Flexible I/O Tester (FIO), un outil d'E/S de disque gratuit et open source utilisé à la fois pour l'évaluation et la vérification des contraintes et du matériel. Pour installer FIO, consultez la section relative aux packages binaires dans le fichier README de FIO pour installer l’outil sur la plateforme de votre choix.

Bien que ces tests se concentrent sur les modèles d’accès aux E/S aléatoires, vous obtenez des résultats similaires lors de l’utilisation d’E/S séquentielles.

IOPS élevées : 100 % de lectures

Taille d’E/S de 4 000 – lecture aléatoire – profondeur de file d’attente de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Taille d’E/S de 8 000 – lecture aléatoire – profondeur de file d’attente de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Débit élevé : 100 % de lectures

Taille d’E/S de 64 Kio – lecture aléatoire – profondeur de file d’attente de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Taille d’E/S de 1 024 Kio – lecture aléatoire à 100 % – profondeur de file d’attente de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

IOPS élevées : 100 % d’écritures

Taille d’E/S de 4 Kio – écriture aléatoire à 100 % – profondeur de file d’attente de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Taille d’E/S de 8 Kio – écriture aléatoire à 100 % – profondeur de file d’attente de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Débit élevé : 100 % d’écritures

Taille d’E/S de 64 KiB - 100% écriture aléatoire - profondeur de file d’attente de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Taille d’E/S de 1 024 – écriture aléatoire à 100 % – profondeur de file d’attente de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Considérations relatives aux performances pour nconnect

Lorsque vous utilisez l’option de montage nconnect, vous devez évaluer étroitement les charges de travail qui ont les caractéristiques suivantes :

• Charges de travail d’écriture sensibles à la latence qui sont à thread unique et/ou utilisent une faible profondeur de file d’attente (inférieure à 16)
• Charges de travail de lecture sensibles à la latence qui sont à thread unique et/ou utilisent une faible profondeur de file d’attente en combinaison avec des tailles d’E/S plus petites

Toutes les charges de travail ne nécessitent pas d’IOPS à grande échelle ou tout au long des performances. Pour les charges de travail à plus petite échelle, nconnect peut ne pas avoir de sens. Utilisez le tableau suivant pour déterminer si nconnect est avantageux pour votre charge de travail. Les scénarios indiqués en vert sont recommandés, tandis que ceux en rouge ne le sont pas. Les scénario marqués en jaune sont neutres.

Voir aussi

• Monter un partage de fichiers NFS sur Linux
• Liste des options de montage
• Comprendre les performances d’Azure Files