Améliorer les performances du partage de fichiers Azure SMB

Cet article explique comment améliorer les performances des partages de fichiers premium Azure SMB, notamment en utilisant SMB Multichannel et la mise en cache de métadonnées (préversion).

S’applique à

Type de partage de fichiers SMB NFS
Partages de fichiers Standard (GPv2), LRS/ZRS No No
Partages de fichiers Standard (GPv2), GRS/GZRS No No
Partages de fichiers Premium (FileStorage), LRS/ZRS Yes No

Optimisation des performances

Les conseils suivants peuvent vous aider à optimiser les performances :

  • Assurez-vous que votre compte de stockage et votre client sont colocalisés dans la même région Azure pour réduire la latence réseau.
  • Utilisez des applications multithread et répartissez la charge sur plusieurs fichiers.
  • Les avantages en matière de performances de SMB Multichannel augmentent avec le nombre de fichiers distribuant la charge.
  • Les performances du partage Premium sont liées à la taille du partage approvisionné (IOPS/sortie/entrée) et les limites de fichiers uniques. Pour plus d’informations, consultez Comprendre le provisionnement des partages de fichiers Premium.
  • Les performances maximales d’un seul client de machine virtuelle sont toujours liées aux limites des machines virtuelles. Par exemple, Standard_D32s_v3 peut prendre en charge une bande passante maximale de 16 000 Mbits/s (ou 2 Gbits/s), les sorties de la machine virtuelle (écritures vers le stockage) sont limitées, contrairement aux entrées (lectures depuis le stockage). Les performances des partages de fichiers sont soumises aux limites du réseau des machines, aux UC, à la bande passante réseau disponible du stockage interne, aux tailles d’e/s, au parallélisme, ainsi qu’à de nombreux autres facteurs.
  • Le test initial est généralement un échauffement. Ignorez les résultats et répétez le test.
  • Si les performances sont limitées par un seul client et que la charge de travail reste inférieure aux limites de partage provisionnées, vous pouvez obtenir des performances plus élevées en répartissant la charge sur plusieurs clients.

Relation entre les IOPS, le débit et les tailles d’E/S

Débit = Taille d’e/s * IOPS

Les tailles d’e/s supérieures améliorent le débit et entraînent des latences plus élevées, ce qui réduit le nombre d’IOPS. Des tailles d’E/S plus petites augmentent les IOPS, mais entraînent une diminution du débit net et des latences. Pour plus d’informations, consultez Comprendre les performances d’Azure Files.

SMB Multichannel

SMB Multichannel permet à un client SMB 3.x d’établir plusieurs connexions réseau à un partage de fichiers SMB. Azure Files prend en charge SMB Multichannel sur des partages de fichiers Premium (partages de fichiers dans le type de compte de stockage FileStorage) pour les clients Windows. Du côté service, le protocole SMB Multichannel est désactivé par défaut dans Azure Files, mais son activation n’entraîne aucun coût supplémentaire.

Avantages

SMB Multichannel permet aux clients d’utiliser plusieurs connexions réseau qui améliorent les performances tout en réduisant le coût de possession. L’agrégation de bande passante sur plusieurs cartes réseau et l’utilisation de la prise en charge de la mise à l’échelle côté réception (RSS) pour distribuer la charge d’E/S sur plusieurs processeurs permet d’améliorer les performances.

  • Débit accru : plusieurs connexions permettent le transfert de données sur plusieurs chemins d’accès en parallèle et, par conséquent, sont considérablement utiles aux charges de travail qui utilisent des fichiers de plus grande taille avec des tailles d’E/S plus élevées et qui nécessitent un débit élevé à partir d’une seule machine virtuelle ou d’un plus petit groupe de machines virtuelles. Certaines de ces charges de travail incluent des supports multimédia et de divertissement pour la création ou le transcodage de contenu, la génomique et l’analyse des risques de services financiers.
  • IOPS le plus élevé : La fonctionnalité RSS de la carte réseau permet une distribution efficace de la charge sur plusieurs UC avec plusieurs connexions. Cela permet d’obtenir une mise à l’échelle des IOPS et une utilisation efficace des UC de machines virtuelles. Cela est utile pour les charges de travail qui ont de petites tailles d’E/S, telles que les applications de base de données.
  • Tolérance de panne réseau : Les connexions multiples atténuent le risque d’interruption puisque les clients ne s’appuient plus sur une connexion individuelle.
  • Configuration automatique : Lorsque SMB Multichannel est activé sur les clients et les comptes de stockage, il permet la découverte dynamique de connexions existantes et peut créer des chemins de connexion supplémentaires si nécessaire.
  • Optimisation des coûts : Les charges de travail peuvent obtenir une mise à l’échelle supérieure à partir d’une machine virtuelle unique ou d’un petit ensemble de machines virtuelles, tout en se connectant à des partages Premium. Cela peut réduire le coût total de possession en réduisant le nombre de machines virtuelles nécessaires à l’exécution et à la gestion d’une charge de travail.

