From 262ccb24235ff6d388820b8d36d943e2798bb69b Mon Sep 17 00:00:00 2001 From: gcolpart Date: Tue, 24 Jan 2017 05:34:37 +0100 Subject: [PATCH] ajout / relecture --- HowtoDRBD.md | 68 +++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 60 insertions(+), 8 deletions(-) diff --git a/HowtoDRBD.md b/HowtoDRBD.md index 4d918866..fbcef3e4 100644 --- a/HowtoDRBD.md +++ b/HowtoDRBD.md @@ -4,7 +4,6 @@ title: Howto DRBD ... * Documentation : -* 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 -# drbdadm secondary +# drbdadm primary +# drbdadm secondary ~~~ > *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 +~~~ + +> *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 +# drbdadm connect +~~~ + ### 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 # drbdadm invalidate # drbdadm disconnect -# drbdadm connect +# drbdadm -- --discard-my-data connect ~~~ 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 +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. +~~~