LP ASRALL

Équilibrage de Charge et Haute Disponibilité

pour applications Web Ruby On Rails

Auteurs :
Gatien Gaspard ,

Rémi Jachniewicz ,

Lacava
22 avril 2009
Julien ,

Vincent Meslard
Table des matières
1 Étude 2
1.1 Le projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Équilibrage de charge et haute disponibilité . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Équilibrage de charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Haute disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 État de l'art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Répartition de charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Haute Disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.3 Serveur Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.4 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 Principe et fonctionnement de LVS . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.1 Présentation de LVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.2 Méthodes de transmission pour la répartition de charge . . . . . . . . . 15
1.4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5 Algorithmes des équilibreurs de charge . . . . . . . . . . . . . . . . . . . . . . . 18
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 Protocoles de tests 22
2.1 Inventaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Outils de test montée en charge . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1 Apache Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.2 HTTPerf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.3 Siege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.4 Tsung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Mise en Pratique 25
3.1 Environnement d'expérimentation . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Mise en ÷uvre des Équilibreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 LVS Nat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.2 Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.3 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Mise en ÷uvre des serveurs Web . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.1 Développement d'une application ROR simple . . . . . . . . . . . . . . . 29
3.3.2 Installation d'un serveur Web Apache + Mongrel . . . . . . . . . . . . . 29
3.3.3 Mise en ÷uvre des Bases Mysql . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Installation de Tsung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

1
 3.5 Tests et relevés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5.1 Conguration du test de charge . . . . . . . . . . . . . . . . . . . . . . . 32
3.5.2 Point de vue du Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5.3 Point de vue de l'Administrateur . . . . . . . . . . . . . . . . . . . . . . 39
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 Divers 43
4.1 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Compte rendu projet Tutoré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.1 Nous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.2 Statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.3 Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2
Chapitre 1

Étude
1.1 Le pro jet

Notre projet porte sur la mise en place de solutions assurant la haute disponibilité et la
répartition de charge sur un service Web. Les serveurs oriront un service Web basé sur Ruby
on Rails couplé à un Système de Gestion de Base de Données. Le projet se déroule en deux
grandes parties. La première consiste à se documenter sur les solutions existantes et à choisir
celles qui conviendront le mieux. La seconde est plus pratique avec la mise en place de l'une
des solutions choisies suivie d'une période de tests et benchmarking.

Le developpement d'une petite application Ruby on Rails sera donc indispensable pour ce
Ruby
projet. est un langage de script orienté objet. L'une de ses plus importantes caractéris-
tiques est d'être entièrement orienté objet. Mais malgré ses nombreuses qualités, il manquait
Ruby
au langage un framework puissant, exploitant au mieux ses nombreuses facettes.
Ruby on Rails est donc apparu. Celui-ci permet de construire des sites Internet de manière
fonctionnelle, rapide et fournissant tous les outils nécessaires pour les sites que l'on trouve au-
jourd'hui. Il propose aux développeurs d'améliorer considérablement leur productivité grâce à :

 un code plus concis, plus évolutif et produit plus rapidement,

 une conguration minimale, favorisant certaines conventions,
 des technologies déjà intégrées comme Ajax permettant d'orir aux utilisateurs naux
une interface riche et plus ergonomique.

Il en résulte des sites qui proposent des interfaces riches en fonctionnalités, pourvues d'une
forte interactivité, illustrant bien les services Web 2.0. De plus, tout a été conçu pour minimiser
la partie développement d'un projet et maximiser la partie créativité et originalité du projet.
Ainsi, il est possible de produire des petits sites web sans écrire une seule ligne de code ! Un
certain nombre d'outils sont disponibles à l'installation et permettent d'automatiser les tâches
les plus classiques (création d'un formulaire, gestion de la base de données, gestion des erreurs,
etc.).

Dans sa phase de développement, une application Ruby on Rails peut se permettre de

travailler avec le serveur web écrit en Ruby WEBrick
: . Par une simple ligne de commande, le
développeur exécute sur son ordinateur un serveur web. Le serveur est tout de suite opérationnel
et est entièrement dédiée au développement de l'application.
En ce qui concerne la base de données, plusieurs systèmes de gestion de base de données sont
supportés : SQLite MySQL PostgreSQL DB2 Oracle Microsoft SQL Server
, , , , et . Pour les
apache lighttpd
serveurs Web, on peut utiliser ou Nginx Mongrel
ou encore avec .

3
1.2 Équilibrage de charge et haute disponibilité

1.2.1 Équilibrage de charge

L'équilibrage de charge est un élément important lors de la mise en place de services amenés
à croître. Il faut s'assurer que la capacité à monter en charge soit la plus optimale possible an
d'éviter toute dégradation que ce soit en terme de performances ou de abilité lors d'auences
importantes.
Le principe de base de l'équilibrage de charge ( load balancing en anglais) consiste à eectuer
une distribution des tâches à des machines de façon intelligente. Pour cela il faut intégrer un
dispositif entre les serveurs et les utilisateurs de la ressource. Ce dispositif aura pour tâche de
rediriger les consommateurs de services en fonction de l'état d'occupation des serveurs. Il faut
aussi prendre en compte le service distribué et adapter la méthode de redirection en fonction
de celui-ci au travers de diérents algorithmes (Round Robin, Random, Least Resources...).
Les gains sont non négligeables :
 amélioration des temps de réponse des services,
 capacité à pallier la défaillance d'une ou de plusieurs machines,
 ajout de nouveaux serveurs sans interruption de service.
L'équilibrage de charge utilise essentiellement 2 techniques qui sont le DNS et le reverse-
proxy.

1.2.2 Haute disponibilité

La haute disponibilité est l'ensemble des moyens mis en ÷uvre dans le but de garantir la
disponibilité d'un service de part son bon fonctionnement. Ces dispositions sont eectuées dans
le but de prévenir toutes les pannes informatiques qui peuvent, en fonction de leur gravité,
provoquer une perte de productivité et par conséquent une perte d'argent.
Cette disponibilité est exprimée en pourcentage avec temps de disponibilité sur temps total.
Quelques exemples sur une année :
97% 11 jours
98% 7 jours
99% 3 jours et 15 heures
99,9% 8 heures et 48 minutes
99,99% 53 minutes
99,999% 5 minutes
99,9999% 32 secondes

Pour prévenir les défaillances, il est nécessaire de mettre en place des mécanismes de re-
dondance sur les éléments critiques.

1.3 État de l'art

1.3.1 Répartition de charge

Il existe plusieurs solutions pour faire de la répartition de charge, la plus basique étant
l'utilisation de DNS. Dans cette solution le répartiteur de charge est le serveur DNS. Basé sur
la conguration de bind (démon le plus utilisé sous Linux pour le DNS), le serveur DNS permet
de résoudre les noms d'hôtes de manière diérente à chaque requête. Un nom de domaine est
associé à plusieurs adresses IP correspondant à chaque serveur du cluster. Bind , utilise alors
un algorithme round-robin pour choisir le serveur destinataire de la requète. L'avantage de ce
système est sa grande simplicité, il sut d'ajouter quelques lignes à la conguration de bind

4
sur le serveur DNS. Par contre il ne permet pas de prendre en compte les performances d'un
serveur, ou bien son taux d'occupation, puisque qu'il n'utilise qu'un algorithme round-robin.

D'autres solutions permettent de prendre en compte ces problèmes de performance ou de

défaillance de serveurs du cluster. Voici quelques unes de ces solutions.

LVS
Linux Virtual Server 1 est une solution de répartition de charge pour GNU/Linux. L'objectif
principal est de construire un serveur de haute performance pour Linux utilisant la technologie
du clustering. LVS est un logiciel basé sur les couches 3 et 4 de la représentation OSI. Il fait
des redirections sur les adresses IP ainsi que diérents ports TCP. LVS est plus détaillé par la
suite (en 1.4).

Apache - mod_proxy_balancer
À partir de apache 2.1 2 , en utilisant le module mod_proxy_balancer, il est possible de
faire de l'équilibrage de charge pour les protocoles HTTP, FTP et AJP13 (Apache JServ Protocol
- utilisé principalement avec Tomcat pour rediriger les sessions vers le bon serveur et pour faire
du monitoring simple). Il intègre trois algorithmes d'ordonnancement : Request Counting ,
Weighted Trac Counting Pending Request Counting
et .
 Request Counting : répartit les requêtes de façon pondérée vers les serveurs.
 Weighted Trac Counting : répartit les requêtes de façon pondérée sur la taille (en
octets) des réponses.
 Pending Request Counting : répartit les requêtes de façon pondérée sur la taille de la
liste d'attente des requêtes sur chaque serveur.
Le module mod_status permet de rajouter des possibilités de gestion dynamique des pon-
dérations de chaque serveur.
Avantages :
 facilité de mise en ÷uvre,
 bien maintenu,
 portabilité (toute architecture supportant apache ).
Inconvénients :
 protocoles HTTP, FTP et AJP13 uniquement.

Pen
Pen est un load balancer pour les protocoles basés sur TCP. Il permet de distribuer les
requêtes de clients sur diérents serveurs en gardant une trace de ceux-ci pour renvoyer chaque
client vers le serveur qui lui avait été aecté précédemment. Il intègre également un dispositif
simple de haute disponibilité qui, si un serveur est hors service, envoie la requête vers un autre.
Il est possible de faire de la redondance sur pen lui-même en le déployant sur plusieurs
serveurs et en utilisant le protocole VRRP3 pour décider lequel est actif.
Alors que le monitorage de pen se limite à la couche transport, il est possible de faire du
monitorage au niveau applicatif en utilisant penbw .
Avantages :
 tous les protocoles basés sur TCP (y compris HTTPS),
 possibilité d'utiliser VRRP,

1
http://www.linuxvirtualserver.org/
2
http://httpd.apache.org/
3
Virtual Router Redundancy Protocol - RFC 3768

5
  bien maintenu (dernière version : mai 2008),
 bonne portabilité (FreeBSD, Linux, HP-UX, Solaris et Windows),
 détection automatique des serveurs hors-services,
 garde en mémoire les traces des clients.
Inconvénients :
 un seul algorithme (round-robin + trace des connexions).

HaProxy
HAProxy 4 permet de répartir les connexions reçues d'un protocole sur plusieurs serveurs.
Il permet aussi de détecter l'indisponibilité d'un des serveurs. Il peut être utilisé pour les
applications utilisant TCP. HAProxy sait gérer plusieurs proxy à la fois. C'est un Reverse-
Proxy, surtout utilisé pour les sites Web.
Avantages :
 peut tenir des charges très importantes comme plusieurs milliers de connexions par se-
conde,
 ressources matérielles nécessaires très faibles,
 aucune vulnérabilité depuis plus de 6 ans.
Inconvénients :
 reconguration à chaud impossible,
 pas d'interface Web de conguration,
 pas de centralisation des congurations.

Balance
Balance 5 est une solution simple basée sur le niveau utilisateur de la couche OSI, il ne
touche pas au kernel. Il ore une solution d'équilibrage de charge mais aussi de proxy TCP.
Son Load Balancing est basé sur plusieurs algorithmes (RoundRobin, random, hash, least
resources). Il ore une gestion totale via la ligne de commande en plus d'être très léger. Il
existe en deux versions, une gratuite ( balance ) et une commerciale ( balanceng 6 ).
Avantages :
 gestion totale via ligne de commande possible,
 diérents algorithmes de Load Balancing,
 mise en place rapide.
Inconvénients :
 basé sur niveau utilisateur,
 pas OpenSource,
 version payante plus souvent mise à jour.

Nginx
Nginx 7 est un serveur et proxy web haute performance, il peut également servir de proxy
mail et surtout en mode reverse proxy avec load balancer. Il a été programmé an d'obtenir les
meilleurs performances possibles. Ainsi, il ne nécessite pas d'avoir autant de processus que de
connexions, un par processeur sut. Les requêtes sont découpées en mini-tâches, ordonnancées
par chacun des processus. Ceci et le fait qu'il soit développé en C lui confèrent une empreinte
mémoire vraiment faible et une excellente rapidité d'exécution.

4
http://haproxy.1wt.eu/
5
http://www.inlab.de/balance.html
6
http://www.inlab.de/balanceng/
7
http://nginx.net/

6
 Nginx est un front-end populaire pour les applications Rails PHP
et . Aussi, l'équilibrage
de charge mis en place est de type Round-Robin pondéré.
Avantages :
 très facile à mettre en ÷uvre,
 bien maintenu (dernière version : Janvier 2009),
 bonne portabilité GNU/Linux, BSD, Mac OS X, Solaris, Windows (non maintenu o-
ciellement),
 protocoles HTTP et HTTPS.
Inconvénients :
 pas de monitoring intégré.

Autres solutions logicielles

Voici une liste non exhaustive d'autres solutions disponibles :

1. OSCAR (Open Source Cluster Application Ressources)8

Cette solution contient un ensemble d'applications pour l'installation, l'administration
et l'utilisation de clusters.
Avantages :
 projet open source,
 apres la version 5.0 en 2006, reprise de l'activité en 2009 avec la version 6.0,
 packagé pour de nombreuses distributions,
 multi-architecture.
Inconvénients :
 peu de documentation,
 plutôt orienté calcul distribué.

2. CLIC9
C'est une application permettant la gestion de cluster développée par Mandrake Soft.
Avantages :
 projet open-source.
Inconvénients :
 peu de documentation,
 ne semble plus maintenu, n'a pas évolué depuis 2003,
 plutôt orienté calcul distribué.

3. POUND10
POUND est un reverse-proxy.
Avantages :
 projet open-source sous licence GPL,
 pas d'accès direct au disque dur,
 wrapper ssl.
Inconvénients :
 utilisable uniquement pour la répartition de charge sur serveurs web.

Implication de la couche du modèle OSI utilisée.

Parmi toutes ces solutions, certaines sont basées sur la couche réseau/transport du modèle
OSI (Niveau 3/4) tandis que d'autres sont basées sur la couche applicative (Niveau 7). Cela

8
http://oscar.openclustergroup.org/
9
http://www.mandriva.com/clustering
10
http://www.apsis.ch/pound/

7
implique que les premiers prennent en considération l'ensemble des protocoles
11 utilisant TCP,
tels que HTTP(S), FTP, SMTP / POP3 / IMAP, . . . Ceux basés sur la couche applicative en revanche
sont beaucoup plus restrictifs puisqu'ils sont spécialisés, ils ne s'occupent par exemple que de
HTTP.

11
TCP (RFC 793), HTTP (RFC 2616), FTP (RFC 959), SMTP (RFC 1870), POP3 (RFC 1939), IMAP
(RFC 2595).

8
 Récapitulatif des fonctionnalités
I
S é
O it nu
e il
ce b te
e en ch ta in
yp ic ou or a

TLS/SSL
Sessions
Cache
T L C P M
Apache Serveur web, apache X X X Application Unix, Windows décembre 2008
reverse proxy
HAProxy Load Balancer GPL X X X Application Unix Novembre 08
Pen Load Balancer GPL X Application Unix, Windows Mai 2008
Balance GPL ? ? Application Unix Avril 08
BalanceNG shareware X X Application Unix Février 09
UltraMonkey ? GPL - - - Réseau/Transport Unix 2005
Nginx Serveur web, Reverse Proxy type BSD X X X Application12 Unix janv-2009
reverse proxy
Oscar GPL ? ? ? Réseau/Transport Unix 2009
Clic GPL - - Réseau/Transport Unix 2003
Pound Reverse Proxy GPL X X X Application Unix 2009

9
LVS(IPVS) Load Balancer GPL X X - Réseau/Transport Unix 2004
KeepAlived HealthCheck/Failover GPL ? ? ? Application Unix 2009
Synthèse : répartition de charge
Si l'on s'en tient aux données présentées précédemment, il existe 2 méthodes principalement
utilisées pour faire de l'équilibrage de charge de serveurs Web, il y a les applications basées sur
LVS et les reverse-proxies. Nous pouvons ainsi retenir dans le cadre de notre projet, POUND
qui est un reverse-proxy et LVS puisque ceux-ci sont maintenus, stables et éprouvés.

1.3.2 Haute Disponibilité

La haute disponibilité permet d'obtenir un temps d'indisponibilité minimal grâce à des
principes simples tels que la redondance de l'ensemble du matériel et des services an de limiter
les SPOF ( Single Point of Failure ). Il est ainsi systématique dans ce type de conguration de
pratiquer de la réplication de données ainsi que de mettre en place des technologies telles que
le RAID an d'éviter les pertes de données.

Drbd
DRBD (Distributed Replicated Block Device) est un mécanisme de réplication de données
localisées sur deux serveurs distincts par voie réseau. Quand une écriture a lieu sur le disque du
serveur maître, l'écriture est simultanément réalisée sur le serveur esclave. La synchronisation
est faite au niveau de la partition. Le mécanisme DRBD fournit une approche du périphé-
rique partagé, mais ne nécessite aucun matériel spécique. En eet, il utilise simplement le
protocole IP pour le transport des données, ce qui s'avère moins coûteux en matériels que les
périphériques de stockage réseau (NAS, SAN).
Avantages :
 maintenance des serveurs sans coupure de services,
 indépendant du type de système de chiers utilisé sur le serveur.

