Vous êtes sur la page 1sur 59

Université de Kinshasa

Faculté des Sciences

Département des Mathématiques et Informatique


B.P.190 KINSHASA XI

MISE EN PLACE D’UNE SOLUTION SDN POUR LA


GESTION DU RESEAU :
« Application de Gestion de Load-Balancing »

Rédigé par :
MUKADI NTUMBA Chaco

Mémoire présenté et défendu en vue de


l’obtention du titre de Licencié en
Sciences.

Groupe : Informatique
Option : Gestion

Directeur
Professeur MBUYI MUKENDI Eugène

Année universitaire 2017-2018


ii

Epigraphe

« (…) Et les gagnants seront ceux qui arriveront à restructurer la


manière dont l’information circule au sein de leurs
organisations »

William Henry Bill Gates

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


iii

Dédicace
Je dédie ce modeste travail aux êtres les plus chers de ma vie :

-A mes très chers parents, André MUKADI et Théthé TSHIBOLA qui ont attendu, et espérer
ma réussite, ont toujours veillé sur moi avec beaucoup d’amour et de patience,

-A mes très chers frères et sœurs, Raphael, Lydie, Anne, Christian, Aimée, Divine, Grace.

- A tous ceux qui me sont chers et proche.

- A tous ceux qui ont semé en moi à tout point de vue

- A tous ceux que j’aime et ceux qui m’aiment.

- A tous ceux qui me connaissent de prêt ou de loin

Je dédie ce travail.

Toutes ces valeurs m’ont donné confiance et espoir pour continuer les études et pour
préparer ce travail.

Chaco MUKADI NTUMBA

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


iv

Remerciements

Je tiens à remercie le Dieu tout puissant de m’avoir accordé la santé et la volonté pour
accomplir ce travail.

Je tiens à remercier : tous ceux qui de près ou de loin, ont contribué à l’élaboration de ce
modeste travail.

Mes remerciements s’adressent essentiellement à mon directeur le professeur MBUYI


MUKENDI pour sa disponibilité et orientations.

Mes remerciements aussi à mon co-directeur le chef des travaux KABAMBA Richard pour
son encadrement et à Mr. Jean Claude MUDILU.

Je remercie également tout le personnel de l’entreprise Tendaji-Technologies;

Mon chef Renato NSUMBU et sans oublier Mr BOHARI Souleymane qui m’ont soutenu
énormément par des explications et des tests du logiciels.
Je remercie mes amis et proches de lutte, notamment : Edouard TSHONGA et Christian
MAZAMBA

Je remercie toutes les personnes qui, d’une quelconque manière, m’ont apporté leur amitié,
leur attention, leurs encouragements, leur appui et leur assistance pour que je puisse mener à
terme ce travail : Nathan NGALAMULUME, Yves KATANGA, Kelvi KANGA, Isaac NZOVU,
Josué NZABA, Grazzy MAYAMBALA, Olivia MABULU, Clarisse NTUMBA et Isaac
MUZIGWA

Je suis honoré par la présence de membres du jury d’avoir accepté ce Travail en espérant
qu’ils trouveront dans ce projet de quoi être satisfait.

Et auront la gratitude de l’enrichir avec leurs critiques et correct.

Que tous trouvent ici l’expression de ma franche et profonde reconnaissance !

Chaco MUKADI NTUMBA

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


v

Liste des Abréviations et Acronymes

API : Application Programming Interface


ASIC : Application Specific Integrated Circuit
CLI : Command Line Interface
HP : Hewlett Packard
HTTP : HyperText Transfer Protocol
Iaas : Infrastructure as a Service
IP : Internet Protocol
JDK : Java Development Kit
KVM : Kernel-based Virtual Machine
NAT : Network Address Translation
NIST : National Institute of Standards and Technology
ONF : Open Networking Foundation
OSI : Open Systems Interconnection
PaaS : Platform as a Service
QoS : Qualité de Service
RDP : Remote Desktop Protocol
SaaS : Software as a Service
SDN : Software Defined Network
TCP : Transmission Control Protocol
TLS : Transport Layer Security

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


vi

Liste des Figures

Figure I.1 : Architecture Réseau classique………………………..…………………...8


Figure I.2 : La virtualisation des systèmes………………………………….………......9
Figure I.3 : Informatique du Nuage……………………………………………...........12
Figure II.1 : Architecture SDN……………………………………………...……………16
Figure II.2 : Réseau traditionnel et SDN….……………………………...……………16
Figure II.3 : Diagramme de flux des messages OpenFlow………...………….......20
Figure II.4 : Table de flux des messages OpenFlow……………………...………....21
Figure II.5 : Schématisation d’un modèle de flux OpenFlow…………..…………21
Figure III.1 : Schéma d’un réseau SDN simple……………………….…………..…..30
Figure III.2 : Différents types de topologie réseau.………………………….….…..32
Figure IV.1 : Architecture de l’application…………………………………..…….…36
Figure IV.2 : Topologie du scénario…………………………………………..……..…41
Figure IV.3 : Fichier topomemo.py…………………………………………………….42
Figure IV.4 : Topologie du lancement de topomemo.py……………………...…43
Figure IV.5 : Exécution de la commande Help………..……………………...….…43
Figure IV.6 : Sortie des commandes net et dump……...…………………………..44
Figure IV.7 : Démarrage de l’équilibreur de charge et des servers………...…..45
Figure IV.8 : Démarrage des servers……………………………………………….….45
Figure IV.9 : Affichage des requêtes au niveau des serveurs……………… . ….45
Figure IV.10 : Requêtes des 3 premiers clients………………………………….…...46
Figure IV.11 : Requêtes des 3 derniers clients…………………………… ……..…..47

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


vii

Liste des Tableaux

Tableau II.1 : Résumer des caractéristiques des contrôleurs…………………..…27

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


1

0. INTRODUCTION GENERALE

Avec l’avènement des innovations technologiques récentes


telles que la virtualisation des systèmes, le cloud computing et le Big
Data, les limites actuelles des architectures réseaux deviennent de plus
en plus problématiques pour les opérateurs et les administrateurs
réseaux.

Durant ces dernières années, les réseaux informatiques


classiques ont connu de grands défis qui résultent principalement des
applications modernes déployées sur ces réseaux.

En effet, l’apparition du Big Data qui nécessite un traitement


distribué et l’adoption de l’infonuagique par plusieurs entreprises ont
induit le besoin d’avoir des réseaux dynamiques qui offrent la possibilité
de s’adapter rapidement aux changements des requis.

À titre d’exemple, les usagers de l’infonuagique peuvent


demander de nouvelles ressources selon leurs besoins et peuvent
changer les politiques de gestion (exp : liste de contrôle d’accès,
bande passante...) des infrastructures allouées. Dans d’autres mesures,
les infrastructures de calcul et stockage distribués des données massives
(Big Data) peuvent évoluer rapidement en adoptant de nouveaux
clusters qui peuvent contenir des milliers de serveurs et de
commutateurs.

Ces évolutions nécessitent généralement une mise à jour


des infrastructures concernées. Toutefois, la mise à jour des réseaux
classiques (ou traditionnels) est réalisée en configurant manuellement
chaque équipement ce qui peut produire plusieurs erreurs et
incohérences. De plus, ces configurations prennent beaucoup de
temps ce qui ne permet pas de faire face à l’expansion rapide du
monde des technologies d’information.

C’est dans ce contexte qu’est apparu le paradigme des


réseaux définis par logiciels en acronyme (SDN) qui permet
principalement de s’adapter à la nature dynamique des applications
susmentionnées.

En effet, SDN permet principalement de centraliser la


logique déterminant les politiques de gestion d’un réseau dans une ou
plusieurs unités appelées contrôleurs. Ces contrôleurs communiquent
avec le reste des équipements du réseau via des interfaces ouvertes.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


2

De ce fait, la définition d’une politique de gestion d’un


réseau revient à écrire des programmes et les déployer dans les
contrôleurs. Dans la plupart des cas, ces programmes seront compilés,
en tenant compte de la topologie et des ressources disponibles, afin de
générer les configurations nécessaires à chaque équipement du réseau
pour mettre en œuvre les politiques désirées.

L’architecture SDN a été adoptée par plusieurs grandes


entreprises et universités à savoir, Google et Stanford. D’autre part, les
fabricants des équipements pour les réseaux tels que Cisco, HP et
Juniper offrent désormais des solutions SDN qui permettent de gérer les
centres de données.

Dans le cadre de ce travail, nous comparons les


caractéristiques des différents contrôleurs utilisés dans la mise en place
d’un réseau défini par les logiciels. Notamment, Pox, Nox, Floodlight et
Opendaylight. Au terme des analyses, les résultats prouvent l’efficacité
du contrôleur POX.

En vue de concilier la théorie à la pratique, nous avons


également développé une application de gestion de LOAD
BALANCING (Répartition de Charge) dans un environnement SDN.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


3

0.1 PROBLEMATIQUE

Depuis des années, il est communément admis que les


architectures IP traditionnelles présentent, d’une part, particularité
complexes dans sa configuration, à cause de la nature distribuée des
protocoles réseaux et, d’autre part, la difficulté à son évolution, en
raison du fort couplage qui existe entre le plan de contrôle et le plan
de données des équipements d’interconnexion existants. Ce qui
engendre des contraintes importantes sur le déploiement des
applications réseaux.

Pour pallier à cette instabilité, l’intégration des


fonctionnalités relatives à l’interopérabilité des composants devient un
préalable de la conception d’infrastructures réseau.

