Migrera från Nätverksansluten lagring (NAS) till en hybridmolndistribution med Azure File Sync

  • Artikel

Den här migreringsartikeln är en av flera som rör nyckelorden NAS och Azure File Sync. Kontrollera om den här artikeln gäller för ditt scenario:

  • Datakälla: Nätverksansluten lagring (NAS)
  • Migreringsväg: NAS ⇒ Windows Server ⇒ ladda upp och synkronisera med Azure-filresurser
  • Cachelagring filer lokalt: Ja, det sista målet är en Azure File Sync-distribution.

Om ditt scenario är annorlunda kan du titta igenom tabellen med migreringsguider.

Azure File Sync fungerar på DAS-platser (Direct Attached Storage) och stöder inte synkronisering till NAS-platser (Network Attached Storage). Detta gör en migrering av dina filer nödvändig, och den här artikeln vägleder dig genom planering och körning av en sådan migrering.

Gäller för

Typ av filresurs SMB NFS
Standardfilresurser (GPv2), LRS/ZRS Yes No
Standardfilresurser (GPv2), GRS/GZRS Yes No
Premiumfilresurser (FileStorage), LRS/ZRS Yes No

Migreringsmål

Målet är att flytta SMB-filresurserna på NAS-installationen till en Windows Server och sedan använda Azure File Sync för en hybridmolndistribution. I allmänhet måste migreringar göras på ett sätt som garanterar integriteten för produktionsdata och dess tillgänglighet under migreringen. Det senare kräver att stilleståndstiden hålls till ett minimum, så att den får plats i eller bara något överskrider regelbundna underhållsperioder.

Migreringsöversikt

Som vi nämnde i Migrera till SMB Azure-filresurser är det viktigt att använda rätt kopieringsverktyg och metod. Nas-installationen exponerar SMB-resurser direkt i ditt lokala nätverk. Du kan antingen använda Azure Storage Mover eller RoboCopy för att flytta dina filer.

Fas 1: Identifiera hur många Azure-filresurser du behöver

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

Diagram that shows an example of a mapping table. Download the following file to experience and use the content of this image.

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.


Excel icon that sets the context for the download. Ladda ned en mall för namnområdesmappning.

Fas 2: Etablera en lämplig lokal Windows Server

  • Skapa en virtuell Windows Server 2022- eller Windows Server 2019-dator eller distribuera en fysisk server. Ett Windows Server-redundanskluster stöds också.

  • Etablera eller lägga till direktansluten lagring (DAS jämfört med NAS, som inte stöds).

    Mängden lagringsutrymme som du etablerar kan vara mindre än vad du använder för närvarande på DIN NAS-installation. Det här konfigurationsvalet kräver att du även använder Azure File Syncs molnnivåindelningsfunktion. Men när du kopierar dina filer från det större NAS-utrymmet till den mindre Windows Server-volymen i en senare fas måste du arbeta i batchar:

    1. Flytta en uppsättning filer som passar till disken
    2. Låt filsynkronisering och molnnivåindelning engagera
    3. När mer ledigt utrymme skapas på volymen fortsätter du med nästa uppsättning filer. Du kan också läsa roboCopy-kommandot i avsnittet RoboCopy i den här artikeln för att få användning av den nya /LFSM växeln. Att använda /LFSM kan förenkla RoboCopy-jobb avsevärt, men det är inte kompatibelt med andra RoboCopy-växlar som du kanske är beroende av. Använd bara växeln /LFSM när migreringsmålet är lokal lagring. Det stöds inte när målet är en fjärransluten SMB-resurs.

    Du kan undvika den här batchbearbetningsmetoden genom att etablera motsvarande utrymme på Den Windows Server som filerna upptar på NAS-installationen. Överväg deduplicering på NAS/Windows. Om du inte vill checka in den här stora mängden lagringsutrymme permanent på Din Windows Server kan du minska volymstorleken efter migreringen och innan du justerar principerna för molnnivåindelning. Det skapar en mindre lokal cache av dina Azure-filresurser.

Resurskonfigurationen (beräkning och RAM) för den Windows Server som du distribuerar beror främst på antalet objekt (filer och mappar) som du ska synkronisera. Vi rekommenderar att du går med en konfiguration med högre prestanda om du har några problem.

Lär dig hur du ändrar storlek på en Windows Server baserat på antalet objekt (filer och mappar) som du behöver synkronisera.

Kommentar

Den tidigare länkade artikeln visar en tabell med ett intervall för serverminne (RAM). Du kan orientera dig mot det mindre numret för servern, men förvänta dig att den inledande synkroniseringen kan ta betydligt längre tid.

Fas 3: Distribuera Azure File Sync-molnresursen

För att slutföra det här steget behöver du dina autentiseringsuppgifter för Azure-prenumerationen.

Den kärnresurs som ska konfigureras för Azure File Sync kallas för en synkroniseringstjänst för lagring. Vi rekommenderar att du bara distribuerar en för alla servrar som synkroniserar samma uppsättning filer nu eller i framtiden. Skapa endast flera Storage Sync Services om du har distinkta uppsättningar servrar som aldrig får utbyta data. Du kan till exempel ha servrar som aldrig får synkronisera samma Azure-filresurs. Annars är det bästa sättet att använda en enda tjänst för synkronisering av lagring.

Välj en Azure-region för lagringssynkroniseringstjänsten som är nära din plats. Alla andra molnresurser måste distribueras i samma region. För att förenkla hanteringen skapar du en ny resursgrupp i din prenumeration som innehåller synkroniserings- och lagringsresurser.

Mer information finns i avsnittet om hur du distribuerar Tjänsten för synkronisering av lagring i artikeln om distribution av Azure File Sync. Följ endast det här avsnittet i artikeln. Det kommer att finnas länkar till andra avsnitt i artikeln i senare steg.

Fas 4: Distribuera Azure Storage-resurser

I den här fasen läser du mappningstabellen från fas 1 och använder den för att etablera rätt antal Azure-lagringskonton och filresurser i dem.

En Azure-filresurs lagras i molnet på ett Azure-lagringskonto. En annan nivå av prestandaöverväganden gäller här.

Om du har mycket aktiva resurser (resurser som används av många användare och/eller program) kan två Azure-filresurser nå prestandagränsen för ett lagringskonto.

Bästa praxis är att distribuera lagringskonton med en filresurs var. Du kan poola flera Azure-filresurser till samma lagringskonto om du har arkivresurser eller om du förväntar dig låg daglig aktivitet i dem.

Dessa överväganden gäller mer för direkt molnåtkomst (via en virtuell Azure-dator) än för Azure File Sync. Om du endast planerar att använda Azure File Sync på dessa resurser är det bra att gruppera flera till ett enda Azure Storage-konto.

Om du har gjort en lista över dina resurser bör du mappa varje resurs till det lagringskonto som den kommer att finnas i.

I föregående fas fastställde du lämpligt antal resurser. I det här steget har du en mappning av lagringskonton till filresurser. Distribuera nu lämpligt antal Azure-lagringskonton med lämpligt antal Azure-filresurser i dem.

Kontrollera att regionen för vart och ett av dina lagringskonton är densamma och matchar regionen för den Storage Sync Service-resurs som du redan har distribuerat.

Varning

Om du skapar en Azure-filresurs som har en gräns på 100 TiB kan den resursen endast använda lokalt redundant lagring eller zonredundanta alternativ för lagringsredundans. Överväg dina behov av lagringsredundans innan du använder 100 TiB-filresurser.

Azure-filresurser skapas fortfarande med en 5 TiB-gräns som standard. Följ stegen i Skapa en Azure-filresurs för att skapa en stor filresurs.

Ett annat att tänka på när du distribuerar ett lagringskonto är redundansen i Azure Storage. Se Redundansalternativ för Azure Storage.