Heartbeat
Heartbeat est un système de gestion de la haute disponibilité. Heartbeat met en place un
système de clustering en haute disponibilité basé sur le principe des battements de c÷ur. Il
exécute des scripts d'initialisations lorsque une machine tombe (plus d'entente du batte-
ment de c÷ur) ou est à nouveau disponible (battement de c÷ur retrouvé). Il permet aussi de
changer d'adresse IP entre plusieurs machines à l'aide de mécanismes ARP avancés. Heartbeat
fonctionne à partir de deux machines et peut être mis en place pour des architectures réseaux
plus complexes.

Ldirectord
Ldirectord , écrit en Perl
, a pour rôle la surveillance applicative des machines et modie, en
temps réel, les règles de redirection, à l'aide de la commande ipvsadm Ldirectord
. va permettre,
si une machine devient indisponible, de la retirer du pool de serveurs, an que les utilisateurs
n'aient pas de messages d'erreurs.

KeepAlived
Keepalived est utilisé pour surveiller les serveurs au sein d'un cluster en utilisant LVS .
Keepalived peut être conguré pour supprimer un serveur appartenant au cluster (grappe de
machines) s'il ne répond plus. Il peut aussi envoyer une notication par courriel pour que
l'administrateur soit prévenu de la perte du service.

10
UltraMonkey
Il existe également des solutions tout-en-un permettant de mettre en ÷uvre rapidement un
équilibrage de charge. Ultramonkey fait partie de celles-ci.
Ultramonkey regroupe plusieurs solutions logicielles permettant de mettre en place un sys-
tème assurant l'équilibrage de charge mais aussi la haute disponibilité des services/données.
Celui-ci est basé sur LVS pour l'équilibrage, heartbeat pour la disponibilité et ldirectord pour la
supervision des diérentes machines. Ces logiciels sont réputés pour leur bon fonctionnement
ainsi que leur ecacité. Ultramonkey convient aussi bien pour la mise en place sur de petits
clusters que sur de grands systèmes.
Avantages :
 travaille sur la couche transport du modèle OSI avec LVS ,
 facilement extensible pour un grand nombre d'IP basées sur des services virtuels,
 haute disponibilité oerte par le protocole de Heartbeat ,
 monitoring des services via ldirectord,
 ore une documentation assez complète sur le déploiement de solutions de haute dispo-
nibilité et/ou d'équilibrage de charge,
 open source,
 package Debian disponible.
Inconvénients :
 n'est plus maintenu.

Mon
Mon est un outil de surveillance applicative qui permet de surveiller l'état des ressources
logicielles et de déclencher des actions paramétrables. C'est un composant essentiel pour dé-
clencher un basculement dans le cadre d'un cluster avec migration de services ( Heartbeat ) si
l'application ne tourne plus sur la machine active.

Mysql Replication
MySQL supporte la réplication unidirectionnelle interne. Un serveur sert de maître, et les
autres serveurs servent d'esclaves. Le serveur entretient des logs binaires de toutes les mo-
dications qui surviennent. Il entretient aussi un chier d'index des chiers de logs binaires,
pour garder la trace de la rotation des logs. Chaque esclave, après connexion réussie au serveur
maître, indique au maître le point qu'il avait atteint depuis la n de la dernière réplication, puis
rattrape les dernières modications qui ont eu lieu, puis se met en attente des prochains événe-
ments en provenance du maître. Ce sera donc une solution de haute disponibilité, l'équilibrage
de charge ne sera pas mis en place sur les bases de données.

11
 Récapitulatif des fonctionnalités
é
it nu
il
b te
e ta i n
yp or a
T P M
UltraMonkey Package de solution Unix Juillet 2007
Drdb Outil de replication réseau Unix Février 2009
HeartBeat Outil de monitoring Unix Février 2009
Ldirectord Système de clustering Unix Février 2009
KeepAlived Système de clustering Unix Mars 2009
Mon Outil de monitoring Unix Juin 2007
MySQL Replication Outil de replication réseau Multiplateforme Janvier 2009

12
Synthèse : haute disponibilité
Comme cela est visible dans le tableau précédant, chacune de ces applications est destinée
à un traitement particulier lié à la haute disponibilité hormis Ultramonkey qui est un package
regroupant certaines des solutions présentées an de fournir un outil clé en main. Dans le cadre
de notre projet, ces solutions peuvent toutes convenir. Ainsi, un choix devait être fait ( Heart-
Beat Ldirectord Keepalived
+ ou pour la gestion du cluster, DRBD MySQL Replication
ou
pour les bases de données). Les solutions choisies au nal sont : HeartBeat Ldirectord
+ ainsi
que MySQL Replication
1.3.3 Serveur Web
An de mettre en place une application ruby , il nous faut un serveur web capable d'exécuter
du code ruby . Nous allons présenter ici une liste des serveurs susceptibles de nous intéresser.

Apache
Apache HTTP Server , souvent appelé Apache , est un serveur HTTP produit par l'Apache
Software Foundation. C'est le serveur HTTP le plus populaire du Web. C'est un logiciel libre
avec un type spécique de licence, nommée licence Apache Apache
. est conçu pour prendre en
charge de nombreux modules lui donnant des fonctionnalités supplémentaires : interprétation
des langage Perl PHP Python Ruby
, , et , serveur proxy, Common Gateway Interface, réécriture
d'URL, etc.

Nginx
Nginx est un serveur HTTP et Reverse proxy. Il est désormais utilisé par de plus en plus
de site internet au niveau mondial. Nginx reprend un certain nombre de principes d' Apache ,
comme la notion de chiers de conguration modulaires (via des include), des virtual hosts...
Cependant dans Nginx , il n'y a pas de notion de ServerName ni de ServerAlias. Tout est au
même niveau.

Lighttpd
Lighttp est un serveur web qui supporte un grand nombre de fonctionnalités comparables à
celles d' Apache , comme les rewrite, fast-cgi, proxy, pour des performances aussi bonnes. Gros
inconvénient par rapport à Apache : il ne supporte pas les chiers .htaccess. Il est dans le
Top 5 des serveurs les plus utilisés dans le monde.

Mongrel
Mongrel est un serveur HTTP écrit en Ruby et en C. Il a été conçu pour être léger, rapide et
sécurisé et optimisé pour le délivrement de contenu dynamique Ruby On Rails . C'est un logiciel
libre distribué selon les termes de la licence Ruby, compatible avec la licence GNU GPL.

13
FastCGI ou Mongrel ?

Fig. 1.1  Source : http ://blog.kovyrin.net/

D'après ce graphique, on s'aperçoit que les performances de Nginx et Apache sont sen-
siblement les mêmes, l'un en utilisant Mongrel , l'autre en utilisant FastCGI, d'autre part, la
conguration d' Apache est plus simple que celle ne Nginx
. Nous avons donc décidé de tester
Apache avec Mongrelpour voir les performances avec cette conguration.

1.3.4 Monitoring
En vue d'eectuer des tests sur notre cluster il est indispensable de s'équiper d'outils nous
permettant de surveiller les ressources utilisées sur les machines. De nombreuses solutions
existent c'est pourquoi le choix est très important. Nous allons en premier lieu utiliser les
outils fournis par Linux avec top uptime ps free
, , , ...

Nagios
Nagios (anciennement appelé Netsaint ) est une application permettant la surveillance sys-
tème et réseau. Plutôt axé supervision celui-ci permet d'être conguré de telle façon à récupérer

14
des informations système au travers de scripts. La récupération des informations se fait en par-
tie via SNMP.

RRDtool
Outils de création de graphiques ultra polyvalent, celui-ci permet de créer des graphiques
à partir d'informations de tout type. RRDtool ne gère pas la récupération automatique des
ressources systèmes, il faut pour cela déployer une solution qui lui enverra les informations
désirées.

Munin
Munin est un outil de surveillance système et réseau basé sur l'outil RRDtool . Il présente ses
résultats sous forme de graphiques disponibles via une interface web. Il possède une structure
de plugins particulièrement simple qui permet d'enrichir rapidement l'outil. L'architecture du
système Munin est constituée d'un serveur principal, récupérant les informations à intervalle
régulier et de plusieurs n÷uds, souvent un par serveur à surveiller.

Ganglia
De fonctionnalités équivalentes à Munin Ganglia
, est lui plus axé pour la surveillance de
cluster ou grid (ensemble de cluster). On bénécie aussi d'une présentation par interface web
et d'un système client-serveur pour la récupération des informations.

