Le « Software Defined Networking » (SDN), la prochaine génération de réseaux d’entreprise, s’inscrit parfaitement dans cette logique, rendant possible une intégration de services en quelques minutes par la création de réseaux en fonction des besoins des applications métiers. On constate cependant une adoption très frileuse par les grandes entreprises, en particulier en France. Alors que cette technologie représente un gain prometteur, certains éléments peuvent freiner sa progression. Voici quelques éléments d’analyse de la situation.

Les vertus du Software defined networking

Il existe de multiples raisons de mettre en place une technologie SDN. Les apports peuvent être visibles à tous les niveaux : des techniciens en charge de maintenir le réseau opérationnel aux utilisateurs finaux.

Le réseau est aujourd’hui complexe à manipuler et à faire évoluer. Cette brique du datacenter est la dernière à résister aux sirènes de la virtualisation. Une telle évolution ouvre le champ des possibles en termes d’interactions entre tous les éléments de l’infrastructure. Cela autorise alors à imaginer des mécanismes d’automatisation dans la gestion de son infrastructure réseau.

Outre cette forte interaction rendue possible entre l’infrastructure et les applications directement exposées aux utilisateurs, la gestion « traditionnelle » du réseau est grandement simplifiée. La manière d’interconnecter les différents services du SI est repensée. En se concentrant sur le rôle de ces services SI, le réseau devient un simple intermédiaire. Le cas d’usage qui se dessine est alors celui de la flexibilité  du datacenter : si une politique donnée est associée à un service donné, alors cette dernière sera appliquée sans tenir compte de l’emplacement du composant qui exécute ce service. Il en résulte une grande facilité à mettre en place des applications.

Un usage répendu du SDN aujourd’hui est très lié à la virtualisation de fonctions réseaux (Network Function virtualisation ou NFV). Les NFV consistent à virtualiser les équipements de sécurité (Firewall, Load-Balancer, etc.) pour les rendre modulaires et faciliter leur déploiement. On voit alors apparaitre des solutions qui regroupent tous ces équipements au niveau de chaque machine virtuelle. Cela ajoute une couche de sécurité en local à l’intérieur d’un périmètre existant. Ces solutions offrent la possibilité de sécuriser les échanges à l’intérieur de zones de sécurité habituellement dépourvues d’équipements spécifiques. Le SDN intervient pour le pilotage central de ces équipements de sécurité distribués, dans le même environnement que le contrôle du réseau.

Enfin, il existe des initiatives qui jouent un rôle important dans l’accompagnement à l’adoption de la technologie SDN. HP, pionnier du SDN, propose une plateforme de mise en relation d’entreprises ayant des besoins précis avec des développeurs. Ces derniers pourront alors travailler avec l’entreprise pour mettre le SDN au cœur de la relation entre l’infrastructure et les applications. Pica8, acteur important du SDN, propose un kit de démarrage pour aider les entreprises à se lancer en fournissant un équipement réseau et des outils logiciels.

Aujourd’hui, l’adoption des technologies SDN se fait essentiellement chez les opérateurs Télécoms et les fournisseurs de services Cloud. Ces derniers utilisent le plus souvent des technologies développées en interne pour des besoins extrêmes très spécifiques. Pour les entreprises, le modèle SDN présente l’avantage de pouvoir se mettre en place sur un périmètre restreint dans une logique d’adoption progressive.

Pourquoi prévoit-on une adoption plus longue en entreprise ?

Le SDN génère un fort intérêt dans les entreprises, mais l’adoption sera longue.

Le premier frein à l’adoption du SDN pour les entreprises est l’identification du besoin et des applications concrètes dans un contexte métier. Toute la flexibilité que le SDN apporte n’est pas toujours une priorité pour les entreprises. De plus, cette technologie est en mesure de rendre possible de nouveaux usages que les entreprises ne perçoivent pas toujours en avance de phase. Par exemple la sécurisation au niveau de la machine virtuelle comme peuvent le proposer des acteurs comme VMWare.

