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 🙂