Arquitetura de migração sem agente

Este artigo descreve os conceitos de replicação ao migrar VMs VMware usando o método de migração sem agente da ferramenta de migração e modernização.

Nota

Esta documentação completa do cenário de migração VMware está atualmente em visualização. Para obter mais informações sobre como usar o Azure Migrate, consulte a documentação do produto 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 de máquinas virtuais. O diagrama de blocos a seguir mostra várias etapas envolvidas ao migrar suas máquinas virtuais usando a ferramenta Migração e modernização.

Quando a replicação é configurada para uma máquina virtual, ela passa primeiro por uma fase inicial de replicação. Durante a replicação inicial, um instantâneo da VM é tirado e uma cópia completa dos dados dos discos de instantâneo é replicada 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). Na fase de replicação incremental, 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 da réplica, mantendo a replicação sincronizada com as alterações que ocorrem na VM.

A tecnologia CBT (changed block tracking, rastreamento de blocos alterados) da VMware é usada para acompanhar as alterações entre os ciclos de replicação. No início do ciclo de replicação, um instantâneo da VM é tirado e o controle de bloco alterado é usado para obter as alterações entre o instantâneo atual e o último instantâneo replicado com êxito. Somente os dados alterados desde o ciclo de replicação concluído anteriormente são replicados para manter a replicação da VM sincronizada. No final de cada ciclo de replicação, o snapshot é liberado e a consolidação de snapshot é executada para a máquina virtual.

Quando você executa a operação de migração em uma máquina virtual replicante, há um ciclo de replicação delta sob demanda que replica as alterações restantes desde o último ciclo de replicação. Após a conclusão do ciclo sob demanda, os discos gerenciados de réplica correspondentes à máquina virtual são usados para criar a máquina virtual no Azure. Antes de acionar a migração/failover, você deve desligar a máquina virtual local. O desligamento da máquina virtual garante perda zero de dados durante a migração.

Quando a migração for bem-sucedida e a VM for inicializada no Azure, certifique-se de interromper a replicação da VM. A interrupção da replicação excluirá os discos intermediários (discos de propagação) que foram criados durante a replicação de dados e você também evitará incorrer em encargos adicionais associados às transações de armazenamento nesses discos.

Ciclos de replicação

Nota

Certifique-se de verificar se há instantâneos presentes de tentativas de replicação anteriores ou de outros aplicativos de terceiros. O controle de alterações não pode ser habilitado na VM se os instantâneos já estiverem presentes para a VM. Exclua os instantâneos existentes ou habilite o controle de blocos de alterações na VM.

Os ciclos de replicação referem-se ao processo periódico de transferência de dados do ambiente local para os discos gerenciados do Azure. Um ciclo completo de replicação consiste nas seguintes etapas:

1. Crie snapshots VMware para cada disco associado à VM
2. Carregar dados para registrar a conta de armazenamento no Azure
3. Instantâneo de lançamento
4. Consolide discos VMware

Diz-se que um ciclo está completo quando os discos são consolidados.

Componentes envolvidos na replicação

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

• Agente DRA
• Agente de gateway

Componentes do Azure: A tabela a seguir resume vários artefatos do Azure que são criados ao usar o método sem agente de migração de VM VMware.

Componente	País/Região	Subscrição	Description
Cofre dos serviços de recuperação	Região do projeto Azure Migrate	Subscrição do projeto Azure Migrate	Usado para orquestrar a replicação de dados
Service Bus	Região de destino	Subscrição do projeto Azure Migrate	Usado para comunicação entre o serviço de nuvem e o dispositivo Azure Migrate
Conta de armazenamento de log	Região de destino	Subscrição do projeto Azure Migrate	Usado para armazenar dados de replicação, que são lidos pelo serviço e aplicados no disco gerenciado do cliente
Conta de armazenamento de gateway	Região de destino	Subscrição do projeto Azure Migrate	Usado para armazenar estados da máquina durante a replicação
Key Vault	Região de destino	Subscrição do projeto Azure Migrate	Gerencia cadeias de conexão para barramento de serviço e chaves de acesso para a conta de armazenamento de log
Máquina Virtual do Azure	Região de destino	Subscrição de destino	VM criada no Azure quando você migra
Managed Disks do Azure	Região de destino	Subscrição de destino	Discos gerenciados anexados a VMs do Azure
Placas de interface de rede	Região de destino	Subscrição de destino	As NICs anexadas às VMs criadas no Azure

Permissões necessárias

Quando você inicia a replicação pela primeira vez, o usuário conectado deve receber 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 receber 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 descritas acima, o usuário conectado precisaria 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 que garantem a integridade dos dados entre o disco local (disco de origem) e o disco de réplica no Azure (disco de destino).

1. Primeiro, validamos se cada setor que foi alterado no disco de origem é replicado para o disco de destino. A validação é realizada 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 bitmap é criado 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, um bitmap é criado. Quando a transferência de dados for concluída com êxito, o serviço de nuvem compara os dois bitmaps para garantir que nenhum bloco alterado seja perdido. Caso haja alguma incompatibilidade entre os bitmaps, o ciclo é considerado falha. Como cada ciclo é ressincronizado, a incompatibilidade será corrigida no próximo ciclo.

2. Em seguida, garantimos 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 escrito como um blob na conta de armazenamento de log. Calculamos a soma de verificação deste bloco antes da compressão. Essa soma de verificação é armazenada como metadados junto com os dados compactados. Após a descompressão, a soma de verificação dos dados é calculada e comparada 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 será corrigida no próximo ciclo.

Segurança

O dispositivo Azure Migrate compacta dados e criptografa antes de carregar. Os dados são transmitidos através de um canal de comunicação seguro através de https e utilizam 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á alguns estados possíveis:

• Replicação inicial em fila: a VM é enfileirada para replicação (ou migração), pois pode haver outras VMs que estão consumindo os recursos locais (durante a replicação ou migração). Quando os recursos estiverem livres, essa VM será processada.
• Replicação inicial em andamento: a VM está sendo 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, você não pode prosseguir com a migração e a migração de teste. Só é possível interromper a replicação neste estágio.
• Replicação inicial (x%): A replicação inicial está ativa e progrediu em x%.
• 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 será pausada em algum tempo.
• Em pausa: os ciclos de replicação foram pausados. Os ciclos de replicação podem ser retomados executando uma operação de replicação de retomada.
• Retomar na fila: a VM está na fila para retomar a replicação, pois há outras VMs que 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 em x%.
• 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 serão excluídos. Mais informações.
• Migração completa em andamento: a limpeza da migração está em andamento. Quando você concluir a migração, os discos gerenciados intermediários (discos de propagação) criados durante a replicação serão excluídos. Mais informações.
• – : Quando a VM tiver migrado com êxito e/ou quando você tiver interrompido a replicação, o status mudará para "-". Depois de interromper a replicação/concluir a migração e a operação for concluída com êxito, a VM será removida da lista de máquinas replicantes. Você pode encontrar a VM na guia 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ê tiver optado 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 selecione Reparar replicação. Se você não optou por Reparar automaticamente a replicação ou se a etapa acima não funcionou para você, interrompa a replicação para a máquina virtual, redefina o rastreamento de bloco alterado na máquina virtual e reconfigure a replicação.
• Reparar a replicação em fila: a VM está na fila para reparo de replicação, pois há outras VMs que estão consumindo os recursos locais. Quando 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. Isso pode acontecer se houver algum problema/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).

Nota

Algumas VMs são colocadas em estado de fila para garantir um impacto mínimo no ambiente de origem devido ao consumo de IOPS de armazenamento. Essas VMs são processadas com base na lógica de agendamento, conforme descrito na próxima seção.

Status da migração/migração de teste

• Migração de teste pendente: a VM está em fase de replicação delta e agora você pode executar a migração (ou migração) de teste.
• 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 ser migrada para o Azure.
• Migração em andamento enfileirada: a VM é enfileirada para migração, pois há outras VMs que estão consumindo os recursos locais durante a replicação (ou migração). Quando os recursos estiverem livres, a VM será processada.
• Migração de teste/Migração em andamento: A VM está passando por uma migração/migração de teste. Você pode selecionar o link para verificar o trabalho de migração em andamento.
• Data, carimbo de data/hora: A data e o carimbo de data/hora da migração/migração de teste.
• –: A replicação inicial está em curso. Você pode executar uma migração ou testar a migraçã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/migração de teste foi concluído 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/migração de teste 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 a replicação é configurada para uma VM. É seguido por replicações incrementais (replicações delta).

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

• O primeiro ciclo de replicação delta é agendado imediatamente após a conclusão 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 hora, (Tempo do ciclo de replicação delta anterior/2)], 12 horas]

Ou seja, a próxima replicação delta será agendada não antes de uma hora e não mais de 12 horas. Por exemplo, se uma VM leva quatro horas para um ciclo de replicação delta, o próximo ciclo de replicação delta é agendado em duas 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 e os ciclos subsequentes seguem a lógica de agendamento descrita acima.

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

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 pré-failover (replicação delta sob demanda) tem a prioridade mais alta, seguido pelo ciclo de replicação inicial. O ciclo de replicação delta tem a menor prioridade.

Ou seja, sempre que uma operação de migração é acionada, o ciclo de replicação sob demanda para a VM é agendado e outras replicações contínuas ficam em segundo plano se estiverem competindo por recursos.

Restrições:

Usamos as restrições a seguir para garantir que não excedemos os limites de IOPS nas SANs.

• Cada aplicação do Azure Migrate suporta a 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, podemos agendar 8 discos no host (Cada disco ocupa 4 MB de buffer para IR, DR).
• Cada arquivo de dados pode ter no máximo 15 instantâneos de disco. A única exceção é quando uma VM tem mais de 15 discos ligados a si.

Replicação em expansão

O Azure Migrate dá suporte à replicação simultânea de 500 máquinas virtuais. Ao planejar a replicação de mais de 300 máquinas virtuais, você deve implantar um dispositivo de expansão. O dispositivo de expansão é semelhante a um dispositivo principal do Azure Migrate, mas consiste apenas em 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 após configurar o dispositivo principal, mas não é necessário até que haja 300 VMs replicando simultaneamente. Quando há 300 VMs replicando simultaneamente, você deve implantar o dispositivo de expansão para prosseguir.

Interromper a replicação/concluir a migração

Quando você interrompe a replicação, os discos gerenciados intermediários (discos de propagação) criados durante a replicação serã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.

A VM para a qual a replicação foi interrompida pode ser replicada 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 tiver migrado com êxito para o Azure para garantir que você não incorra em cobranças extras por transações de armazenamento nos discos gerenciados intermediários (discos semente). Em alguns casos, você notará que parar a replicação leva tempo. Isso ocorre porque 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 de excluir os artefatos.

Impacto da rotatividade

Tentamos 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 agendarmos 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.

Gerenciamento da replicação

Limitação

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

Você pode criar uma política no dispositivo Azure Migrate para limitar o tráfego de replicação do dispositivo criando uma política como esta:

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

Nota

Isso é aplicável a todas as VMs replicantes do dispositivo Azure Migrate simultaneamente.

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 blackout

O Azure Migrate fornece um mecanismo baseado em configuração através do qual os clientes podem especificar o intervalo de tempo durante o qual não desejam que nenhuma replicação prossiga. Esse intervalo de tempo é 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 os clientes querem que a replicação passe apenas fora do horário comercial, etc.

Nota

• Os ciclos de replicação existentes no início da janela de blackout serão concluídos antes que a replicação seja pausada.
• Para qualquer migração iniciada durante a janela de blackout, a replicação final não será executada, fazendo com que a migração falhe.

Uma janela blackout pode ser especificada para o dispositivo criando/atualizando o GatewayDataWorker.json de arquivo em C:\ProgramData\Microsoft Azure\Config. Um arquivo típico seria do tipo:

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

A lista de janelas blackout é uma string delimitada "|" do formato "DayOfWeek; StartTime; Duração". A duração pode ser especificada em dias, horas e minutos. Por exemplo, as janelas blackout podem ser especificadas 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 acima indica uma janela de 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 que o GatewayDataWorker.json é criado/atualizado com esses conteúdos, o serviço Gateway no dispositivo precisa ser reiniciado 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.

Próximos passos

Migre VMs VMware com migração sem agente.