Almacenamiento: iSCSI vs NFS vs NVMe-oF — ¿Cuál gana realmente y por qué

La verdadera pregunta: ¿qué estás optimizando?

“¿Cuál es más rápido?” es la primera pregunta equivocada. Puedes hacer que cualquiera de estos sea rápido en laboratorio y miserable en producción.
La pregunta correcta es: ¿qué fallo estás dispuesto a tolerar y qué trabajo estás dispuesto a repetir una y otra vez?

Los protocolos de almacenamiento son un paquete completo:

• Semántica: dispositivo de bloques frente a sistema de archivos compartido, comportamiento de bloqueo, operaciones de metadatos.
• Modelo de concurrencia: un host escribe su dispositivo de bloques frente a múltiples clientes compartiendo un espacio de nombres.
• Comportamiento de recuperación: qué sucede cuando una ruta hace flapping, un switch pierde paquetes o un servidor se reinicia en medio de una E/S.
• Ergonomía operativa: aprovisionamiento, redimensionado, snapshots, multipath, observabilidad.
• Postura de seguridad: authN/authZ, cifrado, radio de impacto, protección ante “ups”.

Si ejecutas virtualización, bases de datos, analítica o Kubernetes, no eliges solo un protocolo sino un estilo de vida.
Elige el que puedas operar a las 3 a.m. medio despierto y con cierto resentimiento moderado.

Veredictos rápidos (la parte con opinión)

Elige NFS cuando…

• Quieres almacenamiento compartido con flujos de trabajo humanos sensatos: directorios personales, repositorios de contenido, medios, caches de compilación.
• Valoras la sencillez del aprovisionamiento y las restauraciones rápidas más que la latencia absoluta más baja.
• Puedes invertir en un buen servidor NFS (o appliance) y eres disciplinado con las opciones de montaje y el diseño de red.

NFS es el campeón del “funciona lo suficientemente bien”—hasta que lo abusan con cargas intensivas en metadatos y se pretende que la red sea sin pérdida.

Elige iSCSI cuando…

• Necesitas almacenamiento en bloque para un solo host (o un sistema de archivos de clúster/gestor de volúmenes encima).
• Necesitas multipathing maduro y amplia compatibilidad con sistemas operativos, hipervisores y arrays de almacenamiento.
• Puedes comprometerte con la higiene operativa: timeouts, políticas de ruta y monitorización.

iSCSI es el sedán confiable del almacenamiento en red. No es cool. Tampoco suele ser la razón por la que incumples tu SLO—a menos que lo configures como un juguete de laboratorio.

Elige NVMe-oF cuando…

• Tu carga es sensible a la latencia y ya está sintonizada localmente (bases de datos, indexación de alta frecuencia, ingestión de logs a escala).
• Tienes una red limpia y con poca pérdida y puedes justificar la complejidad operativa.
• Estás listo para tratar la tela como un sistema de primera clase: telemetría, control de congestión y gestión cuidadosa de cambios.

NVMe-oF puede ser espectacular. También puede ser espectacularmente humillante cuando una pequeña pérdida de paquetes convierte tu sueño de “NVMe casi local” en un generador de tickets.

Si quieres una regla por defecto: elige NFS para archivos compartidos, iSCSI para bloques genéricos, NVMe-oF solo cuando puedas demostrar que lo necesitas y que puedes operarlo.

Hechos interesantes y contexto histórico (para que dejes de repetir errores antiguos)

1. NFS es anterior a tu presupuesto en la nube. NFS apareció a mediados de los años 80 en Sun Microsystems, creado para hacer que las redes se sintieran como sistemas de archivos locales.
2. NFSv3 triunfó por ser simple. Su diseño sin estado ayudó a que los servidores escalaran y se recuperaran, pero empujó la complejidad a los clientes (y el bloqueo a protocolos laterales).
3. NFSv4 se tomó en serio el estado. Introdujo bloqueo integrado y mecanismos de seguridad más fuertes, intercambiando simplicidad por corrección y mejor comportamiento en WAN.
4. iSCSI nació para matar “redes especiales”. Surgió a principios de los 2000 para ejecutar SCSI sobre TCP/IP y que los SANs pudieran usar Ethernet en lugar de FC.
5. Los jumbo frames fueron una vez un símbolo de estatus. Muchos equipos activaron MTU 9000 sin validación de extremo a extremo; las descoincidencias todavía causan fragmentación extraña y pérdidas hoy.
6. NVMe fue diseñado para el paralelismo. NVMe usa múltiples colas para reducir la contención de bloqueo y aprovechar CPUs modernas—a diferencia de pilas de almacenamiento antiguas pensadas para discos giratorios.
7. NVMe-oF no es una sola cosa. Es una familia: transportes RDMA (RoCE/iWARP/InfiniBand) y TCP. TCP suele ser más fácil de desplegar; RDMA puede ofrecer menor latencia pero es más exigente.
8. “NAS vs SAN” es mayormente una guerra de proxies. La división real es semántica de archivos vs semántica de bloques—y qué capa se queda con la caché, el bloqueo y la consistencia.
9. Multipathing es anterior a tu plataforma de contenedores. Los patrones MPIO se forjaron en la era de arrays con controladoras duales y HBAs inestables; las lecciones aún aplican.

Cómo funcionan realmente (y dónde duelen)

NFS: semántica de sistema de archivos remoto

Con NFS, los clientes piden al servidor operaciones de archivos: open, read, write, getattr, readdir, lock (en v4), y más.
El servidor controla el namespace y los metadatos autoritativos. Los clientes cachean agresivamente para reducir los viajes de ida y vuelta.

La gran ventaja: namespace compartido y aprovisionamiento trivial. Exporta un directorio, móntalo y listo.
La gran trampa: la latencia de metadatos y el comportamiento de coherencia de caché se vuelven problemas de rendimiento y corrección.
NFS puede rendir mucho en throughput secuencial y aun así colapsar con patrones de “millones de archivos pequeños”.

iSCSI: dispositivo de bloques sobre TCP

iSCSI encapsula comandos SCSI sobre TCP. El cliente (initiator) ve un LUN remoto como un dispositivo de bloques local.
Sistemas de archivos, LVM, RAID, bases de datos—todo eso se apila encima, igual que con discos locales.

La ventaja: aplicaciones y sistemas operativos saben cómo tratar dispositivos de bloques. Multipath está bien entendido.
El dolor: heredas las aristas afiladas del almacenamiento en bloque: corrupción si múltiples hosts escriben sin una capa consciente de clúster, y comportamiento feo en fallos si los timeouts son incorrectos.

NVMe-oF: semántica NVMe a través de una tela de red

NVMe-oF extiende el conjunto de comandos NVMe por la red. Comparado con iSCSI, generalmente reduce la sobrecarga de protocolo y soporta un paralelismo profundo.
En la práctica, puedes acercarte a la latencia de NVMe local—especialmente con RDMA—pero solo si la red se comporta.

El dolor no es “es nuevo” (ya no es tan nuevo). El dolor es que eleva las expectativas.
Cuando la latencia baja, el siguiente cuello de botella se vuelve visible: planificación de CPU, afinidad de IRQ, congestión TCP, vecinos ruidosos, firmware del array, lo que sea.

Broma #1: NVMe-oF promete “rendimiento similar al local”. Igual que cualquier currículum que he visto.

Realidad del rendimiento: latencia, IOPS, rendimiento

Latencia: la única métrica que tu base de datos realmente cree

Si tu carga es transaccional, la distribución de latencia importa más que el pico de IOPS. La mediana no es suficiente; la latencia en cola te arruina.
La sobrecarga del protocolo, la fluctuación de la red, las profundidades de cola y los retransmisos aparecen como p95/p99 picos.

• NFS: a menudo excelente para lecturas/escrituras secuenciales grandes, pero los metadatos y las escrituras síncronas pueden ser costosos dependiendo del servidor y las opciones de montaje.
• iSCSI: usualmente estable y predecible; multipathing ayuda más a la disponibilidad que a la latencia bruta.
• NVMe-oF: mejor latencia potencial; también la manera más rápida de descubrir que tu red no es tan limpia como pensabas.

IOPS: lo que le encanta al marketing y desconfían los SRE

“IOPS” sin tamaño de bloque, mezcla lectura/escritura, profundidad de cola y distribución de latencia es trivia.
Aun así, el protocolo moldea cuán eficientemente se transporta la E/S pequeña.

NVMe-oF tiende a manejar bien grandes profundidades de cola y paralelismo. iSCSI también puede alcanzar IOPS muy altos, pero la sobrecarga de CPU y el procesamiento de comandos SCSI pueden aparecer antes.
El rendimiento de NFS depende mucho del cacheo del cliente, de los hilos del servidor y de si tu carga es intensiva en datos o en metadatos.

Throughput: la victoria fácil con las armas de destrucción fáciles

Para throughput masivo, 10/25/40/100GbE importa más que la elección del protocolo. También: consistencia MTU extremo a extremo, offloads de NIC y no sobreusar tus uplinks hasta crear un agujero negro.

La falla de throughput más común no es “el protocolo es lento”. Es “un puerto de switch está dando errores” o “un enlace en un LAG está medio muerto” o “el array está haciendo rebuilds en background”.

Costo de CPU: el impuesto oculto

iSCSI y NFS ambos corren sobre TCP, así que la CPU se convierte en parte del coste del almacenamiento. NVMe-oF sobre TCP es similar; NVMe-oF sobre RDMA puede reducir la sobrecarga de CPU pero aumenta las restricciones operativas.
Si estás en nodos de cómputo compartidos, ese impuesto de CPU es real: roba margen de hilos de aplicación y eleva la latencia.

