Migração do servidor Azure Migrate: Questões comuns

Este artigo responde a perguntas comuns sobre a ferramenta Azure Migrate: Server Migration. Se tiver outras questões, verifique estes recursos:

Perguntas gerais

Quais são as opções de migração em Azure Migrate: Migração de servidores?

A ferramenta Azure Migrate: Server Migration oferece duas opções para migrar os seus servidores de origem e máquinas virtuais para Azure: migração sem agentes e migração baseada em agentes.

Independentemente da opção de migração escolhida, o primeiro passo para migrar um servidor usando a migração do Azure: A migração do servidor é iniciar a replicação para o servidor. Isto executa uma replicação inicial dos seus dados VM/servidor para Azure. Após a replicação inicial ser concluída, é estabelecida uma replicação em curso (delta-sync em curso) para migrar dados incrementais para Azure. Uma vez que a operação atinja a fase delta-sync, pode optar por migrar para Azure a qualquer momento.

Eis algumas considerações a ter em mente ao decidir sobre a opção de migração.

As migrações sem agentes não requerem que nenhum software (agentes) seja implantado na origem VMs/servidores que estão a ser migrados. A opção sem agente orquestra a replicação integrando-se com a funcionalidade fornecida pelo fornecedor de virtualização. As opções de replicação sem agente estão disponíveis para VMware VMs e VMs Hiper-V.

As migrações baseadas em agentes exigem que o software (agentes) Azure Migrate seja instalado na fonte VMs/máquinas a migrar. A opção baseada em agente não depende da plataforma de virtualização para a funcionalidade de replicação. Portanto, pode ser usado com qualquer servidor executando uma arquitetura x86/x64 e uma versão de um sistema operativo suportado pelo método de replicação baseado em agente.

A opção de migração baseada em agentes pode ser utilizada para VMware VMs, Hiper-VMs, servidores físicos, VMs em execução em AWS,VMs em execução em GCP, ou VMs em execução em um fornecedor de virtualização diferente. A migração baseada em agentes trata as suas máquinas como servidores físicos para migração.

Embora a migração sem agente ofereça outra conveniência e simplicidade sobre as opções de replicação baseadas em agente para os cenários suportados (VMware e Hyper-V), você pode considerar a utilização do cenário baseado no agente para os seguintes casos de utilização:

  • Ambiente constrangido do IOPS: A replicação sem agente utiliza instantâneos e consome armazenamento IOPS/largura de banda. Recomendamos o método de migração baseado em agente se houver restrições no armazenamento/IOPS no seu ambiente.
  • Se não tiver um servidor vCenter, pode tratar os seus VMware VMs como servidores físicos e utilizar o fluxo de trabalho de migração baseado em agentes.

Para saber mais, reveja este artigo para comparar opções de migração para migrações VMware.

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

Reveja as regiões suportadas em clouds públicas e do Azure Government.

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

Embora possa criar avaliações para várias regiões num projeto Azure Migrate, um projeto Azure Migrate pode ser usado para migrar servidores apenas para uma região de Azure. Você pode criar projetos adicionais de Azure Migrate para cada região para onde precisa migrar.

  • Para migrações de VMware sem agente, a região alvo fica bloqueada assim que ativar a primeira replicação.
  • Para migrações baseadas em agentes (VMware, servidores físicos e servidores de outras nuvens), a região alvo é bloqueada uma vez que o botão "Criar Recursos" é clicado no portal enquanto configura o aparelho de replicação.
  • Para migrações hiper-V sem agente, a região alvo é bloqueada uma vez que o botão "Criar Recursos" é clicado no portal enquanto configura o fornecedor de replicação Hyper-V.

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

Sim, você pode migrar para várias subscrições (o mesmo inquilino Azure) na mesma região alvo para um projeto Azure Migrate. Pode selecionar a subscrição-alvo enquanto permite a replicação de uma máquina ou de um conjunto de máquinas. A região alvo é a primeira replicação de postes bloqueados para migrações de VMware sem agente e durante a instalação de aparelhos de replicação e fornecedor de hiper-V para migrações baseadas em agentes e migrações de hiper-V sem agente, respectivamente.

Como é transmitidos os dados do ambiente on-prem para o Azure? Está encriptado antes da transmissão?

O aparelho Azure Migrate no caso de replicação sem agente comprime dados e encripta antes de ser carregado. Os dados são transmitidos através de um canal de comunicação seguro através de https e utilizam o TLS 1.2 ou mais tarde. Além disso, o Azure Armazenamento encripta automaticamente os seus dados quando estes são persistidos na nuvem (encriptação em repouso).

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

Não recomendamos a utilização do cofre de serviços de recuperação criado pela Azure Migrate para cenários de recuperação de desastres. Fazê-lo pode resultar em falhas de replicação de início em Azure Migrate.

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

A migração de testes fornece uma forma de testar e validar migrações antes da migração real. Testar a migração funciona permitindo-lhe criar cópias de teste de replicação de VMs num ambiente de caixa de areia em Azure. O ambiente da caixa de areia é demarcado por uma rede virtual de teste que especifica. A operação de migração de testes não é disruptiva, com as aplicações a continuarem a funcionar na fonte enquanto lhe permite realizar testes numa cópia clonada num ambiente isolado de caixa de areia. Pode realizar vários testes conforme necessário para validar a migração, realizar testes de aplicações e resolver quaisquer problemas antes da migração real.

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

Pode utilizar a opção de Migração de Testes para validar a funcionalidade e desempenho da sua aplicação no Azure. Pode realizar qualquer número de migrações de teste e executar a migração final depois de estabelecer confiança através da operação de migração de testes. Uma migração de teste não afeta a máquina no local, que permanece operacional e continua a replicar-se até que realize a migração real. Se houve erros durante a migração do teste UAT, pode optar por adiar a migração final e manter a sua fonte VM/servidor em funcionamento e replicação para Azure. Pode voltar a atacar a migração final assim que resolver os erros.
Nota: Uma vez realizada uma migração final para Azure e a máquina de origem no local foi desligada, não é possível efetuar uma reversão de Azure para o seu ambiente no local.

Posso selecionar a Rede Virtual e a sub-rede para usar para fazer migrações de teste?

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-alvo (que não seja o padrão) foi especificada como uma entrada enquanto permite a replicação, então a Azure Migrate prioriza usando uma sub-rede com o mesmo nome na Rede Virtual selecionada para a migração do teste.
  • Se a sub-rede com o mesmo nome não for encontrada, então a Azure Migrate seleciona a primeira sub-rede disponível alfabeticamente que não é uma sub-rede Gateway/Application Gateway/Firewall/Bastion.

Porque é que o botão de migração de teste está desativado para o meu Servidor?

O botão de migração do teste pode estar num estado de desativação nos seguintes cenários:

  • Não é possível iniciar uma migração de teste até que uma replicação inicial (IR) esteja concluída para o VM. O botão de migração do teste será desativado até que o processo de INFRA esteja concluído. Pode realizar uma migração de teste uma vez que o seu VM esteja numa fase de sincronização delta.
  • O botão pode ser desativado se uma migração de teste já estiver concluída, mas não foi realizada uma limpeza de migração de testes para esse VM. Efetue uma limpeza de migração de teste e relempenhem a operação.

O que acontece se eu não limpar a migração do meu teste?

A migração de testes simula a migração real criando um teste Azure VM usando dados replicados. O servidor será implantado com uma cópia pontual dos dados replicados para o Grupo de Recursos alvo (selecionado enquanto permite a replicação) com um sufixo "teste". As migrações de teste destinam-se a validar a funcionalidade do servidor de modo a minimizar os problemas de migração pós-migração. Se a migração do teste não for limpa após os testes, a máquina virtual de teste continuará a funcionar em Azure e incorrerá em cargas. Para limpar a migração de teste, vá à visualização das máquinas de replicação na ferramenta de migração do servidor e utilize a ação de "migração de testes de limpeza" na máquina.

Como sei se o meu VM foi migrado com sucesso?

Uma vez migrado o seu VM/servidor com sucesso, pode visualizar e gerir o VM a partir da página Máquinas Virtuais. Ligação ao VM migrado para validar. Em alternativa, pode rever o "Estado do Trabalho" para a operação para verificar se a migração foi concluída com sucesso. Se vir algum erro, resolva-os e recandiduça a operação de migração.

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

Quando para a replicação, a ferramenta Azure Migrate: Server Migration limpa os discos geridos na subscrição que foram criados para replicação. Se não parar a replicação após uma migração, continuará a incorrer em taxas para estes discos. A replicação de stop não impactará os discos ligados a máquinas que já foram migradas.

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

Azure Migrate: A ferramenta de migração do servidor migra máquinas baseadas em UEFI para Azure como Azure geração 2 VMs. Se quiser emigrá-los para a geração Azure 1 VMs, converta o tipo de bota em BIOS antes de iniciar a replicação e, em seguida, utilize a ferramenta Azure Migrate: Server Migration para migrar para Azure.

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

Azure Migrate: A ferramenta de migração do servidor migra todas as máquinas baseadas na UEFI para Azure como Azure geração 2 VMs. Já não apoiamos a conversão de VMs baseados na UEFI em VMs baseados em BIOS. Todas as máquinas baseadas em BIOS são migradas para Azure como apenas a geração Azure 1 VMs.

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

Sistemas operativos suportados para máquinas baseadas na UEFI VMware sem agente para Azure Hyper-V sem agente para Azure VMware baseado em agente, nuvens físicas e outras para Azure
Windows Servidor 2019, 2016, 2012 R2, 2012 Y Y Y
Windows 10 Pro, Windows 10 Enterprise Y Y Y
SUSE Linux Enterprise Server 15 SP1 Y Y Y
SUSE Linux Enterprise Server 12 SP4 Y Y Y
Ubuntu Server 16.04, 18.04, 19.04, 19.10 Y Y Y
RHEL 8.1, 8.0, 7.8, 7.7, 7.6, 7.5, 7.4, 7.0, 6.x Y
RHEL 8.x requer preparação manual
Y Y
Cent OS 8.1, 8.0, 7.7, 7.6, 7.5, 7.4, 6.x Y
Cent OS 8.x requer preparação manual
Y Y
Oracle Linux 7.7, 7.7-CI Y Y Y

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

A ferramenta de migração do servidor é agnóstica de aplicação e funciona para a maioria das aplicações. Quando migrar um servidor utilizando a ferramenta De migração do servidor, todas as aplicações instaladas no servidor são migradas juntamente com ele. No entanto, para algumas aplicações, métodos de migração alternativos que não a migração de servidores podem ser mais adequados para a migração. Para o Ative Directory, no caso de ambientes híbridos onde o site no local está ligado ao seu ambiente Azure, pode estender o seu Diretório para Azure adicionando controladores de domínio extra em Azure e configurando a replicação ative directy. Se estiver a migrar para um ambiente isolado em Azure, exigindo os seus próprios controladores de domínio (ou testar aplicações num ambiente de caixa de areia), pode migrar servidores utilizando a ferramenta de migração do servidor.

Posso atualizar o meu so durante a migração?

A ferramenta Azure Migrate: A ferramenta de migração do servidor apenas suporta migrações similares atualmente. A ferramenta não suporta o upgrade da versão SO durante a migração. A máquina migrada terá o mesmo SISTEMA que a máquina de origem.

Preciso de VMware vCenter para migrar VMware VMs?

Para migrar VMware VMs utilizando a migração baseada em agentes VMware ou sem agentes, os anfitriões ESXi nos quais estão localizados os VMs devem ser geridos pelo vCenter Server. Se não tiver vCenter Server, pode migrar VMware VMs migrando-os como servidores físicos. Saiba mais.

Posso consolidar vMs de múltiplas fontes em um VM enquanto migra?

Azure Migrate servidor capacidades de migração suportam como migrações atualmente. Não suportamos a consolidação de servidores ou a atualização do sistema operativo como parte da migração.

Será Windows Server 2008 e 2008 R2 será suportado em Azure após a migração?

Pode migrar os seus servidores Windows Server 2008 e 2008 para máquinas virtuais Azure e obter Atualizações de Segurança Alargadas durante três anos após as datas de Fim de Suporte, sem custos adicionais acima do custo de funcionamento da máquina virtual. Pode utilizar a ferramenta Azure Migrate: Server Migration para migrar as cargas de trabalho do Windows Server 2008 e 2008 R2.

Como posso migrar Windows Server 2003 a funcionar em VMware/Hyper-V para Azure?

Windows Suporte alargado do Servidor 2003 terminou em 14 de julho de 2015. A equipa de suporte do Azure continua a ajudar na resolução de problemas que dizem respeito a correr Windows Server 2003 no Azure. No entanto, este suporte está limitado a questões que não requerem resolução de problemas ou patches ao nível do SISTEMA. Migrar as suas aplicações para instâncias Azure executando uma versão mais recente do Windows Server é a abordagem recomendada para garantir que você está efetivamente usando a flexibilidade e fiabilidade da nuvem Azure.

