RAID-1 over IP avec DRBD

A l'heure où les serveurs d'entreprises doivent stocker un volume croissant de données et assurer une haute disponibilité, il est nécessaire d'imaginer des systèmes de mirroring (miroir) autres que simplement sur des disques durs.

La redondance de disques durs (RAID-1, RAID-5) permet déjà d'avoir une bonne résistance aux pannes d'un disque (ou plusieurs si on est en RAID-5). Cependant, si c'est la machine qui tombe (le processeur, l'alimentation, le contrôleur de disque,…), on n'a aucun moyen pour relancer le tout rapidement sans perte de données.

Ayant été confronté à cette problématique, j'ai envisagé une solution de RAID-1 au travers du réseau. C'est-à-dire que sur deux serveurs, on a deux partitions (une par serveur) qui sont à tout moment une copie exacte l'une de l'autre. C'est un mirroring (miroir) de partitions à travers une interface réseau.

Pour pouvoir avoir cette sorte de mirroring, on pourrait utiliser une solution rsync en effectuant les synchronisations dans un intervalle de temps relativement court. Cependant, cette solution n'est pas utilisable dans mon cas.

Les limitations d'une telle solution sont évidentes : même en synchronisant les serveurs toutes les 2 minutes, nous risquons de perdre des données modifiées durant cette intervalle de temps. Ce type de solution conviendrait pour des données ne changeant pas trop fréquemment mais pas pour un serveur de production.

Pour utiliser le principe de synchronisation des données avec un fonctionnement quasi instantané, nous devons descendre au niveau des périphériques en mode bloc avec DRBD.

DRBD est un module pour le kernel implémentant un périphérique en mode bloc qui en plus d'écrire l'information sur le disque physique de la machine, la transmet à son homologue miroir qui se trouve sur l'autre (ou les autres serveurs).

• DRBD ne se soucie pas du système de fichier, son job consiste seulement à répliquer les blocs. La seule dépendance au niveau du système de fichier est que DRBD soit compatible avec ce dernier (avec l'ext3, pas de problème).

• DRBD permet le mirroring, c'est différent du partage. Cette notion implique qu'il existe un périphérique maître/primaire dont les données sont répliquées sur un ou des périphériques esclave/secondaire.

• ATTENTION : Vous ne pouvez pas monter le système de fichiers du périphérique esclave. Le montage en lecture/écriture est totalement interdit à moins de changer les rôles maître/esclave.

• Tout comme le RAID-1, DRBD assure une cohérence des données au niveau du périphérique. C'est à charge du système de fichiers de s'assurer, conserver et retrouver l'intégrité des données au niveau des fichiers. De même que c'est à charge des applications de retrouver un état cohérent si un problème survient.

• En gros, DRBD est aux serveurs ce que le RAID-1 est au disque locaux. Ne comptez pas uniquement sur DRBD pour maintenir toute l'intégrité de vos données !!!

Ce tutoriel a été écrit pour des personnes ayant des notions d'administration de serveurs; si vous êtes débutants, c'est à vos risques et périls. Si vous faites une fausse manoeuvre, les partitions seront mirrorés et écrasées. Ne l'oubliez pas !

Pour les débutants, je vous conseille une solution s'appuyant sur rsync; cette solution est plus simple et moins risquée à mettre en oeuvre.

La configuration de tests se compose de deux machines modestes ; twin1 et twin2.

• Maître / Primaire
• Pentium 3 - 500 MHz - 128Mo RAM
• Installation neuve de Hoary en mode minimaliste (option : server au boot du CD)
• Mise à niveau de l'image vers 2.6.10-5-686 (au lieu de 386)
• IP : 192.168.252.200
• Hostname : twin1
• Disque de 13.5Go partagé en 5 partitions (/ de 4.5Go, /srv/prod de 3Go, /srv/intern de 3Go, /srv/other de 2Go et swap de 1Go)
• Partition à mirrorer : /srv/prod de 3Go disposée en /dev/hda2.

• Esclave / Secondaire
• Pentium 3 - 700 MHz - 128Mo RAM
• Installation neuve de Hoary en mode minimaliste (option : server au boot du CD)
• Mise à niveau de l'image vers 2.6.10-5-686 (au lieu de 386)
• IP : 192.168.252.201
• Hostname : twin2
• Disque de 10Go partagé en 4 partitions (/ de 3Go, /srv/prod de 3Go, /srv/intern de 3Go et swap de 1Go)
• Partition à mirrorer : /srv/prod de 3Go disposée en /dev/hda2.

Sur les deux machines, voici ce qui a été fait.

Remarque : Cette installation a également été effectuée sur deux serveurs HP Proliant DL380 avec la version Breezy 5.10 de Ubuntu. Les sections suivantes sont annotées en conséquence pour l'installation de DRBD sous Breezy.

• Installation en mode server à partir du CD d'installation x86 Hoary 5.04 (ou x86 Breezy 5.10) et configuration réseau manuelle.
• Mise à jour de quelques paquets basiques via Internet.

sudo apt-get update
sudo apt-get upgrade

• Mise à niveau du kernel pour profiter du Pentium 3 (pas nécessaire mais faite attention à la version lorsque vous suivrez le tutoriel). Après la mise à niveau, un petit redémarrage pour prendre en compte le nouveau kernel. (Sous Breezy, j'ai utilisé le noyau 2.6.12-9-686-smp)

sudo apt-get install linux-image-2.6.10-5-686
sudo reboot

• Remarque importante : Vous avez sans doute remarqué que je n'utilise pas la technique décrite dans la page traitant de l'installation des noyaux optimisés. C'est du au fait que nous devons compiler le module DRBD afin de le lier au noyau. Etant donné que l'installation des paquets du type linux-image-686 provoque la mise à jour du noyau dès qu'un nouveau est disponible, il nous faudrait recompiler le module DRBD à chaque mise à jour du noyau (idéalement). Vous trouverez de plus amples informations sur les modules dans les systèmes Linux sur cette page.

• Activation des paquets universe en éditant /etc/apt/sources.list :

sudo vi /etc/apt/sources.list

• en décommentant les lignes suivantes (Remarque : sous Breezy, ces lignes sont très similaires et vous saurez certainement les reconnaître) :

deb http://be.archive.ubuntu.com/ubuntu hoary universe
deb-src http://be.archive.ubuntu.com/ubuntu hoary universe
deb http://security.ubuntu.com/ubuntu hoary-security universe
deb-src http://security.ubuntu.com/ubuntu hoary-security universe

• Suivi d'une update de la liste des paquets :

sudo apt-get update

Voilà une configuration propre à partir de laquelle nous allons configurer le mirroring.

Le module n'est pas disponible en paquet tout prêt à être installé car celui-ci dépend de la version de votre kernel. Les opérations qui suiveent doivent être effectuées sur les deux machines (à moins d'avoir deux machines parfaitement identiques, dans ce cas, il suffit de copier le fichier .deb et de l'installer sur le second serveur).

Afin de pouvoir compiler le module, nous avons besoin des headers du kernel ainsi que certains utilitaires de construction :

sudo apt-get install linux-headers-$(uname -r) build-essential

Ensuite, nous récupérons les paquets drbd nécessaires, ainsi que leurs dépendances. Le paquet drbd0.7-utils contient les utilitaires de configuration. Le paquet drbd0.7-module-source contient les sources du module qui nous intéresse.

sudo apt-get install drbd0.7-utils drbd0.7-module-source

Avant de continuer, nous avons besoin de quelques paquets pour configurer le noyau et pouvoir appeler le menuconfig du kernel :

sudo apt-get install dpkg-dev kernel-package ncurses-dev

Maintenant, on peux passer aux choses sérieuses et compiler le module. On commence par décompresser l'archive source du module :

cd /usr/src
sudo tar xfzv drbd0.7-tar.gz

Pour Breezy, avant de continuer, il est nécessaire d'installer le paquet contenant la version 3.4 de GCC. En effet, Breezy est fournit par défaut avec la version 4.0. Pour installer la version 3.4 de GCC, entrez la commande suivante :

sudo apt-get install gcc-3.4

Ensuite, on sauve la configuration du kernel pour faire une reconstruction des modules (sous Breezy, vous devez vous placer dans le répertoire de votre noyau, à savoir : /usr/src/linux-headers-2.6.12-9-686-smp) :

cd /usr/src/linux-headers-2.6.10-5-686
sudo make menuconfig

Dans le menuconfig, faites directement exit et sauver la configuration (bouton yes). Après ça, on compile le module et on l'ajoute au noyau courant (pour Breezy, on fait un –append-to-version -9-686-smp).

sudo make-kpkg modules-image --append-to-version -5-686

Note A : Si vous rencontrez un problème à cette étape, il se peut que vous ayez déjà effectué une commande de ce type. Il faut donc "nettoyer" le répertoire en exécutant la commande suivante :

sudo make-kpkg clean

Puis recommencez la commande précédente.

Note B : Il arrive que l'utilisation de l'option –append-to-version provoque la double concaténation du numéro de version, ce qui va poser un problème au moment de l'ajout du module (voir note plus bas à propos du chargement du module avec modprobe). Dans ce cas, ne pas utiliser cette option, le module sera compilé pour le noyau courant. Tapez donc seulement :

sudo make-kpkg modules-image

Un certain temps peut s'écouler suivant la puissance de votre machine. Après cet attente, un paquet .deb est disponible dans /usr/src. Pour installer le nouveau paquet fraîchement construit :

cd /usr/src
sudo dpkg --install drbd0.7-module-2.6.10-5-686_0.7.7-1+10.00.Custom_i386.deb

Le module est maintenant installé, il ne reste plus qu'à le charger :

sudo modprobe drbd

Si la commande échoue (FATAL: Module drbd not found.), le module a sans doute été généré dans un autre répertoire que celui des modules noyau actuellement utilisés. Positionnez-vous dans le répertoire /lib/modules pour visualiser les différents noyaux. Dans le cas de cette erreur, un nouveau répertoire a été créé, avec un nom comme par exemple 2.6.15-28-386-28-386 au lieu de 2.6.15-28-386. Le module compilé de drbd se retrouve alors en dehors du répertoire du noyau courant, d'où l'impossibilité de charger le module. Pour y remédier, reportez-vous aux Notes A et B précédentes.

Vous pouvez vérifier si le module a bien été chargé en tapant la commande suivante :

lsmod | grep drbd 

Cette section comprend les informations pour mettre en route votre système de RAID-1 over IP. Cette procédure est très manuelle et veuillez noter que le mirroring ne sera plus actif une fois que vous aurez redémarré les machines.

Si vous redémarrez les machines (ou seulement une des deux), il vous faudra introduire à nouveau la suite des commandes de configuration.

Dans la suite de ce document, vous trouverez une technique pour mettre en place le mirroring de manière définitive sur les machines (voir section Configuration définitive).

A tout moment, vous pouvez avoir des informations concernant le statut de drbd en tapant :

cat /proc/drbd

Tout d'abord, il faut faire attention au fait que la partition est montée sur le système de fichier. Afin d'éviter des désagréments par la suite, voici la procédure pour démonter la partition. Pour ne pas avoir le remontage au redémarrage de la machine, nous allons commenter la ligne correspondant à la partition dans /etc/fstab.

sudo vi /etc/fstab

et dans ce fichier, on commente la ligne :

#/dev/hda2       /srv/prod       ext3    defaults        0       2

Ensuite, il ne faut pas oublier de la démonter de la session en cours :

sudo umount /dev/hda2

Pour vérifier si la partition a bien été démontée, il suffit de taper la commande :

mount

La partition /dev/hda2 ne doit plus s'y trouver.

Nous pouvons maintenant préparer le périphérique de mirroring via la commande suivante :

sudo drbdsetup /dev/drbd0 disk /dev/hda2 internal -1

Cette commande attache le périphérique de mirroring /dev/drbd0 au disque physique /dev/hda2 en gardant les informations concernant le mirroring en interne (internal). Le code -1 est le code imposé quand on utilise internal.

Maintenant, nous devons indiquer à drbd l'hôte auquel il doit se connecter pour le mirroring. Pour ce faire, on entre la commande suivante :

sudo drbdsetup /dev/drbd0 net 192.168.252.201 192.168.252.200 B

Cette commande indique que l'on travaille sur le périphérique de mirroring /dev/drbd0 et que l'on fait une connexion réseau entre 192.168.252.201 (l'esclave Twin 2) et 192.168.252.200 (le maître Twin 1). La lettre qui ponctue la commande de configuration indique le protocole.

• A : signifie qu'une opération d'écriture est terminée lorsque les données sont inscrites sur le disque local et envoyées sur le réseau.
• B : signifie qu'une opération d'écriture est terminée lorsque les données sont inscrites sur le disque local et l'accusé de réception de l'hôte distant arrive.
• C : signifie qu'une opération d'écriture est terminée lorsque les données sont inscrites sur le disque local et la confirmation d'écriture sur le disque distant est réceptionnée.

Théoriquement, les délais augmentent proportionellement au niveau de garantie du protocole utilisé. A titre d'exemple, j'ai fait des tests de transferts d'une masse importante de fichiers (+/- 800 Mo) à plusieurs reprises et avec des protocoles différents; voici les résultats obtenus sur les machines Twin 1 et Twin 2 (décrites dans le préambule de cet article) avec les pourcentages de délais supplémentaires :

On remarque que quelque soit le protocole utilisé (B ou C), les délais supplémentaires introduits sont de maximum 5% par rapport à une copie d'une partition locale vers une autre partition locale non mirrorée.

Pour information, la syntaxe de configuration du réseau pour drbd est la suivante :

• sudo drbdsetup peripherique_drbd net ip_local[:port_local] ip_distante[:port_distant] protocole

Par défaut, le port d'utilisation est le 7788.

Par précaution, nous allons démonter également la partition mirrorée avant de mettre les mains dans le cambouis. Sur Twin 1, la partition est également en /dev/hda2. La procédure de démontage des partitions est identique au début de l'étape 1.

Après cela, nous devons préparer le périphérique de mirroring en attachant ce périphérique à la partition physique /dev/hda2 via la commande suivante :

sudo drbdsetup /dev/drbd0 disk /dev/hda2 internal -1

Ensuite, nous devons établir le lien réseau entre les deux serveurs :

sudo drbdsetup /dev/drbd0 net 192.168.252.200 192.168.252.201 B

Nous pouvons voir dans la log que la connexion est bien établie (ligne drbd : Connection established) en faisant :

tail /var/log/messages | grep drbd

Il ne nous reste plus qu'à indiquer que Twin 1 est le maître :

sudo drbdsetup /dev/drbd0 primary --do-what-I-say

Remarque importante : L'option –do-what-I-say force la commande. Cette sécurité est mise en place pour éviter que vous écrasiez les partitions des esclaves. Car une fois la commande entrée, le maître va mettre à jour les esclaves et les partitions locales des esclaves seront écrasées. Cette option est à utiliser la première fois mais plus par la suite !!! Pour les autres mises en place de cette manière, vous devrez utiliser une commande de ce type pour la déclaration du primary : sudo drbdsetup /dev/drbd0 primary.

Il ne nous reste plus qu'à créer un système de fichier sur ce nouveau périphérique mirroré :

sudo mkfs.ext3 /dev/drbd0

Maintenant, les changements seront répercutés pendant un long (très long) moment. A titre d'information, la construction de la partition de 3Go sur les machines de tests a duré 3h30 (tablez donc sur 1Go / 1h). Cependant, cette durée de construction initiale est beaucoup plus rapide si on n'impose pas de limite de transfert. Par défaut, les transferts de drbd sont limités à 250K/s. Voyez la section Configuration additionelle pour savoir comment augmenter cette limite.

Durant cette construction, vous pouvez voir que la construction se déroule en faisant cat /proc/drbd. Sur Twin 1 (le maître), cela nous donne :

version: 0.7.7 (api:77/proto:74)
SVN Revision: 1680 build by phil@wiesel, 2004-12-14 16:05:39
 0: cs:SyncSource st:Primary/Secondary ld:Consistent

    ns:2081560 nr:0 dw:44172 dr:2037440 al:23 bm:296 lo:0 pe:0 ua:0 ap:0
        [==============>.....] sync'ed: 72.9% (764820/2802208)K
        finish: 0:42:29 speed: 248 (236) K/sec
 1: cs:Unconfigured

Sur Twin 2 (l'esclave) :

version: 0.7.7 (api:77/proto:74)
SVN Revision: 1680 build by phil@wiesel, 2004-12-14 16:05:39
 0: cs:SyncSource st:Secondary/Primary ld:Inconsistent
    ns:2081560 nr:0 dw:44172 dr:2037440 al:23 bm:296 lo:0 pe:0 ua:0 ap:0
        [==============>.....] sync'ed: 72.9% (764820/2802208)K
        finish: 0:42:29 speed: 248 (236) K/sec
 1: cs:Unconfigured

Remarquez que le maître est dans un état consistant et l'esclave en état inconsistant. C'est parfaitement normal. Une fois la construction terminée, les deux seront en état consistant et vous pourrez passer à l'étape suivante.

Pour utiliser le périphérique mirroré, il nous suffit de le monter sur le point de montage où était la partition avant l'installation des périphériques drbd :

sudo mount /dev/drbd0 /srv/prod

Maintenant, dès que l'on fait quelque chose dans le répertoire /srv/prod, c'est répercuté en temps réel sur Twin 2 (l'esclave).

Comme je vous l'ai signalé en début d'article, on ne peut pas monter le périphérique directement sur l'esclave (Twin 2). Cependant, que faire en cas de panne de Twin 1 (vu que c'est ça le but de l'article).

Nous devons tout d'abord couper la connexion du côté de Twin 1 afin d'éviter les conflits avec Twin 2. Si la machine Twin 1 est éteinte ou déconnectée physiquement du réseau, ces commandes ne sont pas nécessaires. Néanmoins, en cas de redémarrage de Twin 1, il ne faut pas qu'il reprenne le contrôle ! Si c'était le cas, le système de fichiers pourraient devenir inconsistant. Afin d'éviter ce désagrément, déconnectez physiquement Twin 1 du réseau et désactivez le lien drbd avant de la reconnecter.

Pour couper la connexion miroir de Twin 1, nous entrons les commandes suivantes (sur Twin 1 bien entendu) :

sudo umount /srv/prod
sudo drbdsetup /dev/drbd0 secondary

Nous pouvons alors déconnecter également la liaison miroir de Twin 2 et monter le système de fichier afin de pouvoir travailler sur ce dernier. Nous effectuons cela en introduisant les commandes suivantes (sur Twin 2) :

sudo drbdsetup /dev/drbd0 primary
sudo mount /dev/drbd0 /srv/prod

Nous avons donc basculé le système de fichiers sur Twin 2 et maintenant dès qu'un changement est appliqué sur Twin 2, il est répercuté sur Twin 1 (pour peu que celui-ci soit connecté). Si Twin 1 était déconnecté et qu'il y a eu des changements sur Twin 2, les changements seront répercutés par une reconstruction une fois que Twin 1 se reconnectera (en tant qu'esclave).

Nous pouvons faire quelques essais avant d'appliquer la procédure de retour à la normale. Par exemple, copions quelques fichiers tests et supprimons un répertoire ou l'autre.

Une fois le maître reconnecté (en tant qu'esclave dans un premier temps), Twin 2 va reconstruire le système de fichier de Twin 1. C'est ce qu'on appelle la synchronisation après panne. Cette synchronisation peut durer plus ou moins longtemps suivant la quantité de données modifiées durant la panne.

Pour savoir où en est la synchronisation après panne, vous pouvez examiner /proc/drbd.

Une fois la synchronisation terminée, on peut retourner à la normale en basculant le système de fichier sur Twin 1.

Nous commençons par remettre Twin 2 en tant qu'esclave en entrant les commandes suivantes (sur Twin 2) :

sudo umount /srv/prod
sudo drbdsetup /dev/drbd0 secondary

Et on rebascule avec Twin 1 comme maître en entrant les commandes suivantes (sur Twin 1) :

sudo drbdsetup /dev/drbd0 primary
sudo mount /dev/drbd0 /srv/prod

Tout est redevenu comme avant et on a perdu aucune données malgré la panne (simulée) de Twin 1.

La configuration telle qu'elle a été établie ci-dessus est très bien pour faire des essais mais est très lourde pour une utilisation courante. En effet, la configuration du miroir est oubliée dès l'arrêt des machines.

Pour éviter ce désagrément, et surtout, maintenant que nous avons testé notre système et que tout fonctionne, voyons comment appliquer cette configuration de manière définitive.

Lors de l'installation de drbd0.7-utils, un script d'Init System V a été installé en même temps. Ce script se situe dans /etc/init.d/drbd et accepte les commandes suivantes :

• start : démarre la connexion miroir
• stop : arrête la connexion miroir
• status : donne les informations concernant les connexions miroirs (équivaut à cat /proc/drbd)
• reload : recharge la configuration (la configuration se trouve dans /etc/drbd.conf)
• restart : redémarre la connexion miroir
• force-reload : force le rechargement de la configuration

Avant de pouvoir utiliser ces commandes (/etc/init.d/drbd commande), nous devons indiquer au script la configuration de nos serveurs miroirs. Pour ce faire, nous allons éditer le fichier /etc/drbd.conf via la commande suivante :

sudo vi /etc/drbd.conf

On crée un fichier de configuration commun aux deux serveurs :

resource drbd0 {
    protocol B;
    incon-degr-cmd "halt -f";

    on twin1 {
       device     /dev/drbd0;
       disk       /dev/hda2;
       address    192.168.252.200:7789;
       meta-disk  internal;
    }

    on twin2 {
       device     /dev/drbd0;
       disk       /dev/hda2;
       address    192.168.252.201:7789;
       meta-disk  internal;
    }

    syncer {
       rate       2048;
    }
}

Ce fichier reprend les paramètres que nous avons utilisés lors de nos précédents essais. A la différence que nous définissons un limite de vitesse à 2048 K/s au lieu des 250 K/s par défaut.

Notez que le fichier est le même sur les deux machines et que le nom d'hôte (nom de machine) indiqué doit correspondre au nom retourné par la commande uname -n.

Avant de lancer le script d'Init, assurez vous que tous les liens miroirs sont désactivés et que le système de fichier est bien démonté. Pour démonter le système de fichier (sur Twin 1 normalement) :

sudo umount /srv/prod

Pour désactiver la liaison miroir (sur les deux machines) :

sudo drbdsetup /dev/drbd0 down

Il ne nous reste plus qu'à lancer sur chacun des serveurs le script d'Init via la commande :

sudo /etc/init.d/drbd start

Normalement, la liaison miroir est établie entre les deux serveurs. Cependant, après un examen du /proc/drbd, on se rend compte que les deux serveurs sont considérés comme secondaire. C'est normal car c'est à vous (ou à un système de basculement automatique) de dire lequel est le serveur maître.

Nous pouvons utiliser les commandes précédentes pour basculer le maître et l'esclave et vice-versa (sans oublier les points de montage). Cependant, je vais vous présenter un système plus complexe mais nettement plus efficace dans le cas d'une solution RAID-1 over IP : il s'agit du basculement automatique.

L'idée du basculement automatique est que si un des deux serveurs ne fonctionne pas, l'autre prend le relais automatiquement et vice-versa. En termes plus clairs, on aura un serveur de préférence qui prendra le rôle du maître et montera le disque mirroré. Si ce dernier tombe, c'est le second serveur qui deviendra maître. On peut imaginer une solution avec plus de deux serveurs mais n'oubliez pas que le mirroring des disques peut devenir vite gourmand en multipliant les serveurs. Nous allons présenter ici une solution dans la lignée de l'article en présentant comment installer un basculement automatique sur nos deux serveurs Twin 1 et Twin 2.

Pour établir un système de basculement automatique, je vous invite à consulter la page concernant heartbeat. A partir de cette page, installer heartbeat et appliquer la configuration basique.

A partir de cette base, nous allons ajouter le basculement automatique pour notre système de mirroring. Avant de commencer, stoppez tout sur les deux serveurs Twin 1 et Twin 2 via les commandes suivantes (à exécuter sur chacun des serveurs) :

sudo /etc/init.d/heartbeat stop
sudo /etc/init.d/drbd stop

Editez le fichier de configuration des ressources de Heartbeat via la commande :

sudo vi /etc/ha.d/haresources

Et ajoutez une surveillance pour les services suivants :

drbddisk::drbd0
Filesystem::/dev/drbd0::/srv/prod::ext3

A titre d'exemple, mon fichier /etc/ha.d/haresources ressemble à ceci (configuration de base avec le système mirroré) :

twin1 IPaddr::192.168.252.205 drbddisk::drbd0 Filesystem::/dev/drbd0::/srv/prod::ext3

Vous pouvez maintenant relancer la liaison mirroring en commençant par Twin 1 (le maître) et ensuite l'esclave par la commande suivante :

sudo /etc/init.d/drbd start

Et maintenant, vous pouvez lancer Hearteat afin de surveiller les serveurs et assurer la disponibilité du service :

sudo /etc/init.d/heartbeat start

Une fois les deux serveurs interconnectés, Twin 1 devient le maître et Twin 2 l'esclave. Si la liaison Twin 1 tombe, Twin 2 prend automatiquement le relais en montant le disque mirroré sur le système local et devient le maître.

Lorsque Twin 1 réapparait, Twin 2 reconstruit le système de fichier mirroré sur Twin 1. Pour refaire passer Twin 1 comme maître, il vous suffit de redémarrer le service HeartBeat manuellement à l'aide de la commande suivante :

sudo /etc/init.d/heartbeat restart

N'hésitez pas à faire quelques essais de retrait brutal du câble d'alimentation pour voir si tout les services voulus sont bien transférés car lors d'une panne réelle, vous n'aurez pas droit à l'erreur.

Pour modifier la vitesse de transfert entre les deux serveurs mirrorés, vous devez utiliser la commande suivante sur l'une des deux machines :

sudo drbdsetup /dev/drbd0 syncer -r 2048

Ici, on limite le taux de transfert à 2048K/s. La limite de taux de transfert va de 1 à 700000 K/s. Notez que lorsque la limite est à 700000 K/s, les autres tâches du système sont fortement ralenties et je ne vous parles pas des collisions réseaux. A mon avis, il vaut mieux ne pas dépasser les 4096K/s.

Vous pouvez également changer la limite de taux de transfert dans le fichier de configuration dans le cas d'une configuration définitive. Ce paramètre est indiqué dans le fichier drbd.conf d'exemple.

Contributeur : ostaquet