Améliorer les performances des partages de fichiers Azure NFS

S’applique à : ✔️ partages de fichiers NFS

Cet article propose différentes façons d’améliorer les performances des partages de fichiers Azure du système de fichiers réseau (NFS). Les sujets abordés incluent la configuration du paramètre du noyau Linux read_ahead_kb pour un meilleur débit de lecture séquentielle, l’utilisation de l’option nconnect de montage pour faire évoluer le débit avec moins de machines clientes, et le placement de votre compte de stockage dans la même zone de disponibilité que vos clients pour réduire la latence.

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 valeur plus faible pourrait réduire le débit de lecture pour les gros fichiers. Les utilisateurs passant de versions Linux avec une valeur de lecture anticipée plus élevée vers des versions avec la valeur par défaut de 128 KiB pourraient constater une baisse des performances de lecture séquentielle.

Pour les noyaux Linux 5.4 ou version ultérieure, définissez durablement la valeur de read_ahead_kb à 15 MiB 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. Il suffit d’exécuter cette commande une seule fois pour que udev soit informé du nouveau fichier.

   sudo udevadm control --reload
   

NFS nconnect

NFS nconnect est une option de montage côté client pour les partages de fichiers NFS que vous utilisez pour créer plusieurs connexions TCP entre le client et votre partage de fichiers NFS. Il est particulièrement utile pour les charges de travail à grande échelle où une seule connexion TCP devient un goulot d’étranglement.

Avantages de nconnect

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, il vous faut environ 20 machines clientes pour atteindre les limites d’échelle de bande passante (10 GiBo/s) offertes par la plus grande taille de provisionnement 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.

Prérequis de nconnect

• 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

Les résultats de performance suivants ont été mesurés en utilisant l’option de montage nconnect avec des partages de fichiers NFS Azure sur des clients Linux à grande échelle. Pour plus d’informations sur la manière dont ces résultats ont été obtenus, voir configuration des tests de performance.

Recommandations de nconnect

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

Définissez nconnect=4

Bien que Azure Files supporte de configurer nconnect jusqu’au réglage maximum de 16, configurez les options de montage avec le réglage optimal 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 de monter plusieurs partages avec un ou plusieurs comptes de stockage avec différents paramètres nconnect à partir d’un seul client, ces paramètres ne sont pas garantis de persister lors du montage sur le point public. La configuration par montage ne prend en charge qu’un seul partage de fichiers Azure 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

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

Pour atteindre et mesurer les résultats présentés dans cet article, utilisez les ressources et outils de benchmarking suivants.

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

Outils et tests d’évaluation

Ces tests utilisent le Flexible I/O Tester (FIO), un outil d’E/S disque gratuit et open source, utilisé à la fois pour le benchmarking et la vérification du stress ou matériel. Pour installer FIO, consultez la section Paquets binaires dans le fichier FIO README et suivez les instructions de la plateforme que vous choisissez.

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 de IOPS à grande échelle ou des performances en débit. Pour des charges de travail plus petites, nconnect cela peut ne pas être bénéfique. 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.

Utiliser le placement zonal

Pour les partages de fichiers classiques créés avec le fournisseur de ressources Microsoft.Storage, nous vous recommandons d’utiliser le placement zonal pour sélectionner la zone de disponibilité spécifique dans laquelle réside votre compte de stockage. Cela vous permet de placer vos machines virtuelles dans la même zone de disponibilité que votre stockage, ce qui peut réduire la latence jusqu’à 30 %. Cette fonctionnalité est actuellement disponible uniquement pour les comptes de stockage SSD à l’aide du stockage localement redondant (LRS) dans les régions prises en charge.

Voir aussi

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