Comprendre et optimiser le niveau de performance du partage de fichiers Azure

✔️ 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.

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. Sur les partages de fichiers provisionnés, un test court peut mesurer les IOPS en rafale basés sur le crédit au lieu des IOPS provisionnés. Pour plus d’informations, voir Bursting.

• 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.

Mode en rafales

Les partages de fichiers utilisant le modèle de facturation provisionné v2 ou provisionné v1 prennent en charge le bursting des IOPS basée sur les crédits. Le bursting basé sur le crédit permet à un partage de fichiers d’utiliser plus d’IOPS qu’il n’en a provisionné pendant un temps limité. Le bursting basé sur des crédits est une fonctionnalité du partage de fichiers. Le trafic en rafale est un schéma de charge de travail avec de courts pics d’IOPS ou de débit. Le bursting basé sur le crédit peut absorber de courts pics d’IOPS causés par un trafic en rafale.

Le bursting basé sur le crédit est inclus dans le coût du partage de fichiers provisionné et n’ajoute pas de frais à votre facture. Le bursting basé sur les crédits s’applique uniquement à l’IOPS. Cela n’augmente pas le débit au-delà du débit provisionné.

Le bursting ne s’applique pas aux partages de fichiers à l’utilisation. Les partages de fichiers classiques avec fonctionnalité de rafale restent soumis aux limites d’IOPS du compte de stockage. Pour plus d’informations, voir Limites classiques du plan de données du partage de fichiers. Pour plus d’informations sur l’impact du bursting sur le coût, voir Comprendre la facturation Azure Files.

Bursting v2 approvisionné

Le bursting d’IOPS basé sur le crédit offre une flexibilité accrue en matière d’utilisation des IOPS. Utilisez cette flexibilité comme mémoire tampon contre les pics d’E/S imprévus. Pour les modèles d’E/S établis, provisionnez les pics d’E/S.

Les crédits d’E/S par seconde en rafale s’accumulent chaque fois que le trafic de votre partage de fichiers est inférieur à l’IOPS provisionné (base de référence). Chaque fois que l'utilisation d'IOPS d'un partage de fichiers dépasse les IOPS provisionnées et que des crédits d'IOPS en rafale sont disponibles, le partage de fichiers peut atteindre la limite maximale d'IOPS en rafale autorisée. Les partages de fichiers peuvent continuer à faire l’objet d’une rafale tant qu’il y a des crédits restants, en fonction du nombre de crédits de rafale cumulés. Chaque opération d'entrée/sortie au-delà des IOPS provisionnées consomme un crédit. Après que tous les crédits ont été consommés, la part retourne à l’IOPS provisionné. Les d’IOPS sur le partage de fichiers n’ont rien à faire de spécial pour utiliser le bursting. Le bursting fonctionne sur une base optimale.

Les crédits de partage ont trois états :

• Accumulation, lorsque le partage de fichiers utilise moins que les IOPS provisionnés.
• Décliner, lorsque le partage de fichiers utilise plus que les IOPS provisionnés et en mode rafale.
• Constante, lorsque le partage de fichiers utilise exactement les IOPS provisionnés et qu’il n’y a pas de crédits cumulés ou utilisés.

Un nouveau partage de fichiers commence par le nombre total de crédits de son compartiment de rafale. Les crédits bursting ne s’accumulent pas si l’IOPS de partage tombe en dessous de la limite approvisionnée en raison de la limitation par le serveur. Les formules suivantes permettent de déterminer la limite des IOPS en mode rafale et le nombre de crédits possibles pour un partage de fichiers :

Le tableau suivant illustre quelques exemples de ces formules pour différentes quantités d’IOPS approvisionnés :

Bursting v1 approvisionné

Le modèle provisionné v1 prend en charge deux types de bursting : le bursting basé sur le crédit, inclus sans coût supplémentaire, et le bursting payant, que vous pouvez en option activer pour permettre des IOPS et un débit supérieurs au niveau provisionné pour des frais basés sur l’utilisation.

Bursting v1 approvisionné basé sur le crédit

Le bursting d’IOPS basé sur le crédit offre une flexibilité accrue en matière d’utilisation des IOPS. Utilisez cette flexibilité comme mémoire tampon contre les pics d’E/S imprévus. Pour les modèles d’E/S établis, provisionnez les pics d’E/S.

