Comprendre les performances d’Azure Files

Article
09/08/2023

Azure Files peut répondre aux besoins de performances pour la plupart des applications et des cas d’usage. Cet article explique les différents facteurs qui peuvent affecter les performances des partages de fichiers, et comment optimiser les performances des partages de fichiers Azure pour votre charge de travail.

S’applique à

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

Glossaire

Avant de lire cet article, il est utile de comprendre certains termes clés relatifs aux performances de stockage :

Opérations d’E/S par seconde (IOPS)

Les IOPS, ou opérations d’entrée/sortie par seconde, mesurent le nombre d’opérations de système de fichiers par seconde. Le terme « E/S » est interchangeable avec les termes « opération » et « transaction » dans la documentation Azure Files.
Taille des E/S

La taille des E/S, parfois appelée taille de bloc, correspond à la taille de la requête utilisée par une application pour effectuer une seule opération d’entrée/sortie (E/S) sur le stockage. Selon l’application, la taille des E/S peut se situer entre des tailles très petites, par exemple 4 Kio, et des tailles beaucoup plus grandes. La taille des E/S joue un rôle majeur dans le débit pouvant être atteint.
Débit

Le débit mesure le nombre de bits lus ou écrits dans le stockage par seconde. Il est mesuré en mébioctets par seconde (Mio/s). Pour calculer le débit, multipliez les IOPS par la taille des E/S. Par exemple, 10 000 IOPS * taille d’E/S de 1 Mio = 10 Gio/s, alors que 10 000 IOPS * taille d’E/S de 4 Kio = 38 Mio/s.
Latence

La latence est synonyme de retard. Elle est généralement mesurée en millisecondes (ms). Il existe deux types de latence : la latence de bout en bout et la latence du service. Pour plus d’informations, consultez Latence.
Profondeur de file d’attente

La profondeur de file d’attente correspond au nombre de requêtes d’E/S en attente qu’une ressource de stockage peut gérer à un moment donné. Pour plus d’informations, consultez Profondeur de file d’attente.

Choix d’un niveau de performance en fonction des modèles d’utilisation

Azure Files fournit une gamme de niveaux de stockage qui contribuent à réduire les coûts, tout en vous permettant de stocker les données au niveau de performance et au prix appropriés. Au niveau le plus élevé, Azure Files propose deux niveaux de performances : Standard et Premium. Les partages de fichiers Standard sont hébergés sur un système de stockage basé sur des disques durs (disques HDD), alors que les partages de fichiers Premium sont basés sur des disques SSD pour de meilleures performances. Les partages de fichiers Standard disposent de plusieurs niveaux de stockage (optimisé pour les transactions, chaud et froid) interchangeables de manière transparente pour permettre l’optimisation du stockage des données au repos et des prix des transactions. Toutefois, vous ne pouvez pas passer du niveau Standard au niveau Premium sans migrer physiquement vos données entre les différents comptes de stockage.

Quand vous devez choisir entre les partages de fichiers Standard et Premium, il est important de comprendre les besoins liés au modèle d’utilisation attendu, que vous comptez exécuter sur Azure Files. Si vous avez besoin de grandes quantités d’IOPS, de vitesses de transfert de données extrêmement rapides ou d’une latence très faible, choisissez les partages de fichiers Azure Premium.

Le tableau suivant récapitule les objectifs de performances attendus entre les niveaux Standard et Premium. Pour plus d’informations, consultez Objectifs de scalabilité et de performance d’Azure Files.

Besoins liés au modèle d’utilisation	Standard	Premium
Latence d’écriture (à un seul chiffre en millisecondes)	Oui	Oui
Latence de lecture (à un seul chiffre en millisecondes)	Non	Oui

Les partages de fichiers Premium offrent un modèle de provisionnement qui garantit le profil de performances suivant en fonction de la taille du partage. Pour plus d’informations, consultez Modèle provisionné. Les crédits du mode rafale s’accumulent dans un compartiment pour le débit en rafale chaque fois que le trafic de votre partage de fichiers est inférieur aux IOPS de référence. Les crédits gagnés sont utilisés plus tard pour activer le bursting quand les opérations dépassent les IOPS de référence.

Capacité (Gio)	IOPS de base	IOPS en rafale	Lister les crédits	Débit (entrée + sortie)
100	3 100	Jusqu’à 10 000	24 840 000	110 Mio/s
500	3 500	Jusqu’à 10 000	23 400 000	150 Mio/s
1 024	4 024	Jusqu’à 10 000	21 513 600	203 Mio/s
5 120	8 120	Jusqu’à 15 360	26 064 000	613 Mio/s
10 240	13 240	Jusqu’à 30 720	62 928 000	1 125 Mio/s
33 792	36 792	Jusqu’à 100 000	227 548 800	3 480 Mio/s
51 200	54 200	Jusqu’à 100 000	164 880 000	5 220 Mio/s
102 400	100 000	Jusqu’à 100 000	0	10 340 Mio/s

