Optimización Jumbo Frames en ESXi y NAS: MTU 9000 para Estabilidad en Producción

Jumbo Frames en ESXi con comprobación vmking

Optimización Jumbo Frames en ESXi y NAS: MTU 9000 para Estabilidad en Producción

CONTENIDO LEGADO

Este artículo forma parte de la bitácora histórica de Sys Adventures (originada en 2019)

La información o visión técnica aquí descrita puede no reflejar los estándares actuales del sitio. Úsalo como referencia, pero siempre valida bajo tu propia responsabilidad.

En entornos de misión crítica en México, donde el cumplimiento normativo exige una disponibilidad impecable, la red no puede ser el eslabón débil. Configurar Jumbo Frames en ESXi no es un lujo decorativo; es una decisión de ingeniería de infraestructura diseñada para obtener esa paz mental que solo da un almacenamiento estable y veloz.

¿Qué son los Jumbo Frames y por qué importan?

Toda información en la red viaja en paquetes llamados frames. El tamaño estándar (MTU) es de 1500 bytes. Cualquier valor superior es un Jumbo Frame.

En arquitecturas modernas de 10 Gbps o superiores, usar un MTU de 9000 reduce drásticamente la fragmentación de datos y el consumo de CPU. Es la diferencia entre transportar arena en cubetas o hacerlo en un camión de volteo: menos viajes, más eficiencia.

Standard Frame 1500 vs Jumbo Frames 9000
Standard Frame MTU 1500 vs Jumbo Frames MTU 9000

Si quieren obtener más detalles sobre esta función, les recomiendo hacer una búsqueda rápida y leer hasta que su sed de conocimiento sea saciada.

Escenarios Críticos: ¿Cuándo implementarlos?

Para un SysAdmin en la trinchera, los Jumbo Frames son obligatorios en:

  • Almacenamiento iSCSI/NFS: Para evitar latencia en la data de tus VMs.
  • vMotion: Para que las migraciones en vivo no tarden una eternidad.
  • Bases de Datos en RAC: Donde la interconectividad es el corazón del servicio.
  • Respaldos Masivos: Crucial para cumplir con los tiempos de recuperación (RTO) locales.

Jumbo Frames en ESXi y NAS

Para este artículo usaremos de ejemplo un ambiente de virtualización incorporado por lo siguiente:

Dispositivo S.O. Puertos Hostname IP
Switch Capa 2 10 Gbps SWMC2
Servidor VMware ESXi Uno a 10 Gbps Nodo1 192.168.0.2
Servidor VMware ESXi Uno a 10 Gbps Nodo2 192.168.0.3
Storage NAS Dos a 10 Gbps SNAS10 192.168.0.4

192.168.0.5

Nuestro objetivo será mejorar la comunicación entre los servidores ESXi y el Storage NAS debido a que en esa comunicación viajan paquetes de gran tamaño (La data de los discos virtuales de cada VM)

[PASO] Configuración de punta a punta (End-to-End)

La configuración debe ser simétrica. Si un solo punto en el camino (Switch, NIC, Storage) no soporta MTU 9000, los paquetes se fragmentarán o se perderán.

Dispositivo S.O. Interfaz MTU Sugerido
Switch Capa 2 OS Propietario 10 Gbps Trunk/Access 9216
Servidor Nodo 1 VMware ESXi vmk (VMkernel) 9000
Storage NAS Storage OS Bond/LACP 9000

En el switch siempre configuramos un poco más (9216) para dar margen a los encabezados de capa 2 y evitar el descarte de paquetes.

Para configurar en ESXi puedes consultar este artículo Enable Jumbo Frames for a VMkernel Adapter

[SOLUCIÓN] Cómo validar la comunicación real

La prueba es tan sencilla como hacer uso del comando ping, sólo se tiene que agregar algunos parámetros para especificar que se usa paquetes de mayor tamaño.

Hablando técnicamente: lo que se hace es definir el tamaño de la carga ICMP; tomando en cuenta que ICMP usa 8 bytes para su encabezado y 20 bytes para su encabezado IP.

Mtu Size
9000 (MTU size) – 8 (ICMP header) – 20 (IP header) = 8972 bytes for ICMP payload

En base a lo anterior (y suponiendo que ingresas a los servidores ESXi mediante SSH) hacemos la prueba con el comando vmkping (El equivalente de ping para los ESXi)

Respuesta satisfactoria

# vmkping -s 8972 -d 192.168.0.2

PING 192.168.0.2 (192.168.0.2): 8972 data bytes
8980 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=0.446 ms
8980 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=0.479 ms
8980 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=0.477 ms
# vmkping -s 8972 -d 192.168.0.4

PING 192.168.0.4 (192.168.0.2): 8972 data bytes
8980 bytes from 192.168.0.4: icmp_seq=0 ttl=64 time=0.446 ms
8980 bytes from 192.168.0.4: icmp_seq=0 ttl=64 time=0.479 ms
8980 bytes from 192.168.0.4: icmp_seq=0 ttl=64 time=0.477 ms

Error de comunicación

La siguiente respuesta se puede dar si algún puerto no está conectado correctamente o hace falta alguna otra configuración que impide la comunicación.

PING xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx): 8184 data bytes
Request timeout for icmp_seq 0

Prueba en Linux, MacOS y Windows (PowerShell)

La siguiente respuesta se puede dar si el MTU no está configurado en alguno de los puntos de comunicación

PING xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx): 8184 data bytes
ping: sendto: Message too long

Como extra, en otros sistemas operativos la sintaxis del comando ping es la siguiente:

MacOS

# ping -D -s 8184 [IP]

Windows

# ping -f -l 9000 [IP]

Linux

# ping -M do -s 8972 [IP]

Conclusiones

Optimizar con Jumbo Frames es como abrir la llave de una tubería al máximo. Sin esto, en cargas de trabajo pesadas, enfrentarás desconexiones de storage, lentitud general y, en el peor de los casos, caídas del servicio en horas pico.

Referencias

Share this post

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *