Dela via

Tillförlitlighet i Azure Storage Mover

  • Artikel

Den här artikeln beskriver tillförlitlighetsstöd i Azure Storage Mover och beskriver både intraregional återhämtning med tillgänglighetszoner och haveriberedskap mellan regioner och affärskontinuitet. En mer detaljerad översikt över tillförlitlighetsprinciper i Azure finns i Azures tillförlitlighet.

Stöd för tillgänglighetszon

Tillgänglighetszoner är fysiskt separata grupper av datacenter i varje Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Mer information om tillgänglighetszoner i Azure finns i Vad är tillgänglighetszoner?.

Azure Storage Mover stöder en zonredundant distributionsmodell.

När du distribuerar en Azure Storage Mover-resurs måste du välja en viss region där resursens instansmetadata lagras.

Om regionen stöder tillgänglighetszoner replikeras instansmetadata automatiskt över flera tillgänglighetszoner i den regionen.

Viktigt!

Azure Storage Mover-instansmetadata innehåller projekt, slutpunkter, agenter, jobbdefinitioner och jobbkörningshistorik, men innehåller inte de faktiska data som ska migreras. Azure Storage-konton som används som migreringsmål har sitt eget tillförlitlighetsstöd.

Förutsättningar

  • Om du vill distribuera med stöd för tillgänglighetszoner måste du välja en region som stöder tillgänglighetszoner. Information om vilka regioner som stöder tillgänglighetszoner finns i listan över regioner som stöds.

  • (Valfritt) Om mållagringskontot inte har stöd för tillgänglighetszoner och du vill migrera kontot till AZ-support läser du Migrera Azure Storage-konton till stöd för tillgänglighetszoner.

Zon-ned-upplevelse

Under ett zonomfattande avbrott krävs ingen åtgärd under zonåterställning. Azure Storage Mover är utformat för att själv läka och balansera om sig själv för att dra nytta av den felfria zonen automatiskt.

Alla lagringskonton för migreringsmål kan kräva egna återställningssteg. Det här kravet beror på vilka redundansalternativ som valts för varje lagringskonto. Se guiden för haveriberedskap för lagringskontot för att avgöra om fler steg krävs.

Om en lokal lagring valdes i stället för redundansalternativ kan du behöva skapa ett nytt lagringskonto för användning i migreringar under avbrott.

Haveriberedskap och affärskontinuitet mellan regioner

Haveriberedskap handlar om att återställa från händelser med hög påverkan, till exempel naturkatastrofer eller misslyckade distributioner som resulterar i driftstopp och dataförlust. Oavsett orsak är den bästa lösningen för en katastrof en väldefinierad och testad DR-plan och en programdesign som aktivt stöder DR. Innan du börjar fundera på att skapa en haveriberedskapsplan kan du läsa Rekommendationer för att utforma en strategi för haveriberedskap.

När det gäller dr använder Microsoft modellen för delat ansvar. I en modell med delat ansvar ser Microsoft till att baslinjeinfrastrukturen och plattformstjänsterna är tillgängliga. Samtidigt replikerar många Azure-tjänster inte automatiskt data eller återgår från en misslyckad region för att korsreparera till en annan aktiverad region. För dessa tjänster ansvarar du för att konfigurera en haveriberedskapsplan som fungerar för din arbetsbelastning. De flesta tjänster som körs på PaaS-erbjudanden (Plattform som en tjänst) i Azure ger funktioner och vägledning för att stödja DR och du kan använda tjänstspecifika funktioner för att stödja snabb återställning för att utveckla din DR-plan.

När en Storage Mover-agent registreras ansluter den till den region där Storage Mover-resursen är registrerad. Om en agent i Azure-regionen drabbas av ett avbrott påverkas inte själva agenten, men hanteringsåtgärder som förlitar sig på Azure kanske inte kan slutföras. Dessutom kan alla aktiva datamigreringar till lagringskonton som finns i den berörda regionen misslyckas.

Storage Mover stöder två typer av haveriberedskap:

Viktigt!

Haveriberedskap för lokala datakällor är kundens ansvar.

Azure-initierad haveriberedskap

Azure-initierad haveriberedskap gäller endast för de regioner som har regionpar. När replikering mellan regioner används replikeras instansmetadata till varje region, men tillåts aldrig lämna geografin.

Azure Storage Mover använder Cosmos DB för att lagra instansmetadata. Dataförlust kan endast inträffa vid en oåterkallelig katastrof i Azure Cosmos DB . Mer information finns i Regionfel. Azure-initierad återställning är aktiv-passiv och fullständig återställning av en region kan ta upp till 24 timmar.

Kundinitierad haveriberedskap

