Planera för distribution av Azure File Sync

Azure File Sync är en tjänst som gör att du kan cachelagrar flera Azure-filresurser på en lokal Virtuell Windows Server- eller molndator.

Den här artikeln beskriver begrepp och funktioner för Azure File Sync. När du är bekant med Azure File Sync kan du prova den här tjänsten genom att följa distributionsguiden för Azure File Sync.

Filerna lagras i molnet i Azure-filresurser. Azure-filresurser kan användas på två sätt: genom att montera dessa serverlösa Azure-filresurser (SMB) direkt eller genom att cachelagra Azure-filresurser lokalt med hjälp av Azure File Sync. Vilket distributionsalternativ du väljer ändrar de aspekter du behöver tänka på när du planerar för distributionen.

• Direkt montering av en Azure-filresurs: Eftersom Azure Files ger SMB-åtkomst kan du montera Azure-filresurser lokalt eller i molnet med hjälp av standard-SMB-klienten som är tillgänglig i Windows, macOS och Linux. Eftersom Azure-filresurser är serverlösa kräver distribution för produktionsscenarier inte någon filserver eller NAS-enhet. Det innebär att du inte behöver tillämpa programkorrigeringar eller byta ut fysiska diskar.

• Cachelagra Azure-filresurs lokalt med Azure File Sync: Med Azure File Sync kan du centralisera organisationens filresurser i Azure Files, samtidigt som du behåller flexibiliteten, prestandan och kompatibiliteten hos en lokal filserver. Azure File Sync omvandlar en lokal (eller molnbaserad) Windows Server till en snabb cache av din Azure-filresurs.

Hanteringsbegrepp

En Azure File Sync-distribution har tre grundläggande hanteringsobjekt:

• Azure-filresurs: En Azure-filresurs är en serverlös molnfilresurs som tillhandahåller molnslutpunkten för en Azure File Sync-synkroniseringsrelation. Filer i en Azure-filresurs kan nås direkt med SMB eller FileREST-protokollet, men vi rekommenderar att du främst kommer åt filerna via Windows Server-cachen när Azure-filresursen används med Azure File Sync. Det beror på att Azure Files i dag saknar en effektiv mekanism för ändringsidentifiering som Windows Server har, så ändringar i Azure-filresursen direkt tar tid att sprida tillbaka till serverslutpunkterna.
• Serverslutpunkt: Sökvägen på Windows Server som synkroniseras till en Azure-filresurs. Detta kan vara en specifik mapp på en volym eller volymens rot. Flera serverslutpunkter kan finnas på samma volym om deras namnområden inte överlappar varandra.
• Synkroniseringsgrupp: Objektet som definierar synkroniseringsrelationen mellan en molnslutpunkt eller En Azure-filresurs och en serverslutpunkt. Slutpunkter i en synkroniseringsgrupp synkroniseras med varandra. Om du till exempel har två distinkta uppsättningar filer som du vill hantera med Azure File Sync skapar du två synkroniseringsgrupper och lägger till olika slutpunkter i varje synkroniseringsgrupp.

Begrepp för hantering av Azure-filresurser

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, samt andra lagringsresurser som blobcontainrar, köer eller tabeller. Alla lagringsresurser som distribueras till ett lagringskonto delar de gränser som gäller för lagringskontot. Aktuella lagringskontobegränsningar finns i Skalbarhets- och prestandamål för Azure Files.

Det finns två huvudsakliga typer av lagringskonton som du kommer att använda för Azure Files-distributioner:

• 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.
• 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. Endast FileStorage-konton kan distribuera både SMB- och NFS-filresurser.

Det finns flera andra typer av lagringskonton som du kan stöta på i Azure-portalen, PowerShell eller CLI. Två lagringskontotyper, BlockBlobStorage- och BlobStorage-lagringskonton, får inte innehålla Azure-filresurser. De andra två lagringskontotyperna som du kan se är version 1 av generell användning (GPv1) och klassiska lagringskonton, som båda kan innehålla Azure-filresurser. Även om GPv1- och klassiska lagringskonton kan innehålla Azure-filresurser är de flesta nya funktionerna i Azure Files endast tillgängliga i GPv2- och FileStorage-lagringskonton. Därför rekommenderar vi att du endast använder GPv2- och FileStorage-lagringskonton för nya distributioner och uppgraderaR GPv1- och klassiska lagringskonton om de redan finns i din miljö.

Hanteringskoncept för Azure File Sync

Synkroniseringsgrupper distribueras till Storage Sync Services, som är objekt på den översta nivån som registrerar servrar för användning med Azure File Sync och innehåller synkroniseringsgruppens relationer. Storage Sync Service-resursen är en peer för lagringskontoresursen och kan på liknande sätt distribueras till Azure-resursgrupper. En synkroniseringstjänst för lagring kan skapa synkroniseringsgrupper som innehåller Azure-filresurser över flera lagringskonton och flera registrerade Windows-servrar.

Innan du kan skapa en synkroniseringsgrupp i en tjänst för synkronisering av lagring måste du först registrera en Windows Server med Tjänsten för synkronisering av lagring. Då skapas ett registrerat serverobjekt som representerar en förtroenderelation mellan servern eller klustret och Tjänsten för synkronisering av lagring. Om du vill registrera en tjänst för synkronisering av lagring måste du först installera Azure File Sync-agenten på servern. En enskild server eller ett kluster kan bara registreras med en Synkroniseringstjänst för lagring i taget.

En synkroniseringsgrupp innehåller en molnslutpunkt eller En Azure-filresurs och minst en serverslutpunkt. Serverslutpunktsobjektet innehåller de inställningar som konfigurerar kapacitet för molnnivåindelning , vilket ger cachelagringsfunktionen i Azure File Sync. För att kunna synkronisera med en Azure-filresurs måste lagringskontot som innehåller Azure-filresursen finnas i samma Azure-region som Storage Sync Service.

Viktigt!

Du kan göra ändringar i namnområdet för valfri molnslutpunkt eller serverslutpunkt i synkroniseringsgruppen och låta dina filer synkroniseras till de andra slutpunkterna i synkroniseringsgruppen. Om du gör en direkt ändring av molnslutpunkten (Azure-filresursen) måste ändringar först identifieras av ett Azure File Sync-ändringsidentifieringsjobb. Ett jobb för ändringsidentifiering initieras för en molnslutpunkt bara en gång var 24:e timme. Mer information finns i Vanliga frågor och svar om Azure Files.

Överväg antalet synkroniseringstjänster för lagring som behövs

I ett tidigare avsnitt beskrivs den kärnresurs som ska konfigureras för Azure File Sync: en tjänst för lagringssynkronisering. En Windows Server kan bara registreras till en synkroniseringstjänst för lagring. Så det är ofta bäst att bara distribuera en enda Storage Sync-tjänst och registrera alla servrar på den.

Skapa endast flera Synkroniseringstjänster för lagring om du har:

• distinkta uppsättningar servrar som aldrig får utbyta data med varandra. I det här fallet vill du utforma systemet för att undanta vissa uppsättningar servrar som ska synkroniseras med en Azure-filresurs som redan används som en molnslutpunkt i en synkroniseringsgrupp i en annan Tjänst för synkronisering av lagring. Ett annat sätt att titta på detta är att Windows-servrar som är registrerade i en annan lagringssynkroniseringstjänst inte kan synkroniseras med samma Azure-filresurs.
• ett behov av att ha fler registrerade servrar eller synkroniseringsgrupper än vad en enda Storage Sync Service kan stödja. Mer information finns i skalningsmålen för Azure File Sync.

Planera för balanserade synkroniseringstopologier

Innan du distribuerar några resurser är det viktigt att planera vad du ska synkronisera på en lokal server, med vilken Azure-filresurs. Genom att skapa en plan kan du avgöra hur många lagringskonton, Azure-filresurser och synkroniseringsresurser du behöver. Dessa överväganden är fortfarande relevanta, även om dina data för närvarande inte finns på en Windows Server eller den server som du vill använda på lång sikt. Migreringsavsnittet kan hjälpa dig att fastställa lämpliga migreringsvägar för din situation.

I det här steget avgör du hur många Azure-filresurser du behöver. En enda Windows Server-instans (eller ett kluster) kan synkronisera upp till 30 Azure-filresurser.

Du kan ha fler mappar på dina volymer som du för närvarande delar lokalt som SMB-resurser till dina användare och appar. Det enklaste sättet att föreställa sig det här scenariot är att föreställa sig en lokal resurs som mappar 1:1 till en Azure-filresurs. Om du har ett tillräckligt litet antal resurser, under 30 för en enda Windows Server-instans, rekommenderar vi en 1:1-mappning.

