Compartilhar via

Migração e modernização: perguntas comuns

  • Artigo

Este artigo responde a perguntas comuns sobre a ferramenta Migração e modernização. Se você tiver outras dúvidas, confira estes recursos:

Cuidado

Este artigo faz referência ao CentOS, uma distribuição do Linux que tem um status de fim de vida útil. Considere seu uso e planejamento adequados. Para obter mais informações, veja as Diretrizes de fim de vida útil do CentOS.

Perguntas gerais

Quais são as opções de migração com a ferramenta de migração e modernização?

A ferramenta Migração e modernização oferece migração sem agente e baseada em agente para migrar seus servidores de origem e VMs (máquinas virtuais) para o Azure.

Independentemente de qual opção de migração você escolher, a primeira etapa para migrar um servidor usando a ferramenta Migração e modernização é iniciar a replicação para o servidor. Esse processo executa uma replicação inicial de seus dados de VM/servidor para o Azure. Depois que a replicação inicial é concluída, uma replicação contínua (sincronização delta) é estabelecida que migra dados incrementais para o Azure. Depois que a operação atingir o estágio de sincronização delta, você poderá optar por migrar para o Azure a qualquer momento.

Considere as informações a seguir ao decidir qual opção de migração usar.

As migrações sem agente não exigem que você implante nenhum software (agentes) nas VMs/servidores de origem que você está migrando. A opção sem agente orquestra a replicação integrando-se com a funcionalidade fornecida pelo provedor de virtualização.

Opções de replicação sem agente estão disponíveis para VMs VMware e VMs Hyper-V.

As migrações baseadas em agente exigem que você instale o software de Migrações para Azure (agentes) nas VMs de origem que você está migrando. A opção baseada em agente não depende da plataforma de virtualização para o uso da funcionalidade de replicação. Ele pode ser usado com qualquer servidor que execute uma arquitetura x86/x64 e uma versão de um sistema operacional compatível com o método de replicação baseado em agente.

A opção de migração baseada em agente pode ser usada para:

A migração baseada em agente trata seus computadores como servidores físicos para migração.

A migração sem agente oferece mais conveniência e simplicidade do que as opções de replicação baseadas em agente para VMs VMware e Hyper-V. No entanto, talvez você queira considerar o uso do cenário baseado em agente para os seguintes casos de uso:

  • Ambientes restritos por IOPS (operações de entrada/saída por segundo): a replicação sem agente usa instantâneos e consome IOPS de armazenamento/largura de banda. Recomendamos o método de migração baseado em agente se houver restrições de armazenamento/IOPS em seu ambiente.

  • Nenhum vCenter Server: se você não tiver um vCenter Server, poderá tratar suas VMs VMware como servidores físicos e usar o fluxo de trabalho de migração baseado em agente.

Para saber mais, examine Selecione uma opção de migração do VMware.

Quais geografias têm suporte para a migração com as Migrações para Azure?

Examine as geografias compatíveis com nuvens públicas e nuvens governamentais.

Posso usar o mesmo projeto de Migrações para Azure a fim de fazer a migração para várias regiões?

Embora você possa criar avaliações para várias regiões em um projeto de Migrações para Azure, um projeto de Migrações para Azure pode ser usado para migrar servidores para apenas uma região do Azure. Você pode criar mais projetos de Migrações para Azure para outras regiões.

  • Para migrações de VMware sem agente, a região de destino é bloqueada quando você habilita a primeira replicação.
  • Para migrações baseadas em agente (VMware, servidores físicos e servidores de outras nuvens), a região de destino é bloqueada quando o botão Criar Recursos é selecionado no portal quando você configura o dispositivo de replicação.
  • Para migrações do Hyper-V sem agente, a região de destino é bloqueada quando o botão Criar Recursos é selecionado no portal quando você configura o provedor de replicação do Hyper-V.

