Almacenamiento · 8 min read · Jan 10, 2026

Almacenamiento de Alta Disponibilidad Con GlusterFS 3.2.x En Debian Wheezy - Replicación Automática de Archivos (Espejo) Entre Dos Servidores de Almacenamiento

Este tutorial muestra cómo configurar un almacenamiento de alta disponibilidad con dos servidores de almacenamiento (Debian Wheezy) que utilizan GlusterFS. Cada servidor de almacenamiento será un espejo del otro servidor de almacenamiento, y los archivos se replicarán automáticamente entre ambos servidores de almacenamiento. El sistema cliente (Debian Wheezy también) podrá acceder al almacenamiento como si fuera un sistema de archivos local. GlusterFS es un sistema de archivos en clúster capaz de escalar a varios petabytes. Agrega varios bloques de almacenamiento a través de Infiniband RDMA o TCP/IP en un gran sistema de archivos de red paralelo. Los bloques de almacenamiento pueden estar hechos de cualquier hardware común, como servidores x86_64 con RAID SATA-II y HBA Infiniband.

¡No emito ninguna garantía de que esto funcione para ti!

1 Nota Preliminar

En este tutorial utilizo tres sistemas, dos servidores y un cliente:

  • server1.example.com: dirección IP 192.168.0.100 (servidor)
  • server2.example.com: dirección IP 192.168.0.101 (servidor)
  • client1.example.com: dirección IP 192.168.0.102 (cliente)

Los tres sistemas deben ser capaces de resolver los nombres de host de los otros sistemas. Si esto no se puede hacer a través de DNS, debes editar el archivo /etc/hosts para que se vea como sigue en los tres sistemas:

vi /etc/hosts

| 127.0.0.1 localhost.localdomain localhost 192.168.0.100 server1.example.com server1 192.168.0.101 server2.example.com server2 192.168.0.102 client1.example.com client1 # Las siguientes líneas son deseables para hosts compatibles con IPv6 ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts |

(También es posible usar direcciones IP en lugar de nombres de host en la configuración siguiente. Si prefieres usar direcciones IP, no tienes que preocuparte de si los nombres de host se pueden resolver o no.)

2 Configuración de los Servidores GlusterFS

server1.example.com/server2.example.com:

GlusterFS está disponible como un paquete para Debian Wheezy, por lo tanto, podemos instalarlo de la siguiente manera:

apt-get install glusterfs-server

El comando

glusterfsd --version

debiera mostrar ahora la versión de GlusterFS que acabas de instalar (3.2.7 en este caso):

root@server1:~# glusterfsd --version  
glusterfs 3.2.7 built on Nov 12 2012 19:30:08  
Repository revision: git://git.gluster.com/glusterfs.git  
Copyright (c) 2006-2011 Gluster Inc.   
GlusterFS viene con ABSOLUTAMENTE NINGUNA GARANTÍA.  
Puedes redistribuir copias de GlusterFS bajo los términos de la Licencia Pública General de GNU.  
root@server1:~#

Si usas un firewall, asegúrate de que los puertos TCP 111, 24007, 24008, 24009-(24009 + número de bloques en todos los volúmenes) estén abiertos en server1.example.com y server2.example.com.

A continuación, debemos agregar server2.example.com al grupo de almacenamiento de confianza (ten en cuenta que estoy ejecutando todos los comandos de configuración de GlusterFS desde server1.example.com, pero también puedes ejecutarlos desde server2.example.com porque la configuración se replica entre los nodos de GlusterFS; solo asegúrate de usar los nombres de host o direcciones IP correctas):

server1.example.com:

En server1.example.com, ejecuta

gluster peer probe server2.example.com
root@server1:~# gluster peer probe server2.example.com  
Probe successful  
root@server1:~#

El estado del grupo de almacenamiento de confianza debería ser ahora similar a esto:

gluster peer status
root@server1:~# gluster peer status  
Number of Peers: 1
Hostname: server2.example.com  
Uuid: d19cb707-7b23-4d11-8e9c-183cd0a18d96  
State: Peer in Cluster (Connected)  
root@server1:~#

A continuación, creamos el recurso compartido llamado testvol con dos réplicas (ten en cuenta que el número de réplicas es igual al número de servidores en este caso porque queremos configurar el espejado) en server1.example.com y server2.example.com en el directorio /data (esto se creará si no existe):

