Migrações do VMware Hybrid Cloud

Fim da comercialização: A partir de 31 de outubro de 2025, novas implantações das ofertas do “ VMware Solutions ” não estarão mais disponíveis para novos clientes. Os clientes atuais ainda podem usar e expandir suas cargas de trabalho ativas do VMware® no IBM Cloud®. Para obter mais informações, consulte Fim do marketing para VMware em IBM Cloud.

Depois que o VMware HCX™ Service Mesh e as extensões de rede forem provisionados e estendidos, a próxima etapa é a migração das máquinas virtuais (VMs).

Existem os tipos de migração a seguir:

  • vMotion
  • Migração em massa
  • Migração fria

Operação

Use o portal de snap-in da interface do usuário da Web do HCX ou os menus de extensão contextual do cliente da Web VMware vSphere® para iniciar um vMotion entre nuvens. Em ambos os casos, aparece o mesmo assistente de migração. Para os menus contextuais, apenas uma única MV é selecionada para operações de migração. Para o portal, diversas MVs podem ser selecionadas.

A migração reversa de VMs só é possível a partir do portal web UI que usa a caixa de opção Migração Reversa no assistente de Migração do HCX.

vMotion

O recurso vMotion dentro do HCX amplia a capacidade do vSphere vMotion para trabalhar em diferentes versões do vSphere, domínios SSO separados e vários tipos de conectividade de rede na Internet. O HCX presume que a rede usada para conexão não é segura e sempre move o tráfego por meio de túneis criptografados, independentemente do tipo de conectividade.

Conceitos e melhores práticas para o vMotion

O HCX é essencialmente um proxy de duas vias do vMotion. Cada instância do HCX emula um único host VMware ESXi™ no data center vSphere, fora de qualquer cluster. A instância do HCX é uma "parte frontal" do componente da frota de gateway de cloud (CGW). Aparece um host do proxy para cada site do HCX vinculado ao site visualizado atualmente. Quando um vMotion é iniciado para um host remoto, o host ESXi local migra essa VM para o host ESXi de proxy local.

Uma migração do vMotion é iniciada do host do proxy ESXi remoto para o host ESXi físico do vSphere de destino, enquanto ele recebe dados do CGW de origem pelo túnel. Quando o vMotion é empregado, ao contrário da opção de migração em massa, apenas uma única operação de migração da VM é executada de cada vez. Como resultado, para muitas VMs a serem migradas, recomenda-se usar vMotion somente quando o tempo de inatividade não for uma opção ou se houver o risco de reiniciar a VM. No entanto, como o vMotion padrão, a MV pode ficar ativa durante o processo.

Um único vMotion atinge seu limite máximo em cerca de 1.7 Gbps na LAN e 300 a 400 Mbps na WAN por meio do WAN Optimizer. Isso não significa que 1,7 Gbps na LAN seja igual a 400 Mbps na WAN por meio do WAN Optimizer, mas, em vez disso, que esses máximos foram observados em ambientes específicos. Esse ambiente consistia em 10 GB de LAN vMotion Network e em 1 GB de uplink de internet, que é compartilhado com o tráfego da web de produção.

Use o vMotion nos casos a seguir:

  • Se a VM for difícil de desligar ou iniciar, ou se o tempo de atividade for longo e puder introduzir riscos ao desligar a VM.
  • Para qualquer aplicativo do tipo cluster que exija UUIDs de disco, como os clusters Oracle RAC. vMotion não altera os UUIDs de disco no destino.
  • Para mover uma única VM o mais rápido possível.
  • Se a migração planejada não for necessária.

Migração em massa

Conceitos e melhores práticas para migração em massa

O recurso de migração em massa do HCX usa a replicação do vSphere para migrar dados do disco ao recriar a MV na instância do vSphere HCX de destino. Uma migração de uma MV incorre no fluxo de trabalho a seguir:

  • Criação de uma nova MV no lado de destino e seus discos virtuais correspondentes.
  • Replicação de dados da MV para a nova MV. A replicação é iniciada assim que o assistente é concluído, independentemente da programação de alternância.
  • Desligue a MV original.
  • Durante o período de desativação, a replicação final de quaisquer mudanças de dados ocorre.
  • Ligação da nova MV no lado de destino.
  • Renomeie e mova da VM original para a pasta de nuvem para a qual ela foi movida.

