Description : Voici comment mettre en place un HA de serveur Web sans load balancer.
Contexte :
Nous allons mettre en place une solution de HA Open Source entre 2 serveur Web sans solution de loadbalaning (Type HAPorxy, F5 LTM, Alteon, …). Cette solution est basée sur Pacemaker.
Nous partirons du principe que nous avons deux machines Linux fonctionnelles (httpd1 et httpd2) sans iptables et SELinux, dans mon lab se sera deux CentOS 6.
Un point important, la résolution de nom, soit vous renseigner correctement le fichier /etc/hosts soit vous renseignez le DNS, dans ce lab j’ai utilisé /etc/hosts.
Schéma du lab :
Installation et configuration des serveurs Web :
Installation (sur les 2 serveurs) :
Création d’une page web (sur les 2 serveurs) :
Création des images :
Sur le httpd1
Sur le httpd2
Démarrage du service web (sur les 2 serveurs) :
Note : on ne configure pas les services au démarrage car c’est le cluster qui va le gérer.
Test de bon fonctionnement des Webs :
Serveur httpd1
Serveur httpd2
Partie Haute-Disponibilité :
Arrêt d’Apache (sur les 2 serveurs) :
Sur les 2 serveurs
Installation des pacakges (sur les 2 serveurs) :
Configuration du cluster :
sur un serveur, ici httpd1 :
Sur les 2 serveurs :
Un point bloquant peut être le quorum : c’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 va donc falloir demander à Pacemaker d’ignorer le quorum dans cette situation. Le fonctionnement par défaut quand le quorum n’est pas atteint est de couper toutes les ressources !
sur un serveur, ici httpd1 :
Stonith ou “Shoot The Other Node In The Head” . C’est une méthode d’isolation d’un nœud (fencing) qui pour une raison ou une autre ne répond plus. L’idée est d’éviter à tout prix le fameux split-brain qui peut amener tous vos nœuds à fournir le même service (ou à ne plus le fournir du tout). Le nœud jugé hors service sera donc, en général, redémarré ou arrêté électriquement (via IPMI par exemple). Nous n’en avons pas besoins dans notre lab.
Vérifier l’état du cluster (sur les 2 serveurs) :
Configuration Apache pour check de status (sur les 2 serveurs) :
Déclaration des ressources (sur 1 des serveurs):
Vérifier l’état du cluster (sur 1 des serveurs) :
C’est bien, mais L’IP du cluster n’est pas sur le même serveur que la ressource Web …
Affiner la configuration (sur 1 des serveurs) :
La commande de status du service Apache indique qu’il est seulement démarré sur le serveurs “maitre”.
Aller à l’URL http://192.168.5.150 dans un navigateur (fonctionnement nominal) :
Cas de bascule
On éteint le serveur httpd1
Redémmarrage de httpd1
En stoppant juste le service Apache sur httpd1 la bascule n’est pas aussi franche, il y a une bonne dizaine de secondes pour que cela soit effectif.
Il faut faire un cleanup pour repasser sur httpd1, vu que c’est l’admin qui à stopper le service alors que c’est le cluster qui gère normalement les services.