Cisco ACI Multi-Pod vs. Multi-Site: Opciones de Arquitectura en 2026

La elección entre Cisco ACI Multi-Pod y Multi-Site es una decisión arquitectónica fundamental con consecuencias que se extienden mucho más allá de la hoja de datos. Con demasiada frecuencia, esta decisión se enmarca como una simple cuestión de latencia o escala. En realidad, la elección correcta para 2026 depende de una evaluación sobria de los dominios de falla, la complejidad operativa y el costo total de propiedad. Multi-Pod ofrece una simplicidad seductora a costa de un dominio de falla monolítico, mientras que Multi-Site proporciona un verdadero aislamiento de fallas, pero exige un nivel más alto de habilidad de ingeniería y un presupuesto significativamente mayor. Elegir incorrectamente conduce no solo a deuda técnica, sino a interrupciones que definen una carrera.

Constructos Arquitectónicos Centrales: Pods y Sites

Antes de comparar las extensiones multi-fabric, es fundamental tener una comprensión precisa de los componentes base. Todo el portafolio de ACI se basa en una topología Clos de spine-leaf, pero la forma en que se gestionan e interconectan estas topologías dicta la arquitectura.

El Single ACI Fabric: Un Dominio de Falla Base

Un fabric ACI estándar consta de un clúster de al menos tres Application Policy Infrastructure Controllers (APICs), un conjunto de switches spine (por ejemplo, Nexus 9508 con tarjetas de línea Gen3 -FX3) y un conjunto de switches leaf (por ejemplo, Nexus 93180YC-FX3). Toda esta construcción forma un único dominio administrativo y de plano de control. Un principio fundamental de ACI es que todos los endpoints dentro del fabric están a un solo salto de distancia entre sí desde la perspectiva de la política y la accesibilidad, habilitado por el overlay VXLAN. Críticamente, este single fabric es un dominio de falla único. Un bug catastrófico en el software APIC (ejecutando la versión 6.0+ de ACI) o un colapso del plano de control del Council of Oracle Protocol (COOP) puede y afectará a todo el fabric.

ACI Multi-Pod: El Single Fabric Extendido

ACI Multi-Pod puede entenderse como tomar un fabric ACI estándar y "extenderlo" a través de múltiples ubicaciones físicas, o "pods". Cada pod es su propia topología spine-leaf. Sin embargo, todos los pods son gestionados por un *único* clúster de APIC, que reside en uno de los pods. Los pods están conectados a través de una Inter-Pod Network (IPN) basada en IP. Desde una perspectiva de gestión, es un solo fabric. Todos los objetos de configuración (tenants, EPGs, Bridge Domains (BDs)) se sincronizan en todos los pods. Esto significa que tiene una única interfaz de gestión (single pane of glass), pero también significa que tiene un único dominio de falla geográficamente distribuido. Una falla en el clúster de APIC puede hacer que toda la infraestructura multi-pod sea inestable.

ACI Multi-Site: Una Federación de Fabrics Independientes

ACI Multi-Site presenta un paradigma fundamentalmente diferente. Cada "site" es un fabric ACI completo e independiente con su propio clúster de APIC dedicado. Estos sites son totalmente autónomos; una falla en Site1 tiene un impacto operativo nulo en Site2. Los sites están interconectados a través de una red IP/MPLS estándar o VXLAN EVPN. La magia ocurre con el Nexus Dashboard Orchestrator (NDO), anteriormente Multi-Site Orchestrator (MSO). Ejecutándose en un clúster de Nexus Dashboard separado, NDO (versión 4.2+) actúa como un motor de orquestación de federación y políticas. Un administrador define plantillas y políticas en NDO, que luego envía las configuraciones correspondientes al clúster de APIC local de cada site. No gestiona los fabrics en tiempo real; es una capa de orquestación, no un componente del plano de control.

La Interconexión: Detalles de IPN vs. ISN

La red que conecta sus pods o sites no es un detalle de implementación trivial; es un componente central de la arquitectura con requisitos específicos y rígidos.

Requisitos de Diseño de IPN para Multi-Pod

La IPN es una red de Capa 3 que conecta los switches spine de cada pod. Los spines establecen adyacencias OSPF con los dispositivos IPN y sesiones BGP EVPN con los spines de otros pods. Los requisitos clave incluyen:

• High MTU: La IPN debe soportar un MTU de al menos 9150 bytes para acomodar el tráfico encapsulado en VXLAN (50 bytes de overhead) sin fragmentación. No negociable. El uso de dispositivos como el Catalyst 9500-48UXM para la IPN requiere una validación MTU cuidadosa de extremo a extremo.
• Multicast: PIM-Bidir es el protocolo de enrutamiento requerido para manejar de manera eficiente el tráfico Broadcast, Unknown Unicast y Multicast (BUM) que debe ser inundado entre pods. Si bien otros modos PIM pueden funcionar, Bidir es el diseño estándar.
• DHCP Relay: El APIC utiliza DHCP para asignar direcciones TEP a los nodos, incluidos los spines en pods remotos. La IPN debe configurarse con agentes DHCP relay que apunten al subnet del pool TEP definido en el APIC.
• Latency: El tiempo de ida y vuelta (RTT) oficialmente soportado es de 50 ms. Sin embargo, cualquier diseño que extienda Bridge Domains (L2) sobre una IPN con latencia superior a 10 ms está abocada al desastre. La alta latencia amplifica el impacto de las tormentas de broadcast y puede causar una degradación severa del rendimiento para aplicaciones como vMotion. Para conectividad enrutada solo L3 entre pods, 50 ms es más realista.

Red Inter-Site (ISN) para Multi-Site

La ISN para Multi-Site es más simple en sus requisitos específicos de ACI, pero asume una red subyacente más sofisticada. La ISN es típicamente un MPLS L3VPN provisto por un carrier o, cada vez más, una red de fibra oscura autogestionada que ejecuta VXLAN BGP EVPN. La conexión del plano de datos es de spine a spine, lo que aprovecha las sesiones BGP EVPN para intercambiar información de accesibilidad de endpoints entre sites. NDO orquesta el establecimiento de estas sesiones BGP, pero el transporte de red subyacente es independiente de ACI. Esta es una distinción crucial: Multi-Site no dicta *cómo* sus sites están conectados, solo que *pueden* intercambiar tráfico enrutado con el MTU apropiado.

Dominios de Falla y Radio de Impacto

Esta es la consideración más importante. Un dominio de falla más grande simplifica la gestión pero aumenta el riesgo. Multi-Pod y Multi-Site se encuentran en extremos opuestos de este espectro.

Con Multi-Pod, un bug en ACI, una configuración mal implementada o una falla en el plano de control del APIC es un evento global. Un cambio realizado a través de la GUI o API del APIC se propaga a todos los pods simultáneamente. Imagine un escenario en el que un bug en COOP conduce a un problema de aprendizaje de endpoints en todo el fabric. En un diseño Multi-Pod, este problema se extendería instantáneamente a todos sus data centers. Su site de recuperación ante desastres se vería afectado por la misma falla que su site primario, dejándolo inservible. Esto es un riesgo inaceptable para la mayoría de las implementaciones a nivel empresarial que buscan una verdadera continuidad de negocio.

Multi-Site, por el contrario, ofrece un robusto aislamiento de fallas. Cada site es un fabric ACI autocontenido. El Nexus Dashboard Orchestrator es una plataforma de orquestación out-of-band. Si el clúster NDO falla, los *cambios* de política entre sites ya no se pueden realizar, pero el plano de datos y los planos de control existentes de cada site continúan funcionando perfectamente. El tráfico de datos entre sites no se ve afectado. Un bug en la versión de ACI que se ejecuta en Site1 no se propaga a Site2. Esto permite actualizaciones escalonadas y controladas (por ejemplo, actualizar Site2 a ACI 6.1, validar, luego actualizar Site1 semanas después), una red de seguridad operativa crítica de la que carece Multi-Pod.

Ejemplo de Sizing: Ancho de Banda Inter-Site y Recursos de NDO

Modelemos un escenario típico de dos sites: dos data centers separados por 80 km, que necesitan soportar clústeres de aplicaciones active/active y replicación de bases de datos.

• Sites: 2
• Total de Leafs: 300 (150 por site)
• Tenants: 50
• EPGs: 3,000
• Tráfico de Replicación Inter-Site Pico: 150 Gbps

Enfoque de Sizing para Multi-Pod

Para Multi-Pod, la principal preocupación es la IPN. Necesita dispositivos IPN capaces de reenviar 150 Gbps de tráfico a velocidad de línea y con packets grandes. Sería necesario un par de Juniper SRX5800s o chasis Cisco Catalyst 9606R con suficiente densidad de puertos de 100G. El problema mayor es el tráfico BUM de L2. Si extiende 500 VLANs (como BDs) entre pods, y cada una genera solo 10 Mbps de tráfico BUM en promedio, eso significa 5 Gbps de tráfico multicast constante que consume ancho de banda IPN y CPU en los routers IPN. Este cálculo se pasa por alto con frecuencia. (Número de BDs Extendidos) * (Tráfico BUM promedio por BD) = Carga constante de IPN. Esta carga siempre está presente y debe tenerse en cuenta en su planificación de ancho de banda.

Enfoque de Sizing para Multi-Site

Para Multi-Site, se aprovisiona un servicio L3VPN/EVPN Wave de 200 Gbps (150 Gbps + 33% de margen) de un carrier. El enfoque cambia al dimensionamiento del clúster de Nexus Dashboard. Basado en la guía de dimensionamiento de Cisco NDO 4.2, la gestión de 2 sites, 3000 EPGs y 50 tenants requiere un clúster NDO de 3 nodos donde cada nodo es una máquina virtual con aproximadamente 16 vCPUs, 64 GB de RAM y 1 TB de espacio en disco. Esta es una huella de virtualización no trivial. El costo no está en el cálculo del ancho de banda del plano de datos (que es un costo simple de circuito de carrier) sino en la computación y el licenciamiento de software para NDO y el clúster APIC redundante en el segundo site.

Error Común: Extender L2 Sobre DCI

La capacidad más peligrosa que ofrecen tanto Multi-Pod como Multi-Site es la capacidad de extender un Bridge Domain (Layer 2) entre ubicaciones geográficamente separadas. Aunque técnicamente posible, casi siempre es un error arquitectónico. Extender L2 crea un único dominio de broadcast, lo que significa que una tormenta de broadcast en un site inundará los enlaces DCI/IPN e impactará al otro site (fate-sharing). Complica la resolución de problemas y a menudo sirve como un paliativo para evitar la modernización de aplicaciones legacy que tienen direcciones IP hardcodeadas. Si bien Multi-Site es más elegante en cómo tuneliza el tráfico L2 con VXLAN, el problema fundamental persiste. La mejor práctica en 2026 es mantener los dominios L2 locales a un solo site y usar conectividad enrutada solo L3 entre sites para todo el tráfico. No extienda.

Cuándo NO Usar ACI Multi-Site

A pesar de su superioridad técnica en el aislamiento de fallas, Multi-Site no es una solución universal. Hay escenarios específicos en los que Multi-Pod es la opción más pragmática.

Primero está el costo. Una implementación Multi-Site requiere un clúster APIC completo (al menos 3 nodos) para *cada site*, más un clúster Nexus Dashboard (físico o virtual), más el licenciamiento de software NDO (por ejemplo, N-D-ADV-S-GF). Esto puede duplicar fácilmente el costo del controlador y del software en comparación con un diseño Multi-Pod que utiliza un único clúster APIC. Si sus dos "sites" son simplemente dos pisos en el mismo edificio, el costo de Multi-Site es injustificable.

Segundo está la escala y la latencia. Para una implementación pequeña (por ejemplo, menos de 80 switches leaf en total) en dos ubicaciones metropolitanas con fibra oscura y un RTT inferior a 5 ms, Multi-Pod ofrece un plano de gestión unificado que es más simple de operar que NDO. El riesgo de un único dominio de falla puede ser un compromiso calculado y aceptable para la simplicidad operativa cuando la proximidad física y la baja latencia limitan el potencial de problemas inducidos por la red.

Finalmente, considere las habilidades de su equipo. Multi-Pod es una extensión directa del conocimiento de ACI de single-fabric. Multi-Site, con NDO, plantillas de esquema y la necesidad de gestionar una red inter-site BGP EVPN subyacente, representa un paso significativo en complejidad. Si su equipo no está preparado para ese salto operativo, implementar Multi-Site puede introducir más riesgos de mala configuración de los que resuelve a través del aislamiento de fallas.

En última instancia, la decisión se basa en una evaluación clara del riesgo. Multi-Pod prioriza las operaciones simplificadas dentro de un dominio de falla único y extendido, lo que lo hace adecuado para implementaciones en áreas metropolitanas donde el costo y la simplicidad son primordiales y el riesgo se considera aceptable. Multi-Site prioriza el aislamiento de fallas y la escalabilidad por encima de todo, lo que lo convierte en la elección requerida para redes a gran escala geográficamente dispersas donde la continuidad del negocio no es negociable. Elija la arquitectura que se adapte a su realidad operativa y presupuesto, no solo la que sea técnicamente posible.

En TechLeague, nuestros expertos certificados pueden ayudarlo a modelar el TCO y el impacto operativo de ambas arquitecturas para su entorno específico. Contáctenos para iniciar la conversación. Lea nuestras publicaciones relacionadas sobre diseño de VXLAN EVPN y el ecosistema de Nexus Dashboard para obtener más información.