Dans l'article précédent nous avons vu la méthode Round Robin, nous allons en voir quelques autres.

Load Balancing de type least connection (moins de connexions) :

Définition

Le but de cet algorithme est de maintenir un load balancing équilibré les connexions vers les serveurs au grès des nouvelles/fin/maintient de connexions (envoi de requête vers le serveur le moins chargé).

Configuration

Prenons le fichier /etc/haproxy/haproxy.cfg de l'article précédent en modifiant la partie qui nous intéresse, à savoir listen :
vi /etc/haproxy/haproxy.cfg

listen VIP_Web_lc 192.168.5.17:80
       mode http
       stats enable
       stats       uri /stats // Endroit où les stats seront consultables
       stats auth  pseudo:password // votre username : password
       balance leastconn
       option httpclose
       option forwardfor
       server apache1 10.0.0.1:80 check
       server apache2 10.0.0.2:80 check
       server apache3 10.0.0.3:80 check

Note :
Dans ce lab le trafic ne permet pas de mettre en évidence cette algorithme.
Cette algorithme est particulièrement bien adapté aux connexions dites "longues" comme LDAP, TSE, SQL, ... mais pas vraiment adapté à des connexions comme HTTP qui varient rapidement.

Load Balancing de type source :

Définition

Cet algorithme associe un hash de l'IP source à un serveur de backend, cela assurera que ce même client ira toujours sur le même serveur backend.

Schéma

Configuration

listen VIP_Web_src 192.168.5.17:80
       mode http
       stats enable
       stats       uri /stats // Endroit où les stats seront consultables
       stats auth  pseudo:password // votre username : password
       balance source
       option httpclose
       option forwardfor
       server apache1 10.0.0.1:80 check
       server apache2 10.0.0.2:80 check
       server apache3 10.0.0.3:80 check

Résultat de la page web

Statistiques de load balancing

Note :
C'est un peu une persistance de session du pauvre ... nous verrons d'autres méthodes par la suite. Avantage de cette persistance, elle fonctionne peu importe le comportement du client (contrairement aux cookies).
Cet algorithme possède une faiblesse, si l'adresse IP cliente masque un proxy d'entreprise, le serveur de backend qui recevra les connexions sera plus chargé que les autres.

Note 2 :
Lors de la perte d'un serveur, HA Proxy redistribue bien la connexion sur un autre serveur actif, au retour du serveur, HA Proxy le renvoie sur le serveur initiale cela peut peut être avoir un impact sur l'applicatif du serveur web.

Load Balancing de type URI :

Définition

Cet algorithme associe un hash de l'URI (tout ce qui est avant le point d'interrogation) à un serveur de backend, cela assurera que la même URI ira toujours sur le même serveur backend.
Ce qui est très intéressant lors de load balancing de serveurs de cache car cela aura pour effet d'optimiser le cache.

Schéma

Configuration

listen VIP_Web_uri 192.168.5.17:80
       mode http
       stats enable
        stats       uri /stats // Endroit où les stats seront consultables
        stats auth  pseudo:password // votre username : password
       balance uri
       option httpclose
      option forwardfor
       server apache1 10.0.0.1:80 check
       server apache2 10.0.0.2:80 check
       server apache3 10.0.0.3:80 check

Résultat de la page web

Pour chaque objet dans la page, il y a un backend potentiellement différent.

Statistiques de load balancing

note :
A chaque perte/retour de serveur backend le load balancing est redéfini.

Autres algorithmes de load balancing :

static-rr

Celui-ci est sensiblement équivalent au round-robin, avec la variante qu'il n'y a pas possibilité de lui affecter/modifier une pondération (nous le verrons dans un prochain article).

url_param

Cet algorithme permet de faire du load balancing sur un paramètre de l'URL.
Ligne de configuration (exemple sur le paramètre userid) :

balance url_param userid

note :
Comme pour l'algorithme URI, celui-ci ne s'applique que sur des backends HTTP.

hdr

Cet algorithme permet de faire du load balancing sur un header HTTP.
Ligne de configuration (exemple sur le header "Accept-Encoding") :

balance hdr(Accept-Encoding)

notes :
Comme pour l'algorithme URI et URL param, celui-ci ne s'applique que sur des backends HTTP.
Si le header n'est pas présent, c'est l'algorithme round robin qui est appliqué.

rdp-cookie

Cet algorithme permet de faire du load balancing pour des backends TSE via un cookie RDP.
Il faut préciser le nom du cookie, à défaut c'est "mstshash" qui sera utilisé.

configuration

listen VIP_TSE 192.168.5.11:3389
        mode tcp
        tcp-request inspect-delay 5s
        tcp-request content accept if RDP_COOKIE
        persist rdp-cookie
        balance rdp-cookie
        option tcpka
        option tcplog
        server TSE1 192.168.0.1:3389 weight 1 check
        server TSE2 192.168.0.2:3389 weight 1 check
        server TSE3 192.168.0.3:3389 weight 1 check
        option redispatch

note :
Cet algorithme ne s'applique que sur des backends TSE.