Haute disponibilité avec Heartbeat

Haute disponibilité avec Heartbeat Consignes : Ce TP peut être réalisé seul ou en binôme à l aide de machines virtuelles Debian GNU/Linux. Un serveur DNS opérationnel est recommandé pour finaliser le TP. Vos serveurs Web ainsi que vos machines clientes devront être inscrits sur le DNS et l utiliser à l aide de leur resolver (/etc/resolv.conf). N oubliez pas la résolution inverse. 1. Mise en place d un cluster Actif/Passif avec HeartBeat Note : Remplacer 192.168.1.0 par votre Vlan! "un arbre qui tombe fait beaucoup de bruit, une forêt qui pousse le fait en silence" Gandhi SISR3 ha 1

Préparation du serveur primaire Configurer un serveur opérationnel ( Un clone du serveur Apache de PPE fera très bien l affaire) Procéder à la configuration IP du serveur maître. Configurer correctement le nommage : nano /etc/hostname apache1.votredomaine.local nano /etc/hosts 127.0.0.1 localhost 127.0.1.1 apache1.votredomaine.local apache1 nano /etc/resolv.conf nameserver @IP-votreserverDNS search votredomaine.local Installer Heartbeat, aptitude install heartbeat configurer les deux fichiers principaux et accorder les droits nécessaires. nano /etc/heartbeat/ha.cf # Facility to use for syslog()/logger (alternative to log/debugfile) logfacility local7 logfile /var/log/ha-log debugfile /var/log/ha-debug use_logd no # What UDP port to use for udp or ppp-udp communication? udpport 694 # keepalive: how many seconds between heartbeats keepalive 2 # deadtime: seconds-to-declare-host-dead deadtime 20 initdead 50 auto_failback off # Tell what machines are in the cluster # node nodename... -- must match with hostname # Mise en place des nœuds composant le cluster node apache1.votredomaine.local node apache2.votredomaine.local # permet de vérifier la connectivité avec Apache2 ucast eth0 192.168.1.3 ucast eth0 192.168.1.4 crm yes nano /etc/ha.d/authkeys auth 3 3 md5 azerty #Sécurisation de l accès au fichier d authentification chmod 600 /etc/ha.d/authkeys SISR3 ha 2

Assurez-vous que les noms d'hôtes présents dans les fichiers de configuration puissent être convertis en adresse IP via /etc/hosts et/ou DNS. # Par mesure de simplification si le serveur dns ne fonctionne pas, on peut utiliser /etc/hosts : 192.168.1.3 apache1.votredomaine.local localhost apache1 localhost.votredomaine.local 192.168.1.4 apache2.votredomaine.local apache2 Préparation du serveur secondaire Cloner le serveur primaire procéder à la configuration IP du serveur esclave et à sa personnalisation. Démarrer les nœuds et vérifiez que Heartbeat s'est correctement lancé sur les deux nœuds. Sur les deux nœuds : cl_status hbstatus Heartbeat is running on this machine. cl_status listnodes apache1 apache2 Vérifiez la configuration de Hearbeat sur chaque nœud, désactivez STONITH et le quorum. crm_verify -L -V ==> renvoie les erreurs relatives à STONITH crm configure property stonith-enabled=false crm configure property no-quorum-policy="ignore" Vérifiez de nouveau la configuration ainsi que le fichier xml généré. crm_verify -L -V ==> ne renvoie plus d'erreurs #!!!! attention ne pas modifier ce fichier manuellement!!! cat /var/lib/heartbeat/crm/cib.xml Configuration des ressources «failover IP» et «HTTP» (aide en annexe 2) crm configure primitive IPFailover ocf:heartbeat:ipaddr2 params ip="192.168.1.2" cidr_netmask="255.255.255.0" nic="eth0" op monitor interval="10s" timeout="20s" op start timeout="30s" op stop timeout="40s" Sur quel nœud la ressource a-t-elle été lancée? Justifier et vérifier crm status ou crm_mon sur un des deux nœuds Pour vérifier : ip addr show sur le serveur esclave pour voir l'adresse IP virtuelle (ou sur le maître pour vérifier que l'adresse IP virtuelle n'existe pas) Testez l'accès au service Web à partir de l'adresse IP virtuelle. w3m 192.168.1.2 ou http://192.168.1.2 ou mieux encore (le résultat attendu) : w3m lapastille.votredomaine.local ou http:// lapastille.votredomaine.local Testez le failover IP crm node standby ==> pour tester si l'adresse IP virtuelle passe bien sur l'autre serveur crm node online ==> pour tester le retour de l'adresse IP virtuelle tester l extinction et l allumage des services sur les deux serveurs Pour aller plus loin : Configuration de la réplication des bases de données SISR3 ha 3

