5 août 2021

Tuto Redis en Haute Dispo, partie III : Loadbalancing et VIP

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)

 

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 🙂

 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *