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.

¹ 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. ² 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.

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

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

^{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.

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

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.

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 :

Provisionnement initial unique

É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

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

À 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

• Comprendre les performances d’Azure Files
• Planification d’un déploiement Azure Files
• Planification d’un déploiement de synchronisation de fichiers Azure