Objectifs en matière d’évolutivité et de performances pour Azure Files

Azure Files offre des partages de fichiers entièrement managés dans le cloud accessibles via les protocoles de partage de fichiers SMB et NFS. Cet article décrit les objectifs de scalabilité et de performances pour Azure Files. Outre les limites définies par Azure Files, d’autres variables de votre déploiement peuvent affecter les cibles répertoriées dans cet article. Vous devez tester votre modèle d’utilisation pour déterminer si l’extensibilité et les performances d’Azure Files répondent à vos besoins.

Dans Azure, une ressource est un élément gérable que vous créez et configurez dans vos abonnements Et groupes de ressources Azure. Les ressources sont proposées par les fournisseurs de ressources, qui sont des services de gestion qui fournissent des types de ressources spécifiques. Bien que vous puissiez utiliser de nombreuses ressources pour déployer une charge de travail dans Azure, Azure Files se concentre sur deux ressources clés :

• Comptes de stockage, proposés par le Microsoft.Storage fournisseur de ressources. Les comptes de stockage sont des ressources de niveau supérieur qui représentent un pool partagé de stockage, d’E/S par seconde et de débit dans lequel vous pouvez déployer des partages de fichiers classiques ou d’autres ressources de stockage, en fonction du type de compte de stockage. Toutes les ressources de stockage qui sont déployées dans un compte de stockage partagent les limites qui s’appliquent à ce compte de stockage. Les partages de fichiers classiques prennent en charge les protocoles de partage de fichiers SMB et NFS.

• Partages de fichiers (préversion), proposés par le Microsoft.FileShares fournisseur de ressources. Les partages de fichiers sont un nouveau type de ressource de niveau supérieur qui simplifie le déploiement d’Azure Files en éliminant le compte de stockage. Contrairement aux partages de fichiers classiques, qui doivent être déployés dans un compte de stockage, les partages de fichiers sont déployés directement dans le groupe de ressources, comme les comptes de stockage eux-mêmes, ou d’autres ressources Azure que vous connaissez peut-être comme des machines virtuelles, des disques ou des réseaux virtuels. Les partages de fichiers prennent en charge le protocole de partage de fichiers NFS : si vous avez besoin de SMB, choisissez des partages de fichiers classiques pour votre déploiement.

Cibles de mise à l’échelle de partage de fichiers classiques (Microsoft.Storage)

Il existe deux types de limites qui s’appliquent aux comptes de stockage et aux partages de fichiers classiques :

• Limites du plan de contrôle, qui sont appliquées par le Microsoft.Storage fournisseur de ressources et s’appliquent aux demandes de gestion telles que la création, la mise à jour ou la suppression du compte de stockage ou d’autres ressources enfants, notamment les partages de fichiers classiques.

• Les limites du plan de données, appliquées par la plateforme de stockage Azure, s’appliquent à des éléments tels que la création et la suppression de fichiers et de dossiers via SMB, NFS, FileREST et d’autres protocoles. Pour des raisons héritées, certaines opérations de gestion, telles que la création, la mise à jour ou la suppression de partages de fichiers classiques, sont également disponibles via le plan de données (protocole FileREST). Pour les demandes de gestion adressées directement à la plateforme de stockage Azure, Microsoft.Storage les limites ne s’appliquent pas.

Limites du plan de contrôle Microsoft.Storage

Les limites suivantes s’appliquent aux comptes de stockage ou aux ressources enfants du compte de stockage, telles que les partages de fichiers classiques.

Limites du plan de données du compte de stockage

Les comptes de stockage ont des limites légèrement différentes en fonction de la référence SKU et du type du compte de stockage utilisé. La référence SKU du compte de stockage est une combinaison du niveau multimédia, de l’itération du modèle de facturation et de la redondance. Le type du compte de stockage est un modificateur supplémentaire qui détermine les services de stockage, les fonctionnalités et les modèles de facturation qu’il prend en charge. Pour les partages de fichiers classiques, il existe quatre combinaisons :

• Comptes de stockage v2 approvisionnés ssd, représentés par le type de FileStorage compte de stockage et les références SKU du PremiumV2_LRS ou PremiumV2_ZRS compte de stockage. Ces comptes de stockage peuvent contenir uniquement des partages de fichiers classiques et ne peuvent pas être utilisés pour déployer d’autres ressources de stockage telles que des conteneurs d’objets blob, des files d’attente ou des tables. Les partages de fichiers classiques déployés dans ces comptes de stockage sont toujours sur le niveau multimédia SSD et facturés à l’aide du modèle de facturation v2 approvisionné.

• Comptes de stockage v2 approvisionnés HDD, qui sont représentés par le type de FileStorage compte de stockage et les références SKU de compte de stockage, StandardV2_LRS, StandardV2_ZRS, StandardV2_GRS les StandardV2_GZRSréférences SKU du compte de stockage. Ces comptes de stockage peuvent contenir uniquement des partages de fichiers classiques et ne peuvent pas être utilisés pour déployer d’autres ressources de stockage telles que des conteneurs d’objets blob, des files d’attente ou des tables. Les partages de fichiers classiques déployés dans ces comptes de stockage sont toujours sur le niveau multimédia HDD et facturés à l’aide du modèle de facturation v2 approvisionné.

• Comptes de stockage v1 approvisionnés SSD, représentés par le type de FileStorage compte de stockage et les références SKU du Premium_LRSPremium_ZRS compte de stockage. Ces comptes de stockage peuvent contenir uniquement des partages de fichiers classiques et ne peuvent pas être utilisés pour déployer d’autres ressources de stockage telles que des conteneurs d’objets blob, des files d’attente ou des tables. Les partages de fichiers classiques déployés dans ces comptes de stockage sont toujours sur le niveau multimédia SSD et facturés à l’aide du modèle de facturation v1 approvisionné.

• Comptes de stockage HDD à paiement à l'utilisation, représentés par le StorageV2 type de compte de stockage et les Standard_LRS, Standard_ZRS, Standard_GRS, Standard_GZRS, Standard_RAGRSou Standard_RAGZRS SKU de compte de stockage. Ces comptes de stockage peuvent contenir des partages de fichiers classiques ou d’autres ressources de stockage telles que des conteneurs d’objets blob, des files d’attente et des tables. Les partages de fichiers classiques déployés dans ces comptes de stockage sont toujours sur le niveau de support HDD et facturés selon le modèle de facturation à l'utilisation.

  Note

  Bien que vous puissiez déployer des partages de fichiers classiques dans des comptes de stockage avec les références SKU du compte de stockage, Standard_RAGRS Azure Files ne prend pas en charge le Standard_RAGZRS mode d’accessibilité en lecture pour les comptes de stockage géoredondants. Ces partages de fichiers classiques utilisent implicitement les références SKU du Standard_GRS ou Standard_GZRS compte de stockage. D’autres ressources de stockage, telles que les conteneurs d’objets blob, prennent en charge le mode d’accessibilité en lecture et peuvent être entremêlées dans ces comptes de stockage.

Les limites suivantes s’appliquent au plan de données du compte de stockage. Tous les éléments du compte de stockage, y compris les partages de fichiers classiques, les conteneurs d’objets blob, les tables ou les files d’attente, partagent ces limites.

Les régions sélectionnées suivantes bénéficient d'une augmentation du nombre maximal d'IOPS et du débit pour les comptes de stockage HDD à la carte uniquement (StorageV2) :

• East Asia
• Southeast Asia
• Australia East
• Brazil South
• Canada Central
• Chine orientale 2
• Chine Nord 3
• North Europe
• West Europe
• France Central
• Allemagne Centre-Ouest
• Central India
• Japan East
• JIO Inde Ouest
• Korea Central
• Norway East
• Afrique du Sud Nord
• Sweden Central
• UAE North
• UK South
• Central US
• East US
• USA Est 2
• Gouvernement américain - Virginie
• Gouvernement des États-Unis – Arizona
• Centre-Nord des États-Unis
• États-Unis - partie centrale méridionale
• West US
• USA Ouest 2
• USA Ouest 3

Limites du plan de données du partage de fichiers classique

Les limites suivantes s’appliquent au niveau du partage de fichiers classique. Tous les partages de fichiers classiques sont également soumis aux limites du compte de stockage dans lequel ils sont déployés :

• Comptes de stockage SSD et HDD approvisionnés v2 : vous ne pouvez pas provisionner plus de stockage, d’E/S par seconde ou de débit que le compte de stockage prend en charge, cependant, les partages de fichiers v2 provisionnés prennent en charge le sursaut d’IOPS basées sur le crédit au-delà des IOPS provisionnées, selon un principe de meilleure offre possible. Si plusieurs partages de fichiers classiques dans le compte sont éclatés en même temps, les performances sont limitées aux limites d’IOPS du compte de stockage.

