LP ASRALL

Équilibrage de Charge et Haute Disponibilité

pour applications Web Ruby On Rails

Auteurs :

Gatien Gaspard,

Rémi Jachniewicz,

Julien Lacava,

Vincent Meslard

22 avril 2009

Table des matières

1 Étude 21.1 Le projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Équilibrage de charge et haute disponibilité . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Équilibrage de charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.2 Haute disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 État de l'art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3.1 Répartition de charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3.2 Haute Disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.3 Serveur Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.4 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4 Principe et fonctionnement de LVS . . . . . . . . . . . . . . . . . . . . . . . . . 141.4.1 Présentation de LVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4.2 Méthodes de transmission pour la répartition de charge . . . . . . . . . 151.4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.5 Algorithmes des équilibreurs de charge . . . . . . . . . . . . . . . . . . . . . . . 181.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 Protocoles de tests 222.1 Inventaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2 Outils de test montée en charge . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.1 Apache Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.2 HTTPerf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.3 Siege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.4 Tsung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Mise en Pratique 253.1 Environnement d'expérimentation . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Mise en ÷uvre des Équilibreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.1 LVS Nat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.2 Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.3 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Mise en ÷uvre des serveurs Web . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.1 Développement d'une application ROR simple . . . . . . . . . . . . . . . 293.3.2 Installation d'un serveur Web Apache + Mongrel . . . . . . . . . . . . . 293.3.3 Mise en ÷uvre des Bases Mysql . . . . . . . . . . . . . . . . . . . . . . . 30

3.4 Installation de Tsung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

1

3.5 Tests et relevés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.5.1 Con�guration du test de charge . . . . . . . . . . . . . . . . . . . . . . . 323.5.2 Point de vue du Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.5.3 Point de vue de l'Administrateur . . . . . . . . . . . . . . . . . . . . . . 39

3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 Divers 434.1 Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2 Compte rendu projet Tutoré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.1 Nous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2.2 Statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.3 Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2

Chapitre 1

Étude

1.1 Le projet

Notre projet porte sur la mise en place de solutions assurant la haute disponibilité et larépartition de charge sur un service Web. Les serveurs o�riront un service Web basé sur Rubyon Rails couplé à un Système de Gestion de Base de Données. Le projet se déroule en deuxgrandes parties. La première consiste à se documenter sur les solutions existantes et à choisircelles qui conviendront le mieux. La seconde est plus pratique avec la mise en place de l'unedes solutions choisies suivie d'une période de tests et benchmarking.

Le developpement d'une petite application Ruby on Rails sera donc indispensable pour ceprojet. Ruby 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 manquaitau langage Ruby 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èrefonctionnelle, 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 con�guration minimale, favorisant certaines conventions,� des technologies déjà intégrées comme Ajax permettant d'o�rir aux utilisateurs �nauxune interface �riche� et plus ergonomique.

Il en résulte des sites qui proposent des interfaces riches en fonctionnalités, pourvues d'uneforte interactivité, illustrant bien les services Web 2.0. De plus, tout a été conçu pour minimiserla 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 ! Uncertain nombre d'outils sont disponibles à l'installation et permettent d'automatiser les tâchesles 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 detravailler avec le serveur web écrit en Ruby : WEBrick. Par une simple ligne de commande, ledéveloppeur exécute sur son ordinateur un serveur web. Le serveur est tout de suite opérationnelet 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 sontsupportés : SQLite, MySQL, PostgreSQL, DB2, Oracle et Microsoft SQL Server. Pour lesserveurs Web, on peut utiliser apache ou lighttpd ou encore Nginx avec Mongrel.

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 a�nd'éviter toute dégradation que ce soit en terme de performances ou de �abilité lors d'a�uencesimportantes.

