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

  • Artigo

Cuidado

Este artigo faz referência ao CentOS, uma distribuição do Linux que está se aproximando do status de EOL (fim da vida útil). Considere seu uso e planejamento adequadamente. Para obter mais informações, veja as Diretrizes sobre fim da vida útil do CentOS.

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

Perguntas gerais

Quais são as opções de migração na Migração e modernização?

A ferramenta Migração e modernização oferece duas opções para migrar servidores e máquinas virtuais de origem para o Azure: migração sem agente e migração baseada em agente.

Seja qual for a opção de migração escolhida, a primeira etapa para migrar um servidor usando ferramenta Migração e modernização será iniciar a replicação para o servidor. Isso executa uma replicação inicial dos dados de servidor/VM para o Azure. Após a conclusão da replicação inicial, uma replicação contínua (sincronização delta contínua) é estabelecida para migrar dados incrementais para o Azure. Depois que a operação atingir a fase de sincronização delta, você poderá optar por fazer a migração para o Azure a qualquer momento.

Aqui estão algumas considerações que você deve ter em mente ao decidir sobre a opção de migração.

As migrações sem agente não exigem que nenhum software (agentes) seja implantado nas VMs/servidores de origem que estão sendo migrados. 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 o software de Migrações para Azure (agentes) seja instalado nas VMs/máquinas de origem a serem migradas. A opção baseada em agente não depende da plataforma de virtualização para o uso da funcionalidade de replicação. Portanto, ela pode ser usada 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 VMs VMware, VMs Hyper-V, servidores físicos, VMs em execução na AWS, VMS em execução no GCP ou VMS em execução em um provedor de virtualização diferente. A migração baseada em agente trata seus computadores como servidores físicos para a migração.

Embora a migração sem agente ofereça outra conveniência e simplicidade em relação às opções de replicação baseada em agente nos cenários com suporte (VMware e Hyper-V), talvez seja interessante considerar o uso do cenário baseado em agente para os seguintes casos de uso:

  • Ambiente com restrição de IOPS: a replicação sem agente usa instantâneos 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.
  • Se você não tiver um vCenter Server, poderá tratar suas VMs do VMware como servidores físicos e usar o fluxo de trabalho de migração baseado em agente.

Para saber mais, leia este artigo para comparar as opções de migração das migrações do VMware.

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

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

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

Embora seja possível criar avaliações para várias regiões em um projeto de Migrações para Azure, um projeto das Migrações para Azure pode ser usado para migrar servidores para apenas uma região do Azure. Você pode criar outros projetos de Migrações para Azure para cada região para a qual você precisa fazer a migração.

  • Para migrações do 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 você clica no botão "Criar Recursos" no portal durante a configuração do dispositivo de replicação.
  • Para migrações do Hyper-V sem agente, a região de destino é bloqueada quando você clica no botão "Criar Recursos" no portal durante a configuração do 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 fazer a migração para várias assinaturas (mesmo locatário do Azure) na mesma região de destino para um projeto de Migrações para Azure. 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 é bloqueada após a primeira replicação para migrações do VMware sem agente e durante a instalação do dispositivo de replicação e do provedor do Hyper-V para migrações baseadas em agente e migrações do Hyper-V sem agente, respectivamente.

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

O dispositivo de Migrações para Azure no caso de replicação sem agente compacta dados e os criptografa antes de carregar. Os dados são transmitidos por um canal de comunicação seguro por https e usam o TLS 1.2 ou posterior. Além disso, o Armazenamento do Azure criptografa automaticamente os dados quando eles são persistidos na nuvem (criptografia em repouso).

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 é recomendável usar o cofre dos Serviços de Recuperação criado pelas Migrações para Azure para cenários de recuperação de desastre. Isso pode resultar em falhas de replicação de início nas Migrações para Azure.

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

A migração de teste oferece uma forma de testar e validar as migrações antes da migração real. A migração de teste funciona ao permitir que você use um ambiente de área restrita no Azure para testar as máquinas virtuais antes da migração real. O ambiente de área restrita é demarcado por uma rede virtual de teste que você especificar. A operação de migração de teste não causa interrupção, desde que a VNet de teste esteja suficientemente isolada. A VNet isolada aqui significa que as regras de conexão de entrada e saída foram projetadas para evitar conexões indesejadas. Por exemplo, a conexão com computadores locais é restrita.

Os aplicativos podem continuar sendo executados na origem enquanto permitem que você execute 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.

