LINUX:Pacemaker - Routers inter LAN en Failover

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

retour au menu de la Haute disponibilité


But

Ce premier exemple place deux routers en Failover afin de diminuer le risque de coupures entre deux LANs privés, par exemple, entre votre LAN de travail et la DMZ. Nous n'aborderons pas le mur de feu ou firewall. A vous de le concevoir.


Principe

On dispose de deux ordinateurs Linux configurés en mode routers. On va utiliser le logiciel Pacemaker qui les regroupent en cluster. Ils seront utilisés en Failover. L'un des routers aura des fonctions de router en concentrant les ressources configurées dans Pacemaker tandis que l'autre sera en attente. Quand le premier router sera indisponible, par exemple suite à un problème matériel ou plus simplement lors d'une mise à jour de version, le second reprendra la tâche de router en récupérant les ressources de Pacemaker.

La ressource principale consiste à créer une adresse IP virtuelle sur chacun des deux interfaces réseaux. Ce sont ces adresses virtuelles qui seront utilisées dans les tables de routages. Les adresses IP réelles ne seront utilisées que pour une administration locale, par exemple, pour mettre à jour l'OS. Pour les notions de routage, voyez l'article concernant le Routage statique.

Le schéma suivant visualise la situation stable complètement opérationnelle. Dans la configuration, le routeur de gauche "fo1.home.dom" aura la préférence. Avec cette configuration, on peut choisir cet ordinateur de gauche plus performant, plus récent, tandis que l'autre peut être moins performant sachant que normalement, il ne doit entrer en action que rarement et que s'il tombe en panne, ce n'est pas crucial. Le tracé en vert visualise de trafic de routage et les adresses IP en rouge sont virtuelles qui ne sont pas liées à un router mais vont devoir passer de gauche à droite et inversement en fonction des besoins.

LINUX:Failover1D.pdf

Dans le cas où le router de gauche tombe en panne (grisé), celui de droite prend la relève. Les adresse IP virtuelles migrent sur l'autre router "fo2.home.dom".

LINUX:Failover1G.pdf


Prérequis

Configuration de base

En premier, la Configuration de base de Pacemaker doit être effectuée.


Activation du routage

En second, il faut activer le routage sur les deux routers 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 configuration soit en redémarrant la machine, soit avec la commande suivante:

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


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.71 fo1.home.dom
192.168.1.72 fo2.home.dom
192.168.1.73 cluster.home.dom
 
192.168.2.71 fd1.data.dom 
192.168.2.72 fd2.data.dom 
192.168.2.73 fdcluster.home.dom
 
# serveur mail
192.168.1.110 servermail.home.dom home.dom


Configuration

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 ClusterIPext ocf:heartbeat:IPaddr2 ip=192.168.1.73 cidr_netmask=24 nic=eth1 iflabel=ethcl1 lvs_support=true op monitor interval=30s
pcs constraint location ClusterIPext       prefers fo1.home.dom=1000
pcs constraint location ClusterIPext       prefers fo2.home.dom=10
 
pcs resource create ClusterIPint ocf:heartbeat:IPaddr2 ip=192.168.2.73 cidr_netmask=24 nic=eth2 iflabel=ethcl2 lvs_support=true op monitor interval=30s
pcs constraint location ClusterIPint       prefers fo1.home.dom=1000
pcs constraint location ClusterIPint       prefers fo2.home.dom=10
 
pcs constraint colocation add ClusterIPint with ClusterIPext score=INFINITY
pcs constraint order ClusterIPext then start ClusterIPint
 
pcs resource create ClusterMailTo ocf:heartbeat:MailTo email=root subject="FailOver_Home" op monitor interval=30s
pcs constraint location ClusterMailTo      prefers fo1.home.dom=1000
pcs constraint location ClusterMailTo      prefers fo2.home.dom=10
 
pcs constraint colocation add ClusterMailTo with ClusterIPext score=INFINITY
pcs constraint order ClusterIPint then start ClusterMailTo

Ces commandes ne sont à exécuter qu'à partir d'une seule machine du cluster.


Ajout des ressources des adresses IP virtuelles

Les lignes suivantes:

pcs resource create ClusterIPext ocf:heartbeat:IPaddr2 ip=192.168.1.73 cidr_netmask=24 nic=eth1 iflabel=ethcl1 lvs_support=true op monitor interval=30s
pcs resource create ClusterIPint ocf:heartbeat:IPaddr2 ip=192.168.2.73 cidr_netmask=24 nic=eth2 iflabel=ethcl2 lvs_support=true op monitor interval=30s

vont créer deux ressources, nommées "ClusterIPext" et "ClusterIPint" qui vont activer deux adresses virtuelles respectivement "192.168.1.73/24" et "192.168.2.73/24" grâce à la fonction "ocf:heartbeat:IPaddr2". L'une sera placée sur l'interface réseau "eth1" et l'autre "eth2". Des noms virtuels sont aussi donnés: "ethcl1" et "ethcl2".


Préférences données à "fo1.home.dom"

Les lignes suivantes:

pcs constraint location ClusterIPext       prefers fo1.home.dom=1000
pcs constraint location ClusterIPext       prefers fo2.home.dom=10
pcs constraint location ClusterIPint       prefers fo1.home.dom=1000
pcs constraint location ClusterIPint       prefers fo2.home.dom=10

ajoutent des contraintes donnant la préférence au router "fo1.home.dom" d'un point de vue localisation.


Localisation commune

La ligne suivante:

pcs constraint colocation add ClusterIPint with ClusterIPext score=INFINITY

précise que ces deux ressources seront sur la même machine.


Ordre de démarrage

La ligne suivante:

pcs constraint order ClusterIPext then start ClusterIPint

