« LINUX:Haute disponibilité » : différence entre les versions
(Page créée avec « ---- ''→ retour au menu de Linux'' ---- =But= L'informatique devient de plus en plus cruciale et le temps d'indisponibilité doit être déduite au minimum. ---- ''→ retour au menu de Linux'' ---- __NOEDITSECTION__ Category:LINUX ») |
Aucun résumé des modifications |
||
| (33 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 3 : | Ligne 3 : | ||
---- | ---- | ||
=But= | =But= | ||
L'informatique devient de plus en plus cruciale et le temps d'indisponibilité doit être déduite au minimum. | L'informatique devient de plus en plus cruciale et le temps d'indisponibilité doit être déduite au minimum. Ces temps d'indisponibilité font suite à des erreurs humaines mais surtout à des problèmes matériels. | ||
Chaque type de problème a sa parade plus ou moins efficace selon les moyens mis en oeuvre. | |||
Dans cet article, nous aborderons certaines approches: la duplication de matériel par l'utilisation de grappe de machines ou Cluster. | |||
La pièce centrale utilisée est Pacemaker associées à Corosync, Pcs et, par après, Drbd. | |||
* Corosync est là pour récupérer les informations de présence des machines dans la grappe. | |||
* Pacemaker permet de gérer les ressources sur ces machines. | |||
* Pcs sert à configurer cette grappe et de leur donner des ordres. | |||
* Drbd est un équivalent au RAID1 mais les disques sont sur deux machines différentes et la duplication des données de fait à travers le réseau. | |||
Nous aborderons leur utilisation au travers de divers exemples. En premier, nous utiliserons la notion de Failover ou Basculement et ensuite celle de Loadbalancing ou Répartition de charge en y ajoutant le logiciel Ldirectord. | |||
=[[LINUX:Haute disponibilité - Prérequis|Prérequis]]= | |||
Pour toutes les configurations qui suivent, les machines auront une même base. | |||
=Installation de Pacemaker, Corosync et Pcs= | |||
Ces trois composantes sont liées. Pour les installer, exécutez les commandes suivantes: | |||
dnf install pcs | |||
dnf install pacemaker | |||
dnf install corosync | |||
Normalement en installant le premier, les deux autres s'installent en tant que dépendances. | |||
et éventuellement: | |||
dnf install fence-agents-all | |||
dnf install sbd | |||
=[[LINUX:Pacemaker - Configuration de base|Configuration de base de Pacemaker]]= | |||
Avant d'aborder des cas spécifiques de clusters, on passe d'office par une étape de configuration de base commune à tous les cas. | |||
Par la suite, quand on abordera notre cas spécifique de Loadbalancing, deux paramètres seront changés. | |||
=Configurer le mur de feu ou FireWall= | |||
Si vous activez le Firewall, ce qui est recommandé, il faut y ajouter les règles suivantes. | |||
Le logiciel Corosync échange des informations avec ses partenaires via le protocole UDP et sur le port 5420, dans notre exemple, au travers des interfaces réseaux "eth1". | |||
* sur la machine "fo1.home.dom", on ajoute: | |||
-A INPUT -p udp -m udp -i eth1 -s 192.168.1.72 --dport 5420 -j ACCEPT | |||
-A OUTPUT -p udp -m udp -o eth1 -d 192.168.1.72 --dport 5420 -j ACCEPT | |||
* sur la machine "fo2.home.dom", on ajoute: | |||
-A INPUT -p udp -m udp -i eth1 -s 192.168.1.71 --dport 5420 -j ACCEPT | |||
-A OUTPUT -p udp -m udp -o eth1 -d 192.168.1.71 --dport 5420 -j ACCEPT | |||
De même, le logiciel Pcs écoute sur le port TCP 2224. Ces échanges se font entre les machines du cluster lors de leur configuration et leur gestion. Ces accès peuvent également être effectués à partir d'une machine distante via un interface Web; nous avons choisi l'accès au réseau "192.168.1.0/24". | |||
* sur les machines du cluster, on ajoute: | |||
-A INPUT -p tcp -m tcp --sport 2224 -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT | |||
-A OUTPUT -p tcp -m tcp --dport 2224 -d 192.168.1.0/24 -j ACCEPT | |||
=Activation et lancement= | |||
Dès que la phase de configuration de base est effectuée et '''non avant''', on active ces trois produits: | |||
systemctl enable pcsd | |||
systemctl enable corosync | |||
systemctl enable pacemaker | |||
et on les lancent: | |||
systemctl start pcsd | |||
systemctl start corosync | |||
systemctl start pacemaker | |||
Ces étapes sont à effectuer sur les différentes machines du cluster. | |||
=[[LINUX:Pacemaker - Interface Web|Interface Web]]= | |||
Il existe un interface Web qui est le pendant des commandes de ligne "pcs" utilisées jusqu'ici. | |||
=[[LINUX:Pacemaker - Routers inter LAN en Failover|Routers inter LAN en Failover]]= | |||
Ce premier exemple place deux routers en Failover afin de diminuer le risque de coupures entre deux LANs privés. | |||
=[[LINUX:Pacemaker - Routers LAN-Internet en Failover|Routers LAN-Internet en Failover]]= | |||
Ce second exemple place deux routers en Failover afin de diminuer le risque de coupures. Ces routers relieront notre LAN privé à Internet. | |||
=Elimination d'une ressource= | |||
La commande suivante permet d'éliminer une ressource nom désirée: | |||
pcs resource delete <nom de ressource> | |||
Par exemple: | |||
pcs resource delete ClusterMailTo | |||
à effectuer sur une des machines du cluster. | |||
Je conseille de réfléchir à l'ordre; je le fais en sens inverse de la création. Il faut savoir que toutes ses dépendances sont aussi éliminées tels l'ordre, la localisation,... | |||
=Elimination des notifications d'erreur= | |||
Il arrive, surtout lors des périodes de conception, que des notifications d'erreurs s'affichent. Elles s'accumulent et peuvent bloquer le système. En premier on règle le problème et ensuite on efface ces notifications et l'historique. | |||
La commande suivante efface les notifications relatives à une ressource: | |||
pcs resource cleanup <nom de ressource> | |||
Par exemple: | |||
pcs resource cleanup ClusterDefaultRoutes | |||
La commande suivante efface l'historique au niveau d'une machine, appelé également noeud: | |||
pcs stonith history cleanup <noeud> | |||
Par exemple: | |||
pcs stonith history cleanup fo1.home.dom | |||
=[[LINUX:Drbd|Drbd]]= | |||
Drbd est un équivalent du Raid 1 mais les deux disques sont sur des machines différentes et la synchronisation se fait à travers le réseau. | |||
=[[LINUX:Pacemaker - Serveurs en Failover|Serveurs en Failover]]= | |||
Autre application, nous allons mettre deux serveurs en Failover. Nous utiliserons l'approche utilisée par les routers mis en Failover couplée à l'utilisation de Drbd. | |||
=[[LINUX:Ldirectord|Ldirectord]]= | |||
Ldirectord est un programme qui gère la répartition de charge en utilisant fonctionnalité de Linux, le LVS ou Linux Virtual Server. | |||
=[[LINUX:Pacemaker - Serveurs en Loadbalancing (masq)|Serveurs en Loadbalancing (masq)]]= | |||
Toute autre approche, au lieu qu'un des serveurs soit en attente sans rien faire, les serveurs se répartissent la charge et se partagent les données. Une des machines est chargée de faire le partage équitablement. En anglais, on parle de Loadbalancing. Nous utilisons la configuration "Masquerading de NAT". | |||
=[[LINUX:Pacemaker - Serveurs en Loadbalancing (gate)|Serveurs en Loadbalancing (gate)]]= | |||
Cet autre exemple est très proche de la précédente. Il se différencie principalement par son organisation dans le réseau. | |||
Une des machines est chargée de faire le partage équitablement. En anglais, on parle de Loadbalancing. | |||
Au lieu qu'un des serveurs soit en attente sans rien faire, les serveurs se répartissent la charge et se partagent les données. | |||
Nous utilisons la configuration "Gate ou Routage Direct". | |||
=[[LINUX:ISCSI|ISCSI]]= | |||
ISCSI est un protocole réseau qui permet d'utiliser à distance un disque d'une machine "target" sur une autre machine "initiator" comme si ce disque était connecté localement. | |||
=[[LINUX:Pacemaker et ISCSI|Pacemaker et ISCSI]]= | |||
Si les serveurs ISCSI ou Target s'arrêtent de fonctionner, les espaces disques ISCSI sur le client ou Initiator doivent être démontés de toute urgence sinon certaines fonctions de cette machine seront bloquées. | |||
=[[LINUX:Pacemaker - ISCSI en Failover|ISCSI en Failover]]= | |||
Si à la configuration précédente, nous ajoutons un client Initiator, nous pouvons passer à une installation en Failover utilisant des disques ISCSI. | |||
=[[LINUX:Pacemaker - ISCSI en Failover et SBD (fence)|ISCSI en Failover et SBD (fence)]]= | |||
A la configuration précédente, nous ajoutons la notion de "Fence" avec la couche SBD. | |||
Le logiciel SBD utilise un device de type Watchdog (chien de garde) qui permet d'arrêter la machine client ISCSI Initiator quand elle ne plus atteindre sa cible ISCSI de référence. Cette situation se présente, par exemple, dans le cas d'une défaillance réseau. Cette arrêt permet d'éviter des problèmes de corruptions de données sur les ressources distantes. | |||
Nous n'utiliserons qu'un serveur ISCSI Target mais nous garderons l'approche Failover. | |||
=[[LINUX:Pacemaker - quatre serveurs WEB en Failover, Fsyncd et ISCSI|Quatre serveurs WEB en Failover, Fsyncd et ISCSI]]= | |||
Autre configuration, nous allons configurer 4 serveurs WEB en failover. Ils seront accompagnés d'une réplication grâce au programme Fsyncd. Un accès à un espace disque distant ISCSI, propre à chaque serveur WEB sera ajouté. | |||
=[[LINUX:Galera - Cluster de MariaDB|Galera - Cluster de MariaDB]]= | |||
MariaDB possède une fonctionnalité qui permet qu'il travaille en cluster. Celle-ci est dénommée Galera. | |||
=[[LINUX:Glusterfs|Glusterfs]]= | |||
GlusterFS est un système de fichiers distribué, modulable à volonté, qui réunit les éléments de stockage de plusieurs serveurs pour former un système de fichiers uniforme. | |||
=[[LINUX:Pacemaker - cinq serveurs WEB en Failover, Galera et GlusterFs|Cinq serveurs WEB en Failover, Galera et GlusterFs]]= | |||
Autre configuration, nous allons reprendre la configuration présentée à l'article concernant [[LINUX:Pacemaker - quatre serveurs WEB en Failover, Fsyncd et ISCSI|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. | |||
=[[LINUX:Pacemaker - quatre serveurs WEB en Loadbalancing, Galera et GlusterFs|Quatre serveurs WEB en Loadbalancing, Galera et GlusterFs]]= | |||
Cette configuration rassemble les fonctionnalités de l'article précédent, [[LINUX:Pacemaker - cinq serveurs WEB en Failover, Galera et GlusterFs|Cinq serveurs WEB en Failover, Galera et GlusterFs]] auquel on applique le canevas du schéma présenté dans l'article sur les [[LINUX:Pacemaker - Serveurs en Loadbalancing (masq)|Serveurs en Loadbalancing (masq)]]. A l'approche Drbd on substitue GlusterFs. | |||
=[[LINUX:Pacemaker - deux routers en failover - trois serveurs WEB en Loadbalancing, Galera et GlusterFs|Deux routers en failover - trois serveurs WEB en Loadbalancing, Galera et GlusterFs]]= | |||
Cette configuration est très semblable à la précédente, [[LINUX:Pacemaker - quatre serveurs WEB en Loadbalancing, Galera et GlusterFs|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. | |||
Dernière version du 25 juin 2023 à 14:01
But
L'informatique devient de plus en plus cruciale et le temps d'indisponibilité doit être déduite au minimum. Ces temps d'indisponibilité font suite à des erreurs humaines mais surtout à des problèmes matériels.
Chaque type de problème a sa parade plus ou moins efficace selon les moyens mis en oeuvre.
Dans cet article, nous aborderons certaines approches: la duplication de matériel par l'utilisation de grappe de machines ou Cluster.
La pièce centrale utilisée est Pacemaker associées à Corosync, Pcs et, par après, Drbd.
- Corosync est là pour récupérer les informations de présence des machines dans la grappe.
- Pacemaker permet de gérer les ressources sur ces machines.
- Pcs sert à configurer cette grappe et de leur donner des ordres.
- Drbd est un équivalent au RAID1 mais les disques sont sur deux machines différentes et la duplication des données de fait à travers le réseau.
Nous aborderons leur utilisation au travers de divers exemples. En premier, nous utiliserons la notion de Failover ou Basculement et ensuite celle de Loadbalancing ou Répartition de charge en y ajoutant le logiciel Ldirectord.
Prérequis
Pour toutes les configurations qui suivent, les machines auront une même base.
Installation de Pacemaker, Corosync et Pcs
Ces trois composantes sont liées. Pour les installer, exécutez les commandes suivantes:
dnf install pcs dnf install pacemaker dnf install corosync
Normalement en installant le premier, les deux autres s'installent en tant que dépendances.
et éventuellement:
dnf install fence-agents-all dnf install sbd
Configuration de base de Pacemaker
Avant d'aborder des cas spécifiques de clusters, on passe d'office par une étape de configuration de base commune à tous les cas. Par la suite, quand on abordera notre cas spécifique de Loadbalancing, deux paramètres seront changés.
Configurer le mur de feu ou FireWall
Si vous activez le Firewall, ce qui est recommandé, il faut y ajouter les règles suivantes.
Le logiciel Corosync échange des informations avec ses partenaires via le protocole UDP et sur le port 5420, dans notre exemple, au travers des interfaces réseaux "eth1".
- sur la machine "fo1.home.dom", on ajoute:
-A INPUT -p udp -m udp -i eth1 -s 192.168.1.72 --dport 5420 -j ACCEPT -A OUTPUT -p udp -m udp -o eth1 -d 192.168.1.72 --dport 5420 -j ACCEPT
- sur la machine "fo2.home.dom", on ajoute:
-A INPUT -p udp -m udp -i eth1 -s 192.168.1.71 --dport 5420 -j ACCEPT -A OUTPUT -p udp -m udp -o eth1 -d 192.168.1.71 --dport 5420 -j ACCEPT
De même, le logiciel Pcs écoute sur le port TCP 2224. Ces échanges se font entre les machines du cluster lors de leur configuration et leur gestion. Ces accès peuvent également être effectués à partir d'une machine distante via un interface Web; nous avons choisi l'accès au réseau "192.168.1.0/24".
- sur les machines du cluster, on ajoute:
-A INPUT -p tcp -m tcp --sport 2224 -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT -A OUTPUT -p tcp -m tcp --dport 2224 -d 192.168.1.0/24 -j ACCEPT
Activation et lancement
Dès que la phase de configuration de base est effectuée et non avant, on active ces trois produits:
systemctl enable pcsd systemctl enable corosync systemctl enable pacemaker
et on les lancent:
systemctl start pcsd systemctl start corosync systemctl start pacemaker
Ces étapes sont à effectuer sur les différentes machines du cluster.
Interface Web
Il existe un interface Web qui est le pendant des commandes de ligne "pcs" utilisées jusqu'ici.
Routers inter LAN en Failover
Ce premier exemple place deux routers en Failover afin de diminuer le risque de coupures entre deux LANs privés.
Routers LAN-Internet en Failover
Ce second exemple place deux routers en Failover afin de diminuer le risque de coupures. Ces routers relieront notre LAN privé à Internet.
Elimination d'une ressource
La commande suivante permet d'éliminer une ressource nom désirée:
pcs resource delete <nom de ressource>
Par exemple:
pcs resource delete ClusterMailTo
à effectuer sur une des machines du cluster.
Je conseille de réfléchir à l'ordre; je le fais en sens inverse de la création. Il faut savoir que toutes ses dépendances sont aussi éliminées tels l'ordre, la localisation,...
Elimination des notifications d'erreur
Il arrive, surtout lors des périodes de conception, que des notifications d'erreurs s'affichent. Elles s'accumulent et peuvent bloquer le système. En premier on règle le problème et ensuite on efface ces notifications et l'historique.
La commande suivante efface les notifications relatives à une ressource:
pcs resource cleanup <nom de ressource>
Par exemple:
pcs resource cleanup ClusterDefaultRoutes
La commande suivante efface l'historique au niveau d'une machine, appelé également noeud:
pcs stonith history cleanup <noeud>
Par exemple:
pcs stonith history cleanup fo1.home.dom
Drbd
Drbd est un équivalent du Raid 1 mais les deux disques sont sur des machines différentes et la synchronisation se fait à travers le réseau.
Serveurs en Failover
Autre application, nous allons mettre deux serveurs en Failover. Nous utiliserons l'approche utilisée par les routers mis en Failover couplée à l'utilisation de Drbd.
Ldirectord
Ldirectord est un programme qui gère la répartition de charge en utilisant fonctionnalité de Linux, le LVS ou Linux Virtual Server.
Serveurs en Loadbalancing (masq)
Toute autre approche, au lieu qu'un des serveurs soit en attente sans rien faire, les serveurs se répartissent la charge et se partagent les données. Une des machines est chargée de faire le partage équitablement. En anglais, on parle de Loadbalancing. Nous utilisons la configuration "Masquerading de NAT".
Serveurs en Loadbalancing (gate)
Cet autre exemple est très proche de la précédente. Il se différencie principalement par son organisation dans le réseau.
Une des machines est chargée de faire le partage équitablement. En anglais, on parle de Loadbalancing. Au lieu qu'un des serveurs soit en attente sans rien faire, les serveurs se répartissent la charge et se partagent les données. Nous utilisons la configuration "Gate ou Routage Direct".
ISCSI
ISCSI est un protocole réseau qui permet d'utiliser à distance un disque d'une machine "target" sur une autre machine "initiator" comme si ce disque était connecté localement.
Pacemaker et ISCSI
Si les serveurs ISCSI ou Target s'arrêtent de fonctionner, les espaces disques ISCSI sur le client ou Initiator doivent être démontés de toute urgence sinon certaines fonctions de cette machine seront bloquées.
ISCSI en Failover
Si à la configuration précédente, nous ajoutons un client Initiator, nous pouvons passer à une installation en Failover utilisant des disques ISCSI.
ISCSI en Failover et SBD (fence)
A la configuration précédente, nous ajoutons la notion de "Fence" avec la couche SBD. Le logiciel SBD utilise un device de type Watchdog (chien de garde) qui permet d'arrêter la machine client ISCSI Initiator quand elle ne plus atteindre sa cible ISCSI de référence. Cette situation se présente, par exemple, dans le cas d'une défaillance réseau. Cette arrêt permet d'éviter des problèmes de corruptions de données sur les ressources distantes. Nous n'utiliserons qu'un serveur ISCSI Target mais nous garderons l'approche Failover.
Quatre serveurs WEB en Failover, Fsyncd et ISCSI
Autre configuration, nous allons configurer 4 serveurs WEB en failover. Ils seront accompagnés d'une réplication grâce au programme Fsyncd. Un accès à un espace disque distant ISCSI, propre à chaque serveur WEB sera ajouté.
Galera - Cluster de MariaDB
MariaDB possède une fonctionnalité qui permet qu'il travaille en cluster. Celle-ci est dénommée Galera.
Glusterfs
GlusterFS est un système de fichiers distribué, modulable à volonté, qui réunit les éléments de stockage de plusieurs serveurs pour former un système de fichiers uniforme.
Cinq serveurs WEB en Failover, Galera et GlusterFs
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.
Quatre serveurs WEB en Loadbalancing, Galera et GlusterFs
Cette configuration rassemble les fonctionnalités de l'article précédent, Cinq serveurs WEB en Failover, Galera et GlusterFs auquel on applique le canevas du schéma présenté dans l'article sur les Serveurs en Loadbalancing (masq). A l'approche Drbd on substitue GlusterFs.
Deux routers en failover - trois serveurs WEB en Loadbalancing, Galera et GlusterFs
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.