Projet tuteuré Redondance de serveur Redondance de …€¦ · sur IP avec le logiciel sur IP avec le logiciel AsteAsteAsterisk risk ... 3.2 Installation et configuration d’Asterisk

Licence Réseaux et Télécoms Année 2008/2009

Projet tuteuréProjet tuteuréProjet tuteuréProjet tuteuré Redondance de serveur Redondance de serveur Redondance de serveur Redondance de serveur de téléphonie de téléphonie de téléphonie de téléphonie

sur IP avec le logiciel sur IP avec le logiciel sur IP avec le logiciel sur IP avec le logiciel AsteAsteAsteAsteriskriskriskrisk Tuteur IUT : Joël TOUSSAINT Chargé du projet : Laura REDONDO / Maxime BOSCIA


Melle REDONDO Laura Tuteur : M. TOUSSAINT M. BOSCIA Maxime

RemerciementsRemerciementsRemerciementsRemerciements Nous tenons tout d’abord à remercier M. Joël TOUSSAINT, qui fut notre tuteur durant la période de notre projet, de l’écoute et du temps qu’il nous a accordé quand nous en avions besoin. Nous souhaitons remercier aussi Mme. Nadine GIRAUD pour les cours de communication et d’expression qui ont contribué à l’élaboration de ce rapport et de notre soutenance. Nous remercions aussi l’ensemble de la communauté informatique qui a contribué sans le savoir à ce projet par le biais de site web ou bien de forums. Un remerciement tout particulier est adressé à M. Laurent PERRIN qui nous a fourni la documentation nécessaire essentielle à la bonne réalisation de ce projet.



SommaireSommaireSommaireSommaire Introduction ................................................................................................................................ 1

1 Gestion de projet ................................................................................................................ 2 1.1 Avant Projet Synthétique (APS) .................................................................................. 2 1.2 Avant Projet Détaillé (APD) ........................................................................................ 2 1.3 Cahier des charges fonctionnel (CCF) ......................................................................... 2 1.4 Work Breakdown Structure (WBS) ............................................................................. 5 1.5 Tableau d’antériorité des tâches (TAT) ....................................................................... 6 1.6 Diagramme de GANTT ............................................................................................... 6 1.7 Bilan personnel ............................................................................................................ 8

2 La VoIP et Asterisk .......................................................................................................... 10 2.1 Définition de la VoIP ................................................................................................. 10

2.1.1 Fonctionnement de la VoIP ................................................................................ 10 2.1.2 Avantages ........................................................................................................... 10 2.1.3 Inconvénients ..................................................................................................... 11

2.2 Présentation d’Asterisk .............................................................................................. 12 2.2.1 Avantages ........................................................................................................... 12 2.2.2 Inconvénients ..................................................................................................... 13

2.3 SIP ............................................................................................................................. 14

2.3.1 Présentation ........................................................................................................ 14 2.3.2 Fonctionnement .................................................................................................. 14

3 Installation de la plateforme VoIP.................................................................................... 16 3.1 Configuration matérielle ............................................................................................ 16 3.2 Installation et configuration d’Asterisk ..................................................................... 17

3.2.1 Fichier sip.conf ................................................................................................... 18 3.2.2 Fichier extensions.conf ....................................................................................... 19 3.2.3 Fichier voicemail.conf ........................................................................................ 19 3.2.4 Fichier iax.conf ................................................................................................... 21

3.3 Mise en place des clients X-Lite ................................................................................ 23 4 La haute disponibilité ....................................................................................................... 25

4.1 Présentation ............................................................................................................... 25 4.2 Le Fail-Over avec Heartbeat ...................................................................................... 26

4.2.1 Présentation ........................................................................................................ 26 4.2.2 Configuration du cluster Heartbeat .................................................................... 28

4.2.3 Etat du système ................................................................................................... 29 4.3 Répartition de charge avec IPVS et ldirectord .......................................................... 29

4.3.1 Ipvs ..................................................................................................................... 29 4.3.2 Ldirectord ........................................................................................................... 32

4.4 Scripts d’amélioration ................................................................................................ 36 4.5 Ipv.sh ......................................................................................................................... 36 4.6 test_ldirectord.sh ........................................................................................................ 37 4.7 Schéma d’une plateforme optimisée .......................................................................... 39

5 Test de notre solution ....................................................................................................... 40 Conclusion ................................................................................................................................ 43

English Summary ..................................................................................................................... 44

Glossaire ................................................................................................................................... 45

Bibliographie ............................................................................................................................ 49

Annexes .................................................................................................................................... 50


Melle REDONDO Laura Tuteur : M. TOUSSAINT M. BOSCIA Maxime Page | 1

IntroductionIntroductionIntroductionIntroduction

Dans le cadre de notre licence professionnelle Réseaux et Télécommunications, option Administration Et Sécurité des Réseaux, à l'Institut Universitaire de Technologie de Clermont-Ferrand, nous avons eu l’occasion de réaliser un projet tuteuré.

Celui-ci porte sur une étude de redondance de serveurs de téléphonie Asterisk. Cette technologie étant de nos jours en plein essor dans les entreprises, ce sujet nous permet de compléter notre expérience dans le domaine de la VOIP (voix sur IP), compétence qui nous sera utile dans le monde du travail.

Notre objectif ici est de mettre en place une solution de haute disponibilité du service Asterisk dans un contexte de grande entreprise, incluant des coupures ou encore des surcharges du système. Face à ces objectifs, nous pouvons donc nous poser les questions suivantes :

Pourquoi étudier la haute disponibilité du système Asterisk ?

Quelle technologie utiliser et comment la mettre en place ?

En premier lieu, nous verrons les outils de gestion de projet. Ensuite, nous étudierons la VOIP puis le logiciel Asterisk et son mode de fonctionnement. Dans une troisième partie, nous installerons notre plateforme de téléphonie. Puis nous rechercherons quelles technologies permettent de mettre en place un service de haute disponibilité et quelles sont leurs fonctionnalités. Enfin, nous effectuerons des tests afin de nous assurer du bon fonctionnement de notre solution.



1111 Gestion de projetGestion de projetGestion de projetGestion de projet

Ce projet a été l’occasion de s’exercer à mettre en place les techniques de gestion de projet apprise pendant les cours de Monsieur CLAVAUD afin de se rendre compte des difficultés que représente la charge de « Chef de projet ».

On retrouvera donc dans cette partie tous les documents utiles qui ont dû être produit afin

d’analyser, gérer et répondre aux exigences du projet.

1.11.11.11.1 Avant Projet Synthétique (APS)Avant Projet Synthétique (APS)Avant Projet Synthétique (APS)Avant Projet Synthétique (APS) Téléphonie sur IP :

Le but est ici de mettre en place une solution de téléphonie telle qu’Asterisk. Après avoir étudié les fonctionnalités de base, le but est de réaliser l’interconnexion de plusieurs serveurs, afin d’étudier comment peut-être déployée une telle solution dans un environnement multi-site et avec beaucoup d’usagers.

1.21.21.21.2 Avant Projet Détaillé (APD)Avant Projet Détaillé (APD)Avant Projet Détaillé (APD)Avant Projet Détaillé (APD)

Dans le cadre de notre projet, nous mettrons en place un serveur de téléphonie sur IP grâce au logiciel Asterisk ainsi que des logiciels de téléphonie clients comme X-Lite. Puis nous déploierons un deuxième serveur Asterisk afin d’étudier comment le connecter au premier et ainsi obtenir une interconnexion de serveurs de téléphonie. Enfin, nous utiliserons un logiciel de test comme SIPp afin d’étudier le comportement des serveurs quand ils sont surchargés de communications, pour simuler le contexte de téléphonie de grande entreprise avec de nombreux utilisateurs.

1.31.31.31.3 Cahier des charges fonctionnel (CCF)Cahier des charges fonctionnel (CCF)Cahier des charges fonctionnel (CCF)Cahier des charges fonctionnel (CCF) Le cahier des charges fonctionnel permet de définir le besoin du client au moyen de

fonctions détaillant les services rendus par le produit et de contraintes auxquelles il est soumis.

Pour cela, on utilise d’abord la méthode de questionnement QQOQCCP : Quoi ? Qui ?

Où ? Quand ? Comment ? Combien ? Pourquoi ? Puis on établit enfin le tableau des fonctions et des contraintes du produit.



Méthode de questionnement : Réponses Pourquoi ?

Qui ?

Chefs de projet : Laura REDONDO et Maxime BOSCIA Client / Utilisateur : Mr TOUSSAINT

Nous avons choisi ce projet.

Quoi ? Interconnexion de serveurs de téléphonie sur IP Répartir les communications téléphoniques simultanées lors de la surcharge d’un serveur

Ou ?

Au centre de formation (IUT), dans les salles informatiques réservées

Le matériel nécessaire à la réalisation du projet est mis à notre disposition dans ces locaux.

Quand ? De Novembre à Mai, environ 13 semaines, durant les périodes au centre de formation.

Le travail en entreprise ne nous permet pas de disposer d’un intervalle de temps plus important pour travailler sur le projet.

Comment ? - Mettre en place une architecture matérielle composée d’un serveur de téléphonie sur IP et de postes clients

- Etablir un nombre important de connexions téléphoniques simultanées grâce à un utilitaire à trouver par nous même afin d’établir une situation de surcharge de connexion sur un serveur.

- Ajouter un second serveur de téléphonie sur IP et l’interconnecter avec le premier.

- Gérer la répartition de charge entre les deux serveurs lors d’une surcharge de connexions simultanées.

Grâce à cette procédure, nous pourrons déterminer le nombre de connexions simultanées que peut supporter un serveur. Cette information nous sera donc nécessaire pour gérer par la suite la répartition de charge entre l’ancien serveur et celui ajouté.

Combien ?

Notre budget ne dépassera pas celui de l’achat éventuel de téléphone IP (à compléter pour connaître le budget accordé à cet achat), le reste du matériel nécessaire étant fournit par l’IUT.

Le matériel est fournit par le centre de formation, seul l’achat éventuel de téléphone IP représentera un coût.

Pourquoi ? Analyser le comportement d’un logiciel libre de téléphonie sur IP dans un contexte de grande entreprise nécessitant de nombreuses communications téléphoniques simultanées. Ce projet permettra d’assurer une continuité de service au niveau de la téléphonie.



Cahier des charges fonctionnel N° Type Nature Critère Niveau Flexibilité F1 Fonction Service de téléphonie Serveurs Asterisk 0%

F2 Fonction Connexions simultanées au serveur

Nombre Maximum

F3 Fonction Redondance du service téléphonique

Deux serveurs Asterisk 0%

F4 Fonction Interconnexion Equilibrage de charge en terme de communications.

Répartition équitable 0%

C1 Contrainte Délai Date de la soutenance 20 mai 0%

C2 Contrainte Temps de réalisation Semaine 13 environ 0%

C3 Contrainte Logiciel Serveur de téléphonie Asterisk 0%

C4 Contrainte Système d’exploitation Serveur support de la solution téléphonique Linux Debian 0%

C5 Contrainte Budget Euro 0 0%

C6 Contrainte Matériel Nombre 2 serveurs Asterisk sur Linux Debian 2 clients X-Lite sur Windows XP

0%

C7 Contrainte Lieu Centre de formation Salles réservées 0%



1.41.41.41.4 Work Breakdown Structure (WBS)Work Breakdown Structure (WBS)Work Breakdown Structure (WBS)Work Breakdown Structure (WBS)

Le « Work Breakdown Structure » est un outil de gestion de projet qui permet de déterminer les tâches à effectuer au cours de notre projet.

