Considérations relatives au niveau de performance de NFS (Network File System) 3.0 dans Stockage Blob Azure

Le stockage Blob Azure prend désormais en charge le protocole NFS (Network File System) 3.0. Cet article contient des recommandations à appliquer pour optimiser le niveau de performance des demandes de stockage. Pour plus d’informations sur la prise en charge du protocole NFS 3.0 pour Stockage Blob Azure, consultez Prise en charge du protocole NFS (Network File System) 3.0 pour Stockage Blob Azure.

Ajout de clients pour augmenter le débit

Le Stockage Blob Azure évolue de façon linéaire jusqu’à la limite maximale de sortie et d’entrée du compte de stockage. Par conséquent, vos applications peuvent atteindre un débit plus élevé en utilisant plus de clients. Pour voir les limites d’entrée et de sortie des comptes de stockage, consultez Scalabilité et objectifs de niveau de performance des comptes de Stockage Standard.

Le graphe suivant montre comment la bande passante augmente lorsque d’autres clients sont ajoutés. Dans ce graphique, un client est une machine virtuelle (VM) et avec un compte de stockage v2 standard à usage général.

Niveau de performance Standard

Le graphique suivant montre le même effet lorsqu’il est appliqué à un compte de stockage d’objets blob de blocs Premium.

Niveau de performance Premium

Utiliser des comptes de stockage d’objets blob de blocs Premium pour des applications à petite échelle

Il n’est pas possible pour toutes les applications d’effectuer un scale-up en ajoutant des clients. Dans ce cas, le compte de stockage d’objets blob de blocs Azure Premium offre une faible latence et des taux de transaction élevés. Il peut atteindre une bande passante maximale avec moins de threads et de clients. Par exemple, avec un client unique, il peut enregistrer 2,3 fois plus de bande passante que la même configuration avec un compte de stockage universel v2 à niveau de performance standard.

Chaque barre du graphe ci-dessous montre la différence entre la bande passante obtenue pour les comptes de stockage de niveau de performance standard et Premium. Plus le nombre de clients augmente, plus cette différence diminue.

Niveau de performance relatif

Améliorer la taille de lecture anticipée pour augmenter le débit de lecture de fichiers volumineux

Le paramètre noyau read_ahead_kb représente la quantité de données supplémentaires qui doivent être lues après avoir satisfait à une demande de lecture donnée. Vous pouvez augmenter ce paramètre à 16 Mio pour améliorer le débit de lecture des fichiers volumineux.

export AZMNT=/your/container/mountpoint

echo 16384 > /sys/class/bdi/0:$(stat -c "%d" $AZMNT)/read_ahead_kb

Éviter les remplacements fréquents sur les données

Il faut plus de temps pour effectuer une opération de remplacement qu’une nouvelle opération d’écriture. En effet, une opération de remplacement NFS, en particulier une modification de fichier partielle sur place, est une combinaison de plusieurs opérations Blob sous-jacentes : une opération de lecture, une opération de modification et une opération d’écriture. Par conséquent, une application qui exige des modifications fréquentes sur place n’est pas adaptée aux comptes de Stockage Blob avec NFS.

Déployer Azure HPC Cache pour les applications sensibles à la latence

Certaines applications peuvent nécessiter une faible latence en plus d’un débit élevé. Vous pouvez déployer Azure HPC Cache pour améliorer considérablement la latence. En savoir plus sur la latence dans le stockage Blob.

Augmentez le nombre de connexions TCP

Vous pouvez utiliser l’option de montage nconnect pour obtenir des performances de lecture et d’écriture d’agrégation supérieures à partir d’une seule machine virtuelle, mais uniquement si votre noyau Linux prend en charge Azure nconnect.

nconnect est une option de montage Linux côté client qui vous permet d’utiliser plusieurs connexions TCP entre le client et le point de terminaison du service Blob. Vous pouvez utiliser l’option nconnect de la commande de montage pour spécifier le nombre de connexions TCP que vous souhaitez créer (par exemple : mount -t aznfs -o nconnect=16,sec=sys,vers=3,nolock,proto=tcp <storage-account-name>.blob.core.windows.net:/<storage-account-name>/<container-name> /nfsdatain).

Important

Bien que les dernières distributions Linux prennent entièrement en charge nconnect, vous devez utiliser cette option uniquement si votre noyau prend en charge Azure nconnect. L’utilisation de l’option de montage nconnect sans prise en charge d’Azure nconnect réduira le débit, provoquera plusieurs délais d’expiration et entraînera le fonctionnement incorrect des commandes telles que READDIR et READIRPLUS .

La prise en charge d’Azure nconnect est disponible avec la plupart des noyaux Ubuntu récents qui peuvent être utilisés avec des machines virtuelles Azure. Pour savoir si la prise en charge d’Azure nconnect est disponible pour votre noyau, exécutez la commande suivante.

[ -e /sys/module/sunrpc/parameters/enable_azure_nconnect ] && echo "Yes" || echo "No"

Si la prise en charge d’Azure nconnect est disponible pour votre noyau, alors Yes est affiché sur la console. Sinon, 'No est affiché sur la console.

Si la prise en charge d’Azure nconnect est disponible, activez-la en exécutant la commande suivante.

echo Y > /sys/module/sunrpc/parameters/enable_azure_nconnect

Autres recommandations

  • Utilisez des machines virtuelles dotées d’une bande passante réseau suffisante.

  • Utilisez plusieurs points de montage lorsque vos charges de travail l’autorisent.

  • Utilisez autant de threads que possible.

  • Utilisez de grandes tailles de bloc.

  • Effectuez des demandes de stockage à partir d’un client situé dans la même région que le compte de stockage, de façon à améliorer potentiellement le temps de réponse du réseau.

Étapes suivantes