Arquitetura de migração sem agente

Este artigo descreve os conceitos de replicação quando você está migrando 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 snapshots VMware e a tecnologia VMware changed block tracking (CBT) para replicar dados de discos VM. O diagrama de blocos 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 tira um instantâneo da VM. Em seguida, o serviço replica uma cópia completa dos dados dos discos de snapshot para discos gerenciados em sua assinatura de destino.

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

O Azure Migrate usa a tecnologia VMware CBT para acompanhar as alterações entre os ciclos de replicação. No início de um ciclo de replicação, o Azure Migrate tira um instantâneo da VM. O serviço usa o CBT para obter as alterações entre o snapshot atual e o último snapshot replicado com êxito. Somente os dados alterados desde o ciclo de replicação concluído anterior são replicados, para manter a replicação da VM sincronizada. No final de cada ciclo de replicação, o instantâneo é liberado e o Azure Migrate executa a consolidação de instantâneo para a VM.

Quando você executa a operação de migração em uma VM replicante, 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 que correspondem à VM.

Antes de disparar a migração, você deve desligar a VM local. O desligamento da VM evita 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. A interrupção da replicação exclui os discos intermediários (discos de propagação) que foram criados durante a replicação de dados. Em seguida, evite incorrer em encargos adicionais 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 completo de replicação consiste nas seguintes etapas:

1. Crie um snapshot VMware para cada disco associado à VM.
2. Carregue dados para uma conta de armazenamento de log no Azure.
3. Solte o snapshot.
4. Consolide discos VMware.

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

Componentes para replicação

Um dispositivo Azure Migrate tem os seguintes componentes locais que são responsáveis pela replicação:

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

A tabela a seguir resume os componentes do Azure que são criados quando você usa o método sem agente de migração de VM 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 Azure Migrate 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 dos 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 replicação

O primeiro estágio valida que cada setor alterado no disco de origem seja replicado 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 pouco 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 precisa ser replicado. 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 compara os dois bitmaps para garantir que ele não perca nenhum bloco alterado. Se houver alguma incompatibilidade entre os bitmaps, o ciclo será considerado falha. Como cada ciclo é ressincronizado, a incompatibilidade é corrigida no ciclo seguinte.

Verificar dados replicados

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

Cada bloco alterado que é 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 descompressão, o Azure Migrate calcula a soma de verificação para os dados e a compara com a soma de verificação calculada 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 é ressincronizado, a incompatibilidade é corrigida no ciclo seguinte.

Segurança

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

Estado de replicação

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

• Replicação inicial enfileirada: a VM é enfileirada 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 estiverem livres, essa VM será processada.
• Replicação inicial em andamento: a VM está agendada para replicação inicial.
• Replicação inicial: a VM está passando por replicação inicial. Quando a VM está passando pela replicação inicial, não é possível prosseguir 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.
• Em pausa: 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 no momento.
• Retomar em andamento (x%): O ciclo de replicação está sendo retomado para a VM e progrediu pela porcentagem mostrada.
• Interromper a 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 propagação) 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 propagação) 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 ser concluída com êxito, a VM será removida da lista de máquinas replicantes. 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 orientações de correção para resolver.

• 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 replicação automaticamente selecionando Sim quando acionou a replicação de VM, a ferramenta tentará repará-la para você. Caso contrário, selecione a VM e, em seguida, selecione Reparar Replicação.

  Se você não optou por Reparar automaticamente a replicação ou se a etapa de reparo não funcionou para você, interrompa a replicação para a VM. Redefina o CBT na VM e reconfigure a replicação.

• Reparar replicação em fila: a VM está na fila para reparo de replicação porque outras VMs estão consumindo os recursos locais. Depois que os recursos estiverem livres, a VM será processada para replicação de reparo.

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