gluster volume create testvol replica 2 transport tcp server1.example.com:/data server2.example.com:/data
root@server1:~# gluster volume create testvol replica 2 transport tcp server1.example.com:/data server2.example.com:/data  
Creation of volume testvol has been successful. Please start the volume to access data.  
root@server1:~#

Inicia el volumen:

gluster volume start testvol

Es posible que el comando anterior te diga que la acción no fue exitosa:

root@server1:~# gluster volume start testvol  
Starting volume testvol has been unsuccessful  
root@server1:~#

En este caso, debes verificar la salida de…

server1.example.com/server2.example.com:

netstat -tap | grep glusterfsd

en ambos servidores.

Si obtienes una salida como esta…

root@server1:~# netstat -tap | grep glusterfsd  
tcp        0      0 *:24009                 *:*                     LISTEN      1548/glusterfsd  
tcp        0      0 localhost.localdom:1019 localhost.localdo:24007 ESTABLISHED 1548/glusterfsd  
root@server1:~#

… todo está bien, pero si no obtienes ninguna salida…

root@server2:~# netstat -tap | grep glusterfsd  
root@server2:~#

… reinicia el demonio de GlusterFS en el servidor correspondiente (server2.example.com en este caso):

server2.example.com:

/etc/init.d/glusterfs-server restart

Luego verifica la salida de…

netstat -tap | grep glusterfsd

… nuevamente en ese servidor; ahora debería verse así:

root@server2:~# netstat -tap | grep glusterfsd  
tcp        0      0 *:24010                 *:*                     LISTEN      1458/glusterfsd  
tcp        0      0 localhost.localdom:1021 localhost.localdo:24007 ESTABLISHED 1458/glusterfsd  
root@server2:~#

Ahora volvamos a server1.example.com:

server1.example.com:

Puedes verificar el estado del volumen con el comando

gluster volume info
root@server1:~# gluster volume info
Volume Name: testvol  
Type: Replicate  
Status: Started  
Number of Bricks: 2  
Transport-type: tcp  
Bricks:  
Brick1: server1.example.com:/data  
Brick2: server2.example.com:/data  
root@server1:~#

Por defecto, todos los clientes pueden conectarse al volumen. Si deseas otorgar acceso solo a client1.example.com (= 192.168.0.102), ejecuta:

gluster volume set testvol auth.allow 192.168.0.102

Ten en cuenta que es posible usar comodines para las direcciones IP (como 192.168.*) y que puedes especificar múltiples direcciones IP separadas por comas (por ejemplo, 192.168.0.102,192.168.0.103).

La información del volumen ahora debería mostrar el estado actualizado:

gluster volume info
root@server1:~# gluster volume info
Volume Name: testvol  
Type: Replicate  
Status: Started  
Number of Bricks: 2  
Transport-type: tcp  
Bricks:  
Brick1: server1.example.com:/data  
Brick2: server2.example.com:/data  
Options Reconfigured:  
auth.allow: 192.168.0.102  
root@server1:~#

3 Configuración del Cliente GlusterFS

client1.example.com:

En el cliente, podemos instalar el cliente GlusterFS de la siguiente manera:

apt-get install glusterfs-client

Luego creamos el siguiente directorio:

mkdir /mnt/glusterfs

¡Eso es todo! Ahora podemos montar el sistema de archivos GlusterFS en /mnt/glusterfs con el siguiente comando:

mount.glusterfs server1.example.com:/testvol /mnt/glusterfs

(En lugar de server1.example.com, también puedes usar server2.example.com en el comando anterior!)

Ahora deberías ver el nuevo recurso compartido en las salidas de…

mount
root@client1:~# mount  
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)  
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)  
odev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=126813,mode=755)  
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)  
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=102704k,mode=755)  
/dev/mapper/server1-root on / type ext4 (rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered)  
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)  
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=205400k)  
/dev/sda1 on /boot type ext2 (rw,relatime,errors=continue)  
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)  
server1.example.com:/testvol on /mnt/glusterfs type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)  
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)  
root@client1:~#

… y…

