République Tunisienne

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université de Tunis El Manar École Nationale d’Ingénieurs de Tunis

Projet de Fin d’Année II

Conception et mise en place d’une solution

d’allocation de backup complète dans une
architecture cloud

Réalisé par :

MEFTAH GHAZI KACHROUDI FIRAS

Classe : 2ATEL2

Encadré par

M.BAHLOUL FAOUZI

Année Universitaire 2021/2022

Remerciements

En premier lieu, nous remercions Monsieur BAHLOUL Faouzi ,Maitre de conférence

à l’Ecole Nationale d’Ingénieur de Tunis (ENIT) qui a toujours eu le temps pour nous
écouter, nous conseiller et nous fournir les informations nécessaires. Que ce travail soit le
témoignage de notre profond respect.
Nous tenons à remercier également Madame Regaieg Rym, doctorante au laboratoire
Sys’Com, qui nous a guidé le long de ce travail, tout en fournissant les informations qui
nous ont été trés utiles lors de la conception de notre algorithme.
Nous adressons nos vifs remerciements à tous ceux qui ont contribué de proche ou de
loin à la réalisation de ce travail.
Nous voudrons aussi remercier les membres de l’honorable jury d’avoir accepter d’exa-
miner notre travail.

2
Table des matières

Table des figures 4

Liste des tableaux 6

1 Description du projet 9
1.1 Le Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.3 Les services du Cloud Computing . . . . . . . . . . . . . . . . . . . 10
1.1.4 Services du Cloud Computing . . . . . . . . . . . . . . . . . . . . . 11
1.1.5 Modèles de déploiement du Cloud Computing . . . . . . . . . . . . 13
1.2 Caractéristiques des services du Cloud Computing . . . . . . . . . . . . . 15
1.3 Virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4 Centre de donnéess virtuel (Virtual Data Center, VDC) . . . . . . . . . . 17
1.5 Etat de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5.1 Architecture Fat-Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5.2 Architecture Spine-Leaf . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5.3 Description du probléme . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Modélisation de problème d’allocation de backup et conception de so-

lution proposée 20
2.1 Présentation et Modélisation de problème . . . . . . . . . . . . . . . . . . 20
2.1.1 Présentation de donnés et de l’algorithme . . . . . . . . . . . . . . 20
2.1.2 Hypothèses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.3 Phase d’allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.4 Phase de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Phase de Backup : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.1 Critère spécial de l’indépendance : . . . . . . . . . . . . . . . . . . . 29
2.2.2 Conception de l’algorithme : . . . . . . . . . . . . . . . . . . . . . . 31

3 Etude de performance de l’algorithme et analyse des résultats 35

3.1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Génération des requêtes VDCs : . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4 Scénarios : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.1 scénario 1 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.2 scénario 2 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3
 3.4.3 scénario 3 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4.4 scénario 4 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.5 scénario 5 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Conclusion générale 43

Bibliographie 44

4
Table des figures

1.1 Les trois modèles de services cloud [1] . . . . . . . . . . . . . . . . . . . . 11

1.2 Trois modèles de services cloud [1] . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Modèles de déploiement du cloud computing [2] . . . . . . . . . . . . . . . 14
1.4 Hyperviseur type 1 et type 2 [6] . . . . . . . . . . . . . . . . . . . . . . . 16
1.5 Architecture Fat-Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.6 Architecture Spine-Leaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1 Architecture Spine-Leaf avec ses différents composants . . . . . . . . . . . 21

2.2 Présentation des liaisons et de la valeur de la bande passante entre les VMs
d’un VDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Matrice de lien d’un VDC . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Exemple d’allocation d’un VDC dans un centre des donnés . . . . . . . . 24
2.5 Présentation des liaisons et des valeur de la bande passante entre les VMs
d’un exemple de trois VDCs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6 Indexation des PMs et des PLs . . . . . . . . . . . . . . . . . . . . . . . . 25
2.7 Exemple d’allocation de trois VDC dans un centre des donnés . . . . . . . 26
2.8 Matrice de modélisation après la phase d’allocation des VMs . . . . . . . . 26
2.9 Allocation des chemins entre les VMs des trois VDCs . . . . . . . . . . . . 27
2.10 Présentation de l’état final de la matrice de modélisation . . . . . . . . . . 27
2.11 Formule de la matrice de modélisation . . . . . . . . . . . . . . . . . . . . 28
2.12 Matrice de modélisation en relation avec les PMs et les PLs . . . . . . . . 28
2.13 Produit matriciel entre le transposée de la première colonne et la troisième
colonne de la partie réelle de la matrice M . . . . . . . . . . . . . . . . . . 30
2.14 Produit matriciel entre le transposée de la première colonne et la troisième
colonne de la partie imaginaire de la matrice M . . . . . . . . . . . . . . . 30
2.15 Produit matriciel entre la transposée de la première colonne et la troisième
colonne de la partie imaginaire de matrice M . . . . . . . . . . . . . . . . 31
2.16 Détermination de VR de chaque VDC à partir de la partie réelle de la
matrice de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.17 Interprétation de résultat du produit matriciel entre le transposé de VRn
et VRk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.18 Allocation de VM de backup . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.19 Allocation de VL de backup . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1 Représentation de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2 Moyenne de variation de temps d’exécution de l’algorithme en fonction de
nombre de VDC traités . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Utlisations moyenne du CPU en variation avec le nombre de VDCs . . . . 38
5
3.4 Utlisations moyenne du RAM en variation avec le nombre de VDCs . . . . 38
3.5 Utlisations moyenne du DISK en variation avec le nombre de VDCs . . . . 39
3.6 Utlisations moyenne de la bande passante en variation de nombre de VDCs 39
3.7 Utilisation moyenne du nombre de machines virtuelles de backup en fonc-
tion du nombre total de VMs . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.8 Utilisation moyenne du nombre de liens virtuels de backup en fonction du
nombre total de VLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.9 Temps d’exécution de l’algorithme de solution proposée en comparaison
avec le temps de génération des requêtes VDCs . . . . . . . . . . . . . . . 42

6
Liste des tableaux

2.1 Différents catégories de machine virtuelle . . . . . . . . . . . . . . . . . . . . 21

2.2 Types des VMs selon un exemple de VDC . . . . . . . . . . . . . . . . . . . 21

3.1 Caractéristiques de machine physique . . . . . . . . . . . . . . . . . . . . . . 36

7
Introduction général

Le développement remarquable du Cloud Computing ces dernières années a suscité l’in-

