DRBD 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)

[IRL] RedHat virtualisé et haute dispo, RHCS+VMDK partagés vs vSphere Replication

Wed, 11 Feb 2015 14:58:49 +0000

Contexte

Dans un contexte professionnel, il arrive que des décisions soient prises et qu’il faille s’y tenir coute que coute. Même si on se rend compte plus tard que ce n’était pas forcément le chemin le plus facile. La facilité, c’est le côté obscur, on le sait bien ;-).

Pour un client, on m’a donc demandé de concevoir une plateforme RedHat 5.X virtualisée hautement disponible, avec une durée d’interruption de service maximale de 30 minutes en toute circonstance (jusque là tout va bien), ET la possibilité de restaurer les disques des OS virtuels avec plusieurs points de restaurations par palliers de 30 minutes (RPO/RTO). Aie!

Tel le Mac Giver des temps modernes, je dispose des outils suivants pour y parvenir :

1 licence vSphere Essential Plus
2 serveurs physiques, installés en ESXi 5.5 et reliés en SAN
2 baies de disques EMC² VNX5200
2 souscriptions RedHat Datacenter - pour disposer d’autant de VMs RHEL qu’on le souhaite sur nos deux nœuds physiques
2 souscriptions RedHat High Availability (anciennement RedHat Cluster Suite) en mode Datacenter - pour disposer d’autant de clusters RedHat qu’on le souhaite sur nos deux nœuds physiques

Clusters RHCS et VMDK partagés ou RDM

Comme vous pouvez le deviner avec la dernière ligne, on m’a demandé d’utiliser les licences qui avaient été achetées. Donc de déployer du cluster RHCS à tour de bras, pour faire des paires de VMs et simuler ce que l’on fait habituellement sur des paires de machines physiques.

Sauf qu’à tenter de faire des clusters RHCS sur des machines virtuelles VMware, on trouve vite toute sortes de petits désagréments.

Note : Je vous demanderai de bien vouloir faire abstraction du fait que c’est vraiment « bourrin » de doubler des VMs lorsqu’on dispose d’un cluster vSphere. En fait, si j’en suis arrivé là, c’est parce qu’un simple cluster VMware HA ne répond pas à l’ensemble des besoins énoncés plus haut. C’est possible, bien sûr, mais il faut aller creuser peu plus loin (cf la fin de l’article).

Prérequis

VMware et RedHat supportent l’utilisation de cluster RHCS dans sur des machines virtuelles avec les obligations suivantes :

Support de vSphere 5.1 uniquement à partir de RHEL 5u9 ou 6u4
Support de vSphere 5.5 uniquement à partir de RHEL 5u11, 6u6 ou 7
Support du partage de disques via RDM à partir RHEL 5u7
Support du partage de VMDK à partir de RHEL 5u9

(Voir ici pour plus d’infos)

Idéalement, il faut donc disposer de machines virtuelles RHEL 5u11 et de vSphere en version 5.5 (version la plus à jour si on met de côté la 6 qui va sortir), mais on peut se « contenter » d’une version RHEL 5u9 en installant une version plus ancienne de vSphere (5.1).

Le cas le plus défavorable est l’utilisation de vSphere 5.0 avec un RHEL 5u7 ou 5u8. Dans ce cas, seul le partage de disques via RDM est possible et un bug connu dans la version 5.0 de vSphere empêche le fonctionnement opérationnel du cluster (au niveau du fencing).

Au-delà, ce n’est pas supporté.

Architecture

Cas de panneS

Les disques OS sont installés en RAID 1 MDADM avec 2 VMDKs situés sur les deux baies.

Si ce n’est pas le cas, en cas de la perte de la baie de disques hébergeant l’OS du nœud maitre, le serveur deviendra instable mais ne pourra pas se saborder d’elle-même correctement, plantant le cluster et l’application.

Pire, s’il s’agit de la baie de disques qui héberge le quorum disk, le cluster ne disposera plus d’assez de votes pour fonctionner et le redémarrage devra être forcé à la main.

En cas de corruption du disque OS du nœud actif, les packages basculeront sur l’autre VM.

En cas de panne de l’ESXi, les packages actifs pourront basculer sur le nœud présent sur l’autre serveur.

En cas de perte de la baie de disques, les données seront toujours accessibles par les deux VMs grâce à l’autre membre du miroir.

Même si la baie hébergeant le quorum tombe en panne, on disposera toujours de deux votes (les deux nœuds du cluster).

Limitations et problématiques de la solution

VMware et Contrôleur Physique

Pour partager des disques durs virtuels (RDM ou VMDK), il faut ajouter à la machine virtuelle un « contrôleur de disques SCSI » en « compatibilité physique ». Ceci a pour conséquence de limiter les fonctionnalités disponibles dans VMware :

Pas de live vMotion (bascule de VM à chaud)
Pas de snapshots
Pas de sauvegarde via l’API VMware (sauvegarde des VMs via l’ESXi « clientless » et sauvegarde granulaire)

RHCS et nombre de votes

La salle primaire héberge le quorum disk qui permet de favoriser la salle primaire en cas de « split brain » (voir mon article sur le démarrage forcé sous RHCS). Ce mécanisme de sécurité permet d’empêcher d’avoir 2 salles autonomes en même temps ce qui aura pour conséquence de corrompre les données du SI.

Le cas défavorable de la perte de la salle primaire complète induit un problème important qui ne peut pas être adressé simplement. Dans ce cas de figure, il n’y a plus assez de votes pour que le cluster fonctionne, et l’application s’éteint.

Il est donc nécessaire de redémarrer manuellement les clusters. Dans l’absolu, ce n’est qu’une commande à passer, mais dans mon cas, j’ai un nombre important de clusters à gérer. La personne d’astreinte ne pourra jamais tenir les SLA de 30 minutes d’indisponibilité.

Il me parait impossible d’automatiser proprement cette relance du cluster, car c’est un mécanisme trop sensible et les risques de corruption de données sont trop important.

LVM vs MDADM

Dans la structure pour laquelle je travaille, l’utilisation du mirroring LVM est un choix technique historique héritée de nos clusters MCSG sous HP-UX.

Sous RHEL 5.X, la gestion des miroirs LVM est complexe et peu adaptée :

l’agrandissement des volumes nécessite une suppression du miroir, rendant les données temporairement non redondée et réduisant les performances.
la perte de l’interconnexion - même temporaire - a des effets de bords qui nécessitent également de tout reconstruire et de tout resynchroniser entièrement (membres de miroirs perdus mais pas tous remontés comme tels).

A l’inverse, l’agrandissement d’un disque via MDADM peut se faire à chaud (on agrandi un VMDK, puis l’autre), et la perte temporaire d’un membre ne nécessite pas de le reconstruire complètement.

Une dernière option - idéale techniquement - est l’utilisation de la réplication de « blocs devices » par DRBD (société LinBIT). Elle a été rejetée pour cause d’absence de support de la part de RedHat mais permet de faire exactement ce que l’on souhaite : répliquer des disques au niveau bloc entre deux VMs.

Réplication des VMDK via vSphere Replication

Et voilà la solution que j’aurai aimé étudier. La facilité. Le côté obscur donc.

Prérequis

Pour utiliser la fonctionnalité vSphere Réplication, il faut disposer d’une licence vSphere Essential Plus (ou mieux), d’un vCenter et de deux datastores distincts.

Architecture

Réplication du disque OS de la VM

Avec la licence vSphere Essential Plus, il est possible de réaliser un « pseudo PRA » à l’aide de la fonctionnalité vSphere Replication.

La machine virtuelle n’est pas doublée comme dans l’architecture précédente. Ici VMware réplique son VMDK en fil de l’eau vers un Datastore secondaire.

En cas de panne quelconque sur la salle primaire, on bascule la VM sur le serveur ESXi secondaire et on la redémarre sur le disque répliqué (opération manuelle).

En cas de corruption des filesystems sur le disque OS, on dispose de plusieurs points de restauration dans le temps nous permettant de revenir à un état précédent fonctionnel.

Limitations et problématiques de la solution

Malheureusement je n’ai pas eu l’occasion de le tester, la solution choisie n’étant pas cette solution. Cependant, au vu des besoins énoncés et des ressources à ma disposition, cette solution me parait être celle qui répond à tous les besoins et toutes les problématiques.

Partage de VMDK entre plusieurs VMs

Wed, 07 Jan 2015 16:05:17 +0000

Si vous déjà voulu faire un POC de cluster Linux sur des machines virtuelles VMware, vous vous êtes déjà demandé comment vous alliez faire pour partager entre deux serveurs un espace de stockage commun à ces deux machines.

Une façon de faire consiste à rajouter une couche d’abstraction du stockage au dessus de l’OS (via GlusterFS ou DRBD par exemple), mais dans le cas d’un POC pour valider un cluster connecté au SAN, ce n’est pas forcément la première solution qui vient à l’esprit. Personnellement, la plupart des clusters que je construis sont encore dans un schéma plus simple à base de LUNs iSCSI ou FC partagés sur un SAN en actif/actif ou actif/passif.

Cependant, pour simuler ce fonctionnement sur vos VMs, il va falloir bidouiller un peu.

En effet, pour éviter toute erreur malencontreuse (et même désastreuse), VMware interdit par défaut le démarrage de toute machine virtuelle qui aurait un disque en cours d’utilisation par une autre machine virtuelle. Aïe…

Voici un petit mode opératoire pour s’en sortir ;-)

Dans ce mode opératoire, les disques qu’on souhaite partager entre les deux serveurs sont des disques LVM en miroir, hébergés sur les baies de disques qui sont accessibles depuis les deux serveurs ESXi.

Cet exemple permet de valider la fiabilité de la méthode dans le cadre d’un cluster Linux virtuel de type RedHat Cluster Suite. Le principe reste tout de même valide pour une utilisation en dehors de RedHat Cluster Suite, certaines opérations ne seront juste pas nécessaires (qui peut le plus peut le moins).

Prérequis

Pour les besoins de la documentation, deux machines virtuelles test_partage_vmdk_1 et test_partage_vmdk_2 ont été créés. Elles disposent des caractéristiques techniques suivantes :

test_partage_vmdk_1
- hébergée sur ESXi1
- RedHat Entreprise Linux 5.8
- 2 vCPU, 1 Go de RAM
- 50 Go de disque interne sur un espace partagé
- IP 192.168.111.1/24 sur un réseau virtuel
test_partage_vmdk_2
- hébergée sur ESXi2
- RedHat Entreprise Linux 5.8
- 2 vCPU, 1 Go de RAM
- 50 Go de disque interne sur un espace partagé
- IP 192.168.111.2/24 sur un réseau virtuel

Création des disques virtuels

Les machines test_partage_vmdk_1 et test_partage_vmdk_2 doivent être éteintes avant de réaliser les modifications.

Ouvrir les paramètres de la machine virtuelle test_partage_vmdk_1, et ajouter un nouveau périphérique (Disque dur).

Le provisionnement du disque doit impérativement être « statique immédiatement mis à zéro ». De plus, il doit aussi être hébergé sur un datastore commun aux deux machines physiques ESXi.

Créer le disque et l’affecter à un Nœud périphérique virtuel qui n’est pas encore utilisé.

Ici, le disque interne est stocké sur l’adresse SCSI (0:0). Par défaut VMware propose de créer le disque à la suite en SCSI (**0:**1).

Il faut impérativement dérouler la liste pour affecter le disque à l’adresse SCSI (**1:**0) qui représente un nouveau contrôleur SCSI.

De plus, pour permettre l’usage des snapshots sur la partie disque dur interne, les disques doivent être créés en Mode Indépendant/Persistant. Dans le cas contraire, les snapshots seront impossibles sur la machine virtuelle.

Une fois le disque créé, un nouveau contrôleur SCSI est également créé. Avant de valider la création du disque et du contrôleur SCSI, il faut modifier le paramètre de Partage de bus de SCSI en mode « Physique ».

[4]Le second disque dur devra être créé de la même manière, et affecté au même contrôleur SCSI (on prendra l’adresse 1:1).

Remettre test_partage_vmdk_1 sous tension.

Ajout des disques virtuels sur la deuxième machine virtuelle

Ouvrir les paramètres de la machine virtuelle test_partage_vmdk_2, ajouter un nouveau périphérique (Disque dur) puis sélectionner « Utiliser un disque virtuel déjà configuré ».

Sélectionner le premier disque créé précédemment.

De la même manière que précédemment, on doit créer un disque dur virtuel sur un nouveau contrôleur SCSI et en mode Indépendant-Persistant.

Modifier le nouveau contrôleur SCSI comme précédemment :

Ajouter enfin le second disque de la même manière à l’adresse SCSI (1:1).

Valider et mettre la machine virtuelle sous tension. Si elle boot correctement c’est que le partage fonctionne.

Créer le miroir LVM partagé

Sur les deux serveurs, exécuter les commandes suivantes :

chkconfig acpid off #seulement pour RHCS
service acpid stop #seulement pour RHCS
vi /etc/lvm/lvm.conf
     filter = [ "a/.*/" ]
   #filter = [ "a|/dev/cciss/.*|", "a|/dev/mpath.*|", "r|.*|" ] #utiliser cette ligne en cas d’utilisation de multipath et de disques locaux présentés en tant que /dev/cciss. A adapter au contexte
[…]
volume_list = [ "vg01" , "@[TAG]" ]

Dans le cas de RedHat Cluster Suite, remplacer [TAG] par le nom de la machine tel qu’il est définit dans le fichier /etc/cluster/cluster.conf.

En dehors du cas d’un traitement automatisé par cluster, n’importe quel tag convient du moment qu’il est unique à la machine. Dans le cas présent, les tags choisis sont respectivement tag_vm1 et tag_vm2.

Quelques précisions :

filter permet de traiter les cas où on doit ignorer certains disques. C’est typiquement nécessaire lorsque l’on utilise LVM avec multipath ou powerpath, car l’OS voit plusieurs « disques » sda ,sdb, … pour un même disque mpath (1 sdX pour chaque chemin vers mpathY).
volume_list indique à LVM que seul le vg01 (interne) et les VG explicitement taggués avec le nom de la machine qui peuvent être utilisés. Cela permet de s’assurer qu’il n’y a qu’une seule machine qui peut activer le VG du moment qu’on n’ajoute jamais plus d’un tag au VG.

Même si les modifications du fichier lvm.conf sont prises en compte immédiatement, RedHat Cluster Suite impose une recompilation de l’initrd. Dans le cas d’un cluster RHCS, il faut donc lancer la commande suivante :

mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r)

Sur un seul nœud (le premier) :

pvcreate /dev/sdb
pvcreate /dev/sdc
vgcreate -c n vg_mirror /dev/sdb /dev/sdc

Tagger le VG pour pouvoir travailler dessus sur ce nœud.

vgchange --addtag tag_vm1 -ay vg_mirror
lvcreate -n lv_mirror -m1 -l 5116 /dev/vg_mirror
Logical volume "lv_mirror" created

Le journal des écritures doit lui aussi être en miroir

lvconvert --mirrorlog mirrored /dev/vg_mirror/lv_mirror
Logical volume lv_mirror converted.

Il est enfin possible de formater le disque, et de le monter sur le test_partage_vmdk_1

mkfs.ext3 /dev/vg_mirror/lv_mirror
mount /dev/vg_mirror/lv_mirror /mnt

Tester la bascule

Scanner les VGs pour vérifier que le nouveau VG est bien disponible sur le test_partage_vmdk_2

vgscan
vgs

Même s’il le VG est visible, il n’est pas possible de le monter car il n’a pas le bon tag (tel que spécifié dans le lvm.conf). Cela permet de vérifier que l’on ne pourra pas écrire sur les disques sur les deux nœuds en même temps.

Not activating vg_mirror/lv_mirror since it does not pass activation filter.
0 logical volume(s) in volume group “vg_mirror” now active

On peut démonter le FS, désactiver le vg et enlever le tag sur le serveur test_partage_vmdk_1 et vérifier qu’on peut bien le monter et écrire dessus sur le test_partage_vmdk_2.

Ce comportement est automatique sous RedHat Cluster Suite, qui gère lui même les tags lors de la bascule d’un VG/LV.

Sur test_partage_vmdk_1

umount /mnt
vgchange --deltag tag_vm1 -an vg_mirror

Sur test_partage_vmdk_2

vgchange --addtag tag_vm1 -ay vg_mirror
mount /dev/vg_mirror/lv_mirror /mnt

Have fun