“La esperanza no es una estrategia.” — idea parafraseada citada con frecuencia en ingeniería y operaciones

Modos de fallo que encontrarás en producción

NFS: cuando el servidor estornuda, los clientes se resfrían

NFS es centralizado. Eso es tanto el punto como el riesgo. Si el servidor está sobrecargado, todos los clientes lo notan.
El cacheo en el cliente puede enmascarar problemas hasta que deja de hacerlo, y entonces obtienes manadas atronadoras.

• Handles de archivo obsoletos: típicamente después de cambios en las exportaciones del servidor, reconstrucciones del sistema de archivos o failovers que no preservaron la identidad del inode.
• I/O “colgado”: clientes esperando respuestas del servidor, a menudo debido a pérdida de red, inanición de hilos del servidor o contención de bloqueos.
• Tormentas de metadatos: sistemas de build, gestores de paquetes y diseños de “vamos a almacenar millones de objetos pequeños como archivos”.

iSCSI: muerte por timeouts y fallos parciales

iSCSI tiende a fallar de maneras parciales y feas: una ruta se degrada, un switch deja caer paquetes, una NIC comienza a hacer flapping.
Tu SO mantiene el dispositivo de bloques vivo hasta que no puede. Entonces los sistemas de archivos hacen panic, o peor: siguen y tu app se corrompe.

• Flapping de rutas: problemas intermitentes de enlace que disparan failover frecuente y causan picos de latencia.
• Colapso de colas: I/O se acumula detrás de una ruta bloqueada; cuando ocurre el failover, ya estás intercambiando memoria virtual.
• Acceso split-brain: múltiples initiators escribiendo el mismo LUN sin coordinación (esto no es un “tal vez”; es un “cuando”).

NVMe-oF: la red es ahora tu backplane

NVMe-oF brilla cuando puedes tratar la tela como un bus interno de alta calidad. Pero Ethernet es una democracia de paquetes; no le importan tus objetivos de latencia.
La congestión, microbursts, ajustes ECN, comportamiento de buffers y firmware de NIC importan mucho.

• Sensibilidad a pérdida de paquetes: incluso pequeñas tasas de pérdida pueden disparar la latencia en cola, especialmente bajo carga.
• Multipath mal configurado: asimetría o políticas erróneas que generan paths calientes y rendimiento impredecible.
• Brecha de observabilidad: equipos que despliegan NVMe-oF antes de poder explicar latencia por cola y retransmisos por sesión.

Broma #2: La gente de almacenamiento ama los “cinco nueves” hasta que el equipo de red pregunta cuáles cinco minutos estás dispuesto a perder.

Tres mini-historias corporativas desde las trincheras

Incidente: la suposición equivocada (“Es solo un montaje”)

Una compañía mediana ejecutaba builds de CI en una flota de workers Linux. Guardaban artefactos de build en un share NFS porque era fácil de gestionar y fácil de limpiar.
Alguien notó que el share estaba “subutilizado” y decidió consolidar: mover directorios personales, caches de build y logs de aplicaciones al mismo export.

La suposición equivocada fue sutil: asumieron que NFS se comporta como un disco local bajo churn de metadatos. No es así.
La carga de CI generó una tormenta de creaciones de archivos, stats, renames y deletes. Los directorios personales añadieron una carga constante de lecturas y escrituras pequeñas.
Los logs añadieron appends síncronos más ráfagas en rotación.

Los síntomas fueron confusos. La CPU en los workers de build se disparó, pero no en un modo de “ocupado compilando”—más bien en un modo de “bloqueado en estado D”.
Los builds empezaron a agotar tiempo. Los inicios de sesión SSH se volvieron lentos porque el arranque del shell toca muchos archivos. La monitorización mostró que la red del servidor NFS no estaba saturada.

La causa raíz: hilos del servidor NFS y el backing de almacenamiento estaban saturados por operaciones de metadatos y escrituras síncronas, mientras la caché del lado cliente se invalidaba repetidamente.
“Pero el ancho de banda está bien” fue la lente equivocada. El cuello de botella real era op/s en el servidor y la latencia de RPC de metadatos.

La solución fue aburrida y efectiva: separar exportaciones por carga de trabajo, aislar caches de CI en su propio servidor (o discos locales) y afinar opciones de montaje y conteos de hilos del servidor.
También añadieron un benchmark sintético de metadatos a la planificación de capacidad. El servicio se recuperó y el servidor NFS dejó de ser la ansiedad compartida no oficial de la compañía.

Optimización que salió mal: jumbo frames y la caída silenciosa

Otra organización quiso mejor throughput en iSCSI. Alguien activó MTU 9000 en la VLAN de almacenamiento y en las NICs iSCSI.
La ventana de cambio fue corta y no validaron cada salto. “Es una VLAN dedicada, estará bien.”

Durante una semana, todo parecía correcto—hasta que aparecieron picos de latencia periódicos en horas punta. No eran caídas completas. Solo el tipo de lentitud aleatoria que hace que los equipos culpen a “la nube”
aun cuando corren sus propios racks.