Interconnexion de serveurs de

téléphonie Asterisk

Installer les serveurs

Installer les postes clients

Créer une situation de surcharge sur l’un des

deux serveurs

Gérer la haute disponibilité et la

répartition de charge

Installer Linux Debian

sur deux postes

physiques (A)

Installer VMWare

sur les serveurs

(I)

Installer et configurer le logiciel de téléphonie Asterisk

(B)

Installer les clients

virtuels sur les serveurs

(C)

Configurer les logiciels clients

(D)

Utiliser un logiciel

créant des surcharges

(E)

Analyser les conséquences

de la surcharge

(F)

Etudier la configuration à mettre en

place (G)

Installer la solution

(H)



1.51.51.51.5 Tableau d’antériorité des tâches (TAT)Tableau d’antériorité des tâches (TAT)Tableau d’antériorité des tâches (TAT)Tableau d’antériorité des tâches (TAT)

Le tableau d’antériorité des tâches vient à la suite du WBS et permet de hiérarchiser l’ensemble des tâches définis dans le temps.

Tâches Nom Antériorité Temps x Hommes A Installer Linux Debian / 8 B Installer/configurer Asterisk A 40 C Installer les clients A, I 8 D Configurer les clients A, B, C, I 20 E Créer la surcharge A, B, C, D, I 56 F Analyser les conséquences A, B, E, C, D, I 40 G Etudier les solutions / 40 H Installer notre solution A, B, D, E, F, G, I 80 I Installer VMWare A 8

1.61.61.61.6 Diagramme de GANTTDiagramme de GANTTDiagramme de GANTTDiagramme de GANTT

Le diagramme de GANTT est un outil de planification des différentes tâches du projet afin de suivre son état d’avancement. Cela permet de savoir si l’on est en avance, dans les temps ou bien en retard sur le projet.



Diagramme de GANTT



1.71.71.71.7 Bilan personnelBilan personnelBilan personnelBilan personnel

Laura : Ce projet m’a permis d’améliorer mes compétences dans la maîtrise des systèmes Linux. De plus, issue d’une formation de BTS Informatique de Gestion option Administrateur des Réseaux Locaux d’Entreprise, je ne disposais d’aucune connaissance dans le domaine de la téléphonie sur IP. L’exécution de ce projet m’a donc apporté de nouvelles connaissances dans ce domaine, qui est aujourd’hui en plein essor dans le monde de l’entreprise.

J’ai également pu acquérir des compétences humaines telles que le travail en équipe et la répartition du travail. En effet, devant travailler en binôme, certaines tâches à effectuer ont été réalisées en parallèle les unes des autres. J’ai donc pu apprendre à diviser certaines tâches et à rendre compte de l’avancement de mes propres actions auprès de mon binôme. De cette façon, nous avons pu suivre l’avancement du projet sans oublier certains éléments qui auraient pu être essentiels à sa bonne réalisation. Mes capacités rédactionnelles ont permis l’avancement du projet et notamment du rapport. En effet, ayant l’habitude de prendre des notes, j’ai pu établir un suivi de l’avancement du projet, qui a pu permettre de résoudre les différentes difficultés que nous avons rencontré en relevant d’éventuelles erreurs de configuration que nous avions effectuées. Ne me reposant jamais sur mes acquis, j’ai effectuée de nombreuses recherches afin de trouver des solutions aux problèmes que nous avons pu rencontrer. Ces recherches ont permis la résolution de certaines difficultés, et parfois, elles ont abouties à de nouvelles solutions à mettre en place pour contourner nos problèmes techniques. Face au retard que nous avons pu prendre sur certaines tâches, je n’ai pas cédé au stress et j’ai su gérer la situation en instaurant une répartition dans notre travail afin que nous puissions terminer ce dernier dans les délais.



Maxime : Pendant toute la durée de ce projet, j’ai pu apporter mes connaissances aussi bien sur le plan technique, organisationnel ou humain. En effet, mes compétences techniques en matière de réseaux ont permis de résoudre de nombreux problèmes qui se sont posés lors de cet exercice et notamment sur la partie concernant l’interconnexion des serveurs Asterisk entre eux. Au niveau organisationnel, j’ai apporté ma rigueur dans la rédaction et la mise en forme de documents. De plus, étant méticuleux dans mon travail et organisé dans l’ordre des différentes tâches à effectuer, cela nous a permis d’éviter en grande partie les erreurs ou de les retrouver très rapidement. Sur le plan humain, j’ai utilisé mes connaissances précédentes du travail en équipe, basé sur mes expériences précédentes, afin de bien collaborer avec ma collègue et de fournir du bon travail. Ce projet m’a quant à lui apporté de nombreuses compétences sur ces mêmes plans. Ainsi, au niveau technique, j’ai mieux appris à connaître les systèmes Linux. De plus, la téléphonie sur IP et les techniques de haute disponibilité étaient des domaines complètement inconnus pour moi. Sur le plan organisationnel, j’ai pu voir ce qu’était toute la difficulté de bien gérer un projet et qu’il ne suffisait pas d’être bon techniquement pour mener son projet à bien. Cela demande de multiples connaissances autant au niveau de la gestion de projet qu’au niveau de la création de documents ou encore au niveau du sens des relations humaines. J’ai donc appris que de nombreux outils de gestion existe afin de nous aider à gérer au mieux un projet. Pour ce qui est des compétences humaines, ce projet m’a enseigné à demander de l’aide lorsque cela est nécessaire. La communauté informatique est très grande et toujours prête à se rendre service si c’est nécessaire. Sans cela, notre projet n’aurai jamais pu aboutir à son terme.



2222 La La La La VoIPVoIPVoIPVoIP et et et et AsteriskAsteriskAsteriskAsterisk

2.12.12.12.1 Définition de la Définition de la Définition de la Définition de la VoIPVoIPVoIPVoIP

La Voix sur IP, ou Voice Over IP en anglais, est une technique qui permet le transport de la voix via la technologie IP (1)1 à travers Internet ou tout autre réseau acceptant le protocole TCP/IP (2).

Celle-ci est employé grâce à un IPBX (Internet Protocol Private Branch Exchange) qui n’est autre qu’un commutateur téléphonique comme un PABX (Private Automatic Branch Exchange) sauf qu’il fonctionne via la technologie IP.

2.1.12.1.12.1.12.1.1 FFFFonctionnementonctionnementonctionnementonctionnement de la de la de la de la VoIPVoIPVoIPVoIP

La voix est avant tout un signal analogique (3). Elle est donc d’abord échantillonnée afin de la numériser (4) pour qu’elle puisse être transmise par voix numérique. Des codecs (5) sont ensuite utilisés afin de compresser (6) ce signal.

La téléphonie traditionnelle utilise la commutation de circuits (7) pour le transport de la voix. La téléphonie sur IP, quant à elle, effectue ce transport à l’aide de la commutation de paquets (8).

La voix est transformée en paquets qui vont transiter sur le réseau en utilisant le protocole UDP (9). UDP est un protocole de transport qui procure de meilleurs délais d’envoi des paquets que TCP (10) car il n’utilise pas de contrôle de réception, dit acquittement.

2.1.22.1.22.1.22.1.2 AvantagesAvantagesAvantagesAvantages La VoIP possède différents avantages qui la rendent intéressante dans un contexte d’entreprise :

� Réduction des frais de facture téléphonique. En effet, avec une solution IPBX, les appels internes à l’entreprise ne sont pas facturés. Des avantages interviennent également dans la mutualisation voix/données du réseau IP inter-sites (WAN (12) )

� Gain de mobilité. Les postes peuvent être déplacés et ne sont plus physiquement reliés à

des lignes. Les numéros des utilisateurs les suivent lors de leurs déplacements.

1 technologie IP (1) : Voir le glossaire, définition n°1.



� Permet une centralisation des équipements qui sont maintenant tous reliés au réseau informatique. (ordinateurs, téléphones, fax...)

� Les services opérateurs ouvrent les alternatives VoIP. Non seulement l'entreprise peut opérer son réseau privé VoIP en extension du réseau RTC (13) opérateur, mais l'opérateur lui-même ouvre de nouveaux services de transport VoIP qui simplifient le nombre d'accès locaux à un site et réduit les coûts induits. Le plus souvent les entreprises opérant des réseaux multi-sites louent une liaison privée pour la voix et une pour la donnée, en conservant les connexions RTC d'accès local. Les nouvelles offres VoIP opérateurs permettent, outre les accès RTC locaux, de souscrire uniquement le média VoIP inter-sites.

� La VoIP intègre une gestion de la voix mais également une gestion de la vidéo. En effet,

le réseau VoIP peut accueillir des applications vidéo de type vidéoconférence, vidéo surveillance, …

2.1.32.1.32.1.32.1.3 InconvénientsInconvénientsInconvénientsInconvénients La VoIP implique des contraintes sur les performances du réseau telles que : � le délai de latence (RTD = Round Trip Delay) : c’est le temps que met un paquet IP pour

traverser le réseau. (valeur acceptable : inférieur ou égal à 200 ms) � la gigue (ou Jitter): c’est la variation du délai de latence. (valeur acceptable : inférieur ou

égal à 75 ms) � le taux de perte de paquets : parfois, certains datagrammes (11) UDP sont détruits (surtout

à cause de l’engorgement du réseau). Pour qu’une conversation soit compréhensible, la dégradation du signal voix ne doit pas dépasser un certain seuil. (valeur acceptable : inférieur ou égal à 3%)



2.22.22.22.2 Présentation d’Présentation d’Présentation d’Présentation d’AsteriskAsteriskAsteriskAsterisk Asterisk est un logiciel qui, installé sur un ordinateur, fait office de PABX. C’est un logiciel libre (Open Source), publié et créé par Mark Spencer de la société Digium en 1999. Il tourne sur Linux, BSD et Mac OS X (14). Asterisk offre tous les services de téléphonie « classiques » d’un PABX ainsi que des fonctions avancées :

� Boîte vocale (avis par courriel de réception d’un message vocal, voyant indicateur de

message en attente…)

� Conférence téléphonique

� Serveur vocal interactif

� Applications CTI (ex : possibilité de composer un numéro de téléphone à partir

du carnet d’adresses d’Outlook)

� Visiophonie

� Rapport détaillé sur les appels

Asterisk utilise différents protocoles afin de faire de la téléphonie, tels que SIP ou encore

H323 et IAX. Les protocoles SIP (Session Initiation Protocol) et H323 sont des protocoles qui permettent d’établir, modifier et terminer des sessions multimédia. Nous utiliserons ici le protocole SIP que nous décrirons dans la partie suivante. Le protocole IAX (Inter-Asterisk eXchange) permet la communication entre client (15) et serveur (16) ainsi qu'entre serveurs Asterisk.

2.2.12.2.12.2.12.2.1 AvantagesAvantagesAvantagesAvantages

Le logiciel Asterisk présente plusieurs avantages. Le premier est avant tout son coût. En effet, issue du monde libre, Asterisk et l’ensemble des paquets (17) qui lui sont rattachés sont disponibles en téléchargement gratuit sur Internet.

La configuration d’Asterisk est également un avantage car elle se résume essentiellement à quelques lignes de commandes à rajouter dans des fichiers, et la communauté Linuxienne (18) permet grâce aux différents forums de s’approprier assez rapidement ces commandes et donc cette configuration.

Il permet également de passer sur le réseau RTC (téléphonique commuté) via des cartes de téléphonie type PCI (19) à incorporer au serveur.



Enfin, Asterisk propose toutes les fonctionnalités ou presque d’un commutateur PABX (20) classique.