• Comptes de stockage v1 approvisionnés SSD : vous ne pouvez pas provisionner plus de stockage que le compte de stockage pris en charge, mais vous pouvez provisionner plus d’IOPS ou de débit que le compte de stockage prend en charge. Si l’utilisation totale des E/S par seconde ou du débit dépasse les limites du compte de stockage, les demandes sont limitées au niveau du compte de stockage.

• Comptes de stockage avec paiement à l’utilisation HDD : vous pouvez créer un nombre illimité de shares de fichiers classiques, chacun jusqu’à 100 TiB, mais alors que chaque share de fichiers classique peut théoriquement consommer jusqu’à la limite du compte de stockage pour les IOPS et le débit, si l’utilisation combinée de toutes les ressources du compte de stockage (shares de fichiers classiques, conteneurs d’objets blob, tables, et files d’attente) dépasse ces limites, les demandes sont limitées.

^Les opérations de métadonnées 1 sont des opérations qui manipulent des handles de fichier, telles que l’ouverture d’un fichier ou d’un dossier. La limite maximale d’E/S par seconde de métadonnées spécifie l’IOPS maximale qui peut être utilisée pour les métadonnées, quelle que soit la quantité d’E/S par seconde provisionnée d’un partage de fichiers. Les partages SMB stockés sur SSD peuvent monter en puissance jusqu’à 35 000 IOPS à l’aide de la fonctionnalité de mise en cache des métadonnées. Pour obtenir des conseils, consultez Surveiller les E/S par seconde des métadonnées.
² Azure Files applique certaines règles de nommage pour les noms de répertoire et de fichiers.

Cibles d’échelle de partage de fichiers classiques pour les fichiers individuels

Les cibles d’échelle de fichiers s’appliquent aux fichiers individuels stockés dans des partages de fichiers classiques. Votre capacité à atteindre les limites d’un fichier individuel est soumise aux limites du partage de fichiers classique et du compte de stockage dans lequel il est contenu.

* Le nombre maximal de handles simultanés par fichier et de répertoire est une limite réversible pour les partages de fichiers classiques sur le niveau multimédia SSD à l’aide du protocole SMB. Si vous devez effectuer une mise à l’échelle au-delà de cette limite, vous pouvez activer la mise en cache des métadonnées et demander des limites accrues de manipulation de fichiers (préversion).

Cibles d’échelle de partage de fichiers (Microsoft.FileShares)

Il existe deux types de limites qui s’appliquent aux partages de fichiers :

• Limites du plan de contrôle, qui sont appliquées par le Microsoft.FileShares fournisseur de ressources et s’appliquent aux demandes de gestion telles que la création, la mise à jour ou la suppression du partage de fichiers ou des ressources enfants telles que les instantanés de partage de fichiers.

• Les limites du plan de données, appliquées par la plateforme de stockage Azure, s’appliquent à des éléments tels que la création et la suppression de fichiers et de dossiers via le protocole de partage de fichiers NFS.

Limites du plan de contrôle Microsoft.FileShares

Les limites suivantes s’appliquent au partage de fichiers et aux ressources enfants du partage de fichiers, telles que les instantanés de partage de fichiers.

¹Microsoft.FileShares utilise un algorithme de limitation similaire pour les demandes de gestion, car Azure Resource Manager lui-même utilise. La limitation des API est gérée à l’aide d’un algorithme de compartiment de jetons. Le compartiment de jetons représente le nombre maximal de demandes que vous pouvez envoyer par seconde. Lorsque vous atteignez le nombre maximal de requêtes, le taux de remplissage détermine la rapidité avec laquelle les nouvelles demandes sont ajoutées au « compartiment ».

Cibles du plan de données de partage de fichiers

Les limites suivantes s’appliquent au niveau du partage de fichiers et sont appliquées au plan de données. Les partages de fichiers utilisent le modèle de facturation v2 approvisionné.

^Les opérations de métadonnées 1 sont des opérations qui manipulent des handles de fichier, telles que l’ouverture d’un fichier ou d’un dossier. La limite maximale d’E/S par seconde de métadonnées spécifie l’IOPS maximale qui peut être utilisée pour les métadonnées, quelle que soit la quantité d’E/S par seconde provisionnée d’un partage de fichiers.

Cibles de mise à l’échelle des partages de fichiers pour les fichiers individuels

Les cibles d’échelle de fichiers s’appliquent aux fichiers individuels stockés dans un partage de fichiers. Votre capacité à atteindre les limites d’un fichier individuel est soumise aux limites du partage de fichiers.

Voir aussi

• Planification d’un déploiement Azure Files
• Comprendre les performances d’Azure Files
• Présentation de la facturation d’Azure Files