Arquitetura de migração sem agente

Este artigo descreve os conceitos de replicação ao migrar máquinas virtuais (VMs) VMware usando o método de migração sem agente no Azure Migrate.

Processo de replicação

A opção de replicação sem agente funciona usando instantâneos do VMware e a tecnologia de acompanhamento de blocos alterados (CBT) do VMware para replicar dados dos discos da VM. O diagrama de bloco a seguir mostra as etapas envolvidas ao migrar suas VMs usando o Azure Migrate.

Quando você configura a replicação para uma VM, ela passa por uma fase inicial de replicação. Durante essa fase, o Azure Migrate captura um instantâneo da VM. O serviço então replica uma cópia completa dos dados dos discos de instantâneo para discos gerenciados na sua assinatura de destino.

Após a conclusão da replicação inicial da VM, o processo de replicação faz a transição para uma fase de replicação incremental (replicação delta). Nesta fase, as alterações de dados que ocorreram desde o início do último ciclo de replicação concluída são replicadas e gravadas nos discos gerenciados pela réplica. Essa parte do processo mantém a replicação em sincronia com as alterações na VM.

"O Azure Migrate utiliza a tecnologia de Rastreamento de Alterações do VMware para monitorar alterações entre ciclos de replicação." No início de um ciclo de replicação, o Azure Migrate captura um instantâneo de VM. O serviço usa CBT para identificar as alterações entre o snapshot atual e o último snapshot replicado com êxito. Somente os dados alterados desde o ciclo de replicação anterior são replicados, para manter a replicação da VM em sincronia. No final de cada ciclo de replicação, o instantâneo é liberado e o Migrações para Azure realiza a consolidação do instantâneo da VM.

Quando você executa a operação de migração em uma VM de replicação, um ciclo de replicação delta sob demanda replica as alterações restantes desde o último ciclo de replicação. Após a conclusão do ciclo sob demanda, o Azure Migrate cria a VM no Azure usando os discos gerenciados de réplica correspondentes à VM.

Antes de disparar a migração, você deve desligar a VM local. Desligar a VM impede a perda de dados durante a migração.

Depois que a migração for bem-sucedida e a VM for reiniciada no Azure, certifique-se de interromper a replicação da VM. Parar a replicação exclui os discos intermediários (discos de semente) que foram criados durante a replicação de dados. Em seguida, evite incorrer em encargos extras associados às transações de armazenamento nesses discos.

Ciclos de replicação

Um ciclo de replicação é o processo periódico de transferência de dados de um ambiente local para discos gerenciados do Azure. Um ciclo de replicação completo consiste nas seguintes etapas:

1. Crie um instantâneo VMware para cada disco associado à VM.
2. Carregue dados em uma conta de armazenamento de log no Azure.
3. Libere o instantâneo.
4. Consolide discos VMware.

Um ciclo é concluído depois que os discos são consolidados.

Componentes para replicação

Um dispositivo de Migrações para Azure tem os seguintes componentes locais responsáveis pela replicação:

• Agente de replicação de dados
• Agente de gateway

A tabela a seguir resume os componentes do Azure criados quando você usa o método sem agente da migração de VM do VMware.

Permissões necessárias

Quando você inicia a replicação pela primeira vez, o usuário conectado deve ter as seguintes funções:

• Proprietário ou Colaborador e Administrador de Acesso de Usuário no grupo de recursos do projeto Migrações para Azure e no grupo de recursos de destino

Para as replicações subsequentes, o usuário conectado deve ter as seguintes funções:

• Proprietário ou Colaborador no grupo de recursos do projeto Azure Migrate e no grupo de recursos de destino

Além das funções anteriores, o usuário conectado precisa da seguinte permissão em um nível de assinatura: Microsoft.Resources/subscriptions/resourceGroups/read.

Integridade de dados

Há dois estágios em cada ciclo de replicação, para ajudar a garantir a integridade dos dados entre o disco local (disco de origem) e o disco de réplica no Azure (disco de destino).

Validar a replicação

O primeiro estágio valida que todos os setores que foram alterados no disco de origem são replicados para o disco de destino. Você executa a validação usando bitmaps.

O disco de origem é dividido em setores de 512 bytes. Cada setor no disco de origem é mapeado para um bit no bitmap. Quando a replicação de dados é iniciada, o Azure Migrate cria um bitmap para todos os blocos alterados (no ciclo delta) no disco de origem que precisam ser replicados. Da mesma forma, quando os dados são transferidos para o disco do Azure de destino, o Azure Migrate cria um bitmap.