Pour en savoir plus sur SMB Multichannel, reportez-vous à la documentation de Windows.

Cette fonctionnalité offre de meilleures performances pour les applications multithread, mais elle n’aide généralement pas les applications à thread unique. Consultez la section Comparaison des performances pour plus de détails.

Limites

SMB Multichannel pour les partages de fichiers Azure présente actuellement les restrictions suivantes :

  • Pris en charge uniquement sur les clients Windows qui utilisent le protocole SMB 3.1.1. Vérifiez que les systèmes d’exploitation clients SMB sont corrigés aux niveaux recommandés.
  • Actuellement non pris en charge ou non recommandé pour les clients Linux.
  • Le nombre maximal de canaux est de quatre. Pour plus d’informations consultez ce lien.

Configuration

SMB Multichannel fonctionne uniquement lorsque la fonctionnalité est activée côté client (votre client) et côté service (votre compte de stockage Azure).

Sur les clients Azure, SMB Multichannel est activé par défaut. Vous pouvez vérifier votre configuration en exécutant la commande PowerShell suivante :

Get-SmbClientConfiguration | Select-Object -Property EnableMultichannel

Sur votre compte de stockage Azure, vous devez activer le protocole SMB Multichannel. Consultez Réactiver SMB Multichannel.

Désactiver SMB Multichannel

Dans la plupart des scénarios, en particulier les charges de travail multithread, les clients doivent obtenir des performances améliorées avec SMB Multichannel. Toutefois, pour certains scénarios spécifiques tels que les charges de travail à thread unique ou à des fins de test, vous pouvez désactiver le protocole SMB Multichannel. Consultez la section Comparaison des performances pour plus de détails.

Vérifier que SMB Multichannel est configuré correctement

  1. Créez un partage de fichiers Premium ou utilisez-en un partage Premium existant.
  2. Vérifiez que votre client prend en charge SMB Multichannel (une ou plusieurs cartes réseau ont une mise à l’échelle côté réception activée). Pour plus d’informations, consultez la documentation Windows.
  3. Montez un partage de fichiers sur votre client.
  4. Générez une charge avec votre application. Un outil de copie tel que robocopy/MT ou n’importe quel outil de performances tel que Diskspd pour lire/écrire des fichiers, peut générer une charge.
  5. Ouvrez PowerShell en tant qu’administrateur et utilisez la commande suivante : Get-SmbMultichannelConnection |fl
  6. Recherchez des propriétés de MaxChannels et CurrentChannels.

Screenshot of Get-SMBMultichannelConnection results.

Comparaison entre les performances

