Migrar para o Azure Stack HCI em novo hardware

Artigo
02/13/2024

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 ficheiros de máquina virtual (VM) no Windows Server 2012 R2, Windows Server 2016 ou Windows Server 2019 para o novo hardware de servidor do Azure Stack HCI com o Windows PowerShell e o Robocopy. O Robocopy é um método avançado para copiar ficheiros de um servidor para outro. Retoma se for desligado e continua a trabalhar a partir do último estado conhecido. O Robocopy também suporta a cópia de ficheiros de múltiplos threads através do protocolo SMB (Server Message Block). Para obter mais informações, consulte Robocopy.

Nota

A Migração em Direto do Hyper-V e a Réplica do Hyper-V do Windows Server para o Azure Stack HCI não são suportadas. No entanto, a réplica do Hyper-V é válida e suportada entre sistemas HCI. Não pode replicar uma VM para outro volume no mesmo cluster, apenas para outro sistema HCI.

Se tiver VMs no Windows 2012 R2 ou mais antigas que pretenda migrar, veja Migrar VMs mais antigas.

Para migrar para o Azure Stack HCI com o mesmo hardware, veja Migrar para o Azure Stack HCI no mesmo hardware.

O diagrama seguinte mostra um cluster de origem do Windows Server e um cluster de destino do Azure Stack HCI como exemplo. Também pode migrar VMs em servidores autónomos.

Em termos de tempo de inatividade esperado, ao utilizar um único NIC com uma rede rdma de 40 GB duplos East-West entre clusters e o Robocopy configurado para 32 multithreads, pode perceber velocidades de transferência de 1,9 TB por hora.

Nota

A migração de VMs para clusters dispersos não é abordada neste artigo.

Antes de começar

Existem vários requisitos e aspetos a ter em conta antes de iniciar a migração:

Todos os comandos Windows PowerShell têm de ser executados como Administrador.
Tem de ter credenciais de domínio com permissões de administrador para clusters de origem e de destino, com direitos totais para a Unidade Organizacional (UO) de origem e destino que contém ambos os clusters.
Ambos os clusters têm de 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 têm de residir numa UO do Active Directory com a herança de blocos de objetos de Política de Grupo (GPO) definida nesta UO. Isto garante que nenhum GPOs ao nível do domínio e políticas de segurança podem afetar a migração.
Ambos os clusters têm de estar ligados à mesma origem de tempo para suportar a autenticação Kerberos consistente entre clusters.
Anote o nome do comutador virtual Hyper-V utilizado pelas VMs no cluster de origem. Tem de utilizar o mesmo nome de comutador virtual para o cluster de destino do Azure Stack HCI "rede de máquina virtual" antes de importar VMs.
Remova quaisquer ficheiros de imagem ISO para as VMs de origem. Isto é feito com o Gestor de Hyper-V nas Propriedades da VM na secção Hardware. Selecione Remover para quaisquer unidades virtuais de CD/DVD.
Encerre todas as VMs no cluster de origem. Isto é necessário para garantir que o controlo de versões e o estado são mantidos durante todo o processo de migração.
Verifique se o Azure Stack HCI suporta a sua versão das VMs para importar e atualizar as VMs conforme necessário. Veja a secção suporte e atualização da versão da VM sobre como fazê-lo.
Faça uma cópia de segurança de todas as VMs no cluster de origem. Conclua uma cópia de segurança consistente com falhas de todas as aplicações e dados e uma cópia de segurança consistente com a aplicação de todas as bases de dados. Para fazer uma cópia de segurança do Azure, veja Utilizar Azure Backup.
Crie um ponto de verificação das VMs do cluster de origem e do controlador de domínio, caso tenha de reverter para um estado anterior. Isto não é aplicável a servidores físicos.
Certifique-se de que os tamanhos máximos da frame Jumbo são os mesmos entre as redes de armazenamento de clusters de origem e de destino, especificamente os adaptadores de rede RDMA e as respetivas portas de rede de comutador para fornecer o tamanho de pacote de transferência ponto a ponto mais eficiente.
Anote o nome do comutador virtual hyper-V no cluster de origem. Irá reutilizá-lo no cluster de destino.
O hardware do Azure Stack HCI deve ter, pelo menos, capacidade e configuração iguais como 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 ficheiros mais rápida.

