Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
✔️ S’applique à : partages de fichiers SMB et NFS classiques créés avec le fournisseur de ressources Microsoft.Storage
✔️ S’applique à : Partages de fichiers créés avec le fournisseur de ressources Microsoft.FileShares
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 affectent les performances du partage de fichiers et comment optimiser les performances de Azure Files pour votre charge de travail.
Glossaire des performances du stockage
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. Dans la documentation Azure Files, le terme « E/S » est interchangeable avec les termes « opération » et « transaction ».
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 E/S par seconde × une taille d’E/S de 1 Mio = 10 Gio/s, tandis que 10 000 E/S par seconde × une taille d’E/S de 4 KiO = 38 Mio/s.
Latence
La latence est un synonyme de délai et est 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 multimédia en fonction des modèles d’utilisation
Azure Files fournit deux niveaux de support de stockage que vous pouvez utiliser pour équilibrer les performances et le prix : SSD et HDD. Vous sélectionnez le niveau multimédia du partage de fichiers au niveau du compte de stockage. Après avoir créé un compte de stockage dans un niveau multimédia particulier, vous ne pouvez pas passer à l’autre niveau multimédia sans migrer manuellement vers un nouveau partage de fichiers.
Lorsque vous choisissez entre les partages de fichiers SSD et HDD, tenez compte des exigences du modèle d’utilisation attendu que vous envisagez d’exécuter sur Azure Files. Si vous avez besoin de grandes quantités d’IOPS, de vitesses de transfert de données rapides ou de faible latence, choisissez des partages de fichiers SSD.
Le tableau suivant récapitule les cibles de performances attendues entre les partages de fichiers SSD et HDD. Pour plus d’informations, consultez Objectifs de scalabilité et de performance d’Azure Files.
| Besoins liés au modèle d’utilisation | ssd | HDD |
|---|---|---|
| Latence d’écriture (à un seul chiffre en millisecondes) | Oui | Oui |
| Latence de lecture (à un seul chiffre en millisecondes) | Oui | Non |
Les partages de fichiers SSD utilisent un modèle d’approvisionnement qui garantit le profil de performances suivant en fonction de la taille du partage. Pour plus d’informations, consultez Modèle provisionné v1.
Meilleures pratiques en matière de performances
Que vous évaluez les exigences de performances pour une charge de travail nouvelle ou existante, la compréhension de vos modèles d’utilisation vous permet d’obtenir des performances prévisibles.
Sensibilité de la latence : Les charges de travail sensibles à la latence de lecture et qui ont une visibilité élevée pour les utilisateurs finaux sont plus adaptées aux partages de fichiers SSD, ce qui peut fournir une latence en millisecondes pour les opérations de lecture et d’écriture (moins de 2 ms pour une petite taille d’E/S).
Exigences en matière d’IOPS et de débit : Les partages de fichiers SSD prennent en charge des IOPS et des limites de débit plus importantes que les partages de fichiers HDD. Pour plus d’informations, consultez les cibles de mise à l’échelle du partage de fichiers.
Durée et fréquence de la charge de travail : Les charges de travail courtes (minutes) et peu fréquentes (toutes les heures) sont moins susceptibles d’atteindre les limites de performances supérieures des partages de fichiers HDD par rapport aux charges de travail longues et fréquentes. Sur les partages de fichiers SSD, la durée de la charge de travail permet de déterminer le profil de performances approprié à utiliser en fonction du stockage provisionné, des IOPS et du débit. Une erreur courante consiste à exécuter des tests de performances pendant seulement quelques minutes, ce qui est souvent trompeur. Pour avoir une vue réaliste des performances, assurez-vous de tester à une fréquence et une durée suffisamment élevées.
Parallélisation de la charge de travail : Pour les charges de travail qui effectuent des opérations en parallèle, telles que via plusieurs threads, processus ou instances d’application sur le même client, les partages de fichiers SSD offrent un avantage clair sur les partages de fichiers HDD : SMB Multichannel. Pour plus d’informations, consultez Améliorer les performances du partage de fichiers SMB Azure.
Distribution des opérations d’API : les charges de travail lourdes de métadonnées, telles que les charges de travail qui effectuent des opérations de lecture sur un grand nombre de fichiers, conviennent mieux aux partages de fichiers SSD. Pour plus d’informations, consultez Charge de travail gourmande en métadonnées ou en espace de noms.
Placement zonal : utilisez le placement zonal pour sélectionner la zone de disponibilité spécifique dans laquelle réside votre compte de stockage. Cette fonctionnalité vous permet de placer vos machines virtuelles dans la même zone de disponibilité que votre stockage, ce qui peut réduire la latence jusqu’à 30 %. Cette fonctionnalité est actuellement disponible uniquement pour les comptes de stockage SSD à l’aide du stockage localement redondant (LRS) dans les régions prises en charge.
Latence
Lorsque vous pensez à la latence, commencez par comprendre comment Azure Files détermine la latence. 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 vous aider à identifier les problèmes de latence et de mise en réseau côté client en montrant combien de temps votre trafic d’application passe en transit vers et depuis le 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) est le temps nécessaire à une transaction pour aller-retour uniquement dans Azure Files. Cette mesure n’inclut aucune latence de client ou de 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 signale une faible latence et que la latence de bout en bout signale une latence très élevée pour les requêtes, tout le temps est passé en transit vers et depuis le client, et non dans le service Azure Files.
En outre, comme le montre le diagramme, plus vous êtes loin du service, plus l’expérience de latence est lente, et plus il est difficile d’atteindre des limites de mise à l’échelle des performances avec n’importe quel service cloud. Cette condition est particulièrement vraie lors de l’accès à Azure Files à partir d’un emplacement local. Bien que les options telles que Azure ExpressRoute soient idéales pour les locaux, 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. Les circuits ExpressRoute sous-dimensionnés ou mal routés, ainsi que les passerelles VPN mal configurées, peuvent ralentir considérablement les charges de travail s'exécutant sur Azure Files.
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. À mesure que les disques utilisés par les systèmes de stockage ont évolué des spindles HDD (IDE, SATA, SAS) aux appareils ssd (SSD, NVMe), ils ont également évolué pour prendre en charge une plus grande profondeur de file d’attente. 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. Étant donné que Azure Files est un service de fichiers distribué qui s’étend sur des milliers de nœuds de cluster Azure et est conçu pour exécuter des charges de travail à grande échelle, générer et tester des charges de travail avec une profondeur de file d’attente élevée.
Vous pouvez obtenir une profondeur de file d’attente élevée de plusieurs façons différentes. Pour déterminer la profondeur de file d’attente de votre charge de travail, multipliez le nombre de clients par le nombre de fichiers par le nombre de threads (les clients × fichiers × threads = profondeur de file d’attente).
Le tableau suivant illustre les différentes combinaisons que vous pouvez utiliser pour obtenir une profondeur de file d’attente plus élevée. Bien que vous puissiez dépasser la profondeur de file d’attente optimale de 64, il n’est pas recommandé. 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 | Sujets | 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 | 32 |
Conseil
Pour obtenir des performances maximales, assurez-vous que votre charge de travail ou votre test de benchmarking utilise plusieurs threads et plusieurs fichiers.
Applications monothread ou multithread
Azure Files offre les meilleures performances avec des applications multithread. Le moyen le plus simple de comprendre l’impact sur les performances que le multithreading a sur une charge de travail consiste à parcourir le scénario par E/S. Dans l’exemple suivant, vous avez une charge de travail qui doit copier 10 000 petits fichiers le plus rapidement possible vers ou à partir 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 | Fermer | Total |
|---|---|---|---|---|---|---|---|
| Thread 1 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
Dans cet exemple, il faut environ 14 ms pour créer un seul fichier de 16 Kio à partir des six opérations. Si une application à thread unique souhaite déplacer 10 000 fichiers vers un partage de fichiers Azure, cette opération se traduit par 140 000 ms (14 ms × 10 000) ou 140 secondes, car chaque fichier est déplacé séquentiellement un par un à la fois. Le temps de traitement de chaque requête est principalement déterminé par la proximité entre les ressources de calcul et de stockage, comme expliqué dans la section précédente.
En utilisant huit threads au lieu d’un, vous pouvez réduire la charge de travail précédente de 140 000 ms (140 secondes) jusqu’à 17 500 ms (17,5 secondes). Comme le montre le tableau suivant, lorsque vous déplacez huit fichiers en parallèle au lieu d’un 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 | Fermer | 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 |