Om du har fler än 30 resurser är det ofta onödigt att mappa en lokal resurs 1:1 till en Azure-filresurs. Överväg följande alternativ.

Dela gruppering

Om personalavdelningen till exempel har 15 resurser kan du överväga att lagra alla HR-data i en enda Azure-filresurs. Att lagra flera lokala resurser i en Azure-filresurs hindrar dig inte från att skapa de vanliga 15 SMB-resurserna på din lokala Windows Server-instans. Det innebär bara att du organiserar rotmapparna för dessa 15 resurser som undermappar under en gemensam mapp. Sedan synkroniserar du den här gemensamma mappen till en Azure-filresurs. På så sätt behövs bara en enda Azure-filresurs i molnet för den här gruppen med lokala resurser.

Volymsynkronisering

Azure File Sync stöder synkronisering av roten på en volym till en Azure-filresurs. Om du synkroniserar volymroten går alla undermappar och filer till samma Azure-filresurs.

Att synkronisera volymens rot är inte alltid det bästa alternativet. Det finns fördelar med att synkronisera flera platser. Om du till exempel gör det kan du hålla antalet objekt lägre per synkroniseringsomfång. Vi testar Azure-filresurser och Azure File Sync med 100 miljoner objekt (filer och mappar) per resurs. Men bästa praxis är att försöka hålla antalet under 20 miljoner eller 30 miljoner i en enda andel. Att konfigurera Azure File Sync med ett lägre antal objekt är inte bara fördelaktigt för filsynkronisering. Ett lägre antal objekt har också fördelar med scenarier som dessa:

• Den första genomsökningen av molninnehållet kan slutföras snabbare, vilket i sin tur minskar väntan på att namnområdet ska visas på en server som är aktiverad för Azure File Sync.
• Det går snabbare att återställa molnsidan från en Ögonblicksbild av Azure-filresursen.
• Haveriberedskapen för en lokal server kan påskyndas avsevärt.
• Ändringar som görs direkt i en Azure-filresurs (utanför synkroniseringen) kan identifieras och synkroniseras snabbare.

Dricks

Om du inte vet hur många filer och mappar du har kan du kolla in verktyget TreeSize från JAM Software GmbH.

En strukturerad metod för en distributionskarta

Innan du distribuerar molnlagring i ett senare steg är det viktigt att skapa en karta mellan lokala mappar och Azure-filresurser. Den här mappningen informerar hur många och vilka Azure File Sync-synkroniseringsgruppresurser du ska etablera. En synkroniseringsgrupp kopplar samman Azure-filresursen och mappen på servern och upprättar en synkroniseringsanslutning.

Information om hur många Azure-filresurser du behöver finns i följande begränsningar och metodtips. Om du gör det kan du optimera kartan.

• En server där Azure File Sync-agenten är installerad kan synkroniseras med upp till 30 Azure-filresurser.

• En Azure-filresurs distribueras i ett lagringskonto. Det här arrangemanget gör lagringskontot till ett skalningsmål för prestandanummer som IOPS och dataflöde.

  Var uppmärksam på IOPS-begränsningarna för ett lagringskonto när du distribuerar Azure-filresurser. Helst bör du mappa filresurser 1:1 med lagringskonton. Detta kanske dock inte alltid är möjligt på grund av olika gränser och begränsningar, både från din organisation och från Azure. När det inte är möjligt att bara ha en filresurs distribuerad på ett lagringskonto bör du överväga vilka resurser som är mycket aktiva och vilka resurser som är mindre aktiva för att säkerställa att de hetaste filresurserna inte sätts in på samma lagringskonto tillsammans.

  Om du planerar att lyfta en app till Azure som ska använda Azure-filresursen internt kan du behöva mer prestanda från din Azure-filresurs. Om den här typen av användning är en möjlighet, även i framtiden, är det bäst att skapa en enda Standard Azure-filresurs i sitt eget lagringskonto.

• Det finns en gräns på 250 lagringskonton per prenumeration per Azure-region.

Dricks

Med den här informationen blir det ofta nödvändigt att gruppera flera mappar på den översta nivån på dina volymer i en ny gemensam rotkatalog. Sedan synkroniserar du den nya rotkatalogen och alla mappar som du grupperade i den till en enda Azure-filresurs. Med den här tekniken kan du hålla dig inom gränsen på 30 Azure-filresurssynkroniseringar per server.

Den här gruppering under en vanlig rot påverkar inte åtkomsten till dina data. Dina ACL:er håller sig som de är. Du behöver bara justera eventuella resurssökvägar (till exempel SMB- eller NFS-resurser) som du kan ha på de lokala servermappar som du nu har ändrat till en gemensam rot. Inget annat ändras.

Viktigt!

Den viktigaste skalningsvektorn för Azure File Sync är antalet objekt (filer och mappar) som måste synkroniseras. Mer information finns i skalningsmålen för Azure File Sync.

Det är en bra idé att hålla antalet objekt per synkroniseringsomfång lågt. Det är en viktig faktor att tänka på i mappningen av mappar till Azure-filresurser. Azure File Sync testas med 100 miljoner objekt (filer och mappar) per resurs. Men det är ofta bäst att hålla antalet objekt under 20 miljoner eller 30 miljoner i en enda andel. Dela upp namnområdet i flera resurser om du börjar överskrida dessa tal. Du kan fortsätta att gruppera flera lokala resurser i samma Azure-filresurs om du ligger ungefär under dessa siffror. Den här metoden ger dig utrymme att växa.

Det är möjligt att en uppsättning mappar i din situation kan synkroniseras logiskt med samma Azure-filresurs (med hjälp av den nya gemensamma rotmappsmetoden som nämndes tidigare). Men det kan fortfarande vara bättre att omgruppera mappar så att de synkroniseras till två i stället för en Azure-filresurs. Du kan använda den här metoden för att hålla antalet filer och mappar per filresurs balanserade på servern. Du kan också dela upp dina lokala resurser och synkronisera mellan fler lokala servrar, vilket lägger till möjligheten att synkronisera med ytterligare 30 Azure-filresurser per extra server.

Vanliga scenarier och överväganden för filsynkronisering

#	Synkroniseringsscenario	Stöds	Överväganden (eller begränsningar)	Lösning (eller lösning)
1	Filserver med flera diskar/volymer och flera resurser till samma Azure-målfilresurs (konsolidering)	Nej	En Azure-målfilresurs (molnslutpunkt) stöder endast synkronisering med en synkroniseringsgrupp. En synkroniseringsgrupp stöder endast en serverslutpunkt per registrerad server.	1) Börja med att synkronisera en disk (dess rotvolym) för att rikta in sig på Azure-filresursen. Från och med den största disken/volymen hjälper det med lagringskraven lokalt. Konfigurera molnnivåindelning för att nivåindela alla data till molnet, vilket frigör utrymme på filserverdisken. Flytta data från andra volymer/resurser till den aktuella volymen som synkroniseras. Fortsätt stegen en i taget tills alla data har nivåindelats upp till molnet/migrerats. 2) Rikta in sig på en rotvolym (disk) i taget. Använd molnnivåindelning för att nivåindela alla data för att rikta in sig på Azure-filresurs. Ta bort serverslutpunkten från synkroniseringsgruppen, återskapa slutpunkten med nästa rotvolym/disk, synkronisera och upprepa processen. Obs! Ominstallation av agenten kan krävas. 3) Rekommenderar att du använder flera Azure-målfilresurser (samma eller ett annat lagringskonto baserat på prestandakrav)
2	Filserver med en enskild volym och flera resurser till samma Azure-målfilresurs (konsolidering)	Ja	Det går inte att ha flera serverslutpunkter per registrerad serversynkronisering till samma Azure-målfilresurs (samma som ovan)	Synkronisera roten på volymen som innehåller flera resurser eller mappar på den översta nivån. Mer information finns i Dela grupperingskoncept och Volymsynkronisering.
3	Filserver med flera resurser och/eller volymer till flera Azure-filresurser under ett enda lagringskonto (1:1 resursmappning)	Ja	En enda Windows Server-instans (eller ett kluster) kan synkronisera upp till 30 Azure-filresurser. Ett lagringskonto är ett skalningsmål för prestanda. IOPS och dataflöde delas mellan filresurser. Behåll antalet objekt per synkroniseringsgrupp inom 100 miljoner objekt (filer och mappar) per resurs. Helst är det bäst att hålla sig under 20 eller 30 miljoner per aktie.	1) Använd flera synkroniseringsgrupper (antal synkroniseringsgrupper = antal Azure-filresurser att synkronisera med). 2) Endast 30 resurser kan synkroniseras i det här scenariot åt gången. Om du har fler än 30 resurser på filservern använder du konceptet Dela gruppering och Volymsynkronisering för att minska antalet rotmappar eller toppnivåmappar vid källan. 3) Använd ytterligare filsynkroniseringsservrar lokalt och dela upp/flytta data till dessa servrar för att kringgå begränsningar på Windows-källservern.
4	Filserver med flera resurser och/eller volymer till flera Azure-filresurser under ett annat lagringskonto (1:1 resursmappning)	Ja	En enskild Windows Server-instans (eller ett kluster) kan synkronisera upp till 30 Azure-filresurser (samma eller ett annat lagringskonto). Behåll antalet objekt per synkroniseringsgrupp inom 100 miljoner objekt (filer och mappar) per resurs. Helst är det bäst att hålla sig under 20 eller 30 miljoner per aktie.	Samma metod som ovan
5	Flera filservrar med enskild (rotvolym eller resurs) till samma Azure-målfilresurs (konsolidering)	Nej	En synkroniseringsgrupp kan inte använda molnslutpunkt (Azure-filresurs) som redan har konfigurerats i en annan synkroniseringsgrupp. Även om en synkroniseringsgrupp kan ha serverslutpunkter på olika filservrar kan filerna inte vara distinkta.	Följ vägledningen i scenario nr 1 ovan med ytterligare övervägande av att rikta in sig på en filserver i taget.

