par Elle est enfin la, la troisième partie de la série sur Redis !
Bon, faut se remettre dans le bain, donc, je vous invite à lire les articles précédents.
C’est bon ?
Nous allons rendre notre instance Redis accessible à nos clients.
Les deux redis communiquant sur 10.30.1.XXX, ils ne sont pas joignables directement (et c’est bien ce que je voulais).
Comme vu dans la partie I, nous aurons des loadbalancers avec Haproxy et une VIP avec Keepalived.
Un Loadbalancer sera actif par défaut, l’autre prenant la main si le premier se casse la figure.
C’est très redondant, mais ainsi pas de spof (single point of failure)
Sommaire
I – Loadbalancers
Commençons par les loadbalancers qui seront deux HAProxy.
L’astuce est d’utiliser les contrôles Tcp-check de HAProxy pour vérifier le statut du serveur.
Si le rôle master est détecté, alors le serveur est OK pour les transactions. Sinon, il passe en timeout et n’est pas utilisé.
A – Préparatifs
Avant de commencer, sur les deux serveurs, on va éditer le fichier /etc/sysctl.conf pour ajouter :
net.ipv4.ip_nonlocal_bind = 1
Puis :
redisX# sysctl -p
Pourquoi ?
Et bien, sans cela, HAParoxy ne pourra pas démarrer. Oui, le corniaud ne peut pas binder l’adresse 10.20.1.130 vu qu’elle n’existe pas sur le serveur.
L’autre solution, c’est de la rajouter dans /etc/network/interfaces :
auto lo:0 iface lo:0 inet static address 10.20.1.130
Puis de la monter :
redisX# ifup lo:0
B – Installation et configuration
Pour installer HAProxy :
redisX# apt-get install haproxy
Sur les deux serveurs, on aura une configuration identique et ce, dans le fichier /etc/haproxy/haproxy.conf :
global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin stats timeout 30s user haproxy group haproxy daemon defaults log global mode tcp timeout connect 4s timeout server 30s timeout client 30s mailers smtp mailer smtp1 ip.smtp frontend front_redis bind 10.20.1.130:6379 name redis default_backend back_redis backend back_redis email-alert mailers smtp email-alert level alert email-alert from haproxyX@mondomaine.fr email-alert to monmail@mondomaine.fr mode tcp option tcplog option tcp-check tcp-check send PING\r\n tcp-check expect string +PONG tcp-check send info\ replication\r\n tcp-check expect string role:master tcp-check send QUIT\r\n tcp-check expect string +OK server redis1 10.30.1.131:6379 check inter 1s server redis2 10.30.1.132:6379 check inter 1s
On prend juste bien soin de demander les serveurs redis sur le réseau 10.30.1.0/24.
HAProxy fournissant le front-end sur 10.20.1.130 (VIP qu’on mettra en place avec Keepalived).
On modifie également l’adresse d’expédition.
Et on peut enfin démarrer les Haproxys sur les deux serveurs :
redisX# service haproxy start
C – Status Haproxy
Pour voir le status de HAProxy, vous pouvez utiliser cela :
redisX# apt-get install hatop
Puis :
redisX# hatop -s /var/run/haproxy/admin.sock
Ou alors, si vous aimez les interfaces Web, vous rajoutez cela dans les fichiers /etc/haproxy/haproxy.cfg :
listen stats bind 0.0.0.0:8282 mode http timeout client 5000 timeout connect 4000 timeout server 30000 stats hide-version stats uri /haredisX/ stats realm HAProxy\ Statistics Web stats auth admin:password stats admin if TRUE
Changez le stats uri par haredis1 ou haredis2 et le login/mdp dans stats auth
Puis :
redisX# service haproxy restart
Avec en amont dans votre reverse proxy quelque chose qui ressemble à :
location /haredis1 {
proxy_pass http://10.20.1.131:8282/haredis1;
proxy_http_version 1.1;
}
location /haredis2 {
proxy_pass http://10.20.1.132:8282/haredis2;
proxy_http_version 1.1;
}et bien sur :
reverse# service nginx reload
Et vous avez alors l’interface Web des statistiques disponible en web.
II – Keepalived
Les loadbalancers sont prêts, il ne reste plus que la VIP, pour rappel, 10.20.1.130.
On installe sur les deux serveurs :
redisx# apt-get install keepalived
Puis on créer un fichier /etc/keepalived.conf sur chaque serveur.
Pour Redis1 :
global_defs {
router_id redis1
enable_script_security
notification_email {
nicolas@debugo.fr
}
notification_email_from keepalived-redis1@mondomaine.fr
smtp_server ip.smtp
smtp_connect_timeout 30
}
vrrp_script check_ha {
script "/bin/pidof haproxy"
interval 2
fall 1
rise 1
}
vrrp_instance REDISMASTER {
state MASTER
interface eth0.20
virtual_router_id 130
priority 100
advert_int 1
smtp_alert
track_script {
check_ha
}
virtual_ipaddress {
10.20.1.130
}
}Et pour Redis2
global_defs {
router_id redis2
enable_script_security
}
vrrp_script check_ha {
script "/bin/pidof haproxy"
interval 2
fall 1
rise 1
}
vrrp_instance REDISMASTER {
state BACKUP
interface eth1
virtual_router_id 130
priority 80
advert_int 1
track_script {
check_ha
}
virtual_ipaddress {
10.20.1.130
}
}Au niveau fonctionnement, rien de complexe, on a l’IP 10.201.130 qui est présente la où HAPROXY tourne et par défaut, c’est pour Redis1.
On lance sur les deux serveurs :
redisX# service keepalived start
Et on peut tester d’une machine extérieur au cluster :
redis-cli -h 10.20.1.130 -p 6379
Merveilleux !
IV – Tests
Deuxième campagne de tests.
A – Coupure de Redis
Si on coupe redis sur Redis1, redis sur Redis2 passe master et sur les Haproxy, on le voit.
Les requêtes sont bien envoyées vers redis sur Redis2.
La VIP quand a elle reste bien sur Redis1.
On pense à revenir en configuration initiale en repassant le master sur Redis1 (on relance Redis1en coupant Redis2 lorsqu’il est master et que Redis1 est backup, puis on relance Redis2).
B – Coupure de HAProxy
Sur Redis1 ou Haproxy est celui qui a la VIP, on peut tester une coupure de ce dernier.
redis1# service harpxoy stop
voir que l’IP passe sur REDIS2 ou son HAProxy prend en charge la répartition (et transfert bien vers redis sur Redis1)
On redémarre :
redis1# service harpxoy start
Et la VIP revient.
C – Coupure de Keepalived
On peut ensuite couper Keepalived sur Redis1
redis1# service keepalived stop
et constater que la aussi, cela bascule bien sur Redis2 pour la partie répartition qui renvoit bien vers redis sur Redis1
On peut alors le relancer
redis1# service keepalived stop
Et la VIP revient.
V – Conclusion
Et bien voila, vous avez votre cluster opérationnel.
Je ferais surement encore quelques articles autour de Redis, mais quand…. je ne sais pas 🙂
Salut,
J’ai de gros problèmes avec HaProxy.
Ma configuration :
– Debian 11
– vmware 6.5 pour les VM
– 2 VM
Ethernet :
– redis1 : 10.134.198.80 (eth0 – LAN visible), 172.134.198.80 (eth1)
– redis2 : 10.134.198.81 (eth0 – LAN visible), 172.134.198.82 (eth1)
Adresse frontend de HapProxy :
– Redis : 10.134.198.82 (eth0)
Mon problème 1 :
Lorsque j’arrête HaProxy sur Redis1 ça ne bascule pas sur Redis2, l’IP virtuelle reste sur Redis1.
On le voit avec un « ip a »
Mon problème 2 :
En faisant cela, si je test depuis une adresse extérieure cela provoque un plantage des interfaces réseau de Redis2. Je suspecte que Vmware n’aime pas refaire ses tables de routage de l’IP virtuelle dans sa gestion DVS (Dynamic Virtual Switch).
Logs dans dmesg :
[ 42.040502] vmware-modconfi[788]: segfault at 0 ip 00007f221d34f4e8 sp 00007ffda2643998 error 4 in libc-2.31.so[7f221d215000+14b000]
[ 42.040512] Code: 0c 8a 8b 04 82 29 c8 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f9 c5 f9 6e c6 c4 41 31 ef c9 c4 e2 7d 78 c0 83 e1 3f 83 f9 20 77 38 7e 6f 07 c4 c1 7d 74 c8 c4 c1 35 74 d0 c5 ed eb c9 c5 fd d7 c1
Cela peut-il venir du positionnement de net.ipv4.ip_nonlocal_bind à 1 dans la configuration sysctl ?
Est-ce que revenir à une configuration classique du lo:0 dans /etc/network/interface arrangerait les chose ?
J’ai essayé. Il n’y a plus de plantage de l’interface réseau sur le redis2 mais il n’y a pas non plus de bascule de l’IP virtuelle de redis1 sur Redis2 par HaProxy !
Du coup, l’interrogation de redis depuis l’extérieur plante…
Par contre la bascule KeepAlived effectue la bascule de l’IP virtuelle !
Malheureusement le routage de l’une sur l’autre est très longue à être prise en compte sur le réseau et il faut être patient avant de pouvoir interroger Redis depuis une VM externe…
Je n’y comprend rien !
Qu’en pense tu ?
Possibilité :
Si j’ai créé un réseau intercluster monté sur eth1 c’était pour caler avec ta doc. En fait je n’en vois pas le besoin à moins que ça coince avec HaProxy. Ne pourrais-je pas rester sur le même LAN 10.134.198/24 avec :
Ethernet :
– redis1 : 10.134.198.80 (eth0)
– redis2 : 10.134.198.81 (eth0
Adresse frontend de HapProxy :
– Redis : 10.134.198.82 (eth1)
Pour bien séparer les flux ?
Hello et désolé de la réponse tardive.
J’avoue que la, je ne sais pas trop, il faut que je creuse tout ça.
Je suis en train de revoir mes tutos pour Debian 11, je regarde donc bientôt Redis.
Pour Keepalived et la bascule lente, regarde un de mes derniers articles sur les routeurs de bordures, je donne un truc.
Salut,
Après m’être battu avec HAProxy qui ne basculait pas la VIP sur un de mes cluster Vmware j’ai décidé de revenir sur ce que tu proposais comme hypothèse au début de cet excellent tuto ; c’est à dire de faire gérer les bascules VIP par KeepAlived uniquement 🙂
Il faut alors intégrer un petit script de test de l’état REDIS (« ping » et « info réplication ») lancé par KeepAlived et le tour est joué. Finalement c’est beaucoup plus simple…
Voilà le script lancé par KeepAlived :
———————————————————————————————
#!/bin/bash
# Test de l’état de REDIS
if [ « X$(redis-cli -h $1 -p 6379 ping) » = « XPONG » ] ; then
echo « Ping $1 Ok »
if eval redis-cli -h $1 -p 6379 info replication | grep -q ‘^role:master’ ; then
echo « Rôle MASTER $1 Ok »
else
echo « Rôle MASTER $1 Nok »; exit 1
fi
else
echo « Ping $1 Nok »; exit 1
fi
exit 0
———————————————————————————————
J’ai également configuré KeepAlived en load balancing comme tu l’avais proposé dans ton tuto sur OpenLDAP. Du coup j’ai même fais un test avec 2 « backup » REDIS et ça fonctionne plutôt bien.
Par contre il y a toujours une bascule lente de la VIP et je ne me sens pas d’introduire un système de routeur de bordure pour y remédier…
Sinon, bravo pour ces tutos.
PS :
Nous allons bientôt basculer la gestion de la virtualisation de Vmware vers ProxMox. Je vais enfin revenir vers du libre 😉
Je te ferais un tuto de cette expérience.