Вы находитесь на странице: 1из 75

Universit de Maroua

****
Institut Suprieur du Sahel
****
Dpartement dInformatique et des

The University of Maroua


****
The Higher Institute of the Sahel
****
Department of Computer Science and

Tlcommunications

Telecommunications

****

****

INFORMATIQUE ET TLCOMUNICATIONS

CLUSTERING ET HAUTE DISPONIBILIT DES


INFRASTRUCTURES RSEAU DU MINISTRE DE
LENSEIGNEMENT SUPRIEUR
Mmoire prsent et soutenu en vue de lobtention du Diplme dINGENIEUR DE
CONCEPTION EN RSEAUX INFORMATIQUES

Par

KEPSEU KAMENI Jaspers


Ingnieur de Travaux en Scurit et Administration Rseaux
Matricule : 11V381S

Sous la Direction de

Prof. EMVUDU WONO Yves


Matre de Confrences
Devant le jury compos de :
Prsident :

Prof. DANWE RADANDI

Rapporteur :

Prof. EMVUDU WONO Yves

Examinateur :

Dr. NLONG II Jean Michel

Anne Acadmique 2013 / 2014

pigraphe

"Ayez confiance en vous cest ltat desprit permanent


qui vous permet de franchir les obstacles imprvus et
davancer avec convictions. Vous ntes que ce que vous
tes parce que vous avez accept ltre . "
FRANKLIN DELANO ROOSVELT

Ddicace

la grande famille KAMENI.

ii

Remerciements
Jai pu raliser ce travail grce aux efforts conjugus de plusieurs personnes
qui je voudrai exprimer ma profonde gratitude. Ainsi, jadresse mes sincres
remerciements :
Pr. DANWE Radandi pour avoir accept de prsider ce jury
Dr. NLONG II Jean Michel pour avoir accept dvaluer ce travail
Prof. EMVUDU Yves qui na mnag aucun moyen pour me permettre de
faire le stage et malgr toutes ses occupations, il ma encadr dans la
rdaction.
Dr. VIDEME BOSSOU OLIVIER le Chef du Dpartement dInformatique
et des Tlcommunications pour tous les efforts quil a abattu pour nous
suivre comme un bon pre de famille.
Mme BOUDJOU Hortense pour le suivi gratuit quelle ma accorde ds
mon entre lInstitut Suprieur du Sahel jusqu' mon niveau actuel.
Quelle reoit travers ce travail toute ma reconnaissance.
M. NGWET HANS pour le suivi professionnel de ce travail.
Dr. DADA Jean Pierre pour ses corrections et ses remarques
Mes parents, M. KAMENI Bernard et Mme KAMENI ne POUEME Odette
qui malgr toutes mes caprices ont toujours dploy toutes leurs nergies
pour faire de moi un homme.
Mes

frres SIAHE Idriss, DEUGOUE Bachelard, KAMAN Firmin,

NGEUHOU Chardin.
Mes cousins et cousines Eric, Stephen, Aim, Martial, Nelly, Lopold .
Mes amis TANEKEU Igor, MOYAP Ren, WOUWO David, WONYOU
Didier, OUAFO WILLIAMS, ESSANA Christelle, NGUESUH Stella, ANGO
Jean, PRISCA, DONA. Pour leurs rconforts et la relecture de ce travail.
Tous ceux qui, de prs ou de loin ont contribus mon ducation, quils
reoivent ici lexpression de ma profonde gratitude.

iii

Tables des matires


P I G RAP H E ............................................................................................................................................................. I
D D IC AC E .............................................................................................................................................................. II
REM E RC I EM E NT S ............................................................................................................................................ III
TAB L E S DE S M A T I R E S ............................................................................................................................... IV
L IS T E D E S S I G L E S E T AB R V I A TI O N S ............................................................................................... VI
R S UM .................................................................................................................................................................. IX
AB S T RA C T ...............................................................................................................................................................X
L IS T E D E S TAB L EA U X ................................................................................................................................... XI
L IS T E D E S F I GU R ES E T I L LU S TR A TI O N S ....................................................................................... XII
IN T RO D UC T IO N G N R A L E ........................................................................................................................ 1
CH AP I T R E 1 ............................................................................................................................................................ 2
CO N T E XT E E T P RO B L M AT I Q U E ............................................................................................................ 2
1.1 PRSENTATION DU LIEU DE STAGE ..................................................................................................................... 2
1.1.1

Historique ........................................................................................................................................... 2

1.1.2

Organisation du CITI ......................................................................................................................... 2

1.1.3

Localisation du CITI........................................................................................................................... 4

1.2 CONTEXTE ET PROBLMATIQUE ......................................................................................................................... 4


1.3 MTHODOLOGIE ................................................................................................................................................. 6
1.4 LES OBJECTIFS .................................................................................................................................................... 7
CH AP I T R E 2 ............................................................................................................................................................ 8
G N R AL I T S ...................................................................................................................................................... 8
2.1 INTRODUCTION ................................................................................................................................................... 8
2.2 MSURE DU TAUX DE DISPONIBILIT ................................................................................................................. 9
2.3 TECHNIQUES AMELIORANT LA DISPONIBILITE ..................................................................................................... 9
2.3.1

Rpartition de charge et sensibilit .................................................................................................. 10

2.3.2

Les techniques de gestion de qualit de service ............................................................................... 17

CH AP I T R E 3 .......................................................................................................................................................... 23
TU D E A P P R O F O ND I E DU R ES E AU D U M I NI S T ER E E T AP P R EC IA T IO N D E S A
DI SP O N IB I L I T E ........................................................................................................................................... 23
3 . 1 RECENSEMENT DU MATERIEL ........................................................................................................................... 23
3.2 EFFICACITE DES SERVEURS ............................................................................................................................... 23

iv

3.3 PRESENTATION DE LARCHITECTURE RESEAU ................................................................................................... 24


3.4 SIMULATION DU RESEAU DU MINESUP .......................................................................................................... 25
3.4.1

Choix du simulateur ......................................................................................................................... 26

3.4.2

Les points nvralgiques de larchitecture......................................................................................... 29

3.5 GESTION DE LA BANDE PASSANTE .................................................................................................................... 34


3.6 GESTION DU ROUTAGE DES PAQUETS ................................................................................................................ 34
3.7 PRESENTATION DES FAIBLESSES ET DES LIMITES DE CE RESEAU ....................................................................... 35
CH AP I T R E 4 .......................................................................................................................................................... 36
M ISE S UR P I E D DE L A H A U T E D I SP O N IB I L I T E D U R E S EA U E T CL U S TE R IN G D E S
S ER V EU RS ...................................................................................................................................................... 36
4.1 MISE EN UVRE DE LA HAUTE DISPONIBILITE DU RESEAU ................................................................................ 36
4.1.1

Mise en uvre dune connexion de secours ..................................................................................... 36

4.1.4

Rduction de la congestion ............................................................................................................... 42

4.2 MISE EN UVRE DE LA HAUTE DISPONIBILITE DES SERVICES (CLUSTERING) ..................................................... 44


4.2.1

Prsentation de LVS ......................................................................................................................... 44

4.2.2

Choix de la mthode de clustering .............................................................................................. 45

4.2.3

Mise en uvre des quilibreurs (Load Balancer) ............................................................................ 46

CH AP I T R E 5 .......................................................................................................................................................... 50
RE S U LT A T S E T CO M M ENT A IR E S ........................................................................................................... 50
5.1 NOUVELLE ARCHITECTURE ............................................................................................................................... 50
5.2 REDONDANCE DES ROUTEURS........................................................................................................................... 51
5.3 REDONDANCE DES SERVEURS ........................................................................................................................... 53
CO N C LU S IO N E T P E RSP E C T IV E S ........................................................................................................... 57
B IB LIO G R AP H I E ................................................................................................................................................ 58
AN NE X E .................................................................................................................................................................. 59

Liste des sigles et abrviations

ARP: Address Resolution Protocol


AVF: Active Virtual Forwarder
AVG: Active Virtual Gateway
BCV : Business Copy Volume
BTS : Brevet du technicien Suprieur
CBQ: Class-Based Queuing
CBWFQ: Class-Based Weighted Fair Queueing
CITI: Centre Interuniversitaire des Technologies de lInformation
CU: Currently Unused
DHCP: Dynamic Host Configuration Protocol
DiffServ: Differentiated Services
DNS: Domain Name System
DR: Direct Routing
DRBD : Distributed Replicated Block Device
DSCP : Differentiated Service CodePoint
ENS : Ecole Normale Suprieure
FAI: Fournisseur Accs Internet
FIFO: First In First Out
FQ: Fair Queuing

vi

FTP: file Transfert Protocol


GLBP: Gateway Load Balancing Protocol
HSRP: Hot Standby Router Protocol
HTTP: Hyper Text Transfer Protocol
ICMP : Internet Control Message Protocol
IGNU : Institut de la Gouvernance Numrique Universitaire
IP: Internet Protocol
LAN: Local Area Network
LVS: Linux Virtual Server
MAC: Medium Access Control
MINESUP : Ministre de lEnseignement Suprieur
MPLS : MultiProtocol Label Switching
NAT: Network Address Translation
NS: Network Simulator
OSI: Open System Interconnection
PHB: Per Hop Behavior
POP: Post Office Protocol
QoS: Quality of Service
RAID: Redundant Array of Inexpensive Disks
SMTP: Simple Mail Transfer Protocol
SRDF: Symmetrix Remote Data Facility

vii

TCI: Tag Control Information


TCL: Tool Commande Language
TCP: Transmission control Protocol
ToS: Type of Service
TPID: Tag Protocol Identifier
UDP: User Datagram Protocol
URL: Uniform Ressource Locator
VLAN: Virtual Local Area Network
VOIP: Voice Over IP
VRRP: Virtual Router Redundancy Protocol
WAN: Wide Area Network
WLAN: Wireless Local Area Network

viii

Rsum
Lavance galopante de linformatique et particulirement des rseaux
informatiques a permis ce que le monde soit actuellement considr comme un
village plantaire. De ce fait, les Administrations publiques et les Entreprises se dotent
de plus en plus des infrastructures Rseaux pour communiquer, donner des
informations, ou encore offrir des services divers. La mise la disposition du public du
Rseau dune Entreprise ou dune organisation implique de la part de cette structure
une garantie de la disponibilit des services offerts.
La haute disponibilit a toujours tenu une place importante, voire prpondrante
dans la conception des architectures des Rseaux informatiques. Ce mmoire
synthtise le travail effectu au CITI (Centre Interuniversitaire des Technologies de
lInformation) sur le Clustering et la haute disponibilit des infrastructures Rseau
du Ministre de lEnseignement Suprieur . Pour atteindre cette haute disponibilit, il
faut la fois combiner les techniques de redondance du matriel avec rpartition de
charge, et ensuite de gestion de la Qualit de Service sur les nuds qui peuvent un
moment donn tre congestionns.
la suite dun constat fait par simulation minutieuse du rseau du Ministre,
nous avons dabord orient notre travail sur la disponibilit du rseau. Cette premire
rflexion a dbouch sur la redondance des routeurs dentre au rseau grce au
dploiement du protocole GLBP (Gateway Load Balancing Protocol). Le second
aspect de notre rflexion a t accentu sur la disponibilit des services rseau qui sont
offerts au public. La mise en uvre dune grappe de serveurs (cluster) grce la LVS
(Linux Virtual Server) couple un rpartiteur de charge (Heartbeat) pour chaque
service, rsout le problme dindisponibilit des services.
Mots cls : haute disponibilit, rpartition de charge, grappe de serveur, GLBP, LVS,
Qualit de Services

ix