Les principaux domaines d’innovation au cours des


dernières années sont à chercher du côté du contrôle centralisé, de la
programmabilité, et de la virtualisation. Ces innovations sont
regroupées sous l’appellation commune de SDN (ou software-defined
network) et visent à résoudre les problèmes que les entreprises
rencontrent avec leurs réseaux en leur fournissant une solution de
gestion (soit des Vlans, des Serveurs, etc) centralisée au niveau d’un
contrôleur.

Notre préoccupation se résumera au tour des questions


suivantes :

-En quoi le SDN est-il une meilleure solution pour la gestion actuelle du
réseau ?
-En quoi la répartition de charge dans un SDN est-elle meilleure que
dans un réseau traditionnel (ou classique) ?

0.2 HYPOTHESES DU TRAVAIL

Une hypothèse est selon le dictionnaire Robert Méthodique,


une proposition relative à l’expression des phénomènes naturels et qui
doit être vérifié par des faits.

A ces préoccupations exprimées sous forme des questions


au niveau de la problématique, nous avons proposé la mise en place
d’une solution SDN pour la gestion des réseaux en mettant en place
une application de répartition de charge qui serait une solution pour la
gestion des serveurs et assurer la haute disponibilité sans interruption
des services au niveau des serveurs.
Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.
4

0.3 CHOIX ET INTERET DU SUJET


0.3.1 CHOIX

Il convient de souligner que le choix d’un sujet est fonction


de plusieurs facteurs notamment les motivations personnelles, les
enseignements reçus et la filière choisie.

Cependant notre choix est poussé par le souci de savoir


comment mettre en place une solution SDN et répartir les charges au
sein d’un réseau définis par le logiciel.

0.3.2 INTERET

En sus des différentes motivations qui nous ont poussés à


exploiter des solutions, ce travail vise également à des personnels et
collectifs. Personnel, dans la mesure où nous serons le premier à le
capitaliser, et collectif puisqu’il révèle un caractère à profiter à
l’ensemble de la société. Ces intérêts sont notamment :
- Montrer l’importance actuelle du réseau définis par le logiciel
pour la gestion actuelle du réseau.

- Déterminer les points essentiels en montrant les outils et la


procédure à suivre pour mettre en place un réseau définis par le
logiciel.

- Montrer le rôle et l’importance de Load-Balancing (répartition des


charges) dans un réseau définis par le logiciel.

0.4 DELIMITATION DU SUJET

Selon Madeleine GRAWITZ, « Limiter son sujet, c’est


déterminer ce que l’on retient mais c’est aussi d’écarter un certain
nombre de problème ».
Pour mieux mener un travail de recherche, il faut qu’il soit
limité dans le temps, dans l’espace et dans le domaine.
La mise en place d’une solution SDN (software defined
network) pour la gestion du réseau, application du Load-Balancing
(répartiteur des charges).
En ce qui concerne notre travail, nous nous sommes limité
dans le temps et dans l’espace, étant donné que nous n’avions pas de

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


5

temps ni de moyens matériels suffisants pour effectuer une étude


couvrant toutes les fonctionnalités du Réseau définis par le logiciel
(Software defined network-SDN).
Nous nous sommes limités seulement au Load-Balancing qui
est une répartition des charges.
Du point de vue temporel, ce travail est effectué d’une
période allant de Février 2018 et Avril 2019.
Du point de vue spatial, nous nous sommes limités à parler
uniquement d’une fonctionnalité du réseau définis par le logiciel, SDN
en sigle qui est la gestion de Load-Balancing.

0.5 DIFFICULTES RENCONTREES

En effectuant nos recherches pour l’élaboration de notre travail de fin


d’étude, nous nous sommes buté à certaines difficultés :

- La recherche documentaire a été compliquée car nous n’avons


pas pu avoir des documents suffisant pour l’enrichissement de ce
sujet. Cela se justifie par le manque des moyens suffisants pour
l’accession à des bibliothèques dans des conditions normales ;

- L’auto formation des nouveaux cours et logiciels non familier.

0.6 SUBDIVISION DU TRAVAIL

Hormis l’introduction et la conclusion générale, ce présent


travail est organisé en quatre chapitres qui sont subdivisé en deux
parties.

La première partie, L’état des technologies de réseaux, qui


comprend deux chapitres. Ces chapitres, Fonctionnement des bases
de réseaux informatique et Réseau programmable : SDN, présentent
respectivement un aperçu sur les technologies actuelles des réseaux et
les détails relatifs à la technologie du SDN.

S’agissant de la seconde partie, Mise en place d’une


solution SDN, elle comprend le troisième et quatrième chapitre. Ces
derniers sont organisés comme suit : Le contrôleur SDN : POX, pour le
troisième chapitre dans lequel les différentes démarches à suivre pour
déployer un réseau SDN avec contrôleur POX sont abordées, et
l’Implémentation d’une application SDN : gestion de LOAD-BALANCING
comme quatrième chapitre, qualifié comme pratique.
Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.
6

PARTIE I :

L’ETAT DES TECHNOLOGIES DE RESEAUX

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


7

CHAPITRE I : FONCTIONNEMENT DE BASE DE


RESEAUX INFORMATIQUE
[1] [6] [10]

I.1 INTRODUCTION

Vu le cout d’exploitation des réseaux à grande échelle,


c’est ce qui continue à pousser aux fournisseurs des services de toujours
rechercher d’autres moyens pour réduire leur capital et les couts
opérationnels.

Ceci s’explique par l’explosion des différentes technologies,


tel que la virtualisation des serveurs, du stockage, ou encore des postes
de travail et l'apparition de l'informatique en nuage, mais avec toutes
ces innovations, nous rencontrons toujours les problèmes de
l’incapacité à faire évoluer les réseaux physiques aussi vite que les
montées en charge, ou encore une limitation dans le déploiement
automatique des ressources dans des environnements multi-clients.

Ce premier chapitre défini d’abord le réseau ensuite


présente l’architecture du réseau classique ainsi que les technologies
des réseaux utilisées actuellement tel que l'informatique en nuage, la
virtualisation, le cloud et le besoin du réseau programmable.

I.2 DEFINITION DU RESEAU

Un réseau est principalement défini par un ensemble


d’équipements qui sont connectés entre eux par des liens. Chaque lien
du réseau permet de passer une quantité spécifique de donnée
pendant une période bien définie.

I.3 ARCHITECTURE DU RESEAU CLASSIQUE

Le schéma ci-dessous décrit l’Etat de l’Art actuel d’une


architecture Réseau. Chaque nœud du réseau (Switch, Routeur) est un
boitier propriétaire. Il intègre deux fonctions (plans) principales : la
fonction Control (plan de contrôle) et la fonction Data Plane (plan de
données).

 Le plan de Control est l’intelligence du boitier, il lui permet de


déterminer les destinations que les paquets doivent atteindre. En
quelque sorte le plan de contrôle permet de prendre les décisions
de transmission.
Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.
8

Il comprend des mécanismes de transmission d'itinéraire de


couche 2 et 3, notamment la table de voisinage et la table
topologique (protocole de routage), la table de routage, etc.

 Le plan de données est la capacité de traitement du boitier, il lui


permet de faire transiter les paquets à très grande vitesse vers leur
destinataire. Le plan de données de chaque périphérique permet
de transmettre les flux de trafic. Les routeurs et les commutateurs
utilisent les informations du plan de contrôle pour transmettre le
trafic entrant vers l'interface de sortie appropriée.

Figure I.1: Architecture Réseau « classique »

Le point essentiel est que les applications ne dialoguent pas


avec le réseau, une médiation humaine est nécessaire.

I.4 LA VIRTUALISATION

La virtualisation est un ensemble de techniques matérielles


et/ou logicielles qui permettent de faire fonctionner sur une même
machine, plusieurs systèmes d’exploitation et/ou plusieurs applications,
séparément les uns des autres, comme s’ils fonctionnaient sur des
machines physiques distinctes.

On parle de :
Machine hôte = machine exécutant les différents systèmes
virtuels.

Machine invitée = machine virtuelle s'exécutant dans


l'environnement de virtualisation.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


9

La virtualisation dépasse ces limites en permettant


d’exécuter simultanément plusieurs systèmes d’exploitation et plusieurs
applications sur le même ordinateur, ce qui accroît l’utilisation et la
flexibilité du matériel.

Ce concept couvre différents aspects, on peut ainsi


