Använda DataBox för att migrera från nätverksansluten lagring (NAS) till Azure-filresurser
Den här migreringsartikeln är en av flera som rör nyckelorden NAS och Azure DataBox. Kontrollera om den här artikeln gäller för ditt scenario:
- Datakälla: Nätverksansluten lagring (NAS)
- Migreringsväg: NAS ⇒ DataBox ⇒ Azure-filresurs
- Inga cachelagringsfiler lokalt: Eftersom det slutliga målet är att använda Azure-filresurserna direkt i molnet finns det ingen plan för att använda Azure File Sync.
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. Den här guiden använder Azure DataBox för massdatatransport (offlinedatatransport).
Gäller för
Typ av filresurs | SMB | NFS |
---|---|---|
Standardfilresurser (GPv2), LRS/ZRS | ||
Standardfilresurser (GPv2), GRS/GZRS | ||
Premiumfilresurser (FileStorage), LRS/ZRS |
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 den får plats i eller bara något överskrider regelbundna underhållsperioder.
Migreringsöversikt
Migreringsprocessen består av flera faser. Du måste distribuera Azure Storage-konton och filresurser och konfigurera nätverk. Sedan migrerar du dina filer med Hjälp av Azure DataBox och RoboCopy för att komma ikapp med ändringarna. Slutligen klipper du över dina användare och appar till de nyligen skapade Azure-filresurserna. I följande avsnitt beskrivs faserna i migreringsprocessen i detalj.
Dricks
Om du återvänder till den här artikeln använder du navigeringen till höger för att gå vidare till migreringsfasen där du slutade.
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. 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 filresurser du vill migrera till molnet kan du välja att antingen använda en 1:1-mappning eller dela gruppering.
Använda en 1:1-mappning
Om du har ett tillräckligt litet antal resurser rekommenderar vi en 1:1-mappning. 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.
Använda resursgruppering
Om du har ett stort antal filresurser kan du överväga att dela gruppering. Om personalavdelningen till exempel har 15 resurser kan du överväga att lagra alla HR-data i en enda Azure-filresurs. 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 den här fasen etablerar du Azure Storage-kontona och filresurserna i dem.
Kom ihåg att en Azure-filresurs distribueras i molnet på ett Azure Storage-konto. För standardfilresurser gör det här arrangemanget lagringskontot till ett skalningsmål för prestandanummer som IOPS och dataflöde. 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 resurser (resurser som används av många användare och/eller program) vill du distribuera lagringskonton med en filresurs var. Dessa begränsningar gäller inte för FileStorage-lagringskonton (premium), där prestanda uttryckligen etableras och garanteras för varje resurs.
Kommentar
Det finns en gräns på 250 lagringskonton per prenumeration per Azure-region. Med en kvotökning kan du skapa upp till 500 lagringskonton per region. Mer information finns i Öka Azure Storage-kontokvoter.
Ett annat att tänka på när du distribuerar ett lagringskonto är redundans. Se Redundans för Azure Files.
Om du har gjort en lista över dina resurser bör du mappa varje resurs till lagringskontot som den skapas i.
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.
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 vill du se till att regionen för vart och ett av dina lagringskonton är densamma.
Fas 3: Fastställa hur många Azure DataBox-enheter du behöver
Starta endast det här steget när du har slutfört föregående fas. Dina Azure Storage-resurser (lagringskonton och filresurser) bör skapas just nu. Under din DataBox-beställning måste du ange till vilka lagringskonton DataBox flyttar data.
I den här fasen måste du mappa resultatet av migreringsplanen från föregående fas till gränserna för tillgängliga DataBox-alternativ. Dessa överväganden hjälper dig att skapa en plan för vilka DataBox-alternativ du bör välja och hur många av dem du behöver för att flytta dina NAS-resurser till Azure-filresurser.
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:
- Alla Azure DataBox-data kan flytta data till upp till 10 lagringskonton.
- Varje DataBox-alternativ har sin egen användbara kapacitet. Se DataBox-alternativ.
Se migreringsplanen för antalet lagringskonton som du har valt att skapa och resurserna i var och en. Titta sedan på storleken på var och en av resurserna på din NAS. Genom att kombinera den här informationen kan du optimera och bestämma vilken installation som ska skicka data till vilka lagringskonton. Du kan låta två DataBox-enheter flytta filer till samma lagringskonto, men dela inte upp innehållet i en enda filresurs mellan två DataBox-enheter.
DataBox-alternativ
För en standardmigrering bör ett eller en kombination av dessa två DataBox-alternativ väljas:
- DataBox Det här är det vanligaste alternativet. En robust DataBox-apparat, som fungerar ungefär som en NAS, levereras till dig. Den har en användbar kapacitet på 80 TiB. Mer information finns i Dokumentation om DataBox.
- DataBox Heavy Det här alternativet har en robust DataBox-apparat på hjul, som fungerar ungefär som 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 DataBox Heavy.
Varning
Data Box-diskar rekommenderas inte för migreringar till Azure-filresurser. Data Box-diskar bevarar inte filmetadata, till exempel åtkomstbehörigheter (ACL: er) och andra attribut.
Fas 4: Etablera en tillfällig Windows Server
Medan du väntar på att Azure DataBox(es) ska komma kan du redan distribuera en eller flera Windows-servrar som du behöver för att köra RoboCopy-jobb.
- Den första användningen av dessa servrar är att kopiera filer till DataBox.
- Den andra användningen av dessa servrar är att komma ikapp med ändringar som har inträffat på NAS-installationen medan DataBox var i transport. Den här metoden håller stilleståndstiden på källsidan till ett minimum.
Hur snabbt roboCopy-jobben fungerar beror främst på följande faktorer:
- IOPS på käll- och mållagringen
- den tillgängliga nätverksbandbredden mellan dem
Hitta mer information i avsnittet Felsökning: överväganden för IOPS och bandbredd - möjligheten att snabbt bearbeta filer och mappar i ett namnområde
Hitta mer information i avsnittet Felsökning: Bearbetningshastighet - antalet ändringar mellan RoboCopy-körningar
Hitta mer information i avsnittet Felsökning: Undvik onödigt arbete
Det är viktigt att ha den refererade informationen i åtanke när du bestämmer dig för det RAM-minne och trådantal som du ska ange för dina tillfälliga Windows Server(er).
Fas 5: Förbereder användning av Azure-filresurser
För att spara tid bör du fortsätta med den här fasen medan du väntar på att databoxen ska komma. Med informationen i den här fasen kan du bestämma hur dina servrar och användare i Azure och utanför Azure ska aktiveras för att använda dina Azure-filresurser. De viktigaste besluten är:
- Nätverk: Aktivera nätverk för att dirigera SMB-trafik.
- Autentisering: Konfigurera Azure Storage-konton för Kerberos-autentisering. AdConnect och domän som ansluter till ditt lagringskonto gör det möjligt för dina appar och användare att använda sin AD-identitet för autentisering
- Auktorisering: ACL:er på resursnivå för varje Azure-filresurs ger AD-användare och grupper åtkomst till en viss resurs och i en Azure-filresurs tar interna 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: Integrering av Azure-filresurser i en befintlig miljö innebär ofta att befintliga resursadresser bevaras. Om du inte redan använder DFS-Namnområden bör du överväga att etablera det i din miljö. Du skulle kunna behålla delningsadresser som användarna och skripten 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.
Den här videon är en guide och demo för hur du på ett säkert sätt exponerar Azure-filresurser direkt för informationsarbetare och appar i fem enkla steg.
Videon refererar till dedikerad dokumentation för följande avsnitt. Observera att Azure Active Directory nu är Microsoft Entra-ID. För mer information, se Nytt namn för Azure AD.
- Översikt över identitetsbaserad autentisering för SMB
- Nätverksöversikt för Azure-filresurser
- Så här konfigurerar du offentliga och privata slutpunkter
- Så här konfigurerar du ett S2S VPN
- Så här konfigurerar du ett Windows P2S VPN
- Så här konfigurerar du ett Linux P2S VPN
- Konfigurera DNS-vidarebefordran
- Konfigurera DFS-N
Fas 6: Kopiera filer till din DataBox
När din DataBox anländer måste du konfigurera din DataBox med obehindrat nätverksanslutning till DIN NAS-enhet. Följ installationsdokumentationen för den DataBox-typ som du har beställt.
Beroende på DataBox-typ finns det kanske databox-kopieringsverktyg som är tillgängliga för dig. I det här läget rekommenderas de inte för migreringar till Azure-filresurser eftersom de inte kopierar dina filer med fullständig återgivning till DataBox. Använd RoboCopy i stället.
När din DataBox anländer har den företablerade SMB-resurser tillgängliga för varje lagringskonto som du angav vid tidpunkten för beställningen.
- Om dina filer hamnar i en Premium Azure-filresurs finns det en SMB-resurs per premiumlagringskonto för "fillagring".
- Om dina filer går in på ett standardlagringskonto finns det tre SMB-resurser per standardlagringskonto (GPv1 och GPv2). Endast de filresurser som slutar med
_AzFiles
är relevanta för migreringen. Ignorera alla block- och sidblobresurser.
Följ stegen i Azure DataBox-dokumentationen:
- Ansluta till Data Box
- Kopiera data till Data Box
- Förbereda din DataBox för avresa till Azure
Den länkade DataBox-dokumentationen anger ett RoboCopy-kommando. Kommandot är dock inte lämpligt för att bevara den fullständiga fil- och mappåtergivningen. Använd det här kommandot i stället:
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:n
på 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.
Dricks
Som ett alternativ till Robocopy har Data Box skapat en datakopieringstjänst. Du kan använda den här tjänsten för att läsa in filer på din Data Box med fullständig återgivning. Följ den här självstudien om datakopieringstjänsten och se till att ange rätt Azure-filresursmål.
Fas 7: Kom ikapp RoboCopy från din NAS
När din DataBox rapporterar att alla filer och mappar har placerats i de planerade Azure-filresurserna kan du fortsätta med den här fasen. En catch-up RoboCopy behövs bara om data på NAS kan ha ändrats sedan DataBox-kopian startades. 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 en resurs för att vara skrivskyddad under migreringen och bara kan absorbera ett litet avbrottsfönster, är det här roboCopy-steget viktigt att slutföra innan redundansväxlingen av användaråtkomst direkt till Azure-filresursen.
I det här steget kör du RoboCopy-jobb för att komma ikapp dina molnresurser med de senaste ändringarna på DIN NAS sedan du förgrenade dina resurser till DataBox. Den här upphämtningen av RoboCopy kan avslutas snabbt eller ta ett tag, beroende på mängden omsättning som skedde på dina NAS-resurser.
Kör den första lokala kopian till windows server-målmappen:
- Identifiera den första platsen på DIN NAS-installation.
- Identifiera den matchande Azure-filresursen.
- Montera Azure-filresursen som en lokal nätverksenhet på din tillfälliga Windows Server
- 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 resursen som en lokal nätverksenhet till den Windows Server som du planerar att använda för RoboCopy.
Viktigt!
Innan du kan montera en Azure-filresurs på en lokal Windows Server måste du ha slutfört fasen : Förbereder användning av Azure-filresurser!
När du är klar läser du artikeln Använd en Azure-filresurs med Windows och monterar den Azure-filresurs som du vill starta NAS-komma ikapp RoboCopy för.
RoboCopy
Följande RoboCopy-kommando kopierar endast skillnaderna (uppdaterade filer och mappar) från NAS-lagringen till din Azure-filresurs.
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 /IT kan 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 , /NFL och /NDL , kan behöva tas bort för att uppnå korrekt dokumenterade testresultat. |
/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.
Dricks
Kolla in felsökningsavsnittet om RoboCopy påverkar produktionsmiljön, rapporterar många fel eller inte går så snabbt som förväntat.
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 sedan lägger en användare på källplatsen (NAS) 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 dataomsättningen till din Azure-filresurs. 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.
När den första körningen är klar kör du kommandot igen.
En andra gång du kör RoboCopy för samma resurs avslutas den snabbare eftersom den bara behöver transportera ändringar som har inträffat sedan den senaste körningen. Du kan köra upprepade jobb för samma resurs.
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. Det kommer att plocka upp eventuella ändringar, som kan ha missats. Hur lång tid det här sista steget tar beror på roboCopy-genomsökningens hastighet. 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 när 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.
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.
Felsöka
Hastigheten och framgångsgraden för en viss 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.
Varning
Även om det ofta är mest önskvärt att kopiera så snabbt som möjligt bör du överväga användningen av ditt lokala nätverk och NAS-installationen för andra, ofta affärskritiska uppgifter.
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. Med den här växeln kan du undvika monopolisering av resurser på både I/O-begränsade enheter och överfulla nätverkslänkar.
/IPG:n
kan inte användas för exakt nätverksbegrä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. När du har infört en fördröjning kan du utvärdera om dina andra appar nu kan fungera som förväntat. Med den här optimeringsstrategin kan du hitta den optimala RoboCopy-hastigheten i din miljö.
Bearbetningshastighet
RoboCopy bläddrar igenom namnområdet som det pekar på och utvärderar varje fil och mapp för kopiering. Varje fil utvärderas under en första kopia och under upphämtningskopior. Till exempel upprepade körningar av RoboCopy /MIR mot samma käll- och mållagringsplatser. Dessa upprepade körningar är användbara för att minimera stilleståndstiden för användare och appar och för att förbättra den totala framgångsgraden för filer som migreras.
Vi brukar ofta betrakta bandbredd som den mest begränsande faktorn i en migrering – och det kan vara sant. 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 betydligt 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. Detta är det förväntade beteendet.
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 vårt 1-TiB-exempel på små filer betydligt snabbare än färre trådar. Samtidigt kanske den extra resursinvesteringen på vår 1 TiB av större filer inte ger proportionella fördelar. Ett högt antal trådar försöker kopiera fler av de stora filerna ö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 troligen 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.
Dricks
Tumregel: Den första RoboCopy-körningen, som flyttar mycket data i ett nätverk med högre svarstid, drar nytta av överetablering av antalet trådar (/MT:n
). Efterföljande körningar kopierar färre skillnader och du är mer benägna att flytta från nätverksdataflöde begränsat till beräkningsbegränsat. Under dessa omständigheter är det ofta bättre att matcha antalet RoboCopy-trådar med de faktiskt tillgängliga trådarna på datorn. Överetablering i det scenariot kan leda till fler kontextförskjutningar i processorn, vilket kan göra kopian långsammare.
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
- återanvändning av data som flyttats tidigare kan behöva kopieras på nytt. Till exempel måste mer data kopieras när mappstrukturerna ändras efter att filer redan har kopierats tidigare. 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. Med det rekommenderade RoboCopy-skriptet skapar och sparar du en loggfil för fel. Kopieringsfel kan inträffa – det är normalt. Dessa fel gör det ofta nödvändigt att köra flera omgångar av ett kopieringsverktyg som RoboCopy. En första körning, till exempel från en NAS till DataBox eller en server till en Azure-filresurs. Och en eller flera extra körningar med /MIR-växeln för att fånga och försöka igen filer som inte kopieras.
Du bör vara beredd att köra flera rundor av RoboCopy mot ett angivet namnområdesomfång. Efterföljande körningar slutförs snabbare eftersom de har mindre att kopiera, men begränsas i allt högre grad av bearbetningshastigheten för namnområdet. 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.
Nästa steg
Det finns mer att upptäcka om Azure-filresurser. Följande artiklar hjälper dig att förstå avancerade alternativ, metodtips och även felsökningshjälp. De här artiklarna länkar till Dokumentation om Azure-filresurser efter behov.