ISET Radès    TP HA 

Cluster Apache Haute disponibilité avec Pacemaker (Centos 7)

1. Présentation des outils utilisés
Introduction
La haute disponibilité est un sujet important de nos jours car les interruptions de service peuvent
être très coûteuses. Il est prudent de prendre des mesures pour que votre site Web ou votre
application Web continue de fonctionner en cas de panne. Avec la pile Pacemaker, vous pouvez
configurer un cluster à haute disponibilité.

Pacemaker est un gestionnaire de ressources de cluster . Il gère tous les services de cluster
( ressources ) et utilise les fonctionnalités de messagerie et d'adhésion du moteur de
cluster sous-jacent . Nous utiliserons Corosync comme moteur de cluster. Les ressources ont
un agent de ressources , qui est un programme externe qui résume le service.
Dans un cluster actif-passif, tous les services s'exécutent sur un système principal. Si le système
principal échoue, tous les services sont déplacés vers le système de sauvegarde. Un cluster actif-
passif permet d'effectuer des travaux de maintenance sans interruption.
Dans ce TP, vous allez apprendre à créer un cluster actif-passif Apache à haute
disponibilité. Le cluster Web sera adressé par son adresse IP virtuelle et basculera
automatiquement en cas de défaillance d'un nœud.
Vos utilisateurs accéderont à votre application Web par l’adresse IP virtuelle gérée par
Pacemaker. Le service Apache et l'adresse IP virtuelle sont toujours situés sur le même
hôte. Lorsque cet hôte échoue, ils sont migrés vers le deuxième hôte et vos utilisateurs ne
remarqueront pas la panne.

Elies Jebri    Page 1 sur 9 
ISET Radès    TP HA 

Fonctionnalités principales de pacemaker :

 Détecter et réparer les erreurs entre les nodes du cluster
 Compatible STONITH, garantie l’intégrité de vos données
 Autant à l’aise sur les petits que les grands clusters
 Réplique automatiquement sa configuration sur les autres nodes du cluster lorsqu’un
noeud est paramétré
 Gestion du stockage et des ressources cluster
 Support de toutes les architectures redondantes
Pré-requis et architecture
Cet exemple est basé sur l'environnement suivant.
192.168.70.100
(Virtual IP)
|
+----------------------+ | +----------------------+
| [ Node 1 ] |10.0.0.51 | 10.0.0.52| [ Node 2 ] |
| node1.domaine.local +----------+----------+ node2.domaine.local |
| Apache | | Apache |
+----------------------+ +----------------------+
Avant de commencer avec ce TP, vous aurez besoin des éléments suivants :
 Deux VMs CentOS 7 (clonez la VM des TPs), qui constitueront les nœuds du cluster.
Nous les désignerons par node1.domaine.local (adresse IP 10.0.0.51) et
node2.domaine.local (10.0.0.52).
 Le client sera votre machine hôte.
Vous devrez exécuter certaines commandes sur les deux serveurs, et certaines commandes sur
un seul.
2. Réalisation du Cluster
Étape 1 - Configuration de la résolution de nom
Tout d'abord, nous devons nous assurer que les deux hôtes peuvent résoudre le nom d'hôte des
deux nœuds de cluster. Pour ce faire, nous allons ajouter des entrées au fichier /etc/hosts.
Suivez cette étape sur node1 et node2.
Ouvrez /etc/hosts avec nano ou votre éditeur de texte préféré.
nano /etc/hosts
 Ajoutez les entrées suivantes à la fin du fichier.
10.0.0.51 node1.domaine.local node1
10.0.0.52 node2.domaine.local node2
192.168.70.100 www.domaine.local www
 Utilisez l’outil nmtui pour configurer les adresses IP sur les deux nœuds.

Elies Jebri    Page 2 sur 9 
ISET Radès    TP HA 

Étape 2 - Installer Apache

Dans cette section, nous allons installer le serveur Web Apache.
Vous devez effectuer cette étape sur les deux hôtes.
Tout d'abord, installez Apache.
yum install httpd
L'agent de ressources Apache du cluster utilise la page d'état du serveur Apache pour vérifier
l'intégrité du service Apache. Vous devez activer la page d'état en créant le fichier
/etc/httpd/conf.d/status.conf.
nano /etc/httpd/conf.d/status.conf
Cete directive permet l'accès à la page d'état de httpd seulement en local.
ExtendedStatus On