définit l'ordre de démarrage de ces deux ressources; la ressource "ClusterIPext" sera démarrée avant la ressource "ClusterIPint".


Ressource de notification par mail

La ligne suivante:

pcs resource create ClusterMailTo ocf:heartbeat:MailTo email=root subject="FailOver_Home" op monitor interval=30s

crée une ressource nommée "ClusterMailTo" grâce à la fonction "ocf:heartbeat:MailTo". A tout changement d'état un mail sera envoyé à l'utilisateur "root" dont le sujet débutera avec les mots "FailOver_Home".

On peut facilement comprendre le reste des lignes similaires à ce qui a été vu plus haut. Cette ressource débutera après les autres et sera avec elles.


Statut

La commande suivante:

crm_mon -1

donne:


Status of pacemakerd: 'Pacemaker is running' (last updated 2023-02-08 21:29:56 +01:00)
Cluster Summary:
  * Stack: corosync
  * Current DC: fo1.home.dom (version 2.1.5-3.fc37-a3f44794f94) - partition with quorum
  * Last updated: Wed Feb  8 21:29:56 2023
  * Last change:  Wed Feb  8 21:29:47 2023 by root via cibadmin on fo1.home.dom
  * 2 nodes configured
  * 3 resource instances configured
 
Node List:
  * Online: [ fo1.home.dom fo2.home.dom ]
 
Active Resources:
  * ClusterIPext        (ocf::heartbeat:IPaddr2):        Started fo1.home.dom
  * ClusterIPint        (ocf::heartbeat:IPaddr2):        Started fo1.home.dom
  * ClusterMailTo       (ocf::heartbeat:MailTo):         Started fo1.home.dom

Les deux machines sont actives et c'est la machine "fo1.home.dom" qui a les ressources.


Voici la situation de l'adressage réseau sur la machine "fo1.home.dom", qui a les ressources, avec la commande:

ifconfig

qui donne:


eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.1.71  netmask 255.255.255.0  broadcast 192.168.1.255
       ether 00:1c:c0:92:a2:08  txqueuelen 1000  (Ethernet)
       RX packets 107979  bytes 17802627 (16.9 MiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 135883  bytes 33136749 (31.6 MiB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
       device interrupt 20  memory 0xd3300000-d3320000
 
eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.2.71  netmask 255.255.255.0  broadcast 192.168.2.255
       ether 00:1b:21:3b:b6:ea  txqueuelen 1000  (Ethernet)
       RX packets 800  bytes 72941 (71.2 KiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 471  bytes 47011 (45.9 KiB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
 
eth1:ethcl1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.1.73  netmask 255.255.255.0  broadcast 192.168.1.255
       ether 00:1c:c0:92:a2:08  txqueuelen 1000  (Ethernet)
       device interrupt 20  memory 0xd3300000-d3320000
 
eth2:ethcl2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.2.73  netmask 255.255.255.0  broadcast 192.168.2.255
       ether 00:1b:21:3b:b6:ea  txqueuelen 1000  (Ethernet)
 
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
       inet 127.0.0.1  netmask 255.0.0.0
       inet6 ::1  prefixlen 128  scopeid 0x10<host>
       loop  txqueuelen 1000  (Boucle locale)
       RX packets 13264  bytes 10017919 (9.5 MiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 13264  bytes 10017919 (9.5 MiB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Les adresses virtuelles s'y trouvent.

Et cette même commande sur la machine "fo2.home.dom":


eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.1.72  netmask 255.255.255.0  broadcast 192.168.1.255
       ether 00:1b:21:3b:b0:77  txqueuelen 1000  (Ethernet)
       RX packets 3897  bytes 767023 (749.0 KiB)
       RX errors 0  dropped 1  overruns 0  frame 0
       TX packets 3638  bytes 809626 (790.6 KiB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
 
eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
       inet 192.168.2.72  netmask 255.255.255.0  broadcast 192.168.2.255
       ether 00:1c:c0:2a:c4:25  txqueuelen 1000  (Ethernet)
       RX packets 13  bytes 832 (832.0 B)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 10  bytes 640 (640.0 B)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
       device interrupt 20  memory 0xe0380000-e03a0000
 
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
       inet 127.0.0.1  netmask 255.0.0.0
       inet6 ::1  prefixlen 128  scopeid 0x10<host>
       loop  txqueuelen 1000  (Boucle locale)
       RX packets 16  bytes 5560 (5.4 KiB)
       RX errors 0  dropped 0  overruns 0  frame 0
       TX packets 16  bytes 5560 (5.4 KiB)
       TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Les adresses virtuelles ne s'y trouvent pas.


Maintenant si on arrête la machine "fo1.home.dom", la commande:

crm_mon -1

, sur la machine "fo2.home.dom", donne:


Status of pacemakerd: 'Pacemaker is running' (last updated 2023-02-09 10:55:30 +01:00)
Cluster Summary:
  * Stack: corosync
  * Current DC: fo2.home.dom (version 2.1.5-3.fc37-a3f44794f94) - partition with quorum
  * Last updated: Thu Feb  9 10:55:30 2023
  * Last change:  Thu Feb  9 10:54:24 2023 by hacluster via crmd on fo1.home.dom
  * 2 nodes configured
  * 3 resource instances configured
 
Node List:
  * Online: [ fo2.home.dom ]
  * OFFLINE: [ fo1.home.dom ]
 
Active Resources:
  * ClusterIPext        (ocf::heartbeat:IPaddr2):        Started fo2.home.dom
  * ClusterIPint        (ocf::heartbeat:IPaddr2):        Started fo2.home.dom
  * ClusterMailTo       (ocf::heartbeat:MailTo):         Started fo2.home.dom

La machine, ayant les ressources, a changé et la machine "fo1.home.dom" est hors circuit.





retour au menu de la Haute disponibilité