La continuité de service : les clusters, la répartition de charge

I INTRODUCTION

Si la performance est un élément important de satisfaction de l'utilisateur de réseau, la permanence de

la disponibilité des ressources l'est encore davantage. Ici nous nous intéressons aux serveurs et aux
solutions de continuité de service de type cluster. Les solutions de continuité de service de bas niveau
(RAID, DRDB, DFS) ne seront pas abordées ici.

II POURQUOI LES CLUSTERS DE SERVEURS ?

Il suffit de prendre l’exemple d’un serveur de messagerie qui ne fonctionne plus pendant une
demi-journée suite à un disque dur défectueux, le temps de le remplacer et de faire la restauration ; le
service commercial ainsi que la direction ne peuvent plus répondre aux appels d’offres, le service
client ne peut pas faire le suivi des réclamations, le service technique ne peut plus passer de
commande.
La structure est paralysée pour tous les échanges de courrier électronique, qui représente un
pourcentage conséquent de la gestion des activités au sein d’une structure commerciale. Les
résultats sont radicaux puisque l’entreprise cumule des contrats perdus, des bénéfices en moins, des
heures de travail perdues, des sanctions pour l’équipe de commerciaux et pour le service informatique.
Pour éviter ce genre de scénario catastrophe certains architectes ou administrateurs de systèmes
d’informations décident d’implémenter un service de cluster sur les serveurs hébergeant les
applications critiques : serveur de messagerie, serveur ERP, serveur Web commerce électronique,
serveur de base de données, serveur de fichiers ou autres.

III LES CLUSTERS TERMINOLOGIE

La technologie de clustering permet d'avoir une haute disponibilité des ressources publiées. On
utilise cette technologie pour avoir une disponibilité et stabilité des ressources proche de 100 %.
Tolérance zéro pour les pannes matérielles ou logicielles. Il y a également éventuellement une
répartition des charges entre les nœuds d'un cluster.
Un serveur de cluster est un groupe de serveurs gérant des ressources stockées généralement sur des
disques au SF partagé. Les nœuds et les disques sont généralement connectés par un bus de liaison
(SCSI ou Fibre Channel). Les disques sont dits à SF partagé car alors que les systèmes de fichiers
classiques n’autorisent qu’un SE à les gérer, les disques à SF partagé autorisent plusieurs SE à utiliser
le SF au même moment.
Un serveur dans le cluster est appelé nœud dit node en anglais. Les données publiques sont appelées
ressources, les disques au SF partagé contiennent les ressources. Une ressource peut-être une
machine virtuelle dans le cas d’un cluster d’hyperviseurs ou un service comme Apache
dans le cas de clusters applicatifs.
Par défaut chaque ressource est attribuée à un nœud ; pour publier un groupe de ressources
accessible par les clients externes, il est nécessaire de créer un serveur virtuel en lui adressant une
adresse IP virtuelle et un nom d'hôte. Cette IP virtuelle et ce nom d’hôte seront accédés depuis les
clients extérieurs au cluster. C’est donc une passerelle permettant la communication entre le nœud
chargé de la ressource à utiliser et le client.
Par défaut chaque groupe de ressources est attribué à un nœud. Dans le cas où le nœud a une
défaillance, un autre nœud prend en charge les groupes de ressources de son homologue, et répond
aux requêtes distantes. Cette phase de basculement entre les 2 nœuds est appelé failover. Par

1 Marie-pascale Delamare d’après « Clustering » de J.Y. Repetti et L. Cardona

conséquent la mise en place d'un cluster permet d’avoir une disponibilité des ressources proche de
100%.

IV LES APPORTS DES CLUSTERS

Haute disponibilité (Availability) des ressources sur le cluster, celles-ci sont garanties disponibles à
99,9 % du temps. Dans le cas où un des nœuds ne pourrait plus fournir des réponses aux requêtes
des clients, alors les autres nœuds du cluster prennent le relais. Ainsi la communication avec les
clients et l’application hébergée ou autres ressources sur le cluster ne subit pas d’interruption ou une
très courte interruption.
Adaptabilité : (Scalability) : il est possible d’ajouter un à plusieurs nœuds, ou d’ajouter des
ressources physiques (disques, processeurs, mémoire vive) à un nœud du cluster. En effet, il est
possible que de part les trop nombreuses requêtes sur le serveur que celui-ci soit en saturation au
niveau de la charge processeur, mémoire ou autre, dans quel cas il est nécessaire d’ajouter des
éléments, voir un autre nœud que l’on mettra alors en mode actif.
Évolutivité : Lorsque la charge totale excède les capacités des systèmes du cluster, d’autres systèmes
peuvent lui être ajoutés. En architecture multiprocesseur, pour étendre les capacités du système, il faut
dès le départ opter pour des serveurs haut de gamme coûteux autorisant l'ajout d'autres processeurs,
de lecteurs et de la mémoire supplémentaires.

V LES CLUSTERS : ARCHITECTURE