térêt d’un nombre croissant d’internautes et d’utilisateurs d’ordinateurs désireux de pro-
fiter au mieux des services et des applications disponibles en ligne via le Web en mode ser-
vices à la demande et facturation à l’usage.
En raison de leur capacité à stocker une grande quantité de données, les centres de données
(DC), qui sont constitués d’un réseau de serveurs puissants appelés machines physiques
(PM), gagnent en popularité.
En raison de la forte demande de services de cloud computing, les centres de données sont
chargés d’optimiser l’utilité et l’efficacité de leurs ressources, ainsi que la fragmentation des
demandes de service.
Le centre de données virtuel (VDC) a été proposé comme un moyen pour les fournisseurs
d’infrastructures d’augmenter leurs profits sans avoir à faire de nouveaux investissements.
Le VDC a commencé à évoluer afin de mieux utiliser les ressources et de générer plus
de profits. L’objectif principal du fournisseur d’infrastructure est de traiter autant de
demandes de VDC que possible dans le centre de données physique qui est disponible.
Traditionnellement, les fournisseurs de services Cloud (Cloud Providers, CP) ont offert à
leurs clients des ressources sous forme de machines virtuelles (Virtual Machines, VM) sans
tenir compte des relations entre ces VM (en bande passante). C’est une autre raison pour
laquelle le concept de centre de données virtuel s’est développé. Par conséquent, plutôt que
de proposer des VM, les fournisseurs vont se tourner vers cette nouvelle solution et propo-
ser des centres de données virtuels (VDC). Les CP sont souvent confrontés à un dilemme :
comment maximiser leurs gains tout en maintenant un service de qualité. C’est ce que nous
étudierons dans ce projet.

Ce projet est divisé en trois parties. Dans le premier chapitre, nous présenterons notre
projet dans son intégralité, et nous aborderons certains concepts fondamentaux liés au
Cloud Computing. Le deuxième chapitre contient une description détaillée de notre solu-
tion. Dans le troisième chapitre, nous examinerons les aspects de simulation et d’analyse
de la méthode, ainsi que la manière d’évaluer ses performances.

8
Chapitre 1

Description du projet

Introduction
L’évolution du Cloud Computing et l’augmentation de la demande de ses services
motive les entreprises à investir dans ce domaine. Dans ce premier chapitre, nous allons
passer en revue quelques concepts fondamentaux liés au Cloud Computing .

1.1 Le Cloud Computing

1.1.1 Definition
Le "Cloud Computing" est une infrastructure permettant de fournir des services in-
formatiques à la demande généralement via internet et selon un modèle de paiement à
l’utilisation . Il est caractérisé par son élasticité et permet aux fournisseurs d’adapter auto-
matiquement la capacité de stockage et la puissance de calcul aux besoins des utilisateurs.

(https ://vixra.org/pdf/1605.0018v1.pdf // https ://www.futura-sciences.com/tech/definitions/informa

cloud-computing-11573/ )

1.1.2 Historique
Le concept du Cloud Computing est né dans les années 1990, notamment en 1991, avec
le lancement d’Internet et la mise en place du CERN( Conseil Européen pour la Recherche
Nucléaire) ; le premier logiciel basé sur le Web. L’idée a ensuite avancé avec l’introduction
de nouvelles solutions informatiques, comme le lancement du navigateur Mosaic en 1993
et du navigateur Netscape en 1994. La découverte d’eBay et d’Amazon en 1995 a encore
accéléré le processus. Ainsi l’introduction de l’assistant numérique Palm en 1996 a donné
un nouvel élan. Enfin, l’arrivée de Google en 2000 a favorisé la véritable émergence du
cloud computing.[1]

9
1.1.3 Les services du Cloud Computing
Les services offerts par le Cloud Computing se catégorisent en trois grands modèles de
services comme illustré à la figure 1.1 :

- Infrastructure as a Service (IaaS)

- Platform as a Service (PaaS)

- Software as a Service (SaaS)

Software as a service (SaaS) :

La location d’un logiciel en tant que service.
Habituellement, pour pouvoir utilisé un logiciel , il est nécessaire de l’installer sur l’ordina-
teur. Grâce à un logiciel SaaS, on n’a rien à installer ; au contraire, on l’utilise à distance : il
"tourne" sur des serveurs dans les centres de données du fournisseur. La plupart du temps,
l’accès à ces programmes se fait par l’intermédiaire d’un navigateur web, de sorte qu’il suf-
fit seulement d’une connexion internet.
L’avantage évident de ce modèle est sa facilité d’utilisation : en quelques clics de souris,
vous pouvez commencer à utiliser le logiciel. On peut ainsi s’affranchir des contraintes de
téléchargement et d’installation, ainsi que des problèmes de stockage...

Platform as a service (PaaS) :

Il s’agit de plates-formes réseau, qui regroupent essentiellement des serveurs partagés
et leurs systèmes de gestion. En plus de pouvoir fournir des logiciels en tant que service, le
PaaS offre des environnements de développement qui comprennent les langages, les outils
et les modules nécessaires. L’avantage est que ces environnements sont hébergés par un
fournisseur externe, ce qui permet à l’entreprise de se concentrer sur le développement
plutôt que sur la maintenance des infrastructures et des employés.

Infrastructure as a service (IaaS) :

Dans ce modèle, une entreprise loue les serveurs et l’espace de stockage dont elle a besoin
auprès d’un fournisseur de cloud. Elle peut ensuite utiliser cette infrastructure en cloud
pour créer ses propres applications. La démarche IaaS apparaît lorsqu’une entreprise loue
un espace ou elle peut développer ce qu’elle veut, mais elle doit fournir ses propres équipe-
ments et matériaux de construction.
DigitalOcean, Google Compute Engine et OpenStack sont les trois principaux fournisseurs
IaaS

10
 modelser.PNG

Figure 1.1 – Les trois modèles de services cloud [1]

1.1.4 Services du Cloud Computing

Les services offerts par le Cloud Computing se catégorisent en trois grands modèles de
services comme illustré à la figure 1.1 :

- Infrastructure as a Service (IaaS)

- Platform as a Service (PaaS)

- Software as a Service (SaaS)

Software as a service (SaaS) :

Habituellement, pour pouvoir utilisé un logiciel , il est nécessaire de l’installer sur l’or-
dinateur. Grâce à un logiciel SaaS, on n’a rien à installer ; au contraire, on l’utilise à dis-
tance : il "tourne" sur des serveurs dans les centres de données du fournisseur. La plupart
du temps, l’accès à ces programmes se fait par l’intermédiaire d’un navigateur web, de sorte
qu’il suffit seulement d’une connexion internet.
L’avantage évident de ce modèle est sa facilité d’utilisation : en quelques clics de souris,
vous pouvez commencer à utiliser le logiciel. On peut ainsi s’affranchir des contraintes de
téléchargement et d’installation, ainsi que des problèmes de stockage...

Platform as a service (PaaS) :

Il s’agit de plates-formes réseau, qui regroupent essentiellement des serveurs partagés
et leurs systèmes de gestion. En plus de pouvoir fournir des logiciels en tant que service, le
11
PaaS offre des environnements de développement qui comprennent les langages, les outils
et les modules nécessaires. L’avantage est que ces environnements sont hébergés par un
fournisseur externe, ce qui permet à l’entreprise de se concentrer sur le développement
plutôt que sur la maintenance des infrastructures et des employés[2].

Infrastructure as a service (IaaS) :