Abstract
Galloping of computer sciences and computer networks in particular have
made possible that the world is currently considered as global village. Thus, public
administrations and companies shall have in place more infrastructure networks to
communicate, provide information, or offer various services. Making network
available to the public implies that the enterprise should use structures that guarantee
the availability of services
High availability of services has always held an important place, even
predominant in the design of computer architectures networks. This thesis summarizes
the work done at ICIT (Interuniversity Center of Information Technology) on
"Clustering and high availability of network infrastructure in the Ministry of Higher
Education." To achieve this high availability, it is necessary to combine both
techniques, hardware redundancy with load balancing, and then manage the Quality of
Service on nodes that may be congested at some point.
Following our observation made by a meticulous simulation on the ministry
network, we initially focused our work on network availability. This first reflection led
to redundant edge routers through the deployment of GLBP (Gateway Load Balancing
Protocol). The second aspect of our thinking has been highlighted on the availability
of network services that are offered to the public. The implementation of a cluster of
servers with the LVS (Linux Virtual Server) coupled to a load balancer (Heartbeat) for
each service solves the problem of service unavailability.

Keywords: high availability, load balancing, server clustering, GLBP, LVS, Quality
of Services

Liste des tableaux


TABLEAU 2.1 :

TAUX DE DISPONIBILITE [9]............................................................................................................ 9

TABLEAU 3.1 :

COMPARAISON DES SIMULATEURS [5]. ......................................................................................... 28

TABLEAU 4.1 :

COMPARAISON DES METHODES DE CLUSTER AVEC LVS .............................................................. 45

xi

Liste des figures et illustrations


Figure 1.1

Plan de localisation du CITI ......................................................................................................... 4

Figure 2.1

Rseau dot un cluster [11]......................................................................................................... 13

Figure 2.2

Rseau de haute disponibilit avec duplication de load Balancer [11] ...................................... 14

Figure 2.3

Architecture fonctionnelle de LVS NAT ...................................................................................... 15

Figure 2.4

Architecture fonctionnelle de LVS Direct Routing ...................................................................... 16

Figure 2.5

Architecture fonctionnelle de LVS tunnelling.............................................................................. 17

Figure 2.6

Localisation du champ TAG dans la trame Ethernet [4] ............................................................ 21

Figure 2.7

Localisation du champ DS dans lEntte du paquet IP [4] ......................................................... 22

Figure 3.1

architecture simplifie du rseau du MINESUP ......................................................................... 25

Figure 3.2

Prsentation de la simulation du rseau. .................................................................................... 31

Figure 3.3

Simulation dun trafic de 5200 bits toute les 5millisecondes ...................................................... 33

Figure 3.4

Simulation dun trafic de 6400 bits toute les 5millisecondes ...................................................... 33

Figure 4.1

Rseau haute disponibilit internet envisag ........................................................................... 38

Figure 4.2

Politique de QoS applique aux routeurs dentre ..................................................................... 43

Figure 4.2

Cluster WEB haute disponibilit .............................................................................................. 49

Figure 5.1

Architecture du rseau haute disponibilit............................................................................... 50

Figure 5.2

Prsentation de la configuration de lAVG Camtel..................................................................... 51

Figure 5.3

Constatation de la rpartition de charge "load balancing" ........................................................ 52

Figure 5.4

Paramtre rseau du serveur2 .................................................................................................... 53

Figure 5.5

Paramtre rseau du serveur1 .................................................................................................... 54

Figure 5.6

Table ARP du client..................................................................................................................... 54

Figure 5.7

Rsultat du "ping" sur le cluster aprs de multiples interruptions de serveur ............................ 55

Figure 5.8

Rsultat de la table ARP du client aprs plusieurs interruptions dun serveur du cluster. ......... 56

xii

Introduction Gnrale

Les concepteurs des rseaux informatiques dans des structures se confrontent au


compromis entre performance, et rduction du cot lors du choix architectural du
rseau de Leurs Entreprises. Pour garantir une bonne performance et une satisfaction
des utilisateurs, il est ncessaire dassurer la Haute Disponibilit du rseau dans
toute sa globalit.
La haute disponibilit est donc cet effet primordiale, surtout lorsque le rseau
offre des services un public incomptable et divers. Si non comment comprendre que
des grandes firmes telles que Yahoo ou Google, parviennent desservir efficacement
des millions de clients simultanment sans que lon ne se rende compte de la moindre
dfaillance de leur rseau ? Cest donc ce problme dindisponibilit des services
rseaux (cas du Ministre de lenseignement Suprieur) que nous avons essay de
rsoudre dans ce travail.
Pour mieux rpondre la question prcdente, nous avons subdivis ce travail
en cinq chapitres :
Le premier chapitre, intitul Le contexte et la problmatique du sujet , va nous
situer et nous claircir sur la faon dont nous avons eu le sujet. Quant au second
chapitre intitul Gnralits , nous nous intresserons aux gnralits lies la
haute disponibilit. Ltude Approfondie du rseau du ministre est le titre du
troisime chapitre. Laccent sera mis ici sur larchitecture actuelle du rseau du
ministre ; nous ferons un examen minutieux de ce rseau afin dtecter les causes de
lindisponibilit. Au quatrime chapitre dont le titre est Mise sur pied de la haute
disponibilit du rseau et Clustering des serveurs, il faudra proposer une solution
palliative des problmes dindisponibilit qui auront t dtects afin de garantir la
haute disponibilit. Enfin nous prsenterons nos rsultats au dernier chapitre, intitul
Les Rsultats et commentaires . Ce travail fini par une conclusion gnrale et une
revue bibliographique.

Chapitre 1
Contexte et problmatique

Contenu
1.1

Prsentation du lieu de stage

1.2

Contexte et problmatique

1.3

Mthodologie

1.4

Les objectifs

1.1

Prsentation du lieu de stage

1.1.1

Historique

Le Centre Interuniversitaire des Technologies de lInformation (CITI) a vu le


jour le 19 juin 2006. Il a t cre pour lensemble des institutions universitaires
publiques et est plac sous lautorit du ministre charg de lenseignement suprieur.
Son sige se trouve au campus de luniversit de Yaound I. Travaillant en troite
collaboration avec les centres informatiques et multimdias des universits dtat du
Cameroun, Le CITI est donc un centre dappui lappropriation des technologies de
linformation et de la communication par les institutions universitaires camerounaises.

1.1.2

Organisation du CITI

Le CITI est constitu des organes suivant :


Le conseil du centre ;

Lorgane excutif du centre.


Le conseil du centre est prsid par le ministre charg de lenseignement suprieur.
Il est compos des membres ci-aprs.
Un reprsentant du ministre charg de la recherche scientifique et de
linnovation ;
Un reprsentant du ministre charg des tlcommunications ;
Un reprsentant du ministre charg de lindustrie, des mines et du
dveloppement technologique.
Un reprsentant du ministre charg de lconomie et des finances ;
Un prsident de la confrence des recteurs ou son reprsentant ;
Un reprsentant de lagence nationale des technologies de linformation et de la
communication ;
Un reprsentant par universit dtat ;
Un reprsentant des institutions prives denseignement suprieur agr dsign
par ses pairs ;
Un reprsentant des milieux socioprofessionnels choisi par ses pairs selon un
mcanisme de rotation des diffrentes composantes ;
Un reprsentant du personnel.
Lorgane excutif est plac sous lautorit dun coordonnateur appuy par les
units oprationnelles. Le coordonnateur est dsign par le ministre charg de
lenseignement suprieur lissue dun test pass devant le conseil du centre aprs
sa slection suite une procdure dappel

la candidature. Les units

oprationnelles du centre sont :


Lunit de la formation ;
Lunit des infrastructures, rseaux et tlcommunications ;
Lunit des bases de donnes et systme dinformation ;
Lunit administrative et financire.

la tte de chaque unit est plac un chef qui est le coordonnateur des activits
concernant lunit.

1.1.3

Localisation du CITI

Le CITI est situ dans la ville de Yaound au quartier Melen son btiment se

Vers Mokolo

trouve juste cot de lcole national suprieur Polytechnique (ENSP).

Etou-Ebe
Garde Prsidentielle
Melen

Total Melen

EMIA

Carrefour Obili

CHU

ENSP

IGNU
(CITI)

Figure 1.1 Plan de localisation du CITI

1.2

Contexte et problmatique
Le MINESUP est un dpartement ministriel qui a la lourde responsabilit

dlaborer et de mettre en uvre la politique du gouvernement en matire


denseignement suprieur [12]. ce titre, il est charg de :
Lorganisation,

du

fonctionnement

et

du

contrle

pdagogique

de

lenseignement suprieur ;
La prennisation des missions traditionnelles de lenseignement suprieur ; la
promotion et de la diffusion de la recherche universitaire ;

La coopration universitaire internationale en liaison avec le Ministre des


Relations Extrieures et les Administrations concernes ;
La garantie de la qualit de la formation de lenseignement suprieur.
Pour atteindre ces objectifs, le ministre a un ensemble de services et de divisions
parmi lesquels ont y trouve la division des systmes dinformation. Cette division
quant elle est charge :
De la conduite de llaboration et du suivi de la mise en uvre du schma
directeur informatique du ministre ;
Du pilotage des Systmes dInformation du Ministre
Des tudes de dveloppement, de lexploitation et de la maintenance des
applications et du rseau informatique du ministre ;
Du dveloppement et de ladministration technique des sites Web du ministre,
en liaison avec la Cellule de la communication ;
Du traitement informatique et la diffusion des donnes
Au vu de ces diffrentes missions non exhaustives tant au niveau de la division des
systmes dinformation que du ministre tout entier, il ressort que le ministre doit tre
en permanence en contact avec tous les acteurs du milieu universitaire. Pour y
parvenir, Cette division a produit plusieurs services et applications dont un service
web qui est accessible par tous via Internet. Ce service a t trs bien pens dans la
mesure o il rsout quelques problmes cruciaux de lheure quils soient chez les
tudiants que chez les enseignants. En effet, le site
Informe les tudiants sur lactualit du ministre
Informe les tudiants sur les bourses dtude et donne les modalits sous
fichiers joints
Met la disposition des tudiants les arrts des examens et des concours
Met la disposition du Public les rsultats des diffrents concours et examens
officiels linstar du BTS, des ENS etc.
Pour les enseignants, le site
Leur informe sur la passation de grade
Leur signale les ventuels recrutements

Leur informe aussi sur les bourses de recherche


Il est noter que toutes ces informations fournies par le site Web sont gnralement
sous fichier joint en format PDF. Donc les utilisateurs doivent tlcharger avant de les
exploiter. Parmi les services rseau que dispose le MINESUP, nous avons aussi un
service mail qui est sous le nom de domaine minesup.gov.cm ce service permet au
ministre de grer les mails.
Lors de la publication des informations sur le site web, en particulier celles qui
attirent beaucoup de monde linstar des rsultats du BTS, nous avons fait un constat
selon lequel le site web devient difficile accder. Et quand bien mme un utilisateur
la chance daccder, ce dernier aura de la peine rcuprer le fichier sur le site. Nous
avons galement constat que ce problme se rpercute aussi sur le serveur Mail. Face
ce problme dindisponibilit des services rseaux du ministre, il en dcoule donc la
problmatique suivante :
Comment mettre en place une infrastructure rseau haute disponibilit permettant
de garantir lefficacit des services rseau du ministre ?
Cest donc problme nous a t soumis au niveau du CITI.

1.3

Mthodologie

Pour rsoudre le problme dindisponibilit du rseau et des services rseau du


ministre, nous allons procder de la manire suivante :
Dabord nous allons faire une tude approfondie du rseau. Ici, le travail
consistera valuer les capacits actuelles du rseau et des serveurs.
Ensuite nous allons rsoudre le problme dindisponibilit du rseau.
Enfin grer la haute disponibilit des services par le dploiement des
clusters1 pour chaque service.

"Cluster" (une grappe en Franais) est un groupe de machines rendant le mme service de manire transparente
pour les Clients.

1.4

Les objectifs
Le but de la mise en uvre dune infrastructure haute disponibilit au

MINESUP est de permettre aux diffrents utilisateurs en particulier les universitaires


