18
0
Fork 0

nombreux ajouts et vérifications

This commit is contained in:
gcolpart 2017-01-24 04:56:50 +01:00
parent 61d33c5091
commit 1dab9234c9
1 changed files with 551 additions and 362 deletions

View File

@ -4,8 +4,9 @@ title: Howto DRBD
...
* Documentation : <http://www.drbd.org/en/doc/users-guide-84>
* http://www.linbit.com/en/resources/technical-publications/
[DRBD](http://www.drbd.org) (Distributed Replicated Block Device) est un outil pour répliquer des blocs (disques, partitions…) entre deux serveurs Linux via une connexion réseau. On peut voir cela comme un « RAID1 par le réseau ». Nous l'utilisons principalement comme stockage pour de la virtualisation avec [KVM](HowtoKVM), cela permet de réaliser des migrations à chaud de machines virtuelles entre deux hyperviseurs sans dépendre d'un équipement externe de type _SAN_.
[DRBD](http://www.drbd.org) (Distributed Replicated Block Device) est un outil libre pour répliquer des blocs (disques, partitions, volumes LVM…) entre deux serveurs Linux via une connexion réseau. On peut voir cela comme un « RAID1 over TCP/IP ». Nous l'utilisons principalement comme stockage pour de la virtualisation avec [KVM](HowtoKVM), cela permet notamment de réaliser des migrations à chaud de machines virtuelles entre deux hyperviseurs sans dépendre d'un équipement externe de type _SAN_.
## Installation
@ -41,12 +42,12 @@ parm: usermode_helper:string
## Utilisation basique
Avec DRBD on définit :
Sur une installation DRBD on définit :
- des **ressources** : chaque ressource a différents paramètres, notamment le second serveur pour la réplication
- des **volumes** : chaque ressource peut avoir un ou plusieurs volumes, chaque volume est accessible via un périphérique unique `/dev/drbdXX`
- des **ressources** : chaque ressource DRBD a plusieurs paramètres, notamment le second serveur vers qui envoyer/recevoir la réplication
- des **volumes** : chaque ressource DRBD peut avoir un ou plusieurs volumes, chaque volume est accessible via un périphérique unique nommé `/dev/drbdXX`
La configuration des ressources DRBD sont dans le répertoire `/etc/drbd.d/` par exemple `/etc/drbd.d/foo.res` définit le volume `/dev/drbd42`:
La configuration des ressources DRBD est dans le répertoire `/etc/drbd.d/` par exemple `/etc/drbd.d/foo.res` définit le volume `/dev/drbd42`:
~~~
resource "foo" {
@ -55,26 +56,427 @@ resource "foo" {
disk /dev/sdz1;
meta-disk internal;
}
on {
on tic {
address 192.0.2.1:7014;
}
on kvm7 {
on tac {
address 192.0.2.2:7014;
}
}
~~~
Pour voir les volumes configurés et leur statut :
~~~
$ cat /proc/drbd
$ drbd-overview
version: 8.4.7 (api:1/proto:86-101)
srcversion: 0904DF2CCF7283ACE07D07A
42: cs:WFConnection ro:Secondary/Unknown ds:Inconsistent/DUnknown C r----s
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:1048508
# drbd-overview
42:foo/0 WFConnection Secondary/Unknown Inconsistent/DUnknown
~~~~
Pour lister la configuration et vérifier la syntaxe :
~~~
# drbdadm dump
~~~
**drbdadm** est l'outil principal pour DRBD, voici quelques commandes utilisables sur une ressource :
~~~
# drbdadm dump
# drbdadm create-md [ressource]
# drbdadm attach/detach [ressource]
# drbdadm connect/disconnect [ressource]
# drbdadm adjust/adjust-with-progress [ressource]
# drbdadm primary/secondary [ressource]
~~~
**drbdadm** pilote principalement les commandes bas niveau `drbdsetup` et `drbdmeta` : son mode _dry-and-run_ est très utile car il va lister les commandes bas niveau effectuées (sans les appliquer). Par exemple pour voir tous les changements de configuration non appliqués :
~~~
# drbdadm -d adjust all
~~~
## Création de ressources/volumes
## À propos des protocoles
### ressource avec un seul volume
Il faut créer `/etc/drbd.d/foo.res` **sur les deux serveurs concernés** :
~~~
resource "foo" {
net {
#allow-two-primaries;
}
volume 0 {
device minor 42;
disk /dev/sdz1;
meta-disk internal;
}
on tic {
address 192.0.2.1:7014;
}
on tac {
address 192.0.2.2:7014;
}
}
~~~
> *Note* : les hostnames et adresses IP doivent être correctes, DRBD vérifie qu'ils sont effectivement configurés en local !
On vérifie la syntaxe :
~~~
# drbdadm dump foo
# resource foo on diez: not ignored, not stacked
# defined at /etc/drbd.d/foo.res:1
[…]
~~~
On initialise les _metadatas_ sur les volumes de la ressource (attention, cela écrit des données à la fin des _disk_) sur chaque serveur :
~~~
tic# drbdadm create-md foo
tac# drbdadm create-md foo
initializing activity log
NOT initializing bitmap
Writing meta data...
New drbd meta data block successfully created.
~~~
On utilise la commande _drbdadm adjust_ en mode dry-and-run sur chaque serveur pour vérifier les actions :
~~~
tic# drbdadm -d adjust foo
tac# drbdadm -d adjust foo
drbdsetup-84 new-resource foo
drbdsetup-84 new-minor foo 42 0
drbdmeta 42 v08 /dev/sdz1 internal apply-al
drbdsetup-84 attach 42 /dev/sdz1 /dev/sdz1 internal
drbdsetup-84 connect foo ipv4:192.0.2.1:7014 ipv4:192.0.2.2:7014
~~~
Puis on applique cette nouvelle configuration :
~~~
tic# drbdadm adjust foo
tac# drbdadm adjust foo
~~~
À ce stade, vous devez avoir une ressource _Connected_ avec des données _Inconsistent_ :
~~~
# drbd-overview
42:foo/0 Connected Secondary/Secondary Inconsistent/Inconsistent
~~~
Il reste à forcer la synchronisation d'un côté :
~~~
tic# drbdadm -- --overwrite-data-of-peer primary foo
~~~
Et observer la resynchronisation et l'état **UpToDate** de chaque côté :
~~~
# drbd-overview
42:foo/0 SyncSource Primary/Secondary UpToDate/Inconsistent
[===>................] sync'ed: 22.3% (818364/1048508)K
# drbd-overview
42:foo/0 Connected Primary/Secondary UpToDate/UpToDate
~~~
Si l'on veut être en _Primary/Primary_ il faut avoir configuré `allow-two-primaries;` puis :
~~~
tac# drbdadm primary foo
# drbd-overview
42:foo/0 Connected Primary/Primary UpToDate/UpToDate
~~~
### ressources avec plusieurs volumes
On peut avoir plusieurs volumes pour une même ressource.
Cela simplifie la configuration (un seul fichier) et la gestion (drbdadm s'applique pour tous les volumes d'une même ressource).
Voici un exemple de fichier `/etc/drbd.d/foo.res` associé à un volume pour `/dev/drbd43` et un volume pour `/dev/drbd44` :
~~~
resource "foo" {
net {
#allow-two-primaries;
}
volume 0 {
device minor 43;
disk /dev/sdz1;
meta-disk internal;
}
volume 1 {
device minor 44;
disk /dev/sdz2;
meta-disk internal;
}
on tic {
address 192.0.2.1:7014;
}
on tac {
address 192.0.2.2:7014;
}
}
~~~
> *Note* : attention, les _device minor_ doivent être différents (uniques sur tout un serveur)
Les étapes sont similaires à une ressource avec un seul volume (voir ci-dessous pour détails). En résumé :
~~~
tic# drbdadm create-md foo
tac# drbdadm create-md foo
tic# drbdadm adjust foo
tac# drbdadm adjust foo
tic# drbdadm -- --overwrite-data-of-peer primary foo
~~~
Si l'on veut être en _Primary/Primary_ :
~~~
tac# drbdadm primary foo
~~~
### ajouter un volume à une ressource existante
Pour ajouter un volume à une ressource existante avec des volumes déjà en production, on utilisera directement les commandes bas niveau `drbdsetup` et `drbdmeta` pour ne pas perturber les autres volumes.
Voici l'exemple du fichier `/etc/drbd.d/foo.res` ci-dessus avec l'ajout d'un 3ème volume `/dev/drbd45` :
~~~
resource "foo" {
net {
#allow-two-primaries;
}
volume 0 {
device minor 43;
disk /dev/sdz1;
meta-disk internal;
}
volume 1 {
device minor 44;
disk /dev/sdz2;
meta-disk internal;
}
volume 2 {
device minor 45;
disk /dev/sdz3;
meta-disk internal;
}
on tic {
address 192.0.2.1:7014;
}
on tac {
address 192.0.2.2:7014;
}
}
~~~
On crée ensuite les _metadatas_ uniquement pour ce nouveau volume `/dev/drbd45` :
~~~
tic# drbdmeta 45 v08 /dev/sdz3 internal create-md
tac# drbdmeta 45 v08 /dev/sdz3 internal create-md
~~~
Puis on applique cette nouvelle configuration (en observant avant en mode dry-and-run) :
~~~
tic# drbdadm -d adjust foo
tac# drbdadm -d adjust foo
tic# drbdadm adjust foo
tac# drbdadm adjust foo
~~~
Et enfin, on force la synchronisation de ce nouveau volume `/dev/drbd45` :
~~~
tic# drbdsetup primary 45 --overwrite-data-of-peer
~~~
Si l'on veut être en _Primary/Primary_ :
~~~
tac# drbdsetup primary 45
~~~
## Configuration
<https://www.drbd.org/en/doc/users-guide-84/re-drbdconf>
La configuration générale (directives _global_ et _common_) est dans le fichier `/etc/drbd.d/global_common.conf` (inclus par `/etc/drbd.conf`), les ressources sont dans des fichiers `/etc/drbd.d/*.res` (directives _resource_).
~~~
/etc/drbd.conf
├── /etc/drbd.d/global_common.conf
└── /etc/drbd.d/*.res
~~~
### Authentification
Afin de sécuriser un peu les échanges DRBD entre deux serveurs et surtout pour éviter des erreurs de manipulation, on peut configurer une authentification dans la section _net{}_ (que l'on peut mettre dans _common_ ou dans chaque directive _resource_):
~~~
net {
cram-hmac-alg "sha1";
shared-secret "PASSWORD";
}
~~~
### Protocoles A/B/C et _allow-two-primaries_
DRBD dispose de 3 protocoles de réplication/synchronisation : A, B et C.
* A : réplication asynchrone
* B : réplication semi-asynchrone
* C : réplicaton synchrone (c'est le protocole utilisé par défaut), seul ce mode permet l'option `allow-two-primaries;`
On peut configurer le protocole dans la section _net{}_ (que l'on peut mettre dans _common_ ou dans chaque directive _resource_):
~~~
net {
protocol A;
}
net {
protocol B;
}
net {
protocol C;
allow-two-primaries;
}
~~~
### Vitesse de re-synchronisation
<https://www.drbd.org/en/doc/users-guide-84/s-configure-sync-rate>
Par défaut, la vitesse de re-synchronisation est dynamique et limitée à 100Mo/s (soit 800Mb/s). Ceci est valable depuis DRBD 8.4 [même si la documentation principale n'est pas tout à fait à jour](https://www.drbd.org/en/doc/users-guide-84/re-drbdconf). [Les paramètres par défaut sont](https://www.drbd.org/en/doc/users-guide-84/s-recent-changes-defaults#s-recent-changes-defaults-variable-rate-sync) `c-plan-ahead 20; c-fill-target 50k; c-min-rate 250k; c-max-rate 100M;`.
Si besoin, on peut fixer temporairement cette vitesse (pour la limiter ou pour l'augmenter) en définissant en Mo/s sur le serveur qui reçoit les données :
~~~
# drbdadm disk-options --c-plan-ahead=0 --resync-rate=500M <ressource>
~~~
Pour reprendre les valeurs des fichiers de configuration :
~~~
# drbdadm adjust <ressource>
~~~
Si l'on veut modifier des paramètres de façon définitive, on utilisera la section _disk{}_ (que l'on peut mettre dans _common_ ou dans chaque directive _resource_) :
~~~
disk {
c-max-rate 300M;
resync-rate 40M;
}
~~~
## Administration
### Supprimer une ressource
On peut supprimer une ressource via `drbdadm down` (qui fait un _disconnect_ puis _detach_) :
~~~
# drbdadm down <ressource>
~~~
On peut ensuite supprimer le fichier de conf associé et s'assurer que c'est pris en compte :
~~~
# rm /etc/drbd.d/<ressource>.res
# drbdadm dump <ressource>
~~~
### Passer une ressource en primary/secondary
Pour passer une ressource en primary ou secondary :
~~~
# drbdadm primary <ressource>
# drbdadm secondary <ressource>
~~~
> *Note* : pour passer en _primary_ il faut s'assurer d'utiliser le protocole C et d'avoir configuré `allow-two-primaries;`
### DRBD et systemd
Bien qu'il n'y ait pas de démon pour DRBD, il y a une unité [systemd](HowtoSystemd), mais **son utilisation est déconseillée** :
* `systemctl reload drbd` fait un `drbdadm adjust all` : autant utiliser la commande soi-même (en la testant en dry-and-run avant)
* `systemctl start drbd` fait tout d'abord un `drbdadm adjust-with-progress all` : si vous n'avez aucune ressource DRBD, cela échoue avec _no resources defined!_ ; il fait ensuite `drbdadm wait-connect all` qui sera bloqué infiniment si vos serveurs secondaires ne sont pas encore opérationnels ; enfin, il tente de passer les ressources en _Primary_ ce qu'il est plus prudent de faire manuellement
* `systemctl stop drbd` est dangereux, il stoppe toutes les ressources en faisant `drbdadm stop all`
## Plomberie
<https://www.drbd.org/en/doc/users-guide-84/p-learn>
DRBD est un _block device_ qui se met en _proxy_ devant un périphérique de stockage pour intercepter les requêtes en écriture et les réplique sur un périphérique distant via un lien réseau.
<img src="https://www.drbd.org/ug/users-guide-8.4/drbd-in-kernel.png" alt="Architecture de DRBD" />
DRBD a besoin de [metadatas](https://www.drbd.org/en/doc/users-guide-84/ch-internals#s-metadata) : il les écrit en général **à la fin** du disque concerné (`meta-disk internal`)… la taille du _block device_ final est donc un peu plus petite que le disque concerné. Il peut aussi gérer ses _metadatas_ à un autre emplacement, ce qui peut notamment servir à utiliser DRBD avec un disque sans le modifier.
Les metadatas DRBD contiennent :
* la taille du volume DRBD
* des _Generation Identifiers (GI)_
* un _Activity Log (AL)_ qui liste les blocs récemment écrits au cas où
* Un _quick-sync bitmap_ qui est une sorte de hash du volume DRBD pour optimiser la resynchronisation
Les [Generation Identifiers (GI)](https://www.drbd.org/en/doc/users-guide-84/s-gi) identifient le statut d'un volume DRBD. Concrètement il s'agit de plusieurs UUID auxquels on peut accéder via :
~~~
# drbdadm show-gi foo2
+--< Current data generation UUID >-
| +--< Bitmap's base data generation UUID >-
| | +--< younger history UUID >-
| | | +-< older history >-
V V V V
0283D46356ABF426:0000000000000000:E55525BF67DFF687:E55425BF67DFF687:1:1:0:1:0:0:0
^ ^ ^ ^ ^ ^ ^
-< Data consistency flag >--+ | | | | | |
-< Data was/is currently up-to-date >--+ | | | | |
-< Node was/is currently primary >--+ | | | |
-< Node was/is currently connected >--+ | | |
-< Node was in the progress of setting all bits in the bitmap >--+ | |
-< The peer's disk was out-dated or inconsistent >--+ |
-< This node was a crashed primary, and has not seen its peer since >--+
flags: Secondary, Connected, UpToDate
meta-data: need apply-al
~~~
### À propos des protocoles
DRBD dispose de 3 protocoles de réplication/synchronisation, A, B et C.
@ -86,398 +488,185 @@ C : Réplication synchronisé sur les disques. Les écritures sur le disque loca
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.
Si l'on souhaite ajouter un volume à une ressource existante il faudra générer les métadonnées avec `drbdmeta`.
Dans cet exemple, toujours sur les deux machines, on ajoute un troisième volume `volume 2` à notre ressource précédente :
~~~
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;
}
volume 2 {
device minor 2;
disk /dev/sdc1;
meta-disk internal;
}
on tic {
address 192.0.2.1:7788;
}
on tac {
address 192.0.2.2:7788;
}
}
~~~
On crée ensuite les métadonnées liées à ce nouveau volume :
~~~
# drbdmeta 2 v08 /dev/sdc1 internal create-md
~~~
Et on recharge la configuration :
~~~
# /etc/init.d/drbd reload
~~~
## 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
~~~
# apt 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-----
42: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r-----
~~~
Le nœud attend une éventuelle reconnexion du second nœud pour se resynchroniser.
Le nœud attend une reconnexion avec le second nœud pour lui renvoyer les données (resynchronisation).
~~~
0: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown r-----
42: 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-----
42: 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-----
42: 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)
Une synchronisation est en cours vers le serveur secondaire.
### Reload DRBD
TODO : expliquer ns/nr/dw/al/bm/log/pe/ua/ap/ep/wo/oos
Si vous modifiez à chaud la conf de DRDB, pensez à reloader :
## Optimisation
<https://www.drbd.org/en/doc/users-guide-84/p-performance>
### disque
DRBD s'assure que les données sont écrites, et notamment que les données sont effectivement écrites sur le disque. Si l'on veut davantage de performance, on peut désactiver ces actions. On conseille notamment de le faire si l'on utilise une carte RAID hardware équipée d'une batterie :
~~~
# /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;
[…]
}
[…]
disk {
disk-barrier no;
disk-flushes no;
md-flushes no;
}
~~~
### Supprimer une ressource
On peut synchroniser moins souvent les _metadatas_ :
~~~
# drbdadm disconnect <resource>
# drbdadm detach <resource>
disk {
al-extents 6433;
}
~~~
ou
On peut aussi envisager de modifier le _scheduler_ des disques concernés par DRBD de _cfq_ à **_deadline__** et modifier certaines valeurs _iosched/*_.
### réseau
Si possible, on peut activer les _Jumbo Frames_ sur interfaces concernées par DRBD et tous les équipements intermédiaires :
~~~
# drbdadm down <resource>
# ifconfig eth4 mtu 9000
~~~
On pourra ensuite supprimer le fichier de conf associé et reloader drbd.
### Passer primary ou secondary
Tout simplement
On peut augmenter les buffers de chaque volume :
~~~
# drbdadm primary <resource>
net {
max-buffers 8000;
max-epoch-size 8000;
}
~~~
ou
### Choix du protocole
Le protocole C utilisé par défaut est le plus sécurisé, mais il implique qu'une donnée est considérée comme écrite si elle l'a été également sur le second serveur. Pour éviter cela on peut utiliser le protocole A ou B tout en gardant en tête que c'est risqué. Le plus performant (et le plus risqué) est `protocol A;`
## Monitoring
### Munin
Il existe un plugin Munin pour avoir des graphes disque/réseau pour chaque volume DRBD :
~~~
# drbdadm secondary <resource>
$ wget https://raw.githubusercontent.com/munin-monitoring/contrib/master/plugins/drbd/drbd
~~~
Le plugin _drbd_ nécessite a priori de tourner en root, `/etc/munin/plugin-conf.d/munin-node` :
~~~
[drbd]
user root
~~~
### Nagios
On peut surveiller l'état des synchronisations DRBD via Nagios via <https://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_drbd/details>
~~~
/usr/local/lib/nagios/plugins/check_drbd -d All -c StandAlone
~~~
## FAQ
### Récupérer d'un _split-brain_
<https://www.drbd.org/en/doc/users-guide-84/s-resolve-split-brain>
Un _split-brain_ signifie que des écritures ont été réalisées sur deux volumes primaires et desynchronisés, le seul moyen est de choisir manuellement un volume à réinitialiser !
Sur le serveur en _Standalone_ qu'on veut réinitialiser :
~~~
# drbdadm secondary <ressource>
# drbdadm invalidate <ressource>
# drbdadm disconnect <ressource>
# drbdadm connect <ressource>
~~~
Sur le serveur primaire où sont les données choisies comme valides :
~~~
# drbdadm connect <ressource>
~~~
### Unrelated data, aborting
~~~
block drbd0: Unrelated data, aborting
~~~
Si l'on obtient ce message, c'est probablement que les _metadatas_ ont été perdues sur un volume. Il faut alors les recréer…
### Vérifier la configuration avec _drbdadm verify_ ?
Attention `drbdadm verify` ne vérifie pas la configuration mais une vérification à chaud des volumes… à ne pas lancer à la légère en production !
### Erreur Failure: (127) Device minor not allocated
Si l'on obtient une erreur du type :
~~~
42: Failure: (127) Device minor not allocated
additional info from kernel:
unknown minor
Command 'drbdsetup-84 verify 42' terminated with exit code 10
~~~
il faut créer le périphérique avec `drbdsetup new-minor` …ou plus simple avec `drbdadm adjust`.
### Peut-on avoir plusieurs serveurs ?
Une ressource DRBD doit être définie entre deux serveurs, mais rien n'enpêche d'avoir d'autres resssources liées à différents serveurs.
Si l'on veut répliquer une ressource avec un troisième serveur, [une solution est d'empiler deux réplications DRBD](https://www.drbd.org/en/doc/users-guide-84/s-three-way-repl)
### états différents pour les volumes d'une ressource
Les volumes d'une même ressource sont-ils forcément dans le même état primary/secondary ?
Contrairement à ce que l'on pourrait penser, on peut très bien ajuster des volumes d'une même ressource dans des états différents :
~~~
tic# drbdsetup primary 43
tic# drbdsetup secondary 44
tac# drbdsetup secondary 43
tac# drbdsetup primary 44
# drbd-overview
43:foo/0 Connected Primary/Secondary UpToDate/UpToDate
44:foo/1 Connected Secondary/Primary UpToDate/UpToDate
~~~
> *Note* : cela nécessite d'utiliser le protocole C et d'avoir configuré `allow-two-primaries;`
### Réplication truck-base
Plus fort que l'[IPoAC](https://fr.wikipedia.org/wiki/IP_over_Avian_Carriers), DRBD propose la [réplication truck-based](https://www.drbd.org/en/doc/users-guide-84/s-truck-based-replication)