1.3.5 Conclusion
Notre choix principal est Ganglia car conçu spécialement pour le monitoring de cluster. De
plus il procure un nombre important d'informations et une précision plus grande (détails sur
l'heure, la journée, ...). En eet sous ganglia la précision des statistiques est plus importante
(regraphage sur de plus grands graphiques, changement de base de temps, etc.)

1.4 Principe et fonctionnement de LVS

1.4.1 Présentation de LVS

LVS permet de mettre en ÷uvre un cluster d'un nombre important de machines avec
un répartiteur de charge fonctionnant sous Linux. Celui-ci permet d'assurer la répartition de
charge pour la plupart des services existants tout en permettant une haute disponibilité (via
des logiciels comme heartbeat ).
LVS est constitué d'un logiciel appelé IPVS IPVS
. implémente la répartition de charge au
niveau de la couche transport (TCP). Celui-ci est inclus dans le noyau de Linux depuis sa version
2.0. C'est lui qui met en ÷uvre les diérents algorithmes et s'occupe de router les paquets vers
les serveurs.

La commande ipvsadm permet d'administrer IPVS sur le répartiteur. C'est par son inter-
médiaire qu'on communique l'architecture du cluster (le répartiteur et les serveurs), ainsi que
les services disponibles, les algorithmes à utiliser et les diérents paramètres globaux (timeouts,
log, etc.).

15
1.4.2 Méthodes de transmission pour la répartition de charge
La partie forwarding de IPVS se charge d'envoyer les paquets vers un serveur particulier.
Il change les en-tête des paquets pour pouvoir les transmettre au serveur élu.
Plusieurs méthodes de répartition existent, la grande diérence se situe au niveau de l'ar-
chitecture du cluster. Avec LVS NAT le cluster est dans un réseau privé, alors que dans les
deux autres méthodes les serveurs réels font partie du même réseau que le routeur.

Il y a deux grands principes que le processus de transmission doit respecter :

 Le répartiteur doit modier le paquet pour l'envoyer au serveur réel.
 L'adresse source du paquet répondant à la requête doit être celle du répartiteur.

LVS NAT
C'est la méthode la plus simple à mettre en ÷uvre, on n'a pas besoin de recongurer les
serveurs réels, hormis leur indiquer l'équilibreur de charge comme passerelle par défaut. Seul
le répartiteur a besoin d'être conguré.
Les serveurs sont à l'intérieur d'un réseau privé et leur passerelle, pour leur permettre d'ac-
céder aux réseaux externes, est un répartiteur déni. Donc tous les paquets en provenance ou
à destination d'un serveur réel passent par le répartiteur.

Le principe du NAT (Network Adress Translator) est basé sur la modication des adresses
IP de destination. Lorsqu'un paquet arrive sur le répartiteur, l'adresse IP de destination est
substituée par celle du serveur choisi. Le client n'étant pas dans le réseau privé, le paquet de
réponse du serveur est envoyé au répartiteur (conguré en tant que passerelle sur le client), qui
remplace l'adresse IP source par son adresse. Donc le client recevra un paquet dont l'adresse
IP source est le répartiteur et non le serveur réel. On assure ainsi une totale transparence de
la grappe (répartiteur + serveurs).

LVS NAT a pour avantage l'utilisation d'adresses privées (10.x.x.x, 192.168.x.x) pour les
serveurs réels, il est donc économe en adresse IP publiques et plus simple à administrer.

En contrepartie, la translation d'adresses demande des ressources de calculs plus impor-

tantes que les autres méthodes.

Un autre problème est l'accès d'un serveur à une machine externe au réseau privé, tout le
trac doit passer obligatoirement par le répartiteur. Ce qui constitue un goulet d'étranglement.

16
 Fig. 1.2  Chemin des paquets via LVS-NAT.

LVS DR
LVS Direct Routing modie les tables ARP des serveurs pour transmettre les paquets.

Lors de l'arrivée d'un paquet sur le répartiteur, celui-ci change l'adresse MAC de desti-
nation par celle du serveur élu puis modie la table ARP de ce serveur pour pouvoir résoudre
l'adresse MAC de destination avec l'IP du répartiteur.

À la suite de cette opération, le serveur va renvoyer directement (sans passer par le répar-
titeur) sa réponse au client avec comme adresse IP source celle du répartiteur.

Cette méthode est contraignante car l'ensemble des machines du cluster doit partager la
même table ARP.

17
 Fig. 1.3  Chemin des paquets via LVS-DR.

LVS Tun
Cette méthode utilise l'encapsulation IPIP ( Tunnelling ). Un paquet arrivant sur le répar-
titeur sera encapsulé dans un nouveau paquet, puis envoyé au serveur élu. L'adresse IP de
destination de ce paquet sera alors celle du serveur. Par suite le serveur désencapsule ce pa-
quet pour récupérer le paquet original. Il répond ensuite en envoyant sa réponse directement
au client.

Cette méthode à l'avantage de pouvoir construire une grappe avec des machines très éloi-
gnées (réparties sur plusieurs réseaux), pour faire des miroirs FTP par exemple.

Cette interface est associée à l'adresse IP du répartiteur pour que les paquets partant du
serveur puissent avoir comme adresse source celle du répartiteur.

Ainsi il faut faire en sorte que les serveurs réels ne répondent pas aux requêtes ARP, sous
peine que le client se connecte directement à un des serveurs.

18
 Fig. 1.4  Chemin des paquets via LVS-Tun.

1.4.3 Conclusion
Parmi ces 3 types d'infrastructure, celle qui semble la plus ecace dans le cadre d'un
équilibrage de charge avec haute disponibilité est la méthode de routage direct ( LVS - Direct
Routing ). En eet, cette méthode permet d'éviter le goulet d'étranglement au niveau du ré-
partiteur lié à la structure LVS NAT sans pour autant utiliser d'adresses IP publiques et sans
rendre possible la connexion directe à l'un des serveurs.

1.5 Algorithmes des équilibreurs de charge

Les applications Web modernes utilisent le plus souvent un mécanisme de persistance (les
fameuses sessions en PHP par exemple). HTTP étant un protocole non connecté, un répartiteur
de charge doit pouvoir assurer qu'au cours d'une session limitée dans le temps, un utilisateur
donné devra être reconnecté au serveur ayant eectué la transaction initiale. Plusieurs solu-
tions possibles ont été mise en ÷uvre.

Il existe deux grands types de gestion de la répartition des charges : les algorithmes dé-
terministes et non-déterministes. Les algorithmes déterministes se basent sur un cycle déni
tandis que les algorithmes non-déterministes peuvent router en se basant sur plusieurs para-
mètres. La redirection peut donc ne jamais être la même. Par exemple, Least Connection est
non-déterministe car il va rediriger le client en fonction de la dernière connexion.

19
 Algorithmes déterministes
 Tables de hash : On construit une table de hash à partir de l'adresse IP du client. Cet
algorithme suppose que le client ne passe pas au travers de diérents proxies (adresse IP
variable), sinon il n'est valable qu'au cours d'une session limitée dans le temps. N'assure
pas forcément une répartition homogène.
 Redirection : Les clients sont envoyés vers un serveur de redirection, celui-ci les rediri-
geant vers un serveur selon un algorithme qui lui peut ne pas être déterministe.
Le problème peut alors survenir si le serveur vers lequel le client a été redirigé est indis-
ponible. Peu able donc.
Algorithmes non-déterministes
 Round Robin : ou 'tourniquet' est comme son nom l'indique un algorithme de le tour-
nante : l'équilibrage choisit à chaque instant un serveur dans la le et boucle sur celle-ci.
Certainement le plus performant.
 Least connection : Le répartiteur renvoi les requêtes vers le serveur le moins chargé. Si en
théorie il semble le plus adapté, en réalité dans le cadre du Web dynamique, un serveur
peut être considéré comme chargé alors que les processus sont en attente d'une requête
vers une base de données...
 First Response : Les requêtes clients sont envoyées simultanément à tous les serveurs et le
premier qui répond sera chargé de la connexion. Dicile à mettre en ÷uvre et rarement
employé.
 Least-Load Scheduling : C'est un algorithme qui distribue les requêtes au serveur dont la
charge CPU est la plus faible. Le Load Balancer interroge à intervalles réguliers la charge
de chacun des serveurs, il y a donc une vraie répartition de charge, mais ce procédé est
lent et gourmand en ressources

1.6 Conclusion

Au travers de toutes ces solutions nous avons sélectionné les applications que l'on a mises
en place.

