Introduction
Redis Sentinel assure la haute disponibilité de Redis en surveillant les instances, en gérant les basculements automatiques et en notifiant les administrateurs. Dans un contexte de production, il devient indispensable pour éviter les interruptions de service. Ce tutoriel couvre une architecture maître-esclaves avec trois sentinelles pour la tolérance aux pannes. Vous apprendrez à déployer, configurer et monitorer Sentinel de manière robuste.
Prérequis
- Redis 7.2+ installé sur trois serveurs
- Accès root ou sudo sur les machines
- Connaissances avancées de Linux et networking
- Docker (optionnel pour tests)
- Outils de monitoring comme Prometheus
Configuration du maître Redis
bind 0.0.0.0
port 6379
protected-mode no
appendonly yes
appendfsync everysec
Ce fichier configure l'instance maître Redis pour accepter les connexions et activer la persistance AOF. Protégé-mode est désactivé uniquement pour l'environnement contrôlé.
Configuration des esclaves
bind 0.0.0.0
port 6379
protected-mode no
replicaof 192.168.1.10 6379
appendonly yes
Chaque esclave pointe vers le maître via replicaof. Cette configuration assure la réplication en temps réel et la haute disponibilité.
Fichier de configuration Sentinel
port 26379
sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 10000
Ce fichier définit le quorum à 2 sentinelles, les délais de détection et les timeouts de basculement. Adaptez les IPs selon votre réseau.
Script de démarrage Sentinel
#!/bin/bash
redis-sentinel /etc/redis/sentinel.conf --sentinel
Script simple pour lancer Sentinel en tant que service. Rendez-le exécutable avec chmod +x et intégrez-le dans systemd.
Configuration systemd pour Sentinel
[Unit]
Description=Redis Sentinel
After=network.target
[Service]
ExecStart=/usr/bin/redis-sentinel /etc/redis/sentinel.conf
Restart=always
[Install]
WantedBy=multi-user.target
Ce service systemd garantit que Sentinel redémarre automatiquement après un crash ou un reboot du serveur.
Bonnes pratiques
- Déployez au minimum trois sentinelles sur des machines distinctes
- Utilisez des adresses IP fixes et un DNS interne
- Testez les basculements régulièrement en environnement de staging
- Activez l'authentification avec ACL Redis 6+
- Surveillez les métriques via Prometheus exporter
Erreurs courantes à éviter
- Oublier de synchroniser les clocks NTP entre les nœuds
- Configurer un quorum trop élevé rendant le cluster indisponible
- Négliger les règles firewall pour le port 26379
- Ne pas tester le basculement automatique avant la mise en production
Pour aller plus loin
Approfondissez vos compétences avec nos formations avancées sur la haute disponibilité et la résilience des systèmes. Découvrez nos formations Learni.