Creación de un clúster de discos (SDS) usando GlusterFS (Parte 1)

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:

VM1VM2VM3VM4
Hostname: gluster1Hostname: gluster2Hostname: gluster3Hostname: glusterclient
IP: 192.168.120.10IP: 192.168.120.20IP: 192.168.120.30IP: 192.168.120.100
HDD: 3, 1 para OS y 2 para clusterizarHDD: 3, 1 para OS y 2 para clusterizarHDD: 3, 1 para OS y 2 para clusterizarHDD: 1 para OS
Todas las VMs se encuentran en la misma red.
NOTA: Cada disco dispuesto para clusterizar es de apenas 5GB.

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:

Configurar la red del host “gluster1”:

Aplicar los cambios de red:

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

Configurar la red del host “gluster2”:

Aplicar los cambios de red:

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

Configurar la red del host “gluster3”:

Aplicar los cambios de red:

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

Configurar la red del host “glusterclient”:

Aplicar los cambios de red:

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:

Para Debian:

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

Añadir la fuente:

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.

Una vez instalado se puede verificar su versión:

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:

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

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

Debe devolver lo siguiente:

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”:

Lo mismo, pero para 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):

Debe devolver algo similar a:

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:

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:

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:

Agregar el punto de montaje de forma persistente:

Aplicar el montaje:

Verificar si se realizaron correctamente los puntos de montaje:

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”:

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:

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:

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:

Debe devolver lo siguiente:

Una vez creado el volumen, podremos listarlo:

Ahora resta inicializarlo:

Verificar información del volumen creado:

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.

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.

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:

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:

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

Verificar que todas las opciones habilitadas:

Devolviendo una salida similiar a:

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:

Montar el volumen de tipo glusterfs en su respectivo directorio:

Verificar si se montó correctamente:

Debe devolver algo similar:

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

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:

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:

Para obtener detalles más exhaustivos del volumen:

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:

Devolvió lo siguiente:

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

Agregar lo siguiente:

Dar permisos de ejecución:

Y se corre el script para cada disco:

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:

En gluster2 o gluster3 una vez apagado gluster1:

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

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.

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

¿De cuánta utilidad te ha parecido este contenido?

¡Haz clic en una estrella para puntuar!

Promedio de puntuación 5 / 5. Recuento de votos: 1

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

Sé el primero en comentar

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.


*