MERI-LL
Télécharger le fichier pdf d’un mémoire de fin d’études
Architectures des réseaux SDN
Au début des propositions autour du paradigme SDN, la plupart des travaux envis-ageaient seulement un contrôleur centralisé pour un domaine donné, ce qui conduisait à une sollicitation importante de la capacité de traitement du contrôleur et conduisait naturellement à des problèmes de mise à l’échelle.
Paradoxalement, une des propositions qui a surgi alors était le concept de contrôleur logiquement centralisé s’appuyant sur une certaine distribution physique de cette fonc-tion comparable à la distribution des fonctions dans les réseaux classiques.
Il est apparu aussi que la fonctionnalité de contrôleur devait être physiquement dis-tribuée pour permettre de gérer des réseaux à grande échelle.
Nous avons donc abordé cet état de l’art en classant les principales propositions d’architecture pour réaliser la centralisation et la distribution du contrôleur SDN. Nous avons aussi abordé les propositions visant à introduire une certaine dynamicité pour répondre aux variations du réseau.
En préambule, nous présentons le paradigme NFV chez les opérateurs TelCo dans lequel s’inscrivent les technologies SDN. En effet ce paradigme est devenu le contexte principal dans lequel les technologies SDN doivent être mises en œuvre chez les opéra-teurs.
Architectures virtualisées pour opérateurs Telco
L’idée générale de NFV est de mettre en œuvre des infrastructures composées de serveurs banalisés (Commercial Of The Shelf (COTS)) pour implémenter des fonctions réseaux hébergées dans des machines virtuelles sous forme de VNFs. Notre objectif n’est pas de présenter les différentes approches autour du paradigme NFV, mais simplement de mon-trer comment SDN, et en l’occurence OF et NFV peuvent s’articuler de manière complé-mentaire, en particulier:
• Le contrôleur réseau peut être virtualisé et hébergé sur des serveurs NFV, il peut donc s’agir d’une brique réseau virtuelle, d’une VNF,
• Le switch OF (OpenFlow Switch (SOF)) peut-être virtualisé comme par exemple avec Open-VSwitch, [PFAFF et collab., 2015],
• OF est généralement un moyen de déployer la connectivité dans une infrastructure virtualisée, à différents niveaux, à l’intérieur d’une machine virtuelle (Virtual Ma-chine (VM)), dans un serveur pour connecter des machines virtuelles et des Virtual Network Functions Components (VNF-C)s, à l’intérieur d’une VNF, d’un tenant, ou dans l’infrastructure d’hébergement,
• OF est un moyen de réaliser le chaînage de services pour composer des services réseaux en aiguillant les flux entre VNFs ou entre middleboxes virtualisées,
• La brique OF est très répandue dans les datacenters,
• La brique OF est présente dans le Virtual Infrastructure Manager (VIM) pour réaliser la connectivité entre les machines virtuelles, par exemple dans OpenStack,
• La brique OF permet de réaliser une connectivité dynamique et adaptative,
• OF permet de réaliser le concept de slices réseaux présent par exemple dans la 5G.
Sous certains aspects, le paradigme NFV a supplanté l’approche SDN (en partic-ulier OF) en répondant autrement à certains verrous techniques qui initialement étaient adressés par les deux approches. Par exemple, tandis que le SDN essayait de résoudre le verrou technique des middle-Boxes qui se multipliaient dans les infrastructures (fonc-tions DPI, firewall, NAT . . . ) en distribuant ces fonctions dans des SOFs améliorés couplés à des contrôleurs plus ou moins distribués, NFV propose plutôt de garder les middle-boxes en les virtualisant dans des datacenters, ce qui permet de résoudre les problèmes de coûts et d’évolutivité.
Dans le contexte NFV, le SDN est devenu essentiellement un moyen de gérer la con-nectivité et la ressource réseau au service de l’ensemble de l’infrastructure et est poten-tiellement utilisable dans différents blocs fonctionnels:
• dans des tenants ou des infrastructures virtuelles,
• au niveau de l’infrastructure physique elle même qui supporte les tenants,
• dans les VNFs pour relier des VNF-Cs,
• pour chaîner des VNFs et aiguiller les flux de manière à réaliser un service réseau complet.
Les différents blocs fonctionnels peuvent être vus comme organisant une architecture récursive ou hiérarchique de contrôleurs chargés de piloter les ressources réseaux dans les différentes couches [CHATRAS, 2015]. Une tentative d’illustration est présentée dans la figure 2.1. Dans la couche supérieure se trouvent les fonctions Operational Support System (OSS) et Business Support System (BSS) qui regroupent les fonctions supports et métiers de l’opérateur.
Il faut remarquer cependant que les deux approches SDN et NFV se complètent mais abordent les verrous techniques que constituent l’élasticité et la flexibilité de manière différente, l’une en centralisant les fonctions, l’autre en les virtualisant.
Architectures SDN physiquement centralisées et en clusters
L’organisation des contrôleurs en clusters est un moyen d’améliorer la fiabilité du réseau SDN et de résoudre le problème de défaillance d’un seul point centralisé dans les architec-tures SDN. La technologie qui organise les clusters est basée sur un processus électif d’un maître parmi des instances de contrôleurs partageant une base de données distribuée.
[JAIN et collab., 2013] ont présenté une implémentation concrète et effective d’OF dans le contexte industriel de la gestion du trafic interne entre les data-centers Google. Les motivations pour la mise en œuvre d’OF étaient principalement la facilité pour la mise en œuvre de nouveaux protocoles, des procédures de tests et de validation plus sim-ples, et enfin et surtout un objectif d’optimisation du trafic entre data-centers avec l’idée de réduire le surdimensionnement des liens par la mise en œuvre d’outils d’ingénierie de trafic.
Pour Google, chaque Data Center constitue un système autonome AS connecté au réseau internet. Ils sont quelques dizaines disséminés dans le monde et sont inter-connectés entre eux via le cœur de réseau B4 d’interconnexion. Ce réseau prend la forme d’un autre système autonome AS qui utilise traditionnellement les protocoles iBGP et IS-IS pour le routage. Dans cette architecture, les services de routage et d’ingénierie de trafic sont déployés de manières indépendantes afin d’assurer un fonctionnement minimal par des procédures de routage classique en cas de défection du serveur d’ingénierie de trafic. Le schéma 2.2 présente une vue de l’architecture globale.
Architectures SDN distribuées à plat et logiquement centralisées
Nous appelons architecture distribuée à plat, une architecture composée de contrôleurs physiquement distribués mais logiquement centralisés.
L’idée est, en distribuant les contrôleurs, de lever les inconvénients d’un seul con-trôleur physiquement centralisé tout en conservant les avantages que constituent le fait de disposer d’une vue globale du réseau et d’interagir globalement avec lui.
Les inconvénients d’un contrôleur centralisé sont nombreux. On peut souligner au moins trois aspects:
• Un contrôleur centralisé aura du mal à réagir à des évènements locaux réclamant des traitements locaux, de manière optimale. Il y a donc des compromis à établir entre centralisation et distribution des fonctions.
• Un contrôleur centralisé constitue un goulot d’étranglement, ce qui limite la mise en œuvre de services réseaux performants.
• Un contrôleur centralisé est un “single point of failure”.
D’un autre côté, une architecture de contrôleurs distribués introduit de nouveaux verrous techniques associés à la nécessité de garantir la cohérence des informations partagée par les contrôleurs afin de disposer d’une vue unique du réseau. Un protocole est-ouest est nécessaire pour gérer les échanges entre contrôleurs. De plus, le degré de distribution physique peut varier énormément suivant les approches.
[SCHMID et SUOMELA, 2013] analysent la problématique de la localité dans un réseau SDN en fonction des applications réseau mises en œuvre.
La proposition vise à montrer que dans un réseau SDN distribué, on peut souvent définir une composante locale pour les applications réseaux, voire réaliser un traitement purement local plutôt qu’adopter systématiquement une approche centralisée.
L’approche locale permet d’augmenter la réactivité. De plus il n’est pas toujours nécessaire de réaliser une optimisation globale. Enfin, les applications locales peuvent ensuite être coordonnées pour réaliser aussi des fonctions globales sur le modèle des ap-proches adoptées pour les algorithmes distribués.
Deux cas d’usage sont étudiés à titre d’exemple, un cas d’usage de calcul d’un span-ning tree et un cas d’usage d’établissement de connectivité client vers des serveurs. Ce type d’approche intéressante n’est pas exploitée aujourd’hui dans le contexte du SDN.
[LEVIN et collab., 2012] proposent d’analyser les verrous techniques liés à la distribu-tion des états inter-contrôleurs dans la mise en œuvre d’une architecture SDN distribuée à plat et logiquement centralisée.
L’implémentation d’applications réseaux de manière distribuée peut-être rendue im-possible ou infaisable si des incohérences surgissent dans les vues réseaux dont disposent les contrôleurs et peut générer des boucles et des erreurs de routage.
Les auteurs étudient donc d’une part, une stratégie qui privilégie le compromis en-tre les performances espérées de l’application réseau ciblée par rapport au surplus de trafic nécessaire pour distribuer les différents états de manière cohérente entre les dif-férents contrôleurs (strongly consistent). Ils étudient, d’autre part, une stratégie qui lim-ite le risque d’incohérences dans le partage de l’information (eventually consistent) en réduisant le surplus de trafic et qui privilégie la complexité de la logique applicative en la rendant capable de prendre en compte certains états du réseau. Le cas d’usage considéré est un load balancer.
[PANDA et collab., 2013a] abordent la question des contrôleurs dans des architectures SDN distribuées à plat, et logiquement centralisées du point de vue du théorème CAP (Consistency, Availability, Partition Tolerance), [GILBERT et LYNCH, 2012], utilisé dans les bases de données distribuées. Pour rappel, le théorème énonce que l’on ne peut réaliser simultanément les trois propriétés: cohérence atomique, disponibilité et tolérance au partitionnement. Dans le cas du réseau SDN et d’un plan de contrôle séparé (outband), les auteurs s’intéressent à trois propriétés présentées comme équivalentes:
• La propriété de disponibilité désigne le fait de pouvoir adresser un message à un SOF même en cas de partitionnement du réseau.
• La propriété de cohérence ou d’exactitude (correctness) désigne le fait de pouvoir implémenter correctement une politique réseau dans l’infrastructure réseau.
• la propriété de tolérance au partitionnement exprime le fait que le réseau doit rester fonctionnel même en cas de partitionnement notamment du réseau de contrôle du à une défaillance d’un nœud ou d’un lien.
A partir d’un modèle très simple de réseau SDN distribué équivalent à un système dis-tribué de transmission de messages asynchrones, les auteurs montrent que dans un réseau SDN, il n’est pas possible de réaliser simultanément ces trois propriétés mais seulement deux d’entre elles. Ils déclinent ensuite ces résultats sur 3 cas d’usage, un cas d’usage d’isolation, un cas d’usage de middle box et un cas d’usage d’ingénierie de trafic.
Ils en tirent ensuite quelques conclusions en terme d’implémentation. Le principal résultat est que si l’on tolère le partitionnement du réseau du fait de pannes, il n’est pas possible de garantir la fiabilité de la mise en œuvre des politiques réseaux.
[KOPONEN et collab., 2010] ont proposé ONIX qui nous semble la première véritable tentative d’architecture SDN distribuée sur réseaux hétérogènes (du WAN au datacenter).
Au-dessus du réseau lui-même se trouve l’infrastructure de connectivité pour organ-iser la communication entre les instances ONIX et les équipements sur la base d’un pro-tocole de routage standard. Les instances ONIX sont hébergées dans des serveurs.
Au-dessus d’ONIX se trouve comme dans une architecture SDN standard, la logique de contrôle des applications. La principale composante d’ONIX est la NIB (Network Infor-mation Base). La NIB est une base de données distribuée qui fournit des API Nord pour les applications et des API Sud pour le déploiement des services réseau. La NIB main-tient une vue actualisée du réseau disponible pour la logique applicative au niveau des différentes instances.
Les API sont conçues pour garantir l’accès atomique aux ressources et la synchroni-sation entre elles si nécessaire. Des éléments peuvent être agrégés et vus comme un seul pour fournir une vue plus simple aux autres instances ONIX.
C’est la logique de contrôle de l’application qui permet de garantir la cohérence. Elle utilise pour cela deux bases de données distribuées, l’une pour assurer une cohérence forte et qui assure la persistance de l’information et l’autre pour une cohérence plus faible qui garantit la disponibilité du service [PANDA et collab., 2013b]. La première base de don-nées stocke des informations durables comme la topologie du réseau, l’autre stocke des informations plus volatiles comme les métriques d’utilisation des liens. Les API fournies aux applications offrent le choix d’adopter un compromis et de privilégier soit des taux de mise à jour élevés et une bonne disponibilité, soit une cohérence plus forte et une meilleure persistance.
[TOOTOONCHIAN et GANJALI, 2010] présentent Hyperflow qui peut-être considérée comme une proposition de référence d’une architecture physiquement distribuée et logiquement centralisée. Les contrôleurs contrôlent différents domaines et sont inter-connectés entre eux par une interface est-ouest et via une base de données distribuée qui met à disposition différents canaux de communication pour mettre à jour les états des contrôleurs. Chaque contrôleur gère les SOFs qui lui sont connectés et intervient indi-rectement dans la gestion de l’ensemble du réseau.
L’architecture est illustrée avec des contrôleurs NOX [PALIWAL et collab., 2018] et des SOFs dans un environnement Mininet et une application de base de données distribuée au-dessus des contrôleurs pour synchroniser les vues réseau entre elles via un canal de contrôle utilisant un service de publication de messages. L’application de base de don-nées et de publication de messages permet grâce à ses propriétés intrinsèques de :
• garantir les événements qui doivent être délivrés à chaque contrôleur (en utilisant des modalités de stockage persistantes dans la base de données distribuée),
• fournir une propriété de résilience contre le partitionnement du réseau et les pannes (c’est-à-dire que le réseau continue d’être fonctionnel en cas de partition-nement et le redevient pleinement quand le partitionnement est résolu.
• minimiser le trafic entre les contrôleurs pour propager des événements vers les SOFs.
La résilience est garantie par la capacité de l’application à se resynchroniser après une défaillance du canal de publication/abonnement. Les configurations locales ou les re-quêtes vers les SOFs sont toujours gérées par les contrôleurs locaux en charge des SOFs correspondants.
L’ordre de grandeur donné pour maintenir la cohérence entre contrôleurs est d’environ 1000 événements par seconde. Cette limitation est principalement une limi-tation du canal de publication/abonnement de la base de données distribuée.
[PHEMIUS et collab., 2014] présentent une architecture distribuée à plat inter-domaines illustrée par un cas d’usage de perturbation de la topologie inter-domaines. Comme pour hyperflow, l’application distribuée s’exécute au-dessus de la couche des contrôleurs qui est composée cette fois-ci d’entités contrôleurs floodlight. Le proto-cole de communication inter-contrôleur est basé sur AMQP 1 et RabbitMQ [DOBBE-LAERE et SHEYKH ESMAILI, 2017] pour composer un système de bus de messages pub-lication/abonnement avec un AMQP client-serveur sur chaque contrôleur. Chaque con-trôleur met en place quatre agents chargés de la surveillance, de l’accessibilité, de la con-nectivité et de la réservation des ressources. Dans le cas d’utilisation présenté, les agents sont combinés pour reconfigurer dynamiquement le réseau en cas de surcharge des com-munications de contrôle afin d’adapter le trafic à un plan de contrôle aux caractéristiques variables en commutant par exemple le trafic vers une liaison alternative.
Architectures SDN hiérarchiques
Différents travaux proposent une architecture hiérarchique pour adresser le problème de la distribution des contrôleurs et pallier la complexité d’une architecture à plat. Le principe consiste à définir deux niveaux de hiérarchie : un niveau local responsable de la gestion d’un domaine et un niveau supérieur pour gérer la communication entre les contrôleurs locaux et disposer d’une vue globale. Les réseaux B2 et B4 de Google peuvent être vus ainsi, bien que le niveau le plus élevé ne relève que de l’ingénierie de trafic.
[HASSAS YEGANEH et GANJALI, 2012] proposent Kandoo, un ensemble organisé hiérar-chiquement de contrôleurs compatibles avec OF. Ils définissent une notion de con-trôleurs locaux gérant directement un ensemble de SOFs et un contrôleur racine qui bénéficie d’une vision globale du réseau.
Kandoo a l’avantage principal d’éviter la modification ou l’extension des SOFs.
Bien que le document présente des résultats impressionnants avec 90% des événe-ments traités par les contrôleurs locaux, il est à noter que le champ d’application de cette solution est limité aux environnements où les décisions locales sont prédominantes comme les data-centers.
[FU et collab., 2014] présentent Orion, un plan de contrôle hiérarchique hybride qui, comme Kandoo, divise le plan de contrôle en un plan de contrôle local et un plan de con-trôle global. Afin d’aborder les réseaux à grande échelle, ils introduisent la notion de sous-domaine, divisé en zones. Une des principales différences avec l’architecture de Kandoo réside dans le rôle de chaque plan de contrôle. Dans Orion, les contrôleurs locaux gèrent une zone entière et proposent une vue abstraite de leur zone à un contrôleur responsable de zone
Une autre différence avec Kandoo est la distribution intrinsèque des contrôleurs de domaine. Alors que Kandoo plaide pour un contrôleur global « logiquement » centralisé, Orion a conçu sa couche contrôleur de domaines avec plusieurs contrôleurs globaux qui interagissent pour la gestion inter-domaines via un protocole distribué.
[SANTOS et collab., 2014] proposent D-SDN avec l’idée d’un contrôleur responsable de la gestion d’un sous-domaine du réseau et en interaction avec un contrôleur maître. D-SDN donne un aperçu général d’un concept d’architecture D-SDN. Le document se concentre ensuite sur les questions de sécurité pour la délégation de contrôle entre le contrôleur principal et un contrôleur secondaire. La sécurité des communications entre les contrôleurs avec une hiérarchie à deux niveaux ainsi que leur tolérance aux pannes ont également été étudiées.
Architectures SDN flexibles et adaptatives
[DIXIT et collab., 2014] proposent une architecture distribuée à plat capable d’adapter dynamiquement les pools de contrôleurs et les SOFs associés aux conditions de charge du réseau.
Selon la charge du réseau, la fréquence des paquets envoyés aux contrôleurs varie et les contrôleurs peuvent être sous-chargés ou surchargés. En cas de variation de charge, les pools de contrôleurs peuvent être réduits ou augmentés, et les SOF réaffectés.
L’architecture à plat proposée repose sur une base de données distribuée qui assure une cohérence forte et une bonne communication entre les entités. Les contrôleurs four-nissent des informations de mesure de charge pour alimenter un module de décision sur l’interface nord des contrôleurs et pour gérer les décisions d’équilibrage de charge.
[SHAKSHUKI et collab., 2015] décrivent une architecture distribuée à plat flexible. La flexibilité est obtenue en utilisant des instances de contrôleurs virtuels qui peuvent être déployées à la demande sur du matériel COTS fonction des conditions réseaux. Les ré-sultats expérimentaux sont limités à la démonstration de l’intérêt d’une architecture dis-tribuée pour gérer des conditions de charges élevées du réseau, tandis que la propriété de flexibilité n’est pas réellement illustrée.
[TUNCER et collab., 2015] proposent une architecture de management et de contrôle distribuée d’un réseau SDN composées de Local Managers (LM) et de Local Controllers (LC) qui forment des plans de contrôle et de management logiques séparés.
Chaque LC est associé à un ou plusieurs LMs qui sont en charge de la logique dis-tribuée des applications réseaux.
L’architecture proposée permet de gérer des scénarios statiques ou dynamiques de gestion de réseaux. Le déploiement et le placement des LCs et des LMs dépend de la topologie réseau ou du type d’applications supportées et aussi du degré de distribution recherché. Un module de management central est en charge des opérations de manage-ment à long terme tout en agrégeant des informations provenant des LCs et des LMs et dispose en particulier d’une vue globale du réseau.
Un LM est constitué d’un module de monitoring, d’un module de management des applications et d’un orchestrateur d’applications. Un LC est constitué d’un module de stockage qui permet de stocker des structures de données locales, d’un module de plani-fication et d’un module d’exécution. Un algorithme de placement des LCs est également présenté. Il est décrit dans la section de l’état de l’art concernant le placement des contrôleurs en 2.3.1. Enfin deux cas d’usage d’applications réseaux sont illustrés de manière théorique: un cas d’usage de load balancing et un cas d’usage d’ingénierie de trafic.
Data Planes programmables
Comme nous l’avons mentionné, OF présente des limitations intrinsèques. Il y a des in-convénients significatifs à déplacer toute la logique de contrôle au niveau d’un point cen-tral avec la mise en œuvre de contrôleurs centralisés. Prendre toutes les décisions sur un point distant introduit des problèmes de délais de réaction et aussi des problèmes d’évolutivité des services.
Pour optimiser le fonctionnement d’OF, différentes architectures, distribuées, hiérar-chique et même dynamiques ont été suggérées. Globalement, ces solutions ambitieuses héritent des défauts d’OF: trop de centralisations, des fonctionnalités réduites dues à l’absence de programmabilité du nœud réseau. La fourniture de services réseaux à la demande reste donc difficile à mettre en œuvre et la mise en œuvre de décisions locales est limitée.
L’idée d’enrichir les SOFs, dépourvus d’intelligence, avec un traitement des flux via une machine à états, a été aussi proposée par exemple par [BIANCHI et collab., 2014]. Cela permet d’enrichir le spectre des fonctionnalités au niveau du SOF. Cependant, même si le concept généralise le système des règles SOF et décharge le contrôleur central, le type de fonctions supportées reste limité à des fonctions assez simples.
Pour aller plus loin dans la complexité et la programmabilité des fonctions support-ées localement, diverses contributions proposent de construire un plan de données pro-grammable.
[BOSSHART et collab., 2014] ont proposé le langage P4 pour accroître la flexibilité d’OF. P4, permet de créer des plugins, qui peuvent être compilés dans un SOF reconfigurable en terme de protocole de contrôle.
L’idée générale est que plutôt que d’enrichir à l’infini le protocole OF, il est préférable d’introduire une flexibilité dans la programmation du SOF de manière à réinterpréter les messages du protocole. Une illustration est donnée avec le diagramme 2.4. Le switch est conçu et structuré pour accueillir des protocoles variés qui sont déterminés par program-mation.
|
Table des matières
Liste des tableaux
1 Introduction générale
1.1 Introduction
1.2 Motivations
1.3 Contributions de la thèse
1.4 Organisation du manuscrit
2 Etat de l’art
2.1 Introduction
2.2 Architectures des réseaux SDN
2.3 Placement de services réseaux
2.4 Algorithmes évolutionnaires
3 Propositions pour une architecture SDN flexible et distribuée
3.1 Introduction
3.2 DICES, Une architecture SDN orientée services
3.3 Un plan de contrôle SDN étendu et flexible
3.4 Conclusion
4 Placement de services réseaux dans une infrastructure SDN & NFV
4.1 Introduction
4.2 Algorithmes de référence pour le placement
4.3 Regroupement hiérarchique basé sur la latence et la charge
4.4 Placement de contrôleurs avec un algorithme évolutionnaire
4.5 Placement de chaînes de VNFs avec un algorithme évolutionnaire
4.6 Conclusion sur le placement de services réseaux
5 Conclusion et perspectives
5.1 Conclusion
5.2 Perspectives
A Annexes III
A.1 Notions théoriques sur la connectivité
Télécharger le rapport complet