virtualiser les serveurs, le stockage, les applications (simplification de
l'administration) ou encore le poste client.

Figure I.2 : La virtualisation des systèmes

A ce stade, la virtualisation et l'informatique en nuage, ces


deux sujets vont de pair, les avantages de la virtualisation prennent tout
leur sens à l'échelle de l'informatique en nuage.

I.5 LE CLOUD COMPUTING (L’INFORMATIQUE EN NUAGE)

I.5.1 Définition

L’informatique en nuage ou Cloud Computing est un


concept où les ressources informatiques sont virtualisées et
dynamiquement élastiques (provisionnement et déprovisionnement
automatique).

Ces ressources sont fournies comme un service à travers


Internet, de manière transparente pour les utilisateurs.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


10

I.5.2 Modèles de services

Les services cloud sont disponibles sous diverses options,


selon les besoins des clients. Dans la publication spéciale 800-145, le
NIST (National Institute of Standards and Technology) définit les
trois principaux services cloud suivants : Software as a
Service (SaaS), Platform as a Service (PaaS), Infrastructure as a
Service (IaaS).

Ces trois modèles de service doivent être déployés sur des


infrastructures qui possèdent les cinq caractéristiques essentielles citées
plus bas pour être considérées comme du Cloud Computing.

I.5.2.1 Software as a Service (SaaS) : Logiciel en tant que Service

Les applications sont mises à la disposition des utilisateurs via


le web. Ce modèle de service est caractérisé par l’utilisation d’une
application partagée qui fonctionne sur une infrastructure Cloud.

L’utilisateur accède à l’application par le réseau au travers


de divers types de terminaux (souvent via un navigateur web).
L’administrateur de l’application ne gère pas et ne contrôle pas
l’infrastructure sous-jacente (réseaux, serveurs, applications, stockage).
Il ne contrôle pas les fonctions de l’application à l’exception d’un
paramétrage de quelques fonctions utilisateurs limitées.

I.5.2.2 Platform as a Service (PaaS) : Plate-forme en tant que Service

Représente les outils et les services utilisés pour fournir les


applications.

L’utilisateur a la possibilité de créer et de déployer sur une


infrastructure Cloud PaaS ses propres applications en utilisant les
langages et les outils du fournisseur. L’utilisateur ne gère pas ou ne
contrôle pas l’infrastructure Cloud sous-jacente (réseaux, serveurs,
stockage) mais l’utilisateur contrôle l’application déployée et sa
configuration.

I.5.2.3 Infrastructure as a Service (IaaS) : Infrastructure en tant que Service

Représente le matériel et les logiciels utilisés pour les


serveurs, le stockage, les réseaux et les systèmes d’exploitation.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


11

L’utilisateur loue des moyens de calcul et de stockage, des


capacités réseau et d’autres ressources indispensables (partage de
charge, pare-feu, cache).

L’utilisateur a la possibilité de déployer n’importe quel type


de logiciel incluant les systèmes d’exploitation.

L’utilisateur ne gère pas ou ne contrôle pas l’infrastructure


Cloud sous-jacente mais il a le contrôle sur les systèmes d’exploitation,
le stockage et les applications. Il peut aussi choisir les caractéristiques
principales des équipements réseau comme le partage de charge, les
pare-feu, etc.

I.5.3 Caractéristiques du cloud

Le cloud présente les caractéristiques suivantes :

 Self-service à la demande (Accès aux services par l’utilisateur à la


demande): un utilisateur peut allouer des ressources sans interaction
humaine avec le fournisseur.

 Accès réseau élargi (Accès réseau large bande): les ressources sont
accessibles via le réseau par des systèmes hétérogènes (clients
légers, clients lourds, etc.).

 Partage de ressources (Réservoir de ressources (non localisées)): les


ressources sont dynamiquement affectées, libérées puis réaffectées
à différents utilisateurs. L'utilisateur n'a pas besoin de connaître la
localisation (pays, région, centre de donnée) des ressources.

 Élasticité (Redimensionnement rapide): La mise en ligne d’une


nouvelle instance d’un serveur est réalisée en quelques minutes,
l’arrêt et le redémarrage en quelques secondes. Toutes ces
opérations peuvent s’effectuer automatiquement par des scripts. Ces
mécanismes de gestion permettent de bénéficier pleinement de la
facturation à l’usage en adaptant la puissance de calcul au trafic
instantané.

 Facturation à l’usage: Il n’y a généralement pas de coût de mise en


service (c’est l’utilisateur qui réalise les opérations).

La facturation est calculée en fonction de la durée et de la quantité de


ressources utilisées. Une unité de traitement stoppée n’est pas facturée.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


12

Figure I.3 : Informatique du Nuage

I.6 UN BESOIN DU RESEAU PROGRAMMABLE

Dans l’architecture du réseau classique présenté ci-haut,


nous avons pu voir que les applications ne dialoguent pas avec le
réseau, une médiation humaine est nécessaire.

Dans ces conditions, le Réseau devient le maillon faible des


infrastructures IT. L’intervention humaine pour sa programmation fait
perdre un temps précieux, sans compter les risques d’erreurs. Ajouter à
cela que l’homme ne peut évidemment pas être aussi réactif qu’une
machine pour gérer les montées en charge soudaines.

Alors, avec toutes ces difficultés, ça nous montrent qu'il faut


trouver une solution d'automatisation adaptée aux défis de réseau,
c'est le réseau programmable.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


13

I.7 CONCLUSION

Pour cela nous nous posons cette question : Est-ce que


l'informatique en nuage, la virtualisation et le cloud computing
résolvent toutes les problématiques? Non, car il reste la problématique
d'appliquer des règles réseau, d’où la sécurité n’est qu'un aspect parmi
d’autres, notamment des règles de QoS, de routage et de load-
balancing. C’est pourquoi le marché planche sur SDN.

Alors dans le chapitre suivant, nous discuterons en premier


lieu sur la technologie SDN, puis nous traiteront les différents
composants d'un réseau SDN.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


14

CHAPITRE II : LE RESEAU PROGRMMABLE : SDN


[1] [2] [3] [4] [5] [7] [8] [9] [15] [16]

II.1 INTRODUCTION

Les infrastructures réseau courantes utilisent généralement


des équipements (commutateurs, routeurs. . .) dont la configuration
dépend des fabricants. Une fois déployées, il s’avère difficile de faire
évoluer ces infrastructures en adoptant de nouveaux protocoles ou en
ajoutant et supprimant des équipements.

De ce fait émerge l’idée des réseaux définis par logiciels


(SDN).

L’idée de SDN est de rendre le réseau programmable, c’est-


à-dire de permettre aux applications d’interagir directement avec les
réseaux, avec une coopération à double sens : l’application informe le
réseau du comportement désiré, le réseau informe les applications de
ses capacités. Le tout permettant d’établir un service avec des
conditions définies a priori.

Par conséquent, SDN sépare le plan de données et le plan


de contrôle. Le plan de données définit les équipements du réseau et
les connexions entre eux tandis que le plan de contrôle définit le
comportement de ce réseau.

II.2 DEFINITION

SDN signifie littéralement Software Defined Networking,


c’est-à-dire le réseau défini par logiciel. On comprend donc
immédiatement que le sujet est vaste et qu’il va être difficile d’avoir
une définition unique.

Le SDN désigne, comme son nom l’indique, le fait de piloter


une infrastructure réseau par un logiciel.

Autrement nous pouvons définir le SDN comme une


architecture qui découplait les fonctions de contrôle et de transfert des
données du réseau afin d’avoir une infrastructure physique
complètement exempte de tout service réseau.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


15

Dans ce modèle, les équipements réseau se contentent


d’implémenter des règles, injectées par les applications, de traitement
des flux de données.

Plus besoin d’avoir sur ces équipements de protocoles de


routage : une entité intelligente, appelée « contrôleur » voit le réseau
dans sa globalité et injecte directement les règles de traitement des
données sur chaque équipement.

Le SDN est donc reconnue aujourd’hui comme une


architecture permettant d’ouvrir le réseau aux applications. Cela
intègre les deux volets suivants :

 Permettre aux applications de programmer le réseau afin d’en


accélérer le déploiement ;

 Permettre au réseau de mieux identifier les applications


transportées pour mieux les gérer (qualité de service, sécurité,
ingénierie de trafic...).

II. 3 ARCHITECTURE

La Figure II.1 présente une vue logique de l’architecture


typique d’un réseau SDN.

- La couche « Plan de données » est composée principalement des


équipements d’acheminement (commutateurs, routeurs...).

- La couche « Plan de contrôle » est constituée principalement d’un


contrôleur SDN qui permet d’héberger la logique de contrôle du
réseau. Ce contrôleur met en œuvre cette logique en accédant
au plan des données à travers une interface unifiée appelée
‘south-bound’.

- D’autre part, la couche « Application » représente les


programmes qui définissent la logique de contrôle du réseau. Ces
programmes sont construits moyennant une interface de
programmation appelée ‘north-bound’ et offerte par le
contrôleur. Une application de contrôle pourrait, par exemple,
définir la politique de routage ou la façon de gérer la qualité de
service (QOS) dans un réseau SDN.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


16

Figure II.1 : Architecture SDN

Ci-dessous une figure comparative entre le réseau


traditionnel et le SDN :

Figure II.2 : Réseau traditionnel et SDN

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


17

II. 4 AVANTAGES

Offrant un réseau qui peut dynamiquement s'adapter afin


de répondre aux divers besoins des entreprises et la centralisation du
plan de contôle, SDN fournit également les avantages suivants:

II.4.1 Réduction des dépenses d'investissement

SDN limite potentiellement la nécessité d'acheter des


équipements hardware (matériels) réseau basés sur des ASICs via un
modèle « pay-as-you-grow » (payer à la croissance).

II.4.2 Réseaux programmables

Avec SDN, il est plus simple de modifier les stratégies réseau


car il suffit de changer une politique de haut niveau et non de multiples
règles dans divers équipements de réseau.

De plus, la centralisation de la logique dans un tel contrôleur


entièrement personnalisé avec des connaissances globales et une
puissance de calcul élevée, simplifient le développement des fonctions
plus sophistiquées. Cette aptitude à programmer le réseau est l'élément
clé du SDN.

II.4.3 Livrer agilité et la flexibilité

SDN aide les organisations à déployer rapidement de


nouvelles applications, les services et l'infrastructure de répondre
rapidement à l'évolution des objectifs et objectifs d'affaires.

Il apporte également une grande flexibilité dans la gestion


du réseau. Il devient facile de rediriger le trafic, d'inspecter des flux
particuliers, de tester de nouvelles stratégies ou de découvrir des flux
inattendus.

II.4.4 Routage

SDN peut également être utilisé pour gérer les informations


de routage de manière centralisée en déléguant le routage et en
utilisant une interface pour le contrôleur.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


18

II.4.5 Politique unifiée

Avec son contrôleur, SDN garantit également un politique


réseau unifié et à jour, puisque le contrôleur est responsable de l'ajout
de règles dans les commutateurs, il n'y a aucun risque qu'un
administrateur de réseau ait oublié un commutateur ou installé des
règles incohérentes entre les dispositifs.

En effet, l'administrateur va simplement spécifier une


nouvelle règle et le contrôleur adaptera la configuration pour envoyer
des règles cohérentes dans chaque dispositif pertinent.

II.4.6 Simplification matérielle

SDN a tendance d'utiliser des technologies standard et de


base pour contrôler les équipements du réseau, tandis que la puissance
de calcul n'est requise qu'au niveau du contrôleur. Ainsi, les
équipements de réseau deviendront des produits à bas prix offrant des
interfaces standard.

II.4.7 Activer l'innovation

SDN permet aux organisations de créer de nouveaux types


d'applications, des services et des modèles d'affaires qui peuvent offrir
de nouvelles sources de revenus et plus de valeur à partir du réseau.

II. 5 LE PROTOCOLE OPENFLOW DANS L’ARCHITECTURE SDN

Le protocole d’injection de règles SDN le plus connu est


OpenFlow, c’est aussi ça que nous allons utiliser dans le cadre de notre
travail.
II.5.1 Introduction

Dans le fonctionnement actuel des réseaux IP, chaque


équipement de réseau (routeur IP, commutateur Ethernet, Firewall,
load-balancer, système de détection d’intrusion, NAT, etc.) exécute ses
fonctions du plan de contrôle et du plan de données.

SDN (Software Defined Network) propose de créer un point


central qui gère le plan de contrôle, tandis que les
commutateurs/routeurs physiques n’ont plus à prendre en charge que
le plan de données. Pour ce faire, l’Open Networking Foundation (ONF)
a publié OpenFlow.
Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.
19

Il s’ agit d’un protocole standard utilisé par le contrôleur


pour transmettre au commutateur des instructions qui permettent de
programmer leur plan de données et d’obtenir des informations de ces
commutateurs afin que le contrôleur puisse disposer d’une vue globale
logique (abstraction) du réseau physique.

OpenFlow est un protocole de lien entre le plan de contrôle


et le plan de données. L’échange de messages se fait au cours d’une
session TCP établie via le port 6633 du serveur contrôleur.

Cette vue est utilisée pour toutes les décisions que doit
prendre le plan de contrôle (routage, filtrage de trafic, partage de
charge, traduction d’adresse, etc).

II.5.2 La genèse d’OpenFlow

L’histoire d ’OpenFlow est intéressante et permet de mieux


comprendre son rôle fondamental dans la conception de
l’architecture SDN (Software Defined Network) et la virtualisation des
fonctions réseau.

OpenFlow a été initié comme un projet à l’université de


Stanford lorsqu’un groupe de chercheurs exploraient la manière de
tester de nouveaux protocoles dans le monde IP (créer un réseau
expérimental confondu avec le réseau de production) mais sans
arrêter le trafic du réseau de production lors des tests.

C’est dans cet environnement que les chercheurs à


Stanford ont trouvé un moyen de séparer le trafic de recherche du
trafic du réseau de production qui utilise le même réseau IP.

OpenFlow est donc un protocole ouvert (open protocol) qui


permet aux administrateurs de réseau de programmer les tables de flux
(flow tables) dans leurs différents commutateurs, chacun avec son
ensemble de fonctionnalités et caractéristiques de flux, c’est ça qui a
était le résultat de l’équipe de recherche à Stanford.

II.5.3 Structure d’un commutateur OpenFlow

Les commutateurs Ethernet et les routeurs les plus modernes


contiennent des tables de flux qui sont utilisées pour effectuer des
fonctions de transfert indiquées dans les entêtes de paquets.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


20

Les principales fonctions des commutateurs sont les


suivantes :

 Fonction de support du contrôle (Control support function) :


Interagit avec la couche contrôle SDN afin de supporter la
programmabilité via les interfaces ressource-contrôle.

Le commutateur communique avec le contrôleur et le


contrôleur gère le commutateur avec le protocole OpenFlow.
OpenFlow peut être utilisé aussi bien pour du contrôle que pour de la
gestion.

 Fonction d’acheminement des données (Data forwarding


function) : Accepte les flux de données entrants provenant
d’autres équipements de réseau et des systèmes de terminaison
et les relaie sur un chemin de commutation qui a été calculé et
établi à partir des règles définies par les applications SDN, passées
au contrôleur et redescendues au commutateur.

À l'aide de la table de flux, une des actions suivantes est exécutée :

A. Relayer le paquet sur un port de sortie,


B. Supprimer le paquet,
C. Passer le paquet au contrôleur. Le paquet est encapsulé dans
un message OpenFlow PACKET_IN.

Figure II.3 : Diagramme de flux des messages OpenFlow

II.5.4 Table de flux

Chaque table de flux du commutateur contient un


ensemble d’entrées de flux qui présentent les règles d’acheminement
des paquets. Chacune est structurée comme suit :
Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.
21

Figure II.7 : Table de flux des messages OpenFlow

 Champ de correspondance (Match fields) : qui définissent le


modèle du flux de paquets à travers l'instanciation des champs
d'en-tête allant de la couche Ethernet à la couche Transport.

 Compteurs (Counters) : des compteurs sur les paquets servent


essentiellement à garder des statistiques sur les flux pour ensuite
décider si une entrée de flux est active ou non.

 Instructions (Actions) : Actions à appliquer aux paquets qui


correspondent à l’entrée de flux.

Figure II.5 : Schématisation d’un modèle de flux OpenFlow

II.5.5 Messages OpenFlow

Les messages OpenFlow entre le contrôleur et le


commutateur sont transmis via un canal sécurisé, implanté via une
connexion TLS sur TCP. Le commutateur initie la connexion TLS lorsqu’il
connaît l’adresse IP du contrôleur. Chaque message entre le
commutateur et le contrôleur commence avec l’en-tête OpenFlow.

Cet en-tête spécifie le numéro de version OpenFlow, le type


de message, la longueur de message, et l’identificateur de transaction
du message.

Il existe trois catégories de message : symétrique, contrôleur-


commutateur et asynchrone.
Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.
22

II.5.5.1 Messages symétriques

Les messages symétriques peuvent être émis indifféremment


par le contrôleur ou le commutateur sans avoir été sollicité par l’autre
entité. Par exemple, on trouve les messages HELLO qui sont échangés
une fois que le canal sécurisé a été établi.

Les messages ECHO sont utilisés par n’importe quelle entité


(contrôleur, commutateur) pendant le fonctionnement du canal pour
s’assurer que la connexion est toujours en vie et afin de mesurer la
latence et le débit courants de la connexion. Chaque message
ECHO_REQUEST doit être acquitté par un message ECHO_REPLY.

II.5.5.2 Messages asynchrones

Les messages asynchrones sont émis par le commutateur au


contrôleur sans que le commutateur ait été sollicité par le contrôleur.

Par exemple, on peut citer le message PACKET_IN qui est


utilisé par le commutateur pour passer les paquets de données au
contrôleur pour leur prise en charge (lorsqu’aucune entrée de flux ne
correspond au paquet entrant ou lorsque l’action de l’entrée
correspondante spécifie que le paquet doit être relayé au contrôleur).

Si le commutateur dispose d'une mémoire suffisante pour


mémoriser les paquets qui sont envoyés au contrôleur, les messages
PACKET-IN contiennent une partie de l’en-tête (par défaut 128 octets),
les commutateurs qui ne supportent pas de mémorisation interne (ou
ne disposant plus de mémoire) émettent le paquet entier au contrôleur
dans le message PACKET-IN.

Le commutateur peut informer le contrôleur qu’une entrée


de flux a été supprimée de la table de flux via le message
FLOW_REMOVED. Cela survient lorsqu’aucun paquet entrant n’a de
correspondance avec cette entrée pendant un temporisateur spécifié
par le contrôleur lors de la création de cette entrée au niveau de la
table de flux du commutateur.

Le message PORT_STATUS est utilisé afin de communiquer un


changement d’état du port (le lien est hors service). Finalement le
commutateur utilise le message ERROR pour notifier des erreurs au
contrôleur.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


23

II.5.5.3 Messages contrôleur-commutateur

Les messages contrôleur-commutateur représentent la


catégorie la plus importante de messages OpenFlow. Ils peuvent être
représentés en cinq sous-catégories : switch configuration, command
from controller, statistics, queue configuration, et barrier.

a. Les messages switch configuration consistent en un message


unidirectionnel et deux paires de messages requête-réponse.

- Le contrôleur émet le message unidirectionnel SET_CONFIG afin


de positionner les paramètres de configuration du commutateur.

- Le contrôleur utilise la paire de message FEATURES_REQUEST et


FEATURES_REPLY afin d’interroger le commutateur au sujet des
fonctionnalités (notamment optionnelles) qu’il supporte.

- La paire de message GET_CONFIG_REQUEST et


GET_CONFIG_REPLY est utilisée afin d’obtenir la configuration du
commutateur.

b. Les messages command from controller sont au nombre de 3.


PACKET-OUT est analogue à PACKET_IN mentionné précédemment.

- Le contrôleur utilise PACKET_OUT afin d’émettre des paquets de


données au commutateur pour leur acheminement via le plan
usager (Plan de données).

- Le contrôleur modifie les entrées de flux existantes dans le


commutateur via le message FLOW_MOD.

- PORT_MOD est utilisé pour modifier l’état d’un port OpenFlow.

c. Des statistiques sont obtenues du commutateur par le contrôleur via


la paire de message STATS_REQUEST et STATS_REPLY.

d. La configuration de files d’attente associées à un port n’est pas


spécifiée par OpenFlow. Un autre protocole de configuration doit être
utilisé pour ce faire. Toutefois le contrôleur peut interroger le
commutateur via QUEUE_GET_CONFIG_REQUEST acquitté par
QUEUE_GET_CONFIG_REPLY pour apprendre quelle est la configuration
des files d’attente associées à un port afin de pourvoir acheminer des
paquets sur des file d’attente spécifiques et ainsi fournir à ces paquets
un niveau de QoS désiré.
Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.
24

e. Le message BARRIER_REQUEST est utilisé par le contrôleur pour


s’assurer que tous les messages OpenFlow émis par le contrôleur et qui
ont précédé cette requête ont été reçus et traités par le commutateur.

II.6 QUELQUES CONTROLEURS SDN

Le contrôleur est, quant à lui, piloté par le besoin des


applications. On dit que le contrôleur fournit une abstraction du plan
de transport aux applications.

La notion d’abstraction signifie que le contrôleur offre des


interfaces programmables aux applications réseaux (les interfaces sont
nommées API) et le contrôleur se charge de piloter le plan de données
en injectant des règles d’acheminement spécifiques répondant aux
besoins des applications sans que les applications connaissent ces
règles.

La couche d’abstraction du contrôleur comporte


une interface de programmation (interface Nord) qui fournit des
fonctions génériques et banalisées de manipulation du réseau de
transport en cachant les détails techniques des entités du réseau. Ceci
permet à une application d’informer le contrôleur des besoins de
traitement de flux de manière générale en faisant abstraction des
détails technique du matériel.

Le contrôleur SDN fournit une API aux « applications SDN »


qui inclut cette vue globale. Ces applications implémentent, via le
contrôleur, des services tels que le routage de flux, la mise en œuvre de
politiques de QoS pour les flux, la sécurité de bout en bout des flux, le
filtrage de flux, etc. Cette approche permet une mise en œuvre flexible
et rapide de nouvelles applications réseau qui émule les « appliances »
réseau.

Le contrôleur SDN permet d’implémenter un changement


sur le réseau en traduisant une demande globale en une suite
d’opérations sur les équipements réseau (ajouts d’états Openflow,
configuration en CLI…), les ordres sont donnés au contrôleur par une
application via une API dite « Northbound » ou nord. Le contrôleur
communique avec les équipements via une ou plusieurs API dites «
Southbound » ou sud. Openflow se positionne comme une API sud
agissant directement sur le plan de données.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


25

Plusieurs contrôleurs ont été développés, dont la majorité


sont open source et supportent le protocole OpenFlow. Ces contrôleurs
diffèrent par leurs langages de programmation, la version d’OpenFlow
supportée, les techniques utilisées comme le multi-threading et les
performances comme le débit.

Nous présentons ci-dessous une liste non exhaustive des


contrôleurs SDN:

II.6.1 NOX

Le premier contrôleur disponible au public écrit en langage


C, l’utilisation d’un seul thread dans son cœur limite son déploiement.
Plusieurs dérivations du NOX ont été proposées plus tard, notamment le
Nox dans sa version multithread appelée NOX-MT, le QNOX, NOX
supportant la qualité de service (QoS), FortNOX, une extension du NOX
implémentant un analyseur de détection des conflits dans les règles de
flux causées par les applications, et enfin, le contrôleur POX, un
contrôleur basé sur NOX en langage python, dont le but est d’améliorer
les performances du contrôleur original NOX.

II.6.2 POX

POX est le plus jeune frère de NOX. C'est un contrôleur


open-source écrit en Python, et comme NOX, fournit un cadre pour le
développement et le test d'un contrôleur OpenFlow.

II.6.3 MAESTRO

Utilise la technologie du multithreading pour effectuer le


parallélisme au bas niveau, en gardant un modèle simple de
programmation pour les développeurs d’applications. Il atteint ses
performances à travers la distribution des tâches du cœur aux threads
disponibles et la minimisation de la mémoire consommée.

II.6.4 BEACON

Développé en java par l’université de Stanford, il est aussi


basé sur les technologies de multithreads et est multiplateforme. Son
architecture modulaire permet au gestionnaire d’exécuter uniquement
les services désirés.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


26

II.6.5 SNAC

Utilise une application web pour gérer les règles du réseau.


Un langage de définition des règles flexibles et des interfaces faciles à
utiliser ont été intégrés pour configurer les équipements réseaux et
contrôler leurs évènements.

II.6.6 MCNETTLE

C’est un contrôleur SDN programmé par Nettle, qui est un


DSL (Domain Specific Language) intégré dans Haskell, et permet la
programmation des réseaux en utilisant OpenFlow. McNettle opère
dans des serveurs multi-cœurs qui partagent leur mémoire pour
atteindre une visibilité globale, une haute performance et une faible
latence.

II.6.7 RISE

Conçu pour les expérimentations des réseaux à grande


échelle, RISE est un contrôleur basé sur Trema. Ce dernier est un
Framework programmé en Ruby et C. Trema fournit un environnement
intégré de test et de débogage, incluant un ensemble d’outils pour le
développement.

II.6.8 RYU

Est un Framework développé en Python. Il permet la


séparation entre les domaines sans utiliser de VLAN. Il supporte jusqu’à
la dernière version d’OpenFlow 1.5.

II.6.9 FLOODLIGHT

Floodlight est un contrôleur open-source OpenFlow basé sur


Java, pris en charge par BigSwitch Networks. Il est sous licence Apache.

II.6.10 OPENDALIGHT

OpenDaylight est un projet de la Fondation Linux pris en


charge par l'industrie. C'est Un framework open source pour faciliter
l'accès au logiciel de définition de réseau (SDN). Comme Floodlight, il
peut également être Considéré comme une solution complète.
Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.
27

II.7 CHOIX DU CONTROLEUR

Par la suite plusieurs contrôleurs ont été proposés pour


améliorer les performances et la scalabilité (adaptation au
changement) du réseau.

Les performances des contrôleurs SDN sont caractérisées


par le débit, qui est la quantité de flux traités par seconde et la latence,
qui est le temps d’installation d’une nouvelle règle, etc.

Voici ci-dessous une table non exhaustive des


caractéristiques des contrôleurs SDN:

Caractéristiques FLOODLIGHT OPENDAYLIGH NOX POX


T
Développé par Big Switch Linux Nicira Nicira
Networks Foundation
Ecrit en Langage Java Java C++/Pytho Python
n
Langages Java, Python Java C++, etc Python
supportés
Open source Oui Oui Oui Oui
Interface Oui Oui Non Oui
utilisateur
Virtualisation Mininet, Mininet, Mininet, Mininet,
OpenVswitch OpenVswitch OpenVswit OpenVswit
ch ch
Interface southbound southbound southboun southboun
(OpenFlow), (OpenFlow et d d
northbound autres (OpenFlow (OpenFlow
(Java, REST) protocoles), ), ),
northbound northboun
(Java RPC) d
Plateforme Linux, Mac, Linux, Windows Linux Linux
Windows
Documentation Un peu difficile Un peu difficile Difficile à Facile à
à trouver à trouver trouver trouver
Northbound API OpenFlow Open Flow, - OpenFlow
BGP-LS,
Apprentissage Difficile Difficile Moyen Facile
Distribué Oui Oui Non Non
Installation Difficile Moyen Moyen Facile

Tableau II.1 : Résumer des caractéristiques des contrôleurs

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


28

Le Tableau II.1 ci-dessus résume les caractéristiques des


contrôleurs SDN les plus connus.

Selon les résultats, nous avons remarqué que plusieurs


contrôleurs ont des problèmes du côté de l’apprentissage, de
l’installation, du langage supporté et de la documentation. Suite à ces
résultats de simulation, nous avons opté pour le choix du contrôleur POX
pour réaliser notre simulation SDN ainsi que l'application.

II.8 CONCLUSION

Cette première partie a été consacrée aux bases théoriques


des réseaux définis par logiciels (SDN). Tout au long de son
développement, nous avons présenté notamment les avantages des
réseaux définis par logiciels (SDN) avant de traiter les composants
essentiels de cette solution pour leur adaptation au contexte de notre
travail.

Il sied de relever la fonction relative à la « programmabilité »


présente un avantage majeur dans la mesure où elle facilite à
l’administrateur de contrôler tous les nœuds réseau au même moment.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


29

PARTIE II :

MISE EN PLACE D’UNE SOLUTION SDN

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


30

CHAPITRE III : LE CONTROLEUR SDN : POX


[1] [11] [15] [16]

III.1 INTRODUCTION

Le réseau programmable, sépare la partie contrôle de la


partie infrastructure du réseau qui traite et achemine les données.

Autrement dit, l’application indique au contrôleur SDN ses


prérequis, et le contrôleur relaie la demande a une infrastructure qui
n’a plus besoin d’être homogène, ainsi, c’est le contrôleur qui devient
le véritable cerveau du réseau.

Ci-dessous nous avons une figure qui illustre le routage d’un


paquet entre deux réseaux qui ne sont pas dans un même site (réseaux
distants) via une
implémentation de SDN avec le protocole OpenFlow. Les routeurs
discriminent les paquets et
déterminent leur interface de sortie, mais ce comportement découle
de règles émises par le
contrôleur. Le routeur qui réceptionne le paquet de l’envoi (1) signale
l’évènement au
contrôleur et reçoit en retour des règles au cours d’un échange (2), afin
de décider du transfert
(3) vers le routeur suivant approprié.

Figure III.1 : Schéma d’un réseau SDN simple

Avec le SDN, les administrateurs gère aisément et à faible


coût le réseau, puisqu’ils n’ont
à gérer que les paramètres et les règles, uniquement au niveau du
contrôleur central, et non
plus au niveau de chaque équipement.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


31

Ce chapitre représente la première contribution de notre


travail, nous commençons d'abord par une présentation de Mininet et
open Vswitch, puis nous parlerons du contrôleur POX ainsi que ses
fonctionnalités.

III.2 MININET

Mininet est un émulateur de réseau, il permet de créer une


topologie réseau qui se compose d'un ensemble de hosts, de switchs,
de contrôleurs et liens virtuels. Il fournit la capacité de créer des hôtes,
les commutateurs et contrôleurs via :

 Ligne de commande,
 Interface interactive,
 Script Python.

III.2.1 Configuration utilisée

Afin de bien visualiser le fonctionnement du SDN, nous avons


choisi d'utiliser une machine virtuelle téléchargée depuis :
https://github.com/mininet/mininet/releases/download/2.2.2/mininet-
2.2.2-170321-ubuntu- 14.04.4-server-amd64.zip et accessible via
VirtualBox, elle utilise le système d'exploitation Linux (Ubuntu-14.04.4).

III.2.2 Fonctionnement de base du Mininet

Mininet permet avec un simple jeu de commande de


réaliser des réseaux virtuels en utilisant la commande mn.

III.2.2.1 Création d'une topologie avec la ligne de commande

Mininet fournit, en plus de la topologie « minimal », la


topologie « single », « linear » et « tree » comme montre dans la figure 8.
Pour charger l’une de ces topologies, on utilise l’option «--
topo», par exemple : $ sudo mn –topo single. « single » tout court
donne la même topologie que minimal, c’est-à-dire créer un hôte relie
avec un switch, mais on peut ajouter également comme argument un
chiffre, qui indique le nombre d'hôtes à créer.
$ sudo mn –topo single, 4
Si nous souhaitons personnaliser une topologie déjà créée, nous
appliquons une des commandes citées ci-dessous :

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


32

- Ajouter un switch : self.addSwitch(‘s1’)


- Ajouter un hôte : self.addHost(‘h1’)
- Ajouter un lien : self.addLink(h1,s1)

Figure III.2 : Différents types de topologie réseau

Apres la configuration, nous devons tester si les paquets sont


routes correctement avec la commande ping qui est un bon moyen
pour vérifier la connectivité :

Mininet> h1 ping -c h2 ou bien Mininet> pingall


et pour analyser les règles insérées dans chaque commutateur, nous
utilisons la commande dpctl: Mininet> dpctl dump-flows, et d'une façon
générale, pour accéder a toutes les commandes utilisées sous Mininet,
il suffit de taper :
Mininet> help

III.2.2.2 Topologies personnalisées

Si nous souhaitons travailler avec une topologie autre que


tree, linear ou simple, et même sans la ligne de commande, il faut créer
une topologie personnalisée à l’aide des scripts Python. Par exemple, si
on veut créer 2 hôtes h1 et h2, les deux sont connectes a un switch s1.

Voici le script Python à écrire :

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


33

class Test_Topo(Topo):
def __init__(self):
"Create P2P topology"
# Initialize topology
Topo.__init__(self)
# Add hosts and switches
h1 = self.addHost('h1')
h2 = self.addHost('h2')
s1 = self.addSwitch('s1')
# Add links
self.addLink(h1,s1)
self.addLink(h2,s1)
topos = { 'toptest': (lambda: Test_Topo()) }

Apres, nous sauvegardons le code dans un fichier


toptest.py, et nous executons la commande suivante:
$ sudo mn --custom /chemin/vers/toptest.py --topo toptest

III.3 Open vSwitch

Open vSwitch est bien adapte pour fonctionner comme un


commutateur virtuel dans les environnements Virtuels. En plus, il
supporte plusieurs technologies de virtualisation basées sur Linux, y
compris Xen, KVM et VirtualBox.

Open vSwitch est donc une implémentation logicielle d’un


switch Ethernet. Concrètement il est constitué d’un service (ovs-
vswitchd) et d’un module kernel (openvswitch_mod).

Le service permet de commuter effectivement les paquets


vers les bons ports virtuels, alors que le module kernel permet de
capturer le trafic provenant des interfaces réseau.

Pour fonctionner comme n’importe quel switch, Open


vSwitch utilise la notion de ports. Chaque port est constitué d’une ou
plusieurs interfaces, qui correspondent à des interfaces du système hôte
(logiques ou physiques).

IIII.3.1 Interagir avec Open vSwitch

 Pour connaitre l’état global d’un switch : ovs-vsctl show


 La création d’un switch se fait par la commande :

ovs-vsctl add-br <nom du virtuel switch>


Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.
34

 Pour ajouter un flux directement dans la table de flux sans avoir


utiliser un controleur, nous utilisons la commande : dpctl

mininet> dpctl add-flow in_port=1,actions=output:2


mininet> dpctl add-flow in_port=2,actions=output:1

Cette commande permet de transférer les paquets arrivant à port1 vers


port 2 et vice versa.

 Pour vérifier le contenu de la table de flux : $ dpctl dump-flows

III.4 CONTROLEUR POX

Dans les SDN, le plan de contrôle est place dans un


contrôleur centralise qui a une visibilité sur l’ensemble du réseau, y
compris les hôtes qui s’y connectent, les applications qui disent aux
contrôleurs comment programmer le réseau utilisent des interfaces de
programmation « NorthBound » tandis que les API et protocoles utilises
par le contrôleur pour communiquer avec les équipements du réseau
sont dits « SouthBound ».

L'une des conceptions de POX est facile à installer et à


exécuter. Cependant, surtout si cela vous intéresse vraiment. Les
commutateurs OpenFlow POX et logiciels sont préinstallés et prêts à
fonctionner.

Il peut également fonctionner comme un commutateur SDN


ou un système d'exploitation réseau. POX est très facile à installer et à
tester depuis la source.

a. Fonctionnalité de base du contrôleur POX

POX est une plate-forme de développement open source


pour les applications de contrôle de réseau défini par logiciel (SDN),
telles que les contrôleurs OpenFlow SDN. POX, qui permet un
développement et un prototypage rapides, est de plus en plus utilisé
par NOX, un projet jumeau.

Il a pour mission :

● Installer / Supprimer les règles de transfert sur les commutateurs


● Découverte de la topologie : besoin de savoir à quoi ressemble
le réseau (Link Layer Discovery Protocol (LLDP)).
● Statistiques : besoin de savoir ce qui se passe dans le réseau.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


35

III.5 CONCLUSION

Outre les concepts se rapportant à la démarche


d’implémentation évoqués au chapitre suivant, au présent chapitre
nous avons présenté Mininet qui fait office d’émulateur réseau. Cet
outil permet de créer une topologie réseau qui se compose d'un
ensemble de hosts, de switchs, de contrôleurs et liens virtuels.

En vue de concilier cette théorie à la pratique, nous avons


évoqué le Open vswitch qui est un commutateur Virtuel avant de
boucler par le contrôleur POX ainsi que ses différentes fonctionnalités
de base.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


36

CHAPITRE IV :
L’IMPLEMENTATION D’UNE
APPLICATION SDN
« GESTION DU LOAD-BALANCING »
[12] [13] [14] [16]

IV.1 INTRODUCTION

Au cours de ce chapitre, nous allons implémenter une


application de gestion de load-balancing (répartition de charge) au
sein d’une entité qui a deux départements, ces derniers ont chacun 3
clients qui veulent accéder aux serveurs http et nous allons répartir les
charges entre nos trois serveurs de telle sorte qu’il ait un équilibre entre
eux. Et à la fin de l’implémentation, chaque serveur recevra le même
nombre de requêtes que les autres venant des clients, c’est ce qui fera
qu’il ait l’équilibre entre les serveurs.

La version Ubuntu-14.04.4 du système d'exploitation Linux a


été choisie comme environnement du travail pour ces fins.

Ci-dessous l’architecture utilisée pour l’implémentation de


notre application :

Figure IV.1 : Architecture de l’application


Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.
37

IV.2 LOAD-BALANCING

Load-balancing : littéralement "répartition de charge" ou


"équilibrage de charge".

D’un côté un serveur. De l’autre un poste client. Entre les


deux, tout un ensemble d’équipements reliés entre eux pour permettre
aux informations de circuler de l’un à l’autre : le réseau.

Simple dans son concept, le réseau est plus complexe qu’il


n’y paraît. De nombreux éléments le composent, regroupés en
"couches" dans le modèle OSI, sur lequel repose le fonctionnement
d’un réseau informatique.

Chaque composant participe, à sa manière, au bon


déroulement des opérations de circulation des informations.

Une solution de load balancing peut intervenir à deux


niveaux du modèle OSI:

Niveaux 3/4 : Réseau et transport (protocole TCP/ IP) ;


consiste à travailler sur les paquets réseau en agissant sur leur routage
(TCP/IP). Le répartiteur de niveau 3/4 intervient donc à l’ouverture de la
connexion TCP puis aiguille les paquets en fonction des algorithmes
retenus.
Niveau 7 : Applications (protocole HTTP, RDP…) : le
répartiteur de charge ne se contente plus d’aiguiller "aveuglément" les
requêtes. Il analyse le contenu de chaque requête HTTP, RDP ou autre
pour décider du routage.

IV.3 INTERET DU LOAD-BALANCING

Pourtant, dans sa définition fonctionnelle, un répartiteur,


quel qu’il soit, assumera au moins deux missions principales :
l’équilibrage de charge entre les serveurs et la surveillance de ces
derniers.

a) Equilibrer dynamiquement la charge sur les serveurs

En pratique, le répartiteur s’appuie sur des algorithmes de


répartition. Il en existe de nombreux qui répondent à des critères bien
différents : les durées de sessions, les variations de charge, les capacités
de serveurs, etc.
Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.
38

b) Surveiller l’état des serveurs

C’est l’un des aspects les plus complexes de la répartition


de charge. Mais néanmoins indispensable : en cas de défaillance de
l’un des serveurs, toutes les requêtes seront réparties automatiquement
entre les autres serveurs de la ferme. Et ceci, de façon totalement
transparente pour l’utilisateur. On parle alors de haute disponibilité
applicative.

IV.4 DIFFICULTES DU LOAD-BALANCING DANS RESEAUX TRADITIONNELS

Les équilibreurs de charge actuellement disponibles


contiennent peu d'algorithmes pouvant être utilisés. Les administrateurs
réseau ne peuvent pas créer leurs propres algorithmes car les
équilibreurs de charge traditionnels sont verrouillés par le fournisseur et
non programmables.

Ces équilibreurs de charge traditionnels sont exorbitants et


peu flexibles au changement.

Étant donné que les équilibreurs de charge traditionnels sont


verrouillés par le fournisseur, les administrateurs réseau ne sont pas en
mesure de créer leurs propres algorithmes en raison de leur nature non
programmable.

IV.5 LE SDN, POUR UNE GESTION SIMPLE DU LOAD-BALANCING

Les équilibreurs de charge SDN sont programmables et vous


permettent de concevoir et de mettre en œuvre votre propre stratégie
d'équilibrage de charge.

Les autres avantages de l'équilibreur de charge SDN sont


que nous n'avons pas besoin de matériel dédié.

Le périphérique silicium muet peut être converti en un


puissant équilibreur de charge par l’application construite sur le
contrôleur, sans nécessiter d’administration de réseau.

Dans le cas d’équilibreurs de charge SDN, les programmeurs


ont la possibilité de construire et de concevoir leur propre stratégie
d’équilibrage de charge, ce qui rend l’équilibreur de charge SDN
programmable et flexible.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


39

Il transmet la demande du client aux serveurs principaux et


obtient les réponses des serveurs, qu'il répond au client.

Il aide également les clients à se connecter directement aux


serveurs principaux, ce qui sécurise la structure du réseau interne et
empêche toute attaque sur le réseau.

IV.6 CHOIX DU TYPE D’EQUILIBREUR DE CHARGE

Pour planifier efficacement le routage des demandes d'un


client vers les serveurs respectifs de manière optimisée, plusieurs
stratégies d'équilibrage de charge sont utilisées, qui sont les suivantes:

 STRATÉGIE ALÉATOIRE: à partir d'une liste de serveurs actifs, l'équilibreur


de charge choisira au hasard un serveur pour l'envoi de la demande.
Cette politique a de gros frais généraux.

 ROUND-ROBIN: chaque serveur reçoit la requête de manière


circulaire. Les requêtes sont allouées à divers serveurs en direct sur une
base de tourniquet.

 WEIGHTED ROUND-ROBIN: chaque serveur reçoit la demande du client


en fonction de critères définis par l'administrateur du site. Dans un autre
monde, une pondération statique est attribuée à chaque serveur dans
la stratégie WRR (pondéré). Nous spécifions généralement des poids
proportionnellement aux capacités réelles. Ainsi, par exemple, si la
capacité du serveur 1 est 5 fois supérieure à celle du serveur 2, nous
pouvons attribuer un poids de 5 au serveur 1 et un poids de 1 au serveur
2.

Dans le cas de notre travail nous avons utilisé la stratégie de


l’algorithme "Round Robin", le premier client à se connecter est envoyé
au premier serveur, le deuxième client au deuxième serveur, le
troisième client au troisième serveur et ainsi de suite.

IV.7 IMPLEMENTATION D’UNE APPLICATION DE GESTION DU LOAD-


BALANCING

De nos jours, nos réseaux doivent gérer une grande quantité


de trafic et servir des milliers de clients. Il est très difficile pour un seul
serveur de gérer une telle charge. La solution consiste à utiliser plusieurs
serveurs avec l'équilibreur de charge faisant office de serveur frontal.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


40

Les clients enverront les demandes à l'équilibreur de charge.


L'équilibreur de charge transmettra les demandes du client à différents
serveurs en fonction de la stratégie d'équilibrage de la charge.

Les principales démarches de notre travail sont les suivantes:

- Mettre en place d'une topologie à l'aide d'un outil d'émulation


basé sur Mininet, et d'un contrôleur POX.

- Conception et développement d’une application d’équilibrage


des charges (Load-Balancing) pour une gestion simple des
serveurs.

a. Mise en place d’une topologie à l'aide du Mininet

Scénario : Ici, nous allons utilisé une topologie réseau qui a 3 servers
HTTP (server1, server2 et server3) et 6 hosts clients (Client1, Client2,
Client3, Client4, Client5 et Client7), tous sont connectés via un Switch
Openflow, et ce dernier est connecté au Contrôleur POX, comme
indiqué dans la figure IV.2 ci-dessous.

- Client1 envoi sa demande au contrôleur qui joue le rôle de


l’équilibreur de charge, et ce dernier transmet sa demande au
server1,

- Client2 envoi sa demande au contrôleur qui joue le rôle de


l’équilibreur de charge, et ce dernier transmet sa demande au
server2,

- Client3 envoi sa demande au contrôleur qui joue le rôle de


l’équilibreur de charge, et ce dernier transmet sa demande au
server3,

- Ainsi de suite pour le reste des clients.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


41

Figure IV.2 : Topologie du scénario

Nous avons créé notre topologie, nous avons utilisé un fichier python :
topomemo.py que nous avons créé, puis nous avons fait appel à ce
fichier à travers la ligne de commande ci-après :

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


42

Figure IV.3 : Fichier topomemo.py

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


43

Figure IV.4 : Topologie du lancement de topomemo.py

Après avoir créé la topologie, nous pouvons la tester en


exécutant des différentes commandes, nous pouvons utiliser la
commande help pour avoir cette liste de commandes, comme montre
la figure ci-dessous :

Figure IV.5 : Exécution de la commande Help

Par exemple, la figure ci-dessous nous affiche la sortie de la commande


dump (la configuration de la topologie) ainsi que la sortie de la
commande net (qui nous montre les liens entre hôtes et switch) :

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


44

Figure IV.6 : Sortie des commandes net et dump

b. Contrôleur POX

Pré-requis :

 Pour étudier et tester un réseau SDN, nous avons utilisé une


machine Linux (Ubuntu 14.03), et installé les outils de
développement JDK et éclipse.

 Puis, nous avons téléchargé et installé POX.

Exécution du POX :

Pour démarrer POX, nous exécutons le fichier pox.py avec la


commande suivante: ./pox.py forwarding.l2_learning

Démarrage de notre équilibreur des charges et des servers au niveau du


contrôleur

La figure ci-dessous nous montre comment notre équilibreur


des charges est démarré avec nos 3 serveurs (server1, server2 et
server3) :

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


45

Les résultats de la commande est :

Figure IV.7 : Démarrage de l’équilibreur de charge et des servers

Démarrage des serveurs web HTTP au niveau des servers

Les serveurs sont démarrés au moyen de cette commande :


python –m SimpleHTTPServer 80 et nous pouvons l’arrêter via : Ctrl+C

Figure IV.8 : Démarrage des serveurs

Envoi des requêtes aux serveurs par les clients

Cette figure nous montre comment les requêtes sont


redirigées via des différents serveurs par notre serveur Load Balancer.

Figure IV.9 : Affichage des requêtes au niveau des serveurs


Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.
46

Ci-dessous nous montre comment les requêtes des clients


arrivent aux différents serveurs par l’équilibrage des charges. Le premier
client envoi sa requête au contrôleur (Load Balancer) à l’aide de la
commande curl suivi de l’adresse IP du contrôleur, et ce dernier
redirige la requête au premier serveur, le deuxième vers le deuxième
server, ainsi des suites pour les autres clients.

Figure IV.10 : Requêtes des 3 premiers clients

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


47

Figure IV.11 : Requêtes des 3 derniers clients

IV.8 CONCLUSION

Tout au long de ce chapitre, nous avons exploité


l’émulateur Mininet, le contrôleur POX et le protocole OpenFlow. Notre
contribution principale est le développement d’une application
d’équilibrage de charge (Load Balancing) dans un environnement
SDN. Notre application donne la possibilité de gérer, créer, de modifier
et aussi de visualiser un équilibrage des charges.

En fournissant une topologie réseau, notre l’administrateur


réseau peut surveiller facilement pour les flows qui va vers nos serveurs
web http à l’aide du contrôleur.

Actuellement, l'équilibrage de charge est un concept très


