Partager via

Objectifs de scalabilité et de performances pour Azure Files et Azure File Sync

  • Article

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 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 à

Modèle de gestion Modèle de facturation Niveau multimédia Redondance PME NFS
Microsoft.Storage V2 approvisionné HDD (standard) Local (LRS) Oui Non
Microsoft.Storage V2 approvisionné HDD (standard) Zone (ZRS) Oui Non
Microsoft.Storage V2 approvisionné HDD (standard) Géo (GRS) Oui Non
Microsoft.Storage V2 approvisionné HDD (standard) GeoZone (GZRS) Oui Non
Microsoft.Storage V1 approvisionné SSD (Premium) Local (LRS) Oui Oui
Microsoft.Storage V1 approvisionné SSD (Premium) Zone (ZRS) Oui Oui
Microsoft.Storage Paiement à l’utilisation HDD (standard) Local (LRS) Oui Non
Microsoft.Storage Paiement à l’utilisation HDD (standard) Zone (ZRS) Oui Non
Microsoft.Storage Paiement à l’utilisation HDD (standard) Géo (GRS) Oui Non
Microsoft.Storage Paiement à l’utilisation HDD (standard) GeoZone (GZRS) Oui Non

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 FileStorage : les comptes de stockage FileStorage vous permettent de déployer des partages de fichiers Azure avec un modèle de facturation provisionné. 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.

  • Comptes de stockage à usage général (GPv2) : les comptes de stockage GPv2 vous permettent de déployer des partages de fichiers de paiement à l’utilisation sur du matériel 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.

Attribut SSD approvisionné v1 HDD approvisionné v2 HDD, paiement à l'utilisation
Type de compte de stockage FileStorage FileStorage StorageV2
Références SKU
  • Premium_LRS
  • Premium_ZRS
  • StandardV2_LRS
  • StandardV2_ZRS
  • StandardV2_GRS
  • StandardV2_GZRS
  • Standard_LRS
  • Standard_ZRS
  • Standard_GRS
  • Standard_GZRS
Nombre de comptes de stockage par région par abonnement 250 250 250
Capacité de stockage maximale 100 Tio 4 Pio 5 Pio
Nombre maximal de partages de fichiers 1024 (recommandé d’utiliser 50 ou moins) 50 Illimité (recommandé pour utiliser 50 ou moins)
Nombre maximal d’E/S par seconde 102 400 IOPS 50 000 E/S par seconde 20 000 IOPS
Débit maximal 10,340 Mio/s 5 120 Mio/s
  • Sélectionner les régions :
    • Entrée : 7 680 Mio/s
    • Sortie : 25 600 Mio/s
  • Par défaut :
    • Entrée : 3 200 Mio/s
    • Sortie : 6 400 Mio/s
Nombre maximal de règles de réseau virtuel 200 200 200
Nombre maximal de règles d’adresse IP 200 200 200
Opérations de lecture de gestion 800 toutes les 5 minutes 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 10 par seconde/1 200 par heure
Opérations de liste de gestion 100 toutes les 5 minutes 100 toutes les 5 minutes 100 toutes les 5 minutes

Régions sélectionnées avec un débit maximal accru pour le paiement à l’utilisation HDD

Les régions suivantes ont un débit maximal accru pour les comptes de stockage de paiement à l’utilisation HDD (StorageV2) :

  • Asie Est
  • Asie Sud-Est
  • Australie Est
  • Brésil Sud
  • Centre du Canada
  • Chine orientale 2
  • Chine Nord 3
  • Europe Nord
  • Europe Ouest
  • France Centre
  • Allemagne Centre-Ouest
  • Inde centrale
  • Japon Est
  • Inde Ouest Jio
  • Centre de la Corée
  • Norvège Est
  • Afrique du Sud Nord
  • Suède Centre
  • Émirats arabes unis Nord
  • Sud du Royaume-Uni
  • USA Centre
  • USA Est
  • USA Est 2
  • Gouvernement américain - Virginie
  • Gouvernement des États-Unis – Arizona
  • Centre-Nord des États-Unis
  • États-Unis - partie centrale méridionale
  • USA Ouest
  • USA Ouest 2
  • USA Ouest 3

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 SSD approvisionné v1 HDD approvisionné v2 HDD, paiement à l'utilisation
Unité d’approvisionnement de stockage 1 Gio 1 Gio N/A
Unité de provisionnement IOPS N/A 1 E/s N/A
Unité d’approvisionnement de débit N/A 1 Mio/s N/A
La taille minimale de stockage 100 Gio (approvisionné) 32 Gio (approvisionné) 0 octets
Taille de stockage maximale 100 Tio 256 Tio 100 Tio
Nombre maximal de fichiers Illimité Illimité Illimité
Nombre maximal d’E/S par seconde 102 400 IOPS (dépendant de l’approvisionnement) 50 000 IOPS (dépendant de l’approvisionnement) 20 000 IOPS
Débit maximal 10 340 Mio /s (dépendant de l’approvisionnement) 5 120 IOPS (dépendant de l’approvisionnement) Jusqu’à limites de compte de stockage
Nombre maximal d’instantanés de partage 200 instantanés 200 instantanés 200 instantanés
Longueur maximale du nom de fichier 3 (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 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 255 caractères
Limite de liaison codée en dur (NFS uniquement) 178 N/A N/A
Nombre maximal de canaux SMB Multichannel 4 N/A N/A
Nombre maximal de stratégies d’accès stockées par partage de fichiers 5 5 5

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 SSD approvisionné v1 HDD approvisionné v2 HDD, paiement à l'utilisation
Taille maximale du fichier 4 Tio 4 Tio 4 Tio
Nombre maximal d’IOPS de données par fichier 8 000 IOPS 1 000 E/S par seconde 1 000 E/S par seconde
Débit maximal par fichier 1 024 Mio/s 60 Mio/s 60 Mio/s
Nombre maximal de descripteurs simultanés pour le répertoire racine 10 000 descripteurs 10 000 descripteurs 10 000 descripteurs
Descripteurs simultanés maximums par fichier et répertoire 2 000 handles 2 000 handles 2 000 handles

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 100 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 :

  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.

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.

Voir aussi