Posso usar o mesmo projeto de Migrações para Azure a fim de fazer a migração para várias assinaturas?

Sim, você pode usar o mesmo projeto de Migrações para Azure para migrar para várias assinaturas com o mesmo locatário do Azure na mesma região de destino. Você pode selecionar a assinatura de destino ao habilitar a replicação para um computador ou um conjunto de computadores.

A região de destino está bloqueada:

  • Após a primeira replicação para migrações VMware sem agente.
  • Durante a instalação do dispositivo de replicação para migrações baseadas em agente.
  • Durante a instalação do provedor do Hyper-V para migrações do Hyper-V sem agente.

As Migrações para Azure dão suporte ao Azure Resource Graph?

Atualmente, as Migrações para Azure não estão integradas ao Azure Resource Graph. Ele dá suporte à execução de consultas relacionadas ao Azure Resource Graph.

Como os dados são transmitidos de um ambiente local para o Azure? Eles são criptografados antes da transmissão?

Com a replicação sem agente, o dispositivo de Migrações para Azure compacta e criptografa dados antes de carregá-los. 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 seus dados quando eles persistem os dados na nuvem (criptografia em repouso).

Posso usar o cofre dos Serviços de Recuperação criado pelas Migrações para Azure para cenários de recuperação de desastre?

Não recomendamos usar o cofre de serviços de recuperação criado pelas Migrações para Azure para cenários de recuperação de desastre, pois isso pode resultar em falhas de replicação inicial nas Migrações para Azure.

Qual é a diferença entre as operações de migração de teste e de migração?

A opção Migração de teste permite testar e validar migrações antes da migração real. A Migração de teste funciona permitindo que você use um ambiente de área restrita no Azure para testar as VMs antes da migração real. Uma rede virtual de teste especificada demarca o ambiente de área restrita. A operação de Migração de teste não causa interrupções, desde que a rede virtual de teste esteja suficientemente isolada. Uma rede virtual é suficientemente isolada quando você projeta as regras de conexão de entrada e saída para evitar conexões indesejadas. Por exemplo: você restringe a conexão a computadores locais.

Os aplicativos podem continuar a ser executados na origem enquanto você executa testes em uma cópia clonada em um ambiente de área restrita isolado. Você pode executar vários testes conforme necessário para validar a migração, executar testes de aplicativos e resolver problemas antes da migração real.

Captura de tela que mostra a diferença entre um teste e uma migração real.

Há uma opção de reversão para Migrações para Azure?

Você pode usar a opção de Migração de teste para validar a funcionalidade e o desempenho do aplicativo no Azure. Você pode executar qualquer número de migrações de teste e pode fazer a migração final depois de estabelecer confiança por meio da operação Migração de Teste.

Uma migração de teste não afeta o computador local, que permanece operacional e continua replicando até você executar a migração real. Se houver erros durante o UAT (teste de aceitação do usuário) para a migração de teste, você poderá optar por adiar a migração final e manter sua VM/servidor de origem em execução e replicação no Azure. Você pode executar novamente a migração final depois de resolver os erros.

Observação

Depois de executar uma migração final para o Azure e o computador de origem local for desligado, você não poderá executar uma reversão do Azure para seu ambiente local.

Posso selecionar a rede virtual e a sub-rede para serem usadas para migrações de teste?

Você pode selecionar uma rede virtual para migrações de teste. As Migrações para Azure selecionam automaticamente uma sub-rede com base na seguinte lógica:

  • Se você especificar uma sub-rede de destino (diferente do padrão) como uma entrada ao habilitar a replicação, as Migrações para Azure priorizarão uma sub-rede com o mesmo nome na rede virtual usada para a migração de teste.
  • Se uma sub-rede com o mesmo nome não for encontrada, as Migrações para Azure selecionarão em ordem alfabética a primeira sub-rede disponível que não seja um gateway, gateway de aplicativo, firewall ou sub-rede do Azure Bastion.

