Migrar para Azure Stack HCI em novo hardware

Aplica-se a: Azure Stack HCI, versões 21H2 e 20H2; 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áquinas virtuais (VM) em Windows Server 2012 R2, Windows Server 2016 ou Windows Server 2019 para o novo hardware do servidor HCI do Azure Stack HCI utilizando Windows PowerShell e Robocopia. Robocopia é um método robusto para copiar ficheiros de um servidor para outro. Retoma se desligado e continua a trabalhar a partir do seu último estado conhecido. Robocopy também suporta cópia de ficheiro multi-roscada sobre o Bloco de Mensagens do Servidor (SMB). Para mais informações, consulte Robocopy.

Nota

A migração ao vivo hiper-V e a réplica do Hiper-V de Windows Server a Azure Stack HCI não são suportadas.

Se tiver VMs em Windows R2 de 2012 ou mais que pretende migrar, consulte VMs mais antigos migratórios.

Para migrar para Azure Stack HCI usando o mesmo hardware, consulte Migrar para Azure Stack HCI no mesmo hardware.

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

Migrar o cluster para Azure Stack HCI

Em termos de tempo de inatividade esperado, utilizando um único NIC com uma rede de East-West RDMA de 40 GB dupla entre clusters e Robocopia configurada para 32 multiligreads, pode realizar velocidades de transferência de 1,9 TB por hora.

Nota

Neste artigo não são abrangidos os VMs migratórios para aglomerados esticados.

Antes de começar

Existem vários requisitos e coisas a considerar 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 destino, com plenos direitos sobre a unidade organizacional de origem e destino (OU) que contém ambos os clusters.

  • Ambos os agrupamentos devem estar na mesma floresta e domínio do Diretório Ativo para facilitar a autenticação de Kerberos entre aglomerados para a migração de VMs.

  • Ambos os agrupamentos devem residir num Ative Directory OU com o Grupo Policy Object (GPO) Block herança definida neste OU. Isto garante que nenhum OGM de nível de domínio e políticas de segurança podem ter impacto na migração.

  • Ambos os agrupamentos devem ser ligados à mesma fonte de tempo para suportar a autenticação consistente de Kerberos entre clusters.

  • Tome nota do nome do interruptor virtual Hyper-V utilizado pelos VMs no cluster de origem. Deve utilizar o mesmo nome de comutador virtual para o cluster de destino Azure Stack HCI "rede de máquinas virtuais" antes de importar VMs.

  • Remova quaisquer ficheiros de imagem ISO para os seus VMs de origem. Isto é feito usando Hyper-V Manager em Propriedades VM na secção hardware. Selecione Remover para quaisquer unidades virtuais de CD/DVD.

  • Desligue todos os VMs no aglomerado de origem. Isto é necessário para garantir que o controlo da versão e o estado sejam mantidos durante todo o processo de migração.

  • Verifique se o Azure Stack HCI suporta a sua versão dos VMs para importar e atualizar os seus VMs conforme necessário. Consulte a secção de suporte à versão VM e atualização sobre como fazê-lo.

  • Backup de todos os VMs no seu cluster de origem. Preencha uma cópia de segurança consistente de todas as aplicações e dados e uma cópia de segurança consistente de todas as bases de dados. Para fazer backup no Azure, consulte Use Azure Backup.

  • Faça um ponto de verificação dos VMs do seu cluster de origem e do controlador de domínio, caso tenha de voltar para um estado anterior. Isto não é aplicável para servidores físicos.

  • Certifique-se de que os tamanhos máximos de armação Jumbo são os mesmos entre as redes de armazenamento de clusters de origem e destino, especificamente os adaptadores de rede RDMA e as respetivas portas de rede de comutadores para fornecer o tamanho mais eficiente do pacote de transferências de ponta a ponta.

  • Tome nota do nome do interruptor virtual Hyper-V no cluster de origem. Vai reutilizá-lo no cluster de destino.

  • O hardware HCI Azure Stack HCI deve ter pelo menos capacidade e configuração iguais ao hardware de origem.

  • Minimize o número de lúpulos de rede ou distância física entre os clusters de origem e destino para facilitar a transferência de ficheiros mais rápida.

Suporte e atualização da versão VM

Esta tabela lista as versões Windows Server OS e as suas versões VM.

Independentemente da versão OS em que um VM pode estar em execução, a versão VM mínima suportada para migração direta para Azure Stack HCI é a versão 5.0. Isto representa a versão padrão para VMs em Windows Server 2012 R2. Assim, quaisquer VMs em execução na versão 2.0, 3.0 ou 4.0, por exemplo, devem ser atualizados para a versão 5.0 antes da migração.

Versão do SO Versão 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 em Windows Server 2012 R2, Windows Server 2016 e Windows Server 2019, atualize todos os VMs para a versão VM mais recente suportada no hardware de origem primeiro antes de executar o script de migração Robocopy. Isto garante que todos os VMs estão pelo menos na versão 5.0 para uma importação bem sucedida de VM.

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

Atualizar a versão VM

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

Get-VM * | Format-Table Name,Version