Dans ce modèle, une entreprise loue les serveurs et l’espace de stockage dont elle a
besoin auprès d’un fournisseur de cloud. Elle peut ensuite utiliser cette infrastructure
en cloud pour créer ses propres applications. La démarche IaaS apparaît lorsqu’une en-
treprise loue un espace ou elle peut développer ce qu’elle veut, mais elle doit fournir ses
propres équipements et matériaux de construction. DigitalOcean, Google Compute Engine
et OpenStack sont les trois principaux fournisseurs IaaS.

12
 Figure 1.2 – Trois modèles de services cloud [1]

1.1.5 Modèles de déploiement du Cloud Computing

Le modèle de déploiement du cloud computing précise le type d’environnement cloud
en fonction de la propriété, de l’évolutivité et de l’accessibilité, ainsi que de la nature et
de l’objectif du cloud. L’emplacement des serveurs que vous employez et dont vous avez le
contrôle est déterminé par un modèle de déploiement en cloud. Il précise l’aspect de votre
architecture de cloud, ce que vous pouvez modifier et si vous recevrez des services ou devrez
tout construire vous-même.
Les modèles de déploiement du cloud définissent également les relations entre l’infrastruc-
ture et les utilisateurs.

Le NIST (National Institute of Standards technologie) a identifié quatre modèles de

déploiement du cloud [3], à savoir : privé, public, communautaire et hybride, chacun cor-
respondant à un usage différent. Ces quatres modèle sont illustrés à la figure 1.2.

• Cloud privé (interne) : Le terme "cloud privé" fait référence à un serveur, un centre
de données ou un réseau distribué qui est entièrement dédié à une seule organisation. Il
est caractérisé par son haut niveau de sécurité, qui est soutenu par une connexion VPN
(Virtual Private Network).

• Cloud public (externe) : Le " cloud public " fait référence à un service géré par
un fournisseur tiers qui peut inclure des serveurs dans un ou plusieurs centres de données.
Au contraire des clouds privés, les clouds publics sont partagés par un certain nombre
d’organisations. L’utilisation de machines virtuelles permet à plusieurs entreprises de par-
13
tager des serveurs indépendants. C’est ce qu’on appelle une "architecture mutualisée" :
plusieurs sites louent de l’espace sur le même serveur.

• Cloud hybride (interne et externe) : Le "cloud hybride", comme son nom l’in-
dique, permet aux organisations d’utiliser à la fois le cloud computing privé et public pour
atteindre leurs objectifs spécifiques.
Le cloud public est conservé comme solution de backup en cas de panne du cloud privé.

• Cloud communautaire : Le modèle communautaire est constitué d’une infra-

structure partagée par plusieurs organisations ayant des intérêts communs (justice, édu-
cation, santé, industrie, culture, etc.). Il est important de noter que c’est actuellement
le seul modèle de Cloud qui garantit une localisation et un contrôle total des données.

Figure 1.3 – Modèles de déploiement du cloud computing [2]

14
1.2 Caractéristiques des services du Cloud Computing
Le cloud computing combine cinq caractéristiques essentielles afin de fournir des ser-
vices dans des conditions techniques et économiques très avantageuses :

• Libre-service à la demande : La mise en œuvre des services en nuage est entièrement

automatisée, et c’est l’utilisateur, via une interface web , qui met en place et gère la confi-
guration à distance en temps réel, en fonction de ses besoins, sans nécessiter d’interaction
humaine[3].

• Accès réseau large bande (Universel) : Quel que soit le client utilisé (par exemple,
un serveur, un PC, un client mobile, etc.), les services cloud sont disponibles pour l’utili-
sateur à l’échelle mondiale et facilement sur le réseau. En fait, les plus grands fournisseurs
mondiaux répartissent leurs centres de traitement des données dans le monde entier pour
assurer une disponibilité de 99,99% et un accès aux systèmes en moins de 50 millisecondes
depuis n’importe quel endroit de la planète.

• Mutualisation des ressources : Les ressources (par exemple, la bande passante du

réseau, les machines virtuelles, la mémoire, la puissance de traitement, la capacité de sto-
ckage, les applications, etc.) sont mises en commun pour servir plusieurs clients à l’aide
d’un modèle à emplacements multiples. Comme les ressources sont affectées et réaffectées
de manière dynamique en fonction des besoins et des préférences des clients, un seul ser-
veur peut servir des dizaines de clients différents grâce à ce modèle. Les économies d’échelle
réalisées grâce à ce principe permettent de réduire considérablement les coûts des fournis-
seurs et, par conséquent, les dépenses des utilisateurs[4].

• Elasticité ou mise à l’échelle rapide : L’une des caractéristiques les plus importantes
du cloud computing est l’élasticité des ressources. Les ressources peuvent être rapidement
et automatiquement déployées et mises à l’échelle en fonction de la demande, en toute
quantité et à tout moment. Par exemple, la configuration d’une nouvelle instance de ser-
veur prend quelques minutes, tandis que son arrêt et son redémarrage ne prennent que
quelques secondes.

• Facturation à l’usage : L’utilisation des services cloud est automatiquement sur-

veillée, contrôlée et signalée, ce qui assure la transparence pour les fournisseurs de services
en nuage et leurs clients. En fait, la facturation est basée sur le nombre de ressources uti-
lisées et la durée de leur utilisation. Une unité de traitement arrêtée n’est pas une unité
facturée. En général, le processus de facturation tient compte de facteurs tels que le type
de services demandés, la capacité de traitement, le nombre d’utilisateurs, la capacité de
stockage des données et le niveau de service (SLA pour Service Level Agreement).

1.3 Virtualisation
La virtualisation est un concept fondamental dans le domaine du cloud computing. En
effet les techniques utilisées dans le cloud sont basées sur la virtualisation des ressources
15
informatiques telles que le matériel, les logiciels, le stockage et les composants de réseau.

La virtualisation est un processus qui consiste à la mise en place d’un ou de nom-

breux environnements virtuels (ou machines virtuels) sur une même machine physique
(un Hôte). Ces ordinateurs fonctionneront comme des ordinateurs autonomes avec leur
propre système d’exploitation.

Un logiciel appelé Hyperviseur est chargé de la virtualisation du système.Il représente

une couche intermédiaire entre la partie hardware et la partie software. Il va ensuite allouer
les ressources (mémoire RAM, CPU, etc.) aux différentes machines virtuelles. Un hypervi-
seur isole son système d’exploitation et ses ressources des machines virtuelles, et permet de
créer et de gérer ces machines virtuelles.

Il existe deux type d’hyperviseur : hyperviseur type 1 ou bare metal et hyperviseur type
2 ou host metal. La figure 1.3 explique la différence entre ces deux types d’hyperviseur.

Un hyperviseur «bare metal» : Un hyperviseur de type 1 est un logiciel qui est

installé directement sur le hardware. Il constitue également le système d’exploitation de la
machine et il gère directement les ressources matérielles de la machine.

Un hyperviseur «host metal» : est un logiciel qui s’exécute à l’intérieur d’un autre sys-
tème d’exploitation, appelé système "hôte".

Exemples d’hyperviseur de type 1 : Red Hat Enterprise Virtualisation RHEV, KVM