Le principe de base de l'équilibrage de charge (load balancing en anglais) consiste à e�ectuerune distribution des tâches à des machines de façon intelligente. Pour cela il faut intégrer undispositif entre les serveurs et les utilisateurs de la ressource. Ce dispositif aura pour tâche derediriger les consommateurs de services en fonction de l'état d'occupation des serveurs. Il fautaussi prendre en compte le service distribué et adapter la méthode de redirection en fonctionde 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 ladisponibilité d'un service de part son bon fonctionnement. Ces dispositions sont e�ectuées dansle 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 jours98% 7 jours99% 3 jours et 15 heures99,9% 8 heures et 48 minutes99,99% 53 minutes99,999% 5 minutes99,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 étantl'utilisation de DNS. Dans cette solution le répartiteur de charge est le serveur DNS. Basé surla con�guration de bind (démon le plus utilisé sous Linux pour le DNS), le serveur DNS permetde résoudre les noms d'hôtes de manière di�érente à chaque requête. Un nom de domaine estassocié à plusieurs adresses IP correspondant à chaque serveur du cluster. Bind, utilise alorsun algorithme round-robin pour choisir le serveur destinataire de la requète. L'avantage de cesystème est sa grande simplicité, il su�t d'ajouter quelques lignes à la con�guration de bind

4

sur le serveur DNS. Par contre il ne permet pas de prendre en compte les performances d'unserveur, 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 dedéfaillance de serveurs du cluster. Voici quelques unes de ces solutions.

LVS

Linux Virtual Server1 est une solution de répartition de charge pour GNU/Linux. L'objectifprincipal est de construire un serveur de haute performance pour Linux utilisant la technologiedu clustering. LVS est un logiciel basé sur les couches 3 et 4 de la représentation OSI. Il faitdes redirections sur les adresses IP ainsi que di�érents ports TCP. LVS est plus détaillé par lasuite (en 1.4).

Apache - mod_proxy_balancer

À partir de apache 2.1 2, en utilisant le module mod_proxy_balancer, il est possible defaire 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 fairedu monitoring simple). Il intègre trois algorithmes d'�ordonnancement� : Request Counting,Weighted Tra�c Counting et Pending Request Counting.

� Request Counting : répartit les requêtes de façon pondérée vers les serveurs.� Weighted Tra�c Counting : répartit les requêtes de façon pondérée sur la taille (enoctets) des réponses.

� Pending Request Counting : répartit les requêtes de façon pondérée sur la taille de laliste 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 lesrequêtes de clients sur di�érents serveurs en gardant une trace de ceux-ci pour renvoyer chaqueclient vers le serveur qui lui avait été a�ecté précédemment. Il intègre également un dispositifsimple 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 plusieursserveurs 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 dumonitorage au niveau applicatif en utilisant penbw.

Avantages :� tous les protocoles basés sur TCP (y compris HTTPS),� possibilité d'utiliser VRRP,

1http://www.linuxvirtualserver.org/2http://httpd.apache.org/3Virtual 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

HAProxy4 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 lesapplications 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 :� recon�guration à chaud impossible,� pas d'interface Web de con�guration,� pas de centralisation des con�gurations.

Balance

Balance5 est une solution simple basée sur le niveau utilisateur de la couche OSI, il netouche pas au kernel. Il o�re une solution d'équilibrage de charge mais aussi de proxy TCP.Son Load Balancing est basé sur plusieurs algorithmes (RoundRobin, random, hash, leastresources). Il o�re une gestion totale via la ligne de commande en plus d'être très léger. Ilexiste en deux versions, une gratuite (balance) et une commerciale (balanceng6).

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 proxymail et surtout en mode reverse proxy avec load balancer. Il a été programmé a�n d'obtenir lesmeilleurs performances possibles. Ainsi, il ne nécessite pas d'avoir autant de processus que deconnexions, un par processeur su�t. Les requêtes sont découpées en mini-tâches, ordonnancéespar chacun des processus. Ceci et le fait qu'il soit développé en C lui confèrent une empreintemémoire vraiment faible et une excellente rapidité d'exécution.

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

6

Nginx est un front-end populaire pour les applications Rails et PHP. Aussi, l'équilibragede 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'administrationet 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èleOSI (Niveau 3/4) tandis que d'autres sont basées sur la couche applicative (Niveau 7). Cela

8http://oscar.openclustergroup.org/9http://www.mandriva.com/clustering

10http://www.apsis.ch/pound/

7

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

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

8

Récapitulatifdes

fonctionnalités

Type

Lice

nce

TLS/SSL

Sessions

CacheCou

cheOSI

Portab

ilité

Maint

enu

Apache

Serveurweb,

apache

XX

XApplication

Unix,Window

sdécem

bre

2008

reverseproxy

HAProxy

LoadBalancer

GPL

XX

XApplication

Unix

Novem

bre

08

Pen

LoadBalancer

GPL

XApplication

Unix,Window

sMai2008

Balance

GPL

??

Application

Unix

Avril08

BalanceNG

shareware

XX

Application

Unix

Février

09

UltraMonkey

?GPL

--

-Réseau/Transport

Unix

2005

Nginx

Serveurweb,Reverse

Proxy

typeBSD

XX

XApplication12

Unix

janv-2009

reverseproxy

Oscar

GPL

??

?Réseau/Transport

Unix

2009

Clic

GPL

--

Réseau/Transport

Unix

2003

Pound

Reverse

Proxy

GPL

XX

XApplication

Unix

2009

LVS(IPVS)

LoadBalancer

GPL

XX

-Réseau/Transport

Unix

2004

KeepAlived

HealthCheck/Failover

GPL

??

?Application

Unix

2009

9

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 principalementutilisées pour faire de l'équilibrage de charge de serveurs Web, il y a les applications basées surLVS et les reverse-proxies. Nous pouvons ainsi retenir dans le cadre de notre projet, POUNDqui 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 à desprincipes simples tels que la redondance de l'ensemble du matériel et des services a�n de limiterles SPOF (Single Point of Failure). Il est ainsi systématique dans ce type de con�guration depratiquer de la réplication de données ainsi que de mettre en place des technologies telles quele RAID a�n d'éviter les pertes de données.

Drbd

DRBD (Distributed Replicated Block Device) est un mécanisme de réplication de donnéeslocalisées sur deux serveurs distincts par voie réseau. Quand une écriture a lieu sur le disque duserveur maître, l'écriture est simultanément réalisée sur le serveur esclave. La synchronisationest 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éci�que. En e�et, il utilise simplement leprotocole IP pour le transport des données, ce qui s'avère moins coûteux en matériels que lespé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 unsystème de clustering en haute disponibilité basé sur le principe des battements de c÷ur. Ilexé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 dechanger d'adresse IP entre plusieurs machines à l'aide de mécanismes ARP avancés. Heartbeatfonctionne à partir de deux machines et peut être mis en place pour des architectures réseauxplus complexes.

Ldirectord

Ldirectord, écrit en Perl, a pour rôle la surveillance applicative des machines et modi�e, entemps 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, a�n que les utilisateursn'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 con�guré pour supprimer un serveur appartenant au cluster (grappe demachines) s'il ne répond plus. Il peut aussi envoyer une noti�cation par courriel pour quel'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 lasupervision des di�érentes machines. Ces logiciels sont réputés pour leur bon fonctionnementainsi que leur e�cacité. Ultramonkey convient aussi bien pour la mise en place sur de petitsclusters 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é o�erte par le protocole de Heartbeat,� monitoring des services via ldirectord,� o�re 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 ressourceslogicielles 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) sil'application ne tourne plus sur la machine active.

Mysql Replication

MySQL supporte la réplication unidirectionnelle interne. Un serveur sert de maître, et lesautres serveurs servent d'esclaves. Le serveur entretient des logs binaires de toutes les mo-di�cations 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 serveurmaître, indique au maître le point qu'il avait atteint depuis la �n de la dernière réplication, puisrattrape les dernières modi�cations 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'équilibragede charge ne sera pas mis en place sur les bases de données.

11

Récapitulatifdes

fonctionnalités

Type

Portab

ilité

Maint

enu

UltraMonkey

Packagedesolution

Unix

Juillet2007

Drdb

Outildereplicationréseau

Unix

Février

2009

HeartBeat

Outildemonitoring

Unix

Février

2009

Ldirectord

Systèm

edeclustering

Unix

Février

2009

KeepAlived

Systèm

edeclustering

Unix

Mars2009

Mon

Outildemonitoring

Unix

Juin

2007

MySQLReplication

Outildereplicationréseau

Multiplateform

eJanvier2009

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 packageregroupant certaines des solutions présentées a�n de fournir un outil clé en main. Dans le cadrede notre projet, ces solutions peuvent toutes convenir. Ainsi, un choix devait être fait (Heart-Beat + Ldirectord ou Keepalived pour la gestion du cluster, DRBD ou MySQL Replicationpour les bases de données). Les solutions choisies au �nal sont : HeartBeat + Ldirectord ainsique MySQL Replication

1.3.3 Serveur Web

A�n de mettre en place une application ruby, il nous faut un serveur web capable d'exécuterdu 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'ApacheSoftware Foundation. C'est le serveur HTTP le plus populaire du Web. C'est un logiciel libreavec un type spéci�que de licence, nommée licence Apache. Apache est conçu pour prendre encharge de nombreux modules lui donnant des fonctionnalités supplémentaires : interprétationdes langage Perl, PHP, Python et Ruby, serveur proxy, Common Gateway Interface, réécritured'URL, etc.

Nginx

Nginx est un serveur HTTP et Reverse proxy. Il est désormais utilisé par de plus en plusde site internet au niveau mondial. Nginx reprend un certain nombre de principes d'Apache,comme la notion de �chiers de con�guration modulaires (via des include), des virtual hosts...Cependant dans Nginx, il n'y a pas de notion de ServerName ni de ServerAlias. Tout est aumê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. Grosinconvé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 etsécurisé et optimisé pour le délivrement de contenu dynamique Ruby On Rails. C'est un logiciellibre 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, lacon�guration d'Apache est plus simple que celle ne Nginx. Nous avons donc décidé de testerApache avec Mongrel pour voir les performances avec cette con�guration.

1.3.4 Monitoring

En vue d'e�ectuer des tests sur notre cluster il est indispensable de s'équiper d'outils nouspermettant de surveiller les ressources utilisées sur les machines. De nombreuses solutionsexistent c'est pourquoi le choix est très important. Nous allons en premier lieu utiliser lesoutils 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 con�guré 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 desressources systèmes, il faut pour cela déployer une solution qui lui enverra les informationsdésirées.

Munin

Munin est un outil de surveillance système et réseau basé sur l'outil RRDtool. Il présente sesrésultats sous forme de graphiques disponibles via une interface web. Il possède une structurede plugins particulièrement simple qui permet d'enrichir rapidement l'outil. L'architecture dusystème Munin est constituée d'un serveur principal, récupérant les informations à intervalleré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 decluster ou grid (ensemble de cluster). On béné�cie aussi d'une présentation par interface webet 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. Deplus il procure un nombre important d'informations et une précision plus grande (détails surl'heure, la journée, ...). En e�et 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 avecun répartiteur de charge fonctionnant sous Linux. Celui-ci permet d'assurer la répartition decharge pour la plupart des services existants tout en permettant une haute disponibilité (viades logiciels comme heartbeat).

LVS est constitué d'un logiciel appelé IPVS. IPVS implémente la répartition de charge auniveau de la couche transport (TCP). Celui-ci est inclus dans le noyau de Linux depuis sa version2.0. C'est lui qui met en ÷uvre les di�érents algorithmes et s'occupe de router les paquets versles 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 queles 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 lesdeux 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 modi�er 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 recon�gurer lesserveurs réels, hormis leur indiquer l'équilibreur de charge comme passerelle par défaut. Seulle répartiteur a besoin d'être con�guré.

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 modi�cation des adressesIP de destination. Lorsqu'un paquet arrive sur le répartiteur, l'adresse IP de destination estsubstituée par celle du serveur choisi. Le client n'étant pas dans le réseau privé, le paquet deréponse du serveur est envoyé au répartiteur (con�guré en tant que passerelle sur le client), quiremplace l'adresse IP source par son adresse. Donc le client recevra un paquet dont l'adresseIP source est le répartiteur et non le serveur réel. On assure ainsi une totale transparence dela grappe (répartiteur + serveurs).

LVS NAT a pour avantage l'utilisation d'adresses privées (10.x.x.x, 192.168.x.x) pour lesserveurs 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 letra�c 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 modi�e 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 modi�e la table ARP de ce serveur pour pouvoir résoudrel'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 lamê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 dedestination 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 directementau 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 duserveur 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, souspeine 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 e�cace dans le cadre d'unéquilibrage de charge avec haute disponibilité est la méthode de routage direct (LVS - DirectRouting). En e�et, 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 sansrendre 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 (lesfameuses sessions en PHP par exemple). HTTP étant un protocole non connecté, un répartiteurde charge doit pouvoir assurer qu'au cours d'une session limitée dans le temps, un utilisateurdonné devra être reconnecté au serveur ayant e�ectué 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é�nitandis 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 estnon-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. Cetalgorithme suppose que le client ne passe pas au travers de di�érents proxies (adresse IPvariable), sinon il n'est valable qu'au cours d'une session limitée dans le temps. N'assurepas 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 enthéorie il semble le plus adapté, en réalité dans le cadre du Web dynamique, un serveurpeut être considéré comme chargé alors que les processus sont en attente d'une requêtevers une base de données...

� First Response : Les requêtes clients sont envoyées simultanément à tous les serveurs et lepremier qui répond sera chargé de la connexion. Di�cile à mettre en ÷uvre et rarementemployé.

� Least-Load Scheduling : C'est un algorithme qui distribue les requêtes au serveur dont lacharge CPU est la plus faible. Le Load Balancer interroge à intervalles réguliers la chargede chacun des serveurs, il y a donc une vraie répartition de charge, mais ce procédé estlent et gourmand en ressources

1.6 Conclusion

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

Concernant les équilibreurs :

Il nous faut un système d'équilibrage de charge prenant en compte le fait que les di�érentesmachines sont sur un même réseau et n'utilisent que le protocole http. C'est pourquoi nousavons 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.A�n d'assurer la haute disponibilité des équilibreurs, Heartbeat a été choisi car il supporteLdirectord et reste plus léger que Mon vis-à-vis de nos besoins. En e�et la surveillance desressources systèmes en vue de prévention de défaillance n'est pas déployée. On notera que ceslogiciels font partie intégrante du projet Linux HA (High Availibility). Linux HA est un projetde clustering visant à fournir un système à haute disponibilité. Ce projet a pour objectif deréaliser une solution de redondance système et de clustering sous Linux. De plus en plus depersonnes s'intéressent à ce type de système, et Linux HA est vu comme une solution des plusadéquates. C'est pourquoi les développeurs du projet se sont attelés à essayer de rendre leursystème le plus portable et le plus compatible avec les autres systèmes existants. Ce projetcomprend entre autre Ldirectord et HeartBeart ce qui nous assure une compatibilité totaleentre 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 contenudynamique Ruby on Rails est assuré par Mongrel qui est conçu spécialement pour la gestionde 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 e�ectuée par MySQL lui même. La di�érence entrela réplication MySQL et DRBD est que la réplication MySQL est asynchrone alors que DRBDest synchrone. Une réplication synchrone, comme DRBD, signi�e que la copie des informationsse fait en temps réel, les performances des serveurs sont donc a�ectées. De plus DRBD n'apas été créée spéci�quement 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 fonctionnementgaranti 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 larépartition de charge. Un deuxième équilibreur de secours (Equ2) est aussi installé et se chargede prendre le relais en cas de panne du premier. Ces équilibreurs se partagent une ip virtuelle quiest 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 contenuesur 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, cettepartie parle donc des di�érents tests possibles et ceux que nous avons sélectionnés.

Certains éléments sont indispensables pour e�ectuer des statistiques dans de bonnes condi-tions :

� Même matériels et même systèmes d'exploitation pour les tests.� Con�guration des cartes réseaux identiques, ici 100 Megabits.� On enregistre la charge des serveurs avant toute manipulation via top ou uptime.� E�ectuer plusieurs tests et garder les meilleurs résultats.� Redémarrer la machine après chaque test.� Revéri�cation 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 permetd'éviter des déconnexions/reconnexions multiples ayant pour incidence de ralentir l'accès auxdonné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 lesplus 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 rapidemontée en charge. Un test consiste donc à envoyer plusieurs requêtes simultanément. Cegenre de test peut être e�ectué avec des outils comme Apache Benchmark et nécessite unnombre de machines permettant de générer un maximum de connexions en un minimumde 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 travaillonssur 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. Lecôté Utilisateur est plus axé sur la livraison rapide du contenu tandis que le côté Administrateurse 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 dela 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 e�ectués avec plusieurs machines hors lignes (déconnectées ducluster) a�n d'évaluer concrètement les gains procurés par la mise en place d'une solutiond'équilibrage de charge et de haute disponibilité. Les premiers tests nous permettront d'avoirune référence en vue de les comparer avec les résultats obtenus sur le temps de réponse depages 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 plusieursoutils gratuits sous Linux dédiés à cela. Nous nous sommes interessés uniquement à des outilsmaintenus et libres.