No entanto, se ainda optar por migrar o seu Windows Server 2003 para Azure, pode utilizar a ferramenta Azure Migrate: Server Migration se o seu Windows Server for um VM em execução em VMware ou Hyper-V Review este artigo para preparar as suas máquinas Windows Server 2003 para migração.

Migração de VMware sem agente

Como funciona a migração sem agente?

Azure Migrate: A Migração do Servidor oferece opções de replicação sem agentes para a migração de máquinas virtuais VMware e máquinas virtuais Hiper-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 podem ser usados para migrar servidores físicos, e máquinas virtuais x86/x64 em VMware, Hyper-V, AWS, GCP, etc. A opção de replicação baseada em agente requer a instalação de software de agente no servidor/máquina virtual que está a ser migrado, enquanto na opção sem agente nenhum software precisa de ser instalado nas próprias máquinas virtuais, oferecendo assim mais comodidade e simplicidade sobre a opção de replicação baseada no agente.

A opção de replicação sem agente funciona utilizando mecanismos fornecidos pelo fornecedor de virtualização (VMware, Hyper-V). No caso das máquinas virtuais VMware, o mecanismo de replicação sem agente utiliza instantâneos VMware e VMware alterou a tecnologia de rastreio de blocos para replicar dados de discos de máquinas virtuais. Este mecanismo é semelhante ao utilizado por muitos produtos de reserva. No caso das máquinas virtuais Hyper-V, o mecanismo de replicação sem agente utiliza instantâneos VM e a capacidade de rastreio de alterações da réplica Hyper-V para replicar dados de discos de máquinas virtuais.

Quando a replicação é configurada para uma máquina virtual, passa primeiro por uma fase inicial de replicação. Durante a replicação inicial, é tirada uma imagem VM e uma cópia completa dos dados dos discos instantâneos são replicados em discos geridos na sua subscrição. Após a replicação inicial para o VM estar concluída, o processo de replicação transita para uma fase de replicação incremental (replicação delta). Na fase de replicação incremental, as alterações de dados que ocorreram desde o último ciclo de replicação concluído são periodicamente replicadas e aplicadas aos discos geridos por réplicas, mantendo assim a replicação em sincronização com as alterações que ocorriam no VM. No caso das máquinas virtuais VMware, a tecnologia de rastreio de blocos alterada da VMware é utilizada para acompanhar as mudanças entre ciclos de replicação. No início do ciclo de replicação, é tirada uma imagem VM e é utilizada uma localização de blocos alterada para obter as alterações entre o instantâneo atual e o último instantâneo replicado com sucesso. Desta forma, apenas os dados que mudaram desde o último ciclo de replicação concluído precisam de ser replicados para manter a replicação para o VM em sincronização. No final de cada ciclo de replicação, o instantâneo é libertado e a consolidação do instantâneo é realizada para a máquina virtual. Da mesma forma, no caso das máquinas virtuais Hyper-V, o motor de rastreio de mudança de réplica Hiper-V é utilizado para acompanhar as mudanças entre ciclos de replicação consecutivos. Quando executa a operação de migração numa máquina virtual replicante, tem a opção de desligar a máquina virtual no local e executar uma replicação incremental final para garantir a perda zero de dados. Ao executar a opção migradora, os discos geridos por réplica correspondentes à máquina virtual são utilizados para criar a máquina virtual em Azure.

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

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

A largura de banda para replicação de dados para a Azure depende de uma série de fatores e é uma função da rapidez com que o aparelho Azure Migrate 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 começa para um VM, ocorre um ciclo inicial de replicação no qual cópias completas dos discos são replicadas. Após a replicação inicial estar concluída, os ciclos de replicação incrementais (ciclos delta) são programados periodicamente para transferir quaisquer alterações que tenham ocorrido desde o ciclo de replicação anterior.

Pode calcular o requisito de largura de banda com base no volume de dados necessário para ser movido na onda e tempo em que gostaria que a replicação inicial fosse completada (idealmente, gostaria que a replicação inicial tivesse completado pelo menos 3-4 dias antes da janela de migração real para lhe dar tempo suficiente para realizar uma migração de teste antes da janela real e para manter o tempo de inatividade ao mínimo durante a janela).

