Dossier très intéressant : comprendre le SDN, ou l'art de virtualiser le réseau (Article du site pro.clubic.com)

Depuis 2010, le Cloud change de visage avec l'arrivée de mécanismes d'automatisation de gestion des serveurs et du stockage, ainsi que de l'autoconfiguration du réseau. Dans les grands clouds publics, privés ou hybrides, ces tâches deviennent impossibles manuellement, surtout dans un contexte de concurrence où l'adaptation instantanée aux besoins des clients devient primordiale.

A l'origine, les deux initiatives n'avaient rien en commun. D'un côté, le projet OpenStack, lancé en 2010, par la fondation Openstack, pour créer et offrir des services dynamiques dans le monde du Cloud Computing. D'un autre côté, le projet SDN (Software Defined Network), développé par l'Open Networking Foundation (ONF), créée en 2011. Il vise à découpler, dans un équipement réseau, la partie plan de données de la partie plan de contrôle.

En d'autres termes, ne laisser aux commutateurs ou routeurs que l'aiguillage des paquets. Les services réseaux (affectation des priorités, décisions de routage...) sont rassemblées dans un contrôleur, commun à plusieurs équipements.

On peut donc utiliser l'un ou l'autre projet, mais également les deux à la fois car ils se complètent. En effet, le Cloud Computing se caractérise par une forte agilité des infrastructures destinées à s'adapter quasi instantanément aux besoins des utilisateurs, que ce soit dans un Cloud privé ou public. Dès lors, toute automatisation des tâches, tant côté informatique que côté réseau, ne peut que bénéficier aux fournisseurs de services Cloud et, en fin de compte, aux utilisateurs.

Le SDN : quand le réseau s'autoconfigure

Dans un réseau classique, lorsqu'un paquet arrive sur un port d'un commutateur ou d'un routeur, celui-ci applique les règles de routage ou de commutation qui sont inscrites dans son système d'exploitation. Généralement, tous les paquets qui ont la même destination suivent le même chemin. Dans les modèles haut de gamme, les matériels sont capables de reconnaître le type d'application et de lui appliquer les règles spécifiques. Mais cette programmation est rigide. Elle ne peut être changée que manuellement, par l'administrateur, ce qui prend évidemment du temps et ne se prête guère à des changements de contexte rapides.

Avec le SDN, ces changements sont automatisés et même programmables. L'administrateur définit les règles dans le contrôleur, et celles-ci sont instantanément transmises dans les équipements réseaux. Par exemple, si une entreprise réalise des sauvegardes toutes les nuits, il est possible de configurer le réseau pour leur offrir à ce moment-là le maximum de bande passante, le trafic métier de la journée étant alors fort réduit. Autre exemple : une entreprise qui possède des établissements de chaque côté de l'Atlantique. Sachant que le coût de ces liaisons est élevé, elle peut choisir de l'optimiser, en fonction de l'heure et/ou du type de trafic. L'avantage qu'offre le SDN réside dans l'automatisation de ces configurations, sans que l'administrateur ait à intervenir.

Le côté découplage entre la partie matérielle et la partie logicielle n'est pas sans rappeler le fameux IMS (IP Multimedia Subsystem), qui introduisait dans les équipements télécoms plan de données et plan de contrôle. Apparu au tournant des années 2000, il était poussé par les constructeurs, tels que Lucent ou Ericsson. Il répondait à un besoin né de l'arrivée des réseaux UMTS (3G). D'où son rapport très étroit avec le 3rd Generation Partnership Project (3GPP), organisme de normalisation de la téléphonie mobile 3G dans les réseaux UMTS.

Plus tard, sont venus s'ajouter d'autres types d'accès et de protocoles, tels que SIP ou la VoIP et même l'interfonctionnement avec les réseaux fixes, fruit d'une collaboration avec TISPAN (Telecoms & Internet converged Services & Protocols for Advanced Networks), d'origine ETSI (European Telecommunications Standards Institute). Cette nouvelle architecture, s'appliquant uniquement aux réseaux d'opérateurs, fut nommée NGN (Next Generation Network). Elle permet d'utiliser le même plan de contrôle pilotant un cœur de réseau IP unique sur lequel se raccordent différents types d'accès. D'une certaine manière, le SDN est une déclinaison de l'IMS au niveau de l'entreprise et du Cloud computing.