Namnen på dina resurser är också viktiga. Om du till exempel grupperar flera resurser för HR-avdelningen till ett Azure-lagringskonto bör du namnge lagringskontot på rätt sätt. När du namnger dina Azure-filresurser bör du på samma sätt använda namn som liknar de som används för deras lokala motsvarigheter.

Fas 5: Distribuera Azure File Sync-agenten

I det här avsnittet installerar du Azure File Sync-agenten på din Windows Server-instans.

Distributionsguiden förklarar att du måste inaktivera Förbättrad säkerhetskonfiguration i Internet Explorer. Det här säkerhetsmåttet gäller inte för Azure File Sync. Om du inaktiverar det kan du autentisera till Azure utan problem.

Öppna PowerShell. Installera nödvändiga PowerShell-moduler med hjälp av följande kommandon. Se till att installera den fullständiga modulen och NuGet-providern när du uppmanas att göra det.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

Om du har problem med att nå Internet från servern är det dags att lösa dem. Azure File Sync använder alla tillgängliga nätverksanslutningar till Internet. Det finns också stöd för att kräva att en proxyserver når Internet. Du kan antingen konfigurera en datoromfattande proxy nu eller, under agentinstallationen, ange en proxy som endast Azure File Sync ska använda.

Om konfigurationen av en proxy innebär att du måste öppna brandväggarna för servern kan den metoden vara acceptabel för dig. I slutet av serverinstallationen, när du har slutfört serverregistreringen, visar en rapport om nätverksanslutning de exakta slutpunkts-URL:er i Azure som Azure File Sync behöver kommunicera med för den region som du har valt. Rapporten visar också varför kommunikation behövs. Du kan använda rapporten för att låsa brandväggarna runt servern till specifika URL:er.

Du kan också använda en mer konservativ metod där du inte öppnar brandväggarna i stort. Du kan i stället begränsa servern till att kommunicera med DNS-namnområden på högre nivå. Mer information finns i Proxy- och brandväggsinställningar för Azure File Sync. Följ dina egna metodtips för nätverk.

I slutet av guiden för serverinstallation öppnas en guide för serverregistrering. Registrera servern till Azure-resursen för Storage Sync Service från tidigare.

De här stegen beskrivs mer detaljerat i distributionsguiden, som innehåller de PowerShell-moduler som du bör installera först: Installation av Azure File Sync-agenten.

Använd den senaste agenten. Du kan ladda ned den från Microsoft Download Center: Azure File Sync Agent.

Efter en lyckad installation och serverregistrering kan du bekräfta att du har slutfört det här steget. Gå till storage sync service-resursen i Azure-portalen. I den vänstra menyn går du till Registrerade servrar. Servern visas där.

Fas 6: Konfigurera Azure File Sync på Windows Server

Din registrerade lokala Windows Server måste vara klar och ansluten till Internet för den här processen.

Det här steget kopplar samman alla resurser och mappar som du har konfigurerat på din Windows Server-instans under föregående steg.

  1. Logga in på Azure-portalen.
  2. Leta upp din Storage Sync Service-resurs.
  3. Skapa en ny synkroniseringsgrupp i Storage Sync Service-resursen för varje Azure-filresurs. I Azure File Sync-terminologi blir Azure-filresursen en molnslutpunkt i synkroniseringstopologin som du beskriver när du skapar en synkroniseringsgrupp. När du skapar synkroniseringsgruppen ger du den ett bekant namn så att du känner igen vilken uppsättning filer som synkroniseras där. Kontrollera att du refererar till Azure-filresursen med ett matchande namn.
  4. När du har skapat synkroniseringsgruppen visas en rad för den i listan över synkroniseringsgrupper. Välj namnet (en länk) för att visa innehållet i synkroniseringsgruppen. Du ser din Azure-filresurs under Molnslutpunkter.
  5. Leta upp knappen Lägg till serverslutpunkt. Mappen på den lokala server som du har etablerat blir sökvägen till den här serverslutpunkten.

