Välj principer för molnnivåindelning
Den här artikeln innehåller vägledning om hur du väljer och justerar principer för molnnivåindelning för Azure File Sync. Innan du läser den här artikeln bör du se till att du förstår hur molnnivåindelning fungerar. Grunderna för molnnivåindelning finns i Förstå azure file sync-molnnivåindelning. En detaljerad förklaring av principer för molnnivåindelning med exempel finns i Azure File Sync-principer för molnnivåindelning.
Begränsningar
Molnnivåindelning stöds inte på Windows-systemvolymen.
Om du använder FSRM (File Server Resource Manager) för kvothantering på serverslutpunkter rekommenderar vi att du tillämpar kvoterna på mappnivå och inte på volymnivå. Du kan fortfarande aktivera molnnivåindelning om du har en FSRM-kvot på volymnivå. När en FSRM-kvot har angetts rapporterar api:erna för frågor om ledigt utrymme som anropas automatiskt det lediga utrymmet på volymen enligt kvotinställningen. Men när en hård kvot finns på en volymrot är det faktiska lediga utrymmet på volymen och kvotens begränsade utrymme på volymen kanske inte detsamma. Detta kan orsaka oändlig nivåindelning om Azure File Sync anser att det inte finns tillräckligt med ledigt volymutrymme på serverslutpunkten.
Minsta filstorlek för en fil att nivåindela
Den minsta filstorleken för en fil att nivåindela baseras på filsystemets klusterstorlek. Den minsta filstorleken som är berättigad till molnnivåindelning beräknas med 2 gånger klusterstorleken och minst 8 KiB. I följande tabell visas de minsta filstorlekarna som kan nivåindelades, baserat på volymens klusterstorlek:
| Storlek på volymkluster | Filer av den här storleken eller större kan nivåindelas |
|---|---|
| 4 KiB eller mindre (4 096 byte) | 8 KiB |
| 8 KiB (8 192 byte) | 16 KiB |
| 16 KiB (16 384 byte) | 32 KiB |
| 32 KiB (32 768 byte) | 64 KiB |
| 64 KiB (65 536 byte) | 128 KiB |
| 128 KiB (131 072 byte) | 256 KiB |
| 256 KiB (262 144 byte) | 512 KiB |
| 512 KiB (524 288 byte) | 1 MiB |
| 1 MiB (1 048 576 byte) | 2 MiB |
| 2 MiB (2 097 152 byte) | 4 MiB |
Azure File Sync stöder molnnivåindelning på volymer med klusterstorlekar på upp till 2 MiB.
Alla filsystem som används av Windows organiserar hårddisken baserat på klusterstorlek (kallas även allokeringsenhetsstorlek). Klusterstorlek representerar den minsta mängd diskutrymme som kan användas för att lagra en fil. När filstorlekarna inte kommer ut till en jämn multipel av klusterstorleken måste ytterligare utrymme användas för att lagra filen – upp till nästa multipel av klusterstorleken.
Azure File Sync stöds på NTFS-volymer med Windows Server 2012 R2 och senare. I följande tabell beskrivs standardklusterstorlekarna när du skapar en ny NTFS-volym med Windows Server 2019.
| Volume size | Windows Server 2019 |
|---|---|
| 7 MiB – 16 TiB | 4 KiB |
| 16 TiB – 32 TiB | 8 KiB |
| 32 TiB – 64 TiB | 16 KiB |
Det är möjligt att du manuellt formaterade volymen med en annan klusterstorlek när volymen skapades. Om volymen kommer från en äldre version av Windows kan standardklusterstorlekarna också vara olika. Den här artikeln innehåller mer information om standardklusterstorlekar. Även om du väljer en klusterstorlek som är mindre än 4 KiB gäller fortfarande en 8 KiB-gräns som den minsta filstorleken som kan nivåindelas. (Även om tekniskt sett 2x klusterstorlek skulle motsvara mindre än 8 KiB.)
Anledningen till det absoluta minimumet beror på hur NTFS lagrar extremt små filer – 1 KiB till 4 KiB-filer i storlek. Beroende på andra parametrar för volymen är det möjligt att små filer inte lagras i ett kluster på disken alls. Det är kanske mer effektivt att lagra sådana filer direkt i volymens huvudfiltabell eller "MFT-post". Referenspunkten för molnnivåindelning lagras alltid på disken och tar upp exakt ett kluster. Nivåindelning av sådana små filer kan sluta utan utrymmesbesparingar. Extrema fall kan till och med använda mer utrymme med molnnivåindelning aktiverat. För att skydda mot detta är den minsta storleken på en fil som molnnivåindelningen kommer att nivåindela 8 KiB på en 4 KiB eller mindre klusterstorlek.
Välja dina initiala principer
När du aktiverar molnnivåindelning på en serverslutpunkt bör du vanligtvis skapa en lokal virtuell enhet för varje enskild serverslutpunkt. Om du isolerar serverslutpunkten blir det enklare att förstå hur molnnivåindelning fungerar och justera dina principer i enlighet med detta. Azure File Sync fungerar dock även om du har flera serverslutpunkter på samma enhet. Mer information finns i avsnittet Flera serverslutpunkter på lokal volym . Vi rekommenderar också att du när du först aktiverar molnnivåindelning håller datumprincipen inaktiverad och volymfri utrymmesprincip på cirka 10 % till 20 %. För de flesta filservervolymer är 20 % ledigt utrymme i volym vanligtvis det bästa alternativet.
För enkelhetens skull och för att ha en tydlig förståelse för hur objekt ska nivåindelades rekommenderar vi att du främst justerar principen för ledigt utrymme för volymer och håller din datumprincip inaktiverad om det inte behövs. Vi rekommenderar detta eftersom de flesta kunder tycker att det är värdefullt att fylla den lokala cachen med så många heta filer som möjligt och nivåindela resten till molnet. Datumprincipen kan dock vara fördelaktig om du proaktivt vill frigöra lokalt diskutrymme och du vet att filer i serverslutpunkten som används efter det antal dagar som anges i din datumprincip inte behöver behållas lokalt. Om du ställer in datumprincipen frigörs värdefull lokal diskkapacitet för andra slutpunkter på samma volym för att cachelagrar mer av deras filer.
När du har angett dina principer övervakar du utgående och justerar båda principerna i enlighet med detta. Vi rekommenderar att du tittar på molnnivååterkallningsstorleken och molnnivååterkallningsstorleken efter programmått i Azure Monitor. Vi rekommenderar också att du övervakar träfffrekvensen för cachen för serverslutpunkten för att fastställa procentandelen öppnade filer som redan finns i den lokala cachen. Information om hur du övervakar utgående trafik finns i Övervaka molnnivåindelning.
Justera dina principer
Om antalet filer som ständigt återkallas från Azure är större än du vill kan du ha fler heta filer än du har utrymme för att spara dem på den lokala servervolymen. Öka din lokala volymstorlek om möjligt och/eller minska din volymfri utrymmesprincip i små steg. Att minska volymens lediga utrymme i procent för mycket kan också få negativa konsekvenser. Högre omsättning i datamängden kräver mer ledigt utrymme – för nya filer och återkallande av "kalla" filer. Nivåindelningen börjar med en fördröjning på upp till en timme och behöver sedan bearbetningstid, vilket är anledningen till att du alltid bör ha gott om ledigt utrymme på volymen.
Att hålla mer data lokalt innebär lägre utgående kostnader eftersom färre filer kommer att återkallas från Azure, men kräver också en större mängd lokal lagring, vilket kommer till sin egen kostnad.
När du justerar principen för ledigt utrymme för volym bestäms mängden data som du ska behålla lokalt av följande faktorer: din bandbredd, datauppsättningens åtkomstmönster och budget. Med en anslutning med låg bandbredd kanske du vill ha mer lokala data för att säkerställa minimal fördröjning för användarna. Annars kan du basera den på omsättningshastigheten under en viss period. Om du till exempel vet att 10 % av din 1 TiB-datauppsättning ändras eller används aktivt varje månad, kanske du vill behålla 100 GiB lokalt så att du inte ofta återkallar filer. Om volymen är 2 TiB vill du hålla 5 % (eller 100 GiB) lokalt, vilket innebär att de återstående 95 % är din volymfria utrymmesprocent. Du bör dock lägga till en buffert för perioder med högre omsättning – med andra ord börja med en större volymfri utrymmesprocent och justera den om det behövs senare.
Standardprocedurer för drift
- När du först migrerar till Azure Files via Azure File Sync är molnnivåindelning beroende av inledande uppladdning
- Molnnivåindelning kontrollerar efterlevnaden av volymfri utrymme och datumprinciper var 60:e minut
- Om du använder /LFSM-växeln på Robocopy när du migrerar filer kan filer synkronisera och molnnivåindelning göra utrymme under den första uppladdningen
- Om nivåindelning inträffar innan en värmekarta skapas kommer filerna att nivåindelas av den senast ändrade tidsstämpeln