Certains spécialistes ont déclaré que le SDN était l'arme anti-Cisco par excellence. L'industriel a bâti sa réussite sur la fourniture de boîtiers. Or, le SDN les relègue au second plan, favorisant le contrôleur, cerveau du système. Celui-ci peut piloter des équipements de différentes marques, dans la mesure où ils respectent les normes de l'ONF.

Mais encore faut-il qu'il transmette ces ordres du contrôleur au réseau, via un protocole et des interfaces de programmation (API). Et c'est là que les choses se gâtent car si tout le monde est d'accord sur le principe, sa mise en œuvre peut varier d'un constructeur à l'autre. L'ONF a défini le protocole OpenFlow, aujourd'hui en version 1.3. Brocade, par exemple, l'a adopté. Le constructeur l'estime aujourd'hui assez stable (après la rafale de versions successives tous les six mois) et offrant suffisamment de possibilités. Il l'intégrera dans ses équipements dès 2014.

En revanche, pour Juniper, il n'est pas assez mûr et n'offre que des performances réduites. Pour le moment, il lui préfère le protocole BGP (Border Gateway Protocol) pour la partie contrôle et MPLS (MultiProtocol Label Switching) pour la partie transport. Parallèlement, il travaille avec des partenaires sur sa propre solution Contrail, issue du rachat de la société éponyme en décembre 2012. Il l'estime mieux taillée pour les grands Clouds publics et la met en OpenSource. Tout en offrant une interface OpenFlow sur ses équipements, notamment sur le récent Nexus 9000, Cisco a développé également sa propre solution, OnePK, possédant des extensions propriétaires. Cependant, on observe qu'OpenFlow semble de plus en plus enclin à rallier les suffrages, avec des poids lourds comme HP, IBM, Ericsson, NEC ou Alcatel-Lucent.

Le concept de SDN, ici résumé par HP

Cette boite magique que constitue le contrôleur est en fait un logiciel qui se substitue au logiciel de commande inclus dans chaque équipement réseau. Il devient donc possible de prendre les commandes d'un réseau entier, même hétérogène, au lieu d'avoir à intervenir sur chaque boîtier. On peut résumer les fonctions de base du contrôleur 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 le gestionnaire du réseau, cela se traduit par : la suppression des délais de d'allocation de réseau, la modification des bandes passantes à la volée, l'adaptation du paramétrage réseau aux besoins des applications et une réduction de la complexité de gestion des réseaux. A ces fonctions de base, certains constructeurs et éditeurs ajoutent des applications qui enrichissent les possibilités du contrôleur, ce qui nécessite un protocole de communication avec les équipements propriétaire. C'est notamment le cas de Cisco, qui propose sur ses machines une interface standard OpenFlow et une autre Cisco OnePK.

IBM et HP possèdent leur propre contrôleur. Juniper également, avec Contrail. Cisco en annonce deux. Le premier, c'est le XNC (eXtensible Network Controller). Récemment, il vient d'annoncer l'APIC (Application Policy Infrastructure Controller), cœur de sa nouvelle architecture ACI (Application Centrix Infrastructure), à la fois logicielle et matérielle puisqu'elle s'appuie notamment sur le commutateur Nexus 9000. Brocade ne développera pas de contrôleur. Parmi ceux du marché, on trouve notamment Big Switch Networks et son Big Network Controller.

Au départ, il s'agissait d'un projet entre Rackspace Hosting et la NASA, qui ont lancé, conjointement, un nouveau projet OpenSource en 2010 dans le domaine du cloud computing sous le nom d'OpenStack, sous licence Apache. Puis sont venus se greffer d'autres membres. Trois ans plus tard, la Fondation OpenStack compte 12 000 membres. Environ 1 000 d'entre eux écrivent du code et les autres réalisent les tests des différentes versions (une environ tous les six mois), produisent la documentation ou s'occupent des aspects juridiques.

