N'GUESSAN K. Hyppolyte 2012 - 2013
57
III.3.2. Le service de haute disponibilité
III.3.2.1. L'installation
Pour notre cluster, nous suivons le schéma suivant :
Figure 19: La synoptique du clustering de serveurs (Source
: Hyppolyte N'GUESSAN)
Nous aurons donc un serveur actif en 192.168.0.2
et un serveur passif 192.168.0.3 tout deux sous Linux
sur lesquels sera installé le paquet Heartbeat et ses
dépendances. Nous souhaitons que les clients communiquent avec le
serveur via l'IP virtuelle du cluster 192.168.0.50 et non pas
vers 192.168.0.2 ou 192.168.0.3. Ce sera au
cluster de passer les requêtes à tel ou tel serveur suivant la
disponibilité du serveur «maître«.
Après avoir mis en place les serveurs et s'être
assuré de leur inter- connectivité (via un simple ping), nous
allons mettre à jours notre liste de paquet :
apt-get update
Puis installer le paquet Heartbeat
apt-get install Heartbeat
III.3.2.2. La configuration
Les fichiers de configuration devront être les
mêmes sur les deux serveurs membres du cluster et devront se
situés dans «/etc/ha.d»
(ou «/etc/heartbeat» qui est
un lien symbolique
N'GUESSAN K. Hyppolyte 2012 - 2013
58
vers «/etc/ha.d«). Ces
fichiers devront être créés car ils ne le sont pas à
l'installation d'Heartbeat :
vim /etc/heartbeat/
ha.cf
Un «node» est un noeud.
Autrement dit un serveur membre du cluster. L'auto_failback
permet de rebasculer directement sur le serveur maitre quand il
redevient opérationnel après qu'il ait été
déclaré comme «mort» (quand il est configuré
à «yes«. Nous passons maintenant au
fichier «/etc/heartbeat/authkeys«, ce
fichier va définir la clé qui permettra d'authentifier un minimum
les serveurs membres du cluster entre eux :
vim /etc/heartbeat/authkeys
Voici un contenu
Auth1
1sha1 ma clef secrète
Il faut savoir que l'on peut utiliser trois modes de
sécurisation dans ce fichier :
· Sha 1 (Secure Hash Algorithm
1)
· md5 (Message Digest 5)
· crc (Cyclic Redundancy
Check)
Par sécurité, on sécurise ce fichier en lui
mettant des droits plus restreints :
chmod 600 /etc/heartbeat/authkeys
On passe maintenant au fichier
«/etc/heartbeat/haresources» qui va
contenir les actions à mener au moment d'un basculement. Plus
clairement, quand un serveur passera du statut «passif»
à «actif«, il ira lire ce fichier
pour voir ce qu'il doit faire. Dans notre cas nous allons dire à notre
serveur de prendre l'IP virtuelle 192.168.0.50
cluster-node1 192.168.0.50
On rappelle que le contenu du fichier doit être le
même sur les deux serveurs. On indique donc ici le nom du serveur
primaire du cluster (cluster-node1 est pour moi
«192.168.0.2«) puis l'IP virtuelle du cluster :
«192.168.0.50» dans notre cas. Pour information, les
logs de Heartbeat se situent comme indiqué dans le fichier de
configuration dans le fichier
«/var/log/daemon.log«.
| 
