Le titre de ce chapitre est provocateur car il n’est pas question ici de proposer une quelconque méthode pour choisir un constructeur, et ceci pour au moins deux raisons :

• Le modèle de distribution en France est un modèle indirect et il serait donc nécessaire de choisir autant l’intégrateur que le constructeur.
• Les réalités commerciales font que même si c’est à ce stade du raisonnement que le choix devrait se faire, le constructeur est généralement déjà sélectionné pour des raisons stratégiques, par l’intégrateur et/ou le bureau d’étude, bien avant d’analyser le besoin.

Cependant, si l’objectif est bien d’aller dans la direction proposée par tous les concepts évoqués précédemment, il y a des éléments de vocabulaire et des technologies qu’il faut regarder plus en détails pour comprendre la direction que prennent les constructeurs et la réalité de leur positionnement face à ces nouveaux challenges.

Il peut paraître intéressant de commencer par revenir sur les objectifs du SDN (Software Defined Network) dont on entend tant parler. Ce concept a été lancé par l’organisation ONF (Open Networking Foundation) avec pour attente, de séparer le « Control Plane » du « Data Plane » et comme fil conducteur « Transforming Networks into Agile Platforms for Service Delivery ». En d’autres termes, le but est de séparer la partie prise de décision (Control Plane) de la partie action (Data Plane ou Forwarding Plane). Pour que les deux entités puissent communiquer de façon transparente, le protocole OpenFlow a été mis au point.

Dans un même temps, l’organisation OCP (Open Compute Project), dont les équipes de Facebook sont à l’initiative, propose de repenser le matériel sous une forme plus ouverte que celle existante chez les constructeurs, avec comme slogan « The future of IT is open ». Pour ce faire, il est proposé de désagréger le matériel du logiciel afin de sortir des propositions monolithiques des constructeurs existants. Facebook dit avoir économisé plus d’un milliard de dollars grâce à cette approche.

De nombreux grands acteurs de l’IT et de nombreux constructeurs ont rejoint ces mouvements, pas tous convaincus de l’intérêt commercial pour eux à terme, mais au moins pour ne pas rester à la traîne de ce nouveau courant. Ces nouvelles orientations ont donné naissance à des sociétés émergentes et des nouveaux projets Open Source, pour finalement permettre aujourd’hui d’atteindre de nombreux objectifs dans les domaines de la désagrégation et de l’automatisation appelée « Network Automation » dans la littérature.

La presse s’est empressée de parler de l’arrivée des commutateurs « Bare Metal », parfois appelé « White Box » (bien que la signification puisse être légèrement différente), à des prix très bas et sur lesquels il est possible de mettre le système d’exploitation réseau de son choix. C’est une conséquence du mouvement SDN, mais pas forcément conforme à la définition de l’ONF puisque le « Control Plane » reste sur le même équipement que le « Data Plane », mais plus conforme à la logique de l’OCP. S’il est vrai qu’il est possible d’utiliser des commutateurs « Bare Metal » pour construire la partie réseau, au même titre qu’il est possible de construire les parties serveur, virtualisation et stockage à l’aide de matériels ouverts et de logiciels « Open Source », seuls les « Data Centers » sont actuellement concernés par cette approche. En effet, si on observe les commutateurs disponibles, ils sont architecturés pour construire des topologies « Leaf-Spine » propres aux « Building Blocks » des serveurs. Il n’en reste pas moins que tous les constructeurs historiques de matériels réseaux se rendent compte qu’un virage est en train de se prendre et qu’il ne sera plus possible de continuer à proposer des matériels fermés avec des systèmes propriétaires. Il est intéressant de voir apparaître, chez ces constructeurs, des offres de commutateurs ouverts moins chers et sur lesquels ils ne proposent plus leur système d’exploitation propriétaire. Il est également intéressant de voir que certains proposent un système d’exploitation réseau « Open Source ».

On peut souvent voir la notion de NFV (Network Functions Virtualization) associée au SDN. En réalité, l’idée consiste à mettre sous forme logicielle ce qui pouvait faire l’objet d’un matériel. Par exemple, les routeurs, les firewalls, les load-balancers, les IDS/IPS, … ou tout autre fonction qui peut faire l’objet d’une appliance matérielle est susceptible de devenir virtuelle.

Outre les fonctions et protocoles habituels, voici un exemple de ce qu’il faut observer dans les propositions des constructeurs historiques pour avoir une chance d’aller vers tous ces nouveaux concepts :

• Vérifier que toutes les fonctions visées sont disponibles sur l’ensemble des matériels sélectionnés pour construire l’architecture.
• Choisir le protocole OpenFlow, dans la version requise, si on souhaite utiliser un contrôleur externe. Les commutateurs proposent souvent le mode hybride permettant de configurer OpenFlow port par port afin de piloter une partie en externe et une partie en interne.
• Exiger la présence d’un interpréteur python sur les commutateurs, afin d’utiliser pleinement un outil d’automatisation comme Ansible. La disponibilité de librairies python « Open Source » est un plus.
• Disposer du ou des systèmes d’exploitation réseau embarqués sur les commutateurs sous forme de machines virtuelles afin de simuler le réseau et permettre d’élaborer le processus CI/CD.