Comment configurer un basculement pour vos serveurs proxy Linux avec keepalived
Configurer une haute disponibilité sous Linux n’est pas toujours simple, surtout si vous devez assurer le bon fonctionnement de vos serveurs proxy. En cas de panne d’un serveur ou de perturbation réseau, vos clients peuvent rencontrer des erreurs car l’adresse IP n’est pas correctement transférée. C’est là que keepalived excelle : il garantit une transition fluide entre les serveurs en cas de défaillance, évitant ainsi les interruptions de service. La clé réside dans la configuration correcte du VRRP pour que les adresses IP virtuelles basculent entre vos serveurs. Il est essentiel de bien distinguer les adresses IP physiques des virtuelles, car une erreur peut engendrer de graves dysfonctionnements du réseau. Voici un guide pas à pas pour la mise en place d’un cluster de basculement Linux avec keepalived, spécialement conçu pour les serveurs proxy Squid. Ce guide a fonctionné sur CentOS 7, et une grande partie de la procédure est également applicable aux distributions basées sur RHEL.
Comment créer un cluster de basculement avec keepalived sous Linux
Principes du VRRP et ce que vous devez savoir
Si vous n’avez jamais utilisé VRRP, voici un bref résumé : une adresse IP virtuelle (VIP) est une adresse IP flottante qui change entre les serveurs. Ce concept est familier à tous, mais VRRP le rend dynamique. Ainsi, si votre serveur principal (le maître) tombe en panne, le serveur de secours prend le relais. Il utilise un identifiant de routeur virtuel (VRID) pour éviter les conflits entre plusieurs groupes, et des numéros de priorité déterminent quel serveur devient maître. Les paquets de pulsation (multicasts sur 224.0.0.18) indiquent aux autres serveurs qu’ils sont opérationnels. Si le serveur de secours ne reçoit pas de nouvelles du maître, il prend le relais. Attention : assurez-vous que votre commutateur prend en charge le trafic multicast, sinon vous risquez de rencontrer des problèmes. De plus, n’utilisez pas d’adresses IP physiques comme adresses virtuelles, car si un serveur tombe en panne et que son adresse IP change, il risque d’être déconnecté du réseau à son retour, le temps que VRRP se stabilise. Sur certaines configurations, c’est étrange, mais il suffit d’éviter de réutiliser de vraies adresses IP comme adresses VIP pour que tout reste propre.
Étape 1 : Installation de keepalived et configuration de base
- Utilisez yum (ou yum/dnf ) pour installer :
# yum install keepalived
vrrp_script chk_squid_service { script "/usr/sbin/squid -k check" interval 3 } vrrp_instance proxy_ip1 { state MASTER interface eth0 virtual_router_id 1 priority 255 virtual_ipaddress { 192.168.2.101/24 dev eth0 label eth0:1 } track_interface { eth1 } track_script { chk_squid_service } } vrrp_instance proxy_ip2 { state BACKUP interface eth0 virtual_router_id 2 priority 100 virtual_ipaddress { 192.168.2.102/24 dev eth0 label eth0:2 } track_interface { eth1 } track_script { chk_squid_service } }
Étape 2 : Configuration du réseau et du pare-feu
Avant de lancer keepalived, vérifiez vos règles iptables. Vous devez autoriser le trafic VRRP (multicast 224.0.0.18/8).Par exemple :
# iptables -A INPUT -i eth0 -d 224.0.0.0/8 -j ACCEPT # iptables -A INPUT -p vrrp -i eth0 -j ACCEPT
Sur certaines configurations, le pare-feu par défaut bloque cette opération ; assurez-vous donc de l’autoriser. N’oubliez pas d’activer keepalived pour qu’il démarre au démarrage du système.
# systemctl enable keepalived # systemctl start keepalived
Une fois le système en marche, vérifiez vos interfaces :
# ip a show eth0
Vous devriez voir vos adresses IP virtuelles attribuées à l’interface une fois que les deux serveurs seront opérationnels.
Étape 3 : S’assurer que Keepalived réagit aux pannes de service et d’interface
L’essentiel, c’est de surveiller vos applications (comme Squid) et vos interfaces. Voici comment ajouter des contrôles :
vrrp_script chk_squid_service { script "/usr/sbin/squid -k check" interval 3 } vrrp_instance proxy_ip1 {...track_script { chk_squid_service } } vrrp_instance proxy_ip2 {...track_script { chk_squid_service } }
Ce script s’exécute toutes les 3 secondes. Si Squid est hors service, keepalived signalera une panne du serveur et l’adresse IP virtuelle (VIP) basculera vers le nœud fonctionnel. C’est très pratique pour détecter les problèmes tels que les plantages d’applications ou les interruptions de service réseau.
Étape 4 : Tester le basculement — Oui, il faut volontairement provoquer des dysfonctionnements.
Une fois la configuration terminée, il est temps de tester. Désactivez eth0 sur proxy-serv01 ( ifconfig eth0 downou ip link set eth0 down), puis vérifiez si proxy-serv02 prend le relais de l’adresse IP virtuelle. Exécutez :
# ip a show eth0
Et surveillez les journaux de bord :
# cat /var/log/messages | grep -i keepalived
Vous devriez voir des messages indiquant que le premier serveur passe en état de défaillance (FAULT) et que le serveur de secours devient maître (MASTER).Lorsque vous réactivez eth0, le serveur devrait reprendre automatiquement son rôle initial, et les journaux confirmeront ce changement.
Même chose pour la simulation de pannes de réseau externe : désactivez eth1, et vous devriez voir keepalived gérer cela (si configuré avec track_interface), en inversant les rôles selon les besoins.
N’oubliez pas d’arrêter Squid manuellement pour vérifier le comportement en cas de défaillance :
# systemctl stop squid
Les journaux indiqueront que keepalived détecte l’indisponibilité du service et change d’adresse IP en conséquence.
Conclure
Cette configuration, bien que verbeuse, s’est avérée étonnamment fiable après quelques ajustements. L’essentiel est de s’assurer que vos adresses IP virtuelles ne sont pas directement liées à des interfaces physiques et que vos contrôles sont précis. Sur une machine, il peut arriver que le système rencontre un ou deux dysfonctionnements avant de se stabiliser, mais dans un environnement de production, cela permet de limiter considérablement les pannes inattendues. La mise en place de contrôles d’intégrité pour les interfaces réseau et les services applicatifs ajoute une couche de résilience qui peut s’avérer cruciale.
Résumé
- Installez keepalived avec la commande yum install keepalived
- Définissez soigneusement vos instances VRRP, établissez des priorités et spécifiez les adresses IP virtuelles.
- Configurer les règles de pare-feu pour le trafic multicast
- Ajouter des contrôles d’intégrité pour les applications et les interfaces
- Test en interrompant intentionnellement le réseau et les services
Mots de la fin
Configurer une haute disponibilité peut s’avérer complexe, mais une fois en place, c’est un vrai soulagement. L’élément crucial est la surveillance et les tests rigoureux. J’espère que cela vous permettra de bâtir une infrastructure proxy robuste. Il s’agit d’une solution qui a fonctionné sur différents systèmes ; croisons les doigts pour qu’elle aide à réduire les temps d’arrêt.