Arquitectando el Futuro: Diseño de red VCF 9 y el fin del L2 legado

VMware Cloud Foundation (VCF) 9 ya no es una opción, es una directriz. En el panorama post-Broadcom, la era de "elegir y combinar" licencias individuales de vSphere o vSAN ha terminado, reemplazada por un mandato monolítico de pila completa que obliga a los ingenieros de red a tratar el data center como una única entidad programable. Si todavía intenta diseñar su infraestructura física con VLANs artesanales y extensiones L2 legadas, no solo está desactualizado; está diseñando un punto de fallo que colapsará bajo el peso de la integración obligatoria de NSX y vSAN ESA de VCF 9.

La realidad post-Broadcom: VCF 9 como el piso estratégico

La transición a VCF 9 representa un cambio fundamental en la forma en que abordamos el SDDC (Software-Defined Data Center). Anteriormente, NSX a menudo se trataba como una "opción de overlay" para empresas avanzadas. En VCF 9, NSX es el motor, la transmisión y el panel de control. Broadcom ha simplificado las licencias hasta el punto en que el delta de costo entre solo vSphere y VCF está diseñado para forzar la migración. Para el ingeniero de red, esto significa que el underlay físico debe volverse invisible, robusto y puramente L3.

Estamos ante una filosofía de diseño donde la red está definida por VCF Services en lugar de interfaces de hardware. Con la deprecación de vSAN legacy (Original Storage Architecture - OSA) en favor de Express Storage Architecture (ESA), los requisitos de red se han disparado. Si no está implementando 25GbE como su punto de entrada mínimo absoluto —siendo 100GbE el estándar para los clusters VCF 9—, está privando a la ESA basada en NVMe del rendimiento que requiere para alcanzar su potencial de IOPS.

NSX-T está muerto, larga vida a NSX Project Antrea y las VPCs

En VCF 9, los constructos de red han evolucionado. Estamos viendo un fuerte impulso hacia el modelo de NSX Virtual Private Cloud (VPC). Esto no es solo una nomenclatura de marketing; es un cambio estructural en cómo se maneja la multi-tenancy. En lugar de un complejo anidamiento de Tier-0/Tier-1 con el que los ingenieros luchaban por visualizar, VCF 9 trata cada tenant o límite de aplicación como una VPC, abstraiendo el router T1 en un modelo de consumo de autoservicio.

Desde una perspectiva de diseño, esto requiere un replanteamiento de Edge Cluster. En versiones anteriores, podríamos haber salido airosos con pequeños Edge VMs. En VCF 9, especialmente cuando se admite tráfico vSAN ESA de alto rendimiento y failover multi-AZ, sus Edge Nodes deben tener un tamaño "Large" o "X-Large" para manejar los requisitos de DPDK (Data Plane Development Kit). Para un cluster de gestión estándar de 4 nodos, recomendamos un mínimo de dos Edge Nodes con capacidad de 100GbE para evitar que el límite norte-sur se convierta en un cuello de botella.

El Underlay de VCF 9: L3 Fabric o nada

Si todavía está ejecutando MLAG/VPC (Virtual Port Channels) en sus hosts ESXi para cualquier cosa que no sea el arranque PXE inicial o la gestión OOB, está creando una deuda de complejidad que no podrá pagar. VCF 9 prospera en una arquitectura leaf-spine solo L3. Abogamos por un modelo de BGP-to-the-Host utilizando el modelo federado de NSX o, al menos, EBGP entre sus Tier-0 Gateways y sus switches Top-of-Rack (ToR).

Considere una implementación típica de VCF 9 con nodos Dell VxRail o HPE Synergy. Su configuración física debería verse así:

! Sample Leaf Switch BGP Configuration (Arista EOS style)
router bgp 65001
   router-id 10.0.0.1
   maximum-paths 64
   neighbor VCF_EDGE_PEERS peer-group
   neighbor VCF_EDGE_PEERS remote-as 65002
   neighbor VCF_EDGE_PEERS bfd
   neighbor 10.1.1.2 peer-group VCF_EDGE_PEERS
   neighbor 10.1.1.3 peer-group VCF_EDGE_PEERS
   redistribute connected
! Ensure MTU 9000 is set everywhere for vSAN ESA and Geneve Overlays

Sin un MTU de 9000 (Jumbo Frames) de extremo a extremo, la encapsulación Geneve en NSX se fragmentará, lo que provocará una pérdida de rendimiento del 30-40%. En VCF 9, esto no es solo una "recomendación"—es obligatorio para los chequeos de salud de vSAN ESA.

vSAN ESA: La red es el Backplane

La dependencia de VCF 9 en vSAN ESA cambia las matemáticas del rendimiento. A diferencia del antiguo modelo de grupos de discos, ESA utiliza una arquitectura de una sola capa donde cada disco es un disco de rendimiento. Esto crea ráfagas masivas de tráfico East-West durante eventos de resincronización. Ya no estamos diseñando para picos de 10Gbps. Estamos diseñando para cargas sostenidas de 40-60Gbps durante un fallo de nodo.

