Planera för distribution av Azure File Sync

Filerna lagras i molnet i Azure-filresurser. Azure-filresurser kan användas på två sätt: genom att direkt montera dessa serverlösa Azure-filresurser (SMB) eller genom att cachelagra Azure-filresurser lokalt med hjälp av Azure File Sync. Vilket distributionsalternativ du väljer ändrar de aspekter som 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 hantering av en filserver eller NAS-enhet. Det innebär att du inte behöver tillämpa programkorrigeringar eller byta ut fysiska diskar.

• Cachelagra En 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 ett snabbt cacheminne för 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 Azure Files idag saknar en effektiv ändringsidentifieringsmekanism som Windows Server har, så det tar tid att sprida ändringar direkt till Azure-filresursen 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: Det objekt som definierar synkroniseringsrelationen mellan en molnslutpunkt, eller Azure-filresurs och en serverslutpunkt. Slutpunkter i en synkroniseringsgrupp synkroniseras med varandra. Om du till exempel har två olika uppsättningar filer som du vill hantera med Azure File Sync, skapar du två synkroniseringsgrupper och lägger till olika slutpunkter i varje synkroniseringsgrupp.

Hanteringsbegrepp för Azure-filresurs

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 det lagringskontot. Information om aktuella begränsningar för lagringskontot finns Azure Files för skalbarhet och prestanda.

Det finns två huvudsakliga typer av lagringskonton som du använder för Azure Files distributioner:

• GPv2-lagringskonton för generell användning version 2 (GPv2): Med GPv2-lagringskonton kan du distribuera Azure-filresurser på standard-/hårddiskbaserad (HDD-baserad) maskinvara. 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-/solid state-diskbaserad (SSD-baserad) maskinvara. 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 lagringskonto som du kan stöta på Azure Portal, PowerShell eller CLI. Två lagringskontotyper, BlockBlobStorage- och BlobStorage-konton, får inte innehålla Azure-filresurser. De andra två lagringskontotyperna som du kan se är generell användning version 1 (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 funktioner 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 att du uppgraderar GPv1- och klassiska lagringskonton om de redan finns i din miljö.

Azure File Sync hanteringsbegrepp

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 som innehåller synkroniseringsgruppens relationer. Resursen Storage Sync Service är en peer för lagringskontoresursen och kan på liknande sätt distribueras till Azure-resursgrupper. En Storage Sync Service kan skapa synkroniseringsgrupper som innehåller Azure-filresurser över flera lagringskonton och flera registrerade Windows Servrar.

Innan du kan skapa en synkroniseringsgrupp i en Storage Sync Service måste du först registrera en Windows Server med Storage Sync Service. Detta skapar ett registrerat serverobjekt som representerar en förtroenderelation mellan din server eller ditt kluster och Storage Sync Service. Om du vill Storage en synkroniseringstjänst måste du först installera Azure File Sync-agenten på servern. En enskild server eller ett kluster kan bara registreras med Storage tjänst för synkronisering i taget.

En synkroniseringsgrupp innehåller en molnslutpunkt eller Azure-filresurs och minst en serverslutpunkt. Serverslutpunktsobjektet innehåller inställningarna som konfigurerar molnnivåindelad kapacitet, vilket ger cachelagringsfunktionerna 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.

Överväg hur många synkroniseringstjänster Storage behöver

I ett tidigare avsnitt beskrivs kärnresursen som ska konfigureras för Azure File Sync: en Storage Sync Service. En Windows Server kan bara registreras på en Storage Sync Service. Därför är det ofta bäst att bara distribuera en enda Storage Sync Service och registrera alla servrar som den innehåller.

Skapa endast Storage synkroniseringstjänster om du har:

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

Planera för balanserade synkroniserings topologier

Innan du distribuerar resurser är det viktigt att planera vad du ska synkronisera på en lokal server, med vilken Azure-filresurs. Genom att göra 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 ut lokalt som SMB-resurser till dina användare och appar. Det enklaste sättet att se 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 enskild Windows Server-instans, rekommenderar vi mappning 1:1.

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-resurser på din lokala Windows Server-instans. Det innebär bara att du ordnar 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 för en volym till en Azure-filresurs. Om du synkroniserar volymroten kommer alla undermappar och filer att gå till samma Azure-filresurs.

Synkronisering av 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 ett bra sätt är att försöka hålla antalet under 20 miljoner eller 30 miljoner i en enda resurs. Att konfigurera Azure File Sync med ett lägre antal objekt är inte bara bra för filsynkronisering. Ett lägre antal objekt har även fördelar med scenarier som dessa:

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

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 Azure File Sync som du ska etablera för synkroniseringsgruppen. En synkroniseringsgrupp kopplar ihop Azure-filresursen och mappen på servern och upprättar en synkroniseringsanslutning.

Om du vill bestämma hur många Azure-filresurser du behöver kan du läsa 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 gör lagringskontot till ett skalningsmål för prestandanummer som IOPS och dataflöde.

  En Azure-standardfilresurs kan teoretiskt sett ge maximal prestanda som ett lagringskonto kan leverera. Om du placerar flera resurser i ett enda lagringskonto skapar du en delad pool med IOPS och dataflöde för dessa resurser. Om du endast planerar att Azure File Sync till dessa filresurser skapar inte gruppering av flera Azure-filresurser till samma lagringskonto något problem. Granska prestandamålen för Azure-filresursen för att få djupare inblick i relevanta mått. Dessa begränsningar gäller inte för Premium Storage, där prestanda uttryckligen etableras och garanteras för varje resurs.

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

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

Det är bästa praxis att hålla nere antalet objekt per synkroniseringsomfång. Det är en viktig faktor att tänka på när du mappar till Azure-filresurser. Azure File Sync 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 resurs. 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 håller dig ungefär under dessa siffror. Den här övningen ger dig utrymme att växa.

Det är möjligt att en uppsättning mappar i din situation logiskt kan synkronisera till samma Azure-filresurs (med hjälp av den nya gemensamma rotmappsmetod som nämnts ovan). Men det kan fortfarande vara bättre att gruppera om 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 balanserat på servern. Du kan också dela dina lokala resurser och synkronisera mellan fler lokala servrar, vilket ger möjlighet att synkronisera med ytterligare 30 Azure-filresurser per extra server.

Skapa en mappningstabell

Använd föregående information för att avgöra hur många Azure-filresurser du behöver och vilka delar av dina befintliga data som azure-filresursen ska användas i.

Skapa en tabell som registrerar dina tankar så att du kan referera till den när du behöver. Att hålla ordning är viktigt 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 en mall för att skapa mappningen.

Ladda ned en mall för namnområdesmappning.

Windows för filserver

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

Operativsystemskrav

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

Framtida versioner av Windows Server kommer att läggas till när de släpps.

Minsta systemresurser

Azure File Sync kräver en server, antingen fysisk eller virtuell, med minst en processor och minst 2 GiB minne.

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

Rekommenderade systemresurser

Precis som alla server-funktioner eller program bestäms systemresurskraven för Azure File Sync av distributionens skala. större distributioner på en server kräver större systemresurser. För Azure File Sync bestäms skalningen av antalet objekt i serverslutpunkterna och datamängdens omsättning. En enskild server kan ha serverslutpunkter i flera synkroniseringsgrupper och antalet objekt som anges i följande tabellkonton för det fullständiga namnområdet som en server är ansluten till.

Till exempel serverslutpunkt A med 10 miljoner objekt + serverslutpunkt B med 10 miljoner objekt = 20 miljoner objekt. För den exempeldistributionen rekommenderar vi 8 processorer, 16 GiB minne för stabilt tillstånd och (om möjligt) 48 GiB minne för den första migreringen.

Namnområdesdata lagras i minnet av prestandaskäl. Därför kräver större namnrymder mer minne för att upprätthålla bra prestanda, och mer dataomsättning kräver mer processorkraft för att bearbetas.

I följande tabell har vi angett både storleken på namnområdet och en konvertering till kapacitet för vanliga 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 mängd kapacitet. Basera minneskonfigurationen på namnområdets storlek.

*Synkronisering av fler än 100 miljoner &-kataloger rekommenderas inte just nu. Det här är en mjuk gräns baserat på våra testade tröskelvärden. Mer information finns i Azure File Sync skalningsmål.

• En lokalt ansluten volym formaterad med NTFS-filsystemet.

Cmdlet för utvärdering

Innan du Azure File Sync bör du utvärdera om det är kompatibelt med systemet med hjälp Azure File Sync cmdleten för 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. Dess kontroller omfattar de flesta men inte alla funktioner som anges 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, datauppsättningskontrollerna eller båda. Så här utför du både system- och datauppsättningskontrollerna:

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

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

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Testa 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å direkt anslutna NTFS-volymer. Direkt ansluten lagring, eller DAS, på Windows Server innebär att Windows Server-operativsystemet äger filsystemet. DAS kan tillhandahållas genom att fysiskt koppla diskar till filservern, koppla virtuella diskar till en virtuell filserverdator (till exempel en virtuell dator som finns i 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 interopstillståndet för NTFS-filsystemfunktioner:

Azure File Sync hoppar även över vissa tillfälliga filer och systemmappar:

Fundera över hur mycket ledigt utrymme du behöver på den lokala disken

När du planerar att Azure File Sync bör du överväga hur mycket ledigt utrymme du behöver på den lokala disken som du planerar att ha en serverslutpunkt på.

Med Azure File Sync måste du ta hänsyn till följande tagande av utrymme på den lokala disken:

• Med molnnivåindelad aktiverad:

  • Punkter för nivåindelade filer
  • Azure File Sync metadatadatabas
  • Azure File Sync heatstore
  • Fullständigt nedladdade filer i din heta cache (om det finns några)
  • Principkrav för ledigt volymutrymme

• Med molnnivåindelad:

  • Fullständigt nedladdade filer
  • Azure File Sync heatstore
  • 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å din lokala disk. Anta att du har installerat din Azure File Sync på din virtuella Azure Windows dator och planerar att skapa en serverslutpunkt på disk F. Du har 1 miljon filer och vill nivåindelad alla, 100 000 kataloger och en diskklusterstorlek på 4 KiB. Diskstorleken är 1 000 GiB. Du vill aktivera molnnivåindelad lagring och ställa in principen för ledigt volymutrymme 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)

I det här Azure File Sync skulle 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 i eventuellt 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än användning".
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.

Datadeduplicering

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

När Datadeduplicering är aktiverat på en volym med molnnivåindelning aktiverat kommer dedupliceringsoptimerade filer på serverslutpunktens plats att nivåindelad likna 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 till av andra filer på volymen.

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

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

Kommentarer

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

• Om Datadeduplicering är aktiverat på en volym när molnnivåindelad lagring har aktiverats optimerar det första dedupliceringsjobbet filer på volymen som inte redan är nivåindelade och påverkar molnnivåindelade:

  • Principen för ledigt utrymme fortsätter att nivåindelad för filer enligt det lediga utrymmet på volymen med hjälp av heatmap.
  • Datumprincip hoppar över nivåindelad lagring av filer som annars kan vara berättigade till nivåindelad lagring på grund av dedupliceringsoptimeringsjobbet som har åtkomst till filerna.

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

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

• Om en server som kör Windows Server 2012 R2 med Azure File Sync-agenten installerad uppgraderas till Windows Server 2016 eller Windows Server 2019, måste följande steg utföras för att stödja datadeduplicering och molnnivåindelade 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 eller Windows Server 2019).
  • Installera Azure File Sync agenten och starta om servern.

  Obs! Azure File Sync-konfigurationsinställningarna på servern bevaras när agenten avinstalleras och installeras om.

