Redis Sentinel-High Availability: Tutto quello che c’è da sapere da DEV a PROD: Guida completa

Che cosa significa in realtà il termine ‘Redis’?

Significa Server dizionario remoto.

Va bene! Ci sono un sacco di diversi articoli Redis là fuori, ma volevo condividere la mia esperienza come sviluppatore con Redis creando un “all in one articolo corretto” che copre le cose più essenziali e importanti che sono necessarie e utili per uno sviluppatore o un ingegnere devops per costruire un cluster Redis altamente disponibile con Sentinel.

Quindi iniziamo

Redis, che è un open source in memoria data structure store, è una selezione molto popolare tra gli sviluppatori utilizzati per scopi di caching, come broker di messaggi e anche utilizzato principalmente come database di valori chiave NoSQL per diversi casi d’uso.

In questo post, ho intenzione di discutere in modo specifico e demo su Redis insieme a replica Master/Slave, Alta disponibilità (Redis Sentinel), Failover automatico , alcuni suggerimenti di ottimizzazione del livello di produzione e aspetti di monitoraggio. Inoltre, insieme a questi argomenti citerò i problemi e gli errori che ho affrontato durante l’implementazione di Redis Sentinel con Ubuntu. Di seguito viene mostrata la versione del sistema operativo e i dettagli della versione Redis.

OS version: Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-119-generic x86_64)
Redis Version: 4.0.9

Inoltre, voglio evidenziare che la documentazione di Redis è molto informativa ed è “il punto di partenza” se hai bisogno di ulteriori chiarimenti su Redis.

Passando alle basi di Redis; Redis è un database in memoria, semplicemente il che significa che Redis gira su RAM. È inoltre necessario sapere che Redis supporta diverse strutture di dati come stringhe, hash, elenchi, set, set ordinati con query di intervallo, bitmap. Inoltre, supporta anche operazioni atomiche come, aggiungendo a una stringa, incrementando il valore in un hash, spingendo un elemento in un elenco e così via.

Bene, iniziamo le cose con l’alta disponibilità di Redis.

Redis sentinel è la soluzione ad alta disponibilità offerta da Redis. In caso di errore nel cluster Redis, Sentinel rileva automaticamente il punto di errore e riporta il cluster in modalità stabile senza alcun intervento umano.

Cosa succede realmente all’interno di Redis Sentinel ?

Sentinel controlla sempre le istanze MASTER e SLAVE nel cluster Redis, controllando se funzionano come previsto. Se sentinel rileva un errore nel nodo MASTER in un determinato cluster, Sentinel avvierà un processo di failover. Di conseguenza, Sentinel sceglierà un’istanza SLAVE e la promuoverà a MASTER. In definitiva, le altre istanze SLAVE rimanenti verranno automaticamente riconfigurate per utilizzare la nuova istanza MASTER.

Sentinel funge da provider di configurazione o da fonte di autorità per l’individuazione del servizio client.

Che cosa significa ? Semplicemente, i client delle applicazioni si connettono alle Sentinelle e le Sentinelle forniscono l’ultimo indirizzo MASTER Redis a loro.

Inoltre, Sentinel è un robusto sistema distribuito, in cui più sentinel devono accettare il fatto che un dato master non è più disponibile. Quindi solo il processo di failover inizia a selezionare un nuovo nodo MASTER. Questo accordo sentinella viene fatto in base al valore del quorum.

Che cos’è il quorum ?

Il valore del quorum è il numero di Sentinelle che devono concordare sul fatto che il master non è raggiungibile. Tuttavia il quorum viene utilizzato solo per rilevare l’errore. Per poter effettivamente eseguire un failover, una delle Sentinelle deve essere eletta leader per il failover ed essere autorizzata a procedere. Questo accade solo con il voto della maggioranza dei processi Sentinella.

Sporciamoci le mani con Redis Sentinel.

Ci atteniamo alla configurazione di base con 3 istanze del server.

Si prega di fare riferimento al diagramma sopra che illustra la configurazione di base dell’istanza 3 server. Prima di tutto assicurati che le tue istanze di Ubuntu siano aggiornate con le dipendenze di compilazione rilevanti. A volte, potresti aver bisogno anche di jemalloc. Di seguito vengono illustrati i passaggi per installare Redis sulle istanze del server.

sudo apt-get update 
sudo apt-get install build-essential tcl
sudo apt-get install libjemalloc-dev (Optional)curl -O http://download.redis.io/redis-stable.tar.gz
tar xzvf redis-stable.tar.gz
cd redis-stable
make
make test
sudo make install

Ora nella directory redis dovresti essere in grado di vedere entrambi i redis.conf e sentinella.file di configurazione conf.

Prima di eseguire Redis facciamo alcune configurazioni di base necessarie per eseguire ed eseguire un cluster Redis. Di seguito sono riportati gli indirizzi IP di questa configurazione.

10.52.209.46 (Initial Master Node)
10.52.209.47 (Initial Slave Node)
10.52.209.49 (Initial Slave Node)

La porta predefinita per il server Redis è 6379 e Sentinel è 26379. Quindi assicurati di aprire queste porte usando,

sudo ufw allow 6379
sudo ufw allow 26379

Le configurazioni Redis (sia in redis.conf e sentinella.conf) nei server di cui sopra dovrebbe essere configurato come segue.

Per la configurazione di base sopra le configurazioni saranno sufficienti, ma per il livello di produzione si prega di considerare i suggerimenti menzionati nell’ultima parte di questo post. L’unica differenza in redis.i file conf in 3 server sono che tutti gli slave devono avere la seguente configurazione. 10.52.209.46 è l’indirizzo IP principale.

slaveof 10.52.209.46 6379

slaveof dice a Redis cluster di rendere questa particolare istanza del server come istanza SLAVE del nodo MASTER specificato (10.52.209.46).

In sentinel.conf, dopo config notificare Sentinel per avviare il monitoraggio del cluster con le seguenti impostazioni iniziali. Successivamente questa impostazione di configurazione potrebbe essere aggiornata automaticamente di conseguenza.

sentinel monitor mymaster 10.52.209.46 6379 2
(This tells sentinel to monitor the master node. And the last argument which is 2 is the quorum value)

Inoltre, sentinella.conf include anche i seguenti valori di configurazione.

sentinel down-after-milliseconds mymaster 5000
(Means server will unresponsive for 5 seconds before being classified as +down and consequently activating a +vote to elect a new master node.)sentinel failover-timeout mymaster 10000
(Specifies the failover timeout in milliseconds.)

Okie Dokie! Ora run chiamiamo Redis.

Esistono molti modi per eseguire Redis. In questa demo mi atterrò al seguente comando.

(Go to src folder.)
cd src/ && redis-server ../redis.conf &
cd src/ && redis-server ../sentinel.conf — sentinel &(Or else you can simply use cd utils && ./install_server.sh.)

Dopodiché, puoi semplicemente controllare i processi Redis tramite il comando ps-ef | grep redis. Ogni istanza del server deve eseguire sia un processo Redis che un processo Sentinel. Se tutto va al piano, ci dovrebbero essere 2 processi in esecuzione come segue.

Ora connettiti al client Redis tramite uno dei seguenti comandi e verifica se Redis funziona correttamente.

redis-cli ping
or
redis-cli -h IP_Address pingYou should get a output of PONG.

Impressionante! Ora avete Redis installato e funzionante. Concentriamoci sulla replica Master/Slave.

Replica Master/Slave

Ora se si controlla il redis.log (che si trova nel luogo che abbiamo definito nel redis.conf) di ogni istanza, è possibile vedere la sincronizzazione Master — Slave avvenuta.

Nodo principale-redis.registro

nodo Slave — redis.registro

Verifica Stato di Replica

È possibile controllare le informazioni di replica tramite info replica di comando in Redis CLI. Sotto l’attributo role indica se quel particolare nodo è un MASTER o uno SLAVE(riquadro giallo). Inoltre, nel nodo Master, visualizza i dettagli di tutti gli slave collegati. (scatola verde)

Ora esaminiamo cosa sentinella.log indicare. (che si trova nel luogo che abbiamo definito nella sentinella.conf)

Inoltre, se si controlla la sentinella.file conf, si può arrivare a vedere che il file conf viene aggiornato automaticamente con le ultime configurazioni, tra cui sentinel known-slave e sentinel known-sentinel valori.

Figo! Ora creiamo un valore di esempio in tutti i nodi.

127.0.0.1:6739> set demokey "Amila"

Come puoi vedere nel diagramma sopra, gli SLAVE sono di SOLA LETTURA, quindi puoi solo scrivere dati su Master. Poiché Redis replica in modo asincrono con tutti gli slave rimanenti, è possibile recuperare il valore inserito da qualsiasi slave Redis utilizzando la stessa chiave data. Inoltre tramite,KEYS* è possibile elencare tutte le chiavi inserite. Sopra diagramma descrive chiaramente ciò che abbiamo appena parlato.

Ora controlliamo come funziona il Failover automatico Redis Sentinel.

Redis Sentinel Failover automatico

Okiee! Simuliamo uno scenario di failover automatico. Al fine di simulare uno scenario di failover si può semplicemente fermare il server Redis o uccidere il processo Redis nell’istanza MASTER. Anche tu puoi dormire anche il processo Redis. Puoi scegliere qualunque sia il modo in cui desideri.

kill -9 <process id>
or
redis-cli -p 6379 DEBUG sleep 30
or
redis-cli -p 6379 DEBUG SEGFAULT

Come illustrato nel diagramma di cui sopra, in uno scenario di failover, se il nodo principale si guasta, il restante 2 Sentinelle a determinare il failover e se si impegna (Dal quorum valore 2 ), poi un nuovo MASTER sarà eletto da quei 2 nodi rimanenti.

Di seguito viene mostrata la coda del registro per questo scenario di failover.

redis.registro dei nodi Slave.

sentinella.registro dei nodi Slave

Ora controlliamo lo stato della replica tramite il comando info replication.

Elaborando ulteriormente la coda del tronco,

Ogni Sentinel rileva che il master è inattivo con un evento +sdown. (+sdown significa che l’istanza specificata è ora in stato Soggettivamente basso.)

+new-epoch significa che l’epoca corrente è stata aggiornata.

+sdown l’evento viene successivamente intensificato a +odown, il che significa che più Sentinelle concordano sul fatto che il master non è raggiungibile. (+odown significa che l’istanza specificata è ora in uno stato oggettivamente basso.)

Sentinel + vota una Sentinel che avvierà il primo tentativo di failover.

Il failover avviene.

Inoltre, di seguito mostra i lavori upstart.

Parvenu per Redis

description "Redis Server"start on runlevel 
stop on runlevel script
echo $$ > /var/run/redis.pid
su - amila -c "cd /home/amila/redis-stable/src/; redis-server ../redis.conf"
end scriptpost-stop script
rm -f /var/run/redis.pid
end script

Parvenu per Sentinel

description "Redis Sentinel Server"start on runlevel 
stop on runlevel script
echo $$ > /var/run/redis.pid
su - amila -c "cd /home/amila/redis-stable/src/; redis-server ../sentinel.conf --sentinel"
end scriptpost-stop script
rm -f /var/run/redis.pid
end script

Congratulazioni! Questo è semplicemente. Ecco come Redis gestisce l’alta disponibilità e il failover automatico. Ora diamo uno sguardo su alcuni fatti interessanti Redis prima di saltare a ottimizzare suggerimenti e trucchi.

Fatti interessanti su Redis.

Redis può gestire fino a 2 32 chiavi, ed è stato testato in pratica per gestire almeno 250 milioni di chiavi per istanza.

Un’istanza vuota utilizza ~ 3 MB di memoria.

1 milione di piccoli tasti -> Coppie di valori stringa utilizzano ~ 85 MB di memoria.

1 milione di chiavi -> Valore Hash, che rappresenta un oggetto con 5 campi, utilizzare ~ 160 MB di memoria.

Redis è single threaded. Come posso sfruttare più CPU / core?

Non è molto frequente che la CPU diventi il collo di bottiglia con Redis, poiché di solito Redis è legato alla memoria o alla rete. In tal caso, il ridimensionamento orizzontale o verticale delle istanze Redis contribuirà a ridurre i colli di bottiglia relativi alla CPU.

Redis è un database in memoria ma persistente su disco.

Persistenza Redis- > RDB : istantanee puntuali del set di dati a intervalli specificati. (Backup dei dati)| AOF : registra ogni operazione di scrittura ricevuta dal server. (Più durevole)

Se si utilizza Java, è possibile utilizzare Jedis che è un client java, per collegare l’applicazione Java con Redis. Nota: Jedis utilizza Apache Commons Pool per il pool di connessioni (GenericObjectPool). A single Jedis instance is not threadsafe! Per evitare questi problemi, è necessario utilizzare JedisPool, che è un pool di connessioni di rete threadsafe. La dimensione massima predefinita del pool di connessioni è 8.

Ora concentriamoci sui problemi/errori che potresti ottenere e su alcuni suggerimenti e trucchi per ottimizzare le prestazioni di produzione per Redis.

Problemi/Errore che potresti ottenere& Ottimizzazione delle prestazioni di produzione suggerimenti e trucchi

Prima di tutto, nei redis.conf e sentinella.conf, tutte le configurazioni sono in un ordine, quindi non rovinare l’ordine. Altrimenti otterrete errori di configurazione come segue.

*** FATAL CONFIG FILE ERROR ***
Reading the configuration file, at line 98
>>> 'sentinel down-after-milliseconds mymaster 5000'
No such master with specified name.

Dal punto di vista della sicurezza, impostare una password per l’autenticazione con il master e gli slave. Per questo puoi facilmente cambiare il redis.conf e sentinella.conf di conseguenza con il seguente valore di configurazione.

In sentinel.conf
sentinel auth-pass <master-name> <password>In redis.conf
masterauth <master-password>

Fa che l’impostazione del backlog TCP (connessioni massime) sia 511. È possibile impostare tale valore di conseguenza (considerando le specifiche del server) con i seguenti passaggi.

sudo nano /etc/rc.local
Add this:
sysctl -w net.core.somaxconn=65535When you reboot the next time, the new setting will be to allow 65535 connections instead of 128 as before. When you add the line to rc.local make sure it's before the exit 0.

Alcuni degli avvisi che potresti incontrare dai redis.log potrebbe essere,

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.You can add this via following command as well as using a cat command you can makesure whether the value is set properly.echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
cat /etc/sysctl.conf

Potrebbe essere necessario disabilitare THP o Pagina enorme trasparente.

WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.Fixsudo nano /etc/rc.local
echo never > /sys/kernel/mm/transparent_hugepage/enabled

L’uso del socket UNIX invece della porta TCP 6379 contribuirà anche al guadagno delle prestazioni di Redis.

Per raggiungere questo obiettivo, redis.conf dovrebbe essere cambiato alla seguente impostazione.

unixsocket /var/run/redis.sock
unixsocketperm 777# Accept connections on the specified port, default is 6379.
# If port 0 is specified Redis will not listen on a TCP socket.
port 0

Inoltre, a seconda del caso d’uso, è possibile configurare anche l’opzione di persistenza Redis.

Se lo desideri, puoi disabilitare la persistenza, se vuoi che i tuoi dati esistano solo finché il server è in esecuzione. Nota: è possibile disabilitare la persistenza RDB commentando tutte le righe “salva” in redis.conf come segue.

Comment out these 3 values in redis.conf
save 900 1
save 300 10
save 60 10000rdbcompression no
rdbchecksum no

AOF persistance (Aggiungi solo file) è disabilitato per impostazione predefinita in redis.conf.

appendonly no

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Monitoraggio Redis

Dal punto di vista del monitoraggio, esistono diversi strumenti per monitorare Redis. NewRelic fornisce funzionalità avanzate per monitorare e analizzare i Redis, tra cui “La maggior parte delle operazioni db consumate in tempo”,” operazioni per throughput”,” operazioni per tempo di query ” e così via.

Maggiori informazioni su New Relic Redis sono menzionate qui. Inoltre, Redis-stat è anche un buon strumento di monitoraggio Redis opensource.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

AWS ElastiCache

AWS offre anche un servizio cloud di cache in memoria denominato “ElastiCache”, che viene fornito anche con Redis incluso. Può essere specificato come un servizio cloud efficace e facile da usare, che scarica la maggior parte delle configurazioni manuali e delle attività amministrative.

ElastiCache è un servizio Web che semplifica l’avvio, la gestione e la scalabilità di una cache in memoria distribuita nel cloud.

è Interessante notare che, viene fornito con una favolosa funzioni avanzate come la Modalità Cluster con sharding in pochi click, Multi-AZ con Auto-Failover, la Crittografia a riposo, la Crittografia in transito, Importazione di file RDB per S3, Attivare il backup automatico e molti altri.

più Cool funzionalità di AWS ElastichCache è che, offre una completa cruscotto di monitoraggio per il vostro Redis cluster, compreso il monitoraggio degli aspetti della CPU/utilizzo della Memoria (Swap e Freeable memoria), numero di connessioni, il numero di elementi, Sfratti, String;Chiave;Hash di Comando basato su conte, Ritardo di replica e molte altre.

Beh… Questo è più o meno per questo post!

Come ho detto all’inizio di questo post, ci sono un sacco di diversi articoli Redis là fuori, ma ho voluto creare un “all in one articolo corretto” che copre i fatti più essenziali e suggerimenti che è necessario e utile per uno sviluppatore o un ingegnere devops per costruire un cluster Redis altamente disponibile con Sentinel.

Prima di finire questo post, uno degli articoli interessanti che ho trovato è stato Come Flickr ha implementato Redis Sentinel. Si prega di assicurarsi di controllare quel post pure.

OK. Quindi grazie mille per aver letto questo articolo e non vedo l’ora di venire con un altro articolo interessante presto, condividere la mia esperienza come sviluppatore. Fino ad allora, Salute! e Codifica felice!