El patrón fue desagradable: solo ciertos hosts lo veían, y solo cuando el tráfico cruzaba un par particular de switches.
Los retransmisos TCP aumentaron ligeramente, pero nadie vigilaba retransmisos en la VLAN de almacenamiento porque, históricamente, “las VLANs de almacenamiento son limpias”.

El problema real: una interfaz de switch en la ruta todavía estaba en MTU 1500 y estaba descartando tramas sobredimensionadas en lugar de fragmentarlas.
El tráfico iSCSI se retransmitió, se acumularon colas y la capa multipath ocasionalmente falló—añadiendo más turbulencia.
Los gráficos de ancho de banda se mantenían tranquilos porque los paquetes perdidos no aparecen como throughput usado.

El rollback—a MTU 1500 extremo a extremo—estabilizó todo de inmediato. Más tarde, reintrodujeron jumbo frames solo después de imponer comprobaciones de cumplimiento MTU en la automatización
y alertar sobre drops de interfaz y retransmisos TCP. La lección: las “optimizaciones” de rendimiento que no son extremo a extremo son solo nuevos modos de fallo.

Práctica aburrida pero correcta que salvó el día: disciplina en multipath

Una plataforma cercana a finanzas ejecutaba bases de datos críticas en LUNs iSCSI. La configuración no era exótica: controladoras de almacenamiento duales, dos telas, multipath en cada host.
Lo que fue diferente fue la disciplina del equipo. Cada host tenía la misma plantilla de config de multipath, los mismos timeouts y una prueba trimestral de “desconectar un cable” en staging.

Una tarde, un switch top-of-rack empezó a registrar errores CRC en un puerto conectado a una controladora de almacenamiento.
Los errores eran lo bastante intermitentes para que el enlace permaneciera arriba, pero lo bastante malos para causar reintentos y ocasionales problemas de sesión iSCSI.

Las bases de datos no se cayeron. La latencia de la aplicación subió ligeramente y luego se estabilizó.
La monitorización detectó más failovers de ruta y latencia de I/O elevada en un grupo de rutas. El on-call drenó tráfico, falló intencionalmente el enlace sospechoso y abrió un ticket de hardware.

El postmortem no fue dramático. Ese es el punto. Multipath con timeouts sensatos convirtió un problema físico intermitente en un evento de mantenimiento en lugar de un incidente de cliente.
No “resolvieron” la física; la planificaron y practicaron la respuesta hasta que fue memoria muscular.

Manos a la obra: tareas prácticas con comandos, salidas y decisiones

Estas son las tareas que realmente haces cuando los sistemas titubean. Cada una incluye qué significa la salida y qué decisión tomas a continuación.
Los comandos asumen un cliente Linux salvo que se indique lo contrario.

1) Identificar si estás en NFS, iSCSI o NVMe-oF desde el host

cr0x@server:~$ findmnt -t nfs,nfs4
TARGET           SOURCE                 FSTYPE OPTIONS
/mnt/shared      nas01:/export/shared   nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MODEL,TRAN
NAME   TYPE  SIZE MODEL             TRAN
sda    disk  200G Virtual Disk
sdb    disk  2.0T LIO-ORG   iscsi    iscsi
nvme0n1 disk  1.6T NVMeDisk          nvme

cr0x@server:~$ nvme list-subsys
nvme-subsys0 - NQN=nqn.2014-08.org.nvmexpress:uuid:...
\
 +- nvme0 tcp traddr=10.20.0.50 trsvcid=4420 live

Significado: findmnt muestra montajes NFS activos; lsblk muestra transporte; nvme list-subsys confirma sesiones NVMe-oF.

Decisión: Elige la ruta de diagnóstico correcta. No soluciones NFS como si fuera almacenamiento en bloque ni viceversa.

2) NFS: confirmar opciones de montaje que pueden hacer o romper la latencia

cr0x@server:~$ nfsstat -m
/mnt/shared from nas01:/export/shared
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.20.1.21

Significado: hard significa reintentos indefinidos de E/S (más seguro para datos, puede “colgar” apps); timeo y retrans influyen en el comportamiento de espera; rsize/wsize impactan el throughput.

Decisión: Para datos críticos, mantén hard. Si apps orientadas a usuarios no toleran largas esperas, considera cambios de arquitectura (cache local, pipelines asíncronos) en lugar de cambiar a soft.

3) NFS: medir comportamiento a nivel RPC (latencia y retrans)

cr0x@server:~$ nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
2143098    153        2143120

Client nfs v4:
null         read         write        open         close        getattr
0            152340       91822        4311         4309         602111

Significado: retransmisiones sugieren pérdida/ congestión de red o sobrecarga del servidor. Incluso conteos “pequeños” de retrans pueden correlacionar con picos de latencia en cola.

