Migração e modernização: perguntas comuns
Atenção
Este artigo faz referência ao CentOS, uma distribuição Linux que está se aproximando do status de Fim da Vida Útil (EOL). Por favor, considere o seu uso e planejamento de acordo. Para obter mais informações, consulte as diretrizes de Fim da Vida Útil do CentOS.
Este artigo responde a perguntas comuns sobre a ferramenta Migração e modernização. Se tiver outras dúvidas, consulte estes recursos:
- Perguntas gerais sobre o Azure Migrate
- Perguntas sobre o dispositivo Azure Migrate
- Perguntas sobre descoberta, avaliação e visualização de dependência
- Obter respostas para perguntas no fórum Azure Migrate
Perguntas gerais
Quais são as opções de migração em Migração e modernização?
A ferramenta Migração e modernização oferece duas opções para migrar seus servidores de origem e máquinas virtuais para o Azure: migração sem agente e migração baseada em agente.
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. Isso executa uma replicação inicial dos dados da VM/servidor 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. Quando a operação atingir o estágio de sincronização delta, você poderá optar por migrar para o Azure a qualquer momento.
Aqui estão algumas considerações a 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 Azure Migrate (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 a funcionalidade de replicação. Portanto, ele pode ser usado com qualquer servidor que execute uma arquitetura x86/x64 e uma versão de um sistema operacional suportado pelo método de replicação baseado em agente.
A opção de migração baseada em agente pode ser usada para VMs VMware, VMs Hyper-V, servidores físicos, VMs em execução na AWS, VMs em execução no GCP ou 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.
Embora a migração sem agente ofereça outra conveniência e simplicidade em relação às opções de replicação baseadas em agente para os cenários suportados (VMware e Hyper-V), convém considerar o uso do cenário baseado em agente para os seguintes casos de uso:
- Ambiente restrito de IOPS: 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.
- 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, leia este artigo para comparar as opções de migração para migrações VMware.
Quais regiões geográficas são suportadas para migração com o Azure Migrate?
Reveja as regiões suportadas em clouds públicas e do Azure Government.
Posso usar o mesmo projeto do Azure Migrate para migrar para várias regiões?
Embora você possa criar avaliações para várias regiões em um projeto do Azure Migrar, um projeto do Azure Migrate pode ser usado para migrar servidores para apenas uma região do Azure. Você pode criar projetos adicionais do Azure Migrate para cada região para a qual precisa migrar.
- Para migrações VMware sem agente, a região de destino é bloqueada assim que 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 assim que o botão "Criar recursos" é selecionado 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 o botão "Criar recursos" é selecionado no portal durante a configuração do provedor de replicação do Hyper-V.
Posso usar o mesmo projeto do Azure Migrate para migrar para várias assinaturas?
Sim, você pode migrar para várias assinaturas (mesmo locatário do Azure) na mesma região de destino para um projeto do Azure Migrate. Você pode selecionar a assinatura de destino enquanto habilita a replicação para uma máquina ou um conjunto de máquinas. A região de destino é bloqueada após a primeira replicação para migrações VMware sem agente e durante a instalação do dispositivo de replicação e do provedor Hyper-V para migrações baseadas em agente e migrações Hyper-V sem agente, respectivamente.
Como os dados são transmitidos do ambiente local para o Azure? É encriptado antes da transmissão?
O dispositivo Azure Migrate no caso de replicação sem agente compacta dados e criptografa antes de 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 criptografa automaticamente seus dados quando eles persistem na nuvem (criptografia em repouso).
Posso usar o cofre de serviços de recuperação criado pelo Azure Migrate para cenários de recuperação de desastres?
Não recomendamos o uso do cofre de serviços de recuperação criado pelo Azure Migrate para cenários de recuperação de desastres. Isso pode resultar em falhas de replicação de início no Azure Migrate.
Qual é a diferença entre as operações Test Migration e Migration?
A migração de teste fornece uma maneira de testar e validar migrações antes da migração real. A migração de teste funciona permitindo que você use um ambiente de área restrita no Azure para testar as máquinas virtuais antes da migração real. O ambiente de área restrita é demarcado por uma rede virtual de teste especificada. A operação de migração de teste não causa interrupções, desde que a VNet de teste esteja suficientemente isolada. VNet isolada aqui significa que as regras de conexão de entrada e saída são projetadas para evitar conexões indesejadas. Por exemplo, a conexão com máquinas locais é restrita.
Os aplicativos podem continuar a ser executados na origem, permitindo 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 quaisquer problemas antes da migração real.
Existe uma opção de Reversão para o Azure Migrate?
Você pode usar a opção Migração de Teste para validar a funcionalidade e o desempenho do aplicativo no Azure. Você pode executar qualquer número de migrações de teste e pode executar a migração final depois de estabelecer confiança por meio da operação de 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 UAT de migração de teste, você pode optar por adiar a migração final e manter sua VM/servidor de origem em execução e replicando para o Azure. Você pode tentar novamente a migração final depois de resolver os erros. Observação: depois de executar uma migração final para o Azure e a máquina de origem local ter sido desligada, você não poderá executar uma reversão do Azure para seu ambiente local.
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. A sub-rede é selecionada automaticamente com base na seguinte lógica:
- Se uma sub-rede de destino (diferente do padrão) foi especificada como uma entrada ao habilitar a replicação, o Azure Migrate priorizará 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 Azure Migrate selecionará a primeira sub-rede disponível alfabeticamente que não seja uma sub-rede Gateway/Application Gateway/Firewall/Bastion.
Por que o botão Testar migração está desativado para o meu servidor?
O botão de migração de teste pode estar em um estado desabilitado nos seguintes cenários:
- Não é possível iniciar uma migração de teste até que uma replicação inicial (IR) tenha sido concluída para a VM. O botão de migração de teste será desativado até que o processo de RI seja concluído. Você pode executar uma migração de teste quando sua VM estiver em um estágio de sincronização delta.
- O botão pode ser desativado se uma migração de teste já tiver sido concluída, mas uma limpeza de migração de teste não tiver sido executada para essa VM. Execute uma limpeza de migração de teste e tente novamente a operação.
O que acontece se eu não limpar minha migração de teste?
A migração de teste simula a migração real criando uma VM do Azure de teste usando dados replicados. O servidor será implantado com uma cópia point-in-time dos dados replicados para o Grupo de Recursos de destino (selecionado ao habilitar a replicação) com um sufixo "-test". As migrações de teste destinam-se a validar a funcionalidade do servidor para que os problemas pós-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á a ser executada no Azure e incorrerá em encargos. Para limpar após uma migração de teste, vá para a visualização de 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 posso saber se a minha VM foi migrada com êxito?
Depois de migrar sua VM/servidor com êxito, você pode exibir e gerenciar a VM na página Máquinas Virtuais. Conecte-se à VM migrada para validar. Como alternativa, você pode revisar o 'Status do trabalho' da operação 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 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 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 afetará os discos conectados a máquinas que já foram migradas.
Como posso migrar máquinas baseadas em UEFI para o Azure como VMs da geração 1 do Azure?
A ferramenta de migração e modernização migra máquinas baseadas em UEFI para o Azure como VMs da geração 2 do Azure. Se você quiser migrá-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 migrar para o Azure.
O Azure Migrate converte máquinas baseadas em UEFI para máquinas baseadas em BIOS e as migra para o Azure como VMs da geração 1 do Azure?
A ferramenta de migração e modernização migra todas as máquinas baseadas em UEFI para o Azure como VMs da geração 2 do Azure. Não suportamos mais a conversão de VMs baseadas em UEFI em VMs baseadas em BIOS. Todas as máquinas baseadas em BIOS são migradas para o Azure apenas como VMs da geração 1 do Azure.
Quais sistemas operacionais são suportados para a migração de máquinas baseadas em UEFI para o Azure?
| Sistemas operacionais suportados para máquinas baseadas em UEFI | VMware sem agente para o Azure | Hyper-V sem agente para Azure | VMware baseado em agente, nuvens físicas e outras para o Azure |
|---|---|---|---|
| Windows Server 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 | Y | Y |
| Cent OS 8.1, 8.0, 7.7, 7.6, 7.5, 7.4, 6.x | Y | Y | Y |
| Oracle Linux 7.7, 7.7-CI | Y | Y | Y |
Posso migrar controladores de domínio do Ative Directory usando o Azure Migrate?
A ferramenta de migração e modernização é independente de aplicativos e funciona para a maioria dos aplicativos. Quando você migra um servidor usando a ferramenta Migração e modernização, todos os aplicativos instalados no servidor são migrados junto com ele. No entanto, para alguns aplicativos, métodos de migração alternativos diferentes de Migração e modernização podem ser mais adequados para a migração. Para o Ative Directory, se ambientes híbridos em que o site local está conectado ao seu ambiente do Azure, você pode estender seu diretório para o Azure adicionando controladores de domínio extras no Azure e configurando a replicação do Ative Directory. Se você estiver migrando para um ambiente isolado no Azure que exija seus 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 só suporta migrações semelhantes. A ferramenta não suporta a atualização da versão do sistema operacional durante a migração. A máquina migrada terá o mesmo sistema operacional que a máquina de origem.
Preciso do VMware vCenter para migrar VMs VMware?
Para migrar VMs VMware usando a migração baseada em agente VMware ou sem agente, os hosts ESXi nos quais as VMs estão localizadas devem ser gerenciados pelo vCenter Server. Se você não tiver o vCenter Server, poderá migrar VMs VMware migrando-as como servidores físicos. Mais informações.
Posso consolidar várias VMs de origem em uma VM durante a migração?
Atualmente, os recursos de migração e modernização oferecem suporte a migrações semelhantes. Não suportamos a consolidação de servidores ou a atualização do sistema operacional como parte da migração.
O Windows Server 2008 e o 2008 R2 terão suporte no Azure após a migração?
Você pode migrar seus servidores Windows Server 2008 e 2008 R2 locais para máquinas virtuais do Azure e obter Atualizações de Segurança Estendidas por três anos após as datas de Fim do Suporte sem custo adicional acima do custo de execução da 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 migrar o Windows Server 2003 em execução no VMware/Hyper-V para o Azure?
O suporte estendido do Windows Server 2003 terminou em 14 de julho de 2015. A equipe de suporte do Azure continua a ajudar na solução de problemas relacionados à execução do Windows Server 2003 no Azure. No entanto, esse suporte é limitado a problemas que não exigem solução de problemas ou patches no nível do sistema operacional. Migrar seus aplicativos para instâncias do Azure que executam uma versão mais recente do Windows Server é a abordagem recomendada para garantir que você esteja usando efetivamente a flexibilidade e a confiabilidade da nuvem do Azure.
No entanto, se você ainda optar por migrar o 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 Hyper-V Consulte este artigo para preparar suas máquinas Windows Server 2003 para migração.
Migração VMware sem agente
Como funciona a migração sem agente?
A ferramenta de migração e modernização fornece opções de replicação sem agente para a migração de 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 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 do software do agente no servidor/máquina virtual que está sendo migrada, enquanto na opção sem agente nenhum software precisa ser instalado nas próprias máquinas virtuais, oferecendo assim 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 snapshots VMware e a tecnologia VMware changed block tracking para replicar dados de discos de máquinas virtuais. 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 o recurso de controle de alterações da réplica do Hyper-V para replicar dados de discos de máquinas virtuais.
Quando a replicação é configurada para uma máquina virtual, ela 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). Na fase de replicação incremental, as alterações de dados que ocorreram desde o último ciclo de replicação concluído são replicadas periodicamente e aplicadas aos discos gerenciados pela réplica, mantendo assim a replicação sincronizada com as alterações que ocorrem na VM. No caso das máquinas virtuais VMware, a tecnologia VMware changed block tracking é usada para acompanhar as alterações entre os ciclos de replicação. No início do ciclo de replicação, um instantâneo da VM é tirado e o controle de bloco alterado é usado para obter as alterações entre o instantâneo atual e o último instantâneo replicado com êxito. Dessa forma, apenas os dados alterados desde o último ciclo de replicação concluído precisam ser replicados para manter a replicação da VM sincronizada. No final de cada ciclo de replicação, o snapshot é liberado e a consolidação de snapshot é executada para a máquina virtual. Da mesma forma, no caso de máquinas virtuais Hyper-V, o mecanismo de controle de alterações de réplica do Hyper-V é usado para acompanhar as alterações entre ciclos de replicação consecutivos.
Ao executar a operação de migração em uma máquina virtual replicante, você tem a opção de desligar a máquina virtual local e executar uma replicação incremental final para garantir perda zero de dados. Ao executar 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, consulte os tutoriais de migração sem agente do VMware e migração sem agente do Hyper-V.
Como posso avaliar o requisito de largura de banda para as minhas migrações?
A largura de banda para replicação de dados para o Azure depende de uma série de fatores e é uma função da rapidez com que o dispositivo Azure Migrate local pode ler e replicar os dados para o Azure. A replicação tem duas fases: replicação inicial e replicação delta.
Quando a replicação é iniciada para uma VM, ocorre um ciclo de replicação inicial no qual cópias completas dos discos são replicadas. Após a conclusão da replicação inicial, os ciclos de replicação incremental (ciclos delta) são agendados periodicamente para transferir quaisquer alterações que tenham ocorrido desde o ciclo de replicação anterior.
Você pode calcular o requisito de largura de banda com base no volume de dados necessários para serem movidos na onda e no tempo dentro do qual você gostaria que a replicação inicial fosse concluída (idealmente, você desejaria que a replicação inicial tivesse sido concluída pelo menos 3-4 dias antes da janela de migração real para dar tempo suficiente para executar uma migração de teste antes da janela real e manter o tempo de inatividade a um 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 (assumindo uma média de compressão de 30% – estimativa conservadora)}/largura de banda disponível para replicação.
Como faço para limitar a replicação no uso do dispositivo Azure Migrate para replicação VMware sem agente?
Você pode acelerar usando NetQosPolicy. Observe que essa limitação é aplicável somente às conexões de saída do dispositivo Azure Migrate. Por exemplo:
O AppNamePrefix a ser usado no NetQosPolicy é "GatewayWindowsService.exe". Você pode criar uma política no dispositivo Azure Migrate para limitar o tráfego de replicação do dispositivo criando uma política como esta:
New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB
Para aumentar e diminuir a largura de banda de replicação com base em uma programação, você pode 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 tarefa será usada para aumentar a largura de banda. Nota: 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 churn afeta a replicação sem agente?
Como a replicação sem agente dobra nos dados, o padrão de rotatividade é mais importante do que a taxa de rotatividade. Quando um arquivo é gravado repetidamente, a taxa não tem muito impacto. No entanto, um padrão em que todos os outros setores são escritos causa alta rotatividade no próximo ciclo. Como minimizamos a quantidade de dados que transferimos, permitimos que os dados se dobrem o máximo possível antes de programarmos 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 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. No entanto, quando tento migrar as VMs, vejo apenas VMs correspondentes a um dos dispositivos.
Se houver vários dispositivos configurados, é necessário que não haja sobreposição entre as VMs nas contas do vCenter fornecidas. Uma deteção com uma sobreposição desse tipo é um cenário não suportado.
Como a replicação sem agente afeta os servidores VMware?
A replicação sem agente resulta em algum impacto no desempenho dos hosts VMware vCenter Server e VMware ESXi. Como a replicação sem agente usa snapshots, ela consome IOPS no armazenamento, portanto, alguma largura de banda de armazenamento de IOPS é necessária. Não recomendamos o uso da replicação sem agente se você tiver restrições de armazenamento ou IOPs em seu ambiente.
Posso usar o Azure Migrate para migrar meus aplicativos Web para o Serviço de Aplicativo do Azure?
Você pode executar a migração sem agente em escala de aplicativos Web ASP.NET executados em servidores Web IIS hospedados em um sistema operacional Windows em um ambiente VMware. Mais informações.
Migração baseada em agente
Como posso migrar minhas instâncias do AWS EC2 para o Azure?
Analise o artigo para descobrir, avaliar e migrar suas instâncias do AWS EC2 para o Azure.
Como funciona a migração baseada em agente?
Além das opções de migração sem agente para máquinas virtuais VMware e máquinas virtuais Hyper-V, a ferramenta de migração e modernização fornece uma opção de migração baseada em agente para migrar servidores Windows e Linux executados em servidores físicos ou executados como máquinas virtuais x86/x64 em VMware, Hyper-V, AWS, 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 para o 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 dispositivo de replicação ou Servidor de Configuração (ou para um Servidor de Processo de expansão). Saiba mais sobre como funciona a opção de migração baseada em agente.
Observação: o dispositivo de replicação é diferente do dispositivo de descoberta do Azure Migrate e deve ser instalado em uma máquina separada/dedicada.
Onde devo instalar o dispositivo de replicação para migrações baseadas em agente?
O dispositivo de replicação deve ser instalado em uma máquina dedicada. O dispositivo de replicação não deve ser instalado em uma máquina de origem que você deseja replicar ou no dispositivo Azure Migrate (usado para descoberta e avaliação) que você pode ter instalado antes. Siga o tutorial para obter mais detalhes.
Posso migrar VMs da AWS que executam o sistema operacional Amazon Linux?
As VMs que executam o Amazon Linux não podem ser migradas no estado em que se encontram, pois o sistema operacional do Amazon Linux só é compatível com a AWS. Para migrar cargas de trabalho executadas no Amazon Linux, você pode criar uma VM CentOS/RHEL no 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 haver ferramentas específicas da carga de trabalho para ajudar na migração – como para bancos de dados ou ferramentas de implantaçã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 o Azure depende de uma série de fatores e é uma função da rapidez com que o dispositivo Azure Migrate local pode ler e replicar os dados para o Azure. A replicação tem duas fases: replicação inicial e replicação delta.
Quando a replicação é iniciada para uma VM, ocorre um ciclo de replicação inicial no qual cópias completas dos discos são replicadas. Após a conclusão da replicação inicial, os ciclos de replicação incremental (ciclos delta) são agendados periodicamente para transferir quaisquer alterações que tenham ocorrido desde o ciclo de replicação anterior.
Para um método de replicação baseado em agente, o Planejador de Implantação pode ajudar a traçar o perfil do ambiente para a rotatividade de dados e ajudar a prever o requisito de largura de banda necessário. Para saber mais, consulte este artigo
Migração do Hyper-V sem agente
Como funciona a migração sem agente?
A ferramenta de migração e modernização fornece opções de replicação sem agente para a migração de máquinas virtuais VMware e máquinas virtuais Hyper-V que executam Windows ou Linux. A ferramenta também fornece uma opção adicional 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 em VMware, Hyper-V, AWS, 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 migrada, enquanto na opção sem agente nenhum software precisa ser instalado nas próprias máquinas virtuais, oferecendo assim conveniência e simplicidade adicionais 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 Hyper-V, o mecanismo de replicação sem agente usa instantâneos de VM e o recurso de controle de alterações da réplica do Hyper-V para replicar dados de discos de máquinas virtuais.
Quando a replicação é configurada para uma máquina virtual, ela 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). Na fase de replicação incremental, as alterações de dados que ocorreram desde o último ciclo de replicação concluído são replicadas periodicamente e aplicadas aos discos gerenciados pela réplica, mantendo assim a replicação sincronizada com as alterações que ocorrem na VM. No caso das máquinas virtuais VMware, a tecnologia VMware changed block tracking é usada para acompanhar as alterações entre os ciclos de replicação. No início do ciclo de replicação, um instantâneo da VM é tirado e o controle de bloco alterado é usado para obter as alterações entre o instantâneo atual e o último instantâneo replicado com êxito. Dessa forma, apenas os dados alterados desde o último ciclo de replicação concluído precisam ser replicados para manter a replicação da VM sincronizada. No final de cada ciclo de replicação, o snapshot é liberado e a consolidação de snapshot é executada para a máquina virtual. Da mesma forma, no caso de máquinas virtuais Hyper-V, o mecanismo de controle de alterações de réplica do Hyper-V é usado para acompanhar as alterações entre ciclos de replicação consecutivos.
Ao executar a operação de migração em uma máquina virtual replicante, você tem a opção de desligar a máquina virtual local e executar uma replicação incremental final para garantir perda zero de dados. Ao executar 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, consulte o tutorial de migração sem agente do Hyper-V.
Como posso avaliar o requisito de largura de banda para as minhas migrações?
A largura de banda para replicação de dados para o Azure depende de uma série de fatores e é uma função da rapidez com que o dispositivo Azure Migrate local pode ler e replicar os dados para o Azure. A replicação tem duas fases: replicação inicial e replicação delta.
Quando a replicação é iniciada para uma VM, ocorre um ciclo de replicação inicial no qual cópias completas dos discos são replicadas. Após a conclusão da replicação inicial, os ciclos de replicação incremental (ciclos delta) são agendados periodicamente para transferir quaisquer alterações que tenham ocorrido desde o ciclo de replicação anterior.
Você pode calcular o requisito de largura de banda com base no volume de dados necessários para serem movidos na onda e no tempo dentro do qual você gostaria que a replicação inicial fosse concluída (idealmente, você desejaria que a replicação inicial tivesse sido concluída pelo menos 3-4 dias antes da janela de migração real para dar tempo suficiente para executar uma migração de teste antes da janela real e manter o tempo de inatividade a um mínimo durante a janela).
Próximos passos
Leia a visão geral da migração do Azure.