Redis Sentinel — Failover Automatico e Alta Disponibilità senza Riscrivere il Codice

Il tuo Redis va giù e il sito rallenta fino a sembrare morto. Gli utenti abbandonano il carrello, il supporto si riempie di ticket e tu scopri che il tuo "sistema in memoria" era un singolo punto di rottura. Succede più spesso di quanto si creda, soprattutto nelle PMI che usano Redis per sessioni, code o cache ma lo trattano come una scatola nera infallibile. Non lo è.

Noi, di Meteora Web, lo vediamo nei progetti che ci arrivano: Redis configurato in fretta, senza replica, senza monitoraggio, senza un piano se il processo muore o il server va in crash. E quando Redis non risponde, l'applicazione non risponde. La soluzione non è comprare un server più grosso, è progettare l'alta disponibilità. Redis Sentinel fa esattamente questo: monitora, notifica e promuove automaticamente una replica a master quando il nodo principale fallisce. Senza che tu debba riscrivere una riga di codice lato applicazione.

Perché Redis Sentinel è la risposta al tuo singolo punto di rottura?

Se hai un solo server Redis, hai un singolo punto di rottura. Se quel server muore, la tua applicazione non ha più cache, non ha più sessioni, non ha più code. Tutto si blocca. La replica da sola non basta: se il master muore, le repliche restano lì a leggere dati vecchi, senza un comando che le promuova. Serve qualcuno che decida, in automatico, chi diventa il nuovo master.

Sentinel è un processo separato che fa da sentinella, appunto. Osserva il master e le repliche, verifica che rispondano, e se il master sparisce dalla circolazione, indice una votazione tra le sentinelle (il quorum) e promuove una replica a master. Le altre repliche vengono riconfigurate per seguire il nuovo master. L'applicazione continua a funzionare, magari con un piccolo ritardo, ma senza interruzione totale del servizio.

L'alternativa è il failover manuale: ti accorgi che Redis è giù, ti colleghi al server, promuovi la replica a mano e aggiorni la configurazione. Questo significa minuti (o ore) di downtime, errori umani e clienti che se ne vanno. Sentinella fa tutto in secondi, e ti manda anche una notifica via log o webhook.

Come funziona il quorum e perché non puoi ignorarlo

Il quorum è il numero minimo di sentinelle che devono concordare che il master non è raggiungibile per avviare il failover. Se hai tre sentinelle e il quorum è 2, servono almeno due sentinelle che dicano "il master è giù" prima di agire. Questo evita falsi positivi: se una sola sentinella ha un problema di rete, non butta giù tutto il sistema.

La regola pratica che usiamo noi: almeno tre sentinelle, quorum a due. Con tre sentinelle hai la maggioranza anche se una muore. Con due, se una muore e il master fallisce, non hai più il quorum e il failover non parte. Sembra un dettaglio, ma è la differenza tra un sistema che si riprende da solo e uno che ti lascia a terra.

Come configurare Redis Sentinel per il failover automatico?

La configurazione parte dal file sentinel.conf. Ogni sentinella deve sapere quale master monitorare, con quale quorum, e dove trovare le repliche. Ecco un esempio minimale ma funzionante, che usiamo come base nei nostri progetti:

# /etc/redis/sentinel.conf
port 26379
dir /var/lib/redis
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster LaTuaPasswordSuperSegreta

Le direttive chiave sono tre. down-after-milliseconds dice a Sentinel dopo quanto tempo di silenzio considerare il master giù. failover-timeout è il tempo massimo per completare il failover. parallel-syncs controlla quante repliche possono sincronizzarsi col nuovo master contemporaneamente, per non sovraccaricare il server.

Avviare una sentinella è semplice: redis-sentinel /etc/redis/sentinel.conf. Ma se la configuri solo su un server, hai spostato il problema, non risolto. Le sentinelle devono essere su macchine diverse, idealmente in data center o zone di disponibilità differenti. Noi le mettiamo sempre su tre server separati, mai tutte sullo stesso host del master.

Come testare il failover senza aspettare il disastro

Non aspettare che il master muoia da solo per scoprire se la configurazione funziona. Testa il failover in modo controllato. Su una replica, esegui:

redis-cli -p 26379 sentinel failover mymaster

Questo comando forza Sentinel a eseguire il failover immediatamente, promuovendo una replica a master. Se tutto è configurato bene, in pochi secondi vedrai il nuovo master attivo e le altre repliche che lo seguono. Se qualcosa non va, lo scopri adesso, non quando il tuo e-commerce è sotto attacco o in piena stagione di vendite.

Dopo il test, controlla lo stato con redis-cli -p 26379 sentinel master mymaster e verifica che l'indirizzo del master sia cambiato. Poi riconfigura l'applicazione per puntare alle sentinelle, non al master diretto.

Quale impatto ha Sentinel sul tuo codice applicativo?