Distributed File System (DFS)

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

DFS-namnrymder (DFS-N): Azure File Sync stöds fullt ut på DFS-N-servrar. Du kan installera Azure File Sync på en eller flera DFS-N-medlemmar för att synkronisera data mellan serverslutpunkterna och molnslutpunkten. Mer information finns i Översikt över DFS-namnrymder.

DFS Replication (DFS-R): Eftersom DFS-R och Azure File Sync båda är replikeringslösningar rekommenderar vi i de flesta fall att ersätta 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.
• Det är inte alla lokala servrar som behöver en kopia av dina fildata som kan anslutas direkt till Internet.
• Förgreningsservrar konsoliderar data till en enda hubbserver som du vill använda Azure File Sync.

För Azure File Sync och DFS-R ska fungera sida vid sida:

1. Azure File Sync måste inaktiveras på volymer med DFS-R-replikerade mappar.
2. Serverslutpunkter bör inte konfigureras på skrivskyddade DFS-R-replikeringsmappar.

Mer information finns i DFS Replication översikt.

Sysprep

Att använda 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 serveravbildningen och slutfört sysprep-miniinstallationen.

Windows-sök

Om molnnivåindelad är aktiverad på en serverslutpunkt hoppas filer som är nivåindelade över och indexeras inte av Windows Search. Filer som inte är nivåindelade indexeras korrekt.