davoir des services toujours disponible mme lorsque les serveurs sont assez
sollicits. Plus prcisment de toujours rpondre la demande des clients

Chapitre 2
Gnralits
Gnralit s

Contenu
2.1

Introduction

2.2

Mesure du taux de disponibilit

2.3

Techniques amliorant la disponibilit

2.1

Introduction
La haute disponibilit est un terme souvent utilis en informatique, propos

d'architecture de systme ou d'un service pour dsigner le fait que cette architecture ou
ce service a un taux de disponibilit convenable. La disponibilit est aujourd'hui un
enjeu important des infrastructures informatiques. L'indisponibilit des services
informatiques est particulirement critique dans le domaine de l'industrie, notamment
en cas d'arrt d'une chane de production.
Deux moyens complmentaires sont utiliss pour amliorer la haute disponibilit :

la mise en place d'une infrastructure matrielle spcialise, gnralement en se


basant sur de la redondance matrielle. Le but est de crer un cluster de haute
disponibilit qui est une grappe d'ordinateurs dont lobjectif est d'assurer un
service en vitant au maximum les indisponibilits.

la mise en place de processus adapts permettant de rduire les erreurs, et


d'acclrer la reprise en cas d'erreur.

2.2

Mesure du taux de disponibilit


La disponibilit se mesure souvent en pourcentage essentiellement compos de

9. Par exemple une disponibilit de 99 % indique que le service ne sera pas disponible
pendant 3,65 jours par an maximum. On atteint la haute disponibilit partir de
99,9%: le tableau en dessous est fourni pour les diffrents taux de disponibilit).

Disponibilit en %

Indisponibilit

Indisponibilit par

Indisponibilit par

par anne

mois

semaine

90 % ( un neuf )

36.5 jours

72 heures

16.8 heures

95%

18.25 jours

36 heures

8.4 heures

98 %

7.30 jours

14.4 heures

3.36 heures

99 % ( deux neuf )

3.65 jours

7.20 heures

1.68 heures

99.5 %

1.83 jours

3.60 heures

50.4 minutes

99.8 %

17.52 heures

86.23 minutes

20.16 minutes

99.9 % ( trois neuf )

8.76 heures

43.2 minutes

10.1 minutes

99.95 %

4.38 heures

21.56 minutes

5.04 minutes

99.99 ( quatre neuf )

52.56 minutes

4.32 minutes

1.01 minutes

99.999 % ( cinq neuf )

5.26 minutes

25.9 secondes

6.05 secondes

999.999% ( six neuf )

31.5 secondes

2.59 secondes

0.605 secondes

Tableau 2.1 : Taux de disponibilit [9]

2.3

Techniques amliorant la disponibilit


Les pannes dans un systme informatique peuvent avoir de multiples sources.

Les origines peuvent tre physiques (naturelle ou criminelle), d'origines humaines


(intentionnelle ou non) voir oprationnelle (un dysfonctionnement logiciel par

exemple). La haute disponibilit ncessite donc une architecture adapte mais aussi
des locaux qui peuvent abriter cette architecture. Il est ncessaire par exemple
d'alimenter

les composants par une alimentation stabilise, d'installer une

climatisation sous plancher avec filtre particule afin de maintenir les conditions
d'utilisations optimum et minimiser les risques de coupures et donc d'arrt. Un
service de maintenance et ventuellement de gardiennage pour prvenir du vol ou
des dgradations. Les risques d'incendies doivent aussi tre pris en compte ainsi que la
protection des cbles. Ceux ci doivent tre enterrs et multiplis afin de prvenir tout
risque de coupure volontaire ou accidentelle. Ces prcautions de base sont des critres
prendre en compte ds le dbut de l'installation du serveur ou du choix du
prestataire d'hbergement. Ces prcautions bien qutant externe l'architecture sont
trs importantes mais ne suffisent pas pour garantir une haute disponibilit. Afin de
pouvoir amliorer voire atteindre la haute disponibilit, de nombreuses techniques sont
utilises :

la redondance des matriels et la mise en cluster ;

la mise en uvre des bonnes politiques de qualit de service

la scurisation des donnes : RAID, snapshots, Oracle Data Guard , BCV


(Business Copy Volume), SRDF (Symmetrix Remote Data Facility),
DRBD(Distributed Replicated Block Device) ;

la possibilit de reconfigurer le serveur chaud (cest--dire lorsque celui-ci


fonctionne) ;

plan de secours ;

et scurisation des sauvegardes : externalisation, centralisation sur site tiers.

2.3.1

Rpartition de charge et sensibilit

La sensibilit est souvent gre en redondant les lments avec un mcanisme


de rpartition de charge (un cluster websphere avec un load-balancing Alteon par
exemple). Pour que ce systme apporte un rel gain en termes de fiabilit, il faut
vrifier que si un des lments est dfaillant, les lments restants disposent dune

10

puissance suffisante pour assurer le service. Autrement dit, dans le cas de deux
serveurs actifs avec rpartition de charge, la puissance dun seul serveur doit permettre
dassurer la totalit de la charge. Avec trois serveurs, la puissance dun seul serveur
doit permettre dassurer 50 % de la charge (en supposant que la probabilit davoir un
incident sur deux serveurs en mme temps est ngligeable). Pour assurer une bonne
fiabilit, il est inutile de mettre en grand nombre de serveurs se secourant
mutuellement. Par exemple, un lment fiable 99 % redond une fois donne une
fiabilit de 99,99 % (probabilit que les deux lments soit dfaillants au mme
moment = 1/100x1/100 = 1/10000).
a)

La redondance des matriels

La redondance est comme son nom l'indique une duplication partielle ou totale
du systme informatique. Il existe plusieurs types de redondance :
La redondance symtrique
La redondance asymtrique
La redondance volutive
La redondance modulaire
La redondance symtrique repose sur le principe de dupliquer deux quipements
semblables l'identique point par point.
La redondance asymtrique permet de basculer d'un type de matriel un autre, il
n'est pas forcment identique mais assure les mmes fonctionnalits avec si possible
des performances similaires.
La redondance volutive est comparable l'asymtrique mais on isole le systme
dfaillant lors d'une panne pour utiliser une autre partie du systme.
La redondance modulaire est une technique qui permet de dvier une panne d'un
systme sur un autre.

11

Dans tous les cas on ne parle de redondance seulement si les composants exercent les
mmes fonctions et ce sans dpendre les uns des autres. Leur influence mutuelle se
limite en gnral se rpartir la charge de travail ou des donnes. Des interactions
comme la consommation lectrique ou la dissipation de chaleur existent quand
mme. Certains composants effectuent des contrles sur l'activit de leur voisin afin
de se substituer celui ci s'ils sont manifestement hors d'usage, ou relancer le service
si cela est possible. Dans le cas de systmes complexes, on peut dupliquer diffrents
sous-ensemble. On travail successivement sur chaque sous-ensemble en commenant
par ceux jugs les moins fiables ou tant les plus critiques. Une fois dupliqu on
se concentre sur le prochain sous-ensemble jug le plus sensible ou fragile et
ainsi de suite. On poursuivra ce processus jusqu' avoir atteint le niveau de capacit,
de performance et de fiabilit requis et aussi tant que le surcot de l'installation est
jug rentable.
b)

La mise en cluster

La mise en cluster est aussi appel grappe de serveurs ou ferme de calcul. Le principe
est de regrouper des ordinateurs indpendants ainsi appels nuds. Cela permet de
dpasser les limitations d'un seul ordinateur et ainsi de les grer ensemble et non
indpendamment. Les avantages de cette solution sont :
Augmenter la disponibilit
Faciliter la monte en charge
Permettre une rpartition des charges
Faciliter la gestion des ressources telles que CPU, mmoire, disques etc.
Son inconvnient

majeur

est le cot de sa mise en uvre. Le principe de

fonctionnement est de regrouper des serveurs indpendants afin de les faire


fonctionner comme un seul et mme serveur. Le client discute comme si il tait
connect une seule machine. On peut ainsi crer des grappes constitues de
nuds de calcul, de stockage voire mme de monitoring. Ces nuds peuvent tre

12

relis entre eux par plusieurs rseaux. Lors d'une dfaillance d'un serveur, le logiciel
de clustering ragit en transfrant les tches excutes sur le systme dfaillant vers les
autres serveurs de la grappe. Ainsi dans le domaine de la gestion, les clusters sont
utiliss pour minimiser l'impact d'une panne de serveur sur la disponibilit de
l'application.

Figure 2.1 Rseau dot un cluster [11]


Dans la figure 2.1 ci haut, le Load balancer est install. Il sert la rpartition des
charges ainsi que d'aiguiller les requtes du client vers un nud particulier du cluster.
Afin de prvenir tout risque, il est recommand de dupliquer le load balancer. Ce
qui se traduit par le schma suivant :

13

Figure 2.2 Rseau de haute disponibilit avec duplication de load Balancer [11]
c)

Les architectures de rpartition de charge

La solution LVS (Linux Virtual Server) a pour objectif principal de construire


un serveur de haute performance en utilisant la technologie du clustering. Elle
prsente trois mthodes de rpartitions de charges qui sont : NAT (Network Address
Translation), DR (Direct Routing), IP-IP tunnelling.

LVS-NAT
Cette mthode est base sur le principe du NAT, c'est--dire sur la modification
des adresses IP ou les ports de destination. Lorsquun paquet arrive sur le rpartiteur,
ladresse IP de destination est substitue par celle du serveur qui a t choisi. Le client
ntant pas dans le rseau priv, le paquet de rponse du serveur est envoy au
rpartiteur celui ci remplace ladresse IP source cette fois par son adresse. Donc le
client recevra un paquet dont ladresse IP source est celle du rpartiteur et non celle du
serveur rel. LVS NAT a pour avantage lutilisation dadresses prives pour les
serveurs rels. Cette mthode est donc conome en adresse IP publiques.

14

Figure 2.3

Architecture fonctionnelle de LVS NAT [3]

LVS-DR
LVS Direct Routing modifie les tables ARP des serveurs pour transmettre les
paquets. Lors de larrive dun paquet sur le rpartiteur, celui-ci change ladresse
MAC de destination par celle du serveur lu puis modifie la table ARP de ce serveur
pour pouvoir rsoudre ladresse MAC de destination avec lIP du rpartiteur. la suite
de cette opration, le serveur va renvoyer directement (sans passer par le rpartiteur) sa
rponse au client avec comme adresse IP source celle du rpartiteur. Cette mthode est
contraignante car lensemble des machines du cluster doit partager la mme table
ARP.

15

Figure 2.4

Architecture fonctionnelle de LVS Direct Routing [3]

LVS Tunnelling
Cette mthode utilise lencapsulation IP IP (Tunnelling). Un paquet arrivant sur
le rpartiteur sera encapsul dans un nouveau paquet, puis envoy au serveur lu.
Ladresse IP de destination de ce paquet sera alors celle du serveur. Par suite le serveur
dsencapsule ce paquet pour rcuprer le paquet original. Il rpond ensuite en
envoyant sa rponse directement au client. Cette mthode lavantage de pouvoir
construire une grappe avec des machines trs loignes (rparties sur plusieurs
rseaux), pour faire des miroirs FTP par exemple. Le principal avantage de lutilisation
de tunnels est que les serveurs rels peuvent tre sur un des rseaux diffrents.

16

Figure 2.5

2.3.2

Architecture fonctionnelle de LVS tunnelling

Les techniques de gestion de qualit de service

La qualit de service (QDS) ou quality of service (QoS) est la capacit


vhiculer dans de bonnes conditions un type de trafic donn, en termes de
disponibilit, dbit, dlais de transmission, gigue2, taux de perte de paquets etc. Elle
est donc un concept de gestion qui a pour but doptimiser les ressources d'un rseau et
de garantir de bonnes performances aux applications critiques de lEntreprise. La
qualit de service permet doffrir aux utilisateurs des dbits et des temps de rponse
2

Cest la variation du dlai de transmission

17

diffrencis par applications suivant les protocoles mis en uvre au niveau de la


structure. Elle permet ainsi aux fournisseurs de services (dpartements rseaux des
entreprises, oprateurs) de sengager formellement auprs de leurs clients sur les
caractristiques de transport des donnes applicatives sur leurs infrastructures IP.
Selon le type de service envisag, la qualit pourra rsider dans le dbit
(tlchargement ou diffusion vido), le dlai (pour les applications interactives ou la
tlphonie), la disponibilit (accs un service partag) ou encore le taux de pertes de
paquets (pertes sans influence pour de la voix ou de la vido, mais critiques pour le
tlchargement). La qualit de service propre au domaine de la gestion de la qualit est
un concept utile en urbanisation du systme d'information grant les flux immatriels
et la logistique qui gre les flux matriels.
a)

Caractristiques

Dans un rseau, les informations sont transmises sous la forme de paquets, petits
lments de transmission transmis de routeur en routeur jusqu' la destination. Tous les
traitements vont donc s'oprer sur ces paquets. La mise en place de la qualit de
service ncessite en premier lieu la reconnaissance des diffrents services. Celle-ci
peut-se faire sur la base de nombreux critres :
La source et la destination du paquet.
Le protocole utilis (UDP/TCP/ICMP/etc.).
Les ports source et de destination dans le cas des protocoles TCP et UDP.
La date et l'heure.
La congestion des rseaux.
La validit du routage (gestion des pannes dans un routage en cas de routes
multiples par exemple).
La bande passante consomme.
Les temps de latence.

18

En fonction de ces critres, diffrentes stratgies peuvent ensuite tre appliques pour
assurer une bonne qualit de service.
b)

Choix des routes

Lorsquil existe plusieurs routes vers une destination, le choix d'une des routes
peut se faire pour garantir la qualit de service. Par exemple, une route proposant un
dlai faible sur un dbit faible sera utilise pour les applications interactives, tandis
qu'une route acceptant un meilleur dbit au prix d'un dlai plus long sera prfre pour
les applications moins sensibles au dlai (Streaming, tlchargement, etc.).
c)

Mise en forme du trafic

Mettre en forme un trafic (Traffic shaping) signifie prendre des dispositions


pour s'assurer que le trafic ne dpasse jamais certaines valeurs prdtermines.
Pratiquement, cette contrainte s'applique en dlayant certains paquets pour forcer un
certain trafic, selon divers algorithmes. Le contrle du trafic peut-tre utile pour limiter
l'engorgement et assurer une latence correcte. Par ailleurs, des limitations de dbits
sparment aux trafics permettent en contrepartie de leur assurer en permanence un
dbit minimum, ce qui peut tre particulirement intressant pour un fournisseur
d'accs par exemple, souhaitant garantir une certaine valeur du dbit ses clients.
Les deux algorithmes les plus utiliss sont :

Le seau perc

Le seau jetons
d)

Ordonnancement

La mthode par dfaut grant l'ordre de dpart des paquets est dfinie selon le
principe de "Premier arriv, premier servi", ou FIFO, "First In, First Out". Celle-ci
n'appose aucune priorit sur les paquets, et ceux-ci sont transmis dans l'ordre o ils
sont reus. D'un point de vue technique, cette mthode est toujours utilise par dfaut
sur les interfaces dont le dbit est suprieur 2 Mb/s. L'ordonnancement dsigne

19

l'ensemble des mthodes visant modifier cet ordre, en remplacement de la rgle


prcdente. Une de ses applications les plus courantes, le priority queuing, consistera
ainsi donner priorit certains types de trafic, de faon sommaire en ne laissant
passer du trafic de faible priorit que s'il n'y a plus de trafic de forte priorit, ou de
faon plus fine avec des algorithmes de Round-Robin pondrs (devenant alors du
custom queuing), visant faire passer des paquets des diffrentes connexions tour
tour, en laissant plus de temps aux paquets prioritaires. Une autre application, le fair
queuing consiste sparer nettement les connexions, et leur attribuer successivement
et quitablement une possibilit de faire passer leurs paquets : cela permet de s'assurer
qu'aucune application, mme trs demandeuse de dbit, n'en crasera d'autres. Une
version gnrale de cette application existe, le weighted queuing. Cette gnralisation
est effectue en multipliant la taille du paquet concern par l'inverse du poids de la file
dans laquelle il se trouve (le FQ en est un cas spcial dans le sens o les files ont
toutes le mme poids). Une dernire version existe, le class based queuing (autrement
appele Class-Based Queuing) qui utilisera des classes configures selon diffrents
critres (priorit, interface, application d'origine, ...) en lieu et place des connexions du
Fair Queuing. Chacune de ces classes se voit ainsi alloue une partie de la bande
passante en fonction de leur priorit globale. Une dernire application, appele le Low
Latency Queuing concentre son action sur le trafic sensible au dlai. Il prend comme
base le CBWFQ en rendant les priorits plus strictes. Cette mthode est
particulirement adapte l'usage de VOIP et de visiophonie.
e)

Les standards de la QoS aux niveaux 2 et 3


Standard 802.1q - niveau 2

Ce protocole, extension du protocole 802.1q, propose d'insrer dans le TAG de


la trame Ethernet un champ dfinissant la priorit de cette trame circulant dans les
architectures de rseau 802.1q, vhiculant donc les VLANs par des liens "taggus". On
est donc ici sur la couche 2 du modle OSI. 802.1q et ceci ne peut donc devenir
oprationnel que dans un contexte 802.1q.

20

Adresse

Figure 2.6

Adresse

Champ

Type

TPID-16

TCI 16

Priorit- 3

CFI- 1 bit

Donne

Contrl

VID- 12

Localisation du champ TAG dans la trame Ethernet [4]

Ce champ de 32 bits est insr aprs l'adresse MAC source de la trame. Il comprend un
champ TPID (Tag Protocol Identifier) qui permet d'indiquer le type de protocole (ici
802.1q) et le champ TCI (Tag Control Information) qui se dcompose lui-mme en
trois parties :
-

le champ de priorit, sur 3 bits, permettant de dfinir 8 niveaux de priorit ;

le champ CFI indiquant si on est en Token Ring ou Ethernet ;

le champ VID donnant le numro de VLAN (sur 12 bits) permettant 4094


VLANs.
L'entte IP et le champ DS (Differentiated Services)
La priorisation des flux peut se dfinir et s'utiliser galement au niveau du

paquet IP, dans le champ appel ToS (Type of Service) ou CoS (Class of Service)
prsent dans l'entte d'un paquet IP et donc dans les quipements agissant au niveau 3.
Le champ ToS de 8 bits comprend notamment 3 bits dfinissant 8 niveaux de priorit
du paquet. Tel quel, le champ ToS a t peu utilis et il est dsormais remplac, dans
le modle DiffServ (Differentiated Services), par le champ CoS, toujours de 8 bits,
mais compos d'un champ DSCP (Differentiated Service Code Point) sur 6 bits et d'un
champ CU de 2 bits encore inutilis. Les oprations complexes (classification des
paquets, contrle et marquage de len-tte des paquets) interviennent lentre du

21

rseau sur les nuds de bordure (boundary nodes). Les nuds dans le cur du rseau
(interior nodes) se contentent de traiter les paquets en fonction de la classe code dans
len-tte du paquet IP (valeurs du champ DS), selon un comportement appropri, le
PHB (Per Hop Behavior).
Version
4 bits

Longueur
4 bits

TOS : Type
Of Service
8 bits

DSCP
6 bits
Figure 2.7
-

Longueur totale
16 bits

Suite de len-tte
IP

CU
2 bits

Localisation du champ DS dans lEntte du paquet IP [4]

Le champ DSCP (Differentiated Service CodePoint) permet de slectionner le


PHB appliquer au paquet, sur les routeurs du rseau DiffServ. Cod sur 6 bits,
il permet de dfinir jusqu 64 Codepoints.

Le champ CU (Currently Unused) est rserv un usage futur.

La priorisation se dfinie et s'utilise en fonction des valeurs prises par ce champ


DSCP. Cette priorisation fonctionne donc dans un environnement non "802.1q". Elle
est gre au niveau 3 du modle OSI, il est possible quelle soit moins rapide qu'une
priorisation gre au niveau 2.

22

Chapitre 3
tude approfondie du rseau du ministre et
apprciation d e sa disponibilit

Contenu
3.1

Recensement du matriel

3.2

Efficacit des serveurs

3.3

Prsentation de larchitecture rseau

3.4

Simulation du rseau du MINESUP

3 .1

Recensement du matriel
Le ministre possde un parc informatique qui a environ quatre vingt machines.

La quasi-totalit de ces machines est connecte internet. On note aussi la prsence de


quelques imprimantes et scanner qui sont aussi relis au rseau du MINESUP. Le
ministre possde deux serveurs qui sont connects au public ; ces serveurs sont relis
un onduleur qui leur permet de continuer fonctionner en cas de panne lectrique.

3.2

Efficacit des serveurs


Comme nous avons prcis plus haut, nous avons deux serveurs identiques au

ministre dont les caractristiques sont les suivantes :


-

Nom : HP proliant DL 380 G6

RAM : 2 GB

23

Disque Dur : 146 GB 4 = 584 GB

Carte Rseau

Etant donn que ces serveurs sont destins servir le public (les utilisateurs distants),
chacun deux possde une adresse IP public. Sur ces deux serveurs, y sont abrits trois
services rseaux rpartis comme suit : le DNS3 (Domain Name System) et le service
mail (Zimbra) sur lun des serveurs, et sur le second serveur nous avons le service
Web qui est linterface du ministre que nous pouvons avoir partout dans le monde en
tapant lURL (www.minesup.gov.cm).

3.3

Prsentation de larchitecture rseau


Le MINESUP comme plusieurs autres services publics et privs possde un

rseau local Ethernet essentiellement cbl. Ce rseau a une topologie physique en


toile4 et la distribution des adresses se fait partir dun DHCP qui est configur au
niveau du routeur. La plage dadresses distribue par ce routeur est la plage dadresses
prives de classe B (172.16.0.0/16) ; et pour les deux serveurs (DNS+MAIL et WEB)
nous avons deux adresses IPV4 public. Ensuite, le routeur dentr dessert le rseau
dune connexion internet de 2Mb/s fournit par le fournisseur daccs CAMTEL cest
ce dbit qui est utilis pour grer tous les services du ministre. Ce dbit est
naturellement insignifiant pour les utilisateurs internes du ministre et les services
rseau qui sont fournis au public.

Le DNS permet de traduire une adresse IP en nom symbolique et vice versa dans le cas du MINESUP ce nom
est : minesup.gov.cm
4
Tous les terminaux rseau sont interconnects par un nud central (qui est gnralement un Switch dans les
rseaux Ethernet)

24

Cyber caf

Figure 3.1

architecture simplifie du rseau du MINESUP

Dans cette architecture, nous avons:


-

Un routeur dentre qui dessert tous le rseau dune connexion internet


de 2Mb/s de dbit.

Deux serveurs publics connects au rseau par une liaison FastEthernet

Et un rseau local FastEthernet de plusieurs machines adresses par


DHCP.

3.4

Simulation du rseau du MINESUP


La simulation du rseau du MINESUP peut se faire sous plusieurs aspects ;

nous pouvons avoir une simulation qui se focalise sur le respect des normes de
cblages et dadressage du rseau ici on vrifie tout simplement si le rseau peut bien
fonctionner. Ensuite on peut aussi avoir une simulation qui se base sur un test en

25

profondeur des protocoles de communications, des congestions possibles dans le


rseau ; cest cette dernire qui est plus intressante pour nous.

3.4.1

Choix du simulateur

Les simulateurs de rseaux sont tous diffrents: certains possdent des


