Comment mettre en place une adresse VIP avec KeepAlived sous Debian 11 ?
Sommaire
I. Présentation
Dans ce tutoriel, nous allons voir comment mettre en place KeepAlived sur plusieurs serveurs Debian 11 afin de bénéficier d'une adresse IP virtuelle (et partagée) entre trois serveurs. Grâce à cette adresse IP virtuelle appelée VIP, on va pouvoir appliquer le principe de l'IP failover ou IP flottante en français. Pour fonctionner, KeepAlived s'appuie sur le protocole VRRP (Virtual Router Redundancy Protocol) qui est conçu pour gérer une adresse IP virtuelle entre plusieurs hôtes (une passerelle par défaut, sur un réseau, comme le fait le protocole HSRP de Cisco).
Pour cet exemple, je vais prendre comme point de départ un cluster de trois serveurs MariaDB (voir tutoriel ci-dessous) sur lequel je vais ajouter KeepAlived afin de pouvoir contacter mon cluster à partir d'une adresse IP flottante. Ainsi, mon serveur Web pourra contacter mon instance MariaDB à partir d'une adresse IP unique, et si un nœud MariaDB tombe, l'adresse VIP sera portée par un autre nœud de mon cluster.
Ainsi, lorsque KeepAlived sera mis en place sur les serveurs du cluster MariaDB, nous obtiendrons le schéma ci-dessous. Le serveur Web va toujours requêter le même serveur de base de données, en l'occurrence ici "SRV-DEB-1" car il sera prioritaire pour porter l'adresse VIP. Si le serveur SRV-DEB-1 tombe, le serveur SRV-DEB-2 devra prendre le relais (selon l'ordre de priorité définie dans la configuration de KeepAlived).
Lorsque l'on utilise MariaDB Galera pour créer un cluster de serveurs MariaDB, on fonctionne en mode multimaître, donc nous pourrions exploiter plus intensément notre cluster en ajoutant HAProxy pour effectuer de la répartition de charge entre les nœuds du cluster MariaDB Galera. Cela fera l'objet d'un autre article.
Vous pouvez mettre en place KeepAlived pour utiliser une adresse IP failover sous Linux dans d'autres cas de figure, et pas obligatoirement avec un cluster MariaDB. Par exemple, cela peut-être entre plusieurs serveurs Web.
II. IP failover avec KeepAlived
Tout d'abord, nous allons configurer le serveur SRV-DEB-1 mais ces différentes étapes seront à reproduire sur l'ensemble des nœuds du cluster MariaDB Galera. Il y a tout de même une modification à apporter à la configuration de chaque hôte : ce sera précisé.
Commençons par installer le paquet "keepalived" sur le serveur après avoir mis à jour le cache des paquets :
sudo apt-get update sudo apt-get install keepalived
A. Fichier keepalived.conf
On va créer le fichier de configuration de KeepAlived qui n'existe pas par défaut :
sudo nano /etc/keepalived/keepalived.conf
Dans ce fichier, intégrez la configuration suivante :
# Paramètres généraux global_defs { enable_script_security } # MariaDB est-il en cours d'exécution ? vrrp_script check_mariadb { script "/usr/bin/pgrep mariadb" interval 1 fall 2 rise 2 } # Configuration interface virtuelle vrrp_instance VIP { interface ens192 state MASTER priority 100 virtual_router_id 70 authentication { auth_type PASS auth_pass Vip2022 } virtual_ipaddress { 192.168.100.50 } track_script { check_mariadb } }
Quelques explications s'imposent pour bien comprendre ce que l'on fait... Le bloc "vrrp_instance" permet de déclarer la configuration de notre IP surnommée "VIP", avec les paramètres suivants :
- interface : le nom de l'interface locale qui va exploiter l'adresse VIP (un petit "ip a" vous permettra d'obtenir le nom de votre interface).
- state : l'état initial de chaque instance KeepAlived, il est recommandé d'indiquer "MASTER".
- priority : le serveur qui bénéficiera de l'adresse VIP sera celui qui sera en ligne et qui aura le priorité la plus élevée. Autrement dit, la priorité permet d'élire le MASTER. La valeur doit être comprise entre 1 et 255, et plus elle est élevée, plus la priorité est élevée. Ici, la valeur est 100 donc elle devra être inférieure (et différente) sur les deux autres hôtes.
- virtual_router_id : numéro pour identifier cette instance VRRP, doit être compris entre 1 et 255, et la valeur doit être la même sur les trois serveurs KeepAlived.
- authentication > auth_pass : mot de passe pour s'authentifier et participer à l'instance VRRP. Attention, le mot de passe ne doit pas excéder 8 caractères, sinon le message "(/etc/keepalived/keepalived.conf: Line 23) Truncating auth_pass to 8 characters" s'affichera au niveau du statut de KeepAlived.
- virtual_ipaddress : adresse IP virtuelle à partager entre les hôtes, donc 192.168.100.50 dans mon cas
- track_script : comment vérifier l'état de chaque serveur participant à l'instance KeepAlived ? En appliquant les conditions de "check_mariadb" où plusieurs paramètres sont définis et sont à adapter en fonction de vos besoins. En fait, la commande "/usr/bin/pgrep mariadb" sera exécutée pour voir s'il y a un processus nommé "MariaDB" qui tourne bien, et si ce n'est pas le cas, on configure que le serveur n'est pas opérationnel, et donc qu'il doit lâcher l'adresse VIP. Ce sera vérifié chaque seconde (interval) et il faut 2 erreurs pour passer en KO (fall) et 2 succès pour passer en OK (rise).
En complément, je vous recommande de regarder ces deux liens pour vous aider à créer votre configuration :
La configuration est prête : sauvegardez le fichier keepalived.conf. Le fichier de configuration doit être identique sur tous les serveurs participants à l'instance KeepAlived, à la différence du paramètre "priority" qu'il faut ajuster.
B. Étapes supplémentaires
Comme la configuration est prête, sécurisons le fichier en ajustant les droits :
sudo chmod 600 /etc/keepalived/keepalived.conf
Par défaut, KeepAlived utilise l'utilisateur "keepalived_script" pour exécuter les scripts c'est-à-dire la commande "/usr/bin/pgrep mariadb" dans cet exemple. Le problème, c'est que l'utilisateur n'existe pas, donc nous devons créer un utilisateur et un groupe avec ce nom (-U), mais cet utilisateur n'aura pas besoin de dossier home (-M) et n'aura pas d'un accès shell (-s). Ce qui donne la commande suivante pour le créer :
sudo useradd -U -M -s /sbin/nologin keepalived_script
Une fois que les deux étapes précédentes sont effectuées, redémarrez le processus KeepAlived sur le premier nœud (SRV-DEB-1) puis sur les autres :
sudo systemctl restart keepalived
Pour en savoir un peu plus sur l'état, il suffit d'afficher le statut :
sudo systemctl status keepalived
Sur le serveur SRV-DEB-1, en listant les adresses IP de l'hôte local, on peut remarquer qu'il porte l'adresse VIP :
ip a
III. Tester l'IP failover
A. Configuration du serveur Web
Au niveau de mon serveur Web qui héberge un site WordPress, il faut que j'édite le fichier "wp-config.php" pour lui indiquer l'adresse IP virtuelle, comme ceci :
nano /var/www/html/wp-config.php
Lorsque le serveur MySQL / MariaDB n'est pas situé sur le même serveur que le serveur Web en lui-même, il faut autoriser les connexions distantes dans MySQL / MariaDB sur chaque nœud. Une modification du fichier de configuration suivant est indispensable sur chaque nœud du cluster :
nano /etc/mysql/mariadb.conf.d/50-server.cnf
Par défaut, la propriété "bind-address" est définie sur "127.0.0.1" donc on autorise uniquement les requêtes provenant de l'hôte local (via la boucle locale). Désormais, il faut que l'on autorise les connexions en provenance d'un hôte distant en écoutant sur toutes les adresses IP locales : 127.0.0.1, 192.168.100.51 et 192.168.100.50 si l'on prend SRV-DEB-1 pour exemple.
#bind-address = 127.0.0.1
bind-address = 0.0.0.0
Ensuite, il faut donner des autorisations à l'utilisateur "utilisateur-bdd-wp" utilisé par WordPress pour administrer la base de données "wordpress" correspondante au site, à partir de l'adresse IP du serveur Web. Ce qui nécessite de se connecter à l'instance MySQL pour créer une autorisation comme ceci :
GRANT ALL privileges ON `wordpress`.* TO 'utilisateur-bdd-wp'@'192.168.100.14' IDENTIFIED BY 'Mot-de-Passe' WITH GRANT OPTION; FLUSH PRIVILEGES;
Voilà, à partir de ce moment-là, le serveur Web peut exploiter le cluster MariaDB Galera via l'adresse VIP gérée par KeepAlived.
B. Panne de SRV-DEB-1 : que se passe-t-il ?
Pour finir, nous pouvons simuler une panne de SRV-DEB-1 pour voir ce qu'il se passe... Ainsi, on peut simplement éteindre le serveur ou arrêter le service MariaDB puisque KeepAlived vérifie que le processus tourne bien.
systemctl stop mariadb
Suite à l'exécution de cette commande, si l'on regarde le statut de SRV-DEB-1, on peut voir plusieurs messages qui montrent qu'il y a du mouvement... Et on voit "Entering FAULT STATE" ce qui montre que l'adresse VIP va être affectée à un autre hôte.
Puisque SRV-DEB-2 a une priorité de 90 et SRV-DEB-3 une priorité de 80, c'est bien SRV-DEB-2 qui hérite de l'adresse VIP. Son statut indique "Entering MASTER STATE", ce qui confirme qu'il hérite de l'adresse VIP. Une bonne chose ! 🙂
Au niveau du site Web WordPress, la bascule s'est faite rapidement avec une perte de connexion pendant 2 secondes environ, avant que le site fonctionne correctement, en toute transparence. Ce système est diablement efficace, d'autant plus que l'on fonctionne en mode multimaître sur les instances MariaDB donc c'est d'autant plus simple de passer d'un nœud à un autre.
Nous venons de voir comment mettre en place une adresse VIP sous Linux (Debian) avec KeepAlived !
