Objectifs de performance et d’extensibilité d'Azure Files

Azure Files offre des partages de fichiers entièrement gérés dans le cloud, accessibles à l’aide des protocoles SMB et de système de fichiers NFS. Cet article présente les objectifs de performance et d’extensibilité pour Azure Files et Azure File Sync.

Les cibles répertoriées ici peuvent être affectées par d’autres variables dans votre déploiement. Par exemple, les performances d’E/S d’un fichier peuvent être affectées par le comportement de votre client SMB et la bande passante réseau disponible. Vous devez tester votre modèle d’utilisation pour déterminer si l’extensibilité et les performances d’Azure Files répondent à vos besoins.

S’applique à

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

Objectifs de mise à l’échelle Azure Files

Les partages de fichiers Azure sont déployés dans des comptes de stockage, qui sont des objets de niveau supérieur représentant un pool partagé de stockage. Ce pool de stockage peut être utilisé pour déployer plusieurs partages de fichiers. Trois catégories doivent donc être prises en compte : les comptes de stockage, les partages de fichiers Azure et les fichiers individuels.

Objectifs de mise à l'échelle d'un compte de stockage

Les objectifs de mise à l’échelle du compte de stockage s’appliquent au niveau du compte de stockage. Il existe deux types principaux de comptes de stockage pour Azure Files :

  • Comptes de stockage version 2 universels (GPv2) : Les comptes de stockage GPv2 vous permettent de déployer des partages de fichiers Azure sur du matériel Standard/sur disque dur (HDD). En plus de stocker les partages de fichiers Azure, les comptes de stockage GPv2 peuvent stocker d’autres ressources de stockage, telles que des conteneurs d’objets blob, des files d’attente ou des tables. Les partages de fichiers peuvent être déployés sur le niveau Transaction optimisée (par défaut), le niveau d’accès froid ou le niveau d’accès chaud.

  • Comptes de stockage FileStorage : Les comptes de stockage FileStorage vous permettent de déployer des partages de fichiers Azure sur du matériel Premium/sur disque SSD. Les comptes FileStorage peuvent uniquement être utilisés pour stocker des partages de fichiers Azure. Aucune autre ressource de stockage (conteneurs d’objets blob, files d’attente, tables, etc.) ne peut être déployée dans un compte FileStorage.

Attribut Comptes de stockage GPv2 (Standard) Comptes de stockage FileStorage (Premium)
Nombre de comptes de stockage par région par abonnement 2501 2501
Capacité maximale du compte de stockage 5 Pio2 100 Tio (approvisionné)
Nombre maximal de partages de fichiers Illimité Illimité, la taille totale approvisionnée de tous les partages doit être inférieure à la capacité maximale du compte de stockage
Taux maximal de requêtes simultanées 20 000 IOPS2 100 000 E/S par seconde
Débit (entrée + sortie) pour LRS/GRS
  • Australie Est
  • USA Centre
  • Asie Est
  • USA Est 2
  • Japon Est
  • Centre de la Corée
  • Europe Nord
  • États-Unis - partie centrale méridionale
  • Asie Sud-Est
  • Sud du Royaume-Uni
  • Europe Ouest
  • USA Ouest
  • Entrée : 7 152 Mio/s
  • Sortie : 14 305 Mio/s
10,340 Mio/s
Débit (entrée + sortie) pour le stockage redondant interzone
  • Australie Est
  • USA Centre
  • USA Est
  • USA Est 2
  • Japon Est
  • Europe Nord
  • États-Unis - partie centrale méridionale
  • Asie Sud-Est
  • Sud du Royaume-Uni
  • Europe Ouest
  • USA Ouest 2
  • Entrée : 7 152 Mio/s
  • Sortie : 14 305 Mio/s
10,340 Mio/s
Débit (entrée + sortie) pour les combinaisons redondance/région non répertoriées dans la ligne précédente
  • Entrée : 2 980 Mio/s
  • Sortie : 5 960 Mio/s
10,340 Mio/s
Nombre maximal de règles de réseau virtuel 200 200
Nombre maximal de règles d’adresse IP 200 200
Opérations de lecture de gestion 800 toutes les 5 minutes 800 toutes les 5 minutes
Opérations d’écriture de gestion 10 par seconde/1 200 par heure 10 par seconde/1 200 par heure
Opérations de liste de gestion 100 toutes les 5 minutes 100 toutes les 5 minutes

