Virtualisation de réseau, prochaine étape dans les datacenters

« Un datacenter se compose de briques réseau, sécurité, serveurs et stockage. La virtualisation a, jusqu'à présent, gagné les différentes briques du datacenter sauf celle du réseau, même si des solutions de virtualLAN existent. Toutefois, ces dernières restent limitées pour construire des réseaux virtuels dans les grands datacenters. Le réseau programmable de type SDN (Software Defined Networks) va combler ce manque et garantir, ce qu'on appelle, un SDDC (Software Defined Data Center), en quelque sorte un datacenter hautement virtualisé », résume Christian Lorentz, chef de produit sénior chez Riverbed dont le groupe a récemment annoncé des solutions (gamme Cascade et la solution SteelHead) de gestion des performances des réseaux SDN (Software Defined Networks) et d'optimisation WAN pour les datacenters virtuels.

À en croire un certain nombre de nos interlocuteurs et les cabinets d'études comme Gartner et IDC, les réseaux programmables de type SDN constitueront la dernière pierre angulaire des datacenters hautement virtualisés après celle de la virtualisation des serveurs et du stockage. Bien sûr, ils visent en priorité les fournisseurs de services cloud, les services providers et les opérateurs et, dans une moindre mesure, les datacenters des entreprises plus enclins à adopter dans un premier temps des technologies de tunneling et d'overlay de type VXLan et NVGRE. Pour IDC, le marché du SDN devrait même passer de 200 millions de dollars en 2013 à plus de 2 milliards en 2016.

Absence de flexibilité sur les couches réseau

Que peut apporter concrètement la technologie SDN ? Pour tous les intervenants que nous avons interrogés, les réseaux manquent clairement de flexibilité dans leur gestion. Un avis que partage Julien Couturier, directeur technique chez Extreme Networks : « l'organisation actuelle en silo du système d'information dans les entreprises ralentit la mise en place d'applications. Les temps de déploiement des applications varient entre 2 et 4 mois en moyenne, les processus et les méthodologies sont trop nombreux, ce qui pénalise le « time to market ». La raison est qu'il y a peu ou pas de management centralisé au niveau des réseaux dans les entreprises où une multitude de consoles de gestion des commutateurs cohabitent. »

Ce manque de flexibilité et de souplesse est devenu une problématique à résoudre surtout dans un contexte où les écosystèmes qui vont du Byod (Bring your own device) aux services cloud réclament des ressources, une vitesse importante de mise en oeuvre et des performances élevées du réseau. Les SDN pourraient donc combler ce manque. « En termes de gains, les SDN vont déjà apporter de la flexibilité, de l'automatisation, une rapidité d'exécution dans les provisionnements et des garanties sur les SLA... Bref, ce que l'on fait aujourd'hui dans les serveurs avec la gestion des machines virtuelles, on doit pourvoir le faire demain au niveau du réseau avec des VLANs », indique David Limery, ingénieur système chez Brocade.

De forts investissements dans les technologies SDN

Face à cet engouement autour de la technologie SDN et des réseaux virtuels en général, les équipementiers et les éditeurs procèdent à d'importants investissements pour porter leurs équipements « ready SDN » ou pour acquérir de nouvelles technologies et affiner leur stratégie. Aujourd'hui, les offres autour du SDN sont plutôt dans une phase de construction. Premier exemple, Brocade qui a fait l'acquisition de Vyatta, un éditeur américain de solutions SDN en Open Source. L'équipementier acquiert ainsi une communauté Open Source, mais aussi une ligne commerciale avec des appliances virtuelles dédiées. De son côté, VMware s'est offert, pour plus d'un milliard de dollars, la technologie Open vSwitch de Nicira, une société californienne. Oracle, quant à lui, a racheté Xsigo, un fournisseur à l'origine d'une solution de supervision de réseaux hétérogènes. Le géant Cisco investit aussi fortement dans les technologies SDN avec les rachats de vCider, un spécialiste des réseaux programmables, de Cloupia (pour 125 millions de dollars), un spécialiste de  l'automatisation des tâches dans les datacenters et de Cariden (pour 141 millions de dollars), une société spécialisée dans des solutions de planning réseaux, de design et de gestion de trafic.

On n'oubliera pas aussi les investissements financiers de Cisco dans la création de start-ups dédiées à ces technologies à l'instar des 100 millions de dollars déjà versés dans Insieme, un projet de recherche et développement dont le but est d'arriver avec plusieurs approches autour des SDN. Son concurrent Juniper Networks a, de son côté, mis la main sur la start-up Contrail Systems pour 176 millions de dollars. Cette dernière travaille sur un contrôleur SDN. Enfin, Alcatel-Lucent qui a investi, quant à elle, dans Nuage Networks, une start-up travaillant dans le domaine des SDN pour les prestataires de services de cloud et les opérateurs. Hormis ces rachats et ces investissements, il ne faut pas oublier les grands acteurs IT comme HP et Dell et les moins grands comme Extreme Networks, Riverbed et les futurs challengers comme Big Switch Networks qui créent ou qui portent une gamme de produits destinée aux réseaux virtualisés programmables. Tous ces investissements montrent à quel point cette tendance de la virtualisation des réseaux est stratégique.

« Techniquement, l'idée du SDN est de piloter le réseau par une couche logicielle programmable unique et de donner aux entreprises une vue globale centralisée de l'architecture », explique Vincent Felisaz, ingénieur système chez Brocade. Pour ce faire, le SDN introduit donc le principe du découplage du plan de contrôle et du plan de données. Cette dissociation est importante dans la mesure où elle permet le contrôle de l'ensemble du réseau depuis un seul point. « En soi, cette centralisation de l'intelligence existait déjà un peu dans les réseaux ATM...», explique Christophe Compain, architect technology solutions pour les datacenters chez Cisco. De même, le découplage du data plane et du control plane n'est pas nouveau et existe depuis longtemps dans les technologies EPN et VPN, ce découplage est aussi très utilisé dans les réseaux sans fil de type WiFi. En fait, l'approche du SDN est de combattre la complexité du réseau d'aujourd'hui où l'intelligence embarquée est très décentralisée. Ainsi, en centralisant davantage l'intelligence, on augmente la flexibilité du réseau et on simplifie son administration. Et pour un certain nombre d'acteurs comme Extreme Networks, Nec ou Brocade (qui sont aussi à la recherche de solutions de type best of breed), mais aussi pour des start-ups comme Big Switch Networks ou encore Nicira Networks (rachetée par VMware) ainsi que des géants de l'IT qui ont de grandes ambitions dans le réseau comme HP, le protocole OpenFlow peut constituer la base d'un Software Defined Networking (SDN) standardisé.

OpenFlow, le protocole clef dans les SDN

En effet, OpenFlow est un protocole ouvert de réseau programmable conçu pour gérer et diriger le trafic entre les routeurs et les commutateurs des différents constructeurs, il vise uniquement à devenir l'interface standard entre un contrôleur et un noeud du réseau. Le développement d'OpenFlow a commencé en 2007 dans le cadre d'une collaboration entre les mondes de l'université (Stanford) et des affaires sur des équipements HP, cette norme est maintenant définie par l'ONF (Open Networking Foundation) qui compte aujourd'hui plus de 70 membres. Il n'est donc pas étonnant de voir HP soutenir des standards ouverts comme OpenFlow, le fabricant a d'ailleurs lancé, il y a quelques mois, son propre contrôleur SDN Virtual Application Networks et neufs commutateurs embarquant nativement OpenFlow. HP n'est pas le seul, NEC dispose aussi de son propre contrôleur Programmable Flow Networking ainsi qu'IBM avec son Programmable Network Controller (une version OEM du contrôleur de NEC en fait). Pour Alcatel Lucent Entreprises, le protocole OpenFlow sera supporté dans sa gamme de commutateurs Omniswitch en 2014. « Nous estimons que le protocole OpenFlow n'est pas encore dans une version très stabilisée, toutefois, nous avons anticipé depuis un moment sur les réseaux programmables en ajoutant des API Restful dans notre gamme de commutateurs Omniswitch pour les datacenters d'entreprises », confirme Yassine Mahfoufi, directeur marketing France d'Alcatel Lucent Entreprise. Enfin, Juniper Networks, qui a récemment dévoilé sa stratégie SDN pour les opérateurs télécoms, prévoit aussi la sortie d'un contrôleur Open Source, mais pas avant 2014.

L'alternative Cisco

