VaultS3 quiere simplificar el almacenamiento S3 privado con solo 17 MiB de RAM

VaultS3 se presenta como una nueva alternativa para desplegar almacenamiento de objetos compatible con Amazon S3 dentro de infraestructura propia, con una propuesta poco habitual: un único binario, sin servicios externos obligatorios y un consumo en reposo que su desarrollador sitúa alrededor de 17 MiB de memoria. El proyecto entra en un mercado donde conviven desde servicios gestionados como Amazon S3 hasta plataformas de código abierto consolidadas como Ceph, Garage o SeaweedFS.

Las claves de VaultS3 en 20 segundos

  • VaultS3 implementa más de 80 operaciones de la API S3 y funciona como un único binario.
  • Su desarrollador mide unos 17 MiB de RAM en reposo, aunque el consumo aumenta con carga.
  • Incorpora cifrado, IAM, OIDC, versionado, Object Lock, métricas Prometheus y erasure coding.
  • Compite con alternativas como Ceph, Garage, SeaweedFS y servicios gestionados como Amazon S3.
  • El modo distribuido de VaultS3 todavía tiene componentes considerados beta.

La compatibilidad con S3 se ha convertido en una pieza habitual de muchas arquitecturas de almacenamiento. Aplicaciones de backup, plataformas de análisis, repositorios de datos, Kubernetes y numerosas herramientas empresariales pueden utilizar esta interfaz independientemente de que detrás se encuentre el servicio de Amazon Web Services (AWS) o una plataforma instalada en servidores propios.

VaultS3 intenta ocupar precisamente ese segundo espacio, pero evitando parte de la complejidad que acompaña a algunas soluciones distribuidas. El proyecto está desarrollado principalmente en Go y se distribuye bajo licencia AGPL-3.0.

De 17 MiB en reposo a unos 185 MiB trabajando

La cifra que más fácilmente puede llamar la atención es su consumo de memoria. Según las pruebas publicadas por el propio proyecto, VaultS3 utiliza alrededor de 17 MiB de RAM cuando permanece inactivo.

No significa que pueda atender cualquier carga de almacenamiento utilizando esa cantidad.

En una prueba escribiendo objetos de 64 MiB con una concurrencia de 16 operaciones, el consumo puede aproximarse a 185 MiB. La memoria necesaria dependerá por tanto del número de conexiones, tamaño de los objetos y carga que reciba el servidor.

Además, las comparaciones disponibles proceden fundamentalmente del propio proyecto y no constituyen un benchmark independiente. Conviene interpretar los 17 MiB como una referencia sobre la ligereza del proceso base, no como un requisito fijo para producción.

VaultS3 concentra buena parte de sus funciones en un solo ejecutable. No necesita una base de datos externa para empezar a funcionar y utiliza BoltDB para almacenar metadatos. También dispone de imágenes Docker, paquetes para varias distribuciones Linux y opciones para Kubernetes.

A esto añade una interfaz web integrada, autenticación Signature Version 4 de AWS, IAM, integración con OIDC y LDAP, cifrado AES-256-GCM, políticas por bucket, métricas Prometheus y diferentes mecanismos de protección de datos.

VaultS3 frente a Ceph, Garage y SeaweedFS

El almacenamiento compatible con S3 tiene suficientes alternativas como para que el consumo de memoria no pueda ser el único criterio de selección.

Una comparación aproximada ayuda a situar dónde encaja cada propuesta:

SoluciónModeloAPI S3ComplejidadOrientación principal
VaultS3Open source, AGPL-3.0Baja en nodo únicoLabs, edge, homelab y almacenamiento privado ligero
CephOpen sourceSí, mediante RGWAltaClústeres empresariales y almacenamiento distribuido
GarageOpen sourceMedia-bajaAlmacenamiento distribuido ligero
SeaweedFSOpen sourceMediaObject/file storage distribuido
MinIO AIStorComercial, con opciones de evaluación/free tier según modalidadMediaAlmacenamiento S3 empresarial
Amazon S3Servicio cloud gestionadoNativaBaja para el usuarioObject storage cloud a gran escala

La tabla no pretende establecer un ganador porque las arquitecturas son bastante diferentes.

Ceph, por ejemplo, juega en otra categoría. Ceph puede proporcionar almacenamiento de objetos, bloques y archivos sobre un mismo clúster distribuido. Su RADOS Gateway (RGW) implementa una amplia parte de la API de Amazon S3 y dispone de funciones como versionado, lifecycle, políticas, cifrado, IAM y configuraciones multisite.

Esa capacidad tiene un coste operativo. Un despliegue Ceph implica varios componentes y normalmente varios servidores o dispositivos OSD para construir una plataforma redundante. La propia documentación señala que normalmente se requieren al menos tres OSD para disponer de redundancia y alta disponibilidad.

VaultS3 busca prácticamente el extremo contrario: empezar con un servidor pequeño y una configuración sencilla.

Garage también resulta interesante en esa comparación porque nació con una filosofía de almacenamiento distribuido relativamente ligero y pensado para funcionar incluso sobre hardware y conexiones heterogéneas. VaultS3 intenta diferenciarse incorporando dentro del mismo proyecto funcionalidades adicionales de administración y protección del dato.

SeaweedFS, por su parte, tiene un alcance mayor que un simple servidor S3. Su arquitectura distribuida puede utilizar diferentes componentes para gestionar volúmenes, metadatos y acceso a los datos. Eso aumenta las posibilidades de despliegue, pero también introduce más elementos que administrar.

MinIO ya no ocupa exactamente el mismo espacio que hace unos años