Para soportar esto, su diseño de red VCF 9 debe priorizar el Network Partitioning. Aunque estemos utilizando un N-VDS (NSX Virtual Distributed Switch) colapsado en los hosts, debe usar NIOC (Network I/O Control) para garantizar el ancho de banda para el tráfico de sistema vSAN. No priorizar adecuadamente el tráfico de vSAN sobre vMotion o tráfico de Overlay resultará en timeouts de SCSI y escenarios de "All Paths Down" (APD) cuando la red se congestione.

Diseño Multi-AZ y Federación Regional

Un pilar fundamental de VCF 9 es la arquitectura Multi-Availability Zone (Multi-AZ) simplificada. Broadcom ha optimizado la implementación de clusters extendidos, pero los requisitos de red subyacentes siguen siendo estrictos. Para un cluster extendido de VCF 9, necesita:

• < 5ms de Round Trip Time (RTT) para los planos de gestión y de carga de trabajo.
• < 1ms de RTT para el tráfico extendido de vSAN ESA (este es el límite estricto).
• Un mínimo de 10Gbps de ancho de banda dedicado entre sitios para el tráfico de witness y la replicación.

En VCF 9, nos alejamos de las VLANs extendidas L2 a nivel físico. En su lugar, utilizamos NSX Federation para extender segmentos entre sitios. Esto permite una optimización de entrada/salida local (utilizando BGP local preference) para que el tráfico no "haga hairpin" de vuelta al sitio principal si una VM se ha movido a la AZ secundaria. Si no ha leído nuestra inmersión profunda en arquitecturas de NSX Federation, necesita revisar cómo Global Manager maneja los fallos de sitio antes de comprometerse con un despliegue de VCF 9.

Seguridad: Identity-Based Distributed Firewalling (IDFW)

La seguridad en VCF 9 no se trata solo de micro-segmentación; se trata de la integración del Distributed Firewall (DFW) con proveedores de identidad modernos. El framework de cumplimiento de VCF 9 exige que todo el tráfico de gestión esté aislado utilizando reglas DFW de NSX desde el momento de la puesta en marcha. Ya no utilizará firewalls de hardware para el tráfico East-West entre VMs de gestión. La sobrecarga de enviar el tráfico a un appliance físico de Palo Alto o FortiGate es inaceptable en un entorno VCF 9 de alta densidad.

En su lugar, aproveche el NSX Distributed IDS/IPS. Con VCF 9, estas firmas se actualizan automáticamente a través de la Broadcom Cloud, permitiendo que la red reaccione a las amenazas de movimiento lateral en tiempo real sin cambiar una sola etiqueta de VLAN o regla de firewall. Esta es la arquitectura "Zero-Trust" que los proyectos han prometido durante una década, finalmente realizada a través del motor de automatización de VCF 9.

El costo de la ignorancia: Licencias y alineación de hardware

Hablemos de números. Una licencia de VCF 9 es cara, a menudo 2-3 veces el costo del legacy vSphere Enterprise Plus por core (con un mínimo de 16 cores). Si implementa este software en una red antigua de 10GbE, en la práctica está pagando un "impuesto de estupidez". Está pagando por software de alto rendimiento que está siendo estrangulado por switches Top-of-Rack de $500.

Para obtener el ROI de una inversión en VCF 9, el hardware debe alinearse. Esto significa CPUs Intel Ice Lake o Sapphire Rapids, al menos 1TB de RAM por nodo y NICs Mellanox ConnectX-6 o superiores. Estas NICs soportan Uptane/Hardware Offloads que son críticos para el rendimiento de NSX. Sin la descarga de hardware (hardware offloading), la CPU del host gastará del 20 al 30% de sus ciclos solo procesando paquetes de encapsulación Geneve, robando el índice de consolidación de sus VMs.

Conclusión

El diseño de red de VCF 9 es un ejercicio de simplificación despiadada de la capa física para permitir una complejidad y agilidad extremas en la capa virtual. Los días del trunking manual y el ajuste de Spanning Tree han terminado. Su trabajo ahora es proporcionar una "tubería oscura" L3 sólida como una roca que permita a NSX y vSAN ESA hacer lo que fueron creados para hacer: proporcionar una plataforma cloud de alto rendimiento, auto-reparable y segura.

En TechLeague, nos especializamos en ayudar a las organizaciones a navegar estas migraciones de alto riesgo. Ya sea que esté luchando con la transición a las VPCs de NSX o necesite re-arquitecturar su fabric para vSAN ESA, proporcionamos la experiencia de ingeniería de alto nivel que la documentación de Broadcom omite. Explore nuestros paquetes de consultoría y capacitación personalizados para asegurarse de que su viaje con VCF 9 no termine en un cuello de botella de rendimiento.