Khouas, Gacem, Conception Et Réalisation D'un Outil de Gesti

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE

LA RECHERCHE SCIENTIFIQUE
UNIVERSITE M’HAMED BOUGARA - BOUMERDES
FACULTE DES SCIENCES
Département : Physique
MEMOIRE DE FIN
D’ETUDE
Pour l’obtention du diplôme de MASTER en Systèmes
informatiques distribués
Réalisé par :
KHOUAS Abdelhalim GACEM Ahmed Ramzi
Conception et réalisation d'un outil de gestion

normalisé dédié à la plate-forme de
virtualisation des réseaux Open Virtual switch
Devant le jury composé de : Sujet Proposé par :
Mr Med HAMADOUCH Président Mr Med.Amine Bouabid

Mr Med.Amine RIAHLA Promoteur
Mme S.Mechid Examinatrice
2015/2016
RÉSUMÉ
Le Cloud Computing est un ensemble d'outils technologiques qui permettent l'accès à des
ressources informatiques partagées et configurables en mode self-service. En d'autres
termes, il permet l'exploitation des ressources de calcul et de stockage via le réseau de
communication. Les standards de gestion développées par le DMTF sont fondés
essentiellement sur le métalangage orienté objet CIM (Common Information Model) et
l'architecture WBEM (Web Based Enterprise Management).
Afin d'offrir une vision globale, complète et homogène via les standards du DMTF de tous les
composants d'une plateforme de Cloud Computing, nous proposons dans le cadre de notre
projet, d'implémenter un standard dédié au contrôle et l'exploitation des réseaux virtuels.
Plus précisément, il s'agit de standardiser la gestion d'une brique essentielle dans le monde
de la virtualisation des réseaux et du Cloud, à savoir, la plateforme Open Virtual Switch
(OVS ou Open vSwitch) cet outil est adopté par la majorité des technologies de virtualisation
comme Xen, KVM et autres. Mais également par un grand nombre de constructeurs de
Commutateurs physiques de dernière génération dans le cadre de ce qu'on appelle :
Software Defined Network (SDN)
Dans le cadre de notre projet, nous avons réalisé un système dédié à la gestion de la
couche L2 de la plateforme OVS en se basant sur le standard CIM/WBEM. Notre système
permet la supervision et contrôle de cette couche des réseaux informatiques virtuels.
Notre système repose sur une architecture adaptant les composants WBEM élémentaires à
l’architecture d’un Open vSwitch.
La traduction CIM/OVS est réalisée par le Provider CIM/OVS que nous avons développé et
qui représente le noyau de notre travail car il assure d'un coté la traduction CIM de/vers OVS
et aussi faciliter aux clients qui n’ont pas les bases en programmation, le contrôle et la
supervision de leurs plateformes virtuelles.
Notre Provider représente une brique logicielle qui peut être intégrée à la plupart des
plateformes de virtualisation, de SDN et plus généralement de Cloud Computing.
L'intégration avec les environnements existants en sera facilitée grâce à l'écosystème
CIM/WBEM qui va être utilisé.

ABSTRACT
The cloud computing is a set of tools and technologies that allow the access to
shared and configurable on self-service mode IT resources. In other words, they
allow the exploitation of computing and storage resources using network. The
management standards developed by the DMTF are essentially based on the object-
oriented meta-language CIM (Common Information Model) and WBEM architecture
(Web-Based Enterprise Management)
In the aim of providing a global, complete and homogeneous vision through DMTF
standards of all components of cloud computing platform, we offer as part of our
project implementing a standard dedicated for exploiting and controlling virtual
networks. More specifically, it is to standardize the management of an essential brick
in the world of cloud computing and network virtualization, namely, the Open Virtual
Switch Platform (OVS or Open vSwitch), this tool is adopted by the majority of
virtualization technology companies such as Xen, KVM and others. And also by a
large number of latest generations physical switches manufacturers as part of what is
called: Software Defined Network (SDN)
As part of our project, we realized a system dedicated to the management of layer
two of the OVS platform based on the standard CIM / WBEM. Our system allows
monitoring and control of this layer a virtual computer network.
Our system is based on an architecture adapting elementary WBEM components to
the architecture of Open vSwitch.
Translation CIM / OVS is performed by the CIM Provider / OVS that we developed
and represents the core of our work, because it assures one side the translation of
CIM to OVS and also facilitates the monitoring and the supervision of platforms for
customers who do not have programming bases.
Our Provider is a software component that can be integrated with most virtualization
platforms, of SDN and more generally the cloud. The integration with existing
environments will be easier through the ecosystem CIM / WBEM which will be used.

‫ﻣﻠﺨﺺ‬
‫اﻟﺤﻮﺳﺒﺔ اﻟﺴﺤﺎﺑﯿﺔ ھﻲ ﻣﺠﻤﻮﻋﺔ ﻣﻦ اﻷدوات واﻟﺘﻘﻨﯿﺎت اﻟﺘﻲ ﺗﺘﯿﺢ اﻟﻮﺻﻮل إﻟﻰ ﻣﻮارد ﺣﺎﺳﻮﺑﯿﺔ ﻣﺸﺘﺮﻛﺔ‪ .‬وﺑﻌﺒﺎرة أﺧﺮى‪،‬‬
‫ﻓﮭﻲ ﺗﺴﻤﺢ ﺑﺎﺳﺘﻐﻼل ﻣﻮارد اﻟﺤﻮﺳﺒﺔ واﻟﺘﺨﺰﯾﻦ ﺑﺎﺳﺘﺨﺪام اﻟﺸﺒﻜﺎت‪ .‬إن ﻣﻌﺎﯾﯿﺮ اﻹدارة اﻟﺘﻲ وﺿﻌﺘﮭﺎ ‪ DMTF‬ﺗﺴﺘﻨﺪ أﺳﺎﺳﺎ‬
‫ﻋﻠﻰ اﻟﻠﻐﺔ اﻟﻔﻮﻗﯿﺔ )‪ CIM (Common information model‬وﺗﺼﻤﯿﻢ ‪WBEM (Web Based Enterprise‬‬
‫)‪Management‬‬
‫ﺑﮭﺪف ﺗﻮﻓﯿﺮ رؤﯾﺔ ﺷﺎﻣﻠﺔ وﻛﺎﻣﻠﺔ وﻣﺘﺠﺎﻧﺴﺔ ﻣﻦ ﺧﻼل ﻣﻌﺎﯾﯿﺮ ‪ DMTF‬ﻟﺠﻤﯿﻊ ﻣﻜﻮﻧﺎت ﻣﻨﺼﺔ اﻟﺤﻮﺳﺒﺔ اﻟﺴﺤﺎﺑﯿﺔ‪ ،‬ﻧﻘﺪم ﻛﺠﺰء‬
‫ﻣﻦ ﻣﺸﺮوﻋﻨﺎ ﺗﻨﻔﯿﺬ ﻣﻌﺎﯾﯿﺮ ﻣﺨﺼﺼﺔ ﻻﺳﺘﻐﻼل ﺗﺴﯿﯿﺮ اﻟﺸﺒﻜﺎت اﻻﻓﺘﺮاﺿﯿﺔ‪ .‬وﺑﺸﻜﻞ أﻛﺜﺮ ﺗﺤﺪﯾﺪا‪ ،‬ﺗﻮﺣﯿﺪ إدارة ﻟﺒﻨﺔ أﺳﺎﺳﯿﺔ‬
‫ﻓﻲ ﻋﺎﻟﻢ اﻟﺤﻮﺳﺒﺔ اﻟﺴﺤﺎﺑﯿﺔ واﻟﺸﺒﻜﺎت اﻻﻓﺘﺮاﺿﯿﺔ‪ ،‬وھﻲ ﻣﻨﺼﺔ ‪ OVS‬أو ‪ ، vSwitch Open‬وﻗﺪ ﺗﻢ اﻋﺘﻤﺎد ھﺬه اﻷداة ﻣﻦ‬
‫ﻗﺒﻞ اﻟﻐﺎﻟﺒﯿﺔ اﻟﻌﻈﻤﻰ ﻣﻦ ﺷﺮﻛﺎت اﻟﺘﻜﻨﻮﻟﻮﺟﯿﺎ اﻻﻓﺘﺮاﺿﯿﺔ ﻣﺜﻞ ‪ KVM ,Xen‬وﻏﯿﺮھﺎ‪ .‬وأﯾﻀﺎ ﻣﻦ ﻗﺒﻞ ﻋﺪد ﻛﺒﯿﺮ ﻣﻦ أﺣﺪث‬
‫ﻣﺼﻨﻌﻲ أﺟﮭﺰة اﻟﺘﺤﻮﯾﻞ اﻟﻤﺎدﯾﺔ )‪ (Switches‬ﻓﻲ إطﺎر ﻣﺎ ﯾﺴﻤﻰ‪ :‬ﺑﺮاﻣﺞ ﺗﻌﺮﯾﻒ ﺷﺒﻜﺔ )‪(SDN‬‬
‫ﻛﺠﺰء ﻣﻦ ﻣﺸﺮوﻋﻨﺎ‪ ،‬طﻮرﻧﺎ ﻧﻈﺎم ﻣﺨﺼﺺ ﻹدارة اﻟﻄﺒﻘﺔ اﻟﺜﺎﻧﯿﺔ ﻣﻦ ﻣﻨﺼﺔ ‪ OVS‬ﻋﻠﻰ أﺳﺎس ﻣﻌﯿﺎر ‪WBEM / CIM.‬‬
‫اﻻﻓﺘﺮاﺿﯿﺔ‪.‬‬ ‫اﻟﻜﻤﺒﯿﻮﺗﺮ‬ ‫ﺷﺒﻜﺎت‬ ‫ﻓﻲ‬ ‫اﻟﻄﺒﻘﺔ‬ ‫ھﺬه‬ ‫وﻣﺮاﻗﺒﺔ‬ ‫ﺑﺘﺴﯿﯿﺮ‬ ‫ﺑﺘﻄﻮﯾﺮه‬ ‫ﻗﻤﻨﺎ‬ ‫اﻟﺬي‬ ‫اﻟﻨﻈﺎم‬ ‫ﯾﺴﻤﺢ‬
‫وﯾﺴﺘﻨﺪ ﻧﻈﺎﻣﻨﺎ ﻋﻠﻰ ﺑﻨﯿﺔ ﺗﺴﻤﺢ ﻟﮫ ﺑﺘﻜﯿﯿﻒ ﺑﻨﯿﺔ ‪ vSwitch Open‬ﻣﻊ ﻣﻜﻮﻧﺎت ‪ WBEM‬اﻷﺳﺎﺳﯿﺔ‪.‬‬
‫ﺗﺘﻢ اﻟﺘﺮﺟﺔ ‪ OVS/CIM‬ﻣﻦ ﻗﺒﻞ اﻟﻤﺰود اﻟﺬي ﻗﻤﻨﺎ ﺑﺘﻄﻮﯾﺮه واﻟﺬي ﯾﻤﺜﻞ ﺟﻮھﺮ ﻋﻤﻠﻨﺎ‪ ٫‬ﻷﻧﮫ ﯾﻮﻓﺮ ﺧﺎﺻﯿﺔ اﻟﺘﺮﺟﻤﺔ ﻣﻦ ‪CIM‬‬
‫إﻟﻰ‪ OVS‬ﻣﻦ ﺟﮭﺔ وﻣﻦ ﺟﮭﺔ أﺧﺮى ﺗﯿﺴﯿﺮ اﻟﻤﺮاﻗﺒﺔ واﻹﺷﺮاف ﻋﻠﻰ ﻣﻨﺼﺎت اﻟﺸﺒﻜﺎت اﻻﻓﺘﺮاﺿﯿﺔ ﻟﻠﻌﻤﻼء اﻟﺬﯾﻦ ﻟﯿﺲ ﻟﺪﯾﮭﻢ‬
‫ﻗﻮاﻋﺪ ﻓﻲ اﻟﺒﺮﻣﺠﺔ‪.‬‬
‫اﻟﻤﺰود اﻟﺨﺎص ﺑﻨﺎ ھﻮ ﻋﺒﺎرة ﻋﻦ ﺑﺮﻧﺎﻣﺞ ﯾﻤﻜﻦ إدﻣﺎﺟﮫ ﻓﻲ ﻛﺎﻓﺔ ﻣﻨﺼﺎت اﻟﺸﺒﻜﺎت اﻻﻓﺘﺮاﺿﯿﺔ ﻓﻲ ﺑﺮاﻣﺞ ﺗﻌﺮﯾﻒ اﻟﺸﺒﻜﺎت‬
‫واﻟﺤﻮﺳﺒﺔ اﻟﺴﺤﺎﺑﯿﺔ ﻋﺎﻣﺔ‪ ٫‬إدﻣﺎج اﻟﻤﺰود ﻣﻊ اﻷﻧﻈﻤﺔ اﻟﻤﺘﻮﻓﺮة ﺣﺎﻟﯿﺎ ﺳﯿﻜﻮن أﺳﮭﻞ ﻣﻦ ﺧﻼل اﺳﺘﺨﺪام ‪.WBEM / CIM‬‬
‫ ‬
REMERCIMENTS
Nous tenons à remercier tout d'abord notre promoteur Dr. Med Amine RIAHLA de
nous encadrer durant ce projet. Nous tenons aussi à remercier notre encadreur Dr.
Mohamed El Amine BOUABID, d’avoir proposé se sujet et accepté de nous encadrer
durant ce projet, de nous avoir beaucoup aidé et soutenu, pour sa disponibilité, sa
patience, ses conseils, et surtout son encouragement durant les moments difficiles.
Nous remercions Dr. M’hammed HAMADOUCH d'avoir accepté de présider le jury

de soutenance de ce projet.
Nous remercions Mme. S.MECHID d'avoir accepté d’être l’examinatrice de notre

travail.
DEDICACES
A mes chers Parents,

A mes chers frères et sœurs,
A ma future Femme,
A tous mes chers(e) amis(e)
KHOUAS A.E.H
A mes chers Parents,

A ma chère sœur,
A mes chers(e) Professeurs,
A mes chers(e) amis(e)
GACEM A.R

TABLES DES MATIERES
INTRODUCTION GENERALE__________________________________________1
CHAPITRE I : GÉNÉRALITÉS SUR OPEN vSwitch
INTRODUCTION_______________________________________________ 5
1.1. VIRTUALISATION DES RESEAUX_____________________________ 5
1.1.1 LES AVANTAGES DE LA VIRTUALISATION DES RÉSEAUX ___5
1.2. SOFTWARE DEFINED NETWORKING __________________________6
1.2.1 Architecture des SDN___________________________________7
1.3. OPENFLOW _______________________________________________7
1.4. OPEN vSwitch _____________________________________________9
1.4.1 Définition_____________________________________________9
1.4.2 Les composants Principaux d’OVS_________________________11
1.4.2.1 ovsdb-server ____________________________________11
1.4.2.2 ovs-vswitchd ____________________________________12
1.4.2.3 openvswitch.ko (OVS Kernel Module)_________________12
1.4.3 Les outils de l'espace utilisateur ___________________________13
1.4.5 Architecture Open vSwitch représentant le traitement des flux de
données ______________________________________________________14
CONCLUSION _________________________________________________15
CHAPITRE II : GÉSTION WBEM_______________________________________17
INTRODUCTION _______________________________________________18
2.1. L’ARCHITECTURE FONCTIONNELLE __________________________18
2.1.1 RÔLES ______________________________________________18
2.1.2 ENTITÉS_____________________________________________19
2.2. LE MODÈLE D’INFORMATION COMMUN CIM____________________20
2.2.1 LE META-MODELE_____________________________________21
2.2.1.1 Schéma ________________________________________21
2.2.1.2 Classes ________________________________________21

2.2.1.3 Propriétés ______________________________________21
2.2.1.4 Méthodes_______________________________________21
2.2.1.5 Qualificateurs____________________________________22
2.2.1.6 Les Références __________________________________22
2.2.1.7 Les associations _________________________________22
2.2.1.8 Instances_______________________________________22
2.2.1.9 Indications______________________________________22
2.2.2 CIM MANAGED OBJECT FORMAT (MOF) __________________23
2.2.3 Base d'informations de gestion____________________________23
2.2.4 Architecture de la MIB___________________________________23
2.2.5 Les chemins du modèle commun__________________________24
2.2.5.1 Modèle de base__________________________________25
2.2.5.2 Modèles communs________________________________25
2.2.5.3 Extension du schéma _____________________________25
2.3. LE MODÈLE DE COMMUNICATION____________________________25
2.3.1 Le protocole de communication XML/HTTP__________________26
2.3.2 Les opérations CIM_____________________________________27
2.3.2.1 les opérations extrinsèques_________________________27
2.3.2.2 les opérations intrinsèques _________________________28
CONCLUSION _________________________________________________31
CHAPITRE III : CONCEPTION DU SYSTEME ____________________________33
INTRODUCTION _______________________________________________34
3.1. L’ARCHITECTURE FONCTIONNELLE __________________________35
3.2. MODELISATION CIM ________________________________________36
3.2.1 Classes et Associations de notre premier Profile ______________37
3.2.1.1 Les Classes_____________________________________37
3.2.1.1.1 OVS_ComputerSystem ______________________37
3.2.1.1.2 OVS_NetworkVLAN_________________________38
3.2.1.1.3 OVS_LANEndpoint__________________________38
3.2.1.1.4 OVS_EthernetPort __________________________38
3.2.1.1.5 OVS_VLANEndpoint ________________________40
3.2.1.1.6 OVS_VLANEndPointSettingData_______________42

3.2.1.1.7 OVS_ConnectivityCollection __________________42
3.2.1.1.8 OVS_VirtualEthernetSwitchSettingData__________42
3.2.1.1.9 OVS_ResourcePool_________________________42
3.2.1.1.10 OVS_EthernetPortAllocationSettingData________44
3.2.1.1.11 OVS_RegisteredProfile _____________________44
3.2.1.2 Les Association __________________________________44
CONCLUSION _________________________________________________45
CHAPITRE IV : RÉALISATION DE NOTRE SYSTÈME DE GESTION __________46
INTRODUCTION _______________________________________________47
4.1. LES CHOIX TECHNIQUES____________________________________47
4.2. IMPLEMENTATION _________________________________________47
4.3. DETAILS DE PROGRAMMATION______________________________48
4.3.1 DEFINITION DE CLASSE EN FORMAT MOF________________48
4.3.2 GENERATION DU PROJET EN C++_______________________49
4.3.3 L’AJOUT DES CODES DES METHODES ___________________49
4.3.4 COMPILATION DU PROVIDER ___________________________50
CONCLUSION _________________________________________________51
CONCLUSION GENERALE et PERSPECTIVES __________________________52

BIBLIOGRAPHIE ___________________________________________________54

LISTE DES ILLUSTRATIONS
[Figure 1 : architecture du SDN]____________________________________15

[Figure 2 : OpenFlow dans l’architecture d’OVS]_____________________17
[Figure 3 : Les supporteurs d’Open vSwitch]__________________________18
[Figure 4 : Les tables les plus utilisées] _____________________________19
[Figure 5 : Toutes les tables de la BDD]______________________________20
[Figure 6 : Composants d’Open vSwitch] ____________________________21
[Figure 7 : voie de traitement d’OVS]________________________________23
[Figure 8 : les rôles des intervenants dans l’architecteur WBEM]___________27
[Figure 9 : Architecture WBEM] ___________________________________28
[Figure 10 : Le meta-modele CIM] _________________________________31
[Figure 11 : Architecteur de la MIB dans WBEM]_______________________32
[Figure 12 : communication client/serveur WBEM]______________________34
[Figure 13 : Modules de communication WBEM]______________________35
[Figure 14 : Multiples serveurs CIM-OM] ____________________________42
[Figure 15 : Architecture de Système de gestion]_______________________43
[Figure 16 : Le Profile du Virtual Switch Ethernet et le Diagramme des classes]__46
[Figure 17 : étapes de programmation de notre Provider]_______________60

INTRODUCTION GENERALE

CONTEXTE
Les réseaux informatiques sont de plus en plus déployer dans les entreprises et les
organisations, leurs places est devenu stratégique au sein de ces derniers. Le
Cloud Computing, une solution qui permet l'accès à ces réseaux et leurs
ressources informatiques partagées marque aussi sa place importante dans se
milieu et devient de plus en plus utilisé.
L’environnement informatique dans ce genre de systèmes distribues n’est pas

homogène, et la pluralité des utilisateurs rend l’utilisation de cette solution, pratique
pour les uns et un peu moins pour les autres, en cause de sa complexité. Ce qui
implique la nécessité de la normalisation de se type de réseaux pour les rendre
accessible et facile à utiliser sans se soucier de ces bases en programmation.
Donc la normalisation de la représentation et de l’API d’accès aux plateformes

d’Open vSwitch OVS et l’élaboration d’un standard dédié a la supervision et le
contrôle, en se basant sur le standard CIM/WBEM est une solution importante et
pressante dans l’objectif d’en faciliter l’intégration avec les plateformes de Cloud
et de SDN et assurer l’interopérabilité entre ces différentes plateformes.
OBJECTIF DU PROJET
L’objectif de ce projet est le développement d'une brique logicielle qui peut être
intégrée à la plupart des plateformes de virtualisation, de SDN et plus généralement
de Cloud Computing, mais sans pour autant être dépendante de ces outils et
technologies. L'intégration avec les environnements existants en sera facilitée grâce
à l'écosystème CIM/WBEM qui va être utilisé, dans le but d’offrir une gestion
homogène et unifiée a tout types d’utilisateurs.
L'approche CIM-WBEM est la solution de collaboration d'un grand nombre de

constructeurs et éditeurs informatiques dont notamment Cisco, Dell, VMware,
HP, IBM, Intel, Microsoft et Oracle et aussi d’autre Leadership dans ce
domaine. Ces entreprises ont fondé le Distributed Management Task Force ou
DMTF, une organisation qui se charge du développement et du maintien des
standards pour l'administration des systèmes informatiques. Cette approche se
base sur deux standards :

• CIM (Common Information Model), qui est un standard ouvert qui permet de
modéliser n'importe quelle entité gérable.
• WBEM (Web-Based Enterprise Management), qui est un ensemble de
techniques et de standards qui servent à unifier la gestion des systèmes
distribués.
Le standard CIM-WBEM a été choisi dans le cadre de ce projet, pour son caractère
orienté objet, l’exhaustivité des modèles qu’il propose et la richesse des domaines
technologiques qu’il couvre. En effet, le DMTF propose des profils bien définis qui
offrent, aux développeurs souhaitant réaliser n'importe quel système de gestion
standardisé, des modèles abstraits à utiliser comme squelette de départ dont il
faudrait étendre et adapter aux besoins spécifiques.
En outre, l’implémentation OVS qui représente un Switch ou commutateur Virtuel,

s’occupe de la séparation de réseaux et la gestion du trafic des Machine Virtuel VM,
et l’utilisateur peut être affecter à une ou plusieurs machines avec des configurations
de réseau élastiques sans qu’il ne s’aperçoit.
La réalisation de ce système standardisé a comme objectif la contribution à la

normalisation de la supervision et le contrôle de ce type de réseau, et cela en
traduisant l’API d’accès aux plateformes OVS sous format CIM, ce qui facilite la
gestion de tout système de ce type.
ORGANISATION DU MANUSCRIT
Dans cette partie introductive, nous avons expliqué le contexte de notre travail avant
de parler de notre objectif. Nous présentons dans le chapitre suivant l’Open vSwitch
OVS, et ces composants principaux. Dans le deuxième chapitre, nous introduisons le
standard de gestion adopté dans notre projet, en l’occurrence CIM/WBEM. Dans le
troisième chapitre présente la conception de notre système. Dans le dernier chapitre,
nous présentons les détails de la réalisation de notre système. Nous terminons ce
document par une conclusion générale ainsi que quelques perspective

Chapitre I
GENERALITES SUR OPEN vSwitch
SOMMAIRE :
INTRODUCTION
1.1. VIRTUALISATION DES RESEAUX
1.2. SOFTWARE DEFINED NETWORKING
1.3. OPENFLOW
1.4. OPEN vSwitch
CONCLUSION

INTRODUCTION
Dans l’année 1979, IBM a lancé la première VM (IBM 4331 et 4341) qui étaient
des accélérateurs VM optionnel et microcodé. La réussite de ce travail a poussée les
grandes entreprises de se domaine a investir dans les technologies réseaux et
élargir leurs plateforme. La concurrence a été très grande entre ces grandes firmes
et de nouvelles technologies furent apparues par la suite.
Chaque firme a développé sa propre technologie, ce qui nécessite des experts
pour chaqu’une d’elle, ce qui a conduit a un manque de personnel important pour la
gestion de leurs grandes réseaux hétérogènes, Ces difficultés ont affecté non
seulement les activités quotidiennes de gestion des réseaux, mais aussi les plans
stratégiques de ces entreprises. Dans ces circonstances, l'automatisation de la
gestion des réseaux et systèmes est devenue un besoin urgent.
1.1 VIRTUALISATION DES RESEAUX

La virtualisation des réseaux est le processus de combinaison des ressources
matérielles du réseau et les fonctionnalités en une seule entité logiciel. La
virtualisation correspond à l’ensemble des techniques matérielles et/ou logicielles qui
permettent de faire fonctionner sur une seule machine plusieurs systèmes
d’exploitation et/ou plusieurs applications, séparément les uns des autres, comme
s’ils fonctionnaient sur des machines distinctes.[34]
Pour que ceci soit possible, il faut que les capacités matérielles de la machine
hôte soient assez importantes (en processeur et mémoire vive notamment). Les
outils de virtualisation permettent de faire fonctionner ce que l’on appelle des
environnements virtuels. Les entreprises y ont de plus en plus recours à eux car ils
leurs permettent de gagner de la place dans les salles serveurs, de faciliter les
installations et les redémarrages après incidents, et de sécuriser les systèmes.
Chaque outil de virtualisation implémente une ou plusieurs de ces notions :
- couche d’abstraction matérielle et/ou logicielle.
- systèmes d’exploitations (ou applications) « virtualisé(e)(s) » ou « invité(e)(s) »
- partitionnement, isolation et/ou partage des ressources physiques et/ou logicielles.
- images manipulables : démarrage, arrêt, clonage, sauvegarde et restauration,
migration d’une machine physique à une autre.[34]
5
- réseau virtuel : réseau purement logiciel, interne, à la machine hôte, entre hôte
et/ou invité.
1.1.1 LES AVANTAGES DE LA VIRTUALISATION DES RESEAUX

- Elasticité : Facile à étendre les ressources dans le besoin. L'administrateur peut
dynamiquement créer ou supprimer une connexion de réseau virtuel.
- Résistance : Récupérer des échecs. Le réseau virtuel redirigera automatiquement
les paquets par des liens redondants.
- Sécurité : L’isolement des chemins (paths). Réseau virtuel devrait fonctionner avec
un logiciel pare-feu.
- Disponibilité : A tout moment les ressources de réseau sont accessible
1.2 SOFTWARE DEFINED NETWORKING

Au cours des dernières années, les sujets les plus chauds dans les réseaux ont
été définis par le logiciel réseau (SDN) et la virtualisation du réseau (NV). Il y a,
cependant, beaucoup de confusion parmi les grandes entreprises par rapport à ces
sujets. Il existe de nombreuses sources de cette confusion, y compris le grand
nombre de fournisseurs qui ont des solutions qui résolvent différents problèmes en
utilisant comme solutions différentes architectures et technologies, qui tous
prétendent offrir soit le SDN soit NV ou bien une solution HYBRID entre les deux.
Dans l'approche traditionnelle de la mise en réseau, la plupart des
fonctionnalités de réseau sont misent en œuvre dans un dispositif dédié; à savoir,
commutateur, routeur, contrôleur de distribution d'applications. De plus, dans
l'appareil dédié, la plupart des fonctions sont mise en œuvre dans un matériel
spécialisé, tel qu'un ASIC (Application Specific Integrated Circuit).[35]
L’Open Networking Foundation (ONF) est le groupe qui est le plus associé avec
le développement et la standardisation des SDN. Selon l’ONF, Software Defined
Networking (SDN) est une architecture émergente qui permet d’ouvrir le réseau aux
applications, elle est dynamique, gérable, rentable et adaptable, qui la rend idéal
pour une bande passante élevée, c’est la nature dynamique des applications
d'aujourd'hui. Cette architecture découple le contrôle du réseau et les fonctions
d'expédition permettant le contrôle du réseau pour devenir directement
programmable[34][36].
6
1.2.1 ARCHITECTURE DES SDN [32] [21]
Selon l'ONF, l'architecture des SDN est :
- Directement programmable : le contrôle du réseau est directement
programmable, parce qu’il est découplé des fonctions de transfert.
- Agile : la séparation entre le control et la transmission des paquets permet au
administrateur d'ajuster dynamiquement les flux de trafic au niveau du réseau pour
répondre aux besoins changeants.
- Gestion centralisée : l’intelligence du réseau est centralisée dans le contrôleur de
base d’SDN qui maintient une vision globale du réseau qui apparaît aux applications
et aux moteurs de la politique comme un seul commutateur logique.
- La configuration programmable : SDN permet aux gestionnaires du réseau d’être
configurer, gérer, sécuriser et permet d’optimiser les ressources réseau très
rapidement par l'intermédiaire ces programmes dynamiques et automatisés.
[Figure 1 : architecture du SDN]
1.3 OPENFLOW
En regardant comment les réseaux ont été mis en œuvre il y a 20 ans et en
regardant l'image de la mise en réseau d'aujourd'hui, il est évident que les réseaux
ont parcouru un long chemin et ils ont beaucoup évolué en termes de vitesse, de
fiabilité, de sécurité et de l'ubiquité. Et alors que les technologies de la couche
7
physique ont évolué fournissant des bandes passantes de grande capacité, et aussi
une puissance de calcule de plus en plus élevée, une grande quantité d’applications
de réseau a émergé, par contre, la structure du réseau n'a pas vu beaucoup de
changement depuis ses débuts. Dans l'infrastructure existante, les tâches complexes
qui composent la fonctionnalité globale du réseau telles que le routage ou les
décisions d’accès au réseau sont déléguées à des périphériques réseau de
différents fournisseurs, ces derniers s’exécutent sous des firmwares différents. Ces
différences de propriétés de base représentent un obstacle en limitant l’espace des
idées de recherches tels que des nouveaux protocoles (routage ou autre).
OpenFlow a émergé de la nécessité de remédier à ces lacunes critiques dans
la mise en réseau d'aujourd'hui afin d'aider la recherche fluorescente. OpenFlow
exploite l'existence de tables de routage dans les commutateurs et routeurs Ethernet
modernes. Ces flux tables fonctionnent à un débit réel (la vitesse réelle avec laquelle
les bits sont envoyés sur le fil) pour mettre en œuvre les pare-feu, NAT, QoS ou
encore pour recueillir des statistiques. Cependant l'équipe OpenFlow a identifié un
ensemble commun de fonctions qui sont prises en charge par la plupart des
commutateurs et des routeurs. En identifiant cet ensemble commun de fonctions, un
moyen standard de manipulation de flux-de-tables peut être déployé pour tous les
périphériques réseau, indépendamment de leur mise en œuvre spécifique au
[27]
fournisseur . OpenFlow fournit ce moyen standard de manipulation de flux tables,
ce qui permet une partition de trafic réseau basé sur des flux. De cette façon, le trafic
réseau peut être organisé en différents flux qui peuvent être regroupées et isolées
afin d'être router, traités ou contrôlés de manière quelconque.[33]
OpenFlow est de grande utilité dans les réseaux de campus où l’isolement du
trafic de recherche et de production est une opération cruciale. Les flux peuvent être
créés et maintenus par une entité centralisée appelé le contrôleur. Le contrôleur peut
être étendu afin d'effectuer des tâches supplémentaires telles que le routage et les
décisions d'accès au réseau [27].
8
[26]
[Figure 2 : OpenFlow dans l’architecture d’OVS]
1.4 OPEN vSWITCH
1.4.1 DEFINITION
Historiquement, Nicira Network Inc qui a été fondé en 2007 (nicira.com) est le
créateur des projets Open Flow et Open vSwitch, 3 ans après, La première version
d’OVS a été relâchée. En Juillet 2012 cette boite a été racheter par VMware pour le
mentant de 1,2 M$ et cette dernière s’engage à continuer le support de la version
Open Source de la technologie qui ont permis aux solutions Nicira d’être un succès,
incluant la solution Open vSwitch.
Juin 2013 : VMware finalise son offre SDN basée sur la technologie de Nicira
Network pour le vCloud Hybrid Service, et s'oriente vers le marché du réseau virtuel
pour les futures capacités réseau offertes par la firme.
Open vSwitch est 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
9
les bons ports virtuels, alors que le module kernel permet de capturer le trafic
provenant des interfaces réseau, et d’y réinjecter le trafic légitime.
La différence entre VMware « vNetwork distributed switch » et Cisco « Nexus

1000v », ce sont des vSwitch dont la gestion, la configuration et la surveillance sont
effectuées avec une console centrale. « Open vswitch » n'est pas une vSwitch
distribuée. La gestion est locale sur la machine physique, mais supporte la gestion à
distance facilitant la tâche aux développeurs de plateforme de gestion de
virtualisation/Cloud. [40]
[Figure 3 : Les supporteurs d’Open vSwitch]
Donc, Open vSwitch est un commutateur logiciel multicouches,

multiplateformes et open source, il est offert sous la licence Apache 2.0, conçu pour
être utilisé comme un Switch virtuel dans des environnements de serveurs virtualités.
Un vSwitch transmet le trafic entre les différentes machines virtuelles sur le même
hôte physique et aussi transmet le trafic entre les machines virtuelles et le réseau
physique. Open vSwitch prend en charge les interfaces de gestion standard (par
exemple sFlow, NetFlow, IPFIX, RSPAN, CLI), et il est ouvert à l'extension
programmatique et de contrôle en utilisant OpenFlow et le protocole de gestion de
OVSDB. [24]
10
1.4.2 LES COMPOSANTS PRINCIPAUX D’OVS [30]
L’OVS se compose de trois composant principales:

1.4.2.1 ovsdb-server [31]:
La base de donnée d’OVS est l’endroit ou la configuration est enregistrée, la
base de donnée rétablit la configuration même après un redémarrage, c’est a dire
maintenir la configuration au niveau du commutateur elle est très semblable à une
base de donnée régulière.
Cette base de donnée support plusieurs opérations comme:
- Visualisation des bases de données est leurs schéma

- L’insertion dans la base de donnée (insert)
- La suppression de données (delete)
- la mis à jour (update & mutate)
La BDD Communique au gestionnaire et OVS-vswitchd avec protocole de

gestion (JSON-RPC)
1.4.2.1.1 Les principales tables dans La base de données

La Table ‘Bridge’ contiennent des entrées qui décrivent les commutateurs dans
l'instance Open vSwitch. Chaque pont contient un certain nombre de ports. Les ports
sont représentés dans la Table Port[12]. Ils représentent un port virtuel sur le
commutateur virtuel, dont les données peuvent circuler à travers. Ils sont également
utilisés comme ports en ce qui concerne les règles de OpenFlow. Chaque port peut
être liée à une interface qui est une interface du réseau réel, physique.
[Figure 4 : Les tables les plus utilisées]
11
[28]
[Figure 5 : Toutes les tables de la BDD]
1.4.2.2 ovs-vswitchd
- Composante de base dans le système:
- Communique avec le monde extérieur en utilisant OpenFlow.
- Communique avec ovsdb-serveur en utilisant le protocole de gestion.
- Communique avec module de noyau via netlink.
- Communique avec le système via l'interface abstraite netdev.
- Prise en charge des chemins de données (ponts) indépendants multiples .
- Met en œuvre la mise en miroir, collage, et VLANs par les modifications de la
même table de flux exposés à travers OpenFlow
- Vérifie les compteurs de flux de datapath pour gérer l'écoulement l’expiration et les
demandes stats.
1.4.2.3 openvswitch.ko (OVS Kernel Module)

- Kernel module c’est lui qui gère la commutation et le tunneling.
- cache Exact-match des flux.
- Conçu pour être simple et rapide:
- pas d’expiration de flux
- Ne sait rien de OpenFlow
12

[Figure 6 : Composants d’Open vSwitch]

1.4.3 LES OUTILS DE L'ESPACE UTILISATEUR
Les outils de l'espace utilisateur constituent une partie importante de l'Open

vSwitch. Ils fournissent une interface avec le commutateur, permettant la
configuration et la surveillance, deux utilitaires en espace utilisateur différents sont
utilisés: OVS-vsctl et OVS-ofctl.
OVS-vsctl est un outil pour commander le commutateur virtuel. Il fournit

également une interface conviviale pour la base de données (au contraire de ovsdb-
client qui ne permet que d'envoyer des demandes de JSON). Lorsque la commande
est appelée, il faudra un certain nombre de commandes, qu'il exécutera, si plus
qu’une seule commande est spécifié, les commandes doivent être séparés par ‘--’,
par exemple: ovs-vsctl add-br br0 -- add-br br1.

1.4.4 La signification de quelque commandes de OVS
COMMANDE SIGNIFICATION
add-br <name> - ajouter un Pont au commutateur virtuel,
<name>pour spécifier le nom du
commutateur.
del-br <name> - supprimer un Pont avec son nom
13
<name>
add-port <bridge> <interface> Ajouter un port au <bridge> connecté à

<interface>
set-controller <bridge> <controller> mis en place d’un the contrôleur de

<bridge> à <controller>.
set <table> <record> <key=value> mis en place un <key> à <value> à la

ligne ou l’identifiant est <record> (par
exemple, port qui utilise nom come
identifiant) dans <table>
create <table> <key=value> Insertion d’une ligne dans <table> ou la

clé des ligne <key> est égal à <value>
destroy <table> <record> mis en place <column> à une liste vide
de <record> dans <table>
clear <table> <record> <column> mis en place <column> à une liste vide
de <record> dans <table>
[Tableau 1 : Commandes d’Open vSwitch]
1.4.5 ARCHITECTURE OPEN vSWITCH REPRESENTANT LE TRAITEMENT

DES FLUX DE DONNEES
La figure ci-dessous représente les différentes voies de traitement en OvS. Les

deux éléments les plus importants sont le Daemon switch OVS-vswitchd qui
contrôle le commutateur et implémente le protocole OpenFlow, et Datapath, un
module de noyau qui met en œuvre la transmission des paquets réelles. Le module
noyau Datapath traite les paquets avec un système fondé sur des règles. Il conserve
un tableau de flux dans la mémoire qui associe les flux avec des actions. Un
exemple d'une telle règle est de transmettre tous les paquets avec une certaine
adresse MAC de destination à un port physique ou virtuel spécifique ou de jeter tous
les paquets en provenance ou destination d’une adresse IP spécifique. Ces règles
sont appelées FLUX, mais ils sont différents des règles OpenFlow comme un choix
de conception du module du noyau qui était de le garder aussi simple que possible
afin d'obtenir une haute performance.
14
[29]
[Figure 7 : voie de traitement d’OvS]
Un paquet qui peut être traité par une règle dans le Datapath prend le chemin rapide
et il est traité directement dans le module du noyau sans invoquer d'autres parties de
OvS. Figure 8 met en évidence ce chemin rapide avec une ligne rouge solide. Les
paquets qui ne correspondent à aucun flux dans le tableau de flux sont forcés sur le
chemin lent (ligne pointillée), qui copie le paquet à l'espace utilisateur et le transmet
au démon OvS. La voie lente est mise en œuvre par le démon vswitchd qui
fonctionne sur des règles OpenFlow. Les paquets qui prennent ce chemin sont
comparés aux règles OpenFlow qui peuvent être ajoutés par un contrôleur OpenFlow
externe ou via une interface de ligne de commande. Le démon dérive des règles de
chemin de données pour les paquets sur la base des règles OpenFlow et les installe
dans le module du noyau afin que les futurs paquets de ce flux peuvent prendre le
chemin rapide. Toutes les règles du Datapath sont associés à un délai d'inactivité. Le
tableau des flux dans le Datapath ne contient donc que les règles nécessaires pour
gérer les flux actuellement actifs, il agit comme un cache pour le tableau de flux de
OpenFlow plus grand et plus complexe dans la voie lente.
CONCLUSION
La virtualisation des réseaux est devenu un sujet d’actualité et un terrain de
batailles entre les grandes firmes malgré sa complexité et hétérogénéité.
Cette hétérogénéité n’a pas empêché les développeurs à rendre leurs plateformes
interopérable en développant des outils tel que OVS qui le permettent et bien sur par
la suite accélérer l’adoption du Cloud par les entreprises.
15
Dans le cadre de ce projet, nous avons choisi le standard WBEM (Web-Based
Enterprise Management), que nous détaillons dans le chapitre suivant, qui est dédiés
à la gestion des réseaux virtuels.
16
Chapitre II
GESTION WBEM
SOMMAIRE :
INTRODUCTION
2.1. L’ARCHITECTURE FONCTIONNELLE
2.2. LE MODÈLE D’INFORMATION COMMUN CIM
2.3. LE MODÈLE DE COMMUNICATION
CONCLUSION

GESTION WBEM CHAPITRE 2

INTRODUCTION
Les systèmes de réseaux existants deviennent de plus en plus complexe, donc
des solutions telles que Simple Network Management Protocol (SNMP) ne disposent
pas suffisamment de fonctionnalités.
Web Based Enterprise Management (WBEM), conçu par l’organisation
Distributed Managed Task Force (DMTF) en 1996, vise à résoudre l'un des principaux
problèmes des professionnels de l'informatique, il gère facilement le matériel
hétérogène.
La grande diversité de matériel, chacun avec sa propre interface de gestion
personnalisée, utilise plus de ressources et de temps à gérer. WBEM, avec ses
racines dans des technologies éprouvées, offre un cadre commun qui est adaptable
par des fournisseurs, des normes fondées, extensibles, réutilisables et hautement
adaptables aux nouveaux matériels. Tout cela se traduit par un chemin d'amélioration
de la réduction des coûts.
WBEM permet d’intégrer les autres outils de gestion existants comme SNMP et
CMIS en les présentant avec son propre système d’information en assurant ainsi
l’homogénéité des informations présentées aux applications de gestion. En juin 1998,
la tâche de standardisation de l'initiative a été remise au DMTF (Distributed
Management Task Force), consortium regroupant les entreprises concernées par le
projet.

2.1 L’ARCHITECTEUR FONCTIONNELLE
Toute approche de gestion excitante a sa propre terminologie, WBEM aussi a
défini sa propre terminologie, il spécifie des entités et leurs associe des rôles, ces
derniers vont définir la capacité d’une entité dans une interaction de gestion.[39]
2.1.1 ROLES :
A chaque entité on peut associer un ou plusieurs rôles qui sont les suivants :
- Client
- Serveur
- Producteur
- Consommateur
Les supports de communication associer à chaque rôle font la classification des
entités comme le montre la figure 9 :
18

[Figure 8 : les rôles des intervenants dans l’architecteur WBEM]
2.1.2 ENTITES [37]

Les entités dans l’architecteur WBEM sont les suivantes :
- L'application de gestion : aussi appelée client CIM, elle constitue l'interface entre le
domaine géré et le gestionnaire. Elle présente à ce dernier un accès aux informations
qu'elle récupère auprès du gestionnaire d'objets CIMOM.
- Le gestionnaire d'objets CIMOM (CIM Object Manager) :

Le cœur du serveur WBEM est le CIM Object Manager (CIMOM), il est chargé de
maintenir la base d’information de gestion MIB (MIB : Management Information Base),
CIMOM utilise les informations stockées dans le MIB pour les commandes et les
réponses entre les clients WBEM, et il offre aux applications de gestion une interface
d’accès à cette base.
- Le provider : Il agit comme un pilote et une interface entre le monde abstrait du

modèle et la caractéristique réelle du matériel et logiciel, Un provider permet la
traduction des informations CIM en actions ou en valeurs concrètes relatives aux
ressources qu'il gère[5]. Un provider possède donc deux interfaces : Une interface
native qui communique avec les ressources gérées pour lui transmettre les directives
et les requêtes d’informations demandées par le serveur CIMOM. Une interface CIM
qui communique avec le gestionnaire d'objet CIMOM qui traduit les informations et
réponses retournées par les ressources gérées en instances d’objets CIM.
- L'agent : Dans cette architecture, il représente la ressource gérée à laquelle est
attachée un provider WBEM. Il permet d'exécuter les opérations de gestion requises
par le gestionnaire.
19

[Figure 9 : Architecture WBEM]
2.2 LE MODELE D’INFORMATION COMMUN CIM

Le « Common Information Model (CIM) » est un modèle d'information qui sert à
représenter les entités et la relation entre eux. Il fournit une définition et structure
cohérente des informations de gestion en utilisant des techniques orientées objet. CIM
comprend des expressions pour les éléments communs qui doivent être clairement
présentées aux applications de gestion telles que les classes[3], les propriétés, les
méthodes et les associations. CIM utilise un ensemble de terminologie spécifique au
modèle et les principes de la programmation orientée objet. Le langage standard
utilisé pour définir des éléments de CIM dans un format de texte est Managed Object
Format (MOF) [38][39].
Le CIM unifie et étend les normes de gestion existantes (SNMP, DMI, CMIP, etc.)
CIM comporte cinq éléments principaux qui sont :
1- Un méta-modèle qui décrit les composants du modèle.
2- Un schéma de nommage des composants gérés.
3- Un langage du support pour la spécification des objets gérés.
4- Un modèle d’Information de référence servant de base a la spécification de
nouveaux composants gérés ainsi qu'un sous-ensemble représentant les objets
que tout serveur doit implémenter.
5- Un ensemble de recommandations sur l’intégration de modelés de l’information
issue d'autres approche.
20

Nous allons dans la suite de cette section décrire brièvement chacun de ces
composants, qui seront par la suite représenter de façon beaucoup plus détaillée.
2.2.1 LE META-MODELE [41]

Le méta-modèle est une définition formelle du modèle. Il définit les termes
utilisés pour exprimer le modèle et l'utilisation et la sémantique du modèle.
Les éléments du modèle sont Schémas, Classes, Propriétés et Méthodes[6]. Le
modèle prend en charge également des Indications et Associations comme des types
particuliers de classes et Références comme un type spécial de propriété[17]. Le reste
de cette section décrit chacun des éléments en détail.
2.2.1.1 Schéma : Un schéma est un groupe de classes avec un seul

propriétaire. Les schémas sont utilisés pour l'administration et la désignation de
la classe. Les noms de classe doivent être uniques dans leur schéma
propriétaire. Chaque nom de classe comprend le nom de schéma et suit ce
format : « Nomduschéma_NomduClass »
2.2.1.2 Classes : Une classe est un modèle ou prototype, qui définit les
propriétés et les méthodes communes à un type particulier d'objet. Chaque
classe CIM est un modèle pour un type d'élément géré. Les Classes contiennent
des propriétés qui décrivent les données de la classe, et les méthodes, qui
décrivent le comportement de la classe. Une classe doit appartenir à un seul
schéma et le nom de la classe doit être unique dans ce schéma. Un nom de
classe complet comprend le nom de schéma en utilisant le format suivant :
« Nomduschéma_ClassName »
2.2.1.3 Propriétés : Une propriété est une valeur utilisée pour désigner une
caractéristique d'une classe. Une propriété a un nom, type de données, la valeur
et le cas échéant une valeur par défaut. Une propriété qui n'a pas de valeur par
défaut est initialisée à nul.
2.2.1.4 Méthodes : Une méthode est une opération qui peut être exécuté.
Une classe peut avoir zéro ou plusieurs méthodes.
21

Une signature de méthode comprend un nom, type de retour, les
paramètres d'entrée en option et les paramètres de sortie en option. Le type de
retour de la méthode doit être connu (prédéfinit) par CIM, le type de retour ne
doivent pas être un tableau.
2.2.1.5 Qualificateurs : Les qualificateurs fournissent des informations
supplémentaires sur les classes, les associations, les indications, les méthodes,
les paramètres de la méthode, les propriétés ou les références.
2.2.1.6 Les Références : Une référence est une propriété de données de

type particulier qui est déclarée avec le mot clé de REF et le nom de la classe à
laquelle il se réfère.
Les associations définissent deux ou plusieurs propriétés de référence que
les propriétés clés qualifiés. Les références identifient les relations que les
associations définissent entre les classes.
2.2.1.7 Les associations : Une association est un type de classe qui

contient deux ou plusieurs références qui sont définies comme des propriétés
clés qualifiés. Les associations représentent les relations entre deux ou plusieurs
classes.
Les associations sont des classes qui ont le qualificatif Association. Comme
les associations sont des classes, ils établissent une relation entre les classes
sans affecter les classes liées.
2.2.1.8 Instances : Une représentation d'un objet géré qui appartient à une
classe particulière, c'est une occurrence particulière d'une classe ou d'une
association.
2.2.1.9 Indications : Une indication est la représentation active de la

survenance d'un événement. Les indications sont les classes qui ont le
qualificatif d'indication appliquée. Comme une indication est un type de classe, il
peut avoir des propriétés et des méthodes, et peut être définie de manière
hiérarchique. Les instances de l'indication sont transitoires et ne peuvent pas
être récupérées[19]. Les Indications ne peuvent être reçus en ayant souscrit pour
eux avant qu'ils ne surviennent.
22

Ces composants forment les éléments de base de la structure de l'information
dans l'approche CIM. Les relations entre ces composants sont données dans la figure
8 sous la forme d'un schéma UML[4].
[Figure 10 : Le meta-modele CIM]
2.2.2 CIM MANAGED OBJECT FORMAT (MOF)

Il y a plusieurs façons dont l'information de gestion CIM pourrait être représenté
pour échanger des informations. La spécification CIM définit un langage appelé
Managed Object Format (MOF).
Ce langage fournit une syntaxe et une sémantique en lien avec le mata-modèle
CIM permettant de spécifier tout composant du modèle (classes, association...)
2.2.3 BASE D'INFORMATIONS DE GESTION :

Le gestionnaire d'objets CIM (CIMOM) maintient une base d'information de
gestion (MIB) contenants les données relatives aux ressources du système géré.
Cette MIB est composée d'objets gérés CIM (classes et instances) et des
dépendantes entre ces objets.
2.2.4 ARCHITECTURE DE LA MIB :

La MIB est hiérarchisée sous forme d'un arbre, dans l'approche CIM, la
hiérarchie de la MIB est définie par un concept d'espace de nommage comme celui
23

des répertoires dans le système UNIX. Ainsi, dans l'arbre de la MIB, les espaces de
nommage forment les nœuds et les objets gérés les feuilles.
Un espace de nommage peut contenir, en outre des objets gérés, un seul ou
plusieurs espaces de nommage.
L'identification d'une instance : les instances d'objets sont identifiées par la liste
des noeuds parcourus depuis la racine jusqu'à l'objet ainsi que par un identificateur
local relatif au dernier noeud. Dans le modèle CIM, ceci se traduit par le nom absolu
de l'espace de nommage, ainsi que par les valeurs prises par certains attributs
discriminants dits attributs clefs (Key propretés).
La fig9 illustre l’architecteur dans l’approche WBEM :
[Figure 11 : Architecteur de la MIB dans WBEM]
2.2.5 LES CHEMINS DU MODELE COMMUN [41]:

Les schémas de gestion sont les blocs de construction pour les plates-formes de
gestion et d'applications de gestion, telles que la configuration de l'appareil, la gestion
du rendement et la gestion du changement[20]. Le CIM est structuré de telle manière
que l'environnement contrôlé peut être considéré comme un ensemble de systèmes
interdépendants, dont chacun est composé d'un certain nombre d'éléments discrets.
Le schéma CIM fournit un ensemble de classes et d'associations avec des propriétés
et des méthodes qui fournissent un cadre conceptuel bien défini au sein de lequel il
24

est possible d'organiser les informations disponibles sur l'environnement géré. Le
schéma CIM est la combinaison du modèle de base et du modèle commun.
2.2.5.1 Modèle de base :

Le Model de base regroupe des notions qui sont applicables à tous les domaines
de la gestion. Il est un ensemble de classes, associations, propriétés et des méthodes
qui fournissent un vocabulaire de base pour décrire les systèmes gérés. Il représente
un point de départ pour déterminer comment étendre le schéma commun.
2.2.5.2 Modèles communs :

Les modèles communs sont des modèles d'information qui regroupe les notions
qui sont communs à des domaines particuliers de gestion, mais indépendante de toute
technologie ou application particulière. Des exemples de modèles communs
comprennent les systèmes, les applications, les réseaux et les dispositifs. Les classes,
les associations, les propriétés et les méthodes dans les modèles communs sont
destinées à fournir une vue de la surface qui est suffisamment détaillée pour utiliser
comme base pour la conception du programme, et dans certains cas, la mise en
œuvre.[25]
2.2.5.3 Extension du schéma :

Les schémas d'extension représentent des extensions spécifiques à la
technologie des modèles communs. Ces schémas sont spécifiques à des
environnements tels que les systèmes d'exploitation. Il est prévu que les modèles
ordinaires vont évoluer à la suite de la promotion des objets et des propriétés définies
dans le Extension Schemas.
2.3 LE MODELE DE COMMUNICATION
Dans les années 2000, après un large manque dans le model de communication
entre les différentes entités d’une architecture WBEM, suite a la disparition du
protocole HMMP (Hyper-Media Management Protocol) qui été utilise pour
l’acheminement des information CIM, le DMTF a pu étouffer se manque en proposant
un couplage entre deux standard du marché du Web afin de transporter l’information
CIM d’une entité WBEM vers une autre. Le premier c’était le langage XML
25

(eXtensible Marhup Language) et le deuxième protocole HTTP (Hyper-Text
Transport Protocol)
En plus de ces deux standards, le DMTF propose un ensemble standard
d'opérations de gestion appelées opérations CIM permettant l'accès et la manipulation
des données CIM.
2.3.1 LE PROTOCOLE DE COMMUNICATION XML/HTTP [39]

Lorsque DMTF a proposé se Protocol, elle fait le couplage entre XML qui est
utilisé pour encoder l’information CIM et HTTP[2] pour le transport des data. La figure
suivant représente une communication client/serveur entre deux entités WBEM.
[Figure 12 : communication client/serveur WBEM]
Ici, quand le client va encoder des informations CIM et l’encapsuler et l’envoyer au

serveur via HTTP, le serveur va la décoder et l’encapsuler et vice versa.
26

[Figure 13 : Modules de communication WBEM]
2.3.2 LES OPERATIONS CIM
Les opérations CIM sont définies comme des appels de méthodes sur des objets
gérés. Ces appels seront traduits par des requêtes de bas niveau sur les véritables
entités gérées. Ces méthodes définissent un ensemble d'opérations qu'un client
WBEM met en œuvre pour qu’il opère de manière ouverte, standardisée. Les
Opérations WBEM sont des Protocol Independent.
Les Opérations WBEM peuvent être simple (individuel) ou des opérations
multiples (par lots). Les types d'opérations comprennent des données, des
métadonnées, des requêtes, et méthodes.
Deux types d'opérations CIM sont distingués par le DMTF : les opérations
extrinsèques et les opérations intrinsèques.
2.3.2.1 les opérations extrinsèques

Elles représentent les méthodes pouvant être invoquées sur n'importe quel type
d'objets. Ce sont les méthodes définies dans les classes CIM. Tout serveur WBEM est
supposé soutenir les méthodes extrinsèques, qui sont définies par le schéma pris en
charge par le serveur WBEM. Si un serveur WBEM ne supporte pas la méthode
27

extrinsèque, il renvoie le code d'erreur CIM_ERR_NOT_SUPPORTED à toute
demande d'exécution d’une méthode extrinsèque. Cela permet à un client WBEM de
déterminer que toutes les tentatives d'exécution des méthodes extrinsèques
échoueront.
Parmi ces méthodes extrinsèques on peut trouver :
- CIM_ERR_ACCESS_DENIED.
- CIM_ERR_NOT_SUPPORTED (Le serveur WBEM ne supporte pas la
méthode extrinsèques invoquées)
- CIM_ERR_INVALID_NAMESPACE.
- CIM_ERR INVALID_PARAMETER (y compris le manque, la duplication,
non reconnaissance des paramètres, autrement incorrects)
- CIM_ERR_NOT_FOUND (La classe CIM n’existe pas dans l'espace du
noms spécifié)
- CIM_ERR_METHOD _NOT_FOUND.
- CIM_ERR_METHOD NOT_AVAILABLE (Le serveur WBEM est incapable
d'effectuer la demande d'invocation.)
- CIM_ERR_FAILED (Une autre erreur inattendue est survenue.)
2.3.2.2 les opérations intrinsèques

Elles sont conçues pour être intégré dans le serveur CIM, orientées vers la
manipulation du modèle lui-même (récupération, suppression, création... pour
manipuler généralement des classes, des instances, des associations…) ces
opérations correspondent aux opérations de gestion classique de type M-GET et M-
SET.
Les opérations intrinsèques sont classifiées en 7 familles, leurs implémentations
dépendent du modèle fonctionnel. C'est à dire, chaque modèle fonctionnel d'un
système géré nécessite l'implémentation d'au moins une famille. Les familles
d'opérations sont :
2.3.2.2.1 Les opérations de lecture de base (Basic Read) : cette famille
regroupe des opérations de lecture simple des données comme son nom
l’indique, elle est maintenue par le gestionnaire d’objets CIMOM, parmi ces
opérations les plus importante nous citons :
2.3.2.2.1.1 GetClass : retourne une seule classe CIM dans
l'espace de nommage cible (prend en argument le nom de la
28

classe souhaitée)
2.3.2.2.1.2 EnumerateClasses : elle énumère les sous-classes
d'une classe CIM dans l'espace de nommage cible et retourne la
liste de toutes les classes définies dans cet espace.
2.3.2.2.1.3 GetInstance : elle renvoie une instance CIM unique à
partir de l'espace de nommage cible.
2.3.2.2.1.4 EnumerateInstance : elle énumère les instances
d'une classe CIM dans l'espace de nom cible, y compris les
instances dans la classe et toute sous-classes en fonction de la
nature polymorphique des objets CIM.
2.3.2.2.1.5 GetProperty : elle récupère une valeur de propriété
unique à partir d'une instance CIM dans l'espace de noms cible, si
la valeur est NULL, aucun élément ne sera retourné.
2.3.2.2.2 Les opérations d'écriture de base (Basic Write) :
cette famille d'opérations contient une seule opération qui est la
modification de la valeur d'une propriété d'une instance donnée.
Elle doit être implémentée dans tous les systèmes utilisant les
opérations de lecture de base. Cette opération est :
2.3.2.2.2.1 SetProperty : elle définit une valeur de propriété
unique dans une instance CIM dans l'espace de nommage cible.
2.3.2.2.3 Les opérations de manipulation de schémas (Schema

Manipulation) : elle regroupe les opérations qui permettent de créer,
supprimer ou modifier une classe dans l'espace de nommage cible. Cette
famille contient 3 opérations :
2.3.2.2.3.1 CreateClass : elle permet de crée une nouvelle et
unique classe CIM dans l'espace de nommage cible. La classe ne
doit pas déjà exister précédemment.
2.3.2.2.3.2 ModifyClass : modifie une classe CIM existante dans
l'espace de nommage cible. La classe doit déjà exister.
2.3.2.2.3.3 DeleteClass : elle supprime une seule classe CIM a la
fois, de l'espace de nommage cible.
2.3.2.2.4 Les opérations de manipulation d'instances (Instance
29

Manipulation) : ces opérations sont similaire a la famille précédente, on
trouve parmi ces opérations :
2.3.2.2.4.1 CreateInstance : elle crée une seule instance CIM
dans l'espace de noms cible. L'instance ne doit pas déjà exister.
2.3.2.2.4.2 ModifyInstance : elle modifie une instance de CIM
existante dans l'espace de noms cible. L'instance doit déjà exister.
2.3.2.2.4.3 DeleteInstance : elle supprime une instance CIM
unique à partir de l'espace de nommage cible.
2.3.2.2.5 Les opérations de parcours d'associations (Association

Traversal): Dans cette famille réside les opérations les plus puissantes qui
font la force de l’approche CIM/WBEM, car elles permettent de lancer des
requêtes sur des définitions et des instances d'associations (relations) entre
les objets CIM. Car a partir de l’argument donné par une instance définit, ou
par un nom d’une association, d’identifier la classe et toutes instances
dérivées associées à l’instance de départ. Comme exemple, il est possible
d’identifier tous les composants physiques et logiques d’un ordinateur
(instance de CIM_ComputerSystem) à travers les associations qu’il
possède avec les différentes classes (CIM_Processor, CIM_Memory,
CIM_NetworkPort etc.). parmi ces opérations on peut trouver :
2.3.2.2.5.1 Associators : elle énumère et retourne les objets CIM
(classes ou instances) associées à un objet source de CIM
particulier donné en argument, d’autres paramètres peuvent être
donnes pour spécifier l’association qui assure les relations, par
exemple ObjectName qui définit les paramètres de la source
d’objet CIM dont les objets associés doivent être retournés. Cela
peut être soit un nom de classe ou nom d'instance (chemin du
modèle), C'est à dire, ce paramètre permet d'afficher les objets qui
ont l'association donnée en paramètre, avec l'objet concerné.
2.3.2.2.5.2 AssociatorsName : elle énumère les noms des Objets
CIM (classes ou instances) qui sont associés à un objet CIM
source particulière.
2.3.2.2.5.3 References : elle énumère les objets d'association qui
se réfèrent à un objet cible particulière (classe ou d'instance).
30

2.3.2.2.6 Les opérations d'exécution de requêtes (Query Execution) :

elle permet de lancer des requêtes et de l’exécuter sur des objets
maintenus dans l'espace de nommage cible. Cette opération prend comme
arguments le nom du langage de la requête QueryLanguage suivi de la
requête de sélection elle même Query. WBEM définit pour le moment un
seul langage de requêtes appelé le CQL (CIM Query Language). Aussi,
cette opération reflète la puissance de l’approche CIM/WBEM.
2.3.2.2.7 Les opérations de déclaration de qualificateurs (Qualifiers

Declaration) : elle permettent de lancer des requêtes sur des
qualificateurs. Parmi ces opérations on retrouve :
2.3.2.2.7.1 GetQualifier : elle récupère une seule définition du
qualificateur de l'espace de nommage cible.
2.3.2.2.7.2 SetQualifier : elle permet la création ou la modification
d’une définition de qualificateur dans l’espace de nommage cible.
2.3.2.2.7.3 DeleteQualifier : permet la suppression de la définition
d’un qualificateur dans l’espace de nommage cilbe.
CONCLUSION
L’approche WBEM est un standard permettant la gestion homogène d'un ensemble de
ressources hétérogènes complexes (services, composants physiques, utilisateurs…)
Contrairement aux autres approches, WBEM prend en compte l'existence et le
déploiement de toutes les approches de gestion. Cette prise en compte signifie que
les objets gérés issus d'approches différentes sont vus comme des objets CIM
ordinaires, accessibles par n'importe quel client WBEM.
WBEM est considéré comme l'un des standards les plus prometteurs du domaine
grâce à sa puissance d’expression, aux diverses implémentations propriétaires et
open source et au soutient dont il bénéfice.
Plusieurs Implémentations de WBEM sont proposées par exemple nous citons :

- WMI (Windows Management Instrumentation) de Microsoft.
31

- Solaris WBEM Services software d’Oracle.
- OpenPegasus l'implémentation open source fourni par l’OpenGroup.
- SBLIM soutenu par IBM.
- OpenLMI de Fedora.
-
WBEM a été choisi pour la réalisation de se projet a cause de sa capacité de gérer
des entités complexes. De plus, l'interopérabilité offerte par WBEM a répondu à notre
besoin de réalisation d'un un système de gestion standardisé pouvant être intégré
dans d'autres systèmes.
32
Chapitre III
CONCEPTION DU SYSTEME
SOMMAIRE :
INTRODUCTION
3.1. L’ARCHITECTURE FONCTIONNELLE
3.2. MODELISATION CIM
CONCLUSION

CONCEPTION DU SYSTEME CHAPITRE 3

INTRODUCTION
Nous rappelons que l'objectif de ce travail est la Conception et réalisation d'un
outil de gestion normalisé dédié à la plate-forme de virtualisation des réseaux Open
Virtual switch. Pour atteindre notre objectif, nous utilisons le Web Based Enterprise
Management (WBEM), qui est conçu par le DMTF pour gérer le matériel informatique
hétérogène et qui satisfait nos besoins en terme de standard de gestion en offrant
les fonctionnalités de modélisations des entités utilisées en leurs associant leurs
rôles et règles dans le réseau.
Pour la réalisation de notre Provider de Controle, le Framework CIMPLE qui est
Open Source, a été choisi a cause de ces avantages :
• Réduction considérablement des efforts de développement, en raison de
la génération de code.
• Il favorise la sécurité et offre la possibilité de modification/correction du
programme.
• La complexité du codes sources est réduite ce qui implique une bonne
maitrise et compréhension.
• Interopérabilité avec plusieurs serveurs CIM comme c’est explique dans
la figure suivante :
[Figure 14 : Multiples serveurs CIM-OM]
Pour le serveur CIM-OM, OpenPegasus a été choisi sur une plateforme Fedora.
OpenPegasus est un standard codé en C++ par DMTF conçu pour être portable est
hautement modulaire.
34

3.1 ARCHITECTURE FONCTIONNELLE [37]
Pour représenter l’architecture de gestion de notre notre travail, nous avons défini
quelques éléments principaux qui sont détaillés et illustrés en bas comme suit :
• CIM Object Manager (CIMOM): C’est le cœur du serveur WBEM, Il utilise les
information stocker dans le CIM Object Repository (CIMOR), pour commander
directement le client et le provider.
• Client: Il peut interagir avec CIMOM pour manipuler le modèle tel qu’il est
demandé par l’opérateur. Dans notre cas le client peut interroger la base de
donnée OVSBD ou CIMOR pour la supervision, comme il peut créer des
ports, bridges, interfaces virtuels…
• CIM Obejct Repository (CIMOR): C’est l’entité qui stocke la configuration et
caractéristique d’objet géré et permet de les lire plus tard.
• Provider : Il agit comme une interface entre le monde abstrait du modèle et
les caractéristiques désordonnées de biens matériels et logiciels. Dans notre
cas le provider traduit les commandes provenant depuis le client en format
CIM/OVS, et aussi il assure la traduction inverse OVS/CIM.
• L’application Open vSwitch : Représente le switch virtuel, l’application des
configurations et commandes donnés par le client est assuré par cette entité.
[Figure 15 : Architecture de Système de gestion]
35

Dans cette architecture, le client peut contrôler la couche L2 de OVS et aussi la
superviser. Lors de la définition d’un nouveau réseau, les données de configurations
sont stockées dans le CIMOR maintenue par le serveur WBEM par l’intermédiaire du
CIMOM. Par la suite, notre Provider que nous avons développé intervient en
traduisant ces données de configurations en langage d’Open vSwitch. Ce Provider
peut aussi faire le travail inverse.
3.2 MODELISATION CIM

Le schéma des Classes du Virtual Ethernet switch qui est proposé ci-dessous,
décrit les éléments qui appartiennent ou qui sont spécialisés par ce profil, ainsi que
les relations de dépendance entre les éléments de ce profil et d'autres profils. Pour
plus de simplicité dans les diagrammes.
Dans la terminologie CIM, on appelle un schéma, tout modèle (ou un ensemble

de modèle) proposé par une organisation pour satisfaire ses besoins en terme de
gestion. Tout les noms des classes appartenant à un schéma donné, comportent un
préfixe commun appelé schéma spécifique. Par exemple, les noms des classes
appartenant aux modèles CIM proposés par le DMTF commencent tous par le
schéma spécifique "CIM_". Ainsi, pour notre modèle, nous avons défini « OVS_ »
comme schéma spécifique. Ceci implique que toutes nos classes commencent par le
préfixe : « OVS_ »
L'objectif principal de conception de ce profil est qu'un commutateur Ethernet

virtuel et ses composants apparaissent à un client comme un système virtuel avec
des fonctionnalités dévouées. De multiple tâches de gestion telles que la
supervision, l'énumération, l'analyse, la commande ou la configuration d'un
commutateur Ethernet doivent être activés sans exiger au client de comprendre les
aspects spécifiques d'un commutateur Ethernet.
La figure 15 représente le Diagramme de classe du model du Virtual Ethernet Switch

que nous allons implémenter par la suite :
36

[Figure 16 : Le Profile du Virtual Switch Ethernet et le Diagramme des classes]
3.2.1 CLASSES ET ASSOCIATIONS DE NOTRE PREMIER PROFILE

Ce profil indique l'utilisation des classes et des associations suivantes, nous
commençons par détailler les classes avec leurs propriétés ensuite juste après les
associations :
3.2.1.1 LES CLASSES [18][42]
3.2.1.1.1 OVS_ComputerSystem
Elle représente un commutateur Ethernet virtuel ou un commutateur Ethernet
intégré. Une instance de la classe OVS_ComputerSystem doit exister pour
chaque commutateur Ethernet qui est conforme à ce profile[9]. Nous allons
utiliser la Propriété DEDICATED qui est détailler comme suit :
3.2.1.1.1.1 DEDICATED
C’est une énumération qui indique l’objet auquel le système est dédié, par
exemple :
« Virtual Hub » : valeur 8.
37

« Virtual Switch » : valeur 38, et qui est le matériel principal de notre
conception.
3.2.1.1.2 OVS_NetworkVLAN
Représente une collection de paramètres VLAN qui sont membres du même
VLAN.
3.2.1.1.3 OVS_LANEndpoint
Représente le point d'extrémité de communication Ethernet du
[16]
OVS_EthernetPort . Lorsque le dispositif d'interface associé est connecté à
un réseau local, peut envoyer et recevoir des trames de données[8].
3.2.1.1.4 OVS_EthernetPort
Représente un port de commutateur Ethernet. Ses propriétés sont détaillées
comme suite :
PROPRIETES
La classe OVS_EthernetPort possède ces propriétés :
3.2.1.1.4.1 Capabilities
- Data type: uint16 array
- Access type: Read-only
Capacités du port Ethernet. Par exemple, le dispositif pourrait soutenir
AlertOnLan, WakeOnLan, équilibrage de charge, ou FailOver. Si le
basculement ou l'équilibrage de charge des capacités sont répertoriés, un
SpareGroup (failover) ou ExtraCapacityGroup (équilibrage de charge/ load
balancing) doivent également être définies pour décrire complètement la
capacité.
Unknown (0)
Other (1)
AlertOnLan (2)
WakeOnLan (3)
FailOver (4)
LoadBalancing (5)
38

3.2.1.1.4.2 CapabilityDescriptions
- Data type: string array
Un tableau de chaînes de forme libre qui fournit des explications plus
détaillées pour l'une des caractéristiques du port Ethernet qui sont indiqués
dans le tableau des capacités.
3.2.1.1.4.3 EnabledCapabilities
- Data type: uint16 array
Indique quelles capacités sont activées dans la liste de ceux pris en charge,
qui sont définis dans le tableau des capacités.
Unknown (0)
Other (1)
AlertOnLan (2)
WakeOnLan (3)
FailOver (4)
LoadBalancing (5)
.
3.2.1.1.4.4 NetworkAddresses
- Data type: string array
- Qualifiers: MaxLen ( 64)
Un tableau de chaînes indiquant les adresses réseau pour le port.
Les adresses de réseau sont des adresses "Ethernet / 802.3 MAC" formatés
comme douze chiffres hexadécimaux, chaque paire représentant l'un des six
octets de l'adresse MAC
3.2.1.1.4.5 PermanentAddress
- Data type: string
- Qualifiers: MaxLen ( 64)
L'adresse qui est accordée dans un port réseau.
39

3.2.1.1.4.6 PortNumber
- Data type: uint16
Les ports réseau sont souvent numérotés par rapport à soit un module logique
ou à un élément de réseau.
3.2.1.1.4.7 Speed
- Data type: uint64
- Qualifiers: Override, Units ( "Bits per Second" )
La bande passante actuelle du port en bits par seconde. Pour les ports qui
varient en bande passante ou pour ceux qui n’ont pas d’estimation précise,
cette option ne peut pas être faite.

3.2.1.1.5 OVS_VLANEndpoint
Un point d'extrémité sur un commutateur est affecté à un VLAN donné ou
accepte le trafic d'un ou plusieurs VLANs, Tel que défini par la propriété,
OperationalEndpointMode. Ses propriétés sont détaillées comme suite :
PROPRIETES
La classe CIM_VLANEndpoint possède ces propriétés :
3.2.1.1.5.1 DesiredEndpointMode
- Data type: uint16
- Access type: Write-only
Le mode VLAN est donnée par la propriété OperationalEndpointMode. Les
valeurs citées en bas sont définies:
• Access: met le point d’extrémité/port-du-commutateur en mode nontrunking
permanent et négocie pour convertir le lien dans un lien nontrunk.
• Dynamic Auto: Rend le point d'extrémité capable de convertir le lien en
Trunk, le point d'extrémité devient un Trunk si l’interface voisine est réglée en
mode Trunk a son tour.
40

• Dynamic Desirable: permettre au extrémité de convertir manuellement le lien
en trunk. Le point d'extrémité devient une interface Trunk si l'interface voisine
est réglée sur le mode Trunk. Le mode par default de tout les ports du
commutateur est « dynamic desirable »
• Trunk : met le point d'extrémité en mode trunking permanent et négocie pour
convertir le lien en TRUNK. Le point d'extrémité devient une interface Trunk,
même si l'interface voisine est pas en mode Trunk.
• Dot1Q Tunnel : configure l’interface pour permettre au lien d’être asymétrique
avec un mode Trunk. Il est utilisé pour maintenir l'intégrité du réseau local
virtuel de client à travers un réseau de fournisseur de services.
DMTF Reserved (0)

Other (1)
Access (2)
Dynamic Auto (3)
Dynamic Desirable (4)
Trunk (5)
Dot1Q Tunnel (6)
3.2.1.1.5.4 OperationalEndpointMode
- Data type: uint16
- Access type: Write-only
Le mode de configuration pour le point d'extrémité du VLAN, les valeurs citées

en bas sont définies comme suite :
• Access : Met le point final en mode NON TRUNK permanent et négocie pour
convertir le lien dans un lien NON TRUNK. Le point d’extrémité devient une
interface NON TRUNK.
• Dynamic Auto : Rend le point d'extrémité capable de convertir le lien vers un
lien Trunk. L'extrémité devient une interface Trunk si l'interface voisine est
réglé sur Trunk.
• Dynamic Desirable : permettre au extrémité de convertir manuellement le lien
en trunk. Le point d'extrémité devient une interface Trunk si l'interface voisine
41

est réglée sur le mode Trunk. Le mode par default de tout les ports du
commutateur est « dynamic desirable »
• Trunk : met le point d'extrémité en mode trunking permanent et négocie pour
convertir le lien dans un lien de tronc. Le point d'extrémité devient une
interface Trunk, même si l'interface voisine est pas en mode Trunk.
• Dot1Q Tunnel : configure l’interface pour permettre au lien d’être asymetrique
avec un mode Trunk. Il est utilisé pour maintenir l'intégrité du réseau local
virtuel de client à travers un réseau de fournisseur de services.
DMTF Reserved (0)

Other (1)
Access (2)
Dynamic Auto (3)
Dynamic Desirable (4)
Trunk (5)
Dot1Q Tunnel (6)
3.2.1.1.6 OVS_VLANEndPointSettingData
Représente les données de configuration pour les instances
OVS_VLANEndpoint.
3.2.1.1.7 OVS_ConnectivityCollection
Représente une collection de OVS_LANEndpoints qui sont en mesure de
communiquer les uns avec les autres.
3.2.1.1.8 OVS_VirtualEthernetSwitchSettingData
Spécialise la classe OVS_VirtualSystemSettingData pour ajouter des aspects
spécifiques au commutateur Ethernet virtuel[10].
3.2.1.1.9 OVS_ResourcePool
Représente une entité logique (avec les contrôles associés) fournies par le
système hôte afin de l'attribution et l'affectation des ressources. Elle peut être
utilisé pour allouer des ressources d'un type spécifique. Pour notre cas, nous
allons utilisées la propriété suivante :
42

PROPRIETES
La classe OVS_ResourcePool possède ces propriétés :
3.2.1.1.9.1 ResourceType
Indique le type de ressource que ResourcePool peut allouer. Dans notre cas
nous allons prendre le 33 et le 30, pour l’allocation des ports et des
connexions entre les Machines virtuel[7]. D’autres types ressources peuvent
être utilisées, ils sont cités comme suit :
Other (1)
Computer System (2)
Processor (3)
Memory (4)
IDE Controller (5)
Parallel SCSI HBA (6)
FC HBA (7)
iSCSI HBA (8)
IB HCA (9)
Ethernet Adapter (10)
Other Network Adapter (11)
I/O Slot (12)
I/O Device (13)
Floppy Drive (14)
CD Drive (15)
DVD drive (16)
Serial port (17)
Parallel port (18)
USB Controller (19)
Graphics controller (20)
Storage Extent (21)
Disk (22)
Tape (23)
Other storage device (24)
Firewire Controller (25)
43

Partitionable Unit (26)
Base Partitionable Unit (27)
Power Supply (28)
Cooling Device (29)
Allocation Port (30)
Allocation V.S Connexion (31)
3.2.1.1.10 OVS_EthernetPortAllocationSettingData
Il représente les paramètres spécifiques liés à l'attribution d'un EthernetPort

qui sont en dehors du champ d'application de la classe CIM elle-même[11].
Ces paramètres sont utilisés pour fournir des informations spécifiques à la
ressource elle-même. Parmi ces propriétés, nous allons utilisée :
3.2.1.1.10.1 DesiredVLANEndpointMode
Il est utilisé pour définir la valeur initiale de la propriété

OperationalEndpointMode dans l'instance de OVS_VLANEndpoint.
3.2.1.1.11 OVS_RegisteredProfile
Elle est utilisé pour modéliser la conformité avec les profiles du CIM de base
proposé par DMTF.
3.2.1.2 Les Association
• La classe OVS_RegisteredProfile et l'association ElementConformsToProfile

sont utilisés pour modéliser la conformité avec ce profil[18].
• L'association SystemComponent est utilisée pour modéliser la relation entre la

ressource hôte du système de virtualisation de type de ressource 33 (connexion
Ethernet) et le commutateur virtuel Ethernet représenté par la classe
OVS_ComputerSystem à laquelle les connexions Ethernet des ressources
peuvent être faites. Les ressources de connections Ethernet sont utilisés pour
44

l'attribution d'une connexion entre un port Ethernet, qui fait généralement partie
d'un système virtuel, et un port de commutateur Ethernet.
• L'association HostedCollection est utilisée pour modéliser la relation entre le

commutateur virtuel Ethernet représenté par la classe OVS_ComputerSystem à
chaque instance OVS_NetworkVLAN qui représente un VLAN disponible dans
le commutateur. Il est également utilisé pour modéliser la relation entre le
système hôte représenté par la classe OVS_ComputerSystem à chaque
OVS_ConnectivityCollection.
• L'association VirtualSystemSettingDataComponent est utilisée pour modéliser

l'agrégation des instances de la classe OVS_EthernetPortAllocationSettingData
à une instance de la classe OVS_VirtualEthernetSwitchSettingData, formant
une configuration virtuelle de commutation Ethernet.
• L'association SettingsDefineState est utilisé pour modéliser la relation entre

une instance de la classe OVS_ComputerSystem représentant un commutateur
Ethernet virtuel et une instance de la classe
OVS_VirtualEthernetSwitchSettingData représentant des aspects spécifiques à
la virtualisation de ce commutateur Ethernet virtuel.
• L'association ElementSettingData est utilisé pour modéliser la relation entre

un élément et les données de configuration applicable à l'élément.
CONCLUSION
Dans se chapitre nous avons présenter et expliquer l’approche de conception de
notre système standardiser, conforme au model CIM de base du profile du « Virtual
Switch Ethernet » de la gestion de la couche L2 du réseau virtuel. La classe
principale du model est « OVS_ComputerSystem » qui représente la plateforme
OVS.
Dans le dernier chapitre de se travail, nous allons implémenter notre model sur un
système Linux Fedora 23, Cette implémentation se traduit par l'installation d'une
plateforme de gestion WBEM (client/serveur) ainsi que des outils nécessaires pour le
développement des providers chargés de gérer les classes du modèle.
45
Chapitre IV
RÉALISATION DE NOTRE SYSTÈME DE GESTION
SOMMAIRE :
INTRODUCTION
4.1. LES CHOIX TECHNIQUES

4.2. IMPLEMENTATION
4.3. DETAILS DE PROGRAMMATION
CONCLUSION

RÉALISATION DE NOTRE SYSTÈME DE GESTION CHAPITRE 4

INTRODUCTION
Ce chapitre présente les différentes étapes d’implémentation de notre système.
Cette implémentation prouve la possibilité de gérer la gestion en format CIM de la
couche L2 de l’OVS, en assurant son contrôle et sa supervision.
Les phases e développement de notre Provider sont relatées comme suit :

• Les choix techniques utilisés permettant la programmation et la mise en place
de notre Provider.
• IMPLEMENTATION
• DETAILS DE PROGRAMMATION
4.1 LES CHOIX TECHNIQUES

Afin d'implémenter notre système, nous avons choisi comme plateforme un
environnement LINUX FEDORA 23. Comme il est possible de choisir n’importe
qu’elle système de la famille linux qui supporte l’OVS. Pour l’implémentation de
l’ensemble des composants de l’architecture WBEM, ainsi que les points de gestion
de notre architecture y compris (CLIENT CIM, CIMOM et CIMOR), nous avons opté
pour le projet OpenPegasus 2.14.1 fournit par l’OpenGroup.
Pour le développement de notre Provider CIM, nous avons choisi le Framework de
développement CIMPLE 2.0.24 dédié à la programmation de providers et de clients
CIM. Cet outil facilite énormément l’implémentation par la génération de squelettes
de programmes en C++ à partir de la définition en MOF des classes CIM relatives
aux ressources cibles. La puissance de ce Framework se situe en son approche qui
consiste à générer des classes C++ qui correspondent aux classes MOF, et la
génération des squelettes des méthodes intrinsèques et extrinsèques. Le travail du
développeur consiste à coder les méthodes en fonction des ressources visées par
notre Provider.
Pour l’instrumentation de l’OVS a travers notre les méthodes de notre Provider,
nous avons développer notre propre code écrit e langage C et par la suite l’intégrer
dans les squelettes de programmes C++ génères par CIMPLE.
4.2 IMPLEMENTATION
Notre provider est formé de plusieurs modules dont chacun permet de gérer une
classe de notre modèle, il interagit directement avec Open vSwitch,
47

Nous allons implémenter le provider pour la class OVS_NetworkVLAN qui assure la
création, suppression et supervision des VLAN créés par l’OVS, pour cela nous
avons utiliser les méthodes suivantes :
• CreateInstance utilisé pour créer un seul CIM instance dans le CIMOR.

• GetInstance Permet de retourner une instance dans le CIMOR.
• DeleteInstance Permet de supprimer une instance du CIMOR
Les principales propriétés de la class OVS_NetworkVLAN sont les suivantes :

• VLANId : Un ID du VALN de 12 bits.
• VLANName : Nom du VLAN.
4.3 DETAILS DE PROGRAMMATION

La classe OVS_NetworkVLAN fait partie des principales classes de notre
architecture, nous allons détailler ces points de programmation dans la section
suivante.
4.3.1 DEFINITION DE CLASSE EN FORMAT MOF
Nous avons défini la classe OVS_NetworkVLAN en langage MOF (Managed Object
Format) de la manière suivante :
Description (
"An instance of NetworkVLAN represents a collection of "
"VLANSwitchEndpoints and/or VLANEndstationEndpoints
which are "
"members of the VLAN. " )]
class OVS_NetworkVLAN : CIM_ConnectivityCollection {
[Description ( "A 12-bit VLAN ID used in the VLAN Tag header."

),
MinValue ( 1 ),
MaxValue ( 4094 ),
MappingStrings { "MIB.IETF|Q-BRIDGE-MIB.VlanId" }]
uint16 VLANId;
.
.
.
.
[Description (
"A string describing the type of media that is supported "
"by this VLAN, when the value of the Type property is set
"
"to 1 (i.e., \"Other\"). This property should be set to "
48

"NULL when the Type property is any value other than 1."
),
ModelCorrespondence { "CIM_NetworkVLAN.TypeOfMedia" }]
string OtherTypeDescription;
}; //end
Ce code est enregistré dans un fichier .mof, et sera utiliser pout générer le code en
langage c++.
4.3.2 GENERATION DU PROJET EN C++

En utilisant le Framework CIMPLE, nous avons généré la classe OVS_NetworkVLAN
en langage C++ en utilisant la commande suivante :
# genproj SELProvider OVS_NetworkVLAN
Cette commande génère tous les fichiers permettant la programmation du Provider
4.3.3 L’AJOUT DES CODES DES METHODES
Quand nous avons utilisé la commande genproj un fichier nommé

OVS_NetworkVLAN_Provider.cpp a été généré, nous allons intégrer notre code dans
ce fichier pour qu’il fasse le travail souhaité.
Par exemple pour afficher tous les bridges créés par l’OVS nous utilisons la méthode
Get_Instance de la class OVS_NetworkVLAN :
Get_Instance_Status OVS_NetworkVLAN_Provider::get_instance(
const OVS_NetworkVLAN* model,
OVS_NetworkVLAN*& instance)
{
system(“ovs-vsctl list bridge”);
return GET_INSTANCE_OK;
}
49

4.3.4 COMPILATION DU PROVIDER
La génération du provider ne se fait qu'après la programmation de tous les modules
de ce dernier. Le Provider est généré sous forme de librairie (.so)
La figure suivante résume les étapes de la programmation de notre Provider :
[Figure 17 : étapes de programmation de notre Provider]
La compilation du Provider a été faite après la génération et l'adaptation de toutes les

classes C++ de notre modèle, pour générer une bibliothèque nommée
LibOVS_NetworkVLAN_Provider.so
Cette bibliothèque représente le cœur de notre travail car, après son enregistrement
au niveau d'un serveur WBEM, n'importe quel client pourra invoquer les méthodes
qu'elle contienne pour la gestion en format CIM.
50

CONCLUSION
Pour la réalisation de notre Provider qui représente le noyau de notre travail en
forme de bibliothèque (.so) nous avons utiliser l’environnement Fedora et
l’implémentation des classes a été réaliser par le serveur OpenPegasus qui
représente l’environnement de gestion WBEM. Cette bibliothèque pourra être
enregistrer dans les CIMOR des serveur WBEM par l’intermédiaire du CIMOM
comme expliqué précédemment.
51

CONCLUSION GENERALE et PERSPECTIVES
Ce document représente la Conception et réalisation d'un outil de gestion normalisé

dédié à la couche L2 de la plate-forme de virtualisation des réseaux Open Virtual
switch, qui représente une adaptation du standard CIM/WBEM a l’OVS. La
réalisation de se document montre la possibilité de superviser et contrôler la couche
L2 de l’OVS en format CIM.
Vue la complexité et l’hétérogénéité du Cloud, en raison de la diversité des

technologies des grandes firmes informatiques qui les exploite, la DMTF a été créer
dans le but de rendre se domaine homogène a l’utilisateur, vu sa position et sa force
qui le rend indispensable dans la vie quotidienne.
Dans le cadre de notre projet nous avons adapté l’implémentation logiciel d’un
Switch Ethernet Virtuel OVS au standard CIM/WBEM en prenant compte des
exigences de la DMTF et les spécifications du Système proposé précédemment. Une
profonde et longue étude sur OVS a permis de comprendre son fonctionnement et
faire par la suite sa correspondance avec l’architecture CIM/WBEM.
L’étude aussi du standard CIM/WBEM a permis d’atteindre la réalisation de notre

architecture qui est présenté dans le chapitre 3 et qui représente l’équivalent du
Virtual Ethernet Switch. Nous avons procédé à son implémentation en commençant
par l’installation de l’environnement de gestion WBEM (via le projet OpenPegasus) et
par la suite nous avons essayer de développer des Provider pour le contrôle de la
couche L2 de l’OVS.
Comme perspective, nous voulons approfondir notre travail de recherche sur la

couche L3 de l’OVS et essayer de proposer par la suite une standardisation d’un
switch distribué et par la suite une zone démilitarisée ou DMZ et cela, bien sur, en
se basant les bases que nous avons appris sur l’OVS et le standard CIM/WBEM.
BIBLIOGRAPHIE
Articles :
[1] DMTF DSP0004, CIM Infrastructure Specification 2.6, 17-03-2010.

www.dmtf.org/standards/published_documents/DSP0004_2.6.pdf
[2] DMTF DSP0200, CIM Operations over HTTP 1.3, 29-07-2009.

http://www.dmtf.org/standards/published_documents/DSP0200_1.3.pdf
[3] DMTF DSP1001, Management Profile Specification Usage Guide 1.0, 05-08-2009.
[4] DMTF DSP1033, Profile Registration Profile 1.0, 31-07-2007.

[5] DMTF DSP1041, Resource Allocation Profile 1.1, 25-06-2009.

