Redis Sentinel et Cluster : haute disponibilité production

📌 Article principal de la série : Redis 8 : caching, queues, pub/sub et streams pour applications production

Un Redis mono-instance est un point de défaillance unique : tout crash du processus ou de la machine entraîne une indisponibilité totale et potentiellement une perte de données. Pour les applications de production, deux mécanismes officiels permettent d’éliminer ce risque : Redis Sentinel pour le failover automatique sur des déploiements modestes, et Redis Cluster pour le sharding horizontal sur des datasets massifs. Ce tutoriel configure les deux pas à pas, avec les pièges classiques d’exploitation.

Prérequis

• Trois VPS Linux Ubuntu 24.04 ou Debian 12 avec connectivité réseau privée
• Redis 8 installé sur chaque (voir tutoriel installation)
• Bases d’administration systemd et de réseau Linux
• Temps estimé : 90 minutes

Étape 1 — Architecture Sentinel à trois nœuds

Le déploiement Sentinel minimal recommandé comprend trois machines : un Redis maître, un ou deux réplicas, et trois processus Sentinel répartis sur ces machines. Le quorum à trois Sentinels permet de tolérer la perte d’un nœud entier (machine + Sentinel + Redis) sans interrompre le service.

Machine A (10.0.0.1) : Redis maitre + Sentinel-A
Machine B (10.0.0.2) : Redis replica + Sentinel-B
Machine C (10.0.0.3) : Redis replica + Sentinel-C

En cas de panne de la machine A, Sentinels B et C détectent l’indisponibilité, votent (quorum = 2 sur 3) et élisent l’un des deux réplicas comme nouveau maître. Les clients sont automatiquement reconfigurés pour pointer vers le nouveau maître. Le failover prend typiquement 5 à 30 secondes.

Étape 2 — Configurer la réplication Redis

Sur les machines B et C (les futurs réplicas), modifiez /etc/redis/redis.conf pour ajouter une directive replicaof. La machine A reste configurée normalement comme maître.

# Sur machine B (10.0.0.2)
sudo nano /etc/redis/redis.conf

# Ajouter :
replicaof 10.0.0.1 6379
masterauth motdepasse-replication
replica-read-only yes

# Redemarrer
sudo systemctl restart redis-server

La directive replicaof IP PORT dit à cette instance qu’elle est un réplica du maître à l’adresse indiquée. masterauth fournit le mot de passe pour s’authentifier auprès du maître (idem mot de passe défini par requirepass sur le maître). replica-read-only yes empêche les écritures accidentelles sur les réplicas, qui doivent rester pures lectures. Vérifiez l’état de réplication :

# Sur la machine A (maitre)
redis-cli --user appuser --askpass INFO replication

# Sur la machine B (replica)
redis-cli --user appuser --askpass INFO replication

Sur le maître, vous verrez role:master et connected_slaves:2. Sur les réplicas, role:slave, master_host:10.0.0.1 et master_link_status:up. Si master_link_status:down, vérifiez la connectivité réseau et le mot de passe — c’est l’erreur la plus fréquente.

Étape 3 — Tester la réplication

# Sur le maitre (10.0.0.1)
redis-cli --user appuser --askpass SET test:replication "hello"

# Sur un replica (10.0.0.2)
redis-cli --user appuser --askpass GET test:replication
"hello"

# Tenter d'ecrire sur le replica (doit echouer)
redis-cli --user appuser --askpass SET test:write "foo"
(error) READONLY You can't write against a read only replica.

La donnée écrite sur le maître apparaît instantanément sur les réplicas (la réplication est asynchrone mais sub-milliseconde sur LAN). L’écriture refusée sur le réplica confirme la configuration read-only. Cette étape valide que la réplication fonctionne avant de configurer le failover automatique.

Étape 4 — Configurer Sentinel sur les trois machines

Le paquet Redis officiel inclut un binaire Sentinel séparé et un fichier de configuration /etc/redis/sentinel.conf. Sur chacune des trois machines, créez la configuration suivante.

sudo nano /etc/redis/sentinel.conf

port 26379
sentinel announce-ip MA_IP_PUBLIQUE
sentinel monitor mymaster 10.0.0.1 6379 2
sentinel auth-pass mymaster motdepasse-replication
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

Le quorum est défini à 2 dans la directive monitor : deux Sentinels doivent être d’accord avant de déclencher un failover. down-after-milliseconds 5000 dit qu’un maître est considéré comme down après 5 secondes sans réponse. failover-timeout est le délai maximum pour qu’un failover se termine avant de retenter. parallel-syncs 1 limite à un seul réplica resynchronisé en parallèle au nouveau maître (pour ne pas saturer le réseau).

