Delen via

Betrouwbaarheid in Azure Storage Mover

  • Artikel

In dit artikel wordt betrouwbaarheidsondersteuning in Azure Storage Mover beschreven en wordt zowel binnen regionale tolerantie behandeld als beschikbaarheidszones en herstel na noodgevallen in meerdere regio's en bedrijfscontinuïteit. Zie Azure-betrouwbaarheid voor een gedetailleerder overzicht van betrouwbaarheidsprincipes in Azure.

Ondersteuning voor beschikbaarheidszone

Beschikbaarheidszones zijn fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Zie Wat zijn beschikbaarheidszones in Azure voor meer informatie over beschikbaarheidszones?

Azure Storage Mover ondersteunt een zone-redundant implementatiemodel.

Wanneer u een Azure Storage Mover-resource implementeert, moet u een bepaalde regio selecteren waarin de metagegevens van de instantie van de resource worden opgeslagen.

Als de regio beschikbaarheidszones ondersteunt, worden de metagegevens van het exemplaar automatisch gerepliceerd in meerdere beschikbaarheidszones binnen die regio.

Belangrijk

Metagegevens van Azure Storage Mover-exemplaren omvatten projecten, eindpunten, agents, taakdefinities en uitvoeringsgeschiedenis van taken, maar bevatten niet de werkelijke gegevens die moeten worden gemigreerd. Azure-opslagaccounts die worden gebruikt als migratiedoelen hebben hun eigen betrouwbaarheidsondersteuning.

Vereisten

Zone-down-ervaring

Tijdens een zonebrede storing is er geen actie vereist tijdens zoneherstel. Azure Storage Mover is ontworpen om zichzelf te herstellen en opnieuw te verdelen om automatisch te profiteren van de gezonde zone.

Voor elk migratiedoelopslagaccount zijn mogelijk eigen herstelstappen vereist. Deze vereiste is afhankelijk van de redundantieopties die voor elk opslagaccount zijn gekozen. Raadpleeg de handleiding voor herstel na noodgevallen van het opslagaccount om te bepalen of er meer stappen nodig zijn.

Als er een lokale opslag is gekozen in plaats van redundantieopties, moet u mogelijk een nieuw opslagaccount maken voor gebruik in migraties tijdens de storing.

Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's

Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie aanbevelingen voor het ontwerpen van een strategie voor herstel na noodgevallen voordat u begint na te denken over het maken van uw plan voor herstel na noodgevallen.

Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.

Wanneer een Storage Mover-agent is geregistreerd, maakt deze verbinding met de regio waarin de Storage Mover-resource is geregistreerd. Als de Azure-regio van een agent een storing ondervindt, wordt de agent zelf niet beïnvloed, maar kunnen beheerbewerkingen die afhankelijk zijn van Azure mogelijk niet worden voltooid. Bovendien kunnen actieve gegevensmigraties naar opslagaccounts in de betrokken regio mislukken.

Storage Mover ondersteunt twee vormen van herstel na noodgevallen:

Belangrijk

Herstel na noodgevallen voor on-premises gegevensbronnen is de verantwoordelijkheid van de klant.

Door Azure geïnitieerd herstel na noodgevallen

Door Azure geïnitieerd herstel na noodgevallen is alleen van toepassing op regio's met regioparen. Wanneer replicatie tussen regio's wordt gebruikt, worden de metagegevens van exemplaren gerepliceerd naar elke regio, maar mogen ze nooit de geografie verlaten.

Azure Storage Mover maakt gebruik van Cosmos DB voor het opslaan van metagegevens van exemplaren. Gegevensverlies kan alleen optreden met een onherstelbare ramp in Azure Cosmos DB. Zie Regio-storingen voor meer informatie. Door Azure geïnitieerd herstel is actief-passief en het volledig herstel van een regio kan maximaal 24 uur duren.

Door de klant geïnitieerd herstel na noodgevallen

Door de klant geïnitieerd herstel na noodgevallen is niet beperkt tot gekoppelde regio's.

Voordat er een regionale storing optreedt:

  • Implementeer een zone-redundante Opslag-Mover door opslag-Mover-resources te maken in een regio die ondersteuning biedt voor beschikbaarheidszones.

  • Maak periodiek een momentopname van uw Storage Mover-resources, afhankelijk van een planning of nadat u aanzienlijke wijzigingen hebt aangebracht. Het opslaan van de momentopnamen met behulp van een versiebeheersysteem is een goede manier om de geschiedenis van de momentopnamen op te slaan en bij te houden. U gebruikt de laatste goede momentopname in het geval van een noodgeval waarin u uw resources in een nieuwe regio moet herstellen.

Tijdens een regionale storing:

U kunt een van de volgende twee dingen doen:

Tip

Een van deze strategieën kan nog steeds vereisen dat u verdere stappen moet ondernemen voordat er een noodgeval optreedt, dus zorg ervoor dat u dienovereenkomstig beoordeelt en plant.

Resources implementeren in een andere regio

Zie de documentatie over het exporteren van sjablonen voor verdere instructies over het exporteren van resources als een ARM-sjabloon (Azure Resource Manager).

Als uw Opslag-Mover en gerelateerde resources zich in een container bevinden zonder extra resources, moet u een resourcegroepexport uitvoeren om de huidige status vast te leggen. Als uw resourcegroep echter niet-gerelateerde resources bevat, moet u de resources mogelijk verwijderen of op een andere manier uitsluiten van de sjabloon.

Bestaande agents kunnen niet opnieuw worden geïmplementeerd in een andere regio. Als de regio waarin ze oorspronkelijk zijn geconfigureerd een storing ondervindt, is het mogelijk niet mogelijk om de registratie van de agent volledig ongedaan te maken en opnieuw te registreren. In dit document wordt ervan uitgegaan dat nieuwe agents zijn geregistreerd binnen een nieuwe regio.

Als u de geëxporteerde sjabloon wilt gebruiken voor herstel na noodgevallen, zijn enkele wijzigingen in de sjabloon vereist.

  • Verwijder eerst alle Microsoft.StorageMover/agents resources uit Microsoft.HybridCompute/machines de sjabloon. Zorg ervoor dat u ook afhankelijkheidsverwijzingen naar deze resources verwijdert.
  • Verwijder vervolgens de agentResourceId eigenschap uit alle taakdefinities. U moet deze na de implementatie toewijzen aan een nieuwe agent.
  • Nadat u alle verwijzingen naar agent- en Hybrid Compute-machineresources hebt verwijderd, moet u de locatie-eigenschap van de Mover-resource op het hoogste niveau bijwerken. Vervang de naam van de momenteel geïmplementeerde regio door de naam van de nieuwe regio.
  • Bepaal ten slotte of u de resource-id van het bestaande opslagaccount wilt behouden. Vervang deze indien nodig door een ander opslagaccount.

Nadat u de vorige stappen hebt voltooid en hebt gecontroleerd of de sjabloonparameters juist zijn, is de sjabloon gereed voor implementatie naar een nieuwe regio. U moet de sjabloon implementeren in een nieuwe resourcegroep met dezelfde standaardregio als de locatie-eigenschap in de sjabloon.

De nieuwe agent registreren

Volg de stappen in het artikel over het implementeren van een Azure Storage Mover-agent om een nieuwe agent te registreren in de nieuwe Storage Mover-resource.

De agent toewijzen aan taakdefinities

Nadat de nieuwe agent is geregistreerd en als online is gerapporteerd, gebruikt u Azure Portal of PowerShell om de bestaande taakdefinities aan de nieuwe agent te koppelen. Het volgende PowerShell-voorbeeld is voor het gemak beschikbaar.

Zie de definitie van een nieuwe migratietaak voor hulp bij het openen van de taakdefinities voor uw project.


## 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

Agent toegang verlenen tot de doelopslagcontainer

U moet de rol van gegevensbijdrager toewijzen aan de beheerde identiteit om een migratietaak uit te voeren. Wijs de door het systeem beheerde identiteit van de Hybrid Compute-resource toe aan de doelopslagaccountresource. Het toewijzen van een beheerde identiteit tot een resourceartikel bevat richtlijnen voor het verlenen van toegang tot de doelresource.

U bent nu klaar om migratietaken te starten met behulp van de zojuist geïmplementeerde Storage Mover-resources.

Volgende stappen