Una LUN de iSCSI es, en la práctica, un disco lógico expuesto por red para que un servidor, una VM o un hipervisor lo vea como almacenamiento bloque. En este artículo explico qué es exactamente, cómo encaja en una arquitectura de red, qué necesitas para que funcione con estabilidad y qué errores suelen impedir que el disco aparezca o rinda como debe. También verás cuándo conviene iSCSI y cuándo otra opción te simplifica la vida.
Lo esencial para entender una LUN de iSCSI sin perderte en la jerga
- Una LUN de iSCSI es almacenamiento bloque presentado por un target a un host a través de TCP/IP.
- El servidor no recibe una carpeta compartida: ve un disco local que luego inicializa, particiona y formatea.
- El acceso correcto depende de tres piezas: iniciador, target y mapeo de permisos.
- Si quieres continuidad y menos interrupciones, necesitas multipath o MPIO y una red bien separada.
- CHAP ayuda a autenticar, pero no sustituye el aislamiento de red ni el control de accesos.
- Cuando solo necesitas archivos compartidos, NFS o SMB suelen ser más simples que iSCSI.
Qué es una LUN de iSCSI y qué papel cumple
Yo suelo explicarlo de forma muy directa: una LUN es la unidad lógica que la cabina, el servidor de almacenamiento o el appliance presenta al host. El acrónimo LUN viene de Logical Unit Number, pero en la conversación técnica diaria importa más su función que el nombre completo: representa el disco que el sistema operativo va a consumir como bloque.
La diferencia con un volumen o una carpeta compartida es importante. El volumen vive dentro del almacenamiento; la LUN es la interfaz que ese almacenamiento expone al exterior. Por eso un servidor no “entra” a una LUN como quien abre una carpeta, sino que la descubre, la inicializa y después crea encima el sistema de archivos que necesite.
En entornos SAN, el acceso no se deja abierto a cualquiera. La cabina suele usar grupos de iniciadores para decidir qué hosts ven qué LUNs, y ese control evita que dos servidores se pisen entre sí. Si te saltas esa parte, el problema no es solo de seguridad: también puedes provocar conflictos de firma de disco, rutas duplicadas o volúmenes visibles donde no deberían estar. Con esa base clara, lo siguiente es entender el camino que sigue el tráfico hasta llegar al disco.
Cómo viaja el acceso desde el iniciador hasta el disco
El flujo de iSCSI es bastante más simple de lo que parece cuando se descompone. El iniciador es el cliente, normalmente un servidor físico, una VM o un hipervisor con soporte iSCSI. El target es el sistema de almacenamiento que publica una o varias LUNs. Entre ambos viajan comandos SCSI encapsulados sobre TCP/IP, normalmente por el puerto 3260.
Primero se descubre el target, casi siempre por dirección IP o por un portal de descubrimiento. Después el host autentica, si está configurado, mediante CHAP, un mecanismo que añade credenciales a la sesión. Cuando el target acepta al iniciador y el mapeo es correcto, el sistema operativo muestra el LUN como un disco nuevo. A partir de ahí ya depende de ti: inicializarlo, crear particiones y montar el volumen donde corresponda.
La pieza que suele marcar la diferencia en producción es el multipath o MPIO, es decir, la capacidad de tener varias rutas hacia la misma LUN. Si una interfaz, un switch o una NIC falla, el host puede seguir trabajando por otra vía. En arrays modernos también aparece la idea de ruta activa y optimizada, que prioriza el camino más eficiente para el I/O. Yo no daría una LUN por bien diseñada si solo tiene un camino real hacia el almacenamiento.
Cuando entiendes ese recorrido, ya puedes decidir con bastante más criterio si iSCSI encaja o si te conviene otro tipo de acceso al almacenamiento.
Cuándo merece la pena usarla y cuándo elegir otra cosa
iSCSI brilla cuando necesitas almacenamiento bloque sobre red Ethernet. Eso lo hace muy útil para hipervisores, servidores de bases de datos, entornos de virtualización, laboratorios y sistemas donde quieres que el host trate el recurso como un disco real. También encaja bien cuando prefieres aprovechar infraestructura IP ya existente en lugar de montar una SAN Fibre Channel dedicada.
No es la mejor elección si lo que buscas es simplemente compartir archivos. En ese caso, NFS o SMB suelen ser más limpios, más rápidos de desplegar y más fáciles de operar. Yo solo empujo iSCSI cuando hay una razón clara para trabajar a nivel bloque: rendimiento predecible, compatibilidad con un hipervisor, o necesidad de aislar el almacenamiento de la capa de archivos.
| Opción | Qué expone | Cuándo la prefiero | Su punto débil |
|---|---|---|---|
| iSCSI | Disco bloque | VMs, bases de datos, discos dedicados, SAN sobre Ethernet | Exige red y control de rutas bien planteados |
| NFS | Archivos | Datastores y compartición sencilla en entornos Linux y virtualización | No se comporta como un disco local |
| SMB | Archivos | Compartición en entornos Windows y colaboración de ficheros | No encaja tan bien en cargas SAN puras |
| Fibre Channel | Disco bloque | Latencia muy controlada y SAN dedicada | Mayor coste y complejidad operativa |
Mi lectura práctica es esta: si necesitas un disco remoto, iSCSI es una opción sólida; si necesitas una carpeta, estás añadiendo complejidad innecesaria. Y precisamente por eso la red importa tanto, porque el rendimiento y la estabilidad dependen de cómo la diseñes.
Cómo la montaría en la red para que funcione de verdad
La primera decisión es separar el tráfico de almacenamiento del tráfico general. Una VLAN dedicada, o incluso una red física separada, reduce el ruido, hace más predecible la latencia y simplifica la resolución de problemas. Yo evitaría mezclar iSCSI con navegación, backup masivo o tráfico de usuarios si el entorno tiene cualquier exigencia seria de rendimiento.
La segunda decisión es la coherencia. Si activas MTU 9000 en una parte de la cadena, tiene que estar activado de extremo a extremo: host, switch, target y cualquier salto intermedio. Si no puedes garantizarlo, es más sensato trabajar con MTU 1500 bien afinada que con jumbo frames a medias, porque el fallo intermitente es peor que una configuración conservadora.
Después viene el acceso. En despliegues serios yo usaría al menos una interfaz de almacenamiento por nodo y, cuando la continuidad de servicio importa, dos rutas independientes. Eso no significa solo dos cables; significa dos caminos que realmente no compartan el mismo punto de fallo. Si la cabina lo soporta, el mapeo selectivo de LUNs también ayuda a reducir la cantidad de rutas expuestas al host y a mantener el acceso más limpio.
Por último, no confiaría solo en la red. CHAP añade autenticación, pero no reemplaza el masking de la LUN ni la segmentación. Y si el objetivo es un entorno virtualizado o una base de datos, merece la pena revisar también el rendimiento de las NIC, la compatibilidad del driver y si el sistema operativo está usando multipath de verdad, no solo viendo un disco por casualidad. Con eso sobre la mesa, los problemas más típicos suelen volverse bastante reconocibles.
Los fallos que más dejan el disco invisible
Cuando una LUN no aparece, la causa rara vez es misteriosa. Yo empiezo siempre por la ruta básica: conectividad TCP/IP, mapeo correcto y compatibilidad del host. Luego miro autenticación, rutas múltiples y, por último, el sistema operativo. Esa secuencia ahorra mucho tiempo porque evita saltar demasiado pronto a conclusiones sobre la cabina.
| Síntoma | Causa probable | Qué revisaría primero |
|---|---|---|
| El target responde, pero el disco no aparece | La LUN no está mapeada al grupo correcto o el ID no cuadra | Grupos de iniciadores, permisos y número de LUN asignado |
| La LUN aparece pero el sistema no la usa | El disco está sin inicializar, offline o con conflicto de firma | Administrador de discos, particiones y estado del dispositivo |
| La sesión cae a ratos | Un solo camino real, MPIO mal configurado o problema de red | Rutas activas, switches, NICs, MTU y errores de enlace |
| El rendimiento es pobre | Latencia de red, saturación, falta de multipath o una red compartida | Uso de ancho de banda, colas, retransmisiones y latencia |
| La autenticación falla | CHAP desalineado o credenciales erróneas | Usuario, secreto compartido y configuración del target |
Hay dos comprobaciones que nunca me salto: que exista conectividad real entre host y storage, y que el host tenga permisos sobre la LUN. Si esas dos cosas están bien, el resto suele ser bastante más fácil de acotar. Y cuando ya funciona, lo interesante es saber si de verdad has elegido la tecnología adecuada, no solo si ha arrancado.
La lista corta que yo revisaría antes de darla por lista
Si estuviera validando una implantación para producción, haría esta verificación mínima antes de pasarla por buena:
- La LUN está mapeada al grupo de iniciadores correcto y con un identificador único.
- El host descubre el target por la red prevista y no por una ruta accidental.
- Si hay CHAP, la autenticación coincide exactamente en ambos extremos.
- El multipath está activo y el sistema ve más de una ruta útil.
- La VLAN, el MTU y los drivers están alineados en toda la cadena.
- El disco se inicializa y formatea solo después de confirmar que no hay conflictos de firma ni de visibilidad.
- Hay monitorización de latencia, pérdida de paquetes y estado de enlace.
La regla que más me gusta aplicar aquí es simple: si la red falla, la LUN falla. Por eso una buena implementación de iSCSI no se parece tanto a “montar un disco” como a diseñar una pequeña red de almacenamiento con disciplina. Cuando se hace bien, funciona de forma muy limpia; cuando se improvisa, los problemas suelen aparecer justo donde más molestan, en el arranque, en el failover o en el pico de carga.