(kernal-based Virtual machine), VMware vSphere/ ESXI.
Exemples d’hyperviseur de type 2 : VMware WorkStation, VirtualBox VM, GNS3.

Figure 1.4 – Hyperviseur type 1 et type 2 [6]

16
1.4 Centre de donnéess virtuel (Virtual Data Center,
VDC)
Les centres de données cloud sont devenus une infrastructure populaire pour l’héber-
gement d’une variété de services d’application pour les locataires. Le centre de données
virtuel (VDC) est proposé comme un service qui permet de louer à la fois des machines vir-
tuelles (VM) et de la bande passante réseau afin de fournir une agilité et une élasticité dans
l’utilisation des ressources pour les services en nuage.

Traditionnellement, les fournisseurs de services cloud (Cloud service Provider) pro-

posent des ressources en termes de machines virtuelles (VM) sans tenir compte des be-
soins en bande passante entre ces machines. Cette situation soulève un grand nombre de
préoccupations concernant les performances du réseau, la sécurité et la facilité de gestion.

Suite à cette observation, de nombreuses recherches ont récemment proposé d’offrir des
ressources sous forme de centres de données virtuels (VDC). Une solution qui permet aux
fournisseurs d’infrastructures d’améliorer leurs bénéfices sans avoir à réaliser de nouveaux
investissements.

Un centre de données virtuel est composé de machines virtuelles (VM) qui sont reliées
entre elles à l’aide de commutateurs virtuels, de routeurs et de connexions avec une bande
passante garantie. Cela permet aux FSC (fournisseur de service Cloud) d’améliorer les
performances de leurs applications et la qualité de service (QoS).

1.5 Etat de l’art

Une architecture du centre des données est un modèle pour le déploiement des technolo-
gies qui permettent de créer des environnements informatiques qui partagent et regroupent
des ressources évolutives sur un réseau. Dans le centre des données, on peut distinguer
deux types d’architecture ; l’architecture Spine-Leaf et l’architecture Fat-Tree.

1.5.1 Architecture Fat-Tree

L’architecture Fat-Tree se base sur un modèle à trois niveaux :

1 - Des commutateurs d’accès qui se connectent aux machines physiques.
2 - Des commutateurs d’agrégation qui fournissent des connexions redondantes aux
commutateurs d’accès.
3 - Des commutateurs centraux qui garantissent un transport rapide entre les commuta-
teurs d’agrégation, généralement connectés en paire redondante pour offrir une haute dis-
ponibilité. La figure 1.4 représente l’architecture Fat-Tree avec ses différentes couches[7].

17
 Figure 1.5 – Architecture Fat-Tree

1.5.2 Architecture Spine-Leaf

Une architecture Spine-Leaf est une topologie de réseau pour les centres des données
qui consiste en deux couches composés de commutateurs Leafs et de commutateurs Spines
comme il est indiqué dans la figure 1.5. La couche Leaf est composé de commutateurs qui
regroupent le trafic des serveurs et se connectent directement à la couche Spine. Les com-
mutateurs Spine interconnectent tous les commutateurs Leaf dans une topologie à maillage
complet.
En comparant les deux architectures, la topologie Spine-Leaf se caractérise par sa
simplicité par rapport à l’architecture traditionnelle. De plus, l’architecture Spine-Leaf
offre une meilleure rapidité et évolutivité. Elle est présentée sur deux niveaux au lieu de
trois, ainsi elle permet de réduire la possibilité de congestion, même dans un grand réseau.

1.5.3 Description du probléme

Grâce aux réseaux de centres de données (DCN), les serveurs et les commutateurs sont
interconnectés pour fournir des services de cloud. Avec l’évolution de la technologie et la
croissance du nombre des locataires dans les centres des données, les DCNs doivent être ca-
pables d’interconnecter des milliers de serveurs tout en maintenant une bande passante suf-
fisante pour garantir la qualité des services du Cloud.

Le centre de données virtuel est une trés bonne solution qui permet d’offrir la bonne
qualité de service aux clients et d’économiser l’utilisation des ressources physiques.

18
 Figure 1.6 – Architecture Spine-Leaf

Dans notre projet, nous focalisons sur le problème d’optimisation des ressources qui
sont dédiés pour l’utilisation en cas d’échec. C’est-à-dire, on cherche la manière de dési-
gner les éléments physiques remplaçants le fonctionnement des ressources principales si
un endommagement au niveau de ces derniers s’apparaît. Nous concentrons d’abord au
problème d’allocation des machines virtuelles et des liens virtuels composant les requêtes
VDC dans une architecture Spine Leaf. Par la suite, nous abordons la deuxième partie du
problème qui est la phase de backup pour ces VDCs. Cette phase consiste à allouer des
machines virtuelles (VMs) et des liens virtuelles (VLs) de secours d’un ou d’un ensemble
de VDCs vérifiant une certaine condition.

Conclusion
Dans ce premier chapitre, nous avons introduit le projet dans son intégralité, tout en
exposant certains concepts fondamentaux liés au Cloud Computing et en indiquant les
problèmes d’allocation et de backup des ressources.

19
Chapitre 2

Modélisation de problème d’allocation

de backup et conception de solution
proposée

Introduction
Le cloud computing a récemment réussi à devenir un modèle populaire et rentable pour
l’hébergement de services en ligne à grande échelle dans les centres de données. Cependant,
les affaiblissements matériels (serveur, commutateur, processeur...) sont inévitables, ce
qui peut toucher le fonctionnement, la fiabilité et la performance du service. Notre défi
consiste à modéliser une solution qui garantit la survivabilité des centres de données
virtuelles d’une manière optimale. D’autre part, on cherche à inventer une seule solution
qui combine les différents éléments concernés par l’architecture Cloud. Dans ce chapitre,
nous allons présenter nos hypothèses, notre solution, notre conception d’algorithmes et
les phases d’allocations des machines virtuelles ainsi ses liens virtuels en tenant compte
de ses remplaçants (Backups).

2.1 Présentation et Modélisation de problème

2.1.1 Présentation de donnés et de l’algorithme
Dans ce travail, on considère un centre des données (Data Center) composé par des
machines physiques (PM, Physical Machine) et des commutateurs (dans la couche spine
et leaf) qui sont reliés entre eux par des liens physiques (PL, Physical Link). Chaque
machine physique est caractérisée par sa mémoire RAM, sa capacité de stockage DISK et
le nombre des cœurs CPU. Les commutateurs sont présentés sur deux couches. Le com-
mutateur Leaf est l’intermédiaire entre la couche Spine et les Racks qui sont un ensemble
des PMs. Le commutateur Spine est l’épine dorsale d’interconnexion de tous les commuta-
teurs Leaf. La figure 2.1 présente l’architecture Spine-Leaf de centre de données proposé.

