iSCSI tiene un gancho irresistible: almacenamiento compartido por bloques usando redes Ethernet estándar, sin fibra ni hardware exótico. Ese "usa lo que ya tienes" es también su trampa, porque invita a montarlo a la ligera. Bien hecho es sólido y económico; mal hecho es una fuente inagotable de latencia y caídas difíciles de rastrear.
Qué hace falta para hacerlo bien
- Red dedicada: el tráfico iSCSI va por su propia red o VLAN, aislado del tráfico de producción. El almacenamiento es sensible a la latencia y no debe competir con el correo y las descargas.
- MPIO (Multipath I/O): varios caminos de red hacia el almacenamiento, para redundancia y rendimiento. No un solo cable que es punto único de falla y cuello de botella.
- MTU con criterio: los jumbo frames ayudan, pero solo si están configurados de forma consistente de extremo a extremo. A medias, hacen más daño que bien.
Los errores que vemos en campo
Casi siempre los mismos: iSCSI corriendo sobre la LAN de producción "porque funcionaba en la prueba"; un único enlace sin MPIO que el día que falla se lleva el almacenamiento entero; y MTU inconsistente que provoca lentitud intermitente que nadie logra explicar. Ninguno se ve el primer día; todos aparecen bajo carga o el día de una falla —y para entonces el diagnóstico es una pesadilla.
El punto de fondo
iSCSI no es plug-and-play: el diseño de red manda. Es una alternativa válida a una SAN dedicada —parte de la misma familia de decisiones de almacenamiento compartido— siempre que se monte con el respeto que el tráfico de bloques exige. Con marcas como Synology y Dell del lado del almacenamiento, el reto no es el equipo: es la red.
Funcionaba en la prueba
Un caso de campo de manual. Se montó iSCSI para dar almacenamiento a un par de hosts de virtualización, y como en la prueba de laboratorio "funcionó perfecto", se dejó corriendo sobre la misma LAN de producción y con un solo enlace de red. Durante semanas, sin problemas. El primer golpe llegó en un cierre de mes: al saturarse la red con el tráfico normal de la oficina, la latencia del almacenamiento se disparo y las máquinas virtuales se congelaron intermitentemente —un problema que nadie lograba explicar porque "no habíamos cambiado nada"—. El segundo golpe fue peor: el único puerto de switch por el que viajaba todo el iSCSI falló, y con él se cayó el almacenamiento entero de golpe, sin camino alterno. La corrección fue la que debió existir desde el diseño: una VLAN dedicada solo para el tráfico de bloques, aislada de la producción, y doble camino con MPIO para que la caída de un enlace no se llevara nada. iSCSI no falló por ser iSCSI; falló porque se trató una decisión de red seria como un plug-and-play.
La pregunta que conviene hacerse
La pregunta no es "¿tengo iSCSI funcionando?", sino ¿está en su propia red, con múltiples caminos (MPIO) y MTU consistente —o funciona hoy y me va a fallar bajo carga? Diseñarlo así es parte de nuestros servidores de alto rendimiento.
Preguntas frecuentes
help ¿Se puede correr iSCSI sobre la misma red de producción?
Se puede, pero no se debe en un entorno serio. El tráfico de almacenamiento es sensible a la latencia y compite mal con el tráfico normal; mezclarlos provoca lentitud errática y errores difíciles de diagnosticar. Lo correcto es una red o VLAN dedicada y aislada para iSCSI.
help ¿Qué es MPIO y por qué importa en iSCSI?
MPIO (Multipath I/O) permite que un host acceda al almacenamiento por varios caminos de red a la vez, dando redundancia (si un enlace cae, el otro sigue) y mejor rendimiento. Sin MPIO, un solo enlace es punto único de falla y cuello de botella. Es una de las piezas que más se omiten al montar iSCSI.
help ¿Los jumbo frames mejoran iSCSI?
Pueden ayudar al rendimiento, pero solo si se configuran de forma consistente en toda la ruta (host, switches y almacenamiento). Un MTU mal configurado —jumbo frames a medias— causa problemas peores que no usarlos. Es una optimización con criterio, no un interruptor mágico.
Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.
Ver perfil y todos sus artículos →