Concernant les équilibreurs :

Il nous faut un système d'équilibrage de charge prenant en compte le fait que les diérentes
machines sont sur un même réseau et n'utilisent que le protocole http. C'est pourquoi nous
avons choisi une solution basé sur LVS car il répond à ces attentes. Pour un déploiement ra-
pide, une automatisation et une surveillance des serveurs nous avons mis en place Ldirectord .
An d'assurer la haute disponibilité des équilibreurs, Heartbeat a été choisi car il supporte
Ldirectord et reste plus léger que Mon vis-à-vis de nos besoins. En eet la surveillance des
ressources systèmes en vue de prévention de défaillance n'est pas déployée. On notera que ces
logiciels font partie intégrante du projet Linux HA (High Availibility). Linux HA est un projet
de clustering visant à fournir un système à haute disponibilité. Ce projet a pour objectif de
réaliser une solution de redondance système et de clustering sous Linux. De plus en plus de
personnes s'intéressent à ce type de système, et Linux HA est vu comme une solution des plus
adéquates. C'est pourquoi les développeurs du projet se sont attelés à essayer de rendre leur
système le plus portable et le plus compatible avec les autres systèmes existants. Ce projet
comprend entre autre Ldirectord et HeartBeart ce qui nous assure une compatibilité totale
entre ceux-ci.

20
Concernant les serveurs :
Pour le contenu statique, la gestion est assurée par Apache de part sa polyvalence, sa docu-
mentation et le fait que nous avons déjà utilisé ce logiciel durant notre formation. Le contenu
dynamique Ruby on Rails est assuré par Mongrel qui est conçu spécialement pour la gestion
de contenu généré par les frameworks basés sur le langage Ruby .

Concernant la base de données :

La réplication de la base de donnée est eectuée par MySQL lui même. La diérence entre
la réplication MySQL DRBD
et est que la réplication MySQL est asynchrone alors que DRBD
est synchrone. Une réplication synchrone, comme DRBD , signie que la copie des informations
se fait en temps réel, les performances des serveurs sont donc aectées. De plus DRBD n'a
pas été créée spéciquement pour faire de la réplication de base de données contrairement à
MySQL réplication. En choisissant cette méthode nous nous assurons donc un fonctionnement
garanti et pleinement compatible car conçu par les créateurs du SGBD.
Heartbeat est de nouveau utilisé pour assurer la haute disponibilité des bases.
Nous avons donc pour la suite du projet mis en place l'architecture suivante :

Fig. 1.5  Schéma général d'équilibrage de charge.

La structure mise en place est constituée d'un équilibreur (Equ1) qui se charge de la
répartition de charge. Un deuxième équilibreur de secours (Equ2) est aussi installé et se charge
de prendre le relais en cas de panne du premier. Ces équilibreurs se partagent une ip virtuelle qui
est utilisée par les clients pour accéder aux serveurs Web. Sont aussi déployés deux serveurs Web

21
(Serv1 et Serv2) partageant une base de données MySQL commune (BD1). La base contenue
sur BD1 est répliquée sur BD2.

22
Chapitre 2

Protocoles de tests
2.1 Inventaire

Les protocoles de mesure de performances sont nombreux sur ce type de déploiement, cette
partie parle donc des diérents tests possibles et ceux que nous avons sélectionnés.
Certains éléments sont indispensables pour eectuer des statistiques dans de bonnes condi-
tions :
 Même matériels et même systèmes d'exploitation pour les tests.
 Conguration des cartes réseaux identiques, ici 100 Megabits.
 On enregistre la charge des serveurs avant toute manipulation via top ou uptime.
 Eectuer plusieurs tests et garder les meilleurs résultats.
 Redémarrer la machine après chaque test.
 Revérication de load.
 Tests en statique sur des chiers HTML/PHP ainsi que chiers dynamiques.
 Test avec ou sans KeepAlive.
Le KeepAlive fait partie intégrante du protocole HTTP1.1 et permet de maintenir une
connexion ouverte après un échange en vue d'un éventuel nouveau transfert. Cela permet
d'éviter des déconnexions/reconnexions multiples ayant pour incidence de ralentir l'accès aux
données.
Le benchmark de solutions est axé sur plusieurs points qui sont les serveurs Web, l'équili-
brage, le SGBD.
Les tests possibles sont très nombreux, il est donc important de sélectionner ceux qui sont les
plus intéressants vis-à-vis de l'implémentation de la plate-forme Ruby On Rails .
Il faut aussi savoir qu'il existe deux approches de montée en charge :
 Montée en charge brusque : il s'agit ici de tester la capacité du serveur à gérer une rapide
montée en charge. Un test consiste donc à envoyer plusieurs requêtes simultanément. Ce
genre de test peut être eectué avec des outils comme Apache Benchmark et nécessite un
nombre de machines permettant de générer un maximum de connexions en un minimum
de temps.
 Simulation réaliste : cette fois-ci la montée en charge se fait progressivement et plus long-
temps. L'utilisation de scénarios de navigations peut être ici très utile. Nous travaillons
sur ce point avec Tsung qui supporte nativement ce type de simulation.
Le test de charge peut être vu de deux façons diérentes : Utilisateur et Administrateur. Le
côté Utilisateur est plus axé sur la livraison rapide du contenu tandis que le côté Administrateur
se préoccupe plus des ressources générales utilisées sur les diérentes machines.
Pour résumer, notre procédure de test est donc :
 Temps de réponse sur des pages statiques.
 Temps de réponse sur des pages PHP .

23
  Temps de réponse sur des pages PHP MySQL
+ .
 Temps de réponse sur des pages Ruby On Rails .
 Temps de réponse sur des pages Ruby On Rails MySQL + .
 Temps de réponse sur une utilisation intensive de la base de données et surveillance de
la base de sauvegarde.
 Ressources utilisées sur les diérents éléments (Équilibreurs, Serveurs, etc.).
Les éléments ci-dessus ayant un comportement diérent en fonction de l'état du système.
Ces tests peuvent donc être eectués avec plusieurs machines hors lignes (déconnectées du
cluster) an d'évaluer concrètement les gains procurés par la mise en place d'une solution
d'équilibrage de charge et de haute disponibilité. Les premiers tests nous permettront d'avoir
une référence en vue de les comparer avec les résultats obtenus sur le temps de réponse de
pages Ruby On Rails .

2.2 Outils de test montée en charge

Le meilleur moyen de voir comment vont se comporter nos applications Web et nos ser-
veurs sous une charge importante est de les tester avec une charge simulée. Il existe plusieurs
outils gratuits sous Linux dédiés à cela. Nous nous sommes interessés uniquement à des outils
maintenus et libres.

2.2.1 Apache Bench

Apache Bench AB ( ) est un outil conçu pour benchmarker des serveurs Apache . Il est conçu
pour donner des statistiques sur la réponse des serveurs à un test de charge ainsi que le
nombre de requêtes par secondes que celui-ci peut traiter. AB gère également la concurrence
(simultanéité des requêtes).

2.2.2 HTTPerf
HTTPerf est un testeur de charge en ligne de commande développé par les laboratoires
HP. Outil similaire à Apache Bench , celui-ci permet en plus de dénir des sessions. Chaque
session correspondant à un utilisateur et son comportement de navigation associé. Dans le
même esprit mais simplié il existe aussi HTTP_Load .

2.2.3 Siege
Siege est similaire à HTTPerf de part sa conguration quasi intégrale via des arguments
passés en ligne de commande. Siege peut lui utiliser des processus concurrents pour envoyer ses
requêtes. Il possède des options un peu plus bas niveau qu'httperf et gère des listes d'URL. Il
est aussi plus simple d'utilisation qu'httperf grâce à ses options plus claires. L'enregistrement
de scénarios de navigation est aussi possible.

2.2.4 Tsung
Tsung marche de manière similaire à Siege mais ore des fonctionnalités supplémentaires
comme la gestion d'utilisateurs diérents (navigateurs, Os, ...), la simulation de sessions et
le retour d'informations dynamiques. De plus celui-ci est basé sur le langage Erlang qui est
un langage orienté concurrentiel. Tsung supporte aussi de nombreux autres protocoles tels
que WebDAV, SOAP, PostgreSQL, MySQL, LDAP et Jabber/XMPP. Tsung possède de plus une
fonctionnalité permettant de créer un cluster de test de charge, un système de génération de
graphiques et rapports en HTML.

24
2.3 Conclusion

