Équilibrage de Charge et Haute Disponibilité

LP ASRALL
Équilibrage de Charge et Haute Disponibilité
pour applications Web Ruby On Rails
Auteurs :
Gaspard
Jachniewicz
Lacava
Meslard
Gatien
Rémi
Julien
Vincent
,
,
,
22 avril 2009
Table des matières
1 Étude
2
1.1
Le projet
1.2
Équilibrage de charge et haute disponibilité
1.3
1.4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
. . . . . . . . . . . . . . . . . . . .
3
1.2.1
Équilibrage de charge
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2.2
Haute disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
1.3.4
Monitoring
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.3.5
Conclusion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
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
1.4.3
Conclusion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . .
15
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Mise en Pratique
3.1
3.2
3.3
3.4
25
Environnement d'expérimentation . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.1.1
Environnement matériel
25
3.1.2
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Mise en ÷uvre des Équilibreurs . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.2.1
LVS Nat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.2.2
Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2.3
Monitoring
28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
Installation de Tsung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
1
3.5
3.6
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
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
on Rails
Ruby
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
Ruby
Ruby on Rails
projet.
Ruby on Rails
sera donc indispensable pour ce
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
au langage
un framework puissant, exploitant au mieux ses nombreuses facettes.
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 aujourd'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
travailler avec le serveur web écrit en
Ruby WEBrick
:
Ruby on Rails
peut se permettre de
. 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
apache lighttpd
Nginx
Mongrel
,
,
serveurs Web, on peut utiliser
,
,
ou
et
ou encore
3
avec
.
. Pour les
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.
load balancing
Le principe de base de l'équilibrage de charge (
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.
DNS
L'équilibrage de charge utilise essentiellement 2 techniques qui sont le
proxy.
et le reverse-
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 redondance 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.
la conguration de
DNS. Basé sur
serveur DNS permet
Dans cette solution le répartiteur de charge est le serveur
bind
(démon le plus utilisé sous Linux pour le
DNS),
le
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
LVS
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.
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.
suite (en 1.4).
LVS
est plus détaillé par la
Apache - mod_proxy_balancer
À partir de
apache 2.1 2
mod_proxy_balancer, il est possible de
HTTP, FTP et AJP13 (Apache JServ Protocol
, en utilisant le module
faire de l'équilibrage de charge pour les protocoles
- 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 :
Weighted Trac Counting Pending Request Counting
et
.
Request Counting
,
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
Inconvénients :
protocoles
HTTP, FTP
et
AJP13
apache
).
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
serveurs et en utilisant le protocole
Alors que le monitorage de
pen
VRRP3
tous les protocoles basés sur
TCP
penbw
(y compris
possibilité d'utiliser VRRP,
1
2
3
lui-même en le déployant sur plusieurs
se limite à la couche transport, il est possible de faire du
monitorage au niveau applicatif en utilisant
Avantages :
pen
pour décider lequel est actif.
http://www.linuxvirtualserver.org/
http://httpd.apache.org/
Virtual Router Redundancy Protocol - RFC 3768
5
.
HTTPS),
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 seconde,
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
balance
existe en deux versions, une gratuite (
Avantages :
) et une commerciale (
balanceng 6
).
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/
http://www.inlab.de/balance.html
6
http://www.inlab.de/balanceng/
7
http://nginx.net/
5
6
Nginx
est un front-end populaire pour les applications
de charge mis en place est de type Round-Robin pondéré.
Rails PHP
et
. Aussi, l'équilibrage
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 ociellement),
protocoles
HTTP
Inconvénients :
et
HTTPS.
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/
http://www.mandriva.com/clustering
10
http://www.apsis.ch/pound/
9
7
implique que les premiers prennent en considération l'ensemble des protocoles
tels que
HTTP(S), FTP, SMTP / POP3 / IMAP, . . .
11 utilisant
TCP,
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
9
Serveur web,
BalanceNG
GPL
GPL
Reverse Proxy
Load Balancer
HealthCheck/Failover
Pound
LVS(IPVS)
KeepAlived
GPL
GPL
GPL
type BSD
Clic
reverse proxy
Serveur web, Reverse Proxy
GPL
shareware
GPL
GPL
GPL
apache
L
en
ic
ce
Oscar
Nginx
UltraMonkey
?
Load Balancer
Balance
Load Balancer
Pen
reverse proxy
HAProxy
Apache
yp
T
e
Récapitulatif des fonctionnalités
TLS/SSL
?
X
X
?
X
-
X
X
Sessions
?
X
X
-
?
X
-
X
?
X
X
X
?
-
X
-
?
X
-
X
?
X
X
Cache
ou
S
O
I
Application
Réseau/Transport
Application
Réseau/Transport
Réseau/Transport
Réseau/Transport
Application12
Application
Application
Application
Application
Application
C
ch
e
é
it
il
Unix
Unix
Unix
Unix
Unix
Unix
Unix
Unix
Unix
Unix, Windows
Unix
Unix, Windows
or
P
b
ta
nu
2009
2004
2009
2003
2009
janv-2009
2005
Février 09
Avril 08
Mai 2008
Novembre 08
décembre 2008
a
M
te
in
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,
LVS
qui est un reverse-proxy et
puisque ceux-ci sont maintenus, stables et éprouvés.
POUND
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
Single Point of Failure
les SPOF (
). 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 battement 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
Keepalived
est utilisé pour surveiller les serveurs au sein d'un cluster en utilisant
LVS
.
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
Ultramonkey
fait partie de celles-ci.
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 :
LVS
Heartbeat
travaille sur la couche transport du modèle OSI avec
,
facilement extensible pour un grand nombre d'IP basées sur des services virtuels,
haute disponibilité oerte par le protocole de
monitoring des services via ldirectord,
,
ore une documentation assez complète sur le déploiement de solutions de haute disponibilité 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 (
l'application ne tourne plus sur la machine active.
Heartbeat
) si
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 modications 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énements 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
12
Outil de monitoring
Mon
Outil de replication réseau
Système de clustering
KeepAlived
MySQL Replication
Outil de monitoring
Système de clustering
HeartBeat
Outil de replication réseau
Package de solution
e
Ldirectord
Drdb
UltraMonkey
yp
T
Récapitulatif des fonctionnalités
Multiplateforme
Unix
Unix
Unix
Unix
Unix
Unix
é
it
il
b
ta
or
P
Janvier 2009
Juin 2007
Mars 2009
Février 2009
Février 2009
Février 2009
Juillet 2007
a
M
nu
te
n
i
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
HeartDRBD MySQL Replication
HeartBeat Ldirectord
de notre projet, ces solutions peuvent toutes convenir. Ainsi, un choix devait être fait (
Beat Ldirectord Keepalived
MySQL Replication
+
ou
pour la gestion du cluster,
ou
pour les bases de données). Les solutions choisies au nal sont :
que
1.3.3 Serveur Web
An de mettre en place une application
du code
ruby
ruby
+
ainsi
, il nous faut un serveur web capable d'exécuter
. Nous allons présenter ici une liste des serveurs susceptibles de nous intéresser.
Apache
Apache HTTP Server
, souvent appelé
Software Foundation. C'est le serveur
Apache
HTTP
, est un serveur
HTTP
produit par l'Apache
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
,
d'URL, etc.
,
et
, serveur proxy, Common Gateway Interface, réécriture
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
même niveau.
Nginx
, il n'y a pas de notion de
ServerName
ni de
ServerAlias.
Tout est au
Lighttpd
Lighttp
Apache
est un serveur web qui supporte un grand nombre de fonctionnalités comparables à
celles d'
, 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
siblement les mêmes, l'un en utilisant
Apache
Mongrel
conguration d'
Apache
avec
Mongrel
Nginx
et
Apache
sont sen-
, l'autre en utilisant FastCGI, d'autre part, la
est plus simple que celle ne
Nginx
. Nous avons donc décidé de tester
pour 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 partie 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
LVS
heartbeat
).
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'architecture 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'accé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 importantes 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 destination 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épartiteur) 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 paquet 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 éloigné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
peine que le client se connecte directement à un des serveurs.
18
ARP,
sous
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
LVS - Direct
équilibrage de charge avec haute disponibilité est la méthode de routage 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 solutions 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 paramètres. La redirection peut donc ne jamais être la même. Par exemple,
Least Connection
non-déterministe car il va rediriger le client en fonction de la dernière connexion.
19
est
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 redirigeant 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 indisponible. Peu able donc.
Algorithmes non-déterministes
Round Robin : ou 'tourniquet' est comme son nom l'indique un algorithme de le tournante : 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
avons choisi une solution basé sur
LVS
http.
C'est pourquoi nous
car il répond à ces attentes. Pour un déploiement ra-
pide, une automatisation et une surveillance des serveurs nous avons mis en place
An d'assurer la haute disponibilité des équilibreurs,
Ldirectord
et reste plus léger que
Mon
Heartbeat
Ldirectord
.
a été choisi car il supporte
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
entre ceux-ci.
Ldirectord
et
HeartBeart
20
ce qui nous assure une compatibilité totale
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
Concernant la base de données :
la réplication
MySQL DRBD
et
.
MySQL
MySQL
DRBD
La réplication de la base de donnée est eectuée par
est que la réplication
est synchrone. Une réplication synchrone, comme
Ruby
lui même. La diérence entre
DRBD
DRBD
est asynchrone alors que
, signie que la copie des informations
se fait en temps réel, les performances des serveurs sont donc aectées. De plus
n'a
pas été créée spéciquement pour faire de la réplication de base de données contrairement à
MySQL
Heartbeat
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.
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
sur BD1 est répliquée sur BD2.
22
MySQL
commune (BD1). La base contenue
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 conditions :
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'équilibrage, 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 longtemps. 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
Temps de réponse sur des pages
Temps de réponse sur des pages
PHP MySQL
Ruby On Rails
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
2.2
Ruby On Rails
.
Outils de test montée en charge
Le meilleur moyen de voir comment vont se comporter nos applications Web et nos serveurs 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
AB
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.
(simultanéité des requêtes).
gère également la concurrence
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
2.2.3 Siege
Siege
est similaire à
HTTPerf
Siege
passés en ligne de commande.
HTTP_Load
.
de part sa conguration quasi intégrale via des arguments
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
un langage orienté concurrentiel.
que
Tsung
Erlang
qui est
supporte aussi de nombreux autres protocoles tels
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
Heartbeat
Ganglia
Apache
Ldirectord
Openssh
(v1.24)
(2.1.3)
(2.2.9)
(v1.186-ha-2.1.3)
(1 :5.1)
26
Serveurs Web
Système d'exploitation : Debian Lenny (2.6.26.13)
Apache2
Mongrel
Openssh
(2.2.9)
(1.1.5)
(1 :5.1)
Serveurs de Base de données
Système d'exploitation : Debian Etch (2.6.26.13)
3.2
MySQL
Openssh
(5.0.32)
(1 :5.1)
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
down
mais aussi de
de la conguration et la détection de serveurs web
Sur le/les équilibreur(s) :
Tout d'abord on installe
Ldirectord
.
Ldirectord
qui va s'occuper
:
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
et le poids permet de dénir une priorité de l'aiguillage.
Request
LVS
de type NAT
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
des équilibreurs. On installe
Heartbeat
:
Heartbeat
, celui-ci doit être installé sur chacun
sudo apt-get install heartbeat
Heartbeat
Conguration : Il y a 3 chiers à congurer pour qu'
/etc/ha.d/ha.cf
bcast
debugfile
logfile
logfacility
keepalive
deadtime
warntime
initdead
udpport
node
node
auto_failback
:
fonctionne comme désiré :
eth0 <= Interface utilisée pour le battement
/var/log/ha-debug <= fichier de débug
/var/log/ha-log <= fichier de log
local0 <= Log utilisant syslog-ng
2 <= temps (en s) entre chaque battement
10 <= temps au bout du quel on considère une machine morte
6 <= on considère que la machine met du temps à répondre après 6s
60 <= temps avant de lancer le premier battement au démarrage
694 <= port utilisé pour l'envoi du battement
equ1 <= déclaration des machines devant être surveillées
equ2
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
de choisir
Ganglia
munin
Ganglia
semble tout indiqué. Après quelques tests il a été décidé
de part ses nombreux graphiques fournis mais aussi le détail des événements
par heure (sur
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 informations 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
Apache Mongrel
Ruby On Rails
Apache Nginx Lighttpd
Pour la suite, nous allons installer sur chaque serveur,
conguration,
Mongrel
et
. Dans cette
ne sera chargé que du contenu dynamique
statique étant mieux géré par des serveurs Web tels que
29
,
, le contenu
ou
.
3.3.1 Développement d'une application ROR simple
Installer
sudo
sudo
sudo
sudo
Ruby
:
Ruby
Ruby on Rails
Rails/Mysql
Rails/Mysql
apt-get install ruby-full build-essential →
apt-get install rails →
apt-get install mysqlclient15-dev →
gem install 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) :
À ce stade, on se retrouve avec la page par défaut de
un navigateur
http://localhost:3000.
ROR
myrailsapp/script/server
si l'on saisit l'URL suivante dans
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
Relancer
Apache
Deny from all
pour la remplacer par
Allow from 127.0.0.1
:
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 à
et que la base se nomme
MySQL
example.
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
192.168.0.100
/etc/mysql/my.cnf :
qu'il sera l'esclave, que le maître est
Pour cela on modie le chier
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
des tests.
3.5
Tsung
est mise en place au travers d'un chier xml que nous verrons lors
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
HTML
Pour commencer nos tests, nous allons utiliser
une page statique
HTML
("It works.").
34
Tsung
HTTP
200).
sur un serveur sans équilibreur avec
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
de données
MySQL
PHP
ayant un accès à une base
. Nous utilisons ici un CMS déployé sur ces serveurs an d'obtenir un
point de comparaison pour l'application
équilibrage de charge :
ROR
. Voici donc côte-à-côte les résultats sans et avec
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
de charge de l'application
ROR
PHP
, passons au test
. 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'application
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/
apache mongrel
DRBD
MySQL
Diérents tests d'
Réplication
Réplication
4.2
,
: http ://blog.kovyrin.net/
: http ://2005.jres.org/paper/91.pdf
: http ://dev.mysql.com/doc/refman/5.0/fr/replication.html
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
Recherches/Déploiement
Recherches/Déploiement
LVS
LVS Ldirectord
Heartbeat
simple.
+
.
Recherches d'outils de monitoring.
44
.
Munin
Ganglia
Tsung
Recherches/Déploiement
.
Recherches/Déploiement
Protocoles de tests.
Gestion des Tests avec
.
.
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.
Mongrel
ROR
Apache
Recherches sur la mise en oeuvre de
...)
Développement d'une application
avec
Mongrel
.
Interfaçage de
Mongrel
avec
Apache Nginx
sur diérents serveurs Web (
,
,
simple an de tester le déploiement sur un serveur
.
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
Correction orthographique.
Mongrel
et du déploiement d'une application ROR.
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
DRBD
,
,
Recherche et début de déploiement de
) avec Gatien.
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
Correction orthographique.
PHP
.
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
utilisation de la virtualisation.
Rails
45
via fastCGI,
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
quelques statistiques.
SVN
, c'est pourquoi il peut être intéressant de regarder
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èrement 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