Le second frein, une fois cette question de l’usage résolue, est la nécessité de trouver le bon fournisseur. Or aujourd’hui, aucun acteur du SDN ne se domine le marché. Du fait de sa faible adoption, et bien que la technologie fasse beaucoup parler d’elle depuis plusieurs années, aucun acteur n’a pu mettre en avant son savoir-faire. De fait, les entreprises expriment une certaine réserve sur le choix du fournisseur bien que des grands acteurs tels que VMware, HP, Dell ou Cisco proposent des solutions déjà fonctionnelles.

Troisième frein, le coût du ticket d’entrée reste très élevé. Ce coût apparait quel que soit le modèle de SDN mis en place. Dans le cas d’une architecture complètement virtuelle, il est nécessaire d’acquérir les licences logicielles. De même, une architecture mixte oblige à renouveler tout ou partie des équipements réseau. Il est aujourd’hui difficile d’estimer le coût de la transformation du réseau pour passer au SDN.

Finalement la mise en place est une crainte majeure des entreprises qui voit dans le SDN une complexité supplémentaire ajoutée à l’infrastructure existante. Cela est d’autant plus vrai qu’une phase de transition sera le plus souvent nécessaire, avec une cohabitation des différentes technologies. Le changement de paradigme sur le réseau renforce cette crainte du fait des nouveaux outils à appréhender.

Au-delà de ces freins et une fois l’architecture en place, il reste la question de la gouvernance. La mise en place d’un modèle où les flux sont majoritairement encapsulés rend complexe la surveillance et l’analyse des erreurs. L’utilisation d’un logiciel central qui va piloter toute l’infrastructure réseau pose la question de la confiance faite à ce logiciel. Quel contrôle doit exercer l’humain pour garder la maîtrise de la technologie alors même que cette dernière lui offre la possibilité d’accéder rapidement à toute son infrastructure réseau ?

Le SDN offre de nouvelles possibilités dans la gestion du datacenter. Au côté des serveurs et du stockage virtualisés, le datacenter dans son ensemble pourra alors passer au modèle Software Defined. Côté entreprise, des questions restent encore en suspens. Sans doute la meilleure façon d’y répondre serait de  mettre en place ce type de solution pour des projets spécifiques de façon à mettre à l’épreuve cette technologie. Selon nous, l’adoption  du SDN par les entreprises permettra  une évolution certaine dans le sens des besoins métiers. Encore un pas supplémentaire dans la tendance du Software Defined Everything !

Cet article Le Software defined networking pourrait-il devenir le réseau d’aujourd’hui ? est apparu en premier sur RiskInsight.

SDx : tour d’horizon des déclinaisons du « Software Defined »

Le Software Defined Networking est le premier acronyme du lot à avoir fait parler de lui. Il introduit un pilotage du réseau par une intelligence centralisée (le contrôleur), le traitement restant étant effectué par les équipements réseaux (qu’ils soient matériels ou logiciels).

Dans la lignée, le Software Defined Storage, ajoute une couche de virtualisation au-dessus du stockage. De la virtualisation existe déjà dans cet univers  au sein des baies mais le concept est ici étendu pour couvrir le stockage dans son ensemble. Les VSA (Virtual Storage Appliances) en sont un exemple.

Le terme Software Defined Servers, quant à lui,  fait aujourd’hui l’objet d’un débat… On devrait pouvoir ranger dans cette catégorie tous les hyperviseurs du marché.  Le concept a cependant évolué et est sans doute un peu à rapprocher du concept de SDN maintenant : l’idée est de piloter des ressources matérielles depuis une intelligence centralisée pour instancier des serveurs et gérer leurs ressources.

Enfin, le Software Defined Datacenter agrège les différentes techniques de virtualisation pour fournir un service complet de type ITaaS

Toutes ces déclinaisons ont un point commun : retirer de l’intelligence du matériel pour la porter sur du logiciel, supporté en général par du matériel courant (commodity hardware) type serveur x86… l’évolution technologique fait surtout (re)surgir des rivalités entre acteurs. La bataille entre les vendeurs de matériel et éditeurs de logiciels est plus âpre que jamais, chacun voulant soit protéger ses parts de marché actuelles, soit s’imposer sur ce nouveau marché qui explose…

Nouveau débat ou opposition récurrente ?

La rivalité entre les codeurs et les fondeurs de semi-conducteurs ne date pas d’hier, et n’est pas près de s’éteindre, et en fait on observe un balancier rythmé par les évolutions technologiques, que ce soit dans les logiciels et les CPU ou bien dans les matériels spécialisés, et notamment dans les réseaux.

