Redis fornisce alta disponibilità tramite il sistema distribuito Redis Sentinel. Sentinel aiuta a monitorare le istanze di Redis, rilevare guasti e commutare automaticamente i ruoli consentendo così a un’implementazione di Redis di resistere a qualsiasi tipo di guasti.
Include il monitoraggio delle istanze di Redis (padrone e repliche), supporta la notifica di altri servizi/processi o dell’amministratore di sistema tramite uno script, failover automatico per promuovere una replica a padrone quando il padrone va giù e fornisce la configurazione per i client per scoprire il padrone attuale che offre un servizio particolare.
Questo articolo illustra come configurare Redis per l’alta disponibilità con Redis Sentinel in CentOS 8, incluso la configurazione dei sentinel, il controllo dello stato dell’implementazione e il test di un failover di Sentinel.
Prerequisito:
Configurazione dell’ambiente di
Master Server and Sentinel1: 10.42.0.247 Redis Replica1 and Sentinel2: 10.42.0.21 Redis Replica2 and Sentinel3: 10.42.0.34
Secondo la documentazione di Redis Sentinel, è necessario almeno tre istanze di Sentinel per una distribuzione robusta. Considerando la nostra configurazione sopra, se il master fallisce, Sentinels2 e Sentinel3 concorderanno sul fallimento e saranno in grado di autorizzare un failover, consentendo alle operazioni del client di continuare.
Passaggio 1: Avvio ed Abilitazione del Servizio di Redis Sentinel
1. Su CentOS 8, il servizio Redis Sentinel è installato insieme al server Redis (che abbiamo già fatto nella Configurazione della Replica di Redis).
Per avviare il servizio di Redis sentinel e abilitarlo per l’avvio automatico al boot di sistema, utilizza i seguenti comandi systemctl. Inoltre, conferma che sia attivo controllandone lo stato (fallo su tutti i nodi):
# systemctl start redis-sentinel # systemctl enable redis-sentinel # systemctl status redis-sentinel
Passaggio 2: Configurazione di Redis Sentinel su Tutti i Nodi Redis
2. In questa sezione, spieghiamo come configurare il Sentinel su tutti i nostri nodi. Il servizio Sentinel ha un formato di configurazione simile al server Redis. Per configurarlo, utilizza il file di configurazione auto-documentato /etc/redis-sentinel.conf.
Prima, crea un backup
# cp /etc/redis-sentinel.conf /etc/redis-sentinel.conf.orig # vi /etc/redis-sentinel.conf
3. Per default, Sentinel ascolta sulla porta 26379, verificare questo su tutte le istanze. Notare che deve lasciare il parametro bind commentato (o impostare a 0.0.0.0).
port 26379
4. Successivamente, diciamo a Sentinel di monitorare il nostro master e di considerarlo in uno stato “Objectively Down” solo se almeno 2 sentinelle del quorum concordano. Può sostituire “mymaster” con un nome personalizzato.
#On Master Server and Sentinel1 sentinel monitor mymaster 127.0.0.1 6379 2 #On Replica1 and Sentinel2 sentinel monitor mymaster 10.42.0.247 6379 2 #On Replica1 and Sentinel3 sentinel monitor mymaster 10.42.0.247 6379 2
Importante: L’istruzione sentinel monitor deve essere posta prima dell’istruzione sentinel auth-pass per evitare l’errore “No such master with the specified name.” quando si riavvia il servizio sentinel.
5. Se il Redis master da monitorare ha impostato una password (nel nostro caso il master ne ha una), fornire la password così che l’istanza Sentinel possa autenticarsi con l’istanza protetta.
sentinel auth-pass mymaster Securep@55Here
6. Quindi impostare il numero di millisecondi per cui il master (o qualsiasi replica collegata o sentinella) dovrebbe essere inaccessibile per considerarlo in uno stato “Subjectively Down”.
La configurazione seguente significa che il master sarà considerato fallito appena non riceviamo alcuna risposta ai nostri ping entro 5 secondi (1 secondo è equivalente a 1000 millisecondi).
sentinel down-after-milliseconds mymaster 5000
7. Successivamente, impostare il timeout del failover in millisecondi, che definisce molte cose (leggere la documentazione del parametro nel file di configurazione).
sentinel failover-timeout mymaster 180000
8. Poi impostare il numero di repliche che può essere riconfigurato per utilizzare il nuovo master dopo un failover allo stesso tempo. Visto che abbiamo due repliche, imposteremo una replica come l’altra sarà promossa come nuovo master.
sentinel parallel-syncs mymaster 1
Notare che i file di configurazione su Redis Replica1 e Sentinel2, e Reddis Replica1 e Sentinel2 dovrebbero essere identici.
9. Successivamente, riavviare i servizi Sentinel su tutti i nodi per applicare le recenti modifiche.
# systemctl restart redis-sentinel
10. Successivamente, aprire il porto 26379 nella firewall su tutti i nodi per consentire agli istanza Sentinel di iniziare a comunicare, ricevere connessioni dalle altre istanze Sentinel usando il firewall-cmd.
# firewall-cmd --zone=public --permanent --add-port=26379/tcp # firewall-cmd --reload
11. Tutte le repliche verranno automaticamente scoperte. Importante, Sentinel aggiongerà automaticamente la configurazione con informazioni aggiuntive riguardo le repliche. Confermare questo aprendo il file di configurazione Sentinel per ogni istanza e guardare all’interno.
Ad esempio, quando si guarda alla fine del file di configurazione del master, dovrebbe vedere le dichiarazioni known-sentinels e known-replica come mostrato nella seguente screenshot.
Lo stesso caso dovrebbe applicarsi su replica1 e replica2.
Notare che la configurazione Sentinel viene anche ri scritto/aggiornato ogni volta che una replica è promossa al master status durante un failover e ogni volta che una nuova Sentinel viene scoperta nella configurazione.
Passaggio 3: Controlla lo stato dell’installazione di Redis Sentinel
12. Controllare ora lo stato/informazioni del Sentinel sul master, utilizzando il comando info sentinel come segue.
# redis-cli -p 26379 info sentinel
Dall’output del comando come mostrato nello screenshot seguente, abbiamo due repliche/schiavi e tre sentinel.
13. Per visualizzare informazioni dettagliate sul master (chiamato mymaster), utilizzare il comando sentinel master.
# redis-cli -p 26379 sentinel master mymaster
14. Per visualizzare informazioni dettagliate sulle repliche/schiavi e sui sentinel, utilizzare rispettivamente il comando sentinel slaves e il comando sentinel sentinels.
# redis-cli -p 26379 sentinel slaves mymaster # redis-cli -p 26379 sentinel sentinels mymaster
15. Successivamente, chiedere l’indirizzo del master per nome dalle istanze slave utilizzando il comando sentinel get-master-addr-by-name come segue.
L’output dovrebbe essere l’indirizzo IP e la porta dell’istanza master attuale:
# redis-cli -p 26379 sentinel get-master-addr-by-name mymaster
Passaggio 4: Testa il failover di Sentinel
16. Infine, testiamo il failover automatico nella nostra configurazione di Sentinel. Sul Redis/Sentinel master, fai andare in sleep il Redis master (in esecuzione sulla porta 6379) per 60 secondi. Quindi interroga l’indirizzo del master attuale sulle repliche/schiavi come segue.
# redis-cli -p 6379 127.0.0.1:6379> AUTH Securep@55Here 127.0.0.1:6379> debug sleep 60 # redis-cli -p 26379 sentinel get-master-addr-by-name mymaster # redis-cli -p 26379 sentinel get-master-addr-by-name mymaster
Dall’output della query, il nuovo master è ora replica/schiavo2 con indirizzo IP 10.42.0.34 come mostrato nello screenshot seguente.
Puoi ottenere ulteriori informazioni dalla documentazione di Redis Sentinel. Ma se hai pensieri da condividere o domande, il modulo di feedback qui sotto è il tuo gateway verso di noi.
Nella prossima e ultima parte di questa serie, vedremo come configurare un cluster Redis in CentOS 8. Sarà un articolo indipendente rispetto ai primi due.
Source:
https://www.tecmint.com/setup-redis-high-availability-with-sentinel-in-centos-8/