2.2.22.2.22.2.22.2.2 InconvénientsInconvénientsInconvénientsInconvénients

Asterisk dispose néanmoins d’un inconvénient majeur. En effet, son utilisation est dédiée uniquement aux plateformes Linux. Aujourd’hui, de plus en plus de serveur dispose de système Linux tel que Debian (21) ou encore Red Hat (22). Néanmoins, Windows est le plus souvent présent dans les petites entreprises et cela peut être un frein au développement de cette solution.

Une solution Asterisk sous Windows est actuellement en cours de développement mais la version la plus stable reste actuellement celle sous Linux.



2.32.32.32.3 SIPSIPSIPSIP

2.3.12.3.12.3.12.3.1 PrésentationPrésentationPrésentationPrésentation

SIP est un protocole normalisé et standardisé par l'IETF (23). Il a été conçu pour établir, modifier et terminer des sessions multimédia (24). Il se charge de l'authentification et de la localisation des multiples participants mais également de la négociation sur les types de média utilisables par les différents participants.

SIP ne transporte pas les données échangées durant la session comme la voix ou la vidéo. SIP étant indépendant de la transmission des données, tout type de données et de protocoles peut être utilisé pour cet échange. Cependant le protocole RTP (Real-time Transport Protocol) assure le plus souvent les sessions audio et vidéo. SIP remplace progressivement H.323.

2.3.22.3.22.3.22.3.2 FonctionnementFonctionnementFonctionnementFonctionnement