Por que o botão de migração de teste está desabilitado para meu servidor?

O botão Migração de teste pode estar desabilitado nos seguintes cenários:

  • Não é possível iniciar uma migração de teste até que uma replicação inicial seja concluída para a VM. O botão Migração de teste é desabilitado até que o processo de replicação inicial seja concluído. Você pode executar uma migração de teste depois que sua VM estiver em um estágio de sincronização delta.
  • O botão poderá ser desabilitado se uma migração de teste tiver sido concluída, mas uma limpeza de migração de teste não tiver sido executada para essa VM. Execute uma limpeza de migração de teste e repita a operação.

O que acontecerá se eu não limpar minha migração de teste?

Uma migração de teste simula a migração real criando uma VM do Azure de teste usando dados replicados. O servidor é implantado com uma cópia pontual dos dados replicados para o grupo de recursos de destino (selecionado quando você habilita a replicação) com um sufixo -test. As migrações de teste destinam-se a validar a funcionalidade do servidor para minimizar problemas pós-migração.

Se a migração de teste não for limpa após o teste, a VM de teste continuará sendo executada no Azure e incorre em encargos. Para a limpeza após uma migração de teste, acesse a exibição dos Computadores de replicação na ferramenta Migração e modernização e use a ação Limpar migração de teste no computador.

Como saber se minha VM migrou com êxito?

Depois de migrar sua VM/servidor com êxito, você pode exibir e gerenciar a VM no painel Máquinas virtuais. Conecte-se à VM migrada para validá-la.

Você também pode examinar o status do trabalho da operação para verificar se a migração foi concluída com êxito. Se você vir erros, resolva-os e tente novamente a operação de migração.

O que acontecerá se eu não parar a replicação após a migração?

Quando você interrompe a replicação, a ferramenta Migração e modernização limpa os discos gerenciados na assinatura que foi criada para a replicação.

O que acontece se eu não selecionar Concluir migração após uma migração?

Quando você seleciona Concluir migração, a ferramenta Migração e modernização limpa os discos gerenciados na assinatura que foram criados para replicação. Se você não selecionar Concluir migração após a migração, os encargos para esses discos continuarão sendo gerados. A conclusão da migração não afeta os discos anexados aos computadores que já foram migrados.

Como posso migrar computadores baseados em UEFI para o Azure como VMs da geração 1 do Azure?

A ferramenta Migração e modernização migra computadores baseados em UEFI para o Azure como VMs de geração 2 do Azure. Se você quiser migrá-los para VMs da geração 1 do Azure, converta o tipo de inicialização em BIOS antes de iniciar a replicação e use a ferramenta Migração e modernização para fazer a migração para o Azure.

As Migrações para Azure convertem computadores baseados em UEFI em computadores baseados em BIOS e os migra para o Azure como VMs da geração 1 do Azure?

A ferramenta Migração e modernização migra todos os computadores baseados em UEFI para o Azure como VMs da geração 2 do Azure. Não damos mais suporte à conversão de VMs baseadas em UEFI em VMs baseadas em BIOS. Todos os computadores baseados em BIOS são migrados para o Azure apenas como VMs de geração 1 do Azure.

Quais sistemas operacionais têm suporte para a migração de computadores baseados em UEFI para o Azure?

Observação

Se uma versão principal de um sistema operacional tiver suporte na migração sem agente, todas as versões secundárias e kernels serão automaticamente compatíveis.

Sistemas operacionais com suporte para computadores baseados em UEFI VMware sem agente para o Azure Hyper-V sem agente para o Azure VMware baseado em agente, nuvens físicas e outras para o Azure
Windows Server 2025, 2022, 2019, 2016, 2012 R2, 2012 N N S
Windows 11 pro, Windows 11 Enterprise N N S
Windows 10 pro, Windows 10 Enterprise N N S
SUSE Linux Enterprise Server 15 SP1, SP2, SP3, SP4, SP5, SP6 N N S
SUSE Linux Enterprise Server 12 SP4 N N S
Ubuntu Server 22.04 LTS, 20.04 LTS, 18.04 LTS, 16.04 LTS N N S
RHEL 9.x, 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x N N S
CentOS Stream N N S
Oracle Linux 9, 8, 7.7-CI, 7.7, 6 N N S

