wiki/HowtoDRBD.md at fe931a5c476e18c975def3984bf402df270c6bf3

evolix

wiki

9.7 KiB

Raw Blame History

title
Howto DRBD

Documentation : http://www.drbd.org/en/doc/users-guide-84

Installation

# aptitude install drbd-utils

# drbdadm -V
DRBDADM_BUILDTAG=GIT-hash:\ 5474c321d80250cc61d851220503fdc739490ce9\ build\ by\ pbuilder@marvin\,\ 2016-01-04\ 12:36:34
DRBDADM_API_VERSION=1
DRBD_KERNEL_VERSION_CODE=0x080403
DRBDADM_VERSION_CODE=0x080902
DRBDADM_VERSION=8.9.2rc1

# modinfo drbd
filename:       /lib/modules/3.16.0-4-amd64/kernel/drivers/block/drbd/drbd.ko
alias:          block-major-147-*
license:        GPL
version:        8.4.3
description:    drbd - Distributed Replicated Block Device v8.4.3
author:         Philipp Reisner <phil@linbit.com>, Lars Ellenberg <lars@linbit.com>
srcversion:     1A9F77B1CA5FF92235C2213
depends:        lru_cache,libcrc32c
intree:         Y
vermagic:       3.16.0-4-amd64 SMP mod_unload modversions
parm:           minor_count:Approximate number of drbd devices (1-255) (uint)
parm:           disable_sendpage:bool
parm:           allow_oos:DONT USE! (bool)
parm:           proc_details:int
parm:           usermode_helper:string

À propos des protocoles

DRBD dispose de 3 protocoles de réplication/synchronisation, A, B et C.

A : Réplication asynchrone. Les écritures sur le disque local du nœud primaire sont considérées complètes dès que le disque local a fini. Les paquets de réplication sont placés dans le buffer TCP.

B : Réplication synchronisé en mémoire. Les écritures sur le disque local du nœud primaire sont considérées complètes dès que le disque local a fini et que les paquets de réplication sont reçus sur le second nœeud.

C : Réplication synchronisé sur les disques. Les écritures sur le disque local du nœud primaire sont considérées complètes dès que le disque local a fini et sur le disque distant aussi.

Le protocole C est le plus sécurisé, le B est un compromis entre rapidité et sécurité, et enfin le A est le plus rapide mais le moins sécurisé.

/!\ Attention, seul le protocole C permet d'utiliser l'option allow-two-primaries.

La modification du protocole se fait dans la section net{} d'une ressource. Le protocole utilisé par défaut est le protocole C.

Exemple de configuration.

resource "vol0" {
    net {
        cram-hmac-alg "sha1";
        shared-secret "123xxx";
        #allow-two-primaries;
        protocol A;
    }
[…]

Configuration d'une ressource en mode Primary/Primary

/etc/drbd.d/r0.res :

resource r0 {
    net {
        protocol C;
        cram-hmac-alg "sha1";
        shared-secret "PASSWORD";
        allow-two-primaries;
    }
    volume 0 {
        device minor 0;
        disk /dev/sda10;
        meta-disk internal;
    }
    on tic {
        address 192.0.2.1:7788;
    }
    on tac {
        address 192.0.2.2:7788;
    }
}

Note : "tic" et "tac" doivent correspondre aux hostnames réels des machines concernées.

Puis sur les 2 machines :

# drbdadm create-md r0
initializing activity log
NOT initializing bitmap
Writing meta data…
New drbd meta data block successfully created.

# drbdadm attach r0
Device '0' is configured!
Command 'drbdmeta 0 v08 /dev/sda10 internal apply-al' terminated with exit code 20

Et sur l'une des 2 machines :

# drbdadm -- --overwrite-data-of-peer primary r0

Configuration d'une seconde ressource en mode Primary/Primary

On peut configurer plusieurs volumes par ressource.

/etc/drbd.d/r0.res :

resource r0 {
    net {
        protocol C;
        cram-hmac-alg "sha1";
        shared-secret "PASSPHRASE";
        allow-two-primaries;
    }
    volume 0 {
        device minor 0;
        disk /dev/sda10;
        meta-disk internal;
    }
    volume 1 {
        device minor 1;
        disk /dev/sdb1;
        meta-disk internal;
    }
    on tic {
        address 192.0.2.1:7788;
    }
    on tac {
        address 192.0.2.2:7788;
    }
}

On peut aussi évidemment configurer plusieurs ressources (entre machines différentes, avec un status Primary/Secondary différent, etc.), dans ce cas on dupliquera simplement la configuration d'une ressource en utilisant des ports réseau différents.

OCFS2 : FS Clusterisé

Il est nécessaire de disposer d'un FS clusterisé car le FS sera monté à deux endroits différents, ce qui n'est pas possible avec un FS standard tel que ext4.

Installation

# aptitude install ocfs2-tools

Configurer OCFS dans /etc/ocfs2/cluster.conf

node:
    ip_port = 7777
    ip_address = 192.0.2.1
    number = 0
    name = kvm1
    cluster = ocfs2

node:
    ip_port = 7777
    ip_address = 192.0.2.2
    number = 1
    name = kvm2
    cluster = ocfs2

cluster:
    node_count = 2
    name = ocfs2

Formater le device drbd0 sur une seule machine.

# mkfs.ocfs2 /dev/drbd/by-res/r0

Monter la partition sur les deux machines.

# /etc/init.d/o2cb online
# mount /dev/drbd/by-res/r0 /virtualmachines

Monitoring

Munin

Il peut être intéressant de grapher quelques infos sur drbd dans Munin. On peut utiliser 1 plugin pour cela :

# mkdir -p /usr/local/share/munin/plugins/
# cd /usr/local/share/munin/plugins/
# wget <https://raw.githubusercontent.com/munin-monitoring/contrib/master/plugins/drbd/drbd>
# chmod -R 755 /usr/local/share/munin
# cd /etc/munin/plugins/
# ln -s /usr/local/share/munin/plugins/drbd .
# cat <<EOT >> /etc/munin/plugin-conf.d/munin-node
[drbd]
user root
EOT

Nagios

Il peut être utile de surveiller l'état de la synchro via Nagios. https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_drbd/details

command[check_drbd]=/usr/local/lib/nagios/plugins/check_drbd -d All -c StandAlone

FAQ & Tips

Récupérer d'une perte de connectivité

Quand il y a une perte de synchro. On peut y :

drbdadm disconnect all
drbdadm connect all
/etc/init.d/drbd stop && /etc/init.d/drbd start

Ou bien redémarrer le serveur qui a rencontré le soucis. (Perte connexion réseau, bug, …)

Récupérer d'un split-brain

Sur le serveur en Standalone qu'on veut réinitialiser :

# drbdadm secondary r0
# drbdadm invalidate r0
# drbdadm disconnect r0
# drbdadm connect r0

Sur le serveur "master"

# drbdadm connect r0
# cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
srcversion: F937DCB2E5D83C6CCE4A6C9
 0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
    ns:98147667 nr:0 dw:118847637 dr:101298287 al:3692894 bm:26045 lo:62 pe:23 ua:54 ap:8 ep:1 wo:f oos:313362256
        [===>…] sync'ed: 23.9% (306016/401760)Mfinish: 0:57:33 speed: 90,716 (88,724) K/sec

Sur le serveur qui était Standalone une fois la synchro terminée :

# drbdadm primary r0

Forcer à resynchroniser à nœud de zéro

Si par exemple on a :

block drbd0: Unrelated data, aborting

Un des serveurs à perdu les méta-données il faut les re-construire pour que drbd se re-synchronise, lors de la création de méta-données les données seront perdues ! Assurez-vous de choisir le bon serveur, celui qui est le plus à jour.

On peut aussi faire cette opération pour d'autres raisons, comme par exemple un nœud avec des données différentes de chaque côté suite à une désynchronisé trop longue et non détectée.

Faire un unmount de la partition concerné, puis :

# /etc/init.d/o2cb offline
# drbdadm down r0
# drbdadm create-md r0
# drbdadm up r0

Si la synchro ne part pas, faire un connect.

# drbdadm connect r0

Une fois la synchro terminé (cat /proc/drbd), on le repasse en primaire, pour être en master-master.

# drbdadm primary r0
# /etc/init.d/o2cb online

Erreur "Unable to access cluster service while trying initialize cluster"

Si vous avez une erreur "Starting Oracle Cluster File System (OCFS2) mount.ocfs2: Unable to access cluster service while trying initialize cluster" :

# /etc/init.d/o2cb online
# /etc/init.d/ocfs2 restart

Bien comprendre /proc/drbd

0: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r-----

Le nœud attend une éventuelle reconnexion du second nœud pour se resynchroniser.

0: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r-----

Il s'agit d'un split-brain, le nœud est en standalone, et n'est plus synchronisé avec le second nœud.

0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----

Les nœuds sont bien synchronisés.

0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----                               
   ns:782997 nr:8388524 dw:10158853 dr:684557 al:456 bm:562 lo:0 pe:5 ua:64 ap:0 ep:1 wo:f oos:7780060
       [>…] sync'ed:  7.3% (7596/8188)Mfinish: 0:04:29 speed: 28,800 (28,964) K/sec

Une synchronisation du serveur primaire est en cours vers le secondaire. (ro:Primary/Secondary ds:UpToDate/Inconsistent)

Reload DRBD

Si vous modifiez à chaud la conf de DRDB, pensez à reloader :

# /etc/init.d/drbd reload
[ ok ] Reloading drbd configuration (via systemctl): drbd.service.

On peut aussi le faire avec drbdadm adjust all. Ou en précisent le nom de la ressources plutôt que all.

Changer le sync rate à la volée

# drbdadm disk-options --c-plan-ahead=20 --resync-rate=20M nomRessource

« plan-ahead » à 20 active un mode intelligent qui permet de prioriser les écritures en cours plutôt que la synchronisation en arrière-plan.

Fixer une limite de synchronisation

resource <resource>
  disk {
    resync-rate 40M;
[…]
  }
[…]
}

Supprimer une ressource

# drbdadm disconnect <resource>
# drbdadm detach <resource>

# drbdadm down <resource>

On pourra ensuite supprimer le fichier de conf associé et reloader drbd.

Passer primary ou secondary

Tout simplement

# drbdadm primary <resource>

# drbdadm secondary <resource>

9.7 KiB Raw Blame History

Installation

À propos des protocoles

Configuration d'une ressource en mode Primary/Primary

Configuration d'une seconde ressource en mode Primary/Primary

OCFS2 : FS Clusterisé

Installation

Monitoring

Munin

Nagios

FAQ & Tips

Récupérer d'une perte de connectivité

Récupérer d'un split-brain

Forcer à resynchroniser à nœud de zéro

Erreur "Unable to access cluster service while trying initialize cluster"

Bien comprendre /proc/drbd

Reload DRBD

Changer le sync rate à la volée

Fixer une limite de synchronisation

Supprimer une ressource

Passer primary ou secondary

9.7 KiB

Raw Blame History