Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN Virtualisation et Cloud computing Travaux Pratiques TP 05 : Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 2022 – 2023 Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 2022 – 2023 3 Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 2022 – 2023 Objectif : Déployer un environnement Cloud Computing basée sur Openstack, l’un des outils les plus populaires au sein de la communauté Cloud afin de mettre en œuvre des conteneurs Docker visant à procurer des contrôleurs de service SDN (Software-defined networking) (Virtualisation des réseaux). Pour réaliser ce projet, nous présenterons des sections qui : Définissent les notions, introduisent et justifient les outils utilisés, Expliquent les étapes à suivre, Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 4 Cloud Computing Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 13 Cloud Computing 1. Définition et généralités L’informatique dans le nuage est plus connue sous sa forme anglo-saxonne : « Cloud Computing », mais il existe de nombreux synonymes francophones tels que : « informatique dans les nuages », « infonuagique » (Québec) ou encore « informatique dématérialisée ». Même si les experts ne sont pas d’accords sur sa définition exacte, la plupart s’accordent à dire qu’elle inclue la notion de services disponibles à la demande, extensibles à volonté et à distance ou sur le net. En contradiction avec les systèmes actuels, les services sont virtuels et illimités et les détails des infrastructures physiques sur lesquels les applications reposent ne sont plus du ressort de l’utilisateur. Selon le National Institute of Standards and Technology, le cloud computing englobe trois caractéristiques clés : la mutualisation, de la part du fournisseur, de ressources éclatées ; des ressources accessibles en réseau ; des ressources accessibles rapidement, à la demande et de façon souple ; Par exemple quelques définitions qui ont circulés : « Le cloud computing est un modèle qui permet un accès réseau à la demande et pratique à un pool partagé des ressources informatiques configurables (telles que réseaux, serveurs, stockage, applications et services) qui peuvent être provisionnées rapidement et distribuées avec un minimum de gestion ou d’interaction avec le fournisseur de services. » «Le Cloud Computing est une plateforme de mutualisation informatique fournissant aux entreprises des services à la demande avec l'illusion d'une infinité des ressources». Un des points essentiels de ces définitions est la notion de « scalability » ; d’extensibilité à la demande, d’élasticité, c’est à dire qu’on ne paie que ce qu’on utilise. C’est un avantage considérable par rapport à une infrastructure propre à l’entreprise où les serveurs sont très souvent sous-utilisés. On devrait avoir ici pas mal de références ?! « Donc le Cloud Computing est un concept qui consiste à déporter sur des serveurs distants des stockages et des traitements informatiques traditionnellement localisés sur des serveurs locaux ou sur le poste de l'utilisateur. Il consiste à proposer des services informatiques sous forme de service à la demande, accessible de n'importe où, n'importe quand et par n'importe qui ». L'idée principale à retenir est que le Cloud n'est pas un ensemble de technologies, mais un modèle de fourniture, de gestion et de consommation des services et des ressources informatiques localisés dans des Datacenter. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 14 Cloud Computing Figure 1:Cloud Computing Le modèle Cloud Computing se différencie par les cinq caractéristiques essentielles suivantes: Accès aux services par l’utilisateur à la demande La mise en œuvre des systèmes est entièrement automatisée et c’est l’utilisateur, au moyen d’une console ou à travers des outils et des logiciels spécifiques, qui mettent en place et gèrent la configuration à distance. Accès réseau large bande Ces centres de traitement sont généralement raccordés directement sur le backbone internet pour bénéficier d’une excellente connectivité. Les grands fournisseurs répartissent les centres de traitement sur la planète pour fournir un accès aux systèmes en moins de 50 ms de n’importe quel endroit. Réservoir des ressources (non localisées) La plupart de ces centres comportent des dizaines de milliers de serveurs et de moyens de stockage pour permettre des montées en charge rapides. Il est souvent possible de choisir une zone géographique pour mettre les données “près” des utilisateurs. Redimensionnement rapide (élasticité) La mise en ligne d’une nouvelle instance d’un serveur est réalisée en quelques minutes, l’arrêt Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 15 Cloud Computing et le redémarrage en quelques secondes. Toutes ces opérations peuvent s’effectuer automatiquement par des scripts. Ces mécanismes de gestion permettent de bénéficier pleinement de la facturation à l’usage en adaptant la puissance de calcul au trafic instantané. Facturation à l’usage Il n’y a généralement pas de coût de mise en service (c’est l’utilisateur qui réalise les opérations). La facturation est calculée en fonction de la durée et de la quantité de ressources utilisées. Une unité de traitement stoppée n’est pas facturée. 2. Historique du Cloud Computing Il est communément admis que le concept de Cloud Computing a été initié par le géant Amazon en 2002. Le cybermarchand avait alors investi dans un parc informatique afin de pallier les surcharges des serveurs dédiés au commerce en ligne constatées durant les fêtes de fin d’année. A ce moment-là, Internet comptait moins de 600 millions d’utilisateurs mais la fréquentation de la toile et les achats en ligne étaient en pleine augmentation. En dépit de cette augmentation, les ressources informatiques d’Amazon restaient peu utilisées une fois que les fêtes de fin d’année étaient passées. Ce dernier a alors eu l’idée de louer ses capacités informatiques le reste de l’année à des clients pour qu’ils stockent les données et qu’ils utilisent les serveurs. Ces services étaient accessibles via Internet et avec une adaptation en temps réel de la capacité de traitement, le tout facturé à la consommation. Cependant, ce n’est qu’en 2006 qu’Amazon comprit qu’un nouveau mode de consommation de l’informatique et d’internet faisait son apparition. Bien avant la naissance du terme de Cloud Computing, utilisé par les informaticiens pour qualifier l’immense nébuleuse du net, des services de Cloud étaient déjà utilisés comme le webmail2, le stockage de données en ligne (photos, vidéos,…) ou encore le partage d’informations sur les réseaux sociaux. La virtualisation est un concept beaucoup plus ancien qui constitue le socle du Cloud Computing. La virtualisation regroupe l’ensemble des techniques matérielles ou logicielles permettant de faire fonctionner, sur une seule machine physique, plusieurs configurations informatiques (systèmes d’exploitation, applications, mémoire vive,…) de manière à former plusieurs machines virtuelles qui reproduisent le comportement des machines physiques. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 16 Cloud Computing 3. Bénéfices du cloud Computing Les retombées des principes du cloud sont bénéfiques à la fois pour son fournisseur, les entreprises délocalisant leurs infrastructures. Généralement, ils assurent aux deux premiers une meilleure rentabilité. De plus, ils permettent à l'entreprise de se concentrer sur les taches de production autres que la maintenance de systèmes informatiques. 3.1 Pour le fournisseur Les bénéfices du fournisseur sont uniquement dus au fait de la mutualisation des ressources. En effet, après son investissement dans la mise en place des infrastructures pour le cloud, il fait payer aux entreprises la marge nécessaire pour sa rentabilisation. Comme pour une entreprise disposant d'une plateforme interne, il paie pour les frais d'administration de l'ensemble. Cette dépense peut être amortie par facturation aux entreprises. En plus de cette marge, il bénéficie des couts de réutilisation des ressources. En effet, compte tenu de la non appartenance des ressources aux entreprises, elles (les ressources) leurs sont facturées à chaque usage. La même ressource peut ainsi faire l'objet de plusieurs facturations. 3.2 Pour l'entreprise C'est elle la première gagnante de cette technologie. Elle réalise des bénéfices en argent et en flexibilité dans sa capacité à s'agrandir. 3.2.1 La réduction des couts : Le recours au cloud permet à l'entreprise d'être facturée à l'usage, en fonction de ses besoins. Pour avoir une idée du gain réalisé, reprenons cette observation de Michael Crandell du groupe RightScale à propos du cloud d'Amazon « Le cout à pleine charge d'un serveur sur Amazon se situe entre 70$ et 150$ par mois alors qu'il s'élève à 400$ en moyenne par mois s'il était hébergé par l'entreprise en interne » [1]. Plusieurs raisons expliquent cette différence de cout. En effet, une gestion interne de l'infrastructure implique l'achat des matériels, l'affectation du personnel (et donc du cout salarial qu'il induit) pour la gestion de l'infrastructure et divers moyens de production mis en place pour le fonctionnement de l'ensemble (électricité, locaux, ….etc.). Le partage de ressources tel que pratiqué dans le cloud permet au fournisseur de répartir ces couts entre plusieurs entreprises. 3.2.2 La réduction des gaspillages: Les infrastructures gérées en interne sont souvent sous-utilisées, alors que l'infrastructure d'un cloud mutualise l'ensemble de ressources pour un grand nombre d'entreprises. La Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 17 Cloud Computing mutualisation consiste à mettre à la disposition de plusieurs utilisateurs une base commune de ressources. Elle permet ainsi d'augmenter le taux d'utilisation de ces ressources. En effet, les ressources n'étant pas dédiées à un seul utilisateur, elles pourront servir à d'autres en cas de besoin. 3.2.3 La flexibilité et accès aux ressources à larges échelle : L'entreprise peut augmenter la capacité de son infrastructure sans investissement majeur. En effet, grâce à l'allocation dynamique (à la demande) des ressources qu'offre le cloud, il suffit de souscrire à des nouvelles ressources et celles-ci sont directement allouées. De plus, l’entreprise est libre de ses allées et venues car les contrats d'utilisation sont limités dans le temps (autour de l'heure). Ainsi, l'entreprise peut augmenter ou réduire son infrastructure à sa guise à moindre cout et dans un délai réduit (il faut mettre en avant le critère de rapidité qui est un grand avantage) . Rappelons que le cloud offre ainsi à l'entreprise une possibilité d'accéder à une quantité de ressources dont elle ne pourrait se l'offrir en interne. Elle peut dorénavant envisager des applications large échelle sans se soucier de l'obtention des équipements. 4. Les différents services Le cloud computing peut être décomposé en trois couches : Application (SaaS, Software as a Service) Platform (PaaS, Platform as a Service) Infrastructure (IaaS, Infrastructure as a Service) La Figure 6 ci-dessous représente les différentes couches du cloud computing : de la couche la moins visible pour les utilisateurs finaux à la plus visible. L’infrastructure as a Service (Iaas) , est plutôt gérée par les architectes réseaux, la couche PaaS est destinée aux développeurs d’applications et finalement le logicielle comme un service (SaaS) est le « produit final » pour les utilisateurs. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 18 Cloud Computing Figure 2:Les couches du cloud computing Infrastructure as a Service (IaaS) Seul le serveur est dématérialisé. Un prestataire propose la location de composants informatiques comme des espaces de stockages, une bande passante, des unités centrales et des systèmes d’exploitation. Les utilisateurs d’une IaaS peuvent donc utiliser à la demande des serveurs virtuels situés dans des Datacenter sans avoir à gérer les machines physiques (coûts de gestion, remplacement de matériel, climatisation, électricité….) L’IaaS offre une grande flexibilité, avec une administration à distance, et permet d’installer tout type de logiciel. En revanche, cette solution nécessite la présence d’un administrateur système au sein de l’entreprise, comme pour les solutions serveur classiques. Parmi les prestataires d’IaaS, on peut citer : Amazon avec EC2 ou Orange Business Services avec Flexible Computing. Platform as a Service (PaaS) Le matériel (serveurs), l’hébergement et le Framework d’application (kit de composants logiciels structurels) sont dématérialisés. L’utilisateur loue une plateforme sur laquelle il peut développer, tester et exécuter ses applications. Le déploiement des solutions PaaS est automatisé et évite à l’utilisateur d’avoir à acheter des logiciels ou d’avoir à réaliser des installations supplémentaires, mais ne conviennent qu’aux applications Web. Les principaux Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 19 Cloud Computing fournisseurs de PaaS sont : Microsoft avec AZURE, Google avec Google App Engine et Orange Business Services. Software as a Service (SaaS) Le matériel, l’hébergement, le framework d’application et le logiciel sont dématérialisés et hébergés dans un des Datacenter du fournisseur. Les utilisateurs consomment les logiciels à la demande sans les acheter, avec une facturation à l’usage réel. Il n’est plus nécessaire pour l’utilisateur d’effectuer les installations, les mises à jour ou encore les migrations de données. Les solutions SaaS constituent la forme la plus répandue de Cloud Computing. Les prestataires de solutions SaaS les plus connus sont Microsoft – offre Office365 (outils collaboratifs) Google – offre Google Apps (messagerie et bureautique). Figure 3: répartition des charges Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 20 Cloud Computing 5. Modèles de déploiement D’après la définition donnée dans la Section précédente un nuage correspond à une infrastructure distante, dont on ne connaît pas les détails architecturaux, et qui est connue pour les services informatiques qu’elle offre. Aussi, il est courant d’utiliser le terme un nuage pour désigner l’infrastructure gérée par un prestataire donné. On pourra alors parler du nuage d’Amazon, de celui de Google, et ainsi de suite. On peut distinguer quatre types principaux de modèles de déploiement pour ces nuages : le nuage privé, le nuage communautaire, le nuage public et le nuage hybride. Le nuage privé : L’infrastructure d’un nuage privé n’est utilisée que par un unique client. Elle peut être gérée par ce client ou par un prestataire de service et peut être située dans les locaux de l’entreprise cliente ou bien chez le prestataire, le cas échéant. L’utilisation d’un nuage privé permet de garantir, par exemple, que les ressources matérielles allouées ne seront jamais partagées par deux clients différents. Le nuage communautaire : L’infrastructure d’un nuage communautaire est partagée par plusieurs organisations indépendantes et est utilisée par une communauté qui est organisée au tour des mêmes besoins, vis-à-vis de son utilisation. Par exemple, dans le projet Open Cirrus, le nuage communautaire est partagé par plusieurs universités dans le cadre d’un projet scientifique commun. Son infrastructure peut être gérée par les organisations de la communauté qui l’utilise ou par un tiers et peut être située, soit au sein des dites organisations, soit chez un prestataire de service. Le nuage public : L’infrastructure d’un nuage public est accessible publiquement ou pour un large groupe industriel. Son propriétaire est une entreprise qui vend de l’informatique en tant que service. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 21 Cloud Computing Le nuage hybride : L’infrastructure d’un nuage hybride est une composition de deux ou trois des types de nuages précédemment cités. Les différents nuages qui la composent restent des entités indépendantes à part entière, mais sont reliés par des standards ou par des technologies propriétaires qui permettent la portabilité des applications déployées sur les différents nuages. Une utilisation type de nuage hybride est la répartition de charge entre plusieurs nuages pendant les pics du taux d’utilisation. 6. La virtualisation 6.1 Définition La virtualisation consiste à faire fonctionner un ou plusieurs systèmes d'exploitation sur un ou plusieurs ordinateurs. Cela peut sembler étrange d'installer deux systèmes d'exploitation sur une machine conçue pour en accueillir qu'un, mais comme nous le verrons par la suite, cette technique a de nombreux avantages. Il est courant pour des entreprises de posséder de nombreux serveurs, tels que les serveurs de mail, de nom de domaine, de stockage pour ne citer que ceux-ci. Dans un contexte économique où il est important de rentabiliser tous les investissements, acheter plusieurs machines physiques pour héberger plusieurs serveurs n'est pas judicieux. De plus, une machine fonctionnant à 15 pour cent ne consomme pas plus d'énergie qu'une machine fonctionnant à 90 pour cent. Ainsi, regrouper ces serveurs sur une même machine peut donc s'avérer rentable si leurs pointes de charge ne coïncident pas systématiquement. Enfin, la virtualisation des serveurs permet une bien plus grande modularité dans la répartition des charges et la reconfiguration des serveurs en cas d'évolution ou de défaillance momentanée. Les intérêts de la virtualisation sont multiples. On peut citer : L'utilisation optimale des ressources d'un parc de machines (répartition des machines virtuelles sur les machines physiques en fonction des charges respectives) L'économie sur le matériel (consommation électrique, entretien physique, surveillance) 6.1.1 L'installation Le para virtualisation Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 22 Cloud Computing Le para virtualisation est une technique de virtualisation qui présente à la machine invitée une interface logicielle similaire mais non identique au matériel réel. Ainsi, elle permet aux systèmes d'exploitation invités d'interagir directement avec le système d'exploitation hôte et donc ils seront conscients de la virtualisation. 6.1.2 La virtualisation complète La virtualisation complète (en anglais full-virtualization) est une technique de virtualisation qui permet de créer un environnement virtuel complet. En utilisant cette technique, le système d'exploitation invité n'interagit pas directement avec le système d'exploitation hôte et donc il croit s'exécuter sur une véritable machine physique. Cette technique de virtualisation ne permet de virtualiser que des SE de même architecture matérielle que l'hôte. 6.2 Solutions de virtualisation Dans cette section, nous présentons les outils de virtualisation les plus utilisés qui sont Xen, KVM, VMware et HyperV : Xen : est une solution libre de virtualisation permettant de faire tourner plusieurs systèmes d'exploitation sur une même machine physique. Il est de type hyperviseur, c'est à dire qu'il vient s'insérer entre le matériel et le noyau. Xen est considéré comme une solution à base de para virtualisation, car les systèmes invités doivent être modifiés pour cohabiter. KVM : est un projet de virtualisation complète qui est actuellement en développement pour un module de para virtualisation. Il est intégré depuis le noyau Linux 2.6.20 et permettant une virtualisation matérielle des processeurs. Ainsi, il ne fonctionne que sur un processeur de type Intel VT ou AMD-V. VMware : est une société qui offre des produits propriétaires liés à la virtualisation d'architectures x86. Elle est leader dans le marché de la virtualisation pour PC. Son produit de virtualisation VMware Server est de type virtualisation complète pour serveur sous GNU/Linux et/ou Microsoft Windows. , tests, développements sans endommager le système hôte. HyperV : est une solution de virtualisation basée sur la virtualisation 64 bits pour Microsoft. Il est considéré comme une solution de para virtualisation. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 23 Etude Comparative et Choix de la Solution cloud Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 24 Etude Comparative et choix de la solution Cloud 1. Introduction Depuis ces dernières années, plusieurs projets autour du cloud computing ont vu le jour et donnée naissance à autant de plateforme d'administration dans le cloud. Dans cette section, nous étudions un extrait des solutions propriétaires et des solutions open sources. Les solutions open source ne fournissent que le support logiciel (et pas matériels) de la mise en place d'une véritable plateforme de cloud. 2. Le Cloud Computing et Acteurs Le marché du cloud computing est partagé entre acteurs : les éditeurs, les fournisseurs Editeurs : Les éditeurs sont les sociétés proposant des solutions Cloud. Un éditeur n'est pas forcément un fournisseur de services, autrement dit son périmètre n'est pas de fournir un service Cloud, mais plutôt de fournir une technologie capable d'héberger une solution Cloud Fournisseurs : Les fournisseurs de services de Cloud Computing sont des hébergeurs, Ils mettent à disposition des infrastructures physiques proposant une plate-forme de Cloud. Il serait bien trop conséquent d’analyser tous les acteurs du Cloud Computing présents sur le marché actuel. Nous survolerons les principaux acteurs:Salesforce.com, Amazon, Google, VMware et Microsoft : 2.1 . SALESFORCE Salesforce.com est une société créée en 1999 par Marc Benioff. Elle est devenue l'une des pionnières du modèle SaaS notamment grâce à son outil historique de «Customer Relationship Management»CRM intitulé Salesforce. 2.2 . Amazon Amazon, au travers d’ « Amazon Web Services » (AWS) met à disposition un Cloud public depuis 2006. Au départ, il s'agissait de rentabiliser leurs énormes infrastruct ures en place pour absorber les pics de charge lors des fêtes de Noël sur leur boutique en ligne. Aujourd'hui, Amazon propose un service d’IaaS avec « EC2 » (Elastic Compute Cloud) et différents PaaS liés ou non à leur boutique. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 25 Etude Comparative et choix de la solution Cloud 2.3 Google En 2008, Google a lancé son Cloud public orienté pour les services Web offrant une plate forme (PaaS) nommée « Google App Engine » et permettant l'hébergement d'applications Python ou Java, ainsi que des applications SaaS regroupées dans la gamme « Google App ». 2.4 VMware VMware est une entreprise filiale d’EMC créée en 1998 à Palo Alto. Pendant plus de 10 ans, elle a conçu différents produits liés à la virtualisation. En 1999 apparaissait la première version de VMware Workstation, un logiciel client permettant la virtualisation de machines virtuelles. D'autres éditions comme la gamme ESX ou Server (anciennement GSX) proposent des solutions de virtualisation pour les serveurs. Depuis 2008, VMware n'a cessé d'investir dans le marché du Computing, en rachetant différentes entreprises comme Zimbra (application SaaS de collaboration) ou SpringSource pour son offre PaaS avec vFabric. 2.5 . Microsoft Microsoft annonçait l'arrivée de sa propre solution de Cloud Computing nommée Windows Azure. Cette dernière a été rendue commerciale en janvier 2010, Le Cloud de Microsoft s'est aussi des applications SaaS de la gamme Live et Online Service 3. Solution open source 3.1 OpenNebula 3.1.1 Présentation OpenNebula voit le jour en 2005 à l'université Complutense de Madrid dans le cadre du projet européen open source RESERVOIR. Son objectif dans le cadre de ce projet est l'administration des IaaS virtualisés. Autrement dit, il fournit des services permettant de déployer et d'exécuter dans un environnement matériel virtualisé des VM. Notons qu'une version commerciale d'OpenNebula (OpenNebulaPro) est disponible depuis 2010. Dans sa version actuelle, OpenNebula est capable de prendre en compte simultanément dans l'IaaS des hyperviseurs Xen, kvm et VMware. Il organise l'IaaS sous forme de clusters et de VLAN (réseaux virtuels). Un cluster contient un ensemble de machines physiques tandis qu'un VLAN est défini pour un ensemble de VM. Lors de la création d'une VM, le client choisit la machine et le VLAN dans lequel il souhaite l'exécuter. Notons que dans l'esprit du cloud, il ne revient pas au client de choisir la machine sur laquelle il souhaite exécuter sa VM. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 26 Etude Comparative et choix de la solution Cloud Toutes les opérations d'administration sont coordonnées à partir d'une unique machine de l'IaaS appelée Frontend. 3.1.2 Composants Les composants d'Open Nebula peuvent être divisés en trois couches : Tools : c'est l'ensemble des outils de gestion pour OpenNebula ; Core: il se compose d'un ensemble de composants pourcontrôler les machines virtuelles, le stockage et le réseau virtuel ; Drivers : l'interaction entre OpenNebula et l'infrastructure de Cloud est effectuée par des pilotes spécifiques qui sont les drivers. Les machines Front end et Node sont reliés entre eux à travers un réseau privé. Figure 4:architecture OpenNebula 3.2 OpenStack 3.2.1 Présentation Créé en juillet 2010 par la NASA et l'hébergeur américain Rackspace, OpenStack est une offre d'IaaS 100% open-source encore en développement qui a livré son code source récemment et qui permet aux sociétés de développer leurs propres solutions d’infrastructure du Cloud Computing. Plus que trente fournisseurs soutiennent ce projet tels que : A MD, Intel, Dellet Citrix. OpenStack devrait également être intégré dans les prochaines versions d'Ubuntu comme c'est le cas pour Eucalyptus. Il comprend le logiciel OpenStack Compute pour la création automatique et la gestion de grands groupes de serveurs privés virtuels et le logiciel OpenStack Stockage pour optimiser la gestion de stockage, répliquer le contenu sur différents serveurs et le mettre à disposition pour une utilisation massive des données. 3.2.2 Composant d’openstack Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 27 Etude Comparative et choix de la solution Cloud OpenStack s'organise autour de trois composants et des API qui leur permettent de communiquer (figure 10) OpenStack Nova : Il fournit les fonctionnalités de gestion du cycle de vie des VM (via le sous composant nova-compute), du réseau (via nova-network) et des authentifications. Il implante également les programmes de scheduling de VM à travers son composant nova- Scheduler. Son sous composant Queue Server implante le mécanisme de dispatching de requêtes aux autres sous composants en fonction des actions qu'elles requièrent. OpenStack Swift : permet de créer un service de stockage dans une architecture de cloud computing. Il permet de gérer une large capacité de stockage évolutive avec une redondance ainsi que le basculement entre les différents objets de stockage. OpenStack Imaging Service : OpenStack Imaging Service est un système de récupération et de recherche d'images de machines virtuelles. Figure 5:Architecture d’Openstack 1.1 Eucalyptus 1.1.1 Présentation Issue d’un projet de recherche de l’université de Californie, cette plate-forme cloud open source est certainement la plus connue, car intégrée dans Ubuntu Server et Debian. Ecrite en C, Java et Python, elle permet de créer des clouds Iaas (Infrastructure as a service) de type privé ou hybride, supporte des machines virtuelles Linux ainsi que les hyperviseurs Xen et KVM. Par ailleurs, elle est compatible avec EC2 d’Amazon. Il existe également une version Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 28 Etude Comparative et choix de la solution Cloud propriétaire commercialisée par la société Eucalyptus Systems. Il apporte des fonctionnalités supplémentaires comme le support de VMware, celui des machines virtuelles Windows et l’intégration SAN. 1.1.2 Composants Une configuration de cloud fondée sur Eucalyptus se compose de cinq types de composants principaux. Cloud Controller : c'est l'unique point d'entrée (Front end) pour tous les utilisateurs et les administrateurs d'Eucalyptus. Il est responsable de la gestion de tout le système. Surveiller la disponibilité des ressources sur les différentes composantes de l'infrastructure du cloud. Node Controler : Le rôle du node est d'héberger KVM, il sert ainsi d'hyperviseur pour les machines virtuelles qui sont déployées. Les machines virtuelles fonctionnant sur l'hyperviseur sont appelées des instances. Eucalyptus permet aussi d'utiliser d'autres types d'hyperviseurs comme XEN 3, mais Canonical a fait le choix de privilégier KVM. Le contrôleur de node fonctionne sur chaque node et est chargé de vérifier le cycle de vie des instances en cours d'exécution sur le node. Cluster Controller : Ce contrôleur sert à déployer et gérer les différents contrôleurs de node. Il sert également à gérer la mise en place du réseau entre les instances des différents node. C'est lui qui communique l'ensemble des informations au contrôleur du cloud. Il reçoit les requêtes de déploiement des instances, décide sur quel contrôleur de node les instances seront déployé aussi il contrôle le réseau virtuel entre les instances. Walrus: Il assure 3 fonctions principales : Le stockage des images de machines virtuelles. Le stockage des images prises en fonctionnement à uninstant précis. Stocker des fichiers et les services Storage Controller: ce composant fonctionne avec le composant Walrus et permet de stocker les images des machines virtuelles et les données des utilisateurs Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 29 Etude Comparative et choix de la solution Cloud 1.2 Nimbus 1.2.1 Présentation Issu du monde de la recherche, Nimbus permet de déployer un cloud de type Iaas. Diffusée sous licence Apache 2.0, cette plate-forme supporte les hyperviseurs Xen et KVM, et peut s’interfacer avec le cloud d’Amazon, EC2. Elle est associée à autre projet, baptisé Cumulus, qui permet de déployer des services de stockage en cloud, compatible avec le service Amazon S3. Nimbus a été déployé, entre autres, par un réseau d’universités américaines qui proposent des clouds en libre accès pour des projets de recherche. 1.2.2 Architecture Nimbus comprend plusieurs composants qui peuvent être regroupés selon trois contextes comme le montre la figure 2.7. Ces composants sont reliés entre eux à travers un réseau privé. Client-supported modules : il est utilisé pour gérer les clients du Cloud. Il comprend le contexte client module, le Cloud client module, le référence client module et l'EC2 client module. Service-supported modules : il fournit tous les services du Cloud. Il comprend le contexte brocker module, le Web service resource Framework module. Backgroud resource management modules : son rôle est de gérer les ressources physiques du Cloud. Il comprend différents modules à savoir : workspace service manager module, IaaS gateway module, EC2 module, workspace pilot module,workspace ressource management module et workspace contrôler Figure 6: Architecture Nembus Mémoire Projet de Fin d’Etudes | Année Universitaire 2021- 2022 30 Etude Comparative et choix de la solution Cloud 4. Synthèse Tableau comparative détaillé des différentes solutions open source. Tableau 1 : Tableau Comparative des Solutions Open Source Eucalyptus Produit par But Architecture OpenNebula Nimbus OpenStack Apparu au début par l’université Santa Barbara de l’université de Californie Eucalyptus System Company L’union Européen ne Chercheurs de l’université dechicago Rackspace, NASA, Dell, Citrix, Cisco, Canonical et plus que 50 autres organisations Une réponse open source pour le Cloud commerciale EC2 Un Cloud privé pure Solution scientifique du Cloud Computing Créer et offrir des fonctionnalités de Cloud Computing en utilisant un logiciel open source fonctionnant sur du matérielstandard Hiérarchique Cinq composants Centrali sé Trois composants Centralis é Trois composants Intégration desdeux composants Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 31 Chapitre 2 : Etude Comparative et choix de la solution Cloud Domaine d’utilisation Supporte multiple cluster Minimum deux Serveurs Les entreprises Minimum deux serveurs Minimum deux serveurs OpenStack compute Les chercheurs dans le domaine de Cloud Computing et de la virtualisation Les communautés scientifiques (moins intéressés par les techniques internes du système) Les sociétés, les fournisseurs de services, les chercheurs et les centres de données mondiaux qui cherchent à grande échelle leurs Cloud privés ou publiques -Linux et récemment Windows -Exige x86 processor Linux (Ubuntu, Linux Systèmes d’exploitatio Fedora, CentOS, (Ubuntu, n supportés OpenSUSE et RedHat Debian) Entreprise Linux, Fedora et SUSE Linux Entreprise Server) Langage de Java, C et Java, Ruby et programmat Python C++ ion Walrus GridFTP, Stockage Comulus (version récente de GridFTP XCP Réseau Serveur DHCP Configuration installé sur le manuelle par cluster l’administrateu controller r EC2 WS API EC2 WS API Interface Outils tel que : OCCI API utilisateur HybridFox, ElasticFox Fichier zip Authentificatio Sécurité téléchargeable à n niveau travers utilisateur l’interface Web qui contient certificats Connexion HTTPS Sécurité Connexion SSH Root La plupart des distributions Linux Python et Java Python SCP SQLite3 OpenStack Storage Serveur DHCP installé sur chaque nœud OpenStack Compute EC2 WS API Nimbus WSRF Interface Web Certificat X509 -Certificat X509 Connexion SSL -Connexion Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 32 Etude Comparative et choix de la solution Cloud niveau administrate ur Root exigé seulement si nécessaire (selon les droits d’accès) Intègre Globus (certification) SSH Equilibrage de charge Le Cloud Controller Nginx Le context Broker Le Cloud Controller Tolérance aux pannes Séparation des clusters controllers Database backend (enregistre les informations des machines virtuelles) Vérification périodique des nœuds du Cloud Replication 5. Choix de la Solution Afin de caractériser chaque solution notre choix adéquat pour la construction d'un Cloud Prive Open Source, l’étude comparative de quatre solutions libre se basant sur les différents critères de classification suivantes : But : l'objectif à viser par la création de la solution. L'architecture : c'est la structure du système qui comprend les ressources matérielles et logicielles et l'interaction entre eux. Systèmes d'exploitation supportés : pour construire un Cloud Computing, on doit disposer d'un système d'exploitation qui gère les ressources physiques en permettant leur allocation et leur partage. Langage de programmation : il représente le langage de programmation avec lequel la solution est implémentée. L'interface utilisateur : l'interface utilisateur représente l'interface de communication entre l'utilisateur et le Cloud. Tolérance aux pannes : c'est la capacité d'un système à fonctionner malgré une défaillance d'un de ses composants. Emplacement des machines virtuelles : savoir l'emplacement des machines virtuelles permet de garantir une utilisation optimale des ressources. Migration des machines virtuelles : c'est le fait de déplacer des machines virtuelles d'un serveur physique à un autre. On distingue deux types de migration, à savoir la migration à chaud qui se fait lors de l'exécution des machines virtuelles et la migration à froid qui ne peut être réalisée qu'après l'arrêt de la machine virtuelle à déplacer. Cout de la solution : licence ((Licence Publique Générale\Linux) Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 33 Etude Comparative et choix de la solution Cloud Caractéristiques : Accès aux sources Communautés : Nombre des développeurs importants ayant comme rôle principal de faire remonter des dysfonctionnements et des suggestions. Dans les paragraphes précédents, nous avons présenté une liste de logiciels permettant decréer des solutions Cloud. Il est à présent question de faire le choix de celui qui nous convient le mieux. La solution que nous devons proposer doit être Facile à utilisation Facile à installer et déployer Sous licence libre Extensible S’adaptant à tous types d’infrastructures existantes Bien documenté Modulaire et innovante La solution qui répond à tous ces critères est OpenStack La figure ci-dessous présente le pourcentage d’utilisation du logiciel OpenStack par rapportaux autres solutions selon Zenoss.com. Figure 7: Pourcentage d’utilisation d’OpenStack dans le monde Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 34 Etude Comparative et choix de la solution Cloud Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 35 Conteneurisation & Docker Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 36 Conteneurisation & Docker 1. Introduction : Une machine virtuelle (VM - Virtual Machine) "imite" intégralement un serveur où chaque VM "invitée" contient un système d'exploitation complet, avec ses pilotes, fichiers binaires ou bibliothèques, ainsi que l'application elle-même. Chaque VM s'exécute alors sur un hyperviseur, qui s'exécute à son tour sur un système d'exploitation hôte. Bien que la méthode ait fait ses preuves, on s'aperçoit aisément que cela entraine le gaspille de la mémoire du serveur et limite forcément le nombre de VM prises en charge par chaque serveur. Ce qui pour certains remet en cause le futur de cette technologie. Une approche qui a fait ses preuves face au gaspillage des ressources est le concept de conteneurisation où chaque conteneur ne renferme que l’application et les fichiers binaires ou bibliothèques associées. L’idée globale consiste donc à utiliser le même système d'exploitation OS (operating system) hôte pour plusieurs conteneurs, au lieu d'installer un OS (et d'en acheter la licence) pour chaque VM invitée. Le rôle de l'hyperviseur est alors assuré par un moteur de conteneurisation, tel que Docker, qui s'installe par-dessus le système d'exploitation hôte. Lors de ce chapitre nous allons présenter Docker, ses différents composants et comprendre ce qu’est la conteneurisation. 2. Présentation : Docker est une plate-forme logicielle qui permet de concevoir, tester et déployer des applications rapidement. Docker intègre les logiciels dans des unités normalisées appelées conteneurs, qui rassemblent tous les éléments nécessaires à leur fonctionnement, dont les bibliothèques, les outils système, le code et l'environnement d'exécution. Avec Docker, il est facile de déployer et de dimensionner des applications dans n'importe quel environnement, avec l'assurance que le code s'exécutera correctement. 3. Historique : Docker a été développé par Solomon Hykes pour un projet interne de dotCloud, une société proposant une plate-forme en tant que service, avec les contributions d'Andrea Luzzardi et François-Xavier Bourlet, également employés de dotCloud, entreprise française. Docker est une évolution basée sur les technologies propriétaires de dotCloud, elles-mêmes construites sur des projets open source. Docker a été distribué en tant que projet open source à partir de mars 2013. En 2019 est annoncée la version 3 de la plateforme Docker lors de la conférence DockerCon 2019. 4. Docker Engine (moteur de Docker) : Docker Engine est la technologie client-serveur sous-jacente qui crée et exécute des conteneurs à l'aide des composants et services de Docker. Docker Engine fournit : Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 38 Conteneurisation & Docker Un serveur qui est un type de programme de longue durée appelé processus de démon, qui joue le rôle de création et de gestion des objets Docker tels que images, conteneurs, réseaux et volumes de données. Une API REST qui spécifie les interfaces que les programmes peuvent utiliser pour parler au démon et lui indiquer ce qu'il faut faire. Une ligne de commande client CLI (Command-line Interface) qui permet aux utilisateurs d’interagir avec le démon. Figure 8: Docker Engine 5. Architecture Docker : L'architecture Docker utilise un modèle client-serveur et comprend les composants Docker Client, Docker Host et Docker Registry. Figure 9: Architecture Docker 5.1 Docker Client Le client Docker permet aux utilisateurs d'interagir avec Docker. Le client Docker peut résider sur le même hôte que le démon ou se connecter à un démon sur un hôte distant. Un client docker peut communiquer avec plusieurs démons. Le client Docker fournit une interface de ligne de commande (CLI) qui permet d'émettre des commandes de génération, d'exécution et d'arrêt sur un démon Docker. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 39 Conteneurisation & Docker Le principal objectif du client Docker est de fournir un moyen de diriger l'extraction d'images d'un registre et de l'exécuter sur un hôte Docker. Les commandes courantes émises par un client sont : docker build : permet de créer une nouvelle image. docker pull : permet de récupérer une image du registre. docker run : permet d’exécuter une image. 5.2 Docker Host Docker host fournit un environnement complet pour exécuter des applications. Il comprend le démon Docker, les images, les conteneurs, les réseaux et le stockage. 5.3 Docker Daemon Le docker Daemon est un service d'arrière-plan exécuté sur l'hôte qui est responsable de la création, du démarrage et du monitoring des conteneurs, mais aussi de la construction et du stockage des images. 5.4 Docker Images Les images Docker contiennent du code source d'application exécutable ainsi que tous les outils, bibliothèques et dépendances dont le code d'application a besoin pour s'exécuter en tant que conteneur. Lorsque l'image Docker est exécuté, elle devient une instance (ou plusieurs instances) du conteneur. Il est possible de créer une image Docker à partir de zéro, mais aussi l’obtenir depuis des référentiels courants. Plusieurs images Docker peuvent être créées à partir d'une seule image de base et partagent les points communs de leur pile. 5.5 Docker Container Un conteneur Docker est une instance exécutable d'une image Docker. Un conteneur peut être exécuter, démarrer, arrêter, déplacer ou supprimer à l'aide des commandes Docker. Chaque conteneur est une plate-forme d'application isolée et sécurisée, mais peut avoir accès à des ressources fonctionnant dans un hôte ou un conteneur différent. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 40 Conteneurisation & Docker Figure 10: Principe du conteneur Docker 5.6 Registre Docker : Un registre docker est une bibliothèque d'images qui peut être public ou privé, il permet de fournir des emplacements afin de stocker et télécharger les images Docker. 6. Avantages de Docker Simple à installer : les conteneurs sont lancés à partir d’images portables contenant un programme unique de serveurs et les différents fichiers nécessaire à l’installation (librairies, programmes d’aide, données de configuration). L’installation se fait via une seule ligne de commande. Applications isolées : chaque application contenue dans un conteneur fonctionne indépendamment des autres conteneurs présents sur le même système d’exploitation. L’avantage est donc de pouvoir gérer plusieurs applications n’ayant pas les mêmes contraintes et exigences. Faible consommation de ressources : les containers partagent les ressources avec le système d'exploitation, ce qui permet de les rendre plus efficaces. Les containers permettent de diminuer le temps de démarrage, diminuer l'espace de stockage et la consommation du processeur, par rapport au système traditionnel de machines virtuelles. Meilleure gestion des applications : le fait d’intégrer une application dans un conteneur permet de faciliter le déploiement, la gestion des retours à une version antérieure ou encore la résolution des problèmes. Une accélération du déploiement des applications : Les conteneurs disposent d'un environnement d'exécution minimal pour les applications, réduisant leur taille Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 41 Conteneurisation & Docker et permettant un déploiement plus rapide. 7. Inconvénients de Docker Faille dans le noyau : Contrairement à une machine virtuelle, le noyau est partagé entre tous les conteneurs et le système hôte. Si un conteneur provoque une panique du noyau, il emportera tout le système hôte. Images empoisonnées : Si un attaquant réussit tromper l’utilisateur lors de l’exécution d’une image, le système hôte et les données sont en danger. Impossible d’utiliser des OS différents sur un même serveur physique ce qu’est possible avec la virtualisation classique. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 42 Software Defined Networking Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 43 Software Defined Networking 1 Introduction Avec l’évolution du Cloud Computing, le sujet le plus important en matière de réseaux est le Software Defined Networking (SDN). Cette technologie permet d’avoir une architecture automatisée, programmable et qui peut être mise en place via divers protocoles. Dans ce chapitre, nous allons tous d’abord donner un aperçu global sur la technologie SDN et son architecture, ensuite nous présenterons le protocole OpenFlow et enfin nous terminerons avec quelques contrôleurs SDN. 2 Définition SDN SDN est une technologie qui rend le réseau programmable. Il présente une architecture réseau où le plan de contrôle est totalement découplé du plan de données. Le plan de contrôle gère la gestion des périphériques réseau, tandis que le plan de données est la couche matérielle responsable du transfert des paquets selon les règles définies dans le plan de contrôle. Ce découplage transforme les commutateurs/routeurs en simples dispositifs de transfert, tandis que l’entité logique est implémentée dans le contrôleur qui fonctionne comme un système d'exploitation réseau centralisé. 3 Architecture SDN SDN est basée sur une architecture hiérarchique de trois couches. Couche application : Cette couche regroupe un ensemble d’applications, qui interagit directement avec chaque équipement via des API. De telles applications peuvent, par exemple, implémenter des parefeu, des politiques de routage ou des équilibreurs de charge. Couche du plan de contrôle : Cette couche est considérée comme le noyau du SDN. Elle est constituée d’un ensemble de contrôleurs. Ces derniers traduisent la requête envoyée par l’application afin d’établir des règles de traitement des données, qui seront injecter par la suite au niveau de chaque équipement du réseau. Couche du plan de données : Cette couche est constituée d’un ensemble d’équipements réseaux qui peuvent être physiques ou logiciels, souvent appelés, les équipements de diffusion qui assurent uniquement Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 44 Software Defined Networking L’envoi et la réception des données en respectant l’acheminement, définit par le contrôleur de la couche de contrôle. 4 Interface de communication North bound API : Elle permet la communication et l’échange de données entre le contrôleur SDN et les applications du réseau. South bound API : Elle fait référence aux différentes APIs qui permettent les communications entre les équipements de plan de contrôle et ceux du plan de données. 5 OpenFlow OpenFlow est un standard de communication basé sur le concept des Software-Defined Networking géré par l'ONF (Open Networking Foundation). Il standardise l'interface entre le contrôleur et les périphériques de transfert dans le but de transmettre aux commutateurs des instructions qui permettent de programmer leur plan de données et par conséquent l'obtention des informations de ces derniers afin que le contrôleur puisse avoir une vue globale logique du réseau physique. 5.1 Les structures de données OpenFlow : Un commutateur OpenFlow se compose d'une ou plusieurs tables de flux (pipeline) et d'une table de groupe, qui effectuent des recherches de paquets et le transfert, et un canal OpenFlow vers un contrôleur externe. Le commutateur communique avec le contrôleur et ce dernier gère le commutateur via le protocole OpenFlow comme le montre la figure suivante [18] : Figure 11: Architecture OpenFlow Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 45 Software Defined Networking Une table de flux "Flow Table" est constituée de plusieurs entrées de flux, chacune est structurée comme suit : Match fields : il se compose du port d’entrée et des en-têtes de paquets, et éventuellement d’autres champs tels que les métadonnées spécifiées par d’autres tables du pipeline. Priority : correspond de priorité de l'entrée du flux. Counters : il est mis à jour lorsqu’une correspondance avec un paquet est trouvée. Instructions : Ce champ sert à spécifier des actions à exécuter si une correspondance est trouvée. Timeouts : durée maximale ou temps d'inactivité avant l'expiration du flux par le commutateur. Cookie : utilisé par le contrôleur pour filtrer les entrées de flux affectées par les statistiques, les demandes de modification et de suppression de flux. 5.2 Les messages OpenFlow : L'échange d'informations entre le commutateur et le contrôleur s'effectue par l'envoi de messages via un canal de contrôle sécurisé en utilisant TLS (Transport Layer Security). Le protocole OpenFlow dans l’Architecture SDN prend en charge trois types de message : symétrique, asynchrone et messages contrôleur vers switch. 5.2.1 Messages symétrique Les messages symétriques sont envoyés sans sollicitation, dans les deux sens. Message HELLO : les messages Hello sont échangés entre le commutateur et le contrôleur au démarrage de la connexion. Message ECHO : les messages de request/reply peuvent être envoyés par le commutateur ou le contrôleur, et doivent retourner une réponse Echo. Ils sont principalement utilisés pour vérifier la vivacité d’une connexion contrôleurcommutateur, et peut aussi bien être utilisé pour mesurer sa latence ou sa bande passante. Message ERROR : les messages d’erreur sont utilisés par le commutateur ou le contrôleur pour signaler les problèmes à l’autre côté de la connexion. Ils sont principalement utilisés par le commutateur pour indiquer un échec d’une demande lancée par le contrôleur. 5.2.2 Messages Asynchrones Les messages asynchrones sont envoyés sans qu’un contrôleur les sollicite à partir d’un commutateur. Les commutateurs envoient des messages asynchrones aux contrôleurs pour indiquer l’arrivée ou le changement d’état d’un paquet. Packet-In : Il est utilisé par le commutateur pour envoyer les paquets de données au contrôleur afin de déléguer au contrôleur la décision quant au transfert du paquet. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 46 Software Defined Networking Flow-Removed : informe le contrôleur de la suppression d’une entrée dans la table de Flux. Port-Status : est utilisé afin de communiquer un changement de configuration du port ou changement d’état du port. Messages contrôleur vers switch : Ils sont initiés par le contrôleur et utilisés pour gérer ou vérifier l'état du commutateur. Ce type peut demander une réponse de la part du commutateur. Packet-Out : le contrôleur utilise Packet_Out afin d’émettre des paquets de données au commutateur pour leur acheminement. Modify-State : les messages de modification d’état sont envoyés par le contrôleur pour gérer l’état sur les commutateurs. Leur objectif principal est d’ajouter, supprimer ou modifier dans les tables de flux. Read-State : sont utilisés par le contrôleur pour recueillir diverses informations du commutateur, telles que la configuration actuelle, les statistiques et les capacités. 5.3 Fonctionnement OpenFlow Lorsqu’un paquet arrive à un commutateur, ce dernier vérifie s'il y a une entrée dans la table de flux qui correspond à l'en-tête de paquet. Si c'est le cas, le commutateur exécute l’action correspondante dans la table de flux. Dans le cas contraire, le commutateur génère un message asynchrone vers le contrôleur sous la forme d’un "Packet_in ", puis le contrôleur décide selon sa configuration une action pour ce paquet, et envoie une nouvelle règle de transmission sous la forme d’un "Packet_out" et "Flow-mod " au commutateur, et enfin, la table de flux du commutateur est mise à jour, pour prendre en compte la nouvelle règle installée par le contrôleur. 6 Contrôleurs SDN Avec l'explosion de la technologie SDN, un nombre important de contrôleurs a vu le jour. Ces contrôleurs diffèrent par leurs langages de programmation, la version d'OpenFlow et l’architecture de SDN supportée ainsi que les performances comme le débit. Parmi les contrôleurs existants, on trouve : NOX et POX : NOX est le premier contrôleur OpenFlow qui a vu le jour. Il a été à la base de nombreux projets de recherche et développement dans les débuts de l'exploration de l'OpenFlow et du SDN. Il est développé en C++, il fournit une API pour le développement avec le Python. POX quant à lui, est une variante du NOX écrite en Python, c’est une plate-forme de développement open source utilisée pour développer des applications de contrôle des réseaux définis par logiciel. Floodlight : Floodlight est un contrôleur open-source, il offre un point de gestion central pour les réseaux OpenFlow basé sur Java, pris en charge par BIGSwitch Networks. Il est sous licence Apache. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 47 Software Defined Networking Ryu : Le terme RYU vient d'un mot japonais qui signifie "flux". Ce contrôleur est bien connu dans le monde de la programmation Python. Tout son code est disponible gratuitement sous licence Apache 2.0. Il supporte jusqu’à la dernière version d’OpenFlow. ONOS (Open Network Operating System): Il s’agit d’un système d’exploitation réseau ou d’un contrôleur SDN récemment libéré qui se concentre sur les cas d’utilisation des fournisseurs de services, il assure l'évolutivité, la haute disponibilité, la performance et des abstractions pour faciliter la création des applications et des services. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 48 Conception Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 65 Conception 1. Introduction Au cours de ce chapitre on se basera sur la solution Cloud choisi, ainsi que son architecture suivie d’une étude détaillée sur les différents services qui ont permis de faire le choix d'entre eux pour pouvoir réunir les technologies vues précédemment. 2. Les besoins Le besoin identifié pour ce projet est de promouvoir un contrôleur SDN sous forme d’un service aux clients, de la manière la plus optimale en terme de coût et consommation de ressources, et cela afin d’aller vers une architecture réseau centralisée, managée par un seul contrôleur. Toutefois ces mêmes clients veulent se concentrer sur leurs métiers de base et ne pas fournir plus du temps, d’énergie et d'argent en acquérant et administrant une nouvelle plateforme IT. Par conséquent, la solution proposée est d’implémenter une plateforme Cloud Computing pour fournir des contrôleurs SDN sous forme de conteneur Docker. 3. Choix de la plateforme Cloud Les buts définis plus haut sont la clé majeure qui nous mène au choix optimal de la plateforme cloud à déployer qui doit être : Open source. Aucun cout de licence. Haute disponibilité des services. Intégration avec des outils tiers (Docker, Kubernetes …). Bien documenté. La solution qui s’adapte aux besoins de notre projet est Openstack, ce dernier est une plateforme de Cloud Computing évolutive et open source, la plus utilisée dans ces dernières années. Et ceci est dû à sa flexibilité, scalabilité et de nombreux autres avantages. Architecture d’installation : La difficulté liée à l’installation d’Openstack réside dans la complexité de son architecture, du fait que chaque service comporte plusieurs processus qui doivent communiquer ensemble à travers un courtier de message AMQP, tout en s’authentifiant par un service central (Keystone). En outre, l’état des services et d’autres informations correspondant au cloud déployé sont stockés dans une base de données. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 66 Conception La seconde difficulté vient du fait qu’une telle architecture doit être définie auparavant en fonction de ressources disponibles, parmi de nombreuses architectures nous citons à titre d’exemple : Un seul nœud (All in one): Un seul serveur exécute tous les services Openstack et également conduit toutes les instances virtuelles. Deux nœuds : Il se compose de deux serveurs, en premier le contrôleur qui exécute les services : d'identité, d'image, les parties de gestion de compute, la partie de gestion du réseau ainsi que ses divers agents et le tableau de bord, il comprend également des services de prise en charge tels qu'une base de données et une file d'attente de messages, en second le compute qui exécute la partie hyperviseur et gère les instances. Il exécute également un agent de service de mise en réseau qui connecte les instances aux réseaux virtuels et fournit des services de pare-feu aux instances via des groupes de sécurité. Plusieurs nœuds : Il comprend au minimum trois nœuds qui sont le contrôleur, le compute et le nœud de stockage (Object storage ou Bloc storage). Choix de l’architecture d’installation : On opte pour une architecture All in one qui regroupe tous les services dans un environnement de test. Cette architecture comportera une interface réseau eth0 relié à un réseau externe qui sert à la connectivité internet. Le choix d’un réseau LAN est dû à quelques problèmes de connectivité que nous avons affrontés lors de la phase du déploiement, cela sera expliquer dans le chapitre qui se suit. Figure 23: Architecture d'installation Openstack. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 67 Conception 4. Services de conteneurisation Openstack : En tant que technologie émergente dans le Cloud Computing, Docker devient de plus en plus populaire en raison de sa grande efficacité et de sa portabilité. L'intégration de Docker avec Openstack a été un sujet brûlant dans les domaines de la recherche et de l'industrie [24]. Il existe plusieurs projets, qui répondent à ce besoin. Nous présenterons quelques services que nous avons jugés crucial dans l’étape de l’intégration de docker dans Openstack : Nova docker : Nova-docker est un pilote d'hyperviseur pour Openstack Nova Compute. Il a été introduit pour la première fois avec la version Havana, mais il était également en cours de développement pour Icehouse, Juno et Kilo. Dans ce qui suit nous illustrons le fonctionnement de Nova docker : Pour mettre en place les conteneurs, le pilote Nova compute est pointé sur le pilote Docker comme mentionné dans le schéma ci-dessous. Le pilote Nova Docker Virt communique avec l'agent Docker en utilisant des appels api http. Les images de Docker sont stockées dans le registre Docker et les images sont exportées pour être consultées à partir du registre Docker que Nova utilise pour créer les conteneurs Figure 24:Architecture de nova-docker Ce service n’est malheureusement plus maintenu par la communauté Openstack. Zun : Zun gère le conteneur comme une sorte de ressource Openstack, Il fournit l'API nécessaire pour le déploiement et la gestion des conteneurs en utilisant diverses technologies de conteneurs. Zun a été intégré à plusieurs services d'Openstack. Keystone, Neutron et Kuryrlibnetwork sont des services nécessaires au fonctionnement de Zun. Ils fournissent à ce dernier l'authentification, le réseau, la connexion entre les réseaux de neutrons et de docker. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 68 Conception Pour faire fonctionner un container, Zun nécessite au moins deux nœuds (nœud contrôleur et nœud de calcul). Le diagramme ci-dessous illustre la relation entre les composants Zun et Openstack. Figure 25:Architecture Zun Zun API : Traitement des demandes REST et vérification des paramètres d'entrée. Zun Compute : Planification des ressources et gestion des conteneurs. Glance : Stockage d'images de docker (si glance n'est pas utilisé, l’alternative sera DockerHub). Magnum : Magnum est un service de gestion de l'infrastructure des conteneurs pour Openstack, il fournit des API pour déployer les clusters Kubernetes, Swarm et Mesos sur l'infrastructure d'Openstack. Magnum déploie des VM ou bare-metal via l’orchestrateur Heat, afin de former un cluster, puis invoque l'interface COE (Container Orchestration Engine) pour compléter le déploiement du conteneur. Il existe plusieurs types d'objets dans le service magnum : Cluster : Une collection d'objets nœuds. Cluster Template : Un objet stocke des informations sur le modèle de cluster qui est utilisé pour créer de nouveaux clusters de manière cohérente. Pod : collection de conteneurs fonctionnant sur un bare-metal ou machine virtuelle. Service : Une abstraction qui définit un ensemble logique de pods et une politique permettant d'y accéder. Conteneur : Un conteneur Docker. Deux binaries travaillent ensemble pour composer le service magnum. Le premier est le serveur REST de magnum-api, Ce dernier peut s'exécuter en tant que processus unique ou en tant que multiples processus. Lorsqu'une requête REST est envoyée à l'API du client, la requête est transféré via AMQP au processus magnum-conducteur qui assure la coordination et le support d'interrogation des bases de données pour Magnum, il sélectionne le pilote de cluster et envoie par la suite les fichiers de template au service Heat pour effectuer l'installation, et enfin met à jour la base de données avec les détails des objets. Le diagramme ci-dessous montre les différents composants de Magnum, les autres projets Openstack auxquels ils communiquent et l'infrastructure prévue pour son fonctionnement. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 69 Conception Figure 26: Architecture Magnum Choix de service : Compte tenu des schémas d'intégration existants (Nova-docker et Zun), qui souffrent d'un déploiement lent, d'un faible débit de conteneurs, d'un manque de prise en charge des limitations de ressources, d'une allocation de ressources déraisonnable et d'une grave dégradation des performances de conteneurs dans le cadre de la concurrence des ressources, par conséquent, magnum demeure la meilleure solution comparant aux précédentes et réponds au mieux aux objectifs de ce projet. 5. Choix du contrôleur SDN Une multitude de choix d’images est offerte par docker hub à ses utilisateurs afin de profiter aux avantages de la conteneurisation. Malgré la diversité que Docker hub nous prodigue, il a été difficile de trouver l’image du contrôleur SDN, qui convient le mieux à notre environnement et qui ne pose pas de problème lors de son importation. Pour nos premiers pas nous avons testé plusieurs contrôleurs, mais des anomalies sont apparus lors de l’importation de l’image, c’est ce qui nous a mené à opter pour le contrôleur ONOS qui semble être l’idéal pour notre environnement. 5.1 Architecture de la solution : A travers les concepts théoriques vus précédemment, nous sommes arrivés à proposer une architecture afin de déployer et tester le contrôleur SDN sur la plateforme Openstack. 5.1.1 Architecture réseau : Notre architecture réseau se compose d’un cluster qui regroupe deux instances, dont un master et un worker attachés à un réseau privé 10.10.0.0/24, ce dernier est lié à un routeur virtuel qui est à son tour relié au réseau externe 192.168.1.0/24, et permet la connectivité des VMs au monde extérieur. Afin d’assurer la connectivité de l’extérieur vers les VMs, nous devons associer une adresse ip flottante à ces dernières dans la plage d’adressage 192.168.1.0/24. Afin d’avoir une vision claire sur l’architecture proposée, nous illustrons la figure ci-dessous. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 70 Conception Figure 27:Architecture réseau. 5.1.2 Vue d’ensemble de l’utilisation du cluster : L’architecture générale que nous avons conçue et qui met en œuvre cette plate-forme est illustrée dans la figure 4.8. Elle se compose d’un cluster swarm créé auparavant par l’admin, dont le master est utilisé pour envoyer les tâches au nœud worker. Lors de la réception des tâches par le worker, ce même nœud execute les actions requises, telles que le démarrage ou l’arrêt d’un conteneur. Cela nous offre la possibilité de déployer le contrôleur SDN sur la plateforme Openstack. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 71 Conception Figure 28: Architecture de déploiement Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 72 Déploiement Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 73 Déploiement 1. Introduction On s’intéresse ici, aux principales étapes d’installation d’Openstack. On commence par la préparation du système, sur lequel sera implémentée cette solution 2. Environnement de travail Cette section présentera l'environnement matériel et logiciel dans lesquels notre plateforme sera déployée. 2.1 Environnement matérielle Les caractéristiques de la machine utilisée durant toute la phase de configuration et déploiement sont : 1.1.1 1.1.2 1.1.3 1.1.4 Machine : Dell Mémoire RAM : 12 Go Disque dur : 500 Go HDD Processeur : Intel® Core™ i5-4200U CPU @ 1.60 GHZ 2.2 Environnement logiciel Au lieu d’installer OpenStack directement sur la machine hôte, le logiciel Virtualbox sera utilisé pour créer une machine virtuelle, sur laquelle seront installés les composants d’Openstack. 3. Installation Openstack Openstack est une plateforme qui a fait un énorme bruit au sein de la communauté cloud lors de son lancement, en ce qui concerne l’installation et la maintenance, de divers tutoriels et vidéos ont ouvert la voie aux personnes qui veulent maitriser une nouvelle technique, mais malheureusement cela n’était pas à l’accès de tout le monde du fait qu’Openstack est un outil complexe qui demande du temps et de la bonne maitrise des concepts réseaux et système. 3.1 Méthode d’installation L’installation d’OpenStack peut se faire de deux (2) Manières : Single Node (” All in One”) Deployments. Multi Node. Nous allons installer Openstack sur une seule machine. Openstack propose aussi plusieurs types d’installation : Installation via Packstack. Installation via des scripts. Installation via les packages. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 74 Déploiement Pour la réalisation de notre plateforme, nous allons choisir l’installation via Packstack. Packstack : est un outil d'installation pour Openstack destiné aux déploiements de démonstration et de test, mais n’est absolument pas mise en production. 3.2 Choix de la distribution Openstack propose dans sa documentation des guides d’installation pour les distributions suivantes : 3.2.1 3.2.2 Red Hat Entreprise Linux 7 / CentOS 7. Red Hat Entreprise Linux 8 / CentOS 8. Notre choix s’est porté sur Centos 7, car ce dernier est le plus simple a utilisé avec Openstack. 3.3 Configuration de VirtualBox Après l’installation de VirtualBox nous allons configuré la machine virtuelle comme suit : 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 3.3.7 Nom : centos_2 Type de système d’exploitation : Linux. Version : RedHat 64 bit. Mémoire RAM : 10 Go. Disque : 75 Go. Activer le mode Nested VT-x/AMD-V. Réseau : Bridge Figure 7.1 : Configuration network sur VirtualBox. 3.4 Etape d’installation Openstack : Après avoir configuré la machine virtuelle, notre environnement est maintenant près pour l’introduction des étapes suivantes : Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 75 Déploiement 3.4.1 Désactiver le pare-feu : Figure 7.2 : Désactivation du pare-feu. 3.4.2 Désactiver le NetworkManager : 3.5 Figure 7.3 : Désactivation du NetworkManager. 3.5.1 Redémarrer le service réseau : Figure 7.4 : Redémarrer le service réseau. 3.5.2 Mettre à jour le système : Figure 7.5 : Mise à jour du système. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 76 Déploiement 3.5.3 Installer le package pour active le référentiel Openstack : Figure 7.6 : Installation du package Openstack. 3.5.4 Refaire la mise à jour du système : Figure 7.7 : Mise à jour du système. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 77 Déploiement 3.5.5 Installer Packstack : Figure 7.8 : Installation Packstack. 3.5.6 Avec la commande qui suit, nous aurons un fichier qui figurera dans le répertoire avecle nom answerFile et qui sera utilisé afin de configurer les mots de passes ainsi que l’installation de quelques services que nous verrons par la suite : Figure 7.9 : Génération du fichier answerFile. 3.5.7 Vue global sur le contenu de fichier généré « answer.txt » Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 78 Déploiement 3.5.8 Lancer la commande de l’installation : Figure 7.10 : Lancement de l’installation PackStack. 3.5.9 L’installation est enfin bien réussite Figure 7.11 : Installation avec succès. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 79 Déploiement 3.5.10 Accéder au Dashboard d’Openstack (Horizon) : L’accès se fait à travers lenavigateur web, en introduisant l’adresse 192.168.1.4, ainsi que le nom d’utilisateur « admin » et le mot de passe déjà configuré auparavant « secret ». Figure 7.12 : Dashboard Openstack. 3.6 Configuration d’OpenvSwitch OpenvSwitch est un projet open source qui permet de virtualiser la couche réseau, en fournissant la connectivité et la commutation Ethernet L2 au grand nombre de machines virtuelles. Dans Openstack, le nœud Neutron est le service qui exécute OpenvSwitch, et afin de répondre aux besoins de notre architecture réseaux déployé sur Openstack, l’étape de configuration d’OpenvSwitch demeure une étape cruciale pour la phase qui viendra par la suite. Pour configuré OpenVswitch on doit tout d’abord accéder au fichier ml2_conf.ini qui se trouve dans le chemin /etc/neutron/plugins/ml2. $packstack –allinone –os-neutron-l2-agent=openvswitch \ --os-neutron-ml2-mechanism-drivers=openvswitch \ --os-neutron-ml2-tenant-network-types=vxlan \ --os-neutron-ml2-type-drivers=vxlan, flat \ --os-neutron-ovs-bridge-mappings=extent:br-ex \ --os-neutron-ovs-bridge-interfaces=br-ex:eth0 Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 80 Déploiement 4. Création du cluster swarm Après avoir choisi l’orchestrateur swarm, nous procédons aux étapes suivantes afin de configurer notre environnement : 4.1 Configuration du cluster Avant la création du cluster swarm, il faut un OS sur lequel les instances (master et worker) doivent booter, pour notre cas ça sera l’image Fedora atomic avec l’extension QCOW2. Figure 7.13 : Téléchargement de l'image Fedora. Quand le téléchargement de l’image est effectué, l’étape de la création de l’image glance est initiée. Cette commande permet le stockage de l’image Fedora dans glance. Figure 7.14 : Création de l'image glance. La création d’une paire de clé ssh. Figure 7.15 : Création de la clé ssh. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 81 Déploiement Création du réseau publique de type plat, qui sera attaché au réseau externe. Figure 7.16 : Création du réseau publique. Création de sous-réseau tous comme une architecture réelle, nous devons créer un sous réseau publique 192.168.1.0/24, ce même sous-réseau est lié au réseau externe eten fait partie afin de permettre aux instances de se connecter au monde extérieur. Figure 7.17 : Création de sous-réseau. Quand a la création du routeur et le sous-réseau privé, nous avons fait appel à magnumqui gère ça automatiquement lors de la mise en œuvre du cluster, car la création manuelle nous a causé des anomalies. Création de template : Cette étape consiste au pré-déploiement du cluster, en spécifiant les exigences attribuées précédemment, ainsi que les gabarits personnaliséspour chaque nœud. m1.test : 1,5 GB de ram, 20GB de disque et 1 vCPU attribué au master. m2.test : 500GB de ram, 15GB de disque et 1 vCPU attribué au worker. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 82 Déploiement Ce choix est dû au manque de ressources. Figure 7.18 : Création de template. La figure 5.18 montre que la template a été bien créé. Figure 7.19 : Template du cluster. Création du cluster A travers la template créé, le cluster doté de deux nœuds (1master et 1 worker) peut enfin être déployer. Figure 7.20 : Création du cluster. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 83 Déploiement Figure 7.21 : Swarm cluster. 4.2 Topologie réseau du cluster : Après avoir réussi à mettre en place le cluster swarm, la figure 5.21 illustrera la topologie réseau qui donnera une vue globale sur la connection entre les nœuds du cluster. Figure 7.22 : Topologie réseau du cluster. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 84 Déploiement 5. Création de service et déploiement du conteneur Les conteneurs peuvent être déployés dans le swarm de la même manière que les conteneurs sont utilisés sur un seul hôte. Un service est créé et l'image qui doit être utilisée pour déployer le conteneur est spécifiée. Du moment où le service est lancé au niveau du master, le nœud worker prend automatiquement le relai et execute le conteneur (run). Afin d'assurer la haute disponibilité des conteneurs, le service swarm utilise une politique de réplication de conteneur sur tous les nœuds worker. Dans le cas où l'image utilisée n'est pas disponible dans le registre local, elle est automatiquement tirée du docker hub. Dans le but de déployer notre contrôleur ONOS, nous avons tenté de créer un service à travers la commande qui se suit : $ docker service create --name onos-test -p 6633:6633 -p 6640:6640 –p 8181:8181 -p 8101:8101 -p 9876:9876 onosproject/onos:1.14.0 L’accès au contrôleur doit se faire en exposant les ports spécifiques à ONOS qui sont : Port 6633 : port spécifique à OpenFlow. Port 6640 : port spécifique à OVSDB. Port 8181 : pour l’accès à l’interface graphique (GUI). Port 8101 : pour l’accès à la ligne de commande (CLI). Port 9876 : pour la communication intra-cluster ONOS. Malheureusement, les performances de la machine n’ont pas été en notre faveur, c’est pourquoi et pour des raisons de test, nous avons déployé le conteneur du contrôleur SDN (ONOS) au niveau du nœud master en utilisant les commandes Docker (pull et run). L’utilisation de l’outil d’émulation Mininet est nécessaire pour tester le bon fonctionnement du contrôleur. Mininet est un outil permettant l’émulation des réseaux classiques et SDN, fonctionne sur le noyau linux et propose une API très riche en fonctionnalités programmées en Python. 5.1 Test du contrôleur ONOS Au début de la phase du test, nous devons tout d’abord récupérer (pull) l’image ONOS du docker hub, cela est illustré dans la figure ci-dessous. Figure 7.23 : Récupération de l'image ONOS. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 85 Déploiement Lorsque la récupération de l’image est effectuée, nous exécuterons le conteneur du contrôleur ONOS et exposant les ports nécessaires pour pouvoir y accéder. Figure 7.24 : Exécution du contrôleur. La figure suivante montre l’interface graphique du contrôleur ONOS. Figure 7.25 : Interface graphique ONOS. Pour tester ce contrôleur nous avons opté pour une simple topologie qui se compose de deux hosts reliés à un switch sous mininet, tout cela est décrit par la figure 5.25. Figure 7.26 : Réseau mininet. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 86 Déploiement Figure 7.27 : Topologiemininet. Figure 7.28 : Topologiemininet.2 On voit bien à travers le test effectué que la communication entre toutes les machines. Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 87 Déploiement Les machines détectaient sur le contrôleur. On voit bien à travers le test effectué que la communication entre les deux machines h1 et h2 est bien fonctionnel. Figure 7.28: h1 ping h2. Figure 7.29: h2 ping h1 Conception et déploiement d’une plateforme Cloud pour fournir des conteneurs de service SDN 88
