StorSimple 8100- och 8600-migrering till Azure File Sync

StorSimple 8000-serien representeras av antingen 8100 eller 8600 fysiska, lokala installationer och deras molntjänstkomponenter. Det går att migrera data från någon av dessa apparater till en Azure File Sync miljö. Azure File Sync är den standard- och strategiska långsiktiga Azure-tjänst som StorSimple-installationer kan migreras till.

StorSimple 8000-serien går ut i december 2022. Det är viktigt att börja planera migreringen så snart som möjligt. Den här artikeln innehåller nödvändiga bakgrundskunskaper och migreringssteg för en lyckad migrering till Azure File Sync.

Fas 1: Förbereda för migrering

Det här avsnittet innehåller de steg som du bör vidta i början av migreringen från StorSimple-volymer till Azure-filresurser.

Inventering

När du börjar planera migreringen ska du först identifiera alla StorSimple-enheter och volymer som du behöver migrera. När du har gjort det kan du välja den bästa migreringsvägen för dig.

Sammanfattning av migreringskostnad

Migreringar till Azure-filresurser från StorSimple-volymer via migreringsjobb i StorSimple Data Manager resurs är kostnadsfria. Andra kostnader kan tillkomma under och efter en migrering:

  • Utgående nätverkstrafik: Dina StorSimple-filer finns i ett lagringskonto i en specifik Azure-region. Om du etablerar Azure-filresurser som du migrerar till ett lagringskonto som finns i samma Azure-region sker ingen utgående kostnad. Du kan flytta dina filer till ett lagringskonto i en annan region som en del av migreringen. I så fall gäller utgående kostnader för dig.
  • Azure-filresurstransaktioner: När filer kopieras till en Azure-filresurs (som en del av en migrering eller utanför en) tillämpas transaktionskostnaderna när filer och metadata skrivs. Bästa praxis är att starta din Azure-filresurs på den transaktionsoptimerade nivån under migreringen. Växla till önskad nivå när migreringen är klar. I följande faser visas detta vid lämplig tidpunkt.
  • Ändra en Azure-filresursnivå: Ändra nivån för en Azure-filresurs kostnadstransaktioner. I de flesta fall är det mer kostnadseffektivt att följa rekommendationerna från föregående punkt.
  • Lagringskostnad: När den här migreringen börjar kopiera filer till en Azure-filresurs Azure Files lagringsutrymmet förbrukas och faktureras. Migrerade säkerhetskopior blir ögonblicksbilder av Azure-filresursen. Ögonblicksbilder av filresurs förbrukar endast lagringskapacitet för de skillnader som de innehåller.
  • StorSimple: Tills du har möjlighet att avetablera StorSimple-enheter och lagringskonton fortsätter StorSimple-kostnaden för lagring, säkerhetskopiering och installationer att ske.

Direkt resursåtkomst jämfört med Azure File Sync

Azure-filresurser öppnar upp en helt ny värld av möjligheter att strukturera distributionen av filtjänster. En Azure-filresurs är bara en SMB-resurs i molnet som du kan konfigurera så att användarna får åtkomst direkt via SMB-protokollet med den välbekanta Kerberos-autentiseringen och befintliga NTFS-behörigheter (fil- och mapp-ACL:er) som fungerar inbyggt. Läs mer om identitetsbaserad åtkomst till Azure-filresurser.

Ett alternativ till direktåtkomst är Azure File Sync. Azure File Sync är en direkt analog för StorSimples möjlighet att cachelagra filer som används ofta lokalt.

Azure File Sync är en Microsoft-molntjänst som baseras på två huvudkomponenter:

  • Filsynkronisering och molnnivåindelning för att skapa en cache för prestandaåtkomst på valfri Windows Server.
  • Filresurser som intern lagring i Azure som kan nås via flera protokoll som SMB och fil-REST.

Azure-filresurser behåller viktiga filåtergivningsaspekter på lagrade filer som attribut, behörigheter och tidsstämplar. Med Azure-filresurser behöver du inte längre ett program eller en tjänst för att tolka de filer och mappar som lagras i molnet. Du kan komma åt dem inbyggt via välbekanta protokoll och klienter som Windows Utforskaren. Med Azure-filresurser kan du lagra allmänna filserverdata och programdata i molnet. Säkerhetskopiering av en Azure-filresurs är en inbyggd funktion som kan förbättras ytterligare av Azure Backup.

Den här artikeln fokuserar på migreringsstegen. Om du vill veta mer om Azure File Sync innan du migrerar kan du läsa följande artiklar:

Krypteringsnyckel för StorSimple-tjänstdata

När du först konfigurerade StorSimple-installationen genererade den en "krypteringsnyckel för tjänstdata" och instruerade dig att lagra nyckeln på ett säkert sätt. Den här nyckeln används för att kryptera alla data i det associerade Azure-lagringskontot där StorSimple-installationen lagrar dina filer.

"Krypteringsnyckeln för tjänstdata" är nödvändig för en lyckad migrering. Nu är ett bra tillfälle att hämta den här nyckeln från dina poster, en för var och en av apparaterna i inventeringen.

Om du inte hittar nycklarna i dina poster kan du generera en ny nyckel från installationen. Varje installation har en unik krypteringsnyckel.

Ändra krypteringsnyckeln för tjänstdata

Krypterings nycklar för tjänst data används för att kryptera konfidentiella kunddata, t. ex. autentiseringsuppgifter för lagrings konto, som skickas från din StorSimple Manager-tjänst till StorSimple-enheten. Du måste ändra nycklarna regelbundet om din IT-organisation har en nyckel rotations princip på lagrings enheterna. Nyckel ändrings processen kan skilja sig åt beroende på om det finns en enskild enhet eller flera enheter som hanteras av StorSimple Managers tjänsten. Mer information finns på StorSimple Security och Data Protection.

Att ändra krypterings nyckeln för tjänst data är en tre stegs process:

  1. Använd Windows PowerShell-skript för Azure Resource Manager för att auktorisera en enhet för att ändra krypterings nyckeln för tjänst data.
  2. Initiera ändringen av tjänst data krypterings nyckeln med hjälp av Windows PowerShell för StorSimple.
  3. Om du har mer än en StorSimple-enhet uppdaterar du tjänst data krypterings nyckeln på de andra enheterna.

Steg 1: Använd Windows PowerShell-skript för att auktorisera en enhet att ändra krypterings nyckeln för tjänst data

Normalt begär enhets administratören att tjänst administratören ger en enhet behörighet att ändra krypterings nycklar för tjänst data. Tjänst administratören kommer sedan att auktorisera enheten för att ändra nyckeln.

Det här steget utförs med det Azure Resource Manager baserade skriptet. Tjänst administratören kan välja en enhet som är behörig att auktoriseras. Enheten har sedan behörighet att starta ändrings processen för tjänst data krypterings nyckel.

Om du vill ha mer information om hur du använder skriptet går du till Authorize-ServiceEncryptionRollover.ps1

Vilka enheter kan auktoriseras för att ändra krypterings nycklar för tjänst data?

En enhet måste uppfylla följande kriterier innan den kan auktoriseras för att initiera ändringar av tjänst data krypterings nyckel:

  • Enheten måste vara online för att kunna bli berättigad till ändrings behörighet för tjänst data krypterings nyckel.
  • Du kan auktorisera samma enhet igen efter 30 minuter om nyckel ändringen inte har initierats.
  • Du kan auktorisera en annan enhet, förutsatt att nyckel ändringen inte har initierats av den tidigare auktoriserade enheten. När den nya enheten har auktoriserats kan den gamla enheten inte påbörja ändringen.
  • Du kan inte auktorisera en enhet när förnyelsen av tjänst data krypterings nyckeln pågår.
  • Du kan auktorisera en enhet när några av enheterna som är registrerade i tjänsten har registrerats via krypteringen medan andra inte har det.