Des affrontements ont donc régulièrement lieu entre défenseurs du matériel, principalement pour des raisons de performance, et défenseurs du logiciel, pour la souplesse. Ce type de débat a existé également pour les processeurs où s’opposent  CPU et ASIC (Application Specific Integrated Circuit), le circuit intégré polyvalent mais lent face au circuit intégré spécialisé et très rapide car « câblé » pour faire en une seule opération ce que le CPU fera en de multiples opérations.

Dans le domaine des infrastructures réseaux et sécurité on pourrait également faire référence aux affrontements historiques sur les routeurs (Cisco contre Extreme Networks ou Juniper) ou les pare-feu (Checkpoint contre Netscreen, racheté par Juniper depuis).

Toujours un même driver : vers plus d’intelligence et de souplesse…

La forte augmentation de la puissance des CPU x86 ces derniers temps les a amenés à embarquer un certain nombre de produits auparavant uniquement sous la forme de matériels vers une forme logicielle dans des hyperviseurs. Cette abstraction permet non seulement de ne plus être retreint par les possibilités du matériel, et donc d’apporter plus d’intelligence aisément, mais aussi un fort gain de souplesse : l’ajout de composants virtuels ne requérant aucune installation physique ni câblage.

Au-delà des serveurs c’est également le cas des pare-feu ou des équilibreurs de charge : F5, Radware et Citrix par exemple fournissent tous des versions en mode « virtual appliance ».

…mais pas au détriment des performances !

Ce qui est vrai dans les domaines ayant des traitements complexes ne l’est pas forcément dans des domaines nécessitant de très fortes performances brutes, comme les réseaux. Même les processeurs les plus récents ont du mal à suivre les débits du 10Gbs et encore plus du 40Gbps et du 100Gbps

Le logiciel a un gros avantage : la souplesse. Il est en effet bien plus simple de modifier quelques lignes de codes qu’ajouter des connexions cuivre et des transistors dans un ASIC. Néanmoins ce qu’un CPU fait en 20 ou 50 cycles d’horloge un composant spécialisé peut le faire en 1 ! C’est ici qu’interviennent les FPGA (Field Programmable Gate Array) : ces ASICs reprogrammables donnent une petite marge de manœuvre pour faire évoluer les fonctionnalités offertes par le matériel et tous les matériels modernes les intègrent afin d’arriver à réconcilier performances et souplesse.

Au-delà du cycle, une tendance se dégage donc : la solution doit pouvoir évoluer avec les besoins, qu’elle soit logicielle ou matérielle, et les équipements matériels non reprogrammables seront cantonnés à des utilisations spécifiques

Vers le « Software Defined Everything » oui, mais ne pas confondre « Software Defined » et « Software Only » !

Les solutions tout logiciel ne tiendront pas les performances nécessaires et à l’inverse les solutions tout matériel ne tiendront pas les promesses de souplesse demandées par les SI de demain.

Dans la réalité un compromis entre logiciel et matériel est évidemment obligatoire : du logiciel pour la souplesse et du matériel pour les performances… et c’est typiquement toute la logique derrière le Software Defined Networking, qui laisse au logiciel le soin de piloter du matériel à hautes performances.

Cet article Vers le « Software Defined Everything » ? est apparu en premier sur RiskInsight.

Les prémices du SDN

Il n’existe pas de définition unique du SDN (Software Defined Networking), chaque acteur du marché (équipementiers, éditeurs logiciels …) l’adapte à sa propre vision. Pour comprendre cette notion SDN, il faut s’attacher à son principe de fonctionnement : centraliser la gestion des flux réseaux.

Le SDN est né des travaux de recherche réalisés à l’Université de Berkley et Stanford. Son objectif est de revoir le fonctionnement des réseaux traditionnels actuels, caractérisés par la concentration du control plane (couche de gestion des flux, signalisation) et du data plane (couche de transit des données) au sein des équipements réseaux. Le principe du SDN est de désolidariser ces deux couches en rassemblant les fonctions ‘‘intelligentes’’ (control plane) au sein d’un équipement centralisé (le contrôleur).

