Comment mettre en place une adresse VIP avec KeepAlived sous Debian 11 ?

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 !