Partilhar via

Confiabilidade no Azure Storage Mover

  • Artigo

Este artigo descreve o suporte à confiabilidade no Azure Storage Mover e aborda a resiliência intrarregional com zonas de disponibilidade, recuperação de desastres entre regiões e continuidade de negócios. Para obter uma visão geral mais detalhada dos princípios de confiabilidade no Azure, consulte Confiabilidade do Azure.

Suporte à zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters dentro de cada região do Azure. Quando uma zona falha, os serviços podem fazer failover para uma das zonas restantes.

Para obter mais informações sobre zonas de disponibilidade no Azure, consulte O que são zonas de disponibilidade?.

O Azure Storage Mover dá suporte a um modelo de implantação com redundância de zona.

Ao implantar um recurso do Azure Storage Mover, você deve selecionar uma região específica na qual os metadados da instância do recurso são armazenados.

Se a região oferecer suporte a zonas de disponibilidade, os metadados da instância serão replicados automaticamente em várias zonas de disponibilidade dentro dessa região.

Importante

Os metadados da instância do Azure Storage Mover incluem projetos, pontos de extremidade, agentes, definições de trabalho e histórico de execução de trabalho, mas não incluem os dados reais a serem migrados. As contas de armazenamento do Azure que são usadas como destinos de migração têm seu próprio suporte de confiabilidade.

Pré-requisitos

  • Para implantar com suporte à zona de disponibilidade, você deve escolher uma região que ofereça suporte a zonas de disponibilidade. Para ver quais regiões oferecem suporte a zonas de disponibilidade, consulte a lista de regiões suportadas.

  • (Opcional) Se a sua conta de armazenamento de destino não suportar zonas de disponibilidade e pretender migrar a conta para o suporte AZ, consulte Migrar contas de Armazenamento do Azure para suporte de zona de disponibilidade.

Experiência de zoneamento

Durante uma interrupção em toda a zona, nenhuma ação é necessária durante a recuperação da zona. O Azure Storage Mover foi projetado para se auto-recuperar e se reequilibrar para aproveitar a zona íntegra automaticamente.

Qualquer conta de armazenamento de destino de migração pode exigir suas próprias etapas de recuperação. Esse requisito depende das opções de redundância escolhidas para cada conta de armazenamento. Consulte o guia de recuperação de desastres da conta de armazenamento para determinar se mais etapas são necessárias.

Se um armazenamento local foi escolhido em vez de opções de redundância, talvez seja necessário criar uma nova conta de armazenamento para uso em migrações durante a interrupção.

Recuperação de desastres entre regiões e continuidade de negócios

A recuperação de desastres (DR) consiste na recuperação de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a pensar em criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.

Quando se trata de DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços da plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente ou recorrem de uma região com falha para replicação cruzada para outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de plataforma como serviço (PaaS) do Azure fornecem recursos e orientação para dar suporte à DR e você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para ajudar a desenvolver seu plano de DR.

Quando um agente do Storage Mover é registrado, ele se conecta à região na qual o recurso do Storage Mover está registrado. Se a região do Azure de um agente sofrer uma interrupção, o agente em si não será afetado, mas as operações de gerenciamento que dependem do Azure podem não conseguir ser concluídas. Além disso, qualquer migração de dados ativa para contas de armazenamento localizadas na região afetada pode falhar.

O Storage Mover oferece suporte a duas formas de recuperação de desastres:

Importante

A recuperação de desastres para fontes de dados locais é de responsabilidade do cliente.

Recuperação de desastres iniciada pelo Azure

A recuperação de desastres iniciada pelo Azure só é aplicável às regiões que têm pares de regiões. Quando a replicação entre regiões é utilizada, os metadados da instância são replicados para cada região, mas nunca é permitido sair da geografia.

O Azure Storage Mover usa o Cosmos DB para armazenar metadados de instância. A perda de dados pode ocorrer apenas com um desastre irrecuperável no Azure Cosmos DB. Para obter mais informações, consulte Interrupções de região. A recuperação iniciada pelo Azure é ativa-passiva e a recuperação completa de uma região pode ser de até 24 horas.

Recuperação de desastres iniciada pelo cliente