Parmi les membres, beaucoup d'opérateurs tels que Belgacom, KPN, Swisscom, Deutsche Telekom, pour ne citer que quelques européens. On trouve également des poids lourds de l'industrie, à l'instar de Cisco, IBM ou HP, qui a bâti dessus son offre HP Public Cloud. En France, on compte OVH, ainsi que hébergeur Cloud Numergy qui a rallié récemment la communauté.

Tout a commencé avec la virtualisation, en créant plusieurs instances (machines virtuelles ou VM) sur une même machine physique par le biais d'un hyperviseur. Dans un fonctionnement normal, les serveurs applicatifs échangent des informations avec les bases de données, les baies de stockage et reçoivent des requêtes des utilisateurs, notamment par le biais du Web. On regroupe alors ces VM dans des VLAN. Souvent, un VLAN est affecté à une direction : Finances, Ressources humaines, Commerciale....

Ces VLAN doivent communiquer entre eux, par exemple, entre la Finance et les Ressources humaines pour gérer la paye entre le 25 et le 30 du mois. Cela ne pose pas vraiment un problème lorsqu'il ne s'agit que de quelques dizaines de VLAN. Mais dans un Cloud public, on trouve des milliers d'applications et des dizaines de milliers d'utilisateurs. D'où l'intérêt d'automatiser ces opérations : c'est le rôle d'OpenStack. « Celui-ci crée automatiquement les VM, en fonction des besoins, au lieu de le faire manuellement, ce qui fait gagner beaucoup de temps, par exemple dans la configuration des machines, l'affectation d'adresse IP... », déclare Ahmed Guétary, directeur technique chez Juniper Networks France.

Pour faire communiquer ces VLAN entre eux. On crée alors un réseau surcouche, dit « Overlay ». « Le but est de créer des tunnels de niveau 3 », déclare David Lemery. « En effet, à l'intérieur des entreprises les tunnels pour déplacer les machines virtuelles sont de niveau 2. Mais il faut du niveau 3 pour faire passer les paquets IP et traverser les routeurs ».

Là, plusieurs solutions s'affrontent. L'une des plus connues est VXLAN (Virtual Extensible LAN), fruit de la collaboration entre Cisco VMware, Citrix et Red Hat. Il utilise une encapsulation dans UDP (User Datagram Protocol). Cisco l'incorpore dans son routeur virtuel Nexus 1000V. La surprise vient de WMware, grand partenaire de Cisco depuis des années, et qui propose aujourd'hui NSX, solution directement rivale, née du rachat, l'an passé, de Nicira, pour 1,25 milliard de dollars. Cependant, cette acquisition pose un dilemme à VMware, car Nicira a développé une autre technologie de tunneling : STT (Stateless Transport Tunneling), aujourd'hui plus économe en CPU, fondée sur TCP, qui fonctionne sur Xen ou KVM (Linux). VMWare va sans doute garder les deux : les hébergeurs et les clouds publics utilisent volontiers KVM, tandis qu'ESX domine dans l'entreprise. VMware pourrait également introduire STT dans le commutateur virtuel d'ESXi et néanmoins garder VXLAN afin de ne pas se couper d'une solution qui a le vent en poupe.

Officiellement, les relations entre Cisco et VMware sont toujours au beau fixe, notamment pour rassurer leurs millions de clients communs. Cependant, certains n'hésitent pas à dire que cette belle entente n'est plus que de façade. Ainsi, si Dell, HP et Juniper font partie de la liste des adopteurs de NSX, Cisco en est un absent remarqué. Parmi les autres solutions, NVGRE (Network Virtualization using Generic Routing Encapsulation). Microsoft en est le principal promoteur, avec Arista Networks, Broadcom, Dell, Emulex, Intel et HP. Citons également NVO3 (Network Virtualization Overlays). Pour mettre de l'ordre dans cette belle pagaille, l'IETF (Internet Engineering Task Force) travaille à la normalisations du tunneling.

