LINUX:Pacemaker - cinq serveurs WEB en Failover, Galera et GlusterFs

De WIKI sur Linux (ADB)
Aller à la navigation Aller à la recherche

→ retour au menu de la Haute disponibilité

But

Autre configuration, nous allons reprendre la configuration présentée à l'article concernant Quatre serveurs WEB en Failover, Fsyncd et ISCSI. Nous y mettrons 5 serveurs WEB en failover au lieu de quatre. Ils seront accompagnés d'un stockage en réplication des fichiers grâce à GlusterFs au lieu d'ISCSI et Fsyncd. Nous y ajoutons la réplication de la base de données grâce à Mariadb-Galera.


Matériel et adressage IP

Dans notre exemple, nous utilisons cinq serveurs Web mis en cluster. Pour améliorer les performances et de sécurité, le trafic généré par la réplication se fera au travers d'un second réseau ("192.168.2.0/24"), chaque machine est pour cette raison équipée d'une seconde carte réseau.

Le schéma ci-dessous nous montre l'adressage IP et le nom de ces machines. En outre pour mettre la fonction Failover, une adresse IP virtuelle est ajoutée à chaque serveur Web.

LINUX:Failover.web5.pdf


Principe

En mode d'utilisation complet, nous avons cinq services Web répartis sur cinq machines mises en cluster: "sv0.home.dom", "sv1.home.dom", "sv2.home.dom", "sv3.home.dom" et "sv4.home.dom". A chaque service Web est associé une adresse IP virtuelle propre et un nom de domaine virtuel propre ou nom de machine virtuelle. Ce nom de machine virtuelle et son adresse IP virtuelle seront repris comme "VirtualHost" dans la configuration du service Web HTTP d'Apache.


Associations:

Description Nom de machine virtuelle Adresse IP virtuelle Machine réelle préférée Adresse IP réelle préférée
Service Web n° 5 cluster5.home.dom 192.168.1.75 sv0.home.dom 192.168.1.70
Service Web n° 6 cluster6.home.dom 192.168.1.76 sv1.home.dom 192.168.1.71
Service Web n° 7 cluster7.home.dom 192.168.1.77 sv2.home.dom 192.168.1.72
Service Web n° 8 cluster8.home.dom 192.168.1.78 sv3.home.dom 192.168.1.73
Service Web n° 9 cluster9.home.dom 192.168.1.79 sv4.home.dom 192.168.1.74


Dans de nombreuses configurations d'un site Web, nous avons les composantes suivantes:

  • le code statique du site écrit par exemple en HTML et en PHP
  • une base de sonnées SQL contenant la partie dynamique de mise en page et du contenu du site
  • un espace disque contenant tous les médias dynamiques téléchargés (images, film, documents PDF,...) qui viendront étoffer le site.

C'est ce que nous rencontrons dans des systèmes de gestion de contenu (CMS) tels Wordpress, Mediawiki, Drupal, Joomla, SPIP,...


Le code statique du site doit être accessible à partir de chaque machine Web. Il faut aussi un espace utilisé pour l'hébergement des médias dynamiques téléchargés. Tous ces fichiers seront hébergés sous une arborescence placée sous le répertoire "/web". Cet espace disque se retrouvera sur chaque machine et seront identiques grâce au système de réplication présenté à l'article sur Glusterfs. Le serveur GlusterFs et le client GlusterFs (Fuse) seront sur la même machine. Le montage de l'espace disque sera donc local.


Classiquement les sites Web ont besoin d'un accès à une base de données. Nous utiliserons le gestionnaire de base de données MariaDb. Cette base se retrouvera sur chaque machine; cet accès sera local. Nous utiliserons le système de réplication entre base de données présenté à l'article sur Galera - Cluster de MariaDB. Les cinq bases de données seront donc identiques.


Ces deux types de réplications se feront au travers du réseau secondaire "192.168.2.0/24".


En cas de défaillance d'une machine du cluster, les différentes ressources de la machine défaillante seront transférés sur une des quatre autres machines et ainsi de suite pour aboutir dans le cas extrême que toutes les ressources soient concentrées sur deux machines. Au delà ces services s'arrêteront.


Prérequis

Configurations de base

En premier, les Prérequis doivent être effectués.


Fichier "hosts"

Sur chaque machine du cluster, on ajoute un nom aux différentes adresses réseaux. On le fait en local dans le fichier "/etc/hosts" suivant le schéma ci-dessus. Son contenu devient: 

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
 
192.168.1.70 sv0.home.dom
192.168.1.71 sv1.home.dom
192.168.1.72 sv2.home.dom
192.168.1.73 sv3.home.dom 
192.168.1.74 sv4.home.dom 
 
192.168.2.70 dt0.home.dom
192.168.2.71 dt1.home.dom
192.168.2.72 dt2.home.dom
192.168.2.73 dt3.home.dom 
192.168.2.74 dt4.home.dom 
 
192.168.1.75 cluster5.home.dom 
192.168.1.76 cluster6.home.dom 
192.168.1.77 cluster7.home.dom 
192.168.1.78 cluster8.home.dom
192.168.1.79 cluster9.home.dom 
  
# serveur mail
192.168.1.110 servermail.home.dom home.dom


Configuration des services nécessaires

Nous avons à configurer les différents services nécessaires qui vont être utilisés par Pacemaker.


Service GlusterFs

Sur chaque machine, il faut configurer le serveur Gluster. La configuration se base sur celle présentée dans l'article sur Glusterfs. Toute la configuration centralisée se fera à partir de la machine "sv0.home.dom".


Démarrage

Sur chaque machine, on lance le service "glusterd.service": 

systemctl start glusterd.service


Constitution du "Pool"

On constitue le "Pool" de serveurs qui va utiliser le réseau "192.168.2.0/24". Voici la suite des commandes: 

gluster peer probe dt1.home.dom
gluster peer probe dt2.home.dom
gluster peer probe dt3.home.dom
gluster peer probe dt4.home.dom


Constitution du volume en réplication

On crée ensuite le volume en réplication "diskgfs1" sur les cinq machines: 

gluster volume create diskgfs1 replica 5 transport tcp dt0.home.dom:/disk1/glusterfs/brique1 dt1.home.dom:/disk1/glusterfs/brique1 \
                                                       dt2.home.dom:/disk1/glusterfs/brique1 dt3.home.dom:/disk1/glusterfs/brique1 \
                                                       dt4.home.dom:/disk1/glusterfs/brique1

qui se placera sur un disque indépendant, sous le répertoire "/disk1/glusterfs".


Services HTTPD et PHP

Le service Web est identique à celui présenté à l'article sur la Configuration du service WEB. La seule différence est qu'il faut l'étendre au cinquième site: "cluster9.home.dom" et à la cinquième machine.

Les fichiers des sites se trouvent sous le répertoire "/web". Cet espace sera monté sur le volume GlusterFs configuré ci-dessus. 

mkdir /web
mount -t glusterfs  localhost:/diskgfs1 /web


Service MariaDb-Galera

La configuration se base sur celle présentée dans l'article sur Galera - Cluster de MariaDB. Notons que comme nous avons un nombre impaire de serveurs, le service Garb n'est pas nécessaire.


Configuration de MariaDb et de Galera

Nous prendrons la même configuration; nous mettrons la base de données dans le répertoire "/produc/mysql". Nous garderons aussi l'utilisation du répertoire "/produc/mysql.bat" et de son script "mysql.bat.

Seules deux options liées à Galera seront adaptées dans le fichier de configuration du serveur "/etc/my.cnf.d/mariadb-server.cnf".

Celle liée à l'ensemble des machines du cluster utilisant le réseau "192.168.2.0/24": 

wsrep_cluster_address = "gcomm://192.168.2.70,192.168.2.71,192.168.2.72,192.168.2.73,192.168.2.74"

Et comme nous avons deux interfaces réseaux, il faut spécifier l'option "wsrep_node_address". Sur chaque machine, il faut mettre l'adresse IP de son interface réseau ETH2. Dans cet exemple, c'est celle de la machine "sv1.home.dom": 

wsrep_node_address="192.168.2.71"


Configuration du service "checkgalera.service"

Nous utilisons le service "checkgaler.service" vu à l'article concernant la MariaDB/Galera - Solution d'automatisation de démarrage.

Il faut adapter le fichier "/manager/galera/hosts.txt": 

sv0.home.dom
sv1.home.dom
sv2.home.dom
sv3.home.dom
sv4.home.dom


Configuration du service Rsyncd

Le service précédent utilise le service Rsyncd (voir MariaDB/Galera - Solution d'automatisation de démarrage). La seule option à adapter dans le fichier "/etc/rsyncd.conf" est liée à la sécurité: 

hosts allow = 192.168.1.70 192.168.1.71 192.168.1.72 192.168.1.73 192.168.1.74


Initialisation

Après la configuration, il est préférable de lancer une fois ces services avant d'aborder Pacemaker pour au moins initialiser correctement MariaDb. Pour initier au début le processus, on lance une première fois sur une machine la commande: 

galera_new_cluster

Ensuite on peut lancer sur chaque machine le service "checkgalera.service": 

systemctl start checkgalera.service

On les arrête ensuite.


Arrêt des services

Tous ces services que nous venons de configurer, nous avons dû les lancer pour effectuer les configurations.

Mais ce sera le rôle de Pacemaker de les gérer. Il faut donc les désactiver et les arrêter avant d'aborder la configuration de Pacemaker.

Sur toutes les machines, on effectue ces tâches: 

umount /web

systemctl stop httpd.service
systemctl stop php-fpm.service
systemctl stop glusterd.service
systemctl stop mariadb.service
systemctl stop rsyncd.service
systemctl stop checkgalera.service

systemctl disable httpd.service
systemctl disable php-fpm.service
systemctl disable glusterd.service
systemctl disable mariadb.service
systemctl disable rsyncd.service
systemctl disable checkgalera.service


Configuration de base de Pacemaker

La Configuration de base de Pacemaker doit être effectuée avec quelques modifications car nous avons cinq machines dans le cluster au lieu de deux. Nous allons passer rapidement en revue ces opérations.


Opérations locales

Sur chaque machine:

  • le mot de passe de l'utilisateur "hacluster" est à implémenter. "Chasse4321Eau" pour mémoire.
  • le service "pcsd.service" est à configurer et est lancé.


Initialisation du cluster

Pour initialiser le cluster, on effectue ces opérations sur une seule machine du cluster: 

pcs host auth sv0.home.dom sv1.home.dom sv2.home.dom sv3.home.dom sv4.home.dom -u hacluster -p Chasse4321Eau
pcs cluster setup fo_cluster \
 sv0.home.dom addr=192.168.1.70 sv1.home.dom addr=192.168.1.71 sv2.home.dom addr=192.168.1.72 \
 sv3.home.dom addr=192.168.1.73 sv4.home.dom addr=192.168.1.74 \
 transport knet ip_version=ipv4 link transport=udp mcastport=5420


Quorum

Nous maintenons la contrainte du "quorum" avec la commande: 

pcs property set no-quorum-policy=stop

le "quorum" est de 3; c'est à dire que s'il n'y a pas au moins 3 machines actives, le système s'arrête.

Il est conseillé d'avoir au moins trois serveurs actifs pour un volume GlusterFs en réplication mais nous voulons définir le "quorum" soit de 2. Dans un autre article, nous avions joué sur l'option "expected_votes" dans le fichier "/etc/corosync/corosync.conf". Mais cette valeur n'est prise en compte que si elle est supérieure ou égale au nombre de machines présentes dans le cluster. Nous allons utiliser l'option "last_man_standing".


Modification de la configuration de Corosync

Pour atteindre ce quorum de deux, il faut adapter sur chaque machine du cluster, le fichier "/etc/corosync/corosync.conf". La dernière commande a créé ce fichier. Dans la section "quorum", on va ajouter l'option "last_man_standing: 1". Cette option recalcule le "quorum" en fonction du nombre de machines actives dans le cluster et non sur base du nombre total de machines configurées dans le cluster.

Ce fichier devient pour la section "quorum": 

quorum {
   provider: corosync_votequorum
   last_man_standing: 1
}

Avec cette configuration, le "quorum" minimum sera de 2 et c'est seulement quand il ne restera qu'une machine active que le système de Failover s'arrêtera.

Notons que pour que cette modification soit effective, il faut arrêter puis redémarrer le cluster: 

pcs cluster stop --all
pcs cluster start --all


Fin de la configuration

Par la même occasion exécutez la fin de la configuration de base: 

pcs property set stonith-enabled=false
pcs property set no-quorum-policy=stop

La dernière spécifie que si le quorum n'est pas atteint, les ressources de Pacemaker sont arrêtées.


Configuration des adresses IP virtuelle et des serveurs Web sous Pacemaker

Script

On effectue la suite des commandes suivantes à partir d'une des machines du cluster. On peut les mettre dans un script. 

#!/bin/bash
 
pcs resource create ClusterIP5 ocf:heartbeat:IPaddr2 ip=192.168.1.75 nic=eth1 cidr_netmask=24 iflabel=ethcl5 lvs_support=true op monitor interval=30s
pcs constraint location ClusterIP5 prefers sv0.home.dom=400
pcs constraint location ClusterIP5 prefers sv1.home.dom=100
pcs constraint location ClusterIP5 prefers sv2.home.dom=100
pcs constraint location ClusterIP5 prefers sv3.home.dom=100
pcs constraint location ClusterIP5 prefers sv4.home.dom=100
 
pcs resource create ClusterIP6 ocf:heartbeat:IPaddr2 ip=192.168.1.76 nic=eth1 cidr_netmask=24 iflabel=ethcl6 lvs_support=true op monitor interval=30s
pcs constraint location ClusterIP6 prefers sv0.home.dom=100
pcs constraint location ClusterIP6 prefers sv1.home.dom=400
pcs constraint location ClusterIP6 prefers sv2.home.dom=100
pcs constraint location ClusterIP6 prefers sv3.home.dom=100
pcs constraint location ClusterIP6 prefers sv4.home.dom=100
 
pcs resource create ClusterIP7 ocf:heartbeat:IPaddr2 ip=192.168.1.77 nic=eth1 cidr_netmask=24 iflabel=ethcl7 lvs_support=true op monitor interval=30s
pcs constraint location ClusterIP7 prefers sv0.home.dom=100
pcs constraint location ClusterIP7 prefers sv1.home.dom=100
pcs constraint location ClusterIP7 prefers sv2.home.dom=400
pcs constraint location ClusterIP7 prefers sv3.home.dom=100
pcs constraint location ClusterIP7 prefers sv4.home.dom=100
 
pcs resource create ClusterIP8 ocf:heartbeat:IPaddr2 ip=192.168.1.78 nic=eth1 cidr_netmask=24 iflabel=ethcl8 lvs_support=true op monitor interval=30s
pcs constraint location ClusterIP8 prefers sv0.home.dom=100
pcs constraint location ClusterIP8 prefers sv1.home.dom=100
pcs constraint location ClusterIP8 prefers sv2.home.dom=100
pcs constraint location ClusterIP8 prefers sv3.home.dom=400
pcs constraint location ClusterIP8 prefers sv4.home.dom=100
 
pcs resource create ClusterIP9 ocf:heartbeat:IPaddr2 ip=192.168.1.79 nic=eth1 cidr_netmask=24 iflabel=ethcl9 lvs_support=true op monitor interval=30s
pcs constraint location ClusterIP9 prefers sv0.home.dom=100
pcs constraint location ClusterIP9 prefers sv1.home.dom=100
pcs constraint location ClusterIP9 prefers sv2.home.dom=100
pcs constraint location ClusterIP9 prefers sv3.home.dom=100
pcs constraint location ClusterIP9 prefers sv4.home.dom=400
 
pcs resource create ClusterGlusterd systemd:glusterd op monitor interval=30s clone
 
pcs resource create ClusterRsyncd systemd:rsyncd op monitor interval=30s clone
pcs constraint order ClusterGlusterd-clone then start ClusterRsyncd-clone
 
pcs resource create ClusterCheckGalera systemd:checkgalera op monitor interval=30s clone
pcs constraint order ClusterRsyncd-clone then start ClusterCheckGalera-clone
 
pcs resource create ClusterFsWeb ocf:heartbeat:Filesystem \
  device="localhost:/diskgfs1" \
  directory="/web" fstype="glusterfs" \
  "options=defaults,_netdev" \
  op monitor interval=20s on-fail=stop clone
pcs constraint order ClusterCheckGalera-clone then start ClusterFsWeb-clone
 
pcs resource create ClusterHttpd systemd:httpd op monitor interval=30s clone
pcs constraint order ClusterFsWeb-clone then start ClusterHttpd-clone
 
pcs resource create ClusterPhp systemd:php-fpm àp monitor interval=30s clone
pcs constraint order ClusterHttpd-clone then start ClusterPhp-clone
 
pcs resource create ClusterMailTo ocf:heartbeat:MailTo email=root subject="FailOver_Home" op monitor interval=30s clone
pcs constraint order ClusterPhp-clone then start ClusterMailTo-clone


Ajout des ressources des adresses IP virtuelles

Nous créons les ressources "ClusterIP5", "ClusterIP6", "ClusterIP7", "ClusterIP8" et "ClusterIP9" grâce à la fonction "ocf:heartbeat:IPaddr2".


On remarque qu'on a ajouté des contraintes de localisation par machine du cluster. Pour chacune de ces ressources, une machine différente préférentielle a été choisie. La ressource "ClusterIP5" sera activée sur la machine "sv0.home.dom" (valeur "400") et ainsi de suite. Chaque machine aura sa propre adresse IP virtuelle prédéfinie. Dans le cas d'une déficience de cette machine, cette ressource sera placée aléatoirement sur une des trois autres machines du cluster; elles ont en effet le même score préférentiel (valeur "100").


Ajout des ressources clonées

Les lignes suivantes créent sept ressources de type clone; ces ressources se retrouveront d'office sur toutes les machines du cluster.

  • La ressource "ClusterGlusterd" va activer le service GlusterFs configuré ci-dessus.
  • La ressource "ClusterRsyncd" va activer le service Rsync configuré ci-dessus.
  • La ressource "ClusterCheckGalera" va activer le service CheckGalera configuré ci-dessus qui lancera le service MariaDb.
  • La ressource "ClusterFsWeb" va monter le volume "diskgfs1" local sur le répertoire "/web".
  • La ressource "ClusterHttpd" va activer le service Apache configurée ci-dessus.
  • La ressource "ClusterPhp" va activer le service Php.
  • La ressource "ClusterMailTo" va activer les notifications par mail.

Nous avons intercalé le lancement de Rsyncd et MariaDb entre le service Glusterd et le montage du volume afin de laisser à GlusterFs le temps de se lancer.

Nous avons ordonné l'ordre des lancements de ces services.


Statut

Après cette opération, l'état du cluster peut être visualisé par la commande: 

crm_mon -1

qui donne dans le cas des cinq machines actives: 

Cluster Summary:
 * Stack: corosync (Pacemaker is running)
 * Current DC: sv3.home.dom (version 2.1.6-4.fc38-6fdc9deea29) - partition with quorum
 * Last updated: Mon Jun 19 14:12:15 2023 on sv1.home.dom
 * Last change:  Mon Jun 19 14:09:15 2023 by root via cibadmin on sv1.home.dom
 * 5 nodes configured
 * 40 resource instances configured
 
Node List:
 * Online: [ sv0.home.dom sv1.home.dom sv2.home.dom sv3.home.dom sv4.home.dom ]
 
Active Resources:
 * ClusterIP5  (ocf::heartbeat:IPaddr2):        Started sv0.home.dom
 * ClusterIP6  (ocf::heartbeat:IPaddr2):        Started sv1.home.dom
 * ClusterIP7  (ocf::heartbeat:IPaddr2):        Started sv2.home.dom
 * ClusterIP8  (ocf::heartbeat:IPaddr2):        Started sv3.home.dom
 * ClusterIP9  (ocf::heartbeat:IPaddr2):        Started sv4.home.dom
 * Clone Set: ClusterGlusterd-clone [ClusterGlusterd]:
   * Started: [ sv0.home.dom sv1.home.dom sv2.home.dom sv3.home.dom sv4.home.dom ]
 * Clone Set: ClusterFsWeb-clone [ClusterFsWeb]:
   * Started: [ sv0.home.dom sv1.home.dom sv2.home.dom sv3.home.dom sv4.home.dom ]
 * Clone Set: ClusterHttpd-clone [ClusterHttpd]:
   * Started: [ sv0.home.dom sv1.home.dom sv2.home.dom sv3.home.dom sv4.home.dom ]
 * Clone Set: ClusterPhp-clone [ClusterPhp]:
   * Started: [ sv0.home.dom sv1.home.dom sv2.home.dom sv3.home.dom sv4.home.dom ]
 * Clone Set: ClusterMailTo-clone [ClusterMailTo]:
   * Started: [ sv0.home.dom sv1.home.dom sv2.home.dom sv3.home.dom sv4.home.dom ]
 * Clone Set: ClusterRsyncd-clone [ClusterRsyncd]:
   * Started: [ sv0.home.dom sv1.home.dom sv2.home.dom sv3.home.dom sv4.home.dom ]
 * Clone Set: ClusterCheckGalera-clone [ClusterCheckGalera]:
   * Started: [ sv0.home.dom sv1.home.dom sv2.home.dom sv3.home.dom sv4.home.dom ]




→ retour au menu de la Haute disponibilité

Récupérée de « https://www.adbweb.gslb.eu/wiki/index.php?title=LINUX:Pacemaker_-_cinq_serveurs_WEB_en_Failover,_Galera_et_GlusterFs&oldid=4875 »