Viktigt!

Molnnivåindelning är funktionen Azure File Sync som gör att den lokala servern kan ha mindre lagringskapacitet än vad som lagras i molnet, men ändå har det fullständiga namnområdet tillgängligt. Lokalt intressanta (heta) data cachelagras också lokalt för snabb åtkomstprestanda. Molnnivåindelning är en valfri funktion per Azure File Sync "serverslutpunkt".

Varning

Om du har etablerat mindre lagringsutrymme på dina Windows-servervolymer än dina data som används på NAS-installationen är molnnivåindelning obligatoriskt. Om du inte aktiverar molnnivåindelning frigör servern inte utrymme för att lagra alla filer. Ange din nivåindelningsprincip, tillfälligt för migreringen, till 99 % ledigt volymutrymme. Se till att återgå till inställningarna för molnnivåindelning när migreringen är klar och ange den till en mer långsiktig användbar nivå.

Upprepa stegen för att skapa en synkroniseringsgrupp och lägg till den matchande servermappen som en serverslutpunkt för alla Azure-filresurser/serverplatser som måste konfigureras för synkronisering.

När alla serverslutpunkter har skapats fungerar synkroniseringen. Du kan skapa en testfil och se den synkroniseras från din serverplats till den anslutna Azure-filresursen (enligt beskrivningen av molnslutpunkten i synkroniseringsgruppen).

Båda platserna, servermapparna och Azure-filresurserna, är i övrigt tomma och väntar på data på någon av platserna. I nästa steg börjar du kopiera filer till Windows Server for Azure File Sync för att flytta dem upp till molnet. Om du har aktiverat molnnivåindelning börjar servern sedan nivåindela filer om kapaciteten på de lokala volymerna tar slut.

Fas 7: Kopiera data med Hjälp av Azure Storage Mover eller RoboCopy

Nu kan du använda Azure Storage Mover eller RoboCopy för att kopiera data från NAS-installationen till din Windows Server och använda Azure File Sync för att flytta data till Azure-filresurser. Den här guiden använder RoboCopy för den första kopian. Information om hur du använder Azure Storage Mover finns i Migrera till SMB Azure-filresurser med Hjälp av Azure Storage Mover.

Kör den första lokala kopian till windows server-målmappen:

  • Identifiera den första platsen på DIN NAS-installation.
  • Identifiera den matchande mappen på Den Windows Server som redan har Azure File Sync konfigurerat på den.
  • Starta kopian.

Följande RoboCopy-kommando kopierar filer från NAS-lagringen till din Windows Server-målmapp. Windows Server synkroniserar den med Azure-filresurserna.

Om du har etablerat mindre lagringsutrymme på Din Windows Server än vad dina filer tar upp på NAS-installationen har du konfigurerat molnnivåindelning. När den lokala Windows Server-volymen blir full kommer molnnivåindelningen att starta och nivåindela filer som redan har synkroniserats. Molnnivåindelning genererar tillräckligt med utrymme för att fortsätta kopian från NAS-installationen. Molnnivåindelningen kontrolleras en gång i timmen för att se vad som har synkroniserats och för att frigöra diskutrymme för att nå 99 % ledigt volymutrymme.

