GlusterFS
GlusterFS es un sistema de archivos distribuido y escalable que permite agrupar múltiples servidores de almacenamiento en una sola unidad lógica. Esto nos permite crear un sistema de almacenamiento redundante y altamente disponible para nuestros datos, lo que es especialmente útil en entornos de producción donde la disponibilidad y la integridad de los datos son críticas.
Prerequisitos
Debe estar instalado el swarm en cada una de las maquinas que formarán parte del clúster de GlusterFS. Además, es necesario tener acceso root o privilegios sudo en todas las máquinas. Cada maquina debe tener un segundo disco duro o una partición dedicada exclusivamente para GlusterFS. las maquinas deben poder comunicarse entre sí a través de la red.
Definición de Variables (Para este ejemplo) Disco secundario: /dev/sdb (Asegúrate de verificar cuál es tu disco real con lsblk).
lsblk
Nombre del volumen: vol_datos
Directorio de montaje: /mnt/gluster_data
Instalación de GlusterFS
- Instala GlusterFS en cada máquina:
# Para Debian/Ubuntu
sudo apt-get update
sudo apt-get install -y glusterfs-server
# Para CentOS/RHEL
# sudo dnf install -y glusterfs-server
# Iniciar el servicio y habilitarlo para que arranque al inicio
sudo systemctl enable --now glusterd
- Preparación del Disco
Ejecutar en LOS 3 NODOS
Formateamos el segundo disco (recomendado XFS para GlusterFS) y lo montamos.
Advertencia: El comando mkfs borrará todo en /dev/sdb. Asegúrate de que es el disco correcto.
# 1. Crear el sistema de archivos (formatear)
sudo mkfs.xfs -f /dev/sdb
# 2. Crear el directorio base
sudo mkdir -p /mnt/gluster_data
# 3. Montar el disco
sudo mount /dev/sdb /mnt/gluster_data
# 4. Crear el directorio del ladrillo (brick)
sudo mkdir -p /mnt/gluster_data/brick1
# (Opcional pero recomendado) Añadir al fstab para montaje automático tras reinicio:
echo "/dev/sdb /mnt/gluster_data xfs defaults 0 0" | sudo tee -a /etc/fstab
- Verificar
Comprueba que se ha montado correctamente:
df -h | grep gluster_data
- Persistencia
Asegúrate de que el disco se monta automáticamente al reiniciar editando el archivo /etc/fstab:
nano /etc/fstab
y comprueba que esta, y si no añade:
/dev/sdb /mnt/gluster_data xfs defaults 0 0
Guarda y cierra el archivo.
- Creación del Clúster (Peering) Ejecutar en: SOLO EN EL NODO 1
Desde el primer nodo, conectamos con los otros dos. No es necesario hacer esto en los nodos 2 y 3.
# Conectar con el Nodo 2
sudo gluster peer probe <IP_Nodo2>
# Conectar con el Nodo 3
sudo gluster peer probe <IP_Nodo3>
# Verificar que los nodos están conectados (deberías ver 2 peers conectados)
sudo gluster peer status
``
1. Creación y Arranque del Volumen
Ejecutar en: SOLO EN EL NODO 1
Aquí creamos el volumen replicado (copia idéntica de los datos en los 3 servidores).
Nota técnica: Aunque el texto original menciona "volumen distribuido", al usar replica 3 estás creando técnicamente un Volumen Replicado (alta disponibilidad). Si un nodo cae, los datos siguen accesibles.
```bash
# 1. Crear el volumen
# Sintaxis: gluster volume create <nombre> replica <n> transport tcp <brick1> <brick2> <brick3> force
sudo gluster volume create vol_datos replica 3 transport tcp \
<IP_Nodo1>:/mnt/gluster_data \
<IP_Nodo2>:/mnt/gluster_data \
<IP_Nodo3>:/mnt/gluster_data \
force
# 2. Iniciar el volumen
sudo gluster volume start vol_datos
# 3. Verificar que el volumen está "Started"
sudo gluster volume info
Resumen de estado Si todo ha ido bien, al ejecutar sudo gluster volume status deberías ver que el volumen vol_datos está en línea y los bricks (las carpetas en cada servidor) están activos.
sudo gluster volume status
¿Y ahora qué? (Paso final: Usar el volumen) Ahora tienes el "Servidor" funcionando, pero para guardar archivos ahí necesitas configurar el "Cliente" (es decir, montar ese volumen en tu sistema de archivos para poder usarlo).
Como supongo que vas a usar esto en los mismos servidores (para Docker Swarm u otro servicio), aquí tienes los pasos para montar el volumen en los 3 nodos y que todo lo que escribas ahí se replique mágicamente.
- Crear el punto de montaje (En los 3 nodos) Vamos a crear una carpeta donde "aparecerán" los datos compartidos. Puedes llamarla como quieras, por ejemplo /mnt/shared.
Ejecutar en Nodo 83, 82 y 81:
sudo mkdir -p /mnt/shared
- Montar el volumen (Prueba manual) Para montar el volumen, le decimos a Linux que use el sistema de archivos glusterfs. Apuntamos a localhost porque cada servidor se tiene a sí mismo como fuente de datos.
Ejecutar en Nodo 83, 82 y 81:
# mount -t glusterfs <SERVIDOR>:<NOMBRE_VOLUMEN> <CARPETA_DESTINO>
sudo mount -t glusterfs localhost:gv0 /mnt/shared
- Verificar que funciona (La prueba de fuego) Vamos a crear un archivo en un servidor y ver si aparece en los otros.
En el Nodo 83, crea un archivo:
touch /mnt/shared/hola_mundo.txt
Vete al Nodo 81 o 82 y mira si el archivo existe:
ls -l /mnt/shared/
Si ves hola_mundo.txt en el otro servidor... ¡Enhorabuena! Has creado un sistema de almacenamiento distribuido de alta disponibilidad.
- Persistencia (Automontaje al reiniciar) Si reinicias los servidores, el montaje /mnt/shared se perderá. Tienes que añadirlo al fstab de cada servidor.
Ejecutar en los 3 nodos:
Edita el archivo fstab:
nano /etc/fstab
Añade esta línea al final:
localhost:gv0 /mnt/shared glusterfs defaults,_netdev 0 0
(La opción _netdev es importante: le dice al sistema que espere a tener red antes de intentar montar esto).
Guarda y sal.
- Curado automático (Opcional)
GlusterFS tiene una función de curado automático que ayuda a mantener la integridad de los datos en caso de fallos temporales de red o nodos. Para habilitarlo, puedes usar el siguiente comando:
#PAra ver el log
cat /var/log/glusterfs/bricks/mnt-gluster_data.log
sudo gluster volume heal vol_datos full
# sudo gluster volume set vol_datos cluster.self-heal-daemon on
Uso de Stacks de Swarm/Docker con GlusterFS
Al tener GlusterFS montado en /mnt/shared en todos los nodos, has convertido ese directorio en una carpeta mágica compartida.
Para Docker (o Docker Swarm), usar esto es muy sencillo. La técnica se llama Bind Mounts (montaje de enlace). En lugar de dejar que Docker guarde los datos en su "caja negra" interna, le obligas a usar tu carpeta compartida.
Aquí tienes cómo configurarlo para Docker Swarm (que es lo que imagino que usarás con 3 nodos) y para Docker normal.
- La Regla de Oro: Organización No tires todos los archivos en la raíz de /mnt/shared. Crea una carpeta para cada servicio.
Ejemplo: Si vas a montar un WordPress y un MySQL:
# Ejecuta esto una vez en cualquier nodo
sudo mkdir -p /mnt/shared/wordpress_data
sudo mkdir -p /mnt/shared/mysql_data
- Cómo usarlo en Docker Swarm (Stack / Compose)
Esta es la forma profesional. Cuando crees tu archivo docker-compose.yml o tu stack para el Swarm, debes definir el volumen usando driver: local o, más comúnmente, como un montaje de tipo bind.
Aquí tienes un ejemplo de un docker-compose.yml para un servidor web que servirá los mismos ficheros en cualquier nodo:
version: '3.8'
services:
web:
image: nginx:latest
deploy:
replicas: 3 # Un contenedor en cada nodo
restart_policy:
condition: on-failure
ports:
- "80:80"
volumes:
- type: bind
source: /mnt/shared/mi_web # <--- TU CARPETA GLUSTER
target: /usr/share/nginx/html # <--- DONDE LO VE EL CONTENEDOR
¿Qué pasa aquí?
Si el contenedor web arranca en el Nodo 1, leerá /mnt/shared/mi_web.
Si ese contenedor muere y el Swarm lo levanta en el Nodo 3, leerá /mnt/shared/mi_web.
Como Gluster sincroniza los datos al instante, el Nodo 3 verá exactamente lo mismo que veía el Nodo 1.
- Cómo usarlo con docker run (Prueba rápida) Si lanzas contenedores manualmente, usas la bandera -v.
docker run -d \
--name prueba-nginx \
-p 8080:80 \
-v /mnt/shared/mi_web:/usr/share/nginx/html \
nginx
Un consejo sobre Bases de Datos (Advertencia) GlusterFS es maravilloso para archivos web (html, php, imágenes, documentos) y configuraciones.
Sin embargo, para bases de datos con muchísima escritura (como un MySQL con miles de transacciones por segundo), GlusterFS puede ser un poco lento debido a la latencia de red (tiene que copiar el dato a 3 sitios antes de confirmar).
Para uso normal/medio: Funciona perfecto en /mnt/shared.
Para uso ultra-intensivo: Se suelen usar volúmenes locales pinned (anclados) o soluciones más complejas, pero para tu cluster actual, ponerlo en /mnt/shared es la solución correcta.