Quais são os requisitos de latência para o NSX 4.2 Federation?

O NSX Federation exige uma latência (RTT) de 150ms ou menos entre o Global Manager e os Local Managers, e idealmente abaixo de 10ms para segmentos Layer 2 stretched para evitar degradação do desempenho da aplicação.

Por que devo usar um Stretched Tier-0 Gateway?

Stretched T0s permitem mobilidade de IP entre sites, garantindo que uma VM possa se mover do Site A para o Site B sem alterar seu default gateway, embora isso exija engenharia cuidadosa de BGP para evitar roteamento subótimo.

Como o vDefend se integra com o NSX 4.2 multi-site?

O vDefend é o pacote de segurança renomeado e aprimorado no NSX 4.2, incluindo DFW, IDS/IPS e Malware Prevention. Em uma configuração multi-site, as políticas do vDefend são gerenciadas no Global Manager para aplicação consistente.

Posso ter egress active-active em dois data centers diferentes?

Sim, mas com ressalvas. Para evitar hair-pinning, você deve usar configurações de 'Local Egress', embora serviços stateful como NAT ou Load Balancing ainda possam ser fixados a um cluster Edge específico de um site.

Qual é o dimensionamento mínimo para Edge Nodes em um Federation?

Para ambientes multi-site de produção, Edge VMs 'Large' (8 vCPU, 32GB RAM) são o mínimo recomendado para lidar com a sincronização intensiva e a sobrecarga de roteamento.

O NSX 4.2 Federation substitui o Site Recovery Manager (SRM)?

O NSX Federation fornece a conectividade de rede e a persistência da política de segurança, mas não orquestra sequências de inicialização de VMs ou replicação de armazenamento; para isso, você ainda precisa do SRM ou de uma ferramenta similar.

Design Avançado Multi-Site com NSX 4.2: Evolução de Federation e Segurança

Em 2026, rede multi-site não é mais sobre esticar Layer 2 para satisfazer requisitos legados de heartbeat; é sobre a sincronização programática da postura de segurança e serviços stateful através de domínios de falha. Com o VMware NSX 4.2 (agora parte do ciclo VCF 5.x/9.x), a mudança de 'Global Manager como uma solução de último recurso' para 'Global Manager como a fonte de verdade' está completa, e se você ainda está construindo Local Managers isolados com sincronização manual baseada em scripts, você está arquitetando débito técnico em seu private cloud.

A Evolução do NSX Federation no 4.2

O NSX Federation amadureceu desde os primeiros dias da versão 3.x de objetos "Global" problemáticos para um robusto motor de sincronização que trata múltiplos sites como um único fabric lógico. No NSX 4.2, o pivô arquitetural centraliza-se na integração com o vDefend (anteriormente NSX Distributed Firewall) e na capacidade de lidar com escala massiva através de Global Managers (GM) e Local Managers (LM).

O design padrão para 2026 envolve um par redundante de Global Managers – idealmente hospedado em um cluster de gerenciamento fisicamente separado do data plane. O GM não fica no data path; ele é o orchestrator do control plane. Se o seu GM cair, seu tráfego continua fluindo, mas sua capacidade de atualizar a política de segurança ou alterar o roteamento entre sites desaparece. Recomendamos um cluster GM de 3 nós para alta disponibilidade, com 32 vCPUs e 128GB RAM por nó para lidar com a sobrecarga da telemetria de prevenção avançada de ameaças do vDefend.

Design de Gateway Tier-0 e Tier-1: Stretched vs. Local

A decisão mais crítica no design multi-site do NSX 4.2 é o ponto de saída North-South. Você tem três padrões primários, mas apenas dois são viáveis para empresas de alto desempenho:

Primary-Secondary Stretched T0: Um site está ativo para todo o tráfego North-South. Se o Site A falhar, o BGP reconverge e o Site B assume. Este é o mais simples de gerenciar, mas introduz "tromboning" subótimo para o tráfego de saída do Site B.
Active-Active Stretched T0 (All Primary): Introduzido para resolver o problema de latência, isso permite ingress/egress em ambos os sites. No entanto, requer manipulação cuidadosa do BGP (AS-Path prepending ou communities) para garantir caminhos de retorno simétricos.
Local Egress: O T0 é local para cada site, mas o T1 é stretched. Este é o gold standard para 2026.

# Exemplo: Configurando BGP em um Stretched T0 via NSX CLI
set service bgp 65001
set neighbor 10.255.1.1 remote-as 65100
set neighbor 10.255.1.1 route-map PREPEND_OUT out
!
# Prepending no site secundário para influenciar o ingresso
route-map PREPEND_OUT permit 10
 set as-path prepend 65001 65001 65001

BGP-EVPN e a Morte da Complexidade do Stretched VNI

O NSX 4.2 simplificou significativamente a implementação do BGP-EVPN para multi-site. Embora o NSX use o encapsulamento GENEVE internamente entre Transport Nodes (TEPs), a entrega para o core físico (Cisco Nexus 9300 ou Arista 7050X3) frequentemente depende do EVPN para manter a multi-tenancy. No 4.2, vemos o modo "Route Server" tornando-se o padrão para Federation em larga escala. Isso permite que o Global Manager envie as configurações de Route Target (RT) e Route Distinguisher (RD) para os Local Managers sem gerenciamento manual de colisão.