Fin 2006, afin de concrétiser cette nouvelle approche, Martin Cassado et Nick McKeown de l’Université de Stanford, lancent de nouveaux travaux de développement d’un protocole permettant de mettre en pratique les principes du SDN. Ces travaux vont aboutir au développement du protocole OpenFlow.

Quelques équipementiers réseaux se sont intéressés au concept dès ses prémices, notamment en contribuant à des projets de recherche en collaboration avec les universités à l’initiative du SDN. Parmi ces sociétés, HP a collaboré dès 2007 avec l’Université de Stanford au développement d’Ethane, prédécesseur d’OpenFlow.

C’est en 2011, avec la création de la Open Networking Foundation (ONF), que les travaux de normalisation autour du SDN et de l’OpenFlow vont commencer. L’Open Networking Foundation est un consortium d’entreprises (opérateurs, constructeurs …) qui travaille au développement du SDN et à sa standardisation.

Le SDN est encore à l’époque un marché en retrait, en dépit d’initiatives à l’image de celle lancée aux US par Internet2 (Internet réservé à l’éducation et à la recherche) pour un réseau SDN à 100 Gbit/s Ethernet au standard OpenFlow prévu pour mi-2013.

Rachat de Nicira Networks par VMware : coup d’accélérateur pour le SDN

Le 23 Juillet 2012, VMware crée l’événement en annonçant le rachat de Nicira Networks, jeune entreprise pionnière et spécialisée dans le domaine du SDN, pour la somme de 1,26 milliard de dollars. Nicira Networks qui n’a que 5 ans, n’est autre que l’entreprise fondée en 2007 par Martin Cassado, Nick McKeown et Scott Shenker les pères du SDN et de l’OpenFlow.

Cette nouvelle alliance entre le géant de la virtualisation et l’un des pionniers du SDN confirme l’entrée de VMware dans le domaine du réseau et sa volonté de le faire évoluer. Les propos de Paul Maritz, CEO de VMware à l’époque de l’acquisition, confirment cette analyse : « VMware a conduit la révolution de la virtualisation des serveurs, et nous avons l’opportunité de faire la même chose dans l’univers du datacenter et du réseau en tant que service ».

Nicira Networks et sa technologie SDN s’adosse à la force de frappe commerciale de VMWare, ce qui pose la question de l’arrivée du SDN dans les datacenters. Ceci marque le début de la diffusion du SDN et de sa vulgarisation dans le domaine de l’lT.

Avril 2013, est marqué par la création du OpenDaylight project, qui travaille au développement d’un contrôleur open-source. Ce projet de développement est soutenu par la plupart des acteurs réseaux.

Le SDN, où en est le marché ?

Le SDN remet en question le modèle des grands acteurs du réseau : s’ils n’intègrent pas le SDN à leur stratégie, ils pourraient se retrouver cantonnés à vendre des boîtiers de commutation. Les équipementiers doivent donc intégrer le SDN à leur stratégie.

Ainsi, pouvoir proposer des équipements ou technologies basées sur du SDN devient une priorité et on assiste au rapprochement ou au rachat de petites startups spécialisées dans le SDN par les grands acteurs des réseaux et du logiciel : Oracle rachetant la startup Xsigo qui offre des services réseaux basés sur le SDN, Brocade décidant de renforcer ses recherches de R&D à travers le rachat de Vyatta, Juniper s’alliant à la société Contrail ou encore Cisco se rapprochant de la société Insiemi. Des acteurs comme HP se sont intéressés très tôt au SDN et se positionnent aujourd’hui parmi les leaders du marché.

Le 16 septembre dernier, le grand public a pu assister en direct au Webcast de Juniper, présentant sa solution SDN basée sur le contrôleur Contrail qui s’intègre dans l’orchestrateur IBM SmartCloud Orchestrator. La stratégie présentée par Juniper vise le secteur privé en offrant des solutions intra et inter-datacenter, mais l’ambition affichée est aussi de faire sortir le SDN des datacenters en  s’adressant aux réseaux opérateurs.

Pour les entreprises, le SDN peut représenter un levier pour gagner en flexibilité et optimiser les coûts réseaux. Par ailleurs, le marché du SDN reste très orienté datacenter et doit encore convaincre les réseaux opérateurs qui restent, à l’heure actuelle, la chasse gardée des solutions réseaux traditionnelles.