Depois que a transferência de dados for concluída com êxito, o serviço de nuvem comparará os dois bitmaps para garantir que ele não tenha perdido nenhum bloco alterado. Se houver qualquer incompatibilidade entre os bitmaps, o ciclo será considerado com falha. Como cada ciclo é de ressincronização, a incompatibilidade é corrigida no próximo ciclo.

Verificar dados replicados

O segundo estágio garante que os dados transferidos para os discos do Azure sejam os mesmos que os dados replicados dos discos de origem.

Cada bloco alterado carregado é compactado e criptografado antes de ser gravado como um blob na conta de armazenamento de log. O Azure Migrate calcula a soma de verificação desse bloco antes da compactação. Essa soma de verificação é armazenada como metadados junto com os dados compactados.

Após a descompactação, o Azure Migrate calcula a soma de verificação dos dados e a compara com a soma de verificação computada no ambiente de origem. Se houver uma incompatibilidade, os dados não serão gravados nos discos do Azure e o ciclo será considerado com falha. Como cada ciclo é de ressincronização, a incompatibilidade é corrigida no próximo ciclo.

Segurança

O appliance do Azure Migrate compacta os dados e os criptografa antes de enviá-los. Os dados são transmitidos por um canal de comunicação seguro que usa HTTPS e TLS 1.2 ou posterior. Além disso, o Armazenamento do Azure criptografa automaticamente seus dados quando eles são persistidos na nuvem (criptografia em repouso).

Status de replicação

Quando uma VM passa por replicação (cópia de dados), há vários estados possíveis:

• Replicação inicial na fila: a VM está na fila para replicação ou migração porque outras VMs podem estar consumindo os recursos locais durante a replicação ou migração. Depois que os recursos forem gratuitos, essa VM será processada.
• Replicação inicial em andamento: a VM está agendada para replicação inicial.
• Replicação inicial: a VM está passando pela replicação inicial. Quando a VM está passando por replicação inicial, você não pode continuar com a migração de teste e a migração de produção. Só é possível interromper a replicação neste estágio.
• Replicação inicial (x%): a replicação inicial está ativa e progrediu pela porcentagem mostrada.
• Sincronização delta: A VM pode estar passando por um ciclo de replicação delta que replica a rotatividade de dados restante desde o último ciclo de replicação.
• Pausa em andamento: a VM está passando por um ciclo de replicação delta ativo e está pausada.
• Pausado: os ciclos de replicação são pausados. Você pode retomar os ciclos de replicação executando a operação para retomar a replicação.
• Retomar na fila: a VM está na fila para retomar a replicação porque outras VMs estão consumindo os recursos locais.
• Retomada em andamento (x%): o ciclo de replicação está sendo retomado para a VM e avançou pelo percentual mostrado.
• Parar replicação em andamento: a limpeza da replicação está em andamento. Quando você interrompe a replicação, os discos gerenciados intermediários (discos de semente) criados durante a replicação são excluídos. Você pode saber mais sobre como interromper a replicação mais adiante neste artigo.
• Migração completa em andamento: a limpeza da migração está em andamento. Quando você conclui a migração, os discos gerenciados intermediários (discos de semente) criados durante a replicação são excluídos. Você pode saber mais sobre como concluir a replicação mais adiante neste artigo.
• – : quando a VM é migrada com êxito ou quando você interrompe a replicação, o status muda para um traço. Depois de concluir a migração ou interromper a replicação e a operação for concluída com êxito, a VM será removida da lista de máquinas de replicação. Você pode encontrar a VM na guia para máquinas virtuais no assistente de replicação.

Outros estados

• Falha na replicação inicial: os dados iniciais não puderam ser copiados para a VM. Siga as diretrizes de correção a serem resolvidas.

• Reparo pendente: houve um problema no ciclo de replicação. Você pode selecionar o link para entender possíveis causas e ações a serem corrigidas (conforme aplicável). Se você optou por reparar automaticamente a replicação selecionando Sim quando disparou a replicação da VM, a ferramenta tentará repará-la para você. Caso contrário, selecione a VM e selecione Reparar Replicação.

  Se você não optou pelo Reparo automático de replicação ou se a etapa de reparo não teve êxito no seu caso, interrompa a replicação da VM. Redefina o CBT na VM e reconfigure a replicação.

• Reparar replicação na fila: a VM está na fila para reparo de replicação porque outras VMs estão consumindo os recursos locais. Após a liberação dos recursos, a VM é processada para reparo de replicação.

• Ressincronizar (x%): a VM está passando por uma ressincronização de dados. Essa ressincronização pode acontecer se houver um problema ou uma incompatibilidade durante a replicação de dados.

• Falha ao interromper a replicação/concluir a migração: selecione o link para entender as possíveis causas de falha e as ações de correção (conforme aplicável).