Annexe 1 : fonctionnement et configuration de Hearbeat 3 et de Pacemaker la configuration s'articule autour des fichiers suivants qui doivent être identiques sur les deux serveurs. /etc/ha.d/ha.cf : ce fichier contient la configuration générale de Heartbeat Directives et valeurs Explications logfacility local7 Gestion des logs : il serait plus judicieux d'utiliser un système de gestion de log avec logfile /var/log/ha-log démon (avec l'option use_logd yes) mais par mesure de simplification, nous debugfile /var/log/hadebug logfacility local7 indique un fichier de log de niveau debug utiliserons la méthode classique. udpport 694 Port utilisé par les mécanismes de "battements de coeur" keepalive 2 Délai entre 2 battements (en secondes) deadtime 20 Temps nécessaire (en secondes) avant de déclarer un nœud comme mort initdead 50 Valeur utilisée pour le démarrage (> 2 fois le deadtime) La gestion du retour automatique d'une ou plusieurs ressources sur le nœud auto_failback off primaire ne sera pas gérée par Heartbeat mais par Pacemaker au cas par cas selon la manière dont nous déciderons de configurer la ressource. node apache1 node apache2 crm yes Liste des nœuds participants au Cluster (ne pas oublier de configurer le fichier «hosts» sur chacun des nœuds) Avec «crm yes» : format de configuration des ressources qui exploite un fichier de configuration XML et la gestion du Cluster est réalisée par un Pacemaker. Avec «crm no», Heartbeat exploite un fichier de configuration /etc/ha.d/haresources comme dans sa première version mais les possibilités sont limitées. /etc/ha.d/authkeys : ce fichier détermine le niveau de sécurité des échanges entre les différents noeuds du Cluster. Lorsque ces informations passent pas le réseau, il vaut mieux crypter l'échange avec md5 sha (plus gourmand en temps processeur). Dans ce cas, il faut fournir une «passphrase». auth 1 1 sha1 PassPhrase Par mesure de sécurité, les droits sur ce fichier doivent être réduits à la lecture et écriture seulement à l'utilisateur root (si ce n'est pas fait, Heartbeat ne démarre pas) La configuration du Cluster est contenue dans un Cluster Information Base (CIB) qui est un fichier XML. /var/lib/heartbeat/crm/cib.xml : ce fichier est généré (au démarrage de Heartbeat) à partir des deux fichiers vus précédemment et est complété au fur des ajouts de ressources. Ce dernier fichier ne doit JAMAIS être modifié directement mais via les commandes Les commandes utiles Pour vérifier que heartbeat est lancé : /etc/init.d/heartbeat status (ou service heartbeat status ou cl_status hbstatus) Pour voir la liste des noeuds : cl_status listnodes Et l'état d un noeud : cl_status nodestatus ma-machine-esclave.mondomaine.com La commande crm implémentée par pacemaker (qui peut être avantageusement utilisée aussi en interactif) permet de gérer la configuration et les différentes ressources. Elle se propage sur chaque nœud automatiquement : la commande s'effectue donc sur n'importe quel nœud. La commande suivante permet de suivre l'évolution de la configuration en direct : root@apache2:~# crm_mon Last updated et stack : la dernière mise à jour des informations du moniteur et le fournisseur (provider) utilisé : ici, Heartbeat Current DC : c est le nœud qui va coordonner les actions sur le Cluster. Les autres nœuds remonteront leurs informations au nœud DC. Ce nœud n est pas nécessairement le nœud «maître» du Cluster. SISR3 ha 4

Nodes & votes : le nombre de nœuds et le nombre de votes disponibles pour le quorum (voir page suivante). Resources configured : le nombre de ressources configurées dans le Cluster. Online : la liste des nœuds online. On pourra aussi trouver ici, la liste des nœuds offline ou en stand-by. Le contrôle d'un service actif (ou pas) sur un nœud peut aussi s'effectuer via les commandes usuelles ps, netstat et nmap. Pour afficher la configuration (beaucoup plus lisible que le fichier xml) : root@apache1:~# crm configure show Il existe une commande qui permet de vérifier la validité du fichier de configuration XML alors généré :crm_verify -L -V. À la première exécution de cette commande (après le démarrage correct de Heartbeat), des erreurs sont remontées : «Stonith» (shot the other node in the head) permet de tuer proprement les nœuds qui sont morts. C'est en fait un mécanisme pour éteindre complètement le serveur qui vient de flancher en éteignant son onduleur. C'est surtout utilisé avec des disques partagés car il serait dangereux que l'ordinateur qui est supposé être hors d'état vienne écrire sur le disque partagé et corrompre/altérer les données. Par mesure de simplification, nous allons désactiver STONITH par la commande : crm configure property stonith-enabled=false La vérification ne renvoie plus d'erreur. Vous pouvez consulter le fichier XML généré : /var/lib/heartbeat/crm/cib.xml : Persiste encore un petit problème à régler concernant le quorum qui est le nombre minimum de nœuds en ligne pour être capable de valider une décision. Dans le cas d un Cluster avec Pacemaker, il faut que plus de la moitié des nœuds soit en ligne. Avec un Cluster à deux nœuds, il n y a plus de quorum dès qu un nœud est perdu. Il faut donc demander à Pacemaker d ignorer le quorum dans cette situation car le fonctionnement par défaut, quand le quorum n est pas atteint, est de couper toutes les ressources. Pour désactiver le quorum, saisir la commande suivante : crm configure property no-quorumpolicy="ignore". Note : comment retrouver un nœud propre? Plusieurs raisons peuvent être à l'origine de l'instabilité d'un Cluster dont : la modification «à la main» du fichier de configuration XML ; si on démarre Heartbeat avant clonage sur la première machine pour tester les fichiers de configuration, il se crée un UUID associé à la machine ; lors du clonage, il maintient cet UUID pour la seconde machine. Heartbeat ne voit donc qu'un nœud et "switche" sans arrêt entre les deux (on le voit parfaitement dans les logs) ; une erreur dans la configuration qu'il est difficile d'annuler via une commande crm. Pour repartir sur une configuration de départ «propre»: arrêter le service Heartbeat sur les 2 machines ; supprimer dans /var/lib/heartbeat les fichiers hostcache et hb_uuid (sur les deux machines) ; supprimer dans /var/lib/heartbeat/crm le fichier cib.xml ; redémarrer Heartbeat. SISR3 ha 5

Annexe 2 : création et configuration des ressources Après avoir installé les services sur chaque nœud du Cluster, il est nécessaire de configurer le comportement de ceux que l'on désire mettre en haute disponibilité. Rappel : un service est une ressource au sens de Pacemaker. La commande crm qui va permettre de configurer les ressources dans le Cluster est implémentée par Pacemaker ; quelque soit le nœud sur laquelle la commande est exécutée, la configuration se propage sur chaque nœud automatiquement en modifiant le fichier cib.xml Comment créer une ressource? La création d une ressource s effectue avec une entrée nommée «primitive» dans la CIB (voir annexe 1). On trouvera au minimum dans la commande : crm configure primitive serviceweb ocf:heartbeat:apache2 Cette «primitive» fait appel à un script d application correspondant au service à mettre en haute disponibilité. Le script du service peut être : De type OCF (http://linux-ha.org/wiki/ocf_resource_agent) qui est un script développé pour Pacemaker : ils sont, pour la plupart, dans le répertoire /usr/lib/ocf/resource.d/heartbeat/ ou /usr/lib/ocf/resource.d/pacemaker ; la liste des scripts est obtenue avec les commandes crm ra list ocf heartbeat et crm ra list ocf pacemaker. Dans la commande l'espace de nom est dans de cas ocf:heartbeat ou ocf:pacemaker. On indique ensuite éventuellement (dans la commande crm configure primitive) des paramètres propres à la ressource et des options de monitoring (voir plus loin les configurations spécifiques). La configuration passe donc par la commande crm que l'on peut utiliser directement en ligne de commande (voir notamment «configuration du failover IP») ou en interactif (voir notamment «configuration de la ressource «serviceweb»). Cette commande se propage sur tous les nœuds (ce qui est très pratique) et modifie bien évidemment le fichier XML sur chaque noeud. Attention, il est très dangereux de modifier ce fichier à la main Configuration du failover d'ip Le failover d'ip (en anglais, fail-over se traduit par «passer outre la panne») est le basculement de l'adresse IP (virtuelle) du serveur maître vers le serveur esclave si le premier venait à défaillir. Première étape : attribution de l'adresse IP virtuelle À minima, on crée une ressource nommée «IPFailover» (le nom est libre) qui va créer une adresse IP virtuelle 10.22.100.220/16 (d'autres options sont disponibles) root@apache1:~# crm configure primitive IPFailover ocf:heartbeat:ipaddr2 params ip="192.168.1.2" cidr_netmask="255.255.0.0" nic="eth0" iflabel="vip" Primitive : argument pour ajouter une primitive regroupant plusieurs valeurs indiquant au Cluster quels scripts utiliser pour la ressource, où le trouver et à quel standard il correspond. Ocf : classe de la ressource (ça pourrait donc aussi être lsb) Hearbeat : fournisseur de la ressource IPaddr2 : ressource gérant les adresses IPv4 virtuelles ==> le script appelé Params : déclaration des paramètres nécessaires à la ressource IPFaillover : le nom de la ressource (il est évidemment libre... mais doit être suffisamment «parlant») IPaddr2 : le script appelé params : suivent les différents paramètres à appliquer SISR3 ha 6

ip= «192.168.1.2» : nom et valeurs du paramètre «ip» cidr_netmask= «255.255.0.0» : masque de sous-réseau nic= «eth0» : carte réseau sur laquelle est appliquée l'adresse IP virtuelle iflabel= «VIP» permet de donner un label à la carte réseau virtuelle. Sans ce label, la VIP n est pas visible avec la commande ifconfig mais seulement avec la commande ip addr show. Remarques : pour connaître tous les paramètres de la primitive IPaddr2 (ainsi que ses options par défaut comme tout ce qui concerne le monitoring de la ressource) : crm ra info ocf:heartbeat:ipaddr2 ; pour visualiser en direct l évolution de la configuration, il est intéressant de réaliser la commande sur un nœud et de laisser tourner un «crm_mon» sur l autre (attendre un peu que la propagation soit effective) en cas d'erreur de syntaxe dans la commande, le système peut demander s'il va quand même enregistrer en terminant son retour d'erreur par «Do you still want to commit?» : il faut évidemment répondre par «n» ; chaque script de la classe ocf permet la supervision de la ressource via l'option monitor (voir ci-après) et/ou la promotion d une ressource dans le cadre d un Cluster actif/actif (comme nous allons le voir dans le Coté labo suivant). Avec crm_mon ou crm status, on peut constater qu'une ressource est configurée : primitive IPFailover ocf:heartbeat:ipaddr2 \ params ip="10.22.100.220" cidr_netmask="255.255.0.0" nic="eth0" op monitor interval="30s" timeout="20s" «op» définit des options et «monitor» est l'action de monitoring du pacemaker : toutes les 30 secondes, Pacemaker va appeler le script OCF avec comme paramètre monitor. Avant le timeout de 20 secondes, on devra avoir un code retour à 0 pour que Pacemaker considère la ressource comme fonctionnelle. Sinon, il arrêtera/relancera la ressource ou effectuera une bascule (selon le paramétrage des autres options). Test du failover d'ip Plusieurs possibilités pour tester la solution mise en place dont : arrêter le serveur ou le service ; mettre un nœud en maintenance : crm node standby sur le nœud que l'on veut rendre inactif (crm node online pour le remettre actif). Un jour, un grand et fort Samouraï se rend auprès d'un maître zen et lui pose cette question : «Dis-moi quelle est la nature du ciel et de l'enfer?» Le maître le regarde étonné et il lui répond : «Pourquoi devrais-je répondre à une question aussi stupide d'un sale ignorant, d'un misérable comme toi. Penses-tu que je devrais dire quoi que ce soit à ce sujet à un minable comme toi?» A ces mots, le samouraï entre alors dans une rage destructrice, il sort son épée, s'avance vers le maître et lève son épée, prêt à lui trancher la tête. Le maître zen dit alors : «L'enfer, c'est ça.» Le samouraï comprend alors qu'il vient de créer son propre enfer, plein de haine, chaud et noir, plein de colère et de rage, pour se protéger contre les paroles du maître. Il voit qu'il s'est enfoncé si loin dans son enfer, qu'il était prêt à tuer quelqu'un. Alors des larmes roulent sur ses joues, il joint les mains et il s'incline pour remercier de cette intuition qui l'illumine. Le maître zen ajoute alors : «Le ciel, c'est ça.» SISR3 ha 7