SIP permet de créer et gérer des sessions entre participants pour échanger des données. SIP est un protocole ouvert (25) à base de texte ce qui le rapproche du protocole http (26). SIP utilise un ensemble de méthodes qui lui sont propres telles que : - INVITE (première requête envoyée pour débuter un appel) - ACK (Accusé envoyé par le client qui indique la bonne réception de la réponse du serveur à la requête précédemment transmise). - CANCEL (code d'annulation de INVITE). - BYE (fin de session d’appel). De nombreux codes de réponse nous indiquent les différentes étapes suivies par SIP, ces codes sont regroupés par famille : - 1XX : nous donnes des informations sur l’action en cours (ex: 100 TRYING, 180 RINGING, 183 SESSION PROGRESS…) - 2XX : indique la bonne réception et l’acceptation d’une requête (ex: 200 OK) - 3XX : redirection, une autre action doit être menée afin de valider la requête. - 4XX : nous indique une erreur du client, la requête contient une syntaxe erronée ou ne peut pas être traitée par ce serveur (ex: 400 BAD REQUEST, 401 UNAUTHORISED, 404 NOT FOUND….)



- 5XX : nous indique une erreur du serveur, ce dernier n’ a pas réussi à traîter une requête apparemment correcte (ex : 500 INTERNAL SERVER ERROR , 502 BAD GATEWAY…) - 6XX : échec général, la requête ne peut être traitée par aucun serveur ( ex : 600 BUSY EVERYWHERE). Nous pouvons analyser les échanges de SIP via un analyseur de trames (27) comme le logiciel WireShark. Le schèma ci-dessous représente un échange lors de l’établissement d’une communication via le protocole SIP.

Figure 1 : Schéma de l’établissement d’une communication

On peut donc voir sur ce schéma que lorsque l’utilisateur A souhaite établir une communication avec B, une trame INVITE est envoyée au serveur. Ce dernier renvoie alors une trame TRYING qui stipule à A qu’il est en train d’essayer d’établir la communication.

Le serveur envoie ensuite une trame INVITE à l’utilisateur B qui lui répond également à l’aide d’une trame TRYING, puis d’une trame RINGING lui indiquant que le téléphone de B sonne. Cette trame est transmise à A qui doit entendre la tonalité dans son téléphone indiquant que celui de B est en train de sonner.

B décroche alors et une trame OK signale au serveur que la requête de communication avec B a bien été reçu. Cette trame est transmise à A qui envoie alors un ACK (acquittement) à B pour que la communication puisse s’établir. A et B peuvent alors discuter.

Lorsque A raccroche, une trame BYE est alors envoyée au serveur qui la transfert à B. Celui-ci répond par une trame OK stipulant qu’il a bien reçu la trame BYE qui termine la communication.



3333 Installation de la plateforme Installation de la plateforme Installation de la plateforme Installation de la plateforme VoIPVoIPVoIPVoIP

3.13.13.13.1 Configuration matérielleConfiguration matérielleConfiguration matérielleConfiguration matérielle

Notre objectif étant de créer une redondance du service Asterisk pour assurer une haute disponibilité (28), nous avons du mettre en place une plateforme disposant de deux serveurs Asterisk. Des machines clientes étaient également nécessaires pour pouvoir tester notre configuration à l’aide de softphones (29). Nous avons choisi de virtualiser notre plateforme à l’aide du logiciel VMWare (30). Nous avons adopté cette solution pour des raisons matérielles. En effet, sans la virtualisation, nous aurions du disposer d’au minimum 4 machines physiques, à savoir deux serveurs et deux clients. Nous avons donc utilisé deux machines physiques équipées de VMWare, puis nous avons créé sur chacune d’elle deux postes clients Windows XP virtuels et un serveur Linux Debian pour hébergé notre service de téléphonie.

Nous avons donc appliqué la structure suivante :

Figure 2 : Schéma de notre plateforme d’origine



3.23.23.23.2 Installation et configuration d’Installation et configuration d’Installation et configuration d’Installation et configuration d’AsteriskAsteriskAsteriskAsterisk Pour installer Asterisk, nous avons choisi d’utiliser le système Linux Debian que nous

avions eu l’occasion d’exploiter au sein de notre formation. Nous avons donc procédé à une installation classique de Debian en renseignant différentes informations telles que le nom des postes, les mots de passe et nom de connexion des utilisateurs...

Une fois notre poste Debian installé et configuré, nous pouvons mettre en place le

service Asterisk. Nous l’installons via la commande « apt-get install asterisk » après avoir effectué les différentes mises à jour nécessaires.

Asterisk se compose de différents fichiers de configurations qui respectent

l’architecture suivante :

Figure 3 : Schéma de hiérarchisation des fichiers d’Asterisk

/etc

asterisk

sip.conf

voicemail.conf

iax.conf

extensions.conf



3.2.13.2.13.2.13.2.1 Fichier sip.confFichier sip.confFichier sip.confFichier sip.conf Pour effectuer notre configuration, nous nous rendons dans le fichier sip.conf qui nous

permet de renseigner les utilisateurs du service Asterisk et leurs caractéristiques. Le fichier sip.conf se présente de la façon suivante :

[121] type=friend username=121 secret=212 host=dynamic callerid="Maxime" context=projet

Voici les explications concernant ces différents paramètres : [121] : numéro utilisé pour appelé l’utilisateur type : trois types peuvent être choisi pour définir les « droits » de l’utilisateur

- friend : droit d’émettre et de recevoir des appels. - peer : droit d’émettre uniquement des appels. - user : droit de recevoir uniquement des appels.

username : nom de l’utilisateur secret : mot de passe de l’utilisateur host : deux situations peuvent se présenter

- dynamic : l’utilisateur peut utiliser tous les clients pour se connecter à son compte. - adresse IP (ex : 192.168.0.3) : l’utilisateur ne pourra qu’utiliser le client à l’adresse

IP indiquée pour se connecter à son compte. callerid : variable identifiant l’utilisateur. On pourra ensuite réutiliser cet variable dans les autres fichiers de configuration du serveur. Cela permet aussi d’afficher le nom de la personne qui appel à l’écran du softphone. context : définit quel contexte du plan de numérotation est attribué à l’utilisateur

Nous créons donc de la même façon différents utilisateurs, (131, 141, 151) dans le fichier sip.conf en nous assurant de créer le même fichier sip.conf sur les deux serveurs. En effet, pour pouvoir mettre en place une solution de redondance, il faut que nos deux serveurs aient la même configuration de ce fichier pour que les clients puissent se connecter aux deux serveurs dans l’éventualité ou l’un des deux tomberait, ou encore, si on instaure une répartition de charge sur les deux serveurs.



3.2.23.2.23.2.23.2.2 Fichier extensions.confFichier extensions.confFichier extensions.confFichier extensions.conf

Une fois le fichier sip.conf configuré correctement, nous nous intéressons au fichier extensions.conf. Celui-ci permet de définir le plan de numérotation qui sera utilisé par le serveur pour savoir quelles actions il doit effectuer lorsque qu’un numéro est composé. A la fin de ce fichier, sur le serveur Asterisk-1, nous rajoutons donc les lignes suivantes : [projet] exten => _1XX,1,Dial(SIP/${EXTEN},20) exten => _1XX,2,HangUp

[projet] représente le contexte auquel appartiennent les clients. C’est dans cette partie que nous indiquons les actions à effectuer par le serveur lorsqu’un numéro est composé.

exten => _1XX,1,Dial(SIP/${EXTEN}) permet d’indiquer au serveur que lorsque

qu’un client appel avec un numéro commençant par le chiffre « 1 », il doit dans un premier temps appeler le client SIP dont le numéro vient d’être composé. Ce numéro est ici représenté par la variable ${EXTEN}. L’option 20 située après le SIP/${EXTEN} signifie au serveur qu’il doit attendre 20 secondes avant de passer à la règle suivante.

exten => _1XX,4,HangUp permet de terminer correctement la communication une fois que celle-ci est fini. Le numéro après la variable _1XX indique l’ordre de priorité des règles c’est-à-dire l’ordre dans lequel elles doivent être exécutées.

3.2.33.2.33.2.33.2.3 Fichier voicemail.confFichier voicemail.confFichier voicemail.confFichier voicemail.conf

Le fichier voicemail.conf sert à définir un contexte de boite vocale qui sera utilisé par les clients SIP. Il doit être le même que celui indiqué dans les fichiers sip.conf et extensions.conf.

On configure notre fichier de la manière suivante :

[projet] 121 => 212,Maxime,121@ServeurMail,,|attach=yes|review=yes 131 => 313,Laura,131@ServeurMail,,|attach=yes|review=yes 141 => 414,Fabien,141@ServeurMail,,|attach=yes|review=yes 151 => 515,Mathieu,151@ServeurMail,,|attach=yes|review=yes



[projet] représente le contexte utilisé par nos différents clients lorsque l’appel est redirigé vers leur boite vocale.

121 => 212,Maxime,121@ServeurMail,,|attach=yes|review=yes permet de définir les différents paramètres lorsque l’on tombe sur la boite vocale d’un client. Ici, il est défini que pour la boite vocale correspondant au numéro « 121 », on utilise le mot de passe « 212 ». Elle correspond à l’utilisateur « Maxime ». Un mail sera envoyé, pour signifié qu’un message est en attente, à l’adresse « 121@ServeurMail ». On a défini deux options. La première, « |attach=yes », indique que l’on joindra au mail le fichier audio *.wav correspondant au message enregistré. La seconde option « |review=yes »permet d’autoriser l’utilisateur à réenregistrer son message si jamais celui-ci veux le faire. Les autres lignes correspondent aux mêmes options mais pour nos autres utilisateurs. Ces lignes sont identiques sur nos deux serveurs mais pour pouvoir l’utiliser et qu’il fonctionne correctement, il faut apporter quelques changements aux fichiers sip.conf et extensions.conf.

Ainsi, on rajoute la ligne suivante pour chaque utilisateur dans notre fichier sip.conf :

[121] type=friend username=121 secret=212 host=dynamic callerid="Maxime" context=projet

mailbox=121@projet mailbox : numéro de la boite vocale dans le contexte projet du fichier voicemail.conf On rajoute aussi les lignes suivantes dans le fichier extensions.conf : [projet] exten => _1XX,1,Dial(SIP/${EXTEN},20) exten => _1XX,2,Voicemail(${EXTEN}@projet) exten => _1XX,3,HangUp exten => 888,1,VoicemailMain(@projet)

exten => _1XX,3,Voicemail(${EXTEN}@projet) indique au serveur d’utiliser la messagerie vocale de l’appelé situé dans le contexte projet du fichier voicemail.conf pour que l’appelant puisse laisser un message.

exten => 888,1,VoicemailMain(@projet) sert à consulter sa boite vocale. Lorsqu’un utilisateur compose le « 888 », le serveur l’envoi sur le menu interactif de la boite vocale du contexte projet défini dans le fichier voicemail.conf.



3.2.43.2.43.2.43.2.4 Fichier Fichier Fichier Fichier iaxiaxiaxiax.conf.conf.conf.conf

Nos deux serveurs sont maintenant configurés mais ils ne communiquent pas entre eux et donc leurs clients respectifs ne peuvent pas s’appeler. Sans un lien, les clients connectés au serveur Asterisk-1 ne peuvent appeler que les clients qui sont également connectés à ce serveur. Il en est de même pour les clients connectés au deuxième serveur. Or, si nous voulons établir une redondance et du load balancing (31) entre nos deux serveurs, il faut que les clients puissent s’appeler d’un serveur à l’autre. Nous avons donc utilisé le protocole IAX pour créer ce lien entre nos deux serveurs.

On définit ce lien dans le fichier iax.conf de la façon suivante : Sur le serveur Asterisk-1 « clermont » :

[paris] type=friend host=192.168.206.131 context=projet trunk=yes Sur le serveur Asterisk-2 « paris » : [clermont] type=friend host=192.168.206.130 context=projet trunk=yes [paris] / [clermont] indique ici le nom du contexte attribué au serveur avec lequel nous allons établir le lien. Ce nom peut être différent du nom du contexte qui est créé dans le fichier extensions.conf ([projet] ). type=friend représente ici le droit d’émettre et de recevoir des appels venant de ce serveur. host=192.168.206.131 correspond à l’adresse IP de l’autre serveur avec lequel Asterisk doit communiquer. context=projet correspond au nom du contexte du plan de numérotation du deuxième serveur sur lequel les appels transmis s’appuieront. trunk=yes signifie que l’on autorise le trunk (32).



Notre lien IAX est créé, mais cela ne suffit pas aux serveurs pour qu’ils puissent émettre des appels de l’un vers l’autre. En effet, nous n’avons pas encore modifié le plan de numérotation d’appels pour que les communications aient lieu entre nos deux serveurs respectifs. Pour cela, nous retournons dans le fichier extensions.conf et ajoutons les lignes suivantes :

Sur le serveur Asterisk-1 « clermont » :

[projet] exten => _1XX,1,Dial(SIP/${EXTEN},20) exten => _1XX,2,Dial(IAX2/paris/${EXTEN},20) exten => _1XX,3,Voicemail(${EXTEN}@projet) exten => _1XX,4,HangUp exten => 888,1,VoicemailMain(@projet)

Sur le serveur Asterisk-2 « paris » :

[projet] exten => _1XX,1,Dial(SIP/${EXTEN},20) exten => _1XX,2,Dial(IAX2/clermont/${EXTEN},20) exten => _1XX,3,Voicemail(${EXTEN}@projet) exten => _1XX,4,HangUp exten => 888,1,VoicemailMain(@projet)

exten => _1XX,2,Dial(IAX2/paris/${EXTEN},20) signifie au serveur d’utiliser le lien IAX avec le deuxième serveur pour contacter le numéro composé. Le serveur utilisera alors son fichier iax.conf pour récupérer les informations utiles à la transmission de l’appel.

Pour le serveur Asterisk-1, par exemple, il utilisera le contexte « paris » que l’on lui a

indiqué dans le fichier extensions.conf. Il va ensuite utiliser l’adresse 192.168.206.131 défini dans ce fichier pour contacter le second serveur et va lui transmettre la requête d’appel à résoudre en utilisant le contexte « projet » de ce dernier.

On peut constater que cette action intervient en second car le serveur doit d’abord

cherché si l’utilisateur appelé est enregistré sur lui-même. Si cet utilisateur est connecté, via son softphone, sur l’autre serveur, il ne le trouvera pas. Il passera donc à la deuxième règle qui lui dit d’utiliser son lien IAX.

Ainsi, l’ensemble des utilisateurs seront joignables qu’ils soient enregistrés sur le serveur Asterisk-1 ou le serveur Asterisk-2.

La configuration de nos serveurs Asterisk est désormais terminée. Avant de pouvoir

lancer le service il faut éditer le fichier /etc/default/asterisk et indiquer l’option RUNASTERISK=yes.

Nous pouvons maintenant démarrer notre service Asterisk avec la commande /etc/init.d/asterisk start.



3.33.33.33.3 Mise en place des clients XMise en place des clients XMise en place des clients XMise en place des clients X----LiteLiteLiteLite

Pour tester notre configuration, nous avons dû installer des postes clients avec des softphones afin que ceux-ci puissent utiliser le service de téléphonie sur IP Asterisk. Nous avons choisi d’utiliser le système d’exploitation Windows XP pour les postes clients et les softphones X-Lite qui nous permettent de tester l’ensemble des fonctionnalités que nous avons mises en place.

Les softphones X-Lite se présentent de la façon suivante :

Figure 4 : Softphone X-Lite On peut voir que le numéro de l’utilisateur est ici le numéro 121. L’interface ci-dessus

est celle qui s’affiche à l’écran de l’utilisateur. Pour appeler un correspondant, il lui suffit de cliquer sur les numéros. Pour décrocher, un simple clic sur le téléphone vert suffit. L’utilisateur a la possibilité d’enregistrer sa conversation via l’option record ou de faire un « bis » via le bouton Redial. D’autres options sont disponibles mais nous ne les détaillerons pas car nous avons uniquement besoin de pouvoir appeler un correspondant pour tester notre configuration.



Pour configurer notre softphone, nous nous rendons dans l’onglet SIP Account Settings visible ci-dessous :

Figure 5 : Menu de X-Lite L’écran de configuration suivant apparaît alors :

Figure 6 : Configuration d’un compte SIP



Via cet écran de configuration, nous renseignons le numéro de l’utilisateur, son nom, son mot de passe pour accéder à son compte SIP, et enfin, dans le champ « Domain » nous indiquons l’adresse IP du serveur auquel il est connecté : ici 192.168.206.130 à savoir Asterisk-1.

Une fois connectés, nos clients peuvent communiquer d’un serveur à l’autre grâce à

notre lien IAX. Notre plateforme est donc en place, nous pouvons maintenant passer à l’étude de la

solution de haute disponibilité.

4444 La haute disponibilité La haute disponibilité La haute disponibilité La haute disponibilité

4.14.14.14.1 PrésentationPrésentationPrésentationPrésentation

On appelle "haute disponibilité" (en anglais "high availability") toutes les dispositions visant à garantir la disponibilité d'un service, c'est-à-dire assurer le fonctionnement correct et continu d'un service. Le terme "disponibilité" désigne la probabilité qu'un service soit en bon état de fonctionnement à un instant donné.

La disponibilité est aujourd'hui un enjeu important des infrastructures informatiques. On estime aujourd'hui que la non-disponibilité d'un service informatique peut avoir des coûts se chiffrant en millions, particulièrement dans le domaine de l'industrie où l'arrêt d'une chaîne de production peut avoir un effet dévastateur.

La haute disponibilité est donc un sujet d’actualité et elle peut être mise en place par différents moyens :

• la redondance des équipements ; • la sécurisation des espaces de stockage ; • l'équilibrage de charge et la répartition de charge ; • l'emploi des technologies de réplication de bloc et de surveillance; • la sécurisation des sauvegardes : externalisation, stockage sur site tiers.

L’ensemble de ces moyens permettent de mettre en place une solution fiable et disponible pour n’importe quel système. Néanmoins, pour des raisons matérielles et de délais, nous n’en avons sélectionné que deux qui permettraient à notre système d’être suffisamment fiable, à savoir, la redondance de serveur à laquelle nous avons ajouté du Fail Over (33), et la répartition de charge.



4.24.24.24.2 Le FailLe FailLe FailLe Fail----Over avec Heartbeat Over avec Heartbeat Over avec Heartbeat Over avec Heartbeat

4.2.14.2.14.2.14.2.1 PrésentationPrésentationPrésentationPrésentation

Le Fail-over se traduit en français par « passer outre la panne ». Ce procédé a la capacité de faire basculer un équipement réseau automatiquement vers un chemin réseau (34) alternatif (autre équipement).

Cette capacité existe pour tout type d'équipements réseau, du serveur au routeur (35) en passant par les pare-feu (36) et les commutateurs réseau (switch). Le basculement intervient généralement sans action humaine et même bien souvent sans aucun message d'alerte. Le basculement est conçu pour être totalement transparent.

Les concepteurs de systèmes prévoient généralement cette possibilité dans les serveurs ou les réseaux qui nécessitent une disponibilité permanente (HA=High Availability). Dans certains cas, le basculement automatique n'est pas souhaité et le basculement requiert une action humaine ; c'est ce que l'on appelle automatisation avec approbation humaine. Il existe deux modes principaux de basculement :

• actif/actif qui s'apparente plus à de l'équilibrage de charge (ou load-balancing) ; et le mode classique couramment répandu,

• actif/passif où l'équipement secondaire (passif) est en mode veille tant que l'équipement primaire (actif) ne rencontre aucun problème.

Pour effectuer notre fail-over, nous avons étudié le programme Heartbeat qui est un

système de gestion de la haute disponibilité sous Linux, FreeBSD, OpenBSD, Solaris (37) et MacOS X.

Heartbeat met en place un système classique de clustering (38) en haute disponibilité basé

sur des battements de cœur. Il exécute des scripts d'initialisations (39) lorsqu’une machine tombe (plus d'entente du battement de cœur) ou est à nouveau disponible (battement de cœur retrouvé).

Heartbeat fonctionne à l’aide d’une adresse IP virtuelle qu’il attribue à son cluster. Ce dernier se compose de deux machines, en l’occurrence nos deux serveurs Asterisk.

Le serveur Asterisk-1 sera alors considéré comme Actif et le Asterisk-2 comme Passif. L’adresse IP virtuelle sera physiquement visible seulement sur le serveur actif (Asterisk-1) et nos clients interagiront donc uniquement avec ce même serveur. Néanmoins, si ce serveur devait ne plus fonctionner, Heartbeat redirigera alors l’IP virtuelle sur le serveur passif (Asterisk-2) qui assurera la continuité de service. Une fois que le serveur Asterisk-1 sera remis en service, Heartbeat lui réattribuera automatiquement l’adresse IP virtuelle et il redeviendra le serveur actif. Les serveurs seront alors considérés comme des « nœuds »du cluster. Nos clients Asterisk auront alors comme adresse de référence du domaine l’IP virtuelle qui sera 192.168.206.150 et non pas une des deux adresses IP de serveur.



Le schéma ci-dessous illustre cette configuration :

Figure 7 : Schéma de notre plateforme avec Heartbeat

Ici nous pouvons constater que notre lien Heartbeat est bien monté entre nos deux

serveurs, mais seul le premier dispose de l’adresse IP virtuelle. Nos clients utilisent donc tous ce dernier pour envoyer leurs requêtes SIP.