Decisión: Si retrans no es cero y está subiendo, trátalo como P1. Revisa errores de red y carga del servidor antes de afinar aplicaciones.

4) NFS: detectar stalls inducidos por el servidor en logs del kernel

cr0x@server:~$ dmesg -T | tail -n 8
[Tue Feb  4 10:44:21 2026] nfs: server nas01 not responding, still trying
[Tue Feb  4 10:44:23 2026] nfs: server nas01 not responding, still trying
[Tue Feb  4 10:44:41 2026] nfs: server nas01 OK

Significado: Los clientes experimentaron timeouts; hubo recuperación. Esta es a menudo la señal en host más temprana de los hiccups del servidor o microcaídas de red.

Decisión: Correlaciona con contadores de interfaz del switch y CPU/I/O del servidor NFS. Si se repite, planea mitigación (separar cargas, añadir HA, mejorar la red).

5) iSCSI: validar sesiones y descubrimiento de targets

cr0x@server:~$ sudo iscsiadm -m session
tcp: [1] 10.20.0.10:3260,1 iqn.2003-01.org.linux-iscsi.san01:storage.lun1 (non-flash)
tcp: [2] 10.20.0.11:3260,1 iqn.2003-01.org.linux-iscsi.san01:storage.lun1 (non-flash)

cr0x@server:~$ sudo iscsiadm -m node -o show | head
# BEGIN RECORD 2.1.8
node.name = iqn.2003-01.org.linux-iscsi.san01:storage.lun1
node.tpgt = 1
node.startup = automatic

Significado: Dos sesiones típicamente representan dos rutas (bien). Startup automatic significa que reconecta en boot.

Decisión: Si ves solo una sesión donde esperas dos, para: tienes un punto único de fallo y probable desequilibrio de rendimiento.

6) iSCSI: comprobar salud de multipath y política de rutas

cr0x@server:~$ sudo multipath -ll
mpatha (36001405a7c3d2a1b9c2d7f1a4e5b6c7d) dm-2 LIO-ORG,iscsi_disk
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=1 status=active
| `- 3:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
  `- 4:0:0:1 sdc 8:32 active ready running

Significado: Ambas rutas están active/ready. queue_if_no_path significa que las E/S se encolan durante pérdida total de rutas (puede causar stalls en apps).
La política influye el balanceo de carga.

Decisión: Si alguna ruta está faulty o failed, arregla problemas físicos/red primero. No “afines” alrededor de una ruta rota.

7) iSCSI: confirmar timeouts para evitar “colgar para siempre” o “fallar demasiado rápido”

cr0x@server:~$ sudo iscsiadm -m node -T iqn.2003-01.org.linux-iscsi.san01:storage.lun1 -p 10.20.0.10:3260 -o show | egrep 'noop|replacement|timeout'
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5
node.session.timeo.replacement_timeout = 120

Significado: Noops detectan paths muertos; replacement timeout controla comportamiento de failover. Muy grande = largos stalls; muy pequeño = sesiones flappy.

Decisión: Alinea estos valores con multipath y tolerancia de la aplicación. Prueba failover bajo carga; no adivines en producción.

8) NVMe-oF: listar controladoras y detalles de transporte

cr0x@server:~$ sudo nvme list
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
/dev/nvme0n1     deadbeefdeadbeef     NVMeOF-Target                             1         2.00  TB / 2.00  TB       4 KiB +  0 B     1.3

cr0x@server:~$ sudo nvme list-subsys
nvme-subsys0 - NQN=nqn.2014-08.org.nvmexpress:uuid:3b8d...
\
 +- nvme0 tcp traddr=10.20.0.50 trsvcid=4420 live

Significado: Confirma NVMe-oF sobre TCP y qué IP/puerto del target estás usando.

Decisión: Si ves transportes inesperados o rutas faltantes, para y corrige la topología antes de perseguir rendimiento.

9) NVMe-oF: comprobar multipath y estado ANA (acceso asimétrico)

cr0x@server:~$ cat /sys/module/nvme_core/parameters/multipath
Y

cr0x@server:~$ sudo nvme list-ana /dev/nvme0
ANA Log for NVMe device:nvme0
ANA group ID: 1
  state: optimized
  NSIDs: 1
ANA group ID: 2
  state: non-optimized
  NSIDs: 1

Significado: Multipath está habilitado. Un path es optimized y otro es non-optimized (común en sistemas con controladoras duales).

Decisión: Asegura que tu host prefiera paths optimized. Si el tráfico pasa por paths non-optimized, tendrás latencia evitable.

10) Red: comprobar errores de interfaz (la verdad poco glamorosa)

cr0x@server:~$ ip -s link show dev ens192
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    9876543210 1234567  0      12      0        0
    TX:  bytes packets errors dropped carrier collsns
    8765432109 1122334  0      0      0       0

Significado: Existen drops en RX. Los drops en una interfaz de almacenamiento son multiplicadores de latencia.

