Répartiteur de charge et Haute disponibilité / LB (Load Balancing) and HA (High Availability) System

Le Load Balancing (répartiteur de charge en Français) est généralement utilisé lorsque la montée en charge peut-être élevée (par exemple un serveur Web), couplé à de la High Availability (haute disponibilité en Français), on obtient une redondance très intéressante.

Pour une meilleure compréhension, nous avons testé haproxy, un proxy répartiteur de charge, programmer «devant»  des serveurs web, il est très efficace.

Nous allons commencer par l’installation du système sur tous les serveurs: nous avons choisi  Ubuntu Server 6.06 et pour les 2 serveurs web (que nous appelerons plus tard 186 et 187) debian 4.0 car Ubuntu ne boot pas (et nous avons un temps assez limité). Maintenant, il ne reste plus qu’à  paramètrer les serveurs, nous les appelons:

182: (NFS Serveur)
186: (Apache/PHP5 et NFS Client)
187: (Apache/PHP5 et NFS Client)
180: (Load-Balancing)

A noter que la majeure différence entre les distributions Debian et Ubuntu est que, concernant Ubuntu le compte root n’est pas loggable, c’est en réalité un pseudo compte primaire, il faut donc utiliser la commande sudo pour chaque commandes néccésitant les droits d’accès super utilisateur.

Récapitulatif

Un petit schéma pour illustrer notre structure

En détails la configuration des machines utilisées:
182 (Serveur NFS):
Ubuntu 6.06-2 Server
Compaq
Intel Celeron 1300Mhz
256Mo SD-RAM
Disque Dur 10Go
186 (Serveur web):
Debian 4.0
IBM
Pentium II 200Mhz
64Mo SD-RAM (32*2)
Western Digital Caviar 22500 (2559,8Mb)
187 (Serveur web):
Debian 4.0
IBM
Pentium II 200Mhz
64Mo SD-RAM (32*2)
Seagate  ST31720A (1600Mb)
180 (Proxy répartiteur de charge):
Ubuntu 6.06-2 Server
Compaq
Intel Celeron 1000Mhz
SD-RAM
Disque Dur 20Go

Paramètrage

Sur tous les serveurs,

Je commente la ligne correspondant aux dépôts concernant le CD (/etc/apt/sources.list) puis actualise la liste (apt-get update)

On installe le paquet ssh (pour prendre le contrôle a distance)

Je synchronise la date et l’heure via un serveur ntp que j’installe  (mes serveurs sont vieux, et les piles sont sûrement fatiguées)

J’utilise comme collectes de statistiques « Cacti»  (protocole SNMP), je vais donc installer un deamon SNMP (apt-get install snmpd) et parametrer le SNMP à ma façon:
Par default sur Debian 4.0 le daemon SNMPd écoute uniquement en local (127.0.0.1).
Je rectifie ça:
nano /etc/default/snmpd
SNMPDOPTS=’-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1′
par
SNMPDOPTS=’-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid’

Je sauvegarde l’ancien fichier de configuration général du deamon snmp pour repartir à zéro
mv /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf_bk

J’ouvre maintenant le fichier pour le paramétrer en fonction de mes besoins:
nano /etc/snmp/snmpd.conf

syscontact alex@alouit-multimedia.com
syslocation Fontainebleau, France

com2sec LocalNet 192.168.100.249 public

group ROGroup v1 LocalNet

view tout included .1

access ROGroup « »  v1 noauth exact tout none none

disk /

Pour comprendre la configuration de snmpd, il existe beaucoup de doc et de tutoriels à ce sujet, google est votre ami!!

J’envoie le fichier sur tous les serveurs via scp (qui est très utile, pour le manuel d’utilisation man scp)

Je redémarre le deamon sur tous les serveurs

/etc/init.d/snmpd restart

Ensuite, j’ajoute chaque serveur à cacti

A partir de maintenant, chacune des étapes sont spécifiques à chaque serveur

Occupons-nous de 182, qui stockera les fichiers web
Nous allons maintenant installer le deamon NFS serveur (apt-get install nfs-kernel-server)
cd /
mkdir www
nano /etc/exports
/www/ 192.168.100.0/24

Ensuite, on passe aux 2 serveurs web (186 et 187), il faut donc réitérer tout en double

Installons le client NFS et paramétrons pour monter le dossier /www/ de 182
apt-get install nfs-common

Créons le point de montage
mkdir /media/www/
Pour le monter dès le démarrage de la machine
nano /etc/fstab
192.168.100.182:/www/     /media/www/     nfs     ro      0       0

Montons-les
mount /media/www/

Installons Apache2 et Php5
apt-get install apache2 apache2-doc php5 libapache2-mod-php5

Puis paramétrons le:

nano /etc/apache2/sites-enabled/000-default

Remplaçons à la ligne 5
DocumentRoot /var/www/
Par
DocumentRoot /media/www/

Aussi à la ligne 10, remplaçons
<Directory /var/www/> par <Directory /media/www/>

Supprimons la ligne 17:
RedirectMatch ^/$ /apache2-default/

Redémarrons le deamon
/etc/init.d/apache2 restart

Nous laisserons le reste de la configuration par défault (Je rappelle que le but de ce test n’est pas d’optimiser Apache, mais d’en répartir la charge sur plusieurs serveurs réels)

Pour finir il faut s’occuper de 180, qui répartira la charge avec HAProxy, la première étape dans les requêtes clients de notre Load Balancing System, redistribuer les clients en fonction de la charge.

On l’installe
(d’après ce que j’ai vu, à partir de debian 4.0 haproxy est dans un des dépots, il suffira donc d’un apt-get install haproxy)
dans mon cas, on l’installe manuellement,

apt-get update
apt-get install build-essential make libpcre3 libpcre3-dev
cd /opt/
wget http://haproxy.1wt.eu/download/1.3/src/haproxy-1.3.17.tar.gz
tar zxvf haproxy-1.3.17.tar.gz
cd /opt/haproxy-1.3.17
make TARGET=linux26 CPU=i686 USE_PCRE=1
make install
ln -s /usr/local/sbin/haproxy /usr/sbin/haproxy
cd /etc/init.d/
sudo nano haproxy

#!/bin/sh
# This is our service name
BASENAME=haproxy
[ -f /etc/$BASENAME/$BASENAME.cfg ] || exit 1
RETVAL=0
start() {
/usr/sbin/$BASENAME -c -q -f /etc/$BASENAME/$BASENAME.cfg
if [ $? -ne 0 ]; then
echo « Errors found in configuration file, check it with ‘$BASENAME check’.» 
return 1
fi
echo -n « Starting $BASENAME: » 
/usr/sbin/$BASENAME -D -f /etc/$BASENAME/$BASENAME.cfg
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/$BASENAME
return $RETVAL
}
stop() {
echo -n « Shutting down $BASENAME: » 
kill $(</var/run/haproxy.pid)
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && rm -f /var/lock/$BASENAME
[ $RETVAL -eq 0 ] && rm -f /var/run/$BASENAME.pid
return $RETVAL
}
restart() {
/usr/sbin/$BASENAME -c -q -f /etc/$BASENAME/$BASENAME.cfg
if [ $? -ne 0 ]; then
echo « Errors found in configuration file, check it with ‘$BASENAME check’.» 
return 1
fi
/usr/sbin/$BASENAME -D -f /etc/$BASENAME/$BASENAME.cfg -st $(</var/run/haproxy.pid)
}
check() {
/usr/sbin/$BASENAME -c -q -V -f /etc/$BASENAME/$BASENAME.cfg
}
condrestart() {
[ -e /var/lock/$BASENAME ] && restart || :
}
# See how we were called.
case « $1″ in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
reload)
restart
;;
condrestart)
condrestart
;;
check)
check
;;
*)
echo $» Usage: $BASENAME {start|stop|restart|reload|condrestart|check}» 
RETVAL=1
esac

sudo mkdir /etc/haproxy/
cd /etc/haproxy/

maintenant qu’il est installer, paramètrons-le

sudo nano haproxy.cfg

Résultats

A gauche les résultats avec le répartiteur de charge, et à droite sans (on a donc 1 seul serveur web, sans passer par le proxy)

Grâce a l’outil ab, j’effectue plusieurs tests de charge.

Il seront disponibles très prochainement..

Conclusion

Ce sytème est donc très efficace, en y rajoutant un serveur MySQL, plusieurs serveurs web, et une réplique parfaite de chaque serveur (mise à part les serveurs web), il y a de quoi ramener du traffic (si les conditions le permettent, par exemple le débit internet, le débit intranet (ici nous étions en 100Mb Full-Duplex) et si les serveurs le permettent.
Ce système de répartiteur de charge est assez simple à paramètrer et à utiliser, on peut donc soumettre pas mal de requêtes, beaucoup l’utilisent de cette manière:

L’idéal est d’avoir une réplique du répartiteur, de la base de données MySQL et du serveur NFS+FTP avec un système comme heartbeat.