High availability : drbd et heartbeat

La HA (acronyme pour High Availability, haute disponibilité) peut facilement se mettre en place en conjuguant une solution de mirroring de donnée par le réseau et une solution de détection de panne.

Ces solutions existent et certaines ont fait leurs preuves depuis longtemps. C’est le cas pour DRBD et Heartbeat dont nous allons voir un exemple succinct.

DRBD

DRBD, c’est la version courte de Distributed Replicated Block Device. C’est une solution de réplication de données via un réseau dédié qui, somme toute, permet d’avoir, up to date, un mirroir de vos données tout prêt en cas de problème sur le nominal.

L’installation se fera depuis les dépôts, pour la simple et bonne raison que cela permet de rester cohérent lors des updates du système et de ne pas avoir à tout recompiler après l’opération.

Les packages à installer sont drbd et kmod-drbd, il ne vous reste plus qu’à faire appel à votre gestionnaire de package préféré.

Après l’opération, on peut d’ores et déjà charger le module manuellement via un simple !

# modprobe -i drbd

Et, tant qu’à faire, rajouter la ligne du modprobe dans le fichier /sbin/rcdrbd.

Configuration

C’est à ce niveau que l’on peut admirer le génie de DRDB : deux modes existent :

• la réplication de donnée Active / Passive implique que l’écriture est faite sur l’un des emplacements, le master, puis répliquée sur le slave.
• la réplication de donnée Active / Active, qui gère l’écriture simultanée sur toutes les entités concernées

Malheureusement, on peut dire que la technologie sous-jacente limite les possibilités, car certains filesystems ont été conçus pour être les seuls à accéder aux volumes de données, comme ext3 par exemple.

En conséquence, si vous utilisez -ou voulez utiliser- ext3, il faut opter pour une configuration drdb active / passive. En revanche, si vous souhaitez jouer avec active / active, vous pouvez vous orienter ver un cluster filesystem comme GFS ou OCFS.

Nous sommes dans le cas le plus fréquent : on cherche l’ext3, donc une configuration active / passive. La configuration sera donc un peu comme suit :

# cat /etc/drbd.conf
global{ 
 dialog-refresh 1;
 minor-count 5;
} 

common{} 

resource drbd-dns{
 protocol C;
 disk{ on-io-error detach; }
 syncer{
  rate 640M;
  al-extents 257; 
} 

 handlers {
 # /usr/lib/drbd/notify-split-brain.sh est un script qui notifie l'utilisateur passé en paramètre du split brain et déconnecte le disque
 split-brain "/usr/lib/drbd/notify-split-brain.sh root"; }
 net{
  ping-int 10;
  timeout 60;
  connect-int 10;
  ping-timeout 5;

  # Après la détection du split brain, aucun primaire détecté, et un des serveurs n'a fait aucune modification : répliquer les modifications sur ce serveur
  after-sb-0pri discard-zero-changes; 

  # Après un split brain, un primaire détecté : le secondary est systématiquement la split brain victim
  after-sb-1pri discard-secondary; 

  # Après un split brain, 2 primary détectés : déconnexion
  after-sb-2pri disconnect; 

  # Si le rôle du serveur est incompatible avec la resynchronisation des ressources : déconnexion
  rr-conflict disconnect;
 } 

  startup{ degr-wfc-timeout 120; } 

  on dns1.k-tux.com{
   device      /dev/drbd0;
   address     192.168.1.52:7789; 
   # dns1 IP
   meta-disk /dev/sda6[1];
   disk /dev/sda5;
  } 

  on dns2.k-tux.com{
   device  /dev/drbd0;
   address 192.168.1.53:7789;
   # dns2 IP
   meta-disk /dev/sda6[1];
   disk /dev/sda5;
  } 
}

Si en revanche vous souhaitez monter une configuration en active / active, il suffit de mentionner l’option allow-two-primaries; dans la section net{} et de rajouter en dehors de net{} mais toujours dans la section resource data {} la section startup telle que :

startup {
become-primary-on both;
}

Cela permet de monter les 2 serveurs en rôle primaires au démarrage.