Gzav's Wiki | Clustering / Heart Beat

Continuité de service : créer un cluster de machines avec Heartbeat et DRBD

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 ¹ vers le backup ² :

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 ² : 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 ¹ HeartBeat fera l'opération inverse et réattribuera l'IP du cluster à ¹.

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 ²

# /etc/init.d/heartbeat stop ¹

# /etc/init.d/drbd stop ²

# /etc/init.d/drbd stop ¹

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 ¹

0: cs:StandAlone st:Secondary/Unknown ld:Inconsistent ²

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--- ¹

0: cs:StandAlone st:Secondary/Unknown ds:UpToDate/DUnknown r--- ²

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 >>

Pièces jointes de la catégorie :

Mon pense bête...

Heart Beat