Schaalbaarheids- en prestatiedoelen in Azure Files
Azure Files biedt volledig beheerde bestandsshares in de cloud die toegankelijk zijn via de SMB- en NFS-bestandssysteemprotocollen. In dit artikel worden de schaalbaarheids- en prestatiedoelen voor Azure Files en Azure File Sync besproken.
De doelen die hier worden vermeld, kunnen worden beïnvloed door andere variabelen in uw implementatie. De prestaties van I/O voor een bestand kunnen bijvoorbeeld worden beïnvloed door het gedrag van uw SMB-client en door de beschikbare netwerkbandbreedte. U moet uw gebruikspatroon testen om te bepalen of de schaalbaarheid en prestaties van Azure Files voldoen aan uw vereisten.
Van toepassing op
| Bestands sharetype | SMB | NFS |
|---|---|---|
| Standaardbestandsshares (GPv2), LRS/ZRS |  |
 |
| Standaardbestandsshares (GPv2), GRS/GZRS | |
|
| Premium bestandsshares (FileStorage), LRS/ZRS | |
|
Azure Files-schaaldoelen
Azure-bestandsshares worden geïmplementeerd in opslagaccounts. Dat zijn objecten op het hoogste niveau die een gedeelde opslagpool vertegenwoordigen. Deze opslaggroep kan worden gebruikt om meerdere bestandsshares te implementeren. Er zijn daarom drie categorieën om rekening mee te houden: opslagaccounts, Azure-bestandsshares en afzonderlijke bestanden.
Schaaldoelen voor opslagaccounts
Schaaldoelen voor opslagaccounts zijn van toepassing op opslagaccountniveau. Er zijn twee hoofdtypen opslagaccounts voor Azure Files:
Opslagaccounts voor algemeen gebruik versie 2 (GPv2): met GPv2-opslagaccounts kunt u Azure-bestandsshares implementeren op hardware op basis van standard/harde schijven (HDD). Naast het opslaan van Azure-bestandsshares kunnen GPv2-opslagaccounts andere opslagresources, zoals blobcontainers, wachtrijen of tabellen, opslaan. Bestandsshares kunnen worden geïmplementeerd in de voor transactie geoptimaliseerde (standaard), dynamische of statische lagen.
FileStorage-opslagaccounts: Met FileStorage-opslagaccounts kunt u Azure-bestandsshares implementeren op premium-/SSD-hardware op basis van ssd's. FileStorage-accounts kunnen alleen worden gebruikt voor het opslaan van Azure-bestandsshares. Er kunnen geen andere opslagresources (blobcontainers, wachtrijen, tabellen enz.) worden geïmplementeerd in een FileStorage-account.
| Kenmerk | GPv2-opslagaccounts (standaard) | FileStorage-opslagaccounts (Premium) |
|---|---|---|
| Aantal opslagaccounts per regio per abonnement | 2501 | 2501 |
| Maximale capaciteit van opslagaccount | 5 PiB2 | 100 TiB (ingericht) |
| Maximum aantal bestandsshares | Onbeperkt | Onbeperkte, totale ingerichte grootte van alle shares moet kleiner zijn dan maximaal dan de maximale capaciteit van het opslagaccount |
| Maximum aantal gelijktijdige aanvragen | 20.000 IOPS2 | 102.400 IOPS |
Doorvoer (inkomend en uitgaand verkeer) voor LRS/GRS
|
|
10.340 MiB per seconde |
Doorvoer (inkomend en uitgaand verkeer) voor ZRS
|
|
10.340 MiB per seconde |
| Doorvoer (inkomend en uitgaand verkeer) voor combinaties van redundantie/regio's die niet worden vermeld in de vorige rij |
|
10.340 MiB per seconde |
| Maximum aantal regels voor virtuele netwerken | 200 | 200 |
| Maximum aantal IP-adresregels | 200 | 200 |
| Leesbewerkingen voor beheer | 800 per 5 minuten | 800 per 5 minuten |
| Schrijfbewerkingen voor beheer | 10 per seconde/1200 per uur | 10 per seconde/1200 per uur |
| Beheerlijstbewerkingen | 100 per 5 minuten | 100 per 5 minuten |
1 Met een quotumverhoging kunt u maximaal 500 opslagaccounts maken met standaardeindpunten per regio. Zie Quota voor Azure Storage-accounts verhogen voor meer informatie. 2 Opslagaccounts voor algemeen gebruik versie 2 ondersteunen hogere capaciteitslimieten en hogere limieten voor inkomend verkeer per aanvraag. Neem contact op met de Azure-ondersteuning om een hogere accountlimiet aan te vragen.
Schaaldoelen voor Azure-bestandsshares
Schaaldoelen voor Azure-bestandsshares zijn van toepassing op bestandsshareniveau.
| Kenmerk | Standaardbestandsshares1 | Premiumbestandsshares |
|---|---|---|
| Minimale grootte van een bestandsshare | Geen minimum | 100 GiB (ingericht) |
| Ingerichte grootte vergroten/verkleinen eenheid | N.v.t. | 1 GiB |
| Maximale grootte van een bestandsshare |
|
100 TiB |
| Maximum aantal bestanden in een bestandsshare | Geen limiet | Geen limiet |
| Maximale aanvraagsnelheid (max. IOPS) |
|
|
| Doorvoer (inkomend en uitgaand verkeer) voor één bestandsshare (MiB/sec) |
|
100 + CEILING(0,04 * ProvisionedStorageGiB) + CEILING(0,06 * ProvisionedStorageGiB) |
| Maximum aantal momentopnamen van shares | 200 momentopnamen | 200 momentopnamen |
| Maximale objectnaamlengte3 (volledige padnaam, inclusief alle mappen, bestandsnamen en backslash-tekens) | 2048 tekens | 2048 tekens |
| Maximale lengte van afzonderlijke padnaamcomponent3 (in het pad \A\B\C\D vertegenwoordigt elke letter een map of bestand dat een afzonderlijk onderdeel is) | 255 tekens | 255 tekens |
| Limiet voor vaste koppelingen (alleen NFS) | N.v.t. | 178 |
| Maximumaantal SMB Multichannel-kanalen | N.v.t. | 4 |
| Maximaal aantal opgeslagen toegangsbeleidsregels per bestandsshare | 5 | 5 |
1 De limieten voor standaardbestandsshares zijn van toepassing op alle drie de lagen die beschikbaar zijn voor standaardbestandsshares: geoptimaliseerd voor transacties, dynamisch en statisch.
2 Standaardbestandsshares zijn 5 TiB. Zie Een Azure-bestandsshare maken voor meer informatie over het maken van bestandsshares met een grootte van 100 TiB en het verhogen van bestaande standaardbestandsshares tot 100 TiB. Als u wilt profiteren van de grotere schaaldoelen, moet u uw quotum wijzigen zodat het groter is dan 5 TiB.
3 Azure Files dwingt bepaalde naamgevingsregels af voor map- en bestandsnamen.
Doelen voor vergroten/verkleinen van bestanden
Doelen voor schalen van bestanden zijn van toepassing op afzonderlijke bestanden die zijn opgeslagen in Azure-bestandsshares.
| Kenmerk | Bestanden in standaard bestandsshares | Bestanden in premium bestandsshares |
|---|---|---|
| Maximale bestandsgrootte | 4 TiB | 4 TiB |
| Maximum aantal gelijktijdige aanvragen | 1.000 IOPS | Tot 8.0001 |
| Maximaal inkomend voor een bestand | 60 MiB/sec | 200 MiB/sec (maximaal 1 GiB/s met SMB meerdere kanalen)2 |
| Maximaal uitgaand voor een bestand | 60 MiB/sec | 300 MiB/sec (maximaal 1 GiB/s met SMB meerdere kanalen)2 |
| Maximum aantal gelijktijdige ingangen voor hoofdmap3 | 10.000 ingangen | 10.000 ingangen |
| Maximum aantal gelijktijdige ingangen per bestand en map3 | 2.000 ingangen | 2.000 ingangen |
1 Van toepassing op lees- en schrijf-I/Os (meestal kleinere I/O-grootten kleiner dan of gelijk aan 64 KiB). Metagegevensbewerkingen, anders dan de lees- en schrijfbewerkingen, kunnen lager zijn. Dit zijn zachte limieten en er kan een beperking optreden buiten deze limieten.
2 Afhankelijk van netwerklimieten van computers, beschikbare bandbreedte, I/O-grootten, wachtrijdiepte en andere factoren. Zie prestaties van SMB met meerdere kanalen voor meer informatie.
3 Azure Files ondersteunt 10.000 open ingangen in de hoofdmap en 2000 open ingangen per bestand en map in de share. Het aantal actieve gebruikers dat per share wordt ondersteund, is afhankelijk van de toepassingen die toegang hebben tot de share. Als uw toepassingen geen ingang openen in de hoofdmap, kan Azure Files meer dan 10.000 actieve gebruikers per share ondersteunen. Als u Echter Azure Files gebruikt om schijfinstallatiekopieën op te slaan voor grootschalige virtuele bureaubladworkloads, hebt u mogelijk geen ingangen meer voor de hoofdmap of per bestand/map. In dit geval moet u mogelijk meerdere Azure-bestandsshares gebruiken. Zie de richtlijnen voor het aanpassen van de grootte van Azure Files voor Azure Virtual Desktop voor meer informatie.
Richtlijnen voor het aanpassen van de grootte van Azure Files voor Azure Virtual Desktop
Een populaire use case voor Azure Files is het opslaan van gebruikersprofielcontainers en schijfinstallatiekopieën voor Azure Virtual Desktop, met behulp van FSLogix of App attach. In grootschalige Azure Virtual Desktop-implementaties hebt u mogelijk geen ingangen meer voor de hoofdmap of per bestand/map als u één Azure-bestandsshare gebruikt. In deze sectie wordt beschreven hoe ingangen worden gebruikt door verschillende typen schijfinstallatiekopieën en biedt richtlijnen voor de grootte, afhankelijk van de technologie die u gebruikt.
FSLogix
Als u FSLogix met Azure Virtual Desktop gebruikt, zijn uw gebruikersprofielcontainers virtuele harde schijf (VHD) of Hyper-V V-bestanden (virtuele harde schijf) en worden ze gekoppeld in een gebruikerscontext, niet in een systeemcontext. Elke gebruiker opent één hoofdmaphandgreep, die naar de bestandsshare moet gaan. Azure Files kan maximaal 10.000 gebruikers ondersteunen, ervan uitgaande dat u de bestandsshare (\\storageaccount.file.core.windows.net\sharename) + de profielmap (%sid%_%username%) + profielcontainer (profile_%username.vhd(x)) hebt.
Als u de limiet van 10.000 gelijktijdige ingangen voor de hoofdmap bereikt of als gebruikers slechte prestaties ondervinden, gebruikt u een extra Azure-bestandsshare en distribueert u de containers tussen de shares.
Waarschuwing
Hoewel Azure Files maximaal 10.000 gelijktijdige gebruikers van één bestandsshare kan ondersteunen, is het essentieel om uw workloads goed te testen op basis van de grootte en het type bestandsshare dat u hebt gemaakt. Uw vereisten kunnen variëren op basis van gebruikers, profielgrootte en workload.
Als u bijvoorbeeld 2400 gelijktijdige gebruikers hebt, hebt u 2400 ingangen nodig in de hoofdmap (één voor elke gebruiker), die onder de limiet van 10.000 open ingangen ligt. Voor FSLogix-gebruikers is het bereiken van de limiet van 2000 geopende bestands- en mapingangen zeer onwaarschijnlijk. Als u één FSLogix-profielcontainer per gebruiker hebt, gebruikt u slechts twee bestands-/mapingangen: één voor de profielmap en één voor het profielcontainerbestand. Als gebruikers elk twee containers hebben (profiel en ODFC), hebt u één extra ingang nodig voor het ODFC-bestand.
App koppelen met CimFS
Als u MSIX-appkoppeling of app-bijlage gebruikt om toepassingen dynamisch te koppelen, kunt u CimFS-bestanden (Composite Image File System) of VHD/VHDX-bestanden gebruiken voor schijfinstallatiekopieën. In beide gevallen zijn de schaallimieten per VM gekoppeld aan de installatiekopieën, niet per gebruiker. Het aantal gebruikers is niet relevant bij het berekenen van schaallimieten. Wanneer een virtuele machine wordt opgestart, wordt de schijfinstallatiekopie gekoppeld, zelfs als er geen gebruikers zijn.
Als u App Attach gebruikt met CimFS, worden de schijfinstallatiekopieën alleen gebruikt voor de schijfinstallatiekopiebestanden. Ze gebruiken geen ingangen in de hoofdmap of de map met de schijfinstallatiekopie. Omdat een CimFS-installatiekopie echter een combinatie is van het CIM-bestand en ten minste twee andere bestanden, hebt u voor elke VM die de schijfinstallatiekopie koppelt, één ingang nodig voor drie bestanden in de map. Dus als u 100 VM's hebt, hebt u 300 bestandsingangen nodig.
Als het aantal VM's per app groter is dan 2000, is het mogelijk dat er geen bestandsingangen meer zijn. Gebruik in dit geval een extra Azure-bestandsshare.
App koppelen met VHD/VHDX
Als u app-bijlage gebruikt met VHD-/VHDX-bestanden, worden de bestanden gekoppeld in een systeemcontext, niet in een gebruikerscontext en worden ze gedeeld en alleen-lezen. Meer dan één ingang in het VHDX-bestand kan worden gebruikt door een verbindingssysteem. Als u binnen de schaallimieten van Azure Files wilt blijven, moet het aantal VM's vermenigvuldigd met het aantal apps kleiner zijn dan 10.000 en mag het aantal VM's per app niet groter zijn dan 2000. De beperking is dus afhankelijk van wat u eerst hebt bereikt.
In dit scenario kunt u de limiet per bestand/map bereiken met 2000 koppels van één VHD/VHDX. Als de share meerdere VHD-/VHDX-bestanden bevat, kunt u eerst de limiet voor de hoofdmap bereiken. 100 VM's die 100 gedeelde VHDX-bestanden koppelen, hebben bijvoorbeeld de limiet van 10.000 ingangen voor de hoofdmap.
In een ander voorbeeld vereisen 100 VM's die toegang hebben tot 20 apps 2000 hoofdmapingangen (100 x 20 = 2000), die ruim binnen de limiet van 10.000 voor hoofdmapingangen ligt. U hebt ook een bestandsingang en een mapgreep nodig voor elke VM die de VHD(X)-installatiekopie koppelen, dus 200 ingangen in dit geval (100 bestandsingangen + 100 mapgrepen), die comfortabel onder de limiet van 2000 ingangen per bestand/map ligt.
Als u de limieten voor maximale gelijktijdige ingangen voor de hoofdmap of per bestand/map bereikt, gebruikt u een extra Azure-bestandsshare.
Azure File Sync-schaaldoelen
In de volgende tabel wordt aangegeven welke doelen zacht zijn, wat de door Microsoft geteste grens vertegenwoordigt en hard, wat een afgedwongen maximum aangeeft:
| Bron | Doel | Harde limiet |
|---|---|---|
| Opslagsynchronisatieservices per regio | 100 opslagsynchronisatieservices | Ja |
| Opslagsynchronisatieservices per abonnement | 15 Opslagsynchronisatieservices | Ja |
| Synchronisatiegroepen per opslagsynchronisatieservice | 200 synchronisatiegroepen | Ja |
| Geregistreerde servers per opslagsynchronisatieservice | 99 servers | Ja |
| Privé-eindpunten per opslagsynchronisatieservice | 100 privé-eindpunten | Ja |
| Cloudeindpunten per synchronisatiegroep | 1 cloudeindpunt | Ja |
| Servereindpunten per synchronisatiegroep | 100 servereindpunten | Yes |
| Servereindpunten per server | 30 servereindpunten | Ja |
| Bestandssysteemobjecten (mappen en bestanden) per synchronisatiegroep | 100 miljoen objecten | Nee |
| Maximum aantal bestandssysteemobjecten (mappen en bestanden) in een map (niet recursief) | 5 miljoen objecten | Ja |
| Maximumgrootte beveiligingsbeschrijving (mappen en bestanden) van objecten | 64 KiB | Ja |
| Bestandsgrootte | 100 GiB | Nee |
| Minimale bestandsgrootte om een bestand gelaagd te maken | Op basis van de grootte van het bestandssysteemcluster (dubbele bestandssysteemclustergrootte). Als de bestandssysteemclustergrootte bijvoorbeeld 4 Kb is, is de minimale bestandsgrootte 8 Kb. | Ja |
Notitie
Een Azure File Sync-eindpunt kan tot de grootte van een Azure-bestandsshare worden opgeschaald. Als de maximale grootte van de Azure-bestandsshare is bereikt, kan synchronisatie niet worden uitgevoerd.
Metrische Azure File Sync-gegevens voor prestaties
Omdat de Azure File Sync-agent wordt uitgevoerd op een Windows Server-computer die verbinding maakt met de Azure-bestandsshares, zijn effectieve synchronisatieprestaties afhankelijk van een aantal factoren in uw infrastructuur: Windows Server en de onderliggende schijfconfiguratie, netwerkbandbreedte tussen de server en de Azure-opslag, de bestandsgrootte, de totale grootte van de gegevensset en de activiteit op de gegevensset. Omdat Azure File Sync werkt op bestandsniveau, moeten de prestatiekenmerken van een op Azure File Sync gebaseerde oplossing worden gemeten aan de hand van het aantal objecten (bestanden en mappen) dat per seconde wordt verwerkt.
Voor Azure File Sync zijn de prestaties in twee fasen essentieel:
- Eerste eenmalige inrichting: Als u de prestaties bij de eerste inrichting wilt optimaliseren, raadpleegt u Onboarding met Azure File Sync voor de optimale implementatiedetails.
- Doorlopende synchronisatie: Nadat de gegevens in eerste instantie zijn geseed in de Azure-bestandsshares, worden meerdere eindpunten door Azure File Sync gesynchroniseerd.
Notitie
Wanneer veel servereindpunten in dezelfde synchronisatiegroep tegelijkertijd worden gesynchroniseerd, strijden ze voor cloudserviceresources. Hierdoor worden de uploadprestaties beïnvloed. In extreme gevallen hebben sommige synchronisatiesessies geen toegang tot de resources en mislukken ze. Deze synchronisatiesessies worden echter binnenkort hervat en worden uiteindelijk voltooid zodra de congestie is verminderd.
Interne testresultaten
Om u te helpen bij het plannen van uw implementatie voor elk van de fasen (eerste eenmalige inrichting en doorlopende synchronisatie), volgen hier de resultaten die we hebben waargenomen tijdens interne tests op een systeem met de volgende configuratie:
| Systeemconfiguratie | Details |
|---|---|
| CPU | 64 Virtual cores met 64 MiB L3-cache |
| Geheugen | 128 GiB |
| Schijf | SAS-schijven met RAID 10 met cache door accu-ondersteuning |
| Netwerk | 1 Gbps netwerk |
| Workload | Bestandsserver voor algemene doeleinden |
Eerste eenmalige inrichting
| Eerste eenmalige inrichting | Details |
|---|---|
| Aantal objecten | 25 miljoen objecten |
| Grootte van gegevensset | Ong. 4.7 TiB |
| Gemiddelde bestandsgrootte | Ong. 200 KiB (Grootste bestand: 100 GiB) |
| De eerste cloudwijziging wordt uitgevoerd | 80 objecten per seconde |
| Doorvoer van uploaddoorvoer | 20 objecten per seconde per synchronisatiegroep |
| Doorvoer voor naamruimte downloaden | 400 objecten per seconde |
Initiële inventarisatie van cloudwijziging: Wanneer een nieuwe synchronisatiegroep wordt gemaakt, is de eerste stap die wordt uitgevoerd de eerste stap voor cloudwijziging. In dit proces inventariseert het systeem alle items in de Azure-bestandsshare. Tijdens dit proces is er geen synchronisatieactiviteit. Er worden geen items gedownload van het cloudeindpunt naar het servereindpunt en er worden geen items geüpload van het servereindpunt naar het cloudeindpunt. De synchronisatieactiviteit wordt hervat zodra de initiële opsomming van cloudwijziging is voltooid.
De snelheid van prestaties is 80 objecten per seconde. U kunt een schatting maken van de tijd die nodig is om de eerste inventarisatie van cloudwijziging te voltooien door het aantal items in de cloudshare te bepalen en de volgende formule te gebruiken om de tijd in dagen op te halen.
Tijd (in dagen) voor de initiële cloudopsomming = (aantal objecten in cloudeindpunt)/(80 * 60 * 60 * 24)
Initiële synchronisatie van gegevens van Windows Server naar Azure-bestandsshare: Veel Azure File Sync-implementaties beginnen met een lege Azure-bestandsshare omdat alle gegevens zich op de Windows Server bevinden. In deze gevallen is de initiële inventarisatie van cloudwijzigingen snel en wordt het merendeel van de tijd besteed aan het synchroniseren van wijzigingen van de Windows Server naar de Azure-bestandsshare(s).
Tijdens het synchroniseren van het uploaden van gegevens naar de Azure-bestandsshare, is er geen downtime op de lokale bestandsserver en kunnen beheerders netwerklimieten instellen om de hoeveelheid bandbreedte te beperken die wordt gebruikt voor het uploaden van achtergrondgegevens.
Initiële synchronisatie wordt doorgaans beperkt door de initiële uploadsnelheid van 20 bestanden per seconde per synchronisatiegroep. Klanten kunnen de tijd schatten om al hun gegevens naar Azure te uploaden met behulp van de volgende formules om tijd in dagen te krijgen:
Tijd (in dagen) voor het uploaden van bestanden naar een synchronisatiegroep = (aantal objecten in servereindpunt)/(20 * 60 * 60 * 24)
Het splitsen van uw gegevens in meerdere servereindpunten en synchronisatiegroepen kan deze eerste gegevensupload versnellen, omdat het uploaden parallel kan worden uitgevoerd voor meerdere synchronisatiegroepen met een snelheid van 20 items per seconde. Twee synchronisatiegroepen worden dus uitgevoerd met een gecombineerde snelheid van 40 items per seconde. De totale tijd die moet worden voltooid, is de geschatte tijd voor de synchronisatiegroep met de meeste bestanden die moeten worden gesynchroniseerd.
Doorvoer voor het downloaden van naamruimte: wanneer een nieuw servereindpunt wordt toegevoegd aan een bestaande synchronisatiegroep, downloadt de Azure File Sync-agent geen bestandsinhoud van het cloudeindpunt. Eerst wordt de volledige naamruimte gesynchroniseerd en vervolgens wordt de terugroepactie op de achtergrond geactiveerd om de bestanden in hun geheel te downloaden of, als cloudlagen zijn ingeschakeld, met het beleid voor cloudlagen dat is ingesteld op het servereindpunt.
Doorgaande synchronisatie
| Doorgaande synchronisatie | Details |
|---|---|
| Aantal gesynchroniseerde objecten | 125.000 objecten (ong. 1% verloop) |
| Grootte van gegevensset | 50 GiB |
| Gemiddelde bestandsgrootte | Ong. 500 KiB |
| Doorvoer van uploaddoorvoer | 20 objecten per seconde per synchronisatiegroep |
| Doorvoer van volledige download* | 60 objecten per seconde |
*Als cloudlagen zijn ingeschakeld, zult u waarschijnlijk betere prestaties zien, omdat slechts een deel van de bestandsgegevens wordt gedownload. Azure File Sync downloadt alleen de gegevens van in de cache opgeslagen bestanden wanneer deze worden gewijzigd op een van de eindpunten. Voor gelaagde of nieuw gemaakte bestanden downloadt de agent de bestandsgegevens niet en wordt in plaats daarvan alleen de naamruimte gesynchroniseerd met alle servereindpunten. De agent ondersteunt ook gedeeltelijke downloads van gelaagde bestanden wanneer ze worden geopend door de gebruiker.
Notitie
Deze getallen zijn geen indicatie van de prestaties die u zult ervaren. De werkelijke prestaties zijn afhankelijk van meerdere factoren, zoals beschreven in het begin van deze sectie.
Houd rekening met een aantal zaken als algemene handleiding voor uw implementatie:
- De objectdoorvoer wordt ongeveer geschaald in verhouding tot het aantal synchronisatiegroepen op de server. Het splitsen van gegevens in meerdere synchronisatiegroepen op een server levert een betere doorvoer op, die ook wordt beperkt door de server en het netwerk.
- De objectdoorvoer is omgekeerd evenredig met de miB-doorvoer per seconde. Voor kleinere bestanden ervaart u een hogere doorvoer in termen van het aantal objecten dat per seconde wordt verwerkt, maar lagere MiB per seconde doorvoer. Omgekeerd krijgt u voor grotere bestanden minder objecten verwerkt per seconde, maar hogere MiB per seconde doorvoer. De doorvoer van MiB per seconde wordt beperkt door de Azure Files schaaldoelen.