Schaalbaarheids- en prestatiedoelen in Azure Files
Azure Files biedt volledig beheerde bestandsshares in de cloud die toegankelijk zijn via het SMB- en NFS-bestandssysteemprotocol. In dit artikel worden de schaalbaarheids- en prestatiedoelen voor Azure Files en Azure File Sync besproken.
De doelen die hier worden vermeld, worden mogelijk 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 uw beschikbare netwerkbandbreedte. U moet uw gebruikspatroon testen om te bepalen of de schaalbaarheid en prestaties van Azure Files voldoen aan uw vereisten. U moet ook verwachten dat deze limieten na verloop van tijd zullen toenemen.
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 die u moet overwegen: opslagaccounts, Azure-bestandsshares en afzonderlijke bestanden.
Schaaldoelen voor opslagaccounts
Schaaldoelen voor opslagaccounts zijn van toepassing op het niveau van het opslagaccount. Er zijn twee hoofdtypen opslagaccounts voor Azure Files:
GPv2-opslagaccounts (versie twee voor algemeen gebruik) : Met GPv2-opslagaccounts kunt u Azure-bestandsshares implementeren op (HDD-)hardware met een standaard/harde schijf. 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 transacties geoptimaliseerde (standaard), dynamische of statische lagen.
FileStorage-opslagaccounts: Met FileStorage-opslagaccounts kunt u Azure-bestandsshares implementeren op (SSD-)hardware met een premium/solid-state schijf. 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 max dan de maximale capaciteit van het opslagaccount |
| Maximum aantal gelijktijdige aanvragen | 20.000 IOPS2 | 100.000 IOPS |
Doorvoer (inkomend + uitgaand verkeer) voor LRS/GRS
|
|
10.340 MiB/sec. |
Doorvoer (inkomend + uitgaand verkeer) voor ZRS
|
|
10.340 MiB/sec. |
| Doorvoer (inkomend + uitgaand verkeer) voor redundantie/regiocombinaties die niet in de vorige rij worden vermeld |
|
10.340 MiB/sec. |
| Maximum aantal regels voor virtuele netwerken | 200 | 200 |
| Maximum aantal IP-adresregels | 200 | 200 |
| Leesbewerkingen beheren | 800 per 5 minuten | 800 per 5 minuten |
| Schrijfbewerkingen voor beheer | 10 per seconde/1200 per uur | 10 per seconde/1200 per uur |
| Bewerkingen voor beheerlijsten | 100 per 5 minuten | 100 per 5 minuten |
1 Met een quotumverhoging kunt u maximaal 500 opslagaccounts met standaardeindpunten per regio maken. 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 op 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 het niveau van de bestandsshare.
| 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 lengte van objectnaam3 (volledige padnaam inclusief alle mappen, bestandsnamen en backslash-tekens) | 2048 tekens | 2048 tekens |
| Maximale lengte van afzonderlijke padnaam component3 (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 standaard 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 doelen, 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 | Maximaal 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 Is van toepassing op I/O's voor lezen en schrijven (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 computernetwerklimieten, beschikbare bandbreedte, I/O-grootten, wachtrijdiepte en andere factoren. Zie Prestaties van SMB 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, kunnen Azure Files meer dan 10.000 actieve gebruikers per share ondersteunen.
Azure File Sync-schaaldoelen
In de volgende tabel ziet u welke doelen zacht zijn, die de door Microsoft geteste grens vertegenwoordigen en hard, waarmee een afgedwongen maximum wordt aangegeven:
| Resource | Doel | Harde limiet |
|---|---|---|
| Opslagsynchronisatieservices per regio | 100 opslagsynchronisatieservices | Ja |
| Synchronisatiegroepen per opslagsynchronisatieservice | 200 synchronisatiegroepen | Ja |
| Geregistreerde servers per opslagsynchronisatieservice | 99 servers | 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. | Yes |
Notitie
Een Azure File Sync-eindpunt kan tot de grootte van een Azure-bestandsshare worden opgeschaald. Als de limiet van de Azure-bestandsshare, kan er niet meer worden gesynchroniseerd.
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 de effectieve synchronisatieprestaties afhankelijk van een aantal factoren in uw infrastructuur: Windows Server en de onderliggende schijfconfiguratie, netwerkbandbreedte tussen de server en de Azure-opslag, bestandsgrootte, 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, houdt Azure File Sync meerdere eindpunten gesynchroniseerd.
Notitie
Wanneer veel servereindpunten in dezelfde synchronisatiegroep tegelijkertijd worden gesynchroniseerd, strijden ze om cloudserviceresources. Als gevolg hiervan 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 slagen uiteindelijk zodra de congestie is verminderd.
Interne testresultaten
Om u te helpen bij het plannen van uw implementatie voor elk van de fasen (initiële eenmalige inrichting en doorlopende synchronisatie), ziet u hieronder de resultaten die worden waargenomen tijdens de 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 |
Opsomming van initiële cloudwijziging: wanneer een nieuwe synchronisatiegroep wordt gemaakt, is de initiële opsomming van cloudwijziging de eerste stap die wordt uitgevoerd. In dit proces inventariseert het systeem alle items in de Azure-bestandsshare. Tijdens dit proces is er geen synchronisatieactiviteit, dus 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. Klanten kunnen een schatting maken van de tijd die nodig is om de initiële opsomming van cloudwijziging te voltooien door het aantal items in de cloudshare te bepalen en de volgende formules 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 opsomming van cloudwijzigingen snel en wordt de meeste tijd besteed aan het synchroniseren van wijzigingen van de Windows Server naar de Azure-bestandsshare(s).
Terwijl met synchronisatie gegevens worden geüpload 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 gegevens op de achtergrond.
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.
Downloaddoorvoer 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 opslag in cloudlagen is ingeschakeld, zult u waarschijnlijk betere prestaties zien, omdat slechts een deel van de bestandsgegevens wordt gedownload. Azure File Sync downloadt alleen de gegevens van bestanden in de cache wanneer deze op een van de eindpunten worden gewijzigd. Voor gelaagde of nieuw gemaakte bestanden downloadt de agent de bestandsgegevens niet en synchroniseert in plaats daarvan alleen de naamruimte met alle servereindpunten. De agent ondersteunt ook gedeeltelijke downloads van gelaagde bestanden wanneer deze door de gebruiker worden geopend.
Notitie
De bovenstaande 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.
Als algemene richtlijn voor uw implementatie moet u rekening houden met een aantal zaken:
- 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 een lagere doorvoer van MiB per seconde. Omgekeerd krijgt u voor grotere bestanden minder objecten per seconde verwerkt, maar een hogere doorvoer van MiB per seconde. De doorvoer van MiB per seconde wordt beperkt door de Azure Files schaaldoelen.