19 mars 2024

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

Tuto révisé en décembre 2022

 

Troisième partie de la série sur Redis. Nous allons rendre notre instance Redis accessible à nos clients. Les deux redis communiquant sur 10.50.0.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, 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.100.6.100 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.100.6.100

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.100.6.100: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.50.0.101:6379 check inter 1s
  server redis2 10.50.0.102:6379 check inter 1s

On prend juste bien soin de demander les serveurs redis sur le réseau 10.50.0.0/24.
HAProxy fournissant le front-end sur 10.100.6.100 (VIP qu’on mettra en place avec Keepalived).

On modifie également l’adresse d’expédition pour la messagerie.

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.100.6.101:8282/haredis1;
  proxy_http_version 1.1;
}

location /haredis2 {
  proxy_pass http://10.100.6.102: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.100.6.100.

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/pgrep haproxy"
  interval 2
  fall 1
  rise 1
}
vrrp_instance REDISMASTER {
  state MASTER
  interface eth1
  virtual_router_id 100
  priority 100
  advert_int 1
  smtp_alert
  track_script {
    check_ha
  }
  virtual_ipaddress {
    10.100.6.100
  }
}

Et pour Redis2

global_defs {
  router_id redis2
  enable_script_security
}
vrrp_script check_ha {
  script "/bin/pgrep haproxy"
  interval 2
  fall 1
  rise 1
}
vrrp_instance REDISMASTER {
  state BACKUP
  interface eth1
  virtual_router_id 100
  priority 80
  advert_int 1
  track_script {
    check_ha
  }
  virtual_ipaddress {
    10.100.6.100
  }
}

Au niveau fonctionnement, rien de complexe, on a l’IP 10.100.6.100 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 :

On installe le client redis :

# apt install redis-tools

Puis :

redis-cli -h 10.100.6.100 -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.

 

3 réflexions sur « Tuto Redis en Haute Dispo, partie III : Loadbalancing et VIP »

  1. 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 ?

    1. 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.

  2. 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.

Laisser un commentaire

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