Figure 8 : Schéma de la plateforme quand un serveur tombe en panne

Ce schéma nous montre que si le serveur Asterisk-1 tombe, le second récupère

l’adresse IP virtuelle et les requêtes des clients lui sont alors transmises. Lorsque le serveur Asterisk-1 sera de nouveau en service, il reprendra automatiquement l’adresse IP virtuelle et nous retournerons à la configuration illustrée sur le schéma précédent.



4.2.24.2.24.2.24.2.2 Configuration du cluster HeartbeatConfiguration du cluster HeartbeatConfiguration du cluster HeartbeatConfiguration du cluster Heartbeat

Nous installons le paquet Heartbeat via la commande « apt-get install heartbeat ». La configuration d’Heartbeat s’effectue dans différents fichiers que nous devons tout d’abord créer. Cette configuration sera identique sur les deux serveurs.

Le premier fichier de configuration à créer est le fichier ha.cf à l'emplacement /etc/ha.d/. Ce fichier donne les caractéristiques du cluster monté par Heartbeat : logfacility daemon node asterisk-1 node asterisk-2 keepalive 1 deadtime 10 bcast eth0 auto_failback on logfacility daemon signifie que les logs seront envoyé au syslog dans la catégorie daemon. node asterisk-1 / node asterisk-2 est la liste des membres du cluster Heartbeat. keepalive 1 définit la vitesse de contrôle des nœuds entre eux. deadtime 10 est le temps avant de déclarer qu'un des nœuds est en panne. bcast eth0 définit l’interface réseau à utiliser pour les trames de broadcast de Heartbeat auto_failback on définit si le nœud maître du cluster reprend son rôle lorsqu’il est redétecté.

Nous créons ensuite le fichier haresources au même emplacement. Ce fichier indique au service Heartbeat quel est le serveur qui sera actif pour le cluster.

asterisk-1 IPaddr2::192.168.206.150/24/eth0 On indique ici le nom du serveur actif, et l’adresse IP virtuelle qui lui sera attribuée sur son interface (carte réseau), ici eth0.

Enfin, le fichier authkeys sera nécessaire pour sécuriser le service. En effet, le authkeys contient les informations nécessaires à l'authentification des noeuds du cluster entre eux, pour maximiser la sécurité. Chaque serveur dispose du même fichier authkeys qui contient la « clé secrète ». Voici sa configuration :

auth 1 1 sha1 password

Ces lignes nous permettent d’indiquer que l’on utilise l’authentification numéro « 1 » qui correspond à l’utilisation d’une clé secrète (« password ») qui sera cryptée en sha1.



4.2.34.2.34.2.34.2.3 Etat du système Etat du système Etat du système Etat du système Notre redondance de serveurs est donc mise en place et nous permet de gérer la haute

disponibilité du service en cas de panne d’un serveur. Néanmoins, étant donné que nous avons dans cette configuration un serveur actif (qui

exécute le service asterisk) et un passif (qui prend la relève en cas de panne du premier seulement) , nous n’utilisons pas toutes les ressources des serveurs mises à notre disposition.

Il faut donc que nous mettions en place un système de répartition de charge entre nos deux serveurs qui permettra de disposer de deux fois plus de capacité pour gérer notre service Asterisk qu’actuellement en exploitant les deux serveurs en même temps.

4.34.34.34.3 RRRRépartition de charge avec épartition de charge avec épartition de charge avec épartition de charge avec IPVSIPVSIPVSIPVS et et et et lllldirectorddirectorddirectorddirectord

4.3.14.3.14.3.14.3.1 IpvsIpvsIpvsIpvs

Ce paquet va gérer l’équilibrage de charge entre nos deux serveurs via la commande « ipvsadm ». Il redirige les paquets entrants vers d'autres serveurs en utilisant divers algorithmes (41) de répartition de charge.

IPVS propose 10 algorithmes de répartition dont les principaux sont :

• rr (Round-Robin) : les requêtes sont transmises à tour de rôle sur chaque noeud du cluster.

• wrr (Weighted Round Robin) : identique au précédent, mais peut gérer une pondération associée à chaque noeud, l'objectif étant de charger les machines proportionnellement à leur puissance.

• lc (Least Connection) : IPVS transmet la requête au serveur sur lequel il y a le moins de connexions actives.

• wlc (Weighted Least-Connection) : il agit comme lc, néanmoins on peut ajouter un « poid » à un serveur en fonction de sa puissance.

Pour des facilités de démonstration lors de nos analyses de trames, nous avons choisi d’utiliser l’algorithme de répartition rr (Round-Robin). En effet, cet algortihme transmettant les requêtes à chacun des serveurs à tour de rôle, il est plus facile d’en analyser les effets avec un analyseur de trame. Néanmoins, dans un contexte d’entreprise, l’algorithme lc ou wlc serait préférable car il va répartir les paquets en fonction de la charge du serveur.



4.3.1.14.3.1.14.3.1.14.3.1.1 ConfigurationConfigurationConfigurationConfiguration

La configuration d’IPVS s’effectue à l’aide de ligne de commande. Nous allons tout d’abord voir comment créer un service de redirection des requêtes. Pour cela, nous utilisons la commande suivante :

ipvsadm -A -u 192.168.206.150:5060 -s rr

L’option –A indique que nous allons créer un service de redirection, le –u signale que ce service va utiliser le protocole UDP.

L’adresse IP qui suit est notre adresse IP virtuelle, nous indiquons donc que toutes les requêtes qui auront pour destination cette adresse IP virtuelle sur le port (42) 5060 qui est le port sip, seront redirigées par IPVS.

Enfin, l’option –s indique l’algorithme de répartition que nous allons utiliser, ici rr pour Round-Robin. Puis nous utilisons les lignes de commande suivantes pour indiquer à quel serveur physique il doit rediriger les requêtes :

ipvsadm -a -u 192.168.206.150:5060 -r 192.168.206.130:5060 –g

ipvsadm -a -u 192.168.206.150:5060 -r 192.168.206.131:5060 –g

Les lignes de commande ci-dessus sont sensiblement les deux mêmes. Nous retrouvons ici différentes options.

Le –a indique au service IPVS que nous ajoutons un serveur, l’option –u signale

comme précédemment que le protocole utilisé va être de l’udp.

Nous signalons ensuite l’adresse IP virtuelle et le port à partir desquels seront redirigées les requêtes. L’option –r permet d’ajouter un serveur « réel » à la règle. Nous indiquons ensuite l’adresse IP d’un de nos deux serveurs physiques et le port SIP.

Enfin, nous terminons par l’option –g qui indique que le serveur que nous avons

ajouté, répondra directement au client sans passer par le répartiteur de charge pour ne pas surcharger le trafic réseau.

Au vu de ces nouvelles règles, lorsque nos clients enverront une requête SIP à notre IP

virtuelle, le répartiteur enverra ces requêtes à tour de rôle sur chacun de nos serveurs. Ces derniers répondront alors directement au client, sans repasser par le répartiteur de charge. Pour vérifier notre table de répartition, nous utilisons la commande :

ipvsadm –L



4.3.1.24.3.1.24.3.1.24.3.1.2 SSSSchéma explicatif chéma explicatif chéma explicatif chéma explicatif

Le schèma ci-dessous illustre la répartition à l’aide de l’algorithme Round-Robin que nous avons mis en place.

Figure 9 : Schéma explicatif de la répartition de charge

Pour simplifier le schéma et sa compréhension, nous ne prenons que deux postes clients. On peut donc voir que lorsque le client 1 émet une trame en premier, le serveur Asterisk-1, qui est également le répartiteur de charge, la redirige sur lui-même et envoie un accusé de réception au client 1 pour lui signaler qu’il a bien reçu sa trame.

La deuxième requête qu’il reçoit est émise par le client 2. En respectant son

algorithme de répartition Round-Robin, il transfert cette deuxième requête au serveur Asterisk-2. Ce dernier répond directement au client 2, sans passer par le répartiteur de charge.

Notre répartiteur de charge est donc mis en place et permet d’exploiter au mieux les capacités de nos deux serveurs Asterisk. Néanmoins, si le service Asterisk sur l’un de nos deux serveurs devait ne plus fonctionner, notre répartiteur ne s’en rendrait pas compte et continuerait d’envoyer les requêtes aux deux. Nous devons donc gérer cette situation en ajoutant un paquet supplémentaire qui va surveiller le service Asterisk et indiquer à IPVS si ce-dernier ne fonctionne plus.



4.3.24.3.24.3.24.3.2 Ldirectord Ldirectord Ldirectord Ldirectord Pour éviter à l'équilibreur de charge d'aiguiller des requêtes vers un nœud (un serveur)

défaillant, nous utilisons le paquet “ldirectord”. Ecrit en Perl, ce programme a pour rôle la surveillance applicative des noeuds et modifie, en temps réel, les règles d'équilibrage de charge.

En effet, si le service Asterisk du serveur 1 ne tourne plus, ldirectord va modifier la

table de répartition d’IPVS et indiquer à ce dernier qu’il doit rediriger toutes les requêtes SIP vers le serveur 2. Pour cela, nous effaçons la configuration faite statiquement dans IPVS.

4.3.2.14.3.2.14.3.2.14.3.2.1 ConfigurationConfigurationConfigurationConfiguration La configuration de ldirectord est identique sur les deux serveurs. Nous devons avant

tout créer le fichier ldirectord.cf à l'emplacement /etc/ha.d/. Voici la configuration de ce fichier :

checktimeout=10 checkinterval=10 emailalert="root@localdomain" emailalertfreq=0 quiescent=no virtual=192.168.206.150:5060

real=192.168.206.130:5060 gate real=192.168.206.131:5060 gate checktype=negotiate service=sip checkport=5060 login="121" passwd="212" scheduler=rr protocol=udp

checktimeout=10 indique le temps d’attente d’une réponse du serveur avant que le programme ne le déclare "mort". checkinterval=10 indique le temps écoulé entre deux tests effectués par ldirectord pour vérifier qu’Asterisk fonctionne correctement sur les deux serveurs. emailalert="root@localdomain" définit l’adresse mail sur laquelle envoyer les alertes. emailalertfreq=0 définit la fréquence des alertes. Le « 0 » indique ici que nous souhaitons n’avoir qu’une seule alerte par problème afin d’éviter de surcharger notre boite mail. quiescent=no indique que nous souhaitons supprimer le serveur « mort » de la table ipvsadm pour que celui–ci ne lui envoie plus de requête



virtual=192.168.206.150:5060 indique l’adresse IP virtuelle du cluster et du port dont il faut répartir la charge. real=192.168.206.130:5060 gate / real=192.168.206.131:5060 gate définissent les serveurs réels vers lesquels la charge doit être redirigée. Le mot-clé « gate » signifie que les serveurs doivent répondre directement au client. checktype=negotiate définit la méthode à utiliser afin de tester le bon fonctionnement de notre service Asterisk. service=sip indique que nous utilisons le service SIP. checkport=5060 indique que la surveillance doit se faire sur le port 5060.

login="121" / passwd="212" définit les informations d’identification à utiliser afin de vérifier le bon fonctionnement du protocole. scheduler=rr signifie que nous utilisons l’algorithme de répartition Round-Robin. protocol=udp indique que les requêtes SIP envoyées s’appuieront sur de l’UDP.

Nous avons donc actuellement un répartiteur de charge géré par ldirectord sur chaque serveur Asterisk. Néanmoins, nous n’avons pas besoin que ce service soit actif sur les deux serveurs, un seul nous suffit pour gérer la répartition et l’autre peut donc rester passif sur le deuxième serveur dans l’éventualité ou le premier « tomberait ».

