PDF

1.  Qué es GlusterFS?

En el mundo de los SDS (Software Defined Storage = Almacenamiento definido por software) hay varias opciones: Ceph, ClusterFS, MinIO Cloud, Scality… entre muchos otros. El que se presenta es GlusterFS.

GlusterFS es una herramienta escrita en C puro y, al igual que Ceph, es un sistema de ficheros SDS que al ser open-source proporcionan grandes ventajas sobre sistemas propietarios. Tiene una curva de aprendizaje poco pronunciada, por lo que es realmente bien sencillo crear un cluster GlusterFS, un tanto más simple que Ceph. También es más liviano que Ceph, para el cual se recomienda un hardware más potente. Cuenta con soporte de RedHat (su empresa matriz).

El único punto negativo que se le ha podido encontrar ha sido que sus logs no son muy explicitos, y que a la hora de revisarlos cuesta un poco encontrar detalles significativos si no se sabe lo que se está haciendo.

Un clúster Gluster puede tener las siguientes características:

• Replicación, por tanto, puede ser considerado como HA (Alta disponibilidad).
• Distribuido, por lo que permite escalamiento.
• Dispersión, lo que implica que a la hora de guardar archivos que pasen un umbral de tamaño se van a trocear y se van a guardar distributivamente en cada servidor.

Tipos de volúmenes en GlusterFS

Gluster puede tener varias configuraciones, adaptables a las necesidades del usuario. Las más usadas son:

Distribuido: los volúmenes Distribuidos distribuyen archivos a través de los discos del volumen. Se puede utilizar volúmenes distribuidos cuando el requisito es escalar el almacenamiento y la redundancia no es importante o la proporcionan otras capas de hardware/software. La falla de un disco o de uno de los servidores que conformen los volúmenes distribuidos puede resultar en una pérdida grave de datos porque el contenido del directorio se distribuye aleatoriamente entre los bloques del volumen.

Replicado: los volúmenes Replicados replican archivos en todos los discos del volumen. Se aconseja utilizar volúmenes replicados en entornos donde la alta disponibilidad y la alta confiabilidad son fundamentales.

Distribuido replicado: los volúmenes Distribuidos Replicados distribuyen archivos a través de discos replicados en el volumen. Puede utilizar volúmenes replicados distribuidos en entornos donde el requisito es escalar el almacenamiento y la alta confiabilidad es fundamental. Los volúmenes replicados distribuidos también ofrecen un rendimiento de lectura mejorado en la mayoría de los entornos.

Striped: Los volúmenes distribuidos en bandas (striped) distribuyen los archivos en dos o más nodos del clúster. Para obtener los mejores resultados, se debe utilizar volúmenes striped donde el requisito es escalar el almacenamiento y en entornos de alta concurrencia, el acceso a archivos muy grandes es fundamental.

2.    Implementación de un Volumen Distribuido Replicado

En el laboratorio que se presenta se trabaja con varias VMs, la idea es crear a partir de muchos discos repartidos equitativamente entre los servidores (las primeras 3 VMs) un volumen de almacenamiento que se encuentra distribuido, replicado, pero también striped.

Para realizar el laboratorio se cuenta con:

El laboratorio cuenta con 3 VMs, 3 servidores y una PC cliente. Todas corren sobre Ubuntu 20.04.3, aunque también se intentara incluir datos para Debian 11, las diferencias son muy pocas. Para simular el escenario se utiliza GNS3.

Las configuraciones de las VMs son:

La idea es montar un clúster gluster (que no es más que un volumen de discos que puede ser montado vía red) utilizando los 3 servidores (gluster1, gluster2 y gluster3). Como dice el titulo del subcapítulo será un clúster Distribuido Replicado.

La siguiente imagen muestra lo que se desea lograr con este laboratorio:

Al ser un laboratorio y no tener un servidor DNS disponible habrá que crear una entrada en el archivo /etc/hosts para que las VMs sean capaces de verse entre sí utilizando nombres en vez de IPs. Así que:

Configuración de /etc/hosts en gluster1 agregando las líneas:

echo "" >> /etc/hosts && \
echo "# Gluster1" >> /etc/hosts && \
echo "127.0.0.1 gluster1.sysadmin.cu gluster1" >> /etc/hosts && \
echo "192.168.120.20 gluster2.sysadmin.cu gluster2" >> /etc/hosts && \
echo "192.168.120.30 gluster3.sysadmin.cu gluster3" >> /etc/hosts && \
echo "192.168.120.100 glusterclient.sysadmin.cu      glusterclient" >> /etc/hosts && \
echo "gluster1" > /etc/hostname && \
echo "gluster3" > /proc/sys/kernel/hostname && \
bash

Configurar la red del host “gluster1”:

cat << EOF > /etc/netplan/01-network-manager-all.yaml
network:
 version: 2
 renderer: networkd
 ethernets:
   ens33:
     addresses:
       - 192.168.120.10/24
     nameservers:
       addresses: [8.8.8.8, 8.8.4.4]
     routes:
       - to: default
         via: 192.168.120.169
EOF

Aplicar los cambios de red:

netplan apply

Configuración de /etc/hosts en gluster2 agregando las líneas:

echo "" >> /etc/hosts && \
echo "# Gluster2" >> /etc/hosts && \
echo "192.168.120.10 gluster1.sysadmin.cu gluster1" >> /etc/hosts && \
echo "127.0.0.1 gluster2.sysadmin.cu gluster2" >> /etc/hosts && \
echo "192.168.120.30 gluster3.sysadmin.cu gluster3" >> /etc/hosts && \
echo "192.168.120.100 glusterclient.sysadmin.cu glusterclient" >> /etc/hosts && \
echo "gluster2" > /etc/hostname && \
echo "gluster2" > /proc/sys/kernel/hostname && \
bash

Configurar la red del host “gluster2”:

cat << EOF > /etc/netplan/01-network-manager-all.yaml
network:
 version: 2
 renderer: networkd
 ethernets:
   ens33:
     addresses:
       - 192.168.120.20/24
     nameservers:
       addresses: [8.8.8.8, 8.8.4.4]
     routes:
       - to: default
         via: 192.168.120.169
EOF

Aplicar los cambios de red:

netplan apply

Configuración de /etc/hosts en gluster3 agregando las líneas:

echo "" >> /etc/hosts && \
echo "# Gluster3" >> /etc/hosts && \
echo "192.168.120.10 gluster1.sysadmin.cu gluster1" >> /etc/hosts && \
echo "192.168.120.20 gluster2.sysadmin.cu gluster2" >> /etc/hosts && \
echo "127.0.0.1 gluster3.sysadmin.cu gluster3" >> /etc/hosts && \
echo "192.168.120.100 glusterclient.sysadmin.cu glusterclient" >> /etc/hosts && \
echo "gluster3" > /etc/hostname && \
echo "gluster3" > /proc/sys/kernel/hostname && \
bash

Configurar la red del host “gluster3”:

cat << EOF > /etc/netplan/01-network-manager-all.yaml
network:
 version: 2
 renderer: networkd
 ethernets:
   ens33:
     addresses:
       - 192.168.120.30/24
     nameservers:
       addresses: [8.8.8.8, 8.8.4.4]
     routes:
       - to: default
         via: 192.168.120.169
EOF

Aplicar los cambios de red:

netplan apply

Configuración de /etc/hosts en glusterclient agregando las líneas:

echo "" >> /etc/hosts && \
echo "# Gluster Client" >> /etc/hosts && \
echo "192.168.120.10 gluster1.sysadmin.cu gluster1" >> /etc/hosts && \
echo "192.168.120.20 gluster2.sysadmin.cu gluster2" >> /etc/hosts && \
echo "192.168.120.30 gluster3.sysadmin.cu gluster3" >> /etc/hosts && \
echo "127.0.0.1 glusterclient.sysadmin.cu glusterclient" >> /etc/hosts && \
echo "glusterclient" > /etc/hostname && \
echo "glusterclient" > /proc/sys/kernel/hostname&& \
bash

Configurar la red del host “glusterclient”:

cat << EOF > /etc/netplan/01-network-manager-all.yaml
network:
 version: 2
 renderer: networkd
 ethernets:
   ens33:
     addresses:
       - 192.168.120.100/24
     nameservers:
       addresses: [8.8.8.8, 8.8.4.4]
     routes:
       - to: default
         via: 192.168.120.169
EOF

Aplicar los cambios de red:

netplan apply

Una vez hechos los cambios comprobamos haciendo ping por nombre.

2.1.       Instalación de GlusterFS en Ubuntu/Debian

Dejar claro que en los repos oficiales de Ubuntu 20.04 y Debian 10 la versión de GlusterFS que viene es la 7.X, aunque esta versión es compatible con lo utilizado en esta guía, se recomienda instalar las versiones más actuales. En el caso específico de los repos de Debian 11, los paquetes necesarios de glusterfs se encuentran bien actualizados, pero de todos modos, si se tiene la oportunidad se recomienda usar los repos oficiales de internet.

Para Ubuntu:

add-apt-repository ppa:gluster/glusterfs-9 && \
apt update

Para Debian:

wget -O - https://download.gluster.org/pub/gluster/glusterfs/9/rsa.pub | apt-key add -

Si lo anterior no funciona, usar la siguiente línea:

wget -O - https://download.gluster.org/pub/gluster/glusterfs/7/rsa.pub | apt-key add -

Añadir la fuente:

DEBID=$(grep 'VERSION_ID=' /etc/os-release | cut -d '=' -f 2 | tr -d '"') && \
DEBVER=$(grep 'VERSION=' /etc/os-release | grep -Eo '[a-z]+') && \
DEBARCH=$(dpkg --print-architecture) && \
echo deb https://download.gluster.org/pub/gluster/glusterfs/LATEST/Debian/${DEBID}/${DEBARCH}/apt \
${DEBVER} main > /etc/apt/sources.list.d/gluster.list apt update

En los servidores (gluster1, gluster2 y gluster3) será necesario instalar el paquete glusterfs-server. NOTA: al instalar este paquete se auto instala el cliente de glusterfs.

apt install glusterfs-server -y

Una vez instalado se puede verificar su versión:

gluster --version

glusterfs 9.4
Repository revision: git://git.gluster.org/glusterfs.git
Copyright (c) 2006-2016 Red Hat, Inc. <https://www.gluster.org/>
GlusterFS comes with ABSOLUTELY NO WARRANTY.
It is licensed to you under your choice of the GNU Lesser
General Public License, version 3 or any later version (LGPLv3
or later), or the GNU General Public License, version 2 (GPLv2),
in all cases as published by the Free Software Foundation.

Una vez instalados deberemos de habilitar el servicio que se creó con la instalación (en ambos servidores), su nombre es glusterd, el siguiente comando además de habilitarlo lo inicia sin esperar al siguiente reinicio del sistema:

systemctl enable --now glusterd

Mientras que en el cliente será necesario instalar tan solo el paquete glusterfs-client:

apt install glusterfs-client -y

Para comprobar que se tiene funcionando el servicio, correr el siguiente comando en cualquiera de los 3 servidores que hospedarán el clúster:

gluster peer status

Debe devolver lo siguiente:

Number of Peers: 0

2.2.       Configuraciones

Conformar un pool de almacenamiento:

Lo primero que se necesita hacer es que se agrupen los servidores para formar un solo pool de almacenamiento. Desde el gluster1 se correrá el siguiente comando (aunque se podría haber ejecutado desde cualquiera de los 3 servidores teniendo en cuenta a quien se va a agregar):

En host “gluster1”:

# gluster peer probe [ip|hostname]

gluster peer probe gluster2

Lo mismo, pero para gluster3:

gluster peer probe gluster3

Cuando se reciba el mensaje de success, se podrá, desde cualquiera de los tres nodos, verificar el estado de los gluster peers (comando corrido desde gluster1):

 gluster peer status

Debe devolver algo similar a:

Number of Peers: 2

Hostname: gluster2
Uuid: 07eedacc-8b7a-4003-a448-bcaadbcb7c27
State: Accepted peer request (Connected)

Hostname: gluster3
Uuid: b36e6bfd-7050-414a-8890-5a642ac56bc8
State: Peer in Cluster (Connected)

Como se puede ver el comando gluster peer status nos hace saber que tenemos 2 peers, que esos peers tienen como nombre gluster2 y gluster3, y que además se encuentran conectados. En caso de que uno de los peers no se encuentre, en el apartado State del status nos mostrará Disconnected.

Ya se tiene un pool de almacenamiento, lo que implica que todos los hosts pertenecientes al mismo serán capaces de compartir sus discos (llamados bricks en la documentación oficial). Ahora se debe de darle formato a los discos que vamos a agregar.

 En host “gluster1”, “gluster2” y “gluster3”:

 El primer paso sería identificar los discos a agregar, esta tarea se puede realizar simplemente enviando un y revisando que discos no tengan ninguna partición creada:

fdisk -l

En el caso particular de este laboratorio los discos nuevos obtuvieron el identificativo de sda y sdb, pero pueden tomar cualquier otro valor.

Toca la tarea de dar formato a los discos. El siguiente procedimiento debe realizarse para cada disco que forme parte del clúster de gluster, en cada uno de los servidores de gluster (gluster1, gluster2 y gluster3).

Para el brick0 y brick1, se puede utilizar ext4, pero en la documentación se recomienda xfs:

dev='/dev/sdb' && \
printf "o\nn\np\n1\n\n\nw\n" | fdisk "$dev" && \
mkfs.xfs -i size=512 "${dev}1" && \
dev='/dev/sdc' && \
printf "o\nn\np\n1\n\n\nw\n" | fdisk "$dev" && \
mkfs.xfs -i size=512 "${dev}1"

Ahora toca crear el directorio donde se va a montar el disco. Aunque se puede utilizar cualquier punto de montaje en este laboratorio se decicidio utilizar la siguiente sintaxis:

# mkdir -p /data/glusterfs/[volname]/brick[id]
mkdir -p /data/glusterfs/vol1/brick0 && \
mkdir -p /data/glusterfs/vol1/brick1

Agregar el punto de montaje de forma persistente:

# echo "/dev/sd[disk_label]1       /data/glusterfs/vol1/brick0 xfs defaults 0 0 " >> /etc/fstab
echo "/dev/sdb1       /data/glusterfs/vol1/brick0 xfs defaults 0 0 " >> /etc/fstab && \
echo "/dev/sdc1       /data/glusterfs/vol1/brick1 xfs defaults 0 0 " >> /etc/fstab

Aplicar el montaje:

mount -a

Verificar si se realizaron correctamente los puntos de montaje:

df -hT | grep glusterfs

dev/sdb1      xfs       5.0G   68M  5.0G   2% /data/glusterfs/vol1/brick0
/dev/sdc1      xfs       5.0G   68M  5.0G   2% /data/glusterfs/vol1/brick1

Hacer el mismo procedimiento para cada disco q va a formar parte del pool en cada nodo. Note que en el caso del ejemplo son 6 discos en total.

2.2.1.   Creando el volumen de almacenamiento

En host “gluster1”, “gluster2” y “gluster3”:

Crear directorio data en el punto de montaje de cada brick en cada servidor gluster (gluster1, gluster2, gluster3), ya que gluster necesita de una carpeta donde “montarse”:

mkdir -p /data/glusterfs/vol1/brick0/data && \
mkdir -p /data/glusterfs/vol1/brick1/data

Ahora toca el turno de crear el volumen. En este caso, como ya se ha mencionado, se utilizará la arquitectura de volumen Distribuido Replicado. Al comando hay que pasarle como argumento cada uno de los discos que van a formar parte del volumen. Como ejemplo se toma el siguiente comando:

# gluster volume create vol1 replica 2 transport tcp \
# gluster1:/data/glusterfs/vol1/brick0 \
# gluster1:/data/glusterfs/vol1/brick1

En el caso anterior se está creando un nuevo volumen llamado vol1, con réplica 2 (o sea, que va a replicarse en 2 discos, esta opción puede cambiarse para que la información a guardar se replique en más de un disco), y esos dos discos están ubicados en el servidor gluster1 en el punto de montaje /data/glusterfs/vol1/brick0 y /data/glusterfs/vol1/brick1.

Hay que tener en cuenta que a la hora de crear este tipo de volúmenes en dependencia del tipo de replicación (2, 3, 4, que implica la cantidad de discos que se van a tomar para funcionar como espejos) los discos pertenecientes a unas parejas no pueden formar partes de otras parejas. Mas importante aún: las parejas (o tríos, o…) se conforman especificando los discos que formaran parte de ellas de la siguiente forma:

gluster volume create vol1 replica 2 transport tcp \
[server1:/brick0/mount/point/path/data] \
[server2:/brick0/mount/point/path/data] \
[server1:/brick1/mount/point/path/data] \
[server2:/brick1/mount/point/path/data] force

De tal forma que la primera pareja serán los discos ubicados en [server1:/brick0/mount/point/path/data] [server2:/brick0/mount/point/path/data] mientras que la segunda pareja seran los discos ubicados en [server1:/brick1/mount/point/path/data] [server2:/brick1/mount/point/path/data]

En el caso del laboratorio en específico se desea hacer una replica de orden 2 (replicando la información en dos discos) pero en 3 servidores, por lo tanto el comando quedaría:

gluster volume create vol1 replica 2 transport tcp \
gluster1:/data/glusterfs/vol1/brick0/data \
gluster2:/data/glusterfs/vol1/brick0/data \
gluster1:/data/glusterfs/vol1/brick1/data \
gluster3:/data/glusterfs/vol1/brick0/data \
gluster2:/data/glusterfs/vol1/brick1/data \
gluster3:/data/glusterfs/vol1/brick1/data force

Debe devolver lo siguiente:

volume create: vol1: success: please start the volume to access data

Una vez creado el volumen, podremos listarlo:

gluster volume info vol1 | grep Status
Status: Created

Ahora resta inicializarlo:

gluster volume start vol1

Verificar información del volumen creado:

gluster volume info vol1 | grep Status
Status: Started

2.2.2.   Configuraciones adicionales

En gluster1:

Establecer UID y GID, esta opción puede ser necesaria cuando algunas de las aplicaciones necesitan que el disco tenga un UID específico para funcionar correctamente. Ejemplo: para la integración de QEMU, el UID/GID debe ser qemu:qemu, es decir, 107:107.

gluster volume set vol1 storage.owner-uid 1000 && \
gluster volume set vol1 storage.owner-gid 1000

Optimizaciones y personalizaciones:

Tener en cuenta que las siguientes modificaciones son específicas de una aplicación y que pueden variar en dependencia de las especificidades del despliegue.

gluster volume set vol1 network.remote-dio enable && \
gluster volume set vol1 cluster.eager-lock enable && \
gluster volume set vol1 performance.io-cache off && \
gluster volume set vol1 performance.quick-read off && \
gluster volume set vol1 performance.read-ahead off && \
gluster volume set vol1 user.cifs off && \
gluster volume set vol1 cluster.favorite-child-policy mtime

Donde:

• remote-dio enable: Permitirá habilitar el caché para operaciones de clientes en la red.
• eager-lock enable: Permite que se realicen varias operaciones de escritura al mismo tiempo. SI está desactivado, la escritura en el volumen se podrá hacer solamente cuando se haya terminado la operación de escritura previa.
• io-cache off: Deshabilita el IO-cache, que es el traductor encargado de guardar en caché los datos que son leídos. Habilitarlo sería útil si muchas aplicaciones leen datos varias veces, siendo más frecuentes las lecturas que las escrituras.
• quick-read off: Deshabilita las lecturas rápidas en el IO-cache del volumen.
• read-ahead off: Deshabilita que gluster utilice predicciones para guardar/mantener en cache datos accesados.
• cifs off: Deshabilita soporte para clientes Windows. Permite utilizar el volumen en clientes con este tipo de OS, complementando esta opción con user.smb.
• favorite-child-policy [size|ctime||mtime|majority]: Específica qué política se puede utilizar para resolver automáticamente los split-brain sin la intervención del usuario (sin la necesidad de gluster volumen heal). Se puede elegir entre varias opciones: “size”, «majority», “ctime” y “mtimea”
  • size: elige el archivo con el tamaño más grande como fuente.
  • ctime y mtime: eligen el archivo con el último ctime y mtime respectivamente como fuente.
  • majority: elige un archivo con mtime y tamaño idénticos en más de la mitad del número de discos de la réplica.

Si ocurre algún tipo de error en la configuración siempre se puede resetear:

gluster volume reset [volname] [option-name]

2.2.3     Fragmentación (Sharding)

Bien, se tiene un volumen creado de, dígase, 1 TB de espacio disponible, pero realmente conformado por discos de espacio más pequeño, entonces qué pasaría si se necesitan copiar archivos inmensos que sobrepasen la capacidad real de cada disco que forma parte del volumen? Para estos casos gluster trae la fragmentación o sharding.

Debido a que la fragmentación (sharding) distribuye los archivos a través de los discos en un volumen, le permite almacenar archivos con un tamaño agregado mayor que cualquier disco individual en el volumen. Debido a que las partes del archivo son más pequeñas, las operaciones de recuperación son más rápidas y las implementaciones replicadas geográficamente pueden sincronizar las partes pequeñas de un archivo que han cambiado, en lugar de sincronizar todo el archivo agregado.

Inicialmente, si se asume que el sharding se encuentra habilitado, todos los archivos se crearán como archivos normales hasta un cierto tamaño configurable. El primer bloque (por defecto 4 MB) se almacenará como un archivo normal. Sin embargo, los bloques adicionales se almacenarán en un archivo, nombrado por el GFID y el índice de bloque en un espacio de nombres separado (como /.shard/GFID1.1, /.shard/GFID1.2 … /.shard/GFID1.N). El tamaño de archivo agregado y el recuento de bloques se almacenarán en el archivo xattr del archivo original (primer bloque).

Habilitar fragmentación:

gluster volume set vol1 features.shard enable

El tamaño predeterminado del bloque de fragmentos es de 4 MB. Para modificarlo a 50MB, por ejemplo, hay que ejecutar lo siguiente:

gluster volume set vol1 features.shard-block-size 50MB

Verificar que todas las opciones habilitadas:

gluster volume info vol1

Devolviendo una salida similiar a:

Volume Name: vol1
Type: Distributed-Replicate
Volume ID: 5a9f8008-ffdb-4f33-99f8-abea36e620c7
Status: Started
Snapshot Count: 0
Number of Bricks: 3 x 2 = 6
Transport-type: tcp
Bricks:
Brick1: gluster1:/data/glusterfs/vol1/brick0/data
Brick2: gluster2:/data/glusterfs/vol1/brick0/data
Brick3: gluster1:/data/glusterfs/vol1/brick1/data
Brick4: gluster3:/data/glusterfs/vol1/brick0/data
Brick5: gluster2:/data/glusterfs/vol1/brick1/data
Brick6: gluster3:/data/glusterfs/vol1/brick1/data
Options Reconfigured:
cluster.favorite-child-policy: mtime
features.shard-block-size: 50MB
features.shard: enable
user.cifs: off
performance.read-ahead: off
performance.quick-read: off
performance.io-cache: off
cluster.eager-lock: enable
network.remote-dio: enable
storage.owner-gid: 1000
storage.owner-uid: 1000
cluster.granular-entry-heal: on
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off

2.2.3     Montando el volumen de Gluster

Ya se tiene listo y configurado el volumen, resta montarlo para que los máquinas clientes puedan usarlo. En este caso los mismos servidores tambien se utilizarán como clientes.

En gluster1, gluster2, gluster3 y glusterclient. Crear el directorio que se utilizará para montar el volumen de gluster:

mkdir -p /var/lib/datastores/gluster_mount

Montar el volumen de tipo glusterfs en su respectivo directorio:

mount -t glusterfs gluster1:vol1 /var/lib/datastores/gluster_mount

Verificar si se montó correctamente:

df -hT | grep /var/lib/datastores/gluster_mount

Debe devolver algo similar:

gluster1:vol1  fuse.glusterfs   30G  619M   30G   3% /var/lib/datastores/gluster_mount

Si la salida anterior mostraba el punto de montaje, entonces aplicar el cambio de forma persistente:

echo "gluster1:/vol1 /var/lib/datastores/gluster_mount glusterfs defaults,_netdev 0 0" >> /etc/fstab

Tener en cuenta que para la hora de montar el volumen no es necesario invocar a gluster1, ya que se pueden utilizar tambien tanto gluster2 como gluster3. Ejemplo:

# en cualquier PC cliente
mount -t glusterfs gluster3:vol1 /var/lib/datastores/gluster_mount

2.3    Comprobaciones

Una vez montado el volumen ya se será capaz de entrar a él como si fuese una carpeta más en la red, copiarle y borrarle elementos si se tienen los permisos. Como ejemplo se le copio al volumen el video “Breaking Bad S05E01 – Live Free or Die.mkv”.

En cualquier host que tenga el volumen montado:

ls -lh /var/lib/datastores/gluster_mount/

total 275M
-rw-r--r-- 1 root root 275M Nov  1 20:17 'Breaking Bad S05E01 - Live Free or Die.mkv'

Para obtener detalles más exhaustivos del volumen:

gluster volume status vol1 detail

Cuando se habilita la fragmentación, es posible que se desee comprobar que funciona correctamente o ver cómo se ha fragmentado un archivo en particular en el volumen. Para saber si funciona correctamente basta con revisar los discos que pertenecen al volumen, pues luego de que la opción se encuentre corriendo se crearán carpetas .shard en cada disco, en donde se copiaran los trozos de los archivos más grandes que el umbral dado (50MB en este caso).

El video que se copió al volumen gluster tenía un peso de 274MB (>50MB). Es de esperarse que Gluster fragmente dicho fichero a lo largo de su volumen distribuido y replicado (en tantos discos sea necesario).

Para encontrar las partes de ese archivo, se debe conocer su GFID. Para obtener el GFID de un archivo, ejecutar:

# getfattr -n glusterfs.gfid.string /volume/mount/point/path/ [FILENAME]
getfattr -n glusterfs.gfid.string /var/lib/datastores/gluster_mount/\Breaking\ Bad\ S05E01\ -\ Live\ Free\ or\ Die.mkv

Devolvió lo siguiente:

getfattr: Removing leading '/' from absolute path names
# file: var/lib/datastores/gluster_mount/Breaking Bad S05E01 - Live Free or Die.mkv
glusterfs.gfid.string="3545637f-2bbf-45d5-b0e3-c52b6ea1df25"

Crear el siguiente script para encontrar un shard, según su GFID:

mkdir -p ~/config/scripts && \
nano ~/config/scripts/gfid.sh

Agregar lo siguiente:

#!/bin/bash
if [[ "$#" < "2" || "$#" > "3" ]]; then
cat <<
fi
BRICK="$1"
GFID="$2"
GP1=`cut -c 1-2 <<<"$GFID"`
GP2=`cut -c 3-4 <<<"$GFID"`
GFIDPRE="$BRICK"/.glusterfs/"$GP1"/"$GP2"
GFIDPATH="$GFIDPRE"/"$GFID"
if [[ "$#" == "2" ]]; then
echo -ne "$GFID\t==\t"
fi
if [[ -h "$GFIDPATH" ]]; then
if [[ "$#" == "2" ]]; then
echo -ne "Directory:\t"
fi
DIRPATH="$GFIDPRE"/`readlink "$GFIDPATH"`
echo $(cd $(dirname "$DIRPATH"); pwd -P)/$(basename "$DIRPATH")
else
if [[ "$#" == "2" ]]; then
echo -ne "File:\t"
fi
INUM=`ls -i "$GFIDPATH" | cut -f 1 -d \ `
find "$BRICK" -inum "$INUM" ! -path \*.glusterfs/\*
fi

Dar permisos de ejecución:

chmod +x /config/scripts/gfid.sh

Y se corre el script para cada disco:

# ./config/scripts/gfid.sh /brick/mount/point/path/ GFID
. /config/scripts/gfid.sh /data/glusterfs/vol1/brick0/data 3545637f-2bbf-45d5-b0e3-c52b6ea1df25

En este caso, tras comprobar en todos los nodos gluster y en cada uno de sus bricks, se encontró un fragmentos del fichero en el Brick1 (brick0) del gluster1, gluster2 y gluster3, y Brick2 (brick1) del gluster1.

Una de las comprobaciones a realizar puede ser apagar uno de los nodos que conforman el volumen, emulando una pérdida de conexión con uno de los servidores que conforman parte del pool.

Ahora procedemos a apagar uno de los nodos y comprobar que podemos seguir listando:

En gluster1:

 shutdown -r now

En gluster2 o gluster3 una vez apagado gluster1:

gluster peer status

Deberá aparecer lo siguiente (en este caso desde gluster3):

Number of Peers: 2

Hostname: gluster1.sysadmin.cu
Uuid: 59c537b7-58ba-4e56-9962-890b433f8454
State: Peer in Cluster (Disconnected)

Hostname: gluster2
Uuid: 231fadcc-23e9-4146-8dbf-4868e5474c00
State: Peer in Cluster (Connected)

Al ser un volumen distribuido replicado en gluster2 y gluster3 se podrán seguir listando los archivos, aún con uno de los nodos del cluster off-line. No sólo listar, sino también copiar y ejecutar. Se ha logrado la HA.

ls -lh /var/lib/datastores/gluster_mount/
total 274M
-rw-r--r-- 1 root root 274M Nov  2 18:06 'Breaking Bad S05E01 - Live Free or Die.mkv'

Tener en cuenta que la configuración de este laboratorio en específico fue pensada para tener un sistema a prueba de fallos en el que se pueda perder uno de los nodos que conforma parte del pool. Aunque el volumen va a poder ser accesado desde la red incluso si se pierde la conexión con 2 de los nodos que forman parte del pool y leído (listar su contenido) puede darse el caso de que no se pueda copiar ese contenido, pues ese contenido puede radicar en uno de los discos de los nodos faltantes.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

En el siguiente articulo se mostrarán otros detalles, como: Agregar discos a un volumen ya creado, reemplazar discos rotos, sustituir un servidor roto por uno nuevo…..

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Autores:

• Frank Morales
• Franco Díaz