MEMOIRE DE FIN DE FORMATION POUR L’OBTENTION DU DIPLOME DE MASTER FILIÈRE: MASTER EN TECHNOLOGIE DE L’INFORMATIQUE ET DE LA COMMUNICATION (MTIC) THÈME : ÉTUDE ET DÉPLOIEMENT D’UNE SOLUTION VoIP SUR UN CLUSTER KUBERNETES DE HAUTE DISPONIBILITÉ Superviseur: Dr Joël T. HOUNSOU UNIVERSITÉ D’ ABOMEY- CALAVI [email protected] Soutenu par: Farid Abdel Adediran YESSOUFOU Membres de jury: Président de jury: Jules DEGILA Examinatrice: Pélagie HOUNGUE Encadreur: Joel T. HOUNSOU Année Académique 2019-2020 Résumé Les organisations à la recherche du renforcement de leurs compétences, font face à une problématique d’amélioration de leurs plateformes technologiques qui nécessite la mobilisation de ressources importantes. Par conséquent, ils doivent sans cesse envisager des mécanismes d’optimisation de leurs infrastructures opérationnelles. A cet effet, il est nécessaire de garantir la disponibilité et la non dégradation des services fournis par cette plateforme durant les périodes de grandes charges de travail. Ce type de scénario est parfaitement appliqué dans le domaine des technologies de la VoIP (Voice over Internet Protocol) où les utilisateurs génèrent des charges assez lourdes sur les points critiques de l’infrastructure durant leurs processus d’interaction. Nos travaux portent donc sur une solution de haute disponibilité dans le but de maintenir la continuité d’une opération au niveau des environnements de communication basé sur le protocole SIP (Session Initiation Protocol) aux heures de charges de travail importante. Le protocole SIP fournit la base pour construire des réseaux convergents qui supportent une intégration transparente avec les réseaux vocaux traditionnels, les e-mails, le World Wide Web et les technologies de dernière génération telles que la messagerie instantanée et les réseaux mobiles à partir de la 3G et plus. L’utilisation permanente des services convergents par les entreprises accroît ainsi la nécessité d’un environnement technologique fiable et continuellement opérationnels, disponible pour l’utilisation des services proposés aux clients. Dans ce document, nous proposons une solution de haute disponibilité avec des outils open source, dans le but de maintenir la continuité du fonctionnement des environnements de communication à forte charge sur le protocole SIP. Nous avons également comparé notre solution avec d’autres scénarios VoIP classiques tout en montrant les avantages d’une architecture de haute disponibilité et de tolérance aux pannes pour les entreprises. Mot-Clés— Cluster, Haute Disponibilité, Répartiteur de charge, VoIP, SIP, Asterisk 2 Abstract Organizations seeking to strengthen their skills are facing the problem of improving their technological platforms that requires the mobilization of significant resources. Therefore, they must constantly consider mechanisms to optimise their operational infrastructure. To this end, it is necessary to guarantee the availability and non-degradation of the services provided by this platform during periods of high workloads. This type of scenario is perfectly applied in the field of VoIP (Voice over Internet Protocol) technologies where users generate quite heavy loads on critical infrastructure points during their interaction processes. Our work therefore focuses on a high availability solution in order to maintain business continuity in communication environments based on SIP (Session Initiation Protocol) at times of heavy workloads. The SIP protocol provides the foundation for building converged networks that support seamless integration with traditional voice networks, email, World Wide Web, and latest generation technologies such as instant messaging and mobile networks from 3G and above. The constant use of convergent services by enterprises thus increases the need for a reliable and continuously operational technological environment, available for the use of services offered to customers. In this document, we propose a high available solution with open source tools, in order to maintain the continuity of operation in communication environments with a high load on SIP protocol. We also compared our solution with other classic VoIP scenarios while demonstrating the benefits of a high- available and fault-tolerant architecture for enterprises. Keywords — Cluster, High Availabilisty, Load Sharer, VoIP, SIP, Asterisk 3 Sommaire Dédicaces iii Remerciements iv Liste des tableaux v Liste des figures vi Liste des sigles viii INTRODUCTION GENERALE 9 1 ÉTAT DE L’ART 12 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2 Haute disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.3 Présentation des techniques existantes . . . . . . . . . . . . . . . . . . . . . 14 1.4 Présentation des solutions existantes . . . . . . . . . . . . . . . . . . . . . . 27 1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2 PRÉSENTATION DE L’ARCHITECTURE PROPOSÉE ET CHOIX TECHNIQUES 33 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.2 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3 Présentation de l’architecture proposée . . . . . . . . . . . . . . . . . . . . . 44 2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3 DÉPLOIEMENT ET ÉVALUATION TECHNIQUE 46 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.2 Planification des déploiements . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.3 Exécution des déploiements et évaluation de l’architecture . . . . . . . . . . 47 3.4 Estimation financière pour le déploiement de l’infrastructure proposée . . 53 i 3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 CONCLUSION ET PERSPECTIVES 54 Annexes 57 Farid Abdel A. YESSOUFOU ii IMSP-UAC Dédicaces Je dédie ce travail à : ` A la mémoire de mon oncle SAKO Saibou et ma tante SYLLA Ramatoulaye, que DIEU garde leurs âmes dans son vaste paradis ; ` ` ` A mes chers parents, frères et soeurs ; A mes proches ; A tous mes ami(e)s. iii Remerciements Je tiens à remercier DIEU, qui m’a assisté et m’a permis de réaliser mes objectifs de cette année. Je remercie mon directeur de mémoire Dr Joel HOUNSOU, pour sa patience, sa disponibilité et surtout ses judicieux conseils, qui ont contribué à alimenter ma réflexion. Je remercie également toute l’équipe pédagogique de l’IMSP et les intervenants responsables de ma formation, pour avoir assuré la partie théorique de celle-ci. Je remercie aussi les membres de mon jury, le Dr Jules DEGILA et madame HOUNGUE Pelagie pour leurs critiques contribuant à l’amelioration du travail. Je tiens à témoigner toute ma reconnaissance aux personnes suivantes, pour leur aide dans la réalisation de ce mémoire : ` Jonas DJIVOEDO, Mario GOMEZ et Rosaire SENOU qui m’ont assisté pour le déploiement de la solution ; ` Sabine ZINSOU, qui m’a aidé et assisté dans la rédaction de ce document. Je voudrais exprimer ma reconnaissance envers les amis et collègues qui m’ont apporté leur soutien moral et intellectuel tout au long de ma démarche. Je remercie mes très chers parents, Wabi YESSOUFOU et Fatoumata SAKO, qui ont toujours été là pour moi. iv Liste des tableaux 1.1 Méthode de calcul de la disponibilité d’un SI [3] . . . . . . . . . . . . . . . 14 1.2 Récapitulatif des différents types de cluster . . . . . . . . . . . . . . . . . . 16 1.3 Récapitulatif des solutions actif-passif pour la haute disponibilité . . . . . 16 1.4 Récapitulatif des algorithmes d’équilibrage de charge . . . . . . . . . . . . 18 1.5 Récapitulatif des outils d’équilibrage de charge . . . . . . . . . . . . . . . . 18 1.6 Outils de virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.7 Récapitulatif des outils de conteneurisation . . . . . . . . . . . . . . . . . . 24 1.8 Tableau récapitulatifs des Techniques et outils existantes . . . . . . . . . . 32 2.1 Comparaison entre VMs et conteneurs . . . . . . . . . . . . . . . . . . . . . 33 2.2 Comparatifs des outils de conteneurisation . . . . . . . . . . . . . . . . . . 34 2.3 Comparatifs d’outils d’orchestration des conteneurs . . . . . . . . . . . . . 35 2.4 Récapitulatifs des solutions de volume persistant . . . . . . . . . . . . . . . 41 3.1 Planification des déploiements . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.2 Répartition des adresses IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.3 Évaluation de la performance d’une architecture VoIP de la troisième solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.4 Évaluation de la performance de notre Architecture HA . . . . . . . . . . . 52 3.5 Estimation financière pour le déploiement de l’architecture . . . . . . . . . 53 v Table des figures 1.1 Architecture globale d’un cluster computing . . . . . . . . . . . . . . . . . . 15 1.2 Exemple d’architecture d’un équilibrage de charge [6] . . . . . . . . . . . . 17 1.3 Exemple d’architecture de redondance d’un serveur . . . . . . . . . . . . . 19 1.4 Architecture d’une machine virtuelle [9] . . . . . . . . . . . . . . . . . . . . 20 1.5 Conteneurs physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.6 Architecture d’un conteneur . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.7 Architecture d’un NFV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1.8 Architecture Proposée 1 [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1.9 Architecture Proposée 2 [13] . . . . . . . . . . . . . . . . . . . . . . . . . . 28 1.10 Architecture proposée 3 [17] . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.11 Architecture proposée 4 [20] . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.1 Architecture globale d’un pod [22] . . . . . . . . . . . . . . . . . . . . . . . 37 2.2 Architecture globale d’un deployment [23] . . . . . . . . . . . . . . . . . . . 38 2.3 Architecture globale d’un service [23] . . . . . . . . . . . . . . . . . . . . . . 38 2.4 Architecture globale d’un ingress . . . . . . . . . . . . . . . . . . . . . . . . 39 2.5 Architecture etcd interne [24] . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.6 Architecture etcd externe [24] . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.7 Fonctionnement externe de la solution VNF-asterisk . . . . . . . . . . . . . 42 2.8 Architecture du pod asterisk-homer [25] . . . . . . . . . . . . . . . . . . . . 43 2.9 Présentation de l’architecture proposée . . . . . . . . . . . . . . . . . . . . . 44 3.1 Démarrage du service HeartBeat . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.2 Démarrage du service de Kubernetes au noeud Master1 . . . . . . . . . . . 48 3.3 Analyse du trafic SIP par homer . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.4 Démarrage de SiPp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.5 Démarrage du services Haproxy . . . . . . . . . . . . . . . . . . . . . . . . . 57 3.6 Demarrage des pods VNF-Asterisk . . . . . . . . . . . . . . . . . . . . . . . 57 vi 3.7 Configuration du déploiement des clients NFS sur kubernetes . . . . . . . . i 3.8 Visualisation des services de kubernetes . . . . . . . . . . . . . . . . . . . . i 3.9 Interface de notre controller API . . . . . . . . . . . . . . . . . . . . . . . . ii 3.10 Trunk entre deux pods asterisk . . . . . . . . . . . . . . . . . . . . . . . . . ii 3.11 Test d’appel entre deux pods . . . . . . . . . . . . . . . . . . . . . . . . . . . ii Farid Abdel A. YESSOUFOU vii IMSP-UAC Liste des sigles API Application Programming Interface ARP Address Resolution Protocol BSD Berkeley Software Distribution CPU Central Processing Unit DHCP Dynamic Host Configuration Protocol DNS Domaine Name Server ERP Enterprise Resource Planning ENUM E.164 Number to URI Mapping GPL General Public License HAD High Availability Daemon HSRP Hot Standby Router Protocol IAX Inter-Asterisk eXchange ICMP Internet Control Message Protocol IP Internet Protocol IPC InterProcess Communication IPVS Very Large Scale Integration ITSP Internet Telephony Service Provider LACP Link Aggregation Control Protocol MDT Mean Down Time MSTP Multiple Spanning Tree Protocol MTBF Mean Time Between Failures MTTF Mean Time To Failures MTTR Mean Time To Repair viii MUT Mean Up Time NFV Network Function Virtualization OS Operating System OSI Open Systems Interconnection RAM Random Access Memory RTP Real Time Protocol RTCP Real Time Control Protocol SPOF Single Point of Failure SRV Service Resource Record STP Spanning Tree Protocol TCP Transmission Control Protocol UDP User Datagram Protocol UTS Support Vector Machine VM Virtual Machines VNF Virtualized Network Function Farid Abdel A. YESSOUFOU ix IMSP-UAC INTRODUCTION Depuis des années, l’humanité à tout le temps évolué au rythme des technologies innovantes. L’essor des Nouvelles Technologies de l’Information et de la Communication permet indubitablement l’émergence des entreprises et des organismes. Motivées par leurs intérêts pour une utilisation efficace et efficiente des ressources, ces institutions investissent dans des mécanismes de communication innovants, afin d’établir les connexions entre les dispositifs d’échange d’informations. Généralement, ces technologies de communication suivent des schémas opérationnels bien réglementés qui définissent clairement les activités intermédiaires, les états, les processus et les protocoles de communication. Au delà de ces concepts, elles sont souvent amenées à adopter des technologies de pointe et des protocoles de communication pour une utilisation optimale de leurs capacités de communication. Par conséquent, les solutions de haute disponibilité sont essentielles pour ces entreprises dans le traitement de leurs données sensibles. Ces solutions assurent la continuité de l’activité dans les scénarios suivants : + + + + Crash matériel ; Erreurs logiques au niveau de la base de données ; Charges imprévues ; Effets externes (par exemple, feu, dégâts d’eau). Dans ce travail, nous proposons une solution VoIP basée sur le protocole SIP qui utilise des logiciels open source permettant la mise en place d’infrastructures de haute disponibilité. Pour valider la solution, nous soumettons notre modèle au phénomène de montée en charge dans une entreprise. Notre document se présente comme suit : + + Au chapitre I, nous amorcerons l’État de l’art ; Au chapitre II, nous proposerons une architecture de haute disponibilité pour la VoIP ; + Au chapitre III, nous présenterons le déploiement, les scénarios et l’analyse des tests ; + Puis nous achèverons par une conclusion. 9 Problématique Dans la conception d’une architecture de téléphonie IP, il existe certaines limites pour la fourniture d’un service de téléphonie efficace, notamment lorsque nous utilisons la plateforme dans des conditions où la charge de travail est très élevée. Cela peut amener les entreprises, dans l’optique d’améliorer la qualité de leurs services, à opter pour des solutions propriétaires qui dans de nombreux cas, représentent un lourd investissement. Un grand nombre de ces problèmes est dû au fait que certaines entreprises ne tiennent pas compte des besoins relatifs à l’environnement dans lequel le service sera fourni. Par conséquent, elles n’évaluent pas les solutions open source pour faire face à leurs limites, alors qu’on pourrait offrir des mécanismes pro-actifs de haute disponibilité en cas de dysfonctionnement de leurs systèmes. Le concept de haute disponibilité et de continuité dans les réseaux informatiques est une solution pour les environnements à charge de travail élevée. Souvent, c’est le coût très élevé des installations pour la mise en oeuvre des solutions prioritaires qui empêche les entreprises d’avoir accès à ce service de qualité. C’est ce qui nous conduit à proposer une architecture de haute disponibilité grâce à l’utilisation d’outils open source. Notre solution considère que les caractéristiques particulières de chaque logiciel peuvent être surmontées en faisant un couplage avec d’autres outils pour offrir un service de qualité, c’est-à-dire en utilisant le dicton "L’union fait la force". Objectifs de l’étude L’utilisation des outils de technologies de l’information et de la communication est désormais une nécessité aux entreprises et aux organismes. Chaque panne ou interruption de la plateforme informatique a un impact significatif et néfaste sur la productivité de l’entreprise. La mise en place d’une infrastructure de haute disponibilité est nécessaire pour pallier un problème. L’objectif principal de notre étude est donc de concevoir et de déployer une architecture de haute disponibilité avec des outils open source pour la VoIP. Méthodologie de travail Toute recherche scientifique nécessite l’application de méthodes et techniques pour aboutir à des résultats exacts et efficaces. Notre travail démarre par des recherches sur la haute disponibilité dans un système informatique, les techniques existantes en matière de haute disponibilité et les nouvelles technologies qui peuvent être utilisées. Grâce à la documentation disponible, nous allons procéder à l’analyse des solutions et à la conception de notre architecture pour enfin finir avec l’implémentation de notre Farid Abdel A. YESSOUFOU 10 IMSP-UAC architecture grâce à l’utilisation des machines virtuelles pour les scénarios de simulation. Farid Abdel A. YESSOUFOU 11 IMSP-UAC Chapitre 1 ÉTAT DE L’ART 1.1 Introduction Dans ce chapitre, nous présentons la haute disponibilité du système informatique dans son ensemble. Par la suite nous présentons les techniques et outils de haute disponibilité les plus utilisés. Pour finir nous montrons les approches de solutions et recherches effectuées sur la haute disponibilité au niveau de la VoIP. 1.2 Haute disponibilité 1.2.1 Définition La disponibilité est un enjeu essentiel des infrastructures informatique. L’indisponibilité des services informatiques peut devenir critique, et peut avoir un effet désastreux sur l’entreprise. La haute disponibilité consiste à mettre en place une infrastructure spécialisée, par exemple en appliquant les principes de la redondance et de la réduction des charges, ainsi que des processus permettant la réduction des erreurs et l’accélération de la reprise d’activité, afin de limiter au maximum les indisponibilités[1]. Par conséquent, pour qu’un système offre la haute disponibilité, il faut prendre en compte tous les points les plus importants que doit avoir un système. 1.2.2 Critères DICP-R Le critère DICP-R permet de classifier la sécurité d’un système d’information[2]. + D : Disponibilité Garantir le fonctionnement et la disponibilité du système à tout moment. 12 + I : Intégrité S’assurer qu’une information ne peut être modifiée que par des personnes autorisées et selon un procédé défini. + C : Confidentialité Garantir que l’information ne peut être accessible qu’à ceux qui sont autorisés à le faire. + P : Preuve Garantir la non répudiation pour tout contrôle, c’est à dire l’impossibilité de nier avoir effectué une action. + R : Réglementation Définit les règles que le système doit respecter. 1.2.3 Fiabilité versus disponibilité La fiabilité est un attribut permettant de mesurer la continuité d’un service en l’absence de panne. Les constructeurs fournissent généralement une estimation statistique de cette valeur pour leurs équipements : On parle alors de MTBF(Mean Time Between Failures). Un MTBF fort donne une indication précieuse sur la capacité d’un composant à ne pas tomber en panne trop souvent. Dans le cas d’un système complexe (que l’on peut décomposer en un certain nombre de composants matériels ou logiciels), on va alors parler de MTTF(Mean Time to Failures), soit le temps moyen passé jusqu’à l’arrêt de service consécutif à la panne d’un composant ou d’un logiciel. La disponibilité en ce qui la concerne, est plus difficile à calculer car elle englobe la capacité du système complexe à réagir correctement en cas de panne pour redémarrer le service le plus rapidement possible. Il est alors nécessaire de quantifier l’intervalle moyen de temps ou le service est indisponible avant son rétablissement : on utilise l’acronyme MTTR (Mean Time to Repair) pour représenter cette valeur. La formule qui permet de calculer le taux de disponibilité relative à un système est la suivante : Disponibilité = MT T F MT T F = MT T F + MT T R MT BF Ainsi, un système qui aspire à une forte disponibilité se doit d’avoir soit un MTTF fort et un MTTR faible[3]. Une autre méthode, consiste à mesurer la période de temps ou la plateforme n’est plus accessible pour évaluer le niveau de disponibilité. Cette méthode est très utilisée même si elle ne tient pas compte de la fréquence des pannes mais plutôt de leur durée. Le calcul se fait généralement sur une année. Plus le pourcentage de disponibilité du service est fort, Farid Abdel A. YESSOUFOU 13 IMSP-UAC plus nous pouvons parler de haute disponibilité. Il est assez facile de quantifier le niveau de haute disponibilité d’un service à partir de la durée d’arrêt cumulée en utilisant le principe normalisé des "9" (en dessous de 3 neuf, on ne parle plus de haute disponibilité mais simplement de disponibilité)[1] : Table 1.1 – Méthode de calcul de la disponibilité d’un SI [3] 1.3 Présentation des techniques existantes La présentation des techniques existantes est nécessaire pour exposer les études faites et les solutions apportées en matière de VoIP pour régler les problèmes de défaillance et de disponibilité. Il existe de nombreuses techniques permettant de rendre l’organisation plus performante pour éviter les pannes et atteindre ainsi les objectifs fixés. Nous présentons ici les techniques les plus utilisées dans le domaine de la VoIP. 1.3.1 Clustering 1.3.1.1 Définition Un cluster (grappe) est un regroupement de plusieurs machines indépendantes appelées noeuds en une seule et même machine dans le but de partager des ressources de façon transparente pour le client. Ainsi, si un ou plusieurs noeuds tombent en panne, le service n’est pas interrompu et assure la tolérance aux pannes. Un cluster est : + un ensemble d’ordinateurs connectés en réseau dans le but de répartir des tâches sur ses machines. + un ensemble d’ordinateurs connectés en réseau et capables de traiter rapidement une tâche. Farid Abdel A. YESSOUFOU 14 IMSP-UAC Figure 1.1 – Architecture globale d’un cluster computing 1.3.1.2 + Architecture en Cluster Actif - Passif Dans un schéma actif-passif, l’un des noeuds traite les requêtes reçues par le service critique (donc considéré comme le noeud actif), tandis que l’autre noeud surveille le noeud actif et est prêt à prendre le relais dès que le noeud actif est déconnecté ou incapable de servir ; + Actif - Actif Dans un schéma actif-actif, les deux noeuds fournissent activement et simultanément des services critiques. L’un des principaux objectifs d’un cluster actif-actif est de réaliser l’équilibrage de charge, c’est-à-dire de répartir la charge de travail. En cas de défaillance de l’un des noeuds, l’autre noeud sera responsable de la fourniture de tous les services critiques. 1.3.1.3 Types de Cluster Nous distinguons quatre principaux types de cluster regroupés dans le tableau suivant : Farid Abdel A. YESSOUFOU 15 IMSP-UAC Table 1.2 – Récapitulatif des différents types de cluster 1.3.1.4 Outils Le tableau 1.3 présente les solutions utilisées dans un schéma actif-passif pour assurer la tolérance aux pannes. Table 1.3 – Récapitulatif des solutions actif-passif pour la haute disponibilité Dans un schéma actif-actif nous parlons de répartition de charge que nous présenterons dans la sous-section suivante. Farid Abdel A. YESSOUFOU 16 IMSP-UAC 1.3.2 Cluster d’équilibrage de charge 1.3.2.1 Définitions Considérons deux serveurs ayant des caractéristiques similaires qui sont configurés comme des centraux téléphoniques, l’un d’entre eux actif et l’autre passif. L’idée de base est que le serveur passif prendra le relais lorsque le serveur actif sera confronté à une panne. Maintenant, si le serveur actif devait tomber en panne en raison d’un très haut niveau de services il est fort probable que le même sort arrive à la machine de relais, puisqu’il s’agit de machines ayant des caractéristiques similaires. Pour résoudre ce genre de problèmes, il est conseillé de répartir la charge entre plusieurs serveurs. L’équilibrage de charge consiste à distribuer la charge entre les machines. Il reçoit tout ce qui est dirigé vers les divers serveurs et redirige le trafic vers l’un des serveurs qu’il considère approprié, par le biais de différents techniques et mécanismes pour équilibrer la charge de travail. 1.3.2.2 Architectures d’un cluster d’équilibrage de charge L’architecture d’un équilibrage de charge peut être conçue de nombreuses manières en fonction de nos besoins, mais elle se présente globalement comme suit : Figure 1.2 – Exemple d’architecture d’un équilibrage de charge [6] Dans cet exemple, la requête du client SIP passe d’abord par le serveur kamailio-loadbalancer qui va à son tour relayer la requête vers un noeud apte à traiter la requête. Pour réaliser cela, plusieurs algorithmes d’équilibrage de charges ont été développés. Farid Abdel A. YESSOUFOU 17 IMSP-UAC 1.3.2.3 Algorithmes d’équilibrage de charge Table 1.4 – Récapitulatif des algorithmes d’équilibrage de charge 1.3.2.4 Outils Plusieurs solutions sont disponibles pour assurer l’équilibrage de charge. Table 1.5 – Récapitulatif des outils d’équilibrage de charge Farid Abdel A. YESSOUFOU 18 IMSP-UAC 1.3.3 Redondance La redondance est une technique qui consiste à multiplier les éléments afin d’assurer les fonctions en cas de défaillance de l’élément principal. On trouve la redondance à tous les niveaux du modèle OSI (Open Systems Interconnexion). Pour le faire, on prend en compte les paramètres suivants : + + + Répartition efficace de la charge ; Synchronisation des données ; Gestion efficace des états de session. Figure 1.3 – Exemple d’architecture de redondance d’un serveur 1.3.3.1 Virtualisation 1.3.3.2 Définition La virtualisation se définit comme l’ensemble des techniques matérielles et/ou logicielles qui permettent de faire fonctionner sur une seule machine, plusieurs systèmes d’exploitation[7]. La virtualisation des serveurs permet une plus grande modularité dans la répartition des charges et la reconfiguration des serveurs en cas d’évolution ou de défaillance momentanée. Elle est réalisée avec l’aide des hyperviseurs. On en distingue deux types : l’hyperviseur de type 1 ou bare-metal qui est un système qui s’installe directement sur la couche matérielle du serveur et l’hyperviseur de type 2 qui est un logiciel qui s’installe et s’exécute sur un système d’exploitation déjà en place. Ces derniers permettent respectivement la virtualisation complète et la para-virtualisation. Plusieurs domaines sont impactés dont le stockage, le traitement et le réseau. Farid Abdel A. YESSOUFOU 19 IMSP-UAC Figure 1.4 – Architecture d’une machine virtuelle [9] 1.3.3.3 + Avantages de la virtualisation Les machines virtuelles restent simples à manier. Il est possible par exemple de basculer une VM (machine virtuel) d’un lieu à l’autre, voire même de sauvegarder et de dupliquer une VM à volonté sans aucun impact visible pour les utilisateurs ; + La virtualisation réduit les dépenses en abaissant le besoin de systèmes matériels physiques. Elle permet ainsi de réduire la quantité d’équipements nécessaires et les coûts de maintenance d’alimentation et de refroidissement des composants ; + + L’installation, les tests et les développements n’endommagent pas le système hôte ; Les machines virtuelles apportent également une aisance à l’administration car un matériel virtuel n’est pas sujet aux défaillances. Les administrateurs profitent des environnements virtuels pour faciliter les sauvegardes, la reprise après catastrophe[8] ; + Elle participe à la protection de l’environnement. 1.3.3.4 + Inconvénients de la virtualisation Le fait d’accéder aux ressources de façon virtuelle affaiblit les performances, cela est dû au passage par une couche d’abstraction matérielle qui malheureusement doit faire des interprétations entre le matériel en place et celui simulé dans la machine virtuelle ; Farid Abdel A. YESSOUFOU 20 IMSP-UAC + + + + + Elle limite considérablement la portabilité des applications ; Une machine virtuelle prend du temps à démarrer ; Une machine virtuelle réserve les ressources (CPU/RAM) sur le système hôte ; Elle limite le nombre de VMs qu’un serveur peut héberger ; Consomme à lui tout seul énormément de ressources. Le déploiement d’applications sur la base d’une image de VM est lourd, on se retrouve donc avec une technologie très utile, malléable et économique pour les professionnels, mais qui possède malheureusement aussi son lot d’inconvénients. C’est dans l’optique de pallier ce problème que la conteneurisation a vu le jour. 1.3.3.5 Outils Plusieurs solutions sont utilisées de nos jours pour faire de la virtualisation. Table 1.6 – Outils de virtualisation Farid Abdel A. YESSOUFOU 21 IMSP-UAC 1.3.3.6 La Conteneurisation Figure 1.5 – Conteneurs physiques La conteneurisation est un processus ou un ensemble de processus isolés du reste du système, tout en étant légers. Il permet ainsi de faire de la virtualisation légère, c’est-àdire qu’il ne virtualise pas les ressources, il ne crée qu’une isolation des processus. Le conteneur partage donc les ressources avec le système hôte. Tous les fichiers nécessaires à leur exécution sont fournis par une image distincte, ce qui signifie que les conteneurs sont portables et fonctionnent de la même manière dans les environnements de développement, de test et de production. L’idée générale est que nous n’avons plus besoin d’avoir l’OS (Operating System), les librairies, tout ce qui faisait que les VMs était lourds à gérer et mettait du temps à démarrer en s’appuyant sur l’OS qui est en dessous[9]. Le schéma 1.6 représente l’architecture d’un conteneur. Figure 1.6 – Architecture d’un conteneur [9] Farid Abdel A. YESSOUFOU 22 IMSP-UAC 1.3.3.7 Avantages de la conteneurisation La conteneurisation présente de nombreux avantages : + Flexibilité Toute application peut être transformée en conteneur ; + Légerté Contrairement à la virtualisation classique, un conteneur exploite et partage le noyau du système d’exploitation de l’hôte, ce qui le rend très efficace en terme d’utilisation des ressources du système ; + Portabilité Il est possible de créer, déployer et démarrer des conteneurs sur son ordinateur, celui de ses clients ou un serveur distant ; + Auto-suffisance L’installation et la désinstallation de conteneurs ne dépend pas des autres conteneurs installés. Ce qui permet de mettre à jour ou remplacer un conteneur sans modifier les autres ; + Scalabilité Dupliquer un conteneur est extrêmement simple, ce qui permet de réaliser de la scalabilité horizontale aisément[10]. 1.3.3.8 Inconvénients de la conteneurisation Malgré les multiples avantages des conteneurs, cette solution présente encore quelques inconvénients : + Problème de dépendance Les conteneurs linux ne peuvent pas encore être exécutés sur les versions actuelles de Windows Server contrairement aux VMs classique qui sont autonomes ; + Sécurité Un bug, un virus ou une intrusion peut porter atteinte à une VM sans se propager contrairement aux conteneurs, qui sont plus vulnérables, car ils partagent un noyau, des composants systèmes et leur fonctionnement exige déjà un niveau d’autorisation élevé (généralement l’accès root dans les environnements Linux) ; + Outils de gestion limités Les types d’outils nécessaires pour surveiller et gérer les conteneurs sont encore rares dans le secteur. Farid Abdel A. YESSOUFOU 23 IMSP-UAC 1.3.3.9 Outils Plusieurs solutions sont utilisées de nos jours : Table 1.7 – Récapitulatif des outils de conteneurisation 1.3.3.10 Orchestration de Conteneur La conteneurisation permet de facilement créer, déployer et exécuter des conteneurs mais lorsque nous commençons par l’utiliser en production, de nombreuses interrogations surgissent. + + + Comment gérer la montée en charge ? Comment gérer de grosses quantités de conteneurs ? Comment gérer et planifier efficacement le cycle de vie des conteneurs ? D’ou le besoin d’orchestration des conteneurs. En effet, les outils d’orchestration de conteneur permettent de guider le déploiement des conteneurs, d’automatiser les mises à jour, la surveillance d’état et les procédures de basculement. Trois outils d’orchestration existent, à savoir : — DockerSwarm — Kubernetes — Apache MESOS 1.3.4 NFV 1.3.4.1 Définition NFV (Network Function Virtualization) est une technologie qui offre la possibilité de déployer aisément les fonctions réseau. Il permet de rendre disponible ces fonctions en les virtualisant dans des applications logicielles pouvant être exécutées sur des serveurs, Farid Abdel A. YESSOUFOU 24 IMSP-UAC machines virtuelles ou conteneurs s’exécutant sur ces serveurs. C’est un moyen de réduire les coûts et d’accélérer le déploiement des services pour les opérateurs réseau en dissociant des fonctions telles que le pare-feu ou le chiffrement de tout matériel dédié et en les déplaçant vers des serveurs virtuels. La NFV réduit le besoin de matériel dédié pour déployer et gérer les réseaux en transférant les fonctions réseau vers des logiciels s’exécutant sur du matériel standard et pouvant être gérés à partir de n’importe quel endroit sur le réseau de l’opérateur. Figure 1.7 – Architecture d’un NFV 1.3.4.2 Avantages de la technologie NFV La séparation des fonctions réseau du matériel apporte de nombreux avantages pour l’opérateur réseau, parmi lesquels : — Réduction de l’espace nécessaire aux équipements matériels du réseau ; — Réduction de la consommation électrique du réseau ; — Réduction des coûts de maintenance du réseau ; — Simplification des mises à niveau du réseau ; — Allongement du cycle de vie des équipements matériels du réseau ; — Réduction de la maintenance et des coûts matériels ; — Tolérance aux pannes. Farid Abdel A. YESSOUFOU 25 IMSP-UAC 1.3.4.3 Inconvenients de la technologie NFV Si le concept et les avantages de la NFV sont relativement simples, sa mise en oeuvre peut s’avérer plus complexe. Cela est dû au fait que, pour profiter pleinement des avantages de la NFV, un certain niveau de coopération et d’interaction est nécessaire entre divers fournisseurs de solutions réseau et différents opérateurs de réseau[10]. Farid Abdel A. YESSOUFOU 26 IMSP-UAC 1.4 Présentation des solutions existantes Certaines études et solutions relatives à la mise en place de mécanisme de contingence et d’évolutivité dans les systèmes de téléphonie IP ont été faites. Tout au long de cette section, nous allons décrire et analyser ces solutions, tout en relevant leurs avantages et insuffisances. 1.4.1 Première approche de solution Cette étude de Georgios Kambourakis, Dimitris Geneiatakis, Stefanos Gritzalis et Costas Lambrinoudakis publiée en 2010 propose la création d’une solution de basculement transparente pour les serveurs proxy SIP et RTP(Real Time Protocol)[11]. L’objectif est d’accroître la disponibilité, la stabilité et l’évolutivité des systèmes multimédias basés sur SIP en utilisant des mécanismes de basculement actif-passif avec des adresses IP virtuelles, tant pour SIP que pour RTP. Figure 1.8 – Architecture Proposée 1 [11] 1.4.1.1 Schéma d’équilibrage de charge Pour la réalisation de ce travail, un mécanisme d’équilibrage de charge DNS basé sur des registres SRV(Service Resource Record) a été utilisé. Le module d’équilibrage de charge est responsable de demander dans un intervalle de temps statique le nombre de serveurs SIP disponibles pour le serveur DNS. Le client SIP, lorsqu’il effectue un appel, atteindra d’abord l’équilibreur qui à son tour le serveur DNS (Domain Name Server) Farid Abdel A. YESSOUFOU 27 IMSP-UAC pour transmettre la demande au serveur SIP. Ceci n’est toutefois requis que pour certains messages SIP. Une fois qu’un client SIP a établi la connexion, il n’est plus nécessaire de repasser par l’équilibreur de charge. 1.4.1.2 Insuffisances de la solution L’inconvénient majeur de cette solution est que les auteurs ont écrit leur propre démon HAD (High Availability Daemon), et n’ont pas utilisé un logiciel bien connu et développé par la communauté comme HeartBeat, Keepalived ou MON. Cette solution est sujette aux erreurs, puisque leur logiciel n’a été exposé qu’à une très faible communauté.[12] 1.4.2 Deuxième approche de solution Figure 1.9 – Architecture Proposée 2 [13] L’architecture proposée par Pal, Gadde et Latchman [13] comporte : + + Deux ou plusieurs serveurs virtuels avec Kamailio ; Deux ou plusieurs serveurs virtuels avec FreeSWITCH[14]. Les appels sont acheminés des clients vers les serveurs Kamailio en utilisant un ENUM (E.164 Number to URI Mapping) distribué basé sur le DNS avec des paramètres de priorité[13]. Si à n’importe quel moment un serveur virtuel Kamailio particulier est en panne ou à forte charge, les appels seront redirigés vers un autre serveur Kamailio. Si aucun de ces serveurs n’est actif, l’appel se fera redirigé directement vers n’importe lequel des FreeSWITCHs qui sont responsable de la messagerie vocale. Farid Abdel A. YESSOUFOU 28 IMSP-UAC Pour assurer la redondance matérielle, les auteurs proposent Ultra Monkey [14], qui utilise Linux Virtual Server, pour la création d’une haute disponibilité dans les services réseau. Il utilise le logiciel HeartBeat pour surveiller si les deux serveurs fonctionnent correctement ou non. HeartBeat utilise un plugin appelé IPFail qui permet de déterminer les serveurs qui fonctionnent ou pas. 1.4.2.1 + + Inconvénients de la solution : L’equilibreur de charge UltraMonkey ne permet pas de maintenir l’état du SIP ; UltraMonkey est obsolète et d’une performance inférieure à Kamailio [12]. 1.4.3 Troisième approche de solution L’architecture de cette solution est illustrée sur la figure 1.10 : Figure 1.10 – Architecture proposée 3 [17] Cette solution a été présentée par Doug Smith [16] à la conférence Astricon 2015[18]. Nous avons un ITSP qui communique avec une IP virtuel. Cette IP virtuelle est gérée par Keepalived, et est partagée virtuellement entre deux conteneurs Kamailio. Chaque conteneur Kamailio utilise le répartiteur Kamailio pour choisir le conteneur asterisk disponible pour recevoir l’appel. L’avantage majeur de cette solution est que l’on peut créé plus de conteneurs VoIP pendant les heures de pointe ce qui permet d’économiser en ressources et de maintenir le service. L’objectif est d’avoir un équilibreur de charge qui peut gérer dynamiquement la charge entre plusieurs conteneurs VoIP et maintenir la communication sur chaque conteneur afin que dans l’hypothèse où un conteneur donné tombe en panne, l’on perdra le minimum de communications[17]. Farid Abdel A. YESSOUFOU 29 IMSP-UAC 1.4.3.1 Insuffisance de la solution Avec la configuration actuelle, le système sera toujours opérationnel et nous pourrons envoyer des appels de manière fiable vers les conteneurs Asterisk. Cependant, les appels dans un état intermédiaire pourraient se retrouver dans un autre état intermédiaire. C’est à dire : — Si un appel se situe entre INVITE et le média émetteur, il se peut que l’appel n’arrive jamais ; — Si un appel est envoyé aux médias, il y a une chance qu’aucune des parties n’entende le BYE. L’auteur n’a pas utilisé un orchestrateur pour la gestion des conteneurs qui est un choix pour gérer l’évolution, la mise à l’échelle et la planification dynamique des conteneurs. 1.4.4 Quatrième approche de solution Ce projet est une amélioration des travaux de Doug Smith présenté cette fois ci à l’astricon 2018 [18]. Associé à Leif Madsen, l’objectif est de créer une Virtual Network Function Asterisk. Ce VNF n’est pas destiné à être déployé en production, mais fourni plutôt un ensemble d’exemples sur la façon dont nons pouvons procéder pour en créer un. Ce projet de recherche offre les avantages suivantes : + + + Haute disponibilité ; Scalabilité Horizontale et verticale ; Optimisation des ressources. Figure 1.11 – Architecture proposée 4 [20] L’avantage de cette solution est l’utilisation de Kubernetes comme orchestrateur. Kubernetes gère l’équilibrage de charge lors de l’exposition des services. Ainsi si un noeud Farid Abdel A. YESSOUFOU 30 IMSP-UAC tombe, l’autre noeud reprendra le service et Kubernetes se chargera de remettre en service le noeud qui était inactif. Nous avons donc ainsi l’équilibrage de charge à deux niveaux associant tous les avantages de la troisième solution. 1.4.4.1 Inconvénients de la solution Ce projet est encore à la version bêta, les auteurs n’ont pas proposé une architecture pour leurs clusters. 1.5 Conclusion Dans ce chapitre, nous avons expliqué la haute disponibilité de façon générale ainsi que les différentes techniques utilisées. Ensuite, nous avons parcouru certaines solutions proposées pour l’amélioration du service VoIP. Tout ceci sera utile pour le choix des techniques à utiliser et la conception de notre architecture HA dans le chapitre suivant. Farid Abdel A. YESSOUFOU 31 IMSP-UAC Table 1.8 – Tableau récapitulatifs des Techniques et outils existantes Farid Abdel A. YESSOUFOU 32 IMSP-UAC Chapitre 2 2.1 PRÉSENTATION DE L’ARCHITECTURE PROPOSÉE ET CHOIX TECHNIQUES Introduction Ce chapitre est consacré aux choix et aux explications des outils qui seront utilisés. Nous présentons par la suite l’architecture que nous mettrons en place. Ce module nous permet de justifier nos choix techniques. 2.2 Choix techniques Dans la mise en place de notre solution VoIP, nous avons le choix entre la technologie de conteneurisation et les machines virtuelles comme outils de redondance en cas de dysfonctionnement du serveur VoIP. Le tableau 2.1 présente les avantages et inconvénients des deux options. Table 2.1 – Comparaison entre VMs et conteneurs 33 De l’analyse du tableau 2.2, nous pouvons retenir que les conteneurs sont optimisés afin exécuter un grand nombre d’instances sur une même machine. Ils sont moins dispendieux en temps et en ressource contrairement aux machines virtuelles. Une VM qui pèse normalement des giga-octets ne pèse que quelques centaines de méga-octets dans un conteneur. Le déploiement et le redémarrage d’un conteneur se comptent en millisecondes or sur une VM en minutes. Aussi, en éliminant la couche de virtualisation, la consommation des ressources physiques est minimisée de manière drastique. 2.2.1 Conteneurisation Le tableau ci dessous fais une étude des outils de conteneurisation open source. Table 2.2 – Comparatifs des outils de conteneurisation Toute analyse faite du tableau 2.2, les outils Rkt et Docker sont les solutions que nous pouvons utiliser. Cependant Rkt est encore à ses débuts et dispose d’une faible communauté. Par contre Docker, dispose déjà de plusieurs versions stables et d’une très forte communauté. Le moteur Docker est impliqué dans environ 100 000 projets. Nous avons donc opté pour cette technologie. En plein essor depuis quelques années, la conteneurisation a contribué à l’avènement du DevOps et une avancée considérable de la R&D. Puisant leurs légèretés et leurs flexibilités, ils ont permis l’apparition de nouvelles formes d’architectures, consistant à mettre en place des infrastructures et applications au sein de conteneurs séparés pour ensuite déployer ces conteneurs sur un cluster de machines virtuelles ou physiques. Toutefois, cette nouvelle approche a créé le besoin d’outils d’orchestration pour automatiser le déploiement, le management, le scaling et la disponibilité du système basées sur des conteneurs. Farid Abdel A. YESSOUFOU 34 IMSP-UAC 2.2.2 Orchestration Pour le déploiement de notre solution, il est impératif d’utiliser un orchestrateur de conteneurs. Pour cela, notre choix s’est directement porté sur Kubernetes pour les raisons suivantes : + + Il est très populaire et dispose d’une très forte communauté ; Il présente l’avantage considérable de pouvoir surveiller l’état des conteneurs à tout moment et de suppléer directement aux pannes ; + Il permet de mettre à l’échelle des applications conteneurisées et les infrastructures à la volée ; + Il permet de vérifier l’intégrité de nos applications et les réparer automatiquement grâce au placement, au démarrage, à la réplication et à la mise à l’échelle automatiques ; + Il permet de monter et d’ajouter des systèmes de stockage pour exécuter des applications avec état ; + + Il permet d’orchestrer des conteneurs sur plusieurs hôtes ; Il permet également d’optimiser l’utilisation de matériel afin de maximiser les ressources requises pour l’exécution de nos applications d’entreprise. Le tableau ci-dessous montre les différences entre les solutions actuelles d’orchestration. Table 2.3 – Comparatifs d’outils d’orchestration des conteneurs Comme le montre le tableau 2.3 la solution Apache MESOS offre plus de fonctionnalités et d’avantages que les deux autres outils. Elle est beaucoup plus utilisée au niveau des datacenters. Néanmoins, son paramétrage est complexe et les autres outils offrent des avantages en matière de haute disponibilité que nous recherchons. Contrairement à Farid Abdel A. YESSOUFOU 35 IMSP-UAC Docker Swarm, Kubernetes offre l’avantage de pouvoir surveiller l’état des conteneurs à tout moment et de compenser directement une panne. Nous avons donc choisi Kubernetes pour sa simplicité, sa convivialité et ces multiples avantages en matière de haute disponibilité. 2.2.3 Présentation de Kubernetes Kubernetes est un projet Open Source créé par Google en 2015. Il permet d’automatiser le déploiement et la gestion d’applications multi-conteneur. Il s’agit d’un système permettant d’exécuter et de coordonner des applications conteneurisées sur un cluster de machines. C’est une plateforme conçue pour gérer entièrement le cycle de vie des applications et services conteneurisés en utilisant des méthodes de prédictibilité, de scalabilité et de haute disponibilité. Principalement compatible avec Docker et Rkt, Kubernetes peut fonctionner avec n’importe quel système de conteneur conforme au standard Open Container Initiative en terme de formats d’images et d’environnements d’exécution. De par son caractère open source, Kubernetes peut aussi être utilisé librement par n’importe qui, n’importe où[21]. Un cluster Kubernetes est constitué au minimum de 2 parties : + Master : serveur qui contrôle le cluster et qui donne les instructions à réaliser aux workers (noeuds de travail) ; + Worker : serveur qui exécute les applications conteneurisées. Le Noeud Master est l’unité principale de contrôle qui gère le dimensionnement et les communications dans le système. Le plan de contrôle de Kubernetes consiste en plusieurs composants, chacun ayant son propre processus, qui peuvent s’exécuter sur un ou plusieurs noeuds maîtres permettant de créer des clusters de haute disponibilité. Les différentes modules du noeud master sont : + + + + Serveur d’API Controller Manager Scheduler Etcd Lorsque l’on utilise Kubernetes, quatre fonctionnalités principales sont importantes à connaitre : 2 Pod : Un pod est un groupe d’un ou plusieurs conteneurs, ayant du stockage et réseau partagé, et une spécification sur la manière d’exécuter ces conteneurs. Kubernetes va donc gérer le pod plutôt que le conteneur directement[22]. Un pod a donc pour objectif d’exécuter une instance d’une application. Si l’on veut faire la mise à l’échelle horizontale, il suffit d’avoir plusieurs instances de l’application, Farid Abdel A. YESSOUFOU 36 IMSP-UAC chacune sur un pod différent. En réalité, on ne travaille que rarement sur les pods directement mais sur les contrôleurs à qui gèrent les pods. Figure 2.1 – Architecture globale d’un pod [22] 2 Deployment : Un Deployment contrôle des ReplicaSets et des pods. Il ajoute des fonctionnalités aux ReplicaSets comme : — Déployer des ReplicaSet : les ReplicaSets vont créer des pods et le Deployment va s’assurer que le déploiement se passe bien ; — Déclarer un nouvel état des pods : le Deployment va piloter la mise à jour des pods, des anciens ReplicaSet vers les nouveaux. Ce déploiement va créer une nouvelle révision du Deployment ; — Revenir à une ancienne version du Deployment : si le déploiement engendre des instabilités, on pourra revenir à une précédente révision ; — Mettre à l’échelle le Deployment pour gérer les montées en charge par exemple ; — Mettre en pause un déploiement : pour fixer des éventuelles erreurs et reprendre le rollout ; — Nettoyer les anciens ReplicaSets qui ne servent plus ; — Et d’autres fonctionnalités pour des cas d’utilisation plus avancés[23]. L’avantage du Deployment est de conserver la configuration des Pods intacte peu importe le nombre de réplicas déployés. 2 Service : Un service est un ensemble logique de pods ouverts au reste du cluster Kubernetes. Le service permet de regrouper des pods ensemble en leur fournissant une interface vers le reste du cluster, au moyen d’une adresse IP, d’un port et d’un protocole de communication. C’est le service qui va se charger de router les requêtes vers les pods qu’il gère. Contrairement aux pods, un service est persistant et représente le service exposé au reste du cluster. Il permet également de faire de l’équilibrage de charge[23]. Il existe trois types de services pour une utilisation particulière : Farid Abdel A. YESSOUFOU 37 IMSP-UAC Figure 2.2 – Architecture globale d’un deployment [23] — ClusterIP : C’est le type par défaut. Il expose le Service sur une adresse IP interne du cluster. De ce fait, le service n’est accessible que depuis l’intérieur du cluster ; — NodePort : Il expose le service vers l’extérieur du cluster à l’aide du NAT (la plage de ports autorisés est entre 30000 et 32767) ; — LoadBalancer : Il utilise l’équilibreur de charge. Ainsi, les services NodePort et ClusterIP sont créés automatiquement et sont acheminés par l’équilibreur de charge externe. Figure 2.3 – Architecture globale d’un service [23] 2 Ingress : L’objet Ingress autorise l’exposition d’un Service sur le port souhaité. On parle de règles Ingress qui permettent l’exposition réelle des applications sur le Worker au travers de ports définis par l’utilisateur. Une Ingress s’interconnecte naïvement sur un Service, ce qui rend son utilisation très simple. Grâce à cet objet, l’application peut être pleinement exposée au grand public. Sans elle l’application est disponible uniquement sur le Worker[23]. Farid Abdel A. YESSOUFOU 38 IMSP-UAC Figure 2.4 – Architecture globale d’un ingress [23] Kubernetes est un système distribué, il fonctionne sur plusieurs machines en même temps. Il a donc besoin d’une base de données distribuée. Celui qui fonctionne sur plusieurs machines en même temps, qui facilite le stockage des données sur un cluster et la surveillance des modifications apportées à ces données. Kubernetes utilise donc etcd comme base de données. La base de donnée Etcd stocke la configuration du cluster Kubernetes dans etcd. Il stocke également l’état réel du système et l’état souhaité du système dans etcd. Toute modification que nous effectuons entraîne la mise à jour d’une entrée dans etcd. L’ensemble des processus qui composent Kubernetes utilise etcd pour stocker des données et s’informer mutuellement des changements. Dans la mise en place d’un cluster kubernetes nous avons deux options de configuration de topologie etcd possible. 2.2.3.1 Topologie etcd interne Cette topologie nécessite moins d’infrastructures. Elle couple les noeuds maître et la base de données distribuée etcd sur les mêmes noeuds. Elle est plus simple à configurer qu’un cluster avec des noeuds etcd externes et plus simple à gérer pour la réplication. Cependant, si un noeud maitre tombe en panne, une base de donnée etcd et une instance du plan de contrôle sont perdus et la redondance est compromise. Figure 2.5 – Architecture etcd interne [24] Farid Abdel A. YESSOUFOU 39 IMSP-UAC 2.2.3.2 Topologie etcd externe Cette topologie sépare le plan de contrôle et le module etcd. Il fournit donc une configuration HA où la perte d’une instance du plan de contrôle ou d’un module etcd a moins d’impact et n’affecte pas la redondance du cluster autant que la topologie HA interne. Cependant, cette topologie nécessite deux fois plus d’hôtes que la topologie HA empilée. Figure 2.6 – Architecture etcd externe [24] Dans la mise en place de notre architecture, nous allons utiliser une topologie etcd externe pour les avantages qu’elle offre en matière de tolérance aux pannes pour le cluster HA. 2.2.4 Volume Persistant Les pods sont éphémères, cela signifie qu’ils peuvent être créés et/ou supprimés à tout moment. Ainsi toutes les données qu’ils ont à l’intérieur sont perdues. Nous avons donc besoin du stockage distribué pour avoir la possibilité à partager des configurations et des données entre les noeuds et les applications. Farid Abdel A. YESSOUFOU 40 IMSP-UAC Le tableau 2.4 présente les volumes persistants fonctionnant avec Kubernetes : Table 2.4 – Récapitulatifs des solutions de volume persistant Farid Abdel A. YESSOUFOU 41 IMSP-UAC D’après le tableau, les serveurs CephFS, NFS et GlusterFS sont les serveurs que nous pouvons utiliser. Pour notre implémentation nous avons choisi NFS. C’est un serveur de stockage distribué très populaire, facile à coupler à Kubernetes, évolutif et hautement disponible. 2.2.5 Solution de haute disponibilité VoIP proposée Nous associerons à notre cluster Kubernetes la solution VNF-Asterisk présentée dans le chapitre précédent en apportant des modifications. Pour le déploiement de cette nouvelle solution nous allons utiliser les fonctionnalités Deployment et ReplicaSet de Kubernetes pour assurer la disponibilité de nos pods. Ainsi la configuration des pods restera intacte peu importe le nombre de réplicas. Le schéma 2.7 décrit le fonctionnement de notre nouvelle solution : Figure 2.7 – Fonctionnement externe de la solution VNF-asterisk Avec cette solution plusieurs instances d’Asterisk pourront être déployées grâce au replicaSet. La scalabilité horizontale et verticale sera gérer automatiquement par kubernetes. Lorsque la charge de travail augmente, des pods seront crées par kubernetes et supprimés lorsque cela chutera. Farid Abdel A. YESSOUFOU 42 IMSP-UAC Figure 2.8 – Architecture du pod asterisk-homer [25] Cette architecture offre plusieurs avantages : — L’intégration de l’API(Application Programming Interface) permet d’interagir avec les conteneurs Asterisk et de gérer leurs configurations via des méthodes POST et GET [26] ; — Le sniffer de paquets nous permet d’analyser en temps réels les paquets SIP grâce à homer ; — L’utilisation de etcd pour chaque pods. Farid Abdel A. YESSOUFOU 43 IMSP-UAC 2.3 Présentation de l’architecture proposée Figure 2.9 – Présentation de l’architecture proposée Cette architecture combine les approches de solutions et outils précédemment énumérés. Nous proposons ici une solution VoIP présentant la capacité de haute disponibilité HA avec l’orchestrateur Kubernetes et la solution VNF-Asterisk. Pour ce schéma de cluster Kubernetes, nous avons huit noeuds : + trois serveurs pour le cluster etcd externe ; Farid Abdel A. YESSOUFOU 44 IMSP-UAC + + deux noeuds maîtres ; trois noeuds de travail. Nous avons un cluster Kubernetes avec une topologie multi-maîtres et un cluster Etcd externe comme couche de base et un équilibreur de charge réseau interne. Sur tous les noeuds de travail, nous déploierons un cluster de stockage distribué interne. Nous allons utiliser une paire d’outils HAProxy comme équilibreur de charge avec HeartBeat qui partageront une IP virtuelle entre eux. HeartBeat et HAProxy utilisent un petit nombre de ressources système, donc nous les placerons sur une paire de noeuds Etcd, pour surveiller et load balancer les etcd en cas de défaillance. 2.4 Conclusion A travers ce chapitre, nous avons procédé à l’étude des outils que nous allons utiliser et à la présentation de notre architecture HA. Le chapitre suivant sera consacré au déploiement de notre solution et à l’évaluation de sa performance. Farid Abdel A. YESSOUFOU 45 IMSP-UAC Chapitre 3 3.1 DÉPLOIEMENT ET ÉVALUATION TECHNIQUE Introduction Ce chapitre est consacré à l’implémentation de notre architecture proposée dans le chapitre précédent et à l’évaluation de sa performance. Nous allons commencer par la planification des différentes tâches à effectuer. 3.2 Planification des déploiements Les différents travaux à effectuer sont regroupés dans le tableau 3.1 : Table 3.1 – Planification des déploiements 46 3.3 Exécution des déploiements et évaluation de l’architecture Des captures d’écrans sont réalisées pour les différents déploiements. Cependant, certains déploiements ont leurs captures d’images référencées dans la page annexe de notre document. 3.3.1 Déploiement de Vmware vSphere et du système d’exploitation linux sur les 8 machines virtuelles Nous avons effectué les tâches suivantes : - Installation des machines virtuelles selon nos besoins ; - Installation de Centos 7 sur les VMs. Pour la réalisation de cette tâche nous avons utilisé deux machines physiques ayant les caractéristiques suivantes : — 8 CPUs * 2.394 GHz ; — Processeur Intel Xeon ; — 16GB RAM ; — Disque dur 1To. La répartition des adresses IP est présentée dans le tableau 3.2 : Table 3.2 – Répartition des adresses IP 3.3.2 Déploiement de Haproxy sur les machines etcd1 et etcd2 Le déploiement de haproxy passe par l’installation du paquet haproxy. Nous y avons configuré le fichier /etc/haproxy/haproxy.cfg . Farid Abdel A. YESSOUFOU 47 IMSP-UAC 3.3.3 Déploiement de HeartBeat sur les machines etcd1 et etcd2 Pour la configuration de HeartBeat, nous avons installé le paquet HeartBeat. Après avoir configuré les fichiers /etc/ha.d/ha.cf, /etc/ha.d/haresources et /etc/ha.d/authkeys nous avons assigné à notre IP virtuel l’adresse 172.17.64.10 que nous pouvons voir fonctionnel dans la figure 3.1 : Figure 3.1 – Démarrage du service HeartBeat 3.3.4 Déploiement de docker et kubernetes sur les 8 machines Ansible est un logiciel open source qui permet d’automatiser simplement et efficacement la mise en place d’infrastructures complexes et le déploiement d’applications. Nous l’avons utilisé pour simplifier le déploiement de notre infrastructure. Tous les scripts utilisés ici sont publiés sur : https ://bit.ly/2ZESQaX. La commande ansible-playbook -i hosts /kube-ansible/config-file.yml nous permet de lancé nos installations et configurations. Nous pouvons vérifier que nos déploiements fonctionnent en vérifiant si Kubernetes est bien fonctionnel sur l’un des noeuds master. Figure 3.2 – Démarrage du service de Kubernetes au noeud Master1 3.3.5 Configuration du volume persistant Nous avons dans un premier temps installer le serveur NFS sur notre master1 et créer un répertoire où notre serveur NFS servira les workers. Ensuite, nous avons aussi modi- Farid Abdel A. YESSOUFOU 48 IMSP-UAC fier le fichier /etc/exports pour ajouter le système de fichiers que nous avons créé. Il reste maintenant à coupler kubernetes à notre serveur NFS. Nous avons créé un fichier deployement.yaml pour y renseigner les configurations sur le déploiement du client nfs sur les noeuds workers. Puis nous lancons le déploiement avec la commande kubectl create -f deployment.yaml. 3.3.6 Déploiement de la solution VNF-Asterisk Nous avons configuré : — l’adresse du serveur DNS de kubernetes dans le fichier resolv.conf des noeuds maitres ; — les noeuds maîtres pour empêcher que nos pods s’exécutent sur nos noeuds masters. Nous avons par la suite automatiser le déploiement de notre pod vnf-asterisk grâce au fichier vnf-asterisk.yaml. Pour contrôler le déploiement, nous exécutons la commande : watch -n1 kubectl get pods -o wide. Nous y verrons les pods suivants : — asterisk - Le serveur asterisk ; — controleur - Notre API qui contrôle asterisk ; — webapp - qui est l’interface utilisateur Web de Homer ; — vnfui - qui est l’interface utilisateur Web pour notre API ; — etcd - une base de donnée distribuée utilisée pour la découverte de service ; — cron - utilisé par Homer pour exécuter des scripts ; — MySQL - utilisé pour le stockage des trafics SIP par Homer ; — kamailio - un proxy SIP, utilisé ici par Homer pour examiner le trafic VoIP. 3.3.6.1 Scalabilité horizontale et vertical d’Asterisk Pour ajouter un replicat asterisk, nous exécutons la commande suivante : kubectl scale deployment asterisk –replicas 2. Nous pouvons faire un trunk entre nos deux pods asterisk. Nous allons utiliser notre API pour le faire. Pour récupérer l’UUID des pods asterisk, nous pouvons interroger notre API avec curl ou via notre interface WEB. La commande curl -s controller.default.svc.cluster.local :8001/connect/$uuida/$uuidb/inbound nous permet donc de relier entre nos deux pods asterisk. Grace à notre API, nous pouvons : — Effectuer un trunk entre des pods asterisk ; Farid Abdel A. YESSOUFOU 49 IMSP-UAC — Obtenir une information sur un trunk ; — Ajouter des utilisateurs à un pod spécifique ; — Obtenir des informations sur un pod. 3.3.7 Système de monitoring Homer est un outil d’analyse et de surveillance VoIP. Il permet donc de visualiser ce qui se passe sur le trafic SIP. Pour commencer, nous avons d’abord exposé le pod webapp comme pour le pod vnfui. Après connexion, nous pouvons visualiser nos trafics SIP à travers différents graphes. Figure 3.3 – Analyse du trafic SIP par homer La figure 3.3 représente des graphes décrivant des statistiques des methodes BYE, INVITE et 200 reçu au cours d’un appel émis. 3.3.8 Évaluation de la Performance de l’architecture proposée Pour évaluer la performance de notre architecture HA, nous avons utilisé le logiciel open source SIPp[28]. Ce dernier est un outil de test de performance pour le protocole SIP. L’objectif de ces tests est d’étudier la capacité de l’architecture HA proposée à gérer un grand nombre d’appels. Les tests effectués sont fortement dépendants des ressources matérielles et de la topologie. Farid Abdel A. YESSOUFOU 50 IMSP-UAC Figure 3.4 – Démarrage de SiPp Les résultats de nos tests sont enregistrés dans les tableaux ci-après et dans les figures qui suivent. Le premier tableau représente les tests effectués sur une architecture VoIP de haute disponibilité de la solution et trois conteneurs. Table 3.3 – Évaluation de la performance d’une architecture VoIP de la troisième solution Farid Abdel A. YESSOUFOU 51 IMSP-UAC Le tableau suivant présente les tests effectués sur notre architecture HA. Table 3.4 – Évaluation de la performance de notre Architecture HA Farid Abdel A. YESSOUFOU 52 IMSP-UAC — Interprétation Il ressort des résultats obtenus des tableaux 3.3, 3.4 que l’architecture proposée améliore considérablement le service VoIP. Le nombre d’appels traités avec succès par notre solution est nettement supérieure que celui traité par une architecture VoIP classique. 3.4 Estimation financière pour le déploiement de l’infrastructure proposée L’estimation financière pour la mise en place de notre architecture proposée est résumée dans le tableau ci-après. Table 3.5 – Estimation financière pour le déploiement de l’architecture 3.5 Conclusion Ce chapitre a été consacré au déploiement de notre architecture et à l’évaluation de sa performance tout en faisant une prévision financière pour son déploiement. Des tests ont été effectués pour valider le bon fonctionnement de la haute disponibilité du service VoIP. Farid Abdel A. YESSOUFOU 53 IMSP-UAC CONCLUSION ET PERSPECTIVES Notre étude s’est focalisée sur l’étude et déploiement d’une solution VoIP sur une architecture de haute disponibilité. Nous avons effectué des recherches dans ce sens, partant de la documentation par rapport aux outils et techniques existantes, de l’analyse de ces techniques, aux outils à utiliser pour la conception de l’infrastructure HA et à l’évaluation de la performance. Cette réalisation à été possible grâce à la technologie NFV et à Kubernetes. Notre solution est totalement axée sur les logiciels libres. Dans notre architecture, nous avons utilisé différents outils qui permettent une haute disponibilité, et des concepts de clustering pour offrir des mécanismes de contingence, ainsi que des techniques d’équilibrage de charge pour ajouter une plus grande extensibilité au service de téléphonie fourni. Dans le cadre de nos futurs travaux, nous pensons à : — Virtualiser entièrement le réseau avec la technologie SDN, ce qui nous permettra d’économiser une plus large bande passante ; — Développer une application WEB pour une meilleur utilisation de notre API et créer un annuaire ldap pour la gestion de nos utilisateurs ; — Évaluer la QoS fournie par l’architecture proposée. 54 Bibliographie [1] Pascal CREUSOT, https ://www.itpro.fr/redondance-et-haute-disponibilite-lync2010/, 09/01/2013, consulté le 10/08/2019 à 20h31min. [2] BOUKHOBZA Elior, https ://fr.slideshare.net/EliorBoukhobza/haute-disponibilitet-tolrance-de-panne-50843503,13/10/2009, EPITA Telecom, consulté le 10/08/2019 à 20h44min [3] Plate-forme https d’entreprise sécurisée et de haute disponibilité, ://www.memoireonline.com/11/13/8006/Plate-forme-d-entreprise- securisee-et-de-haute-disponibilite.html, consulté le 10/08/2019 à 23h4min [4] Cluster de Haute disponibilité, http ://www.ha-cc.org/fr/, consulté le 12/08/2019 à 12h [5] Cluster de Haute disponibilité, http ://migale.jouy.inra.fr/ ?q=fr/book/export/html/338 , consulté le 12/08/2019 à 13h [6] kamailio, https ://saevolgo.blogspot.com/2011/11/how-to-increasing-voip- services.html,consulté le 15/08/2019 à 15h [7] Landry Fossouo Noumsi, étude et mise en place d’une solution Cloud Computing, école national supérieur des postes et des télécommunications, 2012. [8] Alain-B TCHANA, système d’administration autonome adaptable : application au Cloud, L’institut national polytechnique de Toulouse , 2011 [9] Conteneur Linux, https ://www.redhat.com/fr/topics/containers/whats-a-linuxcontainer, Redhat Website, consulté le 03/10/2019 à 20h55min [10] Découvrez les conteneurs, https ://openclassrooms.com/fr/courses/2035766optimisez-votre-deploiement-en-creant-des-conteneurs-avec-docker/6211306decouvrez-les-conteneurs, consulté le 03/10/2019 à 22hmin [11] G. Kambourakis, D. Geneiatakis, S. Gritzalis, C. Lambrinoudakis, T. Dagiuklas, S. Ehlert, and J. Fiedler,"High Availability for SIP : Solutions and Real-Time Measu- 55 rement Performance Evaluation," International Journal of Disaster Recovery and Business Continuity, vol. 1, no. 1, pp. 11-29, February 2010. [12] A Proposal for A High Availability Architecture for VoIP Telephone Systems based on Open Source Software [13] S. Pal, R. Gadde, and H. Latchman, On the Reliability of Voice Over IP (VoIP) Telephony, University of Florida, 2011. [14] A. Minessale and G. Maruzzelli, Mastering FreeSWITCH, Packt Publishing, July 2016. [15] Ultra Monkey, Load Balancing and Highly Available Solutions, http ://www.ultramonkey.org. [16] Doug Smith, https ://twitter.com/dougbtv. [17] Docker and Asterisk, http ://dougbtv.com/2014/10/02/docker-and-asterisk/ [18] Astricon, https ://www.asterisk.org/community/astricon-user-conference. [19] STP, http ://bi-reseaux.blogspot.com/2016/02/stp-spanning-tree-protocol.html, consulté le 12/10/2019 à 22h30min [20] VNF Asterisk, https ://github.com/redhat-nfvpe/vnf-asterisk, consulté le consulté le 14/10/2019 à 22h40min [21] Kubernetes ,https ://www.lebigdata.fr/kubernetes-definition, 01/11/2019 à 2h10min [22] Pods, https ://kubernetes.io/fr/docs/concepts/workloads/pods/pod/, consulté le 01/11/2019 à 2h30min [23] Deployment, https ://web.leikir.io/introduction-a-kubernetes/, consulté le 01/11/2019 à 2h35min [24] Etcd cluster kubernetes, https ://kubernetes.io/docs/tasks/administer- cluster/configure-upgrade-etcd/, consulté le 03/11/2019 à 12h12min [25] VNF-Asterisk , https ://www.slideshare.net/LeifMadsen4/asterisk-as-a-virtualnetwork-function-part-1/1, consulté le 03/11/2019 à 13h45min [26] VNF-Asterisk-controller , https ://vnfasteriskcontroller.docs.apiary.io, consulté le 07/12/2019 à 19h12min [27] Configuration Vnf-asterisk , https ://github.com/dougbtv/vnf- asterisk/blob/containers/k8s/ansible/roles/load-podspec/templates/podspec.yml.j2, consulté le 07/01/2020 à 19h34min [28] Sipp , https ://sipp.readthedocs.io/en/v3.6.0/foreword.html, consulté le 12/05/2019 à 16h34min Farid Abdel A. YESSOUFOU 56 IMSP-UAC ANNEXES Figure 3.5 – Démarrage du services Haproxy Figure 3.6 – Demarrage des pods VNF-Asterisk 57 Figure 3.7 – Configuration du déploiement des clients NFS sur kubernetes Figure 3.8 – Visualisation des services de kubernetes Farid Abdel A. YESSOUFOU i IMSP-UAC Figure 3.9 – Interface de notre controller API Figure 3.10 – Trunk entre deux pods asterisk Figure 3.11 – Test d’appel entre deux pods Farid Abdel A. YESSOUFOU ii IMSP-UAC Table des matières Dédicaces iii Remerciements iv Liste des tableaux v Liste des figures vi Liste des sigles viii INTRODUCTION GENERALE 9 1 ÉTAT DE L’ART 12 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2 Haute disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2.2 Critères DICP-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2.3 Fiabilité versus disponibilité . . . . . . . . . . . . . . . . . . . . . . . 13 1.3 Présentation des techniques existantes . . . . . . . . . . . . . . . . . . . . . 14 1.3.1 1.3.2 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3.1.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3.1.2 Architecture en Cluster . . . . . . . . . . . . . . . . . . . . 15 1.3.1.3 Types de Cluster . . . . . . . . . . . . . . . . . . . . . . . . 15 1.3.1.4 Outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Cluster d’équilibrage de charge . . . . . . . . . . . . . . . . . . . . . 17 1.3.2.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.3.2.2 Architectures d’un cluster d’équilibrage de charge . . . . . 17 1.3.2.3 Algorithmes d’équilibrage de charge . . . . . . . . . . . . . 18 1.3.2.4 Outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 iii 1.3.3 Redondance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.3.3.1 Virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.3.3.2 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.3.3.3 Avantages de la virtualisation . . . . . . . . . . . . . . . . . 20 1.3.3.4 Inconvénients de la virtualisation . . . . . . . . . . . . . . 20 1.3.3.5 Outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.3.3.6 La Conteneurisation . . . . . . . . . . . . . . . . . . . . . . 22 1.3.3.7 Avantages de la conteneurisation . . . . . . . . . . . . . . . 23 1.3.3.8 Inconvénients de la conteneurisation . . . . . . . . . . . . 23 1.3.3.9 Outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.3.3.10 Orchestration de Conteneur . . . . . . . . . . . . . . . . . . 24 1.3.4 NFV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.3.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.3.4.2 Avantages de la technologie NFV . . . . . . . . . . . . . . . 25 1.3.4.3 Inconvenients de la technologie NFV . . . . . . . . . . . . 26 1.4 Présentation des solutions existantes . . . . . . . . . . . . . . . . . . . . . . 27 1.4.1 1.4.2 Première approche de solution . . . . . . . . . . . . . . . . . . . . . 27 1.4.1.1 Schéma d’équilibrage de charge . . . . . . . . . . . . . . . 27 1.4.1.2 Insuffisances de la solution . . . . . . . . . . . . . . . . . . 28 Deuxième approche de solution . . . . . . . . . . . . . . . . . . . . . 28 1.4.2.1 1.4.3 Troisième approche de solution . . . . . . . . . . . . . . . . . . . . . 29 1.4.3.1 1.4.4 Inconvénients de la solution : . . . . . . . . . . . . . . . . . 29 Insuffisance de la solution . . . . . . . . . . . . . . . . . . . 30 Quatrième approche de solution . . . . . . . . . . . . . . . . . . . . 30 1.4.4.1 Inconvénients de la solution . . . . . . . . . . . . . . . . . 31 1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2 PRÉSENTATION DE L’ARCHITECTURE PROPOSÉE ET CHOIX TECHNIQUES 33 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.2 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.2.1 Conteneurisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.2.2 Orchestration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.2.3 Présentation de Kubernetes . . . . . . . . . . . . . . . . . . . . . . . 36 2.2.3.1 Topologie etcd interne . . . . . . . . . . . . . . . . . . . . . 39 2.2.3.2 Topologie etcd externe . . . . . . . . . . . . . . . . . . . . . 40 2.2.4 Volume Persistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.2.5 Solution de haute disponibilité VoIP proposée . . . . . . . . . . . . . 42 2.3 Présentation de l’architecture proposée . . . . . . . . . . . . . . . . . . . . . 44 Farid Abdel A. YESSOUFOU iv IMSP-UAC 2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3 DÉPLOIEMENT ET ÉVALUATION TECHNIQUE 46 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.2 Planification des déploiements . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.3 Exécution des déploiements et évaluation de l’architecture . . . . . . . . . . 47 3.3.1 Déploiement de Vmware vSphere et du système d’exploitation linux sur les 8 machines virtuelles . . . . . . . . . . . . . . . . . . . . 47 3.3.2 Déploiement de Haproxy sur les machines etcd1 et etcd2 . . . . . . 47 3.3.3 Déploiement de HeartBeat sur les machines etcd1 et etcd2 . . . . . 48 3.3.4 Déploiement de docker et kubernetes sur les 8 machines . . . . . . 48 3.3.5 Configuration du volume persistant . . . . . . . . . . . . . . . . . . 48 3.3.6 Déploiement de la solution VNF-Asterisk . . . . . . . . . . . . . . . 49 3.3.6.1 Scalabilité horizontale et vertical d’Asterisk . . . . . . . . . 49 3.3.7 Système de monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3.8 Évaluation de la Performance de l’architecture proposée . . . . . . . 50 3.4 Estimation financière pour le déploiement de l’infrastructure proposée . . 53 3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 CONCLUSION ET PERSPECTIVES 54 Annexes 57 Farid Abdel A. YESSOUFOU v IMSP-UAC