avantages que d'autres ; d'o la ncessit de pouvoir les comparer en utilisant des
critres d'valuation prcis. Mais avant cela, il est ncessaire de mentionner quel est
l'intrt de ces simulateurs: quoi peuvent-ils servir ?
Les simulateurs permettent, comme leur nom lindique, de raliser des
simulations dans un environnement simul qui nest pas rel. Ils peuvent aussi bien
simuler un rseau de type LAN ou bien WLAN (suivant les simulateurs). Certains
simulateurs sont plus complets que dautres dans les rsultats dune simulation ; mais
tous permettent dtudier le comportement dun rseau ayant une topologie et des
caractristiques prcis. Les simulateurs permettent ainsi danticiper sur la topologie
dun rseau. Lorsque les rsultats dune simulation ne sont pas satisfaisants, il est
facile de modifier la topologie pour corriger les problmes avancs par la simulation
prcdente. Par exemple, si une simulation indique de par ses rsultats que
lemplacement dun AP5 (Acces Point) nest pas correct (la zone de couverture nest
pas optimale), on peut facilement modifier son emplacement via le simulateur pour
prvoir le comportement du rseau si lAP est dplac rellement. La simulation est
aussi intressante pour crer la topologie dun rseau avant de la mettre en place
rellement. Et cela est possible car les simulateurs intgrent un grands nombre doutils
permettant de raliser des simulations assez ralistes. Au final, les simulateurs sont
dune grande aide dans la recherche scientifique et le dveloppement dapplications.

a)

Network Simulator 2 (NS2) [5]

NS2 est un simulateur vnements discrets destin la recherche. Il est


dvelopp en collaboration avec plusieurs entreprises et centre de recherches pour en
5

"Point Daccs" il permet dinterconnecter (comme un hub) les quipements sans fil

26

citer quelques uns : LBNL9, Xerox PARC10, UCB11, et USC/ ISI12 dans le cadre du
projet VINT13 (qui tudie l'interaction entre diffrents protocoles), depuis 1995. Son
avantage rside aussi dans le fait quil est multi-plateforme (UNIX et Windows, avec
lmulateur Cygwin14) et que son utilisation soit gratuite. Il gre aussi trs bien la
couche physique (couche 1) du modle OSI avec diffrents systmes de transmission,
filaires ou non. NS2 est entirement dvelopp en C++ et son utilisation requiert une
bonne matrise de TCL (Tool Command Language) qui est utilis comme un
interprteur applicatif au langage C du simulateur

b)

Objective Modular Network (OMNet++)

OMNET ++ est un environnement de simulation open source. Cette application


possde une interface graphique solide et un noyau de simulation intgr. Il a
principalement pour but de simuler les communications rseaux, mais est aussi utilis
dans la simulation de systmes, des technologies de l'information. C'est ainsi que cette
plateforme est devenue connue tant au sein de la communaut scientifique que dans le
monde industriel, et c'est grce cette architecture modulaire qu'il est ais d'y
implmenter de nouveaux protocoles. Les composants d'OMNET++ sont cods en
C++, puis assembls sous un modle d'architecture plus large, cod lui sous un langage
fdrateur de haut niveau: le NED. Les modles peuvent tre rutiliss librement et
gratuitement. Omnet++ gre par defaut le TCP / IP15, le SCSI16 et le FDDI17.
Il existe plusieurs autres simulateurs dont nous navons pas dcrit plus haut ;
mais nous allons tablir un tableau qui permet de faire une comparaison de quelques
simulateurs en fonction de certains critres dvaluation

27

Critre dvaluations

NS2

OMNet++

Glomosim

JSim

Modificabilit et extensibilit

++

++

Modules reprsentant les couches OSI

Modules reprsentant les protocoles

++

Interface Utilisateur

++

Entre/Sortie

++

Reprsentation de la topologie

++

++

Observabilit

++

Acceptabilit dans le milieu de la

++

++

Gnration de trafic de donnes

++

++

++

++

Modle de mobilit

++

++

Passage lchelle

++

Documentation

++

++

Facilit dutilisation globale

--

++

Portabilit

++

Stabilit

Performance du moteur de simulation

++

Simulation temps rel

++

Evolutivit

++

++

de routage sans fil

recherche scientifique

Lgende :
Rsultats fiables
Fiabilit non vrifie
Donne inconnue

Tableau 3.1 : Comparaison des simulateurs [5].

28

Aprs avoir recueilli les informations ncessaires, nous avons pu dresser un


tableau comparatif. Il en rsulte que NS2 reste sans doute le simulateur le plus
document et le plus polyvalent. Seul dfaut: sa maniabilit et sa prise en main
difficile. En le comparant OMNet++, on remarque que les deux simulateurs se valent
la diffrence que la prise en main dOMNet++ est largement plus facile (prsence
d'une interface graphique). On regrette peut-tre le manque de dtail lors du
paramtrage d'une simulation. Il demeure cependant un trs bon simulateur. Quant
Glomosim, on ne peut s'empcher de noter qu'il est trs performant pour la simulation
des rseaux sans fil (il intgre un large panel de protocoles de routage). Comme NS2,
il possde un outil de visualisation de simulation (Glomosim Visualization Tool). La
documentation peut cependant sembler assez lgre. Jsim est celui le plus plaindre
quand la documentation: trs difficile d'en trouver. C'est ce qui explique le manque
de certitude lors de l'valuation de ce simulateur. On sait toutefois qu'il est trs
performant (ce qui est du au moteur cod en Java) aprs avoir trouv des rapports qui
comparaient le dit simulateur NS2 ou OMNet++. L'ensemble de ces simulateurs sont
multi-plateforme (Windows et Linux principalement) et stables pour la plupart: les
bugs dcouverts sont rapidement corrigs dans le cas de NS2 et Omnet++. Nous
regrettons un peu le manque de temps lors de l'tude de ces simulateurs qui ne nous a
pas permit d'tablir un tableau comparatif significatif et bas sur notre propre
exprience des simulateurs.

3.4.2

Les points nvralgiques de larchitecture

En se basant sur la topologie du rseau du ministre que nous avons prsente


dans la figure 3.1 Ci haut, nous pouvons constater que le rseau peut se rsumer en
cinq nuds essentiels :
-

Un nud reprsentant les utilisateurs externes au rseau

Un nud reprsentant le routeur dentre

Un nud qui reprsente le Switch qui est entre les deux rseaux (publicprive)

Un nud qui reprsente le serveur sollicit

29

Un nud qui reprsente le rseau prive interne du MINESUP

Ce sont ces nuds que nous allons utiliser pour simplifier notre simulation. Nous
allons insister sur la simulation de la disponibilit du rseau c'est--dire concrtement
valuer la quantit des requtes qui ne produit aucune congestion dans notre rseau.

a)

Evaluation thorique de la disponibilit

Le ministre reoit une connexion internet de 2Mb/s ; la liaison tant duplex6 on


peut donc par extrapolation dire que nous avons 1Mb/s pour la liaison montante et
1Mb/s pour la liaison descendante. Vu ce dbit, la question que nous devons nous
poser est celle de savoir : combien dutilisateurs simultans pourrions-nous servir
avec un tel dbit ? . Nous avons suppos que les utilisateurs sont majoritairement des
tudiants. Ils sont presque tous utilisateurs des cybers caf et peuvent en moyenne
avoir 10Kb/s leur poste de travail. En faisant le ratio, nous avons :

&'()*+)(+ =

-.../0/2
-.

= 100

Nous pouvons donc avoir 100 utilisateurs de 10Kb/s simultans sur notre
serveur. Lautre problme est celui de savoir une fois lutilisateur connect combien
de temps fait-il pour prendre un fichier de 3M ? . Si un utilisateur a un dbit de
10Kb/s, pour prendre un fichier de 3Mb sur le serveur il fera :
4)56*+)( =

3000
= 300 +)78&9) 5 5<&*4)+
10

En dfinitive, dune faon thorique, on peut avoir 100 utilisateurs simultans et


chaque utilisateur fera cinq minutes sur le serveur. Ces rsultats ne sont que des
rsultats thoriques et ils sont pris dans le meilleur des cas. Puisque la communication
utilise les protocoles TCP et UDP pour le transport, il y a des dtails protocolaires qui
ne sont pas pris en compte dans lvaluation thorique pour cela nous allons donc
effectuer la simulation avec NS2 pour valuer le trafic maximal que peut supporter
notre rseau.
6

Communication seffectuant simultanment dans les deux sens (montant et descendant), mais sur un seul canal

30

b)

Evaluation exprimentale
exprimen

Nous avons cre six nuds pour notre simulation et la simulation consiste
savoir quel volume de donnes il se produit une congestion.

Figure 3.2
-

Prsentation de la simulation du rseau.


rseau

Les nuds "0" et "5" reprsentent


reprsente les utilisateurs externes au rseau. Ils sont
les potentiels clients des serveurs du ministre, notons quil
qu tait possible
dutiliser un seul nud pour la simulation de ces utilisateurs mais nous avons
voulu diversifier le trafic utilisateur.

Le nud "1" reprsente le routeur dentre cest lui qui est connect au FAI

Le nud "2" reprsente


sente le Switch qui interconnecte les serveurs au rseau

Le nud "3" reprsente le rseau interne du ministre

Le nud "4" reprsente les serveurs qui hbergent les services


se
WEB et
service MAIL

31

Nous avons dimensionn les liaisons entre les diffrents nuds de la manire suivante:
-

nud 0

nud 1 20Mb/s, dbit de la liaison entre le routeur dentr et le

rseau extrieur
-

nud 5

nud 1 20Mb/s, dbit de la liaison entre le routeur dentre et

le rseau extrieur
-

nud 1

nud 2 1Mb/s, dbit de la connexion internet du ministre

nud 2

nud 3 100Mb/s, dbit dune liaison Fastethernet

nud 2

nud 4 100Mb/s dbit dune liaison Fastethernet

Voici la portion du code qui nous a permis de faire le dimensionnement des diffrentes
liaisons que nous venons de prsenter.
# Cration des liens, file d'attente DropTail
$ns duplex-link $n0 $n1 20Mb

10ms DropTail

$ns duplex-link $n1 $n2 1Mb

10ms DropTail

$ns duplex-link $n3 $n2 100Mb

10ms DropTail

$ns duplex-link $n4 $n2 100Mb

10ms DropTail

$ns duplex-link $n5 $n1 20Mb

10ms DropTail

Aprs plusieurs simulation, nous avons constat que si nous envoyons un trafic
de 4800 bits tous les 5 ms, le rseau ne prsente aucune dfaillance. Pour un trafic de
5200bits tous les 5 ms, nous avons un dbut de congestion et une perte dun paquet
toute les 63ms comme le prsente la figure ci contre.

32

Paquets envoys

Paquet perdu

Figure 3.3

Simulation dun trafic de 5200 bits toute les 5millisecondes

Dans le cas dun trafic de 6400bits tous les 5 ms nous avons une trs forte congestion
au niveau du routeur dentr ce qui occasionne une perte de paquets chaque 12ms.

Figure 3.4

Simulation dun trafic de 6400 bits toute les 5millisecondes

33

3.5

Gestion de la bande passante


La gestion de la bande passante est un lment capital dans la disponibilit des

services fournis par le ministre. A cause du trs fort potentiel de personnes qui
peuvent se connecter simultanment, et malgr la faible bande passante, il faut
satisfaire tout le monde ; une fois que nous disposons dune bande il faut maintenant
optimiser les services et les protocoles rseau afin davoir une meilleur utilisation. La
technique "doptimisation de la bande" qui est applique est la compression des
fichiers avant la mise la disposition du public.

3.6

Gestion du routage des paquets


Le routage est un lment important dans un rseau informatique. Il est vrai

quen observant larchitecture, on constate quil ne revient pas au Ministre de grer le


