Continuité de service : créer un cluster de machines avec Heartbeat et DRBD
<< DRBD | Index | Mon >>
Basculer les services avec Heartbeat
Configuration
Fichier /etc/ha.d/ha.cf
# interface pour le heartbeat
bcast eth0
# délai entre deux battements de pouls
keepalive 2
# Temps d'attente avant de passer sur le deuxieme
deadtime 10
# Temps avant de diffuser un avertissement pour les pouls en retard
warntime 6
# deadtime spécifique pour les configurations ou le réseau est lent
initdead 60
# port de prise de pouls
udpport 694
# Identification des noeuds du cluster
node server1
node server2
# On interdit le rebasculement automatique vers le maitre lorsque celui-ci redeviendra UP
auto_failback off
# utilisation du démon logd
use_logd yes
Pensez à ouvrir les ports utilisés par
HeartBeat dans le fichier
iptables :
-A RH-Firewall-1-INPUT -p udp -m udp --dport 694 -j ACCEPT
Fichier /etc/ha.d/haresource
server1 IPaddr::192.168.0.50 drbddisk::r0 Filesystem::/dev/drbd0::/mnt/mirroir::ext3::defaults httpd mysqld smb cups MailTo::root
Informations :
- 192.168.0.50 est l'adresse IP attribuée du cluster, visible normalement en tapant la commande ifconfig (si heartbeat tourne)
- en utilisant cette adresse IP vous tomberez soit sur le serveur 1, soit sur le backup si le sertveur 1 est down.
Lors du basculement du serveur 1
1 vers le backup
2 :
- on demande d'abord à HeartBeat de monter automatiquement le répertoire synchonisé par DRBD (/mnt/mirroir)
- on demande à HeartBeat de démarrer les services suivants sur le backup 2 : http, mysql, samba et cups.
- les fichiers de configuration de ces services devront bien sûr être synchronisés entre les 2 machines (cf. bas de cette page) et les données qu'ils utiliseront devront être situés de préférence dans le répertoire /mnt/mirroir pour qu'elles soient toujours à jour.
Lors du rebasculement sur
1 HeartBeat fera l'opération inverse et réattribuera l'IP du cluster à
1.
Options pour
HeartBeat :
- Pour ajouter un mail d'alerte lors du basculement, voir du côté du script Perl MailTo::user@domain.fr::"[server1] Heartbeat alert !".
- Le fichier /etc/haressource est très bien commenté vous devriez y trouver votre bonheur.
Fichiers à personnaliser après un clonage
Si vous avez opté pour le clonage d'un serveur vers l'autre (attention à drbd), vous devrez personnaliser ces fichiers sur chaque serveur :
- /var/lib/heartbeat/hb_uuid (supprimer ce fichier sur l'un des 2 serveurs après clonage, il sera généré au prochain démarrage de heartbeat)
- /etc/udev/rules.d/70-persistent-net.rules (pour faire en sorte que l'interface Ethernet eth0 soit utilisable)
NB : repris tel quel du tutoriel Ubuntu
Redémarrage de Heartbeat
Exécuter les opérations suivantes
dans l'ordre.
Sur le
serveur 2 :
# /etc/init.d/heartbeat stop
Sur le
serveur 1 :
# /etc/init.d/heartbeat stop
Sur le
serveur 1 :
# /etc/init.d/heartbeat start
Sur le
serveur 2 :
# /etc/init.d/heartbeat start
Tests
Basculer sur le serveur 2
Sur le serveur 2 :
# /etc/init.d/heartbeat restart
Troubleshooting
En cas de problème pensez toujours à consulter les logs de DRBD / Heartbeat dans
/var/log/messages (ou ailleurs si vous avez défini des logs spécifiques).
Gestion manuelle des services
La règle est la suivante :
- on arrête toujours HeartBeat avant DRBD
- on arrête toujours le service du secondaire avant celui du primaire
- soit :
# /etc/init.d/heartbeat stop 2
# /etc/init.d/heartbeat stop 1
# /etc/init.d/drbd stop 2
# /etc/init.d/drbd stop 1
- reprendre les commandes dans le sens inverse pour redémarrer les services (en remplaçant le stop par le start).
Split-brain
J'ai repris tel quel l'explication faite
sur ce tuto.
En cas de coupure réseau, les 2 machines deviennent primaires et obtiennent la même adresse ip de la machine virtuelle !
Lorsque la connection est rétablie cela entraine un "split-brain" que l'on ne peut résoudre que manuellement.
Statut de DRBD
0: cs:StandAlone st:Primary/Unknown ld:Consistent 1
0: cs:StandAlone st:Secondary/Unknown ld:Inconsistent 2
L'état des noeuds est passé en "Unknown".
Résolution
# drbdadm connect r0 sur les 2 machines démarre la synchro du primaire vers le secondaire
# drbdadm invalidate r0 sur la machine secondaire : invalide les données et force une resynchronisation.
Problème de reconnaissance des machines entre-elles
Si au redémarrage d'un serveur les services DRBD ne se reconnaissent plus.
Statut de DRBD sur les serveurs :
0: cs:StandAlone st:Primary/Unknown ds:UpToDate/DUnknown r--- 1
0: cs:StandAlone st:Secondary/Unknown ds:UpToDate/DUnknown r--- 2
Résolution du problème
# drbdadm -- --discard-my-data connect r0 (sur le node avec les données corrompues)
# drbdadm connect r0 (sur le node avec les données correctes)
Les nodes doivent ensuite se reconnaitre et renvoyer un statut correct (
st:Primary/Secondary ds:UpToDate/UpToDate).
Synchronisation forcée
Pour forcer la synchronisation d'un des nodes taper une des commandes suivantes :
- pour invalider la ressource r0 sur le serveur courant :
# drbdadm invalidate r0
- pour invalider la ressource r0 sur le serveur distant :
# drbdadm invalidate-remote r0
NB : l'invalidation des données déclenchera automatiquement la synchronisation.
<< DRBD | Index | Mon >>