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 Aste Aste Aste Asterisk risk risk risk
Tuteur IUT : Joël TOUSSAINT
Chargé du projet : Laura REDONDO / Maxime BOSCIA
Remerciements Remerciements Remerciements Remerciements
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.
Sommaire Sommaire Sommaire Sommaire
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
Introduction Introduction Introduction Introduction
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 projet Gestion de projet Gestion de projet Gestion 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.1 1.1 1.1
1.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.2 1.2 1.2
1.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.3 1.3 1.3
1.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 TOUSSAINTNous 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 serveurOu ?
Au centre de formation (IUT), dans les salles informatiques réservéesLe 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éphoniquessimultané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 permettraCahier 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 serveurNombre Maximum
F3
Fonction Redondance du service téléphoniqueDeux 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 LinuxDebian
2 clients X-Lite sur Windows XP
0%
C7
Contrainte Lieu Centre de formation Salles réservées 0%1.4 1.4 1.4
1.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.5 1.5 1.5
1.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.6 1.6 1.6
1.6 Diagramme de GANTT Diagramme de GANTT Diagramme de GANTT Diagramme 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.7 1.7 1.7
1.7 Bilan personnel Bilan personnel Bilan personnel Bilan 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.
2 22
2 La La La La VoIP VoIP VoIP et VoIP et et et Asterisk Asterisk Asterisk Asterisk
2.1 2.1 2.1
2.1 Définition de la Définition de la Définition de la Définition de la VoIP VoIP VoIP VoIP
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.1 2.1.1 2.1.1
2.1.1 FFFFonctionnement onctionnement onctionnement onctionnement de la de la de la de la VoIP VoIP VoIP VoIP
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.2 2.1.2 2.1.2
2.1.2 Avantages Avantages Avantages Avantages
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.3 2.1.3 2.1.3
2.1.3 Inconvénients Inconvénients Inconvénients Inconvé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.2 2.2 2.2
2.2 Présentation d’ Présentation d’ Présentation d’Asterisk Présentation d’ Asterisk Asterisk Asterisk
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.1 2.2.1 2.2.1
2.2.1 Avantages Avantages Avantages Avantages
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.2 2.2.2 2.2.2
2.2.2 Inconvénients Inconvénients Inconvénients Inconvé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.3 2.3 2.3
2.3 SIP SIP SIP SIP
2.3.1 2.3.1 2.3.1
2.3.1 Présentation Présentation Présentation Pré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.2 2.3.2 2.3.2
2.3.2 Fonctionnement Fonctionnement Fonctionnement Fonctionnement
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 VoIP VoIP VoIP VoIP
3.1 3.1 3.1
3.1 Configuration matérielle Configuration matérielle Configuration matérielle Configuration 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.2 3.2 3.2
3.2 Installation et configuration d’ Installation et configuration d’ Installation et configuration d’Asterisk Installation et configuration d’ Asterisk Asterisk Asterisk
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.1 3.2.1 3.2.1
3.2.1 Fichier sip.conf Fichier sip.conf Fichier sip.conf Fichier 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.2 3.2.2 3.2.2
3.2.2 Fichier extensions.conf Fichier extensions.conf Fichier extensions.conf Fichier 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.3 3.2.3 3.2.3
3.2.3 Fichier voicemail.conf Fichier voicemail.conf Fichier voicemail.conf Fichier 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.4 3.2.4 3.2.4
3.2.4 Fichier Fichier Fichier Fichier iax iax iax iax.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.3 3.3 3.3
3.3 Mise en place des clients X Mise en place des clients X Mise en place des clients X Mise en place des clients X----Lite Lite Lite Lite
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.1 4.1 4.1
4.1 Présentation Présentation Présentation Pré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.2 4.2 4.2
4.2 Le Fail Le Fail Le Fail----Over avec Heartbeat Le Fail Over avec Heartbeat Over avec Heartbeat Over avec Heartbeat
4.2.1 4.2.1 4.2.1
4.2.1 Présentation Présentation Présentation Pré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
4.2.2 4.2.2 4.2.2
4.2.2 Configuration du cluster Heartbeat Configuration du cluster Heartbeat Configuration du cluster Heartbeat Configuration 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.3 4.2.3 4.2.3
4.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.3 4.3 4.3
4.3 R R R Répartition de charge avec épartition de charge avec épartition de charge avec IPVS épartition de charge avec IPVS IPVS IPVS et et et et lllldirectord directord directord directord
4.3.1 4.3.1 4.3.1
4.3.1 Ipvs Ipvs Ipvs Ipvs
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.1 4.3.1.1 4.3.1.1
4.3.1.1 Configuration Configuration Configuration Configuration
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.2 4.3.1.2 4.3.1.2
4.3.1.2 S SS Sché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.2 4.3.2 4.3.2
4.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.1 4.3.2.1 4.3.2.1
4.3.2.1 Configuration Configuration Configuration Configuration
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
4.3.2.2 4.3.2.2 4.3.2.2
4.3.2.2 Schéma explicatif Schéma explicatif Schéma explicatif Sché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.
4.4 4.4 4.4
4.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.5 4.5 4.5
4.5 Ipv.sh Ipv.sh Ipv.sh Ipv.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.6 4.6 4.6
4.6 test_ldirectord.sh test_ldirectord.sh test_ldirectord.sh test_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=`ipvsadm -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=`ipvsadm -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