Skapa en mappningstabell

Använd den tidigare informationen för att avgöra hur många Azure-filresurser du behöver och vilka delar av dina befintliga data som ska hamna i vilken Azure-filresurs.

Skapa en tabell som registrerar dina tankar så att du kan referera till den när du behöver det. Det är viktigt att hålla ordning eftersom det kan vara enkelt att förlora information om din mappningsplan när du etablerar många Azure-resurser samtidigt. Ladda ned följande Excel-fil som ska användas som mall för att skapa mappningen.

Ladda ned en mall för namnområdesmappning.

Överväganden för Windows-filserver

Om du vill aktivera synkroniseringsfunktionen på Windows Server måste du installera den nedladdningsbara agenten för Azure File Sync. Azure File Sync-agenten innehåller två huvudkomponenter: FileSyncSvc.exe, windows-bakgrundstjänsten som ansvarar för att övervaka ändringar på serverslutpunkterna och initiera synkroniseringssessioner, och StorageSync.sys, ett filsystemfilter som möjliggör molnnivåindelning och snabb haveriberedskap.

Operativsystemskrav

Azure File Sync stöds med följande versioner av Windows Server:

Version	SKU:er som stöds	Distributionsalternativ som stöds
Windows Server 2022	Azure, Datacenter, Standard och IoT	Full och Core
Windows Server 2019	Datacenter, Standard och IoT	Full och Core
Windows Server 2016	Datacenter, standard och lagringsserver	Full och Core
Windows Server 2012 R2*	Datacenter, standard och lagringsserver	Full och Core

*Kräver nedladdning och installation av Windows Management Framework (WMF) 5.1. Det lämpliga paketet för att ladda ned och installera för Windows Server 2012 R2 är Win8.1AndW2K12R2-KB*******-x64.msu.

Framtida versioner av Windows Server läggs till när de släpps.

Viktigt!

Vi rekommenderar att du håller alla servrar som du använder med Azure File Sync uppdaterade med de senaste uppdateringarna från Windows Update.

Minsta systemresurser

Azure File Sync kräver en server, antingen fysisk eller virtuell, med minst en PROCESSOR, minst 2 GiB minne och en lokalt ansluten volym formaterad med NTFS-filsystemet.

Viktigt!

Om servern körs på en virtuell dator med dynamiskt minne aktiverat bör den virtuella datorn konfigureras med minst 2 048 MiB minne.

För de flesta produktionsarbetsbelastningar rekommenderar vi inte att du konfigurerar en Azure File Sync-synkroniseringsserver med endast minimikraven. Mer information finns i Rekommenderade systemresurser .

Rekommenderade systemresurser

Precis som för alla serverfunktioner och appar bestäms systemresurskraven för Azure File Sync av distributionens skala. Större distributioner på en server behöver mer systemresurser. För Azure File Sync bestäms skalan av antalet objekt vid serverslutpunkterna och datamängdens omsättning. En enskild server kan ha serverslutpunkter i flera synkroniseringsgrupper och antalet objekt som anges i följande tabell avser hela namnområdet som en server är ansluten till.

Exempel: serverslutpunkt A med 10 miljoner objekt + serverslutpunkt B med 10 miljoner objekt = 20 miljoner objekt. I den här exempeldistributionen rekommenderar vi 8 processorer, 16 GiB minne för stabilt tillstånd och (om möjligt) 48 GiB minne för den initiala migreringen.

Namnområdesdata lagras i minnet av prestandaskäl. Det här gör att större namnområden behöver mer minne för att bibehålla bra prestanda, och det behövs fler processorer för att hantera större omsättning.

I följande tabell har vi angett både namnområdets storlek och en konvertering till kapacitet för typiska allmänna filresurser, där den genomsnittliga filstorleken är 512 KiB. Om filstorlekarna är mindre kan du överväga att lägga till mer minne för samma kapacitet. Basera minneskonfigurationen på namnområdets storlek.

Namnområdesstorlek – filer och kataloger (miljoner)	Typisk kapacitet (TiB)	Processorkärnor	Rekommenderat minne (GiB)
3	1.4	2	8 (initial synkronisering)/2 (typisk omsättning)
5	2.3	2	16 (initial synkronisering)/4 (typisk omsättning)
10	4.7	4	32 (initial synkronisering)/8 (typisk omsättning)
30	14,0	8	48 (initial synkronisering)/16 (typisk omsättning)
50	23,3	16	64 (initial synkronisering)/32 (typisk omsättning)
100*	46,6	32	128 (initial synkronisering)/32 (typisk omsättning)

*Vi rekommenderar inte att du synkroniserar fler än 100 miljoner filer och kataloger. Det här är en mjuk gräns som baseras på våra testade tröskelvärden. Mer information finns i Skalningsmål för Azure File Sync.

Dricks

Den inledande synkroniseringen av ett namnområde är en intensiv åtgärd och vi rekommenderar att du allokerar mer minne tills den inledande synkroniseringen är klar. Detta krävs inte, men det kan påskynda den inledande synkroniseringen.

Normal omsättning är 0,5 % av namnområdet per dag. Om omsättningen är högre kan du lägga till fler processorer.

Cmdlet för utvärdering

Innan du distribuerar Azure File Sync bör du utvärdera om det är kompatibelt med systemet med hjälp av cmdleten Azure File Sync-utvärdering. Den här cmdleten söker efter potentiella problem med filsystemet och datauppsättningen, till exempel tecken som inte stöds eller en operativsystemversion som inte stöds. Dessa kontroller omfattar de flesta men inte alla funktioner som nämns nedan; Vi rekommenderar att du läser igenom resten av det här avsnittet noggrant för att säkerställa att distributionen går smidigt.

Utvärderings-cmdleten kan installeras genom att installera Az PowerShell-modulen, som kan installeras genom att följa anvisningarna här: Installera och konfigurera Azure PowerShell.

Användning

Du kan anropa utvärderingsverktyget på några olika sätt: du kan utföra systemkontrollerna, datamängdskontrollerna eller båda. Så här utför du både system- och datauppsättningskontroller:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

Så här testar du endast din datauppsättning:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Så här testar du endast systemkrav:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

Så här visar du resultatet i CSV:

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

Filsystemkompatibilitet

Azure File Sync stöds endast på direktanslutna NTFS-volymer. Direktansluten lagring, eller DAS, på Windows Server innebär att Windows Server-operativsystemet äger filsystemet. DAS kan tillhandahållas genom att fysiskt ansluta diskar till filservern, ansluta virtuella diskar till en virtuell filserverdator (till exempel en virtuell dator som hanteras av Hyper-V) eller till och med via iSCSI.

Endast NTFS-volymer stöds. ReFS, FAT, FAT32 och andra filsystem stöds inte.

I följande tabell visas interoptillståndet för NTFS-filsystemfunktioner:

Funktion	Supportstatus	Kommentar
Åtkomstkontrollistor (ACL)	Stöds fullt ut	Diskretionära åtkomstkontrollistor i Windows-format bevaras av Azure File Sync och tillämpas av Windows Server på serverslutpunkter. ACL:er kan också tillämpas vid direkt montering av Azure-filresursen, men detta kräver ytterligare konfiguration. Mer information finns i avsnittet Identitet.
Hårda länkar	Hoppades över
Symboliska länkar	Hoppades över
Monteringspunkter	Delvis stöd	Monteringspunkter kan vara roten till en serverslutpunkt, men de hoppas över om de finns i en serverslutpunkts namnrymd.
Korsningar	Hoppades över	Till exempel mapparna Distributed File System DfrsrPrivate och DFSRoots.
Referenspunkter	Hoppades över
NTFS-komprimering	Delvis stöd	Azure File Sync stöder inte serverslutpunkter som finns på en volym som har SVI-katalogen (systemvolyminformation) komprimerad.
Glesa filer	Stöds fullt ut	Synkronisering av sparse-filer (blockeras inte), men de synkroniseras till molnet som en fullständig fil. Om filinnehållet ändras i molnet (eller på en annan server) är filen inte längre gles när ändringen laddas ned.
Alternativa data Flöden (ADS)	Bevarad, men inte synkroniserad	Klassificeringstaggar som skapats av filklassificeringsinfrastrukturen synkroniseras till exempel inte. Befintliga klassificeringstaggar på filer på var och en av serverslutpunkterna lämnas orörda.

Azure File Sync hoppar också över vissa temporära filer och systemmappar:

Fil/mapp	Kommentar
pagefile.sys	Fil som är specifik för systemet
Desktop.ini	Fil som är specifik för systemet
Thumbs.db	Temporär fil för miniatyrer
ehthumbs.db	Temporär fil för medieminiatyrer
~$*.*	temporär Office-fil
*.Tmp	Temporär fil
*.laccdb	Access DB-låsningsfil
635D02A9D91C401B97884B82B3BCDAEA.*	Intern synkroniseringsfil
\Systemvolyminformation	Mapp som är specifik för volymen
$RECYCLE. BIN	Mapp
\SyncShareState	Mapp för synkronisering
. SystemShareInformation	Mapp för synkronisering i Azure-filresurs

Kommentar

Även om Azure File Sync stöder synkronisering av databasfiler är databaser inte en bra arbetsbelastning för synkroniseringslösningar (inklusive Azure File Sync) eftersom loggfilerna och databaserna måste synkroniseras tillsammans och de kan bli osynkroniserade av olika orsaker som kan leda till att databasen skadas.

Fundera på hur mycket ledigt utrymme du behöver på din lokala disk

När du planerar att använda Azure File Sync bör du fundera på hur mycket ledigt utrymme du behöver på den lokala disk som du planerar att ha en serverslutpunkt på.

Med Azure File Sync måste du ta hänsyn till följande utrymme på din lokala disk:

• Med molnnivåindelning aktiverat:

  • Referenspunkter för nivåindelade filer
  • Azure File Sync-metadatadatabas
  • Azure File Sync-värmelager
  • Fullständigt nedladdade filer i din frekventa cache (om någon)
  • Principkrav för ledigt utrymme för volym

• Med molnnivåindelning inaktiverad:

  • Fullständigt nedladdade filer
  • Azure File Sync-värmelager
  • Azure File Sync-metadatadatabas

Vi använder ett exempel för att illustrera hur du beräknar hur mycket ledigt utrymme som skulle behövas på den lokala disken. Anta att du har installerat Azure File Sync-agenten på din virtuella Azure Windows-dator och planerar att skapa en serverslutpunkt på disk F. Du har 1 miljon filer och vill nivåindela dem alla, 100 000 kataloger och en diskklusterstorlek på 4 KiB. Diskstorleken är 1 000 GiB. Du vill aktivera molnnivåindelning och ställa in principen för ledigt utrymme på 20 %.

1. NTFS allokerar en klusterstorlek för var och en av de nivåindelade filerna. 1 miljon filer * 4 KiB-klusterstorlek = 4 000 000 KiB (4 GiB)

   Kommentar

   För att dra full nytta av molnnivåindelning rekommenderar vi att du använder mindre NTFS-klusterstorlekar (mindre än 64KiB) eftersom varje nivåindelad fil upptar ett kluster. Dessutom allokeras utrymmet som upptas av nivåindelade filer av NTFS. Därför visas den inte i något användargränssnitt.

2. Synkroniseringsmetadata upptar en klusterstorlek per objekt. (1 miljon filer + 100 000 kataloger) * 4 KiB-klusterstorlek = 4 400 000 KiB (4,4 GiB)
3. Azure File Sync-värmelager upptar 1,1 KiB per fil. 1 miljon filer * 1,1 KiB = 1 100 000 KiB (1,1 GiB)
4. Principen för ledigt utrymme för volym är 20 %. 1000 GiB * 0,2 = 200 GiB

I det här fallet skulle Azure File Sync behöva cirka 209 500 000 KiB (209,5 GiB) utrymme för det här namnområdet. Lägg till den här mängden till ytterligare ledigt utrymme som önskas för att ta reda på hur mycket ledigt utrymme som krävs för den här disken.

Redundanskluster

1. Windows Server-redundansklustring stöds av Azure File Sync för distributionsalternativet "Filserver för allmänt bruk". Mer information om hur du konfigurerar rollen "Filserver för allmän användning" i ett redundanskluster finns i Distribuera en klustrad filserver med två noder.
2. Det enda scenario som stöds av Azure File Sync är Windows Server-redundanskluster med klustrade diskar
3. Redundansklustring stöds inte på "Skalbar filserver för programdata" (SOFS) eller på klustrade delade volymer (CSV:er) eller lokala diskar.

Kommentar

Azure File Sync-agenten måste vara installerad på varje nod i ett redundanskluster för att synkroniseringen ska fungera korrekt.

Datadeduplicering

Windows Server 2022, Windows Server 2019 och Windows Server 2016
Datadeduplicering stöds oavsett om molnnivåindelning är aktiverat eller inaktiverat på en eller flera serverslutpunkter på volymen för Windows Server 2016, Windows Server 2019 och Windows Server 2022. Om du aktiverar Datadeduplicering på en volym med molnnivåindelning aktiverat kan du cachelagra fler filer lokalt utan att etablera mer lagring.

När Datadeduplicering är aktiverat på en volym med molnnivåindelning aktiverad kommer dedupliceringsoptimerade filer på serverslutpunktens plats att nivåindelas på samma nivå som en normal fil baserat på principinställningarna för molnnivåindelning. När de deduplicerade filerna har nivåindelats körs skräpinsamlingsjobbet datadeduplicering automatiskt för att frigöra diskutrymme genom att ta bort onödiga segment som inte längre refereras av andra filer på volymen.

Observera att volymbesparingarna endast gäller för servern. dina data i Azure-filresursen kommer inte att dedupliceras.

Kommentar

För att stöda datadeduplicering på volymer med molnnivåindelning aktiverat på Windows Server 2019 måste Windows Update KB4520062 – oktober 2019 eller en senare månatlig samlad uppdatering installeras.

Windows Server 2012 R2
Azure File Sync stöder inte datadeduplicering och molnnivåindelning på samma volym på Windows Server 2012 R2. Om Datadeduplicering är aktiverat på en volym måste molnnivåindelning inaktiveras.

Anteckningar

• Om Datadeduplicering installeras innan du installerar Azure File Sync-agenten krävs en omstart för att stödja datadeduplicering och molnnivåindelning på samma volym.

• Om Datadeduplicering är aktiverat på en volym när molnnivåindelning har aktiverats optimerar det första optimeringsjobbet för deduplicering filer på volymen som inte redan har nivåindelats och får följande inverkan på molnnivåindelningen:

  • Principen för ledigt utrymme fortsätter att nivåindela filer enligt det lediga utrymmet på volymen med hjälp av värmekartan.
  • Datumprincipen hoppar över nivåindelning av filer som annars kan ha varit berättigade till nivåindelning på grund av att optimeringsjobbet för deduplicering har åtkomst till filerna.