Andra HSM-Storage (Hierarkisk Storage Management)

Inga andra HSM-lösningar bör 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-filresurser beror den effektiva synkroniseringsprestandan 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å 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 Azure Portal eller SMB identifieras inte omedelbart och replikeras som ändringar i serverslutpunkten. Azure Files inte har ändringsmeddelanden eller journaler än, så det går inte att automatiskt initiera en synkroniseringssession när filer ändras. På Windows Server Azure File Sync använder Windows USN-journaler för att automatiskt initiera en synkroniseringssession när filer ändras

Om du vill identifiera ändringar i Azure-filresursen Azure File Sync ett schemalagt jobb som kallas för ett ä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 Azure File Sync en synkroniseringssession. Ändringsidentifieringsjobbet initieras var 24:e timme. Eftersom jobbet för ändringsidentifiering fungerar genom att räkna upp alla filer i Azure-filresursen tar ändringsidentifiering längre tid i större namnrymder än i mindre namnrymder. För stora namnrymder 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 Azure File Sync prestandamått och Azure File Sync skalningsmål

Identitet

Azure File Sync fungerar med din STANDARD AD-baserade identitet 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 åtkomsterna går via Azure File Sync cachelagringsservrar i stället för via Azure-filresursen. Eftersom serverslutpunkterna finns på Windows Server och Windows Server har stöd för AD- och Windows-ACL:er under en längre tid, behövs inget utöver att se till att de Windows-filservrar som registrerats med Storage Sync Service är domänanslutningspunkter. 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, kan du också se till att du kan tillämpa dina AD-behörigheter på din filresurs direkt i molnet också. Om du vill göra detta måste du domän-ansluta ditt lagringskonto till din lokala AD, precis som hur dina Windows-filservrar är domänkopplingar. Mer information om hur du ansluter ditt lagringskonto till en kundägd Active Directory finns i Azure Files Översikt över Active Directory.

Nätverk

Agenten Azure File Sync kommunicerar med din Storage Sync-tjänst och Azure-filresurs 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 ned data mellan 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 ingen särskild nätverkskonfiguration för att distribuera Azure File Sync.

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

• Tunnel och filuppladdning/nedladdning av trafik via ExpressRoute eller Azure VPN.
• Använd funktioner Azure Files och Azure-nätverkstjänster, till exempel tjänstslutpunkter och privata slutpunkter.
• Konfigurera Azure File Sync att stödja din proxy i din miljö.
• Begränsa nätverksaktiviteten från Azure File Sync.

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

Kryptering

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

Windows Serverkryptering i vila

Det finns två strategier för att kryptera data på Windows Server som vanligtvis fungerar 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 utesluter inte varandra. De kan användas tillsammans om så önskas eftersom syftet med kryptering är annorlunda.

