Migração sem agente de máquinas virtuais VMware em Migrações para Azure

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

Processo de replicação

A opção de replicação sem agente funciona usando instantâneos do VMware e a tecnologia de CBT (controle de blocos alterados) na VMware para dados de discos de máquina virtual. O diagrama de bloco a seguir mostra várias etapas envolvidas ao migrar suas máquinas virtuais usando a ferramenta de Migração e modernização.

Quando a replicação é configurada para uma máquina virtual, ela passa primeiro por uma fase de replicação inicial. Durante a replicação inicial, é tirado um instantâneo da VM, e uma cópia completa dos dados dos discos de instantâneo é replicada para os discos gerenciados na sua assinatura.

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). Na fase de replicação incremental, as alterações de dados ocorridas desde o último ciclo de replicação concluído são periodicamente replicadas e gravadas nos discos gerenciados de réplica, mantendo, assim, a replicação em sincronia com as alterações que ocorrem na VM.

A tecnologia de controle de blocos alterados (CBT) na VMware é usada para manter o controle das alterações entre os ciclos de replicação. No início do ciclo de replicação, um instantâneo de VM é tirado e o controle de blocos alterados é usado para obter as alterações entre o instantâneo atual e o último instantâneo replicado com êxito. Dessa forma, somente os dados que foram alterados desde o último ciclo de replicação concluído precisam ser replicados para manter a replicação da VM em sincronia. Ao final de cada ciclo de replicação, o instantâneo é liberado e é executada a consolidação de instantâneo para a máquina virtual.

Quando você executa a operação de migração em uma máquina virtual em replicação, 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 de replicação sob demanda, os discos gerenciados de réplica correspondentes à máquina virtual são usados para criar a máquina virtual no Azure. Logo antes de disparar a migração/failover, você deve desligar a máquina virtual local. Desligar a máquina virtual garante zero perda de dados durante a migração.

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

Ciclos de replicação

Observação

Verifique se há instantâneos presentes de tentativas de replicação anteriores ou de outros aplicativos de terceiros. O controle de alterações não poderá ser habilitado na VM se os instantâneos já estiverem presentes para a VM. Exclua os instantâneos existentes ou habilite o controle de bloco 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 pelo Azure. Um ciclo de replicação completo consiste nas seguintes etapas:

1. Criar um instantâneo do VMware para cada disco associado à VM
2. Carregar dados para a conta de armazenamento de log no Azure
3. Liberar instantâneo
4. Consolidar discos de VMware

Um ciclo é considerado completo depois que os discos são consolidados.

Componentes envolvidos na replicação

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

• Agente DRA
• Agente de gateway

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

Componente	Region	Assinatura	Descrição
Cofre dos Serviços de Recuperação	Região do projeto de Migrações para Azure	Assinatura do projeto de Migrações para Azure	Usado para orquestrar a replicação de dados
Barramento de Serviço	Região de destino	Assinatura do projeto de Migrações para Azure	Usado para comunicação entre o serviço de nuvem e o dispositivo de Migrações para Azure
Conta de armazenamento de log	Região de destino	Assinatura do projeto de Migrações para Azure	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	Assinatura do projeto de Migrações para Azure	Usado para armazenar os estados do computador durante a replicação
Key vault	Região de destino	Assinatura do projeto de Migrações para Azure	Gerencia cadeias de conexão do barramento de serviço e as chaves de acesso da conta de armazenamento do registro
Máquina Virtual do Azure	Região de destino	Assinatura de destino	VM criada no Azure ao migrar
Azure Managed Disks	Região de destino	Assinatura de destino	Discos gerenciados anexados às VMs do Azure
Placas de interface de rede	Região de destino	Assinatura de destino	NICs anexadas às VMs criadas no Azure

Permissões exigidas

Ao iniciar a replicação pela primeira vez, o usuário conectado deve ter as seguintes funções atribuídas:

• Proprietário ou colaborador e administrador de acesso do usuário no grupo de recursos do projeto de Migrações para Azure e no grupo de recursos de destino

Nas replicações subsequentes, o usuário conectado deve ter as seguintes funções atribuídas:

• Proprietário ou colaborador no grupo de recursos do projeto de Migrações para Azure e no grupo de recursos de destino

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

Integridade de 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 está sendo replicado para o disco de destino. A validação é executada 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, é criado o 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, é criado um bitmap. Depois que a transferência de dados é concluída com êxito, o serviço de nuvem compara os dois bitmaps para garantir que nenhum bloco alterado foi perdido. Caso haja incompatibilidade entre os bitmaps, o ciclo será considerado com falha. Como cada ciclo é uma ressincronização, 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 replicados dos discos de origem. Cada bloco alterado a ser carregado é compactado e criptografado antes de ser gravado como um blob na conta de armazenamento de log. Computamos 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, a soma de verificação dos dados é calculada e comparada 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 é uma ressincronização, a incompatibilidade será corrigida no próximo ciclo.

Segurança

O dispositivo de Migrações para Azure compacta dados e os criptografa antes de carregar. Os dados são transmitidos por um canal de comunicação seguro por https e usam o TLS 1.2 ou posterior. Além disso, o Armazenamento do Azure criptografa automaticamente os 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á alguns estados possíveis:

• Replicação inicial na fila: a VM entra na fila para a replicação (ou migração) quando talvez haja outras VMs consumindo os recursos locais (durante a replicação ou migração). Depois que os recursos são liberados, essa VM é processada.
• Replicação inicial em andamento: a VM está sendo agendada para replicação inicial.
• Replicação inicial: a VM está passando pela replicação inicial. Quando a VM estiver passando pela replicação inicial, não será possível continuar a migração ou 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 talvez esteja passando por um ciclo de replicação delta que replica a variação 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 daqui um tempo.
• Em pausa: os ciclos de replicação foram pausados. Os ciclos de replicação podem ser retomados executando uma operação de retomada de replicação.
• 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.
• Retomada 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 de replicação está em andamento. Ao interromper a replicação, os discos gerenciados intermediários (discos de semente) criados durante a replicação serão excluídos. Saiba mais.
• Concluir migração em andamento: a limpeza de migração está em andamento. Ao concluir a migração, os discos gerenciados intermediários (discos de semeadura) criados durante a replicação serão excluídos. Saiba mais.
• –: quando a VM tiver sido migrada com êxito e/ou quando você tiver interrompido a replicação, o status mudará para “-“. Depois que você interromper ou concluir a migração, e a operação for finalizada com êxito, a VM será removida da lista de máquinas de replicação. 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 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ê tiver optado por Reparar automaticamente a replicação selecionando Sim ao disparar a replicação da VM, a ferramenta tentará repará-la. Ou selecione a VM e clique em Reparar Replicação. Se não tiver optado por Reparar automaticamente a replicação ou se a etapa acima não tiver funcionado, pare a replicação da máquina virtual, redefina o controle do bloco alterado na máquina virtual e reconfigure a replicação.
• Reparar a replicação na fila: a VM está na fila para reparar a replicação, pois há outras VMs que estão consumindo os recursos locais no momento. Depois que os recursos forem liberados, a VM será processada para reparar a replicação.
• Ressincronizar (x%): a VM está passando por uma ressincronização de dados. Isso poderá acontecer se houver algum problema/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).

Observação

Algumas VMs são colocadas no estado em fila para garantir o 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 ou da migração de teste

• Migração de teste pendente: a VM está na fase de replicação delta e agora você pode executar a migração de teste (ou a migração).
• Limpeza da 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 encargos no Azure.
• Pronto para migrar: a VM está pronta para ser migrada ao Azure.
• Migração em andamento na fila: a VM está na fila para a migração, pois há outras VMs consumindo os recursos locais durante a replicação (ou migração). Depois que os recursos são liberados, a VM é processada.
• Testar migração/migração em andamento: a VM está passando por uma migração/migração de teste. Você pode clicar no link para verificar o andamento do trabalho de migração.
• Data, carimbo de data/hora: a data de migração ou do teste de migração e o carimbo de data/hora.
• –: a replicação inicial está em andamento. Você pode executar uma migração ou um teste de 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 ou de teste de migraçã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).
• Com falha: o trabalho de migração ou de teste de migraçã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 a replicação é configurada para uma VM. Ela é seguida 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[máx[1 hora, (Tempo do ciclo de replicação delta anterior/2)], 12 horas]

Ou seja, a próxima replicação delta será agendada no máximo uma hora e no máximo 12 horas. Por exemplo, se uma VM levar quatro horas em um ciclo de replicação delta, o próximo ciclo será agendado em duas horas, e não na hora seguinte.

Observação

A lógica de agendamento muda 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ê dispara a migração, é executado um ciclo de replicação delta sob demanda (ciclo de replicação delta de pré-failover) na VM antes da migração.

Priorização de VMs em 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 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 prioridade mais baixa.

Ou seja, sempre que uma operação de migração for disparada, o ciclo de replicação sob demanda da VM será agendado e outras replicação em andamento ficarão em espera se estiverem competindo por recursos.

Restrições:

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

• Cada dispositivo de Migrações para Azure oferece 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, podemos agendar oito discos no host (cada disco ocupa 4 MB de buffer para IR e DR).
• Cada armazenamento de dados pode ter um máximo de 15 instantâneos de disco. A única exceção é quando uma VM tem mais de 15 discos anexados a ela.

Replicação de expansão

As Migrações para Azure oferecem suporte à replicação simultânea de 500 máquinas virtuais. Se você planeja replicar mais de 300 máquinas virtuais, deverá implantar um dispositivo de expansão. O dispositivo de expansão é semelhante a um dispositivo primário de 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 após configurar o dispositivo primário, mas não é necessário até que haja 300 VMs replicando simultaneamente. Quando houver 300 VMs replicando simultaneamente, você deverá implantar o dispositivo de expansão para continuar.

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

Ao interromper a replicação, os discos gerenciados intermediários (discos de semente) criados durante a replicação serão excluídos. Você só pode interromper a replicação durante uma replicação ativa. Você pode selecionar Concluir a migração para interromper a replicação depois que a VM foi migrada.

A VM cuja a replicação é interrompida pode ser replicada habilitando a replicação novamente. Se a VM foi migrada, você poderá retomar a replicação e a migração novamente.

Como melhor prática, você sempre deve concluir a migração depois que a VM for migrada com êxito para o Azure a fim de garantir que não sejam gerados encargos extras para transações de armazenamento nos discos gerenciados intermediários (discos de semeadura). Em alguns casos, observe que levará algum tempo para parar a replicação. Isso ocorre porque, sempre que você para a replicação, o ciclo de replicação em andamento é concluído (somente quando a VM está em sincronização delta) antes de os artefatos serem excluídos.

Impacto da rotatividade

Tentamos minimizar a quantidade de transferência de dados em cada ciclo de replicação ao permitirmos que os dados dobrem o máximo possível antes de agendarmos 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.

Gerenciamento de 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 de Migrações para Azure para restringir o tráfego de replicação do dispositivo criando uma política como esta:

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

Observação

Isso se aplica a todas as VMs de replicação do dispositivo de Migrações para Azure ao mesmo tempo.

Você também pode aumentar ou 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 por meio do qual os clientes podem especificar o intervalo de tempo durante o qual não querem nenhuma replicação em andamento. Esse intervalo de tempo é chamado de janela de blecaute. A necessidade de uma janela de blecaute pode surgir em vários cenários, como quando o ambiente de origem tem restrição de recursos ou quando os clientes querem que a replicação seja apenas durante horários não comerciais etc.

Observação

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

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

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

A lista de janelas de blecaute é uma cadeia de caracteres delimitada por "|" no formato "DayOfWeek;StartTime;Duration". A duração pode ser especificada em dias, horas e minutos. Por exemplo, as janelas de blecaute 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 limpeza que começa todas as segundas-feiras às 7:00 hora local (hora do dispositivo) e com duração de 7 horas.

Depois que o GatewayDataWorker.json for criado/atualizado com esses conteúdos, o serviço de gateway no dispositivo precisará ser reiniciado 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.

Próximas etapas

Migrar VMs da VMware com a migração sem agente.