Schaalbaarheids- en prestatiedoelen voor Azure Files en Azure File Sync
Azure Files biedt volledig beheerde bestandsshares in de cloud die toegankelijk zijn via de SMB-protocollen (Server Message Block) en Network File System (NFS). 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
| Beheermodel | Factureringsmodel | Medialaag | Redundantie | SMB | NFS |
|---|---|---|---|---|---|
| Microsoft.Storage | Ingericht v2 | HDD (standaard) | Lokaal (LRS) |  |
 |
| Microsoft.Storage | Ingericht v2 | HDD (standaard) | Zone (ZRS) | |
|
| Microsoft.Storage | Ingericht v2 | HDD (standaard) | Geo (GRS) | |
|
| Microsoft.Storage | Ingericht v2 | HDD (standaard) | GeoZone (GZRS) | |
|
| Microsoft.Storage | Ingericht v1 | SSD (premium) | Lokaal (LRS) | |
|
| Microsoft.Storage | Ingericht v1 | SSD (premium) | Zone (ZRS) | |
|
| Microsoft.Storage | Betalen per gebruik | HDD (standaard) | Lokaal (LRS) | |
|
| Microsoft.Storage | Betalen per gebruik | HDD (standaard) | Zone (ZRS) | |
|
| Microsoft.Storage | Betalen per gebruik | HDD (standaard) | Geo (GRS) | |
|
| Microsoft.Storage | Betalen per gebruik | HDD (standaard) | GeoZone (GZRS) | |
|
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:
FileStorage-opslagaccounts: Met FileStorage-opslagaccounts kunt u Azure-bestandsshares implementeren met een ingericht factureringsmodel. 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.
Opslagaccounts voor algemeen gebruik versie 2 (GPv2): met GPv2-opslagaccounts kunt u bestandsshares voor betalen per gebruik implementeren op HDD-hardware. Naast het opslaan van Azure-bestandsshares kunnen GPv2-opslagaccounts andere opslagresources, zoals blobcontainers, wachtrijen of tabellen, opslaan.
| Kenmerk | SSD ingericht v1 | HDD ingericht v2 | HDD betalen per gebruik |
|---|---|---|---|
| Opslagaccounttype | FileStorage | FileStorage | StorageV2 |
| SKU's |
|
|
|
| Aantal opslagaccounts per regio per abonnement | 250 | 250 | 250 |
| Maximale opslagcapaciteit | 100 TiB | 4 PiB | 5 PiB |
| Maximum aantal bestandsshares | 1024 (aanbevolen om 50 of minder te gebruiken) | 50 | Onbeperkt (aanbevolen om 50 of minder te gebruiken) |
| Maximum IOPS | 102.400 IOPS | 50.000 IOPS | 20.000 IOPS |
| Maximale doorvoer | 10.340 MiB per seconde | 5.120 MiB per seconde |
|
| Maximum aantal regels voor virtuele netwerken | 200 | 200 | 200 |
| Maximum aantal IP-adresregels | 200 | 200 | 200 |
| Leesbewerkingen voor beheer | 800 per 5 minuten | 800 per 5 minuten | 800 per 5 minuten |
| Schrijfbewerkingen voor beheer | 10 per seconde/1200 per uur | 10 per seconde/1200 per uur | 10 per seconde/1200 per uur |
| Beheerlijstbewerkingen | 100 per 5 minuten | 100 per 5 minuten | 100 per 5 minuten |
Geselecteerde regio's met verhoogde maximale doorvoer voor HDD betalen per gebruik
De volgende regio's hebben een verhoogde maximale doorvoer voor HDD-opslagaccounts voor betalen per gebruik (StorageV2):
- Azië - oost
- Azië - zuidoost
- Australië - oost
- Brazilië - zuid
- Canada - midden
- China - oost 2
- China - noord 3
- Europa - noord
- Europa -west
- Frankrijk - centraal
- Duitsland - west-centraal
- India - centraal
- Japan - oost
- Jio India West
- Korea - centraal
- Noorwegen - oost
- Zuid-Afrika - noord
- Zweden - centraal
- VAE - noord
- Verenigd Koninkrijk Zuid
- Central US
- VS - oost
- VS - oost 2
- VS (overheid) - Virginia
- US Gov - Arizona
- VS - noord-centraal
- VS - zuid-centraal
- VS - west
- VS - west 2
- US - west 3
Schaaldoelen voor Azure-bestandsshares
Schaaldoelen voor Azure-bestandsshares zijn van toepassing op bestandsshareniveau.
| Kenmerk | SSD ingericht v1 | HDD ingericht v2 | HDD betalen per gebruik |
|---|---|---|---|
| Inrichtingseenheid voor opslag | 1 GiB | 1 GiB | N.v.t. |
| Inrichtingseenheid voor IOPS | N.v.t. | 1 IO per seconde | N.v.t. |
| Inrichtingseenheid voor doorvoer | N.v.t. | 1 MiB per seconde | N.v.t. |
| Minimale opslaggrootte | 100 GiB (ingericht) | 32 GiB (ingericht) | 0 bytes |
| Maximale opslaggrootte | 100 TiB | 256 TiB | 100 TiB |
| Maximum aantal bestanden | Onbeperkt | Onbeperkt | Onbeperkt |
| Maximum IOPS | 102.400 IOPS (afhankelijk van inrichting) | 50.000 IOPS (afhankelijk van inrichting) | 20.000 IOPS |
| Maximale doorvoer | 10.340 MiB per seconde (afhankelijk van inrichting) | 5.120 IOPS (afhankelijk van inrichting) | Maximaal opslagaccountlimieten |
| Maximum aantal momentopnamen van shares | 200 momentopnamen | 200 momentopnamen | 200 momentopnamen |
| Maximale bestandsnaamlengte3 (volledige padnaam, inclusief alle mappen, bestandsnamen en backslash-tekens) | 2048 tekens | 2048 tekens | 2048 tekens |
| Maximale lengte van afzonderlijke padnaam component2 (in het pad \A\B\C\D vertegenwoordigt elke letter een map of bestand dat een afzonderlijk onderdeel is) | 255 tekens | 255 tekens | 255 tekens |
| Limiet voor vaste koppelingen (alleen NFS) | 178 | N.v.t. | N.v.t. |
| Maximumaantal SMB Multichannel-kanalen | 4 | N.v.t. | N.v.t. |
| Maximaal aantal opgeslagen toegangsbeleidsregels per bestandsshare | 5 | 5 | 5 |
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 | SSD ingericht v1 | HDD ingericht v2 | HDD betalen per gebruik |
|---|---|---|---|
| Maximale bestandsgrootte | 4 TiB | 4 TiB | 4 TiB |
| Maximale gegevens-IOPS per bestand | 8.000 IOPS | 1.000 IOPS | 1.000 IOPS |
| Maximale doorvoer per bestand | 1024 MiB per seconde | 60 MiB per seconde | 60 MiB per seconde |
| Maximum aantal gelijktijdige ingangen voor hoofdmap | 10.000 ingangen | 10.000 ingangen | 10.000 ingangen |
| Maximum aantal gelijktijdige ingangen per bestand en map | 2.000 ingangen | 2.000 ingangen | 2.000 ingangen |
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 | 100 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.