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ção geral sobre Azure Migrate.
• Leia perguntas frequentes sobre o aparelho 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 Migration and modernization oferece migração sem agentes e baseada em agentes para migrar os seus servidores de origem e máquinas virtuais (VMs) para 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. Este processo realiza uma replicação inicial dos dados da sua VM/servidor para o Azure. Após a conclusão da replicação inicial, é estabelecida uma replicação contínua (delta sync) que migra dados incrementais para o Azure. Depois de a operação atingir a fase de delta-sync, pode 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.

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

As migrações baseadas em agentes exigem que instale o software Azure Migrate (agentes) nas VMs de origem que está a migrar. 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.
• Hyper-V VMs.
• 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 agentes oferece mais conveniência e simplicidade do que as opções de replicação baseadas em agentes para VMware e VMs 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.

Que geografias são suportadas para migração com o Azure Migrate?

Analise as geografias suportadas para nuvenspúblicas e governamentais.

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

Embora possa criar avaliações para múltiplas regiões num projeto Azure Migrate, um projeto Azure Migrate pode ser usado para migrar servidores para apenas uma região Azure. Podes criar mais projetos 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 de Hyper-V sem agentes, a região de destino é bloqueada quando o botão Criar Recursos é selecionado no portal ao configurar o fornecedor de replicação Hyper-V.

Posso usar o mesmo projeto Azure Migrate para migrar para múltiplas subscrições?

Sim, pode usar o mesmo projeto Azure Migrate para migrar para múltiplas subscrições com o mesmo inquilino 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 fornecedor Hyper-V para migrações Hyper-V sem agentes.

O Azure Migrate suporta o Azure Resource Graph?

Atualmente, o Azure Migrate não está integrado com o Azure Resource Graph. Suporta a realização de consultas relacionadas com o Azure Resource Graph.

Como é que os dados são transmitidos de um ambiente local para o Azure? É encriptado antes da transmissão?