Lors de réception d’une demande d’hébergement d’un service sur l’infrastructure Cloud,
on traduit cette demande sous forme des centres de donnés virtuels (VDCs). Un centre de
données virtuelles est un environnement d’infrastructure virtuel qui abstrait les ressources
20
physiques dans l’objectif à distribuer différents clients de manière flexible et selon la de-
mande. Il est constitué par des machines virtuelles (VMs) de différents tailles (S, M, L)
reliées entre elles par des liens virtuels (VL, Virtual Link). Ensuite, on génère notre algo-
rithme qui est capable d’allouer les machines virtuelles de chaque VDC en garantissant la
bande passante nécessaire pour la communication entre elles. Enfin, notre algorithme dé-
termine les VMs de backups ainsi ses liens virtuels de backups jugés selon un caractère spé-
cial basé sur nos hypothèses.

Figure 2.1 – Architecture Spine-Leaf avec ses différents composants

Comme les machines virtuelles se classifient en 3 catégories (S, M, L), Le tableau 2.1
suivant manifeste les différentes classes de machines virtuelles avec ses caractéristiques.

Taille CPU(nombre de cœur) RAM(Go) DISK(Go)

S 1 4 24
M 4 16 64
L 8 32 128

TABLE 2.1 Différents catégories de machine virtuelle

Pour clarifier les données de notre problème, soit l’exemple suivant qui représente un
centre de données virtuel composé par cinq VMs. Le tableau 2.2 décrit le type de chaque
VM de ce VDC.

21
 VM VM1 VM2 VM3 VM4 VM5
Taille S M L S S

TABLE 2.2 - Types des VMs selon un exemple de VDC

Après avoir classifié les caractéristiques de chaque VM, nous allons citer maintenant
les liens entre ces différents VMs. Soit la figure 2.2 suivante qui décrit les relations entre Les
VMs d’un VDC ainsi la valeur de la bande passante de chaque relation.

Figure 2.2 – Présentation des liaisons et de la valeur de la bande passante entre les VMs
d’un VDC

Ces différents liens sont exprimés dans une matrice illustrée dans la figure 2.3. Par
exemple, la machine virtuelle d’indice avec la machine virtuelle d’indice 4 avec une bande
passante de 125Mbps.

Figure 2.3 – Matrice de lien d’un VDC

22
 La prochaine étape consiste à allouer les machines virtuelles dans des machines phy-
siques d’une manière qu’elles peuvent communiquer entre elles. Pour cela, nous allons
citer nos hypothèses d’abord. Ces hypothèses sont un ensemble des propositions sur l’état
des données de notre problème afin de le bien modéliser.

2.1.2 Hypothèses
Avant de présenter notre algorithme, nous considèrons les hypothèses suivantes :

• Deux PMs ou deux PLs ne tombent pas en panne en même temps.

• Toutes les PMs ont les mêmes caractéristiques physiques (CPU, DISK, RAM) sauf ses
fiabilités, c’est-à-dire, la possibilité de pouvoir éviter les défaillance.
• Tous les liens physiques entre les commutateurs Leafs et les PMs ont les mêmes propriétés
physiques (bande passante). Ainsi les liens physiques entre les commutateurs Spines et les
PMs ont les mêmes caractéristiques.
• On suppose que tous les commutateurs n’ont jamais tombé en panne. Mais les commuta-
teurs Leafs peuvent tomber en panne d’où on présente son remplaçant dans l’état en veille
dans le cas d’apparition de défaillance.

L’utilité de ces suppositions se manifeste dans la phase de proposition de notre solution

sur le problème d’allocation des backups de différents VDCs.

2.1.3 Phase d’allocation

Cette étape consiste à allouer les ressources virtuelles dans l’infrastructure physique
suivant les hypothèses qu’on a cité précédemment. D’abord, on loge les VMs dans les
PMs appropriés. Puis, on désigne les liens d’interconnexion entre les VMs avec les bandes
passantes nécessaires. La figure 2.4 présente l’exemple de VDC précèdent après la phase
d’allocation.

Notre problème principal consiste à héberger les backups de VMs et de PLs d’une
manière optimale en se basant sur les hypothèses et les données présentées. Dans la partie
suivante, nous allons modéliser nos ressources virtuelles et physiques dans un modèle
descriptif sur les relations entre elles.

2.1.4 Phase de modélisation

Cette phase est la phase intermédiaire entre la phase d’allocation et la phase de backup.
Le but de cette étape est d’extraire les données utiles pour les exploiter dans l’étape
de logement des backups. Après l’hébergement des VDCs dans le centre des donnés, la
relation entre ces VDCs et les ressources physiques se traduit par une matrice qu’on appelle
matrice de modélisation. Les colonnes de cette matrice définissent les VDCs et ses lignes
présentent les PMs et les PLs. Chaque colonne indique les informations d’un seul VDC
en relation avec les PMs et les PLs. Ainsi, le numéro de colonne indique l’indice de VDC.

23
 Figure 2.4 – Exemple d’allocation d’un VDC dans un centre des donnés

Dans ce travail, nous avons déjà considéré que chaque commutateur Leaf a un commu-
tateur de backup qui est en mode en veille. Cette hypothèse nous amène à ignorer la dis-
cussion sur les backups de PLs entre la couche Leaf et les PMs. En effet, on ne tient compte
dans notre modèle que des PLs entre la couche Spine et la couche Leaf ainsi tous les PMs de
Data Center.

Puisque notre centre de discussion est les machines physiques et les liens physiques, la
matrice de modélisation doit tenir compte de ces deux différents types de matériel. Alors,
nous présentons la matrice de modélisation sous forme de matrice des nombres complexes.
Nous désignons les PMs et les PLs respectivement comme la partie réelle et la partie ima-
ginaire de cette matrice. L’indice de chaque ligne présente l’indice de PM et l’indice de PL
dans un centre de données.

Lors de réception de requête de VDC, qu’on suppose d’indice n, on ajoute une colonne
des valeurs nulles à la matrice de modélisation. Ensuite, dès l’allocation de chaque VM de
VDC dans le k-ième PM, on met la valeur 1 sur la position de n-ième ligne, k-ième colonne
de la matrice de modélisation. Après la phase d’allocation des PMs, le même principe se
fait dans la phase d’allocation des liens. Lorsque on réserve une bande passante entre les
VMs de deux racks différents sur k-ième PL, on ajoute i (avec i un nombre complexe i*i=-
1) à la valeur existant dans la position de n-ième ligne, k-ième colonne de la matrice de mo-
délisation.

Pour mieux expliquer le remplissage de la matrice de modélisation, on va citer l’exemple

détaillé. Soit les trois VDCs suivants comme dans la figure 2.5 qui présente ses VMs et
24
ses liens virtuels en indiquant la valeur de bande passante sur chaque lien.

Figure 2.5 – Présentation des liaisons et des valeur de la bande passante entre les VMs
d’un exemple de trois VDCs

En premier lieu, on énumère les PMs et les PLs, c’est-à-dire, on met à chaque ressource
physique un indice comme il est illusté dans la figure 2.6.

Figure 2.6 – Indexation des PMs et des PLs

On suppose que les VMs de différents VDCs s’hébergent dans les PMs comme il est indi-
qué dans la figure 2.7.

25
 Figure 2.7 – Exemple d’allocation de trois VDC dans un centre des donnés

La matrice de modélisation est sous la forme suivante :

Figure 2.8 – Matrice de modélisation après la phase d’allocation des VMs

En tenant l’exemple du premier VDC qui correspond à la colonne 1 de notre matrice. Ce

VDC a trois VMs allouées dans les PMs d’indice 1,3 et 11. Si on observe à la première co-
lonne de la matrice de modélisation, on voit le numéro 1 dans la première ligne, la troisième
ligne et l’onzième ligne.

26
 Pour établir la communication entre les VMs, on cherche le chemin qui réserve la bande
passante nécessaire. La figure 2.9 présente notre exemple où on a alloué les chemins entre
les machines virtuelles.

Figure 2.9 – Allocation des chemins entre les VMs des trois VDCs

Finalement, la matrice de modélisation s’apparait sous la forme suivante :

Figure 2.10 – Présentation de l’état final de la matrice de modélisation

On revient à notre exemple, si on veut savoir le chemin pris par le VDC1 entre la couche
Spine et la couche Leaf, il faut garder aux parties imaginaires de la matrice de modélisa-
tion. On remarque l’existence de valeur i dans la ligne 5 et 6. Ce qui signifie que l’allocation
des chemins virtuels se fait au niveau le lien physique d’indice 5 et le lien physique d’indice
6.
27
 D’une façon générale, on peut citer la formule indiquée dans la figure 2.11 en supposant
que M est la matrice de modélisation. La figure 2.12 représente une récapitulation de la
relation entre la matrice M et les VDCs proposés au début de cette partie.

Figure 2.11 – Formule de la matrice de modélisation

Figure 2.12 – Matrice de modélisation en relation avec les PMs et les PLs

Après la phase de modélisation, il nous reste que la phase de backup. Dans la par-
tie suivante, nous allons présenter la théorie de Backup et la façon dans laquelle nous
hébergerons les backups des VMs et les backups des VLs.

28
2.2 Phase de Backup :
L’objectif de cette partie est de présenter comment on va définir les backups des VDCs.
La solution immédiate consiste à réserver à chaque VM de VDC un VM de backup. De
même pour les liens physiques, on désigne à chaque lien virtuel un lien virtuel de backup.

Dans ce travail, on considère un groupe des VDCs. Tout d’abord, on a déjà supposé
que les PMs et les PLs ne tombent pas au même temps. Ceci nous conduit à penser
qu’à un intervalle de temps donné, un seul PM ou PL va tomber en panne. Au bout de
cet intervalle de temps, le reste de PMs et de PLs fonctionnent correctement. On déduit
alors que les VDCs qui ne partagent pas les mêmes ressources physiques avec les VDCs
défaillants (c’est-à-dire les VDCs indépendants), peuvent avoir le même VM et VL de
backup avec ces derniers. Le critère de l’indépendance qui nous amène à regrouper les
VDCs est le résultat de nos suppositions sur l’état de centre des données.

2.2.1 Critère spécial de l’indépendance :

Le critère de l’indépendance des VDCs se fragmente en deux niveaux ; le critère de l’in-
dépendance au niveau PM et le critère de l’indépendance au niveau de PL. On dit que le
VDC1 et le VDC2 sont indépendants au niveau de PM si leurs VMs sont allouées dans des
PMs deux à deux différentes. De même pour les PLs, on dit que le VDC1 et le VDC2 sont
indépendants au niveau de PL si leurs VLs sont allouées dans des PLs deux à deux diffé-
rentes.
À partir de la matrice de modélisation, on peut engager l’indépendance entre les
VDCs. Si on veut déterminer l’indépendance au niveau de PM entre VDC d’indice n
et VDC d’indice m, on effectue le produit matriciel entre la transposée de la n-ième
colonne et la m-ième colonne de la partie réelle de la matrice de modélisation. Si on ob-
tient 0 comme résultat, alors VDCn et VDCm sont indépendants au niveau de PM. Si
on trouve un résultat différent à 0, on déduit que VDCn et VDCm ne sont pas indé-
pendants au niveau de PM. Si on veut déterminer l’indépendance au niveau de PL, on
reprend la même démarche, mais avec la partie imaginaire de la matrice de modélisation.

Tenant l’exemple de trois VDCs cités dans la partie précédente, on veut déterminer la
relation d’indépendance entre VDC1 et VDC3. On fait le produit matriciel de la partie
réelle de transposée de la première colonne (qui représente la colonne de VDC1) avec la
troisième colonne (qui représente la colonne de VDC3) de notre matrice M comme il est
expliqué dans la figure 2.13. Le résultat de calcul est 1, différent de 0. Donc on en déduit
que le VDC1 et le VDC3 sont dépendants au niveau de PM. Ce qui est bien approuvé
dans la figure 2.9 où VM2 de VDC1 et VM1 de VDC3 sont alloué sur la même PM3.

29
Figure 2.13 – Produit matriciel entre le transposée de la première colonne et la troisième
colonne de la partie réelle de la matrice M

Si on veut tester l’indépendance au niveau de PL, on applique le produit matriciel

de transposée de la première colonne (VDC1) avec la troisième colonne (VDC3) de la
partie imaginaire de notre matrice M comme il est expliqué dans la figure 2.14. Le ré-
sultat de calcul est 0. Donc le VDC1 et le VDC3 sont indépendants au niveau de PL.

Figure 2.14 – Produit matriciel entre le transposée de la première colonne et la troisième

colonne de la partie imaginaire de la matrice M

La figure 2.15 est une représentation de processus de calcul dans le cas général où on
prend deux VDCs l’une d’indice k et l’autre d’indice n pour tester leurs dépendances au
niveau de PL et PM.

30
Figure 2.15 – Produit matriciel entre la transposée de la première colonne et la troisième
colonne de la partie imaginaire de matrice M

2.2.2 Conception de l’algorithme :

Avant d’allouer les VMs de backups, il faut générer tout d’abord un algorithme qui
différencie les VDCs indépendantes et le VDCs dépendantes au niveau de PL et PM.
Par exemple, si on reçoit 150 requêtes d’hébergements des VDCs, on a alors 11 325
(1+. . .+150) à faire pour déterminer la relation de dépendance entre les VDCs. Le temps
d’exécution de ce code sera lent. Donc, nous désignons alors une comparaison initiale
introduite au niveau des Racks, c’est-à-dire, on compare si deux VDCs allouent ses VMs
dans des Racks différents ou non. On effectue à chaque VDC un vecteur qu’on appelle
vecteur de Rack et on le note par VR. Ce VR est une matrice de taille (nombre de rack, 1).
Chaque ligne de ce vecteur présente le numéro de rack. Le vecteur de Rack est initialement
un vecteur des 0. Si un VDC loge des VMs dans un rack d’indice k, on met alors 1 dans
la position (k,1) de VR associé à ce VDC. De plus, on peut déterminer la valeur de VR
pour chaque VDC en prenant la partie réelle non nulle de la matrice de modélisation. la
figure 2.16 prend l’exemple introduit dans les parties précédentes.

