[INFORMATION] DRBD (Raid1 Over IP)

TibO · #1 20/08/2008, 15h57

Re iop,

Dans la suite des chantiers, parlons de DRBD :)
Ceci est aussi un C/C d'une doc perso, donc ça parle d'ubuntu dapper 6.06, mais vous pourriez avoir des versions plus récentes :)

DRBD :

Présentation et Intérêt

DRBD est un outil qui permet de faire de la synchronisation de données sur le réseau (RAID1 over TCP/IP). L'utilisation ici va être de synchroniser le volume où les données de votre service seront installées pour pouvoir avoir des données synchronisées en cas de bascule.
Dans la pratique, seule une machine du noeud peut accéder aux données, les autres y ayant accès en lecture seule si besoin.
Dès qu'une modif est faite sur les données, tout est immédiatement synchronisé entre les noeuds. On a donc besoin de 2 noeuds minimum, et de disques de la meme taille de préférence :)

Explication et mise en place

De la même façon qu'avec Heartbeat, la version de DRBD fournie avec Dapper n'est que la version 7 (0.7). Au vu des fonctionnalités disponibles avec la version 8, nous avons décidé de le recompiler.

Installation

Le package tgz d'installation peut être trouvé sur le site : http://oss.linbit.com/drbd/ La version la plus à jour à la rédaction de ce document est la version 8.2.6.
L'installation se fait de la façon simple en suivant le fichier INSTALL à la racine du tgz. L'installation est à réaliser dans le dossier /usr/src/.
Recompilation classique ici (cf fichier INSTALL, configure, make build, ...)

Configuration

la configuration se fait dans le fichier /etc/drbd.conf
un man drbd.conf et le fichier drbd.conf généré par défaut contiennent plein d'explications sur l'utilisation du fichier.
Voici les informations ressorties du fichier utilisé dans notre cas :

Code:

global {
    usage-count yes;
}
common {
  syncer { rate 700000K; } #Vitesse du transfert max
  handlers {
        outdate-peer "/usr/lib/heartbeat/drbd-peer-outdater";
        }
}
resource r0 { # Nom de la ressource
  protocol C;
  handlers {
    pri-on-incon-degr "echo o > /proc/sysrq-trigger ; halt -f";
    pri-lost-after-sb "echo o > /proc/sysrq-trigger ; halt -f";
    local-io-error "echo o > /proc/sysrq-trigger ; halt -f";
    outdate-peer "/usr/lib/heartbeat/drbd-peer-outdater -t 5";
  }
  startup {
    wfc-timeout  60; # Timeout d'attente de l'autre noeud sur lancement du démon
    degr-wfc-timeout 120;    # 2 minutes.
  }
  disk {
    on-io-error  detach;
     fencing resource-only;
  }
  net {
    after-sb-0pri disconnect;
    after-sb-1pri disconnect;
    after-sb-2pri disconnect;
    rr-conflict disconnect;
  }
  syncer {
    rate 700000K;
    al-extents 257;
  }
  on noeud1.domaine.com{
    device     /dev/drbd0;
    disk       /dev/sdb;
    address    10.10.10.5:7788;
    flexible-meta-disk  internal;
  }
  on noeud2.domaine.com {
    device    /dev/drbd0;
    disk      /dev/sdb;
    address   10.10.10.4:7788;
    meta-disk internal;
  }
}

Utilisation

Il faut que les fichiers /etc/drbd.conf soient les memes sur les 2 noeuds. Ensuite, on utilisera les commandes drbdsetup / drbdadm pour manipuler les resources.
Il faut commencer par initialiser les resources, avec un drbdsetup create-md r0 et un drbdsetup create-resource r0 (dépend de votre version drbd), ensuite un drbdadm adjust all.
taper les commandes drbdadm et drbdsetup permet d'avoir les différentes options accessibles facilement.

Agrandissement de la partition

Le contexte devient le suivant :
Les machines Hôtes Xen0 (les Dom-0) contiennent des LV (logical volumes) qu'on va pouvoir agrandir à la volée. Ces logical volumes sont montés dans Xen comme des disques (sdb dans notre situation) DRBD supportant le resize, il suffira de taper qqes commandes en cas de resize des LV :
drbdadm create-md $ressource permettra de recréer les inodes virtuels du volume DRBD
ATTENTION : bien penser à le faire sur un volume à la fois, puisque cette manipulation rend le disque “Inconsistent” et donc nécessite une synchronisation des données.

Split Brain

Si jamais on se retrouve avec les 2 machines en état
Secondary / Unknown Voici ce qu'il faut faire :
sur le second noeud :

Code:

drbdadm invalidate r0 (nécessitera peut être un drbdadm down r0)

sur les 2 noeuds :

Code:

   drbdadm adjust all

khamlon · #2 20/08/2008, 16h54

c'est quand même plus facile avec un Home Server.. et plus jolie que des lignes de commande :)

TibO · #3 20/08/2008, 18h02

question de point de vue j'imagine :-)

Pilo · #4 21/08/2008, 07h41

Intéressant quand même, ça semble être une alternative à la réplication DFS de Microsoft que j'avais décrite dans cet article là : http://www.admincafe.re/forums/showthread.php?t=53

Mais dis moi, pour continuer à faire le parallèle, j'aimerais savoir si avec DRBD on peut manager un peu plus finement la réplication...
Y a-t-il un principe de MASTER/SLAVE pour avoir autorité sur les dernières modifications des données ?

Quand tu dis :

Citation:

Dans la pratique, seule une machine du noeud peut accéder aux données, les autres y ayant accès en lecture seule si besoin.

Cela veut dire que les données stockées sur les autres noeuds sont juste une "sauvegarde" ?

Et tu n'as pas vraiment abordé le contexte client/serveur... Je suis un client dans un réseau ou 3 machines sont des noeuds DRDB, comment savoir ou accéder aux données ? enfin la seule machine non lecture-seule quoi... est ce qu'il y a une bascule automatique ? (une implémentation Linux HA par dessus ? )

Et un dernier point... si j'ai deux noeuds DRBD dans un LAN, et un troisième distant par liaison lente, genre LS 1Mb/s ou autre... quid de la réplication de 3Go de données ? on peut monitorer la BP ? (soit par DRBD et sa config, soit par un autre outil a mettre en place en amont des serveurs pour cette réplication ?!)

TibO · #5 21/08/2008, 15h05

Citation:

Envoyé par Pilo

Intéressant quand même, ça semble être une alternative à la réplication DFS de Microsoft que j'avais décrite dans cet article là : http://www.admincafe.re/forums/showthread.php?t=53

Mais dis moi, pour continuer à faire le parallèle, j'aimerais savoir si avec DRDB on peut manager un peu plus finement la réplication...
Y a-t-il un principe de MASTER/SLAVE pour avoir autorité sur les dernières modifications des données ?

Quand tu dis : Cela veut dire que les données stockées sur les autres noeuds sont juste une "sauvegarde" ?

Ca veut dire que c'est juste comme 2 disques en RAID 1. Dans la réalité, un seul est l'accessible, et l'autre est une copie conforme.

Citation:

Et tu n'as pas vraiment abordé le contexte client/serveur... Je suis un client dans un réseau ou 3 machines sont des noeuds DRDB, comment savoir ou accéder aux données ? enfin la seule machine non lecture-seule quoi... est ce qu'il y a une bascule automatique ? (une implémentation Linux HA par dessus ? )

Le contexte client serveur est en effet bien évidemment à souligner. Dans le principe, si tu as, disons 3 noeuds, en réseau, il faut pouvoir manipuler les données et les rendre disponibles.
Linux HA est très souvent utilisé en complément, à qui tu demandes de gérer les ressources de la manière suivante :
1) Démarrer la resource DRBD en primary
2) Monter le filesystem
3) Monter une IP de service
4) Partager le filesystem (en samba par exemple)

De cette façon, tous tes clients pourront accéder à tes données en faisant \\IPdeservice\Partage, quel que soit le serveur sur lequel se trouve le Linux HA Actif et quel que soit le serveur avec le DRBD Primary.

Citation:

Et un dernier point... si j'ai deux noeuds DRDB dans un LAN, et un troisième distant par liaison lente, genre LS 1Mb/s ou autre... quid de la réplication de 3Go de données ? on peut monitorer la BP ? (soit par DRDB et sa config, soit par un autre outil a mettre en place en amont des serveurs pour cette réplication ?!)

Pour la réplication, le truc est galère si la liaison est lente. tu peux changer la valeur de liaison avec la variable "syncer" dans le fichier de conf (cf post initial), et après le disque se met en Inconsistent si non synchronisé, donc non disponible d'un point de vue ressource. L'avantage est que le Linux HA ne basculera pas si le DRBD l'envoie chier sur la machine cible et cherchera un autre hote pour sa bascule

Pilo · #6 21/08/2008, 15h14

Merci bcp pour les éclaircissements !

Un peu HS par rapport à ce topic, mais bon si t'as des infos pour la synchro client/serveur (l'équivalent des dossiers en mode hors connexion chez Microsoft) sous *nix/*nux ça m'intéresse aussi, juste à titre d'information...

TibO · #7 21/08/2008, 15h39

tu veux dire du genre rsync (je te laisse googleiser si ça ne te dit rien) ? ou un truc qui synchro quand tu vas te logouter ?

Pilo · #8 21/08/2008, 15h45

Rsync je connais oui.

Mais un truc moins roots, ou par exemple un poste client a tous ses dossiers utilisateurs en synchro sur le serveur, et ce de façon transparente (comme une redirection de dossiers avec une GPO Active Directory sous Microsoft, dans un domaine)

Le user se log, il a acces a ses fichiers en local sur son poste, qd des modifs sont faites ça synchro sur le serveur, le serveur tombe (ou la liaison réseau) --> le client peut toujours travailler et resynchronisera qd tout reviens dans l'ordre.

ce genre de choses quoi...

TibO · #9 21/08/2008, 18h14

alors jusqu'à la partie hors ligne j'aurais dit NFS avec automontage, mais pour l'histoire des dossiers hors ligne, me suis jamais posé la question, v essayer de voir :)

Discussions similaires
Discussion	Auteur	Forum	Réponses	Dernier message
[INFORMATION] Heartbeat (clustering)	TibO	Administration des distributions nix et nux	5	01/12/2009 21h01

Utilisateurs regardant la discussion actuelle : 1 (0 membre(s) et 1 invité(s))

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email