A captura de tela mostra a diferença na migração de teste e na 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 executar a migração final depois de estabelecer a confiança por meio da operação de 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 da migração de teste, você poderá optar por adiar a migração final e manter a VM/servidor de origem em execução e que está replicando no Azure. Você poderá tentar 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 ser desligado, você não poderá executar uma reversão do Azure para o 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. A sub-rede é selecionada automaticamente com base na seguinte lógica:

  • Se uma sub-rede de destino (diferente de padrão) tiver sido especificada como uma entrada quando você habilitar a replicação, as Migrações para Azure priorizarão o uso de uma sub-rede com o mesmo nome na rede virtual selecionada para a migração de teste.
  • Se a sub-rede com o mesmo nome não for encontrada, o serviço Migrações para Azure selecionará a primeira sub-rede disponível em ordem alfabética que não seja uma sub-rede de Gateway/Gateway de Aplicativo/Firewall/Bastion.

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

O botão de migração de teste pode estar em um estado desabilitado nos seguintes cenários:

  • Você não pode iniciar uma migração de teste até que uma IR (replicação inicial) tenha sido concluída para a VM. O botão de migração de teste será desabilitado até que o processo de IR seja concluído. Você poderá executar uma migração de teste quando sua VM estiver em uma fase 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?

A migração de teste simula a migração real criando uma VM do Azure de teste que usa dados replicados. O servidor será implantado com uma cópia pontual dos dados replicados no 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 que os problemas após a migração sejam minimizados. Se a migração de teste não for limpa após o teste, a máquina virtual de teste continuará sendo executada no Azure e vai gerar 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 posso saber se minha VM foi migrada com êxito?

Depois de migrar a VM/servidor com êxito, você poderá ver e gerenciar a VM na página Máquinas Virtuais. Conecte-se à VM migrada para validá-la. Como alternativa, você pode examinar o 'Status do trabalho' para a operação a fim de verificar se a migração foi concluída com êxito. Se você encontrar erros, resolva-os e repita 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 acontecerá se eu não concluir a migração após a migração?

Quando você conclui a migração, a ferramenta Migração e modernização limpa os discos gerenciados na assinatura em 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 afetará 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 da 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 somente como VMs da geração 1 do Azure.

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

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 2019, 2016, 2012 R2, 2012 N N S
Windows 10 pro, Windows 10 Enterprise N N S
SUSE Linux Enterprise Server 15 SP1 N N S
SUSE Linux Enterprise Server 12 SP4 N N S
Ubuntu Server 16.04, 18.04, 19.04, 19.10 N N S
RHEL 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x N N S
Cent OS 8.1, 8.0, 7.7, 7.6, 7.5, 7.4, 6.x N N S
Oracle Linux 7.7, 7.7-CI 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 junto com ele. No entanto, para alguns aplicativos, métodos alternativos de migração diferentes da Migração e modernização podem ser mais adequados para a migração. Para o Active Directory, no caso de ambientes híbridos em que o site local está conectado ao seu ambiente do Azure, você pode estender o Directory para o Azure adicionando controladores de domínio extras no Azure e configurando a replicação do Active Directory. Se você estiver fazendo a migração para um ambiente isolado no Azure que exija os próprios controladores de domínio (ou testando aplicativos em um ambiente de área restrita), poderá migrar servidores usando a ferramenta Migração e modernização.

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

Atualmente, a ferramenta Migração e modernização dá suporte a migrações semelhantes. A ferramenta não dá suporte à atualização da versão do sistema operacional durante a migração. O computador migrado terá o mesmo sistema operacional que o computador de origem.

Preciso do VMware vCenter para migrar VMs VMware?

Para migrar VMs VMware usando a migração baseada em agente do VMware ou sem agente, os hosts ESXi nos quais as VMs estão localizadas precisam ser gerenciados pelo vCenter Server. 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, os recursos de Migração e modernização dão suporte a migrações semelhantes. Não há suporte à consolidação de servidores nem à atualização do sistema operacional como parte da 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 máquinas virtuais 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 além do custo de execução da máquina virtual. 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 ajudando 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. A migração dos aplicativos para instâncias do Azure que executam uma versão mais recente do Windows Server é a abordagem recomendada para garantir um uso efetivo da flexibilidade e da confiabilidade da nuvem do Azure.

No entanto, se você ainda quiser migrar seu Windows Server 2003 para o Azure, poderá usar a ferramenta Migração e modernização se o Windows Server for uma VM em execução no VMware ou no Hyper-V. Confira este artigo para preparar seus computadores do 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 máquinas virtuais VMware e máquinas virtuais Hyper-V que executam Windows ou Linux. A ferramenta também fornece outra opção de replicação baseada em agente para servidores Windows e Linux que pode ser usada para migrar servidores físicos, bem como máquinas virtuais x86/x64 no VMware, no Hyper-V, na AWS, no GCP etc. A opção de replicação baseada em agente exige a instalação do software do agente na máquina virtual/no servidor que está sendo migrado, enquanto que, na opção sem agente, nenhum software precisa ser instalado nas máquinas virtuais, oferecendo mais conveniência e simplicidade em relação à opção de replicação baseada em agente.

A opção de replicação sem agente funciona usando mecanismos fornecidos pelo provedor de virtualização (VMware, Hyper-V). No caso de máquinas virtuais VMware, o mecanismo de replicação sem agente usa os instantâneos do VMware e a tecnologia de rastreamento de blocos alterados do VMware para replicar dados de discos de máquina virtual. Esse mecanismo é semelhante ao usado por muitos produtos de backup. No caso de máquinas virtuais 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 máquina virtual.

Quando a replicação é configurada para uma máquina virtual, ela passa primeiro por uma fase de replicação inicial. Durante a replicação inicial, um instantâneo de VM é tirado e uma cópia completa dos dados dos discos de instantâneo é replicada para os 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). Na fase de replicação incremental, as alterações de dados ocorridas desde o último ciclo de replicação concluído são periodicamente replicadas e aplicadas aos discos gerenciados de réplica, mantendo, assim, a replicação em sincronia com as alterações que ocorrem na VM. No caso de máquinas virtuais VMware, a tecnologia de rastreamento de blocos alterados do VMware é usada para manter o controle das alterações entre os ciclos de replicação. No início do ciclo de replicação, um instantâneo de VM é tirado e o controle de blocos alterados é usado para obter as alterações entre o instantâneo atual e o último instantâneo replicado com êxito. Dessa forma, somente os dados que foram alterados desde o último ciclo de replicação concluído precisam ser replicados para manter a replicação da VM em sincronia. Ao final de cada ciclo de replicação, o instantâneo é liberado e a fusão de instantâneo é executada para a máquina virtual. Da mesma forma, no caso de máquinas virtuais Hyper-V, o mecanismo de controle de alterações da réplica do Hyper-V é usado para manter o controle das alterações entre os ciclos de replicação consecutivos.

Ao executar a operação de migração em uma máquina virtual de replicação, você tem a opção de desligar a máquina virtual local e executar uma replicação incremental final para garantir que não haja nenhuma perda de dados. Quando você executa a migração, os discos gerenciados de réplica correspondentes à máquina virtual são usados para criar a máquina virtual 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?

A largura de banda da replicação de dados para o Azure depende de uma variedade de fatores e é uma função que indica com qual rapidez 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 ocorridas desde o ciclo de replicação anterior.

Você pode solucionar o requisito de largura de banda com base no volume de dados necessário para ser migrado na onda e no horário em que você deseja que a replicação inicial seja concluída (o ideal é que a replicação inicial tenha sido concluída pelo menos de 3 a 4 dias antes da janela de migração real para dar tempo suficiente de executar uma migração de teste antes da janela real e para manter um tempo de inatividade mínimo durante a janela).

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 (supondo uma média de compactação de 30 por cento – estimativa conservadora)}/largura de banda disponível para replicação.

Como fazer para restringir a replicação ao usar o dispositivo de Migrações para Azure para replicação do VMware sem agente?

Você pode restringir usando NetQosPolicy. Observe que essa limitação é aplicável somente às conexões de saída do dispositivo de Migrações para Azure. Por exemplo:

O AppNamePrefix a ser usado no NetQosPolicy é o "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 aproveitar a tarefa agendada do Windows para dimensionar a largura de banda conforme necessário. Uma tarefa será usada para diminuir a largura de banda, e outra será usada para aumentar a largura de banda. Observação: você precisa criar o NetQosPolicy, descrito acima, antes de executar os comandos abaixo.

#Replace with an account 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) will be 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 minimizamos a quantidade de dados que transferimos, permitimos que os dados sejam dobrados o máximo possível antes de agendarmos 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. No entanto, quando tento migrar as VMs, vejo apenas as que correspondem a um dos dispositivos.

Se houver vários dispositivos configurados, será necessário que não haja nenhuma 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 de IOPs no ambiente.

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

É possível executar a migração sem agente em escala de aplicativos Web do ASP.NET em execução nos 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 o artigo para descobrir, avaliar e migrar suas instâncias do AWS EC2 para o Azure.

Como a migração baseada em agente funciona?