2.2.1 Apache Bench

Apache Bench (AB) est un outil conçu pour benchmarker des serveurs Apache. Il est conçupour donner des statistiques sur la réponse des serveurs à un test de charge ainsi que lenombre 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 laboratoiresHP. Outil similaire à Apache Bench, celui-ci permet en plus de dé�nir des sessions. Chaquesession correspondant à un utilisateur et son comportement de navigation associé. Dans lemême esprit mais simpli�é il existe aussi HTTP_Load.

2.2.3 Siege

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

2.2.4 Tsung

Tsung marche de manière similaire à Siege mais o�re des fonctionnalités supplémentairescomme la gestion d'utilisateurs di�érents (navigateurs, Os, ...), la simulation de sessions etle retour d'informations dynamiques. De plus celui-ci est basé sur le langage Erlang qui estun langage orienté concurrentiel. Tsung supporte aussi de nombreux autres protocoles telsque WebDAV, SOAP, PostgreSQL, MySQL, LDAP et Jabber/XMPP. Tsung possède de plus unefonctionnalité permettant de créer un cluster de test de charge, un système de génération degraphiques 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 aussid'outils permettant d'obtenir des graphiques exploitables en sortie. De plus le support duclustering 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épartirales tâches sur lui-même ainsi que deux esclaves qui auront pour but de mettre à l'épreuvela solution d'équilibrage via di�érentes requêtes HTTP. Les machines utilisées pour ces testsvont être nos machines car plus puissantes que les machines mises en place dans la solutiond'équilibrage a�n 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 essentiellementsur ipvsadm qui est l'outil d'administration de LVS mais aussi de Ldirectord qui va s'occuperde la con�guration 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 siteweb :

sudo ifconfig eth0 :virt 192.168.2.110

Con�guration de Ldirectord :Les �chiers de con�guration 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é surcelui-ci.

� Scheduler correspond à l'agorithme utilisé pour l'équilibrage, rr signi�ant Round Robin.� real liste les serveurs constituant le pool avec l'adresse ip de chacun d'eux, son type deforward et le poids. Le type masq (pour masquerade) correspond au LVS de type NATet 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éri�er que les serveurs websont toujours disponibles.

27

� Receive contient la valeur que devra contenir la ressource pour être considérée commedisponible.

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�, valeurdé�nie dans le �chier de con�guration.

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 chacundes équilibreurs. On installe Heartbeat :

sudo apt-get install heartbeat

Con�guration : Il y a 3 �chiers à con�gurer 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︸ ︷︷ ︸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

A�n d'exploiter les résultats, il nous est nécessaire de surveiller et tracer des graphiques.MRTG et RRDTOOL sont les leaders dans ce domaine. Néanmoins la mise en place/con�gu-ration n'est pas rapide. C'est pourquoi des outils plus spéci�ques doivent être utilisés.

Après plusieurs recherches Ganglia semble tout indiqué. Après quelques tests il a été décidéde choisir Ganglia de part ses nombreux graphiques fournis mais aussi le détail des événementspar heure (sur munin on ne peut zoomer au delà des jours).

Installation/Con�guration

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

apt-get install gmetad

Puis il faut con�gurer 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 con�guration /etc/gmond.conf :

Name ASRALL

Ganglia est packagé par défaut mais ne contient pas le frontend Web, pour cela il su�tde télécharger le tar.gz sur le site o�ciel et copier le répertoire �web� à l'emplacement duserveur web.

3.3 Mise en ÷uvre des serveurs Web

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

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 dansun 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

Con�guration 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 commandessuivantes :

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