Det är möjligt att RoboCopy flyttar filer snabbare än du kan synkronisera till molnet och nivån lokalt, vilket ger slut på lokalt diskutrymme. I det här fallet misslyckas RoboCopy. Vi rekommenderar att du går igenom resurserna i en sekvens som förhindrar detta, till exempel att inte starta kopieringsjobb för alla resurser samtidigt eller bara flytta resurser som passar på den aktuella mängden ledigt utrymme på Windows Server.

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Switch Innebörd
/MT:n Gör att Robocopy kan köras multitrådat. Standardvärdet för n är 8. Maxvärdet är 128 trådar. Även om ett högt antal trådar hjälper till att mätta den tillgängliga bandbredden betyder det inte att migreringen alltid kommer att gå snabbare med fler trådar. Tester med Azure Files visar att mellan 8 och 20 visar balanserade prestanda för en första kopieringskörning. Efterföljande /MIR körningar påverkas progressivt av tillgänglig beräkning jämfört med tillgänglig nätverksbandbredd. Vid efterföljande körningar matchar du värdet för antal trådar närmare mot antalet processorkärnor och antalet trådar per kärna. Överväg om kärnor måste reserveras för andra uppgifter som en produktionsserver kan utföra. Tester med Azure Files har visat att upp till 64 trådar ger bra prestanda, men bara om dina processorer kan hålla dem vid liv samtidigt.
/R:n Maximalt antal omförsök för en fil som inte kan kopieras vid första försöket. Robocopy försöker n gånger innan filen permanent misslyckas med att kopiera i körningen. Du kan optimera körningens prestanda: Välj ett värde på två eller tre om du tror att tidsgränsproblem orsakade fel tidigare. Detta kan vara vanligare via WAN-länkar. Välj inget nytt försök eller ett värde för ett om du tror att filen inte kunde kopieras eftersom den användes aktivt. Om du försöker igen några sekunder senare kanske det inte finns tillräckligt med tid för att filens användningstillstånd ska ändras. Användare eller appar som håller filen öppen kan behöva timmar mer tid. I det här fallet kan godkännandet av filen inte kopierades och fånga den i en av dina planerade, efterföljande Robocopy-körningar, så småningom lyckas kopiera filen. Det hjälper den aktuella körningen att slutföras snabbare utan att förlängas av många återförsök som i slutändan hamnar i en majoritet av kopieringsfelen på grund av att filer fortfarande öppnas efter tidsgränsen för återförsök.
/W:n Anger hur länge Robocopy ska vänta innan du försöker kopiera en fil som inte gick att kopiera under ett tidigare försök. n är antalet sekunder som ska vänta mellan återförsök. /W:n används ofta tillsammans med /R:n.
/B Kör Robocopy i samma läge som ett säkerhetskopieringsprogram skulle använda. Med den här växeln kan Robocopy flytta filer som den aktuella användaren inte har behörighet för. Säkerhetskopieringsväxeln är beroende av att du kör Robocopy-kommandot i en upphöjd administratörskonsol eller Ett PowerShell-fönster. Om du använder Robocopy för Azure Files kontrollerar du att du monterar Azure-filresursen med hjälp av lagringskontots åtkomstnyckel jämfört med en domänidentitet. Om du inte gör det kanske felmeddelandena inte intuitivt leder dig till en lösning på problemet.
/MIR (Segla källan till målet.) Gör att Robocopy bara kan kopiera delta mellan källa och mål. Tomma underkataloger kopieras. Objekt (filer eller mappar) som har ändrats eller inte finns på målet kopieras. Objekt som finns på målet men inte på källan rensas (tas bort) från målet. När du använder den här växeln matchar du källans och målets mappstruktur exakt. Matchning innebär att kopiera från rätt käll- och mappnivå till den matchande mappnivån på målet. Först då kan en ”catch up”-kopiering lyckas. När källan och målet är matchande leder användningen /MIR till storskaliga borttagningar och omkopior.
/IT Ser till att naturtrogen återgivning bevaras i vissa speglingsscenarier.
Om en fil till exempel upplever en ACL-ändring och en attributuppdatering mellan två Robocopy-körningar markeras den som dold. Utan /ITkan ACL-ändringen missas av Robocopy och inte överföras till målplatsen.
/COPY:[copyflags] Filkopieringens naturtrogna återgivning. Standard: /COPY:DAT. Kopiera flaggor: D= Data, A= Attribut, T= Tidsstämplar, S= Säkerhet = NTFS ACL:er, O= Ägarinformation, U= Auditing information. Granskningsinformation kan inte lagras i en Azure-filresurs.
/DCOPY:[copyflags] Återgivning för kopian av kataloger. Standard: /DCOPY:DA. Kopiera flaggor: D= Data, A= Attribut, T= Tidsstämplar.
/NP Anger att kopieringsförloppet för varje fil och mapp inte visas. Om du visar förloppet får du betydligt läge prestanda.
/NFL Anger att filnamn inte ska loggas. Ger bättre kopieringsprestanda.
/NDL Anger att katalognamn inte ska loggas. Ger bättre kopieringsprestanda.
/XD Anger kataloger som ska undantas. När du kör Robocopy i roten på en volym bör du överväga att undanta den dolda System Volume Information mappen. Om den används som den är utformad är all information där inne specifik för den exakta volymen i det här exakta systemet och kan återskapas på begäran. Att kopiera den här informationen är inte användbart i molnet eller när data någonsin kopieras tillbaka till en annan Windows-volym. Att lämna det här innehållet bakom bör inte betraktas som dataförlust.
/UNILOG:<file name> Skriver status till loggfilen som Unicode. (Skriver över den befintliga loggen.)
/L Endast för en testkörning
ska filer endast visas. De kopieras inte, tas inte bort och får inga tidsstämplar. Används ofta med /TEE för konsolutdata. Flaggor från exempelskriptet, som /NP, /NFLoch /NDL, kan behöva tas bort för att uppnå korrekt dokumenterade testresultat.
/LFSM Endast för mål med nivåindelad lagring. Stöds inte när målet är en fjärransluten SMB-resurs.
Anger att Robocopy fungerar i läget "låg ledigt utrymme". Den här växeln är endast användbar för mål med nivåindelad lagring som kan få slut på lokal kapacitet innan Robocopy slutförs. Den har lagts till specifikt för användning med mål som är aktiverade för molnnivåindelning i Azure File Sync. Den kan användas oberoende av Azure File Sync. I det här läget pausar Robocopy när en filkopiering skulle få målvolymens lediga utrymme att hamna under ett lägsta värde. Det här värdet kan anges i /LFSM:n form av flaggan. Parametern n anges i bas 2: nKB, nMBeller nGB. Om /LFSM anges utan explicit golvvärde anges golvet till 10 procent av målvolymens storlek. Läget låg ledigt utrymme är inte kompatibelt med /MT, /EFSRAWeller /ZB. Stöd för /B lades till i Windows Server 2022. Mer information om en relaterad bugg och lösning finns i avsnittet Windows Server 2022 och RoboCopy LFSM nedan.
/Z Använd försiktigt
Kopierar filer i omstartsläge. Du bör bara använda den här växeln i en instabil nätverksmiljö. Den ber betydligt sämre kopieringsprestanda på grund av den extra loggningen.
/ZB Använd försiktigt
Använder omstartsläge. Om åtkomst nekas använder det här alternativet omstartsläge. Det här alternativet ger betydligt sämre kopieringsprestanda på grund av kontrollpunkterna.