Steg 2: Använd Windows PowerShell för StorSimple för att initiera ändringen av tjänst data krypterings nyckeln

Det här steget utförs i Windows PowerShell för StorSimple-gränssnittet på den auktoriserade StorSimple-enheten.

Anteckning

Inga åtgärder kan utföras i Azure Portal av din StorSimple Manager-tjänst förrän nyckel förnyelsen har slutförts.

Om du använder enhetens serie konsol för att ansluta till Windows PowerShell-gränssnittet utför du följande steg.

Så här initierar du ändringen av tjänst data krypterings nyckeln

  1. Välj alternativ 1 för att logga in med fullständig åtkomst.

  2. Skriv följande i kommandotolken:

    Invoke-HcsmServiceDataEncryptionKeyChange

  3. När cmdleten har slutförts visas en ny krypterings nyckel för tjänst data. Kopiera och spara nyckeln för användning i steg 3 i den här processen. Den här nyckeln används för att uppdatera alla återstående enheter som är registrerade i StorSimple Manager-tjänsten.

    Anteckning

    Den här processen måste initieras inom fyra timmar med att auktorisera en StorSimple-enhet.

    Den nya nyckeln skickas sedan till tjänsten som ska skickas till alla enheter som är registrerade i tjänsten. En avisering visas sedan på instrument panelen för tjänsten. Tjänsten inaktiverar alla åtgärder på de registrerade enheterna och enhets administratören måste då uppdatera krypterings nyckeln för tjänst data på de andra enheterna. I/o (värdar som skickar data till molnet) avbryts dock inte.

    Om du har en enda enhet som är registrerad för tjänsten slutförs förnyelse processen och du kan hoppa över nästa steg. Om du har flera enheter registrerade för tjänsten går du vidare till steg 3.

Steg 3: uppdatera krypterings nyckeln för tjänst data på andra StorSimple-enheter

De här stegen måste utföras i Windows PowerShell-gränssnittet på din StorSimple-enhet om du har flera enheter registrerade i StorSimple Manager-tjänsten. Den nyckel som du hämtade i steg 2 måste användas för att uppdatera alla återstående StorSimple-enheter som är registrerade i StorSimple Manager-tjänsten.

Utför följande steg för att uppdatera tjänst data krypteringen på enheten.

Så här uppdaterar du krypterings nyckeln för tjänst data på fysiska enheter

  1. Använd Windows PowerShell för StorSimple för att ansluta till-konsolen. Välj alternativ 1 för att logga in med fullständig åtkomst.
  2. Skriv följande i kommando tolken: Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey
  3. Ange krypterings nyckeln för tjänst data som du hämtade i steg 2: använd Windows PowerShell för StorSimple för att initiera ändringen av tjänst data krypterings nyckeln.

Så här uppdaterar du krypterings nyckeln för tjänst data på alla 8010/8020-moln enheter

  1. Hämta och konfigurera Update-CloudApplianceServiceEncryptionKey.ps1 PowerShell-skript.
  2. Öppna PowerShell och skriv följande i kommando tolken: Update-CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device manager]

Det här skriptet ser till att krypterings nyckeln för tjänst data är inställd på alla 8010/8020-moln enheter under enhets hanteraren.

Varning

När du bestämmer hur du ska ansluta till StorSimple-installationen bör du tänka på följande:

  • Att ansluta via en HTTPS-session är det säkraste och rekommenderade alternativet.
  • Det är säkert att ansluta direkt till enhetens seriekonsol, men det är inte säkert att ansluta till seriekonsolen via nätverksväxlar.
  • HTTP-sessionsanslutningar är ett alternativ men krypteras inte. De rekommenderas inte om de inte används i ett stängt, betrott nätverk.

Säkerhetskopior av StorSimple-volymer

StorSimple erbjuder differentiella säkerhetskopior på volymnivå. Azure-filresurser har också den här möjligheten, som kallas resursögonblicksbilder. Dina migreringsjobb kan bara flytta säkerhetskopior, inte data från livevolymen. Den senaste säkerhetskopieringen bör därför alltid finnas med i listan över säkerhetskopior som har flyttats under en migrering.

Bestäm om du behöver flytta äldre säkerhetskopior under migreringen. Bästa praxis är att hålla listan så liten som möjligt, så att migreringsjobben slutförs snabbare.

Om du vill identifiera kritiska säkerhetskopieringar som måste migreras, gör du en checklista över dina säkerhetskopieringsprinciper. Till exempel:

  • Den senaste säkerhetskopian. (Obs! Den senaste säkerhetskopieringen bör alltid ingå i den här listan.)
  • En säkerhetskopia per månad i 12 månader.
  • En säkerhetskopia per år under tre år.

Senare när du skapar migreringsjobb kan du använda den här listan för att identifiera de exakta storSimple-säkerhetskopior som måste migreras för att uppfylla kraven i listan.

Varning

Det finns inte stöd för att välja fler än 50 StorSimple-säkerhetskopieringar. Dina migreringsjobb kan bara flytta säkerhetskopior, aldrig data från den direktsända volymen. Därför är den senaste säkerhetskopieringen närmast livedata och bör därför alltid vara en del av listan över säkerhetskopior som ska flyttas i en migrering.

Mappa dina befintliga StorSimple-volymer till Azure-filresurser

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

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

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

Dela gruppering

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

Volymsynkronisering

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

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

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

Tips

Om du inte vet hur många filer och mappar du har kan du kolla in TreeSize-verktyget 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 Azure File Sync som du ska etablera för synkroniseringsgruppen. En synkroniseringsgrupp kopplar ihop Azure-filresursen och mappen på servern och upprättar en synkroniseringsanslutning.

Om du vill bestämma hur många Azure-filresurser du behöver kan du läsa följande begränsningar och metodtips. Om du gör det kan du optimera kartan.

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

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

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

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

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

Tips

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 gemensam rot påverkar inte åtkomsten till dina data. Dina ACL:er förblir som de är. Du behöver bara justera eventuella resurssökvägar (t.ex. SMB- eller NFS-resurser) som du kan ha på de lokala servermapparna 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. Granska Azure File Sync för mer information.

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

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

Skapa en mappningstabell

Diagram som visar ett exempel på en mappningstabell. Ladda ned följande fil för att uppleva och använda innehållet i den här bilden.

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

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


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

Antal lagringskonton

Migreringen kan förmodligen dra nytta av en distribution av flera lagringskonton som var och en innehåller ett mindre antal Azure-filresurser.

Om dina filresurser är mycket aktiva (används av många användare eller program) kan två Azure-filresurser nå prestandagränsen för ditt lagringskonto. Därför är bästa praxis att migrera till flera lagringskonton, var och en med sina egna enskilda filresurser, och vanligtvis inte mer än två eller tre resurser per lagringskonto.

Ett bra sätt är att distribuera lagringskonton med en filresurs vardera. Du kan samla flera Azure-filresurser i samma lagringskonto om du har arkivresurser i dem.

Dessa överväganden gäller mer för direkt molnåtkomst (via en virtuell Azure-dator eller tjänst) än för Azure File Sync. Om du planerar att uteslutande använda Azure File Sync dessa resurser går det bra att gruppera flera i ett enda Azure Storage-konto. I framtiden kanske du vill lyfta och flytta en app till molnet som sedan skulle ha direkt åtkomst till en filresurs. Det här scenariot skulle ha nytta av högre IOPS och dataflöde. Eller så kan du börja använda en tjänst i Azure som också skulle ha nytta av högre IOPS och dataflöde.

Om du har skapat en lista över dina resurser mappar du varje resurs till lagringskontot där den kommer att finnas.

Viktigt

Bestäm en Azure-region och se till att varje lagringskonto Azure File Sync resurs matchar den region som du har valt. Konfigurera inte nätverks- och brandväggsinställningar för lagringskontona nu. Att göra dessa konfigurationer i det här läget skulle göra migreringen omöjlig. Konfigurera de här Azure Storage-inställningarna när migreringen är klar.