Con�guration du maître :

Il faut tout d'abord éditer le �chier /etc/mysql/my.cnf. La première chose à con�gurerest 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 (ceslogs seront utilisés par le serveur esclave a�n de détecter des changements). On lui indique lechemin des log et nous spéci�ons 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 a�cher :

+---------------+----------+--------------+------------------+

| 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 con�guration du maître est désormais terminée.Con�guration 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 qu'il sera l'esclave, que le maître est 192.168.0.100et que la base se nomme example. Pour cela on modi�e 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 e�ective.

3.4 Installation de Tsung

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

sudo apt-get install tsung

La con�guration de Tsung est mise en place au travers d'un �chier xml que nous verrons lorsdes tests.

3.5 Tests et relevés

3.5.1 Con�guration du test de charge

Nous allons durant ces tests mettre en avant les béné�ces d'un équilibrage de charge. Lamontée en charge se fera progressivement et non brutalement dû au manque de matériels et lemanque d'intérêt réel vis à vis des tests que nous voulons e�ectuer.

Les tests de charges vont être fait avec Tsung et certains paramètres doivent être dé�nis.La con�guration 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 maintenantindiquer 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 maintientde 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 deconnexion. Maintenant que tout est con�guré il su�t de lancer tsung :

tsung start

Une fois le test généré il su�t 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 lemême a�n de bien remarquer les e�ets 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 avecune 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 estlui aussi constant. Il y a un pic au début, c'est le temps qu'Apache fork les processus a�n derépondre aux requêtes. Au travers de ces deux graphiques on se rend compte que le serveurn'éprouve aucune di�culté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 équilibragesur 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èssimilaires avec l'équilibrage, il n'est pas nécessaire de nous y attarder. On constate que commeavec 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 basede données MySQL. Nous utilisons ici un CMS déployé sur ces serveurs a�n d'obtenir unpoint 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 quesans.

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 e�et, la moyenne du temps de réponse est beaucoup plus faible avec l'équilibreur. Ici legain 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 testde charge de l'application ROR. Voici donc toujours dans le même ordre, les résultats du testsans 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'utilisateursgrimpe à 350, le serveur n'arrive pas à gérer toutes les connexions et les mets en attente. Dansle cas où l'équilibrage est mis en place, le serveur arrive facilement à gérer les utilisateursconnecté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 letest de charge de l'application ROR, que notre équilibrage de charge fonctionne et permet desgains 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 deces di�érents tests. Voici donc les diverses caractéristiques que nous avons relevés.

40

Fig.3.13

�Évolution

delacharge

CPUdu

serveursurveillé

41

Fig.3.14

�Évolution

del'utilisationmém

oire

duserveursurveillé

42

En ce qui concerne le premier graphique, on voit bien par exemple que lors des tests demontées de charges sur une page dynamique en PHP sans équilibrage (3), la charge CPU estmontée jusqu'à 85%. Si l'équilibrage est actif, la charge CPU est 25% moins importante. Letest 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 quelorsque l'équilibrage est mis en place, on gagne environ 250Mo en passant à 250Mo. En ce quiconcerne l'application ROR (5), on passe d'environ 180Mo sans équilibrage à 140Mo avec lamise en place de l'équilibrage (6).

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

3.6 Conclusion

Étant donné les di�érents résultats présentés dans cette partie, nous pouvons en conclureque notre équilibrage fonctionne parfaitement puisqu'il permet aux clients d'accéder au siteplus rapidement en cas d'encombrement tout en réduisant les ressources nécessaires sur lesdiverses 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 dedonné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 destâches. Bien qu'une très grande partie ait été faite entièrement en commun, certains élémentsont é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 travailtotal d'environ 140 heures.

� Recherche de documentation concernant la haute disponibilité et l'équilibrage de chargesous 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 a�n de tester le déploiement sur un serveuravec 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 chargesous 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 pro�t 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 chargesous 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é e�ectué sur un SVN, c'est pourquoi il peut être intéressant de regarderquelques 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 engrande 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 modi�cations se font le vendredi et le lundi en e�et lesré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 modi�cations se font très souvent le matin au vu de ces statistiques. En e�et la théoriea 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