El almacenamiento es donde la mayoría de los proyectos de nube privada triunfan o fracasan en silencio. El cómputo es fácil de razonar y fácil de reemplazar. La red está bien entendida. El almacenamiento es la capa que sostiene tu estado, carga con tus obligaciones de cumplimiento normativo y es lo más difícil de migrar una vez que está lleno. Si estás construyendo una nube soberana o privada, el almacenamiento es el cimiento y, por lo general, la parte más profunda del proyecto.
Esta es una recorrido neutral sobre lo que realmente significa el almacenamiento soberano, las capas que necesitas diseñar y un mapa honesto de las opciones open source. Construimos estos sistemas para ganarnos la vida y no vendemos un producto de almacenamiento, así que el objetivo aquí es ayudarte a elegir bien, no empujarte un stack.
Por qué el almacenamiento es la parte difícil
Tres cosas convierten al almacenamiento en el rincón complicado de una nube privada.
Primero, tiene estado. Puedes vaciar y reconstruir un nodo de cómputo en minutos. No puedes hacer eso con la única copia de tus datos. Cada decisión de diseño en torno a la replicación, la codificación de borrado (erasure coding) y la copia de seguridad es una decisión sobre cuánta pérdida de datos y cuánto tiempo de inactividad puedes tolerar.
Segundo, es donde la soberanía se vuelve real. Una carga de trabajo que se ejecuta en un centro de datos de la UE sigue filtrando soberanía si la capa de almacenamiento la opera una entidad sujeta a leyes extranjeras de divulgación. La residencia de datos y la soberanía de datos no son lo mismo. La residencia es dónde se ubican físicamente los bytes. La soberanía es quién tiene el control legal y técnico sobre ellos. Los datos alojados en una región de Frankfurt de un hyperscaler operado por EE. UU. todavía pueden caer bajo la CLOUD Act estadounidense, que puede obligar a una empresa de EE. UU. a entregar datos sin importar dónde estén almacenados. El EDPB ha sido explícito en que el cifrado fuerte con claves bajo control exclusivo del EEE es la medida complementaria que aborda esta exposición. El almacenamiento es exactamente donde implementas ese control.
Tercero, es implacable a nivel operativo. Los sistemas de almacenamiento distribuido tienen modos de fallo que solo aparecen a escala o bajo carga: split-brain, reconstrucciones lentas, amplificación de escritura, condiciones de clúster lleno. Acertar en esto requiere un diseño deliberado, no valores por defecto.
Las tres capas: bloque, archivo, objeto
Una nube privada completa suele necesitar los tres tipos de almacenamiento. No son intercambiables.
El almacenamiento de bloque presenta volúmenes en bruto a un host, como un disco virtual. Es lo que quieren las máquinas virtuales y las bases de datos: baja latencia, lectura y escritura aleatorias, semántica de un solo escritor. El bloque es la columna vertebral de las cargas de trabajo de hipervisor y de los pods de Kubernetes con estado.
El almacenamiento de archivo presenta un sistema de archivos POSIX compartido que muchos clientes pueden montar a la vez. Encaja con datos de aplicación compartidos, directorios personales, pipelines de medios y software heredado que espera una ruta en disco. El compromiso es que la semántica POSIX distribuida es genuinamente difícil, así que los sistemas de archivos tienden a ser la capa más compleja de operar bien.
El almacenamiento de objetos presenta los datos como objetos en buckets planos, accedidos por HTTP con una API de estilo S3. No hay sobrescritura en el lugar ni jerarquía de sistema de archivos. A cambio obtienes una escala horizontal prácticamente ilimitada, metadatos integrados y un encaje limpio para copias de seguridad, data lakes, registros (logs), corpus de entrenamiento de IA y activos de aplicación. El almacenamiento de objetos es el hogar natural del grueso de los datos no estructurados, razón por la cual se sitúa en el centro de la mayoría de los diseños de almacenamiento soberano.
El almacenamiento definido por software, en breve
El almacenamiento definido por software (SDS) desacopla la lógica de almacenamiento del hardware. En lugar de un appliance propietario, ejecutas software abierto sobre servidores genéricos y dejas que se encargue de la colocación, la replicación y la reparación. Eso es lo que hace alcanzable el almacenamiento soberano: la inteligencia es abierta, auditable y tuya, y el hardware es intercambiable. El costo es que asumes la complejidad operativa, ya sea con tu propio equipo o a través de un socio de servicios gestionados.
Dos estrategias de protección de datos atraviesan todo lo que sigue:
- La replicación mantiene N copias completas de cada pieza de datos. Es simple, rápida de recuperar, pero hambrienta de almacenamiento: una replicación 3x significa 3 TB de disco en bruto por cada 1 TB de datos utilizables.
- La codificación de borrado (erasure coding) divide los datos en fragmentos más paridad, de modo que sobrevives a los fallos usando mucha menos capacidad en bruto. Un perfil de borrado típico te da una resiliencia similar a la replicación 3x necesitando aproximadamente 1,5x de capacidad en bruto. El compromiso es más CPU, escrituras pequeñas más lentas y reconstrucciones más largas.
Un mapa amplio de las opciones open source
No hay una única herramienta correcta. La elección correcta depende de la escala, los protocolos que necesitas, la profundidad de tu equipo y dónde vive la carga de trabajo. Aquí va un panorama honesto.
Ceph es la plataforma SDS unificada de referencia. Un solo clúster sirve las tres capas: RBD para bloque, CephFS para archivo y el RADOS Gateway (RGW) para almacenamiento de objetos compatible con S3 y Swift. Escala a petabytes, soporta replicación y codificación de borrado, y se autorrepara. El costo es una complejidad operativa real, es el sistema más exigente de operar de forma segura aquí, y es hambriento de RAM y CPU. Rook es el operador que ejecuta Ceph de forma nativa dentro de Kubernetes y elimina gran parte del trabajo del día a día. Ceph es la respuesta por defecto cuando quieres una sola plataforma para todo a escala.
LINSTOR con DRBD toma un camino distinto: replicación de bloque a nivel de kernel, esencialmente un RAID-1 síncrono entre servidores, orquestado por LINSTOR. Ofrece un rendimiento de disco casi nativo con muy poca sobrecarga, lo que lo hace fuerte para bases de datos y VMs sensibles a la latencia. Es solo de bloque, y su configuración implica módulos del kernel y LVM, por lo que es menos plug-and-play. Piraeus lleva LINSTOR a Kubernetes.
Para el almacenamiento de objetos compatible con S3 específicamente, el campo ha cambiado recientemente y vale la pena conocerlo:
- MinIO fue durante años el servidor S3 ligero por defecto. Su edición comunitaria está ahora efectivamente al final de su vida útil: la consola de administración fue retirada, la distribución de binarios se detuvo y el repositorio de GitHub fue archivado en febrero de 2026. La licencia AGPL que adoptó significa que el código puede ser (y ha sido) bifurcado, pero la edición comunitaria upstream ya no se mantiene. Trata las implementaciones existentes como algo que necesita un plan de migración.
- Garage es un almacén de objetos ligero y distribuido diseñado para implementaciones georredundantes en sitios separados. Sin nodo maestro, todos pares (peers), colocación de réplicas consciente de zona, corre en hardware modesto y en ARM. Excelente para soberanía multisitio y de borde (edge). AGPL-3.0.
- SeaweedFS es maduro, rápido y especialmente bueno con un número muy grande de objetos pequeños. Ofrece S3, FUSE y WebDAV, tiene una integración sólida con Kubernetes y está licenciado bajo Apache-2.0. Una opción de propósito general fuerte a escala.
Para volúmenes persistentes nativos de Kubernetes:
- Longhorn es el almacenamiento de bloque distribuido más simple para Kubernetes: fácil de operar, buena interfaz de usuario, instantáneas (snapshots) y copias de seguridad integradas. Es lo mejor para borde (edge) y clústeres pequeños a medianos; la latencia puede dispararse bajo carga pesada.
- OpenEBS es modular; su motor Mayastor da altas IOPS con menor costo de CPU que Ceph, centrado en el bloque, sin funciones de objeto.
Para el sustrato de almacenamiento en sí:
- ZFS es el estándar de oro del sistema de archivos local: sumas de verificación (checksumming), instantáneas, compresión, cifrado nativo. Sustenta muchos de los sistemas anteriores como la capa de cada nodo.
- GlusterFS es un sistema de archivos de red escalable que todavía se encuentra en producción, aunque el impulso se ha movido claramente hacia Ceph y los diseños orientados a objetos para construcciones nuevas.
El almacenamiento compatible con S3 como alternativa soberana a AWS S3
La API de S3 se ha convertido en el estándar de facto para el almacenamiento de objetos, lo cual es una buena noticia para la soberanía. Como tanto software habla S3, puedes ejecutar un almacén compatible con S3 en tu propia infraestructura (Ceph RGW, Garage, SeaweedFS) y mantener el mismo código de aplicación, las mismas herramientas de copia de seguridad, los mismos motores de data lake, mientras tus datos permanecen en tu jurisdicción bajo tus claves. Obtienes la ergonomía para el desarrollador de S3 sin la exposición legal de una nube operada por extranjeros. Este es el movimiento de mayor apalancamiento en la mayoría de los diseños de almacenamiento soberano.
Cifrado, control de claves y residencia
La soberanía se hace cumplir en la frontera de las claves, no en la pared del centro de datos.
- El cifrado en reposo debería estar activado en cada capa que lo soporte, desde ZFS hasta la pasarela (gateway) de objetos.
- El control de claves es el punto. Si un tercero puede descifrar tus datos, no eres soberano sin importar dónde vivan los discos. Mantén las claves en un KMS o HSM controlado por la UE, separado del operador de almacenamiento, de modo que ninguna entidad extranjera pueda obligar a la divulgación de datos utilizables.
- La residencia sigue importando: fija la colocación en regiones de la UE y demuéstralo. Pero la residencia sin control de claves es puro teatro.
Copias de seguridad y recuperación ante desastres
La replicación no es una copia de seguridad. Copia fielmente tus errores. Un diseño de almacenamiento soberano real tiene copias de seguridad independientes (idealmente inmutables, al estilo object-lock) y un plan de DR probado: replicación entre sitios para datos de objeto, recuperación basada en instantáneas para bloque y archivo, y simulacros de restauración periódicos. El fallo que no has ensayado es el que te va a doler.
Autogestionado o gestionado
El SDS open source elimina el bloqueo por licencias (lock-in), no la carga operativa. La división honesta:
- Autogestionado cuando tienes un equipo de plataforma capaz en almacenamiento y quieres control total. Presupuesta una guardia (on-call) real y experiencia profunda; Ceph en particular castiga a las plantillas escasas.
- Gestionado cuando quieres almacenamiento soberano y open source, pero no un busca (pager) a las 3 de la madrugada por un clúster degradado. Un socio neutral puede diseñar, construir y operar el stack en tu infraestructura, en tu jurisdicción, con tus claves, y devolvértelo cuando lo quieras.
Preguntas frecuentes
¿Basta con el almacenamiento de objetos por sí solo? Rara vez. El objeto cubre el grueso de los datos no estructurados, pero las VMs y las bases de datos necesitan bloque, y los datos de aplicación compartidos a menudo necesitan archivo. La mayoría de las nubes privadas ejecutan los tres.
¿Ceph o algo más ligero? Ceph si quieres una sola plataforma para bloque, archivo y objeto a escala y puedes dotarla de personal. Las herramientas más ligeras y de un solo propósito (Garage o SeaweedFS para objeto, Longhorn o LINSTOR para bloque) son más fáciles de operar cuando no necesitas una plataforma unificada.
¿Compatible con S3 significa exactamente igual que AWS S3? La API central es ampliamente compatible, razón por la cual las migraciones suelen ser fluidas. Las funciones de borde (edge features) y las garantías de consistencia varían, así que valida las operaciones específicas de las que dependen tus aplicaciones.
¿Qué pasa con la situación de MinIO? La edición comunitaria ya no se mantiene desde principios de 2026. Los usuarios existentes deberían planificar una migración a una alternativa mantenida o a un fork con soporte.
Dónde encaja Rapid Solutions
Somos una consultoría de ingeniería neutral y un socio de servicios gestionados, no un proveedor de nube. Diseñamos y operamos almacenamiento soberano, open source primero, sobre infraestructura que tú controlas, con residencia de datos en la UE y claves que permanecen en tus manos. Nos adaptamos a tu stack en lugar de venderte el nuestro.
Si estás planificando una nube privada o repensando dónde viven tus datos, habla con nosotros.