Com a replicação sem agente, o appliance Azure Migrate comprime e encripta os dados antes de os 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 encripta automaticamente os seus dados quando persiste os dados para a cloud (encriptação 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 usar o 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. Test Migration funciona permitindo usar um ambiente sandbox em 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 alguma opção de rollback para o Azure Migrate?

Pode usar a opção Test Migration para validar a funcionalidade e o desempenho da sua aplicação em 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 algum erro durante o teste de aceitação do utilizador (UAT) para a migração de teste, pode optar por adiar a migração final e manter a sua VM/servidor de origem a funcionar e replicar 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 especificar uma sub-rede alvo (diferente da predefinida) como entrada enquanto ativa a replicação, o Azure Migrate prioriza uma sub-rede com o mesmo nome na rede virtual usada para a migração de teste.
• Se não for encontrada uma sub-rede com o mesmo nome, o Azure Migrate seleciona alfabeticamente a primeira sub-rede disponível que não seja um gateway, gateway de aplicação, firewall ou sub-rede 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 a operação novamente.

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 Azure de teste usando dados replicados. O servidor é implantado com uma cópia instantânea dos dados replicados para o grupo de recursos de destino (selecionado quando se ativa 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 continua a ser executada no Azure e acarreta custos. 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 com sucesso a sua VM/servidor, pode visualizar e gerir a VM navegando até à página Executar> Migrações. A fase de execução será mostrada como Concluída e o estado será Concluído. 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 Azure geração 1?

A ferramenta Migração e modernização migra máquinas baseadas em UEFI para Azure como VMs Azure geração 2. Se quiseres migrá-las como VMs Azure geração 1, converte o tipo de arranque para BIOS antes de iniciar a replicação e depois usa a ferramenta Migration and modernization para migrar para Azure.

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

A ferramenta Migration and modernization migra todas as máquinas baseadas em UEFI para Azure como VMs Azure geração 2. 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 de geração 1 do Azure.

Que sistemas operativos são suportados para migração de máquinas baseadas em UEFI para o Azure?

Posso migrar controladores de domínio do Active 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 Active Directory, o tipo de ambiente pode ser um fator. Num ambiente híbrido com um site local ligado ao seu ambiente Azure, pode expandir o seu diretório para o Azure adicionando controladores de domínio extra e configurando a replicação do Active Directory. Você pode usar a ferramenta Migração e modernização se:

• Migrar para um ambiente isolado no Azure que requer os 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 suporta a atualização do sistema operativo Windows durante a migração. Esta opção não está atualmente disponível para Linux. Obtenha mais detalhes sobre Windows atualização do sistema operativo.

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. Saiba mais.

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 serão suportados no Azure após a migração?

Pode migrar os seus servidores Windows Server 2008 e 2008 R2 on-premises para VMs Azure e obter atualizações de segurança prolongadas durante três anos após o fim do suporte, sem custos adicionais acima do custo de funcionamento da VM. Pode usar a ferramenta de Migração e modernização para migrar as suas cargas de trabalho Windows Server 2008 e 2008 R2.

Como migro o Windows Server 2003 a correr no VMware/Hyper-V para o Azure?

O suporte estendido do Windows Server 2003 terminou a 14 de julho de 2015. A equipa de suporte do Azure continua a ajudar a resolver problemas relacionados com a 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 migre as suas aplicações para instâncias do Azure a correr uma versão mais recente do Windows Server, para garantir que utiliza eficazmente a flexibilidade e fiabilidade da cloud do Azure.

Se ainda optar por migrar o Windows Server 2003 para o Azure, pode usar a ferramenta Migração e modernização se a sua implementação Windows Server for uma VM que está a correr em VMware ou Hyper-V. Para mais informações, consulte Prepare as suas máquinas de Windows Server 2003 para migração.

Migração VMware sem agente

Como funciona a migração sem agente?

A ferramenta Migration and modernization fornece opções de replicação sem agente para a migração de VMware e VMs Hyper-V a correr Windows ou Linux. A ferramenta oferece outra opção de replicação baseada em agentes para servidores Windows e Linux. Esta outra opção pode ser usada para migrar servidores físicos e VMs x86/x64 em fornecedores 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 utiliza mecanismos fornecidos pelo fornecedor de virtualização (VMware ou Hyper-V). Para VMs VMware, o mecanismo de replicação sem agente utiliza snapshots do VMware e a tecnologia de rastreamento de blocos alterados da VMware para replicar dados dos discos das VMs. Muitos produtos de backup usam um mecanismo semelhante. Para VMs Hyper-V, o mecanismo de replicação sem agente utiliza snapshots de VM e a capacidade de acompanhamento de alterações da réplica Hyper-V para replicar dados a partir de discos 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 de rastreamento de blocos alterados da VMware acompanha as alterações entre os ciclos de replicação das VMs da VMware. No início do ciclo de replicação, uma captura de instantâneo da VM é realizada e o rastreamento de blocos alterados é usado para compilar as alterações entre o instantâneo atual e o último instantâneo replicado com sucesso. 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 é libertado e a consolidação do snapshot é executada para a VM. De forma semelhante, para VMs Hyper-V, o motor de seguimento de alterações das réplicas Hyper-V regista 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 é realizada, os discos geridos por réplicas que correspondem à VM são usados para criar a VM no Azure.

Para começar, consulte os tutoriais de migração sem agente VMware e Hyper-V migração sem agente.

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

Vários fatores podem afetar a largura de banda necessária para replicar dados para o Azure. O requisito de largura de banda depende da rapidez com que o appliance Azure Migrate local consegue 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 precisas 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 appliance Azure Migrate para replicação VMware sem agente?

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

Por exemplo, o AppNamePrefix valor a ser usado em NetQosPolicy é GatewayWindowsService.exe. Poderia criar uma política no dispositivo Azure Migrate para controlar o tráfego de replicação a partir 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 num calendário, pode usar tarefas agendadas no Windows para escalar 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. Ao minimizar a quantidade de dados transferidos, permite-se que os dados sejam consolidados tanto quanto possível antes de se 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 descoberta com uma sobreposição desse tipo é 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 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 as minhas aplicações web para o Serviço de Aplicações do Azure?

Pode realizar uma migração sem agente em larga escala de aplicações web ASP.NET a correr em servidores web IIS alojados num sistema operativo Windows num ambiente VMware. Saiba mais.

Migração baseada em agente

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

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

Como funciona a migração baseada em agente?

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

O método de migração baseado em agentes utiliza software de 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. Não deves instalar o appliance de replicação numa máquina de origem que queiras replicar, nem no appliance Azure Migrate que usaste para descoberta e avaliação. Leia Migrar máquinas como servidores físicos para Azure para 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 a correr no Amazon Linux, podes criar 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?

Vários fatores podem afetar a largura de banda necessária para replicar dados para o Azure. O requisito de largura de banda depende da rapidez com que o appliance Azure Migrate local consegue 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 agentes, o Azure Site Recovery Deployment Planner pode ajudar a perfilar o ambiente para o churn de dados e prever a necessidade necessária de largura de banda. Para saber mais, leia Plan VMware deployment.

Migração Hyper-V sem agentes

Como funciona a migração sem agente?

A ferramenta Migration and modernization fornece opções de replicação sem agente para a migração de VMware e VMs Hyper-V a correr Windows ou Linux. A ferramenta oferece outra opção de replicação baseada em agentes para servidores Windows e Linux. Esta outra opção pode ser usada para migrar servidores físicos e VMs x86/x64 em fornecedores 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 utilizando mecanismos fornecidos pelo fornecedor de virtualização (VMware ou Hyper-V). Para VMs Hyper-V, o mecanismo de replicação sem agente replica dados dos discos VM utilizando snapshots VM e a capacidade de acompanhamento de alterações da réplica 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 de rastreio de blocos alterados da VMware é usada para acompanhar as alterações entre os ciclos de replicação para as VMs da VMware. No início do ciclo de replicação, um instantâneo da VM é capturado e o rastreamento 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 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 é libertado e a consolidação do snapshot é executada para a VM. De forma semelhante, para VMs Hyper-V, o motor de rastreamento de alterações de réplicas Hyper-V é usado para acompanhar 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 geridos por réplicas que correspondem à VM são usados para criar a VM no Azure.

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

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

Vários fatores podem afetar a largura de banda necessária para replicar dados para o Azure. O requisito de largura de banda depende da rapidez com que o appliance Azure Migrate local consegue 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 precisas 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.

Como faço para reverter se algo der errado durante o processo de migração?

O Azure Migrate já não suporta rollback, o que significa que, depois da migração, os utilizadores não podem voltar ao local.

Que estratégias utilizo para reduzir o tempo de inatividade durante a migração?

Como posso medir o sucesso da minha execução de migração para a nuvem?

Conteúdos relacionados

• Saiba mais sobre a migração de VMs VMware, Hyper-V VMs e servidores físicos.