TOC

Comment configurer un cluster Apache actif-passif à l’aide de Pacemaker sur CentOS 7

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 (resources) et utilise les capacités de messagerie et d’appartenance du cluster engine sous-jacent. Nous utiliserons Corosync comme moteur de cluster. Les ressources ont un agent de ressource, 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 didacticiel, 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.

Conditions préalables

Avant de commencer avec ce tutoriel, vous aurez besoin des éléments suivants:

  • Deux droplets CentOS 7, qui constitueront les nœuds du cluster. Nous les désignerons par webnode01 (adresse IP: `) et webnode02 (adresse IP: `).

  • Un utilisateur sur les deux serveurs avec des privilèges root. Vous pouvez le configurer en suivant ce tutoriel Initial Initial Server avec CentOS 7.

Vous devrez exécuter certaines commandes sur les deux serveurs, et certaines commandes sur un seul.

É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 du cluster. Pour ce faire, nous ajouterons des entrées au fichier + / etc / hosts +. Suivez cette étape sur webnode01 et webnode02.

Ouvrez + / etc / hosts + avec + nano + ou votre éditeur de texte préféré.

sudo nano /etc/hosts

Ajoutez les entrées suivantes à la fin du fichier.

/ etc / hosts

webnode01.example.com webnode01
webnode02.example.com webnode02

Enregistrez et fermez le fichier.

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

sudo yum install httpd

L’agent de ressources Apache 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 +.

sudo nano /etc/httpd/conf.d/status.conf

Collez la directive suivante dans ce fichier. Ces directives permettent l’accès à la page d’état à partir de localhost mais pas à partir d’un autre hôte.

/etc/httpd/conf.d/status.conf

<Location /server-status>
  SetHandler server-status
  Order Deny,Allow
  Deny from all
  Allow from 127.0.0.1
</Location>

Enregistrez et fermez le fichier.

É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 ultérieurement pour configurer le cluster.

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

sudo systemctl start pcsd.service

Pour que le démon soit démarré après chaque redémarrage, nous activerons également le service.

sudo systemctl enable pcsd.service

Après avoir installé ces paquets, 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.

sudo passwd hacluster

Étape 4 - Configuration du stimulateur cardiaque

Ensuite, nous autoriserons le trafic de cluster dans FirewallD pour permettre à nos hôtes de communiquer.

Tout d’abord, vérifiez si FirewallD est en cours d’exécution.

sudo firewall-cmd --state

S’il ne fonctionne pas, démarrez-le.

sudo systemctl start firewalld.service

Vous devrez le faire sur les deux hôtes. Une fois qu’il est lancé, ajoutez le service + high-availability + à FirewallD.

sudo firewall-cmd --permanent --add-service=high-availability

Après cette modification, vous devez recharger FirewallD.

sudo firewall-cmd --reload

Si vous souhaitez en savoir plus sur FirewallD, vous pouvez lire le sur la façon de procéder. configurer FirewallD sur CentOS 7.

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, * webnode01 *).

sudo pcs cluster auth webnode01 webnode02
Username:

Vous devriez voir la sortie suivante:

Sortie

webnode01: Authorized
webnode02: Authorized

Nous allons ensuite générer et synchroniser la configuration de Corosync sur le même hôte. Ici, nous nommerons le cluster * webcluster *, mais vous pourrez l’appeler comme vous le souhaitez.

sudo pcs cluster setup --name  webnode01 webnode02

Vous verrez le résultat suivant:

Sortie

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...
webnode01: Succeeded
webnode02: Succeeded

La configuration de 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 webnode01.

sudo pcs cluster start --all

Pour que Pacemaker et corosync démarrent au démarrage, nous devons activer les services sur les deux hôtes.

sudo systemctl enable corosync.service
sudo 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.

sudo pcs status

Vérifiez que les deux hôtes sont marqués comme étant en ligne dans la sortie.

Sortie

. . .

Online: [ webnode01 webnode02 ]

Full list of resources:


PCSD Status:
 webnode01: Online
 webnode02: Online

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

Étape 6 - Désactiver STONITH et ignorer le quorum

Qu’est-ce que STONITH?

Vous verrez un avertissement à la sortie de + 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, fencing est utilisé pour ramener le cluster à un état connu.

La configuration du niveau de ressources garantit essentiellement qu’il n’y a pas de corruption de données en cas de panne en configurant une ressource. Vous pouvez utiliser la séparation 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é.