Status da migração de teste ou migração de produção

• Migração de teste pendente: A VM está na fase de replicação delta. Agora você pode executar a migração de teste (ou migração de produção).
• Limpeza de teste de migração pendente: após a conclusão do teste de migração, realize uma limpeza do teste de migração para evitar cobranças no Azure.
• Pronto para migrar: a VM está pronta para migração para o Azure.
• Migração em andamento na fila: a VM está na fila para migração porque outras VMs estão consumindo os recursos locais durante a replicação (ou migração). Depois que os recursos forem gratuitos, a VM será processada.
• Migração de teste/Migração em andamento: A VM está passando por uma migração de teste ou uma migração de produção. Você pode clicar no link para verificar o andamento do trabalho de migração.
• Data, carimbo de data/hora: o teste de migração ou a migração de produção ocorreu nesta data e hora.
• –: a replicação inicial está em andamento. Você pode executar uma migração de teste ou uma migração de produção após a transição do processo de replicação para uma fase de sincronização delta (replicação incremental).

Outros estados

• Concluído com informações: o trabalho de teste de migração ou migração de produção foi concluído com informações. Você pode selecionar o link para verificar o último trabalho de migração para obter as possíveis causas e ações de correção (conforme aplicável).
• Falha: O trabalho de migração de teste ou de produção falhou. Você pode selecionar o link para verificar o último trabalho de migração para obter as possíveis causas e ações de correção.

Lógica de agendamento

A replicação inicial é agendada quando você configura a replicação para uma VM. As replicações incrementais (replicações delta) a seguem.

Os ciclos de replicação delta são agendados da seguinte forma:

• O primeiro ciclo de replicação delta é agendado imediatamente após o término do ciclo de replicação inicial.

• Os próximos ciclos de replicação delta são agendados de acordo com a seguinte lógica: min[max[1 hour, (<Previous delta replication cycle time>/2)], 12 hours].

  Ou seja, a próxima replicação delta está agendada para não menos que 1 hora e não mais que 12 horas. Por exemplo, se uma VM levar 4 horas para um ciclo de replicação delta, o próximo ciclo de replicação delta será agendado em 2 horas e não na próxima hora.

  Observação

  A lógica de agendamento é diferente após a conclusão da replicação inicial. O primeiro ciclo delta é agendado imediatamente após a conclusão da replicação inicial. Os ciclos subsequentes seguem a lógica de agendamento.

• Quando você dispara a migração, um ciclo de replicação delta sob demanda (pré-failover) ocorre para a VM antes da migração.

Priorização

Aqui está a priorização de VMs para vários estágios de replicação:

• As replicações de VM em andamento são priorizadas em relação às replicações agendadas (novas replicações).
• O ciclo de replicação delta sob demanda (pré-failover) tem a prioridade mais alta, seguida pelo ciclo de replicação inicial. O ciclo de replicação delta tem a prioridade mais baixa.

Sempre que você dispara uma operação de migração, o ciclo de replicação sob demanda da VM é agendado. Outras replicações em andamento devem aguardar se estiverem competindo por recursos.

Restrições

As seguintes restrições ajudam a garantir que você não exceda os limites de IOPS nas redes da área de armazenamento:

• Cada dispositivo de Migrações para Azure dá suporte à replicação de 52 discos em paralelo.
• Cada host ESXi oferece suporte a oito discos. Cada host ESXi tem um buffer NFC de 32 MB. Portanto, você pode agendar 8 discos no host. (Cada disco ocupa até 4 MB de buffer para resposta a incidentes e recuperação de desastre.)
• Cada armazenamento de dados pode ter um máximo de 15 instantâneos de disco. A única exceção é quando mais de 15 discos são anexados a uma VM.

Replicação de expansão

As Migrações para Azure dão suporte à replicação simultânea de 500 VMs. Ao planejar replicar mais de 300 VMs, você deve implantar um dispositivo de expansão. O dispositivo de expansão é semelhante a um dispositivo primário do Migrações para Azure, mas consiste apenas em um agente de gateway para facilitar a transferência de dados para o Azure.

O diagrama a seguir mostra a maneira recomendada de usar o dispositivo de expansão.

Você pode implantar o dispositivo de expansão a qualquer momento depois de configurar o dispositivo primário, mas ele não é necessário até que 300 VMs estejam replicando simultaneamente. Quando 300 VMs estiverem replicando simultaneamente, você deverá implantar o dispositivo de expansão para continuar.

Interrompendo a replicação ou concluindo uma migração

Quando você interrompe a replicação, os discos gerenciados intermediários (discos de semente) criados durante a replicação são excluídos. Você só pode interromper a replicação durante uma replicação ativa. Você pode selecionar a migração completa para interromper a replicação após a migração da VM.

