Forum Linux.général Comment est sélectionné le noeud d'un cluster HAPROXY ?

Posté par  . Licence CC By‑SA.
Étiquettes :
0
9
août
2016

Bonjour,

Je m'interesse à HAPROXY et malgré la lecture de plusieurs article à ce sujet y a toujours une question (au moins) à laquelle je ne trouve pas de réponse.

Lorsque par exemple on a un cluster HAPROXY composé de 4 serveurs si j'ai bien tout compris chaque noeud du cluster porte l'adresse IP virtuelle du cluster en plus de sa propre IP.
Mais comment s'effectue la selection du noeud haproxy qui va recevoir la requette client et la transférer ?
Puisque chaque noeud porte l'IP du cluster j'imagine que c'est pas chaque noeud sui recoit la requette client ?

En d'autres termes comment s'effectue le load balancing du cluster haproxy lui même ?

Merci de vos éclairages.

  • # 2 etages, 2 systeme.

    Posté par  . Évalué à 4.

    c'est haproxy qui sait à quelle machine envoyer, par son IP reelle,
    l'IP virtuelle du cluster ne servant qu'à permettre au serveur finale d'accepter le paquet IP, et de repondre directement au client.

    sur ton haproxy, tu configures un frontend pour ecouter sur l'IP de cette machine.
    puis tu selectionnes un backend dans une liste definie.

    dans ce backend, tu peux definir plusieurs serveurs, c'est ta ferme du cluster.
    chaque element du cluster doit evidemment avoir sa propre IP,
    et c'est dans la definition du backend que tu choisis la methode qu'haproxy va utiliser pour choisir à quel element du cluster envoyer le flux qu'il recoit.

    tu as (entre autres) les modes :
    - "roundrobin" qui equilibre de maniere egale entre les serveurs
    - "leastconn" qui regarde regarde sur quel serveur il y a le moyen d'activité et envoie le flux sur celui là.

    pour le cas que tu decris : "chaque noeud du cluster porte l'ip du cluster", c'est dans le cas du routage assymetrique.
    avec la requete circulant comme ca :
    Client -> Haproxy -> Serveur
    et la reponse :
    Serveur -> Client

    le plus simple pour demarrer etant de mettre ton haproxy en "coupure" entre ton serveur et tes clients,
    la route par defaut des serveurs devenant le serveur haproxy, il n'y a alors plus besoin de mettre l'IP du cluster sur chaque noeud

    • [^] # Re: 2 etages, 2 systeme.

      Posté par  . Évalué à 1.

      Merci NeoX,
      C'était pas tout à fait ma question. Mais c'est pas grave car dans l'explication que tu donnes j'ai appris qu'il y avait plusieurs mode de load balancing.
      Jusqu'ici je ne m'était interessé que à round-robin.
      D'ailleurs cela m’ammene une autre question.
      En round robin si par exemple mon HAPROXY adresse une ferme de 4 noeud apache et que l'un d'eux tombe, est que HAPROXY continue à lui envoyer des paquets occasionnant 25 % de perte ou est-ce que il détecte qu'un noeud et mort et décide tout seul de l'éliminer?

      • [^] # Re: 2 etages, 2 systeme.

        Posté par  . Évalué à 3.

        En round robin si par exemple mon HAPROXY adresse une ferme de 4 noeud apache et que l'un d'eux tombe, est que HAPROXY continue à lui envoyer des paquets occasionnant 25 % de perte ou est-ce que il détecte qu'un noeud et mort et décide tout seul de l'éliminer?

        quelque soit le mode de loadbalancing, il est recommandé d'activer les checks dans la definition du backend.
        exemple de backend definit chez moi - il faut virer les ** qui ne sont que pour te montrer ce qui gere les checks :

        backend WEB
  id 2011
  balance roundrobin                                         #alctl: load balancing algorithm
  **mode http**                                              #alctl: protocol analyser
  log global                                                 #alctl: log activation
  option httplog                                             #alctl: log format
  option forwardfor                                          #alctl: insert X-Forwarded-For header
  cookie WEB insert indirect nocache                         #alctl: cookie persistence
  default-server inter 3s rise 2 fall 3                      #alctl: default check parameters
  **option httpchk HEAD /**                                  #alctl: advanced http check
  timeout server 25s                                         #alctl: server inactivity timeout
  server VM301 10.0.30.1:80 maxconn 1000 weight 10 cookie VM301 **check** #alctl: server VM301 configuration.
  server VM302 10.0.30.2:80 maxconn 1000 weight 10 cookie VM302 **check** #alctl: server VM301 configuration.

        ainsi il va verifier que les VM301 et VM302 sont dispos, normalement toutes les secondes.
        si l'une d'elle tombe, il adapte ses flux pour renvoyer le reste vers l'autre.

        sans ces checks en effet, je penses qu'il continuerait d'envoyer vers une machine qui n'existe plus.

  • # Keepalived

    Posté par  (site web personnel) . Évalué à 2.

    Je n'ai jamais mis en place ça moi même, mais en général, HAProxy est utilisé avec Keepalived et comme tu le dis une adresse IP virtuelle.

    C'est donc Keepalived qui bascule le serveur vivant sur la VIP (grâce au protocol VRRP je crois.)

    Ça te donne quelques mots clés supplémentaires pour chercher de la doc.

    • [^] # Re: Keepalived

      Posté par  . Évalué à 1.

      Merci Benoit,

      C'est parfait. Oui j'ai vu un peu de doc sur vrrp. il semble que se soit un peu le même principe que hsrp en plus efficace et plus rapide.

      • [^] # Re: Keepalived

        Posté par  . Évalué à 2.

        Par contre de ce que je comprends il n'existe pas de possibilité que plusieurs neoud d'un cluster HAPROXY ou LVS fonctionnent en actif-actif?

        • [^] # Re: Keepalived

          Posté par  . Évalué à 3.

          un cluster HAPROXY ou LVS fonctionnent en actif-actif

          c'est quoi le but ?
          de mettre un autre loadbalancer devant ton cluster haproxy ?

          keepalived permet quand meme cela, en jouant des priorités
          tu peux tres bien definir un noeud Master sur l'IP 1.2.3.4 (qui sera backup pour l'IP 5.6.7.8)
          et definir l'autre noeud Master sur 5.6.7.8 (qui sera backup pour 1.2.3.4)

          et donc ils seront actif/actif avec echange des roles si l'un deux tombe.

          mais je ne sais pas si haproxy va bien vouloir se lancer s'il n'a pas l'IP sur laquelle il est censé ecouter.

          • [^] # Re: Keepalived

            Posté par  . Évalué à 4.

            mais je ne sais pas si haproxy va bien vouloir se lancer s'il n'a pas l'IP sur laquelle il est censé ecouter.

            sysctl net.ipv4.ip_nonlocal_bind  1

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Keepalived

              Posté par  . Évalué à 2.

              merci faut que je me la note dans un coin celle là

  • # Article sur le sujet

    Posté par  (site web personnel) . Évalué à 1.

    Je viens de croiser cet article, je le met ici pour mémoire.

    Loadbalancer hautement disponible avec HAProxy et Keepalived

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.