Skalbarhets- och prestandamål för Azure Files och Azure File Sync
Azure Files erbjuder fullständigt hanterade filresurser i molnet som är tillgängliga via filsystemprotokollen Server Message Block (SMB) och Network File System (NFS). I den här artikeln beskrivs skalbarhets- och prestandamål för Azure Storage-konton, Azure Files och Azure File Sync.
Målen som anges här kan påverkas av andra variabler i distributionen. Prestanda för I/O för en fil kan till exempel påverkas av SMB-klientens beteende och av din tillgängliga nätverksbandbredd. Du bör testa ditt användningsmönster för att avgöra om skalbarheten och prestandan för Azure Files uppfyller dina krav.
Gäller för
| Typ av filresurs | SMB | NFS |
|---|---|---|
| Standardfilresurser (GPv2), LRS/ZRS |  |
 |
| Standardfilresurser (GPv2), GRS/GZRS | |
|
| Premiumfilresurser (FileStorage), LRS/ZRS | |
|
Azure Files – skalningsmål
Azure-filresurser distribueras till lagringskonton, som är objekt på den översta nivån som representerar en delad lagringspool. Den här lagringspoolen kan användas för att distribuera flera filresurser. Det finns därför tre kategorier att tänka på: lagringskonton, Azure-filresurser och enskilda filer.
Skalningsmål för lagringskonto
Skalningsmål för lagringskonto gäller på lagringskontonivå. Det finns två huvudsakliga typer av lagringskonton för Azure Files:
GPv2-lagringskonton (GPv2) för generell användning: Med GPv2-lagringskonton kan du distribuera Azure-filresurser på standard-/hårddiskbaserad maskinvara (HDD-baserad). Förutom att lagra Azure-filresurser kan GPv2-lagringskonton lagra andra lagringsresurser, till exempel blobcontainrar, köer eller tabeller. Filresurser kan distribueras till transaktionsoptimerade (standard), frekventa eller lågfrekventa nivåer.
FileStorage-lagringskonton: Med FileStorage-lagringskonton kan du distribuera Azure-filresurser på premium-/SSD-baserad maskinvara (SSD-baserad). FileStorage-konton kan bara användas för att lagra Azure-filresurser. inga andra lagringsresurser (blobcontainrar, köer, tabeller osv.) kan distribueras i ett FileStorage-konto.
| Attribut | GPv2-lagringskonton (standard) | FileStorage-lagringskonton (premium) |
|---|---|---|
| Antal lagringskonton per region per prenumeration | 2501 | 2501 |
| Maximal kapacitet för lagringskonto | 5 PiB2 | 100 TiB (etablerad) |
| Maximalt antal filresurser | Obegränsat | Obegränsad, total allokerad storlek för alla resurser måste vara mindre än max än den maximala lagringskontokapaciteten |
| Högsta frekvens för samtidiga förfrågningar | 20 000 IOPS2 | 102 400 IOPS |
Dataflöde (ingress + utgående) för LRS/GRS
|
|
10 340 MiB/s |
Dataflöde (ingress + utgående) för ZRS
|
|
10 340 MiB/s |
| Dataflöde (ingress + utgående) för redundans/regionkombinationer som inte visas i föregående rad |
|
10 340 MiB/s |
| Maximalt antal regler för virtuellt nätverk | 200 | 200 |
| Maximalt antal IP-adressregler | 200 | 200 |
| Läsåtgärder för hantering | 800 per 5 minuter | 800 per 5 minuter |
| Skrivåtgärder för hantering | 10 per sekund/1200 per timme | 10 per sekund/1200 per timme |
| Åtgärder för hanteringslista | 100 per 5 minuter | 100 per 5 minuter |
1 Med en kvotökning kan du skapa upp till 500 lagringskonton med standardslutpunkter per region. Mer information finns i Öka Azure Storage-kontokvoter. 2 Lagringskonton för generell användning version 2 har stöd för högre kapacitetsgränser och högre gränser för ingress per begäran. Om du vill begära en ökning av kontogränser kontaktar du Azure-supporten.
Skalningsmål för Azure-filresurs
Skalningsmål för Azure-filresurser gäller på filresursnivå.
| Attribut | Standardfilresurser1 | Premium-filresurser |
|---|---|---|
| Minsta storlek på en filresurs | Inget minimum | 100 GiB (etablerad) |
| Enhet för ökad/minskning av etablerad storlek | Ej tillämpligt | 1 GiB |
| Maximal storlek på en filresurs | 100 TiB | 100 TiB |
| Maximalt antal filer i en filresurs | Ingen begränsning | Ingen begränsning |
| Högsta begärandefrekvens (max IOPS) | 20 000 |
|
| Dataflöde (ingress + utgående) för en enskild filresurs (MiB/s) | Upp till lagringskontogränser | 100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB) |
| Maximalt antal resursögonblicksbilder | 200 ögonblicksbilder | 200 ögonblicksbilder |
| Maximal längd på objektnamn3 (fullständigt sökvägsnamn inklusive alla kataloger, filnamn och omvänt snedstreck) | 2 048 tecken | 2 048 tecken |
| Maximal längd på enskild pathname-komponent2 (i sökvägen \A\B\C\D representerar varje bokstav en katalog eller fil som är en enskild komponent) | 255 tecken | 255 tecken |
| Gräns för hård länk (endast NFS) | Ej tillämpligt | 178 |
| Maximalt antal SMB Multichannel-kanaler | Ej tillämpligt | 4 |
| Maximalt antal lagrade åtkomstprinciper per filresurs | 5 | 5 |
1 Gränserna för standardfilresurser gäller för alla tre nivåerna som är tillgängliga för standardfilresurser: transaktionsoptimerad, frekvent och lågfrekvent.
2 Azure Files tillämpar vissa namngivningsregler för katalog- och filnamn.
Filskalningsmål
Filskalningsmål gäller för enskilda filer som lagras i Azure-filresurser.
| Attribut | Filer i standardfilresurser | Filer i premiumfilresurser |
|---|---|---|
| Maximal filstorlek | 4 TiB | 4 TiB |
| Högsta frekvens för samtidiga förfrågningar | 1 000 IOPS | Upp till 8 0001 |
| Maximal inmatning för en fil | 60 MiB/s | 200 MiB/s (upp till 1 GiB/s med SMB Multichannel)2 |
| Maximal utmatning för en fil | 60 MiB/s | 300 MiB/s (upp till 1 GiB/s med SMB Multichannel)2 |
| Maximalt antal samtidiga referenser för rotkatalog3 | 10 000 handtag | 10 000 handtag |
| Maximalt antal samtidiga referenser per fil och katalog3 | 2 000 referenser | 2 000 referenser |
1 Gäller för läs- och skriv-I/Os (vanligtvis mindre I/O-storlekar som är mindre än eller lika med 64 KiB). Metadataåtgärder, förutom läsningar och skrivningar, kan vara lägre. Det här är mjuka gränser och begränsning kan ske utöver dessa gränser.
2 Beroende på nätverksgränser för datorer, tillgänglig bandbredd, I/O-storlekar, ködjup och andra faktorer. Mer information finns i SMB Multichannel-prestanda.
3 Azure Files har stöd för 10 000 öppna referenser i rotkatalogen och 2 000 öppna referenser per fil och katalog i resursen. Antalet aktiva användare som stöds per resurs är beroende av de program som har åtkomst till resursen. Om dina program inte öppnar ett handtag i rotkatalogen kan Azure Files ha stöd för mer än 10 000 aktiva användare per resurs. Men om du använder Azure Files för att lagra diskavbildningar för storskaliga virtuella skrivbordsarbetsbelastningar kan det hända att handtagen för rotkatalogen eller per fil/katalog tar slut. I det här fallet kan du behöva använda flera Azure-filresurser. Mer information finns i Vägledning för storleksändring i Azure Files för Azure Virtual Desktop.
Storleksvägledning för Azure Files för Azure Virtual Desktop
Ett populärt användningsfall för Azure Files är att lagra användarprofilcontainrar och diskavbildningar för Azure Virtual Desktop med hjälp av FSLogix eller App attach. I storskaliga Azure Virtual Desktop-distributioner kan handtagen för rotkatalogen eller per fil/katalog ta slut om du använder en enda Azure-filresurs. Det här avsnittet beskriver hur handtag används av olika typer av diskbilder och ger storleksvägledning beroende på vilken teknik du använder.
FSLogix
Om du använder FSLogix med Azure Virtual Desktop är dina användarprofilcontainrar antingen virtuella hårddiskfiler (VHD) eller VHDX-filer (Hyper-V Virtual Hard Disk) och de monteras i en användarkontext, inte en systemkontext. Varje användare öppnar en enda rotkatalogreferens, som ska vara till filresursen. Azure Files har stöd för högst 10 000 användare förutsatt att du har filresursen (\\storageaccount.file.core.windows.net\sharename) + profilkatalogen (%sid%_%username%) + profilcontainern (profile_%username.vhd(x)).
Om du når gränsen på 10 000 samtidiga referenser för rotkatalogen eller om användarna får dåliga prestanda kan du prova att använda ytterligare en Azure-filresurs och distribuera containrarna mellan resurserna.
Varning
Azure Files har stöd för upp till 10 000 samtidiga användare från en enda filresurs, men det är viktigt att testa dina arbetsbelastningar korrekt mot storleken och typen av filresurs som du har skapat. Dina krav kan variera beroende på användare, profilstorlek och arbetsbelastning.
Om du till exempel har 2 400 samtidiga användare behöver du 2 400 referenser i rotkatalogen (en för varje användare), vilket är under gränsen på 10 000 öppna referenser. Det är mycket osannolikt att FSLogix-användare når gränsen på 2 000 öppna fil- och kataloghandtag. Om du har en enda FSLogix-profilcontainer per användare använder du bara två fil-/katalogreferenser: en för profilkatalogen och en för profilcontainerfilen. Om användarna har två containrar vardera (profil och ODFC) behöver du ytterligare ett handtag för ODFC-filen.
Appanslutning med CimFS
Om du använder MSIX App attach eller App attach för att dynamiskt bifoga program kan du använda CimFS-filer (Composite Image File System) eller VHD/VHDX-filer för diskbilder. Hur som helst är skalningsgränserna per virtuell dator som monterar avbildningen, inte per användare. Antalet användare är irrelevant vid beräkning av skalningsgränser. När en virtuell dator startas monteras diskavbildningen, även om det inte finns några användare.
Om du använder App attach med CimFS använder diskbilderna endast handtag på diskbildfilerna. De använder inte referenser i rotkatalogen eller katalogen som innehåller diskbilden. Men eftersom en CimFS-avbildning är en kombination av .cim-filen och minst två andra filer behöver du ett handtag var för tre filer i katalogen för varje virtuell dator som monterar diskavbildningen. Så om du har 100 virtuella datorer behöver du 300 filhandtag.
Du kan få slut på filreferenser om antalet virtuella datorer per app överstiger 2 000. I det här fallet använder du ytterligare en Azure-filresurs.
Appanslutning med VHD/VHDX
Om du använder App attach med VHD/VHDX-filer monteras filerna i en systemkontext, inte i en användarkontext, och de delas och skrivskyddas. Mer än ett handtag på VHDX-filen kan användas av ett anslutningssystem. Om du vill hålla dig inom skalningsgränserna för Azure Files måste antalet virtuella datorer multiplicerat med antalet appar vara mindre än 10 000 och antalet virtuella datorer per app får inte överstiga 2 000. Så begränsningen är beroende på vilket du träffar först.
I det här scenariot kan du nå gränsen per fil/katalog med 2 000 monteringar av en enda VHD/VHDX. Om resursen innehåller flera VHD/VHDX-filer kan du först nå rotkataloggränsen. Till exempel når 100 virtuella datorer som monterar 100 delade VHDX-filer gränsen på 10 000 handtag.
I ett annat exempel kräver 100 virtuella datorer som har åtkomst till 20 appar 2 000 rotkatalogreferenser (100 x 20 = 2 000), vilket ligger långt inom gränsen på 10 000 för rotkatalogreferenser. Du behöver också ett filhandtag och ett katalog-/mapphandtag för varje virtuell dator som monterar VHD(X)-avbildningen, så 200 handtag i det här fallet (100 filhandtag + 100 kataloghandtag), som ligger bekvämt under gränsen på 2 000 handtag per fil/katalog.
Om du når gränserna för maximala samtidiga referenser för rotkatalogen eller per fil/katalog använder du ytterligare en Azure-filresurs.
Azure File Sync – skalningsmål
Följande tabell anger vilka mål som är mjuka, som representerar den Microsoft-testade gränsen och hård, som anger ett framtvingat maxvärde:
| Resurs | Mål | Hård gräns |
|---|---|---|
| Lagringssynkroniseringstjänster per region | 100 lagringssynkroniseringstjänster | Ja |
| Synkroniseringstjänster för lagring per prenumeration | 15 Synkroniseringstjänster för lagring | Ja |
| Synkroniseringsgrupper per lagringssynkroniseringstjänst | 200 synkroniseringsgrupper | Yes |
| Registrerade servrar per lagringssynkroniseringstjänst | 99 servrar | Ja |
| Privata slutpunkter per lagringssynkroniseringstjänst | 100 privata slutpunkter | Ja |
| Molnslutpunkter per synkroniseringsgrupp | 1 molnslutpunkt | Yes |
| Serverslutpunkter per synkroniseringsgrupp | 100 serverslutpunkter | Yes |
| Serverslutpunkter per server | 30 serverslutpunkter | Yes |
| Filsystemobjekt (kataloger och filer) per synkroniseringsgrupp | 100 miljoner objekt | No |
| Maximalt antal filsystemobjekt (kataloger och filer) i en katalog (inte rekursiva) | 5 miljoner objekt | Yes |
| Maximal säkerhetsbeskrivningsstorlek för objekt (kataloger och filer) | 64 KiB | Yes |
| Filstorlek | 100 GiB | No |
| Minsta filstorlek för en fil som ska nivåindelas | Baserat på filsystemets klusterstorlek (dubbla filsystemets klusterstorlek). Om filsystemets klusterstorlek till exempel är 4 KiB är den minsta filstorleken 8 KiB. | Ja |
Kommentar
En Azure File Sync-slutpunkt kan skalas upp till storleken på en Azure-filresurs. Om storleksgränsen för Azure-filresursen har nåtts kan synkroniseringen inte fungera.
Azure File Sync – prestandamått
Eftersom Azure File Sync-agenten körs på en Windows Server-dator som ansluter till Azure-filresurserna beror effektiv synkroniseringsprestanda på ett antal faktorer i infrastrukturen: Windows Server och den underliggande diskkonfigurationen, nätverksbandbredden mellan servern och Azure Storage, filstorlek, total datamängdsstorlek och aktiviteten på datauppsättningen. Eftersom Azure File Sync fungerar på filnivå bör prestandaegenskaperna för en Azure File Sync-baserad lösning mätas med antalet objekt (filer och kataloger) som bearbetas per sekund.
För Azure File Sync är prestandan kritisk i två faser:
- Inledande engångsetablering: Information om hur du optimerar prestanda vid den inledande etableringen finns i Registrering med Azure File Sync.
- Pågående synkronisering: När data ursprungligen har seedats i Azure-filresurserna håller Azure File Sync flera slutpunkter synkroniserade.
Kommentar
När många serverslutpunkter i samma synkroniseringsgrupp synkroniseras samtidigt, konkurrerar de om molntjänstresurser. Därför påverkas uppladdningsprestandan. I extrema fall kommer vissa synkroniseringssessioner inte att komma åt resurserna och misslyckas. Dessa synkroniseringssessioner återupptas dock inom kort och lyckas så småningom när överbelastningen minskar.
Interna testresultat
För att hjälpa dig att planera distributionen för vart och ett av stegen (inledande engångsetablering och pågående synkronisering) visas de resultat som vi observerade under intern testning i ett system med följande konfiguration:
| Systemkonfiguration | Information |
|---|---|
| Processor | 64 virtuella kärnor med 64 MiB L3-cache |
| Minne | 128 GiB |
| Disk | SAS-diskar med RAID 10 och batteribaserad cache |
| Nätverk | 1 Gbit/s-nätverk |
| Arbetsbelastning | Allmän filserver |
Inledande engångsetablering
| Inledande engångsetablering | Information |
|---|---|
| Antal objekt | 25 miljoner objekt |
| Datamängdens storlek | ~4,7 TiB |
| Genomsnittlig filstorlek | ~200 KiB (största fil: 100 GiB) |
| Initial molnändringsuppräkning | 80 objekt per sekund |
| Dataflöde för uppladdningen | 20 objekt per sekund och synkroniseringsgrupp |
| Dataflöde för nedladdning i namnområdet | 400 objekt per sekund |
Inledande uppräkning av molnändringar: När en ny synkroniseringsgrupp skapas är den första uppräkning av molnändringar det första steget som körs. I den här processen räknar systemet upp alla objekt i Azure-filresursen. Under den här processen kommer det inte att finnas någon synkroniseringsaktivitet. Inga objekt laddas ned från molnslutpunkten till serverslutpunkten och inga objekt laddas upp från serverslutpunkten till molnslutpunkten. Synkroniseringsaktiviteten återupptas då den första molnändringsuppräkningen har slutförts.
Prestandahastigheten är 80 objekt per sekund. Du kan uppskatta den tid det tar att slutföra den första molnändringsuppräkningen genom att fastställa antalet objekt i molnresursen och använda följande formler för att få tid i dagar.
Tid (i dagar) för initial molnuppräkning = (Antal objekt i molnslutpunkten)/(80 * 60 * 60 * 24)
Inledande synkronisering av data från Windows Server till Azure-filresurs: Många Azure File Sync-distributioner börjar med en tom Azure-filresurs eftersom alla data finns på Windows Server. I dessa fall är den första molnändringsuppräkningen snabb och merparten av tiden ägnas åt att synkronisera ändringar från Windows Server till Azure-filresurserna.
Medan synkronisering laddar upp data till Azure-filresursen finns det ingen stilleståndstid på den lokala filservern, och administratörer kan konfigurera nätverksgränser för att begränsa mängden bandbredd som används för uppladdning av bakgrundsdata.
Den initiala synkroniseringen begränsas vanligtvis av den initiala uppladdningshastigheten på 20 filer per sekund per synkroniseringsgrupp. Kunder kan uppskatta den tid det tar att ladda upp alla sina data till Azure med hjälp av följande formler för att få tid i dagar:
Tid (i dagar) det tar att ladda upp filer till en synkroniseringsgrupp = (Antal objekt i serverslutpunkten)/(20 * 60 * 60 * 24)
Att dela upp data i flera serverslutpunkter och synkroniseringsgrupper kan påskynda den första datauppladdningen, eftersom uppladdningen kan göras parallellt för flera synkroniseringsgrupper med en hastighet på 20 objekt per sekund vardera. Därför kan två synkroniseringsgrupper köras med en sammanlagd hastighet på 40 objekt per sekund. Den totala tid det tar att slutföra är tidsuppskattningen för den synkroniseringsgrupp som har flest filer att synkronisera.
Dataflöde för nedladdning av namnområde: När en ny serverslutpunkt läggs till i en befintlig synkroniseringsgrupp laddar Inte Azure File Sync-agenten ned något av filinnehållet från molnslutpunkten. Den synkroniserar först det fullständiga namnområdet och utlöser sedan bakgrundsåterkallelse för att ladda ner filerna, antingen i sin helhet eller, om molnnivåindelning är aktiverat, till den princip för molnnivåindelning som angetts på serverslutpunkten.
Pågående synkronisering
| Pågående synkronisering | Information |
|---|---|
| Antal synkroniserade objekt | 125 000 objekt (~1 % omsättning) |
| Datamängdens storlek | 50 GiB |
| Genomsnittlig filstorlek | ~500 KiB |
| Dataflöde för uppladdningen | 20 objekt per sekund och synkroniseringsgrupp |
| Dataflöde för hela nedladdningen* | 60 objekt per sekund |
*Om molnnivåindelning är aktiverat kommer du förmodligen att se bättre prestanda eftersom endast en del av fildata laddas ned. Azure File Sync laddar bara ned data från cachelagrade filer när de ändras på någon av slutpunkterna. För alla nivåindelade eller nyligen skapade filer laddar agenten inte ned fildata och synkroniserar i stället bara namnområdet till alla serverslutpunkter. Agenten stöder också partiella nedladdningar av nivåindelade filer när de används av användaren.
Kommentar
Dessa siffror är inte en indikation på den prestanda som du kommer att uppleva. Den faktiska prestandan beror på flera faktorer som beskrivs i början av det här avsnittet.
Som en allmän guide för distributionen bör du ha några saker i åtanke:
- Objektets dataflöde skalas ungefär i proportion till antalet synkroniseringsgrupper på servern. Att dela upp data i flera synkroniseringsgrupper på en server skapar bättre dataflöde, vilket också begränsas av servern och nätverket.
- Objektets dataflöde är omvänt proportionellt mot dataflödet MiB per sekund. För mindre filer får du högre dataflöde när det gäller antalet objekt som bearbetas per sekund, men lägre Dataflöde för MiB per sekund. För större filer får du färre objekt som bearbetas per sekund, men högre Dataflöde för MiB per sekund. Dataflödet för MiB per sekund begränsas av Azure Files skalningsmål.