SDN : principes et fonctionnement

Dans une solution Cloud il est nécessaire de pouvoir consommer chaque ressource comme un service. Ça paraît évident en ce qui concerne la puissance de calcul (CPU), la mémoire vive, le stockage, etc… Ceci est d’ailleurs valable quel que soit le type de service que l’on veut proposer, IaaS ou PaaS. Même si ce n’est pas la ressource qui vient en premier à l’esprit, le réseau présente les mêmes besoins, pour des questions de scalabilité, mais aussi de sécurité (mettre les VMs ou conteneurs de plusieurs utilisateurs différents dans un même réseau est inconcevable). 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 : qu’est ce que c’est ?

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.

Qu’est ce que ça apporte concrètement ?

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.

Comment ça marche ?

Un peu d’historique

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.

control plane et data plane

Et donc ?

Le principe du SDN est simple :

  • séparer le plan de contrôle du plan de transmission
  • centraliser et mutualiser le plan de contrôle entre tous les équipements
  • réduire les équipements à leur fonction la plus élémentaire : transmettre (ou ne pas transmettre) des données sur le réseau
  • les serveurs chargés de fournir le plan de contrôle de la solution SDN sont généralement appelés contrôleurs SDN

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.

control plane, data plane et SDN

Terminologie et interfaces

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).

SDN

Encore un peu de terminologie

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:

  • le plan des opérations (operations plane ): ce plan désigne la gestion globale d’un composant de l’architecture de SDN
  • le plan d’administration (management plane) : celui-ci désigne la configuration et la supervision d’un composant de l’architecture de SDN
  • le plan des applications (application plane): celui ci est le plus simple à visualiser, il désigne les applications et services développés au dessus de la Northbound API

Et les réseaux d’overlay dans tout ça ?

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).

Quelles implémentations ?

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.

Nom Porteur Open Source Licence Spécialité
ONOS Open Networking Foundation oui Apache 2.0 Générique
Cilium Cilium oui Apache 2.0 + GPL v2.0 Conteneurs
Neutron OpenStack Foundation oui Apache 2.0 Générique
Calico Tigera oui Apache 2.0 Générique
OpenContrail Juniper oui Apache 2.0 Générique
Contiv Cisco oui Apache 2.0 Conteneurs
OVN Linux Foundation oui Apache 2.0 Générique
OpenDaylight Linux Foundation oui EPL 1.0 Générique
weave net weaveworks oui Apache 2.0 Conteneurs
Flannel CoreOS oui Apache 2.0 Conteneurs
ACI Cisco non Commerciale Virtualisation et bare metal
Midonet Midokura non Commerciale Générique
NSX VMWare non Commerciale Générique
NuageNetworks Nokia non Commerciale Générique

Conclusion

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.

Sources

OpenFlow specifications
Blog de Stéphane Bortzmeyer: RFC 7426
Blog de Stéphane Bortzmeyer: RFC 7419