Node au niveau de nœud s’assure 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 (qui signifie "tire l’autre nœud dans la tête"). Le stimulateur cardiaque prend en charge une grande variété de dispositifs d’escrime, par exemple: une alimentation sans coupure ou des cartes d’interface de gestion pour les serveurs.

Étant donné que la configuration de la clôture au niveau du noeud dépend fortement de votre environnement, nous allons le désactiver pour ce tutoriel.

sudo pcs property set stonith-enabled=false

Qu’est-ce que le quorum?

Un cluster a quorum lorsque plus de la moitié des nœuds sont en ligne. Le comportement par défaut du pacemaker est d’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 +:

sudo pcs property set no-quorum-policy=ignore

Étape 7 - Configuration de l’adresse IP virtuelle

A partir de maintenant, nous allons interagir avec le cluster via le shell + pcs +, 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.

Les ressources peuvent avoir meta-attributs et instance attributs. 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 allons également définir + cidr_netmask + (le masque de sous-réseau en notation CIDR).

Les opérations de ressources sont les actions que le cluster peut effectuer sur une ressource (par exemple, démarrer, arrêter, surveiller). 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 ressources.

Tout d’abord, nous allons créer la ressource d’adresse IP virtuelle. Ici, nous allons utiliser + 127.0.0.2 + comme adresse IP virtuelle et * Cluster_VIP * pour le nom de la ressource.

sudo pcs resource create Cluster_VIP ocf:heartbeat:IPaddr2 ip= cidr_netmask=24 op monitor interval=20s

Ensuite, vérifiez le statut de la ressource.

sudo pcs status

Recherchez la ligne suivante dans la sortie:

Sortie

...
Full list of resources:

Cluster_VIP    (ocf::heartbeat:IPaddr2):   Started webnode01
...

L’adresse IP virtuelle est active sur l’hôte webnode01.

Étape 8 - Ajout de la ressource Apache

Nous pouvons maintenant ajouter la deuxième ressource au cluster, qui servira le service Apache. L’agent de ressource du service est + ocf: heartbeat: apache +.

Nous nommerons la ressource + WebServer + et définirons les attributs d’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.

sudo pcs resource create WebServer ocf:heartbeat:apache configfile=/etc/httpd/conf/httpd.conf statusurl="http://127.0.0.1/server-status" op monitor interval=20s

Nous pouvons interroger le statut de la ressource comme avant.

sudo pcs status

Vous devriez voir * Web Server * dans la sortie exécutée sur Webnode 02.

Sortie

...
Full list of resources:

Cluster_VIP    (ocf::heartbeat:IPaddr2):   Started webnode01
WebServer  (ocf::heartbeat:apache):    Started webnode02
...

Comme vous pouvez le constater, les ressources s’exécutent sur différents hôtes. Nous n’avions pas encore indiqué à Pacemaker que ces ressources devaient s’exécuter sur le même hôte. Elles sont donc réparties de manière homogène sur les nœuds.

Étape 9 - Configuration des contraintes de colocation

Presque toutes les décisions d’un cluster de stimulateurs cardiaques, 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, il ne s’agit que d’une recommandation. Un score d’INFINITE 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.

sudo pcs constraint colocation add WebServer 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 que l’adresse IP virtuelle (+ Cluster_VIP +) est active. Cela signifie également que + WebSite + n’est pas autorisé à s’exécuter n’importe où 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.

Vérifiez que les deux ressources s’exécutent sur le même hôte.

sudo pcs status

Sortie

...
Full list of resources:

Cluster_VIP    (ocf::heartbeat:IPaddr2):   Started webnode01
WebServer  (ocf::heartbeat:apache):    Started webnode01
...

Les deux ressources sont maintenant sur webnode01.

Conclusion

Vous avez configuré un cluster actif-passif Apache à deux nœuds, accessible par l’adresse IP virtuelle. Vous pouvez maintenant configurer Apache plus avant, mais assurez-vous de synchroniser la configuration sur les hôtes. Vous pouvez écrire un script personnalisé pour cela (par exemple, avec + rsync +) ou vous pouvez utiliser quelque chose comme csync2.

Si vous souhaitez distribuer les fichiers de votre application Web parmi les hôtes, vous pouvez configurer un volume DRBD et l’intégrer à Pacemaker].

Related