<Location /server-status>
SetHandler server-status
Require local
</Location>Enregistrez et fermez le fichier.
Puis créez le VirtualHost visible par les utilisateurs
nano /etc/httpd/conf.d/site.conf
<VirtualHost *:80>
DocumentRoot /var/www/html
ServerName www.domaine.local
</VirtualHost>
Puis
echo "<b>Site clustérisé</b>" > /var/www/html/index.html
Étape 3 - Installation de Pacemaker
Nous allons maintenant installer la pile Pacemaker.
Vous devez effectuer cette étape sur les deux hôtes.
Installez la pile Pacemaker et le shell de cluster pcs. Nous utiliserons ce dernier plus tard pour
configurer le cluster.
yum install pacemaker pcs
Nous devons maintenant démarrer le démon pcs, utilisé pour la synchronisation de la
configuration de Corosync sur les nœuds.
systemctl start pcsd.service
Pour que le démon soit lancé après chaque redémarrage, nous activerons également le service.
systemctl enable pcsd.service
Une fois ces packages installés, il y aura un nouvel utilisateur sur votre système appelé
hacluster. Après l'installation, la connexion à distance est désactivée pour cet utilisateur. Pour
des tâches telles que la synchronisation de la configuration ou le démarrage des services sur
d'autres nœuds, nous devons définir le même mot de passe pour cet utilisateur.
passwd hacluster

Elies Jebri    Page 3 sur 9 
ISET Radès    TP HA 

Étape 4 - Configuration de Heartbeat (node1)

Maintenant que nos deux hôtes peuvent se parler, nous pouvons configurer l'authentification
entre les deux nœuds en exécutant cette commande sur un hôte (dans notre cas, node1 ).
pcs cluster auth node1 node2
Username: hacluster

Vous devriez voir la sortie suivante:

node1: Authorized
node2: Authorized
Ensuite, nous allons générer et synchroniser la configuration de Corosync sur le même hôte. Ici,
nous nommerons le cluster Webcluster, mais vous pouvez l’appeler comme vous le souhaitez.
pcs cluster setup --name Webcluster node1 node2

Vous verrez la sortie suivante:

Shutting down pacemaker/corosync services...
Redirecting to /bin/systemctl stop pacemaker.service
Redirecting to /bin/systemctl stop corosync.service
Killing any remaining services...
Removing all cluster configuration files...
node1: Succeeded
node2: Succeeded
La configuration corosync est maintenant créée et distribuée sur tous les nœuds. La
configuration est stockée dans le fichier /etc/corosync/corosync.conf.
Étape 5 - Démarrer le cluster
Le cluster peut être démarré en exécutant la commande suivante sur node1.
pcs cluster start --all
pcs cluster enable --all
OU

On peut aussi faire les étapes suivantes pour que Pacemaker et corosync se lancent au
démarrage, nous devons activer les services sur les deux hôtes.
systemctl enable corosync.service
systemctl enable pacemaker.service

Nous pouvons maintenant vérifier le statut du cluster en exécutant la commande suivante sur
l'un des hôtes.
pcs status

Elies Jebri    Page 4 sur 9 
ISET Radès    TP HA 

Vérifiez que les deux hôtes sont marqués comme en ligne dans la sortie.
. . .
Online: [ node1 node2 ]

Full list of resources:

PCSD Status:
node1: Online
node2: Online

Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
Remarque: après la première installation, il peut s'écouler un certain temps avant que les
nœuds soient marqués comme en ligne.
Étape 6 - Désactiver STONITH, ignorer le quorum et désactiver le auto failback
Qu'est-ce que STONITH ?
Vous verrez un avertissement à la sortie pcs status indiquant qu'aucun périphérique STONITH
n'est configuré et que STONITH n'est pas désactivé :
Attention
. . .
WARNING: no stonith devices and stonith-enabled is not false
. . .
Qu'est-ce que cela signifie et pourquoi devriez-vous vous en soucier ?
Lorsque le gestionnaire de ressources en cluster ne peut pas déterminer l'état d'un nœud ou d'une
ressource sur un nœud, le fencing est utilisé pour ramener le cluster à un état connu.
Le fencing au niveau des ressources garantit principalement l’absence de corruption des
données en cas de panne en configurant une ressource. Vous pouvez utiliser le fencing au
niveau des ressources, par exemple, avec DRBD (Distributed Replicated Block Device) pour
marquer le disque d'un nœud comme étant obsolète lorsque le lien de communication est arrêté.
Le fencing de niveau de noeud garantit qu'un nœud n'exécute aucune ressource. Cela se fait en
réinitialisant le nœud et son implémentation s'appelle STONITH (ce qui signifie "tire l'autre
nœud dans la tête"). Pacemaker prend en charge une grande variété de dispositifs de clôture,
par exemple une alimentation sans coupure ou des cartes d'interface de gestion pour serveurs.
Étant donné que la configuration de la clôture au niveau du nœud dépend fortement de votre
environnement, nous allons le désactiver pour ce TP.
pcs property set stonith-enabled=false