important dans les datacenters où une haute disponibilité et des
performances sont requises.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


48

CONCLUSION GENERALE

Grâce à la solution SDN, les réseaux sont maintenant


programmables, et la mise à disposition d’interfaces de programmation
d’applications permettra de programmer les équipements du réseau
en utilisant différents langages.

Dans ce travail, nous avons présenté une technologie dans


le domaine des réseaux : SDN qui consistait à mettre en œuvre et à
étudier l'équilibrage de la charge des serveurs dans l'environnement de
réseau défini par logiciel (SDN) à l'aide de règles récurrentes et
aléatoires. Les règles d'équilibrage de la charge sont exécutées sur le
contrôleur SDN.

Le contrôleur Open Source POX Controller utilisé a permis de


fournir l’interface North Bound pour la mise en œuvre des règles
d’équilibrage de la charge, ainsi que l’interface South pour la
communication avec les commutateurs OpenFlow. L'ensemble du
centre de données est émulé dans la plate-forme Mininet.

Au cours des simulations, nous avons découvert en quoi le


réseau défini par logiciel est différent du réseau traditionnel par sa
facon de gérer le réseau au travers d'un côntroleur et enfin une
meilleure appréhension de de POX, Mininet et OpenFlow vSwitch a été
obtenue.

Ce travail nous a également permis de comprendre les


fonctionnalités de base du réseau actuel, et la manière dont ces
dernières sont simplifiées à l’aide du réseau définis par les logiciels.

Ainsi, pouvoir proposer des équipements ou technologies


basées sur SDN devient une priorité et nous citons quelques
rapprochement ou rachat de petites startups spécialisées dans le SDN
par les grands acteurs des réseaux et du logiciel : Oracle rachetant la
startup Xsigo qui offre des services réseaux basés sur le SDN, Juniper
s’alliant à la société Contrail, Cisco se rapprochant de la société
Insiemi. Des acteurs comme HP se sont intéressés très tôt au SDN et se
positionnent aujourd’hui parmi les leaders du marché.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


49

Bibliographie

[1] Bouida Hafida, « Etude et mise en œuvre d’une solution SDN », Mémoire de
Master, Université Abou Bakr Belkaid-Tlemcen, Année universitaire 2016-2017.

[2] Enric Caceres, « Le Protocole OpenFlow dans l’Architecture SDN », EFORT


2016.

[3] Fouad BENAMRANE, « Etude des Performances des Architectures du Plan


de Contrôle des Réseaux SDN », Thèse de doctorat, Université Mohammed V,
Soutenue le 18 Janvier 2017.

[4] Samy ZEMMOURI, «Modèle de routage écoénergétique dans les réseaux


définis par logiciel », Mémoire de Master, école de technologie supérieure
université du québec, soutenue le 1 juin 2017.

[5] Shiva Rowshanrad, Vajihe Abdi et Manijeh Kechtgari, « Performance


evaluation of SDN Controllers », Université de technologie Shiraz, Iran, IIUM, 2
Novembre 2016.

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


50

Webographie

[6] Le nuage informatique : https://www.figer.com/Publications/nuage.htm

[7] L’architecture SDN : https://www.supinfo.com/articles/single/1080-sdn-software-


defined-networking-architecture

[8] Le principe du SDN dans une architecture réseau classique :


http://blogs.univ-poitiers.fr/f-launay/2018/01/15/principe-du-sdn-dans-une-
architecture-reseau-classique/

[9] SDN, principes et fonctionnement : https://blog.wescale.fr/2018/03/01/sdn-


principes-et-fonctionnement/

[10] Introduction à la virtualisation :


https://www.google.cd/url?sa=i&source=images&cd=&cad=rja&uact=8&ved=2ahU
KEwikpu2d9dXeAhUmz4UKHc_2AzQQjRx6BAgBEAU&url=https%3A%2F%2Fwww.sebasti
en-han.fr%2Fblog%2F2011%2F04%2F12%2Fintroduction-a-la-
virtualisation%2F&psig=AOvVaw1XxRLRFZ62OdN0IFxowIXq&ust=1542354468552014

[11] Définition du POX : https://searchnetworking.techtarget.com/definition/POX

[12] Haute disponibilité des serveurs : https://www.jscape.com/blog/active-


active-vs-active-passive-high-availability-cluster

[13] Haute disponibilité des serveurs :


https://www.jscape.com/blog/bid/86515/How-to-Setup-High-Availability-File-Transfer-
Servers

[14] Utilisation d’équilibreur des charges dans le contrôleur POX :


https://angel.co/projects/193862-load-balancing-in-sdn-using-pox-controller

[15] Caractéristique des contrôleurs :


https://www.researchgate.net/publication/3E8W6mVzyQgNxhj6uNkBTc4NbkUc1Kh1r
sSDN_controllers_POX_Floodlight_and_Opendaylight

[16] Architecture de l’application : https://www.draw.io/

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.


51

Table des matières

0. INTRODUCTION GENERALE ........................................................ Erreur ! Signet non défini.1


0.1 PROBLEMATIQUE ..................................................................................................................... 3
0.2 HYPOTHESES DU TRAVAIL ..................................................................................................... 3
0.3 CHOIX ET INTERET DU SUJET ............................................................................................. 4
0.4 DELIMITATION DU SUJET ....................................................................................................... 4
0.5 DIFFICULTES RENCONTREES .................................................................................................. 5
0.6 SUBDIVISION DU TRAVAIL ...................................................................................................... 5
PARTIE I : L’Etat des technologies de réseaux ............................................................................... 6
CHAPITRE I : FONCTIONNEMENT DE BASE DE RESEAUX INFORMATIQUE ...... 7
I.1 INTRODUCTION ......................................................................................................................... 7
I.2 DEFINITION DU RESEAU............................................................................................................ 7
I.3 ARCHITECTURE DU RESEAU CLASSIQUE .............................................................................. 7
I.4 LA VIRTUALISATION ................................................................................................................. 8
I.5 LE CLOUD COMPUTING (L’INFORMATIQUE EN NUAGE) .............................................. 9
I.5.1 Définition .............................................................................................................................. 9
I.5.2 Modèles de services ...................................................................................................... 10
I.5.3 Caractéristiques du cloud ........................................................................................... 11
I.6 UN BESOIN DU RESEAU PROGRAMMABLE ....................................................................... 12
I.7 CONCLUSION .......................................................................................................................... 13
CHAPITRE II : LE RESEAU PROGRMMABLE : SDN ........................................................ 14
II.1 INTRODUCTION ...................................................................................................................... 14
II.2 DEFINITION ............................................................................................................................... 14
II. 3 ARCHITECTURE ...................................................................................................................... 15
II. 4 AVANTAGES........................................................................................................................... 17
II. 5 LE PROTOCOLE OPENFLOW DANS L’ARCHITECTURE SDN ......................................... 18
II.5.1 Introduction ..................................................................................................................... 18
II.5.2 La genèse d’OpenFlow ............................................................................................... 19
II.5.3 Structure d’un commutateur OpenFlow ................................................................ 19
II.5.4 Table de flux ..................................................................................................................... 20
II.5.5 Messages OpenFlow .................................................................................................... 21
II.6 QUELQUES CONTROLEURS SDN ......................................................................................... 24
II.6.1 NOX .................................................................................................................................... 25
II.6.2 POX .................................................................................................................................... 25
Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.
52

II.6.3 MAESTRO .......................................................................................................................... 25


II.6.4 BEACON ........................................................................................................................... 25
II.6.5 SNAC ................................................................................................................................. 26
II.6.6 MCNETTLE ......................................................................................................................... 26
II.6.7 RISE ..................................................................................................................................... 26
II.6.8 RYU ..................................................................................................................................... 26
II.6.9 FLOODLIGHT .................................................................................................................... 26
II.6.10 OPENDALIGHT............................................................................................................... 26
II.7 CHOIX DU CONTROLEUR ..................................................................................................... 27
II.8 CONCLUSION ......................................................................................................................... 28
PARTIE II : Mise en place d’une solution SDN .............................................................................. 29
CHAPITRE III : LE CONTROLEUR SDN : POX .................................................................. 30
III.1 INTRODUCTION ...................................................................................................................... 30
III.2 MININET ................................................................................................................................... 31
III.3 Open vSwitch........................................................................................................................ 33
III.4 CONTROLEUR POX ............................................................................................................... 34
III.5 CONCLUSION ........................................................................................................................ 35
CHAPITRE IV : L’IMPLEMENTATION D’UNE APPLICATION SDN ............................. 36
IV.1 INTRODUCTION .................................................................................................................... 36
IV.2 LOAD-BALANCING.............................................................................................................. 37
IV.3 INTERET DU LOAD-BALANCING ........................................................................................ 37
IV.4 DIFFICULTES DU LOAD-BALANCING DANS RX TRADITIONNELS ................................ 38
IV.5 LE SDN, POUR UNE GESTION SIMPLE DU LOAD-BALANCING ................................... 38
IV.6 CHOIX DU TYPE D’EQUILIBREUR DE CHARGE ............................................................... 39
IV.7 IMPLEMENTATION D’UNE APPLICATION DE GESTION DU LOAD-BALANCING ...... 39
IV.8 CONCLUSION ........................................................................................................................ 47
V. CONCLUSION GENERALE ..................................................................................................... 48
Bibliographie ................................................................................................................................... 49
Webographie .................................................................................................................................... 50

Travail de fin d’étude/UNIKIN 2017-2018 MUKADI N.

Vous aimerez peut-être aussi