Criar o Cluster de vSAN VMware Estendido

Com todas as configurações de pré-requisito concluídas, agora você pode continuar criando o cluster esticado de vSAN VMware. Esta etapa formaliza a conexão entre hosts na OCI Dedicated Region A e na OCI Dedicated Region B, bem como o nó de Testemunha implantado em uma terceira região.

Você pode usar o Assistente de Início Rápido ou navegar diretamente para: Cluster, Configure, vSAN, Domínios de Falha e Cluster Estendido na IU VMware vCenter.

Configure o seguinte durante este processo:

  • Designe um host à OCI Dedicated Region ao Domínio de Falha 1
  • Designe hosts OCI Dedicated Region B ao Domínio de Falha 2
  • Especifique o Host da Testemunha (anteriormente adicionado) para o quorum

Para obter mais detalhes, consulte Stretched Cluster Requirements e VMware vSAN Stretched Cluster Guide.

Após a criação do cluster esticado:

  • Execute as Verificações de Integridade vSAN para validar a integridade do cluster.
  • Resolva quaisquer erros relacionados à rede (por exemplo, incompatibilidade de MTU ou problemas de roteamento).

Observação:

Você pode encontrar objetos vSAN obsoletos em determinados hosts de seus clusters originais. Consulte este guia para removê-los: Como Excluir Objetos Inacessíveis no Armazenamento de Dados vSAN

Quando concluído, o cluster deverá relatar uma pontuação de integridade de vSAN no alto 90s, indicando uma configuração estendida bem-sucedida.

Configurar NSX

Com o cluster vSAN VMware estendido, atualize o NSX VMware para suportar a rede de sobreposição entre sites. Esta etapa garante que os hosts ESXi de ambas as regiões possam se comunicar por meio de túneis NSX usando suas respectivas zonas de transporte.

Clonar Configuração do NSX TEP
  • Copie o Pool de IPs NSX TEP do NSX Manager da OCI Dedicated Region para a OCI Dedicated Region A NSX Manager.
  • Para evitar conflitos de IP com o host de gerenciamento ESXi ainda presente na Região Dedicada do OCI B, configure o novo Pool de IPs na Região Dedicada do OCI A para começar em .10.

    Exemplo: No OCI Dedicated Region, um NSX Manager, crie um Pool de TEP com uma faixa de .10–.20 para hosts da OCI Dedicated Region B para garantir que não haja sobreposição com IPs existentes.

Criar um Perfil de Uplink B da OCI Dedicated Region em OCI Dedicated Region A
  • No OCI Dedicated Region A NSX Manager, defina um novo Perfil de Uplink especificamente para hosts da OCI Dedicated Region B.
  • Use o ID de VLAN correto e certifique-se de que a ordem de uplink corresponda à configuração B da OCI Dedicated Region.
Preparar Hosts para NSX
  • Use OVERLAY-TZ e VLAN-TZ como zonas de transporte.
  • Durante a preparação do host, designe o Perfil de Uplink apropriado, dependendo se o host é da OCI Dedicated Region A ou da OCI Dedicated Region B.

    Observação: em alguns cenários, especialmente após um evento de failover, as interfaces de túnel NSX podem não aparecer corretamente. Para resolver isso:

    • Reinicialize o host ESXi afetado ou
    • Execute a reinicialização services.sh via SSH no host.

    Isso garante que todos os serviços NSX comecem na ordem correta e restaure a estabilidade do túnel.

Criar Segmentos de Sobreposição NSX
  • Crie quatro segmentos de sobreposição NSX.
  • Certifique-se de que esses segmentos estejam visíveis e sincronizados em todos os hosts ESXi nos dois sites.
Configurar DHCP (opcional)
  • Opcionalmente, configure as configurações DHCP para os novos segmentos de sobreposição.
  • As definições de DNS já foram configuradas anteriormente neste guia e não precisam ser repetidas aqui.
Validar Conectividade de Sobreposição Ponta a Ponta
  • Implemente quatro VMs, colocando uma em cada host em ambas as regiões.
  • Designe a cada VM um endereço IP estático dentro da respectiva faixa de segmentos.
  • Pingindo os gateways de segmento e entre VMs para validar a conectividade de sobreposição L3 em todo o ambiente esticado.

Ativar Conectividade Externa para VMs de Sobreposição

Para permitir que as VMs de sobreposição NSX VMware acessem redes externas, configure regras NAT e roteamento para as VLANs relevantes.

Em VCN-MGMT-Active e VCN-MGMT-Failover, atualize a configuração NAT para a VLAN do Uplink 1 da Borda NSX:

  • Use os mesmos IPs de acesso externo em ambas as regiões, correspondendo àqueles usados durante a implantação da OCI Dedicated Region A.
  • Confirme se o IP usado é o VIP HA para os nós do NSX Edge, visíveis no NSX Manager.

Atualize também as regras de acesso externo para as vSphere VLANs:

  • Configure regras NAT para vcenter-vip, nsxt-manager-vip e HCX-manager-vip (se HCX for usado) em ambas as VCNs.

Suporte de encaminhamento de DNS