Para mostrar todas as versões VM em todos os servidores de um cluster:

Get-VM –ComputerName (Get-ClusterNode)

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

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

Recomendações de RDMA

Se estiver a utilizar o Acesso à Memória Direta Remota (RDMA), a Robocopia pode aproveitar-se para copiar os seus VMs entre clusters. Aqui ficam algumas recomendações para a utilização de RDMA:

  • Ligação ambos os clusters para o mesmo topo de rack (ToR) para usar o caminho de rede mais rápido entre os clusters de origem e destino. Para o caminho da rede de armazenamento isto normalmente suporta 10GbE/25GbE ou velocidades mais altas e alavancas RDMA.

  • Se o adaptador ou padrão RDMA for diferente entre os clusters de origem e destino (ROCE vs iWARP), a Robocopy irá, em vez disso, alavancar o SMB sobre o TCP/IP através da rede mais rápida disponível. Este será tipicamente um duplo 10Gbe/25Gbe ou uma velocidade superior para a rede East-West, fornecendo a forma mais ideal de copiar ficheiros VM VHDX entre clusters.

  • Para garantir que a Robocopia pode alavancar o RDMA entre clusters (rede Este-Oeste), configurar as redes de armazenamento RDMA para que sejam encaminháveis entre os clusters de origem e destino.

Criar o novo cluster

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

Utilize Windows Centro de Administração ou Windows PowerShell para criar o novo cluster. Para obter informações detalhadas sobre como fazê-lo, consulte Criar um cluster HCI Azure Stack utilizando Windows Centro de Administração e Criar um cluster HCI Azure Stack utilizando Windows PowerShell.

Importante

Os nomes do interruptor virtual Hiper-V VMSwitch () entre clusters devem ser os mesmos. Certifique-se de que os nomes de switch virtuais criados no cluster de destino correspondem aos utilizados no cluster de origem em todos os servidores. Verifique os nomes do interruptor para o mesmo antes de importar os VMs.

Nota

Tem de registar o cluster HCI Azure Stack com O Azure antes de poder criar novos VMs nele. Para mais informações, consulte Registar-se com Azure.

Executar o roteiro de migração

O seguinte script PowerShell Robocopy_Remote_Server_.ps1 utiliza robocopia para copiar ficheiros VM e seus diretórios dependentes e metadados da fonte para o cluster de destino. Este script foi modificado a partir do script original na TechNet em: Robocopy Files para Remote Server Using PowerShell e RoboCopy.

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

O script de migração é executado localmente em cada servidor de origem para aproveitar o benefício de RDMA e transferência rápida de rede. Para efetuar este procedimento:

  1. Certifique-se de que cada nó de cluster de destino está definido para o proprietário do CSV para o destino CSV.

  2. Para determinar a localização de todos os ficheiros VM VHD e VHDX a serem copiados, utilize o seguinte cmdlet. Reveja o C:\vmpaths.txt ficheiro para determinar o caminho de ficheiro de origem mais alto para robocopia começar a partir do passo 4:

    Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vhd*" -Recurse > c:\vmpaths.txt
    

    Nota

    Se os seus 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.

  3. Altere as seguintes três variáveis para combinar o caminho VM do cluster de origem com o caminho VM do cluster de destino:

    • $Dest_Server = "Node01"
    • $source = "C:\Clusterstorage\Volume01"
    • $dest = "\\$Dest_Server\C$\Clusterstorage\Volume01"
  4. Execute o seguinte script em cada Windows servidor de origem do servidor:

<#
#===========================================================================  
# 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 os VMs

Uma melhor prática é criar pelo menos um cluster shared volume (CSV) por nó de cluster para permitir um equilíbrio uniforme de VMs para cada proprietário de CSV para maior resiliência, desempenho e escala de cargas de trabalho VM. Por padrão, este equilíbrio ocorre automaticamente a cada cinco minutos e precisa de ser considerado quando se utiliza robocopia entre um nó de cluster de origem e o nó do cluster de destino para garantir que os proprietários de CSV de origem e destino correspondem para fornecer a rota e velocidade de transferência mais ideais.

Execute os seguintes passos no seu cluster HCI Azure Stack para importar os VMs, torná-los altamente disponíveis e iniciá-los:

  1. Executar o seguinte cmdlet para mostrar todos os nós do proprietário CSV:

    Get-ClusterSharedVolume
    
  2. Para cada nó do servidor, vá C:\Clusterstorage\Volume e desacorra o caminho para todos os VMs - por exemplo C:\Clusterstorage\volume01 .

  3. Execute o seguinte cmdlet em cada nó do proprietário do CSV para mostrar o caminho para todos os ficheiros VM VMCX por volume antes da importação de VM. Modifique o caminho para combinar com o seu ambiente:

    Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vmcx" -Recurse
    

    Nota

    Windows Server 2012 VMs R2 e mais antigos usam um ficheiro XML em vez de um ficheiro VCMX. Mais informações, consulte a secção VMs mais antigos.

  4. Execute o seguinte cmdlet para cada nó do servidor importar, registar e disponibilizar os VMs altamente disponíveis em cada nó do proprietário do CSV. Isto garante uma distribuição uniforme de VMs para o melhor processador e alocação de memória:

    Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vmcx" -Recurse | Import-VM -Register | Get-VM | Add-ClusterVirtualMachineRole
    
  5. Inicie cada VM de destino em cada nó:

    Start-VM -Name
    
  6. Inicie sessão e verifique se todos os 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'}
    
  7. Atualize os seus VMs para a versão mais recente do Azure Stack HCI para tirar partido de todos os avanços:

    Get-VM | Update-VMVersion -Force
    
  8. Depois de concluído o script, verifique o ficheiro de registo robocopia para quaisquer erros listados e verifique se todos os VMs são copiados com sucesso.

