retour au menu de la Haute disponibilité


But

Drbd est un équivalent du Raid 1 mais les deux disques sont sur des machines différentes et la synchronisation se fait à travers le réseau. Avec cette pièce de logiciel, on augmente la haute disponibilité. Deux disques en Raid 1 sur la même machine ne nous mettent pas à l’abri d'un arrêt de la machine. Cette configuration est plus délicate et lente mais évite ce cas de figure.

Il est conçu à être intégré à Pacemaker ou équivalent.


Installation

Quelques paquets sont à installer.

dnf install drbd
dnf install drbd-utils
dnf install drbd-pacemaker


Matériel et adressage IP

Pour ces exercices, nous avons besoin de deux machines, chacune avec deux interfaces réseaux. Le schéma ci-dessous reprend la connectique, le nom des machines Linux et leur adressage IP.

Les deux interfaces réseaux "eth2" sont réservés exclusivement à la synchronisation des disques en Drbd afin de ne pas être ralentis par d'autres accès et inversement.

Sur chaque machine, nous avons besoin d'un disque dur de même capacité; nous avons mis un disque de 160 Gb sur chaque machine.


Prérequis

Comme par la suite, on va intégrer Drbd à Pacemaker, les prérequis de l'article sur la Configuration de base de Pacemaker sont d'actualité.


Préparation des disques durs

Il faut maintenant préparer ces disques. Comme vu dans l'article sur les Notions de gestion des disques, nous les préparons avec une seule partition de type LVM ("/dev/sdb1").

Ensuite nous ajoutons une couche LVM. On ajoutons ce device à un Volume Group nommé "fo1_vg_data" pour la machine "fo1.home.dom" et nommé "fo2_vg_data" pour la machine "fo2.home.dom". Ce device est seul dans ce Volume Group. Enfin on y ajoute un Logical Volume qui prend la totalité de l'espace nommé "fo1_lv_data" pour la machine "fo1.home.dom" et nommé "fo2_lv_data" pour la machine "fo2.home.dom". La couche LVM n'est pas obligatoire mais elle permet, si on le désire, utiliser plus d'un disque et d'être indépendant du nom de la partition qui peut changer en fonction de la connectique. Dans la seconde application, nous partirons directement sur les partitions sans couche LVM.

En synthèse, nous avons les devices suivants:

  • "/dev/fo1_vg_data/fo1_lv_data" sur la machine "fo1.home.dom"
  • "/dev/fo2_vg_data/fo2_lv_data" sur la machine "fo2.home.dom"


Configuration

Les fichiers de configuration se retrouvent dans le répertoire "/etc/drbd.d"; le fichier de démarrage se nomme "global_common.conf". Nous n'y intervenons pas. Ensuite sont chargés tous les fichiers dont l'extension est ".res". Ils définissent les nouveaux devices Drbd.


Nous devons créer un fichier que l'on nomme "data.res" dont voici le contenu:


resource drbddata {
 
 net {
   protocol      C;
   verify-alg    sha1;
   after-sb-0pri discard-zero-changes;
   after-sb-1pri discard-secondary;
   after-sb-2pri disconnect;
 }
 
# syncer { rate 45M; }
 
 disk {
   on-io-error detach;
 }
 
 handlers {
   fence-peer "/usr/lib/drbd/crm-fence-peer.9.sh";
   after-resync-target "/usr/lib/drbd/crm-unfence-peer.9.sh";
   split-brain "/usr/lib/drbd/notify-split-brain.sh root";
   out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root";
 }
 
 on fo1.home.dom {
   disk             /dev/fo1_vg_data/fo1_lv_data;
   address          ipv4 192.168.2.71:7789;
   device           /dev/drbd1 minor 1;
   meta-disk        internal;
 }
 
 on fo2.home.dom {
   disk             /dev/fo2_vg_data/fo2_lv_data;
   address          ipv4 192.168.2.72:7789;
   device           /dev/drbd1 minor 1;
   meta-disk        internal;
 }
}

Quelques options sont importantes:

  • le nom de la ressource Drbd se nomme "drbddata"
  • Les deux sections derrière l'option "on" définissent les caractéristiques des deux blocs constituant ce device "/dev/drbd1"
    • Derrière l'option "on", nous avons le nom des machines
    • Derrière la sous-option "disk", nous avons le nom des deux devices de type disque dur que nous avons préparés ci-dessus
    • Derrière la sous-option "address", nous avons les informations réseaux: l'adresse réseau IPV4 de l'interface et le n° de port TCP
    • Derrière la sous-option "device", nous avons le nom du device résultant nommé "/dev/drbd1"

L'ancienne option "syncer" permet de définir la vitesse de transfert en bytes; il existe des options plus récentes, plus adaptatives. Mais le système s'adapte de lui-même et il est calculé à la base pour des cartes réseaux 1Gb, ce que nous avons. Pour cette raison, cette option est mise en commentaire. Le plus facile, pour calculer cette vitesse en bytes et non en bits, on prend la vitesse du périphérique le plus lent entre les disques et les cartes réseaux et on la divise par trois.


Configurer le mur de feu ou FireWall

Si vous activez le Firewall, ce qui est recommandé, il faut y ajouter les règles suivantes qui sont déduites du fichier de configuration du paragraphe précédent.

  • sur la machine "fo1.home.dom", on ajoute:
-A INPUT  -p tcp -m tcp --sport 7789 -s 192.168.2.72 -m conntrack --ctstate NEW -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 7789 -d 192.168.2.72 -j ACCEPT
  • sur la machine "fo2.home.dom", on ajoute:
-A INPUT  -p tcp -m tcp --sport 7789 -s 192.168.2.71 -m conntrack --ctstate NEW -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 7789 -d 192.168.2.71 -j ACCEPT


Principe de fonctionnement

Dans le système Raid 1 classique, un seul disque est accessible, l'autre est là pour recevoir les données à synchroniser et pour prendre la main en cas de problème. Pour Drbd, c'est le même principe en mode Actif/Passif.

Celui qui a la main, est appelé "Primary", l'autre "Secondary". Par défaut, aucun n'a la main et sont donc tous les deux en mode "Secondary"; il faut en désigner un. Si l'autre n'est pas joignable à travers le réseau, il est dit "Unknown". Les deux peuvent être portés au stade "Primary" mais c'est une situation qui demande beaucoup de précautions.

Au début leurs états est "Inconsistent"; c'est à dire que le contenu des deux disques est différent alors qu'il doit être identique. Quand ces contenus sont identiques ou qu'un est défini comme la référence, cet état est déclaré "UpToDate". Quand les deux disques ont un état "UpToDate", nous sommes dans la situation idéale.

Quand les deux machines sont connectées, ce statut est "Connected". Quand une des machines attend d'entrer en connexion avec l'autre, son état est "WFConnection". Lors de l'étape de synchronisation, celui qui envoie des données est à l'état "SyncSource", l'autre qui reçoit les données est à l'état "SyncTarget".

Il existe d'autres termes mais se sont ceux que nous allons rencontrer lors de l'étape suivante.


Création

Il faut maintenant initialiser ce nouveau périphérique "/dev/drbd1". Cette opération est faite manuellement en lignes de commande. Les premières commandes doivent se faire sur les deux machines du cluster Drbd. Dès que le système est lancé, les suivantes se font d'un seul côté.


Pilote

Avant de démarrer, il faut charger le pilote Drbd sur les deux machines:

modprobe drbd


Initialisation du device Drbd

Cette opération analogue au formatage d'un disque. La commande suivante va initialiser la ressource "drbddata" sur chaque disque de chaque machine:

drbdadm create-md drbddata

Cette opération est à faire sur les deux machines. La Commande demande confirmation:

Voici un exemple d'affichage:


md_offset 160037859328
al_offset 160037826560
bm_offset 160032940032
   
Found some data
 
 ==> This might destroy existing data! <==
 
Do you want to proceed?
[need to type 'yes' to confirm] yes
 
initializing activity log
initializing bitmap (4772 KB) to all zero
Writing meta data...
New drbd meta data block successfully created.


Affichage de l'état du système

A tout moment, on peut afficher l'état du système Drdb avec la commande:

cat /proc/drbd

Dans le cas où le système n'est pas démarré, nous avons:


version: 8.4.11 (api:1/proto:86-101)
srcversion: 086EBDAD8BB6D6FF00986AA

Par la suite, nous utiliserons cette commande pour montrer l'évolution de la création.


Démarrage

Maintenant, on peut démarrer cette ressource "drbddata" sur les deux machines.

drbdadm up drbddata

Dès que le processus est démarré sur une machine, l'état devient ("cat /proc/drbd"):


version: 8.4.11 (api:1/proto:86-101)
srcversion: 086EBDAD8BB6D6FF00986AA
 
 1: cs:WFConnection ro:Secondary/Unknown ds:Inconsistent/DUnknown C r----s
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:156282168

Cette machine attend la connexion ("WFConnection"). Quand son équivalent est démarré sur l'autre machine, l'état devient:


version: 8.4.11 (api:1/proto:86-101)
srcversion: 086EBDAD8BB6D6FF00986AA
 
 1: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r-----
    ns:0 nr:0 dw:0 dr:0 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:156282168

On remarque que l'état est connecté ("Connected") mais "Inconsistent". Les deux machines sont à l'état Passif/Passif.


Synchronisation

Comme vu ci-dessus, après ce premier démarrage, l'état est "Inconsistent". C'est normal; chaque disque est constitué de données différentes.

Il faut synchroniser les deux disques. On déclare que celui de la machine "fo1.home.dom" est la référence. Sur cette seule machine, on force le système à se mettre en tant que "Primary", celui qui envoie les données, pour la ressource "drbddata" avec la commande suivante:

drbdadm primary --force drbddata

La synchronisation démarre et pour notre configuration, ce processus va durer 1h.

Sur la machine "fo1.home.dom", l'état affiché passe à:


version: 8.4.11 (api:1/proto:86-101)
srcversion: 086EBDAD8BB6D6FF00986AA
 
 1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
    ns:784128 nr:0 dw:0 dr:784128 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:155498040
        [>....................] sync'ed:  0.6% (151852/152616)M
        finish: 1:09:22 speed: 37,336 (37,336) K/sec

Il transmet ("SyncSource") et il est la référence ("UpToDate").

On peut visionner l'évolution de cet état sur l'autre machine, ici un peut plus tard:


version: 8.4.11 (api:1/proto:86-101)
srcversion: 086EBDAD8BB6D6FF00986AA
 
 1: cs:SyncTarget' ro:Secondary/Primary ds:Inconsistent/UpToDate C r-----
    ns:0 nr:73796608 dw:73796352 dr:0 al:0 bm:0 lo:2 pe:4 ua:1 ap:0 ep:1 wo:f oos:82485816
        [========>...........] sync'ed: 47.3% (80552/152616)M
        finish: 0:35:45 speed: 38,424 (37,516) want: 48,400 K/sec

On peut voir la vitesse de transfert en réception ("SyncTarget"): environ 38,4MB/s (38,424).


On peut observer les connexions de Drbd entre nos deux machines:

netstat -natp | grep ":7789"

Ici sur la machine "fo1.home.dom":


Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat        PID/Program name
tcp        0      0 192.168.2.71:7789       192.168.2.72:56647      ESTABLISHED -
tcp        0 570800 192.168.2.71:44847      192.168.2.72:7789       ESTABLISHED -


Enfin quand la synchronisation est finie, l'état devient stable ("Connected") et mis à jour ("UpToDate"):


version: 8.4.11 (api:1/proto:86-101)
srcversion: 086EBDAD8BB6D6FF00986AA
 
 1: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
    ns:156282168 nr:0 dw:0 dr:156282168 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0


On peut observer la quantité de données échangée avec la commande:

ifconfig

Sur la machine "fo1.home.dom", affichage limité à l'interface réseau "eth2" utilisé:


eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.2.71  netmask 255.255.255.0  broadcast 192.168.2.255
       ether 00:1b:21:3b:b6:ea  txqueuelen 1000  (Ethernet)
       RX packets 11892040  bytes 834317226 (795.6 MiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 111680341  bytes 167428741104 (155.9 GiB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

et sur la machine "fo2.home.dom" (un peu plus tard):


eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.2.72  netmask 255.255.255.0  broadcast 192.168.2.255
       ether 00:1c:c0:2a:c4:25  txqueuelen 1000  (Ethernet)
       RX packets 111682659  bytes 167878464532 (156.3 GiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 11892728  bytes 881941130 (841.0 MiB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
       device interrupt 20  memory 0xe0380000-e03a0000

On a transféré 156GB.


Utilisation

Maintenant que le système est opérationnel, on peut l'utiliser. Ce device "/dev/drbd1" est à considérer comme une partition normale ou à un Logical Volume que l'on peut formater et monter.

Ces opérations sont à faire sur une seule machine, la "Primary", "fo1.home.dom". Dans notre configuration actuelle, il n'est pas question d'être en double "Primary".


Formatage

Sur la machine "Primary", "fo1.home.dom", on va le formater en "xfs":

mkfs.xfs /dev/drbd1


Montage

On crée un répertoire pour ce nouveau device:

mkdir /data

Profitons-en pour effectuer cette création de ce répertoire sur les deux machines car par la suite, sous Pacemaker, nous serons amené à pouvoir migrer cette ressource sur l'autre machine en cas de situation de panne.


On le monte:

mount -t xfs /dev/drbd1 /data

On peut dès lors y copier des fichiers.


Choisir l'état

La commande suivante permet de passer sur la machine local, la ressource ("drbddata") à l'état Actif ("primary"):

drbdadm primary drbddata

Et celle-ci de passer sur la machine local, la ressource ("drbddata") à l'état Passif ("Secondary"):

drbdadm secondary drbddata


Arrêt

Considérons l'arrêt de cette ressource.

En premier, on démonte ce device sur la machine "Primary", "fo1.home.dom":

umount /data


Dès lors on peut arrêter cette ressource "drbddata" sur les deux machines:

drbdadm down drbddata


Remarques

Toute cette opération a été faite manuellement. Ne tentez pas de l'automatiser comme une partition classique. Nous verrons dans l'article suivant comment l'intégrer à Pacemaker dans une situation de Failover et ensuite de Loadbalancing.

Autre remarque, le pilote sera chargé automatiquement par Pacemaker.

Les deux interfaces réseaux "eth2" sont réservés à la liaison entre ces deux machines. Il est donc possible de les relier directement sans Switch; soit par un câble réseau croisé (en théorie, c'est nécessaire), soit un câble réseau normal si les cartes réseaux ont la capacité d'effectuer ce croisement automatique de façon logiciel. C'est notre cas.




retour au menu de la Haute disponibilité