Nous devons donc enlever ldirectord du démarrage automatique (43) sur les deux

serveurs pour le faire interagir avec Heartbeat. En effet, Heartbeat gérant le fail-over, il est actif sur le premier serveur et est en

« stand-bye » sur le deuxième serveur.

Il ne deviendra actif sur le deuxième serveur que si le premier « tombe ». Nous lui indiquons donc qu’en cas de panne du premier serveur, il récupérera l’adresse IP virtuelle et démarrera le service ldirectord.

Pour enlevez ldirectord du démarrage "standalone" nous tapons la commande suivante :

update-rc.d -f ldirectord remove.

Nous devons également indiquer à Heartbeat qu’il doit lancer le service ldirectord. Pour cela nous nous rendons dans le fichier /etc/ha.d/ et nous ajoutons le service ldirectord à la ligne suivante :

asterisk-1 IPaddr2::192.168.206.150/24/eth0 ldirectord

Nous avons donc une architecture qui gère la répartition de la charge et surveille le bon fonctionnement du service Asterisk pour pouvoir modifier ces règles de répartitions en cas de défaillance de ce dernier.



4.3.2.24.3.2.24.3.2.24.3.2.2 Schéma explicatifSchéma explicatifSchéma explicatifSchéma explicatif Le schéma ci-dessous illustre le fonctionnement de ldirectord et d’IPVS.

Figure 10 : Schéma de la plateforme avec IPVS et ldirectord

Dans la configuration ci-dessus, nous avons un échange qui fonctionne correctement avec de la répartition de charge entre nos deux serveurs. On obtient la table de répartition suivante :

Figure 11 : Table de répartition de charge normal On constate dans cette table que l’on retrouve bien la règle de redirection que l’on a définit dans ldirectord avec les serveurs qui lui sont associés. On peut aussi voir le nombre de connexions établit sur chaque serveur.



Le schéma ci-dessous illustre ce qu’il se passe si le service Asterisk ne fonctionne plus sur le serveur Asterisk-1.

Figure 12 : Schéma de la plateforme lorsque Asterisk tombe en panne

Le programme ldirectord met alors la table du répartiteur de charge IPVS à jour, et lui indique qu’il doit rediriger toutes les requêtes sur le deuxième serveur. On obtient alors la table suivante :

Figure 13 : Table de répartition de charge modifié par ldirectord

Enfin, si le service Heartbeat tombe sur le serveur 1, il est remonté sur le serveur 2 et lance le ldirectord en même temps. De ce fait, le deuxième serveur récupère à la fois l’adresse IP virtuelle et le répartiteur de charge.

Figure 14 : Schéma de la plateforme lorsque Heartbeat tombe en panne



4.44.44.44.4 Scripts d’amélioration Scripts d’amélioration Scripts d’amélioration Scripts d’amélioration

Notre plateforme est en place, néanmoins nous avons pu soulever différents problèmes. En effet, notre adresse IP virtuelle qui gère notre cluster, n’est physiquement présente

que sur le serveur 1, cela ne nous posait aucun problème lors de notre première configuration avec une architecture ne disposant que d’un serveur actif et un passif, néanmoins, avec la répartition de la charge, les deux serveurs sont amenés à répondre à des requêtes ayant pour destination cette adresse IP virtuelle.

Nous devons donc créer un script qui permettra au deuxième serveur de répondre aux requêtes qui lui sont transmises et qui ont pour destinataire l’adresse IP virtuelle. Nous avons nommé ce script ipv.sh.

Nous avons également constaté que notre service de redondance n’était pas optimisé

pour le service ldirectord. En effet, lorsque le serveur 1 ou le service Heartbeat tombe, celui-ci lance correctement le service ldirectord en récupérant l’adresse IP virtuelle grâce aux paramètres que nous lui avons indiqué précédemment. Néanmoins, si le service ldirectord ne fonctionne plus sur le serveur 1 mais que Heartbeat lui continue de tourner, il ne récupère pas l’adresse IP virtuelle sur le serveur 2 et ne lance donc pas le service ldirectord. Notre second script, que nous avons nommé test_ldirectord.sh consistera donc à « tuer » le service Heartbeat sur le premier serveur si ldirectord venait à ne plus fonctionner sur ce dernier. De cette façon, le serveur 2 récupérera l’adresse IP virtuelle et Heartbeat lancera le service ldirectord sur ce dernier.

4.54.54.54.5 Ipv.shIpv.shIpv.shIpv.sh

L’objectif est de permettre au serveur 2 de répondre aux requêtes ayant pour destinataire l’adresse IP virtuelle, nous devons nous assurer qu’il ne réponde qu’aux requêtes SIP à destination du service Asterisk, et pas aux requêtes ARP qui sont émises par les clients.

En effet, seul le serveur 1, qui dispose physiquement de l’adresse IP virtuelle, doit répondre aux requêtes ARP des clients car c’est lui qui redirige les requêtes sur les différents Asterisk. Nous allons donc indiquer au serveur qu’il ne doit répondre aux requêtes ARP que si celle-ci sont à destination de son adresse IP primaire (celle qui est paramétrée physiquement sur sa carte réseau).

Nous créons le script ipv.sh à l’emplacement /etc/init.d et nous le configurons comme suit : #!/bin/bash echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce ip addr add 192.168.206.150/32 dev lo



echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore permet de signaler que les requêtes ARP ayant pour destination une adresse IP qui ne serait pas primaire au système seront ignorées. echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce permet de définir que si l’adresse IP de destination de la requête ARP est une adresse primaire du système, ce dernier va lui répondre.

ip addr add 192.168.206.150/32 dev lo indique l’adresse IP virtuelle comme étant présente sur l’interface de loopback du système mais non primaire afin que les requêtes SIP à destination de l’adresse virtuelle puissent être acceptées par ce serveur. Puis nous exécutons la commande suivante pour indiquer au système qu’il doit lancer le script à chaque démarrage de l’ordinateur :

update-rc.d ipv.sh defaults

4.64.64.64.6 test_ldirectord.shtest_ldirectord.shtest_ldirectord.shtest_ldirectord.sh

Afin d’avoir une parfaite redondance de l’ensemble de nos services, nous allons créer un script qui permettra de gérer les éventuels disfonctionnements du service ldirectord. Ce script a pour but de tester le fonctionnement du service ldirectord, et dans l’éventualité ou ce dernier tomberait, de stopper le service Heartbeat sur le serveur 1 afin qu’il se lance sur le serveur 2 et qu’il démarre ldirectord sur ce dernier.

Sur le serveur Asterisk-1 : #!/bin/bash i=0 while [ $i == 0 ]; do testldirectord=ìpvsadm -L | wc -l` testheartbeat=`/etc/init.d/heartbeat status | grep running | wc -l` if [ "$testldirectord" -le 4 ]; then if [ "$testheartbeat" == 1 ]; then /etc/init.d/ldirectord restart testldirectord=ìpvsadm -L | wc -l` if [ "$testldirectord" -eq 4 ]; then /etc/init.d/heartbeat stop fi fi fi sleep 10 done

Dans ce script, nous créons une boucle qui va tourner à l’infini car il s’effectue tant que la valeur i est égale à 0, or sur la ligne précédente nous avons initialisé la valeur de i à 0. Ce script va donc s’exécuter à l’infini toutes les 10 secondes grâce à la ligne sleep 10 qui lui indique qu’il doit « dormir » pendant 10 secondes avant de se relancer.



La ligne suivante nous permet de tester si le service ldirectord tourne.

testldirectord=ìpvsadm -L | wc -l`

On affecte ici une variable $testldirectord dans laquelle on effectue la commande ipvsadm -L | wc -l. Cette commande nous permet de voir si la table de répartition est remplie ou non et donc de connaitre ainsi le statut du service. La commande va compter le nombre de lignes du tableau et va renvoyer le nombre « 5 » ou « 6 » si le service fonctionne correctement, sinon on obtiendra la valeur « 1, 2, 3 ou 4 ».

La ligne suivante permet d’afficher l’état du status de Heartbeat, de chercher la chaîne de caractère « running » et de compter le nombre de lignes renvoyées (« 0 » ou « 1 »).

testheartbeat=`/etc/init.d/heartbeat status | grep running | wc -l` Nous testons ensuite les valeurs retournées par les variables :

if [ "$testldirectord" -le 4 ]; then if [ "$testheartbeat" == 1 ]; then /etc/init.d/ldirectord restart testldirectord=ìpvsadm -L | wc -l` if [ "$testldirectord" -eq 4 ]; then /etc/init.d/heartbeat stop fi fi fi

Ces test nous permettent de tenter un redémarrage du service ldirectord ou un arrêt de Heartbeat selon les valeurs renvoyées par les différents tests. En effet, dans le cas où le service ldirectord s’est arrêté (valeur 3) ou ne redirige plus aucune requêtes (valeur 4) mais que le service Heartbeat est toujours en marche (valeur 1), le fail-over n’aura pas lieu. On exécute donc un redémarrage du service ldirectord et on relance un test pour savoir si cela a fonctionné. Dans le cas contraire, on arrête le service Heartbeat.

Sur le serveur Asterisk 2, nous créons également un script sur le même modèle qui nous permet de tester le bon fonctionnement du service Heartbeat. #!/bin/bash i=0 while [ $i == 0 ]; do testheartbeat=`/etc/init.d/heartbeat status | grep running | wc -l` if [ "$testheartbeat" == 0 ]; then /etc/init.d/heartbeat restart fi sleep 10 done

Notre architecture est donc entièrement redondante et effectue du load-balancing entre nos deux serveurs. Nous disposons donc d’une solution de clustering assurant la haute disponibilité de notre service Asterisk.



4.74.74.74.7 SchSchSchSchééééma ma ma ma d’une plateforme optimiséed’une plateforme optimiséed’une plateforme optimiséed’une plateforme optimisée

Notre solution nous permet d’assurer une continuité de service correcte face à d’éventuelles pannes ou erreurs système.

Néanmoins, nous effectuons ici toutes nos opérations sur nos propres serveurs Asterisk ce qui peut engendrer une surcharge sur ceux-ci dans le cas d’une forte activité. Pour des raisons matérielles évoquées précédemment, nous n’avons pu exploiter d’autres postes afin de réaliser une structure au sein de laquelle les serveurs Asterisk ne géreraient pas d’autres services que la téléphonie IP. En effet, une solution optimale inclurait deux serveurs supplémentaires qui géreraient la répartition de charge et qui seraient tous deux reliés via un Heartbeat pour gérer le fail-over.

Le schéma ci-dessous illustre cette solution :

Figure 15 : Schéma de notre plateforme finale



5555 TestTestTestTest de notre solutionde notre solutionde notre solutionde notre solution

Maintenant que notre configuration est terminée sur chacun de nos deux serveurs ainsi que sur nos deux clients, il faut mettre en place un protocole de test de notre solution afin de la valider. Au niveau de notre script ipv.sh : Pour que notre solution fonctionne correctement, il faut avant tout que le second serveur prenne bien son adresse IP « cachée » et ses paramètres ARP au démarrage de la machine. Pour vérifier cela, on redémarre notre machine et on effectue la commande suivante : « ip addr show » Voici le résultat de cette commande :