Inställningar för lagringskonto

Det finns många konfigurationer som du kan göra på ett lagringskonto. Följande checklista ska användas för att bekräfta dina konfigurationer för lagringskontot. Du kan till exempel ändra nätverkskonfigurationen när migreringen är klar.

  • Stora filresurser: Aktiverat – Stora filresurser förbättrar prestanda och gör att du kan lagra upp till 100TiB i en resurs. Den här inställningen gäller för mållagringskonton med Azure-filresurser.
  • Brandvägg och virtuella nätverk: Inaktiverat – konfigurera inga IP-begränsningar eller begränsa lagringskontots åtkomst till ett specifikt virtuellt nätverk. Den offentliga slutpunkten för lagringskontot används under migreringen. Alla IP-adresser från virtuella Azure-datorer måste tillåtas. Det är bäst att konfigurera brandväggsregler på lagringskontot efter migreringen. Konfigurera både käll- och mållagringskonton på det här sättet.
  • Privata slutpunkter: Stöds – Du kan aktivera privata slutpunkter men den offentliga slutpunkten används för migreringen och måste vara tillgänglig. Det här gäller både käll- och mållagringskonton.

Sammanfattning av fas 1

I slutet av Fas 1:

  • Du har en bra översikt över dina StorSimple-enheter och volymer.
  • Tjänsten Data Manager är redo att komma åt dina StorSimple-volymer i molnet eftersom du har hämtat din "krypteringsnyckel för tjänstdata" för varje StorSimple-enhet.
  • Du har en plan för vilka volymer och säkerhetskopior (om det finns fler än de senaste) som behöver migreras.
  • Du vet hur du mappar dina volymer till lämpligt antal Azure-filresurser och lagringskonton.

Fas 2: Distribuera Azure-lagrings- och migreringsresurser

I det här avsnittet beskrivs överväganden kring distribution av de olika resurstyper som behövs i Azure. Vissa kommer att innehålla dina data efter migreringen, och vissa behövs endast för migreringen. Börja inte distribuera resurser förrän du har skapat distributionsplanen. Det är svårt, ibland omöjligt, att ändra vissa aspekter av dina Azure-resurser när de har distribuerats.

Distribuera lagringskonton

Du behöver förmodligen distribuera flera Azure Storage-konton. Var och en kommer att innehålla ett mindre antal Azure-filresurser, enligt din distributionsplan, som slutfördes i föregående avsnitt i den här artikeln. Gå till Azure Portal för att distribuera dina planerade lagringskonton. Överväg att följa följande grundläggande inställningar för alla nya lagringskonto.

Viktigt

Konfigurera inte nätverks- och brandväggsinställningar för dina lagringskonton nu. Att göra dessa konfigurationer i det här läget skulle göra en migrering omöjlig. Konfigurera de här Azure Storage-inställningarna när migreringen är klar.

Prenumeration

Du kan använda samma prenumeration som du använde för din StorSimple-distribution eller en annan. Den enda begränsningen är att din prenumeration måste finnas i Azure Active Directory klientorganisation som StorSimple-prenumerationen. Överväg att flytta StorSimple-prenumerationen till rätt klientorganisation innan du startar en migrering. Du kan bara flytta hela prenumerationen. Enskilda StorSimple-resurser kan inte flyttas till en annan klient eller prenumeration.

Resursgrupp

Resursgrupper hjälper till med organisering av resurser och administratörshanteringsbehörigheter. Lär dig mer om resursgrupper i Azure.

Lagringskontonamn

Namnet på ditt lagringskonto blir en del av en URL och har vissa teckenbegränsningar. I namngivningskonventionen bör du tänka på att lagringskontonamn måste vara unika i världen, endast tillåta gemener och siffror, kräva mellan 3 och 24 tecken och inte tillåta specialtecken som bindestreck eller understreck. Mer information finns i Namngivningsregler för Azure Storage-resurser.

Location

Platsen eller Azure-regionen för ett lagringskonto är mycket viktig. Om du Azure File Sync lagringskonton måste alla dina lagringskonton finnas i samma region som resursen för tjänsten för synkronisering av lagring. Den Azure-region som du väljer bör vara nära eller central för dina lokala servrar och användare. När resursen har distribuerats kan du inte ändra dess region.

Du kan välja en annan region än den där dina StorSimple-data (lagringskontot) för närvarande finns.

Viktigt

Om du väljer en annan region än din aktuella lagringsplats för StorSimple-lagringskontot debiteras utgående avgifter under migreringen. Data lämnar StorSimple-regionen och anger din nya lagringskontoregion. Inga bandbreddsavgifter tillkommer om du stannar i samma Azure-region.

Prestanda

Du kan välja Premium Storage (SSD) för Azure-filresurser eller standardlagring. Standard Storage innehåller flera nivåer för en filresurs. Standard Storage är rätt alternativ för de flesta kunder som migrerar från StorSimple.

Är du fortfarande osäker?

  • Välj Premium Storage om du behöver prestanda för en Premium Azure-filresurs.
  • Välj standardlagring för allmänna filserverarbetsbelastningar, som innehåller heta data och arkivdata. Välj även standardlagring om den enda arbetsbelastningen på resursen i molnet ska Azure File Sync.

Typ av konto

  • För standardlagring väljer du StorageV2 (generell användning v2).
  • För premiumfilresurser väljer du ArkivLagring.

Replikering

Det finns flera tillgängliga replikeringsinställningar. Läs mer om de olika replikeringstyperna.

Välj bara något av följande två alternativ:

  • Lokalt redundant lagring (LRS).
  • Zonredundant lagring (ZRS), som inte är tillgängligt i alla Azure-regioner.

Anteckning

Endast redundanstyperna LRS och ZRS är kompatibla med de stora Azure-filresurser på 100 TiB-kapacitet.

Geo-redundant lagring (GRS) i alla varianter stöds inte för närvarande. Du kan byta redundanstyp senare och växla till GRS när support för den kommer till Azure.

Aktivera filresurser med 100 TiB-kapacitet

En bild som visar fliken Avancerat i Azure Portal för att skapa ett lagringskonto.

Under avsnittet Avancerat i guiden nytt lagringskonto i Azure Portal kan du aktivera stöd för stora filresurser i det här lagringskontot. Om det här alternativet inte är tillgängligt för dig har du förmodligen valt fel redundanstyp. Se till att du bara väljer LRS eller ZRS för att det här alternativet ska bli tillgängligt.

Att välja stora filresurser med 100 TiB-kapacitet har flera fördelar:

  • Prestandan ökar avsevärt jämfört med de mindre filresurser på 5 TiB-kapacitet (till exempel 10 gånger IOPS).
  • Migreringen slutförs betydligt snabbare.
  • Du ser till att en filresurs har tillräckligt med kapacitet för att lagra alla data som du migrerar till den, inklusive de differentiella säkerhetskopieringar av lagringskapacitet som krävs.
  • Framtida tillväxt omfattas.

Viktigt

Använd inte särskilda nätverk för ditt lagringskonto före eller under migreringen. Den offentliga slutpunkten måste vara tillgänglig på käll- och mållagringskonton. Ingen begränsning till specifika IP-intervall eller virtuella nätverk stöds. Du kan ändra nätverkskonfigurationerna för lagringskontot efter migreringen.

Azure-filresurser

När dina lagringskonton har skapats går du till avsnittet Filresurs i lagringskontot och distribuerar lämpligt antal Azure-filresurser enligt migreringsplanen från Fas 1. Överväg att följa följande grundläggande inställningar för dina nya filresurser i Azure.

En Azure Portal skärmbild som visar det nya användargränssnittet för filresursen.


Namn
Gemener, siffror och bindestreck stöds.

Kvoten
Kvoten här är jämförbar med en hård SMB-kvot på en Windows Server-instans. Det bästa sättet är att inte ange en kvot här eftersom migreringen och andra tjänster misslyckas när kvoten har nåtts.

Nivåer
Välj Transaktionsoptimerad för den nya filresursen. Under migreringen sker många transaktioner. Det är mer kostnadseffektivt att ändra din nivå senare till den nivå som passar bäst för din arbetsbelastning.

StorSimple Data Manager

Den Azure-resurs som ska innehålla dina migreringsjobb kallas för en StorSimple Data Manager. Välj Ny resurs och sök efter den. Välj sedan Skapa.

Den här tillfälliga resursen används för orkestrering. Du avetablerar den när migreringen är klar. Den bör distribueras i samma prenumeration, resursgrupp och region som ditt StorSimple-lagringskonto.

Azure File Sync

Med Azure File Sync kan du lägga till lokal cachelagring av de mest använda filerna. Precis som cachelagringsförmågor i StorSimple erbjuder Azure File Sync-molnnivåindelad funktion svarstid för lokal åtkomst i kombination med bättre kontroll över den tillgängliga cachekapaciteten på Windows Server-instansen och synkronisering av flera webbplatser. Om du har ett lokalt cacheminne är ditt mål ska du i ditt lokala nätverk förbereda en virtuell Windows Server-dator (fysiska servrar och redundanskluster stöds också) med tillräcklig direktkopplad lagringskapacitet.

Viktigt

Konfigurera inte Azure File Sync ännu. Det är bäst att konfigurera Azure File Sync när migreringen av resursen har slutförts. Distribution Azure File Sync bör inte starta före fas 4 av en migrering.

Sammanfattning av fas 2

I slutet av Fas 2 har du distribuerat dina lagringskonton och alla Azure-filresurser på dem. Du har också en StorSimple Data Manager resurs. Du använder det senare i Fas 3 när du konfigurerar migreringsjobben.

Fas 3: Skapa och köra ett migreringsjobb

I det här avsnittet beskrivs hur du ställer in ett migreringsjobb och mappar noggrant katalogerna på en StorSimple-volym som ska kopieras till den Azure-målfilresurs som du väljer. Kom igång genom att gå till StorSimple Data Manager, hitta jobbdefinitioner på menyn och välja + Jobbdefinition. Rätt mållagringstyp är standard: Azure-filresurs.

Migreringsjobbtyper i StorSimple 8000-serien.

Migreringsjobb i StorSimple 8000-serien.

Jobbdefinitionsnamn
Det här namnet bör ange den uppsättning filer som du flyttar. Det är en bra idé att ge den ett liknande namn som din Azure-filresurs.

Plats där jobbet körs
När du väljer en region måste du välja samma region som ditt StorSimple-lagringskonto eller, om det inte är tillgängligt, en region nära det.

Källa

Källprenumeration
Välj den prenumeration där du lagrar storsimple-Enhetshanteraren resursen.

StorSimple-resurs
Välj din StorSimple Enhetshanteraren som din enhet är registrerad med.

Krypteringsnyckel för tjänstdata
Kontrollera föregående avsnitt i den här artikeln om du inte kan hitta nyckeln i dina poster.

Enhet
Välj den StorSimple-enhet som innehåller den volym där du vill migrera.

Volym
Välj källvolymen. Senare bestämmer du om du vill migrera hela volymen eller underkatalogerna till Azure-målfilresursen.

Volymsäkerhetskopior
Du kan välja Välj volymsäkerhetskopior för att välja specifika säkerhetskopieringar som ska flyttas som en del av det här jobbet. Ett kommande, dedikerat avsnitt i den här artikeln beskriver processen i detalj.

Mål

Välj prenumeration, lagringskonto och Azure-filresurs som mål för migreringsjobbet.

Katalogmappning

I ett dedikerat avsnitt iden här artikeln beskrivs all relevant information.

Välja vilka volymsäkerhetskopior som ska migreras

Det finns viktiga aspekter när det gäller att välja säkerhetskopior som behöver migreras:

  • Dina migreringsjobb kan bara flytta säkerhetskopior, inte data från en live-volym. Den senaste säkerhetskopieringen ligger därför närmast livedata och bör alltid finnas med i listan över säkerhetskopior som flyttas i en migrering.
  • Kontrollera att den senaste säkerhetskopieringen är ny för att hålla delta till liveresursen så liten som möjligt. Det kan vara värt att manuellt utlösa och slutföra en annan volymsäkerhetskopiering innan du skapar ett migreringsjobb. En liten delta till live-resursen förbättrar migreringen. Om den här deltan kan vara noll = inga fler ändringar av StorSimple-volymen gjordes efter att den senaste säkerhetskopian togs i listan – så förenklas och påskyndas användarskärningen avsevärt.
  • Säkerhetskopior måste spelas upp till Azure-filresursen från den äldsta till den senaste. En äldre säkerhetskopia kan inte "sorteras till" listan över säkerhetskopior på Azure-filresursen när ett migreringsjobb har körts. Därför måste du se till att listan över säkerhetskopior är klar innan du skapar ett jobb.
  • Den här listan över säkerhetskopior i ett jobb kan inte ändras när jobbet har skapats – även om jobbet aldrig har körts.

Om du vill välja säkerhetskopior av din StorSimple-volym för migreringsjobbet väljer du välj Välj volymsäkerhetskopior i formuläret för jobbskapande.

När bladet för val av säkerhetskopiering öppnas är det indelade i två listor. I den första listan visas alla tillgängliga säkerhetskopior. Du kan expandera och begränsa resultatuppsättningen genom att filtrera efter ett specifikt tidsperiod. (se nästa avsnitt)

En vald säkerhetskopia visas som nedtonad och läggs till i en andra lista på den nedre halvan av bladet. Den andra listan visar alla säkerhetskopior som valts för migrering. En säkerhetskopia som valts i fel kan också tas bort igen.

Varning

Du måste välja alla säkerhetskopior som du vill migrera. Du kan inte lägga till äldre säkerhetskopior senare. Du kan inte ändra jobbet för att ändra ditt val när jobbet har skapats.

Som standard filtreras listan för att visa StorSimple-volymsäkerhetskopior under de senaste sju dagarna för att göra det enkelt att välja den senaste säkerhetskopian. Använd filtret för tidsintervall längst upp på bladet för säkerhetskopieringar som ligger längre fram i tiden. Du kan antingen välja från ett befintligt filter eller ange ett anpassat tidsintervall för att endast filtrera fram säkerhetskopior som har tagits under den här perioden.

Varning

Det finns inte stöd för att välja fler än 50 StorSimple-säkerhetskopieringar. Jobb med ett stort antal säkerhetskopieringar kan misslyckas.

Katalogmappning

Katalogmappning är valfritt för migreringsjobbet. Om du lämnar avsnittet tomt flyttas alla filer och mappar i roten på StorSimple-volymen till roten för Azure-målfilresursen. I de flesta fall är det inte den bästa metoden att lagra en hel volyms innehåll i en Azure-filresurs. Det är ofta bättre att dela upp en volyms innehåll över flera filresurser i Azure. Om du inte redan har gjort en plan kan du börja med att mappa din StorSimple-volym till Azure-filresurser.

Som en del av din migreringsplan har du kanske bestämt att mapparna på en StorSimple-volym måste delas upp över flera Azure-filresurser. Om så är fallet kan du utföra delningen genom att:

  1. Definiera flera jobb för att migrera mapparna på en volym. Var och en har samma StorSimple-volymkälla men en annan Azure-filresurs som målet.
  2. Ange exakt vilka mappar från StorSimple-volymen som måste migreras till den angivna filresursen med hjälp av avsnittet Katalogmappning i formuläret för jobbskapande och efter den specifika mappningssemantiken .

Viktigt

