Browse Source

ajout / relecture

master
gcolpart 3 years ago
parent
commit
262ccb2423
1 changed files with 60 additions and 8 deletions
  1. +60
    -8
      HowtoDRBD.md

+ 60
- 8
HowtoDRBD.md View File

@@ -4,7 +4,6 @@ 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 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_.

@@ -416,15 +415,34 @@ On peut ensuite supprimer le fichier de conf associé et s'assurer que c'est pri

### Passer une ressource en primary/secondary

Pour passer une ressource en primary ou secondary :
Pour passer une ressource (ou toutes les ressources) en primary ou secondary :

~~~
# drbdadm primary <ressource>
# drbdadm secondary <ressource>
# drbdadm primary <ressource/all>
# drbdadm secondary <ressource/all>
~~~

> *Note* : pour passer en _primary_ il faut s'assurer d'utiliser le protocole C et d'avoir configuré `allow-two-primaries;`

### Invalider une ressource

Sur le serveur à invalider, on provoque la réception immédiate des volumes via :

~~~
# drbdadm invalidate <ressource>
~~~

> *Note* : on peut aussi utiliser `drbdadm invalidate-remote` depuis le serveur « maître »

### Déconnecter/connecter une ressource

Pour des raisons de maintenance, on peut déconnecter une ressource (ou toutes les ressources) :

~~~
# drbdadm disconnect <ressource/all>
# drbdadm connect <ressource/all>
~~~

### 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** :
@@ -433,6 +451,13 @@ Bien qu'il n'y ait pas de démon pour DRBD, il y a une unité [systemd](HowtoSys
* `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`

### DRBD et les filesystem

DRBD réalise une réplication au niveau bloc, il ne tient donc absolument pas compte du filesystem :

* si l'on utilise un filesystem classique (ext4, brtfs etc.) il faut faire attention à ne jamais monter le filesystem à deux endroits à la fois
* si l'on veut lire/écrire les données d'une ressource DRBD depuis les deux serveurs, il faut utiliser un filesystem réseau comme [OCFS2](HowtoOCFS2) ou _GFS2_


## Plomberie

@@ -478,7 +503,7 @@ meta-data: need apply-al

### À propos des protocoles

DRBD dispose de 3 protocoles de réplication/synchronisation, A, B et C.
Il est important de bien comprendre les 3 protocoles de réplication/synchronisation :

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.

@@ -486,10 +511,15 @@ B : Réplication synchronisé en mémoire. Les écritures sur le disque local du

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é.
Le protocole C est donc le plus sécurisé mais ayant le plus d'impact sur les performances, le protocole A a les meilleures performances (comparables aux performances des disques locaux… si les buffers de réplication ne sont pas saturés) et le protocole B est un compromis entre les deux : il n'est ni sécurisé ni performant.

### Bien comprendre /proc/drbd

* `cs` : Connection State (Connected/WFConnection/Unconnected/StandAlone/PausedSync)
* `ro` : Resources roles (Primary/Secondary/Unknow)
* `ds` : Disk States (UpToDate/Inconsistent/DUnknown)
* `A/B/C` : Protocol

~~~
42: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r-----
~~~
@@ -608,7 +638,7 @@ Sur le serveur en _Standalone_ qu'on veut réinitialiser :
# drbdadm secondary <ressource>
# drbdadm invalidate <ressource>
# drbdadm disconnect <ressource>
# drbdadm connect <ressource>
# drbdadm -- --discard-my-data connect <ressource>
~~~

Sur le serveur primaire où sont les données choisies comme valides :
@@ -667,6 +697,28 @@ tac# drbdsetup primary 44

> *Note* : cela nécessite d'utiliser le protocole C et d'avoir configuré `allow-two-primaries;`

### Réplication sans synchronisation de données initiales

Une fois les nœuds connectés, au lieu de faire `--overwrite-data-of-peer` sur l'un des serveurs :

~~~
tic# drbdadm -- --clear-bitmap new-current-uuid foo
tic# drbdadm primary foo
~~~

### 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)
Plus fort que l'[IPoAC](https://fr.wikipedia.org/wiki/IP_over_Avian_Carriers), DRBD décrit la [réplication truck-based](https://www.drbd.org/en/doc/users-guide-84/s-truck-based-replication)

### Détruire les _metadatas_

Pour détruire les _metadatas_ des volumes d'une ressources (dangereux) :

~~~
# drbdadm wipe-md <ressource>
Do you really want to wipe out the DRBD meta data?
[need to type 'yes' to confirm] yes

Wiping meta data...
DRBD meta data block successfully wiped out.
~~~

Loading…
Cancel
Save