NSX-T: Como Migrar de vSphere Distributed Switch

Contexto da Migração de vSphere Distributed Switch no NSX-T

A migração de uma vSphere Distributed Switch (vDS) para o ambiente VMware NSX-T Data Center representa um dos momentos críticos na jornada de transformação digital de infraestruturas tradicionais. Este processo não envolve apenas a troca de tecnologia de rede, mas exige uma compreensão profunda da topologia lógica, segmentação de tráfego e políticas de segurança que serão recriadas no novo plano de controle distribuído.

O objetivo principal desta operação é garantir a conectividade contínua das máquinas virtuais (VMs) enquanto elas migram de um switch virtual gerenciado pela camada de gerenciamento vCenter para os segmentos de rede distribuídos do NSX-T. A falha nesse processo pode resultar em interrupção de serviços, perda de conectividade de gerenciamento ou inconsistências nas políticas de segurança implementadas.

Neste tutorial, abordaremos o fluxo técnico completo da migração, desde a preparação dos componentes de infraestrutura até a validação final, utilizando boas práticas recomendadas para ambientes de produção que utilizam NSX-T, integrado com ecossistemas como VMware VCF (VMware Cloud Foundation) ou deployments standalone.

Pré-requisitos e Preparação do Ambiente

Antes de iniciar qualquer procedimento de migração, é fundamental garantir que todos os componentes subjacentes estejam operacionais e compatíveis. A estrutura do NSX-T baseia-se em três planos: Plano de Controle, Plano de Gerenciamento e Plano de Dados (Transport Nodes). A migração da vDS impacta diretamente o Plano de Dados.

Verifique os seguintes pontos críticos:

• O cluster ESXi alvo já foi adicionado ao NSX Manager como um Transport Node?
• O uplink físico (NIC física) do host está associado corretamente a uma Uplink Host Overlay Segment ou Physical Switch Configuration no NSX?
• O MTU jumbo frames (geralmente 9000) está configurado consistentemente nos switches físicos e nos vNICs de transporte do ESXi?
• Existe um plano de rollback caso a migração falhe durante o movimento das VMs?

A compatibilidade entre a versão do VMware vCenter, dos hosts ESXi e do VMware Aria (antigo vRealize Suite) é essencial. Certifique-se de que o NSX Manager esteja sincronizado com o inventory do vCenter.

Etapa 1: Configuração da Interoperabilidade entre vDS e NSX-T

O NSX-T utiliza um recurso chamado vSphere Distributed Switch (vDS) Interoperability para permitir que hosts ESXi rodem tanto a vDS tradicional quanto os segmentos de transporte do NSX simultaneamente. Essa configuração é feita via API REST ou PowerShell, pois não está disponível diretamente na interface gráfica do NSX Manager em todas as versões.

Para habilitar a interoperabilidade, você deve executar o comando abaixo no NSX Manager ou através do CLI do vCenter:

curl -k -u "admin:YOUR_PASSWORD" https://NSX_MANAGER_IP/api/v1/trust/certificates
# Exemplo de chamada API para habilitar a feature via POST
curl -k -u "admin:YOUR_PASSWORD" -H "Content-Type: application/json" -X POST https://NSX_MANAGER_IP/api/v1/trust/certificates \
-d '{
  "action": "CREATE",
  "type": "SERVICE_CERTIFICATE"
}'

No entanto, a configuração mais comum e visível é a criação do vDS Interoperability Switch. Isso permite que o NSX gerencie os uplinks físicos enquanto o vCenter continua gerenciando as portas lógicas da vDS antiga. Sem essa etapa, os hosts não poderão participar do overlay do NSX se estiverem conectados à mesma vDS.

Etapa 2: Criação dos Segmentos de Rede Lógicos (Logical Switches)

Antes de mover as VMs, a nova rede lógica deve existir no NSX-T. No modelo tradicional da vSphere, você criava uma nova vDS e port groups dentro do vCenter. No NSX-T, essa função é exercida pelos Logical Switches.

Acesse o painel do NSX Manager (UI) ou utilize a API para criar os segmentos:

1. Navegue até Networking > Segments.
2. Clique em Add Segment.
3. Preencha o nome do segmento (ex: PROD-APP-SUBNET-A).
4. Defina o modo de transporte como VLAN (se estiver usando overlay físico) ou VXLAN (para redes isoladas logicamente).
5. Se for usar VLAN, associe o segmento à sua Tier-0 Gateway e configure a etiqueta VLAN correspondente no switch físico.

Para ambientes que dependem de automação via VMware VRA (VMware Aria Automation), certifique-se de que os sites ou projetos estejam atualizados com as novas redes lógicas para permitir o provisionamento correto das VMs após a migração.

Etapa 3: Preparação do Transport Node no ESXi

Cada host ESXi que receberá as VMs migradas deve ser configurado como um Transport Node. Isso define como o host se comunica com o plano de controle do NSX e como ele encaminha o tráfego.

1. No NSX Manager, vá para Networking > Transport Nodes.
2. Clique em Add Transport Node.
3. Selecione o host ESXi alvo.
4. Defina o tipo de uplink: associe as NICs físicas (ex: vmnic0, vmnic1) às Uplink Profiles criadas anteriormente.
5. Crie um Uplink Profile se necessário, definindo os modos de bonding (LACP ou Active-Active) e MTU.
6. Atribua o Host Overlay Segment para a comunicação de tunelamento VXLAN.

Após aplicar a configuração, o status do Transport Node deve mudar para Ready. Se houver erros de conectividade com o NSX Controller, verifique as regras de firewall no plano de gerenciamento.

Etapa 4: Execução da Migração via vCenter

A migração real ocorre na interface do VMware vCenter Server. O objetivo é alterar a configuração de rede das VMs para que elas deixem de usar as portas da vDS antiga e passem a usar os segmentos lógicos do NSX-T.

4.1. Migração Manual (vMotion + Network Change)

Esta é a abordagem mais segura para garantir o controle total sobre cada máquina virtual.

1. No vCenter, clique com o botão direito na VM e selecione Migrate.
2. Escolha Change only the storage ou Change both storage and compute, dependendo da estratégia. Para migração de rede pura, o vMotion é suficiente.
3. Durante o wizard de migração, na tela de seleção de host de destino, certifique-se de que o host seja um Transport Node válido do NSX.
4. Na tela de Networking, selecione o segmento lógico do NSX-T correspondente (ex: PROD-APP-SUBNET-A) em vez da antiga port group da vDS.
5. Finalize a migração. O vMotion moverá a VM e, ao conectar-se ao novo segmento, o host ESXi estabelecerá uma sessão de controle com o NSX Manager.

Após a conclusão, verifique no painel do NSX Manager, em Networking > VTEPs, se o endereço IP de transporte do host está listado e se as informações da VM aparecem na aba de detalhes do segmento lógico.

4.2. Migração em Lote (Bulk Migration)

Para grandes volumes de VMs, a migração manual é inviável. Utilize scripts PowerShell ou APIs do vCenter para automatizar a alteração da rede.

# Exemplo conceitual usando VMware PowerCLI
Get-VM -Name "VM-*" | Get-NetworkAdapter | Set-NetworkAdapter -PortGroup "NSX-Segment-PROD" -Confirm:$false

É crucial realizar testes em um grupo pequeno de VMs não críticas antes de executar scripts em larga escala. Monitore o consumo de CPU do NSX Manager e dos hosts ESXi durante a migração em massa para evitar sobrecarga.

Etapa 5: Validação da Conectividade e Segurança

Após a migração, a validação não se limita ao ping básico. É necessário verificar o funcionamento das microsegmentações de segurança.

5.1. Testes de Conectividade

• Verifique se as VMs obtêm IP via DHCP (se aplicável) ou possuem IPs estáticos corretos.
• Teste a conectividade entre VMs no mesmo segmento lógico.
• Teste a conectividade entre segmentos diferentes. No NSX-T, por padrão, o roteamento entre subnets é bloqueado a menos que haja uma Tier-1 Gateway associada e regras de roteamento configuradas.

5.2. Verificação de Segurança (Firewall Rules)

O NSX-T implementa firewalls distribuídos no kernel do ESXi (vsc). As regras de segurança que existiam na vDS tradicional (baseadas em MAC/IP estático) devem ser recriadas como Security Groups e Firewall Rules no NSX.

1. Acesse Security > Firewall.
2. Crie regras para permitir o tráfego necessário entre os segmentos migrados.
3. Habilite a aplicação das regras (Enable) e verifique as contagens de pacotes (packet counts) para confirmar que o tráfego está sendo processado pelas políticas.

Se você utiliza VMware SRM (Site Recovery Manager), é obrigatório validar os planos de recuperação. A migração da vDS pode quebrar os mapeamentos de rede nos planos de recuperação se as redes de destino não forem atualizadas para refletir os novos IDs dos segmentos lógicos do NSX.

Etapa 6: Descomissionamento da vSphere Distributed Switch Antiga

Com todas as VMs migradas e validadas, a vDS antiga pode ser removida. No entanto, siga esta ordem estrita para evitar erros:

1. Remova todos os hosts ESXi do cluster da vDS antiga.
2. Se houver portas órfãs ou configurações residuais, limpe o inventory.
3. Exclua a vSphere Distributed Switch no vCenter.
4. Confirme que os hosts estão agora operando apenas com as interfaces de transporte do NSX-T.

A remoção prematura da vDS antes da migração completa das VMs resultará em perda imediata de conectividade para as máquinas ainda vinculadas a ela. Portanto, mantenha a vDS ativa até que o status de todas as VMs seja confirmado como "Migrated" no dashboard do NSX.

Considerações Finais sobre Integração com Ecossistemas VMware

A migração para o NSX-T não é um evento isolado; ela afeta ferramentas adjacentes. Profissionais que utilizam Veeam Backup & Replication devem revisar as configurações de job de backup, especialmente se houver dependência de snapshots em redes específicas ou se a replicação for feita via API da vSphere.

Além disso, para ambientes que utilizam VMware Aria Operations (antigo vRealize Operations), é necessário aguardar alguns minutos até que o adaptador do NSX-T sincronize os dados de telemetria. Isso permite que as dashboards de performance reflitam corretamente o tráfego nos novos segmentos lógicos, em vez de mostrar dados desatualizados da vDS antiga.

A migração de uma vSphere Distributed Switch para o NSX-T é um processo que demanda precisão cirúrgica. Ao seguir rigorosamente as etapas de preparação, configuração dos Transport Nodes e validação pós-migração, garante-se que a infraestrutura ganhe não apenas modernização tecnológica, mas também agilidade operacional e segurança granular.

Lembre-se: documentação é sua melhor aliada. Mantenha registros das mapeamentos entre Port Groups antigas e Logical Switches novos para facilitar futuras manutenções ou expansões do ambiente.