Cuando empezamos a diseñar la infraestructura de red de CubePath, teníamos una elección. Podíamos hacer lo que hace la mayoría de proveedores: dar a cada región su propia red aislada con MTU 1500 estándar y seguir adelante. Es más barato, es más simple y, siendo honestos, la mayoría de clientes no notarían la diferencia el primer día.

Decidimos ir por otro camino. Invertimos en construir una red privada global con VLANs que abarcan múltiples regiones y MTU 9000 (jumbo frames) en toda la red. Costó más. Llevó más tiempo. Pero abre una categoría de arquitecturas que simplemente no son posibles en una red estándar, y creemos que eso importa.

Este post explica por qué hicimos esa inversión y qué posibilidades abre para los equipos que construyen sobre CubePath.

Por Qué MTU 9000? Porque 1500 Bytes por Paquete Es un Cuello de Botella

Empecemos con la realidad técnica. El MTU por defecto en la mayoría de redes es de 1500 bytes. Ese es el estándar desde que Ethernet se diseñó en los años 80. Cada paquete que tus servidores envían lleva un máximo de 1500 bytes de datos reales, más las cabeceras encima.

Para tráfico web casual, vale. Pero en el momento que empiezas a mover cantidades serias de datos entre servidores, esos paquetes pequeños se convierten en una limitación real.

Coge un backup de base de datos de 1 GB. Con MTU 1500, eso son aproximadamente 700.000 paquetes que hay que ensamblar, enviar, recibir, verificar y confirmar. Cada uno de esos paquetes cuesta ciclos de CPU. Las cabeceras hay que procesarlas, los checksums hay que calcularlos, las interrupciones hay que gestionarlas. Multiplica eso por los cientos de transferencias que ocurren cada hora en una infraestructura ocupada, y estás quemando cómputo real en overhead de red.

Ahora coge la misma transferencia con MTU 9000. Cada paquete lleva 6 veces más datos. Ese backup de 1 GB baja a unos 120.000 paquetes. Menos overhead de CPU, menos interrupciones, mayor throughput. En benchmarks reales, los jumbo frames mejoran el rendimiento de transferencias masivas entre un 15-30%. En cargas de trabajo que constantemente mueven datos entre nodos, como replicación de bases de datos, almacenamiento distribuido o tráfico este-oeste de contenedores, esa diferencia se multiplica a lo largo del día.

Miramos lo que nuestros clientes están construyendo realmente. Clusters de bases de datos con replicación en streaming. Almacenamiento distribuido con Ceph y GlusterFS. Clusters de Kubernetes con cientos de pods hablándose entre sí. Pipelines de big data moviendo resultados intermedios entre nodos. Todas estas son cargas de trabajo donde la eficiencia de red se traduce directamente en rendimiento y coste. Así que tomamos la decisión: MTU 9000 en todas partes, no como un add-on premium, sino como la base.

Por Qué VLANs Multi-Región? Porque las Arquitecturas Reales No Viven en Un Solo Datacenter

La mayoría de proveedores te dan una red privada dentro de una sola región. Tus servidores en España pueden hablar entre ellos de forma privada, y tus servidores en Amsterdam pueden hablar entre ellos de forma privada. Pero si España necesita hablar con Amsterdam? Vas por internet público, montas túneles VPN, o pagas por algún servicio de interconexión.

Eso crea una fricción que empuja a los equipos hacia arquitecturas más simples (y más frágiles). Si conectar dos regiones es un proyecto en sí mismo, la gente lo evita. Ejecutan todo en una región y esperan que nada salga mal. O montan setups de disaster recovery a medias que nunca se han probado realmente porque la capa de red era demasiado dolorosa de configurar.

Queríamos eliminar esa fricción por completo. Las VLANs de CubePath abarcan varias regiones. Tu servidor en España y tu servidor en Amsterdam pueden estar en la misma red privada como si estuvieran en el mismo rack. Sin VPNs, sin túneles, sin configuración especial. Solo servidores que se ven entre sí, con MTU 9000, por una red privada que nunca toca internet público.

Esto no es solo una funcionalidad de conveniencia. Cambia fundamentalmente qué arquitecturas son prácticas de construir.

Qué Hace Posible Esta Red

Esto es lo que se vuelve realista cuando tu red privada es rápida, global y tiene el tamaño de paquete adecuado.

Replicación de Bases de Datos que Realmente No Se Queda Atrás

PostgreSQL streaming replication, MySQL group replication, MongoDB replica sets. Todas dependen de enviar datos desde un primario a una o más réplicas por la red. Cuanto más rápida y eficiente sea esa red, menor será tu lag de replicación.

Con MTU 9000 en una red privada entre regiones, tu réplica en otro datacenter se mantiene cerca del primario incluso bajo cargas de escritura pesadas. Eso significa que tus réplicas de lectura están sirviendo datos frescos, tu objetivo de failover es realmente usable, y tu recuperación point-in-time no tiene un hueco de varios segundos.

¿En una red MTU 1500 estándar yendo por internet público? El lag de replicación se dispara bajo carga, las réplicas se quedan atrás, y cuando realmente necesitas hacer failover, descubres que tu standby va minutos por detrás del primario.

Disaster Recovery en el que Realmente Puedes Confiar

El disaster recovery es una de esas cosas que todo el mundo dice que tiene pero pocos han probado de verdad. Una razón importante es la complejidad de la red. Si enviar backups a otra región implica montar túneles VPN, configurar cifrado, lidiar con costes de ancho de banda y esperar que la transferencia termine antes de que empiece la siguiente ventana de backup, los equipos simplemente... no lo hacen bien.

Cuando tus regiones están conectadas en la misma VLAN con MTU 9000, el disaster recovery se simplifica mucho. Los archivos WAL se envían por la red privada en tiempo real. Los backups nocturnos se transfieren más rápido porque los jumbo frames reducen el overhead. El coste de red es cero porque el tráfico privado es gratis. Y como es fácil de montar, los equipos realmente prueban sus procedimientos de recuperación en vez de asumir que funcionan.

Almacenamiento Distribuido Sin que la Red Sea el Cuello de Botella

Ceph, GlusterFS, NFS, iSCSI. Todos protocolos de almacenamiento que son increíblemente sensibles al rendimiento de red. Un cluster de almacenamiento es solo tan rápido como la red que conecta sus nodos.

MTU 9000 reduce la fragmentación de paquetes y deja que el tráfico de almacenamiento fluya a velocidad cercana al máximo del enlace. Si estás ejecutando un cluster de Ceph entre múltiples servidores, la diferencia entre MTU 1500 y MTU 9000 puede ser la diferencia entre un rendimiento aceptable y cuellos de botella constantes. Lo hemos visto de primera mano con clientes ejecutando almacenamiento distribuido, y es una de las razones por las que apostamos por jumbo frames en toda la red.

Clusters HA Donde el Failover Se Mide en Segundos

Los clusters de alta disponibilidad dependen de comunicación rápida y fiable entre nodos. Los heartbeats tienen que llegar a tiempo. La sincronización de estado tiene que ser rápida. Cuando ocurre un failover, el cluster necesita detectar el fallo y reorganizarse en segundos, no en minutos.

En CubePath, la comunicación del cluster viaja por la red privada. Heartbeats entre nodos Patroni, checks de Redis Sentinel, consenso etcd en Kubernetes, health checks de HAProxy. Todo corre en una red rápida, aislada y con MTU 9000. El resultado es que la detección de fallos es más rápida, la transferencia de estado durante la promoción es más ágil, y tu cluster se recupera antes de que tus usuarios noten que ha pasado algo.

Combina eso con los Load Balancers y las Floating IPs de CubePath y tienes los bloques de construcción para arquitecturas HA que funcionan de verdad en producción. No solo sobre el papel, no solo en un runbook que nadie ha probado, sino en escenarios reales de fallo donde un nodo se cae a las 3 de la mañana y el sistema lo gestiona solo.

Kubernetes con Tráfico Este-Oeste Rápido

Kubernetes genera una cantidad enorme de tráfico de red interno. Pods hablando con otros pods, servicios resolviéndose por DNS del cluster, ingress controllers enrutando a backends. Todo es tráfico este-oeste fluyendo entre nodos.

Cuando ese tráfico corre en una red con MTU 9000, cada comunicación entre pods es más eficiente. Los sidecars de service mesh añaden menos overhead. Los payloads grandes entre microservicios se transfieren más rápido. Y si estás usando un CNI como Cilium o Calico, el rendimiento de la red subyacente impacta directamente en la velocidad de comunicación de tus pods.

Para CubePath Managed Kubernetes, esto significa que la red del cluster rinde mejor de serie. Para setups autogestionados, significa que estás construyendo sobre una red que no te frena cuando tu cluster crece.

Pipelines de Big Data que No Se Atragantan en el Shuffle

Si alguna vez has ejecutado Hadoop, Spark o cualquier framework de procesamiento distribuido, sabes que la fase de shuffle es donde todo se ralentiza. Los nodos intercambian resultados intermedios entre sí, y la velocidad de ese intercambio determina lo rápido que termina tu job.

MTU 9000 reduce el overhead por paquete durante el shuffle, lo que significa que los datos se mueven entre nodos más rápido y tus jobs terminan antes. Para equipos ejecutando cargas de trabajo de analítica regulares o pipelines ETL entre múltiples servidores, esto no es una mejora marginal. Es la diferencia entre un pipeline que termina dentro de tu ventana de batch y uno que no.

La Decisión Detrás de la Inversión

Construir esta red no fue el camino fácil. MTU 9000 requiere soporte end-to-end en cada switch, router y NIC del camino. Las VLANs multi-región requieren interconexiones entre datacenters que la mayoría de proveedores evitan por coste y complejidad. Habría sido más simple y más barato lanzar con networking estándar y centrarnos en otras cosas.

Pero seguíamos llegando a la misma conclusión: la red es la base de todo lo demás. Puedes tener las CPUs más rápidas y el almacenamiento NVMe más potente del mundo, pero si tus servidores no pueden comunicarse de forma eficiente, tu arquitectura tiene un techo.

Replicación de bases de datos, almacenamiento distribuido, clusters HA, networking de contenedores, disaster recovery. Todo esto está limitado por lo buena que sea la red entre tus servidores. Queríamos que CubePath fuera el tipo de infraestructura donde diseñas tu arquitectura basándote en lo que es mejor para tu aplicación, no en lo que la red de tu proveedor puede aguantar.

Por eso lo construimos así. Y por eso seguimos invirtiendo en expandir esta red a medida que añadimos nuevas regiones y capacidad.

Qué Viene Después

Seguimos ampliando nuestra huella de red con nuevas regiones y aumentando la capacidad en las interconexiones existentes. A medida que CubePath Managed Kubernetes crece y los clusters GPU entran en escena, las demandas sobre la red interna solo aumentan, y la inversión en MTU 9000 y VLANs multi-región cobra aún más sentido.

Si estás diseñando una arquitectura que necesita networking interno rápido, replicación entre regiones o alta disponibilidad real, la red de CubePath se construyó exactamente para eso.