LOAD-BALANCING AVEC LINUX VIRTUAL

SERVER

Projet CSII1 2008 encadré par M. Ozano

Réalisé par :

- Yann Garit

- Yann Gilliot

- Steve Lacroix

- Dorian Lamandé

- Maxime Panczak

- Aymeric Vroomhout

CSII1 – Année 2008 – Projet Load-Balancing

SOMMAIRE

Introduction ............................................................................................................................................. 1
1° Le cluster ......................................................................................................................................... 1
2° Le load-balancing ou répartiteur de charge.................................................................................... 1
3° De quoi a-t-on besoin ? (niveau matériel) ...................................................................................... 2
I) A quoi servent ces technologies ...................................................................................................... 4
1° Le load-balancing ............................................................................................................................ 4
A) Les avantages .............................................................................................................................. 4
B) Les différents algorithmes de routage ........................................................................................ 4
C) Comment se passe la connexion d’un client ............................................................................... 6
2° Fonctionnement de LVS et algorithmes de LVS .............................................................................. 6
A) Fonctionnement de LVS .............................................................................................................. 6
B) Le NAT ......................................................................................................................................... 7
C) L’IP tuneling ................................................................................................................................. 7
D) Le routage direct ......................................................................................................................... 8
3° Le clustering .................................................................................................................................... 8
A) Les avantages .............................................................................................................................. 8
B) Utilisation .................................................................................................................................... 9
C) Heartbeart et Ldirector ............................................................................................................... 9
D) Comment mettre en place ces paquets...................................................................................... 9
E) Tests sur heartbeat.................................................................................................................... 10
II) Comment mettre en place un répartiteur de charge ................................................................... 12
1° Mettre en IP fixe les serveurs ....................................................................................................... 12
2°Installer les paquets nécessaires.................................................................................................... 14
3°Autoriser le routage ....................................................................................................................... 14
4°Ajouter des machines dans le cluster ............................................................................................ 15
III) Les tests à effectuer ................................................................................................................... 16
Conclusion ............................................................................................................................................. 17

CSII1 – Année 2008 – Projet Load-Balancing

 INTRODUCTION

Une des principales difficultés rencontrées par les administrateurs réseaux est la capacité à
monter en charge, c'est-à-dire la faculté de répondre aux requêtes avec un temps de réponse
acceptable, même en cas d'affluence massive. Le load-balancing va permettre de résoudre ce
souci en équilibrant les charges en fonction du nombre de serveurs, de leurs capacités, et de
l’algorithme choisi. Nous allons vous expliquer tout ceci en commençant par quelques
définitions indispensables pour avoir le même vocabulaire.

1° LE CLUSTER

Un cluster serveur est un groupe de systèmes informatiques indépendants, appelés nœuds

(node en anglais), qui exécutent un système d’exploitation et fonctionnent ensemble comme
s'il s'agissait d'un seul système pour garantir que des applications et des ressources
stratégiques restent disponibles pour les clients.

Chaque nœud est connecté à un ou plusieurs périphériques de stockage de cluster. Les clusters
serveur permettent aux utilisateurs et aux administrateurs d'accéder aux nœuds et de les gérer,
non comme des ordinateurs distincts, mais comme un seul système.

2° LE LOAD-BALANCING OU REPARTITEUR DE CHARGE

La répartition de charge (load-balancing en anglais, littéralement équilibrage de charge)

est une technique utilisée en informatique pour distribuer un travail entre plusieurs processus,
ordinateurs, disques ou autres ressources.

Le principe de base consiste à interposer entre les consommateurs de la ressource et le

pool de ressources un dispositif (le répartiteur ou load-balancer en anglais) qui connaît l'état
d'occupation de chaque ressource et qui est capable de diriger le consommateur vers la
ressource la moins occupée, ou la plus facilement accessible. Les ressources peuvent ne pas
avoir la même capacité à satisfaire les besoins du consommateur (en vitesse de traitement, en
bande passante, etc.), ce qui influe sur le mode de calcul du répartiteur.

Il existe différents types d’algorithmes de répartition de charge. Ils seront expliqués dans
la suite de ce rapport.

CSII1 – Année 2008 – Projet Load-Balancing page 1

3° DE QUOI A-T-ON BESOIN ? (NIVEAU MATÉRIEL)

Pour faire du load-balancing, il faut au minimum un serveur qui sert de load-balancer et

qui dispache les ressources, ainsi que d’au moins deux serveurs réels qui traiteront les
informations reçues. Cependant dans notre configuration, nous avons ajouté un second load-
balancer, pour ainsi pour étendre le sujet, et créer un répartiteur de charge de secours. (Celui-
ci est facultatif, tout fonctionne parfaitement avec uniquement un load balancer) Voici donc
notre architecture qui a été mise en place.

Eth0 est la carte externe (pour internet) et eth1 est la carte LAN (qui reste dans le cluster)
Loadb1
eth0 192.168.4.100 eth1 192.168.5.1

Real1
eth0 192.168.5.10

Real2
eth0 192.168.5.11

Pour avoir plus de détail sur les configurations, allez voir la partie II.

CSII1 – Année 2008 – Projet Load-Balancing page 2

 Les postes de travail sont des clients qui se connectent au cluster. Ils ne connaissent que l’IP
192.168.4.100 et ne se rendent pas compte qu’il y a en fait plusieurs serveurs capables de gérer leur demande.

Voilà le schéma le plus simple que nous ayons réalisé. Cependant nous pouvons ajouter un second
répartiteur de charge et ajouter un module heartbeat entre les deux load-balancer ce qui permet d’ajouter de la
sécurité à notre architecture. Ainsi si l’un des répartiteurs de charge tombe en panne, le second sera
automatiquement utilisé afin d’allouer les ressources aux serveurs réels. Des explications sur heartbeat seront
apportées dans le chapitre suivant.

CSII1 – Année 2008 – Projet Load-Balancing page 3

I) A QUOI SERVENT CES TECHNOLOGIES

1° LE LOAD-BALANCING

A) LES AVANTAGES

La répartition de charge est une forme d'optimisation. Les avantages sont nombreux :

- Augmentation de la qualité des services.

- Amélioration des temps de réponse des services.
- Capacité à palier la défaillance d'une ou de plusieurs machines.
- Possibilité d'ajouter des serveurs sans interruption de service.

B) LES DIFFERENTS ALGORITHMES DE ROUTAGE

Différents algorithmes de répartition de la charge sont implémentés dans LVS. Ils

définissent l'ordre dans lequel le load-balancer affectera les requêtes des clients aux différents
serveurs réels proposant un service. Chaque service hébergé dans une ferme de serveurs LVS
peut posséder son propre algorithme de répartition de charge. Voici ces algorithmes existants :

- Le Round-Robin (RR) considère avec égalité tous les serveurs réels sans se soucier du
nombre de connections entrantes ou du temps de réponse de chacun. Il est qualifié
d'algorithme de répartition sans condition d'état. Par exemple, dans une configuration
avec 2 serveurs réels, la première requête sera affectée au 1er serveur, la seconde au
second serveur, la 3ème requête au 1er serveur, et ainsi de suite en boucle.

Note : Un exemple de répartition de charge de type Round-robin est effectué au niveau des
serveurs DNS : ainsi, pour un nom de domaine précis, le serveur DNS possède plusieurs
adresses IP. À chaque requête, le serveur DNS choisit l'adresse IP à inclure dans la réponse de
manière à ce que chaque adresse IP soit présente dans les réponses de manière équitable. Les
différents accès au nom de domaine sont par conséquent répartis équitablement entre les
différentes adresses IP. Des tranches de temps sont donc accordées à chaque processus en
proportion égale, sans leur accorder de priorité. Chaque processus reçoit du temps processeur
appelé "quantum". Quand l'algorithme change de processus, cela prend du temps (de l'ordre
de 1 ms). Il faut donc trouver le juste milieu entre :

CSII1 – Année 2008 – Projet Load-Balancing page 4

 o Un quantum court : changements de processus réguliers donc perte d'efficacité
o Un quantum long : le temps de réponse sera allongé

Les algorithmes suivant sont :

- Le Weighted Round-Robin (WRR) ajoute à la boucle du RR la notion de poids. Ainsi,

il est plus performant que ce dernier dans le cas ou les capacités de traitement sont
différentes. Cependant, il peut mener à une mauvaise gestion de la charge lorsque les
puissances varient beaucoup. Il est en effet fréquent que les grosses requêtes soient
dirigées vers le même serveur, déséquilibrant ainsi la balance.

- Le Least-Connection (LC) dirige les requêtes vers le serveur ayant le moins de

connexions établies. Il est dit dynamique, comptant le nombre de connexion de chaque
serveur pour estimer sa charge. Il garde un état du nombre de connexion, incrémentant
le compteur lors de l'assignation ou le décrémentant lors d'une déconnexion ou d'un
timeout. Le Least-Connection est idéal lorsque les serveurs ont une puissance de
traitement similaire.

Note: TCP produit un phénomène de cache. L'état TIME_WAIT, d'une durée d'environ 2
minutes par défaut, est un état durant lesquels les requêtes reçues sont “conservées” afin
d'empêcher que les paquets non fiables ou avec des erreurs ne soient à nouveau traités. Cela
surcharge ainsi virtuellement le serveur. Pendant une période d'attente de 2 minutes, un site
surchargé peut recevoir des centaines de connexions. Ainsi, un serveur A (imaginons le, deux
fois plus puissant qu'un serveur B) peut garder des requêtes déjà exécutées dans un état de
TIME_WAIT alors que le serveur B aura du mal à se défaire de sa centaine de connexion en
cours.

- Le Weighted Least Connexion (WLC) gère bien mieux la répartition entre serveurs de
puissances différentes. Les serveurs du cluster sont classés par rapport à leur poids, et
un pourcentage leur est attribué. Le système de répartition du LC s'y ajoute ensuite.

- Locality-Based Least-Connection : Le load-balancer choisit un serveur réel dans un

groupe en fonction de l'adresse IP de destination. Il est utilisé dans les clusters de
cache.

CSII1 – Année 2008 – Projet Load-Balancing page 5

 - Locality-Based Least-Connection with Replication : Idem que le précédent, avec une
fonctionnalité supplémentaire : si tous les serveurs du groupe sont surchargés ou
indisponibles, il choisit un serveur dans un autre groupe pour l'affecter au 1er groupe
de serveurs.

- Destination Hashing : affecte la requête arrivant à un serveur d'un groupe fixé dans
une table de hachage, en fonction de l'adresse IP de destination.

- Source Hashing : affecte la requête à un serveur réel en fonction de l'adresse source.

C) COMMENT SE PASSE LA CONNEXION D’UN CLIENT

Le client se connecte via la seule IP qu’il connait : c'est-à-dire l’IP principale du load-
balancer. Celui-ci via l’algorithme de routage choisi, va renvoyer le client sur le serveur réel
le plus adapté à l’instant t. Ainsi le client pourra utiliser le service apache, et ne se rendra
même pas compte qu’il y a plusieurs serveurs qui pouvaient traiter sa demande.

2° FONCTIONNEMENT DE LVS ET ALGORITHMES DE LVS

A) FONCTIONNEMENT DE LVS

Mettre en place une solution de clustering et de load-balancing permet d’accroître la

disponibilité de votre application tel qu’un serveur web ou encore un serveur ftp. Pour
effectuer cela, il existe plusieurs techniques :

- Disposer d’un routeur de couche 4

- De mettre en place l’option Round Robin sur votre serveur DNS
- A l’aide de logiciel tel que Linux Virtual Server (LVS)

LVS est un logiciel qui travaille sur les couches 3 et 4. Il fait des redirections sur
différentes adresses IP et sur différents ports TCP. Nous pourrions dire que c’est un Round
Robin évolué.

En effet, si l’on fait une symétrie entre LVS et Round Robin, dans le rôle du serveur ce
sera le load-balancer, et pour le reste cela reste la même chose.

CSII1 – Année 2008 – Projet Load-Balancing page 6

 Ainsi, lorsque l’on effectue une requête au load-balancer c’est lui qui va déterminer quel
serveur va répondre, en fonction de sa table répertoriant les serveurs réels et les services du
serveur. Il se peut que ce load-balancer peut tomber en panne alors vous pouvez mettre un
second load-balancer pour plus de sécurité. Ces deux répartiteurs de charge sont reliés par
heartbeat. Les répartiteurs de charge forment un cluster, et chaque machine du cluster
s’appelle un node.

Quel est l’intérêt par rapport à l’option Round Robin d’un serveur DNS ? Cela permet une
meilleure adaptation au réseau et aux pannes car si un serveur réel tombe en panne, la table du
load-balancer est directement mise à jour par l’intermédiaire d’un logiciel nommé mon. De
plus il existe beaucoup de logiciel de surveillance pour que l’application soit disponible à
99,9%.

LVS peut fonctionner sur tous les systèmes, du moment que celui-ci puisse fournir le
service adéquat (comme http) car la répartition de charge se paramètre avec IPVS.

Il existe trois manières de faire du load-balancing avec LVS :

- En utilisant le NAT

- En utilisant l’IP tuneling

- En utilisant le routage direct

B) LE NAT

On dit qu'un routeur fait du Network Address Translation (NAT) (ce qu'on peut
traduire de l'anglais en « traduction d'adresse réseau ») lorsqu'il fait correspondre les adresses
IP internes non-uniques et souvent non routables d'un intranet à un ensemble d'adresses
externes uniques et routables. Ce mécanisme permet notamment de faire correspondre une
seule adresse externe publique visible sur Internet à toutes les adresses d'un réseau privé, et
pallie ainsi la carence d'adresses IPv4 d'Internet.

Pour le cache ARP la solution la plus simple est en LVS- NAT. Ainsi pas besoin de
gérer le cache ARP. Mais elle est limité car le serveur de répartition est durement mis à
l’épreuve étant donné qu’il traite les paquets entrants, les réécrit et les transmet aux serveurs
réels, puis reçoit leur réponse, la réécrit à nouveau avant de la renvoyer au client.

C) L’IP TUNELING

ITP (Internet Tunneling Protocol) est un protocole (couche 3 du modèle OSI)

permettant le transport de données sécurisées sur un réseau IP.

CSII1 – Année 2008 – Projet Load-Balancing page 7

 ITP prend en charge la notion de NAT, il a été réalisé dans le but de fonctionner avec
le protocole IPv6 tout en étant adapté pour l'actuel protocole IP : IPv4.

Son but est d'assurer l'intégrité et la confidentialité des données : le flux ne pourra être
compréhensible que par le destinataire final (chiffrement) et la modification des données par
des intermédiaires ne pourra être possible (intégrité).

ITP peut être un composant de VPN pour sa sécurité ou peut-être utilisé pour la
répartition des charges.

L’intérêt est que l’IP Tuneling évite le point de congestion, c'est-à-dire que toutes les
requêtes n’ont pas besoin de passer par le serveur de répartition aussi souvent qu’en mode
LVS-NAT.

D) LE ROUTAGE DIRECT

Cette technique est la même que l’IP tuneling sauf que les serveurs réels se trouvent
dans un même réseau local.

L’intérêt est le même que l’IP tuneling (évite le point de congestion) et l’encapsulation
IP avec adressage IP virtuelle.

La solution LVS-DR (Direct Routing) est plus compliqué car il faut gérer le cache
ARP, mais est beaucoup plus performante car elle ne monopolise pas le serveur de répartition
dans les deux sens. Les requêtes ne sont pas retraduites lors des réponses des serveurs réels
vers le client.

3° LE CLUSTERING

A) LES AVANTAGES

Les clusters serveur garantissent une haute disponibilité des applications grâce au
basculement des ressources situées sur les serveurs. Le service de cluster permet le
fonctionnement des clusters serveur.

Un autre avantage est que lorsqu’une machine tombe en panne, toutes les applications
du cluster restent fonctionnelles. Les autres machines prennent en charge ce que la machine
en panne ne peut plus faire.

CSII1 – Année 2008 – Projet Load-Balancing page 8

 Enfin ceci permet aussi de retirer une machine du cluster afin de pouvoir l’administrer
en y ajoutant des applications, des mises à jour etc.

B) UTILISATION

Le clustering est principalement utilisé sur des applications critiques comme les bases
de données, les systèmes de gestion de la connaissance, les progiciels de gestion intégrés et
les services de fichiers et d'impression.

C) HEARTBEART ET LDIRECTOR

Il y a d'autres outils comme Heartbeat et Ldirector qui peuvent renforcer le LVS :

- Heartbeat permet d'avoir plus de deux load-balancers; si le load-balancer primaire tombe en

panne, le secondaire prend le relais automatiquement sans interruption de service

- Ldirector permet de vérifier si les serveurs réels sont disponibles; si un des serveurs réels
tombe en panne, il est automatiquement retiré du LVS.

D) COMMENT METTRE EN PLACE CES PAQUETS

Dans le fichier /etc/ha.d/ha.cf sur tous les load-balancer. (Ici je n’en ai que deux : On
le voit avec les node qui sont le nombre de serveurs contenus dans le cluster)

Eth0 est l’interface c'est-à-dire la carte réseau.

Le port utilisé pour heartbeat est le port 694 en UDP.

L’auto_failback est à off ce qui signifie que lorsqu’un serveur est coupé, pour le remettre dans
le cluster, il faut redémarrer le service heartbeat avec cette commande : /etc/init.d/heartbeat
restart

bcast eth0
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
keepalive 2
deadtime 10

CSII1 – Année 2008 – Projet Load-Balancing page 9

warntime 6
initdead 60

udpport 694
node loadb1
node loadb2

auto_failback off

Dans le fichier /etc/ha.d/haresources sur tous les load-balancer écrire cette ligne pour
considérer loadb1 comme étant le load-balancer maître :

loadb1 IPaddr::192.168.5.1

Dans le fichier /etc/ha.d/authkeys sur tous les load-balancer :

auth 2
1 md5 "cluster test"
2 crc

La phrase de cryptage doit évidemment être changée. Ici « cluster test » n’est qu’un
exemple. Nous pouvons augmenter la sécurité en y ajoutant davantage de caractères
alphanumériques et de caractères spéciaux. Ne pas oublier de faire un chmod 600
/etc/ha.d/authkeys pour protéger le fichier.

Note : Les fichiers haresources et authkeys doivent être strictement identique sur tous les
load-balancer.

E) TESTS SUR HEARTBEAT

Vérifiez si les connexions SSH à chacun des nodes via leur adresse IP (192.168.5.1 et
192.168.5.2 dans notre exemple) fonctionnent. Si tel est le cas, nous pouvons faire un test.
Sinon il faut installer ssh sur les serveurs réels: apt-get install openssh-server

Pour se connecter, suffit de prendre un client ssh (Putty sous Windows, ou la console
sous Linux) et de marquer ssh [email protected] (faire entrée) puis rentrer le mot de passe.
Vous verrez ainsi root@loadb1# ou alors root@loadb2# en fonction du serveur sur lequel
vous êtes.

CSII1 – Année 2008 – Projet Load-Balancing page 10

Lancez le service HeartBeat sur le node maître; à savoir loadb1 via la commande suivante :

/etc/init.d/heartbeat start (ou restart)

Puis faire de même sur loadb2. Si ca fonctionne vous pouvez maintenant tenter une
connexion SSH sur l'adresse du cluster ; à savoir : 192.168.4.100 dans notre exemple. Une
fois identifié, vous vous rendez compte que l'invite de ligne de commande vous dit que vous
êtes sur loadb1 (root@loadb1#).

Maintenant, éteignez loadb1.

Votre console SSH va vous signaler une erreur (normal loadb1 n’est plus allumé).

Relancez une connexion SSH sur l'adresse du cluster. Le service répond ! Or, loadb1
est arrêté. Une fois identifié, vous vous rendez compte que l'invite de ligne de commande
indique qu’on se trouve sur loadb2 (root@loadb2#). En rallumant loadb1 ssh reste sur load2,
même si ce premier est maitre. Pour qu’il reprenne la main, il faut relancer le service sur
loadb2 de cette manière /etc/init.d/heartbeat restart

CSII1 – Année 2008 – Projet Load-Balancing page 11

 II) COMMENT METTRE EN PLACE UN REPARTITEUR DE CHARGE

1° METTRE EN IP FIXE LES SERVEURS

Modifications sur fichier /etc/network/interfaces pour mettre en IP statique (mieux

pour un serveur)

Taper /etc/init.d/networking restart pour relancer le service réseau avec les nouvelles
configurations.
Eth0 est la carte externe (pour internet) et eth1 est la carte LAN (qui reste dans le cluster).

Prenez note que tout ce qui se trouve à l’intérieur du cluster appartient au sous réseau 192.168.5.0 et donc les
seules adresses IP en 192.168.4.x sont sur le load-balancer. Celui-ci possède deux cartes Ethernet pour faire la
liaison entre le WAN, et le LAN. Et enfin les passerelles de serveurs réels sont l’adresse IP du coté LAN du
load-balancer, c'est-à-dire 192.168.5.1

root@loadb1:~#cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.4.100
netmask 255.255.255.0
gateway 192.168.4.254

auto eth1
iface eth1 inet static
address 192.168.5.1
netmask 255.255.255.0

root@real1:~#cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.5.10
netmask 255.255.255.0

CSII1 – Année 2008 – Projet Load-Balancing page 12

 gateway 192.168.5.1

root@real2:~#cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.5.11
netmask 255.255.255.0
gateway 192.168.5.1
Avec un ifconfig, on constate bien que l'on a désormais 3 interfaces réseaux : lo qui est la
boucle locale, eth0 qui est la carte externe pour Internet et enfin eth1 qui est la carte interne
pour le LAN.

CSII1 – Année 2008 – Projet Load-Balancing page 13

2°INSTALLER LES PAQUETS NECESSAIRES

Sur le load-balancer, les paquets nécessaires sont ipvsadm, heartbeat, ldirectord que
l’on installe facilement grâce à apt-get install ipvsadm heartbeat ldirectord

Sur les serveurs réels, nous aurons besoin d’apache2 : apt-get install apache2

Le système de paquets apt gère toutes les dépendances. Il se peut donc qu’il vous
propose d’installer des paquets supplémentaires. Acceptez alors en faisant « o » ou « y » selon
que vous soyez en Français ou en Anglais.

3°AUTORISER LE ROUTAGE

Ensuite, il faut éditer le fichier /etc/sysctl.conf et décommenter la ligne

"net/ipv4/ip_forward=1" pour autoriser le routage.

Ou alors taper echo "1" > /proc/sys/net/ipv4/conf/all/forwarding

Ou enfin allez dans cd /proc/sys/net/ipv4/conf/all/ puis faite un vi forwarding puis modifier la

valeur et enregistrer.

Sur le load-balancer tapez les commandes suivantes pour activer la translation

d’adresses IP sur votre serveur. Dans notre exemple la carte externe (c’est à dire Internet) du
répartiteur de charge correspond à eth0 et donc la carte interne (c’est à dire LAN) correspond
à eth1 :

Iptables –t nat –P POSTROUTING DROP

Iptables –t nat -A POSTROUTING –o eth0 –j MASQUERADE

Modifier les paramètres ARP pour que l’IP LAN renvoie toujours l'adresse MAC du
Load-Balancer afin que les paquets provenant du serveur LVS vers les serveurs réels soient
renvoyés vers le load-balancer. Cela impose une propriété aux serveurs réels : l'interface
possédant l'adresse l’IP LAN ne doit pas résoudre au niveau ARP. Il faut donc modifier ces
fichiers sur le load-balancer grâce à ces commandes :

CSII1 – Année 2008 – Projet Load-Balancing page 14

echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects
echo "0" > /proc/sys/net/ipv4/conf/default/send_redirects
echo "0" > /proc/sys/net/ipv4/conf/eth0/send_redirects

Et on ajoute aussi celles-ci :

echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore

echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce
echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce

Taper la commande sysctl -p /etc/sysctl.conf pour activer les modifications.

4°AJOUTER DES MACHINES DANS LE CLUSTER

Puis ajoutez ces lignes aussi sur le load-balancer :

Ipvsadm –A –t 192.168.4.100 :80 –s wlc
Ipvsadm –a –t 192.168.4.100 :80 –r 192.168.5.10:80 -m
Ipvsadm –a –t 192.168.4.100 :80 –r 192.168.5.11:80 –m –w 2

192.168.4.100 : IP internet du Load-Balancer.

192.168.5.10 : IP du serveur réel1 avec apache
192.168.5.11 : IP du serveur réel2 avec apache
La première commande sert à définir le service. Il s’agit d’un service TCP (-t) sur le
port 80 (http) avec l’adresse 192.168.4.100. L’option "-s wls" sert à choisir l’algorithme de
répartition de charge, c'est-à-dire ici le Le Weighted Least Connexion (WLC) qui pour rappel
gère bien la répartition entre serveurs de puissances différentes. Les serveurs du cluster sont
classés par rapport à leur poids, et un pourcentage leur est attribué.

Les 2 lignes suivantes servent à rajouter nos deux serveurs réels dans la liste des
machines qui font partie du cluster afin de répondre aux requêtes clientes.
-r pour dire que c’est un serveur réel
-m pour dire qu’il s’agit d’une machine
-w pour donner un poids. Plus celui-ci est important, et plus le serveur recevra de demandes.
(Par défaut c’est – w 1)

CSII1 – Année 2008 – Projet Load-Balancing page 15

III) LES TESTS A EFFECTUER

Lorsque toutes les machines sont lancées, un test simple et de prendre un client
d’ouvrir dans un navigateur, et de rentrer dans cet explorer l’adresse IP du load-balancing.
(Dans notre exemple écrire http://192.168.4.100 )

Normalement vous devriez voir des fichiers qui se trouvent dans /var/www/

En fait nous sommes dans le /var/www d’un des serveurs réels. En actualisant la page
il se peut que vous voyez d’autres fichiers ou encore les mêmes. Ca dépend si on reste sur le
même serveur réel ou non, et ceci dépend du choix de l’algorithme.

Comme premier test je vous conseille l’algorithme round robin, ainsi une fois vous
serrez sur le serveur 1 et la seconde fois, sur le second serveur. Créez des fichiers différents
dans les /var/www/ vous verrez qu’avec la même IP dans le navigateur, vous aurez accès à
tous les serveurs réels.

CSII1 – Année 2008 – Projet Load-Balancing page 16

CONCLUSION

Le load-balancing accroit donc considérablement la vitesse de réponse lorsque la

montée en charge devient importante. C’est une solution plus économique que l’achat d’un
nouveau serveur plus puissant, et plus sécurisante, car si l’un des serveurs tombe, les autres
sont toujours là pour assurer le service.

Cependant la répartition de charge pose un autre problème. En effet les serveurs réels
travaillent l’un à la suite de l’autre, et l’utilisateur ne sait pas qu’il travaille sur plusieurs
serveurs, et il sait encore moins sur quel serveur il se trouve. Le problème se trouve ici :
Lorsqu’il enregistre des données sur le serveur numéro 1, les autres serveurs n’ont pas ces
informations, il n’y a pas de réplication. Donc une fois que le load-balancing est installé, il
faut ensuite mettre en place une solution de réplication, afin d’avoir instantanément une même
base de données, et une même arborescence sur tous les serveurs. On peut utiliser le module
de noyau DRBD "Distributed Replicated Block Device" qui permet d'écrire des informations
sur un disque physique et de les transmettre sur un homologue miroir qui se trouve sur une
machine secondaire via le réseau Ethernet (et ceci de manière totalement fiable et
automatisée).

CSII1 – Année 2008 – Projet Load-Balancing page 17