18
0
Fork 0

ajout / relecture

This commit is contained in:
gcolpart 2017-01-24 05:34:37 +01:00
parent 1dab9234c9
commit 262ccb2423
1 changed files with 60 additions and 8 deletions

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.
~~~