Schaalbaarheids- en prestatiedoelen voor Azure Files

Azure Files biedt volledig beheerde bestandsshares in de cloud die toegankelijk zijn via SMB- en NFS-protocollen voor het delen van bestanden. In dit artikel worden de schaalbaarheids- en prestatiedoelen voor Azure Files besproken. Naast de limieten die zijn ingesteld door Azure Files, kunnen andere variabelen in uw implementatie van invloed zijn op de doelen die in dit artikel worden vermeld. U moet uw gebruikspatroon testen om te bepalen of de schaalbaarheid en prestaties van Azure Files voldoen aan uw vereisten.

In Azure is een resource een beheerbaar item dat u maakt en configureert binnen uw Azure-abonnementen en -resourcegroepen. Resources worden aangeboden door resourceproviders, die beheerservices zijn die specifieke typen resources leveren. Hoewel u met veel resources kunt werken om een workload in Azure te implementeren, is Azure Files gebaseerd op twee belangrijke resources:

• Opslagaccounts, aangeboden door de Microsoft.Storage resourceprovider. Opslagaccounts zijn resources op het hoogste niveau die een gedeelde opslaggroep, IOPS en doorvoer vertegenwoordigen waarin u klassieke bestandsshares of andere opslagbronnen kunt implementeren, afhankelijk van het type opslagaccount. Alle opslagresources die in een opslagaccount worden geïmplementeerd, delen de limieten die van toepassing zijn op dat opslagaccount. Klassieke bestandsshares ondersteunen zowel de protocollen voor het delen van SMB- als NFS-bestanden.

• Bestandsshares (preview), aangeboden door de Microsoft.FileShares resourceprovider. Bestandsshares zijn een nieuw resourcetype op het hoogste niveau dat de implementatie van Azure Files vereenvoudigt door het opslagaccount te elimineren. In tegenstelling tot klassieke bestandsshares, die moeten worden geïmplementeerd in een opslagaccount, worden bestandsshares rechtstreeks geïmplementeerd in de resourcegroep, zoals opslagaccounts zelf, of andere Azure-resources waarmee u bekend bent, zoals virtuele machines, schijven of virtuele netwerken. Bestandsshares ondersteunen het NFS-protocol voor het delen van bestanden. Als u SMB nodig hebt, kiest u klassieke bestandsshares voor uw implementatie.

Klassieke schaaldoelen voor bestandsshares (Microsoft.Storage)

Er zijn twee typen limieten die van toepassing zijn op opslagaccounts en klassieke bestandsshares:

• Besturingsvlaklimieten, die worden afgedwongen door de Microsoft.Storage resourceprovider en die van toepassing zijn op beheeraanvragen zoals het maken, bijwerken of verwijderen van het opslagaccount of andere onderliggende resources, waaronder maar niet beperkt tot klassieke bestandsshares.

• Gegevensvlaklimieten, die worden afgedwongen door het Azure-opslagplatform, en zijn van toepassing op zaken zoals het maken en verwijderen van bestanden en mappen via SMB, NFS, FileREST en andere protocollen. Om oudere redenen zijn sommige beheerbewerkingen, zoals het maken, bijwerken of verwijderen van klassieke bestandsshares, ook beschikbaar via het gegevensvlak (FileREST-protocol). Voor beheeraanvragen die rechtstreeks naar het Azure-opslagplatform worden gedaan, Microsoft.Storage zijn de limieten niet van toepassing.

Limieten voor microsoft.Storage-besturingsvlak

De volgende limieten gelden voor opslagaccounts of onderliggende resources van het opslagaccount, zoals klassieke bestandsshares.

Limieten voor gegevensvlak van opslagaccount

Opslagaccounts hebben enigszins verschillende limieten, afhankelijk van de SKU en het type opslagaccount dat wordt gebruikt. De SKU van het opslagaccount is een combinatie van de medialaag, de iteratie van het factureringsmodel en redundantie. Het type opslagaccount is een extra wijziging die bepaalt welke opslagservices, functies en factureringsmodellen worden ondersteund. Voor klassieke bestandsshares zijn er vier combinaties:

• Met SSD ingerichte v2-opslagaccounts, die worden vertegenwoordigd door het FileStorage type opslagaccount en de SKU's van het PremiumV2_LRS opslagaccount of PremiumV2_ZRS het opslagaccount. Deze opslagaccounts kunnen alleen klassieke bestandsshares bevatten en kunnen niet worden gebruikt voor het implementeren van andere opslagbronnen, zoals blobcontainers, wachtrijen of tabellen. Klassieke bestandsshares die in deze opslagaccounts zijn geïmplementeerd, bevinden zich altijd op de SSD-medialaag en worden gefactureerd met behulp van het ingerichte v2-factureringsmodel.