Posso migrar controladores de domínio do Active Directory usando as Migrações para Azure?

A ferramenta Migração e modernização é independente de aplicativo e funciona para a maioria dos aplicativos. Quando você migra um servidor usando a ferramenta Migração e modernização, todos os aplicativos instalados no servidor são migrados com ele. No entanto, métodos de migração alternativos podem ser mais adequados para migrar alguns aplicativos.

Para o Active Directory, o tipo de ambiente pode ser um fator. Em um ambiente híbrido com um site local conectado ao seu ambiente do Azure, você pode estender seu diretório para o Azure adicionando controladores de domínio extras e configurando a replicação do Active Directory. Você pode usar a ferramenta Migração e modernização se estiver:

  • Migrar para um ambiente isolado no Azure que exige seus próprios controladores de domínio.
  • Testando aplicativos em um ambiente de área restrita.

Posso atualizar meu sistema operacional durante a migração?

A ferramenta Migração e modernização agora dá suporte à atualização do sistema operacional Windows durante a migração. Essa opção não está disponível no momento para Linux. Obtenha mais detalhes sobre a atualização do sistema operacional Windows.

Preciso do VMware vCenter para migrar VMs VMware?

Para migrar VMs do VMware usando a migração baseada em agente do VMware ou sem agente, o vCenter Server deve gerenciar os hosts ESXi nos quais as VMs estão localizadas. Se você não tiver o vCenter Server, poderá migrar VMs VMware como servidores físicos. Saiba mais.

Posso consolidar várias VMs de origem em uma VM durante a migração?

Atualmente, a ferramenta Migração e modernização dá suporte a migrações similares. Não damos suporte à consolidação de servidores durante a migração.

Haverá suporte para o Windows Server 2008 e 2008 R2 no Azure após a migração?

Você pode migrar seus servidores locais do Windows Server 2008 e 2008 R2 para VMs do Azure e obter atualizações de segurança estendidas por três anos após as datas de fim de suporte sem custo adicional acima do custo de execução da VM. Você pode usar a ferramenta Migração e modernização para migrar suas cargas de trabalho do Windows Server 2008 e 2008 R2.

Como fazer para migrar o Windows Server 2003 em execução no VMware/Hyper-V para o Azure?

O suporte estendido do Windows Server 2003 terminou em 14 de julho de 2015. A equipe de suporte do Azure continua a ajudar a solucionar problemas relacionados à execução do Windows Server 2003 no Azure. No entanto, esse suporte é limitado a problemas que não exigem patches nem solução no nível do sistema operacional.

Recomendamos que você migre seus aplicativos para instâncias do Azure executando uma versão mais recente do Windows Server para garantir que você esteja usando efetivamente a flexibilidade e a confiabilidade da nuvem do Azure.

Se você ainda optar por migrar o Windows Server 2003 para o Azure, poderá usar a ferramenta Migração e modernização se a implantação do Windows Server for uma VM executada no VMware ou no Hyper-V. Para obter mais informações, consulte Preparar seus computadores Windows Server 2003 para migração.

Migração sem agente do VMware

Como a migração sem agente funciona?

A ferramenta Migração e modernização fornece opções de replicação sem agente para a migração de VMs VMware e Hyper-V executando Windows ou Linux. A ferramenta fornece outra opção de replicação baseada em agente para servidores Windows e Linux. Essa outra opção pode ser usada para migrar servidores físicos e VMs x86/x64 em provedores como VMware, Hyper-V, AWS e GCP.

