El crecimiento de las aplicaciones distribuidas, la virtualización y los entornos híbridos han convertido el almacenamiento en red en una piedra angular de cualquier infraestructura moderna. Migrar de discos locales a un repositorio centralizado y compartido simplifica la operación, habilita alta disponibilidad y permite escalar sin paradas. En ese terreno, dos veteranos —NFS para compartir archivos (NAS) e iSCSI para exponer bloques (SAN)— siguen siendo las herramientas más fiables y versátiles.
Este reportaje repasa qué resuelve cada tecnología, cuándo usar una u otra, cómo desplegarlas con seguridad y rendimiento, y añade un apartado práctico sobre cómo las implementa Stackscale con su almacenamiento en red (NFS/iSCSI) y su almacenamiento síncrono (RTO=0, RPO=0) sobre cabinas NetApp, con tiers de rendimiento (Flash Premium, Flash Plus, Flash Standard) y Archive para copias.
Por qué el almacenamiento en red cambia las reglas
Centralizar los datos aporta cuatro efectos inmediatos:
- Gestión simplificada. En vez de vigilar el espacio, copias y alertas de una docena de máquinas, se administra un único repositorio: ampliar capacidad o programar copias resulta más predecible.
- Alta disponibilidad. Si un servidor cae, otro puede tomar el relevo leyendo el mismo conjunto de datos; con discos locales, ese traspaso es imposible.
- Escalado sin paradas. La cabina de almacenamiento crece en caliente y pone el espacio a disposición de todos los clientes.
- Colaboración real. Varios nodos acceden concurrentemente a los mismos datos (granjas web, clústeres, HPC).
El dilema no es “¿almacenamiento en red sí o no?”, sino a qué nivel acceder: archivos (NAS) o bloques (SAN). Esa elección condiciona rendimiento, complejidad y operaciones.
NAS vs SAN: la diferencia que decide el diseño
NAS (archivo) — NFS. El servidor de almacenamiento mantiene un sistema de archivos (ext4, XFS…) y exporta directorios por la red. Los clientes ven carpetas y piden “lee/escribe este fichero”.
Analogía: pides al bibliotecario un libro concreto; tú no mueves estanterías.
SAN (bloque) — iSCSI. El servidor expone un volumen en bruto; el cliente lo ve como /dev/sdX, lo particiona y formatea (ext4, XFS, NTFS, VMFS). El servidor “no sabe” de ficheros, solo de bloques.
Analogía: te dan un pasillo vacío para organizarlo a tu gusto; el bibliotecario mueve cajas (bloques) cuando se lo pides.
Regla rápida:
- NFS para multiacceso a archivos (colaboración, granjas web, homes).
- iSCSI para discos dedicados de bajo latencia y alto IOPS (datastores de VM, bases de datos, clústeres que requieren disco compartido a nivel de bloque con filesystem de clúster).
NFS: compartir directorios de forma nativa en Linux/UNIX
Qué es y cómo funciona
Un servidor NFS “exporta” rutas a clientes autorizados. Al montar la exportación, el cliente ve el directorio como si fuera local. La gestión se realiza en el archivo /etc/exports (qué se comparte, a quién y con qué permisos).
Casos de uso habituales
- /home centralizados: la sesión del usuario es idéntica en cualquier equipo.
- Granja web: todos los servidores comparten
/srv/www/uploadspara subidas y estáticos. - Repositorios compartidos: datasets, librerías, artefactos de build.
Aspectos de seguridad
- En NFSv3 se confía en IPs y UID/GID: suficiente para redes muy controladas, pero débil ante suplantación e inconsistencias.
- NFSv4 + Kerberos añade autenticación fuerte, integridad y cifrado opcional en tránsito, además de mapear identidades por nombre en vez de por números.
Rendimiento
- Ajustar tamaños de bloque (
rsize/wsize) en clientes para ficheros grandes. - Elegir
sync(más seguro, algo más lento) oasync(más rápido, mayor riesgo si el servidor cae). - Red 10/25/40 GbE y, si procede, Jumbo Frames (MTU 9.000 con todos los saltos alineados).
iSCSI: un “disco local” que viaja por TCP/IP
Conceptos clave
- Target (servidor), Initiator (cliente), LUN (unidad lógica en bloque) e IQN (identificador global).
- El cliente descubre el Target, inicia sesión (idealmente con CHAP o CHAP mutuo) y ve el LUN como un /dev/sdX para particionar y formatear.
Casos de uso habituales
- Virtualización (VMware, Proxmox/KVM, Hyper-V): datastores en bloque (VMFS, LVM compartido).
- Bases de datos: LUN dedicado, filesystem y tuning a medida; suele ofrecer latencia más baja que NFS en E/S aleatoria.
- Clústeres HA que requieren disco compartido (Windows Failover, Veritas, VMFS).
Advertencia importante
Montar el mismo LUN en múltiples clientes con ext4/XFS/NTFS corrompe datos; para multiacceso real hacen falta filesystems de clúster (GFS2, OCFS2, VMFS) o rediseñar el caso con NFS.
Buenas prácticas
- CHAP para autenticación; segmentar por VLAN; red dedicada de storage.
- Telemetría de E/S y colas; cuidado con el backing store (LVM, RAID, SSD/NVMe).
NFS vs iSCSI: comparativa útil
| Característica | NFS (archivo) | iSCSI (bloque) |
|---|---|---|
| Abstracción | Alta: el servidor gestiona el FS; el cliente ve carpetas | Baja: el cliente gestiona el FS; ve discos |
| Complejidad | Baja | Alta (Targets, LUNs, IQN, ACLs) |
| Desempeño | Muy bueno en ficheros; sobrecarga por metadatos | Excelente en E/S aleatoria; latencia baja |
| Concurrencia | Excelente (bloqueos de fichero) | Peligrosa sin FS de clúster |
| Casos típicos | Homes, granjas web, repos compartidos | Datastores de VM, DB, clústeres HA |
Tres decisiones rápidas
- 10 servidores web con subidas → NFS.
- 3 hosts con live migration → iSCSI (o NFS bien dimensionado; iSCSI suele ganar en latencia).
- Un servidor de base de datos +10 TB → iSCSI con LUN dedicado.
Seguridad y rendimiento: más allá del “funciona”
- NFS: intenta NFSv4 + Kerberos; si no, restringe por subred, cuida
root_squashy endurece firewall. - iSCSI: CHAP (idealmente mutuo) + ACL por IQN; segmenta; registra y monitoriza.
- Red dedicada de almacenamiento y Jumbo Frames con MTU 9.000 solo si todos los equipos del circuito lo soportan.
- Observabilidad: métricas p95/p99 de latencia y E/S real; playbooks de contingencia y pruebas periódicas.
Cómo encajan NFS e iSCSI en Stackscale: almacenamiento en red y almacenamiento síncrono
Más allá de la tecnología base, el diseño de plataforma determina la resiliencia y la experiencia de operación. En Stackscale, el almacenamiento en red se ofrece de dos maneras complementarias:
1) Almacenamiento en red (NFS / iSCSI) gestionado
- Exposición de recursos NAS (NFS) para compartir archivos entre múltiples nodos (homes, uploads, repos compartidos) y de recursos SAN (iSCSI) para bloques dedicados (datastores de VM, DB).
- Red agnóstica al hipervisor con VLAN reales: el mismo segmento puede extenderse entre clusters VMware, clusters Proxmox y servidores bare-metal, simplificando diseños híbridos.
- Integración con entornos de virtualización y stacks de cliente; posibilidad de combinar con vSAN (VMware) o Ceph (Proxmox/KVM) cuando la arquitectura lo requiera.
2) Almacenamiento síncrono (NetApp) con RTO=0 y RPO=0
Cuando el negocio no tolera caídas ni pérdida de datos, la opción es el almacenamiento síncrono sobre cabinas NetApp:
- RTO=0 (Recovery Time Objective) — continuidad sin tiempo de inactividad apreciable.
- RPO=0 (Recovery Point Objective) — cero pérdida de datos: escritura confirmada simultáneamente en cabinas redundantes.
- Tiers de rendimiento para ajustar coste/IOPS/latencia:
- Flash Premium — latencia ultra-baja e IOPS muy altos (DB críticas, analítica en tiempo real).
- Flash Plus — equilibrio entre latencia y throughput (apps, middleware, cargas mixtas).
- Flash Standard — rendimiento consistente con coste optimizado (VM generales).
- Archive — capacidad orientada a copias y retención a largo plazo.
- Snapshots frecuentes y réplica multi-DC incluida, con rutas de failover/failback definidas.
- Encaje natural con NFS e iSCSI: exportación de compartidos o LUNs desde la cabina, según el caso de uso.
¿Cuándo optar por el almacenamiento síncrono?
- Frontales de pago, sistemas de emergencia, core financiero, VDI críticos o cualquier carga donde “minutos” ya es demasiado.
- Proyectos que exigen auditoría estricta y continuidad pactada en SLA: la sincronía aporta certeza (no solo redundancia).
Ejemplos de diseño (con Stackscale de fondo)
- Granja web + CDN: NFS sobre cabina NetApp (Flash Standard/Plus) para
/uploadsy artefactos, con VLAN real que une bare-metal y hypervisores. - Cluster VMware con live migration: datastore iSCSI + VMFS (Flash Plus/Premium) y réplica multi-DC; playbook de conmutación probado.
- Base de datos OLTP de alto rendimiento: LUN iSCSI dedicado (Flash Premium), filesystem XFS optimizado, RPO=0 si el proceso admite sincronía.
- Backups y retención: tier Archive con snapshots + copias inmutables; restauraciones verificadas.
Preguntas difíciles (y respuestas claras)
¿NFS o iSCSI para un datastore de VMware/Proxmox?
Los dos están soportados. iSCSI + VMFS suele ofrecer latencia menor y más IOPS en E/S aleatoria (crítico para VMs); NFS simplifica operación y escala rápidamente si el backend es sólido. En Stackscale es habitual iSCSI para datastores y NFS para compartidos.
¿Qué aporta el almacenamiento síncrono (RTO=0, RPO=0) frente a réplica “clásica”?
La réplica asíncrona minimiza el RPO, pero no lo lleva a cero; puedes perder segundos/minutos. La sincronía confirma escrituras en cabinas redundantes al mismo tiempo: no pierdes datos y el servicio no se interrumpe. Requiere red y diseño cuidadosos (latencia, quorum, failover).
¿Puedo mezclar NFS/iSCSI con Ceph o vSAN?
Sí. Es común usar Ceph/vSAN como SDS de proximidad y NFS/iSCSI desde cabina para persistencia y réplica multi-DC. La red con VLAN reales de Stackscale facilita tránsitos híbridos sin depender de SDN del hipervisor.
¿Cómo se “asegura” un NFS/iSCSI en producción?
- NFSv4 + Kerberos para autenticación e integridad (y cifrado si procede); firewall,
root_squashy control de subredes. - iSCSI con CHAP (mutuo idealmente), ACL por IQN y segmentación.
- Red dedicada de storage, MTU 9.000 si todos los saltos lo soportan, métricas de latencia p95/p99 y ensayos de failover.
Conclusión
NFS e iSCSI no compiten: se complementan. NFS ofrece colaboración y concurrencia a nivel de archivo; iSCSI aporta control fino y desempeño a nivel de bloque. La clave es alinear la elección con la carga (web, VM, DB, clústeres) y desplegar con seguridad y telemetría.
Con el almacenamiento en red (NFS/iSCSI) y el almacenamiento síncrono (NetApp, RTO=0, RPO=0) de Stackscale, este diseño se plasma en la práctica: VLAN reales agnósticas al hipervisor, tiers Flash (Premium/Plus/Standard) y Archive, snapshots y réplica multi-DC incluidas, y un enfoque de plataforma que reduce fricción operativa sin renunciar a seguridad y escala. La diferencia entre un TI que “apaga fuegos” y uno que anticipa el crecimiento empieza aquí: la herramienta adecuada para cada trabajo… y una arquitectura que no te condicione mañana.
Preguntas frecuentes (FAQ)
¿Qué diferencia hay entre almacenamiento en red y almacenamiento síncrono en Stackscale?
El almacenamiento en red expone recursos NFS/iSCSI desde cabina para NAS/SAN; el almacenamiento síncrono replica en tiempo real en cabinas NetApp redundantes, garantizando RTO=0 y RPO=0. Se pueden combinar según criticidad y coste.
¿Cuándo elegir Flash Premium, Flash Plus o Flash Standard?
- Premium: latencia mínima e IOPS muy altos (DB críticas, analítica en tiempo real).
- Plus: equilibrio latencia/throughput (aplicaciones mixtas, datastores exigentes).
- Standard: rendimiento estable con coste optimizado (VM y servicios generales). Archive se orienta a copias y retención.
¿Qué ventajas aporta la red con VLAN reales de Stackscale?
Permite extender el mismo segmento entre VMware, Proxmox y servidores bare-metal, sin depender de SDN del hipervisor. Facilita migraciones, híbridos y coexistencia de stacks con baja latencia y alto rendimiento.
¿Puedo usar NFS para un clúster de virtualización en producción?
Sí. Muchos hipervisores soportan datastores sobre NFS con buen desempeño si la red y la cabina están dimensionadas (10/25 GbE, cache adecuada). Para cargas con E/S aleatoria intensa, iSCSI + VMFS suele ofrecer latencia menor y más IOPS. La elección depende de tu perfil de carga, SLA y coste.
