Explication des trois modèles de SDN
Dans cet article, le spécialiste des réseaux Tom Nolle passe en revue les trois modèles de réseau à définition logicielle (SDN), en expliquant les objectifs, mécanismes, avantages et inconvénients de chacun.
Il y a plusieurs dizaines d'années, l'informaticien et spécialiste des réseaux Andrew S. Tanenbaum affirmait déjà en plaisantant que ce qu'il y avait de bien avec les normes c'était qu'on avait largement le choix. On pourrait sans doute en dire autant aujourd'hui du nombre de modèles de réseaux à définition logicielle qui s'offrent aux fournisseurs de Cloud.
Sauf qu'avant même de pouvoir envisager un déploiement de réseau à définition logicielle (SDN) ou même un essai pilote, ces fournisseurs doivent choisir le ou les modèles de SDN à prendre en charge. Et tout mauvais choix pourrait être synonyme de perte de temps, de gaspillage des ressources, voire de désavantage concurrentiel pour leurs offres de service. Cet article s'attache à décrire les trois modèles de SDN, en expliquant les objectifs, mécanismes, avantages et inconvénients de chacun.
SDN étudié : le modèle de virtualisation de réseau
Le modèle le plus simple considéré comme SDN sur le marché est le modèle de virtualisation de réseau, popularisé par Nicira, une startup rachetée par VMware en 2012. La virtualisation de réseau a pour principaux objectifs d'éliminer les restrictions au partitionnement d'un réseau local (LAN) présentes dans les normes Ethernet de réseau local virtuel (VLAN), et de résoudre les problèmes d'évolutivité posés par la multidiffusion dans certaines architectures de réseau virtuel Ethernet.
Les plateformes de virtualisation de réseau renforcent un élément logiciel (généralement l'hyperviseur bien que les logiciels de Cloud comme OpenStack puissent également être modifiés) par une interface qui crée des VLAN fondés sur des tunnels exécutés sur la couche Ethernet traditionnelle. Ainsi, l'équipement et les opérations réseau ne subissent aucune modification et il est théoriquement possible de créer des dizaines de milliers de réseaux virtuels (voire plus).
Le plus grand avantage de la virtualisation de réseau tient à ce qu'elle prend en charge des Clouds multi-tenant sans nécessiter de modifications du réseau lui-même. Ce modèle de SDN s'adapte facilement aux interfaces de virtualisation répandues dans les mécanismes de réseau en Cloud. Il devient donc facile d'intégrer la mise à disposition de réseaux à celle de services de Cloud.
Le plus grand inconvénient tient à ce que les réseaux virtuels, situés « au-dessus » de la couche réseau, apparaissent simplement comme du trafic pour les périphériques réseau. Ces périphériques ne peuvent classer les réseaux virtuels par ordre de priorité ou rapporter leur état qu'en procédant à une inspection approfondie des paquets pour identifier l'en-tête de réseau virtuel. Enfin, comme les réseaux virtuels sont créés par un logiciel faisant partie de la pile serveur, ils ne peuvent relier que des machines virtuelles, pas des utilisateurs ni des périphériques.
SDN étudié : l'approche « évolutive »
Le deuxième modèle de SDN peut être appelé « évolutif ». L'objectif de ce modèle consiste à améliorer le contrôle logiciel du réseau et de son fonctionnement mais dans les limites de la technologie réseau actuelle. Pour ce faire, les fournisseurs de réseau sont susceptibles d'adopter des normes spécifiques, telles que VXLAN, GRE, BGP et MPLS, et de s'en servir pour partitionner le réseau en communautés virtuelles et pour gérer le trafic et la qualité de service. Ces fournisseurs pourront alors combiner leurs solutions en une série d'interfaces de gestion utilisables depuis le Cloud... ici encore par le biais d'outils DevOps ou d'une interface virtuelle de Cloud comme OpenStack Quantum.
Des périphériques réseau mettent en oeuvre ce modèle de SDN, en l'intégrant complètement au fonctionnement, à la gestion FCAPS et à la surveillance du réseau. Il est alors possible d'appliquer les principes conventionnels de l'ingénierie réseau. Par ailleurs, les réseaux virtuels peuvent en théorie s'étendre du serveur à l'utilisateur, du moment que les périphériques prennent en charge les normes sélectionnées.
La plupart des fournisseurs de SDN mettent actuellement en oeuvre toutes les normes de réseau ci-dessus, mais certaines peuvent ne pas être disponibles sur tous les périphériques. Ce dernier point constitue l'un des inconvénients de ces modèles évolutifs. En effet, les fournisseurs doivent valider les normes prises en charge par les équipements existants. Problème plus important, pour l'instant seuls certains fournisseurs proposent ces modèles de SDN évolutifs, qui peuvent ne pas être totalement compatibles avec les équipements d'autres fournisseurs. Enfin, cette approche exigera sans doute une intégration spéciale entre les systèmes de gestion et le réseau virtuel en Cloud ou les interfaces DevOps. Si le fournisseur n'assure pas cette intégration, ce sera à l'opérateur de s'en charger.
SDN étudié : le modèle OpenFlow
Le dernier modèle de SDN est le modèle OpenFlow, celui que la plupart des gens associent au terme SDN. OpenFlow remplace la création traditionnelle, reposant sur la découverte, de tables d'acheminement dans les commutateurs et routeurs dotés d'un acheminement centralisé, ce qui signifie qu'un contrôleur central programme la table d'acheminement de chaque périphérique. Ainsi, ce point de contrôle central régit entièrement le mode de segmentation ou de virtualisation du réseau, la gestion du trafic, etc. Il est possible, dans ce modèle de SDN, d'utiliser n'importe quelle combinaison de contrôleurs et de commutateurs prenant en charge des versions compatibles d'OpenFlow (des versions compatibles avec les fonctions réseau nécessaires).
Contenus Premium
Le plus grand avantage de ce dernier modèle de SDN tient à ce qu'il s'agit du modèle sur lequel repose l'élaboration initiale du concept de SDN. Les premiers essais et déploiements pilotes suggèrent qu'OpenFlow peut améliorer la disponibilité et la fiabilité d'un réseau, tout en augmentant ses taux d'utilisation, réduisant ainsi à la fois les dépenses d'investissement et les coûts opérationnels. Si les commutateurs OpenFlow se généralisent progressivement, il sera peut-être possible à l'avenir de créer des réseaux avec du matériel ouvert, et ce pour un coût bien inférieur.
L'inconvénient de ce modèle est le manque actuel de fonctionnalités pour tous les composants nécessaires. OpenFlow est pris en charge sur la plupart des commutateurs et routeurs courants, mais pas toujours avec un débit comparable à celui des protocoles traditionnels. Et, bien sûr, ce mécanisme de prise en charge OpenFlow ne contribue guère à une baisse du coût de la commutation.
Des contrôleurs OpenFlow open source et commerciaux sont disponibles, mais leurs fonctions se limitent pratiquement à envoyer des commandes aux commutateurs pour créer des chemins, gérer la capacité et ainsi de suite. Des applications de gestion des couches supérieures sont nécessaires. Elles doivent se connecter aux contrôleurs OpenFlow par le biais d'API ascendantes (northbound), qui ne sont pas normalisées. Avec les premières mises en oeuvre d'OpenFlow, les opérateurs devaient intégrer plusieurs composants pour créer un réseau à définition logicielle fonctionnel ; il n'existait aucune offre commerciale complète.
Trois modèles, mais lequel est le meilleur ?
Les fournisseurs de Cloud gênés par les limites des VLAN en matière de segmentation (4 095 VLAN par réseau) ou confrontés à des problèmes de multidiffusion dans le routage par VLAN auront peut-être intérêt à considérer en premier le modèle de SDN reposant sur un réseau virtuel. Ce modèle peut également être superposé au modèle de SDN évolutif, malgré certains problèmes d'harmonisation des interfaces de gestion. Les fournisseurs ayant fortement investi dans l'équipement de réseau du datacenter pourront envisager cette approche pour éviter de multiplier les coûts.
On peut prédire qu'OpenFlow devrait connaître au moins quelques aménagements. Les fournisseurs auraient donc intérêt à réclamer sa prise en charge par leurs fournisseurs de matériel de réseau, en particulier à l'occasion du déploiement de nouveaux équipements. Par chance, presque tous les fournisseurs de réseau se sont explicitement engagés à prendre en charge OpenFlow dans le cadre de leur approche évolutive du SDN. Autrement dit, les fournisseurs de Cloud peuvent en fait miser sur une combinaison de deux modèles de SDN, voire des trois. Comme toujours, des procédures de tests approfondis s'imposent pour garantir un fonctionnement à la fois stable et rentable.