Suporte e atualização da versão da VM

Esta tabela lista as versões do SO do Windows Server e as respetivas versões de VM.

Independentemente da versão do SO na qual uma VM possa estar em execução, a versão mínima da VM suportada para migração direta para o Azure Stack HCI é a versão 5.0. Isto representa a versão predefinida para VMs no Windows Server 2012 R2. Assim, quaisquer VMs em execução na versão 2.0, 3.0 ou 4.0, por exemplo, têm de 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 suportada no hardware de origem antes de executar primeiro o script de migração do Robocopy. Isto garante que todas as VMs têm, pelo menos, a versão 5.0 para uma importação de VM com êxito.

Para VMs no Windows Server 2008 SP1, Windows Server 2008 R2-SP1 e Windows 2012, a versão da VM será inferior à versão 5.0. Estas VMs também utilizam um ficheiro .xml para configuração em vez de um ficheiro .vcmx. Como tal, não é suportada uma importação direta da VM para o Azure Stack HCI. Nestes casos, tem duas opções, conforme detalhado em Migrar VMs mais antigas.

Atualizar a versão da VM

Os seguintes comandos aplicam-se ao Windows Server 2012 R2 e posterior. Utilize o seguinte comando para mostrar todas as versões de VM num único servidor:

Get-VM * | Format-Table Name,Version

Para mostrar todas as versões da VM em todos os servidores num cluster:

Get-VM –ComputerName (Get-ClusterNode)

Para atualizar todas as VMs para a versão suportada mais recente em todos os servidores:

Get-VM –ComputerName (Get-ClusterNode) | Update-VMVersion -Force

Recomendações de RDMA

Se estiver a utilizar o Acesso Remoto Direto à Memória (RDMA), o Robocopy pode tirar partido do mesmo para copiar as VMs entre clusters. Seguem-se algumas recomendações para utilizar o RDMA:

Ligue ambos os clusters ao mesmo comutador tor (top of rack) para utilizar o caminho de rede mais rápido entre clusters de origem e de destino. Para o caminho da rede de armazenamento, isto normalmente suporta velocidades de 10 GbE/25 GbE ou superiores e tira partido do RDMA.
Se o adaptador RDMA ou padrão for diferente entre os clusters de origem e de destino (ROCE vs iWARP), o Robocopy irá, em vez disso, tirar partido do SMB através de TCP/IP através da rede disponível mais rápida. Normalmente, será uma velocidade dupla de 10Gbe/25 Gbe ou superior para a rede East-West, proporcionando a forma mais ideal de copiar ficheiros VM VHDX entre clusters.
Para garantir que o Robocopy pode tirar partido do RDMA entre clusters (rede Este-Oeste), configure as redes de armazenamento RDMA para que sejam encaminháveis entre os clusters de origem e de destino.

Criar o novo cluster

Antes de poder criar o cluster do Azure Stack HCI, tem de instalar o SO do Azure Stack HCI em cada novo servidor que estará no cluster. Para obter informações sobre como fazê-lo, veja Implementar o sistema operativo Azure Stack HCI.

Utilize Windows Admin Center ou Windows PowerShell para criar o novo cluster. Para obter informações detalhadas sobre como fazê-lo, veja Criar um cluster do Azure Stack HCI com Windows Admin Center e Criar um cluster do Azure Stack HCI com Windows PowerShell.

Importante

Os nomes dos comutadores virtuais de Hyper-V (VMSwitch) entre clusters têm de ser os mesmos. Confirme que os nomes dos comutadores virtuais criados no cluster de destino correspondem aos utilizados no cluster de origem em todos os servidores. Verifique os nomes do comutador para os mesmos antes de importar as VMs.

Nota

Tem de registar o cluster do Azure Stack HCI no Azure antes de poder criar novas VMs no mesmo. Para obter mais informações, veja Registar-se no Azure.

Executar o script de migração

O seguinte script Robocopy_Remote_Server_.ps1 do PowerShell utiliza o Robocopy para copiar ficheiros de VM e os respetivos diretórios e metadados dependentes da origem para o cluster de destino. Este script foi modificado a partir do script original no TechNet em: Ficheiros Robocopy para Servidor Remoto Com o PowerShell e o RoboCopy.

O script copia todos os ficheiros VHD, VHDX e VMCX da VM para o cluster de destino para um determinado Volume Partilhado de Cluster (CSV). Um CSV é migrado de cada vez.

O script de migração é executado localmente em cada servidor de origem para tirar partido do RDMA e da transferência rápida de rede. Para efetuar este procedimento:

Certifique-se de que cada nó de cluster de destino está definido como o proprietário do CSV para o CSV de destino.
Para determinar a localização de todos os ficheiros VHD e VHDX da VM a copiar, utilize o seguinte cmdlet. Reveja o C:\vmpaths.txt ficheiro para determinar o caminho de ficheiro de origem mais importante para o Robocopy começar a partir do passo 4:
```
Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vhd*" -Recurse > c:\vmpaths.txt
```
Nota

Se os ficheiros VHD e VHDX estiverem localizados em caminhos diferentes no mesmo volume, terá de executar o script de migração para cada caminho diferente para os copiar a todos.
Altere as três variáveis seguintes 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 melhor prática é criar pelo menos um Volume Partilhado de Cluster (CSV) por nó de cluster para permitir um equilíbrio uniforme de VMs para cada proprietário CSV para uma maior resiliência, desempenho e escala de cargas de trabalho de VM. Por predefinição, este saldo ocorre automaticamente a cada cinco minutos e tem de ser considerado ao utilizar 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 correspondem para fornecer o caminho e a velocidade de transferência mais ideais.

Execute os seguintes passos 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 CSV:
```
Get-ClusterSharedVolume
```
Para cada nó de servidor, aceda a C:\Clusterstorage\Volume e defina o caminho para todas as VMs , por exemplo C:\Clusterstorage\volume01.
Execute o seguinte cmdlet em cada nó de proprietário CSV para apresentar o caminho para todos os ficheiros 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
```
Nota

Windows Server 2012 R2 e VMs mais antigas utilizam um ficheiro XML em vez de um ficheiro VCMX. Para obter mais informações, veja a secção Migrar VMs mais antigas.
Execute o seguinte cmdlet para cada nó de servidor importar, registar e tornar as VMs altamente disponíveis em cada nó de proprietário CSV. Isto garante uma distribuição uniforme de VMs para o processador ideal e alocação de 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
```
Inicie sessão e verifique se todas as VMs estão em execução e que todas as suas aplicações e dados estão lá:
```
Get-VM -ComputerName Server01 | Where-Object {$_.State -eq 'Running'}
```
Atualize as VMs para a versão mais recente do Azure Stack HCI para tirar partido de todos os avanços:
```
Get-VM | Update-VMVersion -Force
```
Após a conclusão do script, verifique se existem erros listados no ficheiro de registo do Robocopy e verifique se todas as VMs são copiadas com êxito.

Migrar VMs mais antigas

Se tiver o Windows Server 2008 SP1, Windows Server 2008 R2-SP1, Windows Server 2012 ou Windows Server 2012 VMs R2, esta secção aplica-se a si. Tem duas opções para processar estas VMs:

Migre estas VMs para Windows Server 2012 R2, Windows Server 2016 ou Windows Server 2019 primeiro, atualize a versão da VM e, em seguida, inicie o processo de migração.
Utilize 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. Isto ignora a limitação da versão da VM para estas VMs mais antigas.