A replicação baseada em agente requer que você instale o software do agente na VM/servidor que você está migrando. A opção sem agente não exige que você instale software nas VMs, o que pode oferecer conveniência e simplicidade.

A opção de replicação sem agente usa mecanismos fornecidos pelo provedor de virtualização (VMware ou Hyper-V). Para VMs VMware, o mecanismo de replicação sem agente usa instantâneos VMware e tecnologia de controle de blocos alterados do VMware para replicar dados de discos de VM. Muitos produtos de backup usam um mecanismo semelhante. Para VMs do Hyper-V, o mecanismo de replicação sem agente usa instantâneos de VM e a funcionalidade de controle de alterações da réplica do Hyper-V para replicar dados de discos de VM.

Quando a replicação é configurada para uma VM, a VM passa pela primeira vez por uma fase inicial de replicação. Durante a replicação inicial, um instantâneo de VM é obtido e uma cópia completa dos dados dos discos de instantâneo é replicada para discos gerenciados em 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).

A fase de replicação incremental aborda as alterações de dados que ocorreram desde o último ciclo de replicação concluído. Essas alterações são replicadas periodicamente e aplicadas aos discos gerenciados por réplica. Esse processo mantém a replicação em sincronia com as alterações na VM.

A tecnologia de controle de blocos alterados do VMware controla as alterações entre ciclos de replicação para VMs VMware. No início do ciclo de replicação, um instantâneo de VM é tirado e o controle de bloco alterado é usado para compilar as alterações entre o instantâneo atual e o último instantâneo replicado com êxito. Para manter a replicação da VM em sincronia, somente os dados que foram alterados desde o último ciclo de replicação concluído precisam ser replicados.

No final de cada ciclo de replicação, o instantâneo é lançado e a consolidação de instantâneos é executada para a VM. Da mesma forma, para VMs do Hyper-V, o mecanismo de controle de alterações de réplica do Hyper-V mantém o controle das alterações entre ciclos de replicação consecutivos.

Ao executar a operação Migrate em uma VM de replicação, você pode desligar a VM local e executar uma replicação incremental final para garantir a perda de dados zero. Quando a replicação é executada, os discos gerenciados por réplica que correspondem à VM são usados para criar a VM no Azure.

Para começar, veja os tutoriais sobre migração sem agente do VMware e migração sem agente do Hyper-V.

Como fazer para medir o requisito de largura de banda das minhas migrações?

Uma variedade de fatores pode afetar a quantidade de largura de banda que você precisa para replicar dados para o Azure. O requisito de largura de banda depende da rapidez com que o dispositivo de Migrações para Azure local pode ler e replicar os dados para o Azure. A replicação tem duas fases: replicação inicial e replicação delta.

Quando a replicação é iniciada para uma VM, ocorre um ciclo de replicação inicial no qual as cópias completas dos discos são replicadas. Após a conclusão da replicação inicial, os ciclos de replicação incremental (ciclos delta) são agendados periodicamente para transferir as alterações que ocorreram desde o ciclo de replicação anterior.

Você pode resolver o requisito de largura de banda com base em:

  • O volume de dados que você precisa mover na onda.
  • O tempo que você deseja alocar para o processo de replicação inicial.

O ideal é que a replicação inicial seja concluída pelo menos 3 a 4 dias antes da janela de migração real. Essa linha do tempo fornece tempo suficiente para executar uma migração de teste antes da janela real e manter o tempo de inatividade durante a janela no mínimo.

Você pode estimar a largura de banda ou o tempo necessário para a migração de VM do VMware sem agente usando a seguinte fórmula:

  • Tempo para concluir a replicação inicial = {tamanho dos discos (ou tamanho usado, se disponível) * 0,7 (supondo uma média de compactação de 30 por cento – estimativa conservadora)}/largura de banda disponível para replicação.

Como faço para limitar a replicação ao usar o dispositivo de Migrações para Azure para replicação de VMware sem agente?