Sökvägarna och mappningsuttrycken i det här formuläret kan inte verifieras när formuläret skickas. Om mappningar anges felaktigt kan ett jobb antingen misslyckas helt eller ge ett oönskat resultat. I så fall är det vanligtvis bäst att ta bort Azure-filresursen, skapa den på nytt och sedan åtgärda mappningsutsatserna i ett nytt migreringsjobb för resursen. Om du kör ett nytt jobb med fasta mappningsutdrag kan du åtgärda utelämnade mappar och ta dem till den befintliga resursen. Det är dock bara mappar som utelämnats på grund av felstavade sökvägar som kan åtgärdas på det här sättet.

Semantiska element

En mappning uttrycks från vänster till höger: [\källsökväg] > [\målsökväg].

Semantiktecken Innebörd
\ Rotnivåindikator.
> [Källa] och [målmappning]-operatorn.
| eller RETUR (ny rad) Avgränsare för två mappningsinstruktioner.
Du kan också utelämna det här tecknet och välja Retur för att hämta nästa mappningsuttryck på en egen rad.

Exempel

Flyttar innehållet i mappen Användardata till roten på målfilresursen:

\User data > \

Flyttar hela volyminnehållet till en ny sökväg på målfilresursen:

\ > \Apps\HR tracker

Flyttar källmappens innehåll till en ny sökväg på målfilresursen:

\HR resumes-Backup > \Backups\HR\resumes

Sorterar flera källplatser i en ny katalogstruktur:

\HR\Candidate Tracker\v1.0 > \Apps\Candidate tracker
\HR\Candidates\Resumes > \HR\Candidates\New
\Archive\HR\Old Resumes > \HR\Candidates\Archived

Semantiska regler

  • Ange alltid mappsökvägar i förhållande till rotnivån.
  • Börja varje mappsökväg med en rotnivåindikator " \ ".
  • Inkludera inte enhetsbeteckningar.
  • När du anger flera sökvägar kan käll- eller målsökvägar inte överlappa:
    Exempel på ogiltig källsökväg överlappar:
    \folder\1 \ > mapp
    \mapp \ 1 \ 2 > \ folder2
    Exempel på ogiltig målsökväg överlappar:
    \mapp > \
    \folder2 > \
  • Källmappar som inte finns ignoreras.
  • Mappstrukturer som inte finns på målet skapas.
  • Precis som i Windows är mappnamn okänsliga men inte fallbevarande.

Anteckning

Innehållet i mappen \System Volume Information och $Recycle.Bin på storSimple-volymen kopieras inte av migreringsjobbet.

Köra ett migreringsjobb

Migreringsjobben visas under Jobbdefinitioner i Data Manager resurs som du har distribuerat till en resursgrupp. Välj det jobb som du vill köra i listan med jobbdefinitioner.

På jobbbladet som öppnas kan du se att jobbet körs i den nedre listan. Den här listan är tom från början. Längst upp på bladet finns ett kommando som heter Kör jobb. Det här kommandot kör inte jobbet direkt, utan öppnar bladet Jobbkörning:

I den här versionen måste varje jobb köras flera gånger.

Du måste börja med den äldsta säkerhetskopian från listan över säkerhetskopior som du vill migrera. (markerat i bilden)

Du kör jobbet igen, så många gånger som du har valt säkerhetskopior, varje gång mot en progressivt nyare säkerhetskopia.

Varning

Det är mycket viktigt att du kör migreringsjobbet med den äldsta säkerhetskopian vald först och sedan igen, varje gång med en progressivt nyare säkerhetskopia. Du måste alltid upprätthålla ordningen på dina säkerhetskopior manuellt – från äldsta till nyaste.

Köra jobb parallellt

Du kommer troligen att ha flera StorSimple-platser som var och en måste kopieras till en annan Azure-filresurs. För en enda StorSimple-installation kan du köra upp till fyra migreringsjobb parallellt om de är mål för var och en av en annan Azure-filresurs.

Varje jobb går igenom flera faser. Det går bara att starta ett annat jobb när det tidigare jobbet har gått in i filkopieringsfasen. Normalt inom 25 till 35 minuter efter att jobbet startades kan ett annat jobb startas, upp till fyra parallellt. Jobb som riktar in sig på samma filresurs (för efterföljande säkerhetskopieringar) måste kopieras en säkerhetskopia efter den andra.

Varning

Starta bara ett migreringsjobb i taget för data som går till samma Azure-filresurs.

Tolka loggfilerna

Ett slutfört migreringsjobb visar en länk till kopieringsloggarna. Dessa loggar är * .csv-filer som visar att namnområdesobjekten lyckades och objekt som inte kunde kopieras.

När du har åtkomst till platsen för loggfilerna kan du hitta loggarna för misslyckade filer genom att filtrera listan med söktermen "failed". Resultatet blir en uppsättning loggar för filer som inte kunde kopieras. Sortera dem sedan efter storlek. Det kan finnas extra loggar som skapas med en storlek på 17 byte. De är tomma och kan ignoreras. Med en sortering kan du enkelt fokusera på loggarna med innehåll.

Samma process gäller för loggfiler som registrerar lyckade kopior.

Sammanfattning av fas 3

I slutet av Fas 3 har du kört minst ett av dina migreringsjobb från StorSimple-volymer till Azure-filresurs(er). Du kommer att ha kört samma migreringsjobb flera gånger, från äldsta till nyaste säkerhetskopior som måste migreras. Nu kan du fokusera på att antingen konfigurera Azure File Sync för resursen (när migreringsjobben för en resurs har slutförts) eller att dirigera resursåtkomst för dina informationsarbetare och appar till Azure-filresursen.

Fas 4: Få åtkomst till dina Azure-filresurser

Det finns två huvudsakliga strategier för att komma åt dina Azure-filresurser:

  • Azure File Sync: Azure File Sync till en lokal Windows Server-instans. Azure File Sync har alla fördelar med en lokal cache, precis som StorSimple.
  • Direct-share-access: Distribuera direct-share-access. Använd den här strategin om ditt åtkomstscenario för en viss Azure-filresurs inte drar nytta av lokal cachelagring, eller om du inte längre har möjlighet att vara värd för en lokal Windows Server-instans. Här fortsätter dina användare och appar att komma åt SMB-resurser via SMB-protokollet. Dessa resurser finns inte längre på en lokal server utan direkt i molnet.

Du bör redan ha bestämt vilket alternativ som passar bäst för dig i Fas 1 i den här guiden.

Resten av det här avsnittet fokuserar på distributionsinstruktioner.

Distribuera Azure File Sync

Det är dags att distribuera en del av Azure File Sync.

  1. Skapa Azure File Sync molnresursen.
  2. Distribuera Azure File Sync-agenten på den lokala servern.
  3. Registrera servern med molnresursen.

Skapa inte några synkroniseringsgrupper ännu. Synkronisering med en Azure-filresurs bör endast konfigureras när migreringsjobben till en Azure-filresurs har slutförts. Om du började använda Azure File Sync innan migreringen slutfördes skulle det göra migreringen onödigt svår eftersom du inte enkelt kunde se när det var dags att påbörja en nedskärning.

Distribuera Azure File Sync molnresurs

För att slutföra det här steget behöver du autentiseringsuppgifterna för din Azure-prenumeration.

Kärnresursen som ska konfigureras för Azure File Sync kallas för en tjänst för synkronisering av lagring. Vi rekommenderar att du endast distribuerar en för alla servrar som synkroniserar samma uppsättning filer nu eller i framtiden. Skapa endast flera tjänster för synkronisering av lagring om du har olika 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 bästa praxis att använda en enda tjänst för synkronisering av lagring.

Välj en Azure-region för din tjänst för synkronisering av lagring som ligger 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 att distribuera tjänsten för synkronisering av lagring i artikeln om att distribuera 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.

Tips

Om du vill ändra den Azure-region som dina data finns i när migreringen är klar distribuerar du tjänsten för synkronisering av lagring i samma region som mållagringskontona för migreringen.

