CLUSTERING ET HAUTE DISPONIBILITE

MASTER PROFESSIONNEL INTERNATIONAL EN INFORMATIQUE
OPTION : SYSTEMES ET RESEAUX
PROJET TUTEURE
THEME : CLUSTERING ET HAUTE DISPONIBILITE
SOUS LINUX
Rédigé et présenté par :
KPEGOUNI Abasse
Année universitaire : 2016 – 2017
Titeur : Dr. TEPE Kossi
Enseignant au CIC
Université de Lomé
Centre Informatique et de Calcul (CIC)
Université de Technologie
Belfort – Montbéliard

i
Résumé
Pour assurer la haute disponibilité d'un service, on utilisera ici deux serveurs identiques, disposant chacun de
ressources en disque suffisantes pour assurer le service. Ces deux serveurs seront reliés par une interface
réseau gigabit dédiée et un lien série. Grâce à ces liaisons le logiciel Heartbeat pourra surveiller l'état des
deux serveurs, et lancer les procédures de bascule d'un serveur à l'autre en cas de panne. C'est le logiciel
DRBD qui garantira la disponibilité des données lors des bascules, grâce à son implémentation très
performante de raid1 sur ip. Grâce au travail qu'accomplit DRBD au niveau block device, le couple
Heartbeat/DRBD permet de rendre hautement disponible à peu près n'importe quel service.
Abstract
To ensure the high availability of a service, two identical servers will be used here, each having sufficient disk
resources to provide the service. These two servers will be connected by a dedicated gigabit network interface
and a serial link. With these links, Heartbeat software can monitor the status of both servers and initiate
failover procedures from one server to another in the event of a failure. It is the DRBD software that will
guarantee the availability of data during the flip-flops, thanks to its very high performance implementation of
raid1 on ip. Thanks to the work done by DRBD at the block device level, the Heartbeat / DRBD couple makes
it possible to make highly available almost any service.

ii
Remerciements
J’aimerais témoigner ici de ma reconnaissance à l’égard des grands leaders et formateurs comme :
 ATCHONOUGLO Kossi, maitre de conférences en science physique, actuellement directeur de la
formation master au CIC de l’Université de Lomé ;
 DJEGUEMA K. Komi, directeur des statistiques agricoles, de l’informatique et de la documentation
(DSID) du ministère de l’agriculture de l’élevage et de l’hydraulique (MAEH) ;
 Docteur TEPE Kossi, mon tuteur, qui a consacré tout son temps à me superviser du début de ce projet
jusqu’à la rédaction de ce document ;
 Docteur PALANGA Eyouléki, maitre-assistant, actuellement responsable pédagogique de la
formation master ;
 A mes collègues Etudiants en master et aux collègues de service qui m’ont aidé dans la réalisation de
ce projet.
Que toutes ces personnes trouvent ici l’expression courtoise de mes salutations distinguées. Leurs conseils,
remarques et suggestions ont constitué pour moi un véritable point d’appui dans la rédaction de ce document.
Je leur en sais vraiment gré et les en remercie vivement.

iii
Sommaire
Résumé ............................................................................................................................................................... i
Abstract .............................................................................................................................................................. i
Remerciements .................................................................................................................................................. ii
Sommaire.......................................................................................................................................................... iii
Glossaire........................................................................................................................................................... iv
Introduction générale......................................................................................................................................... 0
Chapitre 1 : Contexte du travail et problématique............................................................................................. 1
1.1 Contexte du travail ................................................................................................................................ 1
1.2 Problématique........................................................................................................................................ 1
1.3 Approches de solution ........................................................................................................................... 1
Chapitre 2 : Contributions de recherches documentaires .................................................................................. 2
2.1 Qu’est qu’un cluster ?............................................................................................................................ 2
2.2 Haute disponibilité................................................................................................................................. 2
2.3 Synthèse et choix de la solution ............................................................................................................ 7
Chapitre 3 : Mise en œuvre du cluster............................................................................................................... 8
3.1 Eléments de mise en œuvre ................................................................................................................... 8
3.2 Explication de quelques notions............................................................................................................ 8
3.3 Mise en œuvre ....................................................................................................................................... 9
3.3.1 DRBD................................................................................................................................................ 9
3.3.2 HEARTBEAT ................................................................................................................................. 16
3.1 Evaluation des coûts............................................................................................................................ 20
3.2 Perspectives......................................................................................................................................... 21
Conclusion générale ........................................................................................................................................ 22
Bibliographie................................................................................................................................................... 23

iv
Glossaire
Cluster : Une grappe d’ordinateurs
High Availbility (HA) : Traduit en français haute disponibilité
Heartbeat : Logiciel de surveillance de la disponibilité des programmes sous
linix, FreeBSD, solaris, MacOS X. il est sous la licence GPL
DRBD : Distributed Replicated Block Device
RAID : Redundant Array of Independant Disk. C’est une grappe de
disque dur
FOS : FailOver Services
NAS : Network Attached Storage
SAN : Storage Area Network
SPOF : Single Point Of Failure
Failover : Basculement automatique

Introduction générale
De nos jours, les systèmes matériels et logiciels ont gagné régulièrement en complexité et en puissance. Ils ont
envahi toute la vie quotidienne de l’être humain et sont désormais incontournables dans la majorité des secteurs
clés de l'industrie. Peu de domaines ont échappé à cette révolution au point que la cohésion de nos sociétés
fortement industrialisés reposent sur la disponibilité des systèmes complexes qui rythment notre activité de
tous les jours : les transactions bancaires, les télécommunications, l'audiovisuel, internet, le transport de
personne ou de bien (avion, train ou voiture), les systèmes d'informations des entreprises et les services fournis
par les entreprises etc.
Produire les systèmes stables demande de passer beaucoup de temps en études et en analyse. Heureusement,
il existe des techniques simples permettant de pallier à la fiabilité des systèmes complexes, qu'ils soient
matériels ou logiciels. Plutôt que de chercher à rendre ces systèmes stables, on peut inverser la démarche et
intégrer à la source la notion de panne dans l'étude de ces systèmes : si l'on peut prévoir la panne d'un
composant matériel ou logiciel, on peut alors l'anticiper et mettre en œuvre une solution de substitution. On
parle alors de disponibilité du service, voire de haute disponibilité selon la nature de l'architecture mise en
place.
Aujourd'hui, la trop grande importance que révèlent les services qu'on offre impose un certain niveau de
sécurité, les solutions de RAID et autres viennent se greffer à des nouvelles solutions pour assurer une haute
disponibilité des services vitaux, car en effet très souvent d'énormes revenus sont liés à la disponibilité plus ou
moins parfaite de certains services et ce, en fonction des domaines d'activités. Ainsi, ce travail se déroulera en
trois chapitres à savoir contexte du travail et problématique [1], contributions de recherches documentaires [2]
et la mise en œuvre du clustering [3].

