3.3 Concepts de répartition de charge réseau
(Load Balancing)
3.3.1 Présentation
Après avoir fait l'analyse et adopté les types
de cluster à implémenter,avant de passer à la phase de
conception il est important pour nous de maitriser le fonctionnement de
certains concepts comme le Load Balancing entre les noeuds du
cluster.
Une fois le cluster monté, une montée en charge
équivalente au nombre grandissant d'utilisateur se fera ressentir. Pour
assurer cette montée en charge plusieurs méthodes peuvent
être envisageables :
* Augmenter la puissance de traitement des
noeuds : cette méthode n'est pas faisable dans notre cas, car
un raspberry pi tel qu'il est fourni après fabrication ne peut pas
excéder sa puissance nominale. A part sa capacité de stockage que
l'on peut augmenter à souhait.
* Équilibrer les charges à
travers différents noeuds du cluster : cette méthode
consiste à augmenter le nombre de noeuds exécutant les services
en utilisant un processus
33 IAI Gabon
c~Tchuenché Rodrigue Élève Ingénieur
En Informatique 33
permettant l'équilibrage de la charge de travail. c'est
cette méthode que nous allons prévoir pour notre cluster.
Pour repartir les charges dans un cluster ou un réseau
d'ordinateurs, plusieurs technologies existent :
· Le tourniquet DNS (Round robin) :
Permet d'inscrire dans le DNS plusieurs adresses IP pour un même nom
d'hôte. Une fois cette fonction activée, le serveur DNS va
séquen-tiellement renvoyer aux clients faisant une demande de
résolution de nom sur cet hôte une adresse réseau
différente.
· La répartition de charge
matérielle : Fonctionnant sur une base de NAT inversée,
le principe est d'envoyer tous les flux réseaux vers une IP virtuelle
qui va se charger via une translation d'adresse de rediriger les données
vers un membre du cluster.
· Logiciel de distribution de charge
réseau : Ce logiciel prend en charge la répartition du
flux entrant vers les différentes machines du cluster.
· Répartition de charge réseau
: La répartition de charge (NLB) est un système logiciel
distribué et redondant permettant de répartir la charge sur une
ferme de serveur 6. Il ne nécessite pas de
répartiteur car l'ensemble des membres de la ferme du cluster
reçoit les données.
Ci dessous une petite comparaison croisée des quatre
technologies de répartition de charge :
|
Round Robin
|
Hardware
|
Dispatch
|
NLB
|
Facilité D'installation
|
oui
|
|
|
oui
|
Matériel Nécessaire
|
|
oui
|
|
|
Point De Cassure Unique
|
|
oui
|
oui
|
|
Montage En Charge Facilité
|
oui
|
limitée
|
limitée
|
oui
|
Haute Performance
|
oui
|
limitée
|
limitée
|
oui
|
Tolérance aux pannes
|
non
|
limitée
|
limitée
|
oui
|
|
3.3.2 Logiciels de distribution de charge
réseau et haute Disponibilité du cluster
Pour gérer le Load Balancing de notre cluster, nous
allons utiliser un logiciel de distribution de charge réseau. Nous nous
servirons du logiciel Haproxy pour le Load Balancing et nous
allons coupler à ce logiciel le logiciel Heartbeat pour
garantir la haute disponibilité du cluster.
3.3.2.1 HAProxy
HAProxy est une application gratuite permettant de faire du
load-balancing, de la haute disponibilité ainsi que du proxying TCP
& HTTP.
HAProxy est réputé pour être stable,
très fiable, avec de bonnes performances grâce à sa
maturité (douze ans d'existence). L'intérêt d'utiliser
HAProxy, plutôt qu'un des nombreux
6. Une ferme de serveur désigne l'ensemble des noeuds
composant un cluster
34 IAI Gabon
c~Tchuenché Rodrigue Élève Ingénieur
En Informatique 34
35 IAI Gabon
autres reverse proxy ( Nginx, Squid, LYS .. )
est qu'il apporte des fonctionnalités très avancées, comme
le filtrage niveau 7 ( OSI ). HAProxy est disponible pour les systèmes
Linux et Solaris. Il est à sa version 1.7 de nos jours.
Un serveur HAProxy a pour fonction première le
Load-Balancing (répartition des charges) entre plusieurs serveurs web.
Ainsi, en ne joignant qu'une seule IP (celle du serveur HAProxy) nous tomberont
sur des serveurs web différents mais à contenu identique. Le but
est donc de répartir les charges d'un seul serveur web sur deux ou
plusieurs autres de façon transparente pour l'utilisateur. Ce serveur
particulier, appelé " l'équilibreur de charge"
(le load-balancer aussi appelé le
"director") est placé entre les clients et les noeuds
du cluster. Son rôle consiste à aiguiller les requêtes du
client vers un noeud particulier.
FIGURE 3.1 - Architecture Haproxy
3.3.2.2 Heartbeat
Pour gérer la haute disponibilité du cluster,
nous allons coupler à HAProxy le logiciel heartbeat. Heartbeat est un
logiciel de surveillance de la disponibilité des programmes, pour les
systèmes d'exploitation Linux, FreeBSD, OpenBSD, Solaris et MacOS X. Il
est distribué sous licence GPL.
Heartbeat écoute les battements de coeur - des signaux
émis par les services d'une grappe de serveurs lorsqu'ils sont
opérationnels. Il exécute des scripts d'initialisations
lorsqu'une machine tombe (plus d'entente du battement de coeur) ou est à
nouveau disponible. Il permet aussi de changer d'adresse IP entre les deux
machines à l'aide de mécanismes ARP avancés. Heartbeat
fonctionne à partir de deux machines et peut être mis en place
pour des architectures réseaux plus complexes. ' Les «
battements de coeurs » peuvent être prévus
de différentes façons :
-- Connexion par port série
-- Connexion ethernet UDP/IP broadcast -- Unicast
7. Source :
https://fr.wikipedia.org/wiki/Heartbeat_(logiciel)
c~Tchuenché Rodrigue Élève
Ingénieur En Informatique 35
-- ping (pour des routeurs, commutateur réseau, etc.)
Dans le schéma HAProxy standard, si le serveur HAProxy
(Load Balancer) tombe en panne, le cluster devient indisponible. Le principe
consiste donc à prévoir au moins deux serveurs HAProxy (Load
balancer) redondants tel que à un moment donné, un seul soit
actif et les autres passifs. Heartbeat permet ainsi de vérifier et de
synchroniser les Load Balancer de façon à ce que dès que
le serveur actif tombe en panne (n'est plus disponible) un des Load Balancer
passif prend le relais de façon rapide et transparente. L'administrateur
du système remet le serveur qui vient de tomber en marche et peut le
remettre soit en mode actif, le laisser en mode passif ou laisser Heartbeat
gérer automatiquement.
FIGURE 3.2 - Architecture
Haproxy/heartbeat
| 