También hay que mencionar a MinIO porque durante años ha sido una de las referencias más conocidas cuando se buscaba desplegar almacenamiento compatible con S3 fuera de AWS.

Su situación comercial y de licenciamiento ha cambiado.

La documentación actual de MinIO establece una licencia propia para el software distribuido por la compañía y limita, sin un acuerdo Enterprise activo, el software cubierto por dicha licencia a una instancia para evaluación interna no productiva. La empresa comercializa actualmente su plataforma bajo la familia AIStor.

Por tanto, comparar directamente el actual MinIO AIStor con un proyecto AGPL como VaultS3 únicamente bajo la etiqueta de «open source S3» puede resultar engañoso.

VaultS3 intenta precisamente recuperar parte de la experiencia que hizo atractivas a las primeras plataformas S3 autogestionadas: descargar un programa, ejecutarlo y disponer rápidamente de un endpoint compatible con clientes S3.

Amazon S3 resuelve un problema diferente

El otro extremo de la comparación es Amazon Web Services S3.

AWS administra la infraestructura física, la redundancia, la sustitución de hardware y buena parte de la disponibilidad de la plataforma. En una solución autogestionada como VaultS3, esas responsabilidades recaen sobre quien opera los servidores.

Eso cambia completamente la ecuación económica.

Un servidor S3 propio puede resultar interesante cuando existe una cantidad elevada de datos locales, cuando se quiere evitar que determinadas cargas abandonen la infraestructura de la organización o cuando el coste de transferir grandes cantidades de información hacia y desde servicios cloud resulta relevante.

Pero el software no convierte automáticamente un servidor en un servicio equivalente a Amazon S3.

La durabilidad final dependerá de cómo estén configurados los discos, las copias de seguridad, la replicación, los servidores y los centros de datos.

Erasure coding y replicación amplían sus posibilidades

VaultS3 no está limitado a guardar una única copia de cada objeto en un disco. El proyecto implementa erasure coding Reed-Solomon, versionado, Object Lock, backups programados y procesos de recuperación de fragmentos dañados.

También dispone de clustering mediante Raft, consistent hashing y replicación active-active.

Aquí aparece una de sus principales limitaciones actuales.

El propio proyecto diferencia entre las funciones consideradas estables y aquellas que todavía están en desarrollo. Los despliegues de un único nodo, incluido el uso de erasure coding entre varios discos, son el escenario más maduro. Algunas funciones de clustering y replicación distribuida permanecen en beta.

Para un laboratorio doméstico esta diferencia puede resultar secundaria. Para una empresa que pretende almacenar terabytes de backups o información que no puede perder, cambia por completo el análisis.

Un sistema de almacenamiento no se evalúa únicamente por cuánta memoria consume cuando arranca. Importan la recuperación ante fallos, consistencia de los datos, comportamiento durante particiones de red, actualización entre versiones, monitorización y capacidad para reconstruir grandes volúmenes después de perder discos o servidores.

Una opción especialmente atractiva para laboratorios y edge

VaultS3 tiene por ahora un posicionamiento bastante claro. Su bajo consumo y facilidad de instalación pueden convertirlo en una opción interesante para homelabs, laboratorios de desarrollo, pequeños servidores, dispositivos edge o aplicaciones que necesiten un endpoint S3 local.

También puede servir para probar aplicaciones diseñadas para S3 sin depender continuamente de un servicio externo.

Para instalaciones empresariales de mayor tamaño, Ceph ofrece una arquitectura distribuida mucho más veterana y un conjunto considerablemente más amplio de posibilidades. Ceph RGW incluso permite utilizar políticas IAM, OpenID Connect, LDAP, cifrado y configuraciones multisite sobre el almacenamiento distribuido de Ceph.

Los servicios gestionados como Amazon S3 resuelven otra parte del problema: trasladan la operación de la infraestructura al proveedor a cambio de adoptar su modelo de consumo y costes.

VaultS3 intenta encontrar espacio entre ambos extremos. Su verdadero examen llegará cuando aumenten los despliegues reales y pueda comprobarse cómo se comportan sus funciones distribuidas bajo cargas sostenidas, actualizaciones y fallos de hardware.

Mientras tanto, esos 17 MiB de RAM en reposo sirven para llamar la atención sobre algo más interesante: todavía existe margen para construir almacenamiento compatible con S3 sin que el punto de partida tenga que ser necesariamente un clúster complejo.

Preguntas frecuentes

¿VaultS3 es compatible con Amazon S3?

Implementa más de 80 operaciones de la API S3 y funciona con herramientas y SDK compatibles, aunque eso no significa que reproduzca todas las funciones de Amazon S3.

¿VaultS3 puede sustituir a Ceph?

Depende del escenario. VaultS3 busca simplicidad y bajo consumo, mientras que Ceph está diseñado para construir grandes sistemas distribuidos de almacenamiento de objetos, bloques y archivos.

¿VaultS3 realmente utiliza solo 17 MiB de RAM?

Es la cifra medida por el desarrollador con el servidor en reposo. Bajo carga el consumo aumenta; una de las pruebas publicadas ronda los 185 MiB al escribir objetos de 64 MiB con concurrencia 16.

¿VaultS3 está preparado para producción?

Su escenario de nodo único es el más maduro. Algunas capacidades distribuidas, entre ellas componentes relacionados con clustering y replicación active-active, todavía están clasificadas como beta, por lo que deberían probarse cuidadosamente antes de almacenar información crítica.

encuentra artículos

newsletter

Recibe toda la actualidad del sector tech y cloud en tu email de la mano de RevistaCloud.com.

Suscripción boletín

LO ÚLTIMO