Windows Server 2012 anfitriões Hyper-V mais antigos e R2 utilizam um formato de ficheiro XML para a configuração da VM, que é diferente do formato de ficheiro VCMX utilizado para Windows Server 2016 e anfitriões Hyper-V posteriores. Isto requer um comando robocopy diferente para copiar estas VMs para o Azure Stack HCI.

Opção 1: Migração faseada

Esta é uma migração de duas fases utilizada para VMs alojadas no Windows Server 2008 SP1, Windows Server 2008 R2-SP e Windows Server 2012. Eis o processo que utiliza:

Descubra a localização de todos os ficheiros VHD e VHDX da VM a copiar e, em seguida, reveja o vmpaths.txt ficheiro para determinar o caminho de ficheiro de origem mais importante para o Robocopy começar. Utilize o seguinte cmdlet:
```
Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vhd*" -Recurse > c:\vmpaths.txt
```
Utilize o seguinte comando robocopy de exemplo para copiar VMs para Windows Server 2012 R2 primeiro com o caminho mais alto determinado no passo 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) utilizado no cluster do Windows Server 2012 R2 é o mesmo que o nome do comutador utilizado na origem do Windows 2008 R2 ou Windows Server 2008 R2-SP1. Para apresentar os nomes de comutadores utilizados em todos os servidores num cluster, utilize o seguinte:
```
Get-VMSwitch -CimSession $Servers | Select-Object Name
```
Mude o nome do comutador no Windows Server 20212 R2 conforme necessário. Para mudar o nome do comutador para todos os servidores no cluster, utilize o seguinte:
```
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 o Passo 3 e o Passo 4 pelo seguinte para processar os ficheiros 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 os passos restantes em Importar as VMs.

Opção 2: Cópia direta do VHD

Este método utiliza o Robocopy para copiar VHDs de VM alojados no Windows 2008 SP1, Windows 2008 R2-SP1 e Windows 2012 para o Azure Stack HCI. Isto ignora a limitação mínima da versão da VM suportada para estas VMs mais antigas. Recomendamos esta opção para VMs alojadas no Windows Server 2008 SP1 e Windows Server 2008 R2-SP1.

As VMs alojadas no Windows 2008 SP1 e Windows 2008 R2-SP1 suportam apenas VMs de Geração 1 com VHDs de Geração 1. Como tal, as VMs de Geração 1 correspondentes têm de ser criadas no Azure Stack HCI para que os VHDs copiados possam ser anexados às novas VMs. Tenha em atenção que estes VHDs não podem ser atualizados para VHDs de Geração 2.

Nota

Windows Server 2012 suporta VMs de Geração 1 e Geração 2.

Eis o processo que utiliza:

Utilize o exemplo Robocopy 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
Criar novas VMs de Geração 1. Para obter informações detalhadas sobre como fazê-lo, veja Gerir VMs.
Anexe os ficheiros VHD copiados às novas VMs. Para obter informações detalhadas, veja Gerir Discos Rígidos Virtuais (VHD)

Como um FYI, os seguintes sistemas operativos convidados do Windows Server suportam VMs de Geração 2:

Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
Windows Server 2012
Windows 10
Versões de 64 bits do Windows 8.1 (64 bits)
Versões de 64 bits do Windows 8 (64 bits)
Linux (Veja VMs Suportadas do Linux e FreeBSD)

Passos seguintes

Validar o cluster após a migração. Veja Validar um cluster do Azure Stack HCI.
Para migrar para o Azure Stack HCI no local com o mesmo hardware, veja Migrar para o Azure Stack HCI no mesmo hardware.

Migrar para o Azure Stack HCI em novo hardware

Antes de começar

Suporte e atualização da versão da VM

Atualizar a versão da VM

Recomendações de RDMA

Criar o novo cluster

Executar o script de migração

Importar as VMs

Migrar VMs mais antigas

Opção 1: Migração faseada

Opção 2: Cópia direta do VHD

Passos seguintes

Comentários

Comentários

Recursos adicionais