Cet article Le SDN : ce qu’il faut savoir sur le « Cisco killer » est apparu en premier sur RiskInsight.

Mais si le transport du FCoE n’était pas le principal enjeu de la Fabric Ethernet, ce nouveau « super LAN » pour les Datacenters d’aujourd’hui ? En effet quels sont les drivers du marché actuellement ? Certainement pas FCoE mais plutôt le Cloud Computing et notamment dans ses déclinaisons « privées » !

Des infrastructures datacenter mises à mal par la tendance Cloud

C’est la démarche Cloud computing privé qui tire actuellement l’évolution des infrastructures datacenters en bouleversant les modèles établis et poussant à la fois  la mise en place de VLANs (Virtual LAN) étendus au travers du datacenter et des débits plus élevés entre chaque point du réseau. La matrice de flux et les débits au sein du datacenter ont changé radicalement, d’une part du fait de la consolidation serveurs engendrée par la virtualisation et, d’autre part, à cause de la mobilité des machines virtuelles au sein du datacenter.

Les constructeurs de solutions Cloud ont donc dû innover : contraints par des infrastructures LAN historiques très statiques et hiérarchiques, ils ont intégré des solutions permettant de s’affranchir des limites des LAN existants actuellement, tel le Distributed Virtual Switch de VMWare qui ajoute une couche d’abstraction au-dessus des LAN physiques.

Le Cloud a dû innover pour contourner les limites des LAN traditionnels et séduit par sa démarche basée sur l’automatisation et la souplesse.

Une évolution nécessaire pour répondre aux enjeux…

Le LAN du Datacenter ne doit donc plus rester statique et être un frein à la mise en œuvre d’infrastructures de Cloud.

L’enjeu de la Fabric Ethernet est ainsi double : non seulement le LAN doit être étendu sans contrainte de débit ou de localisation géographique des ressources dans le datacenter,  mais il doit également permettre d’apporter une exploitabilité bien supérieure.

Cette amélioration de l’exploitabilité passe par plusieurs éléments : une augmentation de capacité simplifiée (plug & play) et une automatisation de certaines opérations (application d’un profil de configuration sur le port LAN sur déplacement de machine virtuelle par exemple).

Surtout, on ne doit plus administrer un LAN datacenter boîte par boîte, ce qui est consommateur de temps et source d’erreurs.

Certains constructeurs LAN ont d’ores et déjà intégré cette nouvelle donne directement  au sein de l’infrastructure LAN, comme Brocade dans une certaine mesure mais surtout Juniper avec sa QFabric ou encore l’initiative autour de d’OpenFlow et plus généralement, des « SDN » (Software Defined Networking).

D’autres constructeurs privilégient l’ajout d’une couche d’orchestration globale (Network Services Manager chez Cisco).

…avec un impact organisationnel

Cette approche vers un unique point d’administration amplifie toutefois l’impact d’une erreur humaine ou d’un bug. Les processus d’exploitation ainsi que le niveau des exploitants devront être adaptés s’ils ne le sont pas déjà, voire s’appuyer sur des outils de workflow de plus en plus souvent proposés par les équipementiers ou éditeurs, pour intégrer des étapes de validation des changements.

Une montée en compétence nécessaire des exploitants du LAN DC mais des changements allégés : un shift de la quantité vers la qualité des exploitants

En conclusion… vers une révolution de velours ?

C’est bel et bien une révolution, certes lente, qui est en marche au sein des LAN Datacenter… dans un silence assourdissant car complètement masqué par d’autres sujets qui font le buzz…

Mais le LAN Datacenter est encore loin d’avoir fini sa mutation, démarrée sous l’impulsion de la vague Cloud… et ce nouveau LAN, cette « Fabric Ethernet », n’est bien sûr pas indispensable dans  tous les contextes –   les « anciennes » architectures ont encore de beaux jours devant elles – mais c’est le seul à même de répondre de manière pertinente aux nouvelles évolutions du SI et à la souplesse et la réactivité qu’elles imposent.

Cet article Et si la « Fabric Ethernet » ne se limitait pas au FCoE ? est apparu en premier sur RiskInsight.