« LINUX:Pacemaker - deux routers en failover - trois serveurs WEB en Loadbalancing, Galera et GlusterFs » : différence entre les versions

De WIKI sur Linux (ADB)
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
Aucun résumé des modifications
Ligne 65 : Ligne 65 :
=Configuration des services sur les serveurs Web=
=Configuration des services sur les serveurs Web=
Nous avons à configurer les différents services nécessaires qui vont être utilisés par Pacemaker. Ces configurations sont à faire sur les quatre serveurs Web:  
Nous avons à configurer les différents services nécessaires qui vont être utilisés par Pacemaker. Ces configurations sont à faire sur les quatre serveurs Web:  
"192.168.2.71", "192.168.2.72" et "192.168.2.73".
"192.168.2.71", "192.168.2.72" et "192.168.2.73". Voyez l'article sur le [[LINUX:Routage statique|Routage statique]].
 
En pratique, dans le fichier de l'interface du réseau "192.168.2.0/24" dans le répertoire "/etc/NetworkManager/system-connections", on ajoute les deux lignes suivantes sous la section "[ipv4]":
----
[ipv4]
...
route1=192.168.1.0/24,192.168.2.75,101
route2=192.168.1.0/24,192.168.2.74,102
----
 
 
==Routage==
Comme l'adresse IP de la passerelle sera changeante car c'est celle de l'adresse IP virtuelle du router maître, elle sera définie via Pacemaker. Mais quand Pacemaker est arrêté, il faut y pallier. Pour cette raison, nous ajoutons deux adresses IP de routage statique; l'une va vers l'adresse IP "192.168.2.74" et l'autre vers "192.168.2.75".




Ligne 176 : Ligne 188 :
  systemctl disable checkgalera.service
  systemctl disable checkgalera.service


=Configuration des paramètres et des services sur le router=
Les routers "sv4.home.dom" et "sv5.home.dom" demandent quelques configurations et service.
==Activer le routage==
Sur les routers Linux, il ne faut pas oublier d'activer le transfert inter-réseaux en ajoutant un fichier, par exemple "router.conf", dans le répertoire "/etc/sysctl.d". Ce fichier doit contenir la ligne:
----
net.ipv4.ip_forward = 1
----
On active cette fonctionnalité par un redfémarrage ou via la commande:
sysctl -p /etc/sysctl.d/router.conf
==SSL==
Nous avons configuré le service Web qui utilise le cryptage SSL et les certificats associés: HTTPS sur les serveurs Web. Pour valiser ces connexions, Ldirectord doit aussi valider leurs certificats.
Mais les certificats utilisés n'ont pas été validés par une autorité de certification officielle (CA). Il nous faut l'intégrer à la liste officielle du router comme expliqué dans l'article sur les Certificats sous Linux.
Dans l'article sur le [[LINUX:Pacemaker - Paramétrage des services en Failover|Paramétrage des services en Failover]], nous avions créé les certificats. Le certificat de l’autorité de certification (CA) se nomme "ca.home.crt". On va le copier dans le répertoire "/etc/pki/ca-trust/source/anchors" du router "cluster.home.dom". Ensuite on exécute la commande:
update-ca-trust
pour l'intégrer à la liste officielle des autorités de certification officielle (CA).
==Configuration de Ldirectord==
Le fichier de configuration se nomme "/etc/ha.d/ldirectord.cf". Il existe plusieurs types de configuration. Voici le contenu choisi:
----
emailalert="root"
emailalertfreq=3600
emailalertstatus=all
quiescent=yes
checkinterval=20
fork=yes
 
virtual=192.168.1.75:80
        real=192.168.2.71:80 masq 65000
        real=192.168.2.72:80 masq 65000
        real=192.168.2.73:80 masq 65000
        request="vivant.html"
        receive="Je suis vivant."
        checktype=negotiate
        service=http
        scheduler=lblcr
        persistent=3600
        protocol=tcp
        checkport=80
 
virtual=192.168.1.75:443
        real=192.168.2.71:443 masq 65000
        real=192.168.2.72:443 masq 65000
        real=192.168.2.73:443 masq 65000
        request="vivant.html"
        receive="Je suis vivant."
        checktype=negotiate
        service=https
        scheduler=lblcr
        persistent=3600
        protocol=tcp
        checkport=443
----
Cette configuration permet de répartir vers nos trois serveurs Web, les protocoles HTTP et HTTPS en validant le contenu de la page "vivant.html".
==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:
systemctl stop ldirectord.service
systemctl disable ldirectord.service





Version du 25 juin 2023 à 15:39