Lancer Sentinel comme service :

sudo systemctl enable redis-sentinel
sudo systemctl start redis-sentinel
sudo systemctl status redis-sentinel

Le service écoute sur le port 26379 par défaut. Vérifiez la connectivité entre les Sentinels :

redis-cli -p 26379 SENTINEL master mymaster
redis-cli -p 26379 SENTINEL replicas mymaster
redis-cli -p 26379 SENTINEL sentinels mymaster

La dernière commande doit lister deux autres Sentinels (les Sentinels se découvrent mutuellement automatiquement). Si vous n’en voyez qu’un seul, c’est qu’un firewall bloque la communication entre les Sentinels sur le port 26379.

Étape 5 — Tester le failover

Provoquez volontairement un crash du maître pour observer le failover automatique.

# Depuis la machine A (maitre), arreter Redis
sudo systemctl stop redis-server

# Depuis n'importe quelle autre machine, observer les logs Sentinel
sudo journalctl -u redis-sentinel -f

Vous verrez la séquence : +sdown master mymaster (Sentinel détecte localement la panne), +odown master mymaster #quorum 2/2 (quorum atteint, panne objectivement confirmée), +vote-for-leader (élection du leader Sentinel qui pilotera le failover), +failover-state-select-slave, +failover-state-send-slaveof-noone (un réplica est promu), et finalement +switch-master mymaster 10.0.0.1 6379 10.0.0.2 6379. Total : 10 à 30 secondes selon la configuration.

# Verifier le nouveau maitre
redis-cli -p 26379 SENTINEL master mymaster

# Tester ecritures
redis-cli -h 10.0.0.2 --user appuser --askpass SET test:apres-failover "ok"

La machine B est désormais le maître. Quand vous redémarrerez Redis sur A, il sera automatiquement reconfiguré en réplica (le rôle est mémorisé par Sentinel et appliqué via SLAVEOF).

Étape 6 — Connexion client avec Sentinel

Les clients ne se connectent pas directement aux Redis maître/réplicas — ils se connectent aux Sentinels pour découvrir l’adresse du maître courant. ioredis supporte nativement cette discovery.

// client-sentinel.js
import Redis from 'ioredis';

const redis = new Redis({
    sentinels: [
        { host: '10.0.0.1', port: 26379 },
        { host: '10.0.0.2', port: 26379 },
        { host: '10.0.0.3', port: 26379 }
    ],
    name: 'mymaster',
    username: 'appuser',
    password: process.env.REDIS_PASSWORD,
    sentinelPassword: process.env.REDIS_PASSWORD
});

// Utilisation normale : le client se connecte au maitre courant
await redis.set('cle', 'valeur');
const v = await redis.get('cle');

En cas de failover, ioredis reçoit la notification Sentinel +switch-master et reconnecte automatiquement au nouveau maître. Aucun changement de code applicatif n’est nécessaire. Les requêtes en cours pendant le failover peuvent échouer avec READONLY ou NOAUTH ; il faut donc gérer ces erreurs avec un retry court dans la couche applicative.

Étape 7 — Architecture Redis Cluster pour le sharding

Quand votre dataset dépasse la mémoire d’une seule machine (typiquement 100+ Go), Sentinel ne suffit plus — il faut Redis Cluster qui répartit les clés sur plusieurs maîtres. Le minimum recommandé : 3 maîtres + 3 réplicas, soit 6 instances Redis sur 6 machines (ou 6 ports différents sur 3 machines pour un POC).

Master-1 (10.0.0.1:7000) -- Replica-1 (10.0.0.4:7000)
Master-2 (10.0.0.2:7000) -- Replica-2 (10.0.0.5:7000)
Master-3 (10.0.0.3:7000) -- Replica-3 (10.0.0.6:7000)

Chaque clé est mappée à un slot via CRC16(key) mod 16384. Les 16 384 slots sont répartis entre les maîtres. Quand un client écrit sur un nœud qui ne possède pas le slot, le nœud répond MOVED en indiquant le bon nœud, et le client se reconnecte. ioredis gère cette redirection automatiquement.

Étape 8 — Initialiser Redis Cluster

Sur chaque instance Redis Cluster, configurer redis.conf :

port 7000
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-node-timeout 5000
appendonly yes
requirepass motdepasse-cluster
masterauth motdepasse-cluster