Sur le plan technique, le clustering consiste à mettre en grappe des serveurs (nœuds) qui partagent des
périphériques communs en se répartissant éventuellement la charge du traitement. Les unités de
stockage doivent être communes, et il faut un bus de communication entre les différents serveurs.

Un cluster est constitué de plusieurs nœuds. Ce sont des serveurs classiques ne nécessitant aucune
particularité mais malgré tout il est fortement conseillé d'estimer la charge des requêtes clients pour
déterminer la configuration optimale processeur(s) puissant(s), carte réseau, RAM, carte mère.

2 Marie-pascale Delamare d’après « Clustering » de J.Y. Repetti et L. Cardona et

http://www.labo-microsoft.org/articles/win/clustering/6/
Pour une plus grande stabilité du système il est nécessaire de posséder des configurations identiques
sur les 2 nœuds à savoir même processeur(s), mémoire quantité RAM, accès disque SCSI ou IDE
7200tr/min ou 10000 tr/min, ainsi en cas de basculement les ressources seront prises en charge de
la même façon, et n'affecteront pas les temps entrée/sortie sur les ressources.
Dans un cluster applicatif, les applications serveur sont installées de façons identiques sur les deux
nœuds du cluster.

VI LE STOCKAGE DES RESSOURCES

Les disques de cluster sont des disques durs partagés, chaque nœud peut accéder aux disques via le
bus partagé. Le SF utilisé est lui aussi partagé par les différents nœuds du cluster.
Le stockage de toutes les ressources publiables, fichiers de données, files d'impression, applications,
ressources, et services se font sur les disques partagés.
Il est nécessaire de partager les disques sur un bus, il y a deux méthodes d'implémentation pour le
partage des disques sur un bus, la technologie SCSI et la technologie Fibre Channel sur un
système SAN (Storage Area Network).

VII ARCHITECTURE LOGICIELLE : LE QUORUM

Le quorum est un disque dans lequel s o n t stockées toutes les informations concernant le
paramétrage et la configuration du cluster à savoir les adresses IP des serveurs virtuels, leurs
noms réseaux, les groupes de ressources, les fichiers log, retraçant les événements du cluster et
autres informations portant sur la configuration du cluster.
Le quorum est considéré comme le cerveau du cluster. Il maintient une cohérence et un équilibre
dans le cluster pour tous les nœuds. Il g è r e les données et joue le rôle d'arbitre au sein du cluster
pour déterminer quel nœud contrôle le cluster à un instant T et il gère également l'attribution des
groupes de ressources.

VIII LES TYPES DE CLUSTER

VIII.1 LE SERVICE DE CLUSTER À BASCULEMENT

Chez Microsoft, le service MSCS fournit une haute disponibilité pour les applications critiques,
telles que les bases de données, les serveurs de messagerie, serveur de fichier et d’impression. (Voir
fichier PDF fourni sur les clusters failover).
En openSource Corosync, Pacemaker permettent de mettre en œuvre des clusters de basculement.

VIII.1.1 LE FAILOVER
En cas de défaillance du nœud il y a un basculement automatique de prise en charge de toutes les
ressources vers l'autre nœud du cluster, ce processus est appelé failover.

3 Marie-pascale Delamare d’après « Clustering » de J.Y. Repetti et L. Cardona et

http://www.labo-microsoft.org/articles/win/clustering/6/
1 -Le client envoie une requête sur le serveur virtuel géré par le nœud 1.
2 -Le nœud 1 ne peut pas répondre au client car il est hors service
3-Le nœud 1 n’émet plus de « heartbeat »sur le réseau privé ce qui entraîne le basculement des
ressources du nœud 1 vers le nœud 2
4 -Le nœud 2 prend le relais et publie les ressources du serveur virtuel 1 pour les clients externes
5-La requête client est alors correctement acheminée et la mise hors service du nœud 1 est invisible
pour le client.

VIII.1.2 LE FAILBACK
Après les diverses opérations de maintenance et/ou de remise à niveau sur le nœud hors ligne, la
remise en production se fait grâce au procédé de failback. Il est possible de paramétrer l'instant où le
serveur sera remis en production dans le cluster. Il est préférable dans le cas d'un failback de restaurer
le nœud durant les périodes creuses des entrées sorties sur le cluster, la nuit ou le matin avant l'arrivée
des utilisateurs. Le nœud reprend ensuite le management des groupes de ressources qui lui étaient
attribués initialement.

1- Le problème technique est résolu et le nœud est remis en production.

Les datagrammes UDP, battements de cœurs sont de nouveaux générés sur le réseau entre les deux
2-
nœuds
Depuis le réseau privé, le nœud 2 est informé de la remise en production du nœud 1. Les groupes de
3-
ressources qui étaient initialement attribués au nœud 1 lui sont alors restitué.

4 Marie-pascale Delamare d’après « Clustering » de J.Y. Repetti et L. Cardona et

http://www.labo-microsoft.org/articles/win/clustering/6/
 Le nœud 1 synchronise les groupes de ressources et les publie via le serveur virtuel (dont l'IP n'a pas
4-
changé).
Les clients peuvent continuer à faire leur requête, et le failback reste invisible du côté client, on peut
5-
noter parfois en fonction des applications utilisées une micro-coupure de connexion au serveur.