Il bello di Sentinel è che non devi riscrivere l'applicazione. I client Redis più diffusi (in PHP, Python, Node, Java) supportano nativamente la connessione tramite sentinelle. Passi dalla stringa di connessione a un elenco di sentinelle, e il client si occupa di scoprire chi è il master corrente e di riconnettersi automaticamente dopo un failover.

In PHP con Predis, ad esempio, la configurazione cambia così:

$client = new Predis\Client([
    'sentinels' => [
        ['host' => 'sentinel1.example.com', 'port' => 26379],
        ['host' => 'sentinel2.example.com', 'port' => 26379],
        ['host' => 'sentinel3.example.com', 'port' => 26379],
    ],
    'service' => 'mymaster',
    'parameters' => ['password' => 'LaTuaPasswordSuperSegreta'],
]);

Il client interroga le sentinelle, trova il master attivo e si connette. Se il master cambia, il client lo scopre alla riconnessione successiva. Nessuna modifica alla logica di business, nessun intervento manuale. Questo è il motivo per cui insistiamo sempre: possedere il proprio stack e configurarlo bene batte qualsiasi scorciatoia.

Errori comuni che trasformano Sentinel in un boomerang

Il primo errore è configurare tutte le sentinelle sullo stesso server del master. Se il server muore, muoiono anche le sentinelle, e il failover non parte. Il secondo errore è dimenticare la password: se Redis richiede l'autenticazione, Sentinel deve averla configurata, altrimenti non riesce a monitorare nulla. Il terzo errore è non testare mai il failover, scoprendo solo a disastro avvenuto che il quorum era sbagliato o che i timeout erano troppo corti.

Un altro errore subdolo: usare localhost nella configurazione del master. Se le sentinelle sono su macchine diverse, non riusciranno mai a raggiungere il master su 127.0.0.1. Usa sempre l'IP privato o il nome host del server. Lo vediamo spesso nei progetti che ci arrivano: configurazioni copiate da tutorial senza adattarle all'ambiente reale.

Come monitorare lo stato di Sentinel e prevenire i problemi?

Sentinel non è solo failover: è anche monitoraggio. Puoi interrogarlo in tempo reale per sapere chi è il master, quali repliche sono attive e se ci sono problemi di comunicazione. Il comando base è:

redis-cli -p 26379 sentinel master mymaster
redis-cli -p 26379 sentinel replicas mymaster

Il primo mostra lo stato del master (indirizzo, numero di repliche, ultimo failover). Il secondo elenca le repliche e il loro stato. Integra queste query in un sistema di alerting: se il numero di repliche scende o il master cambia senza un tuo intervento, qualcosa non va. Noi usiamo script semplici in cron che interrogano Sentinel e inviano una notifica su Slack o via email se rilevano anomalie.

E non dimenticare i log di Sentinel. Di default scrivono in /var/log/redis/sentinel.log. Controllali periodicamente: contengono la storia dei failover, i cambi di stato e i messaggi di errore. Sono la tua memoria storica per capire cosa è successo e perché.

Quali alternative a Sentinel per l'alta disponibilità di Redis?

Sentinel è la soluzione classica e più diffusa, ma non l'unica. Redis Cluster offre sharding e alta disponibilità integrata, ma richiede una configurazione più complessa e un numero minimo di nodi. Se hai bisogno di scalare orizzontalmente la scrittura, Cluster è la strada. Se hai un carico di lettura/scrittura su un singolo dataset, Sentinel è più semplice e sufficiente.

Ci sono anche soluzioni gestite come Redis Cloud o Amazon ElastiCache, che gestiscono il failover per te. Ma hanno un costo, spesso sotto forma di canone mensile e lock-in. Noi, di Meteora Web, preferiamo il controllo totale: possedere il proprio stack batte affittarlo. Con Sentinel, il failover è automatico, il codice non cambia e i costi sono solo quelli dei server che già hai.

Se vuoi approfondire come evitare che Redis vada in crash sotto carico, ti consigliamo la nostra guida su PgBouncer e Connection Limits — il principio è lo stesso: prevenire il collasso prima che accada. E per una visione d'insieme su Redis e caching, parti dalla nostra guida pillar su Redis e Caching Strategies.

Cosa fare adesso

Non aspettare che Redis muoia per agire. Ecco i passi immediati:

1. Conta i tuoi nodi Redis. Se hai un solo server, hai un singolo punto di rottura. Pianifica almeno una replica e tre sentinelle su macchine diverse.

2. Configura Sentinel con quorum a 2. Usa il file di esempio sopra, adatta IP e password, e avvia le sentinelle su tre server separati.

3. Testa il failover ora. Esegui redis-cli -p 26379 sentinel failover mymaster e verifica che tutto funzioni. Se qualcosa si blocca, risolvi adesso, non quando il sito è giù.

4. Aggiorna la configurazione dell'app. Passa i tuoi client Redis a usare le sentinelle, non il master diretto. È una modifica di poche righe, ma cambia tutto.

5. Monitora e impara. Interroga Sentinel periodicamente, controlla i log e configura alerting. Un sistema che non monitori è un sistema che ti tradirà nel momento peggiore.