[6] DMTF DSP1042 System Virtualization Profile 1.0, 22-04-2014.

[7] DMTF DSP1043, Allocation Capabilities Profile 1.0, 22-06-2009.

[8] DMTF DSP1050, Ethernet Port Resource Virtualization Profile 1.1, 21-06-2012.
[9] DMTF DSP1052, Computer System Profile 1.0, 22-05-2014.

[10] DMTF DSP1057, Virtual System Profile 1.0, 22-04-2010.

[11] DMTF DSP8049, Network Port Profile Schema, 10-10-2012.

http://schemas.dmtf.org/ovf/networkportprofile/1/dsp8049_1.0.0.xsd
[12] IEEE 802.1Qbg - Virtual Bridged Local Area Networks - Amendment XX: Edge Virtual Bridging
http://www.ieee802.org
[13] ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards
http://isotc.iso.org/livelink/livelink.exe?func=ll&objId=4230456&objAction=browse&sort=subtyp e
[14] DMTF DSP0243, Open Virtualization Format 1.1, 12-01-2010.

http://www.dmtf.org/sites/default/files/standards/documents/DSP0243_1.1.0.pdf
[15] DMTF DSP0243, Open Virtualization Format 2.0, 13-12-2012.
[16] DMTF DSP1014, Ethernet Port Profile 1.0, 15-09-2010.
[17] DMTF DSP1059, Generic Device Resource Virtualization Profile 1.0,15-07-2007.

[18] DMTF DSP1097, Virtual Ethernet Switch Profile 1.1, 21-06-2012.

[19] DMTF DSP2013, Virtualization Management White Paper 1.0, 11-11-2007.

[20] DMTF DSP2017, Open Virtualization Format White Paper 1.0, 02-06-2009.
[21] Patricia Thaler, Norman Finn, Don Fedyk, Glenn Parsons, Eric Gray. March 10, 2013. Media
Access Control Bridges and Virtual Bridged Local Area Networks. IEEE 802.1Q
https://www.ietf.org/meeting/86/tutorials/86-IEEE-8021-Thaler.pdf
[22] ETSI GS, Network Functions Virtualisation (NFV); Infrastructure; Network Domain, 2014
http://www.etsi.org/deliver/etsi_gs/NFV-INF/001_099/005/01.01.01_60/gs_NFV-
INF005v010101p.pdf
[23] Standard for Local and metropolitan area networks – Media Access Control (MAC) Bridges and
Virtual Bridged Local Area Networks – Amendment xx: Edge Virtual Bridging. IEEE
P802.1QbgTM-20xx
http://www.ieee802.org/1/files/public/docs2010/new-seaman-1AE-markup-for-gcm-aes-256-0710-
v2.pdf
[24] Simon Horman. An Introduction to Open vSwitch. LinuxCon Japan, Yokoham. 2nd June 2011.
http://openvswitch.org/slides/openvswitch.en-2.pdf
[25] DMTF DSP0004, Common Information Model (CIM) Infrastructure, 22-04-2012

[26] Sylvain Lavoie, Open vSwitch, Desjardins, Janvier 2014

http://docplayer.fr/1818577-Open-vswitch-janvier-2014-sylvain-lavoie-sylvain-lavoie-desjardins-
com.html
[27] Maxence Tury . Les risques d’OpenFlow et du SDN

http://www.ssi.gouv.fr/uploads/2015/06/SSTIC2015-Article-risques_openflow_et_sdn-tury.pdf
[28] Open vSwitch Manual ovs-vswitchd.conf.db.

http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf
[29] Paul Emmerich, Daniel Raumer, Florian Wohlfart, and Georg Carle. Performance Characteristics
of Virtual Switching, Technische Universitat Munchen, Department of Computer Science, Network
Architectures and Services
http://www.net.in.tum.de/fileadmin/bibtex/publications/papers/Open-vSwitch-CloudNet-14.pdf
[30] Ben Pfaff, Justin Pettit, Teemu Koponen, Ethan J. Jackson, Andy Zhou, Jarno Rajahalme, Jesse
Gross, Alex Wang, Jonathan Stringer, Pravin Shelar, Keith Amidon†, Martin Casado. The Design
and Implementation of Open vSwitch. May 4–6, 2015 • Oakland, CA, USA
https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-pfaff.pdf
[31] B. Pfaff. B, Davie, Ed,The Open vSwitch Database Management Protocol. VMware, Inc.
December 2013
https://tools.ietf.org/html/rfc7047
[32] Wenfeng Xia, Yonggang Wen, Senior Member, IEEE, Chuan Heng Foh, Senior Member, IEEE,
Dusit Niyato, Member, IEEE, and Haiyong Xie, Member, IEEE. A Survey on Software-Defined
Networking. IEEE COMMUNICATION SURVEYS & TUTORIALS, VOL. 17, NO. 1, FIRST
QUARTER 2015
http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6834762
Thèses
[33] Christopher Lorier, Techniques for Failure Recovery in a Software-Defined Network, University of
Waikato, August 18, 2014
http://wand.net.nz/~brad/papers/ChrisLorier-
Techniques_for_Failure_Recovery_in_a_Software_Defined_Network.pdf
[34] N.M. Mosharaf Kabir Chowdhury and Raouf Boutaba. Network Virtualization: State of the Art and
Research Challenges. University of Waterloo
www.dev.qmp.cat/attachments/download/31/NetworkVirtualization.pdf
[35] Dmitry Drutskoy. Scalable Network Virtualization in Software-Defined Networks. Princeton

University, Eric Keller Jennifer Rexford University of Pennsylvania Princeton University
https://www.cs.princeton.edu/~jrex/papers/ieeeinternet12.pdf
[36] Networks Rogerio V. Nunes, Raphael L and Dorgival Guedes Pontes. Virtualized Network
Isolation Using Software Defined Networks, Department of Computer Science Universidade
Federal de Minas Gerais Belo Horizonte, MG – Brazil. 2013
http://ieeexplore.ieee.org.www.sndl1.arn.dz/stamp/stamp.jsp?tp=&arnumber=6761310
[37] Chris Hobbs. A Practical Approach to WBEM/CIM Management Book. 2004

https://www.amazon.com/Practical-Approach-WBEM-CIM-Management/dp/0849323061
[38] MALEK Mohamed SEMMAR Mehdi. Conception et réalisation d'un système standardisé de

gestion de politiques de sécurité,
http://dl.cerist.dz/bitstream/handle/CERIST/761/Mémoire%20SEMMAR%20%26%20MALEK%20
N°034-2015-SSI-Final.pdf?sequence=1&isAllowed=y
[39] Olivier Festor, Nizar Ben Youssef. WBEM, 21 avril 2000

www.opac.inria.fr/record=b1043504~S12
Sites Web
[40] http://www.openvswitch.org/ dernier access Juliet 2016
[41] http://www.wbemsolutions.com/tutorials/DMTF/cim-overview.html dernier access Juliet 2016
[42] http://schemas.dmtf.org/wbem/cim-html/2/ dernier access Juliet 2016
ABSTRACT
The cloud computing is a set of tools and technologies that allow the access to
shared and configurable on self-service mode IT resources. In other words, they
allow the exploitation of computing and storage resources using network. The
management standards developed by the DMTF are essentially based on the object-
oriented meta-language CIM (Common Information Model) and WBEM architecture
(Web-Based Enterprise Management)
In the aim of providing a global, complete and homogeneous vision through DMTF
standards of all components of cloud computing platform, we offer as part of our
project implementing a standard dedicated for exploiting and controlling virtual
networks. More specifically, it is to standardize the management of an essential brick
in the world of cloud computing and network virtualization, namely, the Open Virtual
Switch Platform (OVS or Open vSwitch), this tool is adopted by the majority of
virtualization technology companies such as Xen, KVM and others. And also by a
large number of latest generations physical switches manufacturers as part of what is
called: Software Defined Network (SDN)
As part of our project, we realized a system dedicated to the management of layer
two of the OVS platform based on the standard CIM / WBEM. Our system allows
monitoring and control of this layer a virtual computer network.
Our system is based on an architecture adapting elementary WBEM components to
the architecture of Open vSwitch.
Translation CIM / OVS is performed by the CIM Provider / OVS that we developed
and represents the core of our work, because it assures one side the translation of
CIM to OVS and also facilitates the monitoring and the supervision of platforms for
customers who do not have programming bases.
Our Provider is a software component that can be integrated with most virtualization
platforms, of SDN and more generally the cloud. The integration with existing
environments will be easier through the ecosystem CIM / WBEM which will be used.

