Memoire Online - La qualité de service au niveau iaas: vers l'utilisation du concept software-defined networking (SDN)

Dès 1950, les utilisateurs accédaient depuis leurs terminaux à des applications fonctionnant sur des systèmes centraux, les mainframes. Cette façon de faire commençait par redéfinir les architectures du réseau (les réseaux intra- et inter-entreprise). Au début des années 2000, sont apparus des hébergeurs Web capables d'héberger des applications informatiques et des données dans leurs locaux. On observe aussi l'arrivée des Big data (qui est une combinaison de progrès technologiques, d'innovations d'usagers et d'évolutions sociales) et de Datacenter (qui représentent ensemble informatique composé, entre autres, de serveurs, et permettant le stockage de données en un lieu sûr).

Tout ceci à un moment donné, exigera une agilité du réseau pour sa survie et son développement. Nous entrons donc dans l'ère du réseau informatique intelligent. Nous passerons en revue d'abord ces différents concepts qui ont représenté la motivation pour un réseau programmable.

Depuis l'utilisation de statistiques dans le sport de haut niveau jusqu'aux algorithmes de recommandation d'Amazon [2], en passant par le programme de surveillance PRISM [3] de la NSA [4] ou encore la médecine analytique, le Big Data et les Analytics se sont construit une place de premier plan dans tous les domaines de la société.

En entreprise, la mise en place d'outils Big Data & Analytics répond généralement à plusieurs objectifs :

Et avec la multiplication et surtout la démocratisation des outils liés aux data, le débat entre ceux qui sont prêts à partager leurs données s'ils peuvent les valoriser et ceux qui s'inquiètent des risques de ces innovations fait rage.

La notion de Big Data recouvre une combinaison de progrès technologiques, d'innovations d'usage et d'évolutions sociales qui amène les entreprises à repenser leurs priorités stratégiques et leur modèle opérationnel.

La première dimension fondamentale du Big data, c'est la composante technologique. En effet, le Big Data s'appuie sur un ensemble d'innovations technologiques qui transforment profondément la façon dont les entreprises et les individus génèrent, transmettent, stockent et utilisent des données : massification des échanges de données (vidéo, texte, son, image), révolution dans le stockage (Cloud-Computing) et la structuration de données (NoSQL), progrès des techniques d'analyse, progrès des outils de visualisation de données...

Ainsi on note la montée en puissance du Big Data, l'augmentation de la richesse et du volume des data dues à une histoire de technologie, à l'évolution culturelle vis-à-vis de la génération et du partage d'information, aux nouveaux usages et nouvelles possibilités de monétisation. On distingue généralement 2 types de données en Big Data :

§ Les données des entreprises : les emails, les documents, les bases de données, toutes les historiques de processus métiers (logs), et tout autre type de donnée structurée, semi-structurée ou non-structurée que l'entreprise produit et stocke.

§ Les données en dehors des entreprises : bases de données externes (publiques ou fournisseurs de données), contenus échangés sur les réseaux sociaux ou publiés en ligne, les historiques de navigation et de recherche, les données (géolocalisées ou non) transmises par les objets connectés (des puces RFID au smartphone en passant par des thermostats intelligents et les pacemakers)...

Du coup, quand on parle de Big Data, on ne parle pas uniquement d'un nouvel ensemble de données devenu disponible et des technologies permettant de les exploiter mais bien d'une démarche visant à faire des données un mode de décision, un actif stratégique et une façon de créer de la valeur. C'est un véritable renversement de paradigme d'organisation, qui a gagné le nom de DATA-CENTRIC [5], dans lequel l'entreprise est guidée par les données.

En terme d'applications concrètes et d'impact sur l'entreprise (la performance, la stratégie et la gestion), le Big Data propose :

§ Améliorer l'expérience client : On considère généralement que l'intérêt principal du Big Data réside dans l'amélioration de l'efficacité de l'activité marketing de l'entreprise. Grâce au croisement de données sociales, comportementales et transactionnelles, les entreprises peuvent segmenter de manière beaucoup plus fine leur clientèle pour personnaliser leur offre et leurs campagnes marketing, suivre le sentiment des consommateurs et anticiper les points d'accroche dans l'expérience client. La généralisation de pratiques comme l'AdExchange (enchères en temps réel pour des publicités ciblées en ligne), l'AB Testing ou le Marketing 1:1, que permet les progrès du Big Data et des Analytics, transforment en profondeur la façon dont les entreprises comprennent et interagissent avec leurs consommateurs.

§ Améliorer son efficacité opérationnelle : Les nouveaux outils Big Data s'appuient sur des technologies qui permettent de traiter des volumes d'informations plus larges de manière plus rapide et moins coûteuse. Le système de fichiers distribués (Hadoop), les Analytics avancés et les technologies de traitement en mémoire vive, ainsi que le stockage dans le Cloud sont autant d'innovations qui améliorent le niveau rapidité, la compétitivité des processus métiers grâce à plus d'industrialisation et d'automatisation. La technologie de « Text-Mining » (fouille de texte), permet par exemple à un département RH de trier automatiquement les profils correspondant à des critères spécifiques parmis des milliers de CV, économisant ainsi un temps précieux.

§ Développer son Business Model : Certaines entreprises arrivent même à faire de leur projet Big Data une source de revenus, grâce principalement à deux leviers. D'une part, des groupes (télécom notamment), qui disposent d'un trésor de données, peuvent monétiser leurs bases pour permettre à des partenaires de développer leurs activités. C'est le cas de SFR, qui utilise les données géolocalisées de son réseau pour vendre des informations, provenant des clients à des centres commerciaux. D'autre part, des entreprises développant des capacités Big Data peuvent arriver à un tel niveau d'expertise où ils les revendent, soit sous forme de logiciel soit sous forme de prestation (conseil ou autre).

Dans la réalité des faits, le plus intéressant, est une combinaison de ces applications. En exemple, nous pouvons noter la plateforme Big Data mise en place par le groupe bancaire Crédit Mutuel en France. Grâce à une plus grande efficacité de ces systèmes de traitement et une infrastructure de stockage repensée, ils proposent à leurs clients d'accéder à 10 années d'historiques de dépense qui peuvent être filtrées par catégorie ou par commerçant. La technologie de calcul en mémoire leur permet également d'évaluer les demandes de crédit en moins de 4h, contre 48h auparavant. Enfin, la banque monétise ses données en proposant à certains partenaires commerciaux d'avoir accès à des informations sur les comportements d'achat de ses clients [6]. Cette utilisation concrète dans le cas de la plateforme Big Data du groupe bancaire du crédit Mutuel en France, n'a été vraiment possible qu'avec une redéfinition des accès réseaux par l'introduction de la notion d'agilité du réseau.

La notion de Datacenter, au même titre que l'informatique en général, a fortement évolué ces dernières années. Les premiers datacenter avaient pour objectif d'offrir un centre d'hébergement et de traitement des données hyper sensibles à de grandes entreprises internationales, d'un niveau de sécurité très élevé pour des services tel que le Cloud. Le Cloud centralise l'ensemble des logiciels et des données dans des centrales numériques multi-clients en les rendant accessibles en ligne. Ceci n'est possible que grâce à la virtualisation qui n'est autre qu'un système pouvant fonctionner comme un autre système à travers des fonctions pour lesquelles il n'avait pas été prévu à l'origine. Au fil du temps et de la démocratisation des composantes ainsi que la virtualisation des serveurs, les datacenters se sont positionnés comme étant une solution économique pour les PME. Il est aujourd'hui plus intéressant d'utiliser les services ainsi que la qualité d'un datacenter plutôt que d'investir dans du matériel propre.

Un datacenter représente un ensemble informatique composé, entre autres, de serveurs et permettant le stockage de données en un lieu sûr. Initialement conçus pour l'hébergement des données de grandes entreprises, les datacenters offrent désormais toute une série de fonctionnalités.

Les options disponibles lorsque l'on fait appel aux services d'un datacenter sont vastes. Vous pouvez louer un espace ou une armoire réseau entière afin d'y entreposer votre propre matériel et donc profiter de la sécurité contre la surchauffe, les incendies ou même le vol. Une autre possibilité est de choisir à la carte le type de service souhaité.

On pourra opter pour un serveur spécifique avec une bande passante importante pour héberger les sites internet et permettre un accès rapide pour la visualisation de vidéos. La location d'espaces de stockage pour réaliser des sauvegardes (ou backup) externalisées ainsi que l'hébergement de la base de données sont proposés.

Un datacenter se compose habituellement de routeurs, commutateurs, pare-feux, passerelles et de systèmes de détection d'intrusion logicielle.

Malgré tous les moyens mis en oeuvre pour assurer la sécurité des données, certaines entreprises utilisent plusieurs datacenters afin de stocker leurs données dans 2, 3 voire 6 locaux différents. Au-delà de la sécurité des données, la sécurité physique du datacenter même représente un enjeu de taille. On notera donc :

§ La surveillance du bon fonctionnement de la climatisation, elle-même essentielle au bon fonctionnement du matériel électronique.

§ L'alimentation de secours peut être fournie via un UPS et un générateur électrique ou via un groupe tournant (no-break) couplé à un accumulateur cinétique.

§ Dans le but de prévenir une perte d'alimentation électrique, toutes les composantes électriques, y compris les systèmes de secours, sont habituellement doublées. Les serveurs dits essentiels sont de plus alimentés par un système qui fait appel à deux sources électriques indépendantes à l'intérieur du centre.

§ Les centres ont habituellement un plancher surélevé de 60 cm, fait de dalles amovibles. Cet espace permet la libre circulation de l'air, tout comme il facilite le câblage d'alimentation et de données par des chemins de câble différents. Cependant, des centres de données sont sans plancher technique (alimentation par le dessus des racks, afin de supporter plus facilement des éléments lourds de type mainframe (IBM z10, etc.).

§ Ils ont souvent des systèmes complexes de prévention et d'extinction des incendies. Les centres modernes sont souvent équipés de deux systèmes d'alarme. Le premier détecte les particules chaudes émises par les composantes surchauffées de l'équipement, particules qui provoquent souvent un feu. De cette façon, il est possible d'éliminer à sa source un foyer d'incendie (parfois, il suffit d'éteindre un ensemble à soudure pour éliminer le risque d'incendie). Un deuxième système sert à activer un ensemble d'activités si un début d'incendie se manifeste. Ces systèmes sont également dédiés à une portion du centre de traitement de données. Couplés à d'excellentes portes anti-feu et autres appareils de confinement, il est possible de contrôler le feu et de l'éteindre sans affecter le reste du bâtiment.

§ Les systèmes conventionnels d'extinction du feu sont aussi nocifs que le feu pour les composants électroniques, c'est pourquoi des procédés alternatifs ont été développés. Certains utilisent l'azote, l'argonite, le FM-200 ou le Novec(tm)1230 FK-5-1-12, alors que d'autres se rabattent sur l'émission de fines particules d'eau ultra-pure (cette eau n'est pas électriquement conductrice, ce qui n'endommage pas les composants électroniques).

§ La sécurité est aussi essentielle au fonctionnement de tels centres. L'accès physique à ces centres est réservé au personnel autorisé, tout comme des caméras vidéo permettent de suivre les personnes sur place. Également, des gardes de sécurité veillent si le centre est grand ou contient des informations considérées comme essentielles.

Géographiquement parlant, les datacenters sont présents aux quatre coins de la planète, principalement aux États-Unis et au Canada. L'information qu'ils contiennent doit être disponible rapidement grâce à des connexions internet haut débit et quelles que soient les circonstances.

Le datacenter est donc un concentré de données informatiques dont l'accès autorisé peut se faire des 4 coins de la planète. Les connexions internet sont le plus souvent assurées par la fibre optique de plusieurs FAI afin d'obtenir un débit et une bande passante élevés ainsi que de limiter le risque de pannes. Ce type de connexion permet d'absorber les milliers de sessions journalières.

Comme pour la plupart des éléments, les connexions internet sont redondantes et la charge est répartie (load balancing).

Dans sa mise en place, le datacenter, a recours à diverses architectures pour garantir la disponibilité de service. Parmi ces architectures, nous distinguons le 2-tiers et le 3-tiers.

L'architecture 2-tiers, désigne un mode de communication à travers un réseau entre plusieurs programmes ou logiciels : l'un, qualifié de client, envoie des requêtes ; l'autre ou les autres, qualifiés de serveurs, attendent les requêtes des clients et y répondent. Par extension, le client désigne également l'ordinateur sur lequel est exécuté le logiciel client, et le serveur, l'ordinateur sur lequel est exécuté le logiciel serveur. En général, les serveurs sont des ordinateurs dédiés au logiciel serveur qu'ils abritent dans notre cas le datacenter, et dotés de capacités supérieures à celles des ordinateurs personnels en terme de puissance de calcul, d'entrées-sorties et de connexions réseau. Les clients sont souvent des ordinateurs personnels ou des appareils individuels (téléphone, tablette), mais pas systématiquement. Un serveur peut répondre aux requêtes d'un grand nombre de clients.

§ La centralisation de toutes les données sur un seul serveur, physique ou virtuel ; ce qui simplifie les contrôles de sécurité, l'administration, la mise à jour des données et des logiciels.

§ La complexité du traitement et la puissance de calculs à la charge du ou des serveurs, les utilisateurs utilisant simplement un client léger sur un ordinateur terminal pouvant être simplifié au maximum.

§ La recherche d'information : les serveurs étant centralisés, cette architecture est particulièrement adaptée et véloce pour retrouver et comparer de vastes quantités d'informations (moteur de recherche sur le Web), ce qui semble rédhibitoire pour le P2P beaucoup plus lent, à l'image de Freenet.

§ Si un grand nombre de clients veut communiquer avec le serveur au même moment, ce dernier risque de ne pas supporter la charge (la communication simultanée qui, d'ailleurs, est très fréquente au niveau du datacenter).

§ Si le serveur n'est plus disponible, plus aucun des clients ne fonctionne (le réseau pair-à-pair continue à fonctionner, même si plusieurs participants quittent le réseau).

§ En aucun cas les clients ne peuvent communiquer entre eux ; ce qui entraîne une asymétrie de l'information au profit des serveurs.

Le 3-tiers est un modèle logique d'architecture applicative qui vise à modéliser une application comme un empilement de trois couches logicielles (niveaux) dont le rôle est clairement défini. On observe ainsi la couche présentation des données correspondant à l'affichage, la restitution sur le poste de travail et le dialogue avec l'utilisateur. La couche traitement des données correspond à la mise en oeuvre de l'ensemble des règles de gestion et de la logique applicative et la dernière d'accès aux données persistantes qui correspond aux données qui sont destinées à être conservées sur la durée, voire de manière définitive.

Bien que le 3-tiers permette de gérer l'évolutivité grâce à une conception hiérarchique, évite le maillage complet et autorise l'ajout de nouvelles paires de commutateurs d'agrégation sans qu'il soit nécessaire de modifier l'agrégation existante, des insuffisances lui sont notées. On peut énumérer entre autres: la latence élevée en raison de supplémentaires, les congestions, une grande consommation d'énergie et la nécessité de nouveaux racks.

L'avantage principal d'un datacenter est bien évidemment la qualité des infrastructures et le niveau de sécurité. Cela devient encore plus avantageux pour une PME car il lui serait impossible de se doter d'un local informatique équivalent. Sans parler des ressources nécessaires afin d'administrer et de sécuriser le matériel et l'infrastructure :

Comme précédemment évoqué, les connexions internet utilisées pour l'accès aux datacenters, sont redondantes et la charge est répartie grâce au « load balancing ». De plus, nous avons noté que l'architecture 3-tiers sensé solutionner les problèmes au niveau des datacenters a montré ses limites. Cette situation impose d'avoir une bonne connexion avec les datacenters et de penser à une nouvelle architecture. Cet impératif nous ramène à la notion d'agilité du réseau et l'option du SDN.

Quels niveaux de qualité et de sécurité peut-on attendre de son datacenter ? Comment les évaluer ? Telles sont quelques unes des questions que l'on se pose en matière de Qos dans un datacenter. Ainsi, on s'intéressera à la connexion internet, au réseau et à la sécurité. Les connexions internet sont le plus souvent assurées par la fibre optique de plusieurs FAI afin d'obtenir un débit et une bande passante élevés ainsi que de limiter le risque de pannes. Comme pour la plupart des éléments telles que les connexions internet, la notion de load balancing s'impose. Le load balancing est d'un grand intérêt d'autant plus qu'il permet de répartir la charge d'un serveur, d'une connexion internet sur deux ou trois systèmes différents. La charge est répartie comme une balance, ce qui permet de maintenir de hautes performances, introduisant une notion d'intelligence du réseau. En terme de réseau et de sécurité, l'architecture réseau d'un datacenter est composée de routeurs et de commutateurs (Switches) Gigabit, avec des liaisons en fibre optique. Même si la fibre optique est privilégiée pour les liaisons principales, bon nombre de datacenters utilisent encore en partie du câble UTP. Les routeurs et commutateurs sont toujours en redondance et indépendants les uns des autres. Ils disposent également d'une double alimentation électrique. Si le réseau physique est partagé, sa division sera effective par la configuration de VLan (réseau virtuel) ce qui limite les risques d'intrusions internes. La mise en place de firewalls prévient les risques d'intrusions extérieures. Placés entre le routeur et le LAN, ils filtrent la totalité du trafic afin de l'identifier et de bloquer toutes requêtes suspectes.

Les systèmes informatiques d'entreprise utilisent les centres de données comme des noyaux de commutation et des centres de contrôle pour développer des réseaux entièrement connectés et une analyse intelligente du Big Data.

Les datacenters aident les entreprises à résoudre les défis suivants pour la mise en oeuvre du centre de données :

· Le développement rapide des services augmente les besoins de capacité informatique.

· Les nouvelles opérations de l'entreprise nécessitent un déploiement efficace des services, une expansion élastique des ressources informatiques et une gestion de réseau flexible.

· Les systèmes informatiques doivent avoir une haute disponibilité pour maîtriser les risques opérationnels et assurer la continuité de service.

En outre le datacenter fournit des produits de réseau multicouche, et prend en charge l'interconnexion du système (à l'intérieur d'un centre de données et entre les centres de données), la reprise après sinistre, la protection de la sécurité et la gestion de réseau. Cette solution complète offre des services uniques de bout en bout (E2E) permettant aux clients de simplifier leur développement de réseau de centres de données. Le réseau en cloud flexible est construit sur la plus grande plate-forme de commutation non-bloquante 360T au monde, couvrant quatre générations de cycle de vie de serveur (10 ans).

Les réseaux informatiques sont généralement construits de dispositifs réseau tels que les routeurs, commutateurs et d'autres équipements intermédiaires tel qu'un pare-feu, avec de nombreux protocoles complexes mises en oeuvre sur eux. Les administrateurs de réseau sont chargés de mettre en place des politiques pour répondre à un large éventail d'événements et d'applications réseau. Ainsi la gestion de réseau et l'optimisation des performances est assez difficile et sujet à de nombreuses erreurs. Le fait que les dispositifs de réseau soient comme des boîtes noires totalement intégrées exacerbe la plupart du temps les administrateurs réseau. A cela, il faut ajouter le phénomène dénommé «Ossification d'internet ". En bref, il s'explique par le fait que l'internet se développe comme un réseau à commutation de paquets expérimental. De ce fait, aujourd'hui, de nombreux aspects semblent figés comme gravés dans une pierre [7]. Comme résultat, l'internet est devenu extrêmement difficile en terme d'évolution simultanée sur le plan de son infrastructure physique ainsi que ses protocoles et de la performance. Cependant, les applications actuelles et services internet deviennent de plus en plus complexes et exigeants. Il était donc impératif que l'internet évolue pour répondre à ces nouveaux challenges.

L'idée de «réseaux programmables" a été proposée comme un moyen de faciliter l'évolution des réseaux. En particulier, Software Defined Networking (SDN) est un nouveau paradigme de réseautage dans lequel le matériel servant de transfert est découplé du centre de décisions et de contrôle. Il envisage simplifier réseau du point de vue gestion et favoriser son innovation et son évolution. La principale idée est de permettre aux utilisateurs d'être confiant sur la fiabilité du réseau et de ses ressources, comme pour les ressources informatiques. Dans le SDN, l'intelligence du réseau est logiquement centralisée dans des contrôleurs logiciels.

Le cloud computing, est l'exploitation de la puissance de calcul ou de stockage de serveurs informatiques distants par l'intermédiaire d'un réseau, généralement l'internet. Ces serveurs sont loués à la demande, le plus souvent par tranche d'utilisation selon des critères techniques (puissance, bande passante, etc.) mais également au forfait. Le cloud computing se caractérise par sa grande souplesse : selon le niveau de compétence de l'utilisateur client, il est possible de gérer soi-même son serveur ou de se contenter d'utiliser des applicatifs distants en mode SaaS. Selon la définition du National Institute of Standards and Technology (NIST), le cloud computing est l'accès via un réseau de télécommunications, à la demande et en libre-service, à des ressources informatiques partagées configurables. Il s'agit donc d'une délocalisation de l'infrastructure informatique.

En d'autre terme, le cloud est un ensemble de matériel, de raccordements réseau et de logiciels qui fournissent des services sophistiqués que les individus et les collectivités peuvent exploiter à volonté depuis n'importe où dans le monde. Le cloud computing est un basculement de tendance : au lieu d'obtenir de la puissance de calcul par acquisition de matériel et de logiciel, le consommateur se sert de puissance mise à sa disposition par un fournisseur via Internet.

Les caractéristiques essentielles d'un cloud sont la disponibilité mondiale en libre-service, l'élasticité, l'ouverture, la mutualisation et le paiement à l'usage.

· Ressources en libre-service et élasticité : La capacité de stockage et la puissance de calcul sont adaptées automatiquement au besoin d'un consommateur. Ce qui contraste avec la technique classique des hébergeurs où le consommateur doit faire une demande écrite à son fournisseur en vue d'obtenir une augmentation de la capacité - demande dont la prise en compte nécessite évidemment un certain temps. En cloud computing la demande est automatique et la réponse est immédiate.

· Ouverture : les services de cloud computing sont mis à disposition sur l'Internet, et utilisent des techniques standardisées qui permettent de s'en servir aussi bien avec un ordinateur qu'un téléphone ou une tablette11 ;

· Mutualisation : elle permet de combiner des ressources hétérogènes (matériel, logiciel, trafic réseau) en vue de servir plusieurs consommateurs à qui les ressources sont automatiquement attribuées6. La mutualisation améliore l'évolutivité et l'élasticité et permet d'adapter automatiquement les ressources aux variations de la demande6 ;

· Paiement à l'usage : la quantité de service consommée dans le cloud est mesurée, à des fins de contrôle, d'adaptation des moyens techniques et de facturation.

Le cloud utilisent des technologies telles que la virtualisation du matériel informatique, les grilles, l'architecture orientée services et les services web. Un cloud peut être public, privé ou communautaire.

Selon le National Institute of Standards and Technology il existe trois catégories de services qui peuvent être offerts en cloud computing : IaaS, PaaS et SaaS.

En français infrastructure en tant que service. C'est le service de plus bas niveau. Il consiste à offrir un accès à un parc informatique virtualisé. Des machines virtuelles sur lesquelles le consommateur peut installer un système d'exploitation et des applications. Le consommateur est ainsi dispensé de l'achat de matériel informatique. Ce service s'apparente aux services d'hébergement classiques des centres de traitement de données, et la tendance est en faveur de services de plus haut niveau, qui fait davantage abstraction de détails techniques.

En français plate-forme en tant que service. Dans ce type de service, situé juste au-dessus du précédent, le système d'exploitation et les outils d'infrastructure sont sous la responsabilité du fournisseur. Le consommateur a le contrôle des applications et peut ajouter ses propres outils. La situation est analogue à celle de l'hébergement web où le consommateur loue l'exploitation de serveurs sur lesquels les outils nécessaires sont préalablement placés et contrôlés par le fournisseur. La différence étant que les systèmes sont mutualisés et offrent une grande élasticité - capacité de s'adapter automatiquement à la demande, alors que dans une offre classique d'hébergement web l'adaptation fait suite à une demande formelle du consommateur.

En français logiciel en tant que service. Dans ce type de service, des applications sont mises à la disposition des consommateurs. Les applications peuvent être manipulées à l'aide d'un navigateur web ou installées de façon locative sur un PC, et le consommateur n'a pas à se soucier d'effectuer des mises à jour, d'ajouter des patches de sécurité et d'assurer la disponibilité du service. Gmail est un exemple de tel service. Il offre au consommateur un service de courrier électronique et le consommateur n'a pas à se soucier de la manière dont le service est fourni. Autre exemple, Office 365 propose un ensemble de services en abonnement dont la suite logicielle Office qui se met automatiquement à jour, l'utilisateur ne se soucie pas de racheter un nouveau logiciel ou de le mettre à jour. On parle ici de location de services hébergés par Microsoft. D'autres exemples de logiciels mis à disposition en SaaS sont Google Apps, Office Online ou LotusLive (IBM) [53].

La qualité de service (QDS) ou Quality of Service (QoS) est la capacité à véhiculer dans de bonnes conditions un type de trafic donné, en termes de disponibilité, débit, délais de transmission, gigue, taux de perte de paquets...

La qualité de service est un concept de gestion qui a pour but d'optimiser les ressources d'un réseau (en management du système d'information) ou d'un processus (en logistique) et de garantir de bonnes performances aux applications critiques pour l'organisation. La qualité de service permet d'offrir aux utilisateurs des débits et des temps de réponse différenciés par applications (ou activités) suivant les protocoles mis en oeuvre au niveau de la structure.

La qualité d'un service est une notion subjective. Selon le type de service envisagé, la qualité pourra résider dans le débit (téléchargement ou diffusion vidéo), le délai (pour les applications interactives ou la téléphonie), la disponibilité (accès à un service partagé) ou encore le taux de pertes de paquets (pertes sans influence pour de la voix ou de la vidéo, mais critiques pour le téléchargement). La qualité de service propre au domaine de la gestion de la qualité est un concept utile en urbanisation du système d'information gérant les flux immatériels et à la logistique qui gère les flux matériels. L'objet est de créer les synergies (ou flexibilités) nécessaires à l'organisation. Ceci passe par une amélioration de la standardisation des formats, et la mutualisation et ré-utilisation des ressources dans le cadre de l'intégration des flux.

Dans un réseau, les informations sont transmises sous la forme de paquets, petits éléments de transmission transmis de routeur en routeur jusqu'à la destination. Tous les traitements vont donc s'opérer sur ces paquets.

La mise en place de la qualité de service nécessite en premier lieu la reconnaissance des différents services. Celle-ci peut-se faire sur la base de nombreux critères :

· La validité du routage (gestion des pannes dans un routage en cas de routes multiples par exemple).

En fonction de ces critères, différentes stratégies peuvent ensuite être appliquées pour assurer une bonne qualité de service.

Nous présenterons de façon sommaire, un aperçu des débuts du réseautage programmables, précurseurs de l'actuelle SDN paradigme qui a jeté les bases pour la plupart des idées que nous voyons aujourd'hui.

L'Open Signaling (OPENSIG) est un groupe de travail qui a commencé ses travaux en 1995 avec une série d'ateliers dédiée à «rendre plus ouverte, extensible et programmable l'ATM (Asynchronous Transfert Mode, l'internet et les réseaux mobiles » [8]. Ils pensaient que la séparation entre le matériel de communication et logiciel de contrôle était nécessaire, mais difficile à réaliser. Cela est principalement dû à l'intégration totale et complète des commutateurs et des routeurs, rendant impossible un déploiement rapide des nouveaux services et environnements de réseau. Le principe de base de cette proposition était de fournir l'accès au matériel de réseau via des interfaces de réseau ouvert et programmables. Cela permettrait le déploiement de nouveaux services grâce à un environnement de programmation partagé.

Motivé par ce principe, un groupe de travail IETF fut créé, permettant la mise en place du General Switch Management Protocol (GSMP) [9], un protocole général pour gérer les commutateurs propriétaires. GSMP permet à un contrôleur d'établir et de libérer les connexions à travers le commutateur, ajouter et supprimer des circuits en multidiffusion, gérer les ports d'un commutateur, obtenir des informations de configuration, faire et supprimer des réservations de ressources. Ce groupe de travail a officiellement terminé ses activités avec la proposition de cette dernière norme, GSMPv3 en Juin 2002.

Toujours dans les années 1990, Active Networking [10], [11] a proposé l'idée d'une infrastructure de réseau qui serait programmable pour des services personnalisés. Deux approches principales ont été mises en avant :

§ des commutateurs programmables par l'utilisateur, avec un transfert de données intra-bande et de gestion hors bande

§ des fragments de programmes qui pourraient être intégrés dans des messages de l'utilisateur; ces programmes seront interprétés et exécutés par les routeurs.

Malgré sa bonne conception, l'Active Networking n'a pas été utilisé principalement en raison de la sécurité et de la performance [11].

Lancé au milieu de l'année 1990, ce projet avait pour but de concevoir et de développer l'infrastructure nécessaire pour le contrôle évolutif et la gestion des réseaux ATM. L'idée de base est que le contrôle et les fonctions de gestion des appareils (commutateurs ATM dans le cas du DCAN) soient découplés des dispositifs eux-mêmes et délégués à des entités externes dédiées uniquement à cet objectif ayant pratiquement le même principe que celui du SDN [12]. Ainsi poursuivant ce principe, il est proposé dans [13] un contrôle hétérogène avec des architectures multiples autorisés pouvant s'exécuter simultanément et simplement grâce à un basculement entre les contrôleurs.

À partir de 2004, le 4D projet [14], [15], [16] a préconisé un modèle de table rase qui met l'accent séparation entre la logique de décision et les protocoles de routage qui régissent les interactions entre les éléments de réseau. Il propose une subdivision en 4 plans à savoir : «decision plane», «dissemination plane», «discovery plane» et «data plane». Cette subdivision fut à la base des travaux qui ont conduit ultérieurement à des propositions tels que les NOX [16], qui ont proposé un "système d'exploitation pour réseaux" dans le cadre d'un réseau OpenFlow.

En 2006, l'IETF Network Configuration Working Group propose NETCONF [17] comme un protocole de gestion des équipements de réseau. Le protocole autorise les équipements de réseau à utiliser une API par laquelle les données de configuration extensibles peuvent être envoyées et récupérées. NETCONF, au moment de sa présentation par l'IETF, était considéré comme une nouvelle approche pour la gestion de réseau qui résoudrait les inconvénients du SNMP (déjà existant en ce moment) tel que :

§ Le fait que SNMP n'a pas été utilisé pour configurer le réseau d'équipement, mais plutôt comme un suivi de la performance

Bien que le protocole NETCONF permette de simplifier le dispositif de configuration et agit comme un point central de gestion, il n'y a pas de séparation entre les données et les plans de contrôle. Ainsi un réseau avec NETCONF ne devrait pas être considéré comme totalement programmable et que de nouvelles fonctionnalités doivent être mises en oeuvre à la fois sur le dispositif de réseau et le gestionnaire de configurations. De plus, il est conçu principalement pour aider la configuration automatisée et non pour la gestion de l'état du réseau, ni de permettre un déploiement rapide des services et nouvelles applications.

Prédécesseur immédiat d'OpenFlow, le projet SANE/Ethane [18], en 2006, a défini une nouvelle architecture pour les réseaux d'entreprise. L'accent mis par Ethane était sur l'aide d'un contrôleur centralisé pour gérer la politique et sécurité dans un réseau. Identique au SDN, Ethane utilisé deux composants:

§ Un commutateur Ethane constitué d'une table de flux et d'un canal sécurisé vers le contrôleur.

Ethane a ainsi jeté les bases de ce qui allait devenir le Software-Defined Networking. Pour mettre Ethane dans le contexte de SDN le paradigme d'aujourd'hui, le contrôle d'accès basé sur l'identité d'Ethane sera mis en oeuvre à travers des applications comme NOX [16], Maestro [19], Beacon [20], SNAC [21], Helios [22], etc.

Ainsi donc, l'idée de réseaux programmables et la logique de séparer le contrôle et la gestion du matériel fait son chemin depuis de nombreuses années. Les réseaux de communication de données sont généralement constitués par les infrastructures de réseau tels que les routeurs et commutateurs qui relient les utilisateurs finaux entre eux. Sachant que les routeurs et commutateurs sont généralement des systèmes «fermés», souvent avec des interfaces de contrôle limitées et spécifiquement destiné aux fournisseurs, une fois déployé en production, il est assez difficile au réseau d'évoluer. Plus précisément, le déploiement de nouvelles versions des protocoles existants (par exemple, IPv6), sans oublier que le déploiement de nouveaux protocoles et services sur les réseaux actuels présente de nombreux obstacles. Même internet n'y échappe pas. Dans cette situation, notons que le déploiement de nouvelles applications et fonctionnalités de réseau s'avère compliqué, car ils devraient être mis en oeuvre directement dans le matériel (l'infrastructure). Même les tâches les plus simples telle que la configuration d'une politique peut exiger une bonne quantité d'efforts en raison de l'absence d'une interface de commande commune aux différents dispositifs de réseau. Comme alternative, l'utilisation d'équipements intermédiaires tels que les pare-feu, les systèmes de détection d'intrusion, les traducteurs d'adresses réseau et autres est proposée pour contourner en partie ces difficultés.

Figure 5 : Présentation de l'architecture traditionnelle et vue du SDN. Découplement du plan logique et matériel [32].

Comme illustré sur la figure 4, nous voyons en quoi le SDN modifiera nos réseaux actuels. Ainsi au lieu d'appliquer les politiques et protocoles en cours d'exécution sur chaque équipement dispersé, le réseau est réduit à une partie d'exécution "simple", au matériel et au contrôleur de réseau qui assure les décisions.

Le Software-Defined Networking (SDN) a été développé pour faciliter l'innovation et permettre un contrôle simple du réseau par programmation des chemins à suivre par les données. On notera pour ce fait, le découplement de la partie logique du réseau de la partie physique. Ainsi toute la partie logique en charge de la gestion de transmission des données sera ramenée dans une couche supérieure sous le nom de « contrôleur ». Au-dessus du contrôleur, nous aurons dorénavant l'ensemble des services du réseau qui deviennent des applications. De façon globale, le SDN se présente avec une architecture en trois (03) couches : Le Data Plane, Le Control Plane et Le Management plane. Cette architecture que l'on présente de façon simpliste s'avère en réalité complexe et très structurée.

Le terme SDN (Software-Defined Networking) au départ représente les idées et travaux autour d'OpenFlow. Il définira par la suite une architecture réseau où le transfert de données est géré par un plan de contrôle à distance découplée des équipements. Cet aspect de découplement imposera une architecture et le respect de quatre piliers à savoir :

1. Le plan de commande et de données est découplé. Les fonctionnalités de contrôle sont supprimées au niveau des dispositifs de réseau qui sont devenus de simples éléments de transfert de paquets.

2. Les décisions d'expédition sont en fonction un flux au lieu de destination. Un flux représente un ensemble de paquets avec des valeurs servant de critère de filtre et un ensemble d'actions à exécuter (les instructions). Dans le contexte SDN ou OpenFlow, un flux est une séquence de paquets entre une source et une destination. Tous les paquets d'un flux reçoivent les mêmes politiques du dispositif de transmission [33], [34]. L'abstraction de flux permet d'unifier le comportement des différents types de périphériques réseau tel que les routeurs, les commutateurs, les pare-feu [35]. La programmation de flux permet une flexibilité sans précédent limitée seulement à la capacité mis en oeuvre par la table de flux [36].

3. Le système de logique est déplacé du matériel vers une entité externe. Appelé contrôleur SDN ou Network Operating System (NOS), il est une plate-forme logicielle fonctionnant en client/serveur avec le NOS comme serveur. Il fournit l'essentiel les ressources et les abstractions afin de faciliter la programmation des dispositifs basés sur une logique centralisation des commandes. Son but est dans ce cas similaire à celui d'un système d'exploitation classique.

4. Le réseau est programmable à travers des applications logicielles qui s'exécutent au-dessus du NOS et qui interagissent avec des équipements en dessous du NOS. Ceci est la caractéristique fondamentale du SDN.

Ces piliers impérativement suivis dans le SDN nous permettent d'entrevoir une architecture du SDN comme suit :

Figure 6 : Architecture SDN. Présentation en plan, en couche et du système. [37]

En faisant abstraction des détails contenus dans chaque plan de la figure 5 et en retenant uniquement les trois (03) plans, on peut dire que :

· Le « Management plane » est plus constitué d'un ensemble d'interfaces soit web ou CLI servant à l'administration.

· Le « Control Plane » regroupe les protocoles de routage et les décisions sur le traitement.

En terme d'abstraction, nous en distinguons trois (03) principales qui permettent une simplicité de compréhension dans l'architecture et le fonctionnement du SDN.

Le « Forwarding Abstraction » permet à ce que, qu'importe la nature de l'envoi souhaité par le réseau cela soit possible tout en cachant les détails du matériel sous-jacent. Chez OpenFlow, la mise en oeuvre de cette abstraction, peut être considérée comme l'équivalent d'un "pilote de périphérique" sur un système d'exploitation.

La « Distribution Abstraction » gère s'assure de la protection des applications d'une mauvaise distribution des ressources grâce à un contrôle centralisé. Cette couche joue essentiellement deux fonctions : il installe les commandes de contrôle sur les équipements de transfert et collecte les informations relatives aux équipements réseaux afin d'offrir une vue globale du réseau aux applications.

La « Specification Abstraction » permet à une application réseau d'exprimer son besoin du réseau sans être l'auteur de ce besoin. Ceci est possible grâce à la virtualisation et à des langages de programmation.

Il représente la partie service du réseau. Notons qu'avec le SDN, tous les services réseau sont des applications qui, en fonction de leurs besoins feront appel aux autres couches de l'architecture. En regardant de plus près le « Management plane », on peut observer une suite de couche avec évidemment des protocoles pour faciliter les échanges.

On y notera : « Network Application », « Programming Planning » et la « Language-Base Virtualisation » pour les couches.

Les applications réseau peuvent être considérées comme le moteur du réseau. Elles mettent en oeuvre le contrôle logique qui sera traduit en commandes pour être implémentées dans le « Data Plane », afin de dicter les marches à suivre. Considérants le routage, la logique consiste à définir un chemin afin d'acheminer un paquet d'un point A à un point B. Pour atteindre cet objectif, l'application de routage sur la base de la topologie décide du chemin à prendre, charge le contrôleur afin de mettre en place les règles de transferts respectifs pour tous les équipements choisis entre A et B. Ainsi le réseau défini par l'application peut être déployé sur n'importe quel réseau traditionnel à partir de réseaux domestiques et professionnels ou un point d'accès Internet. Les applications de réseau existants effectuent des fonctions telles que le routage, l'équilibrage de charge, la sécurité de la politique mais aussi l'exploration de nouvelles approches telles que réduction de la consommation d'énergie. D'autres applications en plus de ce qui précède font du basculement, la qualité de service, la virtualisation de réseau, la gestion de la mobilité dans les réseaux sans fil [42]. Malgré la grande variété de cas d'utilisation, la plupart des applications SDN peuvent être regroupées dans une des cinq catégories: le trafic d'ingénierie, la mobilité et sans fil, la mesure et la surveillance, la sécurité et la fiabilité des données et la mise en réseau.

La programmation des réseaux a commencé avec des langages tels qu'OpenFlow [40] [41]. Notons qu'OpenFlow est un langage de bas niveau. Ainsi, les programmes OpenFlow doivent tenir compte du comportement du matériel, de la priorité des règles et de la topologie [41]. L'utilisation de ces langages de bas niveau pose donc un problème de réutilisabilité des programmes, de modularité et de présence d'erreur. L'abstraction fournis par les langages de programmation de haut niveau aide considérablement à résoudre les soucis de programmation [41]. Au niveau du SDN, des langages de programmation de haut niveau sont utilisés pour:

§ Créer des abstractions de niveau plus élevé afin de simplifier la tâche de programmation des équipements de transmission.

§ Permettre la mise en place d'environnements plus productifs et orientés sur les solutions aux problèmes des gestionnaires de réseau tout en accélérant le développement et l'innovation

§ Permettre la modularité et la réutilisabilité des programmes du code dans le plan réseau, au niveau du Control Plane.

2.2.1.3. La couche virtualisation basée sur le langage (Language-based Virtualization)

En terme de virtualisation, deux caractéristiques sont essentielles : la modularité et la possibilité d'avoir des niveaux d'abstraction tout en garantissant toutes les propriétés, entre autres la sécurité. Par exemple, les techniques de virtualisation peuvent permettre des vues différentes d'une infrastructure physique unique. Considérons un commutateur virtuel qui pourrait représenter en fait une combinaison de plusieurs dispositifs de transmission. Cette combinaison, simplifie la tâche du gestionnaire de réseau qui au lieu de gérer une multitude de commutateurs avec des règles de transfert sur chacun d'entre eux aura juste un seul commutateur à configurer. Cette abstraction simplifie considérablement le développement et le déploiement des applications de réseau complexes, tels que la sécurité avancée et d'autres services.

Le contrôleur est en fait un logiciel qui se substitue au logiciel de commande inclus dans chaque équipement réseau. Il fournit une interface de programmation au réseau. Les fonctions de base du contrôleur se résument en trois catégories : gérer la commutation et le routage des trames en appliquant des règles prédéfinies, effectuer cette tâche dynamiquement et en fonction des besoins en capacité, enfin, pouvoir être programmé, afin de les exécuter à des moments déterminés par l'administrateur, en fonction des exigences métier par exemple. Pour assurer ses fonctions le Control Plane peut compter sur ses différentes couches telles que « Northbound Interface », « Network Operating System » et « Network Hypervisor » et d'une suite de protocole (ForCES, OpenFlow, POF, Ethane, SANE).

Le « Northbound » et le « Southbound » Interfaces sont deux abstractions importantes du SDN. Le « Southbound Interface » est une proposition largement acceptée dans le SDN (OpenFlow) contrairement au « Northbound interface » qui est toujours en discussion. Ainsi, il sera un peu compliqué de définir par avance le « Northbound interface » comme un cas en utilisation d'un moment où il est encore en élaboration [39]. Quoi qu'il en soit, il est à prévoir une interface commune tels le « Northbound interface » tant que le SDN évoluera. Une telle couche d'abstraction qui permettrait aux applications de réseau de ne pas dépendre des implémentations spécifiques est d'une grande importance afin d'explorer le plein potentiel de SDN.

Les systèmes d'exploitation traditionnels fournissent des abstractions pour accéder aux périphériques de niveau inférieur, de gérer l'accès simultané aux ressources tels que : le disque dur, la carte réseau, le CPU, la mémoire et fournir des mécanismes de protection de sécurité. Ces fonctionnalités et les ressources sont des facteurs essentiels pour augmenter la productivité. Le SDN, en promettant de faciliter la mise en place et la gestion du réseau, a procédé à un contrôle logique et centralisé par le biais de son système d'exploitation ou de son contrôleur. Comme avec les systèmes d'exploitation classiques, la valeur essentielle du NOS est de fournir des abstractions, des services essentiels, et des interfaces de programmation d'application commune (API) pour les développeurs. Le NOS peut donc assurer des fonctions telles que : la fourniture des informations sur l'état et la topologie du réseau puis la détection des périphériques. Grâce au NOS (Contrôleur), pour définir une politique sur le réseau, le gestionnaire de réseau n'a plus besoin de se soucier des détails des équipements de distribution de données et de routage. Notons en bref que le contrôleur (NOS) est un élément essentiel dans l'architecture SDN, car permettant de générer les configurations du réseau en fonction en se basant sur des politiques définies par le gestionnaire du réseau.

Elle permet à différentes machines virtuelles de partager la même ressource matérielle. Dans le Cloud, précisément avec l'Infrastructure-as-a-service (IaaS), chaque utilisateur peut avoir ses propres ressources virtuelles à partir de calcul de stockage. Cela a permis la mise en place de nouveaux services où les utilisateurs allouent des ressources à la demande, à partir d'une infrastructure physique partagée et souvent à un coût relativement faible. La technologie rendant possible ces action est le « FlowVisor » qui tourne dans le « Network Hypervisors ». Il est l'une des premières technologies permettant de virtualiser le SDN. L'idée de base étant de permettre à plusieurs réseaux logiques de partager la même infrastructure de réseau OpenFlow, il fournit une couche d'abstraction qui facilite pour découper un plan de données basé sur le « off-the-shelf OpenFlow », permettant à des réseaux multiples et divers de coexister. Avec « FlowVisor », cinq dimensions de tranchage sont considérés: la bande passante, la topologie, le trafic, le CPU de l'équipement et les tables d'acheminement. De plus, chaque tranche de réseau prend en charge un dispositif de commande, à savoir, plusieurs contrôleurs pouvant coexister sur le dessus de la même infrastructure physique de réseau. Chaque contrôleur est autorisé à agir uniquement sur sa propre tranche du réseau. De manière générale, une tranche est définie comme un ensemble particulier de flux sur le plan de données. Globalement, « FlowVisor » est un proxy transparent qui intercepte les messages OpenFlow entre les commutateurs et contrôleurs. Il divise la bande passante du lien et les tables de flux de chaque commutateur. Chaque tranche reçoit un débit de données minimales et chaque contrôleur obtient son propre tableau de flux virtuel dans les commutateurs.

L'approche proposée par le groupe de travail l'IETF ForCES (Forwarding and Control Element Separation), redéfinit l'architecture interne du dispositif de réseau en séparant la fonction de commande de celle de transfert tout en gardant une représentation unitaire de l'entité de réseau.

Ces deux entités utilisent le protocole de ForCES pour communiquer. Le FE est responsable de l'utilisation du matériel pour le transport des paquets. La CE est en charge des fonctions de contrôle et de signalisation. Grâce au protocole ForCES, il donne les instructions au FE concernant la gestion des paquets. Le protocole fonctionne selon le principe Maître/Esclave où la CE est le maître. Nous pouvons aussi noter la présence du Logical Function Block (LFB) dans l'architecture du ForCES. La LFB permet à la CE de contrôler la configuration du FE.

Motivé par le principe du découplage SDN mettant en place, le plan de contrôle et de transmission de données, OpenFlow [23] tout comme ForCES procède à des échanges entre les deux plans.

Figure 8 : Architecture OpenFlow. La communication entre le contrôleur et les dispositifs de transmission via le protocole OpenFlow [32].

En nous référant à l'architecture d'OpenFlow, le commutateur OpenFlow de transfert, contient un ou plusieurs tableaux de flux et une couche d'abstraction qui communique en toute sécurité avec un contrôleur via le protocole OpenFlow. Les tables (Flow Table) permettent de déterminer la façon dont les paquets transitant sont traités et transmises. Les flux d'entrée sont généralement constitués de:

(1) règles de correspondance, utilisées pour sélectionner les paquets entrants. Ils peuvent refermer des informations contenues dans l'en-tête de paquet, le port d'entrée, et les métadonnées.

(2) compteurs, permettant de collecter les statistiques sur le débit tels que le nombre de paquets reçus, le nombre d'octets et la durée de transfert.

(3) suite d'instructions ou d'actions à suivre lors des correspondances. Elles indiquent comment gérer les paquets lors de la correspondance.

Lorsqu'un paquet arrive à un commutateur OpenFlow, les contenus de l'en-tête de paquet sont extraits et comparées avec les règles de correspondance. Une fois la correspondance faite, le commutateur applique l'ensemble des instructions, ou actions programmées. Sinon, l'action du commutateur dépendra des instructions définies par défaut. Chaque table doit avoir des instructions par défaut afin d'éviter la perte de paquet. . Il est à noter que depuis la version 1.1 OpenFlow prend en charge plusieurs tables, le traitement pipeline et l'utilisation des commutateurs hybrides c'est-à-dire ayant des ports OpenFlow et non-OpenFlow. La communication entre le contrôleur et le commutateur se fait via le protocole OpenFlow, qui définit un ensemble de messages qui peuvent être échangés entre ces entités à travers un canal sécurisé.

POF protocole d'acheminement intervenant au plan de contrôle et de gestion dans l'architecture SDN. La POF dans son fonctionnement utilise deux sections FE (Forwarding Elements) et FIS (Flow Instruction Set). Lors d'une transmission le POF FE n'a pas besoin de comprendre le format de paquet. Sous l'instruction de son contrôleur, le but du F.E. est d'extraire, d'assembler les clés de recherche à partir du paquet en-tête et d'exécuter les instructions s'y trouvant. Par conséquent, le FE peut facilement supporter de nouveaux protocoles avec leurs exigences de transfert. Vu de loin, le traitement de flux semble identique à celui d'OpenFlow. Cependant, dans OpenFlow, l'extraction et l'assemblage de clés de recherche est mené en précisant explicitement les champs d'en-tête de cible (par exemple l'adresse de destination IPv4) [24]. Bien que les FE doivent comprendre le format de paquets afin d'extraire les bits d'en-tête requis, dans POF, les FE n'ont pas de connaissances sur les protocoles de transfert. L'analyse des paquets est gérer par un dispositif de commande à travers une séquence de générique d'assemblage et de consultation de table clés instructions. Pour ce faire, les métadonnées du paquet sont élargies comme un bloc-notes générique associé à chaque paquet dans la suite de traitement [24]. Le contrôleur peut utiliser librement le bloc-notes pour mettre en cache les données temporaires (port d'entrée...) au cours de la durée de vie du paquet. Dans la FIS, les instructions qui manipulent le paquet ou des métadonnées sont stockées et sont utilisées pour localiser la cible des données. De ce fait, les nouvelles données à l'insertion ou à la réécriture peuvent être traitées immédiatement grâce aux instructions ou au paquet métadonnées. L'avantage d'un tel mécanisme est que le traitement est simple et évident [24].

Sur la base de ces différents protocoles, de nombreux contrôleurs furent construits.

En terme de contrôleurs, on note l'existence d'une multitude parmi lesquels on peut énumérer :

Beacon qui est un contrôleur OpenFlow rapide, multiplateforme, modulaire basé sur Java.

Floodlight qui est un contrôleur supporté par BigSwitch ; il est sous licence Apache et écrit en Java.

NOX et POX qui sont les deux premiers contrôleurs OpenFlow. NOX sur C++ et POX sur Python.

Ryu : il est un contrôleur SDN capable de configurer les équipements réseaux en utilisant OpenFlow, NetConf et OF-config.

Open Daylight : Le projet OpenDaylight est un projet open source pour le Software Defined Network qui a été annoncé publiquement le 8 Avril 2013. C'est un projet de collaboration hébergé par la Fondation Linux. Il contient un contrôleur modulaire et souple.

La liste n'étant pas exhaustive, on peut y ajouter : MUL, Maestro, Trema, Jaxon, Helios, SNAC, NodeFlow, Flowvisor, Ovs-controller, RouteFlow.

Contrôleur	Implémentation	Open Source	Développé par	Aperçu
POX	Python	Oui	Nicira	Général, le contrôleur SDN open-source écrit en Python
NOX	Python/C++	Oui	Nicira	Le premier contrôleur OpenFlow écrit en Python et C ++
MUL	C	Oui	Kulcloud	Contrôleur OpenFlow qui dispose d'une infrastructure multi ligne de base. Il prend en charge une interface multi-niveau pour le développement d'applications.
Maestro	Java	Oui	Rice University	Système d'exploitation de réseau basé sur Java. Il fournit des interfaces pour la mise en oeuvre des applications modulaires de contrôle de réseau et pour modifier l'état du réseau.
Trema	Ruby/C	Oui	NEC	Un framework pour le développement de contrôleurs OpenFlow écrites en Ruby et C
Beacon	Java	Oui	Stanford	Plate-forme modulaire, contrôleur OpenFlow.
Jaxon	Java	Oui	Développeur indépendant	Contrôleur OpenFlow en Java, basé sur NOX.
Helios	C	Non	NEC	Contrôleur OpenFlow extensible fournissant un noyau programmable pour des expériences intégrées.
Floodligtht	Java	Oui	BigSwitch	Contrôleur OpenFlow basé sur Beacon, il fonctionne avec les commutateurs OpenFlow physique et virtualisés.
SNAC	C++	Non	Nicira	Contrôleur OpenFlow basé sur NOX-0.4. Il utilise une interface web basé conviviale pour gérer le réseau, configurer les périphériques et surveiller les événements.
Ryu	Python	Oui	NTT, OSRG group	Système d'exploitation SDN, il vise à fournir un contrôle centralisé logique et des API pour créer de nouvelles applications de gestion et de contrôle réseau. Ryu supporte v1.0 OpenFlow, v1.2, v1.3, et les extensions Nicira.
NodeFlow	JavaScript	Oui	Développeur indépendant	Contrôleur OpenFlow mis en place pour Node.JS
Ovs-controller	C	Oui	Développeur indépendant	Contrôleur avec une implémentation Open vSwitch pour gérer un certain nombre de commutateurs distants via le protocole OpenFlow
Flowvisor	C	Oui	Stanford/ Nicira	Contrôleur mise en oeuvre pour un but spécial
RouterFlow	C++	Oui	CPqD	Contrôleur mise en oeuvre pour un but spécial

Notons que l'évolution de la notion du contrôleur loin d'être une solution a soulevé l'inquiétude de performance et de l'évolutivité de ce dernier.

Le contrôleur Ethane [18] hébergé sur une machine de bureau a pu recevoir jusqu'à 11 000 demandes de transferts par seconde et y a répondu en moins de 1,5 milliseconde. Une étude plus récente [27] sur l'implémentation de plusieurs contrôleurs OpenFlow (NOX-MT, Maestro, Beacon), menée sur une simulation de réseau avec 100.000 points connectés et 256 commutateurs, a montré qu'il était possible de traiter au moins 50 000 nouvelles demandes par seconde dans chacun des scénarios testés. Dans un autre test, sur une machine à huit (08) coeurs, la mise en oeuvre de NOX-MT (multi-thread) a géré 1,6 million de nouvelles demandes par seconde avec un temps de réponse moyen de 2 millisecondes. Au vu de ces résultats, un seul contrôleur est capable de gérer un nombre impressionnant de nouvelles demandes. En outre, les nouveaux contrôleurs en cours de développement tels que McNettle [27] destinés serveurs multi coeurs sont conçus pour évoluer avec de grandes charges de travail (Environ 20 millions de flux requêtes par seconde pour 5000 commutateurs). Toutefois, plusieurs contrôleurs peuvent être utilisés pour réduire la latence ou d'augmenter la tolérance aux pannes.

L'autre souci à résoudre est l'emplacement de contrôleur [28] permettant de déterminer à la fois le nombre optimal de contrôleurs et leur emplacement au sein de la topologie du réseau. Notons que pour l'évaluation de la performance et du dimensionnement du réseau, il est important d'avoir une idée précise de la latence sur les liaisons contrôleurs-commutateurs. Cela fut l'une des principales motivations de l'étude dans [29] qui évalue comment le contrôleur et le réseau gèrent la bande passante et la latence sur les liaisons de contrôle. Un autre aspect touchant la performance du réseau, se révèle par la redondance des contrôleurs. En effet, dans le souci d'assurer la performance, il est important d'avoir plus d'un contrôleur dans le Control Plane. Cette disposition permet en cas de panne d'un contrôleur que le réseau soit toujours fonctionnel. Cette étude a permis de conclure d'une part que la bande passante dans le lien arbitre le nombre de flux pouvant être traité par le contrôleur et d'autre part, de connaître le taux saturation. D'autres sujets importants sur l'évolutivité sont présentés dans [30].

Cette partie de l'architecture représente le niveau physique ou matériel du réseau. On y retrouvera donc routeurs et Switch qui serviront à l'acheminement des paquets. Pareillement à ce qui précède, le Data Plane est composé de 2 couches à savoir : Le « Network Infrastructure » et le « Southbound Interface ».

« Southbound Interfaces » (ou southbound APIs) sont les ponts de liaison entre les éléments de commande et d'expédition, étant ainsi l'instrument crucial pour séparer clairement le contrôle et la fonctionnalité de plan de données. Toutefois, ces APIs sont toujours étroitement liées aux équipements de transfert physique ou infrastructure virtuelle. Dans les faits, il faut au moins deux ans pour qu'un nouveau commutateur créé soit commercialisé. A cela, s'ajoutent des cycles de mise à jour qui peuvent durer neuf mois. Le développement de logiciels pour un nouveau produit peut aller de six mois à un an [38]. Ceci dit, les investissements de début dans ce sens sont très risqués. En tant qu'élément central, les « Southbound APIs » représentent l'un des obstacles majeurs pour l'introduction et l'adoption des nouvelles technologies du réseau. Ainsi, l'émergence des « Southbound APIs » du SDN propositions est considérée comme un avantage dans l'industrie du réseau. Ce qui, déjà a été démontré par l'interopérabilité entre les équipements OpenFlow et des équipements non-OpenFlow.

Cette partie est composée d'un ensemble d'équipements réseau (commutateurs, routeurs et pare-feu). Ils sont de simples équipements d'expédition, sans contrôle ni logiciel embarqué permettant de prendre des décisions autonomes. L'intelligence du réseau est déplacée du « Data Plane » vers une unité logique centralisée. Notons qu'avec le SDN, ce sont des nouveaux réseaux conceptuellement construits sur des interfaces standard et ouvert (OpenFlow), une approche cruciale pour assurer la compatibilité des configurations, la communication, l'interopérabilité entre les différentes données et les équipements du plan de contrôle. En d'autres termes, les interfaces ouvertes permettent de contrôler et de programmer tous les équipements réseau quel qu'en soit le concepteur.

Comme sus-évoqué le « Network Infrastructure » regroupe les équipements SDN. Malgré le fait que les réseaux SDN ne soient pas encore en première ligne, les responsables de productions d'équipements de réseau connaissent les avantages de cette technologie et le changement radical qu'il apportera dans les réseaux. De ce fait les équipements réseau se sont mis à la conception des équipements dont les commutateurs compatibles SDN. On notera ainsi la présence d'une base commune pour tous les commutateurs qu'importe le constructeur.

Ce n'est pas seulement l'approche de Cisco, étant donné que d'autres fournisseurs, notamment Arista, Extreme Networks ou Juniper Networks offrent aussi un accès direct à leurs produits. Un avantage de cette approche est qu'elle permet d'accéder de manière très détaillée et de prendre le contrôle, sur les éléments du réseau. Cette approche, cependant, ne fournit pas un point de contrôle central et est spécifique du fournisseur. Alors que certains fournisseurs de services réseau peuvent adopter cette approche à court terme, il est peu probable qu'elle s'implante sur le marché de l'entreprise [30].

Une raison plus puissante pour le changement d'orientation de la définition de la SDN, c'est que si le SDN est considéré comme délivrant des interfaces de programmation dans les équipements de réseau, alors sa valeur est beaucoup plus large. Vu de cette manière, le SDN permet aux entreprises de remplacer une interface manuelle dans l'équipement de réseau par une interface de programmation qui peut permettre l'automatisation des tâches telles que la configuration et la gestion des politiques de contrôle des flux et peut également permettre au réseau de répondre dynamiquement aux exigences des applications [31].

Alcatel-Lucent propose une solution SDN à ses clients en se basant sur sa stratégie existante nommée Application Fluent Network. L'équipementier ajoute à cette vision la brique SDN, qui apporte une automatisation complète et en temps réel de la configuration du réseau. Cette stratégie concerne des routeurs, des commutateurs conçus pour ajuster et optimiser la bande passante en temps réel pour les applications sur le LAN, le WAN et au sein des datacenters. Pour Alcatel-Lucent, les équipements sont capables de détecter les applications virtualisées et de leur appliquer des règles basées sur des profils pour adapter le réseau à ce trafic et garantir ainsi une qualité de service.
Ces politiques peuvent inclure des règles propres à chaque utilisateur, selon le type de périphérique et des applications. Avec l'Omniswitch du constucteur, les responsables réseaux peuvent ajuster dynamiquement les priorités d'accès au réseau et l'allocation de bande passante en fonction des SLA requis.
Pour l'adaptation au SDN, les Omniswitch comprennent plusieurs éléments dont une plus grande capacité de programmation avec les API RESTful. Ces dernières facilitent la gestion des applications, des contrôleurs externes et les plateformes d'orchestration comme OpenStack et CloudStack [31].

La solution HP couvre à la fois les couches d'infrastructure, de contrôle et d'applications avec « un contrôleur unique.» Ce type de contrôleur permet de programmer l'ensemble d'un réseau, au sein de Data Centers, de campus et d'agences. L'objectif des SDN est de remplacer le traditionnel paramétrage manuel par ligne de commande des équipements. Ce travail nécessite trop d'expertise et empêche une vision globale. Selon HP, il existe des produits SDN non intégrés qui s'ils offrent une gestion centralisée via un contrôleur, pêchent par manque de capacités de configuration automatique de l'infrastructure réseau. Ces produits ne disposent pas non plus d'applications SDN pour déployer de nouveaux services sur les réseaux de campus ou d'agences.
La solution de HP se veut complète. Elle ambitionne de couvrir l'ensemble des couches. Les réseaux sont virtualisés, programmables et automatisables. La mise en place d'une nouvelle application pour les utilisateurs ne doit pas prendre plus de quelques minutes. HP affirme être le seul fournisseur délivrant une solution complète de SDN qui automatise les tâches de configuration manuelle sur l'ensemble des couches matérielles et logicielles, du data center au poste de travail, via un plan de contrôle unique. HP se veut le premier acteur à proposer des technologies SDN pour les trois couches - infrastructure, logiciel de contrôle et Applications [31].

Cisco présente Cisco One, une architecture et une stratégie pour instiller de la programmabilité dans ses équipements réseau. Cette stratégie va plus loin selon Cisco que OpenFlow ou SDN (Software-Defined Networking ) proposés par la plupart de ses concurrents. Ceci devrait rendre transparente sa mise en place dans les entreprises. Cisco One signifie "Open Network Environment". Cisco One est conçu pour rendre les réseaux de Cisco plus flexibles et personnalisables afin de répondre aux nouveaux besoins tels que le Cloud, la mobilité, les réseaux sociaux, ou la vidéo. Cisco One intègre des APIS, des agents et des contrôleurs, et des technologies de « surcouche » sur les réseaux afin de rendre programmable chaque couche du réseau, depuis la couche transport jusqu'à la supervision. Les utilisateurs pourront programmer leur réseau via plusieurs protocoles et pas uniquement OpenFlow. Cisco One propose des APIs pour ses systèmes d'exploitation et de routage IOS, IOS-XR, et NX-OS. La mise à disposition de Cisco One a débuté par les plateformes ASR 1000 et ISR G2 routers. Les autres composants de Cisco One comprennent le commutateur virtuel Nexus 1000V.Cisco One permet de supporter divers modèles de déploiement programmables [31].

Juniper Networks travaille en collaboration avec d'autres acteurs de l'industrie sur une base Open Source pour créer un contrôleur de type SDN (software-defined network), pour des réseaux définis par voie logicielle. Ce contrôleur serait une alternative aux offres propriétaires de VMware et de Cisco. Définir ce contrôleur open-source semble être une priorité pour l'équipementier. En effet, VMware et Cisco, avec leurs positions de leaders sur la virtualisation des serveurs et sur les commutateurs pour datacenters, ainsi que leurs importants investissements dans les contrôleurs SDN, sont en position de disposer de parts de marché importantes dans le SDN. Juniper Networks, l'équipementier espère voir un contrôleur SDN Open Source s'imposer comme un standard de facto largement soutenu par l'industrie. Il s'agirait de rejouer sur le marché des SDN une partition déjà connue : Linux, Apache et Hadoop sont devenus des solutions Open-Source dominantes des marchés des systèmes d'exploitation, des serveurs Web et de l'analyse Big Data. Juniper Networks a exposé sa stratégie SDN, qui se définie par l'ajout du support d'OpenFlow à des produits spécifiques. Cela rend possible les réseaux à base de matériels multifournisseurs grâce à la programmation par logiciel [30].

Brocade en rachetant Vyatta, un éditeur de solutions SDN Open Source ayant développé une architecture de virtualisation lui a permis de disposer de nouvelles opportunités de marché dans la virtualisation de datacenters, le cloud public et privé et les services managés . Brocade a donc utilisé la technologie de Vyatta pour proposer une infrastructure réseau dynamique hautement virtualisée à ses clients de manière à accélérer le déploiement des applications et réduire les cycles de développement [31].

Switch/Prix ()	Nombres de Ports	Débit	Capacité Routeur/Commutation	Fonction administration
HP 12500 3 187 952 FCFA	864 ports de 10 GbE	10,8 Bpps maximum	24,3 Tbits/s maximum	IMC - Intelligent Management Center administration hors bande (RS-232C série) interface de ligne de commande, Telnet, FTP, interface de terminal (RS-232C série)
Omniswitch10 000 295 181 FCFA	8 x 10/100 + 2 x SFP Gigabit combiné + 2 x Gigabit SFP	1 gigabit	Interfaces virtuelles (VLAN) : 4000, Entrées ACL : 2048, Route RIP : 256, Routes statiques : 256	8 x 10Base-T/100Base-TX - RJ-45 - PoE+ ? 2 x 10Base-T/100Base-TX/1000Base-T - RJ-45 ? 4 x SFP (mini-GBIC) Hi-Speed USB : 1 x USB à 4 broches, type A ? Série : 1 x RS-232 - RJ-45 - gestion
Juniper EX-Series Ethernet 4 495 651 FCFA	10 X 10 ports	EX4200-24P/24T/24F : 65 millions de paquets par seconde (vitesse filaire), EX4200-48P/48T : 101 millions de paquets par seconde (vitesse filaire)	EX4200-24P/24T/24F : 88 Gbit/s, EX4200-48P/48T : 136 Gbit/s	Interface de ligne de commande, Telnet, FTP
Brocade FWS 648G 2 211 643 FCFA	48 x 10/100/1000 (PoE) + 4 x SFP	10/100/1000 Mbps	1000 Mbit/s à 1 Gbit/s	Ethernet 1000Base-T, Ethernet 100Base-TX, Ethernet 10Base-T

Avec l'évolution du SDN, beaucoup d'équipementiers de réseau et des particuliers proposent une multitude de solutions SDN pour le réseau. Parmi cette multitude, on distingue des solutions propriétaires donc payantes et des solutions open sources ou gratuites. Loin de faire une liste exhaustive de ses différentes solutions passons en revue les principales.

Juniper Networks propose Contrail qui est une solution simple, ouverte, et agile basée sur le SDN qui automatisent et orchestrent la création de réseaux virtuels hautement évolutifs. Ces réseaux virtuels permettent d'exploiter la puissance du Cloud, de nouveaux services, l'augmentation de l'agilité de l'entreprise et entraîne la croissance du chiffre d'affaires. Il permet de créer des réseaux virtuels qui intègrent de façon transparente avec les réseaux physiques existants, et qui sont faciles à gérer et orchestrer. Il permet d'interagir avec une large gamme d'hyperviseurs, systèmes d'orchestration. Grâce à la virtualisation de réseau avec Contrail on peut personnaliser les réseaux sécurisés dans un environnement multi-tenant, contrôler simplement la politique d'insertion et de chaînage en fonction du réseau virtuel, accélèrer les délais de commercialisation des services et améliorer l'agilité et la prévisibilité de l'entreprise. Open source, les standards ouverts et des interfaces ouvertes dans l'architecture du système permettent d'assurer la transparence, l'interopérabilité des fournisseurs agnostique et une plate-forme pérenne. Il permet l'analyse de l'infrastructure et de visualisation, permet de mieux comprendre les réseaux virtuels et physiques pour simplifier les opérations et décisions grâce à une planification proactive et des diagnostics prédictifs. Le niveau hyperviseur vRouter transmet le plan fourni à la fréquence de ligne de traitement de paquets de recouvrement dans un environnement virtualisé, conteneurisé ou en métal nu, mutualisé complètement découplé des commutateurs matriciels physiques sous-jacents. L'API REST facilite la configuration opérationnelle et analytique, l'automatisation et l'intégration avec les systèmes de Cloud orchestration. La solution repose sur le moteur Junos V Contrail, comprenant un contrôleur SDN, un routeur virtuel et un moteur d'analyse, et s'intègre au pare-feu maison Firefly Perimeter. L'architecture se veut standardisée et compatible avec plusieurs hyperviseurs et plateformes d'orchestration du cloud dont CloudStack et OpenStack. Juniper annonce la disponibilité de Contrail sous licence logicielle, à 1003533 FCFA par poste ou sur abonnement pour 591314 FCFA annuels par poste [48].

Le réseau programmable évolué (EPN) de Cisco est une plate-forme complémentaire qui regroupe les fonctionnalités de mise à disposition de services des infrastructures physiques et virtuelles. La plate-forme de services évolués de Cisco (EPN) est capable d'aider à transformer une entreprise et à accélérer le délai de rentabilisation, tout en réduisant les coûts d'exploitation et en déployant de nouveaux services à la vitesse du web répondant à ses besoins. Celle-ci utilise la mise en réseau définie par le logiciel (SDN), la virtualisation des fonctions réseau, des API ouvertes et des fonctionnalités d'orchestration avancées pour créer une plate-forme de services flexible et modulaire. Vous pouvez l'utiliser pour accélérer le déploiement de nouveaux services innovants. Le réseau programmable évolué (EPN) représente le fondement de l'architecture d'environnement réseau ouvert Cisco (Open Network Environment, ONE). Il s'agit d'une couche d'infrastructure composée de périphériques physiques et virtuels qui, ensemble, forment le fabric unifié de bout en bout d'un réseau programmable. L'EPN est conçu pour faire converger les fonctions de la périphérie, du noyau et du data center à l'aide des différentes technologies de pointe de Cisco. Il permet de générer de nouvelles opportunités pour créer des modèles de revenus, simplifier les opérations et offrir de nouvelles expériences grâce à l'Internet of Everything. La solution mis en avant par CISCO est Elastic. Elastic Access est donc en ce moment positionné comme une brique essentielle du Cisco EPN ou dudit Evolved Programmable Network, l'infrastructure combinant solutions physiques et virtuelles pour pouvoir former une structure unifiée de bout en bout pour un réseau programmable. Il est d'environ 2348673 FCFA par an pour un parc de 3postes [49].

NEC a été leader dans le domaine de la virtualisation de réseau se concentrant sur ??Software-Defined Networking (SDN) et plus sur des fonctions de virtualisation (NFV). Pour résoudre les défis des opérateurs télécoms, NEC a été le premier à commercialiser des solutions OpenFlow, VEPC (Evolved Packet Core virtualisé: VmFM et VS / P-GW) et vMVNO-GW . Éprouvée dans un environnement commercial carrier-grade, les solutions SDN et NFV de NEC offrent des performances, la stabilité et la fiabilité. La solution NEC construit sur ??une fondation solide qui est créée par des années de l'innovation technologique et l'expérience commerciale profonde dans l'industrie informatique et Télécom. VEPC est un système de réseau mobile-core qui accueille des systèmes d'accès LTE. Propulsé par classe transporteur, la plate-forme de virtualisation de NEC et Software Defined Networking (SDN) la technologie, VEPC optimise TCO et le service de la qualité des opérateurs mobiles. Au lieu d'utiliser un matériel dédié, VEPC virtualise toutes les fonctions d'un serveur à usage général. Le logiciel optimise l'allocation des ressources de serveur et de réseau pour chaque service sur la plate-forme de virtualisation. VEPC peut fournir tous les services sur des serveurs à usage général, qui entraîne des coûts de maintenance réduits. VEPC travaille dans un NFVI ouverte (Réseau Fonctions Infrastructure de virtualisation) de l'environnement. Cette solution à l'acquisition s'élève à une valeur de 845683 FCFA [50].

6WINDGate ™ est la seule solution logicielle commerciale qui résout les défis de performance du réseau critiques pour les OEM délivrant des fonctions réseau avancées dans les marchés SDN tels que les infrastructures mobiles, appareils de réseau et la mise en réseau de centre de données. 6WINDGate délivre généralement une amélioration de la performance 10x du plan de données, par rapport à des piles standard de Linux, tout en conservant une compatibilité totale avec les API d'application standard. L'intégration transparente avec OpenStack et OpenFlow, 6WINDGate comprend une suite complète de couches 2 optimisée grâce aux protocoles de couches 4 qui représentent une solution complète de plan de données pour les équipements de réseau. Avec un support complet pour les hyperviseurs standards, 6WINDGate fournit des performances de pointe pour les appliances virtuelles sur des plateformes matérielles des produits de base. Ce service s'élève annuellement par poste à 373984 FCFA par poste [51].

OpenStack est un logiciel libre qui permet la construction de cloud privé et public. Il est aussi une communauté et un projet en plus d'un logiciel qui a pour but d'aider les organisations à mettre en oeuvre un système de serveur et de stockage virtuel. Il est composé d'une série de logiciels et de projets au code source libre qui sont maintenus par la communauté incluant: OpenStack Compute (nommé Nova), OpenStack Object Storage (nommé Swift), OpenStack Image Service (nommé Glance), et Neutron (auparavant nommé Quantum). Tout en réduisant le risque de « lock-in » associé à des plates-formes propriétaires, il offre également la flexibilité et choix grâce à une communauté mondiale très engagé composée d'innovateurs, de développeurs, de fournisseurs logiciels et matériels et de prestataires de services [52]. OpenStack est un choix stratégique pour de nombreux types d'organisations et fournisseurs de services qui cherchent à offrir des services de cloud computing sur du matériel standard, aux entreprises qui cherchent à déployer cloud privé, à de grandes entreprises déployant une solution globale de cloud sur plusieurs continents.

Amazon Web Services (AWS) est une collection de services informatiques distants (aussi appelés services Web) fournis via internet par le groupe américain de commerce électronique Amazon.com.

Lancé officiellement en 2006, Amazon Web Services fournit des services en lignes à d'autres sites internet ou applications clientes. La plupart d'entre eux ne sont pas directement exposés à l'utilisateur final, mais offrent des fonctionnalités que d'autres développeurs peuvent utiliser. En juin 2007, Amazon revendiquait plus de 330 000 développeurs ayant souscrit pour l'utilisation des Amazon Web Services1.

Parmi ses grands clients, figurent la NASA, Netflix et le service de renseignement extérieur américain (CIA). Les offres Amazon Web Services sont accessibles en HTTP, sur architecture REST et par le protocole SOAP [47].

En énumérant les solutions SDN existantes nous avons distingué celles propriétaires et celles open sources. Partant du principe que les solutions propriétaires sont pour la plupart payantes et coûteuses à l'occasion, notre choix est donc orienté vers les solutions open sources. Parmi ceux-ci, nous avons choisis OpenStack car il est un système d'exploitation qui procure la même élasticité qu'une infrastructure Cloud et permet l'intégration du SDN.

Solutions	Auteur	Open Source	Caractéristiques	Coût(CFA)/An	Inconvénients
Contrail	JUNIPER	Non	Solution ouverte, et agile basée sur le SDN. Facilite la création et la gestion de réseaux virtuels hautement évolutifs	591314/Poste	Utilisation impossible du logiciel en dehors de la durée de licence, Respect des libertés fondamentales. Adaptabilité, Interopérabilité, Redistribution
EPN	CISCO	Non	Plate-forme complémentaire regroupant les fonctionnalités de mise à disposition de services des infrastructures physiques et virtuelles.	2348673/ 3 Postes	Utilisation impossible du logiciel en dehors de la durée de licence, Respect des libertés fondamentales. Adaptabilité, Interopérabilité, Redistribution
VEPC	NEC	Non	Système de réseau mobile-core qui accueille des systèmes d'accès LTE.	845683/ 1 Poste	Utilisation impossible du logiciel en dehors de la durée de licence, Respect des libertés fondamentales. Adaptabilité, Interopérabilité, Redistribution
6WINDGate Networking Software	6WIND	Non	Relève le défi performance du réseau critique pour les OEM délivrant des fonctions réseau avancées dans les marchés SDN tels que les infrastructures mobiles, appareils de réseau et la mise en réseau de centre de données.	373984/1 Poste	Utilisation impossible du logiciel en dehors de la durée de licence, Respect des libertés fondamentales. Adaptabilité, Interopérabilité, Redistribution
OpenStack	Rackspace Hosting	Oui	Permet la construction de cloud privé et public. Met en oeuvre le SDN dans sa couche Neutron à partir de la version Havana.	Gratuit	Mise en place nécessitant des connaissances approfondies du système, multitude de versions, documentation rare.
AWS	Amazon	Oui	Collection de services informatiques distants (aussi appelés services Web) fournis via internet.	Gratuit	Intégralité des services hébergés chez le concepteur, impossible de modifier les configurations du concepteur en fonction de ses besoins.

Tableau 3: Comparatif des solutions SDN Chapitre III. Implémentation et test d'une solution Software-Defined Network (SDN)

OpenStack est une suite logicielle qui permet de gérer une plate-forme de Cloud Computing. Lancé en 2010 par Rackspace et la NASA, il est soutenu par un ensemble d'entreprises de la technologie. Le projet OpenStack, aujourd'hui, est l'un des principaux clouds privés et hybrides. OpenStack continue d'évoluer rapidement grâce a de nouvelles versions du code publié environ tous les six mois. La version actuelle d'OpenStack, Kilo, a été publiée en Avril 2015. Partout dans le projet, l'accent tend davantage à être mis sur les fonctionnalités de base que sur la facilité d'utilisation ; ce qui conduit parfois les nouveaux arrivants à considérer OpenStack comme complexe ou difficiles à déployer. Un large éventail d'entreprises, y compris Canonical, Mirantis et Rackspace, offre de services professionnels visant à masquer certaines des complexités derrière la livraison d'une installation sur mesure pour répondre aux besoins de leurs clients. Ces entreprises et d'autres offrent également leurs propres distributions du code OpenStack, ajoutant souvent des outils d'installation plus riche ou une intégration plus étroite avec d'autres projets open-source (comme Ubuntu, Canonical) ou de leurs propres produits.

De nos jours, c'est un système reconnu et utilisé par nombre d'acteurs du Cloud, notamment les deux Cloud souverains français (financés à hauteur de 75 millions d'euros par l'état) que sont Numergy et CloudWatt.

Nom	Date	Composants inclus
Austin	21 octobre 2010	Nova, Swift
Bexar	3 février 2011	Nova, Glance, Swift
Cactus	15 avril 2011	Nova, Glance, Swift
Diablo	22 septembre 2011	Nova, Glance, Swift
Essex	5 avril 2012	Nova, Glance, Swift, Horizon, Keystone
Folsom	27 septembre 2012	Nova, Glance, Swift, Horizon, Keystone, Quantum, Cinder
Grizzly	4 avril 2013	Nova, Glance, Swift, Horizon, Keystone, Quantum, Cinder
Havana	22 octobre 2013	Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer
Icehouse	17 avril 2014	Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer, Trove
Juno	16 octobre 2014	Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer, Trove, Sahara
Kilo	30 avril 2015	Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, Heat, Ceilometer, Trove, Sahara, Ironic

· « Nova » : Un des principaux modules d'OpenStack, il est le plus déployé. Nova est largement équivalente à Elastic Compute Cloud d'Amazon (E). Il est au centre du déploiement d'OpenStack, fournit les API que les développeurs utilisent pour démarrer, gérer et arrêter les machines virtuelles au sein d'un Cloud OpenStack. Nova est conçue pour être évolutive et pour fonctionner efficacement sur du matériel standard.

· « Swift » : Il fournit aux utilisateurs OpenStack une solution de stockage d'objets redondants, et il ne doit pas être confondu avec le module de bloc-stockage Cinder.

· « Cinder » : Il est le module de stockage de bloc d'OpenStack, conçu pour gérer une large gamme de baies de stockage commerciales dans la prestation de stockage permanent au niveau des applications hautement performantes telles que les bases de données. Un autre projet, Ceph de plus en plus populaire est conçu pour remplacer (partiellement ou complément) Cinder.

· « Neutron » : Précédemment connu sous le nom de Quantum, il est le module de mise en réseau d'OpenStack. Il permet de gérer la communication entre les instances OpenStack à travers un large éventail d'architectures de réseaux physiques et virtuels. Neutron supporte OpenFlow, l'une des principales spécifications pour le domaine émergent de la Software Defined Networking (SDN).

· « Horizon » : C'est le tableau de bord Web d'OpenStack, augmentant les API offert par chaque module d'OpenStack avec une seule console de gestion graphique.

· « Keystone » : C'est le service de répertoire central d'OpenStack, qui gère l'enregistrement, l'autorisation et l'authentification des utilisateurs. Keystone peut intégrer des services d'authentifications existantes telles que LDAP pour réutiliser les informations d'identification utilisateur créées ailleurs.

· « Glance » : Il est le répertoire d'OpenStack pour les images de machines et serveurs. Il peut être utilisée pour stocker et déployer rapidement des machines virtuelles prédéfinies (par exemple un Ubuntu serveur ou base de données serveur ou une machine de développement CentOS). Les images peuvent être stockées localement dans un Cloud d'OpenStack ou partagées à travers un certain nombre de Cloud ?? grâce à REST .

· « Ceilometer » : Il offre un référentiel unique pour stocker des données d'usage à travers le Cloud d'OpenStack. Ces données d'utilisation sont destinées à soutenir les systèmes de facturation et vérification processus, et il contribue également à la surveillance générale de la performance d'un Cloud.

· « Heat » : Il est le service de coordination d'OpenStack permettant la gestion d'un cloud des infrastructures et des applications [44].

Comme nous avons pu le remarquer, OpenStack a évolué de versions en versions. Notons donc que jusqu'à la version « Grizzly », le module de gestion de réseau, « Quantum » ne prenait pas encore la technologie SDN. Ainsi, à partir de la version « Havanna » « Quantum » fut changé par « Neutron ». Ce dernier avait pour particularité de supporter le SDN.

OpenStack Neutron est un projet axé sur le Network-as-a-Service (NaaS) dans un environnement de machines virtuelles, basé sur le SDN. Neutron a remplacé le réseau d'origine qui était un API appelé Quantum. Neutron est conçu pour combler les lacunes du module réseau dans des environnements de Cloud, ainsi que le manque de contrôle d'utilisateurs dans un environnement multiutilisateur, de la topologie du réseau et de l'adressage. Toutes ces limites rendent difficile le déploiement des services de réseautage de pointe. OpenStack neutron fournit aux organisations un moyen d'éviter la surcharge sur le réseau dans les environnements de Cloud Computing et favoriser la mise en place du NaaS. Il est conçu pour fournir un mécanisme de "plug-in" qui offrira une option pour les opérateurs de déployer différentes technologies via l'API Quantum. Il permet également de créer des réseaux privés et d'y contrôler l'adressage

· connecter les machines virtuelles en reproduisant une infrastructure réseau virtuelle (architecture multi-tiers par exemple)

· éventuellement, apporter les services réseaux supplémentaires (Firewall, Load Balancer, VPN ...)

Pour cela, OpenStack définit plusieurs abstractions pour l'infrastructure réseau

· Port : C'est la représentation des cartes réseau des VM, aussi appelées Virtual NIC ou vNIC

· Network : C'est un segment virtuel de niveau 2, c'est-à-dire un domaine de broadcast (typiquement un VLAN, mais peut également être un tunnel GRE ou un VxLAN)

· Subnet : c'est un plan d'adressage ; en principe on a un subnet pour un network, mais comme sur une infrastructure physique, il est possible de créer plusieurs subnets par network

· Router : un routeur virtuel, capable de router entre les subnets et d'effectuer de la NAT pour sortir sur Internet

· Floating IP : une IP sur un réseau (network) externe qui pointe sur un port. C'est donc la NAT externe de notre VM

Cette couche d'abstraction va permettre de créer une infrastructure réseau sans se préoccuper des technologies utilisées. En effet l'API ne définit que les moyens de gérer ces abstractions, et non pas leur implémentation qui est définie au niveau des plugins. En ce qui concerne le réseau, le plugin ML2 (Modular layer 2) gère l'implémentation de la configuration réseau. C'est un plugin modulaire sur lequel on peut greffer différents drivers correspondant soit à des types de réseau (VLAN, GRE, VxLAN) soit à des mécanismes (c'est-à-dire des implémentations spécifiques, par exemple pour Cisco ou VMWare). Cela lui permet de gérer de nombreuses implémentation différentes, que ce soit pour des switches virtuels tels que Open vSwitch, linux bridge, hyper V, ou des switches physiques, et en plus d'être facilement extensibles (si l'on veut introduire un nouveau type de réseau ou si un constructeur/éditeur veut ajouter le support pour ses équipements, seule la partie driver est à écrire) [45].

Nous avons noté que c'est avec l'arrivée de Neutron que le SDN est directement implémentée dans OpenStack. Ainsi bien avant il fallait installer un plugin après l'installation d'OpenStack. Notons que la plupart des solutions de réseaux virtuels utilisent un contrôleur qui interagit avec le système de cloud via une API.

· De centraliser le plan de contrôle permettant de créer des réseaux virtuels isolés pour chaque utilisateur.

Retenons donc que, l'implémentation du SDN dans OpenStack permet la gestion des commutateurs virtuels et autres équipements. Il est plus facile de regrouper les fonctionnalités de mise en réseau virtuelle dans un contrôleur autonome et de le faire interagir avec de multiples systèmes de cloud à travers un API ou un plugin (celui de neutron par exemple).

A travers la présentation d'OpenStack, nous avons pu distinguer les différentes versions et les couches les constituant. De même grâce aux paragraphes portant sur OpenStack neutron et le SDN, nous avons compris le fonctionnement et le bien fondé de l'intégration du SDN à la couche réseau d'OpenStack. Ainsi, pour le compte de notre mise en place, nous procéderons à l'installation de la version Grizzly d'OpenStack pour sa stabilité à laquelle nous ajouterons le plugin neutron afin de pouvoir implémenter le SDN dans OpenStack.

Le système à mettre en place nous permettra de simuler un service de multimédia.

Nous procédons à l'installation d'OpenStack Grizzly auquel nous ajouterons le plugin neutron.

· Un processeur supportant la virtualisation matérielle ( test sur la page KVM)

· Il est nécessaire de configurer le réseau en IP Fixe. Supprimez les paquets Network-Manager ou Wicd et resolvconf.

Tous les services OpenStack seront installés sur la même machine.
La configuration abordée suppose l'utilisation de 2 interfaces réseau.

L'utilisation d'une interface wifi pour les bridges peut se révéler très complexe voire impossible. Préférez une interface virtuelle

for a in `ifconfig | awk '/Link/ { if ($1 != "lo") print $1 }'`; do sudo ifdown $a ; done

Assurez-vous d'avoir décommenté l'option permettant le forward des paquets en IPV4 dans le fichier /etc/sysctl.conf :

Les volumes LVM serviront de disques durs supplémentaires pour les serveurs virtuels.

Les commandes qui suivent supposent que vous avez un disque dur /dev/sdc vide sans partition. Adaptez les commandes en fonction de votre configuration.
Créez une partition non formatée de 100Gigas sur /dev/sdc en adaptant à votre configuration:

Vous avez maintenant une partition primaire vide de 100 Gigas /dev/sdc1.
Créez maintenant le volume LVM. Attention, le nom nova-volumes doit être respecté:

RabbitMQ est un courtier de messages se basant sur le standard AMQP afin d'échanger avec différents clients.
Pour faire simple: c'est le service qui permet aux composants OpenStack de communiquer entre eux.

Chaque composant possède sa base de données MySQL, contenant toutes les données modifiables à chaud (ID des images disques, des instances virtuelles, réseaux, identités...). Les données de configuration fixes sont stockées dans des fichiers texte.

Il est possible d'utiliser un autre SGBD, MySQL étant recommandé dans la documentation OpenStack.

Pour indiquer a MySQL que le serveur doit écouter sur toutes les adresses et pas seulement sur la boucle locale, modifiez sa configuration en ouvrant avec les droits d'administration le fichier /etc/mysql/my.cnf pour remplacer:

Le composant Keystone est chargé de la gestion des utilisateurs et des services.

· L'objet Tenant que l'on peut représenter par un projet, une organisation au sein duquel les instances seront regroupées et administrées par les utilisateurs.

· L'objet Role qui définit le rôle de l'utilisateur sur un Tenant. Un utilisateur peut avoir un ou plusieurs rôles sur différents Tenants.

La gestion des différents services, comme Glance pour les images ou Swift pour le stockage.
La définition des points d'accès a ces différents services, les url et ports pour y accéder

Commencez par créer la base MySQL.
La commande suivante crée un utilisateur et sa base de données nommés "keystone". Changez SQLPASSWD par un mot de passe de votre choix.

Ouvrez avec les droits d'administration le fichier /etc/keystone/keystone.conf pour modifier les sections suivantes: Remplacez ADMPASSWD par un mot de passe de votre choix et et SQLPASSWD par le mot de passe MySQL défini ci dessus

Chaque commande ci-dessous contient l'authentification définie dans le fichier keystone.conf et utilisée par le client python sous la forme --token admin_token <mot de passe d'administration> --endpoint url_du_service_keystone <adresse du serveur:port/directory/>.

keystone --token ADMPASSWD --endpoint http://192.168.1.250:35357/v2.0/ user-create --name=admin --pass=ADMPASSWD --email=admin@example.com

+----------+-------------------------------------------------------------------------------------------------------------------------+

| password | $6$rounds=40000$cZhg187ypC6hMMD1$YQAxiXspmMVsu1di.o3UlZjvjlEO9WXii48Q29tyIXTzDpT5e92XBij9Pz4A5YLoGaccf8PBf1jcAan9YLDOl. |

+----------+-------------------------------------------------------------------------------------------------------------------------+

keystone --token ADMPASSWD --endpoint http://192.168.1.250:35357/v2.0/ user-create --name=glance --pass=ADMPASSWD --email=glance@example.com

+----------+-------------------------------------------------------------------------------------------------------------------------+

| password | $6$rounds=40000$pYJjQYtDJGdFB/nl$UOmryhbqCIROSPNhs8/svbPg2JIns31yImcAXTh/CXT3o9GOZTNYadZe2zp7M0.XeHqJD5bI1lhZYM09uSrmN0 |

+----------+-------------------------------------------------------------------------------------------------------------------------+

keystone --token ADMPASSWD --endpoint http://192.168.1.250:35357/v2.0/ user-create --name=nova --pass=ADMPASSWD --email=nova@example.com

+----------+-------------------------------------------------------------------------------------------------------------------------+

| password | $6$rounds=40000$ogH/.VbZJgp2pDF8$w7TCuRu95Q8c6PMR5Zmbs7Osjk8tXfkDKixzRY.t/Ghv/WvOoLD1au/cCbMWVfaEhr14RAGheTA2E2rPoVEjd1 |

+----------+-------------------------------------------------------------------------------------------------------------------------+

· admin: donne le droit de modifier la configuration des services (ex:allouer une plage d'adresse IP, un quota d'espace disque pour un projet etc...)

· Member: permet de gérer le contenu du projet (création d'instances de machines, ajout d'un disque virtuel a l'une d'elles etc...)

keystone --token ADMPASSWD --endpoint http://192.168.1.250:35357/v2.0/ role-create --name=admin

keystone --token ADMPASSWD --endpoint http://192.168.1.250:35357/v2.0/ role-create --name=Member

keystone --token ADMPASSWD --endpoint http://192.168.1.250:35357/v2.0/ role-create --name=KeystoneAdmin

keystone --token ADMPASSWD --endpoint http://192.168.1.250:35357/v2.0/ role-create --name=KeystoneServiceAdmin

keystone --token ADMPASSWD --endpoint http://192.168.1.250:35357/v2.0/ tenant-create --name=admin

keystone --token ADMPASSWD --endpoint http://192.168.1.250:35357/v2.0/ tenant-create --name=service

Il faut pour cela utiliser les ID affichés lors de la création des Users, Roles et Tenants. L'User "admin" a un Role admin sur le Tenant "admin".

keystone --token ADMPASSWD --endpoint http://192.168.1.250:35357/v2.0/ user-role-add --user-id c97c87b3ed894401975dd6d757b40330 --role-id 3d945f41e08e4e2db1584fdb8f05d333 --tenant_id 0f71e86d30e247d3b1216fe5f2f3aa50

Comme ce n'est pas pratique de recopier les IDs, les erreurs de frappe seront évitées grâce à l'outil awk. Il s'agira de définir les rôles ainsi:

keystone user-role-add --user-id `keystone user-list | awk '/ admin / { print $2 }'` --role-id `keystone role-list | awk '/ KeystoneAdmin / { print $2 }'` --tenant_id `keystone tenant-list | awk '/ admin / { print $2 }'`

keystone user-role-add --user-id `keystone user-list | awk '/ admin / { print $2 }'` --role-id `keystone role-list | awk '/ KeystoneServiceAdmin / { print $2 }'` --tenant_id `keystone tenant-list | awk '/ admin / { print $2 }'`

keystone user-role-add --user-id `keystone user-list | awk '/ glance / { print $2 }'` --role-id `keystone role-list | awk '/ admin / { print $2 }'` --tenant_id `keystone tenant-list | awk '/ service / { print $2 }'`

keystone user-role-add --user-id `keystone user-list | awk '/ nova / { print $2 }'` --role-id `keystone role-list | awk '/ admin / { print $2 }'` --tenant_id `keystone tenant-list | awk '/ service / { print $2 }'`

Il s'agira dans l'exemple qui suit de la création d'un compte utilisateur, d'un projet supplémentaire et définition du role avec la variable d'environnement $USER (remplacer par ce que vous voulez, c'est juste un exemple)
Le rôle "Member" est suffisant. Remplacez USRPASSWD par un mot de passe de votre choix. L'User $USER (xavier ici) a un Role "Member" sur le Tenant $USER (xavier ici).

keystone --token ADMPASSWD --endpoint http://192.168.1.250:35357/v2.0/ user-create --name=$USER --pass=USRPASSWD --email=$USER@example.com

+----------+-------------------------------------------------------------------------------------------------------------------------+

| password | $6$rounds=40000$3YPS4NJ1DqKdzEjc$XPGFlqCfu2ZCNUMJCjFMkvFfXrOkixuVq1I6.mjd9PXzU.4u6ELHYeNbvYJyiCGvUHaggIgo9rMESeA8v4x3Y1 |

keystone --token ADMPASSWD --endpoint http://192.168.1.250:35357/v2.0/ tenant-create --name=$USER

keystone --token ADMPASSWD --endpoint http://192.168.1.250:35357/v2.0/ user-role-add --user-id 13247a59ad844458ad36c0bd06451376 --role-id 84697b61736c439288900904bdf4a48d --tenant_id c6f05a03b4aa482c91b61a2230356618

keystone --token ADMPASSWD --endpoint http://192.168.1.250:35357/v2.0/ service-create --name=keystone --type=identity --description='Keystone Identity Service'

keystone --token ADMPASSWD --endpoint http://192.168.1.250:35357/v2.0/ endpoint-create --region RegionOne --service_id=41905e02540d48228166c6d06ddcd9f0 --publicurl=http://192.168.1.250:5000/v2.0 --internalurl=http://192.168.1.250:5000/v2.0 --adminurl=http://192.168.1.250:35357/v2.0

Les services et points d'accès des autres services seront ajoutés après l'installation du composant bien qu'il soit possible de les définir dès maintenant.

Il y a plusieurs façons possibles de s'identifier en lançant une commande keystone.

· La méthode d'identification utilisée précédemment avec le mot de passe d'administration (variable admin_token définie dans le fichier keystone.conf) avec les arguments --endpoint et --token

· La méthode user/password avec les arguments --username, --tenant_name, --password, après définition des utilisateurs, rôles et projets, et l'argument --auth_url.

keystone --username admin --password ADMPASSWD --tenant_name admin --auth_url http://localhost:5000/v2.0 user-list

Pour les deux méthodes, il est possible d'utiliser des variables d'environnement pour éviter de ressaisir tous les arguments à chaque commande.

Pour éviter de refaire un export des variables à chaque ouverture de terminal, vous pouvez les exporter automatiquement.
Il suffit de créer un fichier .novarc dans votre Dossier Personnel contenant les lignes suivantes

Les variables seront exportées comme variables d'environnement et vous pourrez utiliser toutes les commandes sous la forme simple sans ressaisir les informations d'authentification.

+----------------------------------+---------+--------------------------+--------+

Les commandes keystone role-list et keystone tenant-list affichent respectivement la liste des rôles et tenants.

Il est bien sûr possible d'envoyer des commandes à partir de n'importe quel autre ordinateur où le paquet python-keystoneclient est installé.

La prochaine étape est l'installation du service d'images Glance.
C'est le service chargé de distribuer les images de disque dur système utilisées par les machines virtuelles.

La commande suivante crée un utilisateur et sa base de données nommés "glance". Changez SQLPASSWD par un mot de passe de votre choix.

Il faut aussi créer les services et points d'accès correspondants pour Keystone

keystone service-create --name=glance --type=image --description='Glance Image Service'

keystone endpoint-create --region RegionOne --service_id=39bbd3107c4c4153a408a3b6a34ef931 --publicurl=http://192.168.1.250:9292/v1 --internalurl=http://192.168.1.250:9292/v1 --adminurl=http://192.168.1.250:9292/v1

Dans les fichiers ci-dessous, SQLPASSWD est le mot de passe MySQL Glance, ADMPASSWD le mot de passe du compte de service Glance

Ouvrez avec les droits d'administration le fichier /etc/glance/glance-api-paste.ini, allez à la fin pour modifier ces lignes avec les valeurs correspondant à votre installation:

Vérifiez maintenant si tout fonctionne correctement. Téléchargez une première image pour tester:

wget http://uec-images.ubuntu.com/releases/precise/release/ubuntu-12.04-server-cloudimg-amd64-disk1.img

glance add name="Ubuntu 12.04 cloudimg amd64" is_public=true container_format=ovf disk_format=qcow2 < ubuntu-12.04-server-cloudimg-amd64-disk1.img

=====================================================================================================================================================================================================================================[100%] 136.648660M/s, ETA 0h 0m 0s

------------------------------------ ------------------------------ -------------------- -------------------- --------------

d1b7defa-0c35-4e8c-aef5-0d58c8d80a52 Ubuntu 12.04 cloudimg amd64 qcow2 ovf 230490112

La commande glance details affiche des informations détaillées sur toutes les images.

================================================================================

glance add name="<Image name>" is_public=true container_format=<container_format> disk_format=<disk_format> < <filename>

· is_public=true : L'image est visible (true) ou non (false) dans tous les projets

· <container_format> : Container Type de container bare pas de container, ovf OVF Container, aki ari ami Amazon kernel ramdisk ou machine

Passez maintenant à l'installation de Nova, la gestion des instances des machines virtuelles, de leur espace disque et du réseau.

La commande suivante crée un utilisateur et sa base de données nommés "nova". Changez SQLPASSWD par un mot de passe de votre choix

Création des services et points d'accès pour Keystone, au nombre de 2: les services de type compute (auquel on donne le nom de "nova") et de type volume (auquel on donne le nom de "volume").

keystone service-create --name=nova --type=compute --description='OpenStack Compute Service'

keystone endpoint-create --region RegionOne --service_id=4ba6c7149dd1421f8c429afc0c8dbdfe --publicurl='http://192.168.1.250:8774/v2/%(tenant_id)s' --internalurl='http://192.168.1.250:8774/v2/%(tenant_id)s' --adminurl='http://192.168.1.250:8774/v2/%(tenant_id)s'

keystone service-create --name=volume --type=volume --description='OpenStack Volume Service'

keystone endpoint-create --region RegionOne --service_id=de65a68c5ae34737bc6678f6c7bc884a --publicurl='http://192.168.1.250:8776/v1/%(tenant_id)s' --internalurl='http://192.168.1.250:8776/v1/%(tenant_id)s' --adminurl='http://192.168.1.250:8776/v1/%(tenant_id)s'

Dans les fichiers ci-dessous, SQLPASSWD est le mot de passe MySQL Nova, ADMPASSWD le mot de passe du compte de service Nova

Ouvrez avec les droits d'administration le fichier /etc/nova/nova.conf et remplacer tout avec les lignes ci dessous.
La configuration obtenue utilisera le mode DHCP. La ligne "nova.scheduler.simple.SimpleScheduler" définit une utilisation avec un seul serveur.
Pour un mode VLAN, pour utiliser plusieurs serveurs ou d'autres options, reportez-vous à la documentation OpenStack (en).

Toutes les entrées --flat... correspondent au réseau privé(172.16.0.0/24, début 172.16.0.2), destiné aux communications entre les VMs (pour Virtual Machine ou machines virtuelles), les autres serveurs Nova ou de stockage s'il y a...

--floating_range est le réseau public (LAN ou Internet) sur lequel est branché l'interface br0, pour attribuer une adresse aux VMs sur le réseau public. L'adresse 192.168.1.250 est celle de l'interface br0, ne remplacez pas par 127.0.0.1, ça ne fonctionnera pas.

for a in libvirt-bin nova-network nova-compute nova-api nova-objectstore nova-scheduler nova-volume nova-cert nova-consoleauth novnc; do sudo service "$a" stop; done

for a in libvirt-bin nova-network nova-compute nova-api nova-objectstore nova-scheduler nova-volume nova-cert nova-consoleauth novnc; do sudo service "$a" start; done

for a in libvirt-bin nova-network nova-compute nova-api nova-objectstore nova-scheduler nova-volume nova-cert nova-consoleauth novnc; do sudo service "$a" stop; done

for a in libvirt-bin nova-network nova-compute nova-api nova-objectstore nova-scheduler nova-volume nova-cert nova-consoleauth novnc; do sudo service "$a" start; done

Vous pouvez maintenant vérifier que tous les services fonctionnent, le résultat dans la colonne STATE doit être

· un XXX : quelque chose n'as pas fonctionné, consultez les logs dans /var/log/nova/nova-le_nom_du_service_KO.

2012-05-16 00:20:09 DEBUG nova.utils [req-527f4f50-f02e-41da-bc96-43d3d9070807 None None] backend <module 'nova.db.sqlalchemy.api' from '/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.pyc'> from (pid=9869) __get_backend /usr/lib/python2.7/dist-packages/nova/utils.py:658

L'affichage du résultat d'une commande est beaucoup plus rapide que son exécution réelle. Si vous n'obtenez pas de message d'erreur, patientez quelques instants et vérifiez avec une commande d'affichage que l'action a bien été prise en compte.
Relancer une commande ou demander son annulation alors qu'elle est en cours d'exécution peut rendre le composant Nova instable et empêcher la suppression de l'action demandée ou laisser des entrées indésirables dans la base de données. Exemples: l'attribution d'une adresse IP publique ou la création d'un disque virtuel.
N'hésitez pas à... patienter

+--------------------------------------+-----------------------------+--------+--------+

+--------------------------------------+-----------------------------+--------+--------+

Profitez-en pour créer les réseaux privés et publics. Les adresses seront enregistrées dans la base MySQL. Le réseau public

Le réseau privé, destiné aux communications entre les VMs, les autres serveurs Nova ou de stockage s'il y a...

sudo nova-manage network create private --fixed_range_v4=172.16.0.0/24 --num_networks=1 --bridge=br1 --bridge_interface=eth1 --network_size=256

Par défaut, les règles de parefeu bloquent les paquets entrants sur l'interface publique à destination des VMs. Il est possible de créer des ensembles de règles. L'ensemble des règles utilisées devra être spécifié au lancement de chaque instance. Ci-dessous un exemple de création de règles sur l'ensemble "default" créé automatiquement à l'installation, si vous voulez autoriser le ping et SSH pour toutes les VMs sur l'interface publique ( icmp -1 correspond a tout ).

Maintenant que tout fonctionne, vous allez pouvoir créez votre première VM.
Assurez-vous d'avoir créé une clé SSH:

Il faut définir les spécifications de la future VM, pour voir les possibilités, utilisez la commande ci-dessous, la création de vos propres définitions étant bien sûr possible:

Pour la suite, il sera utilisé l'ID 1 correspondant à une machine disposant de 512 Mb de RAM, 1 CPU virtuel et aucun disque supplémentaire.

Lancez votre première VM avec la commande nova boot, le paramètre --flavor indique les spécifications choisies, --image l'ID de l'image fournie par glance, vient ensuite le nom et la clé ssh utilisée. Indiquez aussi l'ensemble de règles de parefeu, sinon c'est l'ensemble "default" qui est appliqué.

nova boot --flavor 1 --image d1b7defa-0c35-4e8c-aef5-0d58c8d80a52 myfirstvm --key_name key1 &

[1]+ Fini nova boot --flavor 1 --image d1b7defa-0c35-4e8c-aef5-0d58c8d80a52 myfirstvm --key_name key1

Un récapitulatif des propriétés de la machine s'affiche. Pour le réafficher, utilisez la commande

+--------------------------------------+-----------+--------+--------------------+

+--------------------------------------+-----------+--------+--------------------+

+----+--------+--------------+------+-------------+--------------------------------------+

Vous pouvez maintenant vous reconnecter à la VM pour partitionner ce disque et l'utiliser.

Connectez maintenant cette instance virtuelle à votre LAN.
Il faut tout d'abord allouer une adresse IP

Patientez quelques secondes et vérifiez la présence sur votre LAN d'une machine à cette adresse

+--------------------------------------+-----------+--------+---------------------------------+

+--------------------------------------+-----------+--------+---------------------------------+

Il est bien sûr possible d'envoyer des commandes à partir de n'importe quel autre ordinateur où les paquets python-novaclient,python-nova-adminclientsont installés.

L'interface graphique, le Dashboard Horizon, a été développée pour simplifier l'administration du serveur et des projets. L'accès se fait à partir d'un navigateurweb pointant à l'adresse du serveur.
Les différents services doivent être installés et configurés avant de pouvoir l'utiliser. Une grande partie des commandes est alors à portée d'un clic de souris.

Ouvrez votre navigateur favori à l'adresse de votre interface publique ou 127.0.0.1

Comme pour les commandes shell, l'affichage du résultat d'une commande ne garantit pas qu'elle soit entièrement exécutée. Si vous n'obtenez pas de message d'erreur, la mise à jour de la page peut demander quelques secondes supplémentaires.
Relancer une commande ou demander son annulation alors qu'elle est en cours d'exécution peut rendre le composant Nova instable et empêcher la suppression de l'action demandée ou laisser des entrées indésirables dans la base de données. Exemple: lors de la suppression d'un disque virtuel, les données sont supprimées avant que l'espace ne soit libéré.
N'hésitez pas à... patienter

Les identifiants de connexion de l'administrateur sont les mêmes que ceux du fichier .novarc. Si vous avez suivi ce document sans rien changer, il s'agit donc pour le compte d'administration de:
Username : admin Password: ADMPASSWD.
Les comptes qui ont pour rôle "admin" ont accès à l'interface d'administration sur le Dashboard, ainsi qu'à leur(s) projet(s). Les rôles "Member" n'ont accès qu'à leur(s) projet(s).

· Overview : Récapitulatif de l'usage des serveurs par projet, utilisation actuelle en nombre de CPU virtuels, RAM et Disques puis compteur en CPU et espace disque(GB) par heures.

· Instances : Liste des instances de machines virtuelles actuelles plus quelques infos globales comme le projet auquel elles appartiennent, le serveur hôte, l'adresse IP, la taille, le statut et les actions en cours.

· Flavors : La liste des types d'instances disponibles, leurs spécifications en nombre de CPUs, mémoire, espace disque. La création de nouvelles définitions d'instance est possible.

· Projects : les projets existants et leur statut. Il est possible de créer de nouveaux projets.

· Users : La liste des utilisateurs enregistrés, avec la possibilité d'ajouter ou d'éditer les détails mais pas d'ajouter l'utilisateur à plusieurs projets.

· Quotas : Les quotas définis sur les ressources des serveurs, pas de modification possible.

Un bouton permet de basculer entre les différents projets dont l'utilisateur est membre, si il y a. Puis viennent les menus :

· Overview : Récapitulatif, comme dans la partie Admin, mais ne concernant que le projet sélectionné.

· Instances & Volumes : La liste des instances existantes et les possibilités de les éditer, la création ou modification des volumes disques virtuels.

· Images & Snapshots : Liste des images autorisées pour le projet, sert a lancer de nouvelles instances. Regroupe aussi les instantanés disponibles, instances et volumes disques.

· Acces & Security : Les adresses IP disponibles pour connecter les instances au réseau public avec possibilité de création, les groupes de règles de pare-feu et leur interface d'édition, et enfin la liste des clés SSH avec l'import ou la création de certificat.

L'intérêt d'OpenStack étant de déployer rapidement des instances de machines virtuelles, ça ne servirait à rien de devoir passer ensuite des heures à les configurer. La création de vos propres images vous permettra de gagner un temps précieux.
Plusieurs grandes distributions ont été testées avec succès, dont Ubuntu et Debian, RedHat et Centos mais aussi Mandriva. D'autres systèmes peuvent aussi servir comme FreeBSD ou encore Windows.
Pour un système Linux, les pré-requis sont : un système à jour, Curl et un serveur SSH. Pour FreeBSD ou Windows, prévoyez l'installation du pilote Virtio.(driver Windows signé disponible ici).

Installez et configurez une VM avec KVM, installez les logiciels et services voulus et les comptes utilisateurs. Gardez à l'esprit que tout ce que vous faites sur cette image se retrouvera sur chaque instance. Et à l'inverse, tout ce que vous n'aurez pas fait sera aussi à refaire à chaque nouvelle VM.

Pour simplifier l'administration des comptes sur les instances, l'utilisation d'un annuaire LDAP facilite grandement le travail. Il suffira ensuite de faire les changements sur l'annuaire pour ne pas être obligé de remettre ses images à jour.
Pour finir, pour les images Linux, ouvrez avec les droits d'administration le fichier /etc/rc.local et ajoutez les lignes suivantes avant la ligne "exit 0" (ou avant "/var/lock/subsys/local" pour Centos). Ceci permettra à l'instance de récupérer les clés SSH au lancement.

curl -m 10 -s http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key | grep 'ssh-rsa' >> /root/.ssh/authorized_keys

Une dernière précaution à prendre pour éviter les conflits de nommage des interfaces réseau: effacer la règle udev y faisant référence:

Votre image disque est maintenant prête à être exportée sur le serveur Glance.

Pour supprimer cette application, supprimer les paquets. Selon la méthode choisie, la configuration globale de l'application est conservée ou supprimée. Les journaux du système, et les fichiers de préférence des utilisateurs dans leurs dossiers personnels sont toujours conservés.
Supprimez ensuite les bases de données keystone, glance et nova. [43]

Désignations	Equipements	Prix unitaire	Quantité	Prix total
Switchs de 1Go	Cisco SF 200-24FP	163 335	2	326 670
Switch Ethernet de 46 à 50 GbE	Cisco SG350XG-24T	2 123 990	1	2 123 990
Firewall	ZyXEL USG 60W	373 900	1	373 900
Serveur de calcul	Lenovo ThinkServer TS140 (70A5001XFR)	543 790	1	543 790
Serveur de stockage	Lenovo ThinkServer RS140 (70F9001JEA)	701 875	1	701 875
Controleur SDN	HP VAN SDN Ctrl 50-node E-LTU	2 577 260	2	5154520
Total	9 224 745

Tableau 5 : Estimation financière (en FCFA) de la mise en place d'une solution SDN

3.6. Les difficultés rencontrées d'installations d'OpenStack (Expérience utilisateur)

Les difficultés rencontrées lors de la mise en place de notre système sont multiples. Comme notifier au niveau des inconvénients d'OpenStack, des versions nouvelles sont apportés assez rapidement. Ainsi d'une version à une autre les problèmes peuvent changer ne permettant pas d'avoir une solution efficace sur toutes les versions.

De notre coté le premier problème rencontré fut celui du système d'exploitation. En effet, nous avons travailler avec la version Desktop de Ubuntu 14.04 . A l'installation, on pouvait noter l'absence de certains paquets et librairies pas indispensable pour le fonctionnement du système d'exploitation lui-même mais obligatoire pour l'installation d'OpenStack. Pour ce faire une lecture des forums, s'impose. Cela nous a permis de savoir quelle mise à jour effectuer pour obtenir une version conforme à l'installation d'OpenStack. Notons qu'une mise à jour générale du système n'est pas une solution en soi vu que d'autres librairies additives peuvent être en conflits au moment de l'installation. Ainsi il faut avoir le juste milieu.

Le véritable souci fut l'installation d'OpenStack dans un premier temps, ensuite l'installation de Neutron dans OpenStack. Pour OpenStack, c'est le choix de la source des dépôts. L'absolue n'ayant pas fonctionné, nous avons procédé par tâtonnement afin d'avoir un dépôt pouvant fonctionner chez nous. Pour ce qui est de l'installation de Neutron, la tâche fut plus compliquée à cause du fait que même les versions stables intégrant directement Neutron, ce dernier n'est pas activé. Une solution absolue et efficace n'étant pas disponible, la communauté OpenStack permet de solutionner une partie de ce problème.

La qualité de service au niveau iaas: vers l'utilisation du concept software-defined networking (SDN)

Introduction