Stockage Répliqué on Zwindler's Reflection

Stockage distribué et répliqué avec DRBD

Mon, 11 May 2020 06:35:00 +0000

DRBD

En 2015, j’avais voulu essayer la solution de stockage distribué DRBD. Et oui, 2015. C’est mon plus vieux brouillon sur le blog que je sors enfin. Vous vous en doutez, j’ai du repasser dessus pour ne pas vous donner de versions antédiluvienne ;-)

DRBD (pour Distributed Replicated Block Device) est donc un logiciel disponible sous Linux et Windows qui permet de gérer des périphériques de stockages virtuels utilisables dans des infrastructures.

Ces périphériques ont la particularité de pouvoir être « distribués » sur plusieurs serveurs sur un réseau de façon synchrone ou asynchrone et disposant de plusieurs méthodes de resynchronisation en cas de perte de lien ou d’incohérences.

L’avantage de cette solution est qu’elle est robuste (fiabilité éprouvée) et qu’elle permet de répondre à des problématiques de haute disponibilité et de performance que n’offrent pas forcément toutes les solutions de stockage.

Si cette solution peut paraître de prime abord un peu datée à l’époque des containers et de Kubernetes, sachez que Linbit a fait un effort assez conséquent justement sur cette partie, en essayant de se positionner comme un des acteurs du stockage distribué pour les architectures containerisées et/ou “cloud native” (surtout trusté par Ceph/CephFS, voire Gluster).

Prérequis

Pour tester DRBD, vous l’aurez compris, il va nous falloir au minimum deux serveurs. Pour faire simple, je vais utiliser des machines virtuelles (mais évidemment ça fonctionnera mieux sur un serveur physique) sur lesquelles j’ai installé une image Ubuntu 18.04.

Dans mon cas, j’ai rajouté des disques virtuels de 16Go, pour simuler des disques physiques à synchroniser. De même, j’ai également rajouté des interfaces réseaux supplémentaires pour simuler un réseau dédié « stockage ».

Installation du logiciel

La société LINBIT qui distribue le logiciel DRBD propose des packages précompilés pour la plupart des distributions Linux classiques. L’ensemble des packages des différentes versions de DRBD sont disponibles sur le site de Linbit. Cependant, ces packages « officiels » précompilés nécessitent d’avoir payé le support.

Note : Si les packages officiels sont réservés aux personnes qui payent le support, les sources, elles, sont bien entendu disponibles sur le site.

Heureusement, il est possible d’utiliser tout simplement les packages précompilés de votre distribution.

A la base, quand j’avais écrit le tutoriel en 2015, j’avais des soucis de compatibilité entre la version du kernel et drbd de ma distribution CentOS (6.3 à l’époque…). Ma version, 2.6.32-279 alors que les versions 8.3 et 8.4 de DRBD nécessitent le kernel 2.6.32-431. Mais rien ne vous empêche d’installer le kernel demandé pour résoudre ce problème.

Pour ce tuto, voici les commandes que j’ai dû utiliser pour installer DRBD 9 (la dernière stable même si la 10 arrive bientôt) sur mes Ubuntu 18.04.

sudo apt update
sudo apt upgrade
sudo apt install software-properties-common
sudo add-apt-repository ppa:linbit/linbit-drbd9-stack
sudo apt-get update
sudo apt install drbd-utils python-drbdmanage drbd-dkms

Une fois que c’est installé, testez que tout fonctionne avec la commande suivante :

sudo modprobe drbd

Si tout se passe bien, elle ne devrait remonter aucune erreur. En revanche, si vous n’avez pas un kernel avec une version compatible, vous devriez avoir une erreur du type “file not found”. Dans ce cas-là, il faudra compiler DRBD à la main.

Préparation des machines

Les serveurs doivent évidemment pouvoir se joindre et se résoudre. Le mieux étant bien sûr un DNS correct, on pourra se rabattre dans le cadre d’un test sur a minima un fichier /etc/hosts contenant les informations nécessaires :

192.168.100.11 drbd1 drbd1.example.org
192.168.100.12 drbd2 drbd2.example.org

Ensuite, j’ai créé, sur chaque serveur, deux partitions de 8 Go chacun sur le disque de 16. La première sera de type Linux, la seconde sera de type LVM.

On oublie pas de créer les objets LVM pour pouvoir les utiliser plus tard.

pvcreate /dev/sdb2
vgcreate vg_drbd /dev/sdb2
lvcreate -n lv_drbd -l 2047 vg_drbd

Configuration

Le fichier de configuration global de DRBD est /etc/drbd.conf. Il définit les fichiers unitaires qui doivent être modifiés. Le fichier /etc/drbd.conf en lui-même ne doit donc pas être modifié directement ; sauf dans le cas où on souhaite changer les fichiers de configuration inclus de répertoire.

cat /etc/drbd.conf
# You can find an example in /usr/share/doc/drbd.../drbd.conf.example
include "drbd.d/global_common.conf";
include "drbd.d/*.res";

Le fichier suivant doit contenir les paramètres et les commandes qui sont globaux à toutes les ressources DRBD.

cat /etc/drbd.d/global_common.conf
# DRBD is the result of over a decade of development by LINBIT.
# In case you need professional services for DRBD or have
# feature requests visit http://www.linbit.com
global {
[...]

Template de ressource

Pour rendre la configuration lisible, on sépare les fichiers de configuration de manière à faire un fichier texte par ressource, nommé avec la convention r[nombre].res. Ici on prendra l’exemple le plus simple d’une synchronisation synchrone (protocole C, par défaut) dans un modèle actif/passif. Pour vous aider à créer vos premières ressources, DRBD met à disposition, dans /etc/drbd.d/drbdctrl.res_template un template dans lequel vous n’aurez qu’à modifier les valeurs.

resource .drbdctrl {
net {
cram-hmac-alg sha1;
shared-secret "<your-shared-secret>";
}
volume 0 {
device /dev/drbd0 minor 0;
disk /dev/mapper/<vgname>-.drbdctrl;
meta-disk internal;
}
on <node_1> {
node-id 0;
address <ipaddress>:<port>;
}
on <node_n> {
node-id <n>;
address <ipaddress>:<port>;
}
connection-mesh {
hosts <node_1> <node_2> ... <node_n>;
net {
protocol C;
}
}
}

Ressource pour un disque “simple”

Ici, c’est l’exemple le plus simple. On va indiquer que notre ressource est distribuée sur 2 serveurs sur un bête partition Linux. Les metadata, elles, sont stockées en local (ce qui n’est pas forcément le mieux, mais pour commencer ça suffira).

vi /etc/drbd.d/r0.res
resource r0 {
on drbd1 {
device /dev/drbd1;
disk /dev/sdb1;
address 192.168.100.11:7789;
meta-disk internal;
}
on drbd2 {
device /dev/drbd1;
disk /dev/sdb1;
address 192.168.100.12:7789;
meta-disk internal;
}
}

Note : si le protocole de synchronisation n’est pas spécifié, on est en synchronisation synchrone par défaut.

Attention : chaque ressource déclarée réserve le port TCP pour la communication de la ressource. Il faut donc incrémenter le numéro du device drbd ET incrémenter le numéro de port à chaque nouvelle ressource (et aussi s’assurer que le port est libre…).

Pour mes tests, j’ai également utilisé la possibilité offerte par DRBD d’utiliser des volumes LVM plutôt que des partitions brutes. La configuration est la même à ceci près qu’on pointe sur le LV plutôt que sur une partition.

vi /etc/drbd.d/r1.res
resource r1 {
on drbd1 {
device /dev/drbd2;
disk /dev/vg_drbd/lv_drbd;
address 192.168.100.11:7790;
meta-disk internal;
}
on drbd2 {
device /dev/drbd2;
disk /dev/vg_drbd/lv_drbd;
address 192.168.100.12:7790;
meta-disk internal;
}
}

Initialisation

Maintenant que tout est configuré, on va pouvoir déclencher l’étape d’initialisation des metadata et des ressources nouvellement créées. Lancez les commandes suivantes sur les deux nœuds :

drbdadm create-md r0
drbdadm create-md r1
drbdadm up r0
drbdadm up r1

Une fois que les commandes sont lancées, on peut afficher les informations sur l’initialisation des disques (état normal) avec drbdmon.

Actuellement, les nœuds sont Inconsistants et en Secondaire/Secondaire, car nous n’avons pas encore désigné le nœud principal. Nous allons “forcer” le sens dans lequel le disque doit être synchronisé.

Sélectionner un des nœuds, qu’on va désigner comme “serveur primaire” et exécuter les commandes suivantes (uniquement sur lui) :

root@drbd1:~# drbdadm primary --force r0
root@drbd2:~# drbdadm primary --force r1

ATTENTION : dans le cas d’un disque déjà créé, il faut bien ne pas se tromper de sens, au risque d’écraser le disque qui contiendrait les données.

Une fois la synchronisation terminée, on peut utiliser le disque /dev/drbdX.

C’est fini ?

En fait, pas tout à fait. On ne va pas pouvoir utiliser nos disques exactement comme des disques classiques. Si vous formattez ce disque en ext4/xfs/whatever et que vous essayez de le monter sur vos deux serveurs drbd1 et drbd2, vous allez avoir une drôle de surprise.

En effet, ces filesystems ne savent pas gérer les accès concurrents provenant de deux machines simultanées. On va donc devoir :

soit utiliser un filesystem capable de gérer les accès concurrents (page Wikipedia listant quelques clustered filesystems) comme OCFS2 ou GFS2. Si vous publiez les disques DRBD en iSCSI pour votre cluster VMware, vous n’aurez pas de problème non plus car le VMFS le gère très bien aussi.
soit s’assurer à tout moment que le disque n’est monté que sur un seul serveur à la fois.

Évidemment la 2ème option est à proscrire si vous êtes dans un contexte de production. Cependant, cela reste possible si vous montez un cluster Pacemaker ou RHCS par exemple, qui va s’assurer que les bascules de stockage se font de manière propre.

Enjoy !

Bonus : quelques commandes utiles

Pour une ressource donnée, afficher le rôle du serveur local

root@drbd1:~# drbdadm role r0
Primary
root@drbd1:~# drbdadm role r1
Secondary

Afficher de manière concise l’état d’une ressource sur les nœuds

root@drbd1:~# drbdadm dstate r0
UpToDate/UpToDate
root@drbd1:~# drbdadm dstate r1
Inconsistent/UpToDate

Afficher plus de détails sur une ressource avec drbdadmin pour un résultat simple ou drbdsetup pour avoir plus de détails :

drbdsetup status r1 --verbose --statistics
r1 node-id:1 role:Secondary suspended:no
write-ordering:flush
volume:0 minor:2 disk:Inconsistent quorum:yes
size:8384220 read:0 written:1972628 al-writes:0 bm-writes:0 upper-pending:0 lower-pending:0 al-suspended:no blocked:no
drbd2 node-id:0 connection:Connected role:Primary congested:no ap-in-flight:0 rs-in-flight:0
volume:0 replication:SyncTarget peer-disk:UpToDate done:23.53 resync-suspended:no
received:1972628 sent:0 out-of-sync:6411740 pending:3 unacked:12 dbdt1:92.39 eta:68

En temps normal, toutes les ressources sont actives par défaut. Cependant, on peut les activer ou les désactiver à la main :

drbdadm up r0
drbdadm down r1
# utiliser le mot clé « all » pour désigner toutes les ressources

Si on modifie les fichiers de configuration global ou un fichier de ressource, il est nécessaire de mettre à jour la configuration sur les deux nœuds. Il est possible de reconfigurer les ressources même si elles sont opérationnelles grâce à la méthode suivante :

drdbadm adjust r0

Changer le statut du nœud courant (pour le passer en primary s’il est secondary par exemple)

drbdadm primary r1
drbdadm secondary r0

Sources

User Guide DRBD 9.0 (Anglais)

[Tutoriel] Créer un cluster de stockage GlusterFS sous Proxmox

Tue, 28 Feb 2017 13:00:59 +0000

Installation de GlusterFS sur 2 serveurs Proxmox

Dans ce tutoriel je vais vous guider pas à pas pour ajouter la fonctionnalité de stockage distribué sur deux serveurs Proxmox. Ce tutoriel est également valable pour tout serveur sous Debian (Proxmox est une distribution Debian modifiée) ou même n’importe quelle autre distribution Linux modulo quelques ajustements.

Mais comment en suis-je arrivé là ?

Et bien récemment, j’ai commandé un serveur Kimsufi dans le but de pouvoir tester 2 ou 3 nouvelles technos sans encombrer un peu plus le dressing.

Un aperçu de mon dressing

Me retrouvant donc avec 2 serveurs Kimsufi, j’ai voulu voir si je ne pouvais pas clusteriser tout ça. Pour la partie cluster de virtualisation, malheureusement ce n’est pas possible si les deux serveurs sont dans des réseaux distincts, pour des problèmes de multicast.

Une solution aurait pu être de monter un VPN entre les deux mais j’ai préféré ne pas insister et voir si je ne pouvais pas me concentrer sur un autre point : créer un cluster de stockage !

Dans les dernières versions, Proxmox VE propose directement dans la console une visualisation des volumes Ceph ainsi qu’un tutoriel pour configurer la partie serveur directement sur les hôtes de virtualisation. Sur le papier, c’était donc le mécanisme de réplication de stockage à privilégier. Cependant, dans mon cas d’un « lab » avec seulement 2 serveurs sur un WAN, ce n’était pas l’idéal :

Before you start with Ceph, you need a working Proxmox VE cluster with 3 nodes (or more).

Je me suis donc rabattu sur GlusterFS, qui a l’avantage d’être un peu plus simple de mise en place côté serveur même s’il n’est pas aussi bien intégré côté Proxmox.

Le principe

Déjà on peut commencer par la définition Wikipedia

GlusterFS est un système de fichiers libre distribué en parallèle, qui permet de stocker jusqu’à plusieurs pétaoctets (10^15 octets). C’est un système de fichiers de clusters. Livré en deux parties - un serveur et un client

En gros, Gluster Server se charge de faire communiquer entre eux les hôtes et on défini des « bricks » (espace de stockage sur un serveur donné) qu’on assemble entre elles pour donner un volume (espace de stockage répliqué ou non). Et Gluster Client vous permet d’accéder à un espace de fichiers qui va écrire simultanément sur l’ensemble des bricks du volume de manière transparente.

Assez de théorie, maintenant, la pratique !

Prérequis

Sur les 2 serveurs Proxmox, j’ai créé en préventif un Fflesystem de 5G dédié à la configuration de Gluster. Pourquoi ? Car il y a un gros risque de plantage en cas de remplissage :

Note: GlusterFS stores its dynamically generated configuration files at /var/lib/glusterd. If at any point in time GlusterFS is unable to write to these files (for example, when the backing filesystem is full), it will at minimum cause erratic behavior for your system; or worse, take your system offline completely. It is advisable to create separate partitions for directories such as /var/log to ensure this does not happen.

lvcreate -L 5G -n var_lib_glusterd pve
Logical volume "var_lib_glusterd" created.
mkfs.ext4 /dev/pve/var_lib_glusterd
mkdir -p /var/lib/glusterd
echo '/dev/pve/var_lib_glusterd /var/lib/glusterd ext4 defaults 1 2' >> /etc/fstab
mount -a

On récupère ensuite les sources sont disponibles sur le site gluster.org. Selon les distributions, la marche à suivre peut être différentes, notamment pour Ubuntu qui utilise un PPA.

wget -O - http://download.gluster.org/pub/gluster/glusterfs/3.9/rsa.pub | apt-key add -
echo deb http://download.gluster.org/pub/gluster/glusterfs/3.9/LATEST/Debian/jessie/apt jessie main > /etc/apt/sources.list.d/gluster.list
apt-get update
apt-get install glusterfs-server

Maintenant que le serveur est opérationnel, on créé nos bricks de 100Go sur un LV sur chaque serveur et on le monte.

lvcreate -L 100G -n data_brick1 pve
mkfs.xfs /dev/pve/data_brick1
mkdir -p /data/brick1
echo '/dev/pve/data_brick1 /data/brick1 xfs defaults 1 2' >> /etc/fstab
mount -a && mount

Vérification du service sous Proxmox (Debian)

service glusterfs-server status
* glusterfs-server.service - LSB: GlusterFS server
Loaded: loaded (/etc/init.d/glusterfs-server)
Active: active (running) since Wed 2017-02-08 23:21:00 CET; 3 days ago
CGroup: /system.slice/glusterfs-server.service
└─29562 /usr/sbin/glusterd -p /var/run/glusterd.pid
Feb 08 23:21:00 srv2 glusterfs-server[29557]: Starting glusterd service: glusterd.
Feb 08 23:21:00 srv2 systemd[1]: Started LSB: GlusterFS server.

Comme les nœuds ont besoin d’échanger des informations entre eux, il va falloir ouvrir quelques ports, à savoir :

111/UDP et TCP
24007/TCP
24008/TCP
PUIS, un port par brique en partant du port 49152/TCP

Sous iptables ça devrait donner quelque chose comme cela

iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 24007:24008 -j ACCEPT
iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 49152 -j ACCEPT
iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 111 -j ACCEPT
iptables -I INPUT -m state --state NEW -m udp -p udp --dport 111 -j ACCEPT
service iptables save
service iptables restart

ATTENTION : J’ai lu sur plusieurs sites qu’il faut ouvrir des ports à partir de 24009 pour les bricks. Ce n’est plus vrai depuis la version 3.4 !

Si vous êtes dans ces versions plutôt ancienne, c’est effectivement le port 24009 et + qu’il faut ouvrir mais ce n’est maintenant plus le cas ! Vous aurez des problèmes difficiles à débuguer car vos noeuds serveurs dialoguerons mais les bricks d’un même volumes répliqué ne se synchroniseront pas.

J’ai également lu qu’il était conseillé de s’assurer que la résolution soit toujours opérationnelle et donc de renseigner le fichier hosts mais ça, c’est à vous de voir.

vi /etc/hosts

On connecte maintenant les deux serveurs entre eux en exécutant cette commande que sur un des deux serveurs.

gluster peer probe srv2
peer probe: success.

A partir de là, le cluster est actif. On peut le vérifier avec les 2 commandes suivantes :

gluster peer status
Number of Peers: 1
Hostname: srv2
Uuid: aaaa-7d57-41c1-aaaa-c51f7e1c076a
State: Peer in Cluster (Connected)
gluster pool list
UUID Hostname State
aaaa-7d57-41c1-aaaa-c51f7e1c076a srv2 Connected
aaaa-6a78-44ce-aaaa-2feb3cfb3627 localhost Connected

Sur les deux nœuds du cluster srv1 et srv2 :

mkdir -p /data/brick1/gv0

Depuis un des deux serveurs, on créé notre premier volume à partir des deux bricks de nos deux serveurs.

gluster volume create gv0 replica 2 srv1:/data/brick1/gv0 srv2:/data/brick1/gv0
volume create: gv0: success: please start the volume to access data
gluster volume start gv0
volume start: gv0: success

On vérifie que le volume est marqué « Started » :

gluster volume info
Volume Name: gv0
Type: Replicate
Volume ID: a3ffa060-ac5b-4b36-8b6c-8e77bad98cca
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: srv1:/data/brick1/gv0
Brick2: srv2:/data/brick1/gv0
Options Reconfigured:
transport.address-family: inet
performance.readdir-ahead: on
nfs.disable: on

A partir de là, notre volume est opérationnel est on peut commencer à le monter pour inscrire des données dedans !

Afficher des infos sur le volume

Afficher des infos très précises sur les performances du volume à l’aide des commandes suivantes :

root@srv2:~# gluster volume profile gv0 start
Starting volume profile on gv0 has been successful
root@srv2:~# gluster volume profile gv0 info
Brick: srv2:/data/brick1/gv0
---------------------------------------------
Cumulative Stats:
Block Size: 512b+ 65536b+ 131072b+
No. of Reads: 4 5 22
No. of Writes: 78 219 44
Block Size: 262144b+ 524288b+ 1048576b+
No. of Reads: 0 0 0
No. of Writes: 35 47 919
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 5 RELEASE
0.00 0.00 us 0.00 us 0.00 us 442 RELEASEDIR
0.03 22.00 us 22.00 us 22.00 us 1 STATFS
0.04 32.00 us 32.00 us 32.00 us 1 GETXATTR
0.29 110.50 us 55.00 us 166.00 us 2 LOOKUP
99.64 38491.00 us 32866.00 us 44116.00 us 2 WRITE
Duration: 87590 seconds
Data Read: 3213312 bytes
Data Written: 1033611264 bytes
[...]
Brick: srv1:/data/brick1/gv0
--------------------------------------------
Cumulative Stats:
Block Size: 512b+ 65536b+ 131072b+
No. of Reads: 0 0 0
No. of Writes: 78 218 44
Block Size: 262144b+ 524288b+ 1048576b+
No. of Reads: 0 0 0
No. of Writes: 34 45 906
%-latency Avg-latency Min-Latency Max-Latency No. of calls Fop
--------- ----------- ----------- ----------- ------------ ----
0.00 0.00 us 0.00 us 0.00 us 5 RELEASE
0.00 0.00 us 0.00 us 0.00 us 1 RELEASEDIR
0.26 75.00 us 75.00 us 75.00 us 1 STATFS
0.35 103.00 us 103.00 us 103.00 us 1 GETXATTR
1.38 200.50 us 189.00 us 212.00 us 2 LOOKUP
98.01 14246.50 us 4943.00 us 23550.00 us 2 WRITE
Duration: 87589 seconds
Data Read: 0 bytes
Data Written: 1018144768 bytes

Je vous rassure, ici, si les performances sont catastrophiques, c’est parce que le test a été réalisé en WAN sur ma lien ADSL pour particulier.

Configuration dans proxmox (partie cliente)

Maintenant que la partie serveur est configurée, on doit accéder au volume répliqué via le client. En effet, c’est seulement par ce biais que l’on pourra écrire en Y sur notre volume. Écrire directement dans le dossier d’un brick n’aura pas l’effet escompté.

Depuis la console Proxmox, dans le menu « Stockage », cliquer sur « Ajouter / GlusterFS »

Dans la capture suivante, vous pouvez admirer ma connexion ADSL saturée en upload par la copie d’un fichier d’une machine virtuelle depuis mon serveur dans mon dressing vers mon kimsufi. Et après vérification, on a bien le fichier de machine virtuelle des deux côtés :-).

Sources

www.0rion.netlib.re/forum4/viewtopic.php?t=298 (lien mort, j’utilise Internet Archive)
www.guillaume-leduc.fr/le-stockage-distribue-avec-glusterfs.html (lien mort, site fermé par son auteur en 2018, pas dispo sur Internet Archive)
pve.proxmox.com/wiki/Storage:_GlusterFS
docs.gluster.org/en/latest/Administrator-Guide/Monitoring-Workload/