As VMs de sobreposição geralmente usam um encaminhador de DNS (por exemplo, 192.168.253.253) definido no NSX-T. Para rotear estas consultas de DNS:

  1. Crie uma tabela de roteamento dedicada para o Gateway NAT.
  2. Defina uma rota estática:
    • Destino: 10.x.x.x (sub-redes de VM sobrepostas)
    • Destino: Gateway NAT
    • IP do Encaminhador de DNS: 192.168.253.253

Esta configuração deve ser replicada em ambos os locais. Associe a nova tabela de roteamento ao Gateway NAT para obter comportamento consistente.

Reatribua VLANs do Host ESXi à VCN Flutuante

Na configuração atual, cada host ESXi é provisionado com duas NICs físicas, cada uma associada a um conjunto padrão de VLANs configuradas por meio de anexos de VNICs para VCN-Primary (OCI Dedicated Region A) e VCN-Secondary (OCI Dedicated Region B). Essas VNICs são configuradas usando o bloco CIDR secundário (172.45.0.0/16) anexado às respectivas VCNs.

Para concluir a transição para uma configuração estendida, todas as VLANs com tags 200 e superiores (por exemplo, para vSphere, HCX, NSX Edge etc.) devem ser migradas para as VCNs flutuantes:
  • VCN-MGMT-Active na OCI Dedicated Region A
  • VCN-MGMT-Failover na OCI Dedicated Region B

Migrar VNICs para a VCN Flutuante

Siga estas etapas para cada host ESXi nos dois SDDCs:
  1. Acesse ESXi Detalhes do Host: Na Console do OCI, vá para Compute, ESXi Hosts.
  2. Excluir Anexos de VNIC Existentes: Para cada host, exclua as VNICs associadas às VLANs 201 e posteriores da VCN-Principal ou da VCN-Secundária.

    Observação:

    Esta etapa é obrigatória porque não é possível criar uma nova VNIC para a mesma VLAN enquanto existir a antiga.
  3. Recrie VNICs na VCN Flutuante:
    • Crie uma nova VNIC para cada VLAN na VCN flutuante correspondente:
      • Usar VCN-MGMT-Active na OCI Dedicated Region A
      • Usar VCN-MGMT-Failover na OCI Dedicated Region B
    • Selecione a VLAN marcada com o sufixo -NEW apropriado para distingui-la da original.

    Repita esse processo para ambas as VNICs por host. Recomendamos uma abordagem sistemática: comece com vnic0 e vnic1 para VLAN 201, conclua as substituições e prossiga com a próxima VLAN.

    Considerações Especiais para Hosts de Sites Secundários

    Depois de migrar as VNICs dos hosts no Site Principal, repita o processo de todos os hosts no Site Secundário. No entanto, observe um detalhe importante:

    • Os componentes de gerenciamento vSphere no Site Secundário foram inicialmente implantados em uma VLAN temporária (por exemplo, VLAN-Stretched-Cls-Mgmt-vSphere-TEMP).
    • Essa VLAN temporária pode permanecer em vigor durante a transição. Ele não afeta a funcionalidade vSAN estendida e oferece acesso de fallback para componentes vCenter e NSX, se necessário.

    A retenção dessa VLAN temporária garante acesso de gerenciamento ininterrupto durante a VNIC e o workflow de migração de rede.

    Impacto e Recuperação de Conectividade

    Durante as atualizações da VNIC, é esperada perda temporária de conectividade com os hosts vCenter, NSX Manager ou ESXi. Para garantir a recuperação:

    1. Verificar Anexos do DRG: Confirme se as VCNs de Gerenciamento apropriadas (Ativas e Failover) estão anexadas aos respectivos DRGs (Dynamic Routing Gateways).
    2. Atualizar Tabelas de Roteamento:
      • Atualize a tabela de roteamento principal em cada VCN de Gerenciamento para apontar para o DRG.
      • Atualize as tabelas de roteamento de sub-rede Bastion para garantir que o tráfego de gerenciamento seja roteado corretamente entre VCNs e entre regiões.
    3. Validar Acesso:
      • Após a atualização de rotas, o acesso a todas as interfaces de gerenciamento do Bastion host deverá ser restaurado.
      • Se algum recurso permanecer inacessível, verifique novamente as regras do NSG e roteie a propagação entre VCNs.

    Limpeza de Migração Pós-vNIC

    Quando a migração da VNIC for concluída:

    • Remova todas as VLANs não usadas de VCN-Primary e VCN-Secondary que pertencem ao bloco CIDR 172.45.0.0/16.
    • Desanexe o CIDR secundário (172.45.0.0/16) do VCN-Primary, pois ele não está mais em uso.

    O OCI só permitirá a desanexação do CIDR quando nenhum recurso ativo (VNICs, sub-redes ou VLANs) o usar.

    • Você pode observar indicadores de advertência na página de recursos do SDDC no Console do OCI. Isso é esperado, pois o serviço Oracle Cloud VMware Solution não está mais rastreando componentes que foram implantados inicialmente no VCN-Primary.

    Atualizar Roteamento para Novos Anexos de VCN

    1. Anexe o VCN-MGMT-Active ao DRG na OCI Dedicated Region A.
    2. Atualizar tabelas de roteamento:
      • Para VCN-MGMT-Active: aponte a rota padrão (0.0.0.0/0) para o DRG.
      • Para a sub-rede Bastion em VCN-Primary: atualize sua tabela de roteamento para apontar para o DRG a fim de garantir que ele ainda possa acessar o VMware vCenter e o NSX Manager VMware.

    Depois que essas alterações forem feitas, o VMware vCenter e o NSX Manager VMware na OCI Dedicated Region A deverão ficar acessíveis pelo host do Bastion, mesmo que suas interfaces subjacentes agora residam em outra VCN.

Configurar Regras de Afinidade de DRS, HA e Política de Armazenamento vSAN VMware

Depois que o cluster esticado estiver totalmente operacional e a rede estiver estável em ambos os sites, configure o DRS (Distributed Resource Scheduler), a HA (High Availability) e atribua uma política de armazenamento vSAN VMware compatível com o site à carga de trabalho e às máquinas virtuais (VMs) de gerenciamento.

Essas configurações garantem a colocação ideal de VMs em domínios de falha e permitem a recuperação automática durante falhas no local.

Migrar VMs para o Cluster Estendido

Comece migrando todas as VMs de gerenciamento e VMs de carga de trabalho de teste para o cluster estendido recém-criado:

  • Use vMotion para mover as VMs de seus clusters originais específicos do site para o cluster esticado.
  • Se tudo estiver configurado corretamente (rede, armazenamento, grupos de portas), a migração de VM deverá ser concluída sem nenhum problema.

Se as regras NSX DRS padrão existirem e estiverem definidas como DEVIDO, remova-as. Isso pode interferir nas operações HA e impedir o failover dos nós do NSX Edge e das VMs do NSX Manager.

Criar VM e Grupos de Hosts

Definir grupos de afinidade para colocação de carga de trabalho:

  1. Criar Grupos de Hosts:
    • Agrupe hosts pertencentes ao Site Principal.
    • Agrupe hosts pertencentes ao Site Secundário.
  2. Criar Grupos de VMs:
    • VMs de Gerenciamento de Grupo que devem residir em hosts dentro de cada local (como vCenter, Gerenciadores NSX, nós NSX Edge, HCX Manager e outros, se aplicável).
    • Da mesma forma, agrupe todas as VMs de Carga de Trabalho juntas (no nosso caso, todas as VMs de teste).

Definir Regras de Afinidade de VM/Host

Após a definição dos grupos:

  • Crie regras de afinidade VM-to-Host para manter VMs localizadas em hosts em seu site pretendido.
  • Use as regras Executar VMs em Hosts para permitir flexibilidade de HA em cenários de failover.
  • Crie essas regras para a VM de Gerenciamento e os Grupos de VMs de Carga de Trabalho.

Esta configuração garante que durante a operação normal, cada site hospeda suas cargas de trabalho pretendidas, mas permite a recuperação automática no caso de um host ou falha do site.

Ativar Alta Disponibilidade (HA)
  • Certifique-se de que a opção HA esteja ativada no nível do cluster após a aplicação das regras de afinidade.
  • A opção padrão para Reiniciar VMs em um evento de Falha do Host garante a reinicialização da VM durante falhas inesperadas, incluindo interrupções completas do site.

Criar e Aplicar uma Política de Armazenamento vSAN Esticada

Para garantir a redundância de dados em ambos os sites em uma configuração estendida, defina uma nova política de SBPM (Gerenciamento de Políticas Baseado em Armazenamento vSAN). Essa política controlará como os dados da VM são distribuídos entre os domínios de falha e o site de testemunha.

Configure as seguintes regras de posicionamento dentro da política:

  • Tipo de Armazenamento: vSAN
  • Tolerância a Desastres do Site: Espelhamento de site – cluster esticado
  • Falhas a Serem Toleradas: Sem redundância de dados
  • Número de Faixas de Disco por Objeto: 1
  • Limite de IOPS para Objeto: 0

Deixe todas as outras opções em seus valores padrão.

Após a criação da política:

  1. Aplicar a política a todas as VMs de teste e gerenciamento no cluster esticado.
  2. Navegue até Monitorar, vSAN, Ressincronizar Objetos para observar e rastrear o processo de ressincronização.
  3. Após a conclusão da ressincronização, verifique o posicionamento do objeto para confirmar se a política está funcionando conforme esperado:
    • Um objeto de réplica está localizado no Site Principal
    • Uma segunda réplica de objeto está localizada no Site Secundário
    • O componente de testemunha reside na região de Testemunha remota

Todas as VMs aparecerão inicialmente como não compatíveis. Selecione cada VM ou um grupo de VMs e designe manualmente a política estendida recém-criada para torná-las em conformidade.

Além disso, navegue até Monitor, vSAN, Ressincronização de Objetos e Objetos Virtuais. Depois que o processo de ressincronização for concluído, você deverá observar que cada objeto virtual da VM é distribuído corretamente pelo nó Site Principal, Site Secundário e Testemunha, validando a conformidade total com o design de cluster esticado.