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

Este artigo responde a perguntas comuns sobre a ferramenta Migração e modernização . Se tiver outras questões, consulte estes recursos:

• Obtenha informações gerais sobre o Azure Migrate.
• Leia perguntas comuns sobre o dispositivo Azure Migrate.
• Saiba mais sobre descoberta, avaliação e visualização de dependência.
• Faça perguntas no fórum Azure Migrate.

Perguntas gerais

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

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

Independentemente da opção de migração escolhida, 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. Após a conclusão da replicação inicial, é estabelecida uma replicação contínua (sincronização delta) 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 está migrando. A opção sem agente orquestra a replicação integrando-se com a funcionalidade fornecida pelo provedor de virtualização.

As 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 Azure Migrate (agentes) nas VMs de origem que você está migrando. A opção baseada em agente não depende da plataforma de virtualização para a 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 suportada pelo método de replicação baseado em agente.

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

• VMs VMware.
• VMs Hyper-V.
• Servidores físicos.
• VMs em execução na AWS.
• VMs em execução no GCP.
• VMs em execução em um provedor de virtualização diferente.

A migração baseada em agente trata suas máquinas 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, convém considerar o uso do cenário baseado em agente para os seguintes casos de uso:

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

• Sem 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, consulte Selecione uma opção de migração VMware.

Quais regiões geográficas são suportadas para migração com o Azure Migrate?

Reveja as geografias suportadas das clouds públicas e das clouds governamentais.

Posso usar o mesmo projeto do Azure Migrate para migrar para várias regiões?

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

• Para migrações 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 do Azure Migrate para migrar para várias assinaturas?

Sim, você pode usar o mesmo projeto do Azure Migrate 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 uma máquina ou um conjunto de máquinas.

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 Hyper-V para migrações Hyper-V sem agente.

O Azure Migrate suporta o Azure Resource Graph?

Atualmente, o Azure Migrate não está integrado 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? É encriptado antes da transmissão?

Com a replicação sem agente, o dispositivo Azure Migrate compacta e criptografa dados antes de carregá-los. 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 persiste os dados na nuvem (criptografia em repouso).

Posso usar o cofre de serviços de recuperação criado pelo Azure Migrate para cenários de recuperação de desastres?

Não recomendamos o uso do cofre de serviços de recuperação criado pelo Azure Migrate para cenários de recuperação de desastres, porque isso pode resultar em falhas de replicação inicial no Azure Migrate.

Qual é a diferença entre as operações Test Migration e Migration?

A opção Testar migração 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 máquinas 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 quaisquer problemas antes da migração real.

Existe uma opção de reversão para o Azure Migrate?

Você pode usar a opção 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 a máquina local, que permanece operacional e continua replicando até que você execute a migração real. Se houver erros durante o teste de aceitação do usuário (UAT) para a migração de teste, você pode optar por adiar a migração final e manter sua VM/servidor de origem em execução e replicando para o Azure. Você pode tentar novamente a migração final depois de resolver os erros.

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

Você pode selecionar uma rede virtual para migrações de teste. O Azure Migrate seleciona 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, o Azure Migrate priorizará 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, o Azure Migrate selecionará alfabeticamente 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 Testar migração está desativado para o meu servidor?

O botão Migração de teste pode ser 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 pode ser desativado se uma migração de teste já 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 tente novamente a operação.

O que acontece 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 point-in-time dos dados replicados para o grupo de recursos de destino (selecionado quando você habilita a replicação) com um -test sufixo. 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á a ser executada no Azure e incorrerá em encargos. Para limpar após uma migração de teste, vá para a visualização Máquinas replicantes na ferramenta Migração e modernização e use a ação Migração de teste de limpeza na máquina.

Como sei se minha VM foi migrada 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 validar.

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

O que acontece 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 criada para 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 uma migração, continuará a incorrer em cobranças por esses discos. A migração completa não afeta os discos conectados a máquinas que já migraram.

Como posso migrar máquinas baseadas em UEFI para o Azure como VMs da geração 1 do Azure?

A ferramenta de migração e modernização migra máquinas baseadas em UEFI para o Azure como VMs da geração 2 do Azure. Se você quiser migrá-las como 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 migrar para o Azure.

O Azure Migrate converte máquinas baseadas em UEFI para máquinas baseadas em BIOS e as migra para o Azure como VMs da geração 1 do Azure?

A ferramenta de migração e modernização migra todas as máquinas baseadas em UEFI para o Azure como VMs da geração 2 do Azure. Não suportamos mais a conversão de VMs baseadas em UEFI em VMs baseadas em BIOS. Todas as máquinas baseadas em BIOS são migradas para o Azure apenas como VMs da geração 1 do Azure.

Quais sistemas operacionais são suportados para a migração de máquinas baseadas em UEFI para o Azure?

Sistemas operacionais suportados para máquinas baseadas em UEFI	VMware sem agente para o Azure	Hyper-V sem agente para Azure	VMware baseado em agente, nuvens físicas e outras nuvens para o Azure
Windows Server 2025, 2022, 2019, 2016, 2012 R2, 2012	Y	Y	Y
Windows 11 Pro, Windows 11 Enterprise	Y	Y	Y
Windows 10 Pro, Windows 10 Enterprise	Y	Y	Y
SUSE Linux Enterprise Server 15 SP1, SP2, SP3, SP4, SP5, SP6	Y	Y	Y
SUSE Linux Enterprise Server 12 SP4	Y	Y	Y
Ubuntu Server 22.04 LTS, 20.04 LTS, 18.04 LTS, 16.04 LTS	Y	Y	Y
RHEL 9.x, 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x	Y	Y	Y
Fluxo do CentOS	Y	Y	Y
Oracle Linux 9, 8, 7.7-CI, 7.7, 6	Y	Y	Y

Posso migrar controladores de domínio do Ative Directory usando o Azure Migrate?

A ferramenta de migração e modernização é independente de aplicativos 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 Ative 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 Ative Directory. Você pode usar a ferramenta Migração e modernização se:

• Migração para um ambiente isolado no Azure que requer seus próprios controladores de domínio.
• Testando aplicativos em um ambiente de sandbox.

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

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

Preciso do VMware vCenter para migrar VMs VMware?

Para migrar VMs VMware usando a migração baseada em agente 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. Mais informações.

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

Atualmente, a ferramenta Migração e modernização oferece suporte a migrações semelhantes. Não oferecemos suporte à consolidação de servidores durante a migração.

O Windows Server 2008 e o 2008 R2 terão suporte no Azure após a migração?

Você pode migrar seus servidores Windows Server 2008 e 2008 R2 locais para VMs do Azure e obter atualizações de segurança estendidas por três anos após as datas de fim do 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 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 solução de problemas ou patches no nível do sistema operacional.

Recomendamos que você migre seus aplicativos para instâncias do Azure que executam 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 de migração e modernização se sua implantação do Windows Server for uma VM executada no VMware ou no Hyper-V. Para obter mais informações, consulte Preparar suas máquinas Windows Server 2003 para migração.

Migração VMware sem agente

Como funciona a migração sem agente?

A ferramenta de migração e modernização fornece opções de replicação sem agente para a migração de VMs VMware e Hyper-V que executam 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 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 snapshots VMware e a tecnologia VMware change-block tracking para replicar dados de discos VM. Muitos produtos de backup usam um mecanismo semelhante. Para VMs Hyper-V, o mecanismo de replicação sem agente usa instantâneos de VM e o recurso 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 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. 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).

A fase de replicação incremental aborda quaisquer alterações de dados ocorridas 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 sincronizada com as alterações na VM.

A tecnologia VMware de rastreamento de blocos alterados acompanha as alterações entre os ciclos de replicação para VMs VMware. No início do ciclo de replicação, um instantâneo da 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 sincronizada, somente os dados alterados desde o último ciclo de replicação concluído precisam ser replicados.

No final de cada ciclo de replicação, o snapshot é liberado e a consolidação de snapshot é executada para a VM. Da mesma forma, para VMs Hyper-V, o mecanismo de controle de alterações da réplica do Hyper-V controla as alterações entre ciclos de replicação consecutivos.

Ao executar a Migrate operação em uma VM replicante, você pode desligar a VM local e executar uma replicação incremental final para garantir perda zero de dados. 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, consulte os tutoriais de migração sem agente do VMware e migração sem agente do Hyper-V.

Como posso avaliar o requisito de largura de banda para as minhas migrações?

Uma série de fatores pode afetar a quantidade de largura de banda necessária para replicar dados para o Azure. O requisito de largura de banda depende da rapidez com que o dispositivo Azure Migrate 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 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 quaisquer alterações ocorridas desde o ciclo de replicação anterior.

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

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

Idealmente, você desejaria que a replicação inicial fosse concluída pelo menos 3-4 dias antes da janela de migração real. Essa linha do tempo oferece tempo suficiente para executar uma migração de teste antes da janela real e manter o tempo de inatividade durante a janela ao mínimo.