Pour nos tests nous avons besoin d'un support HTTP, de la gestion de scénarios mais aussi
d'outils permettant d'obtenir des graphiques exploitables en sortie. De plus le support du
clustering nous permettra de gagner du temps tout en augmentant la abilité de nos mesures.
C'est pourquoi nous allons utiliser en majorité Tsung.

Fig. 2.1  Schéma du cluster de test de charge.

Ci-dessus un exemple de structure envisagée pour l'utilisation de Tsung . Le maître répartira

les tâches sur lui-même ainsi que deux esclaves qui auront pour but de mettre à l'épreuve
la solution d'équilibrage via diérentes requêtes HTTP. Les machines utilisées pour ces tests
vont être nos machines car plus puissantes que les machines mises en place dans la solution
d'équilibrage an de pouvoir saturer les serveurs Web.

25
Chapitre 3

Mise en Pratique
3.1 Environnement d'expérimentation

3.1.1 Environnement matériel

Voici un inventaire des ressources utilisées pour la suite de l'expérimentation.

Équilibreurs
 Nombre de machines : 2
 Processeur : Intel Pentium D (2,8GHz) (dual-core)
 Ram : 1024 Mb
 Disque Dur : 80 Gb

Serveurs Web
 Nombre de machines : 2
 Processeur : Intel Pentium 4 (2,4GHz)
 Ram : 512 + 256 = 768 Mb
 Disque Dur : 80 Gb

Serveurs de Base de données

 Nombre de machines : 2
 Processeur : Intel Pentium 4 (2,8GHz)
 Ram : 512 Mb
 Disque Dur : 80 Gb

3.1.2 Environnement logiciel

Équilibreurs
 Système d'exploitation : Debian Lenny (2.6.26.13)
 Ipvsadm (v1.24)
 Heartbeat (2.1.3)
 Ganglia
 Apache (2.2.9)
 Ldirectord (v1.186-ha-2.1.3)
 Openssh (1 :5.1)

26
Serveurs Web
 Système d'exploitation : Debian Lenny (2.6.26.13)
 Apache2 (2.2.9)
 Mongrel (1.1.5)
 Openssh (1 :5.1)

Serveurs de Base de données

 Système d'exploitation : Debian Etch (2.6.26.13)
 MySQL (5.0.32)
 Openssh (1 :5.1)

3.2 Mise en ÷uvre des Équilibreurs

3.2.1 LVS Nat

L'équilibrage de type NAT via LVS que nous allons mettre en place s'appuie essentiellement
sur ipvsadm qui est l'outil d'administration de LVS mais aussi de Ldirectord qui va s'occuper
de la conguration et la détection de serveurs web down .
Sur le/les équilibreur(s) :
Tout d'abord on installe Ldirectord :

sudo apt-get install ldirectord

Ensuite on crée une interface virtuelle, qui sera utilisée par le client désirant visiter le site
web :

sudo ifconfig eth0 :virt 192.168.2.110

Conguration de Ldirectord :
Les chiers de conguration portent l'extension .cf et se trouvent dans /etc/ha.d/.

Dans ce chier il faut renseigner plusieurs éléments :

virtual=192.168.2.110:80
protocol=tcp
scheduler=rr
real=192.168.10.91:90 masq 1
real=192.168.10.110:80 masq 1
request="test.html"
receive="200"

 Virtual renseigne sur l'adresse ip virtuelle qui sera accédée par le client.
 Protocol permettant de dénir le type de protocole utilisé, ici tcp car http est basé sur
celui-ci.
 Scheduler correspond à l'agorithme utilisé pour l'équilibrage, rr signiant Round Robin.
 real liste les serveurs constituant le pool avec l'adresse ip de chacun d'eux, son type de
forward et le poids. Le type masq (pour masquerade) correspond au LVS de type NAT
et le poids permet de dénir une priorité de l'aiguillage.
 Request déni le nom de la ressource qui sera accedée pour vérier que les serveurs web
sont toujours disponibles.

27
  Receive contient la valeur que devra contenir la ressource pour être considérée comme
disponible.
Sur les serveurs web :

Il y a deux petits points à mettre en place sur les serveurs :

La première consiste à changer la passerelle par defaut actuelle par l'ip de l'équilibreur :

/sbin/route add default gw 192.168.10.221

Ensuite il faut créer à la racine le chier test.html et y mettre comme contenu 200, valeur
dénie dans le chier de conguration.

Lancement :
En mode débug :

/usr/sbin/ldirectord -d /etc/ha.d/www.cf start

En mode normal :

/etc/init.d/ldirectord start

3.2.2 Heartbeat
La haute disponibilité va être assurée par Heartbeat , celui-ci doit être installé sur chacun
des équilibreurs. On installe Heartbeat :

sudo apt-get install heartbeat

Conguration : Il y a 3 chiers à congurer pour qu' Heartbeat fonctionne comme désiré :
/etc/ha.d/ha.cf :

bcast eth0 <= Interface utilisée pour le battement

debugfile /var/log/ha-debug <= fichier de débug
logfile /var/log/ha-log <= fichier de log
logfacility local0 <= Log utilisant syslog-ng
keepalive 2 <= temps (en s) entre chaque battement
deadtime 10 <= temps au bout du quel on considère une machine morte
warntime 6 <= on considère que la machine met du temps à répondre après 6s
initdead 60 <= temps avant de lancer le premier battement au démarrage
udpport 694 <= port utilisé pour l'envoi du battement
node equ1 <= déclaration des machines devant être surveillées
node equ2
auto_failback on <= réintègre une machine qui repasse en état de marche
/etc/had.d/haresources :

equ1 Ipaddr :: 192.168.10.221

| {z } | {z }
Node Ip virt à attribuer

/etc/ha.d/authkeys :

28
 auth 1 <= on utilise la méthode d'authentification 1
1 sha1 CleSecrete <= Numéro de méthode, Type de cryptage et clé
Ensuite il ne nous reste plus qu'à lancer Heartbeat sur les machines :

/etc/init.d/heartbeat start

3.2.3 Monitoring
An d'exploiter les résultats, il nous est nécessaire de surveiller et tracer des graphiques.
MRTG RRDTOOL
et sont les leaders dans ce domaine. Néanmoins la mise en place/congu-
ration n'est pas rapide. C'est pourquoi des outils plus spéciques doivent être utilisés.
Après plusieurs recherches Ganglia semble tout indiqué. Après quelques tests il a été décidé
de choisir Gangliade part ses nombreux graphiques fournis mais aussi le détail des événements
par heure (sur munin on ne peut zoomer au delà des jours).

Installation/Conguration
Ganglia se décompose en deux parties, un serveur et un client. Le serveur est à installer
sur chaque machine à surveiller au travers de la commande :

apt-get install gmetad

Puis il faut congurer divers éléments dans le chier /etc/gmetad.conf :
Les serveurs à questionner :

data_source "Mon Cluster" localhost 192.168.10.222 192.168.10.91

192.168.10.110
Le nom de la grid :

gridname ASRALL
Il est ensuite nécessaire d'installer un client qui va s'occuper de récupérer toutes les infor-
mations sur les diérents serveurs :

apt-get install ganglia-monitor

On attribue le nom de la grid via le chier de conguration /etc/gmond.conf :

Name ASRALL
Ganglia est packagé par défaut mais ne contient pas le frontend Web, pour cela il sut
de télécharger le tar.gz sur le site ociel et copier le répertoire web à l'emplacement du
serveur web.

3.3 Mise en ÷uvre des serveurs Web

Pour la suite, nous allons installer sur chaque serveur, Apache Mongrel
et . Dans cette
conguration, Mongrel ne sera chargé que du contenu dynamique Ruby On Rails , le contenu
statique étant mieux géré par des serveurs Web tels que Apache Nginx Lighttpd
, ou .

29
3.3.1 Développement d'une application ROR simple
 Installer Ruby :
 sudo apt-get install ruby-full build-essential → Ruby
 sudo apt-get install rails → Ruby on Rails
 sudo apt-get install mysqlclient15-dev → Rails/Mysql
 sudo gem install mysql → Rails/Mysql
 Se placer dans le répertoire où l'on souhaite développer l'application.
 rails myrailsapp -d mysql
 Démarrage du serveur de développement (Webrick) : myrailsapp/script/server
À ce stade, on se retrouve avec la page par défaut de ROR si l'on saisit l'URL suivante dans
un navigateur http://localhost:3000.

3.3.2 Installation d'un serveur Web Apache + Mongrel

Installation :

sudo apt-get install apache2 mongrel mongrel_cluster

Activation des modules nécessaires pour Apache :

sudo a2enmod proxy deflate proxy_balancer rewrite mem_cache proxy_http

Création du VirtualHost :