Viktigt!

Vi rekommenderar att du använder en Windows Server 2022. När du använder en Windows Server 2019 ska du se till att den senaste korrigeringsnivån eller minst operativsystemets uppdatering KB5005103 är installerad. Den innehåller viktiga korrigeringar för vissa Robocopy-scenarier.

Fas 8: Användarnedskärning

När du kör RoboCopy-kommandot för första gången kommer dina användare och program fortfarande åt filer på NAS och kan eventuellt ändra dem. Det är möjligt att RoboCopy har bearbetat en katalog, går vidare till nästa och en användare på källplatsen (NAS) lägger till, ändrar eller tar bort en fil som nu inte kommer att bearbetas i den aktuella RoboCopy-körningen. Detta är ett förväntat beteende.

Den första körningen handlar om att flytta huvuddelen av data till Din Windows Server och till molnet via Azure File Sync. Den här första kopian kan ta lång tid, beroende på:

  • din nedladdningsbandbredd
  • uppladdningsbandbredden
  • det lokala nätverkets hastighet och antalet hur optimalt antalet RoboCopy-trådar matchar det
  • antalet objekt (filer och mappar) som behöver bearbetas av RoboCopy och Azure File Sync

När den första körningen är klar kör du kommandot igen.

Den andra gången avslutas snabbare eftersom den bara behöver transportera ändringar som har inträffat sedan den senaste körningen. Under den andra körningen kan nya ändringar fortfarande ackumuleras.