df -h
root@client1:~# df -h  
Filesystem                Size  Used Avail Use% Mounted on  
rootfs                     29G  1.2G   26G   5% /  
udev                      10M     0   10M   0% /dev  
tmpfs                     101M  240K  101M   1% /run  
/dev/mapper/server1-root     29G  1.2G   26G   5% /  
tmpfs                     5.0M     0  5.0M   0% /run/lock  
tmpfs                     201M     0  201M   0% /run/shm  
/dev/sda1                 228M   18M  199M   9% /boot  
server1.example.com:/testvol   29G  1.2G   26G   5% /mnt/glusterfs  
root@client1:~#

En lugar de montar el recurso compartido de GlusterFS manualmente en el cliente, podrías modificar /etc/fstab para que el recurso compartido se monte automáticamente cuando el cliente arranque.

Abre /etc/fstab y agrega la siguiente línea:

vi /etc/fstab

| [...] server1.example.com:/testvol /mnt/glusterfs glusterfs defaults,_netdev 0 0 |

(De nuevo, en lugar de server1.example.com, también puedes usar server2.example.com!)

Para probar si tu /etc/fstab modificado está funcionando, reinicia el cliente:

reboot

Después del reinicio, deberías encontrar el recurso compartido en las salidas de…

df -h

… y…

mount

4 Pruebas

Ahora vamos a crear algunos archivos de prueba en el recurso compartido de GlusterFS:

client1.example.com:

touch /mnt/glusterfs/test1  
touch /mnt/glusterfs/test2

Ahora verifiquemos el directorio /data en server1.example.com y server2.example.com. Los archivos test1 y test2 deberían estar presentes en cada nodo:

server1.example.com/server2.example.com:

ls -l /data
root@server1:~# ls -l /data  
total 0  
-rw-r--r-- 1 root root 0 Sep 30 17:53 test1  
-rw-r--r-- 1 root root 0 Sep 30 17:53 test2  
root@server1:~#

Ahora apagamos server1.example.com y agregamos/borramos algunos archivos en el recurso compartido de GlusterFS en client1.example.com.

server1.example.com:

shutdown -h now

client1.example.com:

touch /mnt/glusterfs/test3  
touch /mnt/glusterfs/test4  
rm -f /mnt/glusterfs/test2

Los cambios deberían ser visibles en el directorio /data en server2.example.com:

server2.example.com:

ls -l /data
root@server2:~# ls -l /data  
total 8  
-rw-r--r-- 1 root root 0 Sep 30 17:53 test1  
-rw-r--r-- 1 root root 0 Sep 30 17:54 test3  
-rw-r--r-- 1 root root 0 Sep 30 17:54 test4  
root@server2:~#

Vamos a reiniciar server1.example.com y a mirar el directorio /data:

server1.example.com:

ls -l /data
root@server1:~# ls -l /data  
total 0  
-rw-r--r-- 1 root root 0 Sep 30 17:53 test1  
-rw-r--r-- 1 root root 0 Sep 30 17:53 test2  
root@server1:~#

Como ves, server1.example.com no ha notado los cambios que ocurrieron mientras estaba apagado. Esto es fácil de solucionar, solo necesitamos invocar un comando de lectura en el recurso compartido de GlusterFS en client1.example.com, por ejemplo:

client1.example.com:

ls -l /mnt/glusterfs/
root@client1:~# ls -l /mnt/glusterfs/  
total 8  
-rw-r--r-- 1 root root 0 Sep 30 17:53 test1  
-rw-r--r-- 1 root root 0 Sep 30 17:54 test3  
-rw-r--r-- 1 root root 0 Sep 30 17:54 test4  
root@client1:~#

Ahora echa un vistazo al directorio /data en server1.example.com nuevamente, y deberías ver que los cambios se han replicado a ese nodo:

server1.example.com:

ls -l /data
root@server1:~# ls -l /data  
total 0  
-rw-r--r-- 1 root root 0 Sep 30 17:53 test1  
-rw-r--r-- 1 root root 0 Sep 30 17:54 test3  
-rw-r--r-- 1 root root 0 Sep 30 17:54 test4  
root@server1:~#

5 Enlaces

Share: X/Twitter LinkedIn

Recibe nuevas publicaciones en tu bandeja de entrada.

No spam. Cancela la suscripción en cualquier momento.