Check-list des performances

Que vous évaluiez les besoins en performances d’une nouvelle charge de travail ou d’une charge de travail déjà existante, la compréhension de vos modèles d’utilisation vous permettra d’obtenir des performances prévisibles. Consultez votre administrateur de stockage ou votre développeur d’applications pour déterminer les modèles d’utilisation suivants.

Sensibilité de latence : Les utilisateurs ouvrent-ils des fichiers ou interagissent-ils avec des bureaux virtuels qui s’exécutent sur Azure Files ? Il s’agit d’exemples de charges de travail qui sont sensibles à la latence de lecture, et qui offrent également une visibilité élevée aux utilisateurs finaux. Ces types de charge de travail conviennent mieux aux partages de fichiers Azure Premium, qui peuvent fournir une latence d’une milliseconde pour les opérations de lecture et d’écriture (< 2 ms pour une taille d’E/S réduite).
Exigences en matière d’IOPS et de débit : les partages de fichiers premium prennent en charge des limites d’IOPS et de débit plus importantes que les partages de fichiers standard. Pour plus d’informations, consultez cibles d’échelle de partage de fichiers.
Durée et fréquence des charges de travail : Les charges de travail courtes (en minutes) et peu fréquentes (toutes les heures) ont moins de chances d’atteindre les limites de performances supérieures des partages de fichiers Standard que les charges de travail fréquentes de longue durée. Sur les partages de fichiers Premium, la durée de la charge de travail permet de déterminer le profil de performances approprié en fonction de la taille de provisionnement. En fonction du temps nécessaire à la charge de travail pour son traitement en rafale, et du temps qu’elle passe sous les IOPS de référence, vous pouvez déterminer si vous accumulez suffisamment de crédits de bursting pour répondre de manière cohérente aux besoins de la charge de travail aux heures de pointe. La recherche du bon équilibre permet de réduire les coûts par rapport au surprovisionnement du partage de fichiers. Une erreur courante consiste à exécuter des tests de performances pendant quelques minutes seulement, ce qui est souvent trompeur. Pour obtenir une vue réaliste des performances, veillez à effectuer les tests à une fréquence et une durée suffisamment élevées.
Parallélisation de charge de travail : pour les charges de travail qui effectuent des opérations en parallèle, par exemple via plusieurs threads, processus ou instances d’application sur le même client, les partages de fichiers premium offrent un avantage évident par rapport aux partages de fichiers standard : SMB Multichannel. Pour plus d’informations, consultez Améliorer les performances des partages de fichiers Azure SMB.
Distribution des opérations d’API : Les métadonnées de charge de travail sont-elles lourdes en raison des opérations d’ouverture/de fermeture de fichiers ? Ceci est courant pour les charges de travail qui effectuent des opérations de lecture sur un grand nombre de fichiers. Consultez Métadonnées ou charge de travail importante de l’espace de noms.

Latence

Quand vous pensez à la latence, vous devez d’abord bien comprendre la façon dont elle est déterminée avec Azure Files. Les mesures les plus courantes sont la latence associée aux métriques de latence de bout en bout et de latence du service. L’utilisation de ces métriques de transaction peut permettre d’identifier les problèmes de latence et/ou les problèmes réseau côté client en déterminant la durée de transit du trafic de votre application à destination et en provenance du client.

La latence de bout en bout (SuccessE2ELatency) correspond au temps total nécessaire à une transaction pour effectuer un aller-retour complet entre le client, le réseau, le service Azure Files, puis le client.
La latence du service (SuccessServerLatency) correspond au temps nécessaire à une transaction pour effectuer un aller-retour uniquement au sein du service Azure Files. Cela n’inclut pas la latence du client ou le temps de réponse du réseau.

La différence entre les valeurs de SuccessE2ELatency et SuccessServerLatency correspond à la latence probable causée par le réseau et/ou le client.

Il est courant de confondre la latence du client et la latence du service (dans le cas présent, les performances d’Azure Files). Par exemple, si la latence du service est faible, et si la latence de bout en bout correspond à une latence très élevée pour les demandes, cela peut signifier que tout le temps est passé en transit à destination et en provenance du client, et non dans le service Azure Files.

De plus, comme l’illustre le diagramme, plus vous vous éloignez du service, plus la latence est lente, et plus il est difficile d’atteindre les limites de mise à l’échelle des performances avec un service cloud. Cela est particulièrement vrai quand vous accédez à Azure Files depuis un environnement local. Bien que les options telles qu’ExpressRoute soient idéales pour un environnement local, elles ne correspondent toujours pas aux performances d’une application (calcul + stockage) qui s’exécute exclusivement dans la même région Azure.