A seguir estão as vantagens da migração em massa sobre o vMotion:

  • Migração de diversas VMs simultaneamente.
  • Uso de largura de banda mais consistente. O vMotion pode gerar flutuações no uso de largura de banda que seriam visíveis como picos e vales dentro de ferramentas de monitoramento de rede ou a IU do WAN Opt.
  • Use a migração em massa para um uso geral da capacidade de largura de banda de rede superior ao uso em um vMotion único.
  • Planeje a migração em massa para alternar para as VMs recém-migradas durante uma janela de indisponibilidade planejada.
  • Permita a migração de MVs que estão atualmente usando recursos de CPU virtuais, que diferem do lado da nuvem. A migração do vMotion pode falhar nestes casos.

A seguir estão as desvantagens da migração em massa no vMotion:

  • As MVs individuais migram muito mais lentamente do que com o vMotion.
  • A MV incorre em um rápido tempo de inatividade conforme a nova MV clone é ativada no lado de destino.
  • As MVs que dependem de pedidos de disco e UUIDs de disco (Oracle RAC) podem ter problemas e ter discos exibidos de forma diferente à medida que os UUIDs mudam, podendo mudar os caminhos do S.O. para os dispositivos de disco virtual.

Melhores práticas do tipo de migração

Clusters de disco compartilhados

Clusters do Oracle RAC, do MS Exchange e do MS-SQL são exemplos de aplicativos em que duas ou mais MVs participam de um cluster que requer disco compartilhado em todas as MVs ou nós do cluster. A sinalização multigravadora do VMware® precisa ser ativada em todos os nós da VM para os discos que fazem parte do cluster de aplicativos (discos virtuais não S.O.). Não há suporte para VMs com o sinalizador de gravação múltipla ativado para qualquer disco virtual.

Veja as informações a seguir sobre a migração de um cluster multigravador ativado para disco virtual:

  • O vMotion é usado porque o disco de VM original e os mapeamentos de UUID são mantidos.
  • O cluster permanece ativo em um estado comprometido (nó único) durante a migração.
  • O cluster incorre em tempo de inatividade antes do início da migração e após a migração ser concluída para remontar a configuração de diversos gravadores em VMs do cluster.

Para migrar um cluster multigravador ativado para disco, conclua as etapas a seguir:

  1. Desligue o cluster e todos os nós de acordo com a melhor prática do aplicativo.
  2. Anote a ordem do disco, caso o aplicativo requeira, em cada MV do nó para os discos virtuais configurados com vários gravadores.
  3. Para o Oracle e qualquer outro aplicativo que utilize o recurso UUID de disco virtual, faça login em um host ESXi e execute o comando vmkfstools -J getuuid /vmfs/volumes/datastore/VM/vm.vmdk. Esse comando obtém o UUID de cada arquivo de disco virtual que requer o sinalizador de multigravador definido para o cluster. Esta etapa é necessária se a melhor prática alinha as ordens de disco com como o caminho é exibido no sistema operacional. O vMotion pode reordenar os discos (disk1, disk2, disk3) mas os UUIDs permanecem os mesmos. Quando a migração for concluída, use o UUID indicado para mapear as informações do disco a fim de recriar a ordem de nomenclatura dele e o ID de SCSI, se necessário. Essas informações podem ser úteis para solucionar problemas quando uma instância do Oracle tem muitos discos virtuais mapeados.
  4. Remova os discos virtuais de todas as VMs do cluster, exceto a que é considerada primária.
  5. Remova o sinalizador de gravação múltipla da VM do cluster primário (a única que possui os discos do cluster).
  6. Ligue o cluster principal, se necessário para tempo de inatividade mínimo.
  7. Migrar todos os nós do cluster com vMotion. Migre o cluster principal primeiro. Migre todos os outros nós depois que eles forem desligados.
  8. Quando o nó proprietário do disco primário concluir a migração, desligue-o.
  9. Se necessário, remapeie o pedido de disco com o UUID de disco apropriado e o ID de scsi. O remapeamento não é necessário para que o aplicativo funcione.
  10. Reative a sinalização de vários gravadores no nó primário.
  11. Inicie o nó primário e verifique a operação.
  12. Mapeie o disco ou ative o sinalizador multigravador em todas as outras VMs do cluster para ativá-las.
  13. Verifique outra operação do cluster.

VMs Gerais

Após a construção de confiança em torno da função do HCX, a migração em massa deve ser empregada. A migração em massa é necessária para aplicativos redundantes. Por exemplo, servidores da web e em locais em que centenas ou milhares de VMs devem ser migradas.

VMs que usam NAS conectado diretamente

O NFS é geralmente empregado para uso para compartilhar dados entre muitos servidores, como o conteúdo do servidor da web. O iSCSI pode ser empregado entre nós de MV que consistem em um cluster de aplicativo, como email ou RDBMS e é tipicamente mais sensível à latência do que o NFS.

Em qualquer um dos casos, se for possível manter a latência baixa ao data center IBM Cloud (< ~7 ms para iSCSI e tudo que o aplicativo tolerar para o NFS) e permitir que o aplicativo possa operar com largura de banda de ~1 Gbps ou menos, então a rede NAS poderá ser estendida com o HCX para um local do IBM Cloud. Posteriormente, as VMs podem ser migradas ou processadas pelo vMotion com o HCX.

Após a migração, os volumes de iSCSI podem ser espelhados com o S.O. para outra solução de armazenamento em nuvem local e os dados do NFS podem ser replicados para qualquer solução de nuvem. Revise as considerações a seguir:

  • Latência (iSCSI ou tolerância do aplicativo para NFS)
  • Largura da Banda (~ 1 Gbps por rede estendida)
  • Largura da banda do link de subposição

Após o ciclo de vida de migração, teste os aplicativos de desenvolvimento ou preparação antes de tentar realizar a migração na produção. A QoS pode ser empregada para o tráfego de túnel de subposição (UDP 500/4500) entre os dispositivos L2C HCX que suportam redes L2 estendidas sensíveis à latência.

Network swing

Se o objetivo for a evacuação do data center para o IBM Cloud, a próxima etapa até a última antes da remoção do HCX será a troca de rede. A oscilação de rede realiza uma migração da sub-rede de rede que abriga as VMs migradas do data center de origem para uma rede de sobreposição do VMware NSX® no IBM Cloud.

A troca da rede envolve as etapas a seguir:

  • Verifique se a rede foi evacuada de todas as cargas de trabalho e se quaisquer dispositivos de rede que não são da VM foram movidos para outra rede, migrados funcionalmente para a nuvem ou descontinuados.
  • Verifique se qualquer topologia do NSX ou a topologia de rede de suporte do IBM Cloud está concluída para suportar a troca de rede. Por exemplo, protocolos de roteamento dinâmico e firewalls.
  • Execute um fluxo de trabalho de rede não estendida do HCX na IU e selecione o dispositivo do NSX de roteamento apropriado para assumir o controle do gateway padrão da rede não estendida.
  • Execute todas as alterações de roteamento externo, que podem incluir a inserção de roteamento alterado para redes que foram migradas, a remoção de rotas para o site de origem da rede migrada e a garantia de que o roteamento para a sub-rede migrada na WAN ainda funcione para os aplicativos que não foram migrados.
  • O proprietário do aplicativo testa os aplicativos migrados de todos os pontos de acesso possíveis: Internet, intranet e VPN.

Por exemplo, para trocar a rede de um aplicativo cujas VMs foram todas migradas para a cloud:

  • Você está usando um Vyatta no lado da rede privada para inserir rotas em sua nuvem do MPLS e para fazer túnel para os dispositivos de roteamento de borda no MPLS para que seja possível evitar o espaço de IP do IBM Cloud.
  • Sua conta é configurada com um VRF do IBM Cloud.
  • Alguns aplicativos estão atrás de um IP virtual (vIP) de carga balanceada de rede. Esses vIPs estão em sua própria sub-rede, que está localizada em um F5 virtual atrás do Vyatta.

A inclusão de um roteamento mais específico no MPLS para as redes que são trocadas para o IBM Cloud por meio do HCX funciona adequadamente para outras redes. No entanto, isso não funciona para o indivíduo vIPs porque uma rota /32 está sendo adicionada.

A solução comum para os provedores de WAN é filtrar as rotas /32 que são adicionadas. Trabalhe com o fornecedor da WAN para permitir.

A seguir estão as considerações e implicações:

  • Os aplicativos que compartilham a sub-rede, a vLAN e a VXLAN precisam se mover juntos.
  • Os aplicativos protegidos por um balanceador de carga que usa um IP roteável interno poderão requerer mudanças de roteamento se não puderem ser movidos juntos ou se não for desejável fazer isso. Por exemplo, o envolvimento de muitos aplicativos em uma única oscilação pode ser percebido como um risco muito grande.
  • VMware administradores, administradores de rede (incluindo clientes e fornecedores de WAN) e proprietários de aplicativos precisam estar envolvidos, mesmo que não haja impacto planejado em um sistema ou equipamento de rede específico.