Software Defined Network : la scalabilité des réseaux à travers l’automatisation

d2si_image_blog_SDN_automatisation_reseau
L’automatisation a changé la façon dont on gère l’infrastructure : des serveurs physiques installés manuellement dans des Datacenters, nous sommes passés au déploiement virtualisé. Puis, l’intervention humaine a été facilitée au maximum en automatisant chacune des actions nécessaires au déploiement.
Quelle est la prochaine étape ? Déjà initiée par les grands opérateurs télécom, c’est l’automatisation du réseau : faire en sorte de pouvoir gérer la scalabilité du réseau de façon automatisée.

Software Defined Network

Commençons par quelques éléments de définition. Le SDN, Software Defined Network, est une nouvelle approche dans la définition, la construction et la gestion de l’architecture réseau dans laquelle on sépare les couches d’administration, contrôle et transfert de données.  Le but est de rendre les équipements de la couche de transfert transparents pour l’administrateur, afin que celui-ci puisse agir à travers une console d’administration unique sur l’ensemble du système.  Les applications aussi doivent être en mesure de dialoguer, voire agir sur certains aspects du réseau, en passant justement par la couche de contrôle.  Le tout se fait via des API diverses, mais en essayant d’adhérer au maximum aux standards afin que la compatibilité soit la plus large possible. Parmi les protocoles les plus utilisés au sein d’une architecture SDN, citons OpenFlow, qui permet la communication entre un contrôleur et les équipements réseau, physiques ou virtuels.

On parle également de NFV (Network Functions Virtualization), ou VNF (Virtual Network Functions), qui est un réseau où tous les services peuvent être rendus via des solutions 100% logicielles, de façon à s’affranchir des dépendances du matériel, et donc de ne plus dépendre d’un ou plusieurs fabricants de matériel réseau.

Actuellement, tous les systèmes permettant de faire de la virtualisation embarquent déjà une couche réseau. C’est par exemple le cas de VMware, avec son vSwitch. Une fois que les éléments physiques sont installés, les couches de virtualisation permettant de déployer les VM sont ajoutées. Dans ces couches, une partie basique du réseau est déjà virtualisée : les couches 2 et 3, d’interconnexion et d’envoi des paquets. Mais ces solutions ne sont peut-être plus suffisantes pour gérer la complexité et l’hétérogénéité actuelles des infrastructures.

Pourquoi automatiser le réseau ?

En effet le Cloud et l’automatisation font que les applications et les services sont composés d’une multitude d’éléments, répartis en différents endroits : des VM ici, des BDD en premise, virtualisées ou non, des services externes adressés via une connexion dédiée, etc. De fait, il faut se poser la question de la scalabilité du réseau lors de sa construction. Cette scalabilité doit être gérée de façon automatisée, de la même façon que le reste des éléments : quand la création de VM est automatisée ou que la BDD évolue, comment s’assurer que le réseau suive ? De la même façon, si on déplace une application, jusque-là hébergée en premise, dans le cloud, comment s’assurer que l’opération soit transparente pour les utilisateurs et les applications qui en dependent ? Ou encore, dans le cas d’une application distribuée, comment gérer la qualité de service en fonction des différents types de connexion, et notamment prendre en compte les contraintes de latence et de performance des réseaux mobiles ? L’administrateur réseau n’ayant pas le temps de gérer l’ensemble de ces changements, il faut donc une solution pour contrôler l’ensemble des fonctions réseau pour les adapter aux besoins des applications.

 

Ce pourquoi il n’est plus possible de travailler comme cela a été fait jusqu’à aujourd’hui dans la grande majorité des entreprises. L’administrateur réseau ne peut plus se contenter de mettre à jour les tables de routages à la main en fonction de demandes métier, d’attendre un créneau d’heures creuses (le soir) pour compiler les nouvelles règles firewall ou passer sur 5 à 6 équipements réseau pour créer un nouveau VLAN, et le rendre visible à une nouvelle infrastructure applicative.

 

Les acteurs traditionnels proposent déjà des solutions d’administration centralisée, voire la possibilité d’automatiser un certain nombre d’actions, mais l’offre se limite très souvent aux équipement du même éditeur/fabricant. Il est par ailleurs très difficile, voire impossible de rendre ces solutions accessibles aux applications pour qu’elles puissent interagir avec, sans devenir un minimum dépendant de l’éditeur même.

 

Dans la logique SDN et l’architecture qui en découle, l’ensemble des éléments de la couche infra ainsi que leur configuration doivent être visibles, administrables et être gérables de façon programmatique, et cela afin que les applications et administrateurs puissent agir sur ces éléments de la manière la plus agile et scalable possible.

 

SDN Controller

D’où la notion de SDN Controllersoit une application (ou ensemble d’applications) utilisant des protocoles compatibles avec l’ensemble des équipements réseau (virtuels ou physiques) et capable de fournir les directives et informations concernant la gestion du trafic réseau et la sécurité. Le contrôleur se situe au milieu, dans la couche identifiée comme « Control Plane » ce qui va lui permettre de fédérer la communication et les actions envers les équipements d’infra (Data Plane) et les applications.

On constate deux types d’échanges au niveau des flux. Une communication « southbound » où le trafic émane du contrôleur vers les éléments de l’infrastructure réseau.  Un trafic « northbound » entre les contrôleur et les applications afin que ces dernières puissent agir sur le flux des données au sein du réseau. Le contrôleur doit s’appuyer sur les protocoles les plus ouverts possibles et standardisés pour dialoguer avec le réseau. Les décisions et actions pour la gestion de l’infrastructure réseau sont déportées au niveau des applications qui communiquent avec le contrôleur via des API ou des langages programmatiques.

 

D2SI_Blog_Image_sdn-framework

SDN Northbound API. Source : SDXCentral

Encore une fois le contrôleur, ou Control Plane, gère des connexions et un dialogue en aval avec le Data Plane (équipements réseau physiques ou virtuels), afin de faire les modifications nécessaires pour la bonne gestion du trafic, puis un dialogue en amont avec les applications, capables de lire les informations fournies par le contrôleur (ce qui se passe au niveau du réseau), pour prendre des décisions, faire des choix, et les communiquer au contrôleur. Prenons l’exemple d’une application de streaming vidéo : lors de la transmission d’un événement important générant un fort trafic, l’application doit pouvoir demander au contrôleur de prioriser ce trafic et le faire circuler au mieux de façon à ce que les utilisateurs ne perdent pas en fluidité et en qualité. Le contrôleur doit s’assurer que le trafic ne sera pas perturbé par un autre trafic moins important comme une sauvegarde système qui emprunterait le même réseau physique.

Les possibilités offertes par l’automatisation du réseau

Les éléments et l’architecture décrite ci-dessus offrent de vastes possibilités pour l’automatisation du réseau, par exemple dans le cas du déploiement d’une stack complète (serveur web, serveur applicatif, BDD…), où il faut gérer différents niveaux de sécurité comme les autorisations de dialogue avec la BDD ou la visibilité du serveur applicatif. Avec l’arrivée du DevOps et l’agilité dans de nombreuses équipes IT, tout va maintenant très vite et le réseau doit pouvoir suivre, y compris en termes de sécurité. La mise en place de firewalls, de VPN, l’autorisation des échanges entre services applicatifs…tout cela doit être géré de façon automatique. Ce type de services est déjà proposé par les acteurs du cloud comme AWS ou Azure, mais de nombreuses entreprises étant en cloud hybride ou privé, il faut que les administrateurs réseau soient capables d’en faire de même on premise.

Commentaires :

A lire également sur le sujet :