1
Chapitre 1 : Contexte du travail et problématique
1.1 Contexte du travail
Dans le cadre de la formation en master professionnel au CIC de l’Université de Lomé, il est instauré aux
Etudiants un projet de recherche dénommé projet tuteuré pour les semestres 2 et 3 afin de les permettre d’avoir
des notions, des techniques et des démarches liées à la recherche dans le monde universitaire. Ces projets leurs
préparerons pour pouvoir aborder leurs thèmes de mémoire en fin du cycle sans difficultés aucune car ils
auraient déjà acquis les base solides qui leurs permettront d’aller rapidement du début jusqu’à la fin de leurs
projet de mémoire.
C’est dans cette perspective qu’il serait pour nous intéressant de diriger nos réflexions sur la disponibilité des
services et des données au sein des entreprises suite aux difficultés que rencontrent la plupart de ces dernières
en matière d’accès à leurs données au moment opportun.
Ainsi, le sujet sur le clustering et haute disponibilité à retenu notre attention et qui constitue l’objet de notre
étude.
1.2 Problématique
Dans presque toutes les structures d’aujourd’hui comme les banques, les services de télécommunications, les
agences de voyages, les services d’assurance, les agences de multimédias, bref pour toutes les structures qui
utilisent des données numériques, l’accès aux données est capitale voire indispensable. Ces données sont
sauvegardées souvent sur des disques durs en local, soit sur des serveurs d’entreprises, soit sur des baies de
stockage à travers un réseau de stockage (SAN), etc. Une panne du matériel entrainerait une indisponibilité du
service ou de donnée. Face à cette situation, il se pose un problème de disponibilité de donnée ou de service
pour ces structures. Comment renforcer le serveur ou bien le réseau pour que quand il y a un problème, les
données soient toujours disponible et que le service soit fonctionnel ? Devant ce problème, nous avons pensé
à la haute disponibilité.
Cependant, comment mettre en place une solution de haute disponibilité ?
1.3 Approches de solution
En effet, la panne d'un système informatique peut causer une perte de productivité et d'argent, voire des pertes
matérielles ou humaines dans certains cas critiques. Il est ainsi essentiel d'évaluer les risques liés à un
dysfonctionnement d'une des composantes du système d'information et de prévoir des moyens et mesures
permettant d'éviter ou de rétablir dans des temps acceptables tout incident.
Les risques de pannes peuvent être :
- physiques naturelle ou criminelle ;
- désastre naturel ;
- environnement ;
- panne matérielle (serveur, disque dur) ;
- panne du réseau ;
- coupure électrique ;
- origines humaines ;
- erreur de conception ;
- origines opérationnelles, lié à un état du système à un moment donné ;
- bogue logiciel ;
- dysfonctionnement logiciel ;

2
- malveillance intentionnelle.
- Etc.
La disponibilité s'exprime sous la forme de taux de disponibilité, exprimé en pourcentage, en ramenant le
temps de disponibilité sur le temps total. Le tableau suivant présente le temps d'indisponibilité sur une base
d'une année en fonction du taux de disponibilité.
Taux de disponibilité Durée d’indisponibilité
97% 11 jours
98% 7 jours
99% 3 jours et 15 heures
99,9% 8 heures et 48 minutes
99,99% 53 minutes
99,999% 5 minutes
99,9999% 32 secondes
Tableau 1 : Temps d'indisponibilité sur une base d'une année en fonction du taux de disponibilité1
Après une recherche documentaire liée à ces approches de solution, nous allons nous fixer sur la solution qui
sera retenu pour la mise en place.
Chapitre 2 : Contributions de recherches documentaires
Les techniques permettant de venir à bout des désagréments causés par une indisponibilité temporaire ou
permanente ou soit un arrêt total d’un service dans une infrastructure informatique sont regroupées sous
différentes appellations suivant le degré de la réponse qu'elles apportent au problème posé.
2.1 Qu’est qu’un cluster ?
En informatique, un cluster est une grappe de serveurs sur un réseau, appelé ferme ou grille de calcul rendant
le même service d’une manière transparente pour les clients. Il existe deux types d’utilisations pour les clusters:
 Le calcul distribué, ici on utilise la puissance de calcul de toutes les machines du cluster afin de
réaliser de grandes opérations arithmétiques. Ils sont souvent utilisés dans les laboratoires de
recherches ou les calculs météorologiques.
 La haute disponibilité des infrastructures notamment dans l’utilisation du load-balancing (répartition
de charge entre serveurs). Cela a pour but de favoriser la continuité de service. Dans ce cadre-là toutes
les machines physiques ne forment qu’une machine logique et le gestionnaire de cluster gère le failover
(basculement) en cas de panne d’un noeud.
2.2 Haute disponibilité
[On définit la haute disponibilité comme un système permettant d'assurer une continuité opérationnelle d'un
service sur une période donnée. Pour mesurer la disponibilité, on utilise une échelle qui est composée de 9
échelons. Un service Hautement Disponible est 99% disponible soit moins de 3,65 jours par an.
1
Le tableau est réalisé par moi-même mais les données dans le tableau sont tirées du Support de cours numérique de F A L C H I _ S
O U BRAT_RAYMOND

3
Afin de calculer la disponibilité, les métriques suivantes sont utilisées:
- MTBF (Mean Time Between Failure) : mesure du temps estimé entre 2 défaillances d'un système.
- MTTR (Mean Time to Resolution) : mesure du temps estimé pour restaurer la fonctionnalité.
La formule de calcul de disponibilité est : Disponibilité = MTBF / (MTBF + MTTR)]2
Ainsi, un cluster de haute disponibilité en anglais « High Availbility », est un ensemble de serveurs physiques,
au nombre minimum de deux, afin d'obtenir une activité de services en temps réel, en toutes conditions, de
l'ordre de 99.99%. Ainsi, dans une architecture à haut risque où les services doivent être disponibles 24 heures
sur 24, 7 jours sur 7, une solution devrait être en mesure d'assurer cette disponibilité.
La haute disponibilité possède deux grands axes : La disponibilité des services et la disponibilité des données3
.
2.2.1 La disponibilité de service
Le fait qu’un service soit fonctionnel en temps réel sans aucune interruption traduit sa disponibilité. Son
principe est simple : un service, quelle que soit sa machine de référence ou les données dont il dispose, doit
toujours répondre aux clients qui en font la demande. C'est-à-dire que peu importe le serveur qui répond,
lorsqu'un client arrive, le service demandé doit satisfaire la demande.
Le serveur répondant est l'un des serveurs du cluster qui est encore en activité. Dans le cas d'un cluster en haute
disponibilité sans load balancing, le serveur maître répond à toutes les requêtes sauf si celui-ci est indisponible.
Dans ce cas, c'est le ou l'un des serveurs esclaves qui répond.
Pour de la haute disponibilité de services, deux types de techniques existent : Le FailOver Services et le Linux
Virtual Server.
2.2.1.1 Le FailOver Services (FOS)
Le failover services est un processus de monitoring et de reprise de services pour seulement deux machines :
Le serveur maître et le serveur esclave, chacun surveillant l'autre sur deux canaux et types de connectiques
différents. Dans la plupart des cas, les deux types de liaisons sont de l'ordre du réseau RJ45 en utilisant le
protocole TCP/IP et du câble série branché directement sur les deux machines. Ces précautions évitent que
l'un des serveurs identifie son "compagnon" comme inaccessible alors qu'il n'y a qu'un problème de congestion
de réseau ou bien un problème de branchement momentané sur les câbles.
Le FailOver Services peut vérifier tous services utilisant le protocole TCP/IP et commander l'arrêt ou le
démarrage de n'importe quels scripts. Ce dernier contrôle aussi l'état réseau des machines : en d'autre terme, le
contrôle de l'IP de la machine.
FOS utilise un principe très simple mais à la fois très astucieux dans le changement de serveur "répondant". Il
utilise l'IP Aliasing. L'IP Aliasing permet de définir une interface réseau avec plusieurs adresses IP différentes.
2
https://www.celeste.fr/fondamentaux-haute-disponibilite-entreprise
3
Mémoire on-line d’Armel Francklin SIMO TEGUEU, thème : Plate- forme d'entreprise sécurisée et de haute disponibilité,
promotion 2009

4
Figure 1 : Schéma montrant l’interconnexion des serveurs pour assurer le service failover4
Important : Pour que ce type de haute disponibilité fonctionne, il faut bien sûr que la machine esclave possède
les mêmes services que son homologue maitre. Sinon la haute disponibilité ne fonctionnera pas.
2.2.1.2 Linux Virtual Server (LVS)
Linux Virtual Server effectue le même travail que son homologue FOS mais avec un procédé légèrement
différent. En effet, LVS s'appuie sur une architecture de Load Balancer et d'un ensemble de serveurs. Donc ce
qu’il faut retenir ici est que la haute disponibilité de service se réduit aux trois notions essentielles :
- Le failover (FOS) ;
- Linux Virtual Server (LVS) ;
- Et le Load-Balancing (LB)
Figure 2 : Schéma montrant un cluster LVS simple5
Le redirecteur LVS utilise des algorithmes de load-balancing pour rediriger les paquets vers les serveurs
appropriés.
Au demeurant, disons « qu’un service, quelle que soit sa machine de référence ou les données dont ils
disposent, doit toujours répondre aux clients qui en fait la demande quelle que soit les données dont ils
disposent ».
4
http://denisrosenkranz.com/tuto-ha-un-cluster-drbdapache-avec-heartbeat-sur-debian-7/
5
http://lea-linux.org/documentations/La_haute_disponibilit%C3%A9