Il existe deux catégories de modèles de charge de travail en lecture/écriture : à thread unique et multithread. La plupart des charges de travail utilisent plusieurs fichiers, mais il peut y avoir des cas d’usage spécifiques où la charge de travail fonctionne avec un fichier unique dans un partage. Cette section décrit les différents cas d’utilisation et l’impact sur les performances de chacun d’eux. En général, la plupart des charges de travail sont multithread et distribuent la charge de travail sur plusieurs fichiers afin de pouvoir observer des améliorations significatives des performances avec SMB Multichannel.

  • Multithread/plusieurs fichiers : selon le modèle de charge de travail, vous devriez constater une amélioration significative des performances des E/S en lecture et écriture sur plusieurs canaux. Les gains de performance varient d’un intervalle de 2 à 4 fois en termes d’IOPS, de débit et de latence. Pour cette catégorie, SMB Multichannel doit être activé pour obtenir des performances optimales.
  • Multithread/fichier unique : pour la plupart des cas d’usage de cette catégorie, les charges de travail bénéficient de l’activation du protocole SMB Multichannel, en particulier si la charge de travail a une taille d’E/S moyenne > d’environ 16 ko. Quelques exemples de scénarios qui tirent parti de SMB Multichannel sont la sauvegarde ou la récupération d’un seul fichier volumineux. Une exception dans laquelle vous souhaiterez peut-être désactiver le protocole SMB Multichannel a lieu si votre charge de travail est lourde en E/S de petite taille. Dans ce cas, vous pouvez observer une légère perte de performances d’environ 10 %. Selon le cas d’usage, envisagez la répartition de la charge entre plusieurs fichiers ou désactivez la fonctionnalité. Consultez la section Configuration pour obtenir des informations.
  • Monothread/plusieurs fichiers ou fichier unique : pour la plupart des charges de travail à thread unique, il existe des avantages minimaux en matière de performances en raison d’un manque de parallélisme. En général, il y a une légère dégradation des performances d’environ 10 % si le protocole SMB Multichannel est activé. Dans ce cas, il est idéal de désactiver SMB Multichannel, à une exception près. Si la charge de travail à thread unique peut répartir la charge entre plusieurs fichiers et utilise une taille d’E/S moyenne plus élevée (> d’environ 16 Ko), il devrait y avoir de légers avantages en matière de performances par rapport au protocole SMB Multichannel.

Configuration des performances test

Pour les graphiques de cet article, la configuration suivante a été utilisée : une seule machine virtuelle standard D32s v3 avec une seule carte réseau compatible RSS avec quatre canaux. Le chargement a été généré en tirant parti de diskspd.exe, de plusieurs threads avec une profondeur d’E/S de 10 et d’E/S aléatoires avec différentes tailles d’E/S.

Taille Processeurs virtuels Mémoire : Gio Stockage temporaire (SSD) en Gio Disques de données max. Débit max. de stockage temporaire et mis en cache : IOPS/Mbits/s (taille du cache en Gio) Débit du disque non mis en cache max. : IOPS/Mbits/s Nombre max de cartes réseau Bande passante réseau attendue (Mbit/s)
Standard_D32s_v3 32 128 256 32 64 000/512 (800) 51 200/768 8 16000

Screenshot that shows the performance test configuration.

Fichiers multithread/multiples avec protocole SMB multicanal

Le chargement a été généré pour 10 fichiers avec différentes tailles d’e/s. Les résultats des tests de mise à l’échelle ont montré des améliorations significatives dans les résultats des tests d’IOPS et de débit avec SMB Multichannel activé. Les diagrammes suivants décrivent les résultats :

Diagram of performance.

Diagram of throughput performance.

  • Sur une seule carte réseau, pour les lectures, une augmentation des performances de 2 à 3 fois a été observée et, pour les écritures, des augmentations de 3 à 4 fois en termes d’IOPS et de débit.
  • SMB Multichannel a permis aux IOPS et au débit d’atteindre les limites de la machine virtuelle avec une seule carte réseau et la limite de quatre canaux.
  • Étant donné que la sortie (ou les lectures vers le stockage) n’est pas mesurée, le débit de lecture a pu dépasser la limite publiée par la machine virtuelle de 16 000 Mbits/s (2 Gio/s). Le test a atteint plus de 2,7 Gio/s. L’entrée (ou les écritures dans le stockage) est toujours soumise à des limites de machine virtuelle.
  • La répartition de la charge sur plusieurs fichiers permet des améliorations substantielles.

Voici un exemple de commande utilisée dans ce test :