Les crédits d’E/S par seconde en rafale s’accumulent chaque fois que le trafic de votre partage de fichiers classique est inférieur à l’IOPS provisionné (base de référence). Chaque fois que l’utilisation d’IOPS d’un partage de fichiers classique dépasse les IOPS approvisionnées et qu’il existe des crédits d’E/S par seconde en rafale disponibles, le partage de fichiers classique peut monter en rafale jusqu’à la limite maximale d’E/S par seconde autorisée. Les partages de fichiers classiques peuvent continuer à faire l’objet d’un bursting tant qu’il reste des crédits, en fonction du nombre de crédits de bursting accumulés. Chaque opération d'entrée/sortie au-delà des IOPS provisionnées consomme un crédit. Après avoir consommé tous les crédits, le partage de fichiers classique retourne à l’IOPS provisionné. Les IOPS sur le partage de fichiers classique n’ont rien à faire de spécial pour utiliser le bursting. Le bursting fonctionne sur une base optimale.

Les crédits de partage ont trois états :

• En hausse, lorsque le partage de fichiers utilise un nombre inférieur à celui des IOPS provisionnés.
• Refus, lorsque le partage de fichiers classique utilise plus que les IOPS provisionnés et est en mode bursting.
• Constante, lorsque le partage de fichiers classique utilise exactement les IOPS provisionnés et qu’il n’y a pas de crédits accumulés ou utilisés.

Un nouveau partage de fichiers classique commence avec le nombre total de crédits de son compartiment de rafale. Les crédits bursting ne s’accumulent pas si l’IOPS de partage tombe en dessous de la limite approvisionnée en raison de la limitation par le serveur. Les formules suivantes permettent de déterminer la limite d’E/S par seconde en rafale et le nombre de crédits possibles pour un partage de fichiers classique :

Le tableau suivant illustre quelques exemples de ces formules pour les tailles approvisionnées :

Bursting v1 approvisionné payant

Le bursting payant est une fonctionnalité avancée du modèle v1 approvisionné conçu pour prendre en charge les clients qui ne souhaitent jamais être limités. Le bursting payant ajoute une facturation basée sur l’utilisation supplémentaire pour toute quantité d’IOPS ou de débit au-dessus du stockage approvisionné. Cette fonctionnalité est distincte du bursting basé sur des crédits, qui est inclus gratuitement avec le stockage provisionné. Bien que le bursting payant puisse ajouter une flexibilité puissante à la façon dont vous approvisionnez votre partage de fichiers classique, il peut également entraîner une facturation inattendue si elle est utilisée incorrectement.

Comme le bursting basé sur le crédit, le bursting payant n’est pas un remplacement de l’approvisionnement de la quantité correcte d’IOPS et de débit. Au lieu de cela, elle offre une protection supplémentaire contre la limitation si vous rencontrez une demande inattendue. Si vous avez un niveau cohérent d’IOPS ou d’utilisation du débit, il est moins cher de provisionner suffisamment d’IOPS et de débit (via l’approvisionnement de stockage) pour couvrir la demande au lieu de compter sur le bursting payant.

Le bursting payant est désactivé par défaut, mais vous pouvez l’activer en suivant les instructions pour modifier les caractéristiques de coût et de performances d’un partage de fichiers classique v1 approvisionné (PowerShell et CLI uniquement). Si vous activez le bursting payant, surveillez l’utilisation des E/S par seconde et du débit à l’aide des métriques suivantes disponibles via Azure Monitor :

• IOPS approvisionnées du partage de fichiers
• Mio/s de bande passante provisionnée de partage de fichiers (débit)
• Transactions par IOPS maximaux
• Bande passante par Mo/s maximum (débit)
• Crédits de rafale pour les IOPS (bursting basé sur les crédits)
• E/S de burst payant (IOS)
• Bande passante de burst payant

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.

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.

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.

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.

Voir aussi

• Résoudre les problèmes de performances des partages de fichiers Azure
• Supervision d’Azure Files
• Planification d’un déploiement Azure Files
• Présentation de la facturation d’Azure Files
• Tarification Azure Files