• För pågående jobb för dedupliceringsoptimering fördröjs molnnivåindelningen med datumprincipen av inställningen MinimumFileAgeDays för datadeduplicering, om filen inte redan är nivåindelad.

  • Exempel: Om inställningen MinimumFileAgeDays är sju dagar och molnnivåprincipen är 30 dagar kommer datumprincipen att nivåindela filer efter 37 dagar.
  • Obs! När en fil har nivåindelats av Azure File Sync hoppar dedupliceringsoptimeringsjobbet över filen.

• Om en server som kör Windows Server 2012 R2 med Azure File Sync-agenten installerad uppgraderas till Windows Server 2016, Windows Server 2019 eller Windows Server 2022 måste följande steg utföras för att stödja datadeduplicering och molnnivåindelning på samma volym:

  • Avinstallera Azure File Sync-agenten för Windows Server 2012 R2 och starta om servern.
  • Ladda ned Azure File Sync-agenten för den nya versionen av serveroperativsystemet (Windows Server 2016, Windows Server 2019 eller Windows Server 2022).
  • Installera Azure File Sync-agenten och starta om servern.

  Obs! Konfigurationsinställningarna för Azure File Sync på servern behålls när agenten avinstalleras och installeras om.

Distribuerat filsystem (DFS)

Azure File Sync stöder interop med DFS-namnområden (DFS-N) och DFS Replication (DFS-R).

DFS-namnområden (DFS-N): Azure File Sync stöds fullt ut med DFS-N-implementering. Du kan installera Azure File Sync-agenten på en eller flera filservrar för att synkronisera data mellan serverslutpunkterna och molnslutpunkten och sedan använda DFS-N för att tillhandahålla namnområdestjänsten. Mer information finns i översikten över DFS-namnområden och DFS-namnområden med Azure Files.

DFS Replication (DFS-R): Eftersom BÅDE DFS-R och Azure File Sync är replikeringslösningar rekommenderar vi i de flesta fall att du ersätter DFS-R med Azure File Sync. Det finns dock flera scenarier där du vill använda DFS-R och Azure File Sync tillsammans:

• Du migrerar från en DFS-R-distribution till en Azure File Sync-distribution. Mer information finns i Migrera en DFS Replication-distribution (DFS-R) till Azure File Sync.
• Alla lokala servrar som behöver en kopia av dina fildata kan inte anslutas direkt till Internet.
• Grenservrar konsoliderar data till en enda hubbserver som du vill använda Azure File Sync för.

Så här fungerar Azure File Sync och DFS-R sida vid sida:

1. Azure File Sync-molnnivåindelning måste inaktiveras på volymer med DFS-R-replikerade mappar.
2. Serverslutpunkter bör inte konfigureras på skrivskyddade DFS-R-replikeringsmappar.
3. Endast en enskild serverslutpunkt kan överlappa med en DFS-R-plats. Flera serverslutpunkter som överlappar andra aktiva DFS-R-platser kan leda till konflikter.

Mer information finns i översikten över DFS Replication.

Sysprep

Användning av sysprep på en server som har Azure File Sync-agenten installerad stöds inte och kan leda till oväntade resultat. Agentinstallation och serverregistrering bör ske när du har distribuerat serverbilden och slutfört minikonfigurationen av sysprep.

Windows-sök

Om molnnivåindelning är aktiverat på en serverslutpunkt hoppas filer som är nivåindelade över och indexeras inte av Windows Search. Icke-nivåindelade filer indexeras korrekt.

Kommentar

Windows-klienter orsakar återkallanden vid sökning i filresursen om inställningen Sök alltid efter filnamn och innehåll är aktiverad på klientdatorn. Den här inställningen är inaktiverad som standard.

Andra HSM-lösningar (Hierarchical Storage Management)

Inga andra HSM-lösningar ska användas med Azure File Sync.

Prestanda och skalbarhet   

Eftersom Azure File Sync-agenten körs på en Windows Server-dator som ansluter till Azure-filresurserna beror den effektiva synkroniseringsprestandan på ett antal faktorer i din infrastruktur: Windows Server och den underliggande diskkonfigurationen, nätverksbandbredden mellan servern och Azure Storage, filstorleken, datamängdens totala storlek och aktiviteten på datauppsättningen. Eftersom Azure File Sync fungerar på filnivå mäts prestandaegenskaperna för en Azure File Sync-baserad lösning bättre i antalet objekt (filer och kataloger) som bearbetas per sekund.

Ändringar som görs i Azure-filresursen med hjälp av Azure-portalen eller SMB identifieras inte omedelbart och replikeras som ändringar i serverslutpunkten. Azure Files har inga ändringsmeddelanden eller journaler, så det finns inget sätt att automatiskt initiera en synkroniseringssession när filer ändras. På Windows Server använder Azure File Sync Windows USN-journaler för att automatiskt initiera en synkroniseringssession när filer ändras.

Om du vill identifiera ändringar i Azure-filresursen har Azure File Sync ett schemalagt jobb som kallas ändringsidentifieringsjobb. Ett ändringsidentifieringsjobb räknar upp varje fil i filresursen och jämför den sedan med synkroniseringsversionen för filen. När ändringsidentifieringsjobbet fastställer att filer har ändrats initieras en synkroniseringssession av Azure File Sync. Ändringsidentifieringsjobbet initieras var 24:e timme. Eftersom ändringsidentifieringsjobbet räknar upp varje fil i Azure-filresursen tar ändringsidentifieringen längre tid i större namnområden än i mindre namnområden. För stora namnområden kan det ta längre tid än en gång var 24:e timme att avgöra vilka filer som har ändrats.

Mer information finns i Prestandamått för Azure File Sync och Azure File Sync-skalningsmål

Identitet

Azure File Sync fungerar med din AD-baserade standardidentitet utan någon särskild konfiguration utöver att konfigurera synkronisering. När du använder Azure File Sync är den allmänna förväntningen att de flesta åtkomster går via Azure File Sync-cachelagringsservrarna i stället för via Azure-filresursen. Eftersom serverslutpunkterna finns på Windows Server och Windows Server har stöd för ACL:er i AD- och Windows-format under en längre tid behövs ingenting utöver att se till att De Windows-filservrar som registrerats med Tjänsten för synkronisering av lagring är domänanslutna. Azure File Sync lagrar ACL:er på filerna i Azure-filresursen och replikerar dem till alla serverslutpunkter.

Även om ändringar som görs direkt i Azure-filresursen tar längre tid att synkronisera till serverslutpunkterna i synkroniseringsgruppen, kanske du också vill se till att du kan framtvinga dina AD-behörigheter på filresursen direkt i molnet också. För att göra detta måste du domänansluta ditt lagringskonto till din lokala AD, precis som hur dina Windows-filservrar är domänanslutna. Mer information om domänanslutning till ditt lagringskonto till en kundägd Active Directory finns i Översikt över Azure Files Active Directory.

Viktigt!

Domän som ansluter ditt lagringskonto till Active Directory krävs inte för att distribuera Azure File Sync. Det här är ett strikt valfritt steg som gör att Azure-filresursen kan framtvinga lokala ACL:er när användarna monterar Azure-filresursen direkt.

Nätverk

Azure File Sync-agenten kommunicerar med lagringssynkroniseringstjänsten och Azure-filresursen med hjälp av AZURE File Sync REST-protokollet och FileREST-protokollet, som båda alltid använder HTTPS via port 443. SMB används aldrig för att ladda upp eller ladda ned data mellan din Windows Server och Azure-filresursen. Eftersom de flesta organisationer tillåter HTTPS-trafik via port 443, som ett krav för att besöka de flesta webbplatser, krävs vanligtvis inte särskild nätverkskonfiguration för att distribuera Azure File Sync.

Viktigt!

Azure File Sync stöder inte Internetroutning. Standardalternativet för nätverksroutning, Microsoft-routning, stöds av Azure File Sync.

Baserat på din organisations princip eller unika regelkrav kan du kräva mer restriktiv kommunikation med Azure, och därför tillhandahåller Azure File Sync flera mekanismer för att konfigurera nätverk. Baserat på dina krav kan du:

• Tunnelsynkronisering och filuppladdnings-/nedladdningstrafik via ExpressRoute eller Azure VPN.
• Använd Azure Files- och Azure Networking-funktioner som tjänstslutpunkter och privata slutpunkter.
• Konfigurera Azure File Sync för att stödja proxyn i din miljö.
• Begränsa nätverksaktiviteten från Azure File Sync.

Dricks

