Table des matières

Load balancing TCP avec HAproxy

HAproxy est un load balancer TCP. Il peut donc répartir la charge entre différents serveurs écoutant en TCP en backend.

HAproxy peut par exemple être utilisé pour load-balancer des reverse proxys, des site webs, des bases de données, etc… Bref c'est un outil puissant et très utilisé.

Voici l'architecture que nous allons réaliser :

Voici l'ip publique de HAproxy sur laquelle on va écouter avec HAproxy : 157.159.40.136

Et son ip privée : 192.168.103.136

Voici les ips de nos deux serveurs webs : 192.168.103.166 192.168.103.167

Mise en place

Là, c'est d'une simplicité enfantine :

On commence par installer HAproxy : 

  cat "deb http://ftp.debian.org/debian/ wheezy-backports main" >> /etc/apt/source.list.d
  apt-get update
  apt-get install haproxy

Ensuite on modifie le fichier /etc/default/haproxy :

Remplacez 

  ENABLED=0

par 

  ENABLED=1

Maintenant attaquons la configuration.

Le fichier de conf est même simple à comprendre :

  1. On a d'abord les option générales
  2. Puis on a les ports sur lesquels on écoute qu'on map avec un backend
  3. Et enfin les backends, qui sont les groupes de serveurs loadbalancé.

Si je ne respect pas cet ordre et mélange frontend et backend, j'obtiens une erreur…

Par exemple dans mon cas ça donne : 

global
    daemon

defaults
        maxconn 10000
        timeout connect 2s
        timeout client 10s
        timeout server 2s

frontend site_http
        mode http
        bind 157.159.40.136:80
        default_backend site_http_b

frontend site_https
        mode tcp
        bind 157.159.40.136:443
        default_backend ssh_https_b

backend site_http_b
        mode http
        balance roundrobin
        server site1 192.168.103.166:80 check inter 10s
        server site2 192.168.103.167:80 check inter 10s

backend ssh_https_b
        mode tcp
        balance roundrobin
        server ssh1 192.168.103.166:443 check inter 10s
        server ssh2 192.168.103.167:443 check inter 10s

Passons pas trop de temps sur les options globales, c'est pas très intéressant.

De même pour frontend, on ne fait que spécifier un mode (non obligatoire mais plus propre), donner une adresse sur laquelle écouter, et donner un backend.

Dans le backend, on doit remettre le même mode que dans le frontend correspondant. Ensuite on précise le mode de load balancing. Roundrobin est le plus utilisé à la vue des confs disponibles sur internet. Enfin, on précise l'ensemble des serveurs distants ainsi qu'un intervalle de vérification ( ici 2 secondes ). Dès qu'un nœud est “abîmé”, il est retiré. Dès qu'il est à nouveau “en bonne santé”, il est réutilisé.

J'ai réalisé cette archi en DEV et là pour moi ça marche…

Binding client serveur en http

Si vous accordez une importance au couple client serveur, vous pouvez commencer par remplacer : 

  balance roundrobin

par 

  balance source

Si en plus vous bossez en http, vous pouvez mettre en place des cookies pour améliorez le binding… 

listen http_proxy :80
        mode http
        cookie SERVERID
        balance source
        server web1 192.168.103.166 cookie server01
        server web2 192.168.103.167 cookie server02

Attention néanmoins, les cookies sont un mécanisme de couche 7, il est donc coûteux de s'en servir sur un load-balancer…

Personnellement, j'aurais tendance à considérer les mécanismes de couche 4 tel que balance source suffisant.

Monitoring avec hatop

hatop est un petit utilitaire permettant d'obtenir en temps réel l'état et le nombre de connection en frontend ainsi qu'en backend.

Pour pouvoir l'utiliser, éditez /etc/haproxy/haproxy.cfg, et ajoutez en option globale : 

  stats socket /var/run/haproxy.sock

Installez hatop : 

  apt-get install hatop

Et enfin utilisez hatop : 

  hatop -s /var/run/haproxy.sock

Liens utiles