Conseil

L’utilisation d’une machine virtuelle dans Azure pour tester les performances entre l’environnement local et Azure est un moyen efficace et pratique d’établir une base de référence des fonctionnalités réseau de la connexion à Azure. Une charge de travail peut souvent être ralentie par une passerelle VPN ou un circuit ExpressRoute sous-dimensionné ou mal routé.

Profondeur de file d’attente

La profondeur de file d’attente correspond au nombre de requêtes d’E/S en attente qu’une ressource de stockage peut traiter. Au fur et à mesure que les disques utilisés par les systèmes de stockage sont passés des disques HDD à plateaux (IDE, SATA, SAS) aux périphériques SSD, NVMe, ils ont également évolué pour prendre en charge une profondeur de file d’attente plus importante. Une charge de travail composée d’un seul client qui interagit en série avec un seul fichier au sein d’un jeu de données volumineux est un exemple de faible profondeur de file d’attente. En revanche, une charge de travail qui gère le parallélisme avec plusieurs threads et plusieurs fichiers peut facilement atteindre une profondeur de file d’attente importante. Dans la mesure où Azure Files est un service de fichiers distribué qui s’étend sur des milliers de nœuds de cluster Azure, et qu’il est conçu pour exécuter des charges de travail à grande échelle, nous vous recommandons de créer et de tester des charges de travail avec une profondeur de file d’attente importante.

Vous pouvez obtenir une profondeur de file d’attente importante de plusieurs façons différentes, en combinaison avec les clients, les fichiers et les threads. Pour déterminer la profondeur de file d’attente de votre charge de travail, multipliez le nombre de clients par le nombre de fichiers, puis par le nombre de threads (clients * fichiers * threads = profondeur de file d’attente).

Le tableau ci-dessous illustre les différentes combinaisons qui vous permettent d’obtenir une profondeur de file d’attente plus importante. Bien que vous puissiez dépasser la profondeur de file d’attente optimale définie à 64, nous vous le déconseillons. En effet, vous ne constaterez plus de gains de performances, et vous risquez d’augmenter la latence en raison de la saturation TCP.

Clients	Fichiers	Threads	Profondeur de file d’attente
1	1	1	1
1	1	2	2
1	2	2	4
2	2	2	8
2	2	4	16
2	4	4	32
1	8	8	64
4	4	2	64

Conseil

Pour atteindre les limites de performances supérieures, vérifiez que votre charge de travail ou votre test de point de référence est multithread avec plusieurs fichiers.

Applications monothread et multithread

Azure Files convient mieux aux applications multithread. Le moyen le plus simple de comprendre l’impact du multithread sur les performances d’une charge de travail consiste à parcourir le scénario par E/S. Dans l’exemple suivant, nous avons une charge de travail qui doit copier 10 000 petits fichiers le plus rapidement possible en provenance ou à destination d’un partage de fichiers Azure.

Ce tableau décompose le temps nécessaire (en millisecondes) pour créer un seul fichier de 16 Kio sur un partage de fichiers Azure, sur la base d’une application monothread qui écrit des blocs de 4 Kio.

Opération d’E/S	Créer	Écriture de 4 Kio	Écriture de 4 Kio	Écriture de 4 Kio	Écriture de 4 Kio	Close	Total
Thread 1	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms

Dans cet exemple, la création d’un seul fichier de 16 Kio à partir des six opérations prend environ 14 ms. Si une application monothread souhaite déplacer 10 000 fichiers vers un partage de fichiers Azure, cela se traduit par 140 000 ms (14 ms * 10 000) ou 140 secondes, car chaque fichier est déplacé de manière séquentielle, un par un. N’oubliez pas que le délai de traitement de chaque requête est principalement déterminé par la proximité entre le calcul et le stockage, comme indiqué dans la section précédente.

En utilisant huit threads au lieu d’un seul, la charge de travail ci-dessus peut être réduite de 140 000 ms (140 secondes) à 17 500 ms (17,5 secondes). Comme le montre le tableau ci-dessous, quand vous déplacez huit fichiers en parallèle au lieu d’un seul fichier à la fois, vous pouvez déplacer la même quantité de données en 87,5 % moins de temps.

Opération d’E/S	Créer	Écriture de 4 Kio	Écriture de 4 Kio	Écriture de 4 Kio	Écriture de 4 Kio	Close	Total
Thread 1	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 2	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 3	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 4	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 5	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 6	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 7	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms
Thread 8	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms