Serveur Linux haute disponibilité

1. Introduction :

1.1 Principe de fonctionnement :

Contrairement à un certain nombres de systèmes comme les annuaires LDAP et les serveurs de base de données, les serveurs de fichiers ne possèdent pas de mécanisme natif de réplication. Nous allons voir ici commentre mettre en place un serveur avec réplication de données sur un deuxième serveur qui prendra le relais en cas de panne sur le serveur principal. Ce mécanisme attribuera l’IP virtuelle utilisée par les clients et basculera les données et les services réseaux sur le second serveur. Nous mettrons en évidence le fonctionnement en réalisant un serveur Web haute dispo.

Cette solution s’appuie sur les briques DRBD et Heartbeat. Elle fonctionne en mode maitre->esclave, par conséquent le deuxième serveur ne permet pas de faire de l’équilibrage de charge. C’est néanmoins une excellente solution lorsque le budget est limité car elle fonctionne avec seulement deux serveurs et ne nécessite pas de SAN, NAS, système de fichiers clusterisé etc… dont le coût peut être prohibitif.

Pour tout savoir sur la haute disponibilité, vous pouvez consulter cette page du site lea-linux : [http://lea-linux.org/cached/index/Leapro-pro_sys-dispo.html->http://lea-linux.org/cached/index/Leapro-pro_sys-dispo.html]

1.2 Background technique :

Les exemples seront données en utilisant 2 serveurs nommés debian1 et debian2 se basant sur la distribution Debian Etch.

Chaque serveur possède deux cartes réseau. L’une est l’interface visible depuis les clients, dans notre cas sur le sous-réseau 192.168.69.0/24. La seconde carte réseau est reliée via un cable croisée sur la seconde carte réseau de l’autre serveur afin de se prémunir de fiabiliser au maximum la réplication des données entre les serveurs.

Donc on aura les serveurs suivants :
debian1.morot.local
eth0 : 192.168.69.14/24
eth1 : 10.0.0.1/8

debian2.morot.local
eth0 : 192.168.69.15/24
eth1 : 10.0.0.2/8

2. Redondance des données : DRBD

2.1 Installation des différents composants :

Dans un premier temps, on installe module-assistant pour compiler le module drbd à la sauce Debian :

# apt-get install module-assistant

Ensuite on installe le nécessaire pour compiler un module de cette façon :

# module-assistant prepare
# module-assistant update

Et enfin on réalise l’installation du module et la compilation en une seule étape, qui va également installer tous les outils nécessaire à l’utilisation de drbd :

# module-assistant auto-install drbd0.7-module-source

On peut ensuite charger le module à l’aide de la commande modprobe drbd, ce qui fera apparaitre ceci à l’ecran :

drbd : initialised. Version: 0.7.21 (api:79/proto:74)
drbd : SVN Revision: 2326 build by root@debian2, 2007-09-18 23:57:54
drbd : registered as block device major 147

2.2 Configuration de DRBD :

L’essentiel de la configuration de DRBD se passe dans le fichier /etc/drbd.conf. Il est absolument indispensable que ce fichier soit identique sur les deux serveurs. Voici son contenu :

resource repl {
  protocol C;

  startup {
    degr-wfc-timeout 120;
  }

  disk {
    on-io-error detach;
  }

  syncer {
    rate 100M;
  }

  on debian1 {
    device      /dev/drbd0;
    disk        /dev/hda5;
    address     10.0.0.1:7788;
    meta-disk   internal;
  }

  on debian2 {
    device      /dev/drbd0;
    disk        /dev/hda5;
    address     10.0.0.2:7788;
    meta-disk   internal;
  }
}

Le protocole C est le plus pointilleux en ce qui concerne la réplication. Il considère qu’une information est répliquée lorsqu’elle a été flushée du cache disque du serveurs esclave.

La section syncer définit le débit du lien de réplication qui unit les deux machines.

Enfin, la section on <serveur> est la plus importante. C’est ici que sont définit les serveurs et les partitions de ces serveurs qui forment le périphérique bloc (/dev/drbd0) répliqué entre les serveurs. Il s’agit donc ici d’un endroit à entièrement adapter à votre configuration.

On peut passer à la suite et démarrer drbd sur les deux serveurs :

# /etc/init.d/drbd start

2.3 Initialisation des réplicas :

Les deux serveurs apparaissent alors à ce moment en esclave et désynchronisés dans les logs :

debian1# dmesg
[...]
drbd0: Creating state block
drbd0: resync bitmap: bits=708222 words=22132
drbd0: size = 2766 MB (2832888 KB)
drbd0: 2832888 KB now marked out-of-sync by on disk bit-map.
drbd0: Assuming that all blocks are out of sync (aka FullSync)
drbd0: 2832888 KB now marked out-of-sync by on disk bit-map.
drbd0: drbdsetup [2141]: cstate Unconfigured --> StandAlone
drbd0: drbdsetup [2154]: cstate StandAlone --> Unconnected
drbd0: drbd0_receiver [2155]: cstate Unconnected --> WFConnection
drbd0: drbd0_receiver [2155]: cstate WFConnection --> WFReportParams
drbd0: Handshake successful: DRBD Network Protocol version 74
drbd0: Connection established.
drbd0: I am(S): 0:00000001:00000001:00000001:00000001:00
drbd0: Peer(S): 0:00000001:00000001:00000001:00000001:00
drbd0: drbd0_receiver [2155]: cstate WFReportParams --> Connected
drbd0: I am inconsistent, but there is no sync? BOTH nodes inconsistent!
drbd0: Secondary/Unknown --> Secondary/Secondary

debian1:~# cat /proc/drbd
version: 0.7.21 (api:79/proto:74)
SVN Revision: 2326 build by root@debian1, 2007-09-19 00:02:20
 0: cs:Connected st:Secondary/Secondary ld:Inconsistent
    ns:0 nr:0 dw:0 dr:0 al:0 bm:346 lo:0 pe:0 ua:0 ap:0

Il faut maintenant initialiser le serveur maitre :

debian1:~# drbdadm -- --do-what-I-say primary all

Ce qui aura pour effet d’initier une synchronisation des serveurs :

debian1:~# cat /proc/drbd
version: 0.7.21 (api:79/proto:74)
SVN Revision: 2326 build by root@debian1, 2007-09-19 00:02:20
 0: cs:SyncSource st:Primary/Secondary ld:Consistent
    ns:20560 nr:0 dw:0 dr:28752 al:0 bm:346 lo:1 pe:0 ua:2048 ap:0
        [>...................] sync'ed:  0.9% (2812328/2832888)K
        finish: 0:09:00 speed: 5,140 (5,140) K/sec

Les logs sur le serveur secondaire nous permettent également d’attester que la synchronisation est en train de se réaliser :

debian2 # dmesg
[...]
drbd0: drbd0_receiver [2119]: cstate Connected --> WFBitMapT
drbd0: Secondary/Secondary --> Secondary/Primary
drbd0: drbd0_receiver [2119]: cstate WFBitMapT --> SyncTarget
drbd0: Resync started as SyncTarget (need to sync 2832888 KB [708222 bits set]).

Et une fois la synchro établie on peut constater que le réplicat est consistant :

debian1:~# cat /proc/drbd
version: 0.7.21 (api:79/proto:74)
SVN Revision: 2326 build by root@debian1, 2007-09-19 00:02:20
 0: cs:Connected st:Primary/Secondary ld:Consistent
    ns:2832888 nr:0 dw:0 dr:2832888 al:0 bm:519 lo:0 pe:0 ua:0 ap:0

2.4 Validation du fonctionnement :

La périphérique de réplication se formate comme n’importe quelle partition de disque dur :

debian1# mkfs.ext3 /dev/drbd0

Il ne reste plus qu’à monter cette partition pour tester le fonctionnement de la réplication en forçant une bascule maitre->esclave :

debian1# mount /dev/drbd0 /mnt/repl
debian1:~# touch /mnt/repl/test
debian1:~# ls /mnt/repl/
test  lost+found
debian1:~# drbdadm secondary repl

Il ne reste plus qu’à passer la machine debian2 en maitre et s’assurer que le fichier nommé « test » est bien présent :

debian2:~# drbdadm primary repl
debian2:~# mount /dev/drbd0 /mnt/repl/
debian2:~# ls /mnt/repl/
test  lost+found

Bingo! On peut passer à la suite!

3. Système de failover : Heartbeat

3.1 Installation est configuration :

On commence par installer le nécessaire sur les deux serveurs :

# apt-get install heartbeat

Ensuite, il faut personnaliser trois fichiers de configuration. Tout comme pour DRBD, ces fichiers doivent être identiques sur les deux serveurs de la grappe. Par conséquent vous pouvez commencer par les éditer sur le premier serveur et les recopier en SCP sur le second.

Première étape : définir une clé partagée dans le fichier /etc/ha.d/authkeys

auth 1
1 md5 "Icimonsupermotdepasse"

Puis modifiez les permissions avec un chmod 0600 /etc/ha.d/authkeys

Deuxième étape : configurer les ressources partagées du cluster. Pour cela éditer le fichier /etc/ha.d/haresources. L’ensemble de la configuration est à placer sur une seule ligne.

debian1 192.168.69.16 IPaddr::192.168.69.100 drbddisk::repl Filesystem::/dev/drbd0::/mnt/repl::ext3 apache MailTo::admin@example.com

Dans l’ordre on indique :

• La machine maitre du cluster
• La première adresse virtuelle suivi des autres adresses virtuelles
• La partition DRBD et comment la monter dans l’arborescence
• Les services à démarrer
• Eventuellement une alerte mail

Dernière étape : mettre en place la configuration générale de Heartbeat. Dans le fichier /etc/ha.d/ha.cf on indique les noeuds qui participent au cluster, les durées à partir desquelles on considère que le second noeud est défaillant, si on doit rebasculer automatiquement vers le premier serveur une fois qu’il est de nouveau opérationnel etc…

node debian1 debian2
logfile /var/log/ha.log
logfacility local0

auto_failback off

keepalive 2
warntime 10
deadtime 60
initdead 80

udpport 694
bcast  eth1

Ici, les noeuds communiquent via leur seconde carte réseau. La communication pourrait être fiabilisée en passant par le port série ce qui se ferait avec un fichier de configuration de ce type :

node debian1 debian2
logfile /var/log/ha.log
logfacility local0

auto_failback off

keepalive 2
warntime 10
deadtime 60
initdead 80

baud 9600
bcast eth0
serial /dev/ttyS0

3.2 Test de fonctionnement :

Apache étant démarré par heatbeat, il convient donc de le supprimer du chargement au démarrage de la Debian des deux serveurs :

# update-rc.d -f apache remove

Il ne reste plus qu’à démarrer heartbeat sur les deux serveurs en commençant par le premier :

# /etc/init.d/heartbeat start

Après quelques secondes les adresses IP virtuelles doivent être attribuées sur le serveur debian1 :

debian1:/etc/ha.d# ip addr show eth0
2: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 08:00:27:42:d9:0d brd ff:ff:ff:ff:ff:ff
    inet 192.168.69.14/24 brd 192.168.69.255 scope global eth0
    inet 192.168.69.16/24 brd 192.168.69.255 scope global secondary eth0:0
    inet 192.168.69.100/24 brd 192.168.69.255 scope global secondary eth0:1
    inet6 fe80::a00:27ff:fe42:d90d/64 scope link
       valid_lft forever preferred_lft forever

De même que la partition DRBD doit être montée automatiquement :

debian1:/etc/ha.d# mount
[...]
/dev/drbd0 on /mnt/repl type ext3 (rw)

Il est possible de tester la bascule en coupant Heartbeat sur le premier serveur, voir même en l’éteignant complètement :

debian1:/etc/ha.d# /etc/init.d/heartbeat stop
Stopping High-Availability services:
Done.

Très rapidement, la machine debian2 devrait se voir attribuer les deux adresses IP virtuelles définies dans le fichier /etc/ha.d/haresources. Il ne reste plus qu’à configurer Apache pour que la directive DocumentRoot pointe vers le point de montage de DRBD pour que les services profitent de ce sous-système en haute disponibilité et le tour est joué.

4. Conclusion :

J’ai eu l’occasion de déployer ce type de cluster sur des serveurs Web gérant 450 sites en hébergement mutualisé et des serveurs mails traitant environ 15000 mails/jour et cela a fonctionné parfaitement. Le mécanisme de haute disponibilité permet même de se payer le luxe d’une maintenance sur les serveurs, par exemple lors d’une mise à jour de sécurité, avec un temps de transition très faible.

Il serait possible d’améliorer le système avec des solutions de type stonith, qui permettent à un serveur d’éteindre le second serveur lorsqu’il juge que celui-ci ne répond plus. Personnellement je n’ai pas osé le mettre en place par crainte que l’un des serveurs se fasse éteindre sans que cela soit nécessaire.