Remarque : Si vous envisagez d'utiliser Pacemaker dans un environnement de production,

vous devez planifier une implémentation de STONITH en fonction de votre environnement et
le laisser activé.

Elies Jebri    Page 5 sur 9 
ISET Radès    TP HA 

Qu'est-ce que le quorum ?

Un cluster a un quorum lorsque plus de la moitié des nœuds sont en ligne. Le comportement
par défaut de Pacemaker consiste à arrêter toutes les ressources si le cluster n'a pas de
quorum. Toutefois, cela n’a aucun sens dans un cluster à deux nœuds ; le cluster perdra le
quorum si un nœud échoue.
Pour ce tutoriel, nous dirons à Pacemaker d’ignorer le quorum en définissant le paramètre no-
quorum-policy:
pcs property set no-quorum-policy=ignore

Qu’est-ce que le Failback

Le failback est un processus qui consiste à rétablir les opérations sur une machine ou sur un site
primaire après qu'elles ont été basculées sur une machine ou un site secondaire (un failover).
Nous déciderons de laisser les nœuds dans l’état où ils se trouvent après un failover.
pcs property set default-resource-stickiness="INFINITY"

Vérifions tout cela

pcs property list
Cluster Properties:
cluster-infrastructure: corosync
cluster-name: Webcluster
dc-version: 1.1.12-a14efad
default-resource-stickiness: INFINITY
have-watchdog: false
no-quorum-policy: ignore
stonith-enabled: false
Étape 7 - Configuration de l'adresse IP virtuelle
À partir de maintenant, nous allons interagir avec le cluster via le pcsshell, de sorte que toutes
les commandes ne doivent être exécutées que sur un seul hôte. Peu importe lequel.
Le cluster Pacemaker est maintenant opérationnel et nous pouvons y ajouter la première
ressource, l'adresse IP virtuelle. Pour ce faire, nous allons configurer l'agent de ressources
ocf:heartbeat:IPaddr2, mais abordons d' abord la terminologie.
Chaque nom d'agent de ressources a trois ou deux champs séparés par un signe deux-points:
 Le premier champ est la classe de ressources, qui est la norme à laquelle l'agent de
ressources se conforme. Il indique également à Pacemaker où trouver le script. L’agent
de ressources IPaddr2 est conforme à la norme OCF (Open Cluster Framework).
 Le deuxième champ dépend de la norme. Les ressources OCF utilisent le second champ
pour l'espace de noms OCF.
 Le troisième champ est le nom de l'agent de ressource.

Elies Jebri    Page 6 sur 9 
ISET Radès    TP HA 

Les ressources peuvent avoir des méta-attributs et des attributs d'instance . Les méta-attributs
ne dépendent pas du type de ressource; Les attributs d'instance sont spécifiques à l'agent de
ressources. Le seul attribut d'instance requis de cet agent de ressources est ip (l'adresse IP
virtuelle), mais dans un souci de clarté nous définirons également (le masque de sous-réseau en
notation CIDR) cidr_netmask,.
Les opérations sur les ressources sont des actions que le cluster peut effectuer sur une ressource
(par exemple, démarrer start, arrêter stop, surveiller status). Ils sont indiqués par le mot
clé op. Nous allons ajouter l'opération monitor avec un intervalle de 20 secondes afin que le
cluster vérifie toutes les 20 secondes si la ressource est toujours saine. Ce qui est considéré
comme sain dépend de l'agent de ressource.
Tout d'abord, nous allons créer la ressource d'adresse IP virtuelle. Ici, nous allons
utiliser 192.168.70.100 comme adresse IP virtuelle et Cluster_VIP le nom de la ressource.
sudo pcs resource create Cluster_VIP ocf:heartbeat:IPaddr2 ip=192.168
.70.100 cidr_netmask=24 nic=ens33 op monitor interval=20s

Ensuite, vérifiez le statut de la ressource.

pcs status

Recherchez la ligne suivante dans la sortie :

...
Full list of resources:

Cluster_VIP (ocf::heartbeat:IPaddr2): Started node1

...
L'adresse IP virtuelle est active sur l'hôte node1.
Étape 8 - Ajout de la ressource Apache
Nous pouvons maintenant ajouter la deuxième ressource au cluster, qui sera le service
Apache. L'agent de ressource du service est ocf:heartbeat:apache.
Nous allons nommer la ressource WebServer et définir les attributs de l'instance configfile
(l'emplacement du fichier de configuration Apache) et statusurl (l'URL de la page d'état du
serveur Apache). Nous choisirons à nouveau un intervalle de contrôle de 20 secondes.
pcs resource create WebServer ocf:heartbeat:apache \
configfile /etc/httpd/conf.d/status.conf \
statusurl="http://127.0.0.1/server-status" op monitor interval=20s

