An English version of this post is available.

Moby Dock, la baleine mascotte de Docker

Okay, configurer le cluster Gluster avec un node qui pourrait être éteint à n'importe quel moment n'était peut être pas ma meilleure idée. Mais c'était seulement pour m'apprendre à gérer Gluster sur des nœuds physiques.

Mon NAS Synology est mon troisième nœud choisi pour configurer le cluster. Mais il n'est pas basé sur Debian et, du coup, je ne peux pas faire ce que je veux comme d'habitude.

Heureusement, il y a Docker dessus et il peut communiquer avec ma propre registry priveé. Ça ouvre quelques perspectives !

Je vais ajouter ofuro.onsen.lan, IP 192.168.0.77 au cluster et en supprimer buro.onsen.lan, IP 192.168.0.7.

Packager Gluster comme image Docker

Bon, on a besoin de packager une image Docker pour avoir une configuration aussi proche que possible de mes autres nœuds.

  • On part d'une debian:stable-slim.
  • On y installe Gluster.
  • On démarre glusterd.
  • ????
  • Profit!!!

On utilisera le réseau de l'hôte (host). Donc il faut que l'on s'assure que ces ports resterons disponibles en TCP et UDP:

  • 24007 pour le démon Gluster
  • 24008 pour le RDMA (Je ne l'utilise pas, mais vous en aurez peut être besoin.)
  • 49152+ pour la Brick 1 (Chaque brique a son propre port à 49151 + numéro de la brique)

Avec le Dockerfile suivant :

FROM debian:stable-slim

RUN apt-get update && apt-get install --no-install-recommends --yes glusterfs-server

ARG GLUSTERD_LOG_LEVEL
ARG GLUSTERD_LOG_FILE
ARG GLUSTERD_OPTIONS
ENV GLUSTERD_LOG_LEVEL="${GLUSTERD_LOG_LEVEL:-INFO}" GLUSTERD_LOG_FILE="${GLUSTERD_LOG_FILE:--}" GLUSTERD_OPTIONS="${GLUSTERD_OPTIONS:-}"

CMD /usr/sbin/glusterd --log-level $GLUSTERD_LOG_LEVEL --log-file $GLUSTERD_LOG_FILE --no-daemon $GLUSTERD_OPTIONS

On construit l'image et on la pousse dans notre registry privée :

$ docker login registry.onsen.lan:5000
$ docker build --tag registry.onsen.lan:5000/gluster:0.1 .
$ docker push registry.onsen.lan:5000/gluster:0.1

Faire tourner Gluster sur le Synology

Préparer la brique sur le Synology

On devrait avoir un volume logique formaté en btrfs sur l'un de nos groupes de volume. N'importe quel système de fichier supportant les attributs étendus fera l'affaire. Votre expérience peut être différente.

Mon volume logique est volume6. J'y crée le dossier qui va contenir les données de la brique et un autre qui va contenir les métadonnées de notre nœud Gluster:

$ sudo mkdir -p /volume6/docker/glusterfs/onsen-gv0/brick1/
$ sudo mkdir -p /volume6/docker/glusterfs/var/lib/glusterd/

Lancer l'image Gluster

On va :

  • Lancer l'image Docker depuis notre registry privée.
  • L'exécuter en mode détaché.
  • Nommer le containeur gluster-onsen.
  • L'exécuter en mode privilégié car Gluster a besoin de configurer les attributs étendus sur le volume de données pour les données de la brique.
  • Monter le volume de données en lecture/écriture sur le même chemin que les autres nœuds Gluster dans notre conteneur.
  • Monter le dossier de métadonnées en lecture/écriture.
$ docker run -d \
    --name gluster-onsen \
    --privileged=true \
    --net host \
    --mount type=bind,source=/volume6/docker/glusterfs/onsen-gv0,target=/srv/glusterfs/onsen-gv0 \
    --mount type=bind,source=/volume6/docker/glusterfs/var/lib/glusterd,target=/var/lib/glusterd \
    registry.onsen.lan:5000/gluster:0.1

On vérifie que tout tourne comme attendu:

$ sudo docker logs gluster-onsen
[2020-04-26 15:24:46.676612] I [MSGID: 100030] [glusterfsd.c:2715:main] 0-/usr/sbin/glusterd: Started running /usr/sbin/glusterd version 5.5 (args: /usr/sbin/glusterd --log-level INFO --log-file - --no-daemon)
...

$ sudo netstat -tupan|grep gluster
tcp        0      0 0.0.0.0:49152           0.0.0.0:*               LISTEN      21153/glusterfsd
tcp        0      0 0.0.0.0:24007           0.0.0.0:*               LISTEN      20377/glusterd

Woot!

Rejoindre le cluster Gluster

Ajouter le nœud au Trusted Pool

Pour autoriser un nœud dans le cluster Gluster, il doit d'abord être sondé depuis un pair déjà autorisé. Depuis l'un de ces nœuds, on sonde le nouveau pair :

$ sudo gluster peer probe 192.168.0.77
peer probe: success.

Ajouter la brique du nœud au volume du cluster

Ensuite, on va étendre notre volume Gluster avec la brique de ce nœud en utilisant la commande volume add-brick. On indique à Gluster que l'on souhaite aussi répliquer le contenu sur cette brique en incrémentant le nombre de répliques.

$ sudo gluster volume add-brick onsen-gv0 replica 4 192.168.0.77:/srv/glusterfs/onsen-gv0/brick1
volume add-brick: success

Vérifier le status de la replication

En lançant la commande volume heal <volume> info summary, on peut vérifier le status de la réplication. Ici, on a une situation normale, tout est OK :

$ sudo gluster volume heal onsen-gv0 info summary
Brick 192.168.0.2:/srv/glusterfs/onsen-gv0/brick1
Status: Connected
Total Number of entries: 0
Number of entries in heal pending: 0
Number of entries in split-brain: 0
Number of entries possibly healing: 0

Brick 192.168.0.1:/srv/glusterfs/onsen-gv0/brick1
Status: Connected
Total Number of entries: 0
Number of entries in heal pending: 0
Number of entries in split-brain: 0
Number of entries possibly healing: 0

Brick 192.168.0.7:/srv/glusterfs/onsen-gv0/brick1
Status: Connected
Total Number of entries: 0
Number of entries in heal pending: 0
Number of entries in split-brain: 0
Number of entries possibly healing: 0

Brick 192.168.0.77:/srv/glusterfs/onsen-gv0/brick1
Status: Connected
Total Number of entries: 0
Number of entries in heal pending: 0
Number of entries in split-brain: 0
Number of entries possibly healing: 0

Et voici un exemple de status de réplication en cours pour illustrer. J'ai écrit dans le volume Gluster avec un client et j'ai redémarré le Synology en même temps. Pendant qu'il était indisponible, les autres nœuds ont détecté des réplicats manquant pour certains fichiers :

$ sudo gluster volume heal onsen-gv0 info summary
Brick 192.168.0.2:/srv/glusterfs/onsen-gv0/brick1
Status: Connected
Total Number of entries: 7
Number of entries in heal pending: 7
Number of entries in split-brain: 0
Number of entries possibly healing: 0

Brick 192.168.0.1:/srv/glusterfs/onsen-gv0/brick1
Status: Connected
Total Number of entries: 7
Number of entries in heal pending: 7
Number of entries in split-brain: 0
Number of entries possibly healing: 0

Brick 192.168.0.7:/srv/glusterfs/onsen-gv0/brick1
Status: Connected
Total Number of entries: 7
Number of entries in heal pending: 7
Number of entries in split-brain: 0
Number of entries possibly healing: 0

Brick 192.168.0.77:/srv/glusterfs/onsen-gv0/brick1
Status: Transport endpoint is not connected
Total Number of entries: -
Number of entries in heal pending: -
Number of entries in split-brain: -
Number of entries possibly healing: -
  • Transport endpoint is not connected: La brique du nœud n'est pas connectée au volume.
  • Heal pending : Ce nœud a détecté que certains de ses fichiers ne correspondait pas au nombre de réplicats.

Une fois le Synology redémarré et le conteneur Docker à nouveau disponible, le status est revenu à la normale.

Super, on a un pair Gluster tournant dans Docker sur un Synology !

Supprimer la brique de l'autre nœud du volume du cluster

On supprime la brique de buro.onsen.lan's avec la commande volume remove-brick. On a besoin d'indiquer à Gluster que l'on veut revenir à une configuration de 3 réplicats plutôt que 4.

Une fois la brique enlevée, on supprime le pair du trusted pool. C'est fini.

$ sudo gluster volume remove-brick onsen-gv0 replica 3 192.168.0.7:/srv/glusterfs/onsen-gv0/brick1 force
Remove-brick force will not migrate files from the removed bricks, so they will no longer be available on the volume.
Do you want to continue? (y/n) y
volume remove-brick commit force: success

$ sudo gluster peer detach 192.168.0.7
peer detach: success