iSCSI es una forma de llevar almacenamiento en bloque por red usando TCP/IP, y por eso aparece tanto cuando un servidor necesita ver un disco remoto como si estuviera conectado localmente. Entender qué es iSCSI ayuda a decidir si encaja en un entorno de virtualización, en una cabina compartida o en una red de empresa donde la estabilidad importa tanto como la capacidad. En este artículo te explico la idea técnica, cómo funciona de verdad y qué debes vigilar para no convertir una buena solución en un cuello de botella.
Lo esencial sobre iSCSI en una lectura rápida
- iSCSI transporta comandos SCSI sobre TCP/IP, así que aprovecha redes Ethernet normales en lugar de una SAN dedicada de Fibre Channel.
- El servidor cliente se llama initiator y el sistema de almacenamiento se llama target; entre ambos se presentan volúmenes lógicos, no carpetas.
- El puerto por defecto es el 3260, y la red debe estar bien segmentada si quieres rendimiento y menos problemas.
- CHAP aporta autenticación, pero la fiabilidad real suele depender de multipathing, una red limpia y una buena configuración de arranque.
- No es la mejor opción para todo: brilla en almacenamiento compartido y virtualización, pero pierde sentido si la red es inestable o si solo necesitas compartir archivos.
Por qué iSCSI sigue teniendo sentido en una red moderna
La razón de fondo es simple: iSCSI permite que un sistema operativo trabaje con un disco remoto como si fuese local. Eso cambia mucho la conversación, porque ya no hablamos de compartir archivos, sino de presentar bloques de almacenamiento a un servidor, una máquina virtual o un clúster. Cuando yo evalúo esta tecnología, la primera pregunta no es si es “vieja” o “nueva”, sino si resuelve mejor el problema que tienes delante.
En entornos pequeños y medianos, iSCSI suele ganar por pragmatismo. Aprovecha la infraestructura Ethernet que ya existe, evita montar una red SAN especializada y, aun así, permite centralizar volúmenes, hacer copias más ordenadas o alimentar hosts de virtualización con almacenamiento compartido. También encaja bien cuando conviven Windows, Linux y otros sistemas que necesitan acceso a un mismo backend sin entrar en guerras de formatos o permisos de fichero.
Su límite también conviene decirlo pronto: iSCSI no sustituye a un servidor de archivos. Si lo que buscas es colaborar con documentos, NFS o SMB encajan mejor; si buscas exponer un bloque de disco para que otro sistema lo formatee y lo gestione, iSCSI sí está en su terreno. Esa diferencia parece menor, pero es la que separa una arquitectura limpia de una configuración confusa. Y precisamente por eso conviene ver ahora qué pasa dentro de una conexión iSCSI.
Cómo funciona por dentro
La mecánica interna es bastante elegante. El initiator es el cliente que inicia la sesión; el target es el sistema que ofrece el almacenamiento; y la unidad que se presenta al sistema como disco se expone a través de uno o varios LUN, que son unidades lógicas. Para que todo eso tenga sentido en una red, también aparece el IQN (iSCSI Qualified Name), que es el nombre persistente que identifica a cada nodo.
La conexión típica sigue esta secuencia:
- El initiator localiza el target, ya sea por configuración estática o por un mecanismo de descubrimiento.
- Abre una conexión TCP hacia el puerto iSCSI, que por defecto es el 3260.
- Negocia la sesión y, si está habilitado, autentica con CHAP.
- Recibe el LUN y el sistema operativo lo ve como un dispositivo de bloque más.
Eso tiene una consecuencia práctica importante: el sistema no ve “una carpeta en red”, sino un disco. Por eso puedes crear particiones, sistemas de archivos, volúmenes lógicos o incluso montar el almacenamiento para una base de datos o un hipervisor. También explica por qué iSCSI exige más cuidado que un recurso compartido normal: si la red cae, el disco no desaparece solo de forma estética, sino que el host puede notar errores de I/O.
La autenticación merece un matiz. CHAP ayuda a evitar accesos no deseados, pero no arregla por sí sola una red mal diseñada. Yo lo veo como una puerta con cerradura; útil, sí, pero inútil si el edificio no tiene control de accesos ni vigilancia básica. Con esto claro, la pregunta útil es cuándo merece la pena elegirlo.Cuándo compensa usarlo y cuándo no
iSCSI brilla cuando necesitas almacenamiento compartido con una infraestructura relativamente simple. Si tienes virtualización, laboratorios, servidores que arrancan desde red o un pequeño entorno de almacenamiento centralizado, suele ser una decisión sensata. También puede ser interesante cuando el presupuesto no justifica una SAN Fibre Channel, pero sí necesitas algo más serio que discos locales repartidos por varios equipos.
En cambio, hay escenarios donde yo sería prudente. Si la red tiene mucha latencia, si el tráfico compite con usuarios, copias y videoconferencias, o si no puedes garantizar cierta redundancia, el resultado suele ser decepcionante. iSCSI no hace milagros: solo traslada la carga al transporte IP, así que hereda todas las debilidades de esa red.
| Escenario | Encaja bien | Motivo |
|---|---|---|
| Virtualización con almacenamiento compartido | Sí | Los hosts necesitan bloques de disco centralizados y una red bien controlada |
| Servidor de archivos para usuarios | No es la primera opción | Normalmente resulta más natural compartir archivos que exponer bloques |
| Backups y repositorios de copia | Sí, con red estable | Funciona bien si el ancho de banda y la latencia están bajo control |
| Uso a través de Internet | Solo con mucho cuidado | La latencia, la seguridad y la recuperación de sesiones complican bastante el diseño |
| Laboratorio o pequeño CPD | Sí | Aprovecha Ethernet existente sin montar una infraestructura especial |
La idea práctica es esta: si el almacenamiento centralizado te aporta orden, consolidación y continuidad, iSCSI tiene sentido; si solo te añade complejidad, probablemente estás forzando la herramienta. Para decidir sin ruido, merece la pena compararlo con alternativas que suelen aparecer en la misma conversación.
iSCSI frente a NFS y Fibre Channel
Esta comparación ayuda mucho porque, en la práctica, iSCSI rara vez compite solo. Lo normal es que lo pongas frente a NFS, si estás pensando en compartir datos, o frente a Fibre Channel, si estás pensando en una SAN más clásica. Yo suelo resumirlo así: iSCSI es la vía intermedia pragmática, NFS es más natural para archivos y Fibre Channel es más especializado y costoso.
| Tecnología | Tipo de acceso | Ventaja principal | Punto débil | Cuándo la elegiría |
|---|---|---|---|---|
| iSCSI | Bloques | Aprovecha Ethernet y presenta discos remotos al sistema operativo | Depende mucho de la calidad de la red | Virtualización, SAN pequeña o mediana, almacenamiento compartido por IP |
| NFS | Archivos | Es más natural para compartir ficheros entre sistemas | No expone bloques, sino un sistema de archivos | Repositorios, datos compartidos y colaboración de archivos |
| Fibre Channel | Bloques | Muy consolidado en entornos de alta exigencia | Más complejo y más caro de desplegar | CPD con requisitos altos de rendimiento y segmentación específica |
Si te importa reutilizar red Ethernet y mantener una arquitectura razonable, iSCSI suele ser la respuesta más equilibrada. Si lo que necesitas es intercambio de archivos, no le pidas lo que no está pensado para hacer. Y si tu entorno exige aislamiento extremo y ya vive en la lógica SAN, Fibre Channel puede seguir teniendo sentido. Elegir bien la tecnología sirve de poco si la red está mal afinada.
Qué hay que ajustar para que rinda y no dé problemas
La parte que más diferencia marca no suele ser el protocolo, sino la configuración. Yo revisaría estas piezas antes de considerar un despliegue iSCSI como serio:
- Red separada o bien segmentada: si puedes dedicar una VLAN o, mejor aún, una red física de almacenamiento, reduces interferencias con el tráfico de usuarios.
- Puerto y firewall: el estándar usa el puerto 3260, así que no tiene mucho sentido dejarlo abierto más de la cuenta.
- Multipathing o MPIO: con varias rutas, si una interfaz, un cable o un switch falla, el almacenamiento sigue disponible por otro camino.
- MTU coherente: si usas Jumbo Frames, todo el trayecto debe compartir la misma configuración; mezclar tamaños de trama suele acabar en dolores de cabeza.
- Autenticación: CHAP es una medida útil cuando quieres controlar quién entra, pero no sustituye una segmentación de red seria.
- Persistencia tras reinicio: las sesiones deben volver solas; si dependes de un arranque manual, el sistema queda demasiado frágil.
También conviene recordar que iSCSI vive o muere por la estabilidad de la red. Una red de 1 GbE puede servir en entornos modestos, pero en cuanto entran varias máquinas virtuales, copias simultáneas o un backend con más carga, el margen se estrecha rápido. En muchos proyectos, subir a 10 GbE cambia el comportamiento de forma muy visible, no por magia, sino porque elimina presión donde antes había saturación.
Cuando estas piezas encajan, iSCSI deja de parecer “otro protocolo más” y se convierte en una pieza bastante predecible. Cuando no encajan, los fallos suelen ser ruidosos y, además, engañosos.
Los errores más comunes que veo en despliegues iSCSI
Hay varios fallos que se repiten una y otra vez. El primero es tratar iSCSI como si fuera una carpeta compartida, cuando en realidad estás exponiendo bloques de disco. Eso lleva a permisos mal pensados, expectativas equivocadas y diseños que luego nadie quiere mantener.
El segundo error es olvidar que el tráfico de almacenamiento compite con el resto de la red. Si metes iSCSI en la misma infraestructura que navegación, vídeo, copias y administración, el rendimiento pasa a depender de picos ajenos. El tercero es no probar la caída de una ruta antes de ponerlo en producción. Tener dos enlaces no sirve de mucho si el failover no está verificado.
También veo mucho el clásico problema de configuración inconsistente: VLAN en un lado, MTU distinta en otro, autenticación a medias o sesiones que no persisten tras reinicio. Y, por último, la tentación de dejar el target demasiado expuesto. iSCSI no debería vivir abierto “para que todo sea más fácil”; lo normal es limitar su alcance al mínimo necesario.
Si yo tuviera que dejar una instalación lista para un entorno real, haría algo muy concreto: comprobaría la segmentación de red, validaría el retorno automático de la sesión, probaría una caída física de enlace y revisaría que el almacenamiento se reconecta sin intervención manual. Eso no es glamour técnico, pero evita la mayor parte de sorpresas desagradables.
Antes de darlo por cerrado
La forma más sensata de entender iSCSI es esta: no es una tecnología complicada, pero sí es exigente con la red que la transporta. Cuando el diseño es bueno, ofrece una solución limpia para almacenamiento compartido sin obligarte a montar una SAN compleja; cuando el diseño es flojo, cada pequeño fallo se nota más de la cuenta.
- Si buscas bloques remotos para virtualización o servidores, iSCSI encaja muy bien.
- Si solo quieres compartir archivos, normalmente te conviene otra cosa.
- Si la red no es estable, el proyecto debería replantearse antes de arrancar.
- Si añades multipathing, segmentación y autenticación, el salto de fiabilidad es real.
Mi lectura final es clara: iSCSI merece la pena cuando quieres almacenamiento en red con lógica de disco y una infraestructura Ethernet razonablemente bien cuidada. Ahí es donde aporta valor de verdad, no como sigla de moda, sino como una solución práctica y bastante madura para redes y conectividad.