Om du vill tillhandahålla kryptering under filsystemet Windows Server Inkorg i BitLocker. BitLocker är helt transparent för Azure File Sync. Det främsta skälet 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ö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å liknande sätt som BitLocker, i det att de finns under NTFS-volymen, bör på samma sätt fungera helt transparent med Azure File Sync.

Den andra huvudsakliga metoden för att kryptera data är att kryptera filens dataström när programmet sparar filen. Vissa program kan göra detta inbyggt, men det ä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. Det främsta skälet till att använda en krypteringsmekanism som AIP/RMS är att förhindra data exfiltrering av data från filresursen genom att personer kopierar dem till alternativa platser, till exempel till en flash-enhet eller skickar dem via e-post till en obehörig person. 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 inte fungerar med NTFS Encrypted File System (NTFS EFS) eller krypteringslösningar från tredje part som finns ovanför filsystemet men under filens dataström.

Kryptering under överföring

Azure File Sync-agenten kommunicerar med din Storage Sync-tjänst och Azure-filresurs 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 filresursen.

Det främsta skälet 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 en äldre Linux-distribution, och prata direkt med en Azure-filresurs. Om det äldre programmet pratar med Windows Server-cachen för filresursen har växling av den här inställningen ingen effekt.

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

Mer information om kryptering under överföring finns i kräva säker överföring i Azure Storage.

Kryptering av Azure-filresurs i vila

Alla data som lagras i Azure Files krypteras i vila med hjälp av Azure Storage Service Encryption (SSE). Kryptering av lagrings tjänst fungerar på samma sätt som BitLocker i Windows: data krypteras under fil system nivå. Eftersom data krypteras under fil systemet i Azure-filresursen, eftersom de är kodade till disk, 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 både SMB-och NFS-protokollen.

Som standard krypteras data som lagras i Azure Files med Microsoft-hanterade nycklar. Med Microsoft-hanterade nycklar innehåller Microsoft nycklar 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 rotations processen. Om du väljer att kryptera dina fil resurser med Kundhanterade nycklar har Azure Files behörighet att få åtkomst till dina nycklar för att uppfylla Läs-och skriv förfrågningar från dina klienter. Med Kundhanterade nycklar kan du återkalla den här behörigheten när som helst, men det innebär att Azure-filresursen inte längre kan nås via SMB eller det fileraste API: et.

Azure Files använder samma krypterings schema som de andra Azure Storage-tjänsterna, till exempel Azure Blob Storage. Om du vill veta mer om Azure Storage Service Encryption (SSE) kan du läsa mer i Azure Storage-kryptering för data i vila.

Lagringsnivåer

Azure Files erbjuder fyra olika nivåer av lagring, premium, transaktionsoptimerad, varm och cool så att du kan skräddarsy dina resurser efter prestanda- och priskraven för ditt scenario:

• Premium: Premium-filresurser backas upp av SSD-enheter (Solid State Drives) och ger konsekvent hög prestanda och låg svarstid inom ensiffriga millisekunder för de flesta I/O-åtgärder för I/O-intensiva arbetsbelastningar. Premium-filresurser är lämpliga för en mängd olika arbetsbelastningar som databaser, värdtjänster för webbplatser och utvecklingsmiljöer. Premium-filresurser kan användas med både Server Message Block (SMB) och NFS-protokoll (Network File System).
• Transaktionsoptimerad: Transaktionsoptimerade filresurser möjliggör transaktionsintensiva arbetsbelastningar som inte behöver den svarstid som erbjuds av premiumfilresurser. Transaktionsoptimerade filresurser erbjuds på standardlagringsmaskinvaran som backas upp av hårddiskar (HDD). Transaktionsoptimerad har tidigare kallats "standard", men detta avser lagringsmedietypen snarare än själva nivån (den heta och den coola är också "standard"-nivåer, eftersom de finns på standardlagringsmaskinvara).
• Hot: Heta filresurser erbjuder lagring som är optimerad för allmänna fildelningsscenarier, till exempel gruppresurser. Heta filresurser erbjuds på standardlagringsmaskinvaran som backas upp av hårddiskar.
• Låg cool: Lågeffektiva filresurser erbjuder kostnadseffektiv lagring som är optimerad för scenarier med arkivlagring online. Coola filresurser erbjuds på standardlagringsmaskinvaran som backas upp av hårddiskar.

