Dans le monde des infrastructures IT, la haute disponibilité n’est pas une option, c’est une exigence. Pourtant, combien de fois avez-vous vu un service critique s’écrouler faute d’un mécanisme de basculement fiable ? C’est une situation que j’ai vécue trop souvent, souvent à cause de solutions trop complexes ou mal comprises.
C’est pourquoi je vais vous présenter Keepalived. Ce logiciel open source, qui utilise le protocole VRRP, est une solution éprouvée pour garantir que vos services restent accessibles, même quand l’un de vos serveurs décide de faire une pause imprévue.
Installer Keepalived : les premières étapes sur Linux
Pour assurer une haute disponibilité, Keepalived s’installe via les gestionnaires de paquets comme apt ou yum/dnf. La compilation depuis les sources reste une option pour des besoins spécifiques, offrant souplesse mais complexité accrue. La version installée est vérifiable via une simple commande.
Installation via les gestionnaires de paquets
Sur Debian ou Ubuntu, vous utiliserez la commande `sudo apt install keepalived`. Pour les systèmes basés sur CentOS ou RHEL, `sudo yum install keepalived` ou `sudo dnf install keepalived` feront l’affaire. Ces commandes téléchargent et installent les paquets nécessaires.
Une fois l’installation terminée, vérifiez la version avec `keepalived –version`. Pour confirmer que le service tourne, utilisez `systemctl status keepalived`.
Ces vérifications rapides sont essentielles. Elles vous assurent que Keepalived est bien présent et prêt à être configuré, évitant ainsi des soucis plus tard.
Compilation depuis les sources (si nécessaire)
Si vous avez besoin d’une version plus récente que celle disponible dans les dépôts, la compilation depuis les sources s’impose. Vous trouverez les fichiers nécessaires sur les plateformes de développement du projet.
Le processus typique implique de décompresser les sources, d’exécuter `./configure`, puis `make`, et enfin `sudo make install`.
Cela offre une flexibilité maximale, mais demande plus d’efforts. Les mises à jour devront être gérées manuellement.
Décortiquer le fichier keepalived.conf : l’épine dorsale de votre HA
Mais une fois installé, comment le configurer ? Le fichier `keepalived.conf` est votre point de départ pour définir les règles de haute disponibilité.
Structure générale du fichier de configuration
Le fichier `keepalived.conf` se trouve généralement dans `/etc/keepalived/`. C’est le cœur de votre configuration, le point central pour tout définir.
Il s’articule autour de trois blocs principaux : `global_defs` pour les paramètres généraux, `vrrp_sync_group` pour organiser vos instances VRRP, et `vrrp_instance` pour chaque groupe de haute disponibilité.
N’oubliez pas d’ajouter des commentaires ; ils vous remercieront plus tard, croyez-moi.
Le cœur du réacteur : le bloc `vrrp_instance`
Chaque bloc `vrrp_instance` définit un groupe de haute disponibilité. Donnez-lui un nom qui a du sens.
Associez-le ensuite à une interface réseau physique, comme `interface eth0`. C’est là que votre IP virtuelle prendra vie.
Le `virtual_router_id` est crucial. C’est l’identifiant unique qui permet aux nœuds de se reconnaître au sein du même groupe VRRP.
Paramètres essentiels pour la haute disponibilité
Le paramètre `state` indique si le nœud démarre en `MASTER` ou en `BACKUP`. Simple, mais fondamental.
La `priority` détermine qui a le plus de chances d’être élu `MASTER`. Une valeur plus élevée signifie plus d’autorité, c’est la clé du basculement.
Enfin, `virtual_ipaddress` : c’est l’adresse IP que vos clients utiliseront, celle qui reste accessible quoi qu’il arrive.
Tester le basculement : comment vérifier que tout fonctionne ?
Une fois la configuration en place, la seule façon de s’assurer que votre système est résilient est de le tester activement. Vérifier le basculement de la VIP est donc une étape non négociable.
Simuler une panne du nœud MASTER
Pour commencer, arrêtez proprement le service Keepalived sur le nœud actuellement MASTER. Utilisez pour cela la commande : systemctl stop keepalived.
Le nœud BACKUP devrait alors détecter la défaillance et prendre le relais automatiquement. Observez attentivement ce processus.
Il est crucial d’observer le basculement et la prise de contrôle de la VIP par le nœud de secours.
Vérifier la présence de l’IP virtuelle (VIP)
Listez ensuite les interfaces réseau sur le nouveau nœud MASTER avec ip addr show ou ifconfig.
Confirmez visuellement que la virtual_ipaddress est bien assignée à l’interface réseau du nœud qui vient de prendre le rôle de MASTER.
Testez la connectivité vers cette VIP depuis une autre machine sur le réseau. Cela confirme que le trafic est bien redirigé.
Scénarios de reprise : le nopreempt
Par défaut, si le MASTER initial redémarre, il reprendra automatiquement son rôle. C’est le comportement de préemption.
Pour désactiver cela, utilisez l’option nopreempt dans le bloc vrrp_instance. Le nœud BACKUP restera alors MASTER.
Désactiver la préemption est judicieux pour éviter des basculements intempestifs lors de redémarrages planifiés.
Aller plus loin : personnalisation et sécurité de Keepalived
Maintenant que vous maîtrisez les bases de l’installation et du test, explorons comment affiner votre configuration pour une robustesse et une sécurité accrues. Keepalived offre de nombreuses options pour aller plus loin.
Surveiller la santé des services avec `vrrp_script`
Avec `vrrp_script`, vous créez des scripts sur mesure pour vérifier la santé de vos applications. Cela permet une surveillance fine et réactive.
Vous intégrez ensuite ces scripts à votre configuration VRRP. Ils sont associés à une instance ou une interface spécifique.
La disponibilité de votre service applicatif devient alors un critère direct pour l’élection du `MASTER` VRRP. C’est une approche intelligente.
Sécuriser les communications VRRP
Il est capital de sécuriser vos messages VRRP. Cela évite les attaques ou les configurations involontairement erronées. Le paramètre `auth_pass` est votre premier rempart.
Vous avez le choix entre une authentification simple (PASS) avec un mot de passe partagé, ou une authentification cryptée (AH) pour une meilleure protection.
Pensez à choisir des mots de passe robustes. Leur distribution sécurisée entre les différents nœuds est tout aussi importante.
Configurer les notifications d’état
Les directives `notify_master`, `notify_backup`, et `notify_fault` vous permettent de déclencher des actions précises lors des changements d’état. C’est une fonctionnalité clé.
Utilisez ces notifications pour envoyer des alertes par email ou pour interagir avec votre système de monitoring centralisé. Cela améliore la visibilité.
Adaptez ces notifications. Elles doivent correspondre précisément aux besoins et aux contraintes de votre infrastructure pour être vraiment utiles.
Ajuster les délais pour la stabilité
Le paramètre `advert_int` fixe l’intervalle entre les annonces VRRP. Un délai trop court risque de surcharger inutilement votre réseau. Il faut trouver le juste milieu.
Considérez aussi le `preempt_delay`. C’est le temps d’attente avant qu’un nœud `MASTER` redémarré ne reprenne son rôle. Cela prévient les oscillations rapides et indésirables.
L’objectif est de trouver un équilibre. Il faut la réactivité nécessaire au basculement, sans compromettre la stabilité globale de votre système.
Vous avez maintenant les clés pour déployer et configurer Keepalived, assurant ainsi une disponibilité sans faille de vos services grâce au protocole VRRP et à une adresse IP virtuelle toujours accessible. N’attendez pas la prochaine panne pour renforcer la résilience de votre infrastructure ; maîtriser ce logiciel open source, c’est garantir la continuité de vos opérations.