Om du vill kommunicera med din Azure-filresurs via SMB men port 445 blockeras kan du överväga att använda SMB via QUIC, som erbjuder "SMB VPN" utan konfiguration för SMB-åtkomst till dina Azure-filresurser med hjälp av QUIC-transportprotokollet via port 443. Även om Azure Files inte har direkt stöd för SMB via QUIC kan du skapa en enkel cache av dina Azure-filresurser på en virtuell Windows Server 2022 Azure Edition-dator med Hjälp av Azure File Sync. Mer information om det här alternativet finns i SMB over QUIC with Azure File Sync (SMB over QUIC with Azure File Sync).

Mer information om Azure File Sync och nätverk finns i Nätverksöverväganden för Azure File Sync.

Kryptering

När du använder Azure File Sync finns det tre olika krypteringsnivåer att tänka på: kryptering på den vilande lagringen av Windows Server, kryptering under överföring mellan Azure File Sync-agenten och Azure och kryptering i resten av dina data i Azure-filresursen.

Windows Server-kryptering i vila

Det finns två strategier för att kryptera data på Windows Server som fungerar vanligtvis med Azure File Sync: kryptering under filsystemet så att filsystemet och alla data som skrivs till det krypteras och kryptering i själva filformatet. Dessa metoder är inte ömsesidigt uteslutande. de kan användas tillsammans om så önskas eftersom syftet med kryptering är annorlunda.

Windows Server tillhandahåller BitLocker-inkorg för att tillhandahålla kryptering under filsystemet. BitLocker är helt transparent för Azure File Sync. Den främsta orsaken till att använda en krypteringsmekanism som BitLocker är att förhindra fysisk exfiltrering av data från ditt lokala datacenter genom att någon stjäl diskarna och för att förhindra separat inläsning av ett obehörigt operativsystem för att utföra obehöriga läsningar/skrivningar till dina data. Mer information om BitLocker finns i BitLocker-översikt.

Produkter från tredje part som fungerar på samma sätt som BitLocker, eftersom de ligger under NTFS-volymen, bör på samma sätt fungera helt transparent med Azure File Sync.

