J’exposais dans mon précédent article les contraintes liées à l’automatisation du déploiement de réseaux privés en datacenter et évoquais, sans m’y attarder, la notion de Software Defined Networking. Je tenterai dans le présent article d’y remédier en expliquant ce qu’est le SDN, puis dans une seconde partie, de donner une vision d’ensemble des solutions existantes aujourd’hui.
Le SDN désigne, comme son nom l’indique, le fait de piloter une infrastructure réseau par un logiciel. L’idée est de mettre en place un ou plusieurs serveurs capables de piloter tout ou partie des composants réseau (physiques ou virtuels) de l’infrastructure. Les clients ou autres services de l’infrastructure pourront alors s’adresser à ces serveurs pour allouer des ressources (des réseaux privés, des règles de pare feu, des routes, …). Ainsi, un orchestrateur comme Kubernetes pourra allouer les ressources réseau nécessaires à la volée, lors du déploiement de nouveaux projets, en dialoguant avec le service de contrôle. Dans le cas d’un IaaS privé comme OpenStack par exemple, l’utilisateur de la plateforme pourra allouer lui-même les ressources réseau et les configurer, grâce (notamment) à Neutron. Dans le cas d’un fournisseur de Cloud public comme AWS (ou GCP), lorsque vous allouez des VPCs, subnets, ou autres route tables, vous utilisez également une solution de SDN.
Une solution de SDN permet donc de gagner en rapidité et en productivité, ce qui semble logique. Cependant ce n’est pas le seul avantage. Disposer d’une API et rendre programmable l’allocation de ressources réseau, permet d’appliquer des concepts que l’on retrouvait jusqu’ici rarement dans le domaine : immutabilité, infrastructure as code, intégration continue, infrastructure pilotée par les tests… Concernant l’infrastructure as code, c’est déjà possible à partir du moment où l’on utilise un outil de configuration doué d’idempotence, mais sans un contrôleur unifié la tâche peut s’avérer plus compliquée.
Lorsque l’on parle d’un équipement réseau “classique” (commutateur ou routeur physique), on distingue couramment deux composants principaux : le plan de contrôle et le plan de transmission (ou plan de données). Le plan de contrôle (control plane) désigne l'intelligence de l’équipement, soient le CPU et les services qui en dépendent. C’est cette partie qui est responsable de la communication avec d’autres équipements, via un protocole de routage dynamique (BGP, OSPF, ISIS) par exemple. Plus généralement, le plan de contrôle (souvent apparenté à la Routing Engine) est responsable de remplir la table de transmission. Celle-ci est présente pour une seule raison : dire au second composant majeur de l’équipement, le plan de transmission, ce qu’il doit faire de chaque trame/paquet/ensemble de données qu’il va devoir traiter. Le plan de transmission désigne généralement les composants, dédiés à la transmission de données à hautes performances sur le réseau, que l’on appelle les ASICs.
Le principe du SDN est simple :
Les contrôleurs disposent donc d’une maîtrise globale de l’infrastructure et sont capables de s’informer en temps réel sur l’état et l’activité des équipements (physiques ou virtuels) qu’ils pilotent. Les actions entreprises peuvent alors affecter l’ensemble de l’infrastructure, ce qui ouvre le champ des possibles en termes de scalabilité pour l’allocation de ressources de calcul/mémoire/stockage et permet un très grande souplesse dans les services proposés aux clients.
Lorsque l’on entends parler de SDN, il est également fréquent d’entendre parler de protocoles obscurs comme OpenFlow, Netconf, OVSDB . De quoi s’agit-il ? Tentons de remettre ces appellations à leur place.
Les contrôleurs SDN (la plupart des solutions proposent de créer des clusters de contrôleurs pour des raisons évidentes de haute disponibilité) sont censés piloter les éléments réseau. Les protocoles utilisés pour permettre cette communication et ce contrôle sont parfois regroupés sous l'appellation générique: Southbound API. On retrouve notamment dans cette catégorie les protocoles: Netconf (RFC 6241), OVSDB (RFC 7047), OpenFlow, SNMP, SSH, BGP, voire XMPP. Certaines solutions assurent également cette communication grâce à un backend de stockage en mode clef:valeur (Flannel en est un exemple avec etcd). En fonctions des solutions de SDN, vous pourrez retrouver un ou plusieurs de ces protocoles parmis ceux utilisés pour la communication entre le plan de transmission et le plan de contrôle.
En amont, les contrôleurs SDN proposent une API, souvent appelée Northbound API, destinée aux clients. Ces clients peuvent être de vrais clients (comme vous lorsque vous créez un VPC via l’API d’AWS) ou bien d’autres services d’infrastructure ou applications (l’interface web Horizon dans OpenStack est une application cliente de Neutron, les utilisateurs peuvent passer par Horizon pour demander à Neutron de déployer de nouvelles ressources réseau).
Comme pour compliquer un peu plus les choses, la définition du SDN proposée dans les RFC 7426 et 7419 définit de nouveaux plans:
Si vous vous souvenez de l’article sur les réseaux d’overlay paru plus tôt sur le blog, vous aurez sûrement deviné la place que cette technologie occupe dans une solution SDN. Les réseaux d’overlay, s’ils sont supportés par la solution, permettent d’assurer la communication entre les éléments du data plane, dans un environnement où s’abstraire d’une partie de l’infrastructure est nécessaire (pour toutes les raisons présentées dans ledit article).
Comme évoqué également, certaines solutions de SDN ne proposent pas de réseaux d’overlay au niveau du plan de transmission. C’est le cas notamment de Calico (dans un but de simplicité et pour faciliter le troubleshooting) et de Cisco ACI (car c’est une solution s’appuyant sur les capacités avancées du matériel fourni par le constructeur).
Voici une rapide vue d’ensemble de l’écosystème des solutions SDN aujourd’hui. J’en oublierai certainement quelques unes, mais le but est de pouvoir donner des pistes pour approfondir le sujet par la suite.
NomPorteurOpen SourceLicenceSpécialitéONOSOpen Networking FoundationouiApache 2.0GénériqueCiliumCiliumouiApache 2.0 + GPL v2.0ConteneursNeutronOpenStack FoundationouiApache 2.0GénériqueCalicoTigeraouiApache 2.0GénériqueOpenContrailJuniperouiApache 2.0GénériqueContivCiscoouiApache 2.0ConteneursOVNLinux FoundationouiApache 2.0GénériqueOpenDaylightLinux FoundationouiEPL 1.0Génériqueweave netweaveworksouiApache 2.0ConteneursFlannelCoreOSouiApache 2.0ConteneursACICiscononCommercialeVirtualisation et bare metalMidonetMidokuranonCommercialeGénériqueNSXVMWarenonCommercialeGénériqueNuageNetworksNokianonCommercialeGénérique
Cet article sera le point de départ pour d’autres articles qui présenteront, chacun, l’une de ces solutions, accompagné d’une démonstration simple de ses fonctionnalités.
Il est à noter que l’utilisation de contrôleurs et donc d’une solution SDN, n’est pas le seul moyen d’exporter le plan de contrôle de votre réseau. Chez les opérateurs, l’utilisation de BGP EVPN est très en vogue. L’avantage de cette solution est que le plan de contrôle reste décentralisé et s’appuie sur un protocole très éprouvé: BGP. Cependant cette approche peut être délicate à mettre en place dans un contexte d’hébergement, surtout si l’on veut utiliser des conteneurs.
OpenFlow specifications
Blog de Stéphane Bortzmeyer: RFC 7426
Blog de Stéphane Bortzmeyer: RFC 7419