LINUX:Loadbalancing - Serveurs du cluster (gate)
→ retour aux Serveurs en Loadbalancing (gate)
But
Pour cette configuration, plusieurs pièces la composent et vont subir quelques transformations par rapport à l'article sur les Serveurs en Failover. Pour pouvoir utiliser une ressource disque partagée par deux machines en accès total, il faut changer de système de formatage. Or le système choisi nécessite que les deux espaces soient accessibles. Nombre de ces changements en sont la conséquence.
Préparation
DRBD
Le système utilisé est Drbd. Classiquement ce système est utilisé en mode Actif/Passif (Primary/Secondary); il n'y a que la partie active qui peut avoir un accès à cette ressource disque. Dans cette configuration de deux machines actives, il faut que ces accès disques soient actifs des deux côtés ou Primary/Primary.
En outre, nous sommes revenus à des partitions de base de type Linux sans utilisation de LVM. Le schéma d'initialisation des disques et de la ressource Drbd est similaire à celle faite dans les articles sur le Partitionnement du disque et Drbd mais sans la couche LVM. Les raisons sont doubles: montrer que cette autre initialisation plus ancienne est possible et de ne pas se soucier des problèmes de LVM dans le contexte d'une ressource disque partagée entre deux machines.
Le fichier de configuration "/etc/drbd.d/data.res" devient:
resource drbddata {
net {
protocol C;
verify-alg sha1;
allow-two-primaries yes ;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
startup { become-primary-on both; }
disk {
on-io-error detach;
}
handlers {
split-brain "/usr/lib/drbd/notify-split-brain.sh root";
out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root";
}
on fo1.home.dom {
disk /dev/sdb1;
address ipv4 192.168.2.71:7789;
device /dev/drbd1 minor 1;
meta-disk internal;
}
on fo2.home.dom {
disk /dev/sdb1;
address ipv4 192.168.2.72:7789;
device /dev/drbd1 minor 1;
meta-disk internal;
}
}
Les deux options: "allow-two-primaries yes ;" et "startup { become-primary-on both; }" permettent et démarrent le système en mode "Primary/Primary". Les devices disque de base sont ici tous deux "/dev/sdb1".
Formatage disque
Auparavant nous avions formaté ce nouveau device en "XFS". Dans de cas-ci, il faut un système qui permettent un accès concurrent entre deux machines. Nous avons opté pour le formatage "GFS2". Il en existe un autre connu: "OCFS2".
Nous avons besoin d'installer de deux paquets spécifiques:
dnf install gfs2-utils dnf install dlm
Le premier les utilitaires de formatage et d'utilisation de "GFS2"; le second est nécessaire pour gérer à travers le réseau la gestion concurrente de accès des disques spécialement en cas de modifications; une modification ne pouvant être effectuée que par un programme à la fois, chacun à son tour. Nous aurons donc besoin de lancer un service spécifique apporté par ce paquet.
Dès que la ressource "drbddata" de Drbd est prête, on choisit une machine et on met cette ressource à l'état actif avec la commande suivante:
drbdadm primary drbddata
Ceci fait, on formate le device "/dev/drbd1":
mkfs.gfs2 -p lock_dlm -j 2 -t fo_cluster:datacluster /dev/drbd1
Explications de quelques paramètres:
- -j 2 : on choisit deux journaux car nous avons deux disques partagés
- -t fo_cluster:datacluster : la partie "fo_cluster" doit correspondre au nom du cluster repris dans la configuration de Corosync "/etc/corosync/corosync.conf":
cluster_name: fo_cluster
L'exécution de cette commande donne:
This will destroy any data on /dev/drbd1 Are you sure you want to proceed? [y/n] y Discarding device contents (may take a while on large devices): Done Adding journals: Done Building resource groups: Done Creating quota file: Done Writing superblock and syncing: Done Device: /dev/drbd1 Block size: 4096 Device size: 149,04 GB (39070542 blocks) Filesystem size: 149,04 GB (39070538 blocks) Journals: 2 Journal size: 128MB Resource groups: 598 Locking protocol: "lock_dlm" Lock table: "fo_cluster:datacluster" UUID: 4205aec6-99e4-4019-b150-aec81a885d12
Paramétrage de Corosync
Comme signalé ci-dessous, cette ressource disque qui utilise le service "dlm.service", doit être accessible en même temps sur l'autre machine. On ne peut travailler en Failover. C'est à dire que le quorum doit être de deux et non comme dans le cas du Failover où ce quorum pouvait être de un.
Dans le fichier "/etc/corosync/corosync.conf", l'option "two_node: 1" doit être éliminée.
Eventuellement on peut la remplacer par "expected_votes: 2". La section "quorum" devient:
totem {
version: 2
cluster_name: fo_cluster
transport: knet
ip_version: ipv4
crypto_cipher: aes256
crypto_hash: sha256
cluster_uuid: 7aacd622f1484d40886c2b96120993bb
interface {
knet_transport: udp
linknumber: 0
mcastport: 5420
}
}
nodelist {
node {
ring0_addr: 192.168.1.71
name: fo1.home.dom
nodeid: 1
}
node {
ring0_addr: 192.168.1.72
name: fo2.home.dom
nodeid: 2
}
}
quorum {
provider: corosync_votequorum
expected_votes: 2
}
logging {
to_logfile: yes
logfile: /var/log/cluster/corosync.log
to_syslog: yes
timestamp: on
}
Ne pas oublier de changer les adresses IP des machines du cluster selon le schéma du début d'article.
Pour devenir actif, il faut redémarrer le service Corosync.
Ces opérations doivent être faites sur les deux machines du cluster.
ATTENTION: Avant de redémarrer ce service Corosync, il faut démonter le disque Drbd
umount /data
car en arrêtant le service Corosync, celui de Dlm s'arrête également et comme le service Dlm est nécessaire, vous risquez fortement d'avoir des problèmes.
Configurer le mur de feu ou FireWall
Si vous activez le Firewall, ce qui est recommandé, il faut y ajouter les règles suivantes:
- sur la machine "fo1.home.dom", on ajoute:
-A INPUT -p tcp -m tcp --sport 21064 -s 192.168.1.72 -m conntrack --ctstate NEW -j ACCEPT -A OUTPUT -p tcp -m tcp --dport 21064 -d 192.168.1.72 -j ACCEPT
- sur la machine "fo2.home.dom", on ajoute:
-A INPUT -p tcp -m tcp --sport 21064 -s 192.168.1.71 -m conntrack --ctstate NEW -j ACCEPT -A OUTPUT -p tcp -m tcp --dport 21064 -d 192.168.1.71 -j ACCEPT
Dès que le disque "/data" est monté, le service Dlm utilise le port TCP 21064 pour effectuer son travail.
Montage de "/data"
On peut essayer de monter cette espace disque mais auparavant il est impératif de lancer le service Corosync:
systemctl start corosync.service
et de lancer le service de gestion des accès concurrents des disques:
systemctl start dlm.service
Ces deux services devront être lancés sur les deux machines du cluster.
Si vous ne le faites pas, le montage ne se fera pas et restera bloqué et ne pourra pas être tué; il ne vous restera que la solution que le redémarrage de la machine
La ressource "drbddata" devra être dans l'état "Primary/Primary" sur les deux machines du cluster
Le montage s'effectue avec la commande suivante, similaire à celle déjà vue excepté le type de formatage:
mount -t gfs2 /dev/drbd1 /data
On peut le faire sur les deux machines.
On peut en profiter pour recopier dans ce répertoire "/data", les sous-répertoires "web" et "home" utilisés dans l'article sur sur le Paramétrage des services en Failover.
Services des serveurs
Dans l'article sur les Serveurs en Failover, nous avions ajouté divers services accessibles par les clients tels Web et messagerie électronique. Tous ces services, paramétrés dans l'article sur le Paramétrage des services en Failover, restent changés à l'exception:
- du service Postfix-Base qui n'est plus utilisé sauf si vous voulez le réactiver manuellement dans le cas où Pacemaker et l'ensemble de ses services ne sont pas actifs.
- du service Mariadb.
Nous allons ajouter quelques éléments qui nous seront nécessaires pour la partie Loadbalancing de cette machine.
Mariadb
Deux services Mariadb ne peuvent utiliser les fichiers d'une même base de données ensemble. On choisit une des deux machines du cluster sur laquelle on lance ce service de façon autonome. Le répertoire de la base de données est mis sur un des disques non partagés de cette machine. Il n'y a plus de raison de le mettre sur un espace partagé. A l'origine, ce répertoire est "/var/lib/mysql" mais il peut être mis à un emplacement à votre convenance. Si on voulait utiliser Mariadb en mode Loadbalancing, Mariadb possède son propre système de cluster. Sur l'autre machine, le service Mariadb ne sera pas lancé.
L'option concernée dans le fichier de configuration du serveur Mariadb "/etc/my.conf.d/mariadb-server.cnf" redevient:
datadir=/var/lib/mysql
Apache
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.
Dovecot
On ajoute sur les deux machines du cluster un utilisateur qui permettra au service "ldirectord.service" de vérifier que Dovecot est bien actif:
adduser -b /data/home -u 1001 -g users -s /sbin/nologin -c "Test Mail" testmail
On lui attrinue un mot de passe:
passwd testmail
Le mot de passe peut être:
Bateau52Ivre
Configuration de Pacemaker
Systemd: services nécessaires
Avant de lancer la configuration qui suit, il faut que les services suivants soient lancés sur les deux machines du cluster, spécialement "dlm.service":
systemctl start dlm.service systemctl start corosync.service systemctl start pcsd.service systemctl start pacemaker.service
Quorum
Comme nous devons avoir un quorum de deux machines car si une occurrence subsiste, nous risquons d'avoir des problèmes avec le disque partagé, il faut prendre une action spécifique; en cas de quorum non atteint, on stoppe toutes les ressources.
On adapte cette propriété avec la commande suivante à effectuer sur une des machines du cluster:
pcs property set no-quorum-policy=stop
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 ClusterDrbd ocf:linbit:drbd drbd_resource=drbddata \ op start interval=0s timeout=240s \ op stop interval=0s timeout=100s \ op monitor interval=29s role=Promoted \ clone promotable=true master-max=2 clone-max=2 notify=true pcs resource create ClusterFs ocf:heartbeat:Filesystem device="/dev/drbd1" directory="/data" fstype="gfs2" \ "options=noatime,errors=panic" \ op monitor interval=20s on-fail=stop clone interleave=true pcs constraint order ClusterDrbd-clone then start ClusterFs-clone pcs resource create ClusterHttp systemd:httpd op monitor interval=30s clone pcs constraint order ClusterFs-clone then start ClusterHttp-clone pcs resource create ClusterPhp systemd:php-fpm op monitor interval=30s clone pcs constraint order ClusterHttp-clone then start ClusterPhp-clone pcs resource create ClusterPostfix systemd:postfix op monitor interval=30s clone pcs constraint order ClusterPhp-clone then start ClusterPostfix-clone pcs resource create ClusterDovecot systemd:dovecot op monitor interval=30s clone pcs constraint order ClusterPostfix-clone then start ClusterDovecot-clone pcs resource create ClusterMailTo ocf:heartbeat:MailTo email=root subject="FailOver_Home" op monitor interval=30s clone pcs constraint order ClusterDovecot-clone then start ClusterMailTo-clone
Clones
On remarque ici que toutes création de ressource comporte le paramètre "clone"; ceci implique que chaque ressource sera présente sur chaque machine du cluster. Chaque service sera actif sur chaque machine alors que précédemment, elles n'étaient présente que sur une seule machine. En outre la ressource Drbd est active sur les deux machines ("master-max=2 clone-max=2"); l'état sera en mode "Primary/Primary".
GFS2
On remarque que la ressource disque est montée en "gfs2". Cette ressource peut être plus sujette à des problèmes; divers précautions sont prises en cas d'erreur.
Services
On active les services Apache, PHP, Postfixe, Dovecot et la notification par mail.
Contraintes
Les contraintes d'ordre de démarrage sont connues; elles ont déjà été rencontrées dans les articles précédents. Il tombe sous le sens que la ressource "drbddata" doit être effective avant de pouvoir monter cet espace partagé. Et les services qui utilisent l'espace partagé, doivent être activés après ce montage.
Systemd: Pacemaker et Dlm
J'ai rencontré des problèmes après l'ajout du service Dlm. Par exemple, le service Dlm s'arrête quand on arrête le service Corosync mais quand on redémarre le service Corosync, celui de Dlm ne démarre pas. Quand on le sait, on veille à redémarrer également le service Dlm. Autre cas, on rencontre de temps en temps des problèmes lors du démarrage de la machine si tout est lancé ensemble. La solution consistait à attendre quelque temps (1 min) avant de lancer le service Pacemaker. Mais le plus gros problème se passe lors de l'arrêt de la machine. Systématiquement la machine se bloque ou prend beaucoup de temps pour s'arrêter ou redémarrer. On remarque que le service Dlm essaie de s'arrêter alors que le service Pacemaker n'a pas encore fini son étape d'arrêt, spécialement son étape de démontage du disque partagé. Or ce disque partagé a besoin du service Dlm sinon il se bloque.
Par contre si les services concernés sont arrêtés manuellement dans l'ordre (pacemaker, pcsd, corosync puis dlm), nous n'avons pas de problème.
Il nous faut trouver une solution.
System V et Systemd
Pour mémoire, par défaut, le démarrage d'Unix est structuré en couche en fonction de la niveau de fonctionnalités finales. Les plus connus sont:
- le niveau 0 pour l'arrêt de la machine
- le niveau 1 pour l'utilisation utilisation unique; ce niveau est utilisé en cas de dépannage
- le niveau 3 pour l'utilisation multi-utilisateurs avec support réseau mais sans la couche graphique; ce niveau est normalement utilisé pour les serveurs
- le niveau 5 pour l'utilisation multi-utilisateurs avec le support du réseau et avec la couche graphique; ce niveau est normalement utilisé pour les stations de travail
- le niveau 6 pour le redémarrage
Chaque service était numéroté pour définir son ordre de lancement ou d'arrêt. Ce système était appelé System V.
Dans notre cas, nous sommes au niveau 3 pour une fonctionnalité de type serveur.
Mais maintenant nous sommes passés au système Systemd. La couche 3 est devenue "multi-user.target". Lors du démarrage et de l'arrêt, on passe d'une couche ou "target" à l'autre imbriquées comme pour les pelures d'oignon pour enfin arriver à la couche désirée définie par le fichier "/etc/systemd/system/default.target". Dans le cas d'un serveur, le fichier pointe vers le fichier "/usr/lib/systemd/system/multi-user.target". Lors de la dernière couche à exécuter "multi-user.target", tous les services (ou autres) se trouvant dans le répertoire "/etc/systemd/system/multi-user.target.wants" seront exécutés. On y retrouve notre service Mariadb activé ci-dessus
Target
La solution trouvée consiste à isoler le lancement de ces services liés au clustering et de forcer leurs dépendances: corosync.service, dlm.service, pcsd.service et pacemaker.service. Nous allons ajouter une couche au dessus de la dernière exécutée lors du lancement "multi-user.target".
Nous créons le fichier "/usr/lib/systemd/system/cluster.target" dont voici le contenu:
[Unit] Description=Cluster Target Requires=multi-user.target After=multi-user.target AllowIsolate=yes
On note que cette couche se lance après ("After") la couche "multi-user.target" et que cette couche précédente "multi-user.target" est nécessaire ("Requires").
Comme on veut l'atteindre au final, on doit la définir comme défaut via le lien suivant:
ln -sf /usr/lib/systemd/system/cluster.target /etc/systemd/system/default.target
Il ne faut pas oublier de recharger les paramètres de Systemd suite à ces changements:
systemctl daemon-reload
Services
Maintenant qu'on a créé une nouvelle couche, il faut la remplir. On élimine celles qui nous concernent de la couche "multi-user.target":
systemctl disable dlm.service systemctl disable corosync.service systemctl disable pcsd.service systemctl disable pacemaker.service
Ensuite il nous faut adapter le service "pacemaker.service" qui nous pose quelques problèmes.
Pour ne pas modifier le fichier "pacemaker.service" d'origine, on en fait une copie:
cp /usr/lib/systemd/system/pacemaker.service /etc/systemd/system/cluster.service
On y apporte les modifications suivantes. Les lignes suivantes:
[Unit] ... After=corosync.service Requires=corosync.service ... [Install] WantedBy=multi-user.target ...
sont remplacées par
[Unit] ... After=corosync.service dlm.service pcsd.service Requires=corosync.service dlm.service pcsd.service ... [Install] WantedBy=cluster.target ...
Ce nouveau service va se placer dans la couche "cluster.target" et va exiger le lancement au préalable des services "corosync.service", "dlm.service" et "pcsd.service". On n'aura pas besoin de les activer spécifiquement.
Il ne faut pas oublier de recharger les paramètres de Systemd suite à ce changement:
systemctl daemon-reload
On active enfin ce nouveau service:
systemctl enable cluster.service
Un répertoire "/etc/systemd/system/cluster.target.wants" est créé et un lien est alors ajouté dans ce répertoire vers le fichier "/etc/systemd/system/cluster.service" de notre nouveau service.
Si on lance le nouveau service:
systemctl start cluster.service
les services "corosync.service", "dlm.service" et "pcsd.services" sont aussi lancés.
Lors de l'arrêt de la machine (et de son démarrage), nos problèmes ont disparu.
Statut
Après ces opérations, l'état du cluster peut être visualisé par la commande:
crm_mon -1
qui donne:
Status of pacemakerd: 'Pacemaker is running' (last updated 2023-02-21 12:46:02 +01:00)
Cluster Summary:
* Stack: corosync
* Current DC: fo2.home.dom (version 2.1.5-3.fc37-a3f44794f94) - partition with quorum
* Last updated: Tue Feb 21 12:46:02 2023
* Last change: Mon Feb 20 16:51:45 2023 by root via cibadmin on fo1.home.dom
* 2 nodes configured
* 14 resource instances configured
Node List:
* Online: [ fo1.home.dom fo2.home.dom ]
Active Resources:
* Clone Set: ClusterDrbd-clone [ClusterDrbd] (promotable):
* Masters: [ fo1.home.dom fo2.home.dom ]
* Clone Set: ClusterFs-clone [ClusterFs]:
* Started: [ fo1.home.dom fo2.home.dom ]
* Clone Set: ClusterHttp-clone [ClusterHttp]:
* Started: [ fo1.home.dom fo2.home.dom ]
* Clone Set: ClusterPhp-clone [ClusterPhp]:
* Started: [ fo1.home.dom fo2.home.dom ]
* Clone Set: ClusterPostfix-clone [ClusterPostfix]:
* Started: [ fo1.home.dom fo2.home.dom ]
* Clone Set: ClusterDovecot-clone [ClusterDovecot]:
* Started: [ fo1.home.dom fo2.home.dom ]
* Clone Set: ClusterMailTo-clone [ClusterMailTo]:
* Started: [ fo1.home.dom fo2.home.dom ]
Si la machine "fo2.home.dom" est éteinte ou si ses services du cluster sont arrêtés, cette même commande donne:
Status of pacemakerd: 'Pacemaker is running' (last updated 2023-02-21 13:36:17 +01:00) Cluster Summary: * Stack: corosync * Current DC: fo1.home.dom (version 2.1.5-3.fc37-a3f44794f94) - partition WITHOUT quorum * Last updated: Tue Feb 21 13:36:18 2023 * Last change: Mon Feb 20 16:51:45 2023 by root via cibadmin on fo1.home.dom * 2 nodes configured * 14 resource instances configured Node List: * Online: [ fo1.home.dom ] * OFFLINE: [ fo2.home.dom ] Active Resources: * No active resources
On peut voir les port réseaux utilisés avec la commande:
netstat -natup
qui donne après filtrage de ce qui nous concernent:
Connexions Internet actives (serveurs et établies) Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name udp 0 0 192.168.1.71:5420 0.0.0.0:* 889/corosync tcp 0 0 0.0.0.0:2224 0.0.0.0:* LISTEN 977/python3 tcp 0 0 192.168.1.71:21064 0.0.0.0:* LISTEN - tcp 0 0 192.168.1.71:58475 192.168.1.72:21064 ESTABLISHED - tcp 0 0 192.168.1.71:21064 192.168.1.72:60905 ESTABLISHED - tcp 0 0 192.168.2.71:56993 192.168.2.72:7789 ESTABLISHED - tcp 0 0 192.168.2.71:7789 192.168.2.72:60513 ESTABLISHED - tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1823/httpd tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 1823/httpd tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2135/master tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN 2135/master tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN 2135/master tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 2169/dovecot tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 2169/dovecot tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 2169/dovecot tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 2169/dovecot tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 62285/mariadbd
Je les ai ordonnés: en début, ce qui concerne la base de Pacemaker et les services liées et en bas, les services lancés par Pacemaker.
Pour le paramétrage du mur de feu ou firewall, il faut tenir compte de ces ports et de leurs destinations et origines.
Configurer le mur de feu ou FireWall (Gate)
Cette partie de la configuration d'Iptables (ou équivalent; à adapter en fonction) est obligatoire. Elle est minimaliste; on peut ajouter le filtrage classique vu précédemment si désiré. Elle est à effectuer sur les deux serveurs du cluster.
Le trafic venant du client a été envoyé à la machine "cluster.home.dom" ayant l'adresse IP "192.168.1.73". Cette machine a renvoyé tel quel le paquet à un de nos deux serveurs du cluster. Ce serveur qui reçoit la requête ("PREROUTING") est perturbé car le destinateur ("192.168.1.73") ne lui correspond pas. Les rêgles suivantes vont remplacer l'adresse IP "192.168.1.73" par la sienne ("192.168.1.71" ou "192.168.1.72" selon) avant de la traiter en interne par ses services (HTTP,...). Ces rêgles ne reprennent que les ports qui concernent le LoadBalancing. Le résultat du traitement par le service (HTTP,...) sera envoyé directement au client sans passer par la machine "cluster.home.dom". On évite ainsi ce passage par cet intermédiaire qui peut constituer un goulet d'étranglement. Dans le précédent cas ("masq"), ce passage était obligatoire; la machine "cluster.home.dom" était un router.
Voici le contenu:
#**************************************************************** # FILTER #**************************************************************** *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT #**************************************************************** # NAT #**************************************************************** *nat :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :INPUT ACCEPT [0:0] -A PREROUTING -i eth1 -p tcp -d 192.168.1.73 --dport 80 -j REDIRECT -A PREROUTING -i eth1 -p tcp -d 192.168.1.73 --dport 443 -j REDIRECT -A PREROUTING -i eth1 -p tcp -d 192.168.1.73 --dport 110 -j REDIRECT -A PREROUTING -i eth1 -p tcp -d 192.168.1.73 --dport 143 -j REDIRECT -A PREROUTING -i eth1 -p tcp -d 192.168.1.73 --dport 993 -j REDIRECT -A PREROUTING -i eth1 -p tcp -d 192.168.1.73 --dport 995 -j REDIRECT -A PREROUTING -i eth1 -p tcp -d 192.168.1.73 --dport 25 -j REDIRECT -A PREROUTING -i eth1 -p tcp -d 192.168.1.73 --dport 587 -j REDIRECT -A PREROUTING -i eth1 -p tcp -d 192.168.1.73 --dport 465 -j REDIRECT COMMIT
Assurez-vous que le paquet permettant l'utilisation du service d'Iptables est bien installé:
dnf install iptables.services
On active et lance ce service:
systemctl enable iptables.service systemctl start iptables.service
→ retour aux Serveurs en Loadbalancing (gate)