El dato crece más rápido que el presupuesto. Cada año una organización media multiplica su volumen almacenado, y la tentación de "comprar más disco" choca pronto con un muro de coste, latencia y gestión. Diseñar almacenamiento escalable no consiste en acumular capacidad, sino en colocar cada dato en el medio adecuado, con la redundancia justa y un camino de crecimiento que no obligue a parar el servicio. Este artículo recorre las tres grandes arquitecturas —bloque, fichero y objeto—, el tiering automático que las une y los mecanismos de durabilidad que distinguen un almacenamiento confiable de uno que solo parece confiable hasta el primer fallo.
Bloque, fichero y objeto: tres modelos, tres usos
El almacenamiento de bloque (SAN) expone volúmenes en bruto a través de protocolos como iSCSI o Fibre Channel. El sistema operativo los ve como discos locales y les pone su propio sistema de ficheros encima. Es el modelo de menor latencia y mayor IOPS, ideal para bases de datos transaccionales y máquinas virtuales. Su debilidad: escala mal de forma horizontal y un volumen lo monta normalmente un solo host.
El almacenamiento de fichero (NAS) sirve jerarquías de carpetas y archivos por NFS o SMB/CIFS. Varios clientes comparten el mismo sistema de ficheros, con permisos POSIX o ACL. Es el modelo natural para directorios compartidos, recursos de usuario y aplicaciones que esperan rutas. Escala mejor que el bloque, pero la metadata jerárquica se convierte en cuello de botella a gran escala.
El almacenamiento de objeto (compatible con la API S3) guarda datos como objetos planos identificados por una clave, sin jerarquía real de carpetas, con metadatos ricos y acceso por HTTP. Es el modelo que sostiene el cloud: durabilidad altísima, escalado prácticamente ilimitado y coste por gigabyte bajo, a cambio de mayor latencia y consistencia eventual o fuerte según el proveedor. Es ideal para copias, archivos multimedia, data lakes y backups.
Tabla comparativa de arquitecturas de almacenamiento
| Característica | Bloque (SAN) | Fichero (NAS) | Objeto (S3) |
|---|---|---|---|
| Unidad | Bloque LBA | Fichero en árbol | Objeto + clave |
| Protocolo | iSCSI, FC, NVMe-oF | NFS, SMB | HTTP / API S3 |
| Latencia | Muy baja | Baja-media | Media-alta |
| Escalado | Vertical | Horizontal limitado | Horizontal masivo |
| Caso típico | BBDD, VM | Recursos compartidos | Backup, data lake, media |
| Coste por GB | Alto | Medio | Bajo |
Tiering automático: el dato caliente arriba, el frío abajo
No todos los datos valen lo mismo ni se acceden con la misma frecuencia. El tiering automático mueve los datos entre clases de almacenamiento según patrones de acceso. En la práctica conviven varias capas: hot sobre NVMe/SSD para lo que se lee y escribe ahora; warm sobre SAS o S3 estándar para lo que se accede de forma ocasional; y cold/archive sobre cinta o clases de archivo profundo para lo que casi nunca se toca pero hay que conservar por cumplimiento. Las políticas de ciclo de vida (lifecycle policies) automatizan la transición: un objeto que lleva 30 días sin lecturas baja a una clase más barata, y a los 180 pasa a archivo.
El ahorro es real pero exige diseño: recuperar un dato desde una capa de archivo profundo puede tardar horas y tener coste de extracción. Mover a archivo lo que se necesita con urgencia es un error tan caro como mantener en NVMe lo que nadie consulta.
Escalado horizontal y software-defined storage
La diferencia clave entre un almacenamiento que escala y uno que se queda pequeño está en el modelo de crecimiento. El escalado vertical (scale-up) añade discos a una cabina existente hasta agotar sus controladoras: es simple pero tiene un techo físico y un único punto de fallo. El escalado horizontal (scale-out) añade nodos a un clúster, repartiendo capacidad y rendimiento: cada nodo aporta disco, CPU y red, de modo que el sistema crece de forma lineal sin parada de servicio. Es el modelo de los sistemas distribuidos modernos (Ceph, MinIO o las cabinas scale-out comerciales) y la razón por la que el almacenamiento de objeto puede crecer hasta exabytes.
Sobre esta base se asienta el almacenamiento definido por software (SDS, Software-Defined Storage), que desacopla la lógica de almacenamiento del hardware propietario y la ejecuta sobre servidores estándar. El SDS permite mezclar fabricantes, automatizar el aprovisionamiento por políticas y orquestar volúmenes de forma declarativa —especialmente relevante en entornos de contenedores, donde la CSI (Container Storage Interface) de Kubernetes provisiona volúmenes persistentes bajo demanda—. La contrapartida es que la complejidad se traslada del hardware al software y a las personas: un clúster distribuido mal dimensionado en su red interna o en su factor de réplica rinde peor que una cabina tradicional bien ajustada.
Durabilidad: RAID, erasure coding y la regla 3-2-1
Confiabilidad significa que el dato sobrevive al fallo de hardware. El RAID protege frente a la caída de discos: RAID 6 tolera dos discos simultáneos, pero los tiempos de reconstrucción de discos de gran capacidad son tan largos que aumentan la ventana de riesgo. Por eso el almacenamiento de objeto moderno usa erasure coding, que fragmenta cada objeto en k datos más m de paridad y lo distribuye; con un esquema 10+4 se toleran cuatro fallos a la vez con un sobrecoste de capacidad muy inferior a la triple réplica.
Ningún RAID es un backup. La regla 3-2-1 sigue siendo el estándar de oro de la confiabilidad: tres copias de los datos, en dos tipos de medio distintos, con una de ellas fuera de las instalaciones (offsite). Frente al ransomware se ha extendido la variante 3-2-1-1-0: una copia inmutable o air-gapped y cero errores verificados en las pruebas de restauración. La copia que nunca se ha restaurado no es una copia, es una esperanza.
Rendimiento: IOPS, throughput y latencia no son lo mismo
Dimensionar almacenamiento exige distinguir tres magnitudes que se confunden a menudo. Las IOPS (operaciones de entrada/salida por segundo) miden cuántas peticiones atiende el sistema; importan en cargas de muchas operaciones pequeñas y aleatorias, como una base de datos transaccional. El throughput (MB/s) mide el caudal de datos transferido; manda en cargas secuenciales de ficheros grandes, como copias de seguridad o vídeo. Y la latencia (milisegundos) mide el tiempo de respuesta de cada operación individual, que es lo que el usuario y la aplicación perciben de verdad. Un sistema puede tener IOPS altísimas y aun así sentirse lento si su latencia de cola (los percentiles p99) se dispara bajo carga.
El error de dimensionado más caro es optimizar la magnitud equivocada: comprar discos de altísimo throughput para una base de datos que necesitaba IOPS y baja latencia, o lo contrario. Por eso el diseño correcto parte de caracterizar el patrón de E/S real de cada aplicación —tamaño de bloque, proporción lectura/escritura, aleatoriedad y picos— antes de elegir el medio. El caching en SSD/NVMe delante de capas más lentas y la separación de cargas en pools distintos permiten servir a la base de datos y al repositorio de backups sin que una ahogue a la otra.
Cumplimiento: cifrado, retención y el RGPD
El almacenamiento confiable también es almacenamiento conforme. El RGPD exige cifrado de datos personales en reposo y en tránsito como medida de seguridad apropiada, define plazos de conservación (no se guarda indefinidamente "por si acaso") y obliga a poder ejecutar el derecho de supresión, lo que en object storage con versionado y retención WORM requiere diseño explícito. La inmutabilidad que protege frente a ransomware (Object Lock) puede chocar con el derecho de borrado si no se planifica la convivencia de ambas necesidades. Las buenas prácticas de gestión de seguridad de la información de la familia ISO/IEC 27001 ofrecen el marco de controles para gobernar todo ello.
Errores comunes en arquitectura de almacenamiento
- Usar object storage como sistema de ficheros de baja latencia. La consistencia y la latencia no encajan con cargas transaccionales.
- Confundir RAID con backup. El RAID protege del fallo de disco, no del borrado, la corrupción ni el ransomware.
- No probar las restauraciones. El "cero errores" de la regla 3-2-1-1-0 solo existe si se verifica.
- Tiering sin medir accesos. Mover a archivo datos que se consultan dispara costes de recuperación.
- Ignorar el cifrado en reposo. Un disco extraviado sin cifrar es una brecha notificable bajo RGPD.
Preguntas frecuentes
¿NAS o SAN para una base de datos?
SAN (bloque) por su menor latencia y mayor IOPS. El NAS encaja mejor para ficheros compartidos; algunas bases de datos funcionan sobre NFS, pero el bloque sigue siendo la opción de referencia para cargas transaccionales exigentes.
¿Qué durabilidad ofrece el object storage?
Los proveedores cloud anuncian habitualmente "once nueves" (99,999999999% anual) gracias a la replicación o el erasure coding entre zonas. Esa cifra describe la probabilidad de no perder un objeto por fallo de medio, no exime de mantener backups independientes.
¿Qué es exactamente el tiering automático?
Es el movimiento de datos entre clases de almacenamiento de distinto coste y rendimiento según su frecuencia de acceso, gobernado por políticas de ciclo de vida que las aplican sin intervención manual.
¿La regla 3-2-1 sigue vigente con cloud?
Sí, y se ha reforzado. La nube facilita la copia offsite, pero conviene mantener al menos una copia inmutable y diversificar proveedores o medios para no depender de un único punto de fallo.
Conclusión
El almacenamiento deja de ser un problema de capacidad para convertirse en uno de diseño en cuanto los volúmenes crecen: la pregunta correcta no es "¿cuántos terabytes compro?" sino "¿qué dato vive en cada capa, con qué redundancia y bajo qué política de ciclo de vida?". Un sistema escalable combina bloque para lo transaccional, fichero para lo compartido y objeto para lo masivo, con tiering que abarata lo frío sin penalizar lo caliente y una estrategia 3-2-1-1-0 que sobrevive incluso al ransomware. Y todo ello cifrado y con plazos de retención que cumplen el RGPD. En Summum Sistemas diseñamos esa arquitectura a medida del patrón de acceso real de cada cliente, y verificamos las restauraciones antes de prometer que el dato está a salvo.