31
Figure 2.16 – Détermination de VR de chaque VDC à partir de la partie réelle de la
matrice de modélisation

Cette méthode nous améliora le temps d’exécution puisque nois allons filtrer une quan-
tité de calcul inutile. Elle ne détermine le critére d’indépendance au niveau de PM et PL
que s’il est nécessaire. Si on veut tester l’indépendance de deux VDCs l’un d’indice n et
l’autre d’indice k au niveau de Rack, on effectue le produit matriciel entre le transposé de
VRn et VRk. La figure 2.17 présente le résultat de ce calcul en interprétant les différents
cas. Par exemple, si on obtient un 0 comme résultat, on déduit directement que les deux
VDCs sont indépendant au niveau de PM car ils sont indépendants au niveau de Rack.
De plus, ces deux VDCs ne peuvent pas avoir un lien virtuel commun parce qu’il est im-
possible pour un seul lien physique d’associé deux Racks différents. En effet, nous avons
réussi une méthode très simple et qui combine les deux aspects ; indépendance au niveau
de PM et l’indépendance de PL d’une maniére trés optimale.

32
Figure 2.17 – Interprétation de résultat du produit matriciel entre le transposé de VRn
et VRk

La dernière étape de ce chapitre consiste à héberger le VM de backup dans la place

approprié et de désigner le lien virtuel de backup convenable. Tout d’abord, nous regrou-
pons les VDCs indépendants au niveau de PM puis nous cherchons la machine virtuelle la
plus gourmande en ressources (CPU, RAM, Disque), qui servira comme une machine de
backup pour l’ensemble de ces VDCs. Puis, nous allouons les liens de la machine virtuelle
de backup par la bande passante maximale parmi les bandes passantes de différentes VMs
constituant les VDCs indépendants. Enfin, nous regroupons les VDCs indépendants au
niveau de PL dont on les désigne le lien physique qui est capable de prendre la bande
maximale parmi les différentes VMs constituant les VDCs. La figure 2.18 présente l’allo-
cation de VM de backup de VDC2 et VDC3 de l’exemple pris précédemment. Ainsi, la
figure 2.19 présente l’allocation de VL de backup de VDC1 et VDC3.

Figure 2.18 – Allocation de VM de backup

33
 Figure 2.19 – Allocation de VL de backup

Conclusion
Dans ce chapitre, nous avons présenté la modélisation et la conception de notre algo-
rithme en travaillant sur les problèmes d’allocation de backup des machines virtuelles et
des liens virtuels. Le but principal de ce chapitre est de développer notre approche qui
se base sur différentes hypothèses. Le chapitre suivant sera consacré sur l´évaluation de
l’algorithme et la simulation.

34
Chapitre 3

Etude de performance de l’algorithme

et analyse des résultats

Introduction
Après la conception et la mise en œuvre de notre algorithme, il est temps de le vali-
der et de procéder à des simulations avec différents scénarios d’exécution. Pour ce faire,
nous allons d’abord fournir l’environnement de travail, puis étudier les performances par
l’exécution de plusieurs simulations, et enfin, nous présenterons les principaux résultats.

3.1 Environnement de travail

Notre algorithme a été développé avec le langage de programmation « Python » version
3.8 dans l’environnement IDLE (Integrated Distributed Learning Environment). Notre
choix sur le langage de programmation se base sur notre conception de l’algorithme qui
exige un calcul matriciel. En effet, nous avons également intégré des bibliothèques adé-
quates avec les exigences de notre projet qui s’engage à simplifier la complexité de l’al-
gorithme comme la librairie Numpy. La biblithothéque Numpy est capable de créer et
manipuler le calcul matriciel dont le temps d’execution est trés faible.

3.2 Simulations
Les résultats de simulation sont essentiellement déterminés par la topologie choisie.
L’architecture adoptée pour toutes les simulations est une architecture de taille moyenne
comportant 5 commutateurs dans la couche Spine, 10 commutateurs dans la couche Leaf
et 10 machines physiques par Rack, pour aboutir enfin à 100 machines physiques en
totalité. Les cinq commutateurs de la couche Spine sont reliés entre eux par des liens de
bande passante de 10 Gbps. Chaque commutateur de cette couche est connecté avec les
commutateurs de la couche Leaf par des liens de bande passante de 1 Gbps. On illustre
cette architecture par la figure 3.1.

35
 Figure 3.1 – Représentation de l’architecture

Les machines physiques utilisées sont de même nature, et le tableau 3.1 ci-dessous pré-
sente leurs caractéristiques.

Paramétres Valeur
CPU 64 coeurs
RAM 196 Go
DISK 1000 Go
Bande Passante 1 Gbps

TABLE 3.1 - Caractéristiques de machine physique

3.3 Génération des requêtes VDCs :

Après avoir défini l’architecture, nous devons générer l’entrée de notre algorithme : les
demandes VDCs, qui correspondent à un ensemble de centres de données virtuels compre-
nant chacun un nombre prédéterminé de machines virtuelles connectées entre elles par des
liens virtuelles.

36
 Pour ce faire, nous avons créé un programme qui génère les demandes VDC d’une ma-
nière automatique et dans un ordre aléatoire. Il suffit de spécifier le nombre de VDC sou-
haité pour que l’algorithme génère les demandes. Les informations sur les différents VDCs
sont sauvegardées dans un fichier Excel (.xlsx).
Afin d’obtenir des résultats plus fiables, nous avons répété l’exécution de l’algorithme
cent fois dont les simulations seront présentées dans la suite. De façon plus simple, si nous
fixons le nombre de VDC à 30, nous allons générer 30 demandes VDCs et nous répétons
l’exécution 100 fois avant de calculer une moyenne pour s’assurer que les résultats sont
stables et précis.

3.4 Scénarios :
3.4.1 scénario 1 :
Le temps d’exécution est parmi les meilleurs paramètres d’efficacité d’un programme.
La figure 3.2 représente la moyenne de variation du temps d’exécution de l’algorithme par
rapport au nombre de VDCs traités. Nous avons calculé ce temps d’exécution pour des
demandes de VDCs entre 10 et 340 sur 100 essais. Le temps d’exécution est proportionnel
avec le nombre de VDC. C’est-à-dire plus que nous recevons de demandes d’hébergement
des machines virtuelles plus que le temps d’exécution augmente. Pour une demande de
50 VDCs le programme s’exécute avec une valeur moyenne de 0.012ms et pour 100 VDCs
le temps d’exécution devient 0.038ms pour aboutir enfin à 0.32ms pour une demande de
340 VDCs.

Figure 3.2 – Moyenne de variation de temps d’exécution de l’algorithme en fonction de

nombre de VDC traités
37
3.4.2 scénario 2 :

Dans ce deuxième scénario, nous focalisons sur le taux d’utilisation d’un serveur phy-
sique. Nous avons déjà utilisé 100 serveurs physiques regroupés sur 10 racks dans l’architec-
ture Spine Leaf. Chaque serveur est caractérisé par son CPU (cœurs), sa RAM (Go), son
DISK (Go) et sa bande passante (Mbps). Nous avons calculé le taux d’exploitation des res-
sources physiques en fonction de nombre de VDCs.
Les résultats de simulation sont représentées dans les figures 3.3, 3.4, 3.5 et 3.6.
Notre algorithme a ainsi réussi à bien exploiter les termes des ressources physiques.

Figure 3.3 – Utlisations moyenne du CPU en variation avec le nombre de VDCs

Figure 3.4 – Utlisations moyenne du RAM en variation avec le nombre de VDCs

38
 Figure 3.5 – Utlisations moyenne du DISK en variation avec le nombre de VDCs

Figure 3.6 – Utlisations moyenne de la bande passante en variation de nombre de VDCs

3.4.3 scénario 3 :
Une fois nous avons hébergé les machines virtuelles dans les machines physiques, nous
passons dans ce scénario à déterminer le nombre de VMs de backup en fonction du nombre
total des VMs.
La figure 3.7 présente la variation moyenne du nombre de VMs de backup en fonction du
nombre de VMs de différents VDCs.

39
Figure 3.7 – Utilisation moyenne du nombre de machines virtuelles de backup en fonction
du nombre total de VMs

L’analyse de la figure 3.7 montre que notre algorithme est capable de gagner plus de
ressources matérielles dans les centres des données. La vaste marge de nombre de VMs
totale par rapport au nombre de backup en augmentant le nombre de VDCs est trés
clair. Pour être plus précis, selon les valeurs numériques, pour 340 VDCs effectués, 18
VMs de backup en moyenne sont utilisées, grâce au fait que plusieurs machines virtuelles
partagent un seul backup. Ce résultat met en valeur l’intérêt de l’algorithme proposé.

3.4.4 scénario 4 :
Dans ce scénario, nous étudions les liens virtuels de différents VDCs et ses backup entre
la couche Spine et la couche Leaf. Dans la figure 3.8, on illustre la variation du nombre
de VLs totale et du nombre de VLs de secours en fonction du nombre de VDCs généré.

Le résultat de ce graphe manifeste l’efficacité de la solution que nous avons proposée

dans le chapitre précédent. En analysant le résultat de cette simulation, il est logique
de trouver que le nombre des VLs de backup est à peu prés le tiers du nombre de VLs
en total. Puisque nous avons cinq commutateurs Spines, un seul VL de backup ne doit
correspond qu’aux quatre VDCs indépendants au niveau VL au maximum.

40
Figure 3.8 – Utilisation moyenne du nombre de liens virtuels de backup en fonction du
nombre total de VLs

3.4.5 scénario 5 :
Dans ce dernier scénario, nous allons comparer le temps de l’exécution de notre solution
proposée avec le temps de génération des requêtes VDCs. La figure 3.9 présente le résultat
de temps d’exécution en moyenne pour les deux différents aspects. En effet, ce graphe
confirme la rapidité et l’efficacité de notre conception d’algorithmes même par rapport
au temps de réception des requêtes VDCs. De plus, on peut discuter le terme de la pente
de deux courbes où on admet 0.0045 pour la courbe de génération des requetes VDCs,
or, on trouve 0.00087 en moyenne pour la courbe de temps d’exécution de l’algorithme.
Pour clarifier un peu notre intérêt, si on oriente vers un nombre de VDCs plus grand,
nous serons sûrs que le temps d’exécution de notre solution proposée est très inférieur au
temps de réception des demandes d’hébergement.

41
Figure 3.9 – Temps d’exécution de l’algorithme de solution proposée en comparaison
avec le temps de génération des requêtes VDCs

Conclusion
Dans ce dernier chapitre, nous avons désigné un ensemble de scénarios pour tester les
performances de l’algorithme proposé. Les résultats de différentes simulations montrent
bien que cet algorithme est puissant et efficace en termes de consommation de ressources
et de temps d’exécution.

42
Conclusion générale

Les fournisseurs d’infrastructure en tant que service (IaaS) de cloud computing sont
devenus une alternative à la hausse du coût total de possession des infrastructures infor-
matiques dans de nombreuses entreprises. Le problème du VDC est récemment devenu un
sujet brûlant dans les centres des données, car un placement approprié peut apporter une
grande contribution pour fournir un service cloud à valeur ajoutée de haute qualité aux
utilisateurs finaux. Ainsi, l’approche de backup s’intervient dernièrement pour améliorer la
qualité de service.

Dans ce projet, nous avons abordé principalement la gestion des ressources physiques
en discutant les parties virtuelles. Nous avons développé une solution pour l’allocation de
backup des machines virtuelles et des liens virtuels. Nous avons pu comprendre cela de
manière plus pratique à travers les simulations et les scénarios effectués dans le troisième
chapitre. D’ailleurs, nous avons cité la conception del’algorithme et l’enchaînement du
travail qui est basé sur des hypothèses dans le deuxième chapitre. Le deuxième chapitre
est l’épine dorsale de notre travail. C’est une modélisation de problème d’une part et une
représentation de démarche de notre solution d’autre part. Sans oublier l’intérêt de premier
chapitre qui est une description de problème et représentation des éléments fondamentaux
de Cloud Computing.

L’objectif de notre travail est quasiment atteint grâce aux résultats des simulations.
La réduction de nombre de VLs et VMs pour le backup est remarquable. Nous avons
pu comprendre cela de manière plus pratique à travers les simulations et les scénarios
effectués dans le troisième chapitre. Il serait intéressant de compléter cette étude sur le
plan expérimental à travers un centre de données réel.

43
Bibliographie

[1] http ://www.cloud-entreprise.info/historique-cloud-computing/ : :text=Il

[2] P. M. Mell and T. Grance, “Sp 800-145 : the nist definition of cloud computing,”
tech.rep., National Institute of Standards Technology, https ://bit.ly/2NM71mU, 2011
S. Chhabra and V. S. Dixit, “Cloud computing : State of the art and security issues,” ACM
SIGSOFT Software Engineering Notes, vol. 40, no. 2, pp. 1–11, 2015.

[3] S. Chhabra and V. S. Dixit, “Cloud computing : State of the art and security issues,”
ACM SIGSOFT Software Engineering Notes, vol. 40, no. 2, pp. 1–11, 2015.

[4] C. Gong, J. Liu, Q. Zhang, H. Chen, and Z. Gong, “The characteristics of cloud
computing,” in 2010 39th International Conference on Parallel Processing Workshops,pp.
275–279, IEEE, 2010.
[5] Robert P Goldberg. Survey of virtual machine research. Computer, 7(6) :34–45, 1974.

[6] B. Cully et al., "Remus : High Availability via Asynchronous Virtual Machine Replica-
tion," in Proc. USENIX NSDI’08, San Francisco, USA, Apr. 2008.

[7] Qi Zhang, Mohamed Faten Zhani, Maissa Jabri, Raouf Boutaba David R. Cheriton
School of Computer Science, University of Waterloo, Canada. Venice : Reliable Virtual
Data Center Embedding in Clouds, 2019.

44