Les bases du SDN : comprendre les atouts de la programmabilité et du contrôle centralisé
Les deux principaux piliers de l'approche SDN sont la programmabilité des équipements réseaux et la mise en oeuvre d'un point de contrôle centralisé.
Deux technologies majeures adoptées au cours de la dernière décennie ont eu un effet énorme sur les technologies de l’information : la virtualisation et le cloud computing. Ces technologies, très liées, ont permis aux ingénieurs réseau et aux architectes applicatifs de bénéficier d’une grande souplesse pour tirer parti de chaque mètre carré de leur datacenter et exploiter au mieux les capacités de leurs matériels, tout en améliorant la disponibilité de leurs applications.
Le réseau de données utilisé par les applications a en revanche peu évolué en comparaison des autres composantes du datacenter. Si la virtualisation et le cloud computing ont changé la façon dont les informaticiens abordent l’IT, l’administration du réseau, en tant que discipline, a largement stagné. La plupart des évolutions technologiques dans le monde des réseaux ont essentiellement apporté des évolutions incrémentales en matière de bande passante et n’ont pas affecté en profondeur la façon dont les services réseaux sont délivrés. De fait des ouvrages de référence sur les réseaux écrits il y a cinq ou dix ans sont toujours considérés comme des références valables par de nombreux professionnels des réseaux, simplement parce que de façon générale, le réseau a peu évolué. Résultat, comme l’expliquait James Hamilton, un ingénieur distingué d’Amazon Web Services, dès 2010, "les réseaux de datacenter sont en travers de mon chemin."
Le problème est en effet que le manque d’innovation dans l’univers des réseaux a fait peser des contraintes importantes sur le déploiement des applications. Les constructeurs ont donc fini par se décider à tenter d’apporter aux réseaux le niveau de flexibilité et de simplicité dont ont besoin les entreprises et les fournisseurs de services.
Les principaux domaines d’innovation au cours des dernières années sont à chercher du côté du contrôle centralisé, de la programmabilité, de l’orchestration et de la virtualisation. Ces innovations sont regroupées sous l’appellation commune de SDN (ou software-defined networking) et visent à résoudre les problèmes que les entreprises rencontrent avec leurs réseaux alors que la virtualisation et le cloud poussent ces derniers dans leurs derniers retranchements.
À la base des SDN : un contrôle centralisé
Les SDN ont pour but pratique de rendre les réseaux programmables par le biais d’un contrôleur centralisé. Aujourd’hui les commutateurs et les routeurs programment leurs tables de forwarding localement, ce qui signifie que les périphériques réseau prennent leurs propres décisions en interne sur la meilleure façon de transférer le trafic. Ces décisions s’appuient sur les informations distribuées collectées par des protocoles de routage comme OSPF et BGP ou des protocoles comme Spanning Tree. Mais ces protocoles sont peu flexibles. Pour fonctionner ensemble, tous les équipements du réseau doivent suivre les règles définies par les standards. Cela laisse peu de place à la créativité ou à des exigences métiers inhabituelles.
Avec les SDN, on établit une séparation claire entre le plan de contrôle (qui définit comment un équipement forwarde le trafic) et le plan de données (l’équipement qui effectivement assure le mouvement des données). Dans les SDN, le plan de contrôle est placé dans un contrôleur centralisé qui a une visibilité sur l’ensemble du réseau, y compris les hôtes qui s’y connectent et a une vision complète de la topologie du réseau.
Un contrôleur central omniscient permet aux ingénieurs de réseau de mettre en œuvre des politiques de transfert uniques et flexibles dont les seules limitations sont liées à la capacité du logiciel faisant fonctionner le contrôleur.
Deux termes importants qui reviennent dans les conversations de contrôleur sont « SouthBound » et « NorthBound ». En fait si l’on considère le contrôleur comme un middleware, les applications qui disent aux contrôleurs comment programmer le réseau utilisent des interfaces de programmation « NorthBound » tandis que les API et protocoles utilisés par le contrôleur pour communiquer avec les équipements du réseau sont dits « SouthBound ». Le contrôleur agit comme un arbitre, en fournissant une couche d’abstraction du réseau physique sous-jacent pour les applications qui souhaite le programmer.
Voici par exemple quelques opérations courantes qui peuvent bénéficier d’une approche SDN :
- La création d’un réseau expérimental qui fonctionne sur la même infrastructure physique que le réseau de production, tout en étant logiquement isolé.
- La mise en œuvre de politiques de circulation où l’on applique dynamiquement des politiques à des flux afin de maintenir une qualité de service définie (QoS).
- Le routage en fonction de paramètres financiers, ou les chemins de forwarding sont déterminés en fonction de l’impact financier des flux transportés pour la société.
- La mise en œuvre de politiques de sécurité réseau intelligentes, où des flux particuliers peuvent être isolés et basculés vers un système de détection d’intrusion pour une inspection approfondie, tandis que d’autres sont autorisés à circuler librement en fonction des exigences opérationnelles de la société.
- La mise en œuvre de mirroring de flux (ou de spanning), pour dupliquer des flux à des fins de logging, de reporting ou d’analyse.
Vers un réseau programmable
Les administrateurs réseau configurent généralement les équipements du réseau à l’aide d’une interface de ligne de commande (CLI) ou via l’interface utilisateur graphique (GUI) des équipements. Ce modèle n’est pas sans poser des problèmes. La mise en œuvre de configurations de réseau complexes peut exiger d’un ingénieur qu’il configure séparément plusieurs périphériques réseau différents. C’est un processus gourmand en temps, fastidieux et source d’erreurs.
Par comparaison, les administrateurs système disposent d’outils d’automatisation comme Puppet ou Chef pour soulager leur charge de travail. Malgré l’omniprésence de Simple Network Management Protocol (SNMP), les ingénieurs de réseau n’ont jamais eu un ensemble d’outils de gestion cohérent pour gérer des tâches de provisioning de façon simple.
En rendant les réseaux programmables, l’objectif des SDN est de changer cela en mettant à disposition des administrateurs des interfaces de programmation d’applications (API) permettant de programmer les périphériques du réseau via de multiples langages. L’utilisation d’API implique aussi que la programmation du réseau n’est plus forcément limitée aux seuls ingénieurs réseau capable d’utiliser une CLI mais accessible à un ensemble d’outils. Voici quelques exemples :
- Des scripts peuvent être utilisés par les ingénieurs de réseau pour automatiser les tâches de provisioning ou recueillir des statistiques de réseau. (Les ingénieurs réseau peuvent aujourd’hui utiliser des scripts, mais ce ne sont en général qu’une façon glorifiée d’interagir avec la CLI ou SNMP). Les API promettent des fonctionnalités plus riches et la possibilité de construire des écosystèmes où les ingénieurs pourraient collaborer entre eux ou avec des ingénieurs systèmes.
- Les outils d’orchestration pourraient intégrer des tâches de provisioning réseau avec d’autres tâches requises pour créer une application d’entreprise.
- Des applications réseau, fonctionnant en temps que plugins du contrôleur centralisé, pourraient ajouter des fonctionnalités à l’environnement réseau, un peu comme une App vient enrichir l’OS d’un smartphone.
De nombreux équipementiers réseau se sont attelés à la définition d’API pour permettre de tirer parti aux mieux de leurs matériels. Parmi eux, Cisco, Brocade, Juniper ou HP. Par exemple, même s’il n’en est qu’à ses débuts, onePK de Cisco offre une bibliothèque d’API qui permet la programmation d’une variété de matériel réseau Cisco utilisant IOS, IOS-XR et NX-OS. Junos de Juniper a toujours eu une API XML ; et sa CLI génère du code XML à envoyer au système d’exploitation sous-jacent.
Il est difficile de ne pas mentionner OpenFlow lors de l’évocation des SDN. En développement constant au sein de l’Open Networking Foundation, ce protocole est un excellent exemple de la façon de mettre en œuvre la programmation de réseau à l’aide d’un contrôleur central. OpenFlow est une norme agnostique qui décrit comment programmer un commutateur de réseau. Il identifie les flux spécifiques en utilisant une variété de critères (adresse MAC, adresse IP de destination, etc), puis effectue des actions sur ces flux (forwarding via le port X ou Y, abandon du trafic, etc). Un contrôleur OpenFlow centralisé avec la connaissance de l’ensemble de la topologie du réseau peut programmer ces politiques pour tous les commutateurs de réseau.
Parmi les contrôleurs OpenFlow open source on peut citer Beacon et FloodLight (de Big Switch) ainsi que le contrôleur OpenDaylight. La liste des fournisseurs d’équipements supportant OpenFlow dans leurs équipements comprend notamment Brocade, Cisco, Extreme Networks, HP, Juniper, Pica8 et bien d’autres.
A propos de l’auteur :
Ethan Banks, CCIE #20655, est un professionnel des réseaux qui a conçu, réalisé et assuré la maintenance de réseaux destinés à l’enseignement supérieur, au gouvernement fédéral, à des institutions financières et des entreprises du secteur technologique. E. Banks a également participé au Packet Pushers Podcast, un programme technique consacré à la conception pratique de réseaux, ainsi qu’à des sujets pointus comme la virtualisation, OpenFlow, et les réseaux d’overlays. Il est le rédacteur en chef d’une communauté indépendante de bloggers sur PacketPushers.net et vous pouvez le suivre via @ecbanks.
