SeaweedFS es un sistema de almacenamiento distribuido de objetos construido con Go. Su arquitectura está optimizada para manejar grandes volúmenes de datos multimedia, ofreciendo un rendimiento superior frente a soluciones tradicionales de archivos. Una de sus ventajas clave es la flexibilidad para actuar como back end API, permitiendo modernizar infraestructuras basadas en Nginx o NFS mediante el uso de interfaces REST sin romper la compatibilidad con las estructuras de URL existentes.

A continuación se detalla el proceso de despliegue de sus componentes esenciales: Master, Volume y Filer.

El binario principal se compila directamente desde los releases oficiales. No requiere librerías externas complejas debido a estar compilado en Go.

#!/bin/bash
# Ejemplo de descarga del ejecutable
curl -L https://github.com/seaweedfs/seaweedfs/releases/latest/download/linux_amd64.tar.gz | tar xz

# Verificación del ejecutable
ls -lh weed
./weed help

El componente master actúa como el director lógico del clúster. Su única responsabilidad es mantener el mapa que relaciona dónde residen los volúmenes de datos en los nodos del sistema. Al no gestionar el contenido real de los archivos, consume recursos mínimos y escala eficientemente.

Para iniciar el servicio, se deben definir los parámetros de red y persistencia. En entornos productivos, es crucial configurar múltiples instancias para garantizar alta disponibilidad mediante votación líder.

# Iniciar nodo maestro con configuración básica
/usr/local/bin/weed master \
  --storage_dir=/var/data/master_data \
  --http_port=9334 \
  --peers=192.168.10.50:9334,192.168.10.51:9334 \
  --replication_strategy="000" \
  --ip_bind=192.168.10.50 \
  --garbage_collection_threshold=0.2 >> /var/log/seaweed_master.log 2>&1 &

La salida del registro confirma la incorporación de nuevos servidores de volumen. Un mensaje tipo "added volume server" indica que el nodo ha sido registrado correctamente en el topología global.

Los nodos volume son donde reside físicamente el contenido. Cada volumen es una partición lógica sobre el disco duro, conteniendo un índice (.idx) y datos (.dat). Esto permite búsquedas muy rápidas (complejidad O(1)).

Es necesario asignar correctamente el número máximo de volúmenes permitidos por disco para evitar desperdicio de espacio si el límite por volumen es alto.

# Preparación de directorios
mkdir -p /mnt/volumes/{vol1,vol2}

# Montaje de discos (ejemplo)
mount /dev/sdb1 /mnt/volumes/vol1

# Ejecución de nodos de volumen
/usr/local/bin/weed volume \
  --dir=/mnt/volumes/vol1 \
  --master_addr=192.168.10.50:9334 \
  --ip=192.168.10.55 \
  --port=8083 \
  --max_volumes=50 \
  --datacenter="zona-a" \
  --rack="rack-1" >> /var/log/volume_1.log 2>&1 &

Al revisar el archivo de salida, observamos confirmaciones de carga de índices y creación de nuevas colecciones de datos.

La interacción estándar implica un flujo de tres pasos: solicitar una ubicación (FID), subir el objeto usando la dirección recibida, y acceder posteriormente.

# Paso 1: Asignar ID de archivo
curl http://192.168.10.50:9334/dir/assign

# Salida: {"fid":"1,abcde...","url":"192.168.10.55:8083", ...}

# Paso 2: Subir el dato POST
curl -X POST -F file=@foto.jpg http://192.168.10.55:8083/1,abcde...

# Paso 3: Acceso directo mediante GET
curl http://192.168.10.55:8083/1,abcde...

Para simplificar este proceso, existe un endpoint especial /submit que realiza la asignación y subida en una sola petición HTTP, reduciendo la latencia de control.

Las organizaciones suelen operar inicialmente con arquitecturas Nginx + NFS. Aunque simplifican el desarrollo inicial, enfrentan limitaciones significativas al escalar:

• Limitaciones de E/S: El bloqueo de archivos y concurrencia en sistemas de archivos compartidos afecta el rendimiento bajo carga pesada.
• Cumplimiento Normativo y Backup:
• Puntos Únicos de Fallo:

SeaweedFS mitiga estos problemas al ofrecer escalado horizontal lineal, replicación automática y acceso puramente basado en red sin montaje de sistemas de archivos en clientes finales.

La transición de métodos de acceso basados en ruta (/carpetas/archivo.jpg) a IDs directos (ID_OBJETO) puede romper aplicaciones legacy. Para resolver esto, SeaweedFS incluye el componente Filer.

El Filer expone una interfaz HTTP que permite manipular objetos utilizando jerarquías de directorios, actuando como una capa de traducción entre rutas legibles y IDs internos. Además, permite montar el sistema de archivos remotamente para acceso transparente mediante herramientas estándar.

# Arranque del servicio Filer
/usr/local/bin/weed filer \
  --master_addr=192.168.10.50:9334 \
  --ip=192.168.10.50 \
  --port=8888 \
  --disableDirListing=false \
  >> /var/log/filer.log 2>&1 &

Una vez activo, se puede montar el sistema de archivos para visualización física:

# Montaje local (requiere FUSE)
fusermount -u /mnt/local_fuse 2>/dev/null || true
/usr/local/bin/weed mount \
  --filer=192.168.10.50:8888 \
  --dir=/mnt/local_fuse

Por defecto, el mapeo de rutas se mantiene en memoria. Para persistencia en producción, se debe configurar un almacén externo.

[scaffold config]

Generando el archivo de configuración inicial para especificar el backend de estado.

# Edición de config.toml para habilitar Redis
[storage]
enabled = true
backend = "redis"

[redis]
host = "192.168.10.100"
port = 6379
password = ""
key_prefix = "swfs_path_map"

Reiniciando el servicio Filer aplicará esta configuración. Ahora todas las operaciones de ruta (crear, leer, borrar en carpetas) actualizarán automáticamente la base de datos Redis, asegurando la durabilidad del esquema de directorios aunque el nodo Filer tenga fallos temporales. Si el servicio de Redis falla, la funcionalidad basada en ruta se ve afectada, aunque el almacenamiento subyacente seguirá operando correctamente mediante IDs directos.