SDN et datacenter, où en sommes-nous ? (Tribune)

La nouvelle façon de concevoir le réseau, portée par le concept de SDN (Software Defined Network) à savoir, automatiser le réseau en le rendant programmable, est indéniablement l’avenir du datacenter. Celui-ci requiert une meilleure souplesse pour répondre à l’agilité apportée par la virtualisation des serveurs. Il en résulte qu’il est actuellement impossible de dérouler une présentation Powerpoint d’une solution du marché sans y trouver l’acronyme.

Le problème est que le SDN n’est pas une technologie mais une nouvelle façon d’opérer le réseau et que celle-ci est loin d’être arrivée à maturité et évolue très rapidement. Il est vraiment difficile de s’y retrouver, chaque éditeur apporte sa propre vision mais aussi essaie de ne pas rater le bon wagon. C’est d’autant plus ardu que de nombreuses start-ups se sont créées et se créent sur ce marché en perpétuelle évolution. Elles y apportent leurs idées mais elles participent aussi à la confusion générale.

Il faut aussi bien prendre en considération que dans un datacenter il n’y a pas un mais deux réseaux. Le premier réseau est le réseau de couches L2/L3 dont le rôle est d’acheminer les paquets, le SDN est né de la volonté de les acheminer différemment depuis un point de contrôle centralisé. Le second est le réseau des couches L4/L7 qui sont des couches applicatives où sont positionnées les fonctions de sécurisation, de répartition de charge, d’optimisations associées aux applications.

Un contrôle par l’hyperviseur ou du hardware ?

L’acheminement des paquets dans le monde SDN s’appuie sur la technique d’overlay. Dans le datacenter deux principes s’y affrontent mais peuvent aussi cohabiter. L’overlay de réseaux logiques, à la base du concept SDN, qui s’appuie sur le principe de la norme Openflow avec des commutateurs physiques et virtuels (vswitch) compatibles et une gestion des flux centralisée au niveau du contrôleur. Ce modèle dit ‘’edge-overlay’’ avec des tunnels ‘’L2-in-L3’’, qualifiés de software car établis au niveau des hyperviseurs ou du hardware, sont installés au niveau des commutateurs physiques. Ce modèle étant fortement lié au besoin d’élasticité, à la mobilité des machines virtuelles et au Cloud Computing.

Vaut-il donc mieux partir sur une architecture Openflow de manière, à termes, à bénéficier d’une réduction des coûts de Capex en tablant sur la possibilité d’introduire des commutateurs bare-metal à l’avenir ? Cette solution est-elle mature ?

L’hyperviseur a transformé la couche d’accès, n’est-il pas le meilleur endroit pour y positionner les fonctions de commutation, routage et à termes de sécurité ? N’aurais-je pas des problèmes de performance et ne devrais-je pas plutôt partir sur une solution hardware qui va discuter avec mes hyperviseurs ? Dans ce cas de figure, est-ce que je vais être dépendant d’un seul éditeur ? Mais surtout comment vont s’opérer les fonctionnalités de L4/L7 ?

Des API  et des SDK ouverts

Il reste à l’heure actuelle beaucoup d’interrogations d’autant plus que nous n’avons abordé que le côté Southbound du monde SDN et que ce que nous pouvons qualifier ‘’d’applications standards’’ pouvant s’interfacer avec un contrôleur, de quelque nature qu’il soit, sont les solutions d’orchestration de cloud privé/public (type OpenStack). Les autres applications disponibles restent encore propriétaires et attachées au contrôleur de l’éditeur.

Néanmoins le réseau ne peut rester indéfiniment le parent pauvre de l’IT en termes de flexibilité. Beaucoup optent donc pour le passage par une étape intermédiaire, l’automatisation de sa configuration. Celle-ci permet ainsi de réutiliser la majorité des équipements constituant l’architecture actuelle et particulièrement les équipements de L4/L7.

En ce sens rien de nouveau, cela fait longtemps que les geeks ont automatisé les déploiements par le biais de scripts maison. Néanmoins, l’hétérogénéité des équipements et leurs faibles capacités de programmation (au-delà de la CLI) rendaient la tâche ardue. Les équipementiers réseaux ont bien compris cette étape intermédiaire et rendent leurs produits de plus en plus ouverts et programmables par le biais d’API ouvertes ou de SDK de plus en plus riches.

La question est ici quel est le bon contrôleur/orchestrateur pour m’aider dans cette voie ? Pourra-t-il m’aider à faire le lien avec le futur ?

Tout en essayant de consolider leurs ressources hardware, c’est aussi essentiellement par le biais des API que se positionnent les acteurs du L4/L7 en se rendant ainsi compatibles avec les futures infrastructures ‘’SDN’’ tout autant que les actuelles. Bien évidemment quelques start-ups apportent de nouvelles idées.

A ce jour, il reste beaucoup d’incertitudes sur ce que seront les architectures futures des Datacenters. Par contre, nous avons deux certitudes et aussi deux mythes associés au SDN qui s’effondrent. A savoir que le SDN réduit la complexité de l’infrastructure réseau, tout du moins dans le datacenter et qu’il élimine le besoin en experts réseau.