Além das opções de migração sem agente para máquinas virtuais VMware e máquinas virtuais Hyper-V, 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 como máquinas virtuais x86/x64 no VMware), no Hyper-V, na AWS, na Google Cloud Platform etc.

O método de migração baseado em agente usa o software do agente instalado no servidor que está sendo migrado para replicar dados do servidor no Azure. 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). Saiba mais sobre como a opção de migração baseada em agente funciona.

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

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

O dispositivo de replicação deve ser instalado em um computador dedicado. O dispositivo de replicação não deve ser instalado em um computador de origem que você deseja replicar nem no dispositivo de Migrações para Azure (usado para descoberta e avaliação) que pode ter sido instalado antes. Siga o tutorial 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 no estado em que se encontram porque o sistema operacional Amazon Linux só é compatível com a AWS. Para migrar cargas de trabalho em execução no Amazon Linux, você pode criar uma VM CentOS/RHEL no Azure e migrar a carga de trabalho em execução no computador Linux da 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 a migração – como para bancos de dados ou ferramentas de implantação no caso de servidores Web.

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

A largura de banda da replicação de dados para o Azure depende de uma variedade de fatores e é uma função que indica com qual rapidez 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 ocorridas desde o ciclo de replicação anterior.

Para um método de replicação baseado em agente, o Planejador de Implantações pode ajudar a analisar o ambiente quanto à rotatividade de dados e ajudar a prever o requisito de largura de banda necessário. Para saber mais, acesse este artigo

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 máquinas virtuais VMware e máquinas virtuais Hyper-V que executam Windows ou Linux. A ferramenta também fornece uma opção de replicação baseada em agente adicional para servidores Windows e Linux que podem ser usados para migrar servidores físicos, bem como máquinas virtuais x86/x64 no VMware, no Hyper-V, na AWS, no GCP etc. A opção de replicação baseada em agente requer a instalação do software do agente no servidor/máquina virtual que está sendo migrado, enquanto que, na opção sem agente, nenhum software precisa ser instalado nas máquinas virtuais, oferecendo, assim, conveniência e simplicidade adicionais sobre a opção de replicação baseada em agente.

A opção de replicação sem agente funciona usando mecanismos fornecidos pelo provedor de virtualização (VMware, Hyper-V). No caso de máquinas virtuais 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 máquina virtual.

Quando a replicação é configurada para uma máquina virtual, ela passa primeiro por uma fase de replicação inicial. Durante a replicação inicial, um instantâneo de VM é tirado e uma cópia completa dos dados dos discos de instantâneo é replicada para os 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). Na fase de replicação incremental, as alterações de dados ocorridas desde o último ciclo de replicação concluído são periodicamente replicadas e aplicadas aos discos gerenciados de réplica, mantendo, assim, a replicação em sincronia com as alterações que ocorrem na VM. No caso de máquinas virtuais VMware, a tecnologia de rastreamento de blocos alterados do VMware é usada para manter o controle das alterações entre os ciclos de replicação. No início do ciclo de replicação, um instantâneo de VM é tirado e o controle de blocos alterados é usado para obter as alterações entre o instantâneo atual e o último instantâneo replicado com êxito. Dessa forma, somente os dados que foram alterados desde o último ciclo de replicação concluído precisam ser replicados para manter a replicação da VM em sincronia. Ao final de cada ciclo de replicação, o instantâneo é liberado e a fusão de instantâneo é executada para a máquina virtual. Da mesma forma, no caso de máquinas virtuais Hyper-V, o mecanismo de controle de alterações da réplica do Hyper-V é usado para manter o controle das alterações entre os ciclos de replicação consecutivos.

Ao executar a operação de migração em uma máquina virtual de replicação, você tem a opção de desligar a máquina virtual local e executar uma replicação incremental final para garantir que não haja nenhuma perda de dados. Quando você executa a migração, os discos gerenciados de réplica correspondentes à máquina virtual são usados para criar a máquina virtual no Azure.

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

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

A largura de banda da replicação de dados para o Azure depende de uma variedade de fatores e é uma função que indica com qual rapidez 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 ocorridas desde o ciclo de replicação anterior.

Você pode solucionar o requisito de largura de banda com base no volume de dados necessário para ser migrado na onda e no horário em que você deseja que a replicação inicial seja concluída (o ideal é que a replicação inicial tenha sido concluída pelo menos de 3 a 4 dias antes da janela de migração real para dar tempo suficiente de executar uma migração de teste antes da janela real e para manter um tempo de inatividade mínimo durante a janela).

Próximas etapas

Leia a visão geral das Migrações para Azure.