--- title: "Cómo configurar GlusterFS replicado en Ubuntu 24.04" description: "Crea un volumen GlusterFS replicado en tres servidores Ubuntu 24.04, móntalo desde un cliente con alta disponibilidad y comprueba la autorreparación." category: "Almacenamiento y Copia de Seguridad Avanzada" language: es source: https://cubepath.com/es/docs/almacenamiento-y-copia-de-seguridad-avanzada/configuracion-del-almacenamiento-distribuido-glusterfs updated: 2026-09-25 --- # Cómo configurar GlusterFS replicado en Ubuntu 24.04 GlusterFS es un sistema de archivos distribuido que agrupa directorios de varios servidores (llamados *bricks*) en un único volumen accesible por red. Con un volumen replicado, cada archivo se guarda en varios servidores, de modo que los clientes siguen leyendo y escribiendo aunque uno de ellos caiga. En este tutorial crearás un volumen con réplica 3 en tres servidores Ubuntu 24.04, lo montarás desde un cliente y comprobarás cómo se recupera tras la caída de un nodo. ## Requisitos previos - Tres servidores con Ubuntu 24.04 LTS en la misma red privada, por ejemplo VPS de CubePath. En esta guía se llaman `gluster1`, `gluster2` y `gluster3`, con las IP `10.0.0.21`, `10.0.0.22` y `10.0.0.23`. - En cada servidor, un disco adicional para los datos (en los ejemplos, `/dev/vdb`). Puedes usar un directorio del disco del sistema para pruebas, pero no es recomendable en producción. - Un cuarto servidor Ubuntu 24.04 que actuará como cliente (`10.0.0.30`). - Un usuario no root con privilegios `sudo` en todos los servidores. Conceptos que usarás: | Término | Significado | |---|---| | Brick | Directorio de un servidor que forma parte de un volumen | | Trusted pool | Grupo de servidores GlusterFS que confían entre sí | | Volumen replicado | Cada archivo se copia en todos los bricks de un conjunto de réplica | | Self-heal | Proceso que copia a un brick los cambios que se perdió mientras estaba caído | ## Paso 1: Preparar los servidores Ejecuta este paso en **los tres servidores de almacenamiento**. Añade los nombres de los nodos a `/etc/hosts`, y también el del cliente: ```bash sudo nano /etc/hosts ``` ```text 10.0.0.21 gluster1 10.0.0.22 gluster2 10.0.0.23 gluster3 10.0.0.30 client1 ``` GlusterFS recomienda XFS para los bricks. Instala las herramientas de XFS, formatea el disco adicional y móntalo en `/data/glusterfs`: ```bash sudo apt update sudo apt install xfsprogs sudo mkfs.xfs -i size=512 /dev/vdb sudo mkdir -p /data/glusterfs ``` > Advertencia: `mkfs.xfs` borra todo el contenido del disco. Comprueba con `lsblk` que `/dev/vdb` es el disco vacío correcto. Para que el montaje sobreviva a los reinicios, añádelo a `/etc/fstab` usando su UUID. Obtén el UUID: ```bash sudo blkid /dev/vdb ``` ```output /dev/vdb: UUID="3f8e2c1a-5b7d-4e9f-a012-6c3d4e5f6a7b" BLOCK_SIZE="512" TYPE="xfs" ``` Edita `/etc/fstab`: ```bash sudo nano /etc/fstab ``` Añade esta línea con tu UUID: ```text UUID=3f8e2c1a-5b7d-4e9f-a012-6c3d4e5f6a7b /data/glusterfs xfs defaults 0 0 ``` Monta el sistema de archivos y crea el directorio que será el brick. El brick debe ser un subdirectorio del punto de montaje: si el disco no se monta, GlusterFS no encontrará el subdirectorio y no escribirá en el disco del sistema por error: ```bash sudo systemctl daemon-reload sudo mount -a sudo mkdir -p /data/glusterfs/gv0/brick df -h /data/glusterfs ``` ```output Filesystem Size Used Avail Use% Mounted on /dev/vdb 50G 390M 50G 1% /data/glusterfs ``` ## Paso 2: Instalar GlusterFS En los tres servidores, instala el servidor de GlusterFS desde los repositorios de Ubuntu y arranca el servicio de gestión `glusterd`: ```bash sudo apt install glusterfs-server sudo systemctl enable --now glusterd ``` Comprueba que el servicio está activo: ```bash sudo systemctl status glusterd --no-pager ``` ```output ● glusterd.service - GlusterFS, a clustered file-system server Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; preset: enabled) Active: active (running) since ... ``` GlusterFS usa los puertos TCP 24007 y 24008 para la gestión y un puerto a partir del 49152 por cada brick. Si UFW está activo, permite el tráfico solo desde la red privada, que incluye a los otros nodos y al cliente: ```bash sudo ufw allow from 10.0.0.0/24 to any port 24007:24008 proto tcp sudo ufw allow from 10.0.0.0/24 to any port 49152:60999 proto tcp ``` ## Paso 3: Crear el trusted pool Desde `gluster1`, añade los otros dos servidores al grupo de confianza. Solo hace falta ejecutarlo en un nodo: ```bash sudo gluster peer probe gluster2 sudo gluster peer probe gluster3 ``` ```output peer probe: success peer probe: success ``` Comprueba el estado de los pares: ```bash sudo gluster pool list ``` ```output UUID Hostname State 7b1c... gluster2 Connected a93f... gluster3 Connected 52de... localhost Connected ``` ## Paso 4: Crear el volumen replicado Crea el volumen `gv0` con réplica 3, un brick en cada servidor. Una réplica de 3 copias evita el *split-brain*: si un nodo queda aislado, los otros dos siguen teniendo mayoría: ```bash sudo gluster volume create gv0 replica 3 \ gluster1:/data/glusterfs/gv0/brick \ gluster2:/data/glusterfs/gv0/brick \ gluster3:/data/glusterfs/gv0/brick ``` ```output volume create: gv0: success: please start the volume to access data ``` Limita el acceso de clientes a tu red privada y arranca el volumen: ```bash sudo gluster volume set gv0 auth.allow 10.0.0.* sudo gluster volume start gv0 ``` Comprueba la configuración y que los tres bricks están en línea: ```bash sudo gluster volume info gv0 sudo gluster volume status gv0 ``` ```output Volume Name: gv0 Type: Replicate Status: Started Number of Bricks: 1 x 3 = 3 Transport-type: tcp ... Status of volume: gv0 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick gluster1:/data/glusterfs/gv0/brick 58724 0 Y 2143 Brick gluster2:/data/glusterfs/gv0/brick 54111 0 Y 2087 Brick gluster3:/data/glusterfs/gv0/brick 60213 0 Y 2091 Self-heal Daemon on localhost N/A N/A Y 2160 ``` ## Paso 5: Montar el volumen en el cliente En `client1`, añade las mismas entradas a `/etc/hosts` que en el paso 1 e instala el cliente FUSE de GlusterFS: ```bash sudo apt update sudo apt install glusterfs-client ``` Monta el volumen. El servidor que indicas en el comando solo se usa para descargar la configuración del volumen; después, el cliente se conecta directamente a los tres bricks: ```bash sudo mkdir -p /mnt/gv0 sudo mount -t glusterfs gluster1:/gv0 /mnt/gv0 df -h /mnt/gv0 ``` ```output Filesystem Size Used Avail Use% Mounted on gluster1:/gv0 50G 900M 50G 2% /mnt/gv0 ``` Para montarlo en el arranque, edita `/etc/fstab` en el cliente: ```bash sudo nano /etc/fstab ``` La opción `backup-volfile-servers` permite montar aunque `gluster1` esté caído, y `_netdev` espera a que la red esté disponible: ```text gluster1:/gv0 /mnt/gv0 glusterfs defaults,_netdev,backup-volfile-servers=gluster2:gluster3 0 0 ``` Comprueba la entrada desmontando y montando con `fstab`: ```bash sudo umount /mnt/gv0 sudo mount -a mount | grep gv0 ``` ## Paso 6: Verificar la replicación Crea unos archivos desde el cliente: ```bash for i in $(seq 1 20); do echo "archivo $i" | sudo tee "/mnt/gv0/archivo-$i.txt" > /dev/null; done ls /mnt/gv0 | wc -l ``` ```output 20 ``` En cualquiera de los tres servidores, mira el contenido del brick. Como es una réplica 3, cada brick contiene los 20 archivos: ```bash ls /data/glusterfs/gv0/brick | wc -l ``` ```output 20 ``` > Importante: lee y escribe siempre a través del punto de montaje del cliente, nunca directamente en el brick. Los cambios hechos en el brick no se replican. ## Paso 7: Probar la caída de un nodo y la autorreparación Apaga `gluster3` para simular un fallo: ```bash sudo poweroff ``` Desde el cliente, sigue escribiendo. El volumen continúa disponible con dos de los tres bricks: ```bash echo "escrito con gluster3 caído" | sudo tee /mnt/gv0/durante-fallo.txt ``` En `gluster1`, el comando `heal info` lista los archivos que `gluster3` tiene pendientes: ```bash sudo gluster volume heal gv0 info ``` ```output Brick gluster1:/data/glusterfs/gv0/brick /durante-fallo.txt / Status: Connected Number of entries: 2 ... Brick gluster3:/data/glusterfs/gv0/brick Status: Transport endpoint is not connected Number of entries: - ``` Enciende `gluster3` de nuevo. Al volver, el demonio de self-heal copia los cambios automáticamente. Pasados unos segundos, repite el comando: ```bash sudo gluster volume heal gv0 info ``` ```output Brick gluster1:/data/glusterfs/gv0/brick Status: Connected Number of entries: 0 ... ``` Con `Number of entries: 0` en los tres bricks, todos los nodos vuelven a estar sincronizados. Puedes confirmarlo con `ls /data/glusterfs/gv0/brick/durante-fallo.txt` en `gluster3`. ## Solución de problemas - **`peer probe: failed: Probe returned with Transport endpoint is not connected`**: `glusterd` no está activo en el nodo de destino o el puerto 24007 está bloqueado. Comprueba `systemctl status glusterd` y las reglas de UFW en ese nodo. - **`volume create: gv0: failed: The brick ... is a mount point`**: estás usando el punto de montaje como brick. Usa un subdirectorio, como `/data/glusterfs/gv0/brick`. - **El cliente no monta y el registro dice `failed to fetch volume file`**: el cliente no resuelve los nombres `gluster1`, `gluster2` y `gluster3` o su IP no está incluida en `auth.allow`. Revisa `/etc/hosts` y el registro en `/var/log/glusterfs/mnt-gv0.log`. - **`heal info` muestra entradas en `split-brain`**: ejecuta `sudo gluster volume heal gv0 info split-brain` para ver los archivos afectados y resuélvelos con `gluster volume heal gv0 split-brain latest-mtime `. ## Conclusión Tienes un volumen GlusterFS replicado en tres servidores, montado en un cliente con servidores de respaldo y probado frente a la caída de un nodo. Como siguientes pasos puedes ampliar la capacidad añadiendo otros tres bricks con `gluster volume add-brick` y `gluster volume rebalance`, cifrar el tráfico con TLS, o hacer copias de seguridad periódicas del contenido del punto de montaje, ya que la replicación no protege frente a borrados accidentales.