Gluster – Filesystems con Alta Disponibilidad en Linux

Alguna vez os he hablado de ServiceGuard para montar entornos de alta disponibilidad robustos, que monten filesystems y levanten servicios, pero este es un software de pago que no quería utilizar para montar un único filesystem con alta disponibilidad. En su lugar, he elegido GlusterFS, que es opensource y con soporte de RedHat.

¿Para qué vamos utilizar GlusterFS exactamente?

Lo que vamos a hacer a continuación es crear un filesystem con todos sus datos accesibles y sincronizados en tiempo real en tres servidores, lo que significa que si alguno de ellos cae (avería hardware, reinicio, etc.), los datos siguen siendo accesibles a través de otro nodo del cluster.

Instalación de Gluster en CentOS 7

En primer lugar, vamos a instalar Gluster en los tres nodos que van a formar el cluster de filesystems. Lo haremos en CentOS 7.

[root@server1 ~]# lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: CentOS
Description:    CentOS Linux release 7.6.1810 (Core)
Release:        7.6.1810
Codename:       Core
[root@server1 ~]#

Los pasos de instalación son muy sencillos:

  • Buscamos el repositorio de la última versión disponible del producto y lo instalamos:
[root@server1 ~]# yum search centos-release-gluster
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.sax.uk.as61049.net
 * centosplus: mirror.cwcs.co.uk
 * epel: mirror.team-cymru.com
 * extras: mirror.netweaver.uk
 * updates: mirror.cwcs.co.uk
============================================================================== N/S matched: centos-release-gluster ===============================================================================
centos-release-gluster-legacy.noarch : Disable unmaintained Gluster repositories from the CentOS Storage SIG
centos-release-gluster40.x86_64 : Gluster 4.0 (Short Term Stable) packages from the CentOS Storage SIG repository
centos-release-gluster41.noarch : Gluster 4.1 (Long Term Stable) packages from the CentOS Storage SIG repository
centos-release-gluster5.noarch : Gluster 5 packages from the CentOS Storage SIG repository
centos-release-gluster6.noarch : Gluster 6 packages from the CentOS Storage SIG repository

  Name and summary matches only, use "search all" for everything.
[root@server1 ~]# yum install -y centos-release-gluster6.noarch
  • A continuación, instalamos Gluster con todas sus dependencias:
[root@server1 ~]# yum install -y glusterfs gluster-cli glusterfs-libs glusterfs-server
[root@server1 ~]# rpm -qa |grep -i gluster
glusterfs-6.1-1.el7.x86_64
glusterfs-server-6.1-1.el7.x86_64
glusterfs-api-6.1-1.el7.x86_64
glusterfs-libs-6.1-1.el7.x86_64
glusterfs-cli-6.1-1.el7.x86_64
glusterfs-fuse-6.1-1.el7.x86_64
glusterfs-client-xlators-6.1-1.el7.x86_64
centos-release-gluster6-1.0-1.el7.centos.noarch
[root@server1 ~]#

Repetimos los pasos en los otros dos servidores del cluster.

Habilitamos el servicio de Gluster

Una vez instalado el producto, tenemos que arrancarlo. Ejecutaremos el siguiente comando en los tres servidores CentOS 7 del cluster:

[root@server1 ~]# systemctl enable glusterd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/glusterd.service to /usr/lib/systemd/system/glusterd.service.
[root@server1 ~]#

[root@server1 ~]# systemctl start glusterd.service
[root@server1 ~]# ps -ef |grep -i gluster |grep -v grep
root       6432      1  0 10:50 ?        00:00:00 /usr/sbin/glusterd -p /var/run/glusterd.pid --log-level INFO
[root@server1 ~]#

Asignación de IPs de servicio a cada nodo de GlusterFS

En cada uno de los servidores vamos a asociar una IP distinta de servicio y un nombre. Para ello, configuraremos el fichero /etc/hosts de cada nodo con su IP correspondiente:

[root@server1 ~]# cat /etc/hosts |grep gluster
10.0.0.2 glusterfs1
10.0.0.3 glusterfs2
10.0.0.4 glusterfs3
[root@server1 ~]#

Asignación de un disco a cada nodo

Si leísteis el artículo de ServiceGuard, lo que hacíamos era dar visibilidad de una LUN de la cabina de discos a los tres nodos a la vez.

El concepto de GlusterFS cambia. Lo que haremos aquí será asignar tres discos independientes. Uno para cada nodo y luego sincronizar los datos. Para esta guía, asignamos un disco de 1GB.

[root@server1 ~]# fdisk -l |grep dev |grep -v mapper
Disk /dev/sdb: 1073 MB, 1073741824 bytes, 2097152 sectors
Disk /dev/sda: 10.7 GB, 10737418240 bytes, 20971520 sectors
/dev/sda1   *        2048     2099199     1048576   83  Linux
/dev/sda2         2099200    20971519     9436160   8e  Linux LVM
[root@server1 ~]#

[root@server2 ~]# fdisk -l |grep dev |grep -v mapper
Disk /dev/sdb: 1073 MB, 1073741824 bytes, 2097152 sectors
Disk /dev/sda: 10.7 GB, 10737418240 bytes, 20971520 sectors
/dev/sda1   *        2048     2099199     1048576   83  Linux
/dev/sda2         2099200    20971519     9436160   8e  Linux LVM
[root@server2 ~]#

[root@server3 /]# fdisk -l |grep dev |grep -v mapper
Disk /dev/sdb: 1073 MB, 1073741824 bytes, 2097152 sectors
Disk /dev/sda: 10.7 GB, 10737418240 bytes, 20971520 sectors
/dev/sda1   *        2048     2099199     1048576   83  Linux
/dev/sda2         2099200    20971519     9436160   8e  Linux LVM
[root@server3 /]#

Creación de los filesystems

En cada uno de los nodos, crearemos un filesystem independiente pero con el mismo nombre. En realidad, le puedes poner el nombre que quieras al punto de montaje, pero me gusta ser consistente y darle el mismo nombre a los tres filesystems si son para el mismo servicio.

[root@server1 ~]# grep -i gluster /etc/fstab
/dev/vggluster/lvgluster        /gluster        xfs     defaults        0 0
[root@server1 ~]#

[root@server1 ~]# df -hP /gluster/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vggluster-lvgluster 1014M   33M  982M   4% /gluster
[root@server1 ~]#

[root@server2 ~]# grep -i gluster /etc/fstab
/dev/vggluster/lvgluster        /gluster        xfs     defaults        0 0
[root@server2 ~]#

[root@server2 ~]# df -hP /gluster/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vggluster-lvgluster 1014M   33M  982M   4% /gluster
[root@server2 ~]#

[root@server3 /]# grep -i gluster /etc/fstab
/dev/vggluster/lvgluster        /gluster        xfs     defaults        0 0
[root@server3 /]#

[root@server3 /]# df -hP /gluster/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vggluster-lvgluster 1014M   33M  982M   4% /gluster
[root@server3 /]#

Como véis, hemos creado un filesystem XFS estándar con arquitectura LVM.

Creación del Cluster de Filesystems con GlusterFS

Por fin llegamos al punto interesante, que es la creación del cluster del sistema de archivos con Gluster para replicar los datos entre todos los nodos.

Configuración de los nodos

Lo primero que haremos será configurar el número de nodos del cluster. Así que nos conectamos al servidor1 y ejecutamos el siguiente comando hacia los otros dos nodos del cluster:

[root@server1 ~]# gluster peer probe glusterfs2
peer probe: success.
[root@server1 ~]# gluster peer probe glusterfs3
peer probe: success.
[root@server1 ~]#

Si comprobamos el estado del cluster, veremos que está formado por los tres nodos:

[root@server1 ~]# gluster peer status
Number of Peers: 2

Hostname: glusterfs2
Uuid: c94cb2f7-2784-41ed-8502-065f7855b4e6
State: Peer in Cluster (Connected)

Hostname: glusterfs3
Uuid: ed01e2fa-1cd5-4e8b-9acb-90e331e35560
State: Peer in Cluster (Connected)
[root@server1 ~]#

En caso de que queramos eliminiar alguno de los nodos, utilizaremos el comando gluster detach servidor3.

Configuración de la réplica de datos entre los diferentes filesystems

Primer intento fallido

[root@server1 ~]# gluster volume create glustervol1 replica 3 arbiter 1 transport tcp glusterfs1:/gluster glusterfs2:/gluster glusterfs3:/gluster
volume create: glustervol1: failed: The brick glusterfs1:/gluster is a mount point. Please create a sub-directory under the mount point and use that as the brick directory. Or use 'force' at the end of the command if you want to override this behavior.
[root@server1 ~]#

Lo que nos está diciendo este error es que Gluster necesita guardar sus metadatos en un subdirectorio y no en un punto de montaje.

Segundo intento OK

Creamos el subdirectorio “brick”, tal y como dice el error y lo volvemos a intentar.

[root@server1 ~]# gluster volume create glustervol1 replica 3 arbiter 1 transport tcp glusterfs1:/gluster/brick glusterfs2:/gluster/brick glusterfs3:/gluster/brick
volume create: glustervol1: success: please start the volume to access data
[root@server1 ~]#

[root@server1 ~]# gluster volume start glustervol1
volume start: glustervol1: success
[root@server1 ~]#

Comprobamos el estado del volumen de gluster que acabamos de crear

[root@server1 ~]# gluster volume info

Volume Name: glustervol1
Type: Replicate
Volume ID: 7a5f6b90-5dab-4d3a-b686-023aedd38bf3
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x (2 + 1) = 3
Transport-type: tcp
Bricks:
Brick1: glusterfs1:/gluster/brick
Brick2: glusterfs2:/gluster/brick
Brick3: glusterfs3:/gluster/brick (arbiter)
Options Reconfigured:
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off
[root@server1 ~]#

[root@server1 ~]# gluster volume status glustervol1
Status of volume: glustervol1
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick glusterfs1:/glustersrv/brick         49152     0          Y       5593
Brick glusterfs2:/glustersrv/brick         49152     0          Y       5284
Brick glusterfs3:/glustersrv/brick         49152     0          Y       5368
Self-heal Daemon on localhost               N/A       N/A        Y       5604
Self-heal Daemon on glusterfs3             N/A       N/A        Y       5422
Self-heal Daemon on glusterfs2             N/A       N/A        Y       5343

Task Status of Volume glustervol1
------------------------------------------------------------------------------
There are no active volume tasks

[root@server1 ~]#

[root@server1 ~]# gluster pool list
UUID                                    Hostname        State
062d4a7e-bd66-45ad-a11c-c0f5f796b4d6    glusterfs2     Connected
0187b96f-f6f8-4e8b-9e9f-4a7583b57005    glusterfs3     Connected
0386eef3-268d-4bb6-8c4f-8388a990b3ce    localhost       Connected
[root@server1 ~]#

Montaje de los filesystems

Ahora ya tenemos configurada la réplica entre filesystems pero todavía no los hemos montado como «cluster de Gluster». Lo haremos así:

[root@server1 ~]# mount -t glusterfs glusterfs1:/glustervol1 /gluster_client
[root@server1 ~]# df -hP /gluster_client/
Filesystem               Size  Used Avail Use% Mounted on
glusterfs1:/glustervol1 1014M   43M  972M   5% /gluster_client
[root@server1 ~]#

El fichero /etc/fstab de cada nodo lo he configurado así:

[root@server1 ~]# grep gluster_client /etc/fstab
glusterfs1:/glustervol1         /gluster_client glusterfs       defaults        0 0
[root@server1 ~]#

[root@server2 ~]# grep gluster_client /etc/fstab
glusterfs2:/glustervol1         /gluster_client glusterfs       defaults        0 0
[root@server2 ~]#

[root@server3 /]# grep gluster_client /etc/fstab
glusterfs3:/glustervol1         /gluster_client glusterfs       defaults        0 0
[root@server3 /]#

Los filesystems no montan tras el reboot del servidor

Durante las pruebas, me he dado cuenta de que los filesystems no siempre montan tras rebotar los servidores. Seguramente, el servicio de gluster todavía no se ha levantado y la entrada del fstab falla.

La solución pasa por crear un servicio que se encargue de montar los filesystems cuando el servicio de gluster ya esté arrancado:

  • Creamos el fichero de configuración del servicio:
[root@gluster2 ~]# cat /etc/systemd/system/glusterfsmounts.service
[Unit]
Description=Glustermounting
Requires=glusterfs-server.service

[Service]
Type=simple
RemainAfterExit=true
ExecStartPre=/usr/sbin/gluster volume list
ExecStart=/bin/mount -a -t glusterfs
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target
[root@gluster2 ~]#

[root@gluster2 ~]# systemctl daemon-reload
[root@gluster2 ~]# systemctl enable glusterfsmounts
Created symlink from /etc/systemd/system/multi-user.target.wants/glusterfsmounts.service to /etc/systemd/system/glusterfsmounts.service.
[root@gluster2 ~]#
  • Rebotamos el servidor

Veremos que, tras el reboot, los filesystems de tipo gluster siempre montan correctamente.

Pruebas de réplica de datos

Ya hemos montado el cluster. Ahora vamos a comprobar que los datos se replican correctamente, así que voy a escribir un fichero en uno de los servidores y voy a comprobar que puedo verlo en el resto:

[root@server1 gluster_client]# touch kk
[root@server1 gluster_client]# ll
total 0
-rw-r--r-- 1 root root 0 May 29 12:09 kk
[root@server1 gluster_client]#

Y el fichero «kK» sí existe en los otros nodos:

[root@server2 gluster_client]# ll
total 0
-rw-r--r-- 1 root root 0 May 29 12:09 kk
[root@server2 gluster_client]#

[root@server3 gluster_client]# ll
total 0
-rw-r--r-- 1 root root 0 May 29 12:09 kk
[root@server3 gluster_client]#

Lo mismo ocurre si escribimos otro archivo desde cualquiera de los otros servidores:

[root@server3 gluster_client]# echo "david" >> david.txt
[root@server3 gluster_client]# ll
total 1
-rw-r--r-- 1 root root 6 May 29 12:11 david.txt
-rw-r--r-- 1 root root 0 May 29 12:09 kk
[root@server3 gluster_client]#

[root@server2 gluster_client]# ll
total 1
-rw-r--r-- 1 root root 6 May 29 12:11 david.txt
-rw-r--r-- 1 root root 0 May 29 12:09 kk
[root@server2 gluster_client]#

[root@server1 gluster_client]# ll
total 1
-rw-r--r-- 1 root root 6 May 29 12:11 david.txt
-rw-r--r-- 1 root root 0 May 29 12:09 kk
[root@server1 gluster_client]#

Ampliación de un filesystem GlusterFS

Como he montado la estructura con LVM, la ampliación se realiza, exactamente igual que en cualquier otro FS con estructura LVM. Veamos un ejemplo:

[root@glustersrv1 ~]# pvresize /dev/xvdb
  Physical volume "/dev/xvdb" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized
[root@glustersrv1 ~]#
[root@glustersrv1 ~]# xfs_growfs  /dev/vggluster/lvgluster
meta-data=/dev/mapper/vggluster-lvgluster isize=512    agcount=4, agsize=65280 b                                                                                                                     lks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0 spinodes=0
data     =                       bsize=4096   blocks=261120, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=855, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 261120 to 2620416
[root@glustersrv1 ~]#
[root@glustersrv1 ~]# df -hP /glusterclient/
Filesystem               Size  Used Avail Use% Mounted on
glustercl1:/glustervol1   10G  137M  9.9G   2% /glusterclient
[root@glustersrv1 ~]#

¿Y si quiero ampliar el filesytem añadiendo un nuevo Brick?

Otra manera de ampliar un filesystem de GlusterFS es añadiendo un nuevo Brick a un volumen existente.

Así que crearemos un nuevo filesystem en los tres servidores del cluster, que lo llamaremos glustersrv2 y luego lo añadiremos al volumen glustervol1.

[root@glustersrv1 ~]# df -hP /glustersrv2
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vggluster-lvgluster2 1017M   33M  985M   4% /glustersrv2
[root@glustersrv1 ~]#

[root@glustersrv1 ~]# gluster volume add-brick glustervol1 replica 3 arbiter 1  glustercl1:/glustersrv2/brick glustercl2:/glustersrv2/brick glustercl3:/glustersrv2/brick
volume add-brick: success
[root@glustersrv1 ~]#

[root@glustersrv1 ~]# gluster volume info

Volume Name: glustervol1
Type: Distributed-Replicate
Volume ID: 8d51c4b2-f53b-403d-baa8-2d3d4ae1af00
Status: Started
Snapshot Count: 0
Number of Bricks: 2 x (2 + 1) = 6
Transport-type: tcp
Bricks:
Brick1: glustercl1:/glustersrv/brick
Brick2: glustercl2:/glustersrv/brick
Brick3: glustercl3:/glustersrv/brick (arbiter)
Brick4: glustercl1:/glustersrv2/brick
Brick5: glustercl2:/glustersrv2/brick
Brick6: glustercl3:/glustersrv2/brick (arbiter)
Options Reconfigured:
nfs.rpc-auth-allow: *
performance.client-io-threads: off
nfs.disable: off
transport.address-family: inet
[root@glustersrv1 ~]#

Una vez añadido el nuevo FS al cluster de Gluster, también vemos que ha aumentado el tamaño del FS. En este caso, en 1GB más:

[root@glustersrv1 ~]# df -hP /glusterclient/
Filesystem               Size  Used Avail Use% Mounted on
glustercl1:/glustervol1   11G  1.2G  9.9G  11% /glusterclient
[root@glustersrv1 ~]#

¿Puedo crear un cluster con nodos impares?

Si quisiera crear un cluster de cinco nodos, por ejemplo, también es posible. Veamos un ejemplo:

[root@gluster1 ~]# gluster volume create glustervol1 replica 5 transport tcp gluster1:/gluster/brick gluster2:/gluster/brick gluster3:/gluster/brick gluster4:/gluster/brick gluster5:/gluster/brick
volume create: glustervol1: success: please start the volume to access data
[root@gluster1 ~]#

[root@gluster1 ~]# gluster volume info

Volume Name: glustervol1
Type: Replicate
Volume ID: fe0ae11b-cb98-43d5-ad0a-8e396dd4bce8
Status: Created
Snapshot Count: 0
Number of Bricks: 1 x 5 = 5
Transport-type: tcp
Bricks:
Brick1: gluster1:/gluster/brick
Brick2: gluster2:/gluster/brick
Brick3: gluster3:/gluster/brick
Brick4: gluster4:/gluster/brick
Brick5: gluster5:/gluster/brick
Options Reconfigured:
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off
[root@gluster1 ~]# gluster volume start glustervol1
volume start: glustervol1: success
[root@gluster1 ~]#

[root@gluster5 gluster_client]# ls -la
total 1
drwxr-xr-x   3 root root  41 Jun 17 11:09 .
dr-xr-xr-x. 19 root root 261 Jun 17 11:08 ..
-rw-r--r--   1 root root   6 Jun 17 11:09 david.txt
[root@gluster5 gluster_client]#

[root@gluster1 gluster_client]# ll
total 1
-rw-r--r-- 1 root root 6 Jun 17 11:09 david.txt
[root@gluster1 gluster_client]#

Reemplazar un disco del cluster de Gluster

Si hemos tenido una avería hardware en un disco o estamos migrando de cabina de discos, nos interesará reemplazar un disco de gluster por uno nuevo. En el siguiente ejemplo, vamos a sustituir el «brick» glustercl1:/glustersrv2/brick por el glustercl1:/glustersrv3/brick.

Primero de todo, consultamos el estado del cluster:

[root@glustersrv1 ~]# gluster volume status glustervol1
Status of volume: glustervol1
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick glustercl1:/glustersrv/brick          49152     0          Y       4198
Brick glustercl2:/glustersrv/brick          49152     0          Y       4286
Brick glustercl3:/glustersrv/brick          49152     0          Y       3970
Brick glustercl1:/glustersrv2/brick         49153     0          Y       4211
Brick glustercl2:/glustersrv2/brick         49153     0          Y       4296
Brick glustercl3:/glustersrv2/brick         49153     0          Y       3980
NFS Server on localhost                     N/A       N/A        N       N/A
Self-heal Daemon on localhost               N/A       N/A        Y       4222
NFS Server on glustercl2                    N/A       N/A        N       N/A
Self-heal Daemon on glustercl2              N/A       N/A        Y       4307
NFS Server on glustercl3                    N/A       N/A        N       N/A
Self-heal Daemon on glustercl3              N/A       N/A        Y       3991

Task Status of Volume glustervol1
------------------------------------------------------------------------------
There are no active volume tasks

[root@glustersrv1 ~]#

Añadimos un disco nuevo (/dev/xvdg) con la estructura de gluster:

Añado un disco nuevo, el xvdg:

[root@glustersrv1 ~]# fdisk -l |grep dev |grep -v mapper
Disk /dev/xvda: 8589 MB, 8589934592 bytes, 16777216 sectors
/dev/xvda1   *        2048    16777215     8387584   83  Linux
Disk /dev/xvdf: 1073 MB, 1073741824 bytes, 2097152 sectors
Disk /dev/xvdb: 10.7 GB, 10737418240 bytes, 20971520 sectors
Disk /dev/xvdg: 1073 MB, 1073741824 bytes, 2097152 sectors
[root@glustersrv1 ~]#


[root@glustersrv1 ~]# mkfs.xfs /dev/xvdg
meta-data=/dev/xvdg              isize=512    agcount=4, agsize=65536 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=262144, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
[root@glustersrv1 ~]#


[root@glustersrv1 ~]# df -hP /glustersrv3
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvdg      1014M   33M  982M   4% /glustersrv3
[root@glustersrv1 ~]#


[root@glustersrv1 ~]# mkdir /glustersrv3/brick

Y reemplazamos el disco o brick:

[root@glustersrv1 ~]# gluster volume replace-brick glustervol1 glustercl1:/glustersrv2/brick glustercl1:/glustersrv3/brick commit force
volume replace-brick: success: replace-brick commit force operation successful
[root@glustersrv1 ~]#

[root@glustersrv1 ~]# gluster volume info

Volume Name: glustervol1
Type: Distributed-Replicate
Volume ID: 8d51c4b2-f53b-403d-baa8-2d3d4ae1af00
Status: Started
Snapshot Count: 0
Number of Bricks: 2 x (2 + 1) = 6
Transport-type: tcp
Bricks:
Brick1: glustercl1:/glustersrv/brick
Brick2: glustercl2:/glustersrv/brick
Brick3: glustercl3:/glustersrv/brick (arbiter)
Brick4: glustercl1:/glustersrv3/brick
Brick5: glustercl2:/glustersrv2/brick
Brick6: glustercl3:/glustersrv2/brick (arbiter)
Options Reconfigured:
nfs.rpc-auth-allow: *
performance.client-io-threads: off
nfs.disable: off
transport.address-family: inet
[root@glustersrv1 ~]#

¿Qué ocurre si se cae el servidor de quorum (arbiter)?

Los otros clientes que tienen montado el filesystem de gluster se quedan «congelados» durante unos segundos. Luego, ya vuelven a responder y la réplica de datos funciona con normalidad.

No obstante, esto podría ser un problema para alguna aplicación, ya que el sistema operativo le podría devolver un error de acceso al sistema de archivos mientras éste no está respondiendo, si los timeouts y reintentos de acceso al filesystem no están configurados con el suficiente tiempo.

En este ejemplo, he apagado el servidor árbitro y un simple «ll» no responde.

GlusterFS - Comando ll no responde tras apagar el servidor de Quorum (arbiter)

Para añadir un nuevo servidor de quorum, tendríamos que añadir tres servidores nuevos al cluster de gluster, ya que la configuración es 3 a 1 (3 réplicas y un árbitro).

# gluster volume create testvol replica 3 arbiter 1 \
server1:/bricks/brick server2:/bricks/brick server3:/bricks/arbiter_brick \
server4:/bricks/brick server5:/bricks/brick server6:/bricks/arbiter_brick

# gluster volume info testvol
Volume Name: testvol
Type: Distributed-Replicate
Volume ID: ed9fa4d5-37f1-49bb-83c3-925e90fab1bc
Status: Created
Snapshot Count: 0
Number of Bricks: 2 x (2 + 1) = 6
Transport-type: tcp
Bricks:
Brick1: server1:/bricks/brick
Brick2: server2:/bricks/brick
Brick3: server3:/bricks/arbiter_brick (arbiter)
Brick1: server4:/bricks/brick
Brick2: server5:/bricks/brick
Brick3: server6:/bricks/arbiter_brick (arbiter)
Options Reconfigured:
transport.address-family: inet
performance.readdir-ahead: on
nfs.disable: on

No es posible hacer un 3 a 2, por ejemplo, ni ninguna otra configuración:

[root@glustersrv1 ~]# gluster volume add-brick glustervol1 replica 3 arbiter 2 glustercl4:/glustersrv
For arbiter configuration, replica count must be 3 and arbiter count must be 1. The 3rd brick of the replica will be the arbiter

Usage:
volume add-brick <VOLNAME> [<stripe|replica> <COUNT> [arbiter <COUNT>]] <NEW-BRICK> ... [force]

[root@glustersrv1 ~]#


[root@glustersrv1 ~]# gluster volume add-brick glustervol1 replica 4  glustercl4:/glustersrv
volume add-brick: failed: Increasing replica count for arbiter volumes is not supported.
[root@glustersrv1 ~]#

Eliminar un nodo del cluster de Gluster

Si queremos dar de baja uno de los nodos del cluster de GlusterFS, utilizaremos el siguiente comando:

[root@glustersrv1 ~]# gluster peer detach glustercl4
All clients mounted through the peer which is getting detached need to be remounted using one of the other active peers in the trusted storage pool to ensure client gets notification on any changes done on the gluster configuration and if the same has been done do you want to proceed? (y/n) y
peer detach: success
[root@glustersrv1 ~]#

Exportar por NFS un filesystem de GlusterFS

Lo que vamos a hacer a continuación es exportar por NFS el volumen de Gluster glustervol1.

Instalación del servidor NFS Ganesha en el servidor de Gluster

En el servidor de Gluster, tendremos que instalar el software Ganesha-NFS para exportar por NFS un volumen de Gluster, ya que no utiliza el servicio tradicional de NFS (está obsoleto). Lo haremos de la siguiente manera:

[root@glustersrv1 ~]# yum install -y nfs-ganesha nfs-ganesha-gluster
[root@glustersrv1 ~]# systemctl start nfs-ganesha
[root@glustersrv1 ~]# systemctl enable nfs-ganesha
Created symlink from /etc/systemd/system/multi-user.target.wants/nfs-ganesha.service to /usr/lib/systemd/system/nfs-ganesha.service.
[root@glustersrv1 ~]#

Configuración del filesystem NFS a exportar

Editaremos el fichero de configuración /etc/ganesha/ganesha.conf para indicar qué volumen de Gluster queremos exportar. Para ello, añadiremos las siguientes líneas:

EXPORT{
Export_Id = 1;
Path = «/glustervol1»;
FSAL {
name = GLUSTER;
hostname=»localhost»;
volume=»glustervol1″;
}
Access_type = RW;
Disable_ACL = true;
Squash=»No_root_squash»;
Pseudo=»/glustervol1″;
Protocols = «3», «4» ;
Transports = «UDP»,»TCP»;
SecType = «sys»;
}

Si quisiéramos exportar otro filesystem, añadiríamos una nueva sección «EXPORT».

Reiniciamos Ganesha y comprobamos que se está exportando por NFS el volumen de GlusterFS indicado:

[root@glustersrv1 ~]# systemctl reload nfs-ganesha

[root@glustersrv1 ~]# showmount -e localhost
Export list for localhost:
/glustervol1 (everyone)
[root@glustersrv1 ~]#

Configurar el servicio de Gluster para permitir exportar volúmenes por NFS

Primero habilitamos NFS:

[root@glustersrv1 ~]# gluster volume set glustervol1  nfs.disable off
Gluster NFS is being deprecated in favor of NFS-Ganesha Enter "yes" to continue using Gluster NFS (y/n) y
volume set: success
[root@glustersrv1 ~]#

Y luego permitimos las IPs que se podrán conectar al servicio:

[root@glustersrv1 ~]# gluster volume set glustervol1 nfs.rpc-auth-allow glustercl1,glustercl2,glustercl3,glustercl4
volume set: success
[root@glustersrv1 ~]#

Para permitir a todas las IPs, ejecutar el comando:

gluster volume set glustervol1 nfs.rpc-auth-allow "*"

[root@glustersrv1 ~]# service glusterd restart
Redirecting to /bin/systemctl restart glusterd.service
[root@glustersrv1 ~]#


[root@glustersrv1 ~]# gluster volume info

Volume Name: glustervol1
Type: Replicate
Volume ID: 8d51c4b2-f53b-403d-baa8-2d3d4ae1af00
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x (2 + 1) = 3
Transport-type: tcp
Bricks:
Brick1: glustercl1:/glustersrv/brick
Brick2: glustercl2:/glustersrv/brick
Brick3: glustercl3:/glustersrv/brick (arbiter)
Options Reconfigured:
transport.address-family: inet
nfs.disable: off
performance.client-io-threads: off
nfs.rpc-auth-allow: glustercl1,glustercl2,glustercl3,glustercl4
[root@glustersrv1 ~]#

Montar el filesystem de Gluster por NFS desde el cliente NFS

En cliente tendremos que instalar el paquete nfs-utils:

yum install -y nfs-utils

Y luego montar el volumen de Gluster como si de cualquier otro cualquier filesystem NFS se tratara:

[root@glustersrv4 ~]# mount -t nfs glustercl1:/glustervol1 /glusternfs
[root@glustersrv4 ~]# df -hP /glusternfs/
Filesystem               Size  Used Avail Use% Mounted on
glustercl1:/glustervol1   10G  1.2G  8.9G  12% /glusternfs
[root@glustersrv4 ~]#

Deja un comentario