nano /etc/apache2/sites-available/001-railstest
Contenu du VirtualHost :

<VirtualHost *:80>
ServerName railstest.com
DocumentRoot /var/www/rails/apps/public/
ProxyPass / http://127.0.0.1:3000/
ProxyPassReverse / http://127.0.0.1:3000
ProxyPreserveHost on
#Fix for Apache bug 39499
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
# Ne pas rediriger les images, les CSS
# et les Javascripts vers Mongrel
ProxyPass /images !
ProxyPass /stylesheets !
ProxyPass /javascripts !
# Et précisons le path où se trouve
# les images, les CSS et les javascripts
Alias /images /var/www/rails/apps/public/images
Alias /stylesheets /var/www/rails/apps/public/stylesheets
Alias /javascripts /var/www/rails/apps/public/javascripts
CustomLog /var/www/rails/apps/log/access
"%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-Agent}i\""
ErrorLog /var/www/rails/apps/log/error
</VirtualHost>
Activation du VirtualHost créé et désactivation de celui présent par défaut :

30
 sudo a2ensite 001-railstest

sudo a2dissite 000-default

Conguration du module proxy d' Apache :

sudo nano /etc/apache2/mods-enabled/proxy.conf

Il faut commenter la ligne Deny from all pour la remplacer par Allow from 127.0.0.1
Relancer Apache :

sudo /etc/init.d/apache2 restart

Lancer Mongrel :
Se placer dans le répertoire de l'application (ici /var/www/rails) puis exécuter les commandes
suivantes :

mongrel_rails cluster : :configure -e production -p 3000 -N 3 -c

/var/www/rails/

mongrel_rails cluster::start

3.3.3 Mise en ÷uvre des Bases Mysql

Conguration du maître :

Il faut tout d'abord éditer le chier /etc/mysql/my.cnf. La première chose à congurer

est l'écoute sur le réseau en plus de l'hôte local :

#skip-networking
#bind-address = 127.0.0.1

Maintenant il est nécessaire d'indiquer à MySQL pour quelle base les logs seront écrits (ces
logs seront utilisés par le serveur esclave an de détecter des changements). On lui indique le
chemin des log et nous spécions que le serveur jouera le rôle de maître :

log-bin = /var/log/mysql/mysql-bin.log
binlog-do-db=example
server-id=1
Ensuite on redémarre MySQL :

/etc/init.d/mysql restart
Nous allons maintenant créer un utilisateur avec les droits de réplications via MySQL
mysql -u root -p
On attribue les droits :

GRANT REPLICATION SLAVE ON *.* TO 'serv_esclace'@'%' IDENTIFIED BY

'<motdepass>' ;FLUSH PRIVILEGES ;
Nous allons maintenant bloquer la table qui nous intéresse :

31
USE example;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
Ce qui devrait nous acher :

+---------------+----------+--------------+------------------+
| File | Position | Binlog_do_db | Binlog_ignore_db |
+---------------+----------+--------------+------------------+
| mysql-bin.006 | 183 | example | |
+---------------+----------+--------------+------------------+
1 row in set (0.00 sec)

Il est nécessaire de garder ces informations pour le serveur esclave.

On crée maintenant un dump de la table :

mysqldump -u root -p opt example > example.sql

Une fois le dump établi nous pouvons débloquer la base :

mysql -u root -p
Enter password:
UNLOCK TABLES;
quit;
La conguration du maître est désormais terminée.
Conguration de l'esclave :
On crée tout d'abord la base à répliquer :

mysql -u root -p
Enter password:
CREATE DATABASE example;
quit;
On importe ensuite la base précédemment copiée :

mysql -u root -p example < example.sql

Il faut maintenant indiquer à MySQL 192.168.0.100
qu'il sera l'esclave, que le maître est
et que la base se nomme example. Pour cela on modie le chier /etc/mysql/my.cnf :
server-id=2
master-host=192.168.0.100
master-user=esclave
master-password=motdepasse
master-connect-retry=60
replicate-do-db=example
On redémarre MySQL :

/etc/init.d/mysql restart
Ensuite on lance MySQL pour les derniers réglages :

mysql -u root -p

32
On stoppe le mode esclave :

SLAVE STOP ;

CHANGE MASTER TO MASTER_HOST='192.168.0.100',

MASTER_USER='esclave',
MASTER_PASSWORD='motdepass',
MASTER_LOG_FILE='mysql-bin.006',
MASTER_LOG_POS=183 ;

 MASTER_HOST Ip du maître
 MASTER_USER nom de l'utilisateur avec les droits de réplication.
 MASTER_PASSWORD mot de passe de l'utilisateur.
 MASTER_LOG_FILE nom du chier de log récupéré précédement.
 MASTER_LOG_POS position dans le log actuel.
On relance le mode esclave :

SLAVE START ;
La réplication est désormais eective.

3.4 Installation de Tsung

Tsung est directement packagé sous Debian, l'installation s'eectue donc très simplement :

sudo apt-get install tsung

La conguration de Tsung est mise en place au travers d'un chier xml que nous verrons lors
des tests.

3.5 Tests et relevés

3.5.1 Conguration du test de charge

Nous allons durant ces tests mettre en avant les bénéces d'un équilibrage de charge. La
montée en charge se fera progressivement et non brutalement dû au manque de matériels et le
manque d'intérêt réel vis à vis des tests que nous voulons eectuer.
Les tests de charges vont être fait avec Tsung et certains paramètres doivent être dénis.
La conguration se fait entièrement dans le chier tsung.xml. La première étape consiste à
ajouter les hôtes qui vont envoyer les requêtes :

<clients>
<client host="localhost"> <ip value="192.168.2.27"></ip></client>
<client host="jul"> <ip value="192.168.2.73"></ip></client>
<client host="gat"><ip value="192.168.2.154"></ip></client>
</clients>
On renseigne ensuite l'adresse du serveur à benchmarker :

<servers>
<server host="192.168.2.110" port="80" type="tcp"></server>
</servers>

33
C'est cette adresse qu'il faudra changer pour les tests avec/sans équilibreurs. Il faut maintenant
indiquer la fréquence d'arrivée des utilisateurs et la durée du test :

<load>
<arrivalphase phase="1" duration="3" unit="minute">
<users interarrival="0.05" unit="second"></users>
</arrivalphase>
</load>
Notre test va durer 3 minutes avec 20 nouveaux arrivants toutes les secondes et un maintient
de connexion de 8 secondes. Il nous faut maintenant dénir l'URL de test :

<request>
<http url="/" method="GET" version="1.1"></http>
</request>
<thinktime value="8"/>
Le thinktime présent ici correspond au temps passé sur la page, impliquant un maintient de
connexion. Maintenant que tout est conguré il sut de lancer tsung :

tsung start
Une fois le test généré il sut d'utiliser le script fourni par Tsung pour générer un rapport :

/usr/lib/tsung/bin/tsung_stats.pl
Toutes les valeurs dénies précedemment ont été choisies suite à de nombreux test et un
étalonnage via la réaction de l'application ROR mise en place sur les serveurs Web.

3.5.2 Point de vue du Client

Toutes les données présentées ici sont issues d'un seul des 2 serveurs du cluster, toujours le
même an de bien remarquer les eets de l'équilibrage. Deux grands points vont être relevés :
le nombre de connexions simultanées et le taux de réponses correctes (code HTTP 200).

HTML
Pour commencer nos tests, nous allons utiliser Tsung sur un serveur sans équilibreur avec
une page statique HTML ("It works.").

34
 Fig. 3.1  Nombre d'utilisateurs connectés simultanément

Ce graphique montre que le nombre d'utilisateurs connectés simultanément est constant,

on en déduit donc que sur une page statique, le serveur répond très bien.

Fig. 3.2  Temps de réponse

Ce graphique montre que le temps de réponse du serveur Web pour chaque requête est
lui aussi constant. Il y a un pic au début, c'est le temps qu'Apache fork les processus an de
répondre aux requêtes. Au travers de ces deux graphiques on se rend compte que le serveur
n'éprouve aucune dicultés à répondre aux requêtes qui lui sont adressées.

PHP sans BDD

Nous étudions maintenant la réaction d'un des 2 serveurs du cluster sans/avec équilibrage
sur une page dynamique. Pour ce faire, nous utilisons sur les serveurs Web, un simple phpinfo.

35
 Fig. 3.3  Nombre d'utilisateurs connectés simultanément

Fig. 3.4  Temps de réponse

Les performances relevés ci-dessus ont été obtenues sans équilibrage. Celles-ci étant très
similaires avec l'équilibrage, il n'est pas nécessaire de nous y attarder. On constate que comme
avec les tests de page HTML statique le serveur n'éprouve pas de problème pour gérer les requêtes.