Você pode estimar a largura de banda ou o tempo necessário para a migração de VM 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 (assumindo uma média de compressão de 30% – estimativa conservadora)}/largura de banda disponível para replicação.

Como posso limitar a replicação ao usar o dispositivo Azure Migrate para replicação VMware sem agente?

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

Por exemplo, o AppNamePrefix valor a ser usado em 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

Para aumentar e diminuir a largura de banda de replicação com base em uma programação, 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 tarefa aumenta a largura de banda.

#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 churn afeta a replicação sem agente?

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. Como você minimiza a quantidade de dados transferidos, permite que os dados sejam dobrados 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 de ciclo anterior / 2) ou uma hora, o que for maior.

Por exemplo, se uma VM leva quatro horas para um ciclo delta, o próximo ciclo é 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 no meu vCenter Server. Mas quando tento migrar as VMs, vejo apenas 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 deteção com uma sobreposição desse tipo é um cenário não suportado.

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

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

As VMs desligadas podem ser replicadas?

A replicação de VMs VMware enquanto elas estão desligadas é suportada, mas apenas na abordagem sem agente.

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

Posso usar o Azure Migrate para migrar meus aplicativos Web para o Serviço de Aplicativo do Azure?

Você pode executar a migração sem agente em escala de aplicativos Web ASP.NET executados em servidores Web IIS hospedados em um sistema operacional Windows em um ambiente VMware. Mais informações.

Migração baseada em agente

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

Analise Descubra, avalie e migre VMs da Amazon Web Services (AWS) para o Azure.

Como funciona a migração baseada em agente?

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

O método de migração baseado em agente usa o software do agente para replicar dados do servidor para o Azure. Você instala o software no servidor que está migrando. O processo de replicação usa uma arquitetura de descarregamento na qual o agente retransmite os dados de replicação para um servidor de replicação dedicado chamado 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.

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

Você deve instalar o dispositivo de replicação em uma máquina dedicada. Você não deve instalar o dispositivo de replicação em uma máquina de origem que deseja replicar ou no dispositivo Azure Migrate usado para descoberta e avaliação. Leia Migrar máquinas 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, porque o Amazon Linux OS é compatível apenas com a AWS.

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

Como posso avaliar o requisito de largura de banda para as minhas migrações?

Uma série de fatores pode afetar a quantidade de largura de banda necessária para replicar dados para o Azure. O requisito de largura de banda depende da rapidez com que o dispositivo Azure Migrate 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 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 quaisquer alterações ocorridas desde o ciclo de replicação anterior.

Para um método de replicação baseado em agente, o Planejador de Implantação do Azure Site Recovery pode ajudar a traçar 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 Plan VMware deployment.

Migração do Hyper-V sem agente

Como funciona a migração sem agente?

A ferramenta de migração e modernização fornece opções de replicação sem agente para a migração de VMs VMware e Hyper-V que executam 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 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 Hyper-V, o mecanismo de replicação sem agente replica dados de discos de VM usando instantâneos de VM e o recurso de controle de alterações da réplica do Hyper-V.

Quando a replicação é configurada para uma VM, a VM 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. 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).

A fase de replicação incremental aborda quaisquer alterações de dados ocorridas 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 sincronizada com as alterações na VM.

A tecnologia VMware change-block tracking é usada para acompanhar as alterações entre os ciclos de replicação para VMs VMware. 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. Para manter a replicação da VM sincronizada, somente os dados alterados desde o último ciclo de replicação concluído precisam ser replicados.

No final de cada ciclo de replicação, o snapshot é liberado e a consolidação de snapshot é executada para a VM. Da mesma forma, para VMs Hyper-V, o mecanismo de controle de alterações de réplica do Hyper-V é usado para acompanhar as alterações entre ciclos de replicação consecutivos.

Ao executar a Migrate operação em uma VM replicante, você pode desligar a VM local e executar uma replicação incremental final para garantir perda zero de dados. 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 posso avaliar o requisito de largura de banda para as minhas migrações?

Uma série de fatores pode afetar a quantidade de largura de banda necessária para replicar dados para o Azure. O requisito de largura de banda depende da rapidez com que o dispositivo Azure Migrate 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 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 quaisquer alterações ocorridas desde o ciclo de replicação anterior.

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

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

Idealmente, você desejaria que a replicação inicial fosse concluída pelo menos 3 a 4 dias antes da janela de migração real. Essa linha do tempo oferece tempo suficiente para executar uma migração de teste antes da janela real e manter o tempo de inatividade durante a janela ao mínimo.

Conteúdos relacionados

• Saiba mais sobre como migrar VMs VMware, VMs Hyper-V e servidores físicos.