Kundinitierad haveriberedskap är inte begränsad till kopplade regioner.

Innan ett regionalt avbrott inträffar:

  • Distribuera en zonredundant lagringsflyttare genom att skapa Storage Mover-resurser i en region som stöder tillgänglighetszoner.

  • Med jämna mellanrum – antingen enligt ett schema eller efter att du har genomfört betydande ändringar – tar du en ögonblicksbild av dina Storage Mover-resurser. Att lagra ögonblicksbilderna med hjälp av ett versionskontrollsystem är ett bra sätt att lagra och spåra historiken för ögonblicksbilderna. Du använder den sista bra ögonblicksbilden i händelse av en katastrof där du behöver återställa dina resurser i en ny region.

Under ett regionalt avbrott:

Du kan göra en av två saker:

  • Välj att vänta tills Azure har återställt regionen.
  • Minimera stilleståndstiden genom att omdistribuera dina resurser till en annan region. Eftersom åtkomsten till dina resurser kan påverkas under ett avbrott, vill du använda den sista bra ögonblicksbilden av dina resurser.

Dricks

Någon av dessa strategier kan fortfarande kräva att du måste vidta ytterligare åtgärder före en katastrof, så se till att granska och planera därefter.

Distribuera resurser till en annan region

Mer information om hur du exporterar resurser som en ARM-mall (Azure Resource Manager) finns i dokumentationen om hur du exporterar mallar.

Om din Storage Mover och relaterade resurser finns i en container utan extra resurser bör du utföra en resursgruppsexport för att samla in det aktuella tillståndet. Men om resursgruppen innehåller orelaterade resurser kan du behöva ta bort eller på annat sätt undanta resurserna från mallen.

Befintliga agenter kan inte distribueras om till en annan region. Om den region där de ursprungligen konfigurerades drabbas av ett avbrott kanske det inte går att avregistrera och registrera agenten på nytt. Det här dokumentet förutsätter att nya agenter registreras i en ny region.

Om du vill använda den exporterade mallen för haveriberedskap krävs några ändringar i mallen.

  • Ta först bort alla Microsoft.StorageMover/agents resurser och Microsoft.HybridCompute/machines från mallen. Se till att ta bort eventuella beroendereferenser till dessa resurser också.
  • Ta sedan bort egenskapen agentResourceId från alla jobbdefinitioner. Du måste tilldela dem till en ny agent efter distributionen.
  • När du har tagit bort alla referenser till agent- och Hybrid Compute-datorresurser uppdaterar du platsegenskapen för den översta lagringsflyttarresursen. Ersätt namnet på den distribuerade regionen med namnet på den nya regionen.
  • Slutligen avgör du om du vill behålla det befintliga lagringskontots resurs-ID. Om det behövs ersätter du det med ett annat lagringskonto.

När du har slutfört föregående steg och kontrollerat att mallparametrarna är korrekta är mallen redo för distribution till en ny region. Du bör distribuera mallen till en ny resursgrupp som har samma standardregion som platsegenskapen i mallen.

Registrera den nya agenten

Följ stegen i artikeln distribuera en Azure Storage Mover-agent för att registrera en ny agent i den nya Storage Mover-resursen.

Tilldela agenten till jobbdefinitioner

När den nya agenten har registrerats och rapporter är online använder du Azure Portal eller PowerShell för att associera befintliga jobbdefinitioner med den nya agenten. Följande PowerShell-exempel tillhandahålls för enkelhetens skull.

Se definiera ett nytt migreringsjobb för vägledning om hur du får åtkomst till jobbdefinitionerna för ditt projekt.


## Update the agent in a job definition resource
$resourceGroupName  = "[Your resource group name]"
$storageMoverName   = "[Your storage mover name]"
$projectName        = "[Your project name]"
$jobDefName         = "[Your job definition name]"
$agentName          = "[The name of an agent previously registered to the same storage mover resource]"

Update-AzStorageMoverJobDefinition `
    -ResourceGroupName $resourceGroupName `
    -StorageMoverName $storageMoverName `
    -ProjectName $projectName `
    -Name $jobDefName `
    -AgentName $agentName

Bevilja agentåtkomst till mållagringscontainern

Du måste tilldela rollen datadeltagare till den hanterade identiteten för att kunna utföra ett migreringsjobb. Tilldela Hybrid Compute-resursens systemhanterade identitet åtkomst till mållagringskontoresursen. Artikeln tilldela en hanterad identitet åtkomst till en resurs innehåller vägledning om hur du beviljar åtkomst till målresursen.

Nu är du redo att starta migreringsjobb med hjälp av de nyligen distribuerade Storage Mover-resurserna.

Nästa steg