1 Avec une augmentation du quota, vous pouvez créer jusqu’à 500 comptes de stockage avec des points de terminaison standard par région. Pour plus d’informations, consultez Augmenter de quotas du compte de stockage Azure. 2 Les comptes de stockage universels version 2 prennent en charge de plus grandes limites de capacité et de plus grandes limites d’entrée par requête. Pour demander une augmentation des limites de compte, contactez le support Azure.

Cibles de mise à l’échelle du partage de fichiers Azure

Les objectifs de mise à l’échelle du partage de fichiers Azure s’appliquent au niveau du partage de fichiers.

Attribut Partages de fichiers Standard1 Partages de fichiers Premium
Taille minimale d'un partage de fichiers Pas de minimum 100 Gio (approvisionné)
Unité d’augmentation/de réduction de taille approvisionnée N/A 1 Gio
Taille maximale d’un partage de fichiers
  • 100 Tio, avec la fonctionnalité de partage de fichiers volumineux activée2
  • 5 Tio, par défaut
100 Tio
Nombre maximal de fichiers dans un partage de fichiers Aucune limite Aucune limite
Taux de requêtes maximal (IOPS max.)
  • 20 000, avec la fonctionnalité de partage de fichiers volumineux activée2
  • 1 000 ou 100 requêtes par 100 ms, par défaut
  • IOPS de référence : 3 000 + 1 IOPS par Gio, jusqu’à 100 000
  • IOPS en rafale : Max (10 000, 3 x 3 IOPS par Gio), jusqu’à 100 000
Débit (entrée + sortie) pour un partage de fichiers unique (Mio/sec)
  • Jusqu’aux limites du compte de stockage, avec la fonctionnalité de partage de fichiers volumineux activée2
  • Jusqu’à 60 Mio/s, par défaut
100 + CEILING(0,04 * ProvisionedStorageGiB) + CEILING(0,06 * ProvisionedStorageGiB)
Nombre maximal d’instantanés de partage 200 instantanés 200 instantanés
Longueur maximale du nom d’objet3 (chemin d’accès complet, incluant tous les répertoires, noms de fichiers et caractères de barre oblique inverse) 2 048 caractères 2 048 caractères
Longueur maximale du composant individuel du nom de chemin3 (dans le chemin \A\B\C\D, chaque lettre représente un répertoire ou un fichier qui est un composant individuel) 255 caractères 255 caractères
Limite de liaison codée en dur (NFS uniquement) N/A 178
Nombre maximal de canaux SMB Multichannel N/A 4
Nombre maximal de stratégies d’accès stockées par partage de fichiers 5 5

1 Les limites pour les partages de fichiers standard s’appliquent aux trois niveaux disponibles pour les partages de fichiers standard : transaction optimisée, chaud et froid.

2 La valeur par défaut sur les partages de fichiers standard est de 5 Tio. Pour plus d’informations sur la création de partages de fichiers de 100 Tio et l’augmentation de la taille de partages de fichiers standard existants (jusqu’à 100 Tio), consultez Créer un partage de fichiers Azure. Pour tirer parti des plus grandes cibles de mise à l’échelle, vous devez modifier votre quota afin qu’il soit supérieur à 5 Tio.

3 Azure Files applique certaines règles de nommage pour les noms de répertoire et de fichiers.

Objectifs de mise à l'échelle de fichier

Les objectifs de mise à l’échelle des fichiers s’appliquent aux fichiers individuels stockés dans des partages de fichiers Azure.

Attribut Fichiers dans les partages de fichiers standard Fichiers dans les partages de fichiers Premium
Taille maximale du fichier 4 Tio 4 Tio
Taux maximal de requêtes simultanées 1 000 E/S par seconde Jusqu’à 8 0001
Entrée maximale pour un fichier 60 Mio/s 200 Mio/s (jusqu’à 1 Gio/s avec la version préliminaire de SMB Multichannel)2
Sortie maximale pour un fichier 60 Mio/s 300 MiB/sec (jusqu'à 1 GiB/s avec SMB Multichannel) 2
Nombre maximal de descripteurs simultanés pour le répertoire racine3 10 000 descripteurs 10 000 descripteurs
Descripteurs simultanés maximums par fichier et répertoire3 2 000 handles 2 000 handles

1 S’applique aux opérations d’E/S en lecture et écriture (généralement des tailles d’E/S plus petites ou égales à 64 Kio). Les opérations sur les métadonnées, autres que les lectures et les écritures, peuvent être inférieures. Ce sont des limites souples, et une limitation de requêtes peut se produire au-delà de ces limites.

2 En fonction des limites du réseau des machines, de la bande passante disponible, des tailles des opérations d’E/S, de la profondeur de la file d’attente et d’autres facteurs. Pour plus d’informations, consultez Performances de SMB Multichannel.

3 Azure Files prend en charge 10 000 descripteurs ouverts sur le répertoire racine et 2 000 descripteurs ouverts par fichier et répertoire au sein du partage. Le nombre d’utilisateurs actifs pris en charge par partage dépend des applications accédant au partage. Si vos applications n’ouvrent pas de descripteur sur le répertoire racine, Azure Files peut prendre en charge plus de 10 000 utilisateurs actifs par partage. Toutefois, si vous utilisez Azure Files pour stocker des images de disque pour des charges de travail de bureau virtuel à grande échelle, vous risquez de manquer de descripteurs pour le répertoire racine ou pour chaque fichier/répertoire. Dans ce cas, vous devrez peut-être utiliser plusieurs partages de fichiers Azure. Pour plus d’informations, consultez le guide de dimensionnement d’Azure Files pour Azure Virtual Desktop.

Guide de dimensionnement d’Azure Files pour Azure Virtual Desktop

Un cas d’usage courant pour Azure Files est le stockage des conteneurs de profils utilisateur et des images de disque pour Azure Virtual Desktop, à l’aide de FSLogix ou de l’attachement d’application. Dans les déploiements Azure Virtual Desktop à grande échelle, vous pouvez manquer de descripteurs pour le répertoire racine ou pour chaque fichier/répertoire si vous utilisez un seul partage de fichiers Azure. Cette section explique comment les descripteurs sont consommés par différents types d’images de disque et fournit des conseils de dimensionnement en fonction de la technologie que vous utilisez.

FSLogix

Si vous utilisez FSLogix avec Azure Virtual Desktop, vos conteneurs de profils utilisateur sont des fichiers de disque dur virtuel (VHD) ou de disque dur virtuel Hyper-V (VHDX), et ils sont montés dans un contexte utilisateur, et non dans un contexte système. Chaque utilisateur ouvre un descripteur de répertoire racine unique, qui doit être vers le partage de fichiers. Azure Files peut prendre en charge un maximum de 10 000 utilisateurs en supposant que vous disposez du partage de fichiers (\\storageaccount.file.core.windows.net\sharename), du répertoire de profil (%sid%_%username%) et du conteneur de profils (profile_%username.vhd(x)).

Si vous atteignez la limite de 10 000 descripteurs simultanés pour le répertoire racine ou que les utilisateurs constatent des performances médiocres, essayez d’utiliser un partage de fichiers Azure supplémentaire et de distribuer les conteneurs entre les partages.

Avertissement

Même si Azure Files peut prendre en charge jusqu’à 10 000 utilisateurs simultanés à partir d’un partage de fichiers unique, il est essentiel de tester correctement vos charges de travail par rapport à la taille et au type de partage de fichiers que vous avez créés. Vos besoins peuvent varier en fonction des utilisateurs, de la taille du profil et de la charge de travail.

Par exemple, si vous avez 2 400 utilisateurs simultanés, vous avez besoin de 2 400 descripteurs sur le répertoire racine (un pour chaque utilisateur), ce qui est inférieur à la limite de 10 000 descripteurs ouverts. Pour les utilisateurs de FSLogix, atteindre la limite de 2 000 descripteurs de fichiers et de répertoires ouverts est extrêmement peu probable. Si vous disposez d’un seul conteneur de profil FSLogix par utilisateur, vous n’utiliserez que deux descripteurs de fichier/répertoire : un pour le répertoire de profil et un pour le fichier conteneur de profil. Si les utilisateurs ont chacun deux conteneurs (profil et ODFC), vous avez besoin d’un descripteur supplémentaire pour le fichier ODFC.

Attachement d’application avec CimFS

Si vous utilisez l’attachement d’application MSIX ou l’attachement d’application pour attacher dynamiquement des applications, vous pouvez utiliser des fichiers CimFS (Composite Image File System) ou VHD/VHDX pour les images de disque. Dans les deux cas, les limites de mise à l’échelle s’appliquent à chaque machine virtuelle qui monte l’image, et non à chaque utilisateur. Le nombre d’utilisateurs n’est pas pertinent lors du calcul des limites de mise à l’échelle. Lorsqu’une machine virtuelle est démarrée, elle monte l’image de disque, même s’il n’y a pas d’utilisateurs.

Si vous utilisez l’attachement d’application avec CimFS, les images de disque consomment uniquement les descripteurs sur les fichiers image disque. Ils ne consomment pas de descripteurs sur le répertoire racine ou le répertoire contenant l’image de disque. Toutefois, étant donné qu’une image CimFS est une combinaison du fichier .cim et d’au moins deux autres fichiers, pour chaque machine virtuelle qui monte l’image de disque, vous aurez besoin d’un descripteur pour trois fichiers dans le répertoire. Par conséquent, si vous avez 100 machines virtuelles, vous aurez besoin de 300 descripteurs de fichiers.

Vous pouvez manquer de descripteurs de fichiers si le nombre de machines virtuelles par application dépasse 2 000. Dans ce cas, utilisez un partage de fichiers Azure supplémentaire.

Attachement d’application avec VHD/VHDX

Si vous utilisez l’attachement d’application avec des fichiers VHD/VHDX, les fichiers sont montés dans un contexte système, et non dans un contexte utilisateur, et ils sont partagés et en lecture seule. Plusieurs descripteurs sur le fichier VHDX peuvent être consommés par un système de connexion. Pour rester dans les limites de mise à l’échelle d’Azure Files, le nombre de machines virtuelles multipliées par le nombre d’applications doit être inférieur à 10 000, et le nombre de machines virtuelles par application ne peut pas dépasser 2 000. La contrainte est donc celle que vous rencontrez en premier.

Dans ce scénario, vous pouvez atteindre la limite par fichier/répertoire avec 2 000 montages d’un seul VHD/VHDX. Ou, si le partage contient plusieurs fichiers VHD/VHDX, vous pouvez d’abord atteindre la limite du répertoire racine. Par exemple, 100 machines virtuelles qui montent 100 fichiers VHDX partagés atteignent la limite de répertoire racine de 10 000 descripteurs.

Dans un autre exemple, 100 machines virtuelles accédant à 20 applications nécessitent 2 000 descripteurs de répertoire racine (100 x 20 = 2 000), qui se situe bien dans la limite de 10 000 descripteurs de répertoire racine. Vous aurez également besoin d’un descripteur de fichier et d’un descripteur de répertoire/dossier pour chaque machine virtuelle qui monte l’image VHD(X), donc 200 descripteurs dans ce cas (100 descripteurs de fichiers + 100 descripteurs de répertoire), ce qui est bien en deçà de la limite de 2 000 descripteurs de répertoire racine.

Si vous atteignez les limites du nombre maximal de descripteurs simultanés pour le répertoire racine ou par fichier/répertoire, utilisez un partage de fichiers Azure supplémentaire.

Objectifs de mise à l’échelle d’Azure File Sync

Le tableau suivant indique quelles cibles sont souples, représentant la limite testée par Microsoft, et rigides, indiquant un maximum appliqué :

Ressource Cible Limite inconditionnelle
Services de synchronisation de stockage par région 100 services de synchronisation de stockage Oui
Groupes de synchronisation par service de synchronisation de stockage 200 groupes de synchronisation Oui
Serveurs inscrits par le service de synchronisation de stockage 99 serveurs Oui
Points de terminaison cloud par groupe de synchronisation 1 point de terminaison cloud Oui
Points de terminaison de serveur par groupe de synchronisation 100 points de terminaison de serveur Oui
Points de terminaison de serveur par serveur 30 points de terminaison de serveur Oui
Objets du système de fichiers (répertoires et fichiers) par groupe de synchronisation 100 millions d’objets Non
Nombre maximal d’objets de système de fichiers (répertoires et fichiers) dans un répertoire (non récursif) 5 millions d’objets Oui
Taille maximale du descripteur de sécurité d’objet (répertoires et fichiers) 64 Kio Oui
Taille du fichier 100 Gio Non
Taille minimale d’un fichier à hiérarchiser en fonction de la taille de cluster du système de fichiers (le double de cette taille). Par exemple, si la taille du cluster de système de fichiers est de 4 Kio, la taille de fichier minimale sera de 8 Kio. Oui

Notes

Un point de terminaison Azure File Sync peut augmenter la taille d’un partage de fichiers Azure. Si la limite de taille du partage de fichiers Azure est atteinte, la synchronisation ne fonctionne pas.

Métriques de performances Azure File Sync

Étant donné que l’agent Azure File Sync s’exécute sur un ordinateur Windows Server qui se connecte aux partages de fichiers Azure, les performances de synchronisation réelles dépendent de plusieurs facteurs dans votre infrastructure : Windows Server et la configuration de disque sous-jacente, la bande passante réseau entre le serveur et le stockage Azure, la taille des fichiers, la taille totale du jeu de données et l’activité sur le jeu de données. Comme Azure File Sync fonctionne au niveau du fichier, les caractéristiques de performances d’une solution Azure File Sync doit être exprimée de façon optimale en nombre d’objets (fichiers et répertoires) traités par seconde.

Pour Azure File Sync, les performances sont essentielles dans deux phases :

  1. Approvisionnement initial unique : pour optimiser les performances lors de l’approvisionnement initial, consultez la section Intégrer Azure File Sync pour obtenir plus d’informations sur un déploiement optimal.
  2. Synchronisation continue : une fois que les données sont initialement approvisionnées dans les partages de fichiers Azure, Azure File Sync synchronise plusieurs points de terminaison.

Notes

Lorsque de nombreux points de terminaison de serveur dans le même groupe de synchronisation sont synchronisés en même temps, ils sont en concurrence pour les ressources de service cloud. Par conséquent, les performances de chargement seront affectées. Dans les cas extrêmes, certaines sessions de synchronisation ne parviennent pas à accéder aux ressources et échouent. Toutefois, ces sessions de synchronisation reprendront bientôt et réussiront lorsque la congestion sera moindre.

Résultats du test interne

Pour vous aider à planifier votre déploiement pour chacune des phases (provisionnement initial unique et synchronisation en continu), voici les résultats observés durant le test interne sur un système avec la configuration suivante :

Configuration système Détails
UC 64 cœurs virtuels avec cache L3 64 MiB
Mémoire 128 Go
Disque Disques SAS avec RAID 10 et cache protégé par batterie
Réseau Réseau 1 Gbit/s
Charge de travail Serveur de fichiers à usage général

Provisionnement initial unique

Provisionnement initial unique Détails
Nombre d’objets 25 millions d’objets
Taille du jeu de données ~4,7 Tio
Taille de fichier moyenne ~200 Kio (plus gros fichier : 100 Gio)
Énumération initiale des modifications cloud 80 objets par seconde
Débit de chargement 20 objets par seconde par groupe de synchronisation
Débit de téléchargement d’espace de noms 400 objets par seconde

Énumération initiale des modifications cloud : lors de la création d’un groupe de synchronisation, l’énumération initiale des modifications cloud est la première étape à s’exécuter. Dans ce processus, le système énumère tous les éléments du partage de fichiers Azure. Pendant ce processus, il n’y aura aucune activité de synchronisation, c’est-à-dire qu’aucun élément ne sera téléchargé du point de terminaison cloud vers le point de terminaison de serveur et qu’aucun élément ne sera chargé du point de terminaison de serveur vers le point de terminaison cloud. L’activité de synchronisation reprendra une fois l’énumération initiale des modifications cloud terminée. Le taux de performances est de 80 objets par seconde. Les clients peuvent estimer le temps nécessaire pour effectuer l’énumération initiale des modifications cloud en déterminant le nombre d’éléments dans le partage cloud et en utilisant les formules suivantes pour obtenir la durée en jours.

Durée (en jours) de l’énumération initiale des modifications cloud = (Nombre d’objets dans le point de terminaison cloud)/(80 * 60 * 60 * 24)

Synchronisation initiale des données de Windows Server vers le partage de fichiers Azure : de nombreux déploiements Azure File Sync commencent avec un partage de fichiers Azure vide, car toutes les données se trouvent sur le serveur Windows. Dans ce cas, l’énumération initiale de la modification cloud est rapide, et la plupart du temps est consacrée à la synchronisation des modifications de Windows Server vers le ou les partages de fichiers Azure.

Pendant que la synchronisation charge des données sur le partage de fichiers Azure, il n’y a aucun temps d’arrêt sur le serveur de fichiers local, et les administrateurs peuvent configurer des limites réseau afin de limiter la quantité de bande passante utilisée pour le chargement des données en arrière-plan.

La synchronisation initiale est généralement limitée par le taux de chargement initial de 20 fichiers par seconde par groupe de synchronisation. Les clients peuvent estimer le temps nécessaire pour charger toutes leurs données sur Azure à l’aide de la formule suivante, qui donne la durée en jours :

Durée (en jours) du chargement de fichiers vers un groupe de synchronisation = (Nombre d’objets dans le point de terminaison du serveur)/(20 * 60 * 60 * 24)

Le fractionnement de vos données en plusieurs points de terminaison de serveur et groupes de synchronisation peut accélérer le chargement initial des données, car le chargement peut être effectué en parallèle pour plusieurs groupes de synchronisation à un taux de 20 éléments par seconde. Ainsi, deux groupes de synchronisation s’exécutent à un taux combiné de 40 éléments par seconde. La durée totale de l’opération correspondra à l’estimation de la durée pour le groupe de synchronisation ayant le plus de fichiers à synchroniser.

Débit de téléchargement d’espace de noms : Lorsqu’un nouveau point de terminaison de serveur est ajouté à un groupe de synchronisation existant, l’agent Azure File Sync ne télécharge aucun contenu de fichier à partir du point de terminaison cloud. Il synchronise d’abord l’espace de noms complet, puis déclenche un rappel en arrière-plan pour télécharger les fichiers dans leur intégralité ou, si la hiérarchisation cloud est activée, sur la stratégie de hiérarchisation de cloud définie sur le point de terminaison.

Synchronisation continue

Synchronisation continue Détails
Nombre d’objets synchronisés 125 000 objets (variation ~1 %)
Taille du jeu de données 50 GiB
Taille de fichier moyenne ~ 500 Kio
Débit de chargement 20 objets par seconde par groupe de synchronisation
Débit de téléchargement complet* 60 objets par seconde

* Si la hiérarchisation cloud est activée, vous devez avoir de meilleures performances, car seules certaines données de fichier sont téléchargées. Azure File Sync télécharge uniquement les données des fichiers mis en cache quand elles changent sur un point de terminaison. Pour les fichiers hiérarchisés ou nouvellement créés, l’agent ne télécharge pas les données de fichier et, à la place, synchronise uniquement l’espace de noms sur tous les points de terminaison de serveur. L’agent prend également en charge les téléchargements partiels de fichiers hiérarchisés à mesure qu’ils sont consultés par l’utilisateur.

Notes

Les nombres ci-dessus ne sont pas une indication des performances que vous allez rencontrer. Les performances réelles dépendent de plusieurs facteurs comme indiqué au début de cette section.

En règle générale pour votre déploiement, gardez ces quelques points à l’esprit :

  • Le débit d’objets est proportionnel au nombre de groupes de synchronisation sur le serveur. Si vous fractionnez les données en plusieurs groupes de synchronisation sur un serveur, vous obtenez un meilleur débit qui est également limité par le serveur et le réseau.
  • Le débit d’objets est inversement proportionnel au débit de MiB par seconde. Pour les plus petits fichiers, le débit est plus élevé en termes de nombre d’objets traités par seconde, mais inférieur en termes de MiB par seconde. À l’inverse, pour les plus gros fichiers, moins d’objets sont traités par seconde, mais le débit de MiB par seconde est supérieur. Le débit de MiB par seconde est limité par les objectifs d’échelle d’Azure Files.

Voir aussi