Equilibrage_DeCharge

5/11/2018 Equilibrage_DeCharge - slidepdf.com

http://slidepdf.com/reader/full/equilibragedecharge 1/73

Licence Professionnelle ASRALL

Équilibrage de charges sous Linuxdans un contexte de connexion sécurisée

Rapport

Auteurs : Tuteur :

Michaël DOSCH Philippe

JoseNassim

Thierry





Sommaire

1 Étude .............................................................................................................................................4

1.1 Problématique .........................................................................................................................4

1.2 Haute disponibilité .................................................................................................................5

1.2.1 Définition ........................................................................................................................6

1.2.2 Algorithmes ....................................................................................................................7

a ) Algorithmes déterministes .............................................................................................7

b ) Algorithmes non−déterministes .....................................................................................8

1.2.3 Topologies réseau ...........................................................................................................9

1.3 Connexion sécurisée .............................................................................................................14

1.4 Persistance ............................................................................................................................16

1.5 Solutions existantes pour l'équilibrage de charge .................................................................191.5.1 LVS ...............................................................................................................................19

1.5.2 Nginx ............................................................................................................................19

1.5.3 Pen ................................................................................................................................20

1.5.4 HAproxy .......................................................................................................................20

1.5.5 Logiciels complémentaires aux équilibreurs de charges ..............................................23

2 Mise en pratique ........................................................................................................................26

2.1 Scénarios ..............................................................................................................................27

2.2 Configurations matérielles et logicielles .............................................................................28

2.3 Réseau ..................................................................................................................................29

2.3.1 Les répartiteurs de charge .............................................................................................31

2.3.2 Serveurs de base de données Mysql .............................................................................43

2.3.3 Configuration du NFS ..................................................................................................47

2.3.4 Mise en place du SSL ...................................................................................................51

3 Analyse ........................................................................................................................................52

3.1 Benchmark / Graphiques ......................................................................................................52

3.2 Analyse des graphiques ........................................................................................................53

3.3 Analyse des algorithmes de répartition de charge ...............................................................56

3.4 Single Point Of Failure ........................................................................................................58

4 Conclusion ..................................................................................................................................59

5 Bibliographie ..............................................................................................................................60

6 Annexes .......................................................................................................................................61



1 Étude

1.1 Probl é matique

Nous sommes administrateurs systèmes et réseaux dans une entreprise possédant une boutique en

ligne.

Fort de son succès, le nombre de connexions enregistrées est en constante croissance. Ainsi, il nous

est demandé la mise en œuvre d'une infrastructure de haute disponibilité capable de supporter de

fortes montées en charge et apte à répondre aux diff érents besoins liés à l'activité du site :

● Gestion du protocole HTTPS indispensable aux transactions financières.

● Support des pages dynamiques, notamment la gestion des sessions.

● Sécurisation des données.

Nous allons donc, à travers ce rapport, étudier les diff érentes solutions possibles puis déployer et

tester celles qui semblent les mieux adaptées aux exigences exprimées précédemment.

1



1.2 Haute disponibilit é

La haute disponibilité est le fait de maintenir l'accessibilité à un service suivant un taux de

disponibilité élevé. Afin de garantir cela, il est indispensable de mettre en place une architecture

matérielle dédiée. Il faudra jouer notamment sur la redondance des matériels, la sécurisation des

données afin de garantir leurs intégrités ( RAID, Backup,...), la répartition de charge pour faire face à

des pics d'activités.

Principe de redondance :

La redondance a pour but d'augmenter les performances et/ou diminuer les risques de pannes. Pour

se faire on peut mettre en place plusieurs configurations matérielles et logicielles identiques ou

diff érentes (plus rarement) afin de relayer des serveurs défaillants ou de partager les diff érentes

tâches. La redondance implique donc un investissement conséquent pour les entreprises.

Principe de sé curisation des donné es :

Par « sécurisation des données » on entend « être capable de pouvoir réimplanter des données

rapidement et sans corruptions de celles ci » . Pour cela des technologies sur les disques durs

comme le RAID permettent de gagner en performances ou en sécurité. D'autres solutions sont

possibles comme le stockage des copies des données sur un serveur de sauvegarde ou un NAS.

Principe de r é partition de charge :

Le but de la répartition de charge est de pouvoir distribuer un travail entre plusieurs ressources afin

d'obtenir un gain de performances. Le « load balancing » que nous expliquerons plus loin est une

solution possible de répartition de charge.

Taux de disponibilité Temps d'indisponibilité par an

99,9 % 8 heures 45 minutes

99,99 % 52 minutes

99,999 % 5,2 minutes

99,9999 % 54,8 secondes

99,99999 % 3,1 secondes

Tableau 1 : Estimation du temps d'indisponibilit é annuelle en fonction du taux de disponibilit é .

Concrètement, la haute disponibilité pour une entreprise est devenue une chose indispensable car les

utilisateurs externes à l'entreprise jugent souvent les entreprises à leurs sites internet et ne tolèrent

plus les pannes ou les temps d'attente trop conséquents.

De même pour un service interne à l'entreprise qui ne serait pas disponible à certains moments, il

pourrait y avoir une paralysie pendant plusieurs minutes, heures ou plus encore ce qui entra î ne une

gêne de travail.

Ainsi la haute disponibilité est un réel soucis économique pour les entreprises car elle influe sur leur

crédibilité et leur image de marque. La perte potentielle de clients est aussi à prendre en compte et

par conséquent la perte d'argent aussi.

C'est pour ces raisons que nous allons étudier diff érentes solutions de haute disponibilité,notamment le load balancing afin de permettre une continuité des services en toutes circonstances.

2



1.2.1 Définition

La répartition de charge (en anglais « load balancing ») consiste en l'intégration d'un système entre

les clients (demandeurs de ressources) et les ressources. Ce système se chargera de désigner le

fournisseur le moins occupé au moment de la demande pour servir le client. Ainsi les demandes

seront alors réparties sur plusieurs fournisseurs de ressources au lieu d'un seul.

Sur une architecture classique, c'est àdire une connexion directe entre les clients et les ressources,les ressources sont stock ées sur un seul serveur. En cas de forte activité, ce serveur ne peut pas

servir tout le monde et l'accès aux ressources est alors compromise, c'est ce que l'on appel le déni de

service ( DoS : Deny o f Service). La répartition de charge permet d'optimiser le trafic et de répartir

les charges sur un pool de serveurs permettant l'accès aux ressources, la capacité totale de traitement

est alors plus importante.

La capacité de connexion et de traitement est proportionnelle au nombre de machines présentes dans

le pool1 (ou cluster 2) . Ainsi, il est possible de dimensionner convenablement le pool en fonction des

besoins, il suffit d'augmenter le nombre de machines du pool pour augmenter les capacités. Sur une

architecture classique, l'augmentation de capacité nécessite un changement matériel sur le serveur

(augmentation de la RAM , changement du CPU ,...) ou un remplacement complet de machine, ce qui

entra î ne un arrêt du service.

1 Pool : un pool désigne un ensemble de ressources réutilisables gérées de façon commune pour un ensemble

d'usagers (processus informatique, utilisateurs, ordinateur, etc).

2 Cluster : en réseau et système, le terme cluster peut désigner une grappe de serveurs (ou ferme de calcul) constituée

de deux serveurs au minimum (appelé aussi nœuds) et partageant une baie de disques commune, pour assurer une

continuité de service et/ou répartir la charge de calcul et/ou la charge réseau.

En calcul distribué, le cluster décrit un système informatique composé d'unités de calcul (micro processeurs, cœurs,

unités centrales) autonomes qui sont reliées entre elles à l'aide d'un réseau de communication. Un systèmed'exploitation spécialisé (par exemple Mosix), exploite alors les éléments du cluster pour gérer la répartition du

calcul ou du traitement à réaliser.

3

Illustration 1 : Sché ma simple de « load balancing ».



1.2.2 Algorithmes

Les load balancers utilisent des algorithmes afin de déterminer comment répartir la charge sur les

pools de ressources. Il en existe deux catégories, les algorithmes déterministes et les non

déterministes.

a ) Algorithmes d é terministes

Un algorithme déterministe traitent les demandes de façon linéaire et en suivant toujours le mêmeschéma de répartition. Ce type d'algorithmes assure la persistance, c'est àdire le fait que le client

soit toujours redirigé vers le même serveur.

Les applications Web dynamiques utilisent souvent des mécanismes de sessions, comme les

sessions PHP, qui ne peuvent fonctionner sans cette persistance. Néanmoins, de part leur principe de

fonctionnement, ces algorithmes ne garantissent pas une répartition optimale de la charge.

Tables de Hash : Cet algorithme construit une table de correspondance à partir de l'adresse IP du

client pour rediriger celui ci vers le m ême serveur à chaque nouvelle requête, ceci durant un laps de

temps prédéterminé. Cette façon de faire peut poser des problèmes lorsque les clients passent via un

même proxy, ces derniers seront redirigés vers le même serveur dégradant ainsi la qualité de larépartition de charge.

Illustration de tables de Hash :

Serveurs et IP :

Serveur IP

Serveur 1 129.168.10.3

Serveur 2 129.168.10.4

Serveur 3 129.168.10.5

Serveur n 129.168.10.n

Table IP Hash, on prend l' IP du client comme clé et l' IP du serveur comme valeur :

Clé (client) Valeur (serveur)

194.153.205.26 129.168.10.3

194.28.12.1 129.168.10.4

178.12.77.1 129.168.10.n

194.28.12.4 129.168.10.3

194.28.15.7 129.168.10.n

178.12.73.1 129.168.10.4

194.28.13.5 129.168.10.3

178.12.78.2 129.168.10.5

Redirection : Les clients sont envoyés vers un serveur de redirection, celui ci les redirigeants vers

un serveur selon un algorithme qui lui peut ne pas être déterministe. Une perte de connexion peut

alors survenir si le serveur vers lequel le client a été redirigé est indisponible. Cette méthode necorrespond donc pas à ce que l'on attend, une haute disponibilité.

4



b ) Algorithmes non − d é terministes

Les algorithmes non d éterministes ne permettent pas la persistance à eux seuls car ils ne donnent

pas la même sortie à chaque exécution de l'algorithme et nécessitent un mécanisme auxiliaire pour

assurer cette tâche. Par contre ils offrent la répartition de charge la plus homogène et offrent les

meilleures performances sur les connexions permanentes ( ftp, smtp, ...).

Round Robin

Le round robin ou « tourniquet » est un algorithme pour sélectionner tous les éléments d'un groupe

équitablement et rationnellement, en commençant par le premier élément de la liste jusqu'à arriver

à la fin et recommence à nouveau depuis le premier élément fra î chement arrivé en liste.

Least connection

Le serveur renvoie 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. Difficile à mettre en œuvre et rarement employé.

5



1.2.3 Topologies réseau

Notion de serveur virtuel :

Un serveur virtuel est un serveur de haute disponibilité et haute évolutivité implémenté sur un

cluster réel de serveurs, il est transparent pour les utilisateurs finaux, les utilisateurs interagissent

avec le cluster comme si c'était un seul serveur de haute performance. Pour une meilleure

explication on peut voir le schéma suivant :

Les serveurs réels et le load balancer peuvent être connectés sur une LAN ou une WAN. Les

balancers peuvent déléguer les requêtes aux diff érents serveurs et faire des services en parallèle

pour que le cluster puisse appara î tre comme un service avec une seule adresse IP, pour répondre aux

requêtes le load balancer peut utiliser les technologies « IP Level » ou « Application Level ».

L'évolutivité du système est obtenue soit en ajoutant ou en supprimant de manière transparente les

nœuds du cluster . La haute disponibilité est prévue par la détection des échecs des nœuds ou de la

configuration. Pour combattre la surcharge de travail des serveurs, il y a deux solutions.

L'une consiste à faire évoluer une machine en un serveur de haute performance, mais on risque

encore une fois de surcharger le serveur si les requêtes s'incrémentent, le processus de mise à jour

du serveur est aussi complexe que le coût est haut.

L'autre possibilité est d'utiliser une solution de serveurs multiples, pour passer d'un système évolutif

de services réseau à un cluster de serveurs. Quand la charge s'incrémente, on peut ajouter un

nouveau serveur ou plus au cluster pour répondre au nombre croissant de requêtes et obtenir de cette

manière un bénéfice performance/coût. Par conséquent, il est plus facile et moins coûteux de le faire

évoluer.

Pour construire les clusters on dispose de plusieurs méthodes, on abordera les plus communes.

6

Illustration 2: Repr é sentation d'une architecture simple

avec load balancer transparent pour les clients.



Cluster d'équilibrage de charge basé en DNS.

Le « DNS balancing » est probablement la méthode la plus simple pour construire un cluster de

service réseau. Il utilise le nom domaine pour distribuer les requêtes aux diff érents serveurs à

travers la résolution de nom domaine pour les adresses IP des serveurs. Lorsqu'une requête arrive au

serveur DNS pour résoudre le nom, le serveur DNS donne une des adresses IP en se basant sur une

planification de stratégies (comme le mode round robin par exemple). Ensuite les requ êtes

subséquentes qui viennent des clients en utilisant le même nom du serveur dans le cache local seront

envoyées vers le même serveur pour une période donnée ( time to live ou TTL ).

Cependant, dû à la nature des clients et le stockage en cache du DNS hiérarchique, cela peut poser

des problèmes de déséquilibre de charge entre les serveurs et conduire à une surcharge de n'importe

quel serveur. Une mauvaise élection de la valeur de durée de vie (TTL) de l'enregistrement dans la

configuration du DNS peut devenir un problème. Avec une trop petite ou une trop grande valeur le

serveur DNS peut monter à saturation. Même si la valeur du TTL est mise à zéro, la finesse de

l'ordonnancement est diff érente pour chaque hôte, le comportement de chaque utilisateur est

diff érent, car il y a des clients qui surfent sur quelques pages pendant quelques minutes, mais

d'autres ont l'habitude de surfer sur des pages du site pendant un temps indéterminé. De plus le

« DNS balancing » n'est pas fiable car lorsqu'un nœud tombe en panne, les clients qui sont dirigésvers l'IP d'un serveur en particulier ne trouveront pas le serveur et le problème augmente quand les

clients appuient sur le bouton « actualiser » du navigateur.

Répartiteur de charge basé sur un cluster d'équilibrage.Le répartiteur, également connu comme load balancer , peut être utilisé pour répartir la charge entre

les diff érents serveurs du cluster afin que les services parallèles du cluster puissent appara î tre

comme un seul serveur avec une IP unique. Les clients finaux interagissent comme s'il s'agissait

d'un seul serveur sans conna î tre la vraie infrastructure qu'il y a derrière. Par rapport à l'équilibrage

de charge basé en DNS, le répartiteur peut planifier les demandes de façon précise pour chaque

connexion afin d'obtenir un meilleur équilibrage entre les serveurs. L'un des avantages est que la

panne d'un serveur n'entra î ne pas l'arrêt du travail pour l'utilisateur final car un autre serveur prend

le relais et l'échec est transparent pour le client. Autre avantage la gestion du serveur devient plus

facile, l'administrateur peut retirer un serveur ou plus du pool « à chaud » à n'importe quel moment

sans interrompre les services pour les utilisateurs finaux.

L'équilibrage de charge peut se faire en deux niveaux, au niveau de logiciel ou au niveau d'IP.

Les serveurs virtuels peuvent être mis en place de trois manières pour l'équilibrage de charges :

1. Virtual server via NAT.

2. Virtual server via Tunneling.

3. Virtual server via Routage direct.

7



Serveur Virtuel via NAT

Un serveur virtuel via NAT fonctionne sur le principe d'adresses IP virtuelles, ainsi la seule " vraie "

adresse IP est pour le load balancer . Le load balancer reçoit une requête qu'il va traiter et distribuer

à un serveur réel selon des critères précis définis dans l'algorithme de sélection.

Avantages :

•Peut être mis en place avec n'importe quel système d'exploitation avec support TCP/IP.•Les serveurs peuvent utiliser des IP privées.

•Une seule IP est requise par le load balancer .

Inconvénients :

•Evolutivité limitée, un goulot d'étranglement peut exister quand les serveurs sont trop nombreux,

puisque les requêtes et les réponses doivent passer à travers le load balancer et la sortie d'une

interface est éventuellement limitée.

8

Illustration 3: Sché ma r é seau pour la topologie NAT.



Serveur virtuel via IP Tunneling

Avec le serveur virtuel via « IP Tunneling », le load balancer gère seulement les requêtes vers les

serveurs réels et chaque serveur envoie la réponse directement au client. Donc le load balancer peut

gérer une énorme quantité de demandes et n'est plus un point de défaillance possible.

La fonction d' « IP Tunneling » peut être utilisée pour construire un bon serveur virtuel de haute

performance, puisqu'au moment ou le serveur proxy reçoit une requête, celui ci peut acc éder

directement à internet pour récupérer des objets et les retourner directement aux clients.

9

Illustration 4: Sché ma r é seau pour la topologie IP Tunneling.



Serveur virtuel via Direct Routing.

Tout comme le tunneling, le directeur des processus de Linux, ne traite que la moitié d'une

connexion sur le serveur virtuel via routage direct, de cette manière les paquets peuvent suivre

diff érentes routes sur le réseau, ce qui peut augmenter l'evolutivité du serveur.

Le schéma suivant aide à comparer les trois méthodes.

VS/NAT VS/Tunneling VS/Routage direct

Serveur N'importe lequel Tunneling Sans dispositif ARP

Serveur réseau LAN LAN/WAN LAN

Nombre de serveurs 10 – 20 serveurs Nombreux Nombreux

Serveur passerelle Load balancer Routeur du LAN Routeur du LAN

10

Illustration 5: Sché ma r é seau pour la topologie Direct Routing.



1.3 Connexion s é curis é e

Les services disponibles depuis le réseau internet sont aujourd'hui de plus en plus nombreux. De ce

fait, les entreprises sont de plus en plus vulnérables aux attaques. Il est donc primordial d'appliquer

des politiques de sécurité autour de ces systèmes, comme par exemple la mise en place d'une

connexion sécurisée.

Une connexion sécurisée est une liaison qui permet d'échanger des données de manière cryptée,

d'être sûr de communiquer avec le bon interlocuteur (authentification) et de conserver l'intégrité des

données (pas d'interception par un pirate) .

Afin d'établir ce genre de connexion entre un serveur Web et un internaute, il existe un protocole

nommé SSL pour Secure Sockets Layer.

Principe de fonctionnement :

1 Le client demande au serveur de s'authentifier. Il envoie également la liste des systèmes de

cryptage qu'il supporte (trié par ordre décroissant selon la longueur des clés).

2 Le serveur envoie son certificat, contenant sa cl é publique signée par une autorité de

certification. Il envoie également le nom du cryptage le plus sécurisé parmi la liste reçue avec lequel

il est compatible.

11

Illustration 6 : Demande d'authentification de la part de l'internaute.

Illustration 7 : Envoi du serveur de sa propre clé publique.



3 Le client v érifie le certificat depuis une autorité de certification. Puis crée et envoie une clé

cryptée à l'aide de la clé publique du serveur. Elle sera valable durant la session3.

4 Le serveur va d écrypter la clé du client à l'aide de sa clé privée. La connexion sécurisée

commence alors utilisant une clé symétrique unique.

Ce protocole permet de manière transparente pour l'utilisateur d'obtenir une connexion sécurisée.

L'utilisation d'un cryptage asymétrique puis symétrique permet de simplifier le cryptage (une seule

clé) et de gagner en performance, le cryptage symétrique étant nettement plus rapide.

Toutefois par rapport à notre sujet concernant l'équilibrage de charge et la sécurisation des

connexions, un nouveau soucis se dévoile, celui de la persistance. En effet lorsque l'on met en place

une solution utilisant le load balancing , il se trouve que la connexion peut être perdue si un des

serveurs du pool vient à ne plus fonctionner correctement. Nous abordons cette problématique plusen détail dans la partie suivante.

3 Une session, dans notre cas, est le fait d'accéder au serveur Web. La session est donc initiée lorsque l'internaute a

établit une connexion vers le serveur Web.

L'ouverture de session est ici implicite, c'est àdire qu'elle ne n écessite pas un login et un mot de passe pour être

initialisée, sinon on parle d'authentification. La session implicite est en général utilisée lorsque des droits et donc des

effets sont limités.

La fermeture de la session s'effectue lorsqu'on ferme son navigateur, le demande explicitement (déconnexion aprèsune phase d'authentification) ou encore lorsque l'internaute n'interagit plus avec le serveur Web depuis un temps

défini.

12

Illustration 8 : Cr é ation d'une clé crypt é e apr ès certification.

Illustration 9 : Dé cryptage de la clé publique du client par le

serveur.



1.4 Persistance

On définit la persistance comme le mécanisme responsable de la sauvegarde et la restauration de

données, afin qu'un programme puisse se terminer sans que ses données ni son état ne soient perdus.

Dans ce contexte on prend la persistance comme la capacité du load balancer pour maintenir une

connexion virtuelle entre le client et un service spécifique (HTTP/HTTPS).

Exemple concret :

Si un utilisateur démarre une session sur un des serveurs du pool et que celui ci vient à être

défaillant, il faut impérativement être capable d'assurer qu'un autre serveur puisse continuer à

fournir la session de cet utilisateur.

13

Illustration 10 : Ouverture de session par le client sur un serveur d é signé par le « load balancer ».

Illustration 11 : Dé faillance du serveur sur lequel est connect é l'utilisateur.



Pour résoudre ce genre de problèmes, des méthodes de persistance sur les équilibreurs de charges

existent :

Cookies

Le serveur cible émet un « cookie » contenant un identifiant vers le client. L'équilibreur de charge

pourra ensuite retrouver le serveur initial lorsque le client lui présentera le « cookie » , si cette

méthode présente l'avantage d'être simple à mettre en œuvre, elle n'est pas fiable en pratique puisque

rien ne garantit que le client accepte les « cookies » et que les règles de bonne conduite interdisent

de forcer l'utilisateur à les accepter pour pouvoir accéder au site.

Tracking

Le répartiteur de charge affecte un serveur par Round Robin ou tout autre algorithme que l'on a pu

citer précédemment, et mémorise le lien dans une table. À la connexion suivante, si le client est

reconnu (par son adresse IP par exemple) le serveur le reconnecte au serveur précédemment accédé.

Tout comme l'algorithme déterministe de hashage, seule une session limitée dans le temps peut être

gérée.

Espace disque commun en réseau

Dans le cas de load balacing, comme plusieurs serveurs cohabitent sur le même réseau local il peut

être avantageux de leur permettre de partager des fichiers. C'est ce que permettent les systèmes de

fichiers en réseau, dont le principal représentant est NFS ( N etwork File S ystem) pour les systèmes

Unix.

Le système de fichiers distant est présenté à un utilisateur du réseau comme s'il travaillait sur sa

machine, et celui ci émet des appels système habituels pour y effectuer des opérations d'entrée sortie. Il utilise un appel de procédure à distance, ou Remote Procedure C all. Le résultat de

l'opération est retourné à l'expéditeur par le même procédé.

On concevra aisément que ce processus, qui consiste à commander l'exécution d'un programme sur

un autre ordinateur, peut être une faille béante de sécurité. Il est recommandé de limiter l'usage des

systèmes de fichier en réseau à des environnements soigneusement contrôlés. Il est donc important

de sécuriser les accès même si dans un cas de load balancing ce système ne serait ouvert qu'aux

serveurs de la solution de haute disponibilité.

Cette solution permettrait aux serveurs dans un système de load balancing de partager entre eux des

fichiers contenant les sessions et ainsi assurer la persistance.

14



Stockage des sessions en base de données

Une autre solution est de garder les données de session dans une base de données. En général, cela

est mauvais pour la performance, car la charge sur la base de données augmente. On utilise de

préf érence les bases de données pour stocker des informations moins éphémères que les données de

session.

Pour éviter à une base de données de devenir un point de défaillance unique et d'améliorerl'évolutivité, la base de données est souvent reproduite sur plusieurs machines et l'équilibrage de

charge est utilisé pour répartir la charge de requêtes à travers ces répliques.

15

Illustration 12 : É quilibrage de charge sur les serveurs de bases de donné es.



1.5 Solutions existantes pour l' é quilibrage de charge

L'équilibrage de charge utilise essentiellement deux techniques qui sont le DNS et le load

balancing. Pour réaliser de l'équilibrage de charge plusieurs solutions sont possibles, le plus simple

restant l'utilisation de DNS. Dans le cas du DNS, il n'y a pas de load balancer , c'est le serveur DNS

qui va rediriger le client vers une adresse diff érente appartenant au même nom de domaine que lesite désiré à chaque requête. Ainsi via l'algorithme de round robin les serveurs répondent à tour de

rôle aux demandes.

L'utilisation de DNS ne permet malheureusement pas de prendre en compte les capacités ou

disponibilités des machines, ainsi une autre solution utilisée est celle du load balancing .

1.5.1 LVS

Linux Virtual Server (LVS) est une solution avancée de répartition de charge pour GNU/Linux.

C'est un logiciel libre commencé par Wenson Zhang en mai 1998. La mission de ce projet était de

construire un serveur de haute performance pour Linux qui puisse avoir bonne évolutivité, fiabilité

et robustesse tout en utilisant la technologie du cluster .

L'objectif principal du projet LVS consiste à développer un système IP avancé de répartition de

charge par logiciel (IPVS), répartition de charge par logiciel au niveau d'application et composants

pour l'administration de clusters.

1.5.2 Nginx

Nginx (prononcé « engine X ») est un serveur HTTP libre, open source et haute performance ainsi

qu'un reverse proxy 4. Il intègre également du proxy pour l' IMAP et le POP3.

Il a été développé par Igor Sysoev en 2005. Actuellement Nginx héberge entre 1% et 4% de tous les

noms de domaine au monde. Nginx est reconnu pour ses hautes performances, sa stabilité, son

ensemble de fonctionnalités, sa configuration simple ainsi que sa faible consommation deressources.

Contrairement aux serveurs traditionnels, Nginx ne relie pas un processus à une requête client. À la

place, il utilise un système évolutif et une architecture asynchrone. Cette architecture légère, mais

très importante, lui permet d'utiliser la mémoire de façon prédictive.

Nginx propulse plusieurs sites à forte influence : WordPress, Hulu, Ohloh et TorrentReactor .

4 Le reverse proxy est un serveur proxy monté à l'envers. Contrairement au serveur mandataire classique, le proxy

inverse est orienté du côté des serveurs Web. La connexion entre internautes et serveurs Web s'effectue par sonintermédiaire. Cette technique permet notamment de se prémunir contre les attaques provenant de l'extérieur en

ajoutant une couche de sécurité supplémentaire, la mise en cache des pages statiques, une répartition de la charge.

16



Fonctionnalités :

On peut utiliser Nginx comme un load balancer simple, par deux méthodes, soit via IP Hash soit

par round robin .

Avec la méthode par IP Hash , Nginx garantit que les requêtes du client vont être envoyées au même

serveur. Si le serveur tombe en panne, les requêtes seront envoyées vers autre serveur. En utilisant la

méthode par IP Hash , le poids du serveur ne peut pas être spécifié, si un serveur doit être supprimé

à un moment donné, il doit être enlevé à la main de la configuration avec la finalité de conserver la

granularité.L'autre méthode qu'utilise Nginx, est le round robin , on peut spécifier le poids de chaque serveur

ainsi que le nombre maximal d'échecs et le temps après lequel le serveur est considéré comme

inopérant. Les requêtes sont distribuées par round robin en fonction du poids des serveurs (on

considère le poids du serveur comme la charge maximale de travail que le serveur peut maintenir),

si le client essaie de travailler avec un serveur qui est tombé en panne, la requête sera envoyée au

serveur suivant.

1.5.3 Pen

PEN est un load balancer simple agissant sur les protocoles de la couche TCP (http, snmp,

pop3,...), il utilise le tracking pour assurer la persistance. PEN possède une table permettant de

stocker les connexions effectuées. Lors d'une connexion par un client, PEN vérifie dans la table s'il

a dé jà réalisé une connexion correspondant à l' IP du client. Si c'est le cas, il appel le serveur ayant

dé jà traité cette connexion assurant ainsi le maintient de la session. Sinon, il effectue un round robin

classique et affecte un serveur à la connexion entrante.

La table des connexions est une file tournante, ce qui signifie donc que lorsque celle−ci est pleine,PEN écrase l'entrée la plus ancienne.

PEN est aussi capable de détecter si un serveur est indisponible, il cherche alors un autre serveur

dans la liste en omettant le serveur le plus récemment utilisé.

1.5.4 HAproxyHAproxy est un serveur HTTP simple qui a été développé par le français Willy Tarreau en 2002. Il

s'agit d'un serveur haute performance, léger et à consommation de ressources minimale, son

architecture mono processus lui permet de g érer plusieurs milliers de connexions simultanées sur

plusieurs relais sans effondrer le système.

Il est également capable de s'arrêter en douceur sans perte brutale de service. Autre particularité, il a

la capacité de modifier/ajouter/supprimer des en t êtes dans la requête et la réponse.

Pour travailler avec HAproxy en mode load balancer , il faut savoir qu'il utilise l'algorithme round

robin pour la répartition de charge et les « cookies » pour assurer la persistance de session entre leclient et le serveur.

17



Principe de fonctionnement de HAproxy :

18

Illustration 13: L'internaute veut interroger l'URL 1, HAProxy agit en « load balancer » et le dirige vers le

Serveur A.

Illustration 14: Le serveur A r é pond, HAProxy transmet la page à l'internaute et met en place un « cookie »

identifiant sur le serveur.

Illustration 15: L'internaute interroge l'URL 2, HAProxy recherche un é ventuel « cookie » et le redirige.

Illustration 16: Le serveur r é pond, HAProxy transmet mais ne rajoute pas de nouveau un « cookie ».



19

Illustration 17: Tableau comparatif de quelques solutions de haute disponibilit é existantes.

LVS Nginx Pen HAProxy

Type Load Balancer Serveur Web et Reverse Proxy Load Balancer Load Balancer

Licence GPL type BSD GPL GPL

SSL/TLS

Sessions

Cache

Couche OSI Réseau/Transport Application Application Application

Protocoles TCP HTTP/HTTPS TCP (tout protocoles) HTTP/HTTPS

Portabilité Unix Unix Unix/Window s Unix

Maintenu 2004 Nov. 2009 (version stable) Mai 2008 28 janv. 2010

Algorithmes Nombreux Round Robin Round Robin Nombreux

Légende Non pris en charge

Pris en charge



1.5.5 Logiciels complémentaires aux équilibreurs de charges

● Heartbeat

Heartbeat (ou Pulse) est un système de gestion de la haute disponibilité sous licence GPL.Il met en place un système classique de clustering en haute disponibilité basé sur des « battements

de cœur ». Il exécute des scripts d'initialisations lorsqu'une machine tombe (plus de perception du

battement de cœur) ou est à nouveau disponible (battement de cœur retrouvé). Il permet aussi de

changer d'adresse IP entre les machines à l'aide de mécanismes ARP « avancés ».

Pour fonctionner, Heartbeat doit être combiné avec un gestionnaire de ressources de cluster (CRM),

qui permet le démarrage et l'arrêt des services (adresses IP, serveurs Web, etc).

Heartbeat est livré avec un gestionnaire de ressources primitives, mais il ne détecte pas les échecs au

niveau des ressources.

Pour résumer Heartbeat permet le partage d'une adresse IP « virtuelle » aux diff érentes machines du

cluster . La notion de ma î tre et d'esclave est utilisée ici ; une des machines est déclarée « ma î tre » qui

répond au trafic sur l'IP virtuelle, les autres sont « esclaves » et selon la priorité qui leur est

attribuée prennent la main en cas de défaillance du « ma î tre ».

Ces termes de « ma î tre » et « esclave » font partie de la notion de Fail Over Service , qui consiste en

un basculement automatique d'un équipement informatique défaillant vers un équipement alternatif

ou en veille.

● Mon

Le démon « mon » installé sur l'équilibreur de charge permet de surveiller les services et nœuds de

serveur dans le cluster .

Il permet de surveiller de façon générale :

les services lanc és (ce que ne fait pas Heartbeat)

les ressources (r éseau, locales)

On peut lui définir des alertes et agir en fonction, ainsi en cas de problème on peut exécuter des

scripts, envoyer un mail pour notifier à un administrateur la défaillance rencontrée ...

Ainsi en cas de détection d'une défaillance, il est possible de demander à Heartbeat d'agir sur un

hôte et de le « retirer temporairement » du nœud afin de ne pas laisser une machine « morte » dans

le nœud :

– le ma î tre sera déclaré « mort » par l'esclave

– l'esclave prendra la main et les ressources du défunt « ma î tre »

20



● Ldirectord

Ldirectord (appelé Nanny sous RedHat) fonctionne sous Linux, avec ou sans LVS, et a pour but de

surveiller la santé des serveurs réels en faisant périodiquement une demande et en vérifiant la

réponse attendue. Pour les serveurs HTTP, cela correspond à une requête d'URL connue ainsi qu'une

vérification de la réponse qui doit contenir la cha î ne attendue. Ldirectord fonctionne pour les

services HTTP, HTTPS, FTP, IMAP, POP, SMTP, LDAP, NNTP et les serveurs MySQL.

Si un serveur réel échoue à une requête émise par Ldirectord, alors le serveur doit être retiré du pool

de ressource et devra être réinséré une fois « réparé ».

● Piranha

Outil de configuration LVS disponible avec Red Hat Cluster Suite Piranha Configuration Tool.Piranha (Configuration Tool) est une interface utilisateur graphique (GUI) qui fournit une approche

structurée de la création du fichier de configuration pour LVS /etc/sysconfig/ha/lvs.cf.

La connexion à la page d'accueil donne accès aux quatre principaux écrans (cf. Annexe 1) :

contr ôle / commande

Param ètres globaux

la redondance

serveurs virtuels

● Keepalived

Keepalived gère une IP virtuelle et la répartition de charge depuis cette IP vers des serveurs réels

hébergeant les services répartis. Il utilise la couche IPVS du noyau et la répartition est pilotée depuis

le binaire « ipvsadmin » .

Keepalived monitore les services hébergés sur les serveurs et retire les machines du cluster en casde défaillance. Lorsqu'il détecte que le service est de nouveau opérationnel, le serveur

correspondant est réintégré au cluster . La redondance du répartiteur du charge est assurée par VRRP

qui synchronise un serveur ma î tre et un serveur esclave en montant les IP virtuelles sur l'un ou

l'autre des serveurs en fonction de la disponibilité.

Il existe deux types de configuration :

l'une utilisant deux r éseaux et la réécriture des paquets (LVS NAT),

l'autre utilisant un seul r éseau et le dispatch des paquets (LVS DR).

Dans les deux cas, deux serveurs sont utilisés pour la répartition de charge (un MASTER et un

BACKUP) afin d'assurer la redondance.

21



● DRBD

DRBD « Distributed Replicated Block Device » est un module du noyau Linux qui constitue un

système de stockage distribué. On peut utiliser DRBD pour partager des périphériques entre les

serveurs Linux (disques durs, partitions des volumes logiques, etc).

DRBD met en œuvre un périphérique (block device5) qui peut être utilisé pour le stockage et qui est

reproduit à partir d'un serveur principal à un ou plusieurs serveurs secondaires. Le périphérique de

distribution est géré par le service DRBD.

Sur le serveur primaire, les données sont écrites sur le périphérique physique et distribuées vers les

services secondaires de « DRBD ». Sur le serveur secondaire, les données sont reçues et écrites sur

le périphérique physique. L'information est partagée entre le serveur principal et le serveur

secondaire de manière synchrone, cela signifie que « DRBD » peut être utilisé dans les solutions de

haute disponibilité.

« DRBD » utilise des périphériques logiques (normalement appelés /dev/drbdX où la X est le

nombre de périphérique) sur des périphériques physiques existants de chacun des serveurs du

cluster . Les écritures sont transf érée s du périphérique logique ( /dev/drbdX ) a u périphérique

physique et simultanément vers le serveur secondaire. Le serveur secondaire transf ère les données

vers son périphérique.

Quand le serveur primaire tombe en panne, le processus d'administration du cluster fait la

promotion du serveur secondaire au serveur primaire. Pour faire cette transition requiert unevérification subséquent de l'intégralité du système de fichiers, quand le serveur primaire qui avait

tombé en panne retourne au cluster , une synchronisation est faite et le serveur peut être ou non

retourner à son statut de serveur primaire.

5 Un Block Device : « Fichiers en mode bloc » ou « périphériques de bloc » correspondent à des dispositifs par

lesquels le système déplace les données sous la forme de blocs. Ces périphériques nœuds représentent souvent des

dispositifs adressables tels que les disques durs, lecteurs de CD ROM, ou des zones m émoire.

Le système d'exploitation alloue un tampon de données pour maintenir un seul bloc pour chaque entrée et sortie.

Lorsqu'un programme envoie une demande de lecture ou d'écriture de données sur le périphérique, le système stockechaque caractère de ces données dans le tampon approprié. Lorsque le « buffer » se remplit, l'opération appropriée a

lieu (transfert de données) et le système efface la mémoire tampon.

22



2 Mise en pratique

Pour l'élaboration d'une architecture de load balancing , nous avons choisi de tester la suite de

clustering de RHEL/CentOS basée LVS.

Pourquoi ce choix ?

Pour plusieurs raisons, LVS tout d'abord est toujours la solution la plus utilisée parmi celle

existantes. Un autre élément qui nous a fait choisir cette solution est le fait qu'il est activement

soutenu par des entreprises (Teuto.net, Voxel.net, ...) pour son développement et notamment par

RedHat qui a repris la solution LVS en l'améliorant pour son système d'exploitation. Les outils de

l'éditeur RedHat sont très répandus dans le monde professionnel et sont réputés pour leur fiabilité,

leur flexibilité et leurs performances.

A cela, s'ajoute le fait que ce répartiteur de charge supporte le protocole HTTPS ainsi que la

persistance.

Toutes nos machines fonctionnement sous CentOS qui est un clone de la distribution professionnelle

RHEL (RedHat Entreprise Linux). Elle bénéficie de l'ensemble de ses outils et hérite de sa fiabilité.

Outre ses qualités, cela nous permettra de mieux nous familiariser avec un système basé sur RPM.

Pour informations, la solution de clustering Red Hat comprend :

– LVS (ipvsadm)

– Nanny

– Pulse

– Piranha

23



2.1 Sc é narios

Afin d'avoir un panel de testes représentatif, il est nécessaire de définir quelques situations que l'on

rencontre fréquemment en surfant sur le Web. Ainsi nous pouvons distinguer trois cas principaux :

– Tout d'abord, la page statique, possédant un poids faible de 16ko (moyenne des pages stock ées

dans un serveur mandataire comme Squid).

–

Ensuite, la page statique lourde, agrémentée d'une multitude d'images ou bien d'une photo hauterésolution pour un poids total dépassant les 1024 ko.

– Pour finir, un site commercial. Ici les enjeux côté serveur sont bien plus importants, ce site

requière un moteur PHP, une base de données, ainsi qu'une sécurisation des transactions (SSL).

Afin de mieux comprendre l'interaction d'un internaute avec le site, nous pouvons imaginer un

encha î nement de liens vers lesquels il pourrait se diriger.

Cependant, il est impossible de savoir quel comportement va avoir l'internaute puisqu'il peut très

bien être un habitué du site et conna î tre les produits qu'il désire et donc ne pas passer autant de

temps qu'un autre. Ainsi, nous ne testons pas plusieurs chemins, mais bien une page fréquemment

utilisée par les internautes comme la page d'accueil.

En HTTP et en HTTPS

Round Robin Round Robin Weight Least Connection

Page statique

Page statique lourde

Page dynamique OSCommerce

Page statique



Page statique



Tableau 2: Ré capitulatif des scé narios que nous avons choisis de suivre.

24

Illustration 18: Comportement possible d'un internaute sur

un site commercial.



2.2 Configurations mat é rielles et logicielles

HARDWARE SOFTWARE

Machine CPU RAM DD OS logiciels

Routeur 512 Mo 40 Go

LVS1 512 Mo 40 Go

LVS2 512 Mo 40 Go

Sweb1 768 Mo 40 Go

Sweb2 768 Mo 80 Go

Sweb3 1024 Mo 40 Go

Sweb4 512 Mo 40 Go

512 Mo 40 Go

512 Mo 40 Go

NFS 768 Mo 80 Go

Intel P4 @2.80GHzCentOS 5.4 Openssh

IPTables

Intel P4 @2.80GHzCentOS 5.4 Pulse

Openssh

Piranha

Intel P4 @2.80GHzCentOS 5.4 Pulse

Openssh

Zabbix


Apache


Apache


Apache


Apache

MySQL Intel P4 @2.80GHzCentOS 5.4 Openssh

MySQL

DRDB

MySQL Intel P4 @2,00GHzCentOS 5.4 Openssh

MySQL

DRDB


NFS



2.3 R é seau

26

Illustration 19: Sché ma de l'architecture r é seau mise en place.



Sur le schéma précédent, nous pouvons voir que notre réseau privée comporte l'ensemble des

serveurs qui retournent des informations aux clients. Ainsi nous avons :

– les serveurs Web (4 serveurs Apache) qui permettent d'interpréter les sites et de retourner une

page à un client.

– les serveurs de base de données (2 serveurs Mysql) qui contiennent les données des utilisateurs

enregistrés sur le site (login, mot de passe, informations personnelles, contenu du panier, ...).

– un serveur NFS qui contient toutes les informations communes aux serveurs Web (sites internet,

sessions d'authentifications, certificats pour le SSL).

Nous allons donc expliquer en détail ce qui a été fait pour configurer ces machines :

– installation des répartiteurs de charge

– réplication des base de données MySQL

– configuration du SSL (HTTPS avec certificat)

– configuration du serveur NFS

27



2.3.1 Les répartiteurs de charge

Le cluster LVS est composé de deux groupes de base : les routeurs LVS et les serveurs réels. Pour

éviter les points individuels de défaillance, chacun de ces deux groupes doit comporter au moins

deux machines.

C'est pourquoi notre architecture est composée de deux serveurs LVS : un serveur actif qui se charge

de la répartition de charge entre les diff érents serveurs réels et un serveur de secours qui reste en

veille prêt à reprendre le relais en cas de panne.

Composants de la solution LVS de CentOS :

28

Illustration 20: Communication des services de LVS.



La solution LVS de CentOS est la même que celle de la distribution RHEL de RedHat, elle est

composée des éléments suivants :

Pulse : Il est lancé au démarrage sur le serveur actif et celui de secours. Sur le serveur actif, le

daemon pulse lance l'ensemble des autres daemons relatifs à LVS.

Sur le serveur de secours, le daemon pulse se charge de déterminer l'état du serveur actif en

exécutant un simple heartbeat à un intervalle paramétrable, s'il constate la défaillance de son

homologue, il se chargera de prendre le relais en usant de l'outil send_arp.

LVS : Le daemon LVS est lancé par pulse sur le répartiteur de charge principal. Il lit le fichier de

conguration /etc/sysconfig/ha/lvs.cf puis appelle l'utilitaire ipvsadm pour générer et maintenir les

tables de routage.

Si Nanny lui indique la défaillance d'un des serveurs réels, LVS s'occupe de demander à ipvsadm

de le retirer de la table de routage.

Ipvsadm : Cet utilitaire se charge de mettre à jour les tables de routage dans le kernel (noyau). Il

permet d'ajouter, modifier ou supprimer des entrées.

Nanny : Nanny est le daemon de monitoring qui permet de vérifier le bon fonctionnement des

diff érents serveurs réels. Optionnellement, il peut aussi contrôler leur taux de charge.Il y a un processus nanny diff érent pour chaque service (HTTP, FTP, ...) surveillé sur les serveurs

réels.

send_arp : Cet outil permet au répartiteur de charge de secours de prendre les adresses IP virtuelles

du répartiteur de charge principal lorsque ce dernier dysfonctionne.

Piranha Configuration Tool : C'est une application web permettant le monitoring, la configuration

et l'administration des clusters LVS. C'est l'outil par défaut disponible sous RHEL/CentOS.

29



Support du protocole HTTPS sous LVS :

Il y a deux approches diff érentes pour gérer le protocole HTTPS avec LVS :

1. Le serveur virtuel multiports :

Cette approche consiste à utiliser un unique serveur virtuel gérant à la fois le port 80 (HTTP) et le

port 443 (HTTPS).

Cela est possible en utilisant la méthode des firewall marks qui est un moyen simple et efficace de

regrouper les ports des protocoles multiports tel que le FTP ou ceux des protocoles connexes tels

que le HTTP et le HTTPS.

Cette méthode se base sur le marquage en PREROUTING des paquets entrants sur les ports 80

(HTTP) et 443 (HTTPS) pour que LVS puisse les rediriger vers le même serveur réel.

Il est important de noter que c'est « iptables » qui se charge de marquer les paquets et non LVS, ce

dernier ne fait que lire le marquage.

Les firewall marks peuvent être couplées avec une méthode de persistance, ce qui est utile dans le

cas où les serveurs réels ne partagent pas le même certificat SSL ou les sessions.

30



2. Le serveur virtuel d é dié :

Cette approche consiste à utiliser un serveur virtuel supplémentaire spécialement dédié à la gestion

du protocole HTTPS. On se retrouve ainsi avec deux serveurs virtuels : un pour le HTTP et un autre

pour le HTTPS.

Si ces deux serveurs virtuels exploitent les mêmes machines, ces dernières devront avoir une IP

spécifique pour chaque serveur virtuel pour éviter certains bogues. On peut utiliser pour cela des

interfaces réseaux virtuelles.

Cette façon de faire comporte les avantages et inconvénients suivants :

+ Possibilité d'avoir un pool de machines diff érent pour le HTTP et le HTTPS.

+ Possibilité d'utiliser deux algorithmes de répartition de charge diff érents pour le HTTP et pour le

HTTPS.

+ Possibilité d'avoir un monitoring spécifique pour chacun des deux protocoles.

+ Possibilité de désactiver une machine sur un service tout en la laissant fonctionnelle sur l'autre.

N écessite de déployer une interface réseau virtuelle sur les serveurs réels dans certains cas.

Configuration plus longue que la m éthode des firewall marks.

Consommation de ressources plus élevée, cela s'explique par le fait que LVS gère une table de

routage plus importante et qu'il y a plus de processus nanny pour monitorer les serveurs réels.

31



Installation de LVS :

L'installation des outils LVS se fait simplement à l'aide de la commande :

yum groupinstall Clustering

Il est nécessaire d'activer le fowarding de paquets en éditant le fichier /etc/sysctl.conf :

# Controls IP packet forwarding

net.ipv4.ip_forward = 1

Puis d'éditer les règles de firewalling à l'aide des outils system cong securityleveltui et iptables pour

ouvrir le port 3636 exploité par l'interface web de configuration « Piranha » et pour permettre le

forwarding de paquets.

Configuration de LVS :

La configuration de LVS sous CentOS se fait via l'interface web de Piranha.

Avant de lancer Piranha il faut configurer le mot de passe d'accès à l'aide de la commande :

piranha passwd

On peux maintenant lancer le daemon piranha gui :service piranha gui s tart

Maintenant il est possible d'accéder à l'interface web Piranha via l'URL : http ://192.168.0.1:3636

L'authentification se fait à l'aide du login « piranha » ainsi que le mot de passe définit

précédemment.

32



Voici la description des diff érents écrans de Piranha, des captures d'écrans plus propres sont

disponibles en annexe.

a) Onglet « CONTROL/MONITORING » :

Comme son nom l'indique, cette section permet le contrôle de l'état du serveur LVS, il n'y a rien à y

configurer.

b) Onglet « GLOBAL SETTINGS » :

Primary server public IP : adresse IP publique réelle du serveur LVS. Dans cas il s'agit d'une

adresse IP privée car notre répartiteur de charge est derrière un routeur/pare feu.

Primary server private IP : adresse IP d'une interface réseau alternative du serveur LVS, celle ci

sert à faire un lien heartbeat supplémentaire. On peut laisser ce champ vide.

Use network type : topologie du réseau, dans notre cas s'il s'agit d'un réseau en NAT.

NAT Router IP : adresse IP flottante de la passerelle NAT, les serveurs réels devront avoir cette IP

comme passerelle par défaut.

NAT Router netmask : masque sous réseau du NAT.

NAT Router device : interface réseau du LVS qui doit prendre l'IP de la passerelle NAT.

33



c) REDUNDANCY :

Redundant server public IP : adresse IP publique du serveur LVS de secours, le notre a une adresse

IP privée car il est dernière un routeur/pare feu.

Heartbeat Interval (seconds) : intervalle en secondes entre chaque vérification de l'état du serveurLVS principal, 6 secondes par défaut.

Assume dead after (seconds) : temps d'attente avant la prise de relais lorsque le serveur LVS

principal ne répond plus, 18 secondes par défaut.

Heartbeat runs on port : port de communication avec le serveur LVS principal, le port par défaut

est le 539.

d) VIRTUAL SERVERS :

Cette section permet de créer, supprimer, modifier, activer ou désactiver des serveurs virtuels.

Pour créer un serveur virtuel, il faut cliquer sur le bouton « ADD ».

34



e ) VIRTUAL SERVER :

Name : nom du serveur virtuel, on peut par exemple mettre le nom du service qu'il gère.

Application : port d'écoute du serveur virtuel, par exemple 80 pour le protocole HTTP.

Protocol : choix entre les protocoles TCP ou UDP, pour le HTTP/HTTPS il faut sélectionner TCP.

Virtual IP Address : adresse IP flottante du serveur virtuel.

Virtual IP Network Mask : Masque sous r éseau du serveur virtuel.

Firewall Mark : marquage utilisé pour grouper les ports de protocoles multiports ou ceux de

protocoles connexes comme le HTTP et le HTTPS.

Si on désire utiliser les firewall marks pour gérer le protocole HTTPS (approche serveur

virtuel multiports), on mettra la valeur 80 par exemple, puis il faudra appliquer les

règles « iptables » suivantes sur le serveur LVS :

/sbin/iptables t mangle A PREROUTING p tcp d n.n.n.n/32 dport 80 j MARK set mark 80

/sbin/iptables t mangle A PREROUTING p tcp d n.n.n.n/32 dport 443 j MARK set mark 80

n.n.n.n étant l'adresse ip flottante de notre serveur virtuel, dans notre cas par exemple :

192.168.0.100.

35



Device : interface réseau du serveur LVS sur laquelle sera définit l'adresse IP flottante du serveur

virtuel. Dans notre cas il s'agit de l'interface eth0:1

Re entry Time : temps avant lequel le serveur LVS essaie de réintégrer un serveur réel qui était

défaillant.

Service Timeout : temps après lequel un serveur réel qui ne répond plus est jugé défaillant.

Quiesce server : cette option permet d'éviter qu'un serveur réel qui vient d'être ajouté au pool ne soit

surchargé par un afflux important de requêtes lorsque l'algorithme least connections est utilisé.

Load monitoring tool : cette option active le contrôle de la charge des serveurs réel en utilisant rup

ou ruptime. Pour exploiter rup il faut activer le daemon rstatd sur les serveurs réels et pourruptime il faut activer le daemon rwhod.

Scheduling : algorithme utilisé pour la répartition de charge.

Persistence : période en seconde durant laquelle un mécanisme de persistance est appliquée à la

répartition de charge, si on ne veut pas de persistance on laisse le champ libre, dans notre cas,

l'utiisation d'un serveur NFS pour partager les données entres les diff érents serveurs web nous

permet de s'en passer.

Persistence Network Mask : Masque sous r éseau sur lequel s'applique la persistance, il est ainsi

possible de rediriger des plages d'adresses IP vers le même serveur réel.

36



f ) REAL SERVER

Dans cette section on peut ajouter, supprimer, modifier, activer ou désactiver des serveurs réels dans

notre pool.

Name : nom du serveur réel.

Adress : adresse IP du serveur réel.

Port : port du serveur réel.

Weight : ce paramètre permet d'affecter des poids aux serveurs réels et ainsi pouvoir jouer sur la

répartition de charge selon leur puissance.

37



g ) MONITORING SCRIPTS :

Cette section permet de configurer nanny pour le surveillance des diff érents services sur les

serveurs réels.

Nanny est capable d'effectuer un contrôle basique en envoyant une chaine de caractères préconfigurée aux serveurs réels, vérifiant ainsi la chaine de caractère de retour.

Sending programm : chemin de l'utilitaire appelé par nanny pour vérifier l'état des serveurs réels du

pool, le paramètre spécial %h est remplacé par l'adresse ip du serveur réel contrôé par nanny.

Pour tester le bon fonctionnement du service HTTPS nous avons codé notre propre utilitaire (cf

Annexe 3).

Send : message envoyé par nanny aux serveurs réels, à laisser vide si on utilise un programme

externe avec nanny.

Except : chaine de retour attendue dans le cas d'un fonctionnement normal.

Les paramètres par défaut conviennent très bien pour monitorer le protocole HTTP sur des serveurs

web. Il est cela dit possible de faire appel à un programme externe pour vérifier l'état d'un service.

Une fois notre serveur virtuel paramétré, il ne reste plus qu'à démarrer le service pulse :

service pulse start

38



Configuration du serveur LVS de secours :

Pour configurer le serveur LVS de secours il suffit de copier les fichiers /etc/sysconfig/ha/lvs.conf et

/etc/sysctl et /etc/sysconfig/iptables du serveur LVS principal. On peut utiliser pour cela la

commande scp.

Il ne reste plus qu'à démarrer le service pulse :

service pulse start

Configuration des serveurs réels

La dernière étape consiste à mettre l'IP de la passerelle NAT, dans notre cas 192.168.1.200, comme

passerelle par défaut sur les serveurs réels.

Pour peut utiliser pour cela l'utilitaire : system config network ( ou éditer manuellement le fichier /etc/sysconfig/networkscripts/ ifcfg eth0 )

39



2.3.2 Serveurs de base de données Mysql

Contrairement au serveur Web, les bases de données ne sont pas sous load balancer , nous n'avons

ici qu'un serveur de base de données qui répond à toutes les demandes et non deux serveurs sur

lesquels sont sont réparties les demandes. Toutefois, il est possible de mettre en place un deuxième

système de haute disponibilité (LVS, HAproxy) qui permet de surveiller l'état des serveurs et ainsi

permettre à un autre serveur de prendre la main (Schéma ci dessous). Mais par manque de machinesdisponibles, nous ne mettrons pas en place ce système.

Pour compenser ce problème, nous avons installé deux serveurs MySQL, un principal et un second

qui en fait la réplication. Couplé à l'utilisation de « DRBD », cela nous permet donc d'avoir toujours

un serveur à jour qui est en plus capable de prendre le relais en cas de défaillance du serveur

principal.

40

Illustration 21: Mise en place possible d'un syst ème d' é quilibrage de charge pour les serveurs MySQL



MySQL Cluster

Nous avons donc mis en place la méthode de réplication proposée par MySQL, en voici les étapes :

SUR LES DEUX SERVEURS MYSQL

Installation :

On fera une installation normale avec les partitions qu'on souhaite, la seule diff érence réside dans

le fait qu'on va laisser un espace non partitionné pour l'utilisation avec « DRBD », on recommande

d'utiliser des machines de même capacité et deux cartes réseau pour chaque machine.

Dans ce cas, on a configuré des partitions comme les suivantes pour un disque dur de 40Go :

Périphérique Point de montage Capacité

/dev/hda1 / 10Go [10240 Mo]

/dev/hda3 swap 1Go [1024 Mo]

/dev/hda2 Linux LVM 26,3 Go [26882 Mo]

Nous avons juste installé le système d'exploitation, « OpenSSH » et « MySQL Server ».

_________________________

Configuration :

Pour avoir une meilleure compréhension du texte, nous allons utiliser le vocabulaire suivant :

Serveur – chacune des machines sur lesquels fonctionne « DRBD » et les services de haute

disponibilité ( MySQL et Heartbeat ).

Serveur primaire – le serveur qui contient les données à lire/ écrire, il est le serveur actif.

Serveur secondaire – le serveur sur lequel les données sont répliquées.

Cluster – ensemble des serveurs qui partagent une baie de disques commune, pour assurer une

continuité de service et/ou repartir la charge de calcul et/ou la charge réseau. On parle de cluster

actif actif ou actif passif.

La configuration réseau pour les serveurs se fera de la manière suivante :

Serveur 1 Serveur 2

Nom du serveur mysql01 mysql02

Ip eth0 192.168.1.201/24 192.168.1.202/24

Ip eth1 10.1.1.31/24 10.1.1.32/24

Il est important de nommer6 les serveurs, car nous auront besoin des noms pour la suite.

6 Il est possible de renommer une machine via la commande hostname ou de vérifier le nom courant avec uname n .

41



Il faut aussi permettre la communication entre les deux serveurs sur les ports suivants :

Service Port

MySQL 3306

DRBD 8888

Heartbeat 694

Il arrive souvent que « SELinux » qui est une politique de sécurité sous Linux soit activé par défaut

sur « CentOS » cela crée des problèmes avec « heartbeat », pour le désactiver il faut réaliser des

modifications dans le fichier « /etc/selinux/config », et réaliser la modification de

« SELINUX=disabled », les changements seront appliqués au prochain démarrage du serveur.

_________________________

Installation et configuration de DRBD :Nous avons décidé d'utiliser « DRBD », car c'est l'une des méthodes préconisée sur le site officiel

de « MySQL » pour la réplication, les avantages de cette solution sont les suivants :

Réplication des donnés en temps réel La réplication se produit pendant même que des

applications sont en train de modifier les données sur le périphérique.

Réplication transparente Les applications qui stockent leurs données sur le périphérique ne sont

pas « conscientes » du fait que les données soient stock ées sur plusieurs ordinateurs.

Le principal inconvénient de « DRBD » est qu'il n'est pas capable de détecter automatiquement la

corruption du système de fichiers.

Pour ne pas surcharger le rapport, nous avons mis le reste de la configuration en annexe (cf.

Annexe 2).

42



On obtient donc une réplication entre les serveurs en temps réel. Ainsi lorsque le serveur ma î tre

reçoit un ordre de modification, d'ajout ou de suppression, le serveur esclave exécute instantanément

la même instruction grâce à un système de logs binaires entretenu par Mysql.

Nos serveurs Web et nos serveurs MySQL étant branchés sur le même switch, nous avons donc eu

besoin de deux cartes réseau sur nos serveurs MySQL pour permettre l'utilisation de « DRBD ».

Ainsi le trafic qu'entra î ne la réplication de la base ne perturbe en rien le reste du réseau.

De plus grâce à cette pratique, nous avons maintenant une solution de haute disponibilité pour les

serveurs de base de données, en effet « DRBD » couplé à « heartbeat » permet d'attribuer l'adresse

IP virtuelle du serveur défaillant à celui qui est en attente (mais tout de même à jour).

43

Illustration 22: Sché ma de flux gé né r é pour la r é plication de la base de donné es.



2.3.3 Configuration du NFS

Nous avons utilisé un serveur NFS pour centraliser le contenu et la configuration des serveurs Web.

Cette façon de faire offre plusieurs avantages :

–Uniformisation de la configuration des serveurs Apache.

–Partage des fichiers du site Web entre les diff érents serveurs Web, ce qui simplifie les mises à jour.

–

Partage des sessions PHP entre les diff érents serveurs Web.

Certains éléments n'ont pas été centralisés sur le serveur NFS, comme :

–Les fichiers de log des serveurs Apache.

–Les modules Apache.

Il est important de noter que nous utilisons ici la version 4 du protocole NFS car cette version

apporte des évolutions majeures :

–Chiffrement et sécurisation (support de Kerberos5, certificats SPKM et LIPKEY).

–Support accru de la montée en charge (réduction du trafic par groupement de requêtes ,

délégation).

–Systèmes de maintenance simplifiés (migration, réplication).

–Reprise sur incidents.

–Utilisation du protocole TCP au lieu d'UDP.

Mise en place du serveur NFS

On commence par installer NFS à l'aide de la commande :

yum install nfs utils nfs utils lib

Par la suite on crée un répertoire /nfs qui contiendra les fichiers partagés avec nos serveurs web. On

monte ce même répertoire sur lui m ême en ajoutant cette ligne au fichier /etc/fstab :

/nfs /nfs none bind 0 0

Explication des options :

none : indique qu'il n'y pas de système de gestion de fichier, /nfs étant un répertoire local.

bind : option de montage permettant de monter plusieurs fois le même répertoire.

0 0 : indiquent respectivement la fréquence de sauvegarde de la parition et l'odre dans lequel

l'utilitaire fsck vérifie les partitions.

et on applique le montage à l'aide de la commande :

mount a

Puis on partage le répertoire /nfs avec les serveurs web en ajoutant cette ligne dans le fichier

/etc/exports :

Point de montage IP (options)

/nfs 192.168.1.0/24 (rw,fsid=0,insecure,no_subtree_check,sync)

/nfs/www 192.168.1.0/24 (rw,fsid=0,insecure,no_subtree_check,sync)

/nfs/httpd 192.168.1.0/24 (rw,fsid=0,insecure,no_subtree_check,sync)

/nfs/php 192.168.1.0/24 (rw,fsid=0,insecure,no_subtree_check,sync)

Pour finir, on lance le service nfs :

service nfs start

44

http://fr.wikipedia.org/w/index.php?title=SPKM&action=edit&redlink=1

http://fr.wikipedia.org/w/index.php?title=LIPKEY&action=edit&redlink=1

http://fr.wikipedia.org/w/index.php?title=SPKM&action=edit&redlink=1

http://fr.wikipedia.org/w/index.php?title=LIPKEY&action=edit&redlink=1



Explication 7 :

On va partager sur le réseau 192.168.1.0 les répertoires /nfs/* en lecture écriture.

–rw : lecture écriture.

– fsid=0 : identifie l'utilisateur du système de fichier en tant que root.

–insecure : permet de désactiver l'obligation de l'utilisation d'un port (inf érieur à 1024) pour

l'émission de la requête.

–no_subtree_check : désactive la vérification des sous répertoires, ce qui permet de gagner en

performance ainsi que la fiabilité dans certain cas.

–sync : la réponse aux demandes de ressources se fera après l'application des changements sur le

support (écriture sur le disque). Cela permet d'éviter la corruption des données lors d'un arrêt

inopiné du serveur.

Mise en place du NFS sur les serveurs Web

Configuration du nfs

Fichier /etc/fstab :

Périphérique Point de

montage

SGF Option de

montage

Fréquence de sauvegarde de

la partition (utilitaire dump)

Ordre de vérification de la partition

(utilisé par fsck)

192.168.1.5:/ /mnt nfs4 _netdev,auto 0 0

Explication des options :Périphérique : on spécifie l'adresse IP du serveur NFS.

SGF : il s'agit du protocole nfs en version 4.

Point de montage : on va monter localement les répertoires partagés du nfs dans /mnt.

Option de montage :

– _netdev : le montage de la partition s'effectue seulement si le service réseau est démarré.

– auto : le montage est automatiquement effectué au démarrage de la machine.

On monte les partitions réseau sur chaque serveur réel à l'aide de la commande :

mount a

Après cette étape il reste à déployer des liens symboliques pointant vers les répertoires réseaux.

7 De plus amples explications sont disponibles sur le site: http://sylvain.cherrier.free.fr/documentations/exports.5.html

45

http://sylvain.cherrier.free.fr/documentations/exports.5.html

http://sylvain.cherrier.free.fr/documentations/exports.5.html



Mise en place des liens symboliques :

Après avoir installé les diff érents services nécessaires (httpd, php, php_mysql, mod_ssl) sur le

serveur Web, il faut supprimer les répertoires des configurations et du contenu web. (avec la

commande rm Rf <repertoire>).

Ensuite on remplace les dossiers et les fichiers supprimer par un lien symbolique.

Commande des liens :

ln s /mnt/www /var ln s /mnt/httpd /etc

ln s /mnt/php/config/php.ini /etc/

ln s /mnt/php/config/php /etc/

ln s /mnt/php/session /etc/lib/php/

Lien symbolique : il s'agit d'un fichier particulier pointant vers un fichier ou un répertoire.

Note :

Il faut penser à ouvrir les ports utilisés par le protocole NFS dans la configuration du firewall des

diff érents serveurs web.Pour configurer le pare feu on utilise l'utilitaire « sysconf security level ».

46

Illustration 23: Ré capitulatif des interactions

entre le serveur NFS et les serveurs Web



system config network

Montage et configuration de(s) carte(s) réseaux :

Modification dans le fichier : /etc/sysconfig/network scripts/ifcfg eth0

#Nom du périphérique

DEVICE=eth0BOOTPROTO=static

HDADDR=MAC

ONBOOT=yes

NETMASK=255.255.255.0

IPADDR=192.168.1.3

Type=Ethernet

GATEWAY=192.168.1.254

Ajout de certificat auto sign é sur le NFS :

Via la commande « openssl » on peut générer des certificats, voici les commandes effectuées :

Génération du certificat :

openssl genrsa des3 out ma_cle.key 1024

Avec « des3 » étant le type de chiffrement choisis et 1024 la taille en bits d'encryptage de la clé.

On obtient donc un fichier « ma_cle.key » contenant une clé dite « forte ».

Génération de la demande de signature :

openssl req new key ma_cle.key out ma_demande.csr

Auto signature :

openssl x509 in ma_demande.csr out mon_certif.crt req signkey ma_cle.key days 99

l'option « days 99 » indique que le certificat sera valide 99 jours

Nous obtenons donc un certificat auto sign é placé sur notre serveur NFS, ainsi les serveurs Web qui

reçoivent des requêtes de la part d'internautes récupèrent les certificats sur le serveur de partage

grâce à l'architecture mise en place.

On obtient donc un certificat commun à tout les serveurs Web qui permet de sécuriser la connexiondes utilisateurs au lieu d'avoir un certificat pour chaque serveur.

47



2.3.4 Mise en place du SSL

Pour mettre en place une connexion sécurisée, nous avons activé le module SSL des serveurs Web

(a2enmod mod_ssl). En activant ce module Apache sous CentOS modifie directement le fichier qui

configure l'accès à nos sites internet et y ajoute une partie pour le SSL (sur le port 443).

Grâce à l'utilisation d'un lien symbolique vers le point de montage du serveur NFS, on fait pointer laclé et le certificat comme si on travaillait localement.

Il ne reste plus qu'à renseigner le chemin de la clé et du certificat.

Fichier « virtualhosts.conf »

ServerName www.maboutique.com

NameVirtualHost *:443NameVirtualHost *:80

<VirtualHost *:80><Directory /var/www/html>AllowOverride All</Directory>DocumentRoot /var/www/html

</VirtualHost>

<VirtualHost *:443>SSLEngine onSSLCertificateFile /etc/httpd/ssl/mon_certif.crtSSLCertificateKeyFile /etc/httpd/ssl/ma_cle.key

<Directory /var/www/html>

AllowOverride All</Directory>

DocumentRoot /var/www/html</VirtualHost>

48



3 Analyse

3.1 Benchmark / Graphiques

Pour tester les performances de notre installation il nous est nécessaire d'automatiser et de simuler

de nombreuses connexions simultanées. Pour cela nous allons utiliser un logiciel de benchmark et

de simulation de requêtes massives. Ce programme prend en compte les éléments que l'on va lui

passer en paramètres afin de mesurer les performances d'un système pour ensuite les comparer.

Pour tester un serveur Web l'important n'est pas de savoir en combien de temps la page sera charg ée

car cela dépend en majeure partie du débit du client, on ne peut pas prévoir si un client sera en

56Kbps ou en 10Mbps. L'important est de savoir quel est le temps moyen que va mettre le serveur

pour répondre à un nombre élevé d'utilisateurs connectés simultanément. Il est donc nécessaire de

voir le comportement du serveur par rapport à l'accroissement du nombre d'utilisateurs.

Le tableau suivant tiré d'un livre sur le load balacing écrit par Tony Bourke nous donne une idée

des éléments que nous prenons en compte pour nos évaluations :

Type de traficParamètre le plus

important

Deuxième paramètre

important

Paramètre le moins

important

HTTP (statique)Nombre de connexions

par secondeDébit

Nombre de connexions

persistantes

FTP / Streaming Débit


persistantes


par seconde

Site de vente en

ligne


persistantes


par secondeDébit

Parmi les nombreux outils de mesures existants, nous avons choisis « Siege » qui nous permet de

« stresser » l'adresse vers laquelle se trouvent les sites ; ce logiciel nous donne également des

statistiques sur le nombre de requêtes envoyées, réussies, échouées, le taux de transfert, ...

D'un autre côté nous avons utilisé un logiciel de supervision réseau : Zabbix.

Cet outil ne nous sert pas qu'à surveiller la santé des services et du matériel des machines, mais

aussi à réaliser nos graphiques afin d'illustrer nos simulations.

49



3.2 Analyse des graphiques

Afin de réaliser nos testes, nous avons donc utilisé Siege avec la commande et les paramètres

suivants: siege r1 c50 t5 <URL>

r1 étant le nombre de requêtes simultanées (ici une seule)

c50 le nombre de connexions de clients simultan és (50 clients)t5 le temps de dur ée du siège (5 minutes)

Nous avons donc testé tout nos scénarios avec ces paramètres. Pour se rendre compte de la charge

générée, cela signifie que toute les secondes pendant 5 minutes, 50 clients vont envoyer 1 requête,

soit un total de 15000 connexions et requêtes envoyées à nos serveurs.

Pour illustrer les usages mémoire, de load , réseau, nous avons utilisé Zabbix et généré des

graphiques pour chaque scénario. En voici nos résultats et leurs interprétations.

50



Comparaison de la charge ( Load )

HTTP STATIQUE HTTPS STATIQUE HTTP LOURD HTTPS LOURD HTTP DYNAMIQUE HTTPS DYNAMIQUE

Analyse : Sur ces graphiques, on peut voir que la charge est insignifiante pour la page statique et la page lourde en HTTP, en revanche une page

dynamique demande plus de traitement et donc de charge. Le serveur n°4 avec sa configuration plutôt faible fait monter en flèche son load average .

Pour la page statique en HTTPS, on voit que quelques traitement sont nécessaire et que le serveur n°4 à encore une fois du mal à faire répondre son

agent Zabbix à cause de sa charge. Pour ce qui est de la page dynamique (OSCOMMERCE) en HTTPS, la charge est moins élevée car les serveurs Web

répondent à moins de requêtes dans ce même laps de temps (perte de temps à cause du calcul des transactions chiffrées). Pour les pages HTTP/S

LOURD, la bande passante nous freine, il s'agit ici d'un goulot d'étranglement.



Comparaison de la consommation de mémoire vive (RAM)

HTTP STATIQUE HTTPS STATIQUE HTTP LOURD HTTPS LOURD HTTP DYNAMIQUE HTTPS DYNAMIQUE

Analyse : Comme on peut le voir clairement sur le graphique, la consommation de mémoire vive est liée directement à la nature du document traité. En

effet, une page statique classique n'est pas très gourmande en RAM, une page contenant une image d'un poids élevé non plus. En revanche, un contenu

généré dynamiquement nécessite bien plus de ressources (nombreuses variables à calculer).



3.3 Analyse des algorithmes de r é partition de charge

Nous nous sommes essentiellement focalisés sur l'analyse des algorithmes les plus répandus : le

« Round Robin » et le « Least Connection Scheduling ».

a) Round Robin :

Cet algorithme répartition fonctionne de manière cyclique, sans se préoccuper de la charge des

serveurs. La première requête sera affectée au 1er serveur, la seconde au second serveur, ainsi de

suite en boucle.

On a ainsi remarqué que sur des traitements lourds, comme par exemple des requêtes HTTPS. Le

serveur le moins puissant (ici le serveur 4) se retrouve avec un nombre de connexion actives plus

important que les autres car il prend plus de temps à exécuter les requêtes.

Ce phénomène peut donc causer des disparités de charge entre les serveurs réels selon leurs

ressources et le type de requêtes que chacun d'eux a à gérer.

Pour ce qui est des disparités liées à la puissance des machines, il est possible de régler ce problème

en utilisant l'algorithme « Weighted Round Robin Scheduling » qui permet d'affecter des poids aux

diff érents serveurs réels.

53

Illustration 24: Ré partition de requêtes HTTPS avec Round Robin.

Illustration 25: Ré partition de charge avec Weighted Round Robin.



b) Least Connection Scheduling

Cet algorithme de répartition renvoie toute nouvelle requête au serveur possédant le moins de

connexions actives.

Le « Least Connection Scheduling » montre de très bons résultats en général mais peut montrer ses

limites lors d'une augmentation subite et rapide de la charge avec des connexions non persistantes

(connexions HTTP sans keepalive).

54

Illustration 26: Impacte d'une mont é e en charge subite avec "Least Connection".



3.4 Single Point Of Failure

Un point individuel de défaillance (Single Point of Failure ou SPOF en anglais) est un point d'un

système informatique dont le reste du système est dépendant et dont une panne entra î ne l'arrêt

complet du système. Le point individuel de défaillance a comme principale caractéristique de ne pas

être protégé (redondant). Il est donc un risque pour la disponibilité du système.

La notion de point individuel de défaillance est fortement liée à celle de service, dans la mesure où

un problème sur le point concerné entra î ne une interruption de service. La présence de SPOF dans

un système augmentant la probabilité d'apparition d'un déni de service, elle entra î ne un risque sur la

qualité de service.

Dans un cadre de haute disponibilité, il est inacceptable de laisser des points individuels de

défaillance dans un système.

Ainsi au cours de nos testes, nous nous sommes rendus compte que les points de défaillance de

notre installation étaient les éléments d'interconnexion réseau (switch) qui ne sont pas redondés, si

nos switch viennent à ne plus fonctionner, aucun élément actif ne va prendre le relais pour continuer

à router normalement les machines. Il en est de même pour notre serveur NFS qui n'est pas redondé

que ce soit par du RAID ou par un système de répartition de charge et qui peut également devenir un

goulot d'étranglement. La façon la plus présentable pour le partage de fichiers serait de mettre en

place un SAN8.

Pour corriger cela, nous pouvons utiliser un élément de rechange (en anglais spare) qui sera un

switch dé jà configuré et prêt à remplacer l'ancien. Nous pouvons également penser à surveiller tout

nos matériels grâce à un logiciel de supervision comme Zabbix ou Nagios afin de pouvoir répondre

au plus vite aux pannes.

Autre faille, un goulot d'étranglement se situe entre les internautes qui demandent l'accès au site et

le routeur qui reçoit ces requêtes. On peut aisément imaginer que dans le cas d'un afflux massif de

requêtes la quantité de données soit supérieure à la capacité de la bande passante et de la carte

réseau du routeur. Il existe un autre goulot d'étranglement entre notre serveur NFS et nos serveurs

Web, en effet le serveur de partage est autant sollicité que le routeur.

Contre ce goulot d'étranglement, il faut dé jà vérifier la capacité des cartes réseaux du routeur et

penser à installer des cartes réseau avec une capacité dépassants les classiques 10/100 Mbps. La

connexion établie entre le routeur (comprendre l'entreprise) et les clients (Internet) doit aussi êtred'une capacité importante. Bien entendu ces décisions dépendent du trafic Internet vers les serveurs

de notre entreprise.

Il faut donc prendre en compte ces points et essayer de les résoudre. Par manque de temps et de

matériels nous ne pourront pas les mettre en place, mais nous allons supposer que dans notre

environnement restreint, cela ne sera pas nécessaire.

8 http://fr.wikipedia.org/wiki/Storage_Area_Network

55

http://fr.wikipedia.org/wiki/Storage_Area_Network

http://fr.wikipedia.org/wiki/Storage_Area_Network



4 Conclusion

Comme nous l'avons démontré tout au long de ce rapport, nous pouvons maintenant affirmer que la

haute disponibilité permet un gain de confort pour les utilisateurs finaux tout comme pour les

administrateurs du systèmes.

En effet les utilisateurs finaux ont un accès constant au site, et surtout ils ne voient pas lesdéfaillances d'un ou plusieurs serveurs via lesquelles sont réparties les charges.

Quand à l'administration, nous avons vu que la solution LVS éditée par RedHat s'avère très efficace,

permettant un déploiement rapide et flexible. De plus, l'application « Piranha » apporte une certaine

sécurité car elle prémunit des erreurs de syntaxe liées à une édition manuelle des fichiers de

configuration.. Grâce au système de cluster mis en place, il est également plus simple pour un

administrateur de rajouter ou d'enlever des machines, puisque le pool peut se manipuler « à chaud »

et donc ne requiert pas l'arrêt des machines en production.

La répartition de charge permet de résoudre des problématiques de gestion des ressources, deperformances et de tolérance aux pannes.

L'algorithme « Round Robin » s'avère la meilleure solution pour des serveurs à de fortes variations

de charge, il est donc plus adapté pour des serveurs web. Tandis que l'algorithme « Least

Connection » se montre idéal pour des sessions longues (connexion HTTP 1.1 persistantes) et des

serveurs ne subissant pas de fortes variations de charge.

Pour garantir une disponibilité maximale, il est nécessaire d'implémenter des mécanismes

permettant de synchroniser ou de centraliser les données et les sessions entre les diff érents serveurs

réels et de mettre en place une réplication des bases de données.

Pour finir, la répartition de charge à elle seule ne permet pas d'accomplir des miracles et de combler

les carences d'une application mal écrite (lente, coûteuse en ressource) ou d'une architecture mal

pensée qui générera invariablement des problèmes dans les flux réseaux.

56



5 Bibliographie

● Livres :

Tony Bourke Server Load Balancing O'Reilly 2001

Willy Tarreau, Wilfried Train Le Load Balancing pour les nuls First Interactive 2010

● Sources Internet :

http://www.centos.org/docs/5/html/5.1/pdf/Virtual_Server_Administration.pdf

● Ré capitulatif des logiciels utilisé s :

Système d'exploitation : CentOS (RedHat)

Serveur de base de données : MySQL / DRBD

Serveur Web : Apache2

Serveur de stockage de données : NFS

Logiciels de monitoring et interface d'administration : Zabbix, Piranha

Solutions d'équilibrage de charges : LVS, Heartbeat

Administration à distance : OpenSSH

Solution de pare feu et de routage : Iptables

Outils de benchmark et de génération de graphiques : siege, Zabbix, lovelycharts

57





6 Annexes

Sommaire des annexes

Annexe 1 : Présentation de Piranha ..................................................................................................

Annexe 2 : Installation de DRBD et MySQL Cluster ......................................................................

Annexe 3 : Utilitaire pour le HTTPS ................................................................................................

Annexe 4 : Répartition du temps de travail ......................................................................................

58



Annexe 1 : Présentation de Piranha

Illustration 27: Exemple de configuration du « load balancer »via Piranha



Illustration 28: Liste des serveurs r é els et leur é tat



Illustration 29: É cran de contr ôle de la redondance du service Heartbeat



Annexe 2 : Installation de DRBD et MySQL Cluster

Toutes les instructions ci dessous doivent être faites sur les deux serveurs sauf indication contraire.

Pour la mise en place de la réplication, il faut installer les paquets « drbd » et « kmod drbd » qui setrouvent dans les dépôts de « CentOS ». Il y a aussi la possibilité de faire l'installation manuelle

depuis les paquets.

# yum install drbd

# yum install kmod drbd

Une fois les paquets installés, il faut copier le fichier de configuration de « DRBD » vers le

répertoire /etc, sachant que la version de « DRBD » peut changer en fonction de la version dusystème d'exploitation.

# cp /usr/share/doc/ drbd 8.0.16 /drbd.conf /etc/drbd.conf

Après avoir déplacé le fichier de configuration, il faut enlever les commentaires des lignes suivantes

dans le fichier /etc/drbd.conf et changer shared string pour le mot de passe souhaité.

cram-hmac-alg "sha1";shared-secret "shared-string";

On utilise ces lignes pour avoir une authentification simple avec mot de passe crypté par « sha1 »,

ce qui assure que seuls les serveurs avec le même mot de passe soient capables de se joindre au

groupe.

Le fichier de configuration de « DRBD » /etc/drbd.conf doit être le même sur les deux serveurs,

sachant que l'on a respecté les contraintes d'installation.

• On utilise le port 8888 sur les IP : 10.1.1.31 et 10.1.1.32 pour la communication réseau.

• les ressources sont configurées pour une réplication synchrone (Protocol C ).

• On a utilisé une ressource appelée « r0 » laquelle utilise /dev/hda2 comme périphérique de

stockage de bas niveau, et est configuré comme méta donn ée interne.

Vous trouverez ci dessous le fichier de configuration utilis é ainsi que sa description.

62



Fichier de configuration « DRBD »

global {usage-count no;

}

common {syncer { rate 100M; }

}

resource r0 {procotcol C;

handlers {pri-on-incon-degr "echo o > /proc/sysrq-trigger ; halt -f"pri-lost-after-sb "echo o > /proc/sysrq-trigger ; halt -f"local-io-error "echo o > /proc/sysrq-trigger ; halt -f"outdate-peer "/usr/lib/heartbeat/drbd-peer-outdater";

}

startup {degr-wfc-timeout 120; #2 minutes

}

disk {on-io-error detach;fencing resource-only;

}

net {cram-hmac-alg "sha1";shared-secret "shared-string";

after-sb-0pri disconnect;after-sb-1pri disconnect;after-sb-2pri disconnect;rr-conflict disconnect;

}

syncer {rate 10M;al-extents 257;

} on mysql01 {device /dev/drbd0;disk /dev/hda2;address 10.1.1.31:8888;meta-disk internal;

}

on mysql02 {device /dev/drbd0;disk /dev/hda2;address 10.1.1.32:8888;meta-disk internal;

}

}

63



Les sections principales sont décrites, pour une description plus approfondie il faut vérifier la

documentation dans la page officielle de « DRBD ».

La section « global »

Cette section est permise une seule fois dans le fichier de configuration, l'option usage count est

utilisée pour stocker des statistiques sur l'usage des plusieurs versions de DRBD, en contactant un

serveur HTTP chaque fois qu'une nouvelle version de DRBD est installée sur le système. On peut ledésactiver en utilisant « usage count no; », l'utilisation par d éfaut est « usage count ask; » lequel

vous invite à chaque fois de mettre à jour « DRBD ».

La section « common »

Cette section fournit une méthode plus rapide pour définir une configuration à travers de l'héritage,

pour chaque ressource on peut définir n'importe quelle option, mais aussi définir ou redéfinir des

ressources de base (remplacer les commandes standard par des commandes prenant dé jà en compte

des options).

L'utilisation de la section « common » n'est pas nécessaire mais il est recommandé de l'utiliser si onutilise plus d'une ressource.

Dans notre fichier de configuration on a ajouté l'option syncer{ rate 10M; };

La section « resource »

N'importe quelle ressource qu'on définit devrait être appelée avec « resource nom » dans le fichier

de configuration. On peut utiliser un identifiant arbitraire, le nom d'une ressource ne peut pas

contenir d'espaces et ne doit contenir que des caractères « US ASCII ».

Chaque ressource doit avoir au moins deux sous sections « host » (une pour chaque serveur du

cluster ).

Comme « hearbeat » prends le contrôle du cluster il est nécessaire de changer les permissions sur

les binaires de « DRBD » :

chgrp haclient /sbin/drbdsetup

chmod o x /sbin/dbrdsetup

chmod u+s /sbin/dbrdsetup

chgrp haclient /sbin/drbdmeta chmod o x /sbin/dbrdmeta

chmod u+s /sbin/dbrdmeta

Il faut ensuite créer les méta donn ées pour les périphériques.

# drbdadm create md all

Afin de finaliser la configuration de « DRBD », il faut charger le module dans le noyau.

# modprobe drbd

64



Maintenant on peut démarrer le service « DRBD » et définir le serveur primaire.

Commandes à saisir seulement sur le serveur primaire :

# drbdadm overwrite data of peer primary all

Pour pouvoir utiliser la partition, il faut formater le périphérique « DRBD » (normalement ce qu'on

a utilisé dans la configuration), dans notre cas « /dev/drbd0 ».

# mkfs.ext3 /dev/drbd0

Une fois le périphérique formaté, il faut le monter sur la route souhaitée.

# mkdir /mnt/drbd

# mount /dev/drbd0 /mnt/drbd

65



Configuration de « mysql » pour utiliser la synchronisation

Sur le serveur primaire on va créer un répertoire pour loger les données de « MySQL » et copier le

fichier de configuration principal « my.cnf » dans le répertoire créé.

# mkdir /mnt/drbd/mysql

# cp /etc/my.cnf /mnt/drbd/mysql

Puis, il faut copier le répertoire où sont stock ées les bases de données vers un répertoire monté du

périphérique « DRBD ».

#cp R /var/lib/mysql /mnt/drbd/mysql/data

Maintenant il faut configurer notre serveur primaire, pour cela, nous allons éditer le fichier« /mnt/drbd/mysql/my.cnf » pour changer le répertoire des base de données, il faut aussi activer le

journal binaire, avec l'option « log bin ».

datadir = /drbd/mysql/datalog-bin = mysql-bin

Pour finaliser la configuration, on va créer un lien symbolique vers le nouveau fichier de

configuration.

# ln s /drbd/mysql/my.cnf /etc/my.cnf

Maintenant on peut démarrer le serveur « MySQL » et vérifier que la nouvelle configuration

marche bien.

# /etc/init.d/mysql start

Note : Pour le serveur secondaire, il faut seulement cr é er le lien symbolique car la configuration

sera r é pliqué e, il est inutile d'essayer d'utiliser le pé riphé rique sur le serveur secondaire parce qu'

il n'est pas disponible pour l'utilisation.

66



Installation et configuration de « heartbeat »

Pour CentOS, installer les paquets suivants :

# yum install heartbeat

# yum install heartbeat pils

# yum install heartbeat stonith

Vérifier que le répertoire « /etc/ha.d » soit créé, sinon, il faut le créer :

#mkdir /etc/ha.d

Après il faut déplacer les fichiers d'exemples vers « /etc/ha.d » :

#cp /usr/share/doc/heartbeat 2.1.2/authkeys /etc/ha.d/

#cp /usr/share/doc/heartbeat 2.1.2/ha.cf /etc/ha.d/

#cp /usr/share/doc/heartbeat 2.1.2/haresources /etc/ha.d/

Le fichier de configuration principale « ha.cf » doit ressembler à celui ci :

debugfile /var/log/ha-debuglogfile /var/log/ha-log

logfacility local0keepalive 500msdeadtime 10warntime 5initdead 30mcast bond0 225.0.0.1 694 2 0mcast bond1 225.0.0.2 694 1 0auto_failback onrespawn hacluster /usr/lib/heartbeat/dopapiauth dopd gid=haclient uid=haclusternode mysql01node mysql02

Pour la modification du fichier « authkeys », il faut seulement fixer l'autorisation d'accès aux

informations au cluster . Le fichier utilise une clé unique pour identifier les membres du cluster et

pour assurer la coexistence de plusieurs clusters dans le même réseau.

67



Pour le contrôle automatique des services « DRBD » et « MySQL » il faut ajouter une ligne dans le

fichier « /etc/haresources », cette ligne est formatée par le biais « d'espaces » :

mysql01 drbddisk Filesystem::/dev/drbd0::/mnt/drbd::ext3 mysql 192.168.1.6

– le premier paramètre (mysql01) est le nom du serveur primaire, qui est actif et gère le service,

– le deuxième est le service « DRBD » (drbddisk ) suivi du périphérique, le point de montage et le

type de système de fichiers,

– suit le service (mysql) qui fait réf érence à un script qui se trouve dans le répertoire

« /etc/ha.d/resources.d/ »,

– finalement on ajoute l'adresse IP virtuelle qui sera automatiquement attribuée au serveur

lorsque « heartbeat » démarre.

Une fois que la configuration de « heartbeat » est achevée, il faut copier les fichiers « ha.cf ,

haresources et authkey » vers le serveur secondaire pour s'assurer que la configuration est bien la

même.

Attention, le fichier « authkeys » doit être en lecture/ écriture pour root seulement :

#chmod 600 /etc/ha.d/authkeys

#chown root /etc/ha.d/authkeys

Note : Dé sactivation de SELinux sur les deux machines né cessaires, car cela cr é e des problèmes

avec « heartbeat ». Pour cela dans « /etc/selinux/config », il né cessaire de r é aliser la modification

suivante « SELINUX=disabled » et de red é marrer le serveur pour que cela soit effectif.

68



Annexe 3 : Utilitaire pour le HTTPS

Voici le code de l'utilitaire que nous avons écris pour vérifier l'état du service HTTPS :

#!/usr/bin/python

#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~## #

# Utilitaire de test du service HTTPs #

# #

#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#

import sys

import urllib2

url = "https://"+sys.argv[1]

req = urllib2.Request(url)

try:handle = urllib2.urlopen(req)

print "OK"

except:

print "FAIL"

69



Annexe 4 : Répartition du temps de travail

Pour permettre un bon avancement dans ce projet, nous nous sommes répartis les tâches au fur et à

mesure. Nous avons donc commencé par une rédaction d'un état de l'art comme nous l'a conseillé

notre tuteur de projet.

Nous avons ensuite essayer de voir notre tuteur au moins une fois par semaine afin de visualiser lesfaiblesses de notre rapport ainsi que les approches auxquelles nous n'aurions pas forcement penser.

Chaque fin de semaine nous avons noté ce que a été réalisé et par qui :

70

Illustration 30: Tableau r é capitulatif des t âches effectué es.

Nom Date de début Date de fin Ressources

Début de l'état de l'art 25/01/10 29/01/10 Michaël, Jose, Thierry

Conception Schéma 25/01/10 26/03/10 Thierry

Installation CentOS 28/01/10 29/01/10 Michaël, Jose, Thierry, Nassim

Recherche de solution 01/02/10 05/02/10 Michaël, Jose, Thierry

Mise en place LVS 01/02/10 05/02/10 Nassim

Mise en place serveur Web 01/02/10 05/02/10 Nassim

Correction Ajout Rapport 01/02/10 26/03/10 Micha ël, Thierry

Mise en place BDD 08/02/10 19/02/10 Jose

Mise en place NFS 08/02/10 19/02/10 Nassim

Reconfiguration LVS 12/02/10 19/02/10 Nassim

Reconfiguration serveurs Web 12/02/10 19/02/10 Nassim

Réplication DRBD 01/03/10 11/03/10 Jose

Réinstallation Poste BDD 01/03/10 05/03/10 Jose, Nassim

Rapport DRBD 01/03/10 11/03/10 Jose

Reconfiguration serveur Web 11/03/10 12/03/10 Jose, Thierry, Nassim

Reconfiguration BDD 11/03/10 12/03/10 Jose

Mise en place nouveaux serveurs Web 11/03/10 12/03/10 Thierry, Nassim

Rapport MySQL Haute Dispo 15/03/10 19/03/10 Jose

Finition Rapport 22/03/10 26/03/10 Michaël, Jose, Thierry, Nassim

Évaluation des performances & Analyses 22/03/10 26/03/10 Michaël, Jose, Thierry, Nassim

Documents

Equilibrage_DeCharge