Le logiciel

les pré-requis

Il est impératif de contrôler les points suivants :

  • Le nom que vous utiliserez pour désigner votre machine doit bien être celui donné par la commande uname -n. Sinon, le logiciel le refusera. (Pour définir le nom d'une machine, il faut renseigner le fichier /etc/hostname.

  • De même, les noms utilisés pour désigner les autres noeuds (machines) de votre cluster doivent être connus par chaque machine, soit par l'utilisation d'un dns, soit par le fichier /etc/hosts.

L'installation

Sur une debian stable, l'installation se fait par la méthode standard :

apt-get install heartbeat

Debconf va ensuite vous aider à configurer ce service (pas sur sarge). J'ai preferé construire mes fichiers de configuration manuellement.

les fichiers de configuration

Il y a trois fichiers de configuration principaux :

  • ha.cf contient les réglages de la machine réelle.

  • haresources contient les réglages du cluster (la machine à simuler).

  • authkeys contient les modes d'authentification (utile si on utilise le réseau de production).

Il est important de noter qu'haresources décrit le cluster tel qu'il doit être vu (notamment la 'fausse' adresse IP), tandis qu'ha.cf décrit le fonctionnement du noeud réel. Ainsi, ha.cf pourra varier selon les machines (nom de la carte réseau différent, logs réglés différemment) alors que haresources est lui PARTOUT IDENTIQUE (tous les noeuds doivent être d'accord sur le cluster à simuler).

Le fichier ha.cf

petit tour du propriétaire :

  • choix de médium de surveillance

    la carte réseau

    bcast eth0

    le câble NULL MODEM

    baud 19200

    serial /dev/ttyS0
  • logs

    Les pépins

    debugfile /var/log/hda-debug

    Les évènements

    logfile /var/log/hda-log

    la facility (la sémantique des messages, voir le cours sur syslog)

    logfacility  local0
  • délais de réaction (en secondes)

    délai entre deux 'pouls'

    keepalive 2

    durée du silence avant de déclarer un noeud 'mort'

    deadtime 10

    durée du silence avant de déclencher une alerte

    warntime 8

    temporisation lors du lancement du service (si un noeud est lent)

    initdead 30
  • réglages generaux

    port UDP pour le 'pouls'

    udpport 694

    liste des noeuds participants au cluster (Attention, tous les participants doivent connaitre la liste exhaustive des noeuds concernés)

    node srv-principal

    node srv-secours

    le serveur principal reprend la main lors de son retour

    nice_failback on

La première partie permet de définir le mode d'écoute du logiciel de surveillance. Il semble que l'emploi du port série implique de bien définir les bauds avant. Vous pouvez combiner plusieurs modes d'écoute, c'est alors le silence sur tous ces médias qui entraînera les actions d'heartbeat .

La partie sur les logs permet de bien contrôler le fonctionnement du logiciel et valider les échanges entre les différents noeuds. Vous pouvez choisir les noms de fichiers que vous désirez, ainsi que la facility (pour le traitement par le démon syslogd).

La gestion de temps de réaction peut être donnée en millisecondes (par défaut, elle est en seconde) en ajoutant le suffixe ms (keepalive 200ms). Attention au initdead qui permet de gérer un noeud un peu lent à démarrer, et ainsi éviter de l'exclure immédiatement du cluster. La documentation préconise de doubler au minimum ce temps par rapport au deadtime.

Enfin, partie TRES IMPORTANT, la liste des noeuds qui participent au cluster. Lorsque tous les noeuds seront actifs, alors heartbeat activera le cluster et les services qui lui sont associés (les services démarreront à ce moment là, sur la machine qui est porteuse de l'adresse ip du cluster).

Ce fichier peut legerement différer selon les noeuds, dans les deux premières parties uniquement (puisque ce fichier définit les caractéristiques techniques sécifiques à ce noeud).

exemple de fichier ha.cf

On écoute sur le port série, les deux noeuds s'appellent hypérion et endymyon, et on ne loggue rien.

baud 19200
serial /dev/ttyS0
keepalive 2
deadtime 10
warntime 8
initdead 30
node hyperion
node endymion

On a maintenant un cluster de trois machines ubik, slans et fundation. La surveillance se fait via un réseau spécifique (sur la deuxième carte réseau), et on veut logger les informations, identifiées comme informations de programmes serveurs.

bcast eth1
udpport 694
logfile /var/log/heartbeat.log
logfacility daemon
keepalive 2
deadtime 10
warntime 8
initdead 30
node ubik
node slans
node fundation

Le fichier haresources

Fichier de description du cluster a simuler. IL DOIT ETRE IDENTIQUE SUR TOUS LES NOEUDS !. Ce fichier décrit la machine maître parmi tous les noeuds du cluster, la ou les adresses IP à simuler, et les services à assurer sur ce cluster.

Dans notre exemple, si on veut que notre cluster www ait l'adresse IP 192.168.1.100, que srv-principal soit la machine qui assure prioritairement ce rôle, et que www soit un serveur Web et mysql, alors tous les noeuds auront le fichier haresources suivant :

Example 44.4. haresources pour tous

srv-principal	192.168.1.100	apache	mysql

Avec un tel fichier, automatiquement, dès la mise en route du cluster, (c'est à dire quand toutes les machines qui participent au cluster auront démarrées) le service Web et le serveur de base de données seront automatiquement activés. Si le serveur principal tombe, alors le serveur de secours prend le relais, lance le Web et Mysql, se donne la bonne adresse IP, fait un broadcast ARP pour avertir le réseau...

En cas de problème (unable to find an interface for ip), on peut etre plus précis sur l'adresse IP du cluster. Ainsi, on peut indiquer le nombre de bits du masque, et même la carte réseau qui doit porter l'alias (En théorie, cela devrait être résolu automatiquement... Vous remarquerez que, dans ce cas, les fichiers diffèrent légèrement sur chaque machine).

Exemple, dans lequel c'est hyperion qui doit être le maître, en prenant l'adresse 192.168.4.200 sur sa carte eth1

hyperion	192.168.4.200/24/eth1	apache	postfix

Le fichier authkeys

Ce fichier détermine le niveau de securite des échanges entre les différents noeuds du cluster. Si vous êtes sur un médium fiable, vous pouvez utiliser le niveau le plus bas de sécurité (crc = simple contrôle de contenu, par l'utilisation d'une somme de contrôle, aucun cryptage). Il est possible d'utiliser des systèmes plus puissant (crypté avec md5 ou mieux encore (mais plus gourmand en temps processeur) sha). Dans les deux derniers cas, il faut fournir une clé... Cette clé (ou plutot ce fichier authkeys sera présent et identique sur chacun des noeuds.

Example 44.5. authkeys

auth 1
1 md5 "cluster cluster password"
2 crc
3 sha "conquistador"

Dans cet exemple, les trois modes sont prêts à fonctionner, avec les clés associées aux services, et c'est le md5 qui est choisi (auth est à 1). Ces clés doivent bien sur être les mêmes sur l'ensemble des noeuds participant au cluster.

Attention aux droits sur ce fichier de sécurité (600).

Autre exemple de fichier authkeys

auth 1
1 crc

Mise en route

Tous les fichiers de configuration mis en place sur tous les noeuds, vous pouvez alors lancer le service (pour les recopies, vous pouvez éventuellement vous aider de scp). le lancement du service se fait de la façon habituelle.

/etc/init.d/heartbeat start

Des que le cluster est constitue (tous les noeuds sont actifs), alors srv-principal héritera d'une nouvelle adresse IP (en ip-aliasing) 192.168.1.100, et les services apache et mysql seront alors lancés (si ce n'était déjà fait). Les scripts de lancement apache et mysql sont ceux trouvés à l'endroit habituel (/etc/init.d). Le cluster fonctionne, et les clients peuvent s'y connecter.

Vous pouvez (VOUS DEVEZ !!) surveiller les fichiers de logs (grâce à tail -f /var/log/ha-log), et faire joujou en coupant brutalement le courant sur le serveur principal. Testez le nice_failback, la mise en route de différents services, ainsi que le réseau (ifconfig sur les noeuds, et sniff du réseau pour voir les broadcast ARP lors des changements de serveurs...