Pode estimar a largura de banda ou o tempo necessário para a migração VMware VM sem agente utilizando a seguinte fórmula:

Tempo para completar a replicação inicial = {tamanho de 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 acelerar a replicação na utilização do aparelho Azure Migrate para a replicação de VMware sem agente?

Pode acelerar usando a NetQosPolicy. Por exemplo:

O AppNamePrefix para usar na NetQosPolicy é "GatewayWindowsService.exe". Pode criar uma política sobre o aparelho Azure Migrate para acelerar o tráfego de replicação do aparelho, criando uma política como esta:

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

De forma a aumentar e diminuir a largura de banda de replicação com base num horário, pode aproveitar Windows tarefa programada para escalar a largura de banda conforme necessário. Uma tarefa será usada para diminuir a largura de banda, e outra tarefa será usada para aumentar a largura de banda. Nota: É necessário criar a NetQosPolicy, descrita 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 é que a taxa de churn afeta a replicação sem agente?

Como a replicação sem agente se dobra nos dados, o padrão de churn é mais importante do que a taxa de churn. Quando um ficheiro é escrito uma e outra vez, a taxa não tem muito impacto. No entanto, um padrão em que todos os outros sectores são escritos causa uma grande agitação no ciclo seguinte. Como minimizamos a quantidade de dados que transferimos, permitimos que os dados dobrem o máximo possível antes de agendarmos o próximo ciclo.

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

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

Por exemplo, se um VM demorar quatro horas para um ciclo delta, o próximo ciclo é programado 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 é programado imediatamente.

Implementei dois (ou mais) aparelhos para descobrir VMs no meu servidor vCenter. No entanto, quando tento migrar os VMs, só vejo VMs correspondentes a um dos aparelhos.

Se existirem várias aplicações configuradas, será necessário que não haja nenhuma sobreposição entre as VMs nas contas do vCenter indicadas. Uma deteção com uma sobreposição desse tipo é um cenário não suportado.

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

A replicação sem agente resulta em algum impacto de desempenho nos anfitriões VMware vCenter Server e VMware ESXi. Como a replicação sem agente utiliza instantâneos, consome IOPS no armazenamento, pelo que é necessária uma largura de banda de armazenamento IOPS. Não recomendamos a utilização de replicação sem agente se tiver restrições no armazenamento ou IOPs no seu ambiente.

Migração baseada em agentes

Como posso migrar os meus casos AWS EC2 para Azure?

Reveja o artigo para descobrir, avaliar e migrar as suas instâncias AWS EC2 para Azure.

Como funciona a migração baseada em agentes?

Além das opções de migração sem agente para máquinas virtuais VMware e máquinas virtuais Hiper-V, a ferramenta de migração do servidor fornece uma opção de migração baseada em agentes para migrar servidores Windows e Linux em servidores físicos, ou funcionando como máquinas virtuais x86/x64 em VMware, Hyper-V, AWS, Google Cloud Platform, etc.

O método de migração baseado em agente utiliza software de agente instalado no servidor em migração para replicar dados do servidor para OZure. O processo de replicação utiliza uma arquitetura de descarregamento na qual o agente retransmite dados de replicação a um servidor de replicação dedicado chamado de aparelho de replicação ou Servidor de Configuração (ou a um Servidor de Processo de escala). Saiba mais sobre como funciona a opção de migração baseada em agentes.

Nota: O aparelho de replicação é diferente do aparelho de descoberta Azure Migrate e deve ser instalado numa máquina separada/dedicada.

Onde devo instalar o aparelho de replicação para migrações baseadas em agentes?

O aparelho de replicação deve ser instalado numa máquina dedicada. O aparelho de replicação não deve ser instalado numa máquina de origem que pretende replicar ou no aparelho Azure Migrate (utilizado para a descoberta e avaliação) que possa ter instalado antes. Siga o tutorial para mais detalhes.

Posso migrar VMS AWS com sistema operativo Amazon Linux?

Os VMs que executam o Amazon Linux não podem ser migrados como é, uma vez que o Amazon Linux OS é apenas suportado em AWS. Para migrar cargas de trabalho em execução no Amazon Linux, você pode girar um CentOS/RHEL VM em Azure e migrar a carga de trabalho em execução na máquina AWS Linux usando uma abordagem de migração de carga de trabalho relevante. Por exemplo, dependendo da carga de trabalho, pode existir ferramentas específicas da carga de trabalho para ajudar na migração – como por exemplo, para bases de dados ou ferramentas de implementação no caso de servidores web.

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

A largura de banda para replicação de dados para a Azure depende de uma série de fatores e é uma função da rapidez com que o aparelho Azure Migrate 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 começa para um VM, ocorre um ciclo inicial de replicação no qual cópias completas dos discos são replicadas. Após a replicação inicial estar concluída, os ciclos de replicação incrementais (ciclos delta) são programados periodicamente para transferir quaisquer alterações que tenham ocorrido desde o ciclo de replicação anterior.

Para um método de replicação baseado em agente, o Planejador de Implementação pode ajudar a perfilar o ambiente para o churn de dados e ajudar a prever o requisito de largura de banda necessário. Para saber mais, veja este artigo

Migração hiper-V sem agente

Como funciona a migração sem agente?

Azure Migrate: A Migração do Servidor oferece opções de replicação sem agentes para a migração de máquinas virtuais VMware e máquinas virtuais Hiper-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 em VMware, Hyper-V, AWS, GCP, etc. A opção de replicação baseada em agente requer a instalação de software de agente no servidor/máquina virtual que está a ser migrado, enquanto na opção sem agente nenhum software precisa de ser instalado nas próprias máquinas virtuais, oferecendo assim comodidade e simplicidade adicionais sobre a opção de replicação baseada no agente.

A opção de replicação sem agente funciona utilizando mecanismos fornecidos pelo fornecedor de virtualização (VMware, Hyper-V). No caso das máquinas virtuais Hyper-V, o mecanismo de replicação sem agente utiliza instantâneos VM e a capacidade de rastreio de alterações da réplica Hyper-V para replicar dados de discos de máquinas virtuais.

Quando a replicação é configurada para uma máquina virtual, passa primeiro por uma fase inicial de replicação. Durante a replicação inicial, é tirada uma imagem VM e uma cópia completa dos dados dos discos instantâneos são replicados em discos geridos na sua subscrição. Após a replicação inicial para o VM estar concluída, o processo de replicação transita para uma fase de replicação incremental (replicação delta). Na fase de replicação incremental, as alterações de dados que ocorreram desde o último ciclo de replicação concluído são periodicamente replicadas e aplicadas aos discos geridos por réplicas, mantendo assim a replicação em sincronização com as alterações que ocorriam no VM. No caso das máquinas virtuais VMware, a tecnologia de rastreio de blocos alterada da VMware é utilizada para acompanhar as mudanças entre ciclos de replicação. No início do ciclo de replicação, é tirada uma imagem VM e é utilizada uma localização de blocos alterada para obter as alterações entre o instantâneo atual e o último instantâneo replicado com sucesso. Desta forma, apenas os dados que mudaram desde o último ciclo de replicação concluído precisam de ser replicados para manter a replicação para o VM em sincronização. No final de cada ciclo de replicação, o instantâneo é libertado e a consolidação do instantâneo é realizada para a máquina virtual. Da mesma forma, no caso das máquinas virtuais Hyper-V, o motor de rastreio de mudança de réplica Hiper-V é utilizado para acompanhar as mudanças entre ciclos de replicação consecutivos.

Quando executa a operação de migração numa máquina virtual replicante, tem a opção de desligar a máquina virtual no local e executar uma replicação incremental final para garantir a perda zero de dados. Ao executar a opção migradora, os discos geridos por réplica correspondentes à máquina virtual são utilizados para criar a máquina virtual em Azure.

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

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

A largura de banda para replicação de dados para a Azure depende de uma série de fatores e é uma função da rapidez com que o aparelho Azure Migrate 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 começa para um VM, ocorre um ciclo inicial de replicação no qual cópias completas dos discos são replicadas. Após a replicação inicial estar concluída, os ciclos de replicação incrementais (ciclos delta) são programados periodicamente para transferir quaisquer alterações que tenham ocorrido desde o ciclo de replicação anterior.

Pode calcular o requisito de largura de banda com base no volume de dados necessário para ser movido na onda e tempo em que gostaria que a replicação inicial fosse completada (idealmente, gostaria que a replicação inicial tivesse completado pelo menos 3-4 dias antes da janela de migração real para lhe dar tempo suficiente para realizar uma migração de teste antes da janela real e para manter o tempo de inatividade ao mínimo durante a janela).

Passos seguintes

Leia a visão geral do Azure Migrate.