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.
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.