Decisión: Investiga capa física, desajustes MTU, congestión. No aceptes “unos pocos drops” en redes de almacenamiento.

11) Red: medir retransmisiones TCP (especialmente para iSCSI/NFS/NVMe-TCP)

cr0x@server:~$ nstat -az | egrep 'TcpRetransSegs|TcpExtTCPSynRetrans|TcpTimeouts'
TcpRetransSegs            1842
TcpExtTCPSynRetrans       0
TcpTimeouts               21

Significado: Retransmisiones y timeouts indican pérdida o congestión severa. Esto a menudo correlaciona con picos de latencia p99.

Decisión: Si estos contadores suben durante incidentes, trata la ruta de red como sospechosa, no solo el array de almacenamiento.

12) SO: ver si el kernel espera por E/S (stall de almacenamiento vs problema de CPU)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 812344  92124 933112    0    0   120   340  890 1200 12  4 80  4  0
 3  5      0 810120  92124 933900    0    0   110   500  910 1300 10  3 60 27  0
 1  6      0 808992  92124 934100    0    0   130   480  920 1290  9  3 58 30  0

Significado: Alto b (procesos bloqueados) y alto wa (I/O wait) apuntan a latencia de almacenamiento como cuello de botella.

Decisión: Cambia de “depuración de app” a “depuración de la ruta de I/O.” Recoge iostat, estadísticas de protocolo y contadores de red inmediatamente.

13) Dispositivos de bloque: vigilar latencia por disco y profundidad de cola

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   r_await   w_await   aqu-sz  %util
sdb              120.0   80.0     6.10    18.40      2.95   98.0
dm-2             240.0  160.0     7.50    21.30      6.10   99.0

Significado: await es latencia promedio; aqu-sz muestra E/S encolada; %util alto en dm sugiere saturación en algún punto de la ruta.

Decisión: Si awaits se disparan mientras la red está limpia, sospecha carga en array/controladora o desequilibrio de rutas. Si awaits suben con retrans/drops, sospecha red/transporte.

14) NFS: detectar dolor de metadatos con una prueba simple intensiva en syscalls

cr0x@server:~$ sudo strace -f -tt -T -e trace=file ls -l /mnt/shared >/dev/null
10:51:02.112345 statx(AT_FDCWD, "/mnt/shared", AT_STATX_SYNC_AS_STAT, STATX_BASIC_STATS, ...) = 0 <0.012341>
10:51:02.124910 openat(AT_FDCWD, "/mnt/shared", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 <0.020118>

Significado: Esas operaciones de archivo <0.02s> son lentas para un listado trivial de directorio. Eso es latencia de metadatos.

Decisión: Si las operaciones de metadatos son lentas, deja de culpar el “throughput de disco.” Separa cargas, afina hilos/caché del servidor NFS o rediseña para reducir el chatter de metadatos.

15) NVMe-oF: verificar que el host vea la cola esperada y comportamiento de interrupciones

cr0x@server:~$ cat /proc/interrupts | egrep 'nvme|ens192' | head
 42:  1234567  0  0  0  IR-PCI-MSI 524288-edge  nvme0q0
 43:  2345678  0  0  0  IR-PCI-MSI 524289-edge  nvme0q1
 58:  3456789  0  0  0  IR-PCI-MSI 393216-edge  ens192-TxRx-0

Significado: Existen colas NVMe; las interrupciones se disparan. Si todo está atascado en una CPU, verás desequilibrio y latencia.

Decisión: Si las interrupciones se concentran en un núcleo, ajusta afinidad IRQ / RSS y vuelve a probar latencia bajo carga. NVMe-oF recompensa el ajuste de CPU/red; castiga la negligencia.

Guía rápida de diagnóstico (encuentra el cuello de botella sin una sala de guerra de una semana)

Primero: clasifica el fallo en 60 segundos

• ¿Es latencia de almacenamiento o CPU de la aplicación? Revisa vmstat (procesos bloqueados, iowait) y estados de hilos de la app.
• ¿Es específico del protocolo? Logs cliente NFS vs eventos de sesión iSCSI vs resets de controladora NVMe.
• ¿Está aislado o es sistémico? ¿Un host, un rack, una AZ o todos?

Segundo: revisa la red como si importara

1. Drops/errores de interfaz en clientes y puertos de almacenamiento: ip -s link.
2. Retransmisiones/timeouts TCP para protocolos basados en TCP: nstat.
3. Consistencia de la ruta: MTU extremo a extremo, salud LACP, corrección de VLAN.

Si encuentras drops/retransmisos, para. Arregla eso antes de afinar el almacenamiento. El tráfico de almacenamiento no es “solo tráfico.” Es el torrente sanguíneo de tu app.

Tercero: valida el enrutamiento y comportamiento de failover

• iSCSI: iscsiadm -m session, multipath -ll y logs del kernel para resets de sesión.
• NVMe-oF: nvme list-subsys, nvme list-ana, multipath habilitado.
• NFS: busca “server not responding” y retrans crecientes con nfsstat -rc.