routage puisque les serveurs se trouvent dans un sous rseau particulier. De plus, le
routeur public est entirement configur par le FAI (fournisseur daccs internet) ;
mais grce au backbone7 du FAI (CAMTEL) qui est dot dun assez bon dbit, nous
avons lassurance que lacheminement des paquets vers nos serveurs se fait en un
temps court. En effet, le FAI a boucl le territoire national par une fibre optique la
technique IP/MPLS qui a t implment au niveau de ce backbone national permet
dacheminer efficacement les paquets grce sa mthode dassignation de label. Il est
noter que le MPLS est lun des protocoles les plus implment de nos jour au niveau
des backbones des oprateurs car il enrichi la transmission IP dun routage
"dterministe".8

7
8

"Backbone" Cest lensemble des artres principales du rseau qui interconnecte les autres branches du rseau
"Routage dterministe" Cest un routage o lon peut prdire le chemin que vas emprunter le paquet

34

3.7

Prsentation des faiblesses et des limites de ce rseau


Nous avons prcis plus haut que le ministre tait dot de deux serveurs et que

chaque serveur fournissait des services particuliers. Il est vrai que ces serveurs ayant
des capacits acceptables peuvent traiter un nombre considrable de requtes. Mais le
fait que nous ayons un unique serveur pour un service qui est assez sollicit posera
sans doute un problme de disponibilit de celui-ci. En effet, si nous supposons que
nous avons publi un moment donn les rsultats de BTS sur notre serveur WEB la
quantit de requtes traiter par ce dernier vas trs vite tre intenable, et les requtes
en question doivent tous simplement tre rejetes. Pire encore si le serveur en question
venait steindre ; dans ce cas on naura plus du tout le service. Le rsultat sera
similaire dans le cas dun afflux de requtes au niveau du serveur MAIL.
Les analyses que nous avons faites sur le rseau et la connexion internet plus
haut ainsi que les simulations qui ont corrobor ces analyses, nous montrent les limites
du rseau et son incapacit satisfaire convenablement ne serait-ce que cent
utilisateurs. Au vu de ces limites, nous avons estim quil faille envisager une solution
de haute disponibilit au niveau de la connectivit, et aussi au niveau des services qui
sont hbergs sur les serveurs.

35

Chapitre 4
Mise sur pied de la haute disponibilit du rseau et
clustering des serveurs

4.1

Contenu
Gestion de la haute disponibilit du rseau

4.2

Gestion de la haute disponibilit des services

4.1

Mise en uvre de la haute disponibilit du rseau


Pour assurer la haute disponibilit du rseau informatique du ministre, il faut

mettre en uvre un systme de connexion internet de secours. Et par la suite appliquer


une qualit de service efficace.

4.1.1

Mise en uvre dune connexion de secours

Au ministre, nous avons un seul point de connexion internet fournit par un


unique FAI (CAMTEL). Le fait que cette connexion soit unique pose dj un
problme de conception quelque soit le dbit de la connexion. Si un moment donn
le routeur dentrer tombe en panne, il est claire que tous notre rseau devient
indisponible. Il est donc question pour nous de mettre en place une connexion de
secours qui naura certainement pas le mme dbit que la connexion principale, mais
elle pourra assurer la disponibilit des services pendant la dfaillance de la connexion
principale. Pour y parvenir, nous avons gr la rpartition des charges au niveau des

36

routeurs mis en jeu pour assurer la disponibilit de la connexion. Pour mettre en place
cette rpartition de charge (load-balancing), nous avons implment un protocole
appropri au niveau des routeurs. Nous avons donc opt pour le protocole GLBP
(Gateway Load-Balancing Protocol). Nous allons dabord voir le fonctionnement du
protocole GLBP, puis nous allons le configurer pour notre topologie rseau. Enfin,
nous allons ajouter la configuration globale de GLBP le tracking dinterfaces.
a)

Fonctionnement de GLBP

Gateway Load Balancing Protocol (GLBP) est un protocole propritaire Cisco


qui permet de faire de la redondance ainsi que de la rpartition de charge sur plusieurs
routeurs en utilisant une adresse IP virtuelle, qui sera associe plusieurs adresses
MAC virtuelles. Ainsi, tous les routeurs du groupe GLBP dfini participent activement
alors que dans VRRP ou HSRP, il ny a quun qui est en mode actif tandis que les
autres patientent. Plus concrtement, lintrieur du groupe GLBP, le routeur ayant la
plus haute priorit ou la plus haute adresse IP du groupe prendra le statut de AVG
(Active Virtual Gateway). Ce routeur va intercepter toutes les requtes ARP effectues
par les clients ayant pour but dapprendre ladresse MAC de la passerelle par dfaut, et
grce lalgorithme dquilibrage de charge pralablement configur, il va renvoyer
ladresse MAC virtuelle dun des routeurs du groupe GLBP. Cest dailleurs le
Routeur AVG qui va assigner les adresses MAC virtuelles aux routeurs du groupe,
Ainsi ils ont le statut AVF (Active Virtual Forwarder). Un maximum de 4 adresses
MAC virtuelles est dfini par groupe. Cela veut dire que chaque groupe peut contenir
4 routeurs actifs en mme temps, les autres routeurs seront en attente et prendront le
relai en cas de panne dun AVF.
Pour notre topologie nous avons augment le nombre de routeurs dentre au
rseau afin davoir la connexion internet fournie par trois oprateurs diffrents. Nous
faisons le choix de divers oprateurs pour remdier aux pannes qui pourront tre
propre un FAI.

37

GLBP 10
IP virtuelle :
172.16.1.1

Figure 4.1

Rseau haute disponibilit internet envisag

Nous avons trois routeurs : CAMTEL, Orange et MTN, qui seront les
passerelles vers Internet. Nos trois routeurs appartiennent un groupe GLBP, et le
numro de groupe est 10. LIP virtuelle associe au groupe est 172.16.1.1 (on
configure donc nos utilisateurs avec cette IP comme adresse de passerelle par dfaut).
CAMTEL est dsign comme routeur AVG (il nous faut donc lattribuer une priorit
GLBP plus haute que les autres), cest donc lui qui se charge dintercepter toutes les
requtes ARP des utilisateurs et les associer un routeur grce aux adresses MAC
virtuelles des routeurs. Par exemple, il va associer le serveur Web lui-mme, le
serveur Mail au routeur Orange etc. Les autres routeurs sont donc des AVF. Si un des
routeurs tombe en panne, un des autres routeurs du groupe prendra le relai. Par

38

exemple, si Orange tombe en panne, le serveur Mail qui tait associ ce dernier,
sera automatiquement associ un des autres routeurs. Si le routeur CAMTEL
(lAVG dans notre cas) tombe, il y aura rlection de lAVG, et Orange ou MTN
deviendra AVG (en fonction des priorits que nous donnons). De plus, si nous
activons la premption, si CAMTEL remonte, il redevient automatiquement AVG.
b) Configuration de GLBP sur les routeurs dentre de notre rseau
Configuration du routeur CAMTEL
Le routeur CAMTEL a une interface WAN connect Internet et linterface f0
connect au rseau de lentreprise. Pour cette interface, nous avons choisi comme IP
172.16.1.2 /16:
Camtel(config)# interface f0
Camtel(config-if)# ip address 172.16.1.2 255.255.0.0
Camtel(config-if)# no shutdown
Nous configurons ensuite GLBP sur linterface f0 :
On ajoute linterface f0 au groupe GLBP 10 et on lui donne une priorit de 120 :
Camtel(config-if)# glbp 10 priority 120
On spcifie lIP virtuelle du groupe GLBP 10 :
Camtel(config-if)# glbp 10 ip 172.16.1.1
On active la preemption:
Camtel(config-if)# glbp 10 preempt
Enfin on donne un nom au groupe GLBP
Camtel(config-if)# glbp 10 name glbp-lan

39

Configuration du routeur Orange


Orange(config)# interface f0
Orange (config-if)# ip address 172.16.1.3 255.255.0.0
Orange (config-if)# no shutdown
Orange (config-if)# glbp 10 priority 110
Orange (config-if)# glbp 10 ip 172.16.1.1
Orange (config-if)# glbp 10 preempt
Orange (config-if)# glbp 10 enable
Orange (config-if)# exit
Remarque: il ny a que ladresse IP ainsi que la priorit qui change compar
CAMTEL
Pour configurer le routeur MTN nous avons tout simplement chang ladresse IP et la
priorit.
Configuration du load-Balancing
GLBP propose trois mthodes de Load-Balancing:
Round Robin (le mode par dfaut) : Pour chaque requte ARP, lAVG renvoie
ladresse Mac virtuelle immdiatement disponible. Prenons lexemple ou nous
avons une seule machine. Si cette station fait une requte ARP, elle obtiendra
ladresse MAC de CAMTEL. Si elle vide son cache ARP, et quelle refait une
requte, elle obtiendra ladresse MAC dOrange etc.
Weighted : On dfinit un poids sur les interfaces du groupe GLBP afin de
dterminer la proportion dutilisateurs se connectant sur les routeurs. Si par
exemple le routeur Orange possde des interfaces 100Mb/s et que le routeur

40

CAMTEL possde des interfaces 1GB/s, vous devez mettre un poids plus
important sur les interfaces du routeur CAMTEL pour quil soit privilgi.
Host-dependent : Chaque client gnrant une requte ARP recevra toujours la
mme adresse Mac virtuelle.

On dfinit la mthode que lon veut utiliser avec la commande :


glbp numgroup load-balancing [round-robin | weighted | host-dependent]
Pour notre cas, nous navons pas prcis ; de ce fait le routeur doit choisir la technique
de rpartition par dfaut qui est la round robin.
c)

Configuration du tracking dinterfaces sur nos routeurs

GLBP supporte le tracking dinterfaces, cest--dire quil est capable de


surveiller une autre interface du routeur o nest pas configur GLBP afin de prendre
des dcisions. Il faut donc surveiller ltat du lien WAN des routeurs, pour voir si le
routeur est encore connect internet. Si cette interface tombe, GLBP
automatiquement dclarera le routeur injoignable :
Pour chaque routeur nous avons appliqu les configurations suivantes :
On surveille ltat de la liaison sur linterface WAN
(config)#track 1 interface s0/0 line-protocol
(config-track)#exit
(config)#track 2 interface s0/0 ip routing
(config-track)#exit
(config)#interface fastethernet 0/0
(config-if)#glbp 10 weighting 100 lower 50
On indique que le poids de linterface est de 100, et que le poids ne doit pas tre en
dessous de 50.
(config-if)#glbp 10 weighting track 1 decrement 60

41

(config-if)#glbp 10 weighting track 2 decrement 60


Nous avons fait en sorte que si le track 1(linterface connecte internet) tombe alors
on dcrmente le poids de linterface de 60.Comme on a dit que ce dernier ne doit pas
tre infrieur 50, GLBP liminera le routeur des dcisions de load-balancing. Une
fois la configuration du tracking faite sur tous les routeurs, nous avons du loadbalancing ainsi que de la haute-disponibilit oprationnels.
Ces configurations nous ont permis davoir la haute disponibilit internet. Cette
disponibilit dinternet est capitale pour nos serveurs.

4.1.4

Rduction de la congestion

Pour rduire les congestions au niveau de nos routeurs, nous avons appliqu les
politiques de qualit de service (QoS). La congestion dans notre rseau se situe
principalement au niveau du routeur dentre. Puisque nous avons deux services
principaux qui sont sollicits, nous devons donc trouver la meilleure politique qui doit
amliorer le rendement de ces services. La procdure de mise en place de la QoS dans
les environnements CISCO est la suivante :
Dfinition d'une ou plusieurs classes de flux, en fonction de paramtres divers,
comme par exemple le protocole concern par le flux.
Dfinition d'une politique de QoS dans laquelle chaque classe de flux se voit
attribuer un niveau de priorit.
Application de cette politique sur une interface, en entre ou en sortie.
Dans notre cas, nous avons donn une priorit haute (IP prcdence 5) aux
protocoles HTTP, SMTP, POP3 lorsque ceux-ci proviennent de lextrieur du rseau
tout en donnant galement 50% de la bande passante ce flux. Pour les requtes
sortantes, nous donnons les mmes privilges mais lorsque les rponses proviennent
cette fois ci des serveurs. Nous avons choisi de prioriser les protocoles HTTP, SMTP,
POP3 parce que ce sont les protocoles utiliss dans les serveurs WEB et Mail. Et nous
lappliquons aussi en sortie pour que les rponses des serveurs soient prioritaires par

42

rapport aux requtes des ordinateurs du rseau local. La capture ci contre prsente la
politique de QoS que nous avons appliqu sur une interface du routeur.

Camtel#show policy-map interface fastEthernet 0/0


FastEthernet0/0
Service-policy output: Politiquerouteur
Class-map: Routeur (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol http url *minesup.gov.cm*
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol smtp
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol pop3
0 packets, 0 bytes
5 minute rate 0 bps
QoS Set
precedence 5
Packets marked 0
Queueing
Output Queue: Conversation 265
Bandwidth 50 (%)
Bandwidth 50000 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

Figure 4.2

Politique de QoS applique aux routeurs dentre

Cette politique de QoS a t applique sur tous les routeurs dentre, afin de garantir la
priorit des flux entrant ou sortant des serveurs.

43

4.2

Mise en uvre de la haute disponibilit des services (clustering)


Le clustering est le fait de regrouper plusieurs serveurs physiques et les

configurer afin quils rpondent un service comme tant un seul. Les services
Rseaux (MAIL et WEB) dont le ministre a mis la disposition du public sont
soumis de trs fort trafic cause des multiples internautes qui sy connectent. Face
cette situation, il en ressort que lunicit de serveurs induit des rponses inefficaces
aux diffrentes sollicitations. Nous avons opt pour la mise en place des clusters par
service Rseau. La solution choisie t la LVS (Linux Virtual Serveur). Un Cluster
est un groupe de machines rendant le mme service de manire transparente pour les
Clients.

4.2.1

Prsentation de LVS

LVS permet de mettre en uvre un cluster dun nombre important de machines


avec un rpartiteur de charge fonctionnant sous Linux. Celui-ci permet dassurer la
rpartition de charge pour la plupart des services existants tout en permettant une haute
disponibilit (via des logiciels comme heartbeat). Il existe plusieurs mthodes de
rpartition de charge, la diffrence fondamentale de ces mthodes se situe au niveau de
larchitecture du cluster.
Comme prsent dans les gnralits, il existe trois mthodes pour mettre en
uvre un cluster avec LVS. Le tableau ci aprs rsume chaque mthode

44

LVS NAT
Fonctionnement

LVS-DR

LVS tunnelling

Le cluster est reli au Le rpartiteur des Le rpartiteur des


rpartiteur et tout le charges ne permet charges dirige les
trafic

provenant

du que de diriger les requtes des clients

cluster ou destination requtes des clients vers


du cluster passe par le vers

le

le

serveur

serveur disponible via un

disponible mais la tunnel. Ensuite le

rpartiteur

rponse

est

faite serveur

rpond

directement

au directement

client

ce client

par

au

serveur
Avantages

-Il est conome en Simplifie le travail Simplifie le travail


adresse IP public.

du rpartiteur

du

rpartiteur.

Adapter pour les


clusters

qui

sont

dans diffrents sites


Inconvnients

Tous
passer

le

trafic
par

doit Utilise

autant Gaspillage

le dadresses

IP dadresse,

rpartiteur. qui peut publics quil y a de


donc tre une source serveurs
de congestion.

dans

le

cluster

Tableau 4.1 : Comparaison des mthodes de cluster avec LVS

4.2.2

Choix de la mthode de clustering

Aprs le tableau 4.1 ci dessus, nous il ressort que Cest la mthode LVS-NAT
qui est approprie pour rsoudre notre problme dindisponibilit. En effet, Cest la
mthode la plus simple mettre en uvre, on na pas besoin de reconfigurer les
serveurs rels, il faut juste leur indiquer que lquilibreur de charge est la passerelle

45

par dfaut ; seul le rpartiteur a besoin dtre configur. Les serveurs sont lintrieur
dun rseau priv, et la passerelle qui leur permet daccder aux rseaux externes est
un rpartiteur dfini. Donc tous les paquets en provenance ou destination dun
serveur relle passe par le rpartiteur. LVS NAT a pour avantage lutilisation
dadresses prives pour les serveurs rels, il est donc conome en adresse IP publiques
et plus simple administrer. Pour viter le goulet dtranglement 9qui pourra se poser
au niveau du rpartiteur, nous allons dupliquer ce rpartiteur

4.2.3
a)

Mise en uvre des quilibreurs (Load Balancer)


LVS NAT

Lquilibrage de type NAT via LVS sur le quel nous avons est bas sur
ipvsadm qui est loutil dadministration de LVS mais aussi de Ldirectord qui va
soccuper de la configuration et de la dtection des services down sur les quilibreurs :
Tout dabord on installe Ldirectord :
apt-get install ldirectord
Ensuite on cre une interface virtuelle qui sera utilise par le client pour se connecter
au service Web
ifconfig eth0 : virt 176.16.1.254
Configuration de Ldirectord :
Les fichiers de configuration portent lextension .cf et se trouve dans /etc/ha.d/.
Dans ce fichier (www.cf) il faut renseigner plusieurs lments :
Virtual = 176.16.1.254 :80
Protocol = tcp
Sheduler=rr
Real= 192.168.1.1 :90 masq 1
9

" goulet dtranglement "Cest un nud qui limite les performances globales du rseau

46

Real = 192.168.1.2 : 80 masq 1


Request = index.html
Receive = 200
-

Virtual renseigne sur ladresse IP virtuelle qui reprsentera le serveur chez


les clients.

Protocol permet de dfinir le type de protocole utilis, ici tcp car http est
bas sur tcp.

Scheduler correspond lalgorithme utilis pour lquilibrage de la charge,


et rr signifie Round Robin.

Real liste les serveurs qui constituent le cluster avec ladresse IP de chacun
deux, son type de forward et le poids. Le type masq (pour masquerade)
correspond au LVS de type NAT et le poids permet de definir une priorit de
laiguillage.

Request dfini le nom de la ressource qui sera accede pour vrifier si les
serveurs web sont toujours disponibles.

Receive contient la valeur que devra contenir la ressource pour tre


considre comme disponible.

Au niveau des serveurs, il faudra changer la passerelle par dfaut parce que dsormais
leur passerelle sera ladresse IP relle de lquilibreur.
/sbin/route add default gw 192.168.1.254
Il faut ensuite lancer le service de ldirectord
/etc/init.d/ldirectord start
Note : Nous avons besoin dau moins deux quilibreurs, dont un pour chaque service.
Les configurations doivent donc tre rpliques quelques exceptions prs sur lautre
quilibreur.

47

b)

Heartbeat

Heartbeat permet chaque quilibreur dobtenir les informations de son homologue.


Grce ce mcanisme, il est charg dassurer la haute disponibilit ; celui-ci doit tre
install sur chaque quilibreur. Tout dabord on installe Heartbeat :
Sudo apt-get install heartbeat
Pour la configuration, il y a trois fichiers crer pour que heartbeat fonctionne bien :
/etc/ha.d/ha.cf
# Indication du fichier de log
Logfile
/var/log/heartbeat.log
# Les logs heartbeat seront grs par syslog, dans la
#catgorie daemon
Logfacility
daemon
# On liste tous les membres de notre cluster heartbeat
Node
serveur1
node
serveur2
# On dfini la priodicit de controle des noeuds entre eux
(en seconde)
keepalive
1
# on considre que la machine met du temps rpondre
Warntime
6
# Au bout de combien de seconde un noeud sera considr comme
"mort"
deadtime
10
# Quelle carte rsau utiliser pour les broadcasts Heartbeat
bcast
eth0
# Rebascule-t-on automatiquement sur le primaire si celui-ci
#redevient vivant ? oui
auto_failback
yes

/etc/ha.d/haresource
Serveur1 176.16.1.254
/etc/ha.d/authkeys :

Auth 1
1 sha1 MaClefSecrete

48

Ensuite il ne nous reste plus qu lancer heartbeat sur les machines :


/etc/init.d/heartbeat start.

Figure 4.2

Cluster WEB haute disponibilit

La figure 4.2 ci-dessus nous prsente larchitecture de notre cluster WEB. Le fait que
nous ayons deux quilibreurs (load Balancer), permet de rduire considrablement les
goulets dtranglement. Et puisque nous avons trois serveurs rels, le taux
dindisponibilit sera galement rduit.
Conclusion
Grce cette technique dapproche, c'est--dire grer la haute disponibilit au niveau
du rseau et galement mettre en uvre la haute disponibilit au niveau des services
rseau, nous parvenons atteindre une disponibilit qui pourra satisfaire les
utilisateurs.

49

Chapitre 5
Rsultats et commentaires
commentaire s
Contenu
5.1

Nouvelle architecture

5.2

Redondance des routeurs

5.3

Redondance des serveurs

5.1

Nouvelle architecture
Aprs notre dmarche ci haut, nous constatons donc que latteinte de lobjectif

de haute disponibilit donc nous nous sommes fix entraine une modification de
larchitecture du rseau.

Figure 5.1 Architecture du rseau haute disponibilit

50

Cette architecture est divise en trois grand compartiments


compartiment et chaque compartiment a
subit une configuration particulire conformment ses spcificits de disponibilit.

5.2

Redondance des routeurs


La redondance des routeurs nous a permis dviter le goulet dtranglement qui

se posait lorsque lonn avait un seul routeur. Cette redondance assure galement la
permanence de la connexion internet.
internet

Figure 5.2

Prsentation de la configuration de lAVG Camtel

51

La figure 5.2 ci-dessus prsente la configuration totale


