Compartilhar via

Confiabilidade no Migrador de Armazenamento do Azure

  • Artigo

Esse artigo descreve o suporte à confiabilidade no Migrador de Armazenamento do Azure e aborda a resiliência intra-regional com zonas de disponibilidade e recuperação de desastre entre regiões e continuidade dos negócios. Para obter uma visão geral mais detalhada dos princípios de confiabilidade no Azure, confira Confiabilidade do Azure.

Suporte à zona de disponibilidade

As zonas de disponibilidade do Azure são pelo menos três grupos de datacenters separados fisicamente em cada região do Azure. Os datacenters dentro de cada zona são equipados com energia, resfriamento e infraestrutura de rede independentes. Em caso de falha de uma zona local, as zonas de disponibilidade foram projetadas de modo que, se uma zona é afetada, os serviços regionais, a capacidade e a alta disponibilidade têm suporte nas duas zonas restantes.

As falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. A tolerância a falhas é obtida devido à redundância e ao isolamento lógico dos serviços do Azure. Para obter informações detalhadas sobre as zonas de disponibilidade no Azure, confira Regiões e zonas de disponibilidade.

Os serviços habilitados para zonas de disponibilidade do Azure foram projetados para fornecer o nível ideal de resiliência e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ter redundância de zona, com replicação automática entre zonas, ou podem ser zonais, com instâncias fixadas em uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre a arquitetura zonal versus com redundância de zona, confira Recomendações para usar zonas e regiões de disponibilidade.

O Migrador de Armazenamento do Azure dá suporte a um modelo de implantação com redundância de zona.

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

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

Importante

Os metadados da instância do Migrador de Armazenamento do Azure 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 usadas como destinos de migração têm seu próprio suporte de confiabilidade.

Pré-requisitos

Experiência de zona inoperante

Durante uma interrupção em toda a zona, nenhuma ação é necessária durante a recuperação de zona. O Migrador de Armazenamento do Azure foi projetado para se auto-curar e se equilibrar novamente 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 desastre 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 desastre entre regiões e continuidade dos negócios

A DR (recuperação de desastre) trata da recuperação após eventos de alto impacto, como desastres naturais ou implantações com falha, que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR. Antes de começar a pensar em criar seu plano de recuperação de desastre, confira Recomendações para criar uma estratégia de recuperação de desastre.

Quando o assunto é 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 de plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente nem retornam de uma região com falha para a replicação cruzada em outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastre que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Além disso, você pode usar recursos específicos do serviço para dar suporte a uma recuperação rápida, a fim de ajudar a desenvolver seu plano de DR.

Quando um agente do Migrador de Armazenamento é registrado, ele se conecta à região na qual o recurso do Migrador de Armazenamento é registrado. Se a região do Azure de um agente sofrer uma interrupção, o próprio agente não será afetado, mas as operações de gerenciamento que dependem do Azure poderão não ser concluídas. Além disso, as migrações de dados ativas para contas de armazenamento localizadas na região afetada podem falhar.

O Migrador de Armazenamento dá suporte a duas formas de recuperação de desastre:

Importante

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

Recuperação de desastre iniciada pelo Azure

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

O Migrador de Armazenamento do Azure usa o Cosmos DB para armazenar metadados de instância. A perda de dados pode ocorrer apenas com um desastre irrecuperável na região do Azure Cosmos DB. Para obter mais informações, veja 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 desastre iniciada pelo cliente

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

Antes de ocorrer uma interrupção regional:

  • implante um Migrador de Armazenamento com redundância de zona criando recursos do Storage Mover em uma região que dá suporte a zonas de disponibilidade.

  • Periodicamente, em um agendamento ou depois de fazer alterações substanciais, tire um instantâneo dos recursos do Migrador de Armazenamento. Armazenar os instantâneos usando um sistema de controle de versão é uma boa maneira de armazenar e acompanhar o histórico dos instantâneos. Você usará o último instantâneo bom no caso de um desastre em que precisará recuperar seus recursos em uma nova região.

Durante uma interrupção regional:

Portanto, você tem duas opções:

  • escolha aguardar até 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, você desejará usar o último bom instantâneo de seus recursos.

Dica

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

Implantar recursos em uma região diferente

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

Se o Migrador de Armazenamento 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 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. Esse documento pressupõe que novos agentes sejam registrados em uma nova região.

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

  • Primeiro, remova quaisquer recursos Microsoft.StorageMover/agents e Microsoft.HybridCompute/machines do modelo. Remova as referências de dependência a esses recursos também.
  • Em seguida, remova a propriedade agentResourceId 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 a recursos de computador de computação híbrida e agente, atualize a propriedade de localização do recurso de Migrador de Armazenamento de nível superior. Substitua o nome da região implantada no momento pelo nome da nova região.
  • Por fim, determine se a ID do recurso da conta de armazenamento existente deve ser mantida. Se necessário, substitua-o por uma conta de armazenamento diferente.

Depois de concluir as etapas anteriores e verificar se os parâmetros de 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 de localização no modelo.

Como registrar o novo agente

Siga as etapas no artigo implantar um agente do Migrador de Armazenamento do Azure para registrar um novo agente no novo recurso do Migrador de Armazenamento.

Como atribuir o agente a definições de trabalho

Depois que o novo agente tiver sido registrado e relatar 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 para conveniência.

Confira a definição de um novo trabalho de migração para obter diretrizes 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

Como conceder acesso ao contêiner de armazenamento de destino ao agente

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 gerenciada do 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 diretrizes sobre como conceder acesso ao recurso de destino.

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

Próximas etapas