Você pode limitar usando NetQosPolicy. Esse método de limitação se aplica apenas às conexões de saída do dispositivo de Migrações para Azure.

Por exemplo, o valor 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

Para aumentar e diminuir a largura de banda de replicação com base em um agendamento, você pode usar tarefas agendadas do Windows para dimensionar a largura de banda conforme necessário. Uma tarefa diminui a largura de banda e outra aumenta a largura de banda.

Observação

Você precisa criar o NetQosPolicy mencionado anteriormente antes de executar os comandos a seguir.

#Replace with an account that's part of the local Administrators group
$User = "localVmName\userName"

#Set the task names
$ThrottleBandwidthTask = "ThrottleBandwidth"
$IncreaseBandwidthTask = "IncreaseBandwidth"

#Create a directory to host PowerShell scaling scripts
if (!(Test-Path "C:\ReplicationBandwidthScripts"))
{
 New-Item -Path "C:\" -Name "ReplicationBandwidthScripts" -Type Directory
}

#Set your minimum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 10 MBps
New-Item C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 10MB'
$ThrottleBandwidthScript = "C:\ReplicationBandwidthScripts\ThrottleBandwidth.ps1"

#Set your maximum bandwidth to be used during replication by changing the ThrottleRateActionBitsPerSecond parameter
#Currently set to 1000 MBps
New-Item C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1
Set-Content C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1 'Set-NetQosPolicy -Name "ThrottleReplication" -ThrottleRateActionBitsPerSecond 1000MB'
$IncreaseBandwidthScript = "C:\ReplicationBandwidthScripts\IncreaseBandwidth.ps1"

#Timezone set on the Azure Migrate Appliance (VM) is used; change the frequency to meet your needs
#In this example, the bandwidth is being throttled every weekday at 8:00 AM local time
#The bandwidth is being increased every weekday at 6:00 PM local time
$ThrottleBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 8:00am
$IncreaseBandwidthTrigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Monday,Tuesday,Wednesday,Thursday,Friday -At 6:00pm

#Setting the task action to execute the scripts
$ThrottleBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $ThrottleBandwidthScript"
$IncreaseBandwidthAction = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-executionpolicy bypass -noprofile -file $IncreaseBandwidthScript"

#Creating the scheduled tasks
Register-ScheduledTask -TaskName $ThrottleBandwidthTask -Trigger $ThrottleBandwidthTrigger -User $User -Action $ThrottleBandwidthAction -RunLevel Highest -Force
Register-ScheduledTask -TaskName $IncreaseBandwidthTask -Trigger $IncreaseBandwidthTrigger -User $User -Action $IncreaseBandwidthAction -RunLevel Highest -Force

Como a taxa de rotatividade afeta a replicação sem agente?

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. Como você minimiza a quantidade de dados que transfere, permite que os dados dobram o máximo possível antes de agendar o próximo ciclo.

Com que frequência um ciclo de replicação é agendado?

A fórmula para agendar o próximo ciclo de replicação é (tempo do ciclo anterior/2) ou uma hora, o que for maior.

Por exemplo, se uma VM levar quatro horas para um ciclo delta, o próximo ciclo será agendado em duas horas, e não na próxima hora. O processo é diferente imediatamente após a replicação inicial, quando o primeiro ciclo delta é agendado imediatamente.

Implantei dois (ou mais) dispositivos para descobrir VMs em meu vCenter Server. Mas quando tento migrar as VMs, só vejo VMs que correspondem a um dos dispositivos.

Se você configurar vários dispositivos, não poderá haver sobreposição entre as VMs nas contas do vCenter fornecidas. Uma descoberta com essa sobreposição é um cenário sem suporte.

Como a replicação sem agente afeta os servidores VMware?