total du protocole GLBP que nous
avons implment au niveau du routeur Camtel ; Ce routeur a t choisi comme AVG.
Nous pouvons galement constater sur cette figure que : ladresse
adresse IP virtuelle de notre
groupe de routeur est (172.16.1.1)
(172
et lalgorithme de rpartition des charges est la
round-robin. Cette adresse est renseigne comme passerelle par dfaut des ordinateurs
de notre rseau interne. Sur cette figure, nous pouvons voir que les routeurs possdent
chacun, deux adresses MAC
AC dont lune est virtuelle. Ces adresses MAC virtuelles (qui
sont en surbrillance sur la figure)
figure ne font la correspondance quavec ladresse IP
virtuelle du groupe.

Figure 5.3

Constatation de la rpartition de charge "load balancing"

Dans cette figure 5.3, nous affichons plusieurs fois la table ARP dun client interne et
nous constatons tous simplement que : les requtes sont bascules tour de rle sur

52

notre groupe routeurs. Cest ce qui justifie la modification chaque fois de ladresse
MAC virtuelle. Il est donc vident que cette technique permette dviter lengorgement
des nuds.

5.3

Redondance des serveurs


Tout comme dans la redondance des routeurs, il est question ici de regrouper

plusieurs serveurs qui doivent rpondre un service. Le client ne constate presque pas
quil a faire plusieurs serveurs. Nous avons deux serveurs ; nous prsentons les
interactions entre ces serveurs comme tant un seul avec le client

Figure 5.4

Paramtre rseau du serveur2

53

Figure 5.5

Paramtre rseau du serveur1

Dans la figure 5.4 ci dessus, nous pouvons constater que le serveur2 a pour adresse IP
192.168.1.2, a une adresse MAC 08:00:27:51:66:3B et na quune interface Ethernet
(eth0). Par contre, la figure 5.5, nous prsente le serveur1 qui a pour adresse IP
192.168.1.254, pour adresse MAC 08:00:27:93:DE:9F. Nous avons dans ce serveurs
deux interfaces Ethernet (eth0 et eth0 :2). La sous interface eth0 :2 possde ladresse
virtuelle 192.168.1.254 et a ladresse MAC de serveur1. Ceci signifie tout simplement
que cest le serveur1 qui est charg de rpondre aux requtes du client.

Figure 5.6

Table ARP du client

La correspondance entre ladresse IP virtuelle, et ladresse MAC du serveur1 dans la


table ARP du client ci-dessus, confirme que cest le serveur1 qui rpond lorsquon
sollicite le serveur WEB.

54

Figure 5.7

Rsultat du "ping" sur le cluster aprs de multiples interruptions de


serveur

Ce rsultat montre tout simplement la manire dont se comporte la machine cliente


lorsquil ya des problmes sur le serveur actif de notre cluster. En effet,
"1" reprsente les rponses du serveur2 qui a pris le relais aprs une interruption du
serveur1 (le serveur1 est serveur matre).
"2" reprsente les pertes provoques par la reprise des fonctions du serveur1 en tand
que matre.
"3" reprsente les rponses du serveur1 qui a repris fonction.
"4" reprsente les pertes de paquets qui sont occasionnes par une dfaillance du
serveur1
"5" Reprsente encore les rponses du serveur2 qui a pris le relais.

55

Grce au relais qui est pris chaque fois par les autres serveurs du cluster quand y a
problme, nous parvenons garantir la haute disponibilit du Service.
Pour corroborer ce rsultat, nous avons observ la table ARP du client lorsquil se
produit une interruption.

Figure 5.8

Rsultat de la table ARP du client aprs plusieurs interruptions dun


serveur du cluster.

On peut constater ici que ladresse physique associer ladresse IP virtuelle change
chaque fois. Ceci confirme simplement qu un moment donn, cest le serveur1 qui a
le contrle et un autre cest le serveur2. Donc notre redondance permet dassurer la
continuit du service.

56

Conclusion et perspectives
Dans ce mmoire, il a t question de mettre en uvre une infrastructure
haute disponibilit pour le rseau et les services Rseaux du Ministre. Nous sommes
partis du contexte selon lequel les tudiants ne parviennent pas accder au site web
du ministre au moment o il y a publication des rsultats de lexamen de BTS ou dun
concours. De ce constat, la problmatique ressortie a t la suivante comment assurer
la haute disponibilit des services rseaux du MINESUP ? Dans le second chapitre de
ce travail, nous avons prsent les gnralits sur la haute disponibilit. Toute fois,
pour atteindre cette haute disponibilit, nous avons fait une tude approfondie du
rseau du MINESUP. Ceci nous a permis de dceler des problmes lis larchitecture
du rseau et galement des problmes causs par lunicit des serveurs offrant des
services au public.
Nous pouvons donc rsoudre le problme dindisponibilit au niveau
architecturale du rseau par la redondance et la rpartition des charges des routeurs.
Au niveau des services, le problme dindisponibilit a t rsolu par le clustering des
serveurs combin un quilibreur pour grer la rpartition des charges. Aprs toutes
ces tapes, nous pouvons estimer ( notre humble avis) que le rseau public du
ministre peut garantir une disponibilit acceptable.
Malgr le fait que nous ayons obtenu des rsultats intressant dans notre
travail, beaucoup de choses peuvent encore tre engages pour se rapprocher de plus
en plus de lidal. En effet comme amliorations, larchitecture du rseau public du
ministre pourra tre dupliqu plusieurs endroits du territoire afin dviter les
indisponibilits qui pourront tre causes par des pannes lectriques. Il faut aussi noter
que pour des besoins de performances il faudra mettre en place des plans de reprise
dactivits bas sur un rseau de sauvegarde de type SAN (Storage Area Network) que
lon pourra dployer sur ltendue du territoire.

57

Bibliographie
Bibliogr aphie
Ouvrages :
[1] Achraf Cherti, Jargon informatique, version 1.2, 2005.
[2] Nicola, Ferre, livre blanc haute disponibilit sous linux, 2000
[3] Simon Horman, Linux virtual Server tutorial, VA Linux Systems, Japan, 2004
Thse et Mmoire :
[4] Badr Benmammar : la gestion dynamique de la qualit de service dans les rseaux
IP mobiles, Thse, Universit de Bordeaux I, Ecole doctorale de Mathmatiques et
dInformatiques 12 mai 2006
[5] Dupessey Xavier Glossi Etienne : tude des simulateurs de routage pour rseau
sans fil, Mmoire de fin formation, IUT de valence, 2008
Article du Web (webographie) :
[6] http://lille.labo-cisco.com/2013/09/29/glbp-pratique/ 25 Juillet 13h
[7] http://www.itpro.fr/a/trafic-du-serveur-web/ le 22 Mai 11h
[8] http://reseaucerta.org 25 Mai 17h
[9] http://fr.wikipedia.org/wiki/Haute disponibilit 5 Mai 10h
[10] http://doc.fedora-fr.org/wiki/Cluster_LVS_ou_Linux_Virtual_Server 19 Aout
20h
[11] http://www.maje.biz/downloads/cluster-lb2.doc 1Aout 10h
autre
[12] Organisation du ministre de lenseignement suprieur, Dcret n 2012/433 du 01
octobre 2012

58

Annexe
Extrait du dcret prsidentiel portant Organisation du ministre de lenseignement
suprieur

Code source de la simulation de Congestion du rseau sur NS2


# Cration du simulateur
set ns [new Simulator]
# Cration du fichier de traces NS-2
set nf [open out.nam w]
$ns namtrace-all $nf
# Procdure de fin de simulation, qui crit les donnes dans le fichier
# et lance NAM pour la visualisation
proc finish {} {
global ns nf
$ns flush-trace
close $nf
exec nam out.nam &
exit 0
}
# Cration des noeuds
set n0 [$ns node]
set n1 [$ns node]
set n2 [$ns node]
set n3 [$ns node]
set n4 [$ns node]
set n5 [$ns node]
# Cration des liens, tous en 1Mbps/10ms de TR/file d'attente DropTail
$ns duplex-link $n0 $n1 20Mb
10ms DropTail
$ns duplex-link $n1 $n2 1Mb
10ms DropTail
$ns duplex-link $n3 $n2 100Mb
10ms DropTail
$ns duplex-link $n4 $n2 100Mb
10ms DropTail
$ns duplex-link $n5 $n1 20Mb
10ms DropTail
#gestion du layout
$ns duplex-link-op
$ns duplex-link-op
$ns duplex-link-op
$ns duplex-link-op
$ns duplex-link-op

de la topologie
$n0 $n1 orient right-down
$n1 $n2 orient right-down
$n2 $n3 orient right
$n4 $n2 orient right-up
$n5 $n1 orient right-up

# mise en place des connexions UDP


set udp0 [new Agent/UDP]
$udp0 set class_ 1
$ns attach-agent $n0 $udp0
set udp1 [new Agent/UDP]
$udp1 set class_ 2
$ns attach-agent $n3 $udp1
set udp2 [new Agent/UDP]
$udp1 set class_ 3
$ns attach-agent $n5 $udp2
# Coloration des classes : bleu pour udp (classe 1) et rouge pour tcp
(classe 2)
$ns color 1 Red
$ns color 2 Blue
$ns color 3 Green
# Traffic CBR de 500 octets toutes les 5 ms pour udp0
set cbr0 [new Application/Traffic/CBR]
$cbr0 set packetSize_ 500
$cbr0 set interval_ 0.005
$cbr0 attach-agent $udp0

# Traffic CBR de 500 octets toutes les 5 ms pour udp1


set cbr1 [new Application/Traffic/CBR]
$cbr1 set packetSize_ 500
$cbr1 set interval_ 0.005
$cbr1 attach-agent $udp1
# Traffic CBR de 500 octets toutes les 5 ms pour udp2
set cbr2 [new Application/Traffic/CBR]
$cbr2 set packetSize_ 500
$cbr2 set interval_ 0.005
$cbr2 attach-agent $udp2
# Le trafic issus des agents udp0, udp1 et udp2 est envoy vers NULL0
set null0 [new Agent/Null]
$ns attach-agent $n4 $null0
$ns connect $udp0 $null0
$ns connect $udp1 $null0
$ns connect $udp2 $null0
# Scnario
$ns at 0.5
$ns at 0.5
$ns at 0.5
$ns at 4.5
$ns at 4.5
$ns at 4.5

de dbut et de fin de gnration des paquets par cbr0


"$cbr0 start"
"$cbr1 start"
"$cbr2 start"
"$cbr0 stop"
"$cbr1 stop"
"$cbr2 stop"

# La simulation va durer 5 secondes et appeller la proc finish


$ns at 5.0 "finish"
# dbut de la simulation
$ns run

Extrait de log dun serveur ayant la criticit WARNING


Sep 15 21:34:58 serveur1 heartbeat: [984]: WARN: Logging daemon is disabled --enabling
logging daemon is recommended
Sep 15 21:35:33 serveur1 heartbeat: [1064]: WARN: node serveur2: is dead
Sep 15 21:35:33 serveur1 heartbeat: [1064]: WARN: No STONITH device configured.
Sep 15 21:35:33 serveur1 heartbeat: [1064]: WARN: Shared disks are not protected.
Sep 15 21:35:57 serveur1 heartbeat: [1064]: WARN: 1 lost packet(s) for [serveur2] [11:13]
Sep 15 21:56:05 serveur1 heartbeat: [1407]: WARN: Temporarily Suppressing write error
messages
Sep 15 21:56:05 serveur1 heartbeat: [1407]: WARN: Is a cable unplugged on bcast eth0?
Sep 15 21:56:05 serveur1 heartbeat: [1064]: WARN: node serveur2: is dead
Sep 15 21:56:05 serveur1 heartbeat: [1064]: WARN: No STONITH device configured.
Sep 15 21:56:05 serveur1 heartbeat: [1064]: WARN: Shared disks are not protected.
Sep 15 21:56:09 serveur1 heartbeat: [1064]: WARN: node 192.168.1.1: is dead
Sep 15 21:56:47 serveur1 heartbeat: [1064]: WARN: No reply to standby request.
request cancelled.

Standby

Sep 15 21:57:26 serveur1 heartbeat: [1064]: WARN: Deadtime value may be too small.
Sep 15 21:57:26 serveur1 heartbeat: [1064]: WARN: Late heartbeat: Node serveur2: interval
90870 ms
Sep

15 21:57:26 serveur1
interval 86880 ms

heartbeat:

[1064]:

WARN:

Late

heartbeat:

Node

192.168.1.1:

Sep 15 21:57:41 serveur1 heartbeat: [1064]: WARN: Logging daemon is disabled --enabling
logging daemon is recommended
Sep 15 21:59:53 serveur1 heartbeat: [3164]: WARN: node serveur2: is dead
Sep 15 21:59:53 serveur1 heartbeat: [3164]: WARN: No STONITH device configured.
Sep 15 21:59:53 serveur1 heartbeat: [3164]: WARN: Shared disks are not protected.
Sep 15 22:00:09 serveur1 heartbeat: [3169]: WARN: Temporarily Suppressing write error
messages
Sep 15 22:00:09 serveur1 heartbeat: [3169]: WARN: Is a cable unplugged on bcast eth0?
Sep 15 22:00:13 serveur1 heartbeat: [3164]: WARN: node 192.168.1.1: is dead
Sep

15 22:00:47 serveur1
interval 43130 ms

heartbeat:

[3164]:

WARN:

Late

heartbeat:

Node

192.168.1.1:

Sep 15 22:00:47 serveur1 heartbeat: [3164]: WARN: Deadtime value may be too small.
Sep 15 22:00:47 serveur1 heartbeat: [3164]: WARN: Late heartbeat: Node serveur2: interval
63720 ms
Sep 15 22:00:49 serveur1 heartbeat: [3164]: WARN: Shutdown delayed until current resource
activity finishes.

Оценить