Objectifs de scalabilité et de performances pour Azure Files et Azure File Sync
Azure Files offre des partages de fichiers entièrement managés dans le cloud accessibles via les protocoles de système de fichiers SMB (Server Message Block) et Network File System (NFS). Cet article décrit les objectifs de scalabilité et de performances pour les comptes de stockage Azure, 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 |  |
 |
| Partages de fichiers Standard (GPv2), GRS/GZRS | |
|
| Partages de fichiers Premium (FileStorage), LRS/ZRS | |
|
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 | 102 400 IOPS |
Débit (entrée + sortie) pour LRS/GRS
|
|
10,340 Mio/s |
Débit (entrée + sortie) pour le stockage redondant interzone
|
|
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 |
|
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 | 100 Tio |
| Nombre maximal de fichiers dans un partage de fichiers | Aucune limite | Aucune limite |
| Taux de requêtes maximal (IOPS max.) | 20 000 |
|
| Débit (entrée + sortie) pour un partage de fichiers unique (Mio/sec) | Jusqu’à limites de compte de stockage | 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 chemin2 (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 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 |
| Services de synchronisation de stockage par abonnement | 15 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 privés par service de synchronisation de stockage | 100 points de terminaison privés | 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
Comme l’agent Azure File Sync s’exécute sur une machine Windows Server qui se connecte aux partages de fichiers Azure, les performances effectives de synchronisation dépendent de plusieurs facteurs dans votre infrastructure : la configuration de Windows Server et des disques sous-jacents, la bande passante réseau entre le serveur et le stockage Azure, la taille de fichier, 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 :
- 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.
- 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.
Remarque
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 du service cloud. Par conséquent, les performances de chargement sont 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 que nous avons observés pendant un 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 de modification cloud : lors de la création d’un groupe de synchronisation, l’énumération initiale de modification 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. Il n’y a aucune activité de synchronisation pendant ce processus. Aucun élément n’est téléchargé du point de terminaison cloud vers le point de terminaison de serveur et qu’aucun élément n’est 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. Vous pouvez estimer le temps nécessaire pour effectuer l’énumération initiale de modification 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 du Serveur Windows 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 ces cas, l’énumération initiale de modification cloud est rapide et la plupart du temps 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. Les administrateurs peuvent configurer des limites réseau afin de restreindre 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 avez probablement 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 les points 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.
Remarque
Ces nombres ne constituent 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.
À titre général 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 Mio par seconde. À l’inverse, pour les fichiers les plus volumineux, moins d’objets sont traités par seconde, mais le débit de Mio par seconde est supérieur. Le débit de MiB par seconde est limité par les objectifs d’échelle d’Azure Files.