Figure 17 : Adresse virtuelle « cachée » sur Asterisk-2 Au niveau de la redondance des services : Nous avons déjà vu précédemment que lorsque le service Asterisk tombe en panne sur l’un des serveurs, le programme ldirectord le détecte et modifie la table de répartition en conséquence. Nous ne reverrons donc pas ce point ici. Nous allons désormais nous intéresser au programme Heartbeat. Pour vérifier son bon fonctionnement, nous allons le stopper sur le serveur Asterisk-1 et constater ce qu’il se passe. On observe ainsi que le serveur Asterisk-2 récupère bien l’adresse IP virtuelle :

Figure 17 : Adresse IP virtuelle récupérée sur Asterisk-2



On constate aussi que ce même serveur a bien démarré son service de répartition ldirectord :

Figure 18 : Statut du service ldirectord Lorsque Heartbeat redémarre sur le serveur Asterisk-1, le serveur Asterisk-2 stoppe son service de répartition et « rend » l’adresse IP virtuelle au serveur 1. Regardons maintenant ce qu’il se passe au niveau de notre système lorsque nous arrêtons ldirectord sur la machine Asterisk-1. Ce test nous permettra de valider le bon fonctionnement de notre script test_ldirectord.sh. Voici ce que l’on peut constater :

Figure 19 : Relance de ldirectord par le script test_ldirectord.sh On remarque que le script a détecté l’arrêt de ldirectord et a réussi à le relancer avec succès. Notre service est donc toujours disponible. Dans le cas où le service se relance correctement, on analyse le tableau de répartition de charge afin de savoir s’il contient des données. S’il n’en contient pas, cela signifie qu’il ne peut donc pas répartir correctement la charge. On obtient alors les lignes suivantes :

Figure 20 : Arrêt de Heartbeat par le script test_ldirectord.sh Au niveau de la répartition de charge : Afin de constater les effets de la répartition de charge, nous utiliserons en plus de la commande « ipvsadm –L » le logiciel d’analyse de trame Wireshark que nous avons précédemment installé sur nos postes clients. Ainsi on constate qu’à chaque nouvelle tentative de connexion d’un client, le répartiteur de charge redirige les requêtes de connexion SIP à tour de rôle sur chacun des deux serveurs Asterisk.



On constate ici qu’une connexion est déjà active sur le serveur Asterisk-2.

Figure 21 : Table de répartition Connectons-nous maintenant avec un deuxième client X-Lite afin d’analyser les trames envoyées. On obtient la capture suivante :

Figure 22 : Capture de trames SIP On constate que le client envoie une trame REGISTER à l’adresse IP virtuelle 192.168.206.150 mais que c’est notre serveur Asterisk-1 qui lui répond avec une trame TRYING puis une trame OK pour valider son enregistrement auprès de lui. On constate désormais que deux connexions sont actives et chacune sur un serveur différent.

Figure 23 : Nouvelle table de répartition On peut donc affirmer maintenant que nous disposons d’une infrastructure hautement-disponible qui permet en plus de répartir équitablement les différents clients sur nos différents serveurs Asterisk.



ConclusionConclusionConclusionConclusion

Au cours de notre licence professionnelle, nous avions pour projet de réaliser une interconnexion de serveurs Asterisk sous la tutelle de Mr Toussaint. Ce projet avait une durée de 150 heures. Nous avons dans un premier temps effectué une approche théorique de la téléphonie sur IP et du logiciel Asterisk afin de nous familiariser avec le protocole SIP. Grâce à cette approche, nous avons pu réaliser une plateforme de test comportant deux serveurs Asterisk auxquels des clients SIP pouvaient se connecter afin d’établir des communications entre eux. Ensuite, nous avons effectué des recherches sur les différentes technologies qui nous permettraient de réaliser une redondance du service Asterisk et d’instaurer de la haute disponibilité ainsi que de la répartition de charge. Nous avons cherché à établir une architecture fiable afin de pouvoir l’adapter dans un contexte d’entreprise avec une utilisation intense et continue du service de téléphonie sur IP. Enfin, après avoir déployé notre solution, nous avons effectué différents test qui nous ont permis de valider sa fiabilité. Nous n’avons néanmoins pas eu l’occasion de tester les effets lié à une surcharge d’un serveur avec l’outil SIPp que nous n’avons pas eu le temps de nous approprier dans les délais imposés par le projet. Nous avons pu rencontrer des difficultés lors du respect des délais. En effet, nos recherches sur les technologies à utiliser et leur appropriation nous a pris plus de temps que nous n’en avions prévue. De plus, nous avons pu constater différentes incohérences dans notre architecture ainsi que des erreurs de configuration qu’il nous a fallu résoudre. Néanmoins, nous avons pu réaliser ce projet dans le temps imparti et nous sommes actuellement capables de déployer une solution de haute disponibilité du système Asterisk totalement redondante. Cette solution pourrait être exploitée dans le monde de l’entreprise car elle est fiable et peut parer à de nombreuses pannes.



English SummaryEnglish SummaryEnglish SummaryEnglish Summary As part of our degree in Network Engineering and Telecommunications, we had to realise a project. Our project team was composed by two students : Laura Redondo and Maxime Boscia. We chose the Voice Over IP project so our tutor was the Headmaster of the Department, Mr. Joël Toussaint. Our project involved installing and using an Open Source software called Asterisk to study how it reacts in case of fault and what solutions could we bring at this matter. Asterisk is often used in companies to save money because it permits to cross free internal phone calls. Furthermore, it provides numerous services as conference for example. In first, we had to search information about Asterisk and VoIP on the web and in books because this project requires specifical knowledges. Then we installed Asterisk on two computers which had a Debian operating system. We had configure several basic options of Asterisk and we had test if it worked with software telephony client, also called softphone. Then, we connected two Asterisk servers with redundancy and load-balancing to permit a high availability of Asterisk services. It means we had a continuity of the telephony services if one of the Asterisk servers break down. The main difficulty was to search an learn information about technologies of redundancy and load-balancing that we had never seen. Furthermore, we wasted a lot of time at the begining of the project because we didn’t succeed to install the operating system on the computers which be at our disposition. But we resolve all of these problems. This project was the opportunity for us to deepen our knowledge in VoIP. In fact, we began to study Asterisk software during Mr. Toussaint’s lessons but it was more non-specialized. This project allowed us to improve our technicals skills on Linux operating system and redundancy technologies.



GlossaireGlossaireGlossaireGlossaire 1 - téléphonie sur IP : Service de communication vocale utilisant le protocole de télécommunications créé pour Internet (IP). La voix est numérisée et envoyée dans le réseau Internet comme n'importe quelle donnée. 2 - protocole TCP/IP : Suite de protocoles. Le sigle TCP/IP signifie «Transmission Control Protocol/Internet Protocol». TCP/IP représente d'une certaine façon l'ensemble des règles de communication sur internet et se base sur la notion adressage IP, c'est-à-dire le fait de fournir une adresse IP à chaque machine du réseau afin de pouvoir acheminer des paquets de données 3 - signal analogique : Un signal analogique est un signal continu. Il change de valeur en passant par toutes les valeurs intermédiaires. L’inconvénient majeur d’un signal analogique réside dans le fait qu’il est techniquement difficile de détecter et encore moins corriger les détériorations du signal dû soit à l’affaiblissement de celui-ci, soit à des parasites. 4 - numériser : La transformation d'un signal analogique en signal numériqueLa numérisation comporte deux activités parallèles : l'échantillonnage (en anglais sampling) et la quantification. L'échantillonnage consiste à prélever périodiquement des échantillons d'un signal analogique. La quantification consiste à affecter une valeur numérique à chaque échantillon prélevé. 5 - codecs : Algorithme permettant de compresser et de décompresser des fichiers audio et vidéo sans perdre une quantité considérable d'informations. 6 - compresser : Procédé permettant de réduire le volume (en bits) ou le débit (en bit/s) des données numérisées (parole, images, textes, ...). 7 - commutation de circuits : Un réseau est constitué de plusieurs noeuds interconnectés par des lignes de communication. Il existe plusieurs méthodes permettant de transférer une données d'un noeud émetteur à un noeud dit récepteur. La commutation de circuits consiste à mettre en relation successivement les différents noeuds intermédiaires afin de propager la donnée du noeud émetteur au noeud récepteur. Dans ce type de scénario, la ligne de communication peut être assimilé à un tuyau dédié à la communication. 8 - commutation de paquets : Elle consiste à segmenter l'information en paquets de données, transmis indépendamment par les nœuds intermédiaires et ré assemblés au niveau du destinataire. 9 - UDP : Protocole de transport de l'information non orienté connexion de la couche transport du modèle TCP/IP. Ce protocole est très simple étant donné qu'il ne fournit pas de contrôle d'erreurs (il n'est pas orienté connexion...). 10 - TCP : Protocole de Contrôle de Transmission) est un des principaux protocoles de la couche transport du modèle TCP/IP. Il permet, au niveau des applications, de gérer les données en provenance (ou à destination) de la couche inférieure du modèle (c'est-à-dire le protocole IP).



11 - datagrammes : Les datagrammes sont une représentation structurée de l'ensemble des données constituant un paquet d'information pour un protocole donné. Par exemple, on rencontre très fréquemment des datagrammes pour les paquets du protocole IP, protocole de couche internet du modèle TCP/IP 12 - WAN : Réseau informatique couvrant une grande zone géographique, typiquement à l'échelle d'un pays, d'un continent, voire de la planète entière. Le plus grand WAN est le réseau Internet. 13 - réseau RTC : Le réseau téléphonique commuté (ou RTC) est le réseau du téléphone (fixe et mobile), dans lequel un poste d'abonné est relié à un central téléphonique par une paire de fils alimentée en batterie centrale (la boucle locale). Les centraux sont eux-mêmes reliés entre eux par des liens offrant un débit de 2 Mb/s : ce sont les Blocs Primaires Numériques (BPN). 14 - Linux, BSD et Mac OS X : Différents systèmes d'exploitations basés sur le noyau Unix. 15 - client : Poste informatique utilisateur dans un réseau qui attend et reçoit les réponses du serveur. 16 - serveur : Poste informatique maître d'un réseau, il peut avoir différents rôles, serveur d'applications, de fichiers, de terminaux, ou encore de messagerie électronique. Les clients se connectent au serveur pour obtenir différentes informations de configuration ou encore de données. Un serveur est généralement capable de servir plusieurs clients simultanément. 17 - paquet (linux) : Une distribution Linux est un ensemble cohérent de logiciels rassemblant un système d'exploitation composé d'un noyau Linux et de logiciels supplémentaires - le plus souvent libres, ces logiciels sont alors appelé paquets et téléchargeable gratuitement sur Internet. 18 - communauté Linuxienne : communauté des utilisateurs utilisant les systèmes Unix. 19 - PCI : Le Peripheral Component Interconnect (PCI) est un standard de bus local (interne) permettant de connecter des cartes d'extension sur la carte mère d'un ordinateur. 20 - commutateur PABX : Équipement situé en un noeud de réseau pour assurer des connexions appel par appel entre voies de transmission selon les besoins des usagers. 21 - Debian : Distribution Linux très stable utilisé dans notre cas pour installer nos serveurs. 22 - Red Hat : Distribution Linux très utilisée pour les serveurs. 23 - IETF : Littéralement traduit de l'anglais en « Détachement d'ingénierie d'Internet » est un groupe informel, international, ouvert à tout individu, qui participe à l'élaboration de standards pour Internet. L'IETF produit la plupart des nouveaux standards d'Internet. 24 - sessions multimédia : Une session est l'exécution d'un programme pour un utilisateur donné. L'exécution du programme est alors paramétrée par les informations du profil de l'utilisateur (ses caractéristiques, ses préférences, l'historique de ses interactions avec le programme, etc.). Multimédia ici défini le transport de la voix.