Você pode replicar a VM para a qual a replicação é interrompida habilitando a replicação novamente. Se a VM foi migrada, você poderá retomar a replicação e a migração novamente.

Como prática recomendada, você sempre deve concluir a migração depois que a VM migrar com êxito para o Azure. Essa prática garante que você não incorra em encargos extras para transações de armazenamento nos discos gerenciados intermediários (discos de semente).

Em alguns casos, parar a replicação leva tempo. O motivo é que sempre que você interrompe a replicação, o ciclo de replicação em andamento é concluído (somente quando a VM está em sincronização delta) antes da exclusão dos artefatos.

Impacto da rotatividade

Você pode minimizar a quantidade de transferência de dados de entrada em cada ciclo de replicação permitindo que os dados dobrem o máximo possível antes de agendar o próximo ciclo. Como a replicação sem agente é dobrada nos dados, o padrão de rotatividade é mais importante do que a taxa de rotatividade. Quando um arquivo é gravado novamente e novamente, a taxa não tem muito impacto. No entanto, um padrão no qual todos os outro setores são escritos causa alta rotatividade no próximo ciclo.

Se o ciclo de replicação delta atual apresentar atrasos devido à alta variação de dados, o início do ciclo subsequente poderá ser atrasado. Um volume maior de dados a serem replicados para um disco específico estende a duração necessária para criar um ponto de recuperação. Como resultado, o ciclo de migração final leva mais tempo. Essa situação leva a um período de desligamento estendido para a VM de origem.

Se o tamanho do instantâneo aumentar (devido ao padrão de rotatividade) a ponto de ultrapassar a capacidade disponível do armazenamento de dados, há risco de o armazenamento de dados ficar sem espaço. Essa situação pode afetar negativamente as cargas de trabalho de produção e pode tornar a VM de origem sem resposta.

Para atenuar esse risco, recomendamos que você aumente o tamanho do armazenamento de dados proativamente. Se várias VMs que você está replicando simultaneamente tiverem discos em um armazenamento de dados com baixa capacidade disponível, aconselhamos que você execute migrações de uma VM por vez para evitar a contenção de recursos.

Gerenciamento de replicação

Limitação

Você pode aumentar ou diminuir a largura de banda de replicação usando NetQosPolicy. O AppNamePrefix valor a ser usado NetQosPolicy é GatewayWindowsService.exe.

Para restringir o tráfego de replicação do dispositivo do Migrações para Azure, você pode criar uma política como o exemplo a seguir no dispositivo. Esta política se aplica a todas as VMs em replicação do dispositivo do Migrações para Azure simultaneamente.

New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB

Você também pode aumentar e diminuir a largura de banda de replicação com base em um agendamento usando o script de exemplo.

Janela de blecaute

As Migrações para Azure fornecem um mecanismo baseado em configuração que você pode usar para especificar o intervalo de tempo durante o qual você não deseja que nenhuma replicação prossiga. Esse intervalo é chamado de janela de apagão. A necessidade de uma janela de apagão pode surgir em vários cenários, como quando o ambiente de origem é restrito a recursos ou quando você deseja que a replicação ocorra apenas fora do horário comercial.

Você pode especificar uma janela de indisponibilidade para o dispositivo criando ou atualizando o arquivo GatewayDataWorker.json em C:\ProgramData\Microsoft Azure\Config. Um arquivo típico tem este formulário:

{
    
    "BlackoutWindows": "List of blackout windows"
    
}

A lista de janelas de indisponibilidade é uma cadeia de caracteres delimitada por pipe (|) no formato de<DayOfWeek>;<StartTime>;<Duration>. Você pode especificar a duração em dias, horas e minutos. Por exemplo, você pode especificar as janelas de apagão como:

{
    
    "BlackoutWindows": "Monday;7:00;7h | Tuesday;8:00;1d7h | Wednesday;16:00;1d | Thursday;18:00;5h | Friday;13:00;8m"
    
}

O primeiro valor no exemplo anterior indica uma janela de apagão que começa todas as segundas-feiras às 7h locais (hora no dispositivo) e dura 7 horas.

Depois de criar ou atualizar GatewayDataWorker.json com esses conteúdos, você precisará reiniciar o serviço de gateway no dispositivo para que essas alterações entrem em vigor.

No cenário de expansão, o dispositivo primário e o dispositivo de expansão respeitam as janelas de blecaute de forma independente. Como melhor prática, recomendamos manter as janelas consistentes entre os dispositivos.

Conteúdo relacionado

• Migrar VMs VMware para o Azure (sem agente)