Distribuera en lokal Windows Server-instans

  • Skapa Windows Server 2019 (minst 2012R2) som en virtuell dator eller fysisk server. Ett Windows Server-redundanskluster stöds också. Återanvänd inte servern som använder StorSimple 8100 eller 8600.
  • Etablera eller lägga till direktkopplad lagring. Nätverkskopplad lagring stöds inte.

Det är bästa praxis att ge den nya Windows Server-instansen en lika stor eller större mängd lagringsutrymme än storSimple 8100- eller 8600-installationen har lokalt tillgänglig för cachelagring. Du använder Windows Server-instansen på samma sätt som du använde StorSimple-installationen. Om den har samma mängd lagringsutrymme som installationen bör cachelagringen vara liknande, om inte samma. Du kan lägga till eller ta bort lagring från din Windows Server-instans när du vill. Med den här funktionen kan du skala din lokala volymstorlek och mängden lokal lagring som är tillgänglig för cachelagring.

Förbereda Windows Server-instansen för filsynkronisering

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

I distributionsguiden förklaras att du måste inaktivera Internet Explorer Förbättrad säkerhetskonfiguration. 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 de PowerShell-moduler som krävs 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 en proxyserver för att nå Internet. Du kan antingen konfigurera en proxy för hela datorn nu eller, under agentinstallationen, ange en proxyserver som 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 nätverksanslutningsrapport de exakta slutpunkts-URL:erna 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 försiktig metod där du inte öppnar brandväggarna på bred plats. Du kan i stället begränsa servern för att kommunicera med DNS-namnrymder på högre nivå. Mer information finns i Azure File Sync proxy- och brandväggsinställningar. Följ dina egna nätverksmetoder.

I slutet av serverinstallationsguiden öppnas en guide för serverregistrering. Registrera servern till Azure-resursen för lagringssynkroniseringstjänsten från tidigare.

De här stegen beskrivs i detalj i distributionsguiden, som innehåller de PowerShell-moduler som du ska installera först: Azure File Sync agentinstallation .

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 resursen Storage Sync Service i Azure Portal. I den vänstra menyn går du till Registrerade servrar. Servern visas där.

Konfigurera Azure File Sync på Windows Server-instansen

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

Viktigt

StorSimple-migreringen av filer och mappar till Azure-filresursen måste slutföras innan du fortsätter. Kontrollera att inga fler ändringar har gjorts i filresursen.

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

  1. Logga in på Azure-portalen.
  2. Leta upp resursen för tjänsten för synkronisering av lagring.
  3. Skapa en ny synkroniseringsgrupp i resursen Storage Sync Service för varje Azure-filresurs. I Azure File Sync terminologin blir Azure-filresursen en molnslutpunkt i den synkroniseringstopologi som du beskriver när du skapar en synkroniseringsgrupp. När du skapar synkroniseringsgruppen ger du den ett bekant namn så att du kan identifiera vilken uppsättning filer som synkroniseras där. Se till 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 servern som du har etablerat blir sökvägen till serverslutpunkten.

Viktigt

Se till att aktivera molnnivåindelad lagring. Molnnivåindelad Azure File Sync som gör det möjligt för den lokala servern att ha mindre lagringskapacitet än vad som lagras i molnet, men ändå har det fullständiga namnområdet tillgängligt. Lokalt intressanta data cachelagras också lokalt för snabb, lokal åtkomstprestanda. Ett annat skäl till att aktivera molnnivåindelning i det här steget är att vi inte vill synkronisera filinnehåll i det här skedet. Endast namnområdet bör flyttas just nu.

Distribuera direct-share-access

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 vissa ämnen:

Sammanfattning av fas 4

I den här fasen har du skapat och kört flera migreringsjobb i din StorSimple Data Manager. Dessa jobb har migrerat dina filer och mappar till Azure-filresurser. Du har också distribuerat Azure File Sync eller förberett dina nätverks- och lagringskonton för direkt resursåtkomst.

Fas 5: Användarförseningen

Den här fasen handlar om att omsluta migreringen:

  • Planera din stilleståndstid.
  • Kom ikapp med eventuella ändringar som dina användare och appar skapade på StorSimple-sidan medan migreringsjobben i Fas 3 har körts.
  • Växla över dina användare till den nya Windows Server-instansen med Azure File Sync eller Azure-filresurser via direkt resursåtkomst.

Planera din stilleståndstid

Den här migreringsstrategin kräver viss stilleståndstid för dina användare och appar. Målet är att hålla nedtiden till ett minimum. Följande överväganden kan vara till hjälp:

  • Håll dina StorSimple-volymer tillgängliga medan du kör migreringsjobben.
  • När du har kört datamigreringsjobben för en resurs är det dags att ta bort användaråtkomst (minst skrivåtkomst) från StorSimple-volymerna eller -resurser. En slutlig RoboCopy kommer ikapp din Azure-filresurs. Sedan kan du klippa ut dina användare. Var du kör RoboCopy beror på om du valde att Azure File Sync eller direkt resursåtkomst. I det kommande avsnittet om RoboCopy tar vi upp det ämnet.
  • När du har slutfört RoboCopy-komma ikapp är du redo att exponera den nya platsen för användarna antingen via Azure-filresursen direkt eller en SMB-resurs på en Windows Server-instans med Azure File Sync. Ofta hjälper en DFS-N-distribution till att snabbt och effektivt utföra en snabb och effektiv genomskärning. Det gör dina befintliga resursadresser konsekventa och ger en ny plats som innehåller dina migrerade filer och mappar.

Avgöra när namnområdet har synkroniserats helt till servern

När du Azure File Sync för en Azure-filresurs är det viktigt att du ser att hela namnområdet har laddats ned till servern innan du startar någon lokal RoboCopy. Hur lång tid det tar att ladda ned namnområdet beror på antalet objekt i Azure-filresursen. Det finns två metoder för att avgöra om namnområdet har anlänt helt till servern.

Azure Portal

Du kan använda Azure Portal för att se när namnområdet har anlänt helt.

  • Logga in på Azure Portal och gå till synkroniseringsgruppen. Kontrollera synkroniseringsstatusen för synkroniseringsgruppen och serverslutpunkten.
  • Den intressanta riktningen är att ladda ned. Om serverslutpunkten nyligen har etablerats visas Inledande synkronisering, vilket indikerar att namnområdet fortfarande är i drift. När tillståndet har ändras till allt utom Inledande synkronisering är namnområdet helt ifylld på servern. Du kan nu fortsätta med en lokal RoboCopy.

Windows Server-Loggboken

Du kan också använda Loggboken på Din Windows Server-instans för att se när namnområdet har anlänt helt.

  1. Öppna Loggboken och gå till Program och tjänster.
  2. Gå till och öppna Microsoft\FileSync\Agent\Telemetry.
  3. Leta efter den senaste händelsen 9102, som motsvarar en slutförd synkroniseringssession.
  4. Välj Information och bekräfta att du tittar på en händelse där SyncDirection-värdet är Ladda ned.
  5. För den tid då namnområdet har laddats ned till servern, kommer det att finnas en enda händelse med Scenario, värdet FullGhostedSync och HResult = 0.
  6. Om du missar den händelsen kan du även leta efter andra 9102-händelser med SyncDirection = Download och = scenariot "RegularSync". Att hitta en av dessa händelser indikerar också att namnområdet har laddats ned och synkroniserats till vanliga synkroniseringssessioner, oavsett om det finns något att synkronisera eller inte just nu.

En slutlig RoboCopy