25 - protocole ouvert : Format de données interopérable et dont les spécifications techniques sont publiques et sans restriction d’accès ni de mise en œuvre, par opposition à un format fermé. 26 - http : Protocole utilisé pour la création de page web. Il se compose de ligne de commande visibles par l'utilisateur. 27 - analyseur de trames : une trame est un bloc d'information véhiculé au travers d'un support physique (cuivre, fibre optique, etc.), elle se situe au niveau 2 du modèle OSI. Un analyseur de trame permet de capturer l'ensemble des trames qui circules sur un média afin d'en faire une analyse. 28 - haute disponibilité : On appelle haute disponibilité le fait de rendre un service disponible 24h/24h pour ses utilisateurs en parant aux éventuelles pannes du système. 29 - softphones : Type de logiciel utilisé pour faire de la téléphonie par Internet depuis un ordinateur plutôt qu'un téléphone. Les communications peuvent se faire au moyen d'un microphone et d'un casque ou de haut-parleurs reliés à la carte son, mais il existe aussi un type de périphérique dédié à cette tâche, semblable à un téléphone et se branchant sur un port USB. Les interfaces des softphones sont souvent intuitives et de la forme d'un téléphone. Les fonctionnalités des softphones sont les mêmes que celles des téléphones classiques. 30 - VMWare : Nom d'une gamme de logiciels de virtualisation. La virtualisation est l'ensemble des techniques matérielles et/ou logicielles qui permettent de faire fonctionner sur une seule machine plusieurs systèmes d'exploitation et/ou plusieurs applications, séparément les uns des autres, comme s'ils fonctionnaient sur des machines physiques distinctes. Les outils de virtualisation servent à faire fonctionner ce qu'on appelle communément des serveurs privés virtuels (Virtual Private Servers ou VPS) ou encore environnements virtuels (Virtual Environments ou VE). 31 - load balancing : La répartition de charge (load-balancing en Anglais, littéralement équilibrage de charge) est une technique utilisée en informatique pour distribuer un travail entre plusieurs processus, ordinateurs, disques ou autres ressources. C'est une forme d'optimisation. Les avantages sont nombreux : * Augmentation de la qualité des services. * Amélioration des temps de réponse des services. * Capacité à pallier la défaillance d'une ou de plusieurs machines. * Possibilité d'ajouter des serveurs sans interruption de service. 32 - trunk : Aggrégation de plusieurs lignes de télécommunication ou de VLAN afin d'augmanter la bande passante. 33 - Fail Over : Le basculement (en anglais, fail-over qui se traduit par passer outre à la panne) est la capacité d'un équipement à basculer automatiquement vers un chemin réseau alternatif ou en veille. 34 - chemin réseau : Chemin composé d'équipements réseaux possédant des adresses IP et dont le but est de permettre à un poste d'atteindre son correspondant.



35 - routeur : Un routeur est un élément intermédiaire dans un réseau informatique assurant le routage des paquets. Son rôle est de faire transiter des paquets d'une interface réseau vers une autre, selon un ensemble de règles formant la table de routage. 36 - pare-feu : Un pare-feu est un élément du réseau informatique, logiciel et/ou matériel, qui a pour fonction de faire respecter la politique de sécurité du réseau, celle-ci définissant quels sont les types de communication autorisés ou interdits. 37 - FreeBSD, OpenBSD, Solaris : Distributions basées sur le noyaux Unix. 38 - clustering : Technologie qui permet de créer une grappe de serveurs.On parle de grappe de serveurs ou de ferme de calcul (cluster en anglais) pour désigner des techniques consistant à regrouper plusieurs ordinateurs indépendants (appelés nœuds, node en anglais) pour permettre une gestion globale et dépasser les limitations d'un ordinateur pour : * augmenter la disponibilité * faciliter la montée en charge * permettre une répartition de la charge * faciliter la gestion des ressources (CPU, mémoire, disques, bande passante réseau) 39 - scripts d'initialisations : Programme informatique qui ne nécessite pas de compilation avant d'être exécuté. Pour fonctionner, les scripts doivent être interprétés par un programme ou un serveur dédié au langage dans lequel ils ont été écrits. 40 - broadcasts : Le broadcast est un terme anglais définissant une diffusion de données à un ensemble de machines connectées à un réseau. En français on utilise le terme diffusion. 41 - algorithme : Un algorithme est un ensemble de prescriptions et de règles qui définissent « ce qu’il faut faire » et « dans quel ordre » pour résoudre un problème (ou une classe de problème). 42 - port : Correspondant à la couche de transport du modèle OSI, la notion de port logiciel permet, sur un ordinateur donné, de distinguer différents interlocuteurs. Ces interlocuteurs sont des programmes informatiques qui, selon les cas, écoutent ou émettent des informations sur ces ports. Un port est distingué par son numéro. 43 - démarrage automatique : repertoire dans lequel on indique des programmes qui démarreront au lancement du système.



BibliographieBibliographieBibliographieBibliographie Livres :

• Jim Van Meggelen, Leif Madsen & Jared Smith Asterisk The Future of Telephony 2nd Edition, Edition ‘O’REILLY’, année 2007

• Sébastien Déon

VoIP et ToIP Asterisk : La téléphonie sur IP, Edition ‘ENI’, année 2007 Revues :

• Haute-disponibilité et équilibrage de charge Edition ‘Linux Magazine/France n° 97’, année 2007

Site internet :

• Asterisk : The Open Source PBX & Telephony Platform, www.asterisk.org

• Asterisk Guru – Tutorials and howto’s for the asterisk PBX, www.asteriskguru.com

• Community Asterisk France, www.asterisk-france.net

• Linux Virtual Server, www.linuxvirtualserver.org

• VoIP-Info.org : A reference guide to all things VOIP, www.VoIP-info.org



AnnexesAnnexesAnnexesAnnexes A1 Fichier sip.conf 51 A2 Fichier extensions.conf du serveur Asterisk-1 52 A3 Fichier extensions.conf du serveur Asterisk-2 52 A4 Fichier iax.conf du serveur Asterisk-1 52 A5 Fichier iax.conf du serveur Asterisk-2 52 A6 Fichier voicemail.conf 53 A7 Fichier authkeys 53 A8 Fichier haresources 53 A9 Fichier ha.cf 53 A10 Fichier ldirectord.cf 54 A11 Fichier ipv.sh 54 A12 Fichier test_ldirectord.sh du serveur Asterisk-1 55 A13 Fichier test_ldirectord.sh du serveur Asterisk-2 55 A14 Compte-rendu de la réunion de lancement de projet 56 A145 Compte-rendu de la réunion de fin de projet 58



A1. Fichier sip.conf [121] type=friend username=121 secret=212 host=dynamic callerid="Maxime" context=projet mailbox=121@projet [131] type=friend username=131 secret=313 host=dynamic callerid="Laura" context=projet mailbox=131@projet [141] type=friend username=141 secret=414 host=dynamic callerid="Fabien" context=projet mailbox=141@projet [151] type=friend username=151 secret=515 host=dynamic callerid="Mathieu" context=projet mailbox=151@projet



A2. Fichier extensions.conf du serveur Asterisk-1 [projet] exten => _1XX,1,Dial(SIP/${EXTEN}) exten => _1XX,2,Dial(IAX2/paris/${EXTEN}) exten => _1XX,3,Voicemail(${EXTEN}@projet) exten => _1XX,4,HangUp exten => 888,1,VoicemailMain(@projet) A3. Fichier extensions.conf du serveur Asterisk-2 [projet] exten => _1XX,1,Dial(SIP/${EXTEN}) exten => _1XX,2,Dial(IAX2/clermont/${EXTEN}) exten => _1XX,3,Voicemail(${EXTEN}@projet) exten => _1XX,4,HangUp exten => 888,1,VoicemailMain(@projet) A4. Fichier iax.conf du serveur Asterisk-1 [paris] type=friend host=192.168.206.131 context=projet qualify=yes trunk=yes A5. Fichier iax.conf du serveur Asterisk-2 [clermont] type=friend host=192.168.206.132 context=projet qualify=yes trunk=yes



A6. Fichier voicemail.conf [projet] 121 => 212,Maxime,121@localhost,,|attach=yes|review=yes 131 => 313,Laura,131@localhost,,|attach=yes|review=yes 141 => 414,Fabien,141@localhost,,|attach=yes|review=yes 151 => 515,Mathieu,151@localhost,,|attach=yes|review=yes A7. Fichier authkeys auth 1 1 sha1 password A8. Fichier haresources asterisk-1 IPaddr2::192.168.206.150/24/eth0 ldirectord A9. Fichier ha.cf logfacility daemon node asterisk-1 node asterisk-2 keepalive 1 deadtime 10 bcast eth0 auto_failback on



A10. Fichier ldirectord.cf checktimeout=10 checkinterval=10 autoreload=yes emailalert="root@localdomain" emailalertfreq=0 quiescent=no virtual=192.168.206.150:5060 real=192.168.206.130:5060 gate real=192.168.206.131:5060 gate checktype=negotiate service=sip checkport=5060 login="121" passwd="212" scheduler=rr protocol=udp

Attention : exécuter la commande « update-rc.d ldirectord remove » afin de ne plus le lancer en mode « standalone » au démarrage de l’ordinateur. Celui-ci sera géré par Heartbeat. A11. Fichier ipv.sh #!/bin/bash echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce IP addr add 192.168.206.150/32 dev lo

Attention : exécuter la commande « update-rc.d ipv.sh defaults » afin de le lancer automatiquement au démarrage de l’ordinateur.



A12. Fichier test_ldirectord.sh du serveur Asterisk-1 #!/bin/bash i=0 while [ $i == 0 ]; do testldirectord=ìpvsadm -L | wc -l` testheartbeat=`/etc/init.d/heartbeat status | grep running | wc -l` if [ "$testldirectord" -le 4 ]; then if [ "$testheartbeat" == 1 ]; then /etc/init.d/ldirectord restart testldirectord=ìpvsadm -L | wc -l` if [ "$testldirectord" -eq 4 ]; then /etc/init.d/heartbeat stop fi fi fi sleep 10 done

Attention : exécuter la commande « update-rc.d test_ldirectord.sh defaults » afin de le lancer automatiquement au démarrage de l’ordinateur. A13. Fichier test_ldirectord.sh du serveur Asterisk-2 #!/bin/bash i=0 while [ $i == 0 ]; do testheartbeat=`/etc/init.d/heartbeat status | grep running | wc -l` if [ "$testheartbeat" == 0 ]; then /etc/init.d/heartbeat restart fi sleep 10 done

Attention : exécuter la commande « update-rc.d test_ldirectord.sh defaults » afin de le lancer automatiquement au démarrage de l’ordinateur.



Aujourd’hui, les technologies de l’information et de la communication prennent de

plus en plus d’ampleur au sein de toutes les entreprises, de la plus petite à la plus grande. C’est dans ce contexte de travail que nous avons réalisé ce projet de haute

disponibilité du service de téléphonie, service essentiel au bon fonctionnement de chaque entreprise.

En effet, vous verrez dans ce rapport comment mettre en place de manière très efficace

un service de téléphonie sur IP, Open Source et entièrement gratuit, avec le logiciel Asterisk. Vous trouverez aussi toutes les étapes conduisant à assurer la continuité de service 24h/24h et 7j/7j grâce à des logiciels déjà existant ou à des petits scripts a écrire vous-même.

Documents

Projet tuteuré Redondance de serveur Redondance de …€¦ · sur IP avec le logiciel sur IP avec le logiciel AsteAsteAsterisk risk ... 3.2 Installation et configuration d’Asterisk