Partager via

Améliorer les performances des partages de fichiers Azure NFS

  • Article

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

S’applique à

Type de partage de fichiers SMB NFS
Partages de fichiers Standard (GPv2), LRS/ZRS Non, cet article ne s’applique pas aux partages de fichiers Azure SMB standard LRS/ZRS. Les partages NFS sont uniquement disponibles dans les partages de fichiers Azure Premium.
Partages de fichiers Standard (GPv2), GRS/GZRS Non, cet article ne s’applique pas aux partages de fichiers Azure SMB standard GRS/GZRS. NFS est disponible uniquement dans les partages de fichiers Azure Premium.
Partages de fichiers Premium (FileStorage), LRS/ZRS Non, cet article ne s’applique pas aux partages de fichiers Azure SMB Premium. Oui, cet article s’applique aux partages de fichiers Azure NFS Premium.

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 la 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. Suivez ces étapes :

  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

Nconnect

Nconnect est une option de montage Linux côté client qui accroît les performances à grande échelle en vous permettant d’utiliser davantage de connexions TCP (Transmission Control Protocol) entre le client et le service Fichiers Azure Premium pour NFSv4.1.

Avantages de l'nconnect

Avec nconnect, vous pouvez augmenter les performances à grande échelle en utilisant moins de machines clientes pour réduire le coût total de possession (TCO). Nconnect améliore les performances en utilisant plusieurs canaux TCP sur une ou plusieurs cartes réseau, à l’aide de clients uniques ou multiples. Sans nconnect, vous auriez besoin d’environ 20 machines clientes pour atteindre les limites de mise à l’échelle de la bande passante (10 Gio/s) offertes par la plus grande taille d’approvisionnement de partage de fichiers Azure Premium. Avec nconnect, vous pouvez atteindre ces limites en utilisant seulement six à sept clients, réduisant 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 Ko, 1 024 Ko 3x
IOPS (lecture) Toutes les tailles d’E/S 2-4x
Débit (écriture) 64 Ko, 1 024 Ko 3x
Débit (lecture) Toutes les tailles d’E/S 2-4x

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 de nconnect

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 des 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.

Capture d’écran montrant l’amélioration moyenne des E/S par seconde lors de l’utilisation de nconnect avec des partages de fichiers Azure NFS.

Capture d’écran montrant l’amélioration moyenne du débit lors de l’utilisation de nconnect avec des partages de fichiers Azure NFS.

Recommandations pour nconnect

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’à la valeur maximale de 16, nous vous recommandons de configurer les options de montage avec le paramètre optimal de nconnect=4. Actuellement, il n’y a aucun gain au-delà de quatre canaux pour l’implémentation Azure Files de nconnect. 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 qu’elles soient limitées par la 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 de Nconnect 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 à partir d’un seul client, nous ne pouvons pas garantir que ces paramètres persisteront lors du montage sur le point de terminaison public. La configuration par montage n’est prise en charge que lorsqu’un seul partage de fichiers Azure 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 nconnect 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 nconnect 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 est résolu 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 nconnect 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 Premium Azure Files (provisionné de 30 Tio, nconnect=4 défini)
Taille Processeurs virtuels Mémoire Stockage temporaire (SSD) Disques de données max. Nombre max de cartes réseau Bande passante du 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ée : 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 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=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Taille d’E/S de 1 024 000 – 100 % lecture aléatoire – 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ée : 100 % d’écritures

Taille d’E/S de 4 000 – 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=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Taille d’E/S de 8 000 – 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=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

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

Taille d’E/S de 64 000 – 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 000 – 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=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.

Capture d’écran montrant différents scénarios d’E/S de lecture et d’écriture avec une latence correspondante pour indiquer quand nconnect est recommandé.

Voir aussi