I det här läget finns det skillnader mellan din lokala Windows Server-instans och StorSimple 8100- eller 8600-installationen.

  1. Du måste komma ikapp med de ändringar som användare eller appar skapade på StorSimple-sidan medan migreringen pågick.
  2. För fall där du använder Azure File Sync: StorSimple-installationen har en ifylld cache jämfört med Windows Server-instansen med bara ett namnområde utan något filinnehåll som lagras lokalt just nu. Den slutliga RoboCopy kan hjälpa dig att komma igång med din lokala Azure File Sync-cache genom att hämta lokalt cachelagrat filinnehåll så mycket som är tillgängligt och får plats på Azure File Sync servern.
  3. Vissa filer kan ha lämnats kvar av migreringsjobbet på grund av ogiltiga tecken. I så fall kopierar du dem till den Azure File Sync Windows Server-instansen. Senare kan du justera dem så att de synkroniseras. Om du inte använder Azure File Sync för en viss resurs är det bättre att byta namn på filerna med ogiltiga tecken på StorSimple-volymen. Kör sedan RoboCopy direkt mot Azure-filresursen.

Varning

Robocopy i Windows Server 2019 har för närvarande ett problem som gör att filer som nivåindelats av Azure File Sync på målservern kopieras igen från källan och laddas upp igen till Azure när du använder robocopy-funktionen /POSI. Det är mycket viktigt att du använder Robocopy på en annan Windows Server än 2019. Ett föredraget alternativ är Windows Server 2016. Den här anteckningen uppdateras om problemet löses via Windows Update.

Varning

Du får inte starta RoboCopy innan servern har namnområdet för en Azure-filresurs helt nedladdad. Mer information finns i Avgöra när namnområdet har laddats ned helt till servern.

Du vill bara kopiera filer som har ändrats efter att migreringsjobbet kördes senast och filer som inte har flyttats genom de här jobben tidigare. Du kan lösa problemet med varför de inte har flyttats senare på servern när migreringen är klar. Mer information finns i Azure File Sync felsökning.

RoboCopy har flera parametrar. I följande exempel visas ett färdigt kommando och en lista över orsaker till att välja dessa parametrar.

Robocopy /MT:32 /R:5 /W:5 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path> 
Switch Innebörd
/MT:n Tillåter att Robocopy kör flertrådade. Standardvärdet n för är 8. Maxvärdet är 128 trådar. Börja med ett högt trådantal för en inledande körning. Ett högt trådantal hjälper till att mätta den tillgängliga bandbredden. Efterföljande /MIR körningar påverkas progressivt när du bearbetar objekt via nätverkstransport. För efterföljande körningar matchar du värdet för antalet trådar med 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 ha.
/R:n Maximalt antal återförsök för en fil som inte kan kopieras vid det första försöket. Du kan förbättra hastigheten för en Robocopy-körning genom att ange ett högsta antal återförsök innan filen permanent misslyckas med att n kopieras under körningen. Den här växeln fungerar när det redan är klart att det kommer att finnas fler Robocopy-körningar. Om filen inte kan kopieras i den aktuella körningen försöker nästa Robocopy-jobb igen. Filer som misslyckades på grund av att de används eller på grund av timeout-problem kan så småningom kopieras om du använder den här metoden.
/W:n Anger den tid som Robocopy väntar innan du försöker kopiera en fil som inte kopierades under ett tidigare försök. n är antalet sekunder som ska vänta mellan återförsöken. /W:n används ofta tillsammans med /R:n .
/B Kör Robocopy i samma läge som ett säkerhetskopieringsprogram använder. Med den här växeln kan Robocopy flytta filer som den aktuella användaren inte har behörighet för.
/MIR (Spegla källa till mål.) Tillåter att Robocopy endast kopierar 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 tas bort från målet. När du använder den här växeln matchar du käll- och målmappsstrukturerna exakt. Matchning innebär att kopiera från rätt käll- och mappnivå till matchande mappnivå på målet. Endast då kan en "komma ifatt"-kopia lyckas. När källan och målet är felmatchade leder /MIR användningen till storskaliga borttagningar och omkopieringar.
/IT Säkerställer att återgivning bevaras i vissa speglingsscenarier.
Om en fil till exempel har 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] Filkopian är återgivning. Standard: /COPY:DAT. Kopiera flaggor: D = Data, A = Attribut, = T Tidsstämplar, S = Säkerhet = NTFS ACL:er, O = U Ägarinformation, = Enuditing-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 ska visas. Om du visar förloppet sänks kopieringsprestandan avsevärt.
/NFL Anger att filnamn inte ska loggas. Förbättrar kopieringsprestanda.
/NDL Anger att katalognamn inte ska loggas. Förbättrar kopieringsprestanda.
/UNILOG:<file name> Skriver status till loggfilen som Unicode. (Skriver över den befintliga loggen.)
/LFSM Endast för mål med nivåindelad lagring
Anger att Robocopy fungerar i läget för "lite 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 är klar. Det har lagts till specifikt för användning med ett mål aktiverat för Azure File Sync för molnnivåindelad. Den kan användas oberoende av Azure File Sync. I det här läget pausar Robocopy när en filkopia gör att målvolymens lediga utrymme går under ett "golv"-värde. Det här värdet kan anges i /LFSM:n form av flaggan . Parametern n anges i base 2: , eller nKB nMB nGB . Om /LFSM anges utan något explicit golvvärde anges ordet till 10 procent av målvolymens storlek. Läget för lite ledigt utrymme är inte kompatibelt med /MT , /EFSRAW , eller /B /ZB .
/Z Använd försiktig
Kopierar filer i omstartsläge. Den här växeln rekommenderas endast i en instabil nätverksmiljö. Det minskar kopieringsprestanda avsevärt på grund av extra loggning.
/ZB Använd försiktig
Använder omstartsläge. Om åtkomst nekas använder det här alternativet säkerhetskopieringsläge. Det här alternativet minskar kopieringsprestandan avsevärt på grund av kontrollpunkter.

När du konfigurerar käll- och målplatser för RoboCopy-kommandot ska du granska käll- och målstrukturen för att säkerställa att de matchar. Om du använde katalogmappningsfunktionen i migreringsjobbet kan rotkatalogstrukturen vara annorlunda än strukturen för storSimple-volymen. Om så är fallet kan du behöva flera RoboCopy-jobb, ett för varje underkatalog. Om du är osäker på om kommandot kommer att fungera som förväntat kan du använda parametern /L, som simulerar kommandot utan att faktiskt göra några ändringar.

Det här RoboCopy-kommandot använder /ROB, så det flyttar inte filer som är samma (till exempel nivåindelade filer). Men om du får fel käll- och målsökväg rensar /LTE även katalogstrukturer på din Windows Server-instans eller Azure-filresurs som inte finns på StorSimple-källsökvägen. De måste matcha exakt för Att RoboCopy-jobbet ska nå sitt avsedda mål att uppdatera det migrerade innehållet med de senaste ändringarna som gjorts medan migreringen pågår.

Titta i RoboCopy-loggfilen för att se om filerna har lämnats kvar. Om det finns problem åtgärdar du dem och kör RoboCopy-kommandot igen. Avetablera inte några StorSimple-resurser innan du åtgärdar utestående problem för filer eller mappar som är viktiga för dig.

Om du inte använder Azure File Sync för att cachelagra den aktuella Azure-filresursen utan i stället väljer direkt resursåtkomst:

  1. Montera din Azure-filresurs som en nätverksenhet på en lokal Windows-dator.
  2. Utför RoboCopy mellan StorSimple och den monterade Azure-filresursen. Om filerna inte kopieras kan du korrigera deras namn på StorSimple-sidan för att ta bort ogiltiga tecken. Försök sedan igen med RoboCopy. Det tidigare listade RoboCopy-kommandot kan köras flera gånger utan att orsaka onödig återkallelse till StorSimple.

Felsöka och optimera

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

  • IOPS på käll- och mållagring
  • 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

Överväganden för IOPS och bandbredd

I den här kategorin måste du tänka på funktioner för källlagring, mållagring 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 till de bästa kapaciteterna.

Varning

Kopiering så snabbt som möjligt är ofta det mest åtråvärda, men överväg användningen av ditt lokala nätverk och NAS-enheten för andra, ofta affärskritiska uppgifter.

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

  • Överväg när det är bäst i din miljö att köra migreringar: under dagen, utanför arbetstid eller under helger.
  • Överväg även att använda QoS för nätverk på en Windows Server för att begränsa RoboCopy-hastigheten.
  • Undvik onödigt arbete för migreringsverktygen.

