Software-Defined Networking, mythe ou réalité , livre ebook
22
pages
Français
Ebooks
2018
Vous pourrez modifier la taille du texte de cet ouvrage
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
22
pages
Français
Ebooks
2018
Vous pourrez modifier la taille du texte de cet ouvrage
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
Publié par
Date de parution
04 février 2018
Nombre de lectures
51
EAN13
9791096574100
Langue
Français
Lorsque le sigle SDN (Software-Defined Networking) est utilisé seul, doit-on le comprendre comme exposant une technologie ou comme couvrant un concept, pour ne pas dire un mouvement ? La réponse à cette question parait assez évidente, même s'il convient de repositionner avant tout une définition de ce qu'est Open SDN, qui a drainé de nombreux autres champs d'exploration se prévalant tous d'être du SDN.
Vous l’aurez sans doute remarqué, les constructeurs et les intégrateurs mettent les mots “SDN”, “Agile” et “DevOps” dans tous les messages, convaincus que ça leur permet de montrer une position à la pointe des technologies. Pour ne prendre que le sujet “Software-Defined Networking”, il y a, en réalité, beaucoup d’idées et de courants qui se cachent derrière ce concept. Ce mini guide a pour objectif d’effleurer certains aspects qu’il est important de connaître pour ne pas sombrer dans le simple message marketing dénué de toute réalité.
Voir
Vous l’aurez sans doute remarqué, les constructeurs et les intégrateurs mettent les mots “SDN”, “Agile” et “DevOps” dans tous les messages, convaincus que ça leur permet de montrer une position à la pointe des technologies. Pour ne prendre que le sujet “Software-Defined Networking”, il y a, en réalité, beaucoup d’idées et de courants qui se cachent derrière ce concept. Ce mini guide a pour objectif d’effleurer certains aspects qu’il est important de connaître pour ne pas sombrer dans le simple message marketing dénué de toute réalité.
SOFTWARE-DEFINED NETWORKING, MYTHE OU RÉALITÉ
MINI GUIDE
GILBERT MOÏSIO
Software-Definep Networking, mythe ou réalité pe Gilbert MOÏSIO est mis à pisPosition selon les termes pe lalicence Creative Commons Attribution - as p’Utilisation Commerciale -artage pans les Mêmes Conpitions 4.0 Ceci Peut être votre site web PrinciPal ou la Page p’informations vous concernant sur une Plate forme p’hébergement, comme Flickr Commons., excePt where otherwise notep.
Vous êtes autorisé à :
Licence
– artager — coPier, pistribuer et communiquer le matériel Par tous moyens et sous tous formats – ApaPter — remixer, transformer et créer à Partir pu matériel
L’Offrant ne Peut retirer les autorisations concépées Par la licence tant que vous aPPliquez les termes pe cette licence.
Selon les conpitions suivantes :
– (BY) Attribution — Vous pevez crépiter l’Œuvre, intégrer un lien vers la licence et inpiquer si pes mopifications ont été effectuées à l’Œuvre. Vous pevez inpiquer ces informations Par tous les moyens raisonnables, sans toutefois suggérer que l’Offrant vous soutient ou soutient la façon pont vous avez utilisé son Œuvre. – (NC) as p’Utilisation Commerciale — Vous n’êtes Pas autorisé à faire un usage commercial pe cette Œuvre, tout ou Partie pu matériel la comPosant. – (SA) artage pans les Mêmes Conpitions — Dans le cas où vous effectuez un remix, que vous transformez, ou créez à Partir pu matériel comPosant l’Œuvre originale, vous pevez piffuser l’Œuvre mopifiée pans les même conpitions, c’est à pire avec la même licence avec laquelle l’Œuvre originale a été piffusée.
as pe restrictions comPlémentaires — Vous n’êtes Pas autorisé à aPPliquer pes conpitions légales ou pes mesures techniques qui restreinpraient légalement autrui à utiliser l’Œuvre pans les conpitions pécrites Par la licence.
Notes :
Vous n’êtes Pas pans l’obligation pe resPecter la licence Pour les éléments ou matériel aPPartenant au pomaine Public ou pans le cas où l’utilisation que vous souhaitez faire est couverte Par une excePtion. Aucune garantie n’est ponnée. Il se Peut que la licence ne vous ponne Pas toutes les Permissions nécessaires Pour votre utilisation. ar exemPle, certains proits comme les proits moraux, le proit pes ponnées Personnelles et le proit à l’image sont suscePtibles pe limiter votre utilisation.
ISBN Ebook – 979-10-96574-10-0 ISBN aPier – 979-10-96574-11-7
Crédits images 1. Introduction 2. Automatisation 3. Overlay 4. Marque blanche 5. Virtualisation de fonctions 6. Expérimentation 7. Application Auteur Bibliographie
Contents
Crédits images
Image de couverture : basée sur une création de kml mtz66/123RF
1
Introduction
Il n’est pas possible de parler de SDN sans se tourner vers l’organisation ONF (Open Networking Foundation) qui porte, aujourd’hui, le concept “Open SDN” d’origine ayant été connu comme étant associé au protocole OpenFlow. Leur message est clair : “Transforming Networks into Agile Platforms for Service Delivery”. Lorsqu’on analyse leur définition, on retrouve la description des trois plans d’un équipement réseau avec le fait de séparer physiquement le « Control Plane » du « Data Plane », en poursuivant l’objectif d’offrir un « Control Plane » commun ayant une vue centralisée du réseau afin d’apporter une synchronisation adaptée.
La volonté de désagrégation des éléments réseau a entrainé plusieurs conséquences. La première a été de devoir structurer le modèle en couches autour du contrôleur SDN[0].
Des implémentations, sous forme de produits Open Source, se sont multipliées pour donner aussi naissance à des offres commerciales[7]. Dans les produits Open Source, on peut citer le contrôleur SDN le plus connu ODL (OpenDaylight), mais aussi ONOS le système d’exploitation orienté SDN, Floodlight essentiellement porté par des ingénieurs de Big Switch Networks, OpenContrail et la librairie Python RYU utilisée, entre autre, par la NSA. Beaucoup d’autres noms sont disponibles dans la littérature, mais leur maintient à jour est douteux face à ceux qui se sont implantés dans le domaine.
La couche “Control Layer” ou “Control Plane” représente le contrôleur SDN et elle communique avec le matériel de la couche “Infrastructure Layer” ou “Data Plane” au travers d’une interface appelée “Southbound APIs”. Le protocole OpenFlow n’est qu’un exemple d’implémentation d’une interface “Southbound” et son objectif n’est en aucun cas d’effectuer des configurations sur les matériels, mais uniquement de modifier la table des flux. C’est pour cette raison que des protocoles comme NETCONF, BGP, OVSDB, SNMP, mais aussi CLI et bien d’autres sont utilisables en interface “Southbound”. Le projet OpenDataPlane propose des APIs Open Source pour interagir de façon transparente, avec le “Data Plane” de différents matériels.
Dans la littérature réseau, la FIB (Forwarding Information Base) porte souvent le nom de “Forwarding Table” ou “MAC Table” en référence aux adresses Ethernet MAC, ou encore “CAM Table” en référence à la mémoire CAM (Content-Addressable Memory). Sans l’utilisation d’une table, un switch se comporterait comme un hub Ethernet et enverrait l’ensemble des trames sur tous les ports. Parfois, on peut faire la distinction entre les éléments mis en œuvre pour traiter le niveau 2 du modèle OSI (FIB) et ceux utilisés pour prendre des décisions au niveau 3 (RIB ou Routing Information Base), mais quoi qu’il en soit admettre le vocabulaire suivant :
MAC Switching, pour lequel la décision de transmission est prise sur l’adresse MAC IP Routing, pour lequel la décision de transmission est prise sur l’adresse IP Flow Forwarding, pour lequel la décision de transmission est prise, de façon réactive ou proactive, sur le flux
A titre d’illustration, l’étude de l’architecture Open vSwitch permet de comprendre le positionnement du protocole OpenFlow pour la mise à jour de la table des flux et du protocole OVSDB, décrit dans le RFC 7047, pour la configuration du commutateur virtuel.
La couche “Control Layer” communique avec la couche “Application Layer” ou “Application Plane” au travers d’une interface appelée “Northbound APIs”. Les APIs REST (Representational State Transfer) sont généralement utilisées pour implémenter l’interface “Northbound” et permettre le développement de modules complémentaires qui viennent enrichir les fonctionnalités du contrôleur.
Pour information, les interfaces “Eastbound” et “Westbound” sont utilisées pour les communications inter-contrôleurs.
Mais le fait est que, comme souvent et malgré une adoption par de gros acteurs, la révolution annoncée autour du protocole OpenFlow n’a pas eu lieu[5]. Au-delà de l’idée de départ, on trouve maintenant de nombreuses technologies qui tournent, de façon plus ou moins liée, autour du “Software-Defined Networking”, et qui chacune revendique l’appellation de SDN. Un bon exemple est la notion d’automatisation qui se réclame d’être une forme de programmation du réseau par le logiciel.
2
Automatisation
Depuis le provisionnement ZTP (Zero Touch Provisioning) ou ZTD (Zero Touch Deployment) jusqu’à l’intégration continue, en passant par la collecte de données, la migration, la gestion de configuration, le test de conformité, le tableaux de bord et le diagnostic, l’automatisation apporte des solutions à chacune des étapes.
Le “Management Plane” s’occupe de la partie orchestration en offrant des protocoles de communication, tels que Telnet (Terminal Network), SNMP (Simple Network Management Protocol), SSH (Secure SHell), HTTPS (HyperText Transfer Protocol Secure)…, aux administrateurs afin d’interagir avec l’équipement. L’objectif de l’automatisation n’est pas de chercher à centraliser un “Management Plane”, mais plutôt de rendre automatique un ensemble de tâches nécessitant une connexion sur chacun des équipements pour être réalisées.
Le “Management Plane” tend à évoluer pour passer des accès SNMP et SSH/Telnet/CLI, au protocole NETCONF (Network Configuration Protocol), puis aux API REST (Application Programming Interfaces REpresentational State Transfer). Le format de transfert des données entre l’équipement et l’administrateur se structure également pour passer du mode texte pur au XML (YANG utilisé par NETCONF) ou au JSON (JavaScript Object Notation). Cependant, lors du salon INTEROP 2016 à Las Vegas, il a été mis en évidence que seuls 15% à 20% des équipements supportaient des APIs ou le protocole NETCONF. De ce fait, l’accès SSH classique reste encore indispensable.
L’industrie des réseaux a amorcé un changement dans les années 2010 pour voir apparaître des concepts de plus en plus orientés système et développement. Des spécialistes réseaux ont intensifié l’utilisation de scripts écrits dans leur langage préféré. Poussé par les constructeurs et certains Consultants experts en réseau, le langage interprété Python s’est imposé comme un choix performant, mais aussi plus simple à appréhender, pour des non-développeurs, que bon nombre de langages compilés. Dans tous l’écosystème du SDN, le langage Python est un des langages le plus représenté.
Ansible, écrit en langage Python, s’est progressivement imposé comme le principal outil d’automatisation dans le monde du réseau. Il n’est pas tout seul dans sa catégorie, mais il a l’avantage de pouvoir être utilisé avec seulement un interpréteur Python sur la cible, voire même avec seulement un accès SSH et rien de plus. Racheté par Red Hat en octobre 2015, il est Open Source dans sa version ligne de commande et payant pour sa version web. Travailler avec un outil comme Ansible, permet de structurer l’approche des spécialistes réseaux, et bien que ceci puisse apparaître, au premier abord, comme une limitation de la liberté de codage, les avantages prennent rapidement le dessus sur les inconvénients.
L’automatisation poussée à l’extrême introduit la notion d’orchestration, pour laquelle le rassemblement de produits Open Source, orientés cloud, le plus connu est OpenStack. L’objectif est de pouvoir administrer et configurer à la demande l’ensemble des matériels réseau, des serveurs et du stockage depuis un point central. Faire du réseau avec OpenStack reste complexe et le projet OpenStack Neutron et son jeu de plugins ont pour objectif de proposer le réseau sous la forme de service (Networking as a Service).