• HDD-ingerichte v2-opslagaccounts, die worden vertegenwoordigd door het FileStorage type opslagaccount en de StandardV2_LRS, StandardV2_ZRSStandardV2_GRSof StandardV2_GZRS opslagaccount-SKU's. Deze opslagaccounts kunnen alleen klassieke bestandsshares bevatten en kunnen niet worden gebruikt voor het implementeren van andere opslagbronnen, zoals blobcontainers, wachtrijen of tabellen. Klassieke bestandsshares die in deze opslagaccounts zijn geïmplementeerd, bevinden zich altijd op de HDD-medialaag en worden gefactureerd met behulp van het ingerichte v2-factureringsmodel.

• Met SSD ingerichte v1-opslagaccounts, die worden vertegenwoordigd door het FileStorage type opslagaccount en de SKU's van het Premium_LRS opslagaccount of Premium_ZRS het opslagaccount. Deze opslagaccounts kunnen alleen klassieke bestandsshares bevatten en kunnen niet worden gebruikt voor het implementeren van andere opslagbronnen, zoals blobcontainers, wachtrijen of tabellen. Klassieke bestandsshares die in deze opslagaccounts zijn geïmplementeerd, bevinden zich altijd op de SSD-medialaag en worden gefactureerd met behulp van het ingerichte v1-factureringsmodel.

• HDD-opslagaccounts voor betalen per gebruik, die worden vertegenwoordigd door het StorageV2 opslagaccounttype en de Standard_LRS, Standard_ZRS, Standard_GRS, Standard_GZRS, Standard_RAGRS, of Standard_RAGZRS opslagaccount SKU's. Deze opslagaccounts kunnen klassieke bestandsshares of andere opslagbronnen bevatten, zoals blobcontainers, wachtrijen en tabellen. Klassieke bestandsshares die in deze opslagaccounts zijn geïmplementeerd, bevinden zich altijd op de HDD-medialaag en worden gefactureerd met het factureringsmodel betalen per gebruik.

  Note

  Hoewel u klassieke bestandsshares kunt implementeren in opslagaccounts met de Standard_RAGRS of Standard_RAGZRS opslagaccount-SKU's, biedt Azure Files geen ondersteuning voor de leestoegankelijkheidsmodus voor geografisch redundante opslagaccounts. Deze klassieke bestandsshares maken impliciet gebruik van de Standard_GRS SKU's of Standard_GZRS het opslagaccount. Andere opslagbronnen, zoals blobcontainers, ondersteunen wel de leestoegankelijkheidsmodus en kunnen in deze opslagaccounts worden gebruikt.

De volgende limieten gelden voor het gegevensvlak van het opslagaccount. Alles in het opslagaccount, waaronder klassieke bestandsshares, blobcontainers, tabellen of wachtrijen, delen deze limieten.

De volgende geselecteerde regio's hebben een verhoogde maximale IOPS en doorvoer voor HDD-opslagaccounts met betalen per gebruik (StorageV2alleen):

• East Asia
• Southeast Asia
• Australia East
• Brazil South
• Canada Central
• China - oost 2
• China - noord 3
• North Europe
• West Europe
• France Central
• West-Centraal Duitsland
• Central India
• Japan East
• Jio India West
• Korea Central
• Norway East
• Zuid-Afrika - noord
• Sweden Central
• UAE North
• UK South
• Central US
• East US
• Oostelijke Verenigde Staten 2
• VS overheid Virginia
• VS overheid Arizona
• Noord-Centraal VS
• Zuid-Centraal Verenigde Staten
• West US
• Westelijke Verenigde Staten 2
• Westelijke VS 3

Limieten voor het klassieke gegevensvlak voor bestandsshares

De volgende limieten gelden op het niveau van de klassieke bestandsshare. Alle klassieke bestandsshares gelden ook voor de limieten van het opslagaccount waarin ze worden geïmplementeerd:

• Met SSD en HDD ingerichte v2-opslagaccounts: u kunt niet meer opslag, IOPS of doorvoer inrichten dan het opslagaccount ondersteunt, maar ingerichte v2-bestandsshares kunnen op een best-effort basis een piek in IOPS op basis van tegoeden boven de ingerichte IOPS ondersteunen. Als meerdere klassieke bestandsshares in het account tegelijkertijd bursten, worden de prestaties beperkt tot de IOPS-limieten van het opslagaccount.