Nous pouvons interroger le statut de la ressource comme auparavant.

pcs status

Vous devez voir WebServer dans la sortie exécutée sur node2.

...
Full list of resources:

Elies Jebri    Page 7 sur 9 
ISET Radès    TP HA 

Cluster_VIP (ocf::heartbeat:IPaddr2): Started node1

WebServer (ocf::heartbeat:apache): Started node2
...
Comme vous pouvez le constater, les ressources s'exécutent sur différents hôtes. Nous n'avons
pas encore indiqué à Pacemaker que ces ressources doivent fonctionner sur le même hôte, elles
sont donc réparties de manière homogène sur les nœuds.
Remarque: vous pouvez redémarrer la ressource Apache en l'exécutant ‘pcs resource restart
WebServer’ (par exemple, si vous modifiez la configuration Apache). Assurez-vous de ne pas
utiliser systemctl pour gérer le service Apache.
Étape 9 - Configuration des contraintes de colocation
Presque toutes les décisions d'un cluster Heartbeat, comme le choix de l'emplacement d'une
ressource, sont prises en comparant les scores. Les scores sont calculés par ressource et le
gestionnaire de ressources en cluster choisit le nœud avec le score le plus élevé pour une
ressource particulière. (Si un nœud a un score négatif pour une ressource, celle-ci ne peut pas
s'exécuter sur ce nœud.)
Nous pouvons manipuler les décisions du cluster avec des contraintes. Les contraintes ont un
score. Si une contrainte a un score inférieur à INFINITY, ce n’est alors qu'une
recommandation. Un score d'INFINITY signifie que c'est un must.
Nous voulons nous assurer que les deux ressources sont exécutées sur le même hôte. Nous
allons donc définir une contrainte de colocation avec un score INFINITY.
pcs constraint colocation add WebServer with Cluster_VIP INFINITY

L'ordre des ressources dans la définition de contrainte est important. Ici, nous spécifions que la
ressource Apache (WebServer) doit être exécutée sur les mêmes hôtes sur lesquels l’IP virtuel
(Cluster_VIP) est actif. Cela signifie également que WebServer n'est pas autorisé à s'exécuter
nulle part si Cluster_VIP n'est pas actif.
Il est également possible de définir l'ordre dans lequel les ressources doivent être exécutées en
créant des contraintes d'ordre ou de préférer certains hôtes pour certaines ressources en créant
des contraintes d'emplacement.
pcs constraint order Cluster_VIP then Webserver
Vérifiez que les deux ressources s'exécutent sur le même hôte.
pcs status

...
Full list of resources:

Cluster_VIP (ocf::heartbeat:IPaddr2): Started node1

WebServer (ocf::heartbeat:apache): Started node1
...
Les deux ressources sont maintenant sur node1.

Elies Jebri    Page 8 sur 9 
ISET Radès    TP HA 

Etape 10 : Test du failover

Accédez à l’IP Virtuelle pour vérifier que tout fonctionne.

Vérifiez ensuite les adresses IP sur chacun des nœuds et retrouvez celui qui dispose de la
ressource Cluster_VIP.
[root@node1 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN g
roup default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 00:0c:29:d8:80:68 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.51 /24 brd 10.0.0.255 scope global noprefixroute dyna
mic ens33
valid_lft 1670sec preferred_lft 1670sec
inet 192.168.70.100/24 scope global ens33
valid_lft forever preferred_lft forever

Arrêtez manuellement le nœud actif actuel et assurez-vous que la ressource basculera

normalement vers un autre nœud.
[root @ node01 ~] # pcs cluster stop node1.domaine.local
node1.domaine.local: Stopping Cluster (pacemaker)...
node1.domaine.local: Stopping Cluster (corosync)...

Après vérification, rétablissez le nœud qui était à l’arrêt et observez ce qui se passe.
[root @ node01 ~] # pcs cluster start node1.domaine.local

Conclusion
Vous avez configuré un cluster actif-passif Apache à deux nœuds, accessible par l'adresse IP
virtuelle. Vous pouvez maintenant configurer Apache de façon plus avancée, mais assurez-vous
de synchroniser la configuration sur les hôtes.
Si vous souhaitez distribuer les fichiers de votre application Web parmi les hôtes, vous pouvez
configurer un volume DRBD ou utiliser un LUN commun.

Elies Jebri    Page 9 sur 9