Cuarto: revisa el sistema de almacenamiento backend (sin frases vagas)

• ¿El array está reconstruyendo, haciendo scrub o limitando operaciones?
• ¿Estás saturando CPU o caché de la controladora?
• ¿Una ruta/controladora está más caliente que la otra (asimetría)?

Quinto: mide, luego cambia una cosa

Captura latencia base (p50/p95/p99), retrans/drops, tamaños de cola y estados de rutas. Haz un cambio único, vuelve a medir.
Si no puedes medir, no estás afinando; estás jugando a la ruleta.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: montajes NFS “cuelgan” y procesos pasan a estado D

• Causa raíz: montajes hard esperando un servidor lento/inaccesible, o contención de locks en el servidor.
• Solución: diagnostica salud del servidor y pérdida de red; añade HA (active/active donde sea posible), separa cargas ruidosas y asegúrate de que los timeouts cliente sean sensatos. Evita “arreglarlo” cambiando a soft para datos críticos.

2) Síntoma: timeouts iSCSI intermitentes, errores de sistema de archivos, pausas aleatorias de VM

• Causa raíz: flapping de rutas (cable/SFP/NIC defectuoso), desajuste MTU que causa drops, o mala configuración de multipath.
• Solución: asegura rutas redundantes, valida MTU extremo a extremo, monitoriza retrans y errores de interfaz, y estandariza políticas de multipath entre hosts.

3) Síntoma: “Gran throughput, latencia terrible” en NFS

• Causa raíz: latencia de metadatos y operaciones síncronas; demasiados clientes compitiendo en el mismo export; inanición de hilos del servidor.
• Solución: separa cargas por export/servidor, afina hilos del servidor NFS y backing de almacenamiento, considera caches locales para sistemas de build y reduce explosiones de conteo de archivos.

4) Síntoma: NVMe-oF sobre TCP muestra picos p99 aleatorios bajo carga

• Causa raíz: pérdida de paquetes o microbursts de congestión; problemas de afinidad CPU/IRQ; buffering/ECN insuficiente en la tela.
• Solución: elimina drops primero; afina NIC RSS/afinidad IRQ, verifica estrategia ECN/aqm (si se usa) y asegura que multipath/ANA prefiera paths optimized.

5) Síntoma: corrupción o inconsistencias “misteriosas” del sistema de archivos en LUNs iSCSI

• Causa raíz: mismo LUN montado en modo lectura-escritura por múltiples hosts sin coordinación consciente de clúster; falta de fencing.
• Solución: aplica semántica de escritor único o usa un sistema de archivos de clúster con fencing (o muévete a NFS si realmente necesitas archivos compartidos).

6) Síntoma: errores de “stale file handle” en NFS después de mantenimiento

• Causa raíz: el sistema de archivos/export del servidor se movió o reemplazó de forma que cambió file handles/inodes; el failover no preservó identidad.
• Solución: remonta los clientes; arregla procedimientos HA para preservar identidad del sistema de archivos; evita intercambio manual de export sin coordinación.

7) Síntoma: iSCSI parece bien, pero latencia se dispara en ventanas de backup

• Causa raíz: contención en el array backend (snapshots, replicación, rebuild), o oversubscription de red cuando el tráfico de backup comparte uplinks.
• Solución: aísla tráfico de backup, programa operaciones pesadas del array, aplica QoS y monitoriza latencias y tasas de hit de caché del array.

8) Síntoma: “Subimos a 100GbE pero no se aceleró”

• Causa raíz: limitaciones de flujo único, profundidades de cola incorrectas, cuello de botella de CPU o límites del medio/controladora del almacenamiento.
• Solución: mide utilización de CPU y distribución de IRQ; paraleliza cargas; valida que el array realmente pueda entregar más; afina profundidades de cola con cuidado.

Listas de verificación / plan paso a paso

Lista de decisión: elige el protocolo según la carga y la realidad del equipo

1. ¿Necesitas archivos POSIX compartidos? Empieza con NFSv4.1+.
2. ¿Necesitas un dispositivo de bloque crudo? Empieza con iSCSI (a menos que se demuestre necesidad de NVMe-oF).
3. ¿Necesitas latencia ultra baja y alto paralelismo? Considera NVMe-oF, pero exige SLOs de red y observabilidad primero.
4. ¿Requisito multi-writer? NFS para archivos, o una capa de bloque consciente de clúster con fencing. Nunca “simplemente monta el LUN en ambos”.
5. Madurez operativa disponible? Si tu equipo no puede gestionar consistentemente MTU, LACP y monitorización, no despliegues el protocolo que magnifica esos errores (NVMe-oF).

Lista de construcción: haz que sobreviva fallos normales