PHP avec BDD

Nous passons maintenant à un test de charge sur une page PHP ayant un accès à une base
de données MySQL . Nous utilisons ici un CMS déployé sur ces serveurs an d'obtenir un
point de comparaison pour l'application ROR . Voici donc côte-à-côte les résultats sans et avec
équilibrage de charge :

36
 Fig. 3.5  Nombre d'utilisateurs connectés simultanément sans eq.

Fig. 3.6  Nombre d'utilisateurs connectés simultanément avec eq.

On remarque qu'avec un équilibreur les connexions sont gérées de façon plus souple que
sans.

37
 Fig. 3.7  Temps de réponse sans eq.

Fig. 3.8  Temps de réponse avec eq.

La diérence est ici beaucoup plus agrante qu'avec le nombre d'utilisateurs simultanés.
En eet, la moyenne du temps de réponse est beaucoup plus faible avec l'équilibreur. Ici le
gain est donc considérable et favorisera une navigation plus rapide pour le client.

38
Ruby
Maintenant que nous disposons de notre point de comparaison en PHP , passons au test
de charge de l'application ROR. Voici donc toujours dans le même ordre, les résultats du test
sans puis avec équilibrage de charge.

Fig. 3.9  Nombre d'utilisateurs connectés simultanément sans eq.

Fig. 3.10  Nombre d'utilisateurs connectés simultanément avec eq.

Ici, on s'aperçoit que lorsque l'équilibreur n'est pas mis en place, le nombre d'utilisateurs
grimpe à 350, le serveur n'arrive pas à gérer toutes les connexions et les mets en attente. Dans
le cas où l'équilibrage est mis en place, le serveur arrive facilement à gérer les utilisateurs
connectés avec une constante de 200 utilisateurs simultanés.

39
 Fig. 3.11  Temps de réponse sans eq.

Fig. 3.12  Temps de réponse avec eq.

Nous pouvons voir, d'après les résultats présentés précedemment et notamment pour le
test de charge de l'application ROR
, que notre équilibrage de charge fonctionne et permet des
gains de performance non négligeables.

3.5.3 Point de vue de l'Administrateur

Du côté de l'administrateur, ce qui nous intéresse, ce sont les réactions des serveurs lors de
ces diérents tests. Voici donc les diverses caractéristiques que nous avons relevés.

40
41
Fig. 3.13  Évolution de la charge CPU du serveur surveillé
42
Fig. 3.14  Évolution de l'utilisation mémoire du serveur surveillé
 En ce qui concerne le premier graphique, on voit bien par exemple que lors des tests de
montées de charges sur une page dynamique en PHP sans équilibrage (3), la charge CPU est
montée jusqu'à 85%. Si l'équilibrage est actif, la charge CPU est 25% moins importante. Le
test est encore plus représentatif avec l'application ROR car on passe d'une charge de prati-
quement 100% a à peine 45% de charge. Le gain apporté ici par l'équilibrage est non négligeable.

Le dernier graphique représente l'utilisation de la mémoire. Ici par exemple avec l'appli-
cation PHP (3) sans équilibrage, il y a 500Mo d'utilisé pour répondre aux requêtes alors que
lorsque l'équilibrage est mis en place, on gagne environ 250Mo en passant à 250Mo. En ce qui
concerne l'application ROR (5), on passe d'environ 180Mo sans équilibrage à 140Mo avec la
mise en place de l'équilibrage (6).

Nous pouvons voir sur ces résultats que les ressources nécessaires sans équilibrage de charge
peuvent vite surcharger le serveur tandis qu'avec l'équilibrage, celles-ci restent tout à fait
disponible.

3.6 Conclusion

Étant donné les diérents résultats présentés dans cette partie, nous pouvons en conclure
que notre équilibrage fonctionne parfaitement puisqu'il permet aux clients d'accéder au site
plus rapidement en cas d'encombrement tout en réduisant les ressources nécessaires sur les
diverses machines du cluster. De plus la solution de haute disponibilité nous assure une sécurité
supplémentaire en cas de défaillance au niveau de l'équilibreur, d'un serveur ou de la base de
données.

43
Chapitre 4

Divers
4.1 Bibliographie

LVS et Haute-disponibilité : http ://www.linuxvirtualserver.org/

Exemples de Haute-disponibilité : http ://www.haute-disponibilite.net/

Tsung : http ://www.process-one.net/en/tsung/

Linux Magazine 97 : Cluster haute-disponibilité avec équilibrage de charge

Ruby On Rails : http ://rubyonrails.org/

Diérents tests d'apache mongrel

, : http ://blog.kovyrin.net/

Réplication DRBD : http ://2005.jres.org/paper/91.pdf

Réplication MySQL : http ://dev.mysql.com/doc/refman/5.0/fr/replication.html

4.2 Compte rendu projet Tutoré

Une bonne conduite de projet n'est rien sans un planning et une bonne répartition des
tâches. Bien qu'une très grande partie ait été faite entièrement en commun, certains éléments
ont été attribués séparément.

4.2.1 Nous
Jachniewicz Rémi
Durée approximative de travail : Environ 140 heures.
Tâches :
 Mise en place SVN
 Recherches sur équilibrage de charge et Haute Disponibilité.
 Recherches/Déploiement LVS simple.
 Recherches/Déploiement LVS Ldirectord
+ .
 Recherches/Déploiement Heartbeat
.
 Recherches d'outils de monitoring.

44
  Recherches/Déploiement Munin .
 Recherches/Déploiement Ganglia .
 Protocoles de tests.
 Gestion des Tests avec Tsung .
 Rapport (en parallèle avec le reste).

Gaspard Gatien
Ces tâches sont répertoriés par groupe et non chronologiquement et représentent un travail
total d'environ 140 heures.
 Recherche de documentation concernant la haute disponibilité et l'équilibrage de charge
sous Linux.
 Étude des divers documents trouvés et isolation des éléments intéressants.
 Recherches sur la mise en oeuvre de Mongrel sur diérents serveurs Web ( Apache Nginx
, ,
...)
 Développement d'une application ROR simple an de tester le déploiement sur un serveur
avec Mongrel .
 Interfaçage de Mongrel avec Apache .
 Recherche d'outils de test de charge pour serveurs Web.
 Rédaction du rapport :
 Introductions et liens entre diverses parties.
 Liste non exhaustive de logiciel pour l'équilibrage de charge.
 Principe et fonctionnement de LVS.
 Conclusion des diverses parties de l'état de l'art.
 Rédaction de la mise en oeuvre de Mongrel et du déploiement d'une application ROR.
 Correction orthographique.

Lacava Julien
Durée approximative de travail : Environ 125 heures.

 Recherche de documentation concernant la haute disponibilité et l'équilibrage de charge

sous Linux.
 Recherche et comparatif des diérents serveurs Web.
 Installation de base des serveurs ( Debian MySQL Apache
, , ) avec Gatien.
 Recherche et début de déploiement de DRBD au vue d'une éventuelle mise en place
(abandonné au prot de MysqlReplication).
 Recherche et déploiement de la réplication de la base de données avec l'aide de Rémi.
 Déploiement de l'application PHP .
 Correction orthographique.

Meslard Vincent
Durée approximative de travail : 132 heures.

 Recherche de documentation concernant la haute disponibilité et l'équilibrage de charge

sous Linux.
 Tests de solutions non retenues :
 serveur web nginx,
 communication entre le serveur et Rails via fastCGI,
 utilisation de la virtualisation.

45
  Application Rails de test.
 Recherche et déploiement d'applications ROR .
 Correction orthographique et syntaxique.
 Uniformisation du rapport.

4.2.2 Statistiques
Tout le travail a été eectué sur un SVN , c'est pourquoi il peut être intéressant de regarder
quelques statistiques.

Fig. 4.1  Nombre de lignes Rapport

On remarque que la progression a été plutôt lente au départ car notre travail portait en
grande partie sur la recherche d'informations et d'avis avant toute rédaction.

Fig. 4.2  Activité dans la semaine

46
 On remarque que la plupart des modications se font le vendredi et le lundi en eet les
réunions avec notre tuteur se tenaient en partie ces jours. De plus ces journées étaient entière-
ment dédiées au projet.

Fig. 4.3  Activité dans la journée

Les modications se font très souvent le matin au vu de ces statistiques. En eet la théorie
a souvent été étudiée le matin et appliquée dans l'après-midi.

4.2.3 Remerciements
Philippe Dosch pour nous avoir encadré tout au long du projet.

47