A replicação sem agente resulta em algum impacto no desempenho sobre os hosts VMware vCenter Server e VMware ESXi. Como a replicação sem agente usa instantâneos, ela consome IOPS no armazenamento, portanto, é necessária alguma largura de banda de armazenamento de IOPS. Não recomendamos o uso da replicação sem agente se você tiver restrições de armazenamento ou IOPS em seu ambiente.

VMs desligadas podem ser replicadas?

Há suporte para a replicação de VMs VMware enquanto elas estão desligadas, mas apenas na abordagem sem agente.

Importante

Não podemos garantir que uma VM desligada será inicializada com êxito, pois não podemos verificar seu estado operacional antes da replicação.

É altamente recomendável que você execute uma migração de teste para garantir que tudo prossiga sem problemas durante a migração real. Esse método pode ser útil quando o processo de replicação inicial é longo ou para VMs de alta rotatividade, como servidores de banco de dados ou outras cargas de trabalho com uso intensivo de disco.

Posso usar as Migrações para Azure para migrar meus aplicativos Web para o Serviço de Aplicativo do Azure?

Você pode executar a migração sem agente em escala de ASP.NET aplicativos Web em execução em servidores Web do IIS hospedados em um sistema operacional Windows em um ambiente VMware. Saiba mais.

Migração baseada em agente

Como posso migrar minhas instâncias do AWS EC2 para o Azure?

Examine Descobrir, avaliar e migrar VMs do Amazon Web Services (AWS) para o Azure.

Como a migração baseada em agente funciona?

A ferramenta Migração e modernização fornece uma opção de migração baseada em agente para migrar servidores Windows e Linux em execução em servidores físicos ou em execução como VMs x86/x64 em provedores como VMware, Hyper-V, AWS e GCP.

O método de migração baseado em agente usa software de agente para replicar dados do servidor para o Azure. Instale o software no servidor que você está migrando. O processo de replicação usa uma arquitetura de descarregamento na qual o agente retransmite dados de replicação para um servidor de replicação dedicado chamado de dispositivo de replicação ou servidor de configuração (ou para um servidor de processo de expansão). Para obter mais detalhes, consulte Arquitetura de migração baseada em agente.

Observação

O dispositivo de replicação é diferente do dispositivo de descoberta das Migrações para Azure e deve ser instalado em um computador separado/dedicado.

Onde devo instalar o dispositivo de replicação para migrações baseadas em agente?

Você deve instalar o dispositivo de replicação em um computador dedicado. Você não deve instalar o dispositivo de replicação em um computador de origem que deseja replicar ou no dispositivo de Migrações para Azure usado para descoberta e avaliação. Leia Migrar computadores como servidores físicos para o Azure para obter mais detalhes.

Posso migrar VMs da AWS que executam o sistema operacional Amazon Linux?

As VMs que executam o Amazon Linux não podem ser migradas como estão, pois o sistema operacional Linux da Amazon tem suporte apenas no AWS.

Para migrar cargas de trabalho em execução no Amazon Linux, você pode criar uma VM CentOS/RHEL no Azure. Em seguida, você pode migrar a carga de trabalho executada no computador Linux do AWS usando uma abordagem de migração de carga de trabalho relevante. Por exemplo, dependendo da carga de trabalho, pode haver ferramentas específicas de carga de trabalho para ajudar na migração, como ferramentas para bancos de dados ou ferramentas de implantação para servidores Web.

Como fazer para medir o requisito de largura de banda das minhas migrações?

Uma variedade de fatores pode afetar a quantidade de largura de banda que você precisa para replicar dados para o Azure. O requisito de largura de banda depende da rapidez com que o dispositivo de Migrações para Azure local pode ler e replicar os dados para o Azure. A replicação tem duas fases: replicação inicial e replicação delta.

Quando a replicação é iniciada para uma VM, ocorre um ciclo de replicação inicial no qual as cópias completas dos discos são replicadas. Após a conclusão da replicação inicial, os ciclos de replicação incremental (ciclos delta) são agendados periodicamente para transferir as alterações que ocorreram desde o ciclo de replicação anterior.