Puisque que OpenStack couvre également le stockage, on parle désormais de SDS (Software-Defined Storage). Le principe se calque sur celui du SDN : découpler la partie matérielle de celle du logiciel qui pilote les baies de stockage. Résultat, les entreprises pourront avoir des environnements hétérogènes et ne plus se soucier de problème de sur-capacité ou sous-capacité par système, puisque c'est le logiciel SBS qui le gérera. Celui-ci sera capable d'exécuter automatiquement des réplications, de l'allocation fine de ressources, des sauvegardes ou des restaurations.

Là aussi, l'automatisation apporte plus de souplesse. Attention à ne pas confondre SDS avec virtualisation du stockage. Ce dernier consiste à regrouper plusieurs équipements pour n'en former qu'un seul logique (adresse IP unique par exemple). Cette technique est souvent utilisée dans les environnements SAN (Storage Area Network). Un peu à l'image de ce qui se passe dans les réseaux, lorsque qu'une pile de commutateurs empilables ne forme qu'un seul commutateur virtuel.

Résultat de ces évolutions dans le réseau entre machines virtuelles, VWware a lancé l'idée du SDDC (Software-Defined Data Center), dans lequel les fonctions de routage et même de répartiteur de charge ou de sécurité seraient virtualisées et non plus installées dans des machines physiques.

La dernière version d'OpenStack se nomme Havana, annoncée fin octobre 2013, et qui compte 400 nouvelles fonctions. Il s'agit de la huitième depuis la toute première, Austin, en octobre 2010. Chaque version porte le nom de la ville où la conférence s'est tenue.