Face à ces nombreux acteurs plutôt ouverts au protocole OpenFlow, l'équipementier géant des réseaux Cisco est plus prudent en indiquant qu'OpenFlow vient du monde de la recherche et du milieu universitaire dont l'objectif est de créer des réseaux parallèles sur des processeurs standards. « Notre stratégie est de répondre en fonction des besoins. Concernant OpenFlow, ce protocole a été créé par des chercheurs, mais aujourd'hui, répond-il vraiment aux besoins  des datacenters des entreprises, j'en doute, la plupart des entreprises n'ont pas besoin de management à très grande échelle avec des fonctions de multi-tenancy, elles ont surtout besoin d'automatisation au niveau des process réseau comme c'est toujours le cas actuellement avec la virtualisation au niveau des serveurs, elles ont aussi besoin d'un portail pour piloter les couches serveur et réseau, c'est ce que nous mettons en avant avec CIA (Cisco Intelligent Automation) », indiquent ensemble Eric Debray, responsable des alliances technologiques chez Cisco et Christophe Compain. Concrètement, la stratégie SDN de Cisco passe donc par l'Open Network Environment (Cisco One), une approche centralisée pour livrer un accès à l'ensemble des couches du réseau du niveau 2 au niveau 7 (OpenFlow opère surtout au niveau 2). Cisco ONE intègre certes OpenFlow (qui gère des zones au-dessus et en dessous du plan de contrôle et du plan de transfert), mais surtout des API spécifiques Cisco. Cisco ONE comprend aussi la plateforme One Platform Kit (onePK) qui fournit des API aux développeurs pour les systèmes d'exploitation IOS (Internetwtwork Operating System), IOS-XR et NX-OS.

Une menace pour les équipementiers historiques ?

La prudence de Cisco est aussi à mettre en parallèle à de nombreux équipementiers qui malgré une ouverture ou un soutien à OpenFlow ne souhaitent pas que les réseaux deviennent une « commodity ». « Il est important pour un équipementier de conserver un savoir-faire sur les contrôleurs et de ne pas déporter toute l'intelligence », reconnaît Pascal Danet, responsable de l'équipe ingénieur système chez Brocade dont le groupe a une approche hybride autour d'OpenFlow. Cette approche « hybride », qui consiste, à juste titre, pour les équipementiers de conserver un savoir-faire (en  maintenant un lien entre les commutateurs et le contrôleur), permet toujours de garantir une dépendance des entreprises à leurs équipementiers. Pour Hervé Renault, directeur avant-ventes EMEA chez VMware, il n'y aura pas un monde unifié dans les réseaux autour d'OpenFlow et d'OpenStack. « Il faudra toujours des commutateurs physiques. Est-ce que l'arrivée de la virtualisation des serveurs a créé une perte de valeur pour les acteurs IT ? Je ne le pense pas, dans les réseaux, la valeur ajoutée des équipementiers sera toujours présente. » Pour justifier ses propos, Hervé Renault donne l'exemple du commutateur Nexus 1000V de Cisco qui intègre un certain nombre de fonctions avancées autour des réseaux virtuels. 

Nicira , la pépite de VMware

Cela dit, avec le rachat de Nicira, VMware dispose entre les mains d'un acquis stratégique. Si dans un premier temps, les technologies de réseaux programmables de Nicira viennent en complément de l'offre actuelle de VMware autour de Virtual Distributed Switch, de vCloud Director, de vCenter et des solutions overlay avec VXLan, à terme, sans donner de date précise, ces technologies seront intégrées aux offres VMware. Pour le co-fondateur et CTO de Nicira, Martin Casado, la clef du succès du SDN débutera par l'hyperviseur qu'il appelle « la couche d'accès au réseau. » Le responsable espère que l'année prochaine un contrôleur SDN sera intégré à l'hyperviseur même si ce dernier restera agnostique par rapport aux équipementiers, aux éditeurs et aux plateformes. Martin Casado précise quand même qu'il s'agit d'une technologie de rupture et que les équipementiers ont des challengers derrière eux. Mais cela ne signifie pas qu'ils vont disparaître. Les applications qui s'exécutent sur un réseau virtuel le sont sur une base matérielle ou logicielle. Certains clients vont vouloir garder pour des raisons de sécurité une partie matérielle, mais placer d'autres applications en mode SDN. Cette orientation donnera le choix aux clients.

Encadré :Openstack pour faciliter l'intégration des réseaux virtuels dans les clouds en Open Source.

Comment faire profiter les clouds Openstack des technologies SDN ? La réponse se trouve dans la pile Quantum d'OpenStack (Openstack Virtual Network). En effet, ce service autonome pour Openstack fournit un bloc complet pour la gestion de réseaux complexes dans les infrastructures Cloud.  Ainsi, la stack Quantum livre des API décrivant la connectivité réseau et la configuration entre les interfaces. Quantum prend aussi en charge une série de plug-ins de réseaux virtuels, dont Open vSwitch, l'OS réseau Open Source Ryu et les plug-ins propriétaires ou d'équipementiers comme Cisco et Nicira (rachetée par VMware). Pour ce dernier, Hervé Renault, directeur avant-ventes de VMware pour la région EMEA, précise d'ailleurs que l'acquisition de Nicira permet désormais à l'éditeur de rendre le réseau programmable en OpenStack.

À ce titre, VMware (à l'instar de sa maison mère EMC) a d'ailleurs récemment rejoint la fondation OpenStack. De son côté, Cisco a été un contributeur important dans la création de composants autour du projet Quantum d'Openstack, notamment avec le connecteur Cisco pour Quantum qui supporte la segmentation niveau 2 utilisant les VLAN. Ce plug-in est conçu pour travailler aussi bien avec Open vSwitch que le Cisco Nexus sub-plugin. Cela dit, aujourd'hui, il faut relativiser l'engouement autour d'OpenStack car peu de clouds utilisent les technologies en Open Source, environ 15 % selon une étude réalisée par la société Zenoss intitulée The slate of the Oopen Source cloud 2012 (http://www.zenoss.com/in/wp_open_cloud_survey.html). 

Quelle est votre approche autour du SDN et quelle cible visez-vous ?

Nous avons une approche très pragmatique du SDN, c'est de simplifier et d'automatiser les réseaux en fonction des besoins des applications business. Au-delà du SDN, un terme très à la mode en ce moment, nous essayons d'abord de trouver des réponses aux problèmes les plus préoccupants et complexes des réseaux. Chez Juniper, nous avons identifié cinq challenges : un challenge opérationnel déjà avec des configurations réseaux de plus en plus complexes, ensuite, les caractéristiques fonctionnelles (système, qualité de service, etc.) du réseau qui deviennent de plus en plus lourdes et longues à définir, la partie logicielle pour laquelle les opérateurs éprouvent de plus en plus de difficultés à définir une matrice, le packaging du logiciel qui est, lui aussi, de plus en plus compliqué à appréhender. Enfin, le dernier challenge est la fiabilité du réseau.

Notre stratégie SDN doit donc servir à couvrir ces 5 catégories pour que les opérateurs puissent bénéficier d'un réseau plus dynamique. Au-delà des opérateurs, cette stratégie est aussi valable pour les grands datacenters d'entreprise qui fournissent des services clouds et qui n'ont pas les moyens d'Amazon...

Soutenez-vous le protocole OpenFlow et/ou êtes-vous plus dans une démarche de protocole « propriétaire » ?

Dans l'histoire de Juniper, nous avons toujours eu une démarche de standardisation et non propriétaire. Mais, j'aimerais dire que l'Open Source n'est pas forcément identifié comme un standard.  Concernant le protocole OpenFlow, il est de plus en plus critiqué pour sa viabilité, c'est un protocole très académique. Même si nous supportons les versions 1.2 et bientôt 1.3 du protocole OpenFlow, Juniper ne le recommande pas forcément dans les équipements commerciaux. Hormis OpenFlow, nous disposons de plusieurs choix de protocole comme par exemple REST, IFMap, XMPP, ou le protocole BGP qui permet aux passerelles sur internet de transmettre des informations sur le routage.

Comment définir une approche SDN par rapport aux solutions existantes de virtualisation des réseaux ?

Une approche SDN sans virtualisation des réseaux n'a pas beaucoup d'intérêt. Mais, le vrai problème à régler, c'est le niveau de virtualisation que l'on va appliquer (comme l'abstraction des interfaces logiques où la mise en place d'équipements virtuels) pour implanter du SDN. Il y a bien sûr des tentatives de virtualisation, mais qui sont complexes. Chez Juniper, nous avons une approche de virtualisation pour implémenter SDN suivant quatre étapes : la centralisation du management (Junos Space), l'extraction des services (JunosV App Engine), la centralisation du contrôleur (ndlr : rachat de Contrail Systems) et l'optimisation du hardware pour supporter le plan data. Cette approche simplifie les réseaux, offre une grande automatisation et flexibilité via des standards et permet d'avoir plus d'élasticité.