NAS o SAN: diferencias y cómo elegir almacenamiento en red

NAS (Network Attached Storage) y SAN (Storage Area Network) describen formas distintas de ofrecer almacenamiento a través de una infraestructura de red. En términos generales, un NAS sirve archivos y directorios a clientes; una SAN proporciona almacenamiento en bloques que un servidor puede utilizar como dispositivo de almacenamiento. La diferencia no es simplemente el tamaño del equipo ni la cantidad de discos: importa qué recurso ve el sistema cliente y quién administra el sistema de archivos.

En un NAS, el dispositivo o servidor de almacenamiento suele encargarse del sistema de archivos y publica recursos compartidos para los usuarios o aplicaciones. En una SAN, el servidor conectado recibe volúmenes o unidades lógicas y, normalmente, administra sobre ellos su propio sistema de archivos. Por eso, llamar “NAS” a cualquier servidor con discos compartidos o “SAN” a cualquier almacenamiento rápido puede ocultar decisiones importantes de acceso, administración y compatibilidad.

Las dos arquitecturas pueden emplearse en una empresa y pueden coexistir. Una organización podría compartir carpetas de equipo mediante NAS y reservar una SAN para servidores que requieren volúmenes de bloques. No hay una ganadora universal: si el problema es facilitar el acceso a documentos, la elección no se resuelve con las mismas prioridades que si una aplicación necesita gestionar un volumen de bloques.

Con acceso a archivos, el cliente solicita acciones sobre elementos identificables como archivos y directorios: abrir, leer, escribir o modificar atributos. Los usuarios pueden navegar por carpetas compartidas y las aplicaciones trabajan con rutas y permisos proporcionados por el servicio. Protocolos como SMB y NFS sirven para este modelo. Los clientes ven una estructura de archivos compartida, aunque la implementación y las opciones disponibles dependen del servidor y del protocolo.

Con acceso a bloques, el almacenamiento presenta una unidad lógica al servidor como un dispositivo que puede particionar o formatear. El protocolo transmite operaciones sobre bloques, no una carpeta lista para explorar. El sistema operativo del servidor gestiona el sistema de archivos, mientras que el almacenamiento de fondo proporciona los bloques. iSCSI es una forma estandarizada de transportar comandos de almacenamiento SCSI sobre redes IP; su especificación describe el protocolo, no garantiza por sí misma rendimiento, disponibilidad ni facilidad de despliegue.

La distinción tiene consecuencias operativas. En el modelo de archivos, la gestión de permisos, rutas compartidas y acceso de varios clientes forma parte central del servicio. En el de bloques, hay que definir quién presenta y consume cada volumen y cómo se evita que varios servidores escriban sobre un sistema de archivos que no esté diseñado para acceso concurrente. No debe suponerse que un volumen de bloques compartido puede montarse de forma segura en varios servidores: eso depende del sistema de archivos, del clúster y de la configuración compatible.

SMB es una familia de protocolos para compartir archivos en red, ampliamente asociada a entornos Windows, aunque su uso no se limita a un único sistema operativo. La documentación de Microsoft describe funciones del protocolo y su implementación en Windows y Windows Server. Para valorar un NAS, conviene comprobar qué versiones de SMB ofrece el dispositivo, qué opciones de autenticación y permisos admite y si las funciones que necesita la organización son compatibles con sus clientes. El nombre del protocolo por sí solo no responde a esas preguntas.

NFS también ofrece acceso a archivos y directorios a través de la red. Su documentación en Windows Server explica el soporte de NFS en ese sistema; las opciones efectivas dependen de la versión y la implementación de servidor y cliente. Si conviven sistemas Unix o Linux con otras plataformas, hay que verificar la interoperabilidad concreta: versiones compatibles, asignación de identidades, permisos, bloqueo de archivos y configuración de exportaciones. NFS no convierte automáticamente un equipo en SAN: sigue siendo un protocolo de acceso a archivos.

iSCSI se utiliza para presentar almacenamiento en bloques por redes IP. La RFC 7143 define el protocolo iSCSI, mientras que la RFC 7146 trata requisitos de seguridad para protocolos de almacenamiento en bloques sobre IP mediante IPsec. Son referencias técnicas para entender el ámbito de cada tecnología, pero no sustituyen la documentación del fabricante, el diseño de red ni las políticas de seguridad. Antes de escoger iSCSI, confirma que los iniciadores, destinos, sistemas operativos y herramientas de administración previstos sean compatibles.

La cifra de capacidad anunciada no basta para comparar despliegues. Hay que dimensionar la red para las cargas de trabajo previstas y revisar congestión, redundancia, latencia, rutas alternativas y posibles puntos únicos de fallo. Una SAN puede usar iSCSI sobre Ethernet; por tanto, no debe darse por hecho que toda SAN exige una red física separada. Aun así, separar o segmentar el tráfico de almacenamiento puede ser una decisión de diseño pertinente, que requiere evaluar operación, aislamiento y disponibilidad en el entorno concreto.

La carga de administración también es parte del coste. En NAS, el equipo responsable puede gestionar recursos compartidos, usuarios, cuotas, permisos, copias de seguridad y actualizaciones del servicio. En SAN, además de administrar los volúmenes, puede ser necesario coordinar su presentación a los servidores, la conectividad, la multipath y la administración del sistema de archivos en los hosts. Son responsabilidades habituales de diseño, no una lista idéntica para todos los productos: las funciones incluidas y el trabajo requerido varían según la solución.

La seguridad debe revisarse extremo a extremo. Identifica cómo se autentican los clientes, cómo se autorizan los accesos, qué tráfico puede alcanzar los servicios de almacenamiento y cómo se protegen las comunicaciones según la arquitectura y el producto. Para iSCSI, la RFC 7146 aporta contexto sobre la protección de protocolos de bloques sobre IP; no permite concluir que una instalación particular esté protegida. Documenta también el control de cambios, la recuperación ante fallos y las pruebas de restauración. La redundancia no reemplaza a las copias de seguridad: protege frente a ciertos fallos, pero no necesariamente frente a borrados, errores de operación o incidentes que afecten a los datos replicados.

No es riguroso afirmar que NAS siempre cuesta menos o que SAN siempre escala mejor sin fijar capacidad, rendimiento, disponibilidad, soporte y horizonte de uso. La comparación económica debería incluir almacenamiento, red y adaptadores necesarios, licencias, garantías, consumo, espacio, soporte y horas de administración. Un NAS sencillo puede reducir trabajo inicial en un escenario de carpetas compartidas; una necesidad de bloques integrada en servidores puede justificar una SAN. Son hipótesis de evaluación, no una conclusión aplicable a cualquier proveedor.

Pide a cada alternativa que responda a la misma carga de trabajo y al mismo nivel de servicio. Define cuánto espacio útil se necesita, qué crecimiento se espera, cuántos clientes acceden, qué patrón de lectura y escritura importa y qué tiempo de recuperación se requiere. Después comprueba si la documentación del producto respalda esas características y qué componentes quedan fuera de la oferta. No compares una capacidad bruta con capacidad utilizable ni una cifra máxima comercial con una garantía de rendimiento para tu carga.

También conviene separar capacidad de facilidad de ampliación. Comprueba los límites documentados de unidades, volúmenes, clientes, protocolos y expansión; las condiciones de soporte y las rutas de migración. Las guías generales de almacenamiento ayudan a entender las categorías, pero no acreditan prestaciones de un equipo concreto. Sin modelo, configuración y condiciones de uso definidos, no hay base para publicar una comparación de precios o rendimiento entre soluciones.

Como primer filtro, identifica qué necesitan consumir las aplicaciones: carpetas compartidas, o volúmenes de bloques administrados por los servidores. Después valida protocolos y sistemas operativos, y finalmente asigna un responsable a las tareas de operación, seguridad y recuperación. Este orden evita elegir por una cifra aislada de velocidad o por el nombre de una arquitectura.

La tabla es un punto de partida, no una certificación de que una tecnología sea adecuada para un caso particular. Algunas soluciones comerciales combinan servicios de archivos y bloques; esa combinación no borra las diferencias entre los modelos de acceso ni demuestra que todos los protocolos estén disponibles en cada configuración. Verifica capacidades específicas en la documentación del modelo que se vaya a desplegar y en las versiones de software correspondientes.

Antes de decidir, reúne una descripción de aplicaciones, clientes, datos y objetivos de recuperación. Si la organización no puede especificar todavía requisitos de latencia, disponibilidad, crecimiento o concurrencia, conviene registrar esos huecos y no presentar una elección preliminar como definitiva. Tampoco es necesario empezar por una marca: primero se establece el patrón de acceso y después se evalúan productos capaces de atenderlo.

Una lista breve de validación ayuda a convertir la comparación en una decisión verificable:

• ¿La aplicación requiere acceso a archivos o acceso a bloques?
• ¿Qué versiones de SMB, NFS o iSCSI admite cada extremo?
• ¿Cómo se asignan identidades y permisos, y quién administra volúmenes y recursos compartidos?
• ¿Qué diseño de red, redundancia y aislamiento requiere la solución?
• ¿Cómo se hacen copias, se verifica la restauración y se gestiona una interrupción?
• ¿Qué costes de compra, soporte, operación y ampliación se incluyen en el cálculo?

La respuesta más útil suele ser una arquitectura ajustada a los requisitos demostrables, no una etiqueta más prestigiosa. Para compartir archivos, empieza por evaluar NAS y sus protocolos; cuando el servidor necesita gestionar bloques, examina SAN o servicios equivalentes y sus requisitos de coordinación. Si hay ambas necesidades, considera cubrirlas de forma diferenciada. Decide con requisitos, compatibilidad y responsabilidades documentadas, y deja explícito lo que todavía no se ha medido o confirmado.