1. Dos rutas de red independientes (switches separados) para tráfico de almacenamiento.
2. Estrategia MTU explícita, validada extremo a extremo, con checks en automatización.
3. Monitorización en host: retransmisos, drops de interfaz, percentiles de latencia, profundidad de colas.
4. Failover documentado y probado: desconectar un enlace, reiniciar una controladora, confirmar recuperación bajo carga.
5. Gestión de cambios: los cambios en la red de almacenamiento requieren el mismo rigor que cambios en esquemas de base de datos.

Lista operativa: qué estandarizas entre hosts

1. NFS: opciones de montaje consistentes; usa NFSv4.1+ donde corresponda; alerta en logs “server not responding” y retransmisos.
2. iSCSI: settings iscsiadm consistentes; config multipath consistente; ejercicios periódicos de fallo de ruta.
3. NVMe-oF: multipath habilitado; preferencias ANA-aware; estándares de afinidad IRQ/RSS; alertas en drops/retrans y resets de controladora.

Preguntas frecuentes

1) ¿Es NFS “más lento” que iSCSI?

No inherentemente. NFS puede ser extremadamente rápido para E/S secuencial grande. A menudo pierde en cargas pequeñas, intensivas en sync y en metadatos.
iSCSI tiende a ser más predecible para patrones orientados a bloques.

2) ¿Puedo ejecutar bases de datos en NFS?

Sí, y muchos lo hacen. Pero debes validar semánticas y latencia (especialmente comportamiento de fsync), y necesitas un setup robusto de servidor NFS.
Si no puedes medir la latencia en cola, estás apostando con tus redo logs.

3) ¿Por qué los clientes NFS “cuelgan” en lugar de fallar rápido?

Porque los montajes hard priorizan la integridad de datos: el cliente sigue reintentando para evitar escrituras parciales y corrupción.
Si tu aplicación no tolera eso, la solución correcta suele ser arquitectónica (timeouts, reintentos, colas), no cambiar a soft.

4) ¿iSCSI es seguro para acceso compartido desde múltiples hosts?

Solo con una capa consciente de clúster y fencing (sistema de archivos de clúster, gestor de volúmenes en clúster, etc.). De lo contrario arriesgas corrupción.
Los dispositivos de bloque asumen un escritor único salvo que se demuestre lo contrario.

5) ¿Tiene sentido NVMe-oF sobre TCP, o RDMA es obligatorio?

NVMe-oF sobre TCP suele ser la opción pragmática: más fácil de desplegar en Ethernet existente, menos perillas especializadas.
RDMA puede ofrecer menor latencia y menor CPU, pero eleva la exigencia en configuración de la tela y experiencia operativa.

6) ¿Cuál es el mayor coste oculto de NVMe-oF?

El coste operativo. Necesitarás mejor observabilidad de red, control de cambios más estricto y más disciplina de ajuste.
Cuando puedes hacerlo, es genial. Cuando no puedes, es una forma cara de aprender humildad.

7) ¿Siempre debo habilitar jumbo frames para almacenamiento?

Solo si puedes garantizar consistencia MTU extremo a extremo y monitorizar drops. De lo contrario intercambias una ganancia teórica por un modo de fallo real.
MTU 1500 correcto vence a MTU 9000 “mayormente configurado”.

8) ¿Cuál es la forma más rápida de saber si la red es el problema?

Revisa drops/errores de interfaz (ip -s link) y retrans/timeouts TCP (nstat) durante la ventana del incidente.
Si esos contadores suben, tu “problema de almacenamiento” es al menos en parte un problema de red.

9) Para datastores de virtualización, ¿NFS o iSCSI?

Ambos pueden funcionar. NFS suele ganar en simplicidad (un export, aprovisionamiento fácil), iSCSI puede ganar en predictibilidad e integración con ciertas características de hipervisores.
Elige según tus fortalezas operativas y tus ejercicios de fallo, no según folklore.

Conclusión: próximos pasos prácticos

Si estás eligiendo hoy sin restricciones especiales: usa NFS para archivos compartidos, iSCSI para almacenamiento en bloque de propósito general,
y reserva NVMe-oF para cargas que puedan demostrar necesidad de menor latencia y para equipos que puedan demostrar que pueden operar la tela.

Haz esto a continuación, en orden:

1. Escribe tu objetivo de latencia y tolerancia a fallos (p95/p99, duración de stalls, expectativas de recuperación).
2. Instrumenta la ruta: drops, retransmisos, estadísticas de protocolo, latencia backend.
3. Realiza un ensayo de fallo: desconecta un enlace, reinicia una controladora, falla un switch—mide impacto en la app.
4. Estandariza configuraciones (opciones de montaje, multipath, timeouts) y aplica con automatización.
5. Separa cargas incompatibles antes de perseguir afinados heroicos (tormentas de metadatos y logs no pertenecen al mismo export NFS).

El protocolo ganador es el que cumple tus SLOs y no requiere heroicos diarios. Tu yo del futuro te lo agradecerá. En silencio. Mientras duerme.