• Met SSD ingerichte v1-opslagaccounts: u kunt niet meer opslag inrichten dan het opslagaccount ondersteunt, maar u kunt meer IOPS of doorvoer inrichten dan het opslagaccount ondersteunt. Als het totale gebruik van IOPS of doorvoer de limieten van het opslagaccount overschrijdt, worden aanvragen beperkt op het niveau van het opslagaccount.

• HDD-opslagaccounts op basis van verbruik: U kunt een onbeperkt aantal klassieke bestandsshares maken, elk met een capaciteit tot 100 TiB. Hoewel elke klassieke bestandsshare theoretisch de limieten voor IOPS en doorvoer van het opslagaccount kan bereiken, worden aanvragen beperkt als het gecombineerde gebruik van alle resources in het opslagaccount (klassieke bestandsshares, blobcontainers, tabellen en wachtrijen) deze limieten overschrijdt.

¹ Metagegevensbewerkingen zijn bewerkingen die bestandsingangen bewerken, zoals het openen van een bestand of map. De maximale IOPS-limiet voor metagegevens geeft de maximale IOPS op die kan worden gebruikt voor metagegevens, ongeacht de hoeveelheid ingerichte IOPS die een bestandsshare heeft. SMB-shares die zijn opgeslagen op SSD kunnen maximaal 35.000 IOPS worden geschaald door gebruik te maken van de functie voor het opslaan van metagegevens. Zie IOPS voor metagegevens bewaken voor hulp.
² Azure Files dwingt bepaalde naamgevingsregels af voor map- en bestandsnamen.

Klassieke schaaldoelen voor bestandsshares voor afzonderlijke bestanden

Bestandsschaaldoelen zijn van toepassing op afzonderlijke bestanden die zijn opgeslagen in klassieke bestandsshares. De mogelijkheid om de limieten voor een afzonderlijk bestand te bereiken, is onderhevig aan de limieten van de klassieke bestandsshare en van het opslagaccount waarin het zich bevindt.

* Het maximum aantal gelijktijdige ingangen per bestand en map is een zachte limiet voor klassieke bestandsshares op de SSD-medialaag met behulp van het SMB-protocol. Als u deze limiet wilt overschrijden, kunt u caching van metagegevens inschakelen en registreren voor verhoogde limieten voor bestandsingangen (preview).

Schaaldoelen voor bestandsshares (Microsoft.FileShares)

Er zijn twee typen limieten die van toepassing zijn op bestandsshares:

• Limieten voor het besturingsvlak, die worden afgedwongen door de Microsoft.FileShares resourceprovider en die van toepassing zijn op beheeraanvragen zoals het maken, bijwerken of verwijderen van de bestandsshare of onderliggende resources, zoals momentopnamen van bestandsshares.

• Gegevensvlaklimieten, die worden afgedwongen door het Azure-opslagplatform, en zijn van toepassing op zaken zoals het maken en verwijderen van bestanden en mappen via het NFS-protocol voor het delen van bestanden.

Limieten voor microsoft.FileShares-besturingsvlak

De volgende limieten zijn van toepassing op de bestandsshare en op onderliggende resources van de bestandsshare, zoals momentopnamen van bestandsshares.

¹Microsoft.FileShares maakt gebruik van een vergelijkbaar beperkingsalgoritmen voor beheeraanvragen, zoals Azure Resource Manager zelf gebruikt. API-beperking wordt beheerd met behulp van een bucket-algoritme voor tokens. De tokenbucket vertegenwoordigt het maximum aantal aanvragen dat u voor elke seconde kunt verzenden. Wanneer u het maximum aantal aanvragen bereikt, bepaalt de doorvoersnelheid hoe snel nieuwe aanvragen worden toegevoegd aan de bucket.

Gegevensvlakdoelen voor bestandsshares

De volgende limieten gelden op het niveau van de bestandsshare en worden afgedwongen op het gegevensvlak. Bestandsshares maken gebruik van het ingerichte v2-factureringsmodel.

¹ Metagegevensbewerkingen zijn bewerkingen die bestandsingangen bewerken, zoals het openen van een bestand of map. De maximale IOPS-limiet voor metagegevens geeft de maximale IOPS op die kan worden gebruikt voor metagegevens, ongeacht de hoeveelheid ingerichte IOPS die een bestandsshare heeft.

Schaaldoelen voor bestandsshares voor afzonderlijke bestanden

Bestandsschaaldoelen zijn van toepassing op afzonderlijke bestanden die zijn opgeslagen in een bestandsshare. De mogelijkheid om de limieten voor een afzonderlijk bestand te bereiken, is onderhevig aan de limieten van de bestandsshare.

Zie ook

• Een Azure Files-implementatie plannen
• Inzicht in de prestaties van Azure Files
• Inzicht in Facturering van Azure Files