• Falha ao interromper a replicação/migração completa: selecione o link para entender as possíveis causas de falha e as ações a serem corrigidas (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 migração de teste pendente: após a conclusão da migração de teste, execute uma limpeza de migração de teste para evitar cobranças no Azure.
• Pronto para migrar: a VM está pronta para a migração para o Azure.
• Migração em andamento enfileirada: 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 estiverem livres, a VM será processada.
• Migração de teste/Migração em andamento: a VM está passando por uma migração de teste ou de produção. Você pode selecionar o link para verificar o trabalho de migração em andamento.
• Data, carimbo de data/hora: A migração de teste ou a migração de produção aconteceu nesta data e hora.
• –: A replicação inicial está em curso. 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 migração de teste ou migração de produção terminou com informações. Você pode selecionar o link para verificar o último trabalho de migração em busca de possíveis causas e ações a serem corrigidas (conforme aplicável).
• Falha: O trabalho de migração de teste ou de migração de produção falhou. Você pode selecionar o link para verificar o último trabalho de migração em busca de possíveis causas e ações a serem corrigidas.

Lógica de agendamento

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

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 é agendada não antes de 1 hora nem depois de 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.

  Nota

  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ê aciona a migração, ocorre um ciclo de replicação delta sob demanda (pré-failover) 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 contínuas 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, seguido pelo ciclo de replicação inicial. O ciclo de replicação delta tem a prioridade mais baixa.

Sempre que você aciona uma operação de migração, o ciclo de replicação sob demanda para a VM é agendado. Outras replicações em curso têm de esperar se estiverem a competir por recursos.

Restrições

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

• Cada dispositivo Azure Migrate dá suporte à replicação de 52 discos em paralelo.
• Cada anfitrião do ESXi suporta 8 discos. Cada host ESXi tem um buffer NFC de 32 MB. Assim, você pode agendar 8 discos no host. (Cada disco ocupa 4 MB de buffer para resposta a incidentes e recuperação de desastres.)
• Cada arquivo de dados pode ter no máximo 15 instantâneos de disco. A única exceção é quando mais de 15 discos estão conectados a uma VM.

Replicação em expansão

O Azure Migrate dá 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 Azure Migrate, 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 principal, mas isso não é necessário até que 300 VMs estejam replicando simultaneamente. Quando 300 VMs estão replicando simultaneamente, você deve implantar o dispositivo de expansão para prosseguir.

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

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

Você pode replicar a VM para a qual a replicação foi interrompida habilitando a replicação novamente. Se a VM foi migrada, você pode 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 cobranças extras por transações de armazenamento nos discos gerenciados intermediários (discos de propagação).

Em alguns casos, interromper a replicação leva tempo. O motivo é que, sempre que você interrompe a replicação, o ciclo de replicação contínua é 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 em cada ciclo de replicação, permitindo que os dados se dobrem o máximo possível antes de agendar o próximo ciclo. Como a replicação sem agente dobra nos dados, o padrão de rotatividade é mais importante do que a taxa de rotatividade. Quando um arquivo é gravado repetidamente, a taxa não tem muito impacto. No entanto, um padrão em que todos os outros setores são escritos causa alta rotatividade no próximo ciclo.

Se o ciclo de replicação delta atual sofrer atrasos devido à alta rotatividade de dados, o início do ciclo subsequente poderá ser adiado. Um volume maior de dados a ser replicado 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 uma janela de desligamento estendida para a VM de origem.

Se o tamanho do snapshot aumentar (devido ao padrão de rotatividade) a um ponto que ultrapasse a capacidade disponível do armazenamento de dados, há um 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 reduzir 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, recomendamos que você execute migrações uma VM de cada vez para evitar a contenção de recursos.

Gerenciamento da replicação

Limitação

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

Para limitar o tráfego de replicação do dispositivo Azure Migrate, você pode criar uma política como o exemplo a seguir no dispositivo. Esta política aplica-se a todas as VMs replicantes do dispositivo Azure Migrate 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 uma programação usando o script de exemplo.

Janela de blackout

O Azure Migrate fornece 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 blackout. A necessidade de uma janela de blackout pode surgir em vários cenários, como quando o ambiente de origem é restrito de recursos ou quando você deseja que a replicação aconteça apenas fora do horário comercial.

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

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

A lista de janelas blackout é uma cadeia de caracteres delimitada por pipe (|) do formato <DayOfWeek>;<StartTime>;<Duration>. Você pode especificar a duração em dias, horas e minutos. Por exemplo, você pode especificar as janelas blackout 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 blackout que começa todas as segundas-feiras às 7:00 da manhã no horário local (hora no aparelho) e dura 7 horas.

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

No cenário de expansão, o dispositivo principal e o dispositivo de expansão honram as janelas blackout de forma independente. Como prática recomendada, recomendamos manter as janelas consistentes em todos os aparelhos.

Conteúdo relacionado

• Migrar VMs VMware para o Azure (sem agente)