retour au menu de la Haute disponibilité


But

Cette configuration est très semblable à la précédente, Quatre serveurs WEB en Loadbalancing, Galera et GlusterFs. La différence est qu'on met en Failover deux routers, qui utilisent Ldirectord comme répartiteur de requêtes. Les trois serveurs Web sont en loadbalancing. Ils utilisent en outre les fonctionnalités de GlusterFs et de MariaDb-Galera qui travaillent en réplication.


Matériel et adressage IP

Dans notre exemple, nous utilisons trois serveurs Web mis en cluster sous le réseau "192.168.2.0/24". Pour améliorer les performances et de sécurité, le trafic généré par la réplication des espaces disques et des bases de données se fera au travers d'un troisième réseau ("192.168.3.0/24"), chaque machine est pour cette raison équipée d'une seconde carte réseau. La fonctionnalité de Loadbalancing est assurée par deux routers qui fait la répartition des tâches et la liaison avec la Lan d'entrée. Ces deux routers sont configurés en Failover.

Le schéma ci-dessous nous montre l'adressage IP et le nom de ces machines.

LINUX:Loadbalancing.web3.pdf


Principe

Nous avons trois serveurs Web gérants le même site. La charge Web sera répartie équitablement entre ces trois serveurs Web. Cette tâche est assurée par le paquet Ldirectord en mode "Mask". Il se place sur les routers "sv5.home.dom" et "sv4.home.dom". Ils travaillent en Failover. Celui qui a la main possède une adresse IP virtuelle "192.168.1.70" sous le nom de "cluster.home.dom" et cette adresse servira de passerelle par défaut pour les trois serveurs Web. Ce site utilisera le cryptage SSL sous le nom de "cluster.home.dom". Pour cette raison, l'interface réseau utilisé par les utilisateurs sera accessible sous le nom "cluster.home.dom" du réseau "192.168.1.0/24". La configuration du router "192.168.1.70" peut être trouvée dans l'article sur le Routage statique. Dans cadre d'un réseau à domicile, vous aurez des problème d'appliquer un routage statique; l'article suivant vous aidera à le résoudre via le Natting.

Les fichiers utilisés pour ce site sont placés dans un espace disque commun aux trois serveurs. Pour cette tâche, nous utilisons un volume GlusterFs en réplication. La réplication se passe au travers du réseau "192.168.3.0/24".

Ce site utilise une base de données. Chacun de ces trois serveurs comporte une base de données; elles sont identiques. Cette réplication se fait grâce au gestionnaire de base de données Mariadb-Galera au travers du réseau "192.168.3.0/24". Comme nous avons un nombre impaire de serveurs de base de données, nous n'devons pas besoin du service Garb.

Toute cette configuration sera supervisée par le logiciel Pacemaker. Il assurera que l'ensemble fonctionne et dans le cas extrême, l'ensemble des applications concernées s'arrêtera.

Pour cette mise en place, deux grandes parties sont à considérer:

  • la configuration des trois serveurs qui vont travailler de concert.
  • la configuration des deux routers qui auront la tâche de rediriger et répartir les requêtes des clients.

Avant de passer à Pacemaker.


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 cluster.home.dom cluster
192.168.1.75 cluster5.home.dom cluster5
192.168.1.74 cluster4.home.dom cluster4
192.168.2.75 sv5.home.dom sv5
192.168.2.74 sv4.home.dom sv4
 
192.168.2.71 sv1.home.dom sv1
192.168.2.72 sv2.home.dom sv2
192.168.2.73 sv3.home.dom sv3
 
192.168.3.71 dt1.home.dom dt1
192.168.3.72 dt2.home.dom dt2
192.168.3.73 dt3.home.dom dt3
 
# serveur mail
192.168.1.110 servermail.home.dom home.dom


Configuration des services sur les serveurs Web

Nous avons à configurer les différents services nécessaires qui vont être utilisés par Pacemaker. Ces configurations sont à faire sur les quatre serveurs Web: "192.168.2.71", "192.168.2.72" et "192.168.2.73". Voyez l'article sur le Routage statique.

En pratique, dans le fichier de l'interface du réseau "192.168.2.0/24" dans le répertoire "/etc/NetworkManager/system-connections", on ajoute les deux lignes suivantes sous la section "[ipv4]":


[ipv4]
...
route1=192.168.1.0/24,192.168.2.75,101
route2=192.168.1.0/24,192.168.2.74,102


Routage

Comme l'adresse IP de la passerelle sera changeante car c'est celle de l'adresse IP virtuelle du router maître, elle sera définie via Pacemaker. Mais quand Pacemaker est arrêté, il faut y pallier. Pour cette raison, nous ajoutons deux adresses IP de routage statique; l'une va vers l'adresse IP "192.168.2.74" et l'autre vers "192.168.2.75".


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 "sv1.home.dom".

Le volume sera placé sur un partition d'un disque distinct que nous avons monté sur le répertoire "/disk1".


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.3.0/24". Voici la suite des commandes:

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


Constitution du volume en réplication

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

gluster volume create diskgfs1 replica 3 transport tcp dt1.home.dom:/disk1/glusterfs/brique1 dt2.home.dom:/disk1/glusterfs/brique1 \
                                                       dt3.home.dom:/disk1/glusterfs/brique1
gluster volume start  diskgfs1


Services HTTPD et PHP

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

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

La configuration est similaire à celle présentée dans l'article sur le Paramétrage des services en Failover. La mise en place des certificats est nécessaire. Celle concernant la messagerie n'est pas reprise dans ce cas-ci même si elle pourrait y être ajoutée facilement. La configuration de Mariadb sera abordée ci-dessous. Nous plaçons les fichiers du site sous le répertoire "/data/web".

On ajoute un fichier "/data/web/vivant.html" dont le contenu est:


Je suis vivant.

Il servira au service "ldirectord.service" de vérifier qu'Apache est bien actif.


Service MariaDb-Galera

La configuration se base sur celle présentée dans l'article sur Galera - Cluster de MariaDB.


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.3.0/24":


wsrep_cluster_address = "gcomm://192.168.3.71,192.168.3.72,192.168.3.73"

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. Dans cet exemple, c'est celle de la machine "sv1.home.dom":


wsrep_node_address="192.168.3.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":


sv1.home.dom
sv2.home.dom
sv3.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.2.71 192.168.2.72 192.168.2.73


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 /data
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 des paramètres et des services sur le router

Les routers "sv4.home.dom" et "sv5.home.dom" demandent quelques configurations et service.


Activer le routage

Sur les routers Linux, il ne faut pas oublier d'activer le transfert inter-réseaux en ajoutant un fichier, par exemple "router.conf", dans le répertoire "/etc/sysctl.d". Ce fichier doit contenir la ligne:


net.ipv4.ip_forward = 1

On active cette fonctionnalité par un redfémarrage ou via la commande:

sysctl -p /etc/sysctl.d/router.conf


SSL

Nous avons configuré le service Web qui utilise le cryptage SSL et les certificats associés: HTTPS sur les serveurs Web. Pour valiser ces connexions, Ldirectord doit aussi valider leurs certificats.

Mais les certificats utilisés n'ont pas été validés par une autorité de certification officielle (CA). Il nous faut l'intégrer à la liste officielle du router comme expliqué dans l'article sur les Certificats sous Linux.

Dans l'article sur le Paramétrage des services en Failover, nous avions créé les certificats. Le certificat de l’autorité de certification (CA) se nomme "ca.home.crt". On va le copier dans le répertoire "/etc/pki/ca-trust/source/anchors" du router "cluster.home.dom". Ensuite on exécute la commande:

update-ca-trust

pour l'intégrer à la liste officielle des autorités de certification officielle (CA).


Configuration de Ldirectord

Le fichier de configuration se nomme "/etc/ha.d/ldirectord.cf". Il existe plusieurs types de configuration. Voici le contenu choisi:


emailalert="root"
emailalertfreq=3600
emailalertstatus=all
quiescent=yes
checkinterval=20
fork=yes
 
virtual=192.168.1.75:80
       real=192.168.2.71:80 masq 65000
       real=192.168.2.72:80 masq 65000
       real=192.168.2.73:80 masq 65000
       request="vivant.html"
       receive="Je suis vivant."
       checktype=negotiate
       service=http
       scheduler=lblcr
       persistent=3600
       protocol=tcp
       checkport=80
 
virtual=192.168.1.75:443
       real=192.168.2.71:443 masq 65000
       real=192.168.2.72:443 masq 65000
       real=192.168.2.73:443 masq 65000
       request="vivant.html"
       receive="Je suis vivant."
       checktype=negotiate
       service=https
       scheduler=lblcr
       persistent=3600
       protocol=tcp
       checkport=443

Cette configuration permet de répartir vers nos trois serveurs Web, les protocoles HTTP et HTTPS en validant le contenu de la page "vivant.html".


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:

systemctl stop ldirectord.service

systemctl disable ldirectord.service







retour au menu de la Haute disponibilité