Après démarrage des 6 instances, lancez la création du cluster :

redis-cli --user appuser -a "$REDIS_PASSWORD" --cluster create \
    10.0.0.1:7000 10.0.0.2:7000 10.0.0.3:7000 \
    10.0.0.4:7000 10.0.0.5:7000 10.0.0.6:7000 \
    --cluster-replicas 1

L’option --cluster-replicas 1 dit à redis-cli de créer automatiquement un réplica par maître. La commande propose une configuration et demande confirmation. Acceptez avec yes. Vérifiez le cluster :

redis-cli -h 10.0.0.1 -p 7000 --user appuser --askpass CLUSTER INFO
redis-cli -h 10.0.0.1 -p 7000 --user appuser --askpass CLUSTER NODES

La sortie de CLUSTER INFO doit montrer cluster_state:ok, cluster_slots_ok:16384 et cluster_known_nodes:6. CLUSTER NODES détaille chaque nœud avec son rôle, ses slots et ses liens.

Étape 9 — Client Cluster avec ioredis

// client-cluster.js
import { Cluster } from 'ioredis';

const cluster = new Cluster([
    { host: '10.0.0.1', port: 7000 },
    { host: '10.0.0.2', port: 7000 },
    { host: '10.0.0.3', port: 7000 }
], {
    redisOptions: {
        password: process.env.REDIS_PASSWORD,
        username: 'appuser'
    }
});

// Usage standard : le client route automatiquement vers le bon shard
await cluster.set('user:1', JSON.stringify({ nom: 'Aissa' }));
await cluster.set('user:2', JSON.stringify({ nom: 'Fatou' }));
const u = JSON.parse(await cluster.get('user:1'));

Les seeds (nœuds initiaux) servent uniquement à la découverte de la topologie ; ioredis apprend ensuite la liste complète des nœuds et leurs slots. Les opérations multi-clés (transactions, scripts Lua, MSET) ne fonctionnent qu’à l’intérieur d’un même slot — utiliser des hash tags avec {...} pour forcer plusieurs clés dans le même slot : {user1}:profile et {user1}:settings seront sur le même nœud.

Étape 10 — Resharding et rebalancing

Pour ajouter un nœud au cluster (scaling out) :

redis-cli --cluster add-node 10.0.0.7:7000 10.0.0.1:7000 --user appuser -a "$PWD"
redis-cli --cluster reshard 10.0.0.1:7000 --user appuser -a "$PWD"
# Le tool demande combien de slots migrer et vers quel noeud

Le resharding migre des slots et leurs clés de manière transparente — les clients continuent à fonctionner pendant l’opération grâce aux redirections ASK temporaires. Pour retirer un nœud, d’abord migrer tous ses slots ailleurs, puis cluster forget. Ces opérations doivent être planifiées en heures creuses pour minimiser l’impact sur la latence.

Erreurs fréquentes

Retour au pilier

• 🔝 Redis 8 : caching, queues, pub/sub et streams
• Installer Redis 8 sur Linux et configurer RDB + AOF
• Patterns de cache avec Redis 8

FAQ

Sentinel ou Cluster : que choisir ?

Sentinel pour des datasets sous 100 Go avec besoin de failover automatique mais pas de sharding (le maître unique gère 100 000+ ops/sec). Cluster dès qu’il faut sharder horizontalement le dataset ou que le débit dépasse les capacités d’un seul maître.

Combien de réplicas par maître ?

Un suffit pour le failover. Deux donnent une marge supplémentaire et permettent le load balancing en lecture (les réplicas peuvent servir des GET read-only). Trois et plus n’apportent qu’un coût en bande passante de réplication sans gain proportionnel.

Comment migrer de Sentinel à Cluster ?

Migration manuelle : (1) provisionner le cluster en parallèle, (2) double-écriture côté application pendant la transition, (3) copier les données existantes via --cluster import, (4) basculer la lecture sur le cluster, (5) arrêter Sentinel. Comptez plusieurs jours de migration pour un dataset important.

Le mode Cluster supporte-t-il les transactions MULTI/EXEC ?

Uniquement si toutes les clés impliquées sont sur le même slot. Utilisez les hash tags {...} pour forcer ce regroupement quand vous avez besoin d’atomicité. Pour des transactions cross-slot, il faut soit revoir la modélisation, soit utiliser des verrous distribués applicatifs.

Références

• Redis Sentinel — Documentation officielle
• Redis Cluster — Documentation officielle
• Replication Redis