‫ ‬
‫ﻣﻠﺨﺺ‬
‫اﻟﺤﻮﺳﺒﺔ اﻟﺴﺤﺎﺑﯿﺔ ھﻲ ﻣﺠﻤﻮﻋﺔ ﻣﻦ اﻷدوات واﻟﺘﻘﻨﯿﺎت اﻟﺘﻲ ﺗﺘﯿﺢ اﻟﻮﺻﻮل إﻟﻰ ﻣﻮارد ﺣﺎﺳﻮﺑﯿﺔ ﻣﺸﺘﺮﻛﺔ‪ .‬وﺑﻌﺒﺎرة أﺧﺮى‪،‬‬
‫ﻓﮭﻲ ﺗﺴﻤﺢ ﺑﺎﺳﺘﻐﻼل ﻣﻮارد اﻟﺤﻮﺳﺒﺔ واﻟﺘﺨﺰﯾﻦ ﺑﺎﺳﺘﺨﺪام اﻟﺸﺒﻜﺎت‪ .‬إن ﻣﻌﺎﯾﯿﺮ اﻹدارة اﻟﺘﻲ وﺿﻌﺘﮭﺎ ‪ DMTF‬ﺗﺴﺘﻨﺪ أﺳﺎﺳﺎ‬
‫ﻋﻠﻰ اﻟﻠﻐﺔ اﻟﻔﻮﻗﯿﺔ )‪ CIM (Common information model‬وﺗﺼﻤﯿﻢ ‪WBEM (Web Based Enterprise‬‬
‫)‪Management‬‬
‫ﺑﮭﺪف ﺗﻮﻓﯿﺮ رؤﯾﺔ ﺷﺎﻣﻠﺔ وﻛﺎﻣﻠﺔ وﻣﺘﺠﺎﻧﺴﺔ ﻣﻦ ﺧﻼل ﻣﻌﺎﯾﯿﺮ ‪ DMTF‬ﻟﺠﻤﯿﻊ ﻣﻜﻮﻧﺎت ﻣﻨﺼﺔ اﻟﺤﻮﺳﺒﺔ اﻟﺴﺤﺎﺑﯿﺔ‪ ،‬ﻧﻘﺪم ﻛﺠﺰء‬
‫ﻣﻦ ﻣﺸﺮوﻋﻨﺎ ﺗﻨﻔﯿﺬ ﻣﻌﺎﯾﯿﺮ ﻣﺨﺼﺼﺔ ﻻﺳﺘﻐﻼل ﺗﺴﯿﯿﺮ اﻟﺸﺒﻜﺎت اﻻﻓﺘﺮاﺿﯿﺔ‪ .‬وﺑﺸﻜﻞ أﻛﺜﺮ ﺗﺤﺪﯾﺪا‪ ،‬ﺗﻮﺣﯿﺪ إدارة ﻟﺒﻨﺔ أﺳﺎﺳﯿﺔ‬
‫ﻓﻲ ﻋﺎﻟﻢ اﻟﺤﻮﺳﺒﺔ اﻟﺴﺤﺎﺑﯿﺔ واﻟﺸﺒﻜﺎت اﻻﻓﺘﺮاﺿﯿﺔ‪ ،‬وھﻲ ﻣﻨﺼﺔ ‪ OVS‬أو ‪ ، vSwitch Open‬وﻗﺪ ﺗﻢ اﻋﺘﻤﺎد ھﺬه اﻷداة ﻣﻦ‬
‫ﻗﺒﻞ اﻟﻐﺎﻟﺒﯿﺔ اﻟﻌﻈﻤﻰ ﻣﻦ ﺷﺮﻛﺎت اﻟﺘﻜﻨﻮﻟﻮﺟﯿﺎ اﻻﻓﺘﺮاﺿﯿﺔ ﻣﺜﻞ ‪ KVM ,Xen‬وﻏﯿﺮھﺎ‪ .‬وأﯾﻀﺎ ﻣﻦ ﻗﺒﻞ ﻋﺪد ﻛﺒﯿﺮ ﻣﻦ أﺣﺪث‬
‫ﻣﺼﻨﻌﻲ أﺟﮭﺰة اﻟﺘﺤﻮﯾﻞ اﻟﻤﺎدﯾﺔ )‪ (Switches‬ﻓﻲ إطﺎر ﻣﺎ ﯾﺴﻤﻰ‪ :‬ﺑﺮاﻣﺞ ﺗﻌﺮﯾﻒ ﺷﺒﻜﺔ )‪(SDN‬‬
‫ﻛﺠﺰء ﻣﻦ ﻣﺸﺮوﻋﻨﺎ‪ ،‬طﻮرﻧﺎ ﻧﻈﺎم ﻣﺨﺼﺺ ﻹدارة اﻟﻄﺒﻘﺔ اﻟﺜﺎﻧﯿﺔ ﻣﻦ ﻣﻨﺼﺔ ‪ OVS‬ﻋﻠﻰ أﺳﺎس ﻣﻌﯿﺎر ‪WBEM / CIM.‬‬
‫اﻻﻓﺘﺮاﺿﯿﺔ‪.‬‬ ‫اﻟﻜﻤﺒﯿﻮﺗﺮ‬ ‫ﺷﺒﻜﺎت‬ ‫ﻓﻲ‬ ‫اﻟﻄﺒﻘﺔ‬ ‫ھﺬه‬ ‫وﻣﺮاﻗﺒﺔ‬ ‫ﺑﺘﺴﯿﯿﺮ‬ ‫ﺑﺘﻄﻮﯾﺮه‬ ‫ﻗﻤﻨﺎ‬ ‫اﻟﺬي‬ ‫اﻟﻨﻈﺎم‬ ‫ﯾﺴﻤﺢ‬
‫وﯾﺴﺘﻨﺪ ﻧﻈﺎﻣﻨﺎ ﻋﻠﻰ ﺑﻨﯿﺔ ﺗﺴﻤﺢ ﻟﮫ ﺑﺘﻜﯿﯿﻒ ﺑﻨﯿﺔ ‪ vSwitch Open‬ﻣﻊ ﻣﻜﻮﻧﺎت ‪ WBEM‬اﻷﺳﺎﺳﯿﺔ‪.‬‬
‫ﺗﺘﻢ اﻟﺘﺮﺟﺔ ‪ OVS/CIM‬ﻣﻦ ﻗﺒﻞ اﻟﻤﺰود اﻟﺬي ﻗﻤﻨﺎ ﺑﺘﻄﻮﯾﺮه واﻟﺬي ﯾﻤﺜﻞ ﺟﻮھﺮ ﻋﻤﻠﻨﺎ‪ ٫‬ﻷﻧﮫ ﯾﻮﻓﺮ ﺧﺎﺻﯿﺔ اﻟﺘﺮﺟﻤﺔ ﻣﻦ ‪CIM‬‬
‫إﻟﻰ‪ OVS‬ﻣﻦ ﺟﮭﺔ وﻣﻦ ﺟﮭﺔ أﺧﺮى ﺗﯿﺴﯿﺮ اﻟﻤﺮاﻗﺒﺔ واﻹﺷﺮاف ﻋﻠﻰ ﻣﻨﺼﺎت اﻟﺸﺒﻜﺎت اﻻﻓﺘﺮاﺿﯿﺔ ﻟﻠﻌﻤﻼء اﻟﺬﯾﻦ ﻟﯿﺲ ﻟﺪﯾﮭﻢ‬
‫ﻗﻮاﻋﺪ ﻓﻲ اﻟﺒﺮﻣﺠﺔ‪.‬‬
‫اﻟﻤﺰود اﻟﺨﺎص ﺑﻨﺎ ھﻮ ﻋﺒﺎرة ﻋﻦ ﺑﺮﻧﺎﻣﺞ ﯾﻤﻜﻦ إدﻣﺎﺟﮫ ﻓﻲ ﻛﺎﻓﺔ ﻣﻨﺼﺎت اﻟﺸﺒﻜﺎت اﻻﻓﺘﺮاﺿﯿﺔ ﻓﻲ ﺑﺮاﻣﺞ ﺗﻌﺮﯾﻒ اﻟﺸﺒﻜﺎت‬
‫واﻟﺤﻮﺳﺒﺔ اﻟﺴﺤﺎﺑﯿﺔ ﻋﺎﻣﺔ‪ ٫‬إدﻣﺎج اﻟﻤﺰود ﻣﻊ اﻷﻧﻈﻤﺔ اﻟﻤﺘﻮﻓﺮة ﺣﺎﻟﯿﺎ ﺳﯿﻜﻮن أﺳﮭﻞ ﻣﻦ ﺧﻼل اﺳﺘﺨﺪام ‪.WBEM / CIM‬‬
‫ ‬ ‫ ‬

RÉSUMÉ
Le Cloud Computing est un ensemble d'outils technologiques qui permettent l'accès à des
ressources informatiques partagées et configurables en mode self-service. En d'autres
termes, il permet l'exploitation des ressources de calcul et de stockage via le réseau de
communication. Les standards de gestion développées par le DMTF sont fondés
essentiellement sur le métalangage orienté objet CIM (Common Information Model) et
l'architecture WBEM (Web Based Enterprise Management).
Afin d'offrir une vision globale, complète et homogène via les standards du DMTF de tous les
composants d'une plateforme de Cloud Computing, nous proposons dans le cadre de notre
projet, d'implémenter un standard dédié au contrôle et l'exploitation des réseaux virtuels.
Plus précisément, il s'agit de standardiser la gestion d'une brique essentielle dans le monde
de la virtualisation des réseaux et du Cloud, à savoir, la plateforme Open Virtual Switch
(OVS ou Open vSwitch) cet outil est adopté par la majorité des technologies de virtualisation
comme Xen, KVM et autres. Mais également par un grand nombre de constructeurs de
Commutateurs physiques de dernière génération dans le cadre de ce qu'on appelle :
Software Defined Network (SDN)
Dans le cadre de notre projet, nous avons réalisé un système dédié à la gestion de la
couche L2 de la plateforme OVS en se basant sur le standard CIM/WBEM. Notre système
permet la supervision et contrôle de cette couche des réseaux informatiques virtuels.
Notre système repose sur une architecture adaptant les composants WBEM élémentaires à
l’architecture d’un Open vSwitch.
La traduction CIM/OVS est réalisée par le Provider CIM/OVS que nous avons développé et
qui représente le noyau de notre travail car il assure d'un coté la traduction CIM de/vers OVS
et aussi faciliter aux clients qui n’ont pas les bases en programmation, le contrôle et la
supervision de leurs plateformes virtuelles.
Notre Provider représente une brique logicielle qui peut être intégrée à la plupart des
plateformes de virtualisation, de SDN et plus généralement de Cloud Computing.
L'intégration avec les environnements existants en sera facilitée grâce à l'écosystème
CIM/WBEM qui va être utilisé.
Mots Clés:
Open Virtual Switch (OVS), Software Defined Network, Virtualisation des réseaux,
Virtualisation des systèmes, Cloud Computing, CIM/WBEM, Manged Object Format, VLAN,
Open Flow, DMTF.

Khouas, Gacem, Conception Et Réalisation D'un Outil de Gesti

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Khouas, Gacem, Conception Et Réalisation D'un Outil de Gesti

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE

KHOUAS Abdelhalim GACEM Ahmed Ramzi

Conception et réalisation d'un outil de gestion

Devant le jury composé de : Sujet Proposé par :

Mr Med HAMADOUCH Président Mr Med.Amine Bouabid

Nous remercions Dr. M’hammed HAMADOUCH d'avoir accepté de présider le jury

Nous remercions Mme. S.MECHID d'avoir accepté d’être l’examinatrice de notre

A mes chers Parents,

A mes chers Parents,

CHAPITRE I : GÉNÉRALITÉS SUR OPEN vSwitch

CHAPITRE II : GÉSTION WBEM_______________________________________17

CHAPITRE III : CONCEPTION DU SYSTEME ____________________________33

CHAPITRE IV : RÉALISATION DE NOTRE SYSTÈME DE GESTION __________46

CONCLUSION GENERALE et PERSPECTIVES __________________________52

[Figure 1 : architecture du SDN]____________________________________15

L’environnement informatique dans ce genre de systèmes distribues n’est pas

Donc la normalisation de la représentation et de l’API d’accès aux plateformes

L'approche CIM-WBEM est la solution de collaboration d'un grand nombre de

En outre, l’implémentation OVS qui représente un Switch ou commutateur Virtuel,

La réalisation de ce système standardisé a comme objectif la contribution à la

GENERALITES SUR OPEN vSwitch

1.1. VIRTUALISATION DES RESEAUX

1.2. SOFTWARE DEFINED NETWORKING

1.4. OPEN vSwitch

1.1 VIRTUALISATION DES RESEAUX

1.1.1 LES AVANTAGES DE LA VIRTUALISATION DES RESEAUX

1.2 SOFTWARE DEFINED NETWORKING

[Figure 1 : architecture du SDN]

1.4 OPEN vSWITCH

Open vSwitch est une implémentation logicielle d’un switch ethernet.

La différence entre VMware « vNetwork distributed switch » et Cisco « Nexus

[Figure 3 : Les supporteurs d’Open vSwitch]

Donc, Open vSwitch est un commutateur logiciel multicouches,

L’OVS se compose de trois composant principales:

- Visualisation des bases de données est leurs schéma

La BDD Communique au gestionnaire et OVS-vswitchd avec protocole de

1.4.2.1.1 Les principales tables dans La base de données

[Figure 4 : Les tables les plus utilisées]

1.4.2.3 openvswitch.ko (OVS Kernel Module)

Les outils de l'espace utilisateur constituent une partie importante de l'Open

OVS-vsctl est un outil pour commander le commutateur virtuel. Il fournit

add-port <bridge> <interface> Ajouter un port au <bridge> connecté à

set-controller <bridge> <controller> mis en place d’un the contrôleur de

set <table> <record> <key=value> mis en place un <key> à <value> à la

create <table> <key=value> Insertion d’une ligne dans <table> ou la

1.4.5 ARCHITECTURE OPEN vSWITCH REPRESENTANT LE TRAITEMENT

La figure ci-dessous représente les différentes voies de traitement en OvS. Les

2.1. L’ARCHITECTURE FONCTIONNELLE

2.2. LE MODÈLE D’INFORMATION COMMUN CIM

2.3. LE MODÈLE DE COMMUNICATION

[Figure 8 : les rôles des intervenants dans l’architecteur WBEM]

2.1.2 ENTITES [37]

- Le gestionnaire d'objets CIMOM (CIM Object Manager) :

- Le provider : Il agit comme un pilote et une interface entre le monde abstrait du

[Figure 9 : Architecture WBEM]

2.2 LE MODELE D’INFORMATION COMMUN CIM

2.2.1 LE META-MODELE [41]

2.2.1.1 Schéma : Un schéma est un groupe de classes avec un seul

2.2.1.6 Les Références : Une référence est une propriété de données de

2.2.1.7 Les associations : Une association est un type de classe qui

2.2.1.9 Indications : Une indication est la représentation active de la

[Figure 10 : Le meta-modele CIM]