Para um método de replicação baseado em agente, o Planejador de Implantações do Azure Site Recovery pode ajudar a criar o perfil do ambiente para a rotatividade de dados e ajudar a prever o requisito de largura de banda necessário. Para saber mais, leia Planejar implantação do VMware.

Migração sem agente do Hyper-V

Como a migração sem agente funciona?

A ferramenta Migração e modernização fornece opções de replicação sem agente para a migração de VMs VMware e Hyper-V executando Windows ou Linux. A ferramenta fornece outra opção de replicação baseada em agente para servidores Windows e Linux. Essa outra opção pode ser usada para migrar servidores físicos e VMs x86/x64 em provedores como VMware, Hyper-V, AWS e GCP.

A opção de replicação baseada em agente requer que você instale o software do agente na VM/servidor que você está migrando. A opção sem agente não exige que você instale software nas VMs, o que pode oferecer conveniência e simplicidade.

A opção de replicação sem agente funciona usando mecanismos fornecidos pelo provedor de virtualização (VMware ou Hyper-V). Para VMs do Hyper-V, o mecanismo de replicação sem agente replica dados de discos de VM usando instantâneos de VM e a funcionalidade de controle de alterações da réplica do Hyper-V.

Quando a replicação é configurada para uma VM, a VM passa pela primeira vez por uma fase inicial de replicação. Durante a replicação inicial, um instantâneo de VM é obtido e uma cópia completa dos dados dos discos de instantâneo é replicada para discos gerenciados em 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).

A fase de replicação incremental aborda as alterações de dados que ocorreram desde o último ciclo de replicação concluído. Essas alterações são replicadas periodicamente e aplicadas aos discos gerenciados por réplica. Esse processo mantém a replicação em sincronia com as alterações na VM.

A tecnologia de controle de blocos alterados do VMware é usada para controlar as alterações entre ciclos de replicação para VMs VMware. 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. Para manter a replicação da VM em sincronia, somente os dados que foram alterados desde o último ciclo de replicação concluído precisam ser replicados.

No final de cada ciclo de replicação, o instantâneo é lançado e a consolidação de instantâneos é executada para a VM. Da mesma forma, para VMs do Hyper-V, o mecanismo de controle de alterações de réplica do Hyper-V é usado para controlar as alterações entre ciclos de replicação consecutivos.

Ao executar a operação Migrate em uma VM de replicação, você pode desligar a VM local e executar uma replicação incremental final para garantir a perda de dados zero. Os discos gerenciados por réplica que correspondem à VM são usados para criar a VM no Azure.

Para começar, consulte o tutorial de migração sem agente do Hyper-V.

Como fazer para medir o requisito de largura de banda das minhas migrações?

Uma variedade de fatores pode afetar a quantidade de largura de banda que você precisa para replicar dados para o Azure. O requisito de largura de banda depende da rapidez com que o dispositivo de Migrações para Azure local pode ler e replicar os dados para o Azure. A replicação tem duas fases: replicação inicial e replicação delta.

Quando a replicação é iniciada para uma VM, ocorre um ciclo de replicação inicial no qual as cópias completas dos discos são replicadas. Após a conclusão da replicação inicial, os ciclos de replicação incremental (ciclos delta) são agendados periodicamente para transferir as alterações que ocorreram desde o ciclo de replicação anterior.

Você pode resolver o requisito de largura de banda com base em:

  • O volume de dados que você precisa mover na onda.
  • O tempo que você deseja alocar para o processo de replicação inicial.

O ideal é que a replicação inicial seja concluída pelo menos 3 a 4 dias antes da janela de migração real. Essa linha do tempo fornece tempo suficiente para executar uma migração de teste antes da janela real e manter o tempo de inatividade durante a janela no mínimo.

Conteúdo relacionado