RobCopy kan infoga fördröjningar mellan paket genom att ange växeln där /IPG:n n mäts i millisekunder mellan RoboCopy-paket. Om du använder den här växeln kan du undvika att resurser monopoleras på både I/O-begränsade enheter och nätverkslänkar.

/IPG:n kan inte användas för exakt nätverksbegränsning till en viss Mbit/s. Använd Windows Server-nätverkets QoS i stället. RoboCopy förlitar sig helt på SMB-protokollet för alla nätverksbehov. Att använda SMB är orsaken 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 kontrollera belastningen på NAS. Testa flera värden, till exempel från cirka 20 millisekunder (n = 20) till multiplar av det talet. När du har introducerat 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 den pekar på och utvärderar varje fil och mapp för kopiering. Varje fil utvärderas under en inledande kopia och under komma ifatt-kopior. Till exempel upprepade körningar av RoboCopy /ROB 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 övergripande lyckade frekvensen för filer som migreras.

Som standard överväger vi ofta 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 för att kopiera ännu mer för större namnrymder med mindre filer. Tänk på att det tar betydligt längre tid att kopiera 1 TiB små filer än att kopiera 1 TiB med färre men större filer. Förutsatt att alla andra variabler förblir desamma.

Orsaken till den här skillnaden är den bearbetningskraft som krävs för att gå igenom ett namnområde. RoboCopy stöder flertrådiga kopior via /MT:n parametern där n står för antalet processortrådar. Så 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. Antalet kärnor och trådar för en dator är en viktig datapunkt för att bestämma vilka flertrådsvärden /MT:n du ska ange. Fundera också över hur många RoboCopy-jobb du planerar att köra parallellt på en viss dator.

Fler trådar kopierar vårt 1-TiB-exempel med små filer betydligt snabbare än färre trådar. Samtidigt ger den extra resursinvesteringen på våra 1 TiB större filer kanske inte proportionella fördelar. Ett högt trådantal 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 är du förmodligen begränsad av nätverkets dataflöde. Börja med ett högt trådantal för en inledande körning. Ett högt trådantal, även utanför de trådar som för närvarande är tillgängliga på datorn, hjälper till att utmäta den tillgängliga nätverksbandbredden. Efterföljande /RUNS-körningar påverkas progressivt av bearbetningsobjekt. Färre ändringar i en differentiell körning innebär mindre transport av data över nätverket. Hastigheten är nu mer beroende av din möjlighet att bearbeta namnområdesobjekt än att flytta dem via nätverkslänken. För efterföljande körningar matchar du värdet för antalet trådar med antalet processorkärnor och antalet trådar per kärna. Överväg om kärnor behöver reserveras för andra uppgifter som en produktionsserver kan ha.

Undvik onödigt arbete

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

  • utökad RoboCopy-jobbkörning eftersom varje fil och mapp som påverkas av en ACL-ändring måste uppdateras
  • återanvändning av data som flyttats tidigare kan behöva kopieras igen. Till exempel behöver mer data kopieras när mappstrukturer ändras efter att filer redan har kopierats tidigare. Ett RoboCopy-jobb kan inte "spela upp" en namnrymdsändring. Nästa jobb måste rensa filerna som tidigare transporteras 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. De här felen 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 växeln /SWITCH för att fånga upp och försöka igen filer som inte kopierades.

Du bör vara beredd på att köra flera omgångar av RoboCopy mot ett visst 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 bearbetningen av namnområdet. När du kör flera avrundar kan du påskynda varje omgång genom att inte låta RoboCopy försöka kopiera allt i en viss körning. Dessa RoboCopy-växlar kan göra betydande skillnad:

  • /R:n n = hur ofta du försöker kopiera en misslyckad fil 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 kommer en misslyckad fil att göras om fem gånger, med fem sekunders väntetid mellan återförsöken. Om filen fortfarande inte kan kopieras försöker nästa RoboCopy-jobb igen. Ofta kan filer som misslyckats på grund av att de används eller på grund av timeout-problem så småningom kopieras på det här sättet.

Användarens överklipp

Om du använder Azure File Sync måste du förmodligen skapa SMB-resurser på den Azure File Sync-aktiverade Windows Server-instansen som matchar de resurser som du hade på StorSimple-volymerna. Du kan läsa in det här steget direkt och göra det tidigare för att inte förlora tid här. Men du måste se till att ingen tidigare har åtkomst till att orsaka ändringar i Windows Server-instansen.

Om du har en DFS-N-distribution kan du peka DFN-Namespaces till de nya servermappsplatserna. Om du inte har någon DFS-N-distribution och du fronted din 8100- eller 8600-installation lokalt med en Windows Server-instans kan du ta den servern från domänen. Sedan domän-anslut din nya Azure File Sync-aktiverade Windows Server-instansen. Under den här processen ger du servern samma servernamn och delar namn som den gamla servern så att utskärningen förblir transparent för dina användare, grupprinciper och skript.

Läs mer om DFS-N.

Avetablera

När du avetablera en resurs förlorar du åtkomsten till konfigurationen av resursen och dess data. Avetablering kan inte ångras. Fortsätt inte förrän du har bekräftat att:

  • Migreringen är klar.
  • Det finns inga som helst beroenden för de StorSimple-filer, mappar eller volymsäkerhetskopior som du håller på att avetablera.

Innan du börjar är det bästa praxis att observera den nya Azure File Sync i produktion ett tag. Den tiden ger dig möjlighet att åtgärda eventuella problem som kan uppstå. När du har observerat Azure File Sync distribution i minst ett par dagar kan du börja avetablera resurser i den här ordningen:

  1. Avetablera din StorSimple Data Manager via Azure Portal. Alla dina DTS-jobb tas bort med dem. Du kan inte enkelt hämta kopieringsloggarna. Om de är viktiga för dina poster hämtar du dem innan du avetablera.
  2. Kontrollera att dina fysiska StorSimple-enheter har migrerats och avregistrera dem sedan. Om du inte är helt säker på att de har migrerats ska du inte fortsätta. Om du avetablera dessa resurser medan de fortfarande är nödvändiga kan du inte återställa data eller deras konfiguration.
    Om du vill kan du först avetablera StorSimple-volymresursen, vilket rensar data i installationen. Den här processen kan ta flera dagar och kommer inte att kriminaltekniskt nollställa data i installationen. Om detta är viktigt för dig kan du hantera disk-nollning separat från resursetablering och enligt dina principer.
  3. Om det inte finns några fler registrerade enheter kvar i en StorSimple Enhetshanteraren kan du fortsätta med att ta bort Enhetshanteraren själva resursen.
  4. Nu är det dags att ta bort StorSimple-lagringskontot i Azure. Stoppa och bekräfta att migreringen är klar och att ingenting och ingen är beroende av dessa data innan du fortsätter.
  5. Koppla från den fysiska StorSimple-installationen från ditt datacenter.
  6. Om du äger StorSimple-apparaten kan du använda PC-återanvändning. Om enheten hyrs informerar du utrenaren och returnerar enheten efter behov.

Migreringen är klar.

Anteckning

Har du fortfarande frågor eller har det uppstått några problem?
Vi finns här för att hjälpa till på AzureFilesMigration@microsoft.com .

Nästa steg

  • Bekanta dig med Azure File Sync: aka.ms/AFS.
  • Förstå flexibiliteten i principer för molnnivåindelad lagring.
  • Aktivera Azure Backup azure-filresurser för att schemalägga ögonblicksbilder och definiera scheman för kvarhållning av säkerhetskopior.
  • Om du ser i Azure Portal att vissa filer permanent inte synkroniseras kan du läsa felsökningsguiden för att hitta steg för att lösa dessa problem.