VMs mais velhos migrando

Se tiver 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 lidar com estes VMs:

  • Migrar estes VMs para Windows Server 2012 R2, Windows Server 2016 ou Windows Server 2019 primeiro, atualizar a versão VM e depois iniciar o processo de migração.

  • Use robocopia para copiar todos os VM VHDs para Azure Stack HCI. Em seguida, crie novos VMs e fixe os VHDs copiados aos VMs em Azure Stack HCI. Isto contorna a limitação da versão VM para estes VMs mais antigos.

Windows Server 2012 os anfitriões R2 e hiper-V mais antigos utilizam um formato de ficheiro XML para a sua configuração VM, que é diferente do formato de ficheiro VCMX utilizado para Windows Server 2016 e posteriormente anfitriões Hiper-V. Isto requer um comando robocopia diferente para copiar estes VMs para Azure Stack HCI.

Opção 1: Migração encenada

Esta é uma migração em dois estágios usada para VMs hospedados no Windows Server 2008 SP1, Windows Server 2008 R2-SP, e Windows Server 2012. Aqui está o processo que utiliza:

  1. Descubra a localização de todos os ficheiros VM VHD e VHDX a serem copiados e, em seguida, reveja o vmpaths.txt ficheiro para determinar o caminho de arquivo de origem mais alta para robocopia começar. Utilize o seguinte cmdlet:

    Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vhd*" -Recurse > c:\vmpaths.txt
    
  2. Utilize o seguinte exemplo De comando Robocopy para copiar VMs para Windows Server 2012 R2 primeiro usando 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

  3. Verifique se o nome do interruptor virtual ( VMSwitch ) utilizado no Windows Server 2012 do conjunto R2 é o mesmo que o nome do interruptor utilizado na fonte Windows R2 ou Windows Server 2008 R2-SP1. Para exibir os nomes do switch utilizados em todos os servidores de um cluster, utilize isto:

    Get-VMSwitch -CimSession $Servers | Select-Object Name
    

    Mude o nome do interruptor no Windows Server 20212 R2 conforme necessário. Para mudar o nome do interruptor em todos os servidores do cluster, utilize isto:

    Invoke-Command -ComputerName $Servers -ScriptBlock {rename-VMSwitch -Name $using:vSwitcholdName -NewName $using:vSwitchnewname}
    
  4. Copiar e importar os 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  
    
  5. No Windows Server 2012 R2, atualize a versão VM para 5.0 para todos os VMs:

    Get-VM | Update-VMVersion -Force
    
  6. Executar o roteiro de migração para copiar VMs para Azure Stack HCI.

  7. Siga o processo de Importação dos VMs,substituindo o Passo 3 e o Passo 4 pelo seguinte para manusear os ficheiros XML e para importar os VMs para 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  
    
  8. Complete os passos restantes na Importação dos VMs.

Opção 2: Cópia VHD direta

Este método utiliza robocopia para copiar VM VHDs que são hospedados em Windows SP1 de 2008, Windows R2-SP1 de 2008, e Windows 2012 para Azure Stack HCI. Isto contorna a limitação mínima da versão VM suportada para estes VMs mais antigos. Recomendamos esta opção para VMs hospedados no Windows Server 2008 SP1 e Windows Server 2008 R2-SP1.

Os VMs acolheram em Windows SP1 de 2008 e Windows suporte R2-SP1 de 2008 apenas VMs geração 1 com VHDs de Geração 1. Como tal, os VMs da Geração 1 correspondentes precisam de ser criados no Azure Stack HCI para que os VHDs copiados possam ser ligados aos novos VMs. Note que estes VHDs não podem ser atualizados para VHDs da Geração 2.

Nota

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

Aqui está o processo que utiliza:

  1. Utilize o exemplo Robocopy para copiar VMs VHDs diretamente para 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

  2. Criar novos VMs de geração 1. Para obter informações detalhadas sobre como fazê-lo, consulte Gerir VMs.

  3. Fixe os ficheiros VHD copiados aos novos VMs. Para obter informações detalhadas, consulte Gerir discos rígidos virtuais (VHD)

Como FYI, os seguintes sistemas operativos Windows server suportam VMs 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-bit)
  • Versões de 64 bits de Windows 8 (64-bit)
  • Linux (Ver Linux suportado e VMs freebsd)

Passos seguintes