Pour réaliser ces opérations, le contrôleur OpenStack dispose de plusieurs composants, dont les principaux sont Nova pour la partie serveurs et applications, Cinder ou Swift pour la partie stockage (l'un fonctionnant en mode fichiers et l'autre en mode blocs). On trouve également Horizon (Dashboard, interface Web de paramétrage et de gestion), Keystone (gestion de l'identité). D'autres sont en préparation. Mais il ne faut surtout pas oublier un composant essentiel, Neutron (ex Quantum), pour la gestion des réseaux.

Et c'est là qu'OpenStack rencontre le SDN. Certes OpenStack possède une « patte » réseau. Son but : fournir une connectivité « as a service » entre interfaces d'équipements (par exemple Network Interface Controller ou cartes réseaux) gérés par d'autres services OpenStack. Mais Quantum/Neutron ne « parle » pas directement aux commutateurs, sauf à y ajouter un « plug-in » spécifique. Pour sa part, OpenFlow, s'il communique avec les équipements réseaux, ne possède pas de couche d'abstraction réseau, sauf, là encore, à ajouter un « plug-in ». Les deux se complètent donc : l'un possède ce qui manque à l'autre.

Dès lors, le module Quantum/Neutron est capable de s'interfacer, via une API, au contrôleur SDN, qui configurera automatiquement le réseau physique en fonction des besoins exprimés par les services OpenStack. Ce beau montage ne séduit néanmoins pas tout le monde. « OpenFlow et/ou Opendaylight ne sont pas encore assez mûrs pour que nous les déployions dans notre architecture », estime Patrick Debus-Pesquet, directeur technique de Numergy. « Nous préférons, pour le moment, en rester à la gestion directe des VLAN. 2014 sera une année de convergence pour ces nouveaux standards ».

Il ne faudrait cependant pas croire que l'Open Networking Foundation (ONF) pour le SDN et l'OpenStack Foundation pour les infrastructures Cloud, soient les seules à pousser leurs solutions. Ainsi, dans le SDN, la confrontation est vive entre l'ONF et l'OpenDaylight. Ce projet, lancé en février 2013 par la Linux Foundation, rassemble d'ailleurs bon nombre de membres communs avec l'ONF, dont Arista Networks, Big Switch Networks, Brocade, Cisco, Citrix, Ericsson, HP, IBM, Juniper Networks, Microsoft, NEC.... Encore que Juniper semble prendre ses distances depuis le lancement de son propre projet Contrail. En outre, alors que pour l'ONF la pierre angulaire du SDN est le contrôleur, pour Nicolas Jacques, le nouveau directeur général d'OpenDaylight, qui vient de chez VMware, « toutes ces entreprises réinventent la roue. La valeur ajoutée réside dans la manière dont vous reliez ce contrôleur aux services réseaux d'un côté et aux équipements de l'autre ».

La virtualisation du réseau selon Nicira, racheté par VMWare à l'été 2012

L'ONF possède pour le moment quelques longueurs d'avance. Même chose côté OpenStack avec l'arrivée de CloudStack, en 2012. C'est le fruit du rachat, en juillet 2011, de Cloud.com par Citrix. En 2012, il en a fait don à l'Apache Software Foundation (ASF). Citrix optait alors pour Apache 2.0 et cessait son engagement dans OpenStack. CloudStack fonctionne sur les hyperviseurs tels que KVM, vSphere et XenServer/XCP. En outre, CloudStack met en avant sa compatibilité avec les API AWS (Amazon Web Services). Évidemment, l'OpenStack Foundation a réagi en affirmant que son projet était également compatible avec AWS. Malgré ces bise-billes, CloudStack a adopté, dans sa version 3.0, le module Swift (stockage) d'OpenStack.

La révolution en marche

OpenStack, CloudStack, OpenFlow, OpenDaylight... Née de la virtualisation, la révolution dans le monde de l'IT est en marche et ne semble pas prête de s'arrêter. Les initiatives se poursuivent. Témoin, la création, en octobre 2012, du groupe NFV (Network Functions Virtualisation, au sein de l'ESTI. NFV concerne tout particulièrement les opérateurs et les fournisseurs de services. Jusqu'à présent, les équipements réseaux gardaient, malgré les affirmations des constructeurs, une bonne part de côté propriétaire, même s'ils pouvaient interopérer dans les fonctions de base normalisées (exemple, exécuter le protocole de routage BGP ou Border Gate Protocol), conçu pour les très grands réseaux et notamment Internet. De plus, ajouter un équipement ou le déplacer d'un site à l'autre prenait du temps, car ces tâches s'effectuaient manuellement, et se traduisait en investissements souvent lourds.

Or, avec l'arrivée du Cloud, la création de nouveaux services Internet et la concurrence entre acteurs ont fait qu'opérateurs et fournisseurs de services recherchent des gains de temps et d'investissements. Là aussi, la virtualisation s'imposait, afin de répondre aux besoins avec souplesse et rapidité. Ainsi, équilibreurs de charge, pare-feux, routeurs ont commencé à être virtualisés. Mais, comme au début de la virtualisation dans les data centers, l'opération s'effectuait manuellement, donc manquait de réactivité. NFV vise à automatiser le processus, en fonction des besoins nécessités par le trafic : par exemple, « allumer » automatiquement un SBC (Session Border Controller) supplémentaire, si le trafic VoIP croît. SDN, plutôt taillé pour le campus, et NFV, orienté réseau d'opérateur, peuvent être utilisés indépendamment.

Un datacenter Microsoft à Dublin, qui accueille notamment les infrastructures de Windows Azure

Cependant, comme le souligne l'ETSI, SDN et NFV sont très complémentaires, puisqu'il s'agit, dans les deux cas, de virtualiser les équipements réseau. L'opérateur peut tirer avantage du SDN dans son cœur de réseau. Finalement, toutes ces évolutions vont conduire, prédisent certains, au SDE (Software Defined Eveything), englobant sous un seul chapeau toutes ces initiatives... et celles à venir.

Car la révolution ne s'arrête pas là. « Nous travaillons sur des couches d'orchestration supérieures telles TOSCA », déclare Christian Comtat, directeur Cloud Computing chez IBM France. Le comité technique de TOSCA (Topology and Orchestration Specification for Cloud Applications), créé en avril 2013, vise en effet, notamment, à faciliter le portage d'une architecture Cloud sur n'importe quel Cloud compatible, à réaliser une migration en douceur d'applications déjà développées vers le Cloud et, finalement, tendre vers l'interopérabilité entre Cloud. D'ailleurs le slogan d'OASIS (Advancement of Structured Information Standards), consortium, qui pilote TOSCA, n'est-il pas : La promotion des standards ouverts dans la société de l'information ? Tout un programme.