Upprepa den här processen tills du är övertygad om att den tid det tar att slutföra en RoboCopy för en viss plats ligger inom ett acceptabelt fönster för stilleståndstid.

När du anser att stilleståndstiden är acceptabel måste du ta bort användaråtkomsten till dina NAS-baserade resurser. Du kan göra det genom alla steg som hindrar användare från att ändra fil- och mappstrukturen och innehållet. Ett exempel är att peka ditt DFS-Namnområde till en icke-befintlig plats eller ändra rot-ACL:erna på resursen.

Kör en sista RoboCopy-runda. Den kommer att hämta eventuella ändringar som kan ha missats. Hur lång tid det här sista steget tar beror på hastigheten på RoboCopy-genomsökningen. Du kan beräkna tiden (som är lika med din stilleståndstid) genom att mäta hur lång tid den föregående körningen tog.

Skapa en resurs i Windows Server-mappen och justera eventuellt DFS-N-distributionen så att den pekar på den. Se till att ange samma behörigheter på resursnivå som på din NAS SMB-resurs. Om du hade en domänansluten NAS i företagsklass matchar användar-SID:erna automatiskt, eftersom användarna finns i Active Directory och RoboCopy kopierar filer och metadata med fullständig återgivning. Om du har använt lokala användare på din NAS måste du återskapa dessa användare som lokala Windows Server-användare och mappa de befintliga SID:erna RoboCopy som flyttats över till Din Windows Server till sid:erna för dina nya lokala Windows Server-användare.

Du har migrerat en resurs/grupp med resurser till en gemensam rot eller volym. (Beroende på din mappning från fas 1)

Du kan försöka köra några av dessa kopior parallellt. Vi rekommenderar att du bearbetar omfånget för en Azure-filresurs i taget.

Varning

När du har flyttat alla data från din NAS till Windows Server och migreringen är klar: Gå tillbaka till alla synkroniseringsgrupper i Azure-portalen och justera värdet för volymfritt utrymme på molnnivå till något som passar bättre för cacheanvändning, till exempel 20 %.

Principen för ledigt utrymme på molnnivånivå fungerar på volymnivå med potentiellt flera serverslutpunkter som synkroniseras från den. Om du glömmer att justera det lediga utrymmet på ens en serverslutpunkt fortsätter synkroniseringen att tillämpa den mest restriktiva regeln och försöker behålla 99 % ledigt diskutrymme, vilket gör att den lokala cachen inte fungerar som förväntat. Såvida inte målet är att bara ha namnområdet för en volym som endast innehåller sällan använda arkiveringsdata och du reserverar resten av lagringsutrymmet för ett annat scenario.

Felsöka

Det mest sannolika problemet du kan stöta på är att RoboCopy-kommandot misslyckas med "Full volym" på Windows Server-sidan. Molnnivåindelning fungerar en gång i timmen för att evakuera innehåll från den lokala Windows Server-disken som har synkroniserats. Målet är att nå 99 % ledigt utrymme på volymen.

Låt synkroniseringsframsteg och molnnivåindelning frigöra diskutrymme. Observera att i Utforskaren på din Windows Server.

När din Windows Server har tillräckligt med tillgänglig kapacitet kan du lösa problemet genom att köra kommandot igen. Inget går sönder när du kommer in i den här situationen, och du kan gå vidare med självförtroende. Besväret med att köra kommandot igen är den enda konsekvensen.

Kontrollera länken i följande avsnitt för att felsöka problem med Azure File Sync.

Nästa steg

Följande artiklar hjälper dig att förstå distributionsalternativ, metodtips och felsökningssteg.