diskspd.exe -W300 -C5 -r -w100 -b4k -t8 -o8 -Sh -d60 -L -c2G -Z1G z:\write0.dat z:\write1.dat z:\write2.dat z:\write3.dat z:\write4.dat z:\write5.dat z:\write6.dat z:\write7.dat z:\write8.dat z:\write9.dat .

Charges de travail multithread/fichiers uniques avec SMB Multichannel

La charge a été généré par rapport à un seul fichier de 128 Gio. Avec SMB Multichannel activé, le test de montée en puissance parallèle avec plusieurs threads/fichiers uniques affichait des améliorations dans la plupart des cas. Les diagrammes suivants décrivent les résultats :

Diagram of IOPS performance.

Diagram of single file throughput performance.

  • Sur une seule carte réseau avec une plus grande taille d’E/S moyenne (> d’environ 16 Ko), des améliorations significatives ont été apportées aux lectures et écritures.
  • Pour les plus petites tailles d’E/S, il existait un léger impact d’environ 10 % sur les performances lors de l’activation du protocole SMB Multichannel. Cela peut être atténué en répartissant la charge sur plusieurs fichiers ou en désactivant la fonctionnalité.
  • Les performances sont toujours liées par des limites de fichiers uniques.

Mise en cache des métadonnées pour les partages de fichiers premium SMB

La mise en cache des métadonnées est une amélioration pour les partages de fichiers Premium SMB Azure visant à réduire la latence des métadonnées, à augmenter les IOPS disponibles et à augmenter le débit réseau. Cette fonctionnalité en préversion améliore les API de métadonnées suivantes et peut être utilisée à partir des clients Windows et Linux :

  • Créer
  • En cours
  • Clôture
  • Supprimer

Pour l’intégration, inscrivez-vous à la préversion publique et nous vous fournirons des détails supplémentaires. Pour le moment, cette fonctionnalité d'évaluation est disponible uniquement pour les partages de fichiers premium SMB (comme les partages de fichiers dans le compte de stockage FileStorage). Il n’y a aucun coût supplémentaire associé à l’utilisation de cette fonctionnalité.

Disponibilité régionale

Pour le moment, la préversion de la mise en cache des métadonnées n’est disponible que dans les régions Azure suivantes.

  • Australie Est
  • Brésil Sud-Est
  • France Sud
  • Allemagne Centre-Ouest
  • Suisse Nord
  • Émirats arabes unis Centre
  • Émirats arabes unis Nord
  • USA Centre-Ouest

Améliorations des performances avec la mise en cache des métadonnées

La plupart des charges de travail ou des modèles d’utilisation qui contiennent des métadonnées peuvent tirer parti de la mise en cache des métadonnées. Pour déterminer si votre charge de travail contient des métadonnées, vous pouvez utiliser Azure Monitor pour fractionner les transactions par dimension d’API.

Les charges de travail et les modèles d’utilisation volumineux de métadonnées classiques sont les suivants :

  • Services web/app
  • Tâches DevOps
  • Tâches d’indexation/de traitement par lots
  • Bureaux virtuels avec des répertoires de base ou d’autres charges de travail qui interagissent principalement avec de nombreux petits fichiers, répertoires ou descripteurs

Les diagrammes suivants décrivent les résultats potentiels.

Réduction de la latence des métadonnées

En mettant en cache des chemins de fichiers et de répertoires pour les recherches futures, la mise en cache des métadonnées peut réduire la latence sur les fichiers et répertoires fréquemment consultés de 30 % ou plus pour les charges de travail lourdes de métadonnées à grande échelle.

Chart showing latency in milliseconds with and without metadata caching.

Augmentation des IOPS disponibles

La mise en cache des métadonnées peut augmenter les IOPS disponibles de plus de 60 % pour les charges de travail lourdes de métadonnées à grande échelle.

Chart showing available IOPS with and without metadata caching.

Augmentation du débit réseau

La mise en cache des métadonnées peut augmenter le débit réseau de plus de 60% pour les charges de travail lourdes de métadonnées à grande échelle.

Chart showing network throughput with and without metadata caching.

Étapes suivantes