A recuperação de desastres iniciada pelo cliente não está restrita a regiões emparelhadas.

Antes de ocorrer uma interrupção regional:

  • Implante um Storage Mover com redundância de zona criando recursos do Storage Mover em uma região que ofereça suporte a zonas de disponibilidade.

  • Periodicamente, de acordo com um cronograma ou depois de fazer alterações substanciais, tire um instantâneo dos recursos do Storage Mover. Armazenar os snapshots usando um sistema de controle de versão é uma boa maneira de armazenar e rastrear o histórico dos snapshots. Você usará o último bom instantâneo no caso de um desastre em que precise recuperar seus recursos em uma nova região.

Durante uma interrupção regional:

Você pode fazer uma de duas coisas:

  • Opte por aguardar que o Azure recupere a região.
  • Minimize o tempo de inatividade reimplantando seus recursos em uma região diferente. Como o acesso aos seus recursos pode ser afetado durante uma interrupção, convém usar o último bom instantâneo dos seus recursos.

Gorjeta

Qualquer uma dessas estratégias ainda pode exigir que você precise tomar medidas adicionais antes de um desastre, portanto, certifique-se de revisar e planejar de acordo.

Implantar recursos em uma região diferente

Consulte a documentação sobre exportação de modelos para obter mais instruções sobre como exportar recursos como um modelo do Azure Resource Manager (ARM).

Se o Storage Mover e os recursos relacionados residirem em um contêiner sem recursos extras, você deverá executar uma exportação do Grupo de Recursos para capturar o estado atual. No entanto, se o seu grupo de recursos contiver recursos não relacionados, talvez seja necessário remover ou excluir os recursos do modelo.

Os agentes existentes não podem ser reimplantados em uma região diferente. Se a região na qual eles foram configurados originalmente sofrer uma interrupção, talvez não seja possível cancelar completamente o registro e registrar novamente o agente. Este documento pressupõe que novos agentes sejam registrados em uma nova região.

Para usar o modelo exportado para recuperação de desastres, algumas alterações no modelo são necessárias.

  • Primeiro, remova todos Microsoft.StorageMover/agents os recursos do Microsoft.HybridCompute/machines modelo. Certifique-se de remover todas as referências de dependência a esses recursos também.
  • Em seguida, remova a agentResourceId propriedade de todas as definições de trabalho. Você precisará atribuí-los a um novo Agente após a implantação.
  • Depois de remover todas as referências aos recursos do agente e da máquina de computação híbrida, atualize a propriedade location do recurso Storage Mover de nível superior. Substitua o nome da região implantada atualmente pelo nome da nova região.
  • Por fim, determine se deseja manter o ID de recurso da conta de armazenamento existente. Se necessário, substitua-o por uma conta de armazenamento diferente.

Depois de concluir as etapas anteriores e verificar se os parâmetros do modelo estão corretos, o modelo está pronto para implantação em uma nova região. Você deve implantar o modelo em um novo grupo de recursos que tenha a mesma região padrão que a propriedade location no modelo.

Registrando o novo agente

Siga as etapas no artigo implantar um agente do Azure Storage Mover para registrar um novo agente no novo recurso do Storage Mover.

Atribuindo o agente a definições de trabalho

Depois que o novo agente tiver sido registrado e relatado como online, use o portal do Azure ou o PowerShell para associar as definições de trabalho existentes ao novo agente. O exemplo do PowerShell a seguir é fornecido por conveniência.

Consulte a seção Definir um novo trabalho de migração para obter orientação sobre como acessar as definições de trabalho para seu projeto.


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

Concedendo acesso do agente ao contêiner de armazenamento de destino

Você precisa atribuir a função de colaborador de dados à identidade gerenciada para executar com êxito um trabalho de migração. Atribua o acesso de identidade gerenciado pelo sistema do recurso de computação híbrida ao recurso de conta de armazenamento de destino. O artigo Atribuir um acesso de identidade gerenciada a um recurso fornece orientação sobre como conceder acesso ao recurso de destino.

Agora você está pronto para iniciar os trabalhos de migração usando os recursos recém-implantados do Storage Mover.

Próximos passos