Använd Data Box för att migrera från Network Attached Storage (NAS) till Azure-fildelningar

✔️ Gäller för: Klassiska SMB-fildelningar som skapats med Microsoft.Storage-resursprovider

✖️ Gäller inte för: Alla NFS-filresurser, inklusive filresurser som har skapats med resursprovidern Microsoft.FileShares eller klassiska filresurser som har skapats med resursprovidern Microsoft.Storage

Denna artikel om migration är en av flera som involverar nyckelorden NAS och Azure Data Box. Kontrollera om den här artikeln gäller för ditt scenario:

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

Den här artikeln vägleder dig från slutpunkt till slutpunkt genom de planerings-, distributions- och nätverkskonfigurationer som behövs för att migrera från DIN NAS-installation till funktionella Azure-filresurser. Denna guide använder Azure Data Box för bulkdatatransport (offline-datatransport).

Migreringsmål

Målet är att flytta resurserna på DIN NAS-installation till Azure och låta dem bli interna Azure-filresurser. Du kan använda interna Azure-filresurser utan att behöva en Windows Server. Den här migreringen måste göras på ett sätt som garanterar integriteten för produktionsdata och tillgänglighet under migreringen. Det senare kräver att stilleståndstiden hålls till ett minimum, så att stilleståndstiden får plats i eller bara något överskrider regelbundna underhållsperioder.

Migreringsöversikt

Migreringsprocessen består av flera faser. Först, distribuera Azure-lagringskonton och fildelningar samt konfigurera nätverk. Migrera sedan dina filer med Azure Data Box och RoboCopy för att komma ikapp ändringarna. Slutligen, koppla över dina användare och appar till de nyskapade Azure-fildelningarna. I följande avsnitt beskrivs faserna i migreringsprocessen i detalj.

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

Bestäm hur många Azure-fildelningar du behöver. 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. Beroende på hur många fildelningar du vill migrera till molnet, välj antingen en en-till-en-mappning eller delningsgrupp.

Använda en 1:1-mappning

Om du har ett litet antal delningar, använd en en-till-en-mappning. Det enklaste sättet att föreställa sig det här scenariot är att tänka sig en lokal filresurs som motsvarar exakt en Azure-filresurs.

Använda delningsgruppering

Om du har ett stort antal fildelningar kan du överväga gruppering av dessa. Om personalavdelningen (HR) till exempel har 15 andelar, kan du överväga att lagra all personalavdelningens data i en enda Azure-filandel. På så sätt behövs bara en enda Azure-filresurs i molnet för den här gruppen med lokala resurser.

Fas 2: Distribuera Azure Storage-resurser

I denna fas tillhandahålls Azure-lagringskontona och fildelningarna inom dem.

Kom ihåg att en Azure-filresurs distribueras i molnet på ett Azure Storage-konto. För HDD-fildelning (standard) gör det arrangemanget lagringskontot till ett prestandamål för siffror som IOPS och genomströmning. Om du placerar flera filresurser i ett enda lagringskonto skapar du en delad pool med IOPS och dataflöde för dessa resurser.

Som en allmän regel kan du poola flera Azure-filresurser till samma lagringskonto om du har arkivresurser eller om du förväntar dig låg daglig aktivitet i dem. Men om du har mycket aktiva delningar (delar som används av många användare och applikationer), distribuera lagringskonton med en fildelning vardera. Dessa begränsningar gäller inte för SSD-lagringskonton (FileStorage), där prestanda uttryckligen etableras och garanteras för varje resurs.

Ett annat att tänka på när du distribuerar ett lagringskonto är redundans. Se Redundans för Azure Files.

Om du gör en lista över dina delningar, mappa varje delning till lagringskontot där du skapar den.

Namnen på dina resurser är också viktiga. Till exempel, om du grupperar flera delar för HR-avdelningen i ett Azure-lagringskonto, namnge lagringskontot därefter. På samma sätt, när du namnger dina Azure-fildelningar, använd namn som liknar de som används för deras lokala motsvarigheter.

Distribuera nu lämpligt antal Azure-lagringskonton med lämpligt antal Azure-filresurser i dem, enligt anvisningarna i Skapa en SMB-filresurs. I de flesta fall, se till att regionerna för varje lagringskonto är densamma.

Fas 3: Fastställa hur många Azure Data Box-enheter du behöver

Börja detta steg först när du har slutfört föregående fas. Vid det här laget bör du ha skapat dina Azure-lagringsresurser, inklusive lagringskonton och fildelningar. Under din Data Box-beställning behöver du ange vilka lagringskonton Data Box flyttar data till.

I denna fas, kartlägg resultaten av migrationsplanen från föregående fas till gränserna för tillgängliga Data Box-alternativ. Dessa överväganden hjälper dig att göra en plan för vilka Data Box-alternativ du ska välja och hur många du behöver för att flytta dina NAS-shares till Azure-fildelningar.

Du kan ta reda på hur många enheter av vilken typ du behöver genom att tänka på följande viktiga gränser:

• Vilken Azure Data Box som helst kan flytta data till upp till 10 lagringskonton.
• Varje Data Box-alternativ har sin egen användbara kapacitet. Se Alternativ för Data Box.

Konsultera din migreringsplan för hur många lagringskonton du har valt att skapa och vilka andelar som finns i varje. Titta sedan på storleken på var och en av resurserna på din NAS. Genom att kombinera denna information kan du avgöra vilken enhet som ska skicka data till vilka lagringskonton. Du kan låta två Data Box-enheter flytta filer till samma lagringskonto, men dela inte upp innehållet från en enda fildelning mellan två Data Box-enheter.

Data Box-alternativ

För en standardmigrering, välj en eller en kombination av dessa två Data Box-alternativ:

• Databox Detta alternativ är det vanligaste valet. Det är en robust Data Box-apparat som fungerar likt en NAS. Den levereras till dig med en användbar kapacitet på 80 TiB. Mer information finns i Dokumentation om Data Box.
• Data Box Heavy Detta alternativ har en robust Data Box-apparat på hjul som fungerar likt en NAS, med en kapacitet på 1 PiB. Den användbara kapaciteten är cirka 20 % mindre på grund av omkostnader för kryptering och filsystem. Mer information finns i Dokumentation om Data Box Heavy.

Fas 4: Etablera en tillfällig Windows Server

Medan du väntar på att dina Azure Data Box-apparater ska komma kan du redan distribuera en eller flera Windows-servrar som du behöver för att köra RoboCopy-jobb. För krav på OS-versioner, se den viktiga notisen i avsnittet RoboCopy.

• Använd dessa servrar för att kopiera filer till Data Box.
• Använd dessa servrar för att komma ikapp med ändringar som sker på NAS-enheten medan Data Box är under transport. Den här metoden håller stilleståndstiden på källsidan till ett minimum.

Hur snabbt dina RoboCopy-jobb fungerar beror främst på dessa faktorer:

• IOPS på käll- och mållagringen
• den tillgängliga nätverksbandbredden mellan dem
  Hitta mer information: överväganden för IOPS och bandbredd
• möjligheten att snabbt bearbeta filer och mappar i ett namnområde
  Hitta mer information: Bearbetningshastighet
• antalet ändringar mellan RoboCopy-körningar
  Hitta mer information: Undvik onödigt arbete

Tänk på de refererade detaljerna när du bestämmer RAM och trådantal du tillhandahåller till dina tillfälliga Windows Server.

Fas 5: Förbereder användning av Azure-filresurser

För att spara tid, fortsätt med denna fas medan du väntar på att din Data Box ska komma. Med informationen i denna fas kan du avgöra hur dina servrar och användare ska använda dina Azure-fildelningar. De viktigaste besluten är:

• Nätverk: Aktivera nätverk för att dirigera SMB-trafik.
• Autentisering: Konfigurera Azure Storage-konton för Kerberos-autentisering. Microsoft Entra Connect och domänanslutning till ditt lagringskonto låter dina appar och användare använda sin AD-identitet för autentisering.
• Auktorisation: Share-level ACLs för varje Azure-fildelning låter AD-användare och grupper komma åt en given delning, och inom en Azure-fildelning tar inbyggda NTFS-ACL:er över. Auktorisering baserat på fil- och mapp-ACL:er fungerar sedan som den gör för lokala SMB-resurser.
• Affärskontinuitet: Integration av Azure-fildelningar i en befintlig miljö innebär ofta att befintliga delningsadresser bevaras. Om du inte redan använder DFS-Namnområden bör du överväga att etablera det i din miljö. Du kan behålla delningsadresser som dina användare och skript använder oförändrade. Du skulle använda DFS-N som en namnområdesroutningstjänst för SMB genom att omdirigera DFS-Namespace-mål till Azure-filresurser efter migreringen.

Fas 6: Kopiera filer till din Data Box

När din Data Box anländer, ställ in din Data Box med obehindrad nätverksanslutning till din NAS-enhet. Följ installationsdokumentationen för den typ av Data Box du beställde.

• Konfigurera Data Box
• Konfigurera Data Box Disk
• Konfigurera Data Box Heavy

Beroende på typen av Data Box kan du ha tillgång till kopieringsverktyg för Data Box. Vid det här laget, använd dem inte för migreringar till Azure-fildelningar eftersom de inte kopierar dina filer med full trovärdighet till Data Box. Använd RoboCopy i stället.

När din Data Box anländer har den förkonfigurerade SMB-shares tillgängliga för varje lagringskonto du angav vid beställningstillfället.

• Om dina filer hamnar i en SSD Azure-fildelning finns det en SMB-delning per SSD "File storage"-lagringskonto.
• Om dina filer lagras i ett HDD-lagringskonto finns det tre SMB-resurser för varje HDD-lagringskonto med betala per användning. Endast fildelningen som slutar med _AzFile är relevant för din migrering. Ignorera alla block- och sidblobandelar.

Hur Data Box kopplar mappar till Azure-fildelningar

Under <storage-account-name>_AzFile enhetsdelningen mappas varje första nivå-mapp till en Azure-fildelning på mållagringskontot:

• Mappnamnet på första nivån blir Azure-fildelningsnamnet vid inmatning. Om en delning med det namnet inte redan finns i mållagringskontot, skapar Data Box den. Om det finns, kopierar Data Box datan till den befintliga delningen.

• Kopiera inte filer direkt till roten på den delade resursen _AzFile. All data måste läggas i en första nivå-mapp.

• För en en-till-en-mappning med dina käll-SMB-delningar, skapa en mapp på första nivån för varje källdelning (med önskat Azure-fildelningsnamn) och kopiera varje källdel till motsvarande mapp. Ett exempel:

  \\<DataBox-IP>\<storage-account-name>_AzFile\Share1
  \\<DataBox-IP>\<storage-account-name>_AzFile\Share2
  \\<DataBox-IP>\<storage-account-name>_AzFile\Share3
  

För mer information, se Connect to Data Box.

Följ stegen i Azure Data Box-dokumentationen:

1. Ansluta till Data Box
2. Kopiera data till Data Box
3. Gå igenom RoboCopy-loggfilen för fel för att bekräfta att alla filer har kopierats framgångsrikt.
4. Förbered din Data Box för avresa till Azure

Den länkade Data Box-dokumentationen specificerar ett RoboCopy-kommando. Kommandot är dock inte lämpligt för att bevara hela filens och mappens fidelitet. Detta kommando använder /MT:32 eftersom det är en lokal kopia över LAN till Data Box med försumbar latens, så ett högre trådantal är lämpligt här än för den WAN-baserade ikappkopieringen i fas 7:

Robocopy /MT:32 /NP /NFL /NDL /B /MIR /IT /COPY:DATSO /DCOPY:DAT /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path> 

• Mer information om de enskilda RoboCopy-flaggorna finns i tabellen i det kommande RoboCopy-avsnittet.
• Om du vill veta mer om hur du storleksanpassar trådantalet /MT:npå rätt sätt, optimerar RoboCopy-hastigheten och gör RoboCopy till en bra granne i datacentret kan du ta en titt på felsökningsavsnittet RoboCopy.

Fas 7: Kom ikapp RoboCopy från din NAS

Efter att din Data Box rapporterat att den placerat alla filer och mappar i de planerade Azure-fildelningarna, fortsätt med denna fas. Du behöver bara en kompletterande kopiering med RoboCopy om data på NAS-enheten kan ha ändrats sedan kopieringen till Data Box startade. I vissa scenarier där du använder en resurs i arkiveringssyfte kanske du kan stoppa ändringar i resursen på din NAS tills migreringen är klar. Du kan också ha möjlighet att uppfylla dina affärskrav genom att ange NAS-resurser till skrivskyddade under migreringen.

I de fall där du behöver att en fildelning ska vara läs- och skrivbar under migreringen och bara kan tolerera ett kort driftstopp, är detta ikappkörningssteg med RoboCopy viktigt att genomföra innan användaråtkomsten växlas över direkt till Azure-fildelningen.

I det här steget kör du Robocopy-jobb för att synkronisera dina molndelningar med de senaste ändringarna på din NAS sedan du kopierade dina delningar till Data Box. Denna ikappkörning med RoboCopy kan slutföras snabbt eller ta en stund, beroende på hur många förändringar som har skett på dina NAS-resurser.

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

1. Identifiera den första platsen på DIN NAS-installation.
2. Identifiera den matchande Azure-fildelningen.
3. Montera Azure-fildelningen som en lokal nätverksenhet på din tillfälliga Windows Server.
4. Starta kopian med RoboCopy enligt beskrivningen.

Montera en Azure-filresurs

Innan du kan använda RoboCopy måste du göra Azure-filresursen tillgänglig via SMB. Det enklaste sättet är att montera delningen som en lokal nätverksenhet till den Windows-server du planerar att använda för RoboCopy.

När du är redo läser du igenom instruktionsartikeln om hur du använder en Azure-fildelning med Windows och monterar den Azure-fildelning som du vill köra RoboCopy-synkroniseringen för NAS-ikappkörning på.

RoboCopy

Följande RoboCopy-kommando kopierar endast skillnaderna (uppdaterade filer och mappar) från din NAS-lagring till din Azure-fildelning.

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> 

Klipp ut användare

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 den bearbetade datan till din Azure-filandel. Den här första kopian kan ta en stund. Mer information om vad som kan påverka RoboCopy-hastigheter finns i avsnittet Felsökning.

Efter att den initiala körningen är klar, kör kommandot igen.

När du kör RoboCopy för samma delning en andra gång går det snabbare, eftersom det bara behöver överföra de ändringar som har skett sedan den senaste körningen. Du kan köra upprepade jobb för samma andel.

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 obefintlig plats eller ändra rot-ACL:erna på delningen.

Kör en sista RoboCopy-runda. Den plockar upp eventuella förä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 delning 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 när användarna finns i služba 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 slutfört migreringen av en resurs eller en grupp resurser till en gemensam rot eller volym.

Du kan försöka köra några av dessa kopior parallellt. Bearbeta omfattningen av en Azure-fildelning åt gången.

Felsöka

Hastigheten och framgångsgraden för en RoboCopy-körning beror på flera faktorer:

• IOPS på käll- och mållagringen
• tillgänglig nätverksbandbredd mellan källa och mål
• möjligheten att snabbt bearbeta filer och mappar i ett namnområde
• antalet ändringar mellan RoboCopy-körningar
• storlek och antal filer som du behöver kopiera

Överväganden för IOPS och bandbredd

I den här kategorin måste du överväga funktionerna i källlagringen, mållagringen och nätverket som ansluter dem. Det maximala möjliga dataflödet bestäms av den långsammaste av dessa tre komponenter. Kontrollera att nätverksinfrastrukturen är konfigurerad för att stödja optimala överföringshastigheter efter bästa förmåga.

Det är kanske inte önskvärt att kopiera så snabbt som möjligt när det finns en risk att migreringen kan monopolisera tillgängliga resurser.

• Tänk på när det är bäst i din miljö att köra migreringar: under dagen, ledig tid eller under helger.
• Överväg också att nätverka QoS på en Windows Server för att begränsa RoboCopy-hastigheten.
• Undvik onödigt arbete för migreringsverktygen.

RoboCopy kan infoga fördröjningar mellan paket genom att ange växeln /IPG:n där n mäts i millisekunder mellan RoboCopy-paket. Att använda denna switch kan hjälpa till att undvika monopol på resurser både på I/O-begränsade enheter och trånga nätverkslänkar.

/IPG:n kan inte användas för precis bandbreddsbegränsning till en viss Mbit/s. Använd Windows Server Network QoS i stället. RoboCopy är helt beroende av SMB-protokollet för alla nätverksbehov. Att använda SMB är anledningen till att RoboCopy inte kan påverka själva nätverkets dataflöde, men det kan göra användningen långsammare.

En liknande tankelinje gäller för IOPS som observerats på NAS. Klusterstorleken på NAS-volymen, paketstorlekarna och en matris med andra faktorer påverkar den observerade IOPS. Att införa fördröjning mellan paket är ofta det enklaste sättet att styra belastningen på NAS:n. Testa flera värden, till exempel från cirka 20 millisekunder (n=20) till multiplar av det talet. Efter att du infört en fördröjning kan du utvärdera om dina andra appar nu fungerar som förväntat. Denna optimeringsstrategi hjälper dig att hitta den optimala RoboCopy-hastigheten i din miljö.

Bearbetningshastighet

RoboCopy går igenom namnrymden du anger och utvärderar varje fil och mapp för kopiering. Utvärderar varje fil under den inledande kopieringen och vid ikappkopieringar. Till exempel upprepade körningar av RoboCopy /MIR mot samma käll- och mållagringsplatser. Dessa upprepade körningar minimerar driftstopp för användare och appar och förbättrar den totala framgångsgraden för filer som migreras.

Bandbredd anses ofta vara den mest begränsande faktorn vid en migration, och det kan stämma. Men möjligheten att räkna upp ett namnområde kan påverka den totala tiden att kopiera ännu mer för större namnområden med mindre filer. Tänk på att kopiering av 1 TiB av små filer tar avsevärt längre tid än att kopiera 1 TiB av färre men större filer, förutsatt att alla andra variabler förblir desamma. Därför kan du uppleva långsam överföring om du migrerar ett stort antal små filer. Den här skillnaden är förväntad.

Orsaken till den här skillnaden är den bearbetningskraft som krävs för att gå igenom ett namnområde. RoboCopy stöder flertrådade kopior via parametern /MT:n där n står för antalet trådar som ska användas. När du etablerar en dator specifikt för RoboCopy bör du överväga antalet processorkärnor och deras relation till antalet trådar som de tillhandahåller. De vanligaste är två trådar per kärna. Kärn- och trådantalet för en dator är en viktig datapunkt för att bestämma vilka flertrådsvärden /MT:n du ska ange. Tänk också på hur många RoboCopy-jobb som du planerar att köra parallellt på en viss dator.

Fler trådar kopierar exemplet med 1 TiB med små filer avsevärt snabbare än färre trådar. Samtidigt kanske den extra resursinvesteringen på 1 TiB av större filer inte ger proportionella fördelar. Ett högt trådantal innebär att fler av de stora filerna kopieras över nätverket samtidigt. Den här extra nätverksaktiviteten ökar sannolikheten för att begränsas av dataflöde eller lagrings-IOPS.

Under en första RoboCopy till ett tomt mål eller en differentiell körning med många ändrade filer begränsas du förmodligen av nätverkets dataflöde. Börja med ett stort antal trådar i den första körningen. Ett högt antal trådar, även utanför dina tillgängliga trådar på datorn, hjälper till att mätta den tillgängliga nätverksbandbredden. Efterföljande /MIR-körningar påverkas progressivt av bearbetningsobjekt. Färre ändringar i en differentiell körning innebär mindre dataöverföring över nätverket. Din hastighet är nu mer beroende av att du kan bearbeta namnområdesobjekt än att flytta dem via nätverkslänken. För efterföljande körningar matchar du värdet för antal trådar med antalet processorkärnor och trådantalet per kärna. Tänk på om kärnor måste reserveras för andra uppgifter som en produktionsserver kan ha.

Undvik onödigt arbete

Undvik storskaliga ändringar i namnområdet. Till exempel att flytta filer mellan kataloger, ändra egenskaper i stor skala eller ändra behörigheter (NTFS-ACL:er). Särskilt ACL-ändringar kan ha stor inverkan eftersom de ofta har en sammanhängande ändringseffekt på filer längre ned i mapphierarkin. Konsekvenserna kan vara:

• utökad Körningstid för RoboCopy-jobb eftersom varje fil och mapp som påverkas av en ACL-ändring behöver uppdateras
• Data som har flyttats tidigare kan behöva kopieras om vid återanvändning. Till exempel behöver mer data kopieras när mappstrukturer ändras efter att filer redan har kopierats. Ett RoboCopy-jobb kan inte "spela upp" en namnområdesändring. Nästa jobb måste rensa filerna som tidigare transporterats till den gamla mappstrukturen och ladda upp filerna i den nya mappstrukturen igen.

En annan viktig aspekt är att använda RoboCopy-verktyget effektivt. Genom att använda det rekommenderade RoboCopy-skriptet skapar och sparar du en loggfil för fel. Kopieringsfel kan inträffa och det är normalt. Dessa fel gör det ofta nödvändigt att köra flera omgångar av ett kopieringsverktyg som RoboCopy. Till exempel en inledande körning, till exempel från en NAS till Data Box eller från en server till en Azure-filresurs, och en eller flera extra körningar med växeln /MIR för att fånga upp och försöka kopiera om filer som inte kopierades.

Var beredd på att köra flera omgångar av RoboCopy mot ett givet namnrymdsområde. Successiva körningar slutförs snabbare eftersom de har mindre att kopiera, men begränsas i allt högre grad av hastigheten hos bearbetningen av namnrymden. När du kör flera rundor kan du påskynda varje runda genom att inte låta RoboCopy försöka orimligt hårt för att kopiera allt i en viss körning. Dessa RoboCopy-växlar kan göra stor skillnad:

• /R:n n = hur ofta du försöker kopiera en misslyckad fil igen och
• /W:n n = hur många sekunder som ska vänta mellan återförsök

/R:5 /W:5 är en rimlig inställning som du kan anpassa efter dina önskemål. I det här exemplet görs ett nytt försök med en misslyckad fil, med fem sekunders väntetid mellan återförsök. Om filen fortfarande inte kan kopieras försöker nästa RoboCopy-jobb igen. Ofta kan filer som misslyckades på grund av att de används eller på grund av tidsgränsproblem så småningom kopieras på det här sättet.

Se även

• Migreringsöversikt
• Nätverksöverväganden för direkt åtkomst
• Ögonblicksbilder av Azure-fildelning