Migrar para o Azure Stack HCI em um novo hardware
Aplica-se a: Azure Stack HCI, versões 22H2 e 21H2; Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2008 R2
Este tópico descreve como migrar arquivos de VM (máquina virtual) no Windows Server 2012 R2, Windows Server 2016 ou Windows Server 2019 para o novo hardware de servidor do Azure Stack HCI usando Windows PowerShell e Robocopy. O Robocopy é um método robusto para copiar arquivos de um servidor para outro. Ele é retomado se desconectado e continua trabalhando do último estado conhecido. O Robocopy também dá suporte à cópia de arquivos multi-threaded no protocolo SMB. Para obter mais informações, consulte Robocopy.
Observação
Não há suporte para a Migração Dinâmica do Hyper-V e a Réplica do Hyper-V do Windows Server para o Azure Stack HCI. No entanto, o Hyper-V réplica é válido e tem suporte entre sistemas HCI. Não é possível replicar uma VM para outro volume no mesmo cluster, apenas para outro sistema HCI.
Se você tiver VMs no Windows 2012 R2 ou mais antigas que deseja migrar, consulte Migrando VMs mais antigas.
Para migrar para o Azure Stack HCI usando o mesmo hardware, confira Migrar para o Azure Stack HCI no mesmo hardware.
O diagrama a seguir mostra um cluster de origem do Windows Server e um cluster de destino do Azure Stack HCI como exemplo. Você também pode migrar VMs em servidores autônomos.
Em termos de tempo de inatividade esperado, usando uma única NIC com um RDMA duplo de 40 GB East-West rede entre clusters e Robocopy configurado para 32 multithreads, você pode perceber velocidades de transferência de 1,9 TB por hora.
Observação
A migração de VMs para clusters estendidos não é abordada neste artigo.
Antes de começar
Há vários requisitos e itens a serem considerados antes de começar a migração:
Todos os comandos Windows PowerShell devem ser executados como Administrador.
Você deve ter credenciais de domínio com permissões de administrador para clusters de origem e de destino, com direitos completos para a UO (Unidade Organizacional) de origem e destino que contém os dois clusters.
Ambos os clusters devem estar na mesma floresta e domínio do Active Directory para facilitar a autenticação Kerberos entre clusters para migração de VMs.
Ambos os clusters devem residir em uma UO do Active Directory com herança de bloco de GPO (objeto Política de Grupo) definida nessa UO. Isso garante que nenhum GPOs no nível de domínio e políticas de segurança possam afetar a migração.
Ambos os clusters devem estar conectados à mesma fonte de tempo para dar suporte à autenticação Kerberos consistente entre clusters.
Anote o nome do comutador virtual do Hyper-V usado pelas VMs no cluster de origem. Você deve usar o mesmo nome do comutador virtual para o cluster de destino do Azure Stack HCI "rede de máquina virtual" antes de importar VMs.
Remova todos os arquivos de imagem ISO para suas VMs de origem. Isso é feito usando o Gerenciador do Hyper-V em Propriedades da VM na seção Hardware. Selecione Remover para todas as unidades virtuais de CD/DVD.
Desligue todas as VMs no cluster de origem. Isso é necessário para garantir que o controle de versão e o estado sejam mantidos durante todo o processo de migração.
Verifique se o Azure Stack HCI dá suporte à sua versão das VMs para importar e atualizar suas VMs conforme necessário. Consulte a seção Suporte e atualização da versão da VM sobre como fazer isso.
Faça backup de todas as VMs no cluster de origem. Conclua um backup consistente com falhas de todos os aplicativos e dados e um backup consistente com o aplicativo de todos os bancos de dados. Para fazer backup no Azure, confira Usar Backup do Azure.
Faça um ponto de verificação das VMs do cluster de origem e do controlador de domínio caso precise reverter para um estado anterior. Isso não é aplicável a servidores físicos.
Verifique se os tamanhos máximos de quadro Jumbo são os mesmos entre as redes de armazenamento de cluster de origem e de destino, especificamente os adaptadores de rede RDMA e suas respectivas portas de rede de comutador para fornecer o tamanho do pacote de transferência de ponta a ponta mais eficiente.
Anote o nome do comutador virtual do Hyper-V no cluster de origem. Você o reutilizará no cluster de destino.
O hardware do Azure Stack HCI deve ter pelo menos capacidade e configuração iguais como o hardware de origem.
Minimize o número de saltos de rede ou distância física entre os clusters de origem e de destino para facilitar a transferência de arquivo mais rápida.
Suporte e atualização da versão da VM
Esta tabela lista as versões do sistema operacional Windows Server e suas versões de VM.
Independentemente da versão do sistema operacional em que uma VM pode estar sendo executada, a versão mínima da VM com suporte para migração direta para o Azure Stack HCI é a versão 5.0. Isso representa a versão padrão para VMs no Windows Server 2012 R2. Portanto, todas as VMs em execução na versão 2.0, 3.0 ou 4.0, por exemplo, devem ser atualizadas para a versão 5.0 antes da migração.
Versão do SO | Versão da VM |
---|---|
Windows Server 2008 SP1 | 2,0 |
Windows Server 2008 R2 | 3.0 |
Windows Server 2012 | 4,0 |
Windows Server 2012 R2 | 5.0 |
Windows Server 2016 | 8.0 |
Windows Server 2019 | 9.0 |
Azure Stack HCI | 9.0 |
Para VMs no Windows Server 2012 R2, Windows Server 2016 e Windows Server 2019, atualize todas as VMs para a versão mais recente da VM com suporte no hardware de origem primeiro antes de executar o script de migração do Robocopy. Isso garante que todas as VMs estejam pelo menos na versão 5.0 para uma importação de VM bem-sucedida.
Para VMs no Windows Server 2008 SP1, Windows Server 2008 R2-SP1 e Windows 2012, a versão da VM será menor que a versão 5.0. Essas VMs também usam um arquivo .xml para configuração em vez de um arquivo .vcmx. Dessa forma, não há suporte para uma importação direta da VM para o Azure Stack HCI. Nesses casos, você tem duas opções, conforme detalhado em Migrando VMs mais antigas.
Atualizando a versão da VM
Os comandos a seguir se aplicam a Windows Server 2012 R2 e posteriores. Use o seguinte comando para mostrar todas as versões de VM em um único servidor:
Get-VM * | Format-Table Name,Version
Para mostrar todas as versões de VM em todos os servidores em um cluster:
Get-VM –ComputerName (Get-ClusterNode)
Para atualizar todas as VMs para a versão mais recente com suporte em todos os servidores:
Get-VM –ComputerName (Get-ClusterNode) | Update-VMVersion -Force
Recomendações de RDMA
Se você estiver usando o RDMA (Acesso Remoto Direto à Memória), o Robocopy poderá aproveitá-lo para copiar suas VMs entre clusters. Aqui estão algumas recomendações para usar o RDMA:
Conecte os dois clusters à mesma opção de tor (rack) superior para usar o caminho de rede mais rápido entre clusters de origem e de destino. Para o caminho de rede de armazenamento, isso normalmente dá suporte a velocidades de 10 GbE/25 GbE ou mais altas e aproveita o RDMA.
Se o adaptador rdma ou padrão for diferente entre clusters de origem e destino (ROCE vs iWARP), o Robocopy aproveitará o SMB sobre TCP/IP por meio da rede mais rápida disponível. Normalmente, essa será uma velocidade dupla de 10 Gbe/25 Gbe ou superior para a rede East-West, fornecendo a maneira mais ideal de copiar arquivos VHDX de VM entre clusters.
Para garantir que o Robocopy possa aproveitar o RDMA entre clusters (rede Leste-Oeste), configure redes de armazenamento RDMA para que sejam roteáveis entre os clusters de origem e de destino.
Criar o novo cluster
Antes de criar o cluster do Azure Stack HCI, você precisa instalar o sistema operacional do Azure Stack HCI em cada novo servidor que estará no cluster. Para obter informações sobre como fazer isso, consulte Implantar o sistema operacional do Azure Stack HCI.
Use Windows Admin Center ou Windows PowerShell para criar o cluster. Para obter informações detalhadas sobre como fazer isso, consulte Criar um cluster do Azure Stack HCI usando Windows Admin Center e Criar um cluster do Azure Stack HCI usando Windows PowerShell.
Importante
Os nomes do comutador virtual do Hyper-V (VMSwitch
) entre clusters devem ser os mesmos. Verifique se os nomes do comutador virtual criados no cluster de destino correspondem aos usados no cluster de origem em todos os servidores. Verifique os nomes de opção para o mesmo antes de importar as VMs.
Observação
Você deve registrar o cluster do Azure Stack HCI com o Azure antes de criar novas VMs nele. Para obter mais informações, consulte Registrar-se no Azure.
Executar o script de migração
O script Robocopy_Remote_Server_.ps1
do PowerShell a seguir usa o Robocopy para copiar arquivos de VM e seus diretórios e metadados dependentes da origem para o cluster de destino. Esse script foi modificado do script original no TechNet em: Arquivos Robocopy para Servidor Remoto usando o PowerShell e o RoboCopy.
O script copia todos os arquivos VHD, VHDX e VMCX da VM para o cluster de destino para um determinado CSV (Volume Compartilhado clusterizado). Um CSV é migrado por vez.
O script de migração é executado localmente em cada servidor de origem para aproveitar o benefício do RDMA e da transferência rápida de rede. Para fazer isso:
Verifique se cada nó de cluster de destino está definido como o proprietário do CSV para o CSV de destino.
Para determinar o local de todos os arquivos VHD e VHDX da VM a serem copiados, use o cmdlet a seguir. Examine o
C:\vmpaths.txt
arquivo para determinar o caminho de arquivo de origem mais alto para o Robocopy começar da etapa 4:Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vhd*" -Recurse > c:\vmpaths.txt
Observação
Se os arquivos VHD e VHDX estiverem localizados em caminhos diferentes no mesmo volume, você precisará executar o script de migração para cada caminho diferente para copiá-los todos.
Altere as três variáveis a seguir para corresponder ao caminho da VM do cluster de origem com o caminho da VM do cluster de destino:
$Dest_Server = "Node01"
$source = "C:\Clusterstorage\Volume01"
$dest = "\\$Dest_Server\C$\Clusterstorage\Volume01"
Execute o seguinte script em cada servidor de origem do Windows Server:
<#
#===========================================================================
# Script: Robocopy_Remote_Server_.ps1
#===========================================================================
.DESCRIPTION:
Change the following variables to match your source cluster VM path with the destination cluster VM path. Then run this script on each source Cluster Node CSV owner and make sure the destination cluster node is set to the CSV owner for the destination CSV.
Change $Dest_Server = "Node01"
Change $source = "C:\Clusterstorage\Volume01"
Change $dest = "\\$Dest_Server\C$\Clusterstorage\Volume01"
#>
$Space = Write-host ""
$Dest_Server = "Node01"
$source = "C:\Clusterstorage\Volume01"
$dest = "\\$Dest_Server\C$\Clusterstorage\Volume01"
$Logfile = "c:\temp\Robocopy1-$date.txt"
$date = Get-Date -UFormat "%Y%m%d"
$cmdArgs = @("$source","$dest",$what,$options)
$what = @("/COPYALL")
$options = @("/E","/MT:32","/R:0","/W:1","/NFL","/NDL","/LOG:$logfile","/xf")
## Get Start Time
$startDTM = (Get-Date)
$Dest_Server = "Node01"
$TARGETDIR = \\$Dest_Server\C$\Clusterstorage\Volume01
$Space
Clear
## Provide Information
Write-host ".....Copying Virtual Machines FROM $Source to $TARGETDIR ....................." -fore Green -back black
Write-Host "........................................." -Fore Green
## Kick off the copy with options defined
robocopy @cmdArgs
## Get End Time
$endDTM = (Get-Date)
## Echo Time elapsed
$Time = "Elapsed Time: = $(($endDTM-$startDTM).totalminutes) minutes"
## Provide time it took
Write-host ""
Write-host " Copy Virtual Machines to $Dest_Server has been completed......" -fore Green -back black
Write-host " Copy Virtual Machines to $Dest_Server took $Time ......" -fore Cyan
Importar as VMs
Uma prática recomendada é criar pelo menos um CSV (Volume Compartilhado clusterizado) por nó de cluster para habilitar um equilíbrio uniforme de VMs para cada proprietário CSV para maior resiliência, desempenho e escala de cargas de trabalho de VM. Por padrão, esse saldo ocorre automaticamente a cada cinco minutos e precisa ser considerado ao usar o Robocopy entre um nó de cluster de origem e o nó de cluster de destino para garantir que os proprietários de CSV de origem e destino correspondam para fornecer o caminho de transferência e a velocidade mais ideais.
Execute as seguintes etapas no cluster do Azure Stack HCI para importar as VMs, torná-las altamente disponíveis e iniciá-las:
Execute o seguinte cmdlet para mostrar todos os nós de proprietário do CSV:
Get-ClusterSharedVolume
Para cada nó de servidor, acesse
C:\Clusterstorage\Volume
e defina o caminho para todas as VMs , por exemploC:\Clusterstorage\volume01
.Execute o cmdlet a seguir em cada nó de proprietário CSV para exibir o caminho para todos os arquivos VMCX da VM por volume antes da importação da VM. Modifique o caminho para corresponder ao seu ambiente:
Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vmcx" -Recurse
Observação
Windows Server 2012 R2 e VMs mais antigas usam um arquivo XML em vez de um arquivo VCMX. Para obter mais informações, consulte a seção Migrando VMs mais antigas.
Execute o cmdlet a seguir para cada nó de servidor importar, registrar e tornar as VMs altamente disponíveis em cada nó de proprietário do CSV. Isso garante uma distribuição uniforme de VMs para alocação ideal de processador e memória:
Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vmcx" -Recurse | Import-VM -Register | Get-VM | Add-ClusterVirtualMachineRole
Inicie cada VM de destino em cada nó:
Start-VM -Name
Faça logon e verifique se todas as VMs estão em execução e se todos os seus aplicativos e dados estão lá:
Get-VM -ComputerName Server01 | Where-Object {$_.State -eq 'Running'}
Atualize suas VMs para a versão mais recente do Azure Stack HCI para aproveitar todos os avanços:
Get-VM | Update-VMVersion -Force
Depois que o script for concluído, marcar o arquivo de log do Robocopy para quaisquer erros listados e para verificar se todas as VMs foram copiadas com êxito.
Migrando VMs mais antigas
Se você tiver o Windows Server 2008 SP1, Windows Server 2008 R2-SP1, Windows Server 2012 ou Windows Server 2012 VMs R2, esta seção se aplicará a você. Você tem duas opções para lidar com essas VMs:
Migre essas VMs para Windows Server 2012 R2, Windows Server 2016 ou Windows Server 2019 primeiro, atualize a versão da VM e inicie o processo de migração.
Use o Robocopy para copiar todos os VHDs de VM para o Azure Stack HCI. Em seguida, crie novas VMs e anexe os VHDs copiados às VMs no Azure Stack HCI. Isso ignora a limitação da versão da VM para essas VMs mais antigas.
Windows Server 2012 os hosts R2 e Hyper-V mais antigos usam um formato de arquivo XML para sua configuração de VM, que é diferente do formato de arquivo VCMX usado para Windows Server 2016 e hosts Hyper-V posteriores. Isso requer um comando Robocopy diferente para copiar essas VMs para o Azure Stack HCI.
Opção 1: migração em etapas
Essa é uma migração de dois estágios usada para VMs hospedadas no Windows Server 2008 SP1, Windows Server 2008 R2-SP e Windows Server 2012. Este é o processo que você usa:
Descubra o local de todos os arquivos VHD e VHDX da VM a serem copiados e examine o
vmpaths.txt
arquivo para determinar o caminho de arquivo de origem mais alto do qual o Robocopy começará. Use o seguinte cmdlet:Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vhd*" -Recurse > c:\vmpaths.txt
Use o seguinte exemplo do comando Robocopy para copiar VMs para Windows Server 2012 R2 primeiro usando o caminho mais alto determinado na etapa 1:
Robocopy \\2012R2-Clus01\c$\clusterstorage\volume01\Hyper-V\ \\20H2-Clus01\c$\clusterstorage\volume01\Hyper-V\ /E /MT:32 /R:0 /w:1 /NFL /NDL /copyall /log:c:\log.txt /xf
Verifique se o nome do comutador virtual (
VMSwitch
) usado no cluster Windows Server 2012 R2 é o mesmo que o nome do comutador usado na origem windows 2008 R2 ou Windows Server 2008 R2-SP1. Para exibir os nomes de comutador usados em todos os servidores em um cluster, use este:Get-VMSwitch -CimSession $Servers | Select-Object Name
Renomeie o nome da opção no Windows Server 20212 R2 conforme necessário. Para renomear o nome da opção em todos os servidores no cluster, use este:
Invoke-Command -ComputerName $Servers -ScriptBlock {rename-VMSwitch -Name $using:vSwitcholdName -NewName $using:vSwitchnewname}
Copie e importe as VMs para Windows Server 2012 R2:
Get-ChildItem -Path "c:\clusterstorage\volume01\Hyper-V\*.xml"-Recurse
Get-ChildItem -Path "c:\clusterstorage\volume01\image\*.xml" -Recurse | Import-VM -Register | Get-VM | Add-ClusterVirtualMachineRole
No Windows Server 2012 R2, atualize a versão da VM para 5.0 para todas as VMs:
Get-VM | Update-VMVersion -Force
Execute o script de migração para copiar VMs para o Azure Stack HCI.
Siga o processo em Importar as VMs, substituindo a Etapa 3 e a Etapa 4 pelo seguinte para manipular os arquivos XML e importar as VMs para o Azure Stack HCI:
Get-ChildItem -Path "c:\clusterstorage\volume01\Hyper-V\*.xml"-Recurse
Get-ChildItem -Path "c:\clusterstorage\volume01\image\*.xml" -Recurse | Import-VM -Register | Get-VM | Add-ClusterVirtualMachineRole
Conclua as etapas restantes em Importar as VMs.
Opção 2: Cópia direta do VHD
Esse método usa o Robocopy para copiar VHDs de VM hospedados no Windows 2008 SP1, Windows 2008 R2-SP1 e Windows 2012 no Azure Stack HCI. Isso ignora a limitação mínima da versão da VM com suporte para essas VMs mais antigas. Recomendamos essa opção para VMs hospedadas no Windows Server 2008 SP1 e no Windows Server 2008 R2-SP1.
As VMs hospedadas no Windows 2008 SP1 e no Windows 2008 R2-SP1 dão suporte apenas a VMs de Geração 1 com VHDs de Geração 1. Dessa forma, as VMs de Geração 1 correspondentes precisam ser criadas no Azure Stack HCI para que os VHDs copiados possam ser anexados às novas VMs. Observe que esses VHDs não podem ser atualizados para VHDs da Geração 2.
Observação
Windows Server 2012 dá suporte a VMs de Geração 1 e Geração 2.
Este é o processo que você usa:
Use o robocopy de exemplo para copiar VHDs de VMs diretamente para o Azure Stack HCI:
Robocopy \\2012R2-Clus01\c$\clusterstorage\volume01\Hyper-V\ \\20H2-Clus01\c$\clusterstorage\volume01\Hyper-V\ /E /MT:32 /R:0 /w:1 /NFL /NDL /copyall /log:c:\log.txt /xf
Crie novas VMs de Geração 1. Para obter informações detalhadas sobre como fazer isso, consulte Gerenciar VMs.
Anexe os arquivos VHD copiados às novas VMs. Para obter informações detalhadas, consulte Gerenciar discos rígidos virtuais (VHD)
Como um FYI, os seguintes sistemas operacionais convidados do Windows Server dão suporte a VMs da Geração 2:
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2012
- Windows 10
- Versões de 64 bits de Windows 8.1 (64 bits)
- Versões de 64 bits de Windows 8 (64 bits)
- Linux (consulte VMs Linux e FreeBSD com suporte)
Próximas etapas
Validar o cluster após a migração. Consulte Validar um cluster do Azure Stack HCI.
Para migrar para o Azure Stack HCI in-loco usando o mesmo hardware, consulte Migrar para o Azure Stack HCI no mesmo hardware.