Premium-filresurser distribueras i typen FileStorage-lagringskonto 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. Standardfilresurser, inklusive transaktionsoptimerade, heta och coola filresurser, distribueras i lagringskontotyp för generell användning version 2 (GPv2) och är tillgängliga via betala per användning-fakturering.

När du väljer en lagringsnivå 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, är premiumnivån förmodligen den bästa. Om låg latens inte är lika stort, till exempel när teamresurser är monterade lokalt från Azure eller cachelagras 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 lagringskonto. 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 för rsync macOS och Linux.

Filresurser som distribueras i GPv2-konton kan flyttas mellan standardnivåer (transaktionsoptimerade, heta och coola) utan att skapa ett nytt lagringskonto och migrera data, men du kommer att dra på dig transaktionskostnader när du ändrar din nivå. När du flyttar en resurs från en lägre nivå till en kallare nivå debiteras du den kallare nivåns transaktionskostnad för skrivtransaktioner för varje fil i resursen. Om du flyttar en filresurs från en kallare nivå till en lägre nivå debiteras den lägre nivåns transaktionskostnad för läsning för varje fil i resursen.

Se Förstå Azure Files fakturering för mer information.

Regional tillgänglighet

Standard fil resurser med 100 TiB-kapacitet har vissa begränsningar.

• För närvarande stöds endast lokalt redundant lagring (LRS) och ZRS-konton (Zone redundant Storage).
• När du aktiverar stora fil resurser kan du inte konvertera lagrings konton till GRS-(Geo-redundant lagring) eller GZRS-konton (geo-Zone-redundant lagring).
• När du har aktiverat stora fil resurser kan du inte inaktivera den.

Tillgänglighet för Azure File Sync-regioner

För regional tillgänglighet, se Produkttillgänglighet 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:

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

Följ processen i det här dokumentet om du vill begära åtkomst för dessa regioner.

Redundans

För att skydda data i dina Azure-filresurser mot dataförlust eller skadade data lagrar alla Azure-filresurser flera kopior av varje fil när de skrivs. Beroende på kraven för din arbetsbelastning kan du välja ytterligare grader av redundans. 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-lagringskluster. Detta skyddar mot dataförlust på grund av maskinvarufel, till exempel en felaktig diskenhet. Men om en katastrof som brand eller översvämningar 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, men dessa kopior är fysiskt isolerade i tre olika 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änglighetszoner.
• Geo-redundant lagring (GRS): Med GRS har du två regioner, en primär och en sekundär region. Filer lagras tre gånger i ett Azure Storage-kluster i den primära regionen. Skrivningar replikeras asynkront till en Microsoft-definierad sekundär region. GRS innehåller sex kopior av dina data som är fördelade 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 redundans, och den sekundära blir 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 har replikerats till den sekundära regionen förlorade i händelse av en större katastrof. Du kan också utföra en manuell redundans för ett geo-redundant lagringskonto.
• Geo-zonredundant lagring (GZRS): Du kan tänka på GZRS som om det vore som ZRS men med geo-redundans. Med GZRS lagras filer tre gånger över tre olika lagringskluster i den primära regionen. Alla skrivningar replikeras sedan asynkront till en Microsoft-definierad sekundär region. Redundansprocessen för GZRS fungerar på samma sätt som GRS.

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

GPv2-lagringskonton (General purpose version 2) ger två ytterligare redundansalternativ som inte stöds av Azure Files: lästillgänglig geo-redundant lagring, som ofta kallas RA-GRS, och lästillgänglig geo-zonredundant lagring, vilket ofta kallas RA-GZRS. Du kan etablera Azure-filresurser i lagringskonton med dessa alternativ inställda, Azure Files inte stöder läsning från den sekundära regionen. Azure-filresurser som distribueras till lästillgängliga geo- eller geozonredundant lagringskonton debiteras som geo-redundant eller geo-zonredundant lagring.

Migrering

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

Kolla in migreringsartikeln Azure File Sync azure-filresurs där du hittar detaljerad vägledning för ditt scenario.

Antivirus

Eftersom antivirusprogrammet söker igenom filer efter känd skadlig kod kan en antivirusprodukt orsaka återkallande av nivåindelade filer, vilket resulterar i höga avgifter för utgående data. I version 4.0 och senare av Azure File Sync-agenten har nivåindelade filer attributet secure Windows FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS set. Vi rekommenderar att du tar hjälp av programvaruleverantören för att lära dig hur man konfigurerar sin lösning för att hoppa över läsning av filer med den här attributuppsättningen (många gör det automatiskt).

Microsofts lokala antiviruslösningar, SCEP (Windows Defender and System Center Endpoint Protection), hoppar automatiskt över läsning av 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 kommer filer som är mindre än 800 byte att återkallas (hämtas) på den nya servern. De här filerna finns kvar på den nya servern och nivåindelade eftersom de inte uppfyller storlekskraven för nivåindelade (64 kB>).

Backup

Om molnnivåindelad lagring är aktiverad ska lösningar som direkt backar upp 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, där den fullständiga datauppsättningen finns i din Azure-filresurs. Beroende på vilken säkerhetskopieringslösning som används kommer nivåindelade filer antingen att hoppas över och inte säkerhetskopieras (eftersom de har FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS-attributet inställt), eller så kommer de att återkallas till disk, vilket resulterar i höga avgifter för utgående data. Vi rekommenderar att du använder en molnsäkerhetskopieringslösning för att säkerhetskopiera Azure-filresursen direkt. Mer information finns i Om säkerhetskopiering av Azure-filresurser eller kontakta din säkerhetskopieringsprovider 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åindelad. När du utför en återställning använder du återställningsalternativen på volym- 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.

Dataklassificering

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

1. När molnnivåindelning är aktiverat 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 filerna som är nivåindelade i molnet återkallas när de genomsöks.

2. Om dataklassificeringsprogrammet 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 återkallanden och mängden data som återkallas kan öka kostnaderna.

Uppdateringsprincip för Azure File Sync-agenten

Azure File Sync agent uppdateras regelbundet för att lägga till nya funktioner och för att åtgärda problem. Vi rekommenderar att du konfigurerar Microsoft Update för att hämta uppdateringar för Azure File Sync-agenten när de är tillgängliga.

Huvud versioner jämfört med mindre agent versioner

• Större agent versioner innehåller ofta nya funktioner och har ett ökande antal som den första delen av versions numret. Till exempel: * 2. * .**
• Mindre agent versioner kallas även för "Patches" och släpps oftare än viktiga versioner. De innehåller ofta fel korrigeringar och mindre förbättringar men inga nya funktioner. Till exempel: * * . 3.**

Uppgradera sökvägar

Det finns fyra godkända och testade sätt att installera Azure File Sync agent-uppdateringar.

1. Önskat Konfigurera Microsoft Update att automatiskt hämta och installera agent uppdateringar.
   Vi rekommenderar alltid att du tar varje Azure File Sync uppdatering för att se till att du har åtkomst till de senaste korrigeringarna för Server agenten. Microsoft Update gör den här processen sömlös genom att automatiskt hämta och installera uppdateringar åt dig.
2. Använd AfsUpdater.exe för att ladda ned och installera agent uppdateringar.
   AfsUpdater.exe finns i agentens installations katalog. Dubbelklicka på den körbara filen för att ladda ned och installera agent uppdateringar.
