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.
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.
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).
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
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 :
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
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.
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
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...