5
2.2.2 La disponibilité de données
A ce niveau, il existe deux types de haute disponibilité de données : les données partagées et les données
répliquées. Les données partagées le sont dans le domaine du réseau. Les données répliquées appartiennent à
deux domaines : celui du réseau (réplication serveur à serveur) ou local (réplication disque à disque).
Cependant, dans tous ces domaines, un domaine est prédominant.
Voici les différents types de systèmes de fichiers répartis par domaine.
2.2.2.1 Le RAID
Le RAID n'est pas une solution 100% viable dans un système de haute disponibilité. Parce que le système
devient viable si et seulement si vous êtes sûr que votre serveur ne tombera pas en panne. Le système Raid
n’aidera que pour un secours disque, c'est-à-dire que lorsqu'un disque ne fonctionne plus correctement, un
autre prend le relais. Mais au cas où le serveur tombe entièrement, le raid ne pourra plus faire grand-chose.
Malgré tout, le Raid reste une solution très utile et à privilégier lorsqu'on le peut.
2.2.2.2 Le système de fichier Ext3
L’Ext3 est un système de fichiers journalisé. Il est le remplaçant de l'ext2. Ce système de fichiers a évolué
principalement à cause des durées souvent trop longues lors d'une vérification du système de fichiers lorsque
le serveur n'a pas réussi à démonter proprement les partitions (généralement après un plantage du serveur). Le
grand avantage du Ext3 par rapport aux autres systèmes de fichiers est que l'on passe de l'Ext3 à l'Ext2 et
inversement sans problème et sans avoir à jouer avec les différentes partitions pour garder ses données.
2.2.2.3 Le système de fichier ReiserFS
Le ReiserFS est aussi un système de fichiers journalisé. Ce dernier se distingue par le fait qu'il est basé sur une
notion d'arbre. De plus, il gagne en performance pour un nombre important de fichiers dans un même répertoire
et en espace pour les petits fichiers (sous d'autres filesystems, chaque fichier prend un block au minimum,
tandis que le ReiserFS essaye de caser tout dans un seul si le fichier fait moins d'un block). Ce système de
fichiers est efficace mais plus difficilement applicable sur un système déjà existant.
2.2.2.4 Le système de fichier InterMezzo
Le système de fichier InterMezzo est quelque peu différent de ses précédents. InterMezzo permet une
réplication par réseau des données. Il intègre une gestion de déconnexion (si l'un des serveurs de sauvegarde
est indisponible, il sera resynchronisé plus tard) et gère l'Ext3, le ReiserFS et le XFS pour l'instant. InterMezzo
s'inspire du fonctionnement de Coda. Très utile dans un système de haute disponibilité, son grand désavantage,
c'est qu'il est encore en développement à l'heure actuelle.
2.2.2.5 Le NBD
Network Block Device (NBD) reprend le principe d'InterMezzo et de Coda, dans le sens où il effectue une
copie conforme d'un serveur à un autre serveur au moyen du réseau. A la seule différence qu'il n'utilise qu’Ext
2 et NFS nativement.

6
2.2.2.6 Le NFS
Le NFS (Network File System) procède différemment d'InterMezzo, Coda et autres NBD car il n'effectue pas
une réplication de données mais plutôt un partage de données (data shared). Le système de données ne se
trouve pas sur les serveurs de services mais sur un autre serveur dédié. Le gros point noir de NFS est la sécurité :
les discussions entre le serveur et son client ne sont pas protégées et les permissions laissent à désirer.
Une solution envisageable consiste soit à utiliser du Tunneling soit à utiliser directement sNFS (Secure
Network File System) Cette solution est, malgré tout, recommandé dans certaines solutions de haute
disponibilité.
2.2.2.7 Le GFS
Global File System (GFS) est un système de fichiers sous Linux permettant de partager les disques d'un cluster.
GFS supporte la journalisation et la récupération de données suite à des défaillances de clients. Les noeuds de
cluster GFS partagent physiquement le même stockage par le biais de la fibre optique ou des périphériques
SCSI partagés. Le système de fichiers semble être local sur chaque noeud et GFS synchronise l'accès aux
fichiers sur le cluster. GFS est complètement symétrique ce qui signifie que tous les noeuds sont équivalents
et qu'il n'y a pas un serveur susceptible d'être un entonnoir ou un point de panne. GFS utilise un cache en
lecture écriture tout en conservant la sémantique complète du système de fichiers Unix.
Mis à part que GFS s'adresse directement aux personnes ayant les moyens car la fibre d'optique ou les
périphériques SCSI ne sont pas bon marché. Hormis ce problème, GFS est un atout indispensable dans une
solution de haute disponibilité mais surtout dans le cadre d'un Cluster.
2.2.2.8 Le DRBD
Le DRBD, comme InterMezzo et NBD, effectue un réplica parfait du disque primaire sur un autre disque dur
d'un serveur tiers par voie réseau. DRBD est indépendant du type de système de fichiers utilisé sur le serveur.
Vous pouvez donc utiliser n'importe quel système de fichiers.
Tout comme ses congénères, DRBD propose deux types de synchronisation : partielle ou totale. La
synchronisation partielle n'effectue une mise à jour du disque secondaire que dans les parties non
synchronisées (si le serveur a planté par exemple, rien ne sert de refaire une copie du disque primaire). La
synchronisation totale, elle, effectue une copie disque à disque complète, comme si le disque secondaire venait
d'être installé.
2.2.2.9 Le SAN/NAS
SAN (Storage Area Network) et NAS (Network Attached Storage) sont des serveurs dédiés au stockage de
données. Toutefois, SAN et NAS sont différents mais complémentaires. En effet les deux types peuvent être
utilisés en même temps pour un service de haute disponibilité. Le NAS se charge du réseau et SAN se charge
des serveurs de données. SAN utilise un protocole SCSI tandis que NAS utilise un protocole IP.
SAN est plus une extension pour serveur alors que NAS est plus dans un optique réseau. SAN est plus rapide
du fait de sa connectique alors que son homologue NAS améliore grandement le modèle de stockage.
Ainsi, ces différentes informations recueillies suivies des contributions des revus documentaires nous amènent
à faire une synthèse et choix de la solution pour la mise en place.

7
2.3 Synthèse et choix de la solution
En se servant des connaissances acquises ci-dessus, nous pouvons retenir ce qui suit pour des solutions de
haute disponibilité.
2.3.1 Synthèse
Une solution couramment utilisée pour assurer les mécanismes de reprise arrière consiste à placer les données
sur l'équipement SAN (Storage Area Network) accessible depuis deux serveurs : en cas de panne du serveur
actif, le serveur de secours retrouvera les données à jour sur le SAN. Cependant cette solution présente
plusieurs inconvénients :
- Elle revient relativement chère pour une structure ;
- Elle peut représenter un SPOF (Single Point Of Failure) si elle vient à tomber en panne. Redonder
complètement une baie SAN est possible, jusqu'à la double connexion au serveur, mais alors les prix
s'envolent de manière complètement démesurée et on a vu des cas où même avec tout cet équipement,
une panne survenait.
Une autre solution est de disposer de deux serveurs avec leurs propres espaces disques, et de procéder à des
synchronisations régulières (type rsync) entre les deux machines, dans le sens serveur actif => serveur passif.
En cas de crash, le service pourra démarrer, mais avec des données datant de la dernière synchronisation. La
solution que nous allons étudier ici répond à deux impératifs : ne pas avoir de SPOF dans le cluster, et avoir
des données parfaitement à jour en cas de bascule du service vers la deuxième machine.
2.3.2 Choix de la solution
Vu les avantages et les inconvénients que présentent ces solutions, la dernière sera retenue pour le déploiement
qui présente un rapport qualité prix quasi excellent.
2.3.3 Description générale de la solution retenue
La configuration matérielle de notre solution est la suivante : deux serveurs identiques disposant chacun des
ressources en disque suffisantes pour assurer le service. En temps normal, un seul de ces deux serveurs
(SRV_MASTER) rend effectivement le service : il dispose de l'adresse IP sur laquelle est disponible le service,
le système de fichier contenant les données est monté, et les différents services réseaux lancés. L'autre machine
(SRV_SLAVE) au contraire se contente d'attendre. Les deux machines s'informent mutuellement de leur
fonctionnement par un système de « battement de coeur » implémenté par le logiciel « heartbeat ».
Lorsqu'une panne survient sur SRV_MASTER, la machine SRV_MASTER détecte l'arrêt de battement de
cœur et lance une procédure de bascule : SRV_MASTER va acquérir l'adresse IP du service, monter le système
de fichier, et lancer les services réseaux rendus par le cluster tout ceci grâce à un système d'IP aliasing. Le
système de fichier que l'on monte sur SRV_MASTER doit contenir exactement les mêmes données que celui
de SRV_SLAVE au moment du crash : c'est là que DRDB fonctionne alors comme une sorte de RAID1 sur IP
au niveau block device. Ce dernier monté sur le serveur maitre n'est pas /dev/sda1, par exemple, mais
/dev/drbd1. De fait, quand le serveur maître écrit sur le système de fichier « drbdisé », il écrit à la fois sur son
propre /dev/sda1, mais également sur le /dev/sda1 de l'esclave. L'esclave dispose ainsi en temps réel d'une
copie des données.
Ce RAID1 sur IP s'accompagne d'une gestion intelligente des synchronisations : quand un serveur est
temporairement retiré puis ré-attaché au cluster, seules les données modifiées entre temps sont synchronisées.
Cela garantit des temps de synchronisation faibles, même pour des volumes importants (à peine quelques
minutes pour un volume de 1Tera).

8
Figure 3 : Architecture de déploiement de la solution6
Chapitre 3 : Mise en œuvre du cluster
Une disponibilité de l'ordre de 100% n'est que théorique. Aucun service ne peut être disponible à 100%.
Cependant lorsque l'on parle de haute disponibilité, les services s'approchent de ce chiffre, mais une panne
exceptionnelle de tout ordre peut intervenir (Foudre, Feu, etc.). Ainsi, nous allons mettre en place un cluster
Web actif/passif hautement disponible avec DRBD et Heartbeat.
3.1 Eléments de mise en œuvre
La mise œuvre de la solution nécessite les éléments suivants :
- Un réseau local bien câblé ;
- Deux serveurs physiques ayant les caractéristiques identiques ;
- Installation d’une distribution linux sur les deux serveurs. Dans notre cas ici, nous utiliserons la
distribution Debian 8.3.0 ;
- Configurer le réseau sur les serveurs et donner des noms compréhensifs aux serveurs. Ces derniers
doivent être dans le même réseau local et doivent être proche l’un de l’autre ;
- Créer les mêmes partitions disque dur sur les deux serveurs ;
- Installer et configurer le DRBD pour la réplication ;
- Installer et configurer heartbeat pour la surveillance et le bascule automatique ;
- Installer et configurer apache.
3.2 Explication de quelques notions
 Le DRBD
DRBD pour Distributed Replicated Block Device est comparable à un RAID 1 mais en réseau, c’est à dire
que deux disques, partitions ou même un LVM peuvent être répliqué d’un disque à un autre via un réseau
Ethernet ou fibre optique. Cela permet donc d’assurer la disponibilité de vos données en cas de crash complet
d’une machine. Ce que ne permet pas de faire un RAID classique.
6
Réalisé par moi-même

9
Figure 4 : Schéma DRBD7
 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 cœur, des signaux émis par les services d’une grappe de serveurs lorsqu’ils
sont opérationnels. Lorsque qu’un serveur devient défaillant, Heartbeat le détecte (puisqu’il n’entend plus ses
battements de cœurs) et bascule les services surveillés sur un autre serveur. Pour que cela soit transparent pour
les utilisateurs, Heartbeat met en place une IP virtuelle unique qui est balancée entre les deux serveurs.
Figure 5 : Schéma su cluster HA/DRBD/APACHE8
3.3 Mise en œuvre
3.3.1 DRBD
 Préparation des disques
Nous allons commencer par créer une partition sur les seconds disques que nous avons rajoutés.
Sur les deux nodes tapez les commandes suivantes:
7
http://denisrosenkranz.com/tuto-ha-un-cluster-drbdapache-avec-heartbeat-sur-debian-7/
8
http://denisrosenkranz.com/tuto-ha-un-cluster-drbdapache-avec-heartbeat-sur-debian-7

10
Sur node1
Sur node2
Maintenant que nous avons partitionnés les deux disques nous allons installer les paquets nécessaires à
l’utilisation de DRBD.
 Installation et configuration de DRBD
Sur les deux serveurs (node1 et node2) tapez les commandes suivantes:
apt-get install drbd8-utils
Puis une fois le paquet installé on active le module avec la commande suivante:
modprobe drbd

11
On peut vérifier la version de DRBD installée en tapant la commande modinfo drbd
Maintenant que nos disques et DRBD sont mis en place nous allons configurer la réplication des données entre
les deux disques.
Pour ce faire nous allons créer et éditer un fichier que nous allons appeler drbd1.res dans le dossier
/etc/drbd.d/
NB : Attention les commandes et les configurations suivantes sont à faire sur les deux serveurs.
cd /etc/drbd.d
nano drbd1.res
Puis on remplit le fichier de la façon suivante:
Explications:
Tout d’abord on donne un nom à notre ressource DRBD dans notre cas nous allons l’appeler r0. Dans cette
ressource nous allons renseigner nos deux nodes, cela commence donc par on node1 (node1 doit être le
hostname de la machine) avec les valeurs suivantes:
device /dev/drbd0; #Ceci est le nom du disque DRBD que nous
allons créer
disk /dev/sdb1; #Ceci est le chemin de la partition que
nous allons utiliser
address 192.168.10.128:7788; #Adresse IP du node1
meta-disk internal; #On écrit les MD sur le disque
Et on fait la même chose pour node2
Une fois ce fichier écrit sur les deux nodes nous allons enfin pouvoir mettre en place la réplication :
Toujours sur les deux nodes tapez les commandes suivantes:
drbdadm create-md r0
drbdadm up r0

12
Et voilà notre DRBD est pratiquement mis en place vous pouvez vérifier que vos nodes se contactent en tapant
la commande suivante:
drbd-overview
Vous devriez avoir cette ligne en sortie:
drbd-overview
0:r0 Connected Secondary/Secondary Inconsistent/Inconsistent C r----
Cela veut dire que vos nodes se connectent mais que la réplication n’est pas encore possible étant donné
qu’aucun des deux n’est en mode Primary, pour y remédier nous allons mettre node1 en primary avec la
commande suivante:
root@node1:~# drbdadm -- --overwrite-data-of-peer primary r0
Et node2 en secondary (pas forcement obligatoire de faire ça)
root@node2:~# drbdadm secondary r0
La synchronisation initiale se lance on peut vérifier l’état de la synchronisation avec la commande
suivante:
La synchronisation initiale peut être plus ou moins lente en fonction de l’espace disque et de la rapidité du
réseau local. On peut suivre la synchronisation avec un rafraîchissement toutes les 2 secondes avec la
commande suivante:
watch cat /proc/drbd
On aura ceci en sortie :
L’on peut quitter cette vue en faisant CTRL+C
Une fois la synchronisation terminée la commande cat /proc/drbd vous donneras ceci:
Si les deux sont en mode ds:UpToDate/UpToDate c’est que tout fonctionne bien.

13
Maintenant que notre raid réseau et fonctionnel nous allons créer un système de fichier en ext4 pour pouvoir
écrire dessus.
Tapons la commande suivante sur le node primaire (node1)
root@node1:~# mkfs.ext4 /dev/drbd0
Maintenant nous pouvons monter le disque DRBD comme n’importe quel disque dur
mkdir /mnt/r0
mount /dev/drbd0 /mnt/r0/
Si nous tapons la commande df -h nous pouvons voir que le disque est bien monté.
Maintenant nous allons tester notre réplication.
 Mise en pratique de la réplication via DRBD
Pour tester notre réplication nous allons télécharger une image iso de Debian sur node1 et voir si la réplication
se fait sur le node2 ou bien créer n’importe quel fichier sur le node1.
Donc sur node1 nous allons aller dans le dossier /mnt/r0 et télécharger l’ISO de Debian 6
cd /mnt/r0/
wget http://cdimage.debian.org/debian-cd/6.0.7/i386/iso-cd/debian-6.0.7-
i386-CD-1.iso
Pendant le téléchargement les paquets téléchargés seront aussi copiés sur node2 étant donné que DRBD est
configuré pour faire une copie synchrone des fichiers.
Après le téléchargement, ce que nous pouvons faire maintenant c’est mettre node1 en secondary, de mettre
node2 en primary et de monter la partition sur node2.
Sur node1
root@node1:~# umount /mnt/r0
root@node1:~# drbd-overview
0:r0 Connected Secondary/Secondary UpToDate/UpToDate C r----
On voit donc que maintenant les deux nodes sont en secondary.
Sur node2
root@node2:~# drbdadm primary r0
root@node2:~# mkdir /mnt/r0
root@node2:~# mount /dev/drbd0 /mnt/r0/
Faisons un ls -l dans le dossier /mnt/r0 de node2

14
root@node2:~# ls -l /mnt/r0/
total 662548
-rw-r--r-- 1 root root 678428672 Feb 23 08:36 debian-6.0.7-i386-CD-1.iso
Nous avons bien notre fichier ISO présent sur le node2.
IMPORTANT: On ne peut monter un disque DRBD que sur le serveur ou il est en primary. Le montage
est impossible en secondary.
Si nous tapons la commande drbd-overview quand le disque est monté nous aurons des informations
supplémentaires, comme le point de montage et l’espace disque restant.
0:r0 Connected Primary/Secondary UpToDate/UpToDate C r---- /mnt/r0 ext4
1004M 665M 289M 70%
Maintenant nous allons voir comment faire en cas de crash d’un des serveurs.
 Tests de fonctionnement de la réplication
En cas de crash d’un node
Actuellement node2 est primary est node1 est secondary nous allons éteindre node2 et voir ce qui se passe au
niveau de DRBD. Tout d’abord nous allons éteindre node2
root@node2:~# init 0
Nous allons voir l’état de notre DRBD sur node1
0:r0 WFConnection Secondary/Unknown UpToDate/DUnknown C r----
Il est donc en mode Wait For Connection étant donné que node2 n’est plus joignable. Nous allons donc remettre
node1 en primary pour que nous puissions accéder à nos données:
0:r0 WFConnection Primary/Unknown UpToDate/DUnknown C r---- /mnt/r0
ext4 1004M 665M 289M 70%
Nous avons donc de nouveau accès à nos données mais notre raid n’est plus fonctionnel. Si nous redémarrons
node2, DRBD va automatiquement le mettre en secondary et le raid sera de nouveau opérationnel.
#Après le redémarrage de node2
0:r0 Connected Primary/Secondary UpToDate/UpToDate C r----
Que faire en cas de crash d’un disque dur ?

15
Maintenant nous allons voir quoi faire en cas de crash d’un disque dur sur node2.
Sans éteindre le node2 supprimons le second disque. Retournons sur le node2 et tapons la commande fdisk
-l, nous verrons que le disque /dev/sdb aura disparus.
Sur node1 tapons drbd-overview pour vérifier l’état de DRBD
0:r0 WFConnection Primary/Unknown UpToDate/DUnknown C r----
DRBD est maintenant en attente de connexion. Maintenant toujours sans éteindre le node2 rajoutez de nouveau
un disque de 1To.
Refaites un fdisk -l et vous voyez maintenant qu’un nouveau /dev/sdb est apparus mais celui-ci est
non partitionné.
Créons maintenant une partition comme nous l’avons fait tout au début et réactivons DRBD.
Maintenant sur node1 ou sur node2 tapons drbd-overview et nous verrons que la synchronisation initiale
est lancée.
Une fois la nouvelle synchronisation terminée la commande drbd-overview devrait nous retourner
ceci:
Maintenant nous allons mettre node1 en secondary et node2 en primary et vérifier si les fichiers sont de retour
sur node2.
Sur node1
root@node1:~# umount /mnt/r0
Sur node2
0:r0 Connected Primary/Secondary UpToDate/UpToDate C r---- /mnt/r0 ext4
1004M 665M 289M 70%
root@node2:~# ls -l /mnt/r0/
total 662548
-rw-r--r-- 1 root root 678428672 Feb 23 08:36 debian-6.0.7-i386-CD-1.iso

16
Nous avons donc bien notre fichier ISO sur le node2, cela veut dire que notre raid réseau à bien été reconstruit
et que tout réfonctionne comme avant.
Nous venons de mettre en place notre cluster DRBD qui fonctionne normalement. Donc, nous allons passer à
la mise en place du cluster web hautement disponible à l’aide du logiciel heartbeat.
3.3.2 HEARTBEAT
A ce niveau, on s’assure que le service DRBD fonctionne bien avant de continuer sinon revoir tous les
problèmes possibles du non fonctionnement de drbd.
Ensuite modifier le fichier de configuration de DRBD sur les deux serveurs.
Dans la configuration précédente nous avions le fichier « /etc/drbd.d/drbd1.res » avec le contenu suivant:
Nous allons rajouter deux options intéressantes pour améliorer le cluster, voici le nouveau fichier.
NB : Ne pas oublier de modifier ce fichier sur les deux serveurs DRBD.

17
Si la partition /dev/drbd0 est montée, il est conseillé de la démonter avant de continuer le processus. Si on
a aussi configuré le montage automatique de cette partition dans fstab, on doit supprimez cette ligne. HeartBeat
va gérer le montage de la partition drbd.
Donc maintenant que tout est OK et que DRBD est bien fonctionnel sur les deux serveurs on va pouvoir
installer Heartbeat.
 Installation et configuration de Heartbeat
Il est à rappeler que toutes les prochaines étapes sont à refaire sur les deux serveurs.
HeartBeat s’installe simplement avec la commande :
apt-get install heartbeat
Une fois heartbeat installé nous allons devoir créer trois fichiers dans le dossier « /etc/ha.d/ »
– ha.cf : Pour la configuration générale de HeartBeat
– haresources : Pour la configuration des ressources
– authkeys : Pour la clé partagée entre les serveurs du cluster
Voici le contenu du fichier ha.cf
Attention : Pour que tout fonctionne bien il faut s’assurer que nous puissions pinguer node2 depuis node1 et
vice-versa.
Nous allons maintenant créer le contenu du fichier haresources
node1 IPaddr::192.168.2.57/24/eth0 drbddisk::r0
Filesystem::/dev/drbd0::/mnt::ext4
Explications:
node1 = noeud primaire du cluster
IPaddr::192.168.2.57/24/eth0 = Adresse IP balancée du cluster sur eth0
drbddisk::r0 = nom de la ressource drbd (spécifié dans /etc/drbd.d/drbd1.res)
Filesystem::/dev/drbd0::/mnt::ext4 = Nom de la partition drbd, point de montage et type de système de
fichier.
Et pour finir nous allons créer le fichier « authkeys ». Ce fichier contient une clé partagée entre les deux
serveurs. Cela peut être un mot de passe, ou un simple mot.

18
Voici le fichier :
auth 3
3 md5 my-auth-key
Ce fichier la doit avoir les permissions « 600 ». Donc sur les deux serveurs tapez:
chmod 600 /etc/ha.d/authkeys
Et voilà tout est bon maintenant.
Sur node1 démarrons Heartbeat avec la commande suivante:
/etc/init.d/heartbeat start
Patientons quelques seconde et tapons sur node1 la commande « drbd-overview » et vérifions si la
partition /dev/drbd0 est bien montée dans /mnt/.
Nous pouvons aussi vérifier avec la commande ifconfig, nous verrons qu’une nouvelle interface « eth0:0 » a
été créée avec l’adresse IP configurée dans le fichier haresources.
Maintenant sur node2 démarrons aussi heartbeat avec la commande:
Et voilà notre cluster DRBD est opérationnel.
 Test de fonctionnement
Connectons-nous en SSH sur les deux nodes.
Sur node2 tapons la commande suivante pour vérifier l’état de drbd en temps réel :
watch drbd-overview
Actuellement depuis node2 nous devrions voir cette ligne:
0:r0 Connected Secondary/Primary UpToDate/UpToDate C r-----
Cette ligne nous montre bien que node2 est secondary et que la partition drbd n’est pas montée.
Maintenant sur node1 on arrête Heartbeat avec la commande suivante :
/etc/init.d/heartbeat stop
Basculez tout de suite sur node2 et voyez que la ligne va devenir:
0:r0 Connected Primary/Secondary UpToDate/UpToDate C r----- /mnt ext4
7.9G 146M 7.4G 2%
Cela nous montre bien que node2 est devenu primaire et que la partition drbd est bien monté. Nous pouvons
aussi vérifier que l’IP de balancement est bien présente sur node2.

19
Maintenant on remet node1 en primaire en redémarrons Heartbeat avec la commande:
Maintenant que notre cluster drbd est actif on va installer apache pour mettre en place un site hautement
disponible.
 Installation d’apache
On commence par installer Apache et PHP5 sur les deux nodes avec la commande:
apt-get install apache2 php5
Après l’installation d’Apache, nous allons désactiver sur les deux nodes le démarrage automatique du service
au lancement de la machine parce que c’est Heartbeat qui va gérer le lancement d’Apache.
Sur les deux nodes lancons donc la commande :
insserv -r apache2
Et arrêtons Apache sur node2 avec la commande :
/etc/init.d/apache2 stop
Sur le node1 nous allons créer dans /mnt/ un dossier « www » pour stocker les pages web. Dans ce dossier
nous allons créer une page Web par défaut pour vérifier que le balancement fonctionne.
Donc dans « /mnt/www/ » créez un fichier index.php avec le contenu suivant:
<?php
echo "Bienvenue sur ".gethostname()."n"
?>
Nous allons faire en sorte que le dossier des pages par défaut d’Apache soit /mnt/www au lieu de /var/www.
Ensuite, nous allons créer un lien symbolique de « /var/www » vers « /mnt/www/ ».
Sur les deux nodes faites les commandes suivantes:
rm -rvf /var/www/
ln -s /mnt/www/ /var/
Nous pouvons vérifier que le lien est fonctionnel avec la commande:
ls -la /var/www
Nous devrions voir cette ligne :
lrwxrwxrwx 1 root root 9 Dec 22 11:05 /var/www -> /mnt/www/
Maintenant nous allons configurer Heartbeat pour qu’il gère le démarrage automatique d’Apache.

20
Sur les deux nodes éditons le fichier « /etc/ha.d/haresources » et rajoutons simplement apache2 à
la fin de la ligne.
Nos fichiers /etc/ha.d/haresources devraient ressembler à ceci :
node1 IPaddr::192.168.2.57/24/eth0 drbddisk::r0
Filesystem::/dev/drbd0::/mnt::ext4 apache2
Rechargeons le fichier de configuration Heartbeat sur les deux nodes avec la commande:
/etc/init.d/heartbeat reload
Nous allons vérifier si le balancement fonctionne bien.
Ouvrons un navigateur internet et connectons-nous à l’adresse IP balancé de notre cluster DRBD/Apache. Pour
ma part l’IP est 192.168.2.57. Nous devrions voir une page avec le texte suivant: « Bienvenue sur node1 » si
bien sur node 1 est le node actif.
Si nous voyons bien cela arrêtons HeartBeat sur le node1, patientons quelques secondes et rechargeons la page
web. Maintenant le texte affiché devrait être « Bienvenue sur node2 ».
La page index.php que nous avons mis dans « /mnt/www/ » nous affiche le hostname de la machine.
Nous voyons donc bien que le balancement se fait bien entre les deux nodes de notre cluster DRBD/Apache.
Pour finir relançons Heartbeat sur node1. Rechargeons la page web et le texte « Bienvenue sur node1 » apparait
de nouveau.
Sur node2 nous pouvons voir avec la commande « /etc/init.d/apache2 status » que le service
Apache n’est pas démarré. Heartbeat démarre et arrête automatiquement le service Apache.
3.1 Evaluation des coûts
Comme tout projet, le déploiement de cette solution nécessite un certain nombre de coûts liés à l’acquisition
du matériel et de prestation de service. Le tableau ci-dessous résume ces différents coûts et le coût total de la
mise en place de la solution.

21
Tableau 2 : Tableau des coûts du projet9
Acquisition du matériel
Désignations Quantité Prix unitaire (en
FCFA)
Prix total (en FCFA)
SERVEUR HPE ProLiant ML350
Gen9 - Xeon E5-2630V3 2.4 GHz -
32 Go - 5U, Disque dur 6x1To 6G
SATA 7,2 k 2,5" SC MDL HDD
655710-B21
2 5 732 943 11 465 886
Onduleur Monophasé de 10KVA
avec une unité de stockage externe
de 8 a 10 KWH et une armoire de
protection
1 3 500 000 3 500 000
Sous-total 1 14 965 886
Prestation de service
Câblage – installation et
configuration des serveurs
5 jours ouvrés forfait 1 500 000
Transfert de compétence (formation
des administrateurs réseaux)
3 jours ouvrés forfait 150 000
Frais de maintenance de service 6 mois forfait 300 000
Sous-total 2 1 950 000
TOTAL GENERAL 16 915 886
3.2 Perspectives
La haute disponibilité que nous venons de traiter n’a pas pris en compte tous les aspects liés à ce domaine.
Ainsi, la solution mise en place pourrait avoir une faille dans la mesure où si tout le local technique venait
d’être frapper par une catastrophe sous toutes ses formes. C’est pourquoi, nous envisagerons dans le futur faire
des réplications sur des Cloud privé (Cloud computing) pour la dématérialisation des services ou données de
l’entreprise.
9
Par moi-même

Conclusion générale
Le trio DRBD - Heartbeat - Apache est parfait pour assurer la redondance de deux machines physiquement
proches faisant office des serveurs web. Assurant à la fois la surveillance des défaillances des systèmes mais
aussi celle des services, cette solution met un terme au problème de redondance et d'interruption de service.
Le projet Open source High Availbility est en constante évolution depuis son lancement en 1999 et la limitation
initiale des 2 nœuds est désormais révolue. Une entreprise aux revenus limités ne désirant pas investir dans un
SAN coûteux et à la maintenance ardue peut maintenant disposer d'une solution complète, fiable, facile à
administrer et totalement libre. Une bonne idée est d'associer l'environnement logique que nous venons de
traiter à un environnement physique de disques durs montés en RAID pour des structures plus larges.

1
Bibliographie
[1] Mémoire on-line de Armel Francklin SIMO TEGUEU, thème : Plate- forme d'entreprise sécurisée et de
haute disponibilité, promotion 2009.
[2] support numérique de Nicolas Schmitz, Centre de Ressources Informatiques, Ecole Centrale de Nantes,
44000 Nantes, Nicolas.Schmitz ec-nantes.fr.
[3] Nicolas Ferre, Livre blanc Haute disponibilité sous Linux, Nicolas.Ferre@alcove.fr , 29 septembre 2000.
[4] Support de cours numérique de F A L C H I _ S O U BRAT_RAYMOND
[5] https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-097/Cluster-haute-disponibilite-avec-
equilibrage-de-charge visité le 05/10/2017 à 17:24
[6] https://www.celeste.fr/fondamentaux-haute-disponibilite-entreprise visité le 0410/2017 à 12:24
[7] https://fr.wikipedia.org/wiki/Haute_disponibilit%C3%A9 visité le 26/09/2017 à 17:24
[8] http://denisrosenkranz.com/tuto-ha-un-cluster-drbdapache-avec-heartbeat-sur-debian-7/ visité le
05/10/2017 à 17:00
[9] http://lea-linux.org/documentations/La_haute_disponibilit%C3%A9 visité le 22/09/2017 à 14 :30

CLUSTERING ET HAUTE DISPONIBILITE

Contenu connexe

Tendances (20)

Similaire à CLUSTERING ET HAUTE DISPONIBILITE (20)

Dernier (16)

CLUSTERING ET HAUTE DISPONIBILITE