Ao projetar esses links inter-site (ISL), não restrinja o MTU. Você precisa de no mínimo 1700 bytes para considerar a sobrecarga do GENEVE (50 bytes) mais qualquer tagging interna. Se você estiver operando sobre MPLS ou dark fiber de um provedor, e eles não puderem fornecer MTU de 1700+, o desempenho do seu NSX entrará em colapso devido à fragmentação.

Sincronização de Políticas do vDefend (NSX DFW)

A segurança é o principal motor do NSX Federation hoje. Com o vDefend no 4.2, o Global Manager permite definir "Global Security Groups" com base em tags. Se uma VM se mover de Londres para Nova York (via HCX ou vMotion), a tag env:production a segue, e as regras de micro-segmentação são aplicadas localmente nos hosts vSphere de Nova York imediatamente.

Uma ressalva: as assinaturas do Distributed IDS/IPS (D-IDS/IPS) são gerenciadas no nível do GM. No 4.2, a frequência de sincronização foi ajustada para menos de 30 segundos para atualizações de assinaturas em mais de 16 sites. Nós defendemos uma abordagem de política "Global-First". Defina suas regras de "Ring-0" (Gerenciamento, AD, NTP) e "Ring-1" (Prod, Dev, Test) no nível do GM. Apenas regras específicas de aplicação e exclusivas do site devem ser enviadas para o Local Manager.

vSphere 8.0u3 + NSX 4.2: A Vantagem da Aceleração de Hardware

Executar o NSX 4.2 em CPUs Broadwell ou SkyLake legadas é um desperdício de receita de licenciamento. Para aproveitar todo o poder do sandboxing e NTA (Network Traffic Analysis) do vDefend, você deve implantar no vSphere 8.0u3 com Data Processing Units (DPUs) como NVIDIA BlueField-2 ou AMD Pensando. Isso descarrega o encapsulamento TEP e as pesquisas DFW dos núcleos x86 para a DPU SmartNIC.

Em um design multi-site, as DPUs permitem manter o throughput line-rate de 100Gbps mesmo ao aplicar inspeção profunda de pacotes (DPI) intensiva em segmentos stretched. Sem DPUs, espere uma sobrecarga de CPU de 20-30% em seus hosts ESXi apenas para encapsulamento/desencapsulamento NSX em ambientes de alta rotação.

Recuperação de Desastres: SRM vs. NSX Federation

Frequentemente, arquitetos confundem NSX Federation com um orchestrator de DR. O Federation fornece o *encaminhamento* (disponibilidade de IP e política de segurança), mas o Site Recovery Manager (SRM) ou o VMware Live Cyber Recovery (VLCR) fornecem a *automação*. No 4.2, a integração é mais estreita; o SRM agora pode acionar nativamente o "Global Manager Switchover" via API, promovendo um GM em Standby para Ativo se a região primária for destruída.

Para mais informações sobre a integração dessas camadas, consulte nosso guia sobre vSphere 8 Networking Deep Dive. O objetivo é atingir um Recovery Time Objective (RTO) de minutos, não horas, o que só é possível se a rede já estiver "pré-aquecida" no site secundário via Federation.

Dimensionamento e Escalonamento do Edge Cluster

Não economize nos Edge Nodes. Para uma implantação multi-site 4.2, recomendamos o fator de forma Large ou X-Large Edge VM (8-16 vCPUs). Se você estiver usando serviços stateful como NAT, Load Balancing (AVI) ou VPN em um T1 stretched, esses serviços *devem* ser executados nos Edge Nodes. No 4.2, o T1 "Active-Active Site-A/Site-B" fornece egress local, mas mantém os serviços stateful fixados a um site primário. Entenda que, se o seu T1 for stretched e você estiver usando um firewall stateful nele, seu tráfego fará hair-pin de volta para o site onde reside a instância "Active" desse T1.

Operacionalizando o Fabric

Monitorar um fabric NSX multi-site requer mais do que apenas o vRealize Operations (Aria Operations). Você precisa do NSX Intelligence (agora um serviço containerizado dentro do NSX Manager) para visualizar os fluxos cross-site. No 4.2, o NSX Intelligence pode abranger a Federation, fornecendo uma "God View" de como o tráfego se move de um servidor web no Site A para um banco de dados no Site B. Se você não estiver usando isso, estará voando às cegas em uma interrupção localizada.

O custo dessas licenças (VCF Enterprise ou NSX Advanced/Enterprise Plus) é significativo, muitas vezes excedendo $5,000 por CPU socket quando em bundle. Não deixe esse investimento apodrecer – garanta que sua equipe esteja treinada nos comandos CLI get logical-routers e get firewall threshold para solucionar problemas do control plane quando a GUI inevitavelmente atrasar durante um evento de sincronização global.

Nossa equipe na TechLeague é especializada em implementações NSX de alta disponibilidade para as empresas Fortune 500. Se o seu design atual parece uma confusão de VLANs e regras de firewall manuais, é hora de modernizar. Verifique nossas opções de consultoria e revisões arquiteturais em techleague.io.