3. Korrigera en befintlig Azure File Sync agent med hjälp av en Microsoft Update korrigerings fil eller en. msp-fil. Det senaste Azure File Sync uppdaterings paketet kan laddas ned från Microsoft Updates katalogen.
   Om du kör en. msp-fil uppgraderas Azure File Sync installationen med samma metod som används automatiskt av Microsoft Update i föregående uppgraderings Sök väg. När en Microsoft Update-korrigering används utförs en uppgradering på plats av en Azure File Sync-installation.
4. Hämta det nyaste installations programmet för Azure File Sync agent från Microsoft Download Center.
   Om du vill uppgradera en befintlig Azure File Sync agent installation avinstallerar du den äldre versionen och installerar sedan den senaste versionen från det nedladdade installations programmet. Server registreringen, Sync-grupperna och andra inställningar underhålls av installations programmet för Azure File Sync.

Automatisk agent livs cykel hantering

Med agent version 6 har File Sync-teamet infört en funktion för automatisk uppgradering av agent. Du kan välja något av två lägen och ange en underhålls period där uppgraderingen görs på servern. Den här funktionen är utformad för att hjälpa dig med agentens livs cykel hantering genom att antingen tillhandahålla en guardrail som hindrar agenten från att upphöra att gälla eller som gör att det inte går att använda den aktuella inställningen.

1. Standardvärdet försöker förhindra att agenten upphör att gälla. Inom 21 dagar från det bokförda utgångs datumet för en agent kommer agenten att försöka själv uppgradera. Ett försök görs att uppgradera en gång om veckan inom 21 dagar före förfallo datum och i det valda underhålls fönstret. Det här alternativet eliminerar inte behovet av att göra vanliga Microsoft Update-korrigeringsfiler.
2. Alternativt kan du välja att agenten automatiskt ska uppgraderas automatiskt så snart en ny agent version blir tillgänglig (för närvarande inte gäller för klustrade servrar). Den här uppdateringen sker under den valda underhålls perioden och gör att servern kan dra nytta av nya funktioner och förbättringar så fort de blir allmänt tillgängliga. Detta är den rekommenderade, kostnads fria inställningen som ger större agent versioner samt uppdateringar av vanliga uppdateringar till servern. Varje agent som lanseras är i allmän kvalitet. Om du väljer det här alternativet kommer Microsoft att starta den senaste agent versionen. Klustrade servrar undantas. När flygningen är klar kommer agenten också att bli tillgänglig på Microsoft Download Center -aka.MS/AFS/agent.

Ändra inställningen för automatisk uppgradering

I följande anvisningar beskrivs hur du ändrar inställningarna när du har slutfört installations programmet, om du behöver göra ändringar.

Öppna en PowerShell-konsol och navigera till den katalog där du installerade Sync-agenten och importera sedan Server-cmdletarna. Som standard ser detta 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 kontrol lera den aktuella princip inställningen och avgöra om du vill ändra den.

Om du vill ändra den aktuella princip inställningen till det fördröjda uppdaterings spåret kan du använda:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

Om du vill ändra den aktuella princip inställningen till det omedelbara uppdaterings spåret kan du använda:

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest

Agentens livs cykel och ändrings hantering garanterar

Azure File Sync är en moln tjänst som kontinuerligt introducerar nya funktioner och förbättringar. Det innebär att en viss Azure File Sync agent version bara kan stödjas under en begränsad tid. Följande regler garanterar att du har tillräckligt med tid och meddelande för att hantera agent uppdateringar/uppgraderingar i ändrings hanterings processen för att under lätta distributionen:

• Huvud agent versioner stöds i minst sex månader från datumet för den första versionen.
• Vi garanterar att vi överlappar minst tre månader mellan supporten för större agent versioner.
• Varningar utfärdas för registrerade servrar med en snart inaktuell agent minst tre månader före förfallo datum. Du kan kontrol lera om en registrerad Server använder en äldre version av agenten under avsnittet registrerade servrar i en tjänst för synkronisering av lagring.
• Livs längden för en del agent version är kopplad till den associerade huvud versionen. Till exempel när agent version 3,0 lanseras, agent version 2. * kommer att ställas in så att det upphör att gälla tillsammans.

Nästa steg

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