Den andra huvudmetoden för att kryptera data är att kryptera filens dataström när programmet sparar filen. Vissa program kan göra detta internt, men detta är vanligtvis inte fallet. Ett exempel på en metod för att kryptera filens dataström är Azure Information Protection (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS. Den främsta orsaken till att använda en krypteringsmekanism som AIP/RMS är att förhindra dataexfiltrering av data från filresursen genom att personer kopierar dem till alternativa platser, till exempel till ett flashminne eller skickar dem till en obehörig person via e-post. När en fils dataström krypteras som en del av filformatet fortsätter den här filen att krypteras på Azure-filresursen.

Azure File Sync samverkar inte med NTFS Encrypted File System (NTFS EFS) eller krypteringslösningar från tredje part som ligger ovanför filsystemet men under filens dataström.

Kryptering vid överföring

Kommentar

Azure File Sync-tjänsten tog bort stöd för TLS1.0 och 1.1 den 1 augusti 2020. Alla versioner av Azure File Sync-agenten som stöds använder redan TLS1.2 som standard. En tidigare version av TLS kan inträffa om TLS1.2 har inaktiverats på servern eller om en proxy används. Om du använder en proxy rekommenderar vi att du kontrollerar proxykonfigurationen. Azure File Sync-tjänstregioner som lagts till efter 2020-05-01 stöder endast TLS1.2. Mer information finns i felsökningsguiden.

Azure File Sync-agenten kommunicerar med lagringssynkroniseringstjänsten och Azure-filresursen med hjälp av AZURE File Sync REST-protokollet och FileREST-protokollet, som båda alltid använder HTTPS via port 443. Azure File Sync skickar inte okrypterade begäranden via HTTP.

Azure Storage-konton innehåller en växel för att kräva kryptering under överföring, vilket är aktiverat som standard. Även om växeln på lagringskontonivå är inaktiverad, vilket innebär att okrypterade anslutningar till dina Azure-filresurser är möjliga, använder Azure File Sync fortfarande endast krypterade kanaler för att komma åt din filresurs.

Den främsta anledningen till att inaktivera kryptering under överföring för lagringskontot är att stödja ett äldre program som måste köras på ett äldre operativsystem, till exempel Windows Server 2008 R2 eller äldre Linux-distribution, och prata direkt med en Azure-filresurs. Om det äldre programmet pratar med Windows Server-cachen för filresursen har det ingen effekt att växla den här inställningen.

Vi rekommenderar starkt att kryptering av data under överföring är aktiverat.

Mer information om kryptering under överföring finns i krav på säker överföring i Azure Storage.

Azure-filresurskryptering i vila

Alla data som lagras i Azure Files krypteras i vila med azure storage service encryption (SSE). Kryptering av lagringstjänst fungerar på samma sätt som BitLocker i Windows: data krypteras under filsystemnivån. Eftersom data krypteras under Azure-filresursens filsystem, eftersom de är kodade till disken, behöver du inte ha åtkomst till den underliggande nyckeln på klienten för att läsa eller skriva till Azure-filresursen. Kryptering i vila gäller för både SMB- och NFS-protokollen.

Som standard krypteras data som lagras i Azure Files med Microsoft-hanterade nycklar. Med Microsoft-hanterade nycklar har Microsoft nycklarna för att kryptera/dekryptera data och ansvarar för att rotera dem regelbundet. Du kan också välja att hantera dina egna nycklar, vilket ger dig kontroll över rotationsprocessen. Om du väljer att kryptera dina filresurser med kundhanterade nycklar har Azure Files behörighet att komma åt dina nycklar för att uppfylla läs- och skrivbegäranden från dina klienter. Med kundhanterade nycklar kan du återkalla den här auktoriseringen när som helst, men det innebär att din Azure-filresurs inte längre är tillgänglig via SMB eller FileREST-API:et.

Azure Files använder samma krypteringsschema som de andra Azure Storage-tjänsterna, till exempel Azure Blob Storage. Mer information om Azure Storage Service Encryption (SSE) finns i Azure Storage-kryptering för vilande data.

Lagringsnivåer

Azure Files erbjuder två olika medienivåer för lagring, SSD och HDD, som gör att du kan skräddarsy dina resurser efter prestanda- och priskraven i ditt scenario:

• SSD (Premium): Premium-filresurser som används av SSD:er (Solid State Drives) och ger konsekventa höga prestanda och låg svarstid inom ensiffriga millisekunder för de flesta I/O-åtgärder för IO-intensiva arbetsbelastningar. Premium-filresurser är lämpliga för en mängd olika arbetsbelastningar som databaser, webbplatsvärdar och utvecklingsmiljöer. Premium-filresurser kan användas med protokollen Server Message Block (SMB) och Network File System (NFS). Premium-filresurser distribueras i fillagringskontotypen och är endast tillgängliga i en etablerad faktureringsmodell. Mer information om den etablerade faktureringsmodellen för premiumfilresurser finns i Förstå etablering för premiumfilresurser. Premium-filresurser erbjuder ett serviceavtal med högre tillgänglighet än standardfilresurser (se "Azure Files Premium-nivå").

• HDD (Standard): Standardfilresurser använder hårddiskar (HDD) och tillhandahåller ett kostnadseffektivt lagringsalternativ för allmänna filresurser. Standardfilresurser distribueras i lagringskontotypen generell användning version 2 (GPv2). Information om serviceavtalet finns på sidan med Serviceavtal på Azure (se "Lagringskonton"). Standardfilresurser använder en betala per användning-modell som tillhandahåller användningsbaserad prissättning. Med åtkomstnivån för en filresurs kan du justera lagringskostnaderna mot IOPS-kostnaden för att optimera din totala faktura:

  • Transaktionsoptimerade filresurser erbjuder den lägsta kostnaden för transaktionsintensiva arbetsbelastningar som inte behöver den låga svarstid som erbjuds av Premium-filresurser. Rekommenderas vid migrering av data till Azure Files.
  • Frekventa filresurser erbjuder balanserad lagring och transaktionspriser för arbetsbelastningar som har ett bra mått på båda.
  • Lågfrekventa filresurser erbjuder de mest kostnadseffektiva lagringspriser för lagringsintensiva arbetsbelastningar.

När du väljer en medienivå för din arbetsbelastning bör du tänka på dina prestanda- och användningskrav. Om din arbetsbelastning kräver ensiffrig svarstid, eller om du använder SSD-lagringsmedia lokalt, passar premiumnivån förmodligen bäst. Om låg svarstid inte är lika mycket ett problem, till exempel med teamresurser monterade lokalt från Azure eller cachelagrade lokalt med Azure File Sync, kan standardlagring passa bättre ur ett kostnadsperspektiv.

När du har skapat en filresurs i ett lagringskonto kan du inte flytta den till nivåer som är exklusiva för olika typer av lagringskonton. Om du till exempel vill flytta en transaktionsoptimerad filresurs till premiumnivån måste du skapa en ny filresurs i ett FileStorage-lagringskonto och kopiera data från din ursprungliga resurs till en ny filresurs i FileStorage-kontot. Vi rekommenderar att du använder AzCopy för att kopiera data mellan Azure-filresurser, men du kan också använda verktyg som robocopy i Windows eller rsync för macOS och Linux.

Mer information finns i Förstå Azure Files-fakturering .

Regional tillgänglighet

För närvarande har standardfilresurser med stora filresurser aktiverade (upp till 100 TiB-kapacitet) vissa begränsningar.

• Endast lokalt redundant lagring (LRS) och ZRS-konton (zonredundant lagring) stöds.
• När du aktiverar stora filresurser på ett lagringskonto kan du inte konvertera lagringskontot till att använda geo-redundant lagring (GRS) eller geo-zonredundant lagring (GZRS).
• När du har aktiverat stora filresurser kan du inte inaktivera det.

Om du vill använda GRS eller GZRS med standard-SMB Azure-filresurser läser du Geo-redundans för Azure Files för förhandsversion av stora filresurser.

Tillgänglighet för Azure-filsynkroniseringsregion

Regional tillgänglighet finns i Produkter som är tillgängliga per region.

Följande regioner kräver att du begär åtkomst till Azure Storage innan du kan använda Azure File Sync med dem:

• Södra Frankrike
• Sydafrika, västra
• Förenade Arabemiraten, centrala

Om du vill begära åtkomst för dessa regioner följer du processen i det här dokumentet.

Redundans

För att skydda data i dina Azure-filresurser mot dataförlust eller skada lagrar Azure Files flera kopior av varje fil när de skrivs. Beroende på dina krav kan du välja olika redundansgrader. Azure Files stöder för närvarande följande alternativ för dataredundans:

• Lokalt redundant lagring (LRS): Med LRS lagras varje fil tre gånger i ett Azure Storage-kluster. Detta skyddar mot dataförlust på grund av maskinvarufel, till exempel en felaktig diskenhet. Men om en katastrof, till exempel brand eller översvämning inträffar i datacentret, kan alla repliker av ett lagringskonto som använder LRS gå förlorade eller oåterkalleliga.
• Zonredundant lagring (ZRS): Med ZRS lagras tre kopior av varje fil. Dessa kopior är dock fysiskt isolerade i tre distinkta lagringskluster i olika Azure-tillgänglighetszoner. Tillgänglighetszoner är unika fysiska platser i en Azure-region. Varje zon består av ett eller flera datacenter som är utrustade med oberoende ström, kylning och nätverk. En skrivning till lagring accepteras inte förrän den har skrivits till lagringskluster i alla tre tillgänglighetszonerna.
• Geo-redundant lagring (GRS): Med GRS har du två regioner, en primär region och en sekundär region. Filer lagras tre gånger i ett Azure-lagringskluster i den primära regionen. Skrivningar replikeras asynkront till en Microsoft-definierad sekundär region. GRS innehåller sex kopior av din dataspridning mellan två Azure-regioner. I händelse av en större katastrof, till exempel permanent förlust av en Azure-region på grund av en naturkatastrof eller någon annan liknande händelse, utför Microsoft en redundansväxling. I det här fallet blir den sekundära den primära, som betjänar alla åtgärder. Eftersom replikeringen mellan de primära och sekundära regionerna är asynkron går data som inte replikerats till den sekundära regionen förlorade i händelse av en större katastrof. Du kan också utföra en manuell redundansväxling av ett geo-redundant lagringskonto.
• Geo-zonredundant lagring (GZRS): Du kan se GZRS som ZRS, men med geo-redundans. Med GZRS lagras filer tre gånger i tre distinkta lagringskluster i den primära regionen. Alla skrivningar replikeras sedan asynkront till en Microsoft-definierad sekundär region. Redundansväxlingsprocessen för GZRS fungerar på samma sätt som GRS.

Azure-standardfilresurser på upp till 5 TiB stöder alla fyra redundanstyperna. Standardfilresurser som är större än 5 TiB stöder endast LRS och ZRS. Premium Azure-filresurser stöder endast LRS och ZRS.

Lagringskonton för generell användning version 2 (GPv2) tillhandahåller två andra redundansalternativ som Azure Files inte stöder: lästillgänglig geo-redundant lagring (RA-GRS) och lästillgänglig geo-zonredundant lagring (RA-GZRS). Du kan etablera Azure-filresurser i lagringskonton med dessa alternativ inställda, men Azure Files stöder inte läsning från den sekundära regionen. Azure-filresurser som distribueras till RA-GRS- eller RA-GZRS-lagringskonton faktureras som GRS respektive GZRS.

Viktigt!

Geo-redundant och geo-zonredundant lagring har möjlighet att manuellt redundansbeställa lagring till den sekundära regionen. Vi rekommenderar att du inte gör detta utanför en katastrof när du använder Azure File Sync på grund av den ökade sannolikheten för dataförlust. I händelse av en katastrof där du vill initiera en manuell redundansväxling av lagringen måste du öppna ett supportärende med Microsoft för att få Azure File Sync att återuppta synkroniseringen med den sekundära slutpunkten.

Migrering

Om du har en befintlig Windows-filserver 2012R2 eller senare kan Azure File Sync installeras direkt på plats, utan att du behöver flytta data till en ny server. Om du planerar att migrera till en ny Windows-filserver som en del av införandet av Azure File Sync, eller om dina data för närvarande finns på nätverksansluten lagring (NAS), finns det flera möjliga migreringsmetoder för att använda Azure File Sync med dessa data. Vilken migreringsmetod du ska välja beror på var dina data finns för närvarande.

Mer information finns i översiktsartikeln Azure File Sync och Azure-filresursmigrering.

Antivirus

Eftersom antivirusprogram fungerar genom att söka igenom filer efter känd skadlig kod kan ett antivirusprogram orsaka återkallande av nivåindelade filer, vilket resulterar i höga avgifter för utgående trafik. Nivåindelade filer har den säkra Windows-attributuppsättningen FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS , och vi rekommenderar att du konsulterar programvaruleverantören för att lära dig hur du konfigurerar deras lösning för att hoppa över att läsa filer med den här attributuppsättningen (många gör det automatiskt).

Microsofts interna antiviruslösningar, Windows Defender och System Center Endpoint Protection (SCEP), hoppar båda automatiskt över att läsa filer som har den här attributuppsättningen. Vi har testat dem och identifierat ett mindre problem: när du lägger till en server i en befintlig synkroniseringsgrupp återkallas filer som är mindre än 800 byte (laddas ned) på den nya servern. Dessa filer kommer att finnas kvar på den nya servern och kommer inte att nivåindelas eftersom de inte uppfyller kravet på nivåindelningsstorlek (>64 kB).

Kommentar

Antivirusleverantörer kan kontrollera kompatibiliteten mellan produkten och Azure File Sync med hjälp av Azure File Sync Antivirus Compatibility Test Suite, som är tillgänglig för nedladdning i Microsoft Download Center.

Backup

Om molnnivåindelning är aktiverat bör lösningar som direkt säkerhetskopierar serverslutpunkten eller en virtuell dator där serverslutpunkten finns inte användas. Molnnivåindelning gör att endast en delmängd av dina data lagras på serverslutpunkten, med den fullständiga datamängden som finns i din Azure-filresurs. Beroende på vilken säkerhetskopieringslösning som används hoppas nivåindelade filer antingen över och säkerhetskopieras inte (eftersom de har FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS attributet inställt) eller så återkallas de till disken, vilket resulterar i höga utgående avgifter. Vi rekommenderar att du använder en lösning för molnsäkerhetskopiering för att säkerhetskopiera Azure-filresursen direkt. Mer information finns i Om säkerhetskopiering av Azure-filresurser eller kontakta din provider för säkerhetskopiering för att se om de stöder säkerhetskopiering av Azure-filresurser.

Om du föredrar att använda en lokal säkerhetskopieringslösning bör säkerhetskopieringar utföras på en server i synkroniseringsgruppen som har molnnivåindelning inaktiverad och se till att det inte finns några nivåindelade filer. När du utför en återställning använder du återställningsalternativen på volymnivå eller filnivå. Filer som återställs med hjälp av återställningsalternativet på filnivå synkroniseras till alla slutpunkter i synkroniseringsgruppen och befintliga filer ersätts med den version som återställs från säkerhetskopian. Återställningar på volymnivå ersätter inte nyare filversioner i Azure-filresursen eller andra serverslutpunkter.

Kommentar

Återställning utan operativsystem (BMR), återställning av virtuella datorer, systemåterställning (inbyggd återställning av Windows-operativsystem) och återställning på filnivå med sin nivåindelade version (detta händer när säkerhetskopieringsprogram säkerhetskopierar en nivåindelad fil i stället för en fullständig fil) kan orsaka oväntade resultat och stöds för närvarande inte när molnnivåindelning är aktiverat. VSS-ögonblicksbilder (inklusive fliken Tidigare versioner) stöds på volymer som har molnnivåindelning aktiverat. Du måste dock aktivera tidigare versionskompatibilitet via PowerShell. Lär dig mer.

Dataklassificering

Om du har installerat programvara för dataklassificering kan aktivering av molnnivåindelning leda till ökade kostnader av två skäl:

1. När molnnivåindelningen är aktiverad cachelagras dina hetaste filer lokalt och de coolaste filerna nivåindelade till Azure-filresursen i molnet. Om din dataklassificering regelbundet söker igenom alla filer i filresursen måste de filer som är nivåindelade i molnet återkallas när de genomsöks.

2. Om dataklassificeringsprogramvaran använder metadata i dataströmmen för en fil måste filen återkallas helt för att programvaran ska kunna se klassificeringen.

Dessa ökningar av både antalet återkallelser och mängden data som återkallas kan öka kostnaderna.

Uppdateringsprincip för Azure File Sync-agenten

Azure File Sync-agenten uppdateras regelbundet för att lägga till nya funktioner och åtgärda problem. Vi rekommenderar att du uppdaterar Azure File Sync-agenten när nya versioner är tillgängliga.

Huvudversioner jämfört med mindre agentversioner

• Större agentversioner innehåller ofta nya funktioner och har ett ökande antal som den första delen av versionsnumret. Exempel: 14.0.0.0
• Mindre agentversioner kallas även "korrigeringar" och släpps oftare än större versioner. De innehåller ofta felkorrigeringar och mindre förbättringar men inga nya funktioner. Exempel: 14.1.0.0

Uppgradera sökvägar

Det finns fem godkända och testade sätt att installera Azure File Sync-agentuppdateringarna.

1. Använd funktionen för automatisk uppgradering av Azure File Sync-agenten för att installera agentuppdateringar. Azure File Sync-agenten uppgraderas automatiskt. Du kan välja att installera den senaste agentversionen när den är tillgänglig eller uppdatera när den för närvarande installerade agenten snart upphör att gälla. Mer information finns i Automatisk livscykelhantering för agenten.
2. Konfigurera Microsoft Update för att automatiskt ladda ned och installera agentuppdateringar. Vi rekommenderar att du installerar varje Azure File Sync-uppdatering för att säkerställa att du har åtkomst till de senaste korrigeringarna för serveragenten. Microsoft Update gör den här processen sömlös genom att automatiskt ladda ned och installera uppdateringar åt dig.
3. Använd AfsUpdater.exe för att ladda ned och installera agentuppdateringar. AfsUpdater.exe finns i agentinstallationskatalogen. Dubbelklicka på den körbara filen för att ladda ned och installera agentuppdateringar. Beroende på versionsversionen kan du behöva starta om servern.
4. Korrigera en befintlig Azure File Sync-agent med hjälp av en Microsoft Update-korrigeringsfil eller en körbar .msp-fil. Det senaste Uppdateringspaketet för Azure File Sync kan laddas ned från Microsoft Update Catalog. Om du kör en körbar .msp-fil uppgraderas din Azure File Sync-installation med samma metod som används automatiskt av Microsoft Update. Om du tillämpar en Microsoft Update-korrigering utförs en uppgradering på plats av en Azure File Sync-installation.
5. Ladda ned det senaste installationsprogrammet för Azure File Sync-agenten från Microsoft Download Center. Om du vill uppgradera en befintlig Azure File Sync-agentinstallation avinstallerar du den äldre versionen och installerar sedan den senaste versionen från det nedladdade installationsprogrammet. Serverregistrering, synkroniseringsgrupper och andra inställningar underhålls av Installationsprogrammet för Azure File Sync.

Kommentar

Nedgradering av Azure File Sync-agenten stöds inte. De nya versionerna omfattar ofta icke-bakåtkompatibla ändringar jämfört med de gamla versionerna, vilket gör att nedgraderingsprocessen inte stöds. Om du stöter på problem med din aktuella agentversion kan du kontakta supporten eller uppgradera till den senaste tillgängliga versionen.

Automatisk livscykelhantering för agenten

Azure File Sync-agenten uppgraderas automatiskt. Du kan välja något av två lägen och ange en underhållsperiod där uppgraderingen ska utföras på servern. Den här funktionen är utformad för att hjälpa dig med agentens livscykelhantering genom att antingen tillhandahålla ett skyddsräcke som hindrar din agent från att upphöra att gälla eller för att undvika problem med den aktuella inställningen.

1. Standardinställningen försöker förhindra att agenten upphör att gälla. Inom 21 dagar från det angivna förfallodatumet för en agent försöker agenten att uppgradera sig själv. Det startar ett försök att uppgradera en gång i veckan inom 21 dagar före förfallodatum och i det valda underhållsfönstret. Det här alternativet eliminerar inte behovet av regelbundna Microsoft Update-korrigeringar.
2. Du kan också välja att agenten automatiskt ska uppgradera sig själv så snart en ny agentversion blir tillgänglig (gäller för närvarande inte för klustrade servrar). Den här uppdateringen sker under det valda underhållsfönstret och gör att servern kan dra nytta av nya funktioner och förbättringar så snart de blir allmänt tillgängliga. Detta är den rekommenderade, bekymmersfria inställningen som ger större agentversioner samt regelbundna uppdateringskorrigeringar till servern. Varje agent som släpps är i GA-kvalitet. Om du väljer det här alternativet kommer Microsoft att skicka den senaste agentversionen till dig. Klustrade servrar undantas. När flygresan är klar blir agenten också tillgänglig på Microsoft Download Center aka.ms/AFS/agent.

Ändra inställningen för automatisk uppgradering

Följande instruktioner beskriver hur du ändrar inställningarna när du har slutfört installationsprogrammet, om du behöver göra ändringar.

Öppna en PowerShell-konsol och navigera till katalogen där du installerade synkroniseringsagenten och importera sedan server-cmdletarna. Som standard skulle detta se ut ungefär så här:

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

Du kan köra Get-StorageSyncAgentAutoUpdatePolicy för att kontrollera den aktuella principinställningen och avgöra om du vill ändra den.

Om du vill ändra den aktuella principinställningen till det fördröjda uppdateringsspåret kan du använda:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

Om du vill ändra den aktuella principinställningen till det omedelbara uppdateringsspåret kan du använda:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>

Garantier för agentlivscykel och ändringshantering

Azure File Sync är en molntjänst som kontinuerligt introducerar nya funktioner och förbättringar. Det innebär att en specifik Azure File Sync-agentversion endast kan stödjas under en begränsad tid. För att underlätta distributionen garanterar följande regler att du har tillräckligt med tid och meddelande för att hantera agentuppdateringar/uppgraderingar i din ändringshanteringsprocess:

• Större agentversioner stöds i minst sex månader från den första versionen.
• Vi garanterar att det finns en överlappning på minst tre månader mellan stöd för större agentversioner.
• Varningar utfärdas för registrerade servrar som använder en agent som snart upphört att gälla minst tre månader innan den upphör att gälla. Du kan kontrollera om en registrerad server använder en äldre version av agenten under avsnittet registrerade servrar i en Synkroniseringstjänst för lagring.
• Livslängden för en delagentversion är bunden till den associerade huvudversionen. När agentversion 14.0.0.0 till exempel är inställd på att upphöra att gälla, kommer agentversionerna 14.*.*.* att upphöra att gälla tillsammans.

Kommentar

Om du installerar en agentversion med en förfallovarning visas en varning men lyckas. Försök att installera eller ansluta med en utgången agentversion stöds inte och kommer att blockeras.

Nästa steg

• Överväg brandväggs- och proxyinställningar
• Distribuera Azure Files
• Distribuera Azure File Sync
• Övervaka Azure File Sync