Partager via

Considérations relatives aux performances du système de fichiers réseau (NFS) 3.0 dans le 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 qui vous aident à optimiser les performances de vos demandes de stockage. Pour en savoir plus sur la prise en charge de NFS 3.0 pour le stockage Blob Azure, consultez la prise en charge du protocole NFS (Network File System) 3.0 pour le stockage Blob Azure.

Ajouter des 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 obtenir un débit plus élevé en utilisant davantage de clients. Pour afficher les limites de sortie et d’entrée du compte de stockage, consultez les cibles d’extensibilité et de performances pour les comptes de stockage standard.

Le graphique suivant montre comment la bande passante augmente à mesure que vous ajoutez d’autres clients. Dans ce graphique, un client est une machine virtuelle et avec un compte de stockage v2 standard.

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

Toutes les applications ne peuvent pas être mises à l’échelle en ajoutant d’autres 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 graphique suivant montre la différence de bande passante obtenue entre les comptes de stockage premium et de performances standard. À mesure que le nombre de clients augmente, 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 de noyau read_ahead_kb représente la quantité de données supplémentaires qui doivent être lues après avoir rempli une demande de lecture donnée. Vous pouvez augmenter ce paramètre à 16 Mio pour améliorer le débit de lecture de 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 terminer 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.

Augmenter le nombre de connexions TCP

Vous pouvez utiliser l’option de nconnect montage 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 dans 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 a la prise en charge d’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 en matière de bonnes pratiques

  • Utilisez des machines virtuelles avec 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 blocs.

  • Effectuez des demandes de stockage à partir d’un client situé dans la même région que le compte de stockage. Cela peut améliorer la latence du réseau.

Étapes suivantes