N'GUESSAN K. Hyppolyte 2012 - 2013
59
III.3.2.3. Le démarrage du cluster et l'analyse
des logs
Nous allons pourvoir maintenant passer au démarrage de
notre cluster, nous verrons par la même occasion l'attribution et l'IP
virtuelle. Pour avoir une vue en détail de ce qu'il se passe sur nos
serveurs, il est aussi intéressant d'avoir un oeil sur les logs de
ceux-ci qui se situent, selon notre configuration, dans le fichier
«/var/log/heartbeat.log«. Nous saisissons
donc sur nos deux serveurs la commande suivante :
service heartbeat start
Si tout se passe bien, nous aurons une nouvelle interface et
une nouvelle IP lors de la saisie de la commande
«ifconfig» sur le serveur actif
(«maître«) comme sur la figure 20:
Figure 20: La vérification de l'activation du service
de haute disponibilité (Source : Hyppolyte N'GUESSAN)
On voit donc bien ici que c'est une IP virtuelle
(« :0«) qui est basée sur eth0 et qu'elle
à l'IP 192.168.0.50 qui devrait alors être
joignable (par un simple ping). Jetons maintenant un oeil du coté de nos
logs.
D'abord sur le serveur actif
(«maitre«)
On voit sur la figure ci-dessous le début du processus
des statuts. Le but est ici de définir qui est vivant et qui ne l'est
pas pour définir qui se chargera d'être actif. On voit donc que le
serveur commence par joindre la passerelle afin de vérifier la
connectivité de son interface (ici «eth0«).
Il déclare ensuite le statut de cette interface en
«up« (figure 21)
Figure 21: Une partie du fichier log (Source : Hyppolyte
N'GUESSAN)
On voit ici qu'Heartbeat utilise un deuxième de ses
scripts qui permet de vérifier la réponse d'une requête sur
l'IP virtuelle.
N'GUESSAN K. Hyppolyte 2012 - 2013
60
Après avoir effectué cette vérification,
le serveur paramètre donc l'IP virtuelle dans sa configurati on
grâce à son script «IPaddr«
Figure 22: L'analyse du fichier log (Source : Hyppolyte
N'GUESSAN)
III.3.2.4. Simulation d'une panne,
récupération et analyse des logs
Nous allons maintenant simuler un dysfonctionnement dans le
cluster en éteignant notre serveur «actif»
pour voir si la reprise par le serveur «passif» se
fait correctement, nous allons également vérifier les logs pour
voir comment les actions sont reçues et menées. Nous voyons alors
directement dans les logs les informations suivantes :
On voit ici que le serveur passif détecte que le lien
cluster-node1 (serveur maitre«192.168.0.2«) ne
répond plus, il le considère donc comme
«mort» (figure 23) :
Figure 23: La simulation d'une panne (Source : Hyppolyte
N'GUESSAN)
Il lance ensuite la reprise du serveur actif en configurant
l'IP virtuelle sur son interface comme précisé dans le fichier
«/etc/heartbeat/haresources«. A ce moment,
si l'on fait un «ifconfig» sur le serveur
192.168.0.3, nous allons voir qu'il a bien
récupérer l'IP virtuelle sur cluster (figure 24).
Figure 24: La vérification du fonctionnement du
service de haute disponibilité (Source : Hyppolyte N'GUESSAN)
Pour continuer l'exemple d'une production, nous allons
rallumer notre serveur 192.168.0.2 (ancien actif) pour qu'il
récupère l'IP virtuelle et redevienne le serveur principal comme
nous le voulons. Cela est possible grâce à l'option
«auto_failback» qui est à
«yes«.
N'GUESSAN K. Hyppolyte 2012 - 2013
61
Cela indique que dès que le serveur dit comme
«principal» redeviendra
«vivant«, il prendra à nouveau la fonction et
la tête du cluster. L'utilité de ce paramétrage peut
dépendre du service hébergé sur les serveurs en cluster
(figure 25)
Figure 25: La reprise de la tête du cluster par le
serveur principal (Source : Hyppolyte N'GUESSAN)
| 