VIII.2 LES CLUSTERS À RÉPARTITION DE CHARGE

Tout serveur a une capacité de traitement limitée. Lors de périodes de pointe, cette capacité peut
s'avérer insuffisante. Il est alors nécessaire d'ajouter un ou plusieurs serveurs afin de répartir le travail
(la charge) entre eux.
La répartition de charge (load balancing) est « un ensemble de techniques permettant de distribuer une
charge de travail entre différents ordinateurs d'un groupe. Ces techniques permettent à la fois de
répondre à une charge trop importante d'un service en la répartissant sur plusieurs serveurs, et de
réduire l'indisponibilité potentielle de ce service que pourrait provoquer la panne logicielle ou
matérielle d'un unique serveur » (source http://fr.wikipedia.org/wiki/R%C3%A9partition_de_charge).
La répartition de charge est donc une des technologies qui participe à la haute disponibilité.
Elle s’entend le plus souvent au niveau des serveurs HTTP (par exemple, sites à forte audience devant
pouvoir gérer des centaines de milliers de requêtes par secondes), mais le même principe peut
s’appliquer sur n’importe quel service aux utilisateurs ou service réseau.
Les techniques de répartition de charge les plus utilisées sont :
 Le DNS Round-Robin (DNS RR) : lorsqu’un serveur DNS répond à un client, il fournit une
liste d’adresses IP, dans un certain ordre, la première adresse étant celle que le client utilisera
en priorité (les autres sont des adresses de secours) ; l'ordre sera évidemment différent pour un
autre client (permutation circulaire en général). Le Round-Robin peut être mis en œuvre sur
n'importe quel serveur DNS.
 Le niveau TCP/IP ou niveau 4 : le client établit une connexion vers le « répartiteur »
(matériel ou outil logiciel) qui redirige ensuite les paquets IP entre les serveurs selon
l'algorithme choisi lors de la configuration (RR, aléatoire, en fonction de la capacité des
serveurs, etc.).
 Le niveau « applicatif » ou niveau 7 ou « répartition avec affinité de serveur » : on
analyse ici le contenu de chaque requête pour décider de la redirection. En pratique, deux
choses sont recherchées et analysées : les cookies, qui figurent dans l’entête HTTP ou L’URI,
c’est-à-dire l’URL et l’ensemble de ses paramètres. Ce niveau est parfois rendu nécessaire par
certaines applications qui exigent que les requêtes d’un même utilisateur soient adressées à un
même serveur. Cette technologie de répartition induit bien évidemment des délais
supplémentaires car chaque requête HTTP doit être analysée.

VIII.2.1 CHEZ MICROSOFT

Chez Microsoft, NLB (Network Load Balancing) permet d’équilibrer le trafic IP entrant. A travers
différentes règles établies les connexions entrantes sont réparties entre les différents nœuds du
cluster, il peut y avoir jusqu’à 32 nœuds pour équilibrer la charge IP en mode Network Load
Balancing. Le service d'équilibrage de charge de réseau augmente la disponibilité et la montée en
charge des applications serveur basées sur l’accès Internet, tels que des serveurs WEB, des serveurs
médias streaming, serveur Windows Terminal serveur ou autres. (Voir le fichier PDF fourni sur les
clusters NLB).

5 Marie-pascale Delamare d’après « Clustering » de J.Y. Repetti et L. Cardona et

http://www.labo-microsoft.org/articles/win/clustering/6/
VIII.2.2 DANS LE LIBRE
HAProxy est le logiciel libre de répartition de charge le plus utilisé. C'est une solution très complète au
plan fonctionnel, extrêmement robuste et performante.
Selon la documentation officielle « HAProxy est un relais TCP/HTTP (il fonctionne donc aux
niveaux 4 et 7) offrant des facilités d'intégration en environnement hautement disponible. Il est
capable :
 d'effectuer un aiguillage statique défini par des cookies ;
 d'effectuer une répartition de charge avec création de cookies pour assurer la persistance de
session ;
 de fournir une visibilité externe de son état de santé ;
 de s'arrêter en douceur sans perte brutale de service ;
 de modifier/ajouter/supprimer des en-têtes dans la requête et la réponse ;
 d'interdire des requêtes qui vérifient certaines conditions ;
 d'utiliser des serveurs de secours lorsque les serveurs principaux sont hors d'usage ;
 de maintenir des clients sur le bon serveur d'application en fonction de cookies applicatifs ;
 de fournir des rapports d'état en HTML à des utilisateurs authentifiés.

En outre, il requiert peu de ressources et son architecture événementielle mono-processus lui permet
de gérer facilement plusieurs milliers de connexions simultanées sur plusieurs relais sans effondrer le
système. »

6 Marie-pascale Delamare d’après « Clustering » de J.Y. Repetti et L. Cardona et

http://www.labo-microsoft.org/articles/win/clustering/6/