Cisco ACI Multi-Pod vs. Multi-Site: Escolhas Arquiteturais em 2026

A escolha entre Cisco ACI Multi-Pod e Multi-Site é uma decisão arquitetural definidora com consequências que se estendem muito além da folha de dados. Com muita frequência, essa decisão é enquadrada como uma simples questão de latência ou escala. Na realidade, a escolha correta para 2026 depende de uma avaliação sóbria dos domínios de falha, complexidade operacional e custo total de propriedade. O Multi-Pod oferece simplicidade sedutora ao custo de um domínio de falha monolítico, enquanto o Multi-Site oferece isolamento de falha verdadeiro, mas exige um nível mais alto de conhecimento de engenharia e um orçamento significativamente maior. Escolher incorretamente leva não apenas à dívida técnica, mas a interrupções que podem definir a carreira.

Constructos Arquiteturais Principais: Pods e Sites

Antes de comparar as extensões multi-fabric, é fundamental ter uma compreensão precisa dos componentes de linha de base. Todo o portfólio ACI é construído sobre uma topologia spine-leaf Clos, mas a forma como essas topologias são gerenciadas e interconectadas dita a arquitetura.

O Single ACI Fabric: Um Domínio de Falha de Linha de Base

Um fabric ACI padrão consiste em um cluster de pelo menos três Application Policy Infrastructure Controllers (APICs), um conjunto de switches spine (por exemplo, Nexus 9508 com placas de linha Gen3 -FX3) e um conjunto de switches leaf (por exemplo, Nexus 93180YC-FX3). Toda essa construção forma um único domínio de controle e administração. Um princípio fundamental do ACI é que todos os endpoints dentro do fabric estão a um único hop de distância um do outro da perspectiva de política e acessibilidade, habilitados pelo overlay VXLAN. Criticamente, este single fabric é um único domínio de falha. Um bug catastrófico no software APIC (executando ACI versão 6.0+) ou um colapso do control plane do Council of Oracle Protocol (COOP) pode e irá impactar todo o fabric.

ACI Multi-Pod: O "Single Fabric" Estendido

O ACI Multi-Pod pode ser pensado como pegar um fabric ACI padrão e "estendê-lo" por vários locais físicos, ou "pods". Cada pod é sua própria topologia spine-leaf. No entanto, todos os pods são gerenciados por um *único* cluster APIC, que reside em um dos pods. Os pods são conectados por meio de uma Inter-Pod Network (IPN) baseada em IP. De uma perspectiva de gerenciamento, é um fabric. Todos os objetos de configuração — tenants, EPGs, Bridge Domains (BDs) — são sincronizados em todos os pods. Isso significa que você tem um single pane of glass para gerenciamento, mas também significa que você tem um único domínio de falha geograficamente distribuído. Uma falha no cluster APIC pode tornar toda a infraestrutura multi-pod instável.

ACI Multi-Site: Uma Federação de Fabrics Independentes

O ACI Multi-Site apresenta um paradigma fundamentalmente diferente. Cada "site" é um fabric ACI completo e independente com seu próprio cluster APIC dedicado. Esses sites são totalmente autônomos; uma falha no Site1 tem impacto operacional zero no Site2. Os sites são interconectados por meio de uma rede IP/MPLS ou VXLAN EVPN padrão. A mágica acontece com o Nexus Dashboard Orchestrator (NDO), anteriormente Multi-Site Orchestrator (MSO). Executando em um cluster Nexus Dashboard separado, o NDO (versão 4.2+) atua como um motor de federação e orquestração de políticas. Um administrador define templates e políticas no NDO, que então envia as configurações correspondentes para o cluster APIC local de cada site. Ele não gerencia os fabrics em tempo real; é uma camada de orquestração, não um componente de control plane.

A Interconexão: Detalhes do IPN vs. ISN

A rede que conecta seus pods ou sites não é um detalhe de implementação trivial; é um componente central da arquitetura com requisitos específicos e rígidos.

Requisitos de Design do IPN Multi-Pod

O IPN é uma rede Layer 3 que conecta os switches spine de cada pod. Os spines estabelecem adjacências OSPF com os dispositivos IPN e sessões BGP EVPN com os spines em outros pods. Os requisitos principais incluem:

• High MTU: O IPN deve suportar um MTU de pelo menos 9150 bytes para acomodar o tráfego encapsulado em VXLAN (overhead de 50 bytes) sem fragmentação. Inegociável. Usar dispositivos como o Catalyst 9500-48UXM para o IPN requer validação MTU end-to-end cuidadosa.
• Multicast: PIM-Bidir é o protocolo de roteamento necessário para lidar eficientemente com tráfego Broadcast, Unknown Unicast e Multicast (BUM) que deve ser inundado entre pods. Embora outros modos PIM possam funcionar, Bidir é o design padrão.
• DHCP Relay: O APIC usa DHCP para atribuir endereços TEP aos nós, incluindo spines em pods remotos. O IPN deve ser configurado com agentes DHCP relay apontando para a sub-rede do pool TEP definida no APIC.
• Latency: O tempo de ida e volta (RTT) suportado oficialmente é de 50ms. No entanto, qualquer design que estenda Bridge Domains L2 sobre um IPN com latência superior a 10ms está cortejando o desastre. A alta latência amplifica o impacto de broadcast storms e pode causar degradação severa de desempenho para aplicações como vMotion. Para conectividade roteada L3-only entre pods, 50ms é mais realista.

Multi-Site Inter-Site Network (ISN)

O ISN para Multi-Site é mais simples em seus requisitos específicos do ACI, mas assume uma rede subjacente mais sofisticada. O ISN é tipicamente um MPLS L3VPN fornecido por operadora ou, cada vez mais, uma rede de fibra escura autogerenciada executando VXLAN BGP EVPN. A conexão do data plane é de spine a spine, que utiliza sessões BGP EVPN para trocar informações de acessibilidade de endpoint entre sites. O NDO orquestra o estabelecimento dessas sessões BGP, mas o transporte de rede subjacente é independente do ACI. Esta é uma distinção crucial: o Multi-Site não dita *como* seus sites são conectados, apenas que eles *podem* trocar tráfego roteado com MTU apropriada.

Domínios de Falha e Blast Radius

Esta é a consideração mais importante. Um domínio de falha maior simplifica o gerenciamento, mas aumenta o risco. Multi-Pod e Multi-Site estão em extremidades opostas deste espectro.

Com Multi-Pod, um bug no ACI, um push de configuração falho ou uma falha de control plane do APIC é um evento global. Uma alteração feita através da GUI ou API do APIC é propagada para todos os pods simultaneamente. Imagine um cenário onde um bug no COOP leva a um problema de aprendizado de endpoint em todo o fabric. Em um design Multi-Pod, essa questão abrangeria instantaneamente todos os seus data centers. Seu site de recuperação de desastres seria impactado pela mesma falha que seu site primário, tornando-o inútil. Este é um risco inaceitável para a maioria das implementações de nível empresarial que visam a verdadeira continuidade de negócios.

Multi-Site, por outro lado, oferece isolamento de falha robusto. Cada site é um fabric ACI autocontido. O Nexus Dashboard Orchestrator é uma plataforma de orquestração out-of-band. Se o cluster NDO falhar, *mudanças* de política entre sites não podem mais ser feitas, mas o data plane e os control planes existentes de cada site continuam a funcionar perfeitamente. O tráfego de dados entre sites não é afetado. Um bug na versão do ACI rodando no Site1 não se propaga para o Site2. Isso permite upgrades escalonados e controlados (por exemplo, atualizar o Site2 para ACI 6.1, validar e depois atualizar o Site1 semanas depois), uma rede de segurança operacional crítica que o Multi-Pod não possui.

Exemplo de Dimensionamento: Largura de Banda Inter-Site e Recursos NDO

Vamos modelar um cenário típico de dois sites: dois data centers a 80km de distância, precisando suportar clusters de aplicação active/active e replicação de banco de dados.

• Sites: 2
• Total Leafs: 300 (150 por site)
• Tenants: 50
• EPGs: 3.000
• Tráfego de Replicação Inter-Site de Pico: 150 Gbps

Abordagem de Dimensionamento Multi-Pod

Para Multi-Pod, a principal preocupação é o IPN. Você precisa de dispositivos IPN capazes de encaminhar 150 Gbps de tráfego de linha, large-packet. Um par de Juniper SRX5800s ou chassis Cisco Catalyst 9606R com densidade de porta 100G suficiente seria necessário. O maior problema é o tráfego BUM L2. Se você estender 500 VLANs (como BDs) entre pods, e cada uma gerar apenas 10 Mbps de tráfego BUM em média, isso é 5 Gbps de tráfego multicast constante consumindo largura de banda do IPN e CPU nos roteadores IPN. Este cálculo é frequentemente ignorado. (Número de BDs Estendidos) * (Tráfego BUM Médio por BD) = Carga Constante do IPN. Esta carga está sempre presente e deve ser considerada em seu planejamento de largura de banda.

Abordagem de Dimensionamento Multi-Site

Para Multi-Site, você provisiona um serviço L3VPN/EVPN Wave de 200Gbps (150 Gbps + 33% de headroom) de uma operadora. O foco muda para o dimensionamento do cluster Nexus Dashboard. Com base no guia de dimensionamento do Cisco NDO 4.2, o gerenciamento de 2 sites, 3000 EPGs e 50 tenants requer um cluster NDO de 3 nós, onde cada nó é uma máquina virtual com aproximadamente 16 vCPUs, 64GB RAM e 1TB de espaço em disco. Esta é uma pegada de virtualização não trivial. O custo não está no cálculo de largura de banda do data path (que é um custo simples de circuito de operadora), mas na computação e licenciamento de software para o NDO e o cluster APIC redundante no segundo site.

Armadilha Comum: Estender L2 Sobre DCI

A capacidade mais perigosa oferecida por Multi-Pod e Multi-Site é a de estender um Bridge Domain Layer 2 entre locais geograficamente separados. Embora tecnicamente possível, é quase sempre um erro arquitetural. Estender L2 cria um único broadcast domain, o que significa que um broadcast storm em um site inundará os links DCI/IPN e impactará o outro site (fate-sharing). Isso complica a solução de problemas e muitas vezes serve como uma muleta para evitar a modernização de aplicações legadas que possuem endereços IP hard-coded. Embora o Multi-Site seja mais elegante na forma como tunela o tráfego L2 com VXLAN, o problema fundamental permanece. A melhor prática em 2026 é manter os domínios L2 locais a um único site e usar conectividade roteada L3-only entre sites para todo o tráfego. Não estenda.

Quando Não Usar ACI Multi-Site

Apesar de sua superioridade técnica no isolamento de falhas, o Multi-Site não é uma solução universal. Existem cenários específicos onde o Multi-Pod é a escolha mais pragmática.

Primeiro é o custo. Uma implantação Multi-Site requer um cluster APIC completo (pelo menos 3 nós) para *cada site*, mais um cluster Nexus Dashboard (físico ou virtual), mais licenciamento de software NDO (por exemplo, N-D-ADV-S-GF). Isso pode facilmente dobrar o custo do controlador e do software em comparação com um design Multi-Pod que usa um único cluster APIC. Se seus dois "sites" são meramente dois andares no mesmo edifício, o custo do Multi-Site é injustificável.

Em segundo lugar, escala e latência. Para uma implantação pequena (por exemplo, <80 switches leaf no total) em dois locais metropolitanos com fibra escura e RTT <5ms, o Multi-Pod oferece um plano de gerenciamento unificado que é mais simples de operar do que o NDO. O risco de um único domínio de falha pode ser uma troca calculada e aceitável pela simplicidade operacional quando a proximidade física e a baixa latência limitam o potencial de problemas induzidos pela rede.

Finalmente, considere o conjunto de habilidades de sua equipe. O Multi-Pod é uma extensão direta do conhecimento de ACI de um único fabric. O Multi-Site, com NDO, schema templates e a necessidade de gerenciar uma rede inter-site BGP EVPN subjacente, representa um salto significativo em complexidade. Se sua equipe não está pronta para esse salto operacional, implementar o Multi-Site pode introduzir mais risco de má configuração do que resolve através do isolamento de falhas.

Em última análise, a decisão reside em uma avaliação clara do risco. O Multi-Pod prioriza operações simplificadas dentro de um único domínio de falha estendido, tornando-o adequado para implantações em áreas metropolitanas onde o custo e a simplicidade são primordiais e o risco é considerado aceitável. O Multi-Site prioriza o isolamento de falhas e a escalabilidade acima de tudo, tornando-o a escolha obrigatória para redes de grande escala e geograficamente dispersas onde a continuidade dos negócios é inegociável. Escolha a arquitetura que se alinha à sua realidade operacional e orçamento, não apenas aquela que é tecnicamente possível.

Na TechLeague, nossos especialistas certificados podem ajudá-lo a modelar o TCO e o impacto operacional de ambas as arquiteturas para seu ambiente específico. Entre em contato conosco para iniciar a conversa. Leia nossas postagens relacionadas sobre design VXLAN EVPN e o ecossistema Nexus Dashboard para saber mais.