Tuto Redis en Haute Dispo, partie II : Mise en place de Redis

Tuto révisé en décembre 2022

 

Dans cette seconde partie de la série sur Redis, nous allons mettre en place nos deux serveurs Redis et également Sentinel.

I – Mise en place de Redis en Master/Slave

A – Préparatifs

Avant de commencer, on va faire quelques réglages pour redis.

Sur les deux serveurs,  éditez le fichier /etc/sysctl.conf pour y ajouter :

net.core.somaxconn = 65535
vm.overcommit_memory = 1

Puis :

redisX# sysctl -p

B – Redis

On installe redis sur les deux serveurs :

redisX# apt-get install redis-server redis-tools

On stop le service :

redisX# service redis-server stop

Et on va éditer le fichier /etc/redis/redis.conf sur chaque serveur ( pensez à modifier l’adresse de bind) :

bind 10.50.0.10X
protected-mode no
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
supervised no
pidfile "/var/run/redis/redis-server.pid"
loglevel notice
logfile "/var/log/redis/redis-server.log"
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename "dump.rdb"
dir "/var/lib/redis"
slave-serve-stale-data yes
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
maxmemory-policy noeviction
appendonly yes
appendfilename "appendonly.aof"
appendfsync always
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-rewrite-incremental-fsync yes
aof-load-truncated yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10

Et pour terminer, on lance le service sur les deux serveurs :

redisX# service redis-server start

Pour les logs :

redisX# tail -f /var/log/redis/redis-server.log

 

C – Réplication

Maintenant, il s’agit de déclarer que Redis2 est le slave de Redis1.

Rien de plus simple, on se connecte sur le serveur redis2 :

redis2# redis-cli -h 10.50.0.102

Puis :

10.50.0.102:6379> SLAVEOF 10.50.0.101 6379

Sur les logs, on voit passer la manipulation.

Je crois qu’on ne peut pas faire plus simple pour une réplication Master/Slave.

 

D – Sentinel

La mise en place de Sentinel est rapide.

Sur Redis2, on va créer le fichier /etc/redis/sentinel.conf et mettre :

port 26379
bind 10.50.0.102
supervised systemd
logfile "/var/log/redis/redis-server.log"
dir "/etc/redis"
sentinel monitor master 10.50.0.101 6379 1
sentinel down-after-milliseconds master 1000
sentinel failover-timeout master 1000

On pense à changer le proprio et le groupe, Redis écrivant dynamiquement les configs (Server et Sentinel). Pour la partie serveur, comme on a édité le fichier de base et garder le service de base,  les droits sont déjà bon …)

redis2# chown redis:redis /etc/redis/sentinel.conf

On créer le fichier /etc/systemd/system/redis-sentinel.service :

[Unit]
Description=Redis Sentinel
After=network.target

[Service]
Type=notify
ExecStart=/usr/bin/redis-server /etc/redis/sentinel.conf --sentinel
Restart=always
User=redis
Group=redis
ReadWriteDirectories=/etc/redis


[Install]
WantedBy=multi-user.target

On active au boot :

redis2# systemctl enable redis-sentinel.service

On démarre

redis2# service redis-sentinel start

Puis pour vérifier :

redisX# tail -f /var/log/redis/redis-server.log

Voila, c’était rapide.

 

II – Tests

Avant d’aller plus loin, on va déjà tester nos serveurs Redis.

A – Master/Slave

Sur le serveur Redis1

redis1# redis-cli -h 10.50.0.101 -p 6379

Puis on écrit :

10.50.0.101:6379> SET test 1234

et on récupère :

10.50.0.101:6379> GET test

Jusque la, logique.

 

Sur le serveur Redis 2 :

redis2# redis-cli -h 10.50.0.102 -p 6379

Si on essaye d’écrire :

10.50.0.102:6379> SET test2 1234

indique que nous somme en lecture seule, ce qui est donc bon.

Par contre, on peut tout à fait récupérer l’autre clé qu’on avait écrit sur Redis 1 :

10.50.0.102:6379> GET test

Jusque la, tout vas bien.

 

B – Redis Slave qui tombe

Coupons redis sur Redis2 :

redis2# service redis-server stop

Ecrivons une clé sur Redis1 :

redis1# redis-cli -h 10.50.0.101 -p 6379

10.50.0.101:6379> SET test2 1234

Relançons Redis2 :

redis2# service redis-server start

Les logs doivent indiquer la synchronisation.

On interroge redis 2 :

redis2# redis-cli -h 10.50.0.102 -p 6379

10.50.0.102:6379> GET test2

On récupère bien la clé écrite sur Redis1 pendant le down de Redis2.

 

C – Redis Master qui tombe

Maintenant, testons en coupant redis sur Redis1 :

redis1# service redis-server stop

Sur Redis2, on doit voir passer dans les logs Sentinel qui voit le down et qui passe le Slave en Master.

On peut d’ailleurs tester :

redis2# redis-cli -h 10.50.0.102 -p 6379

10.50.0.102:6379> SET test3 1234

On a pu écrire.

Maintenant, que se passe t’il quand Redis1 revient ?

Et bien il devient automatique backup de Redis2. Les configurations sont d’ailleurs réécrites (d’où les droits sur le fichier de configuration).

Et si on essaye :

redis1# redis-cli -h 10.50.0.101 -p 6379

10.50.0.101:6379> SET test4 1234

On ne peut pas.

Par contre, on peut récupérer la clé qu’on a inséré sur Redis2 :

10.50.0.101:6379> GET test3

 

D – Revenir en configuration initiale

Bon, c’est bien joli, on a nos deux serveurs qui tournent, mais du coup, c’est Redis2 le master et Redis1 le slave.

Et j’ai envie de remettre le master sur Redis1.

Comment faire ? Et bien, c’est tout bête…

Il suffit de couper et relancer redis sur Redis2 pour que le redis de Redis1 repasse master.

Sur Redis2 :

redis2# service redis-server stop

Sentinel sur Redis2 déclare du coup Redis1 en master. On peut le voir dans les logs.

Et quand on redémarre Redis2 :

redis2# service redis-server start

Il redevient backup de Redis1, retour à la normale.

 

III – Conclusion

Nos tests sont concluants, le cluster Redis est opérationnel.

On peut poursuivre avec la mise en place des loadbalancers et de la VIP.

 

---

Envie de me soutenir et de me payer un café ? C’est sur la page Don !