RAPPORT

DE STAGE DE FIN D’ETUDES

Pour l’obtention de la

«Licence Appliquée en Sciences et Technologies de l’Information et de

Communication (LASTIC)»

Présenté par :

OMRI Hassen

Titre
Mise en place d'un Cloud Privé avec gestion centralisée
d’hyperviseurs hétérogènes

Réalisé à

Soutenu le :03-07-2017

Devant le jury :

Encadrant: Mr Hassene Seddik & Mr Issam Benlakhdhar

Rapporteur : Mr.(Mme.)……………………………………………………………….….………

Membre : Mr.(Mme.)……………………………………………………………….….…………..
Année Universitaire : 2016 / 2017
DÉDICACES

A mes Parents,

A ma femme,

A mes enseignants tous au long de mon cursus scolaire et universitaire,

Je ferai le nécessaire pour être digne de votre respect, Toute ma gratitude.

Remerciements

Au terme de ce projet de fin d’études, mes vifs remerciements sont adressés à

tous ceux qui ont contribué, directement ou indirectement à l’élaboration de ce
projet.

Je m’adresse en premier lieu aux membres de l’honorable jury que je remercie

d’avoir bien voulu examiner et évaluer mon modeste travail.

Je tiens aussi à remercier vivement M. Hassene Seddik pour ses conseils et ses
remarques pertinentes.

Je m’adresse également à M. Issam Ben LAKHDHAR, ainsi que M.Oussama

Kammoun pour leur disponibilité, leurs directives qui m’ont permis de soigner
et d’améliorer constamment la qualité de ce travail.

3
Sommaire
Liste des figures....................................................................................................................................... 6
Liste des tableaux .................................................................................................................................... 7
Liste des acronymes ................................................................................................................................ 8
Introduction Générale ............................................................................................................................. 9
Chapitre I : Contexte du projet.............................................................................................................. 10
1. Présentation du projet .............................................................................................................. 10
1.1 Présentation de l’organisme d’accueil .............................................................................. 10
1.2 Cahier des charges............................................................................................................. 11
2. Etat de l’art ................................................................................................................................ 12
2.1 Virtualisation ..................................................................................................................... 12
2.2 Cloud Computing............................................................................................................... 14
3. Conclusion ................................................................................................................................. 16
Chapitre II : Étude des solutions de gestions multi-hyperviseurs ......................................................... 17
1. Etude de l’existant..................................................................................................................... 17
2. Solutions proposées .................................................................................................................. 18
2.1 Solutions de gestion ‘overlay’ ........................................................................................... 18
2.2 Solutions de gestions dédiées ........................................................................................... 18
3. Solution retenue........................................................................................................................ 23
3.1 CloudStack ......................................................................................................................... 24
3.2 Les versions du CloudStack................................................................................................ 24
3.3 Les composants du CloudStack ......................................................................................... 25
3.4 Modèle de déploiement du CloudStack ............................................................................ 25
4. Étude Conceptuelle ................................................................................................................... 28
4.1 Analyse des besoins........................................................................................................... 28
4.2 Identification des acteurs .................................................................................................. 28
4.3 Besoins fonctionnels.......................................................................................................... 28
4.4 Besoins non fonctionnels .................................................................................................. 29
4.5 Description du système ..................................................................................................... 29
4.6 Conception du système ..................................................................................................... 32
5. Conclusion ................................................................................................................................. 34
Chapitre III : Ingénierie de dimensionnement, sécurité et mise en place de la solution...................... 35
1. Dimensionnement ..................................................................................................................... 35

4
 1.1 Infrastructure hyper convergée ........................................................................................ 36
1.2 Dimensionnement des serveurs........................................................................................ 36
1.3 Dimensionnement du stockage......................................................................................... 38
2. Sécurité...................................................................................................................................... 40
2.1 Les différents aspects de la sécurité ................................................................................. 41
2.2 Politique de sécurité adoptée ........................................................................................... 41
3. Préparation de la mise en place de la solution adoptée ........................................................... 42
3.1 Architecture de la solution adoptée.................................................................................. 42
4. Mise en place de la solution...................................................................................................... 45
4.1 Environnement de travail.................................................................................................. 45
4.2 Mise en place de la solution CloudStack ........................................................................... 46
5. Test et validation de la solution ................................................................................................ 49
6. Conclusion ................................................................................................................................. 49
Conclusion et perspectives.................................................................................................................... 50
SITOGRAPHIE............................................................................................................................................. 51
ANNEXE 1: Détails Technique................................................................................................................ 53
ANNEXE 2 : Notions Diverses ................................................................................................................ 80

5
Liste des figures
Figure 1.1- Organigramme Databox………………………………………………………………………………………….. 11
Figure 1.2- Virtualisation des serveurs………………………………………………………………………………………. 13
Figure 1.3- Types d’hyperviseurs………………………………………………………………………………………………. 14
Figure 1.4- Services du cloud …………..…………….………………………………………………………………………… 15

Figure 2.1- Solutions de gestion multi-hyperviseurs……………………………………………………………………. 17

Figure 2.2- Tableau de bord de NEC SigmaSystemCenter……………………………………………………………. 19
Figure 2.3- Principe de fonctionnement de Hotlink SuperVisor…………………………………………………… 20
Figure 2.4- Solution Openstack…………………………………………………………………………………………………… 21
Figure 2.5– Model CloudStack.………………………………………………………………………………………………….. 22
Figure 2.6- Architecture CloudStack……………….………………………………………………………………………….. 23
Figure 2.7- Composants du CloudStack……………….…………………………………………………………………….. 25
Figure 2.8- Déploiement à petit échelle…………………………………………………………………………………….. 26
Figure 2.9- Déploiement à Grand échelle.…………………………………………………………………………………. 27
Figure 3.1- Cas d’utilisation « Gestion des services »…………………………………………………………………. 29
Figure 3.2- Cas d’utilisation « Gestion des comptes »……………………………………………………………….. 30
Figure 3.3- Cas d’utilisation « Gestion des projets »………………………………………………………………….. 31
Figure 3.4- Cas d’utilisation « Gestion des instances »…….………………………………………………………… 32
Figure 3.5- Diagramme de séquence « connexion »…………………………………………………………………… 33
Figure 3.6- Diagramme de séquence « création d’une machine virtuelle »……………………………….. 33
Figure 3.7- Diagramme de séquence « stocker des données »………………………………………………….. 34

Figure 4.1- Etape du dimensionnement…………………………………………………………………………………….. 35

Figure 4.2- Stockage SAN…………………...…………………………………………………………………………………….. 39
Figure 4.3- Stockage NAS…………………...…………………………………………………………………………………….. 39
Figure 4.4- Architecture de la solution adoptée………………………………………………………………………….. 42
Figure 4.5- Services installés sur Serveur de management………………………………………………………….. 46
Figure 4.6- Services installés partie Réseaux ………………………………………………………………………. 47
Figure 4.7- Services installés sur Stockage NFS ………………………………………………………………………… 47
Figure 4.8- Script d’installation CloudStack……….……………………………………………………………………….. 48
Figure 4.9- Instance CloudStack………………………………………………………………………………………………….. 49

6
Liste des tableaux
Table 1.1- Etude comparative des différents hyperviseurs……………………………………………………….... 14

Table 2.1- Etat des serveurs actuels……………………………………………………………………………………………. 18

Table 2.2- Les services d’Openstack……………………………………………………………………………………………. 22
Table 2.3- Etude comparative entre les différentes solutions……………….……………………………………. 24

Table 3.1- Besoins de la société………………………………………………………………………………………………….. 35

Table 3.2- Capacité des serveurs en matière de vCPU………………………………………………………………… 36
Table 3.3- Capacité offerte par la 1ere proposition………………………………………………………………………. 37
Table 3.4- Capacité offerte par la 2eme proposition……………………………………………………………………… 37
Table 3.5- Tableau comparatif entre les serveurs……………………………………………………………………….. 37
Table 3.6- Tableau comparatif entre les deux propositions………………………………………………………… 37
Table 3.7- Capacité offerte par la solution recommandée………………………………………………………….. 40

7
Liste des acronymes
API Applications Programming Interface
CPU Central Processing Unit
DAS Direct Attached Storage
DELL Development of Early Language Learning
ESXI Elastic Sky X Integrated
FC Fiber Channel
HP Hewlett Packard
IT Information Technologies
IP Internet Protocol
ISCSI Internet Small Computer System Interface
IaaS Infrastructure as a Service
KVM Kernel-based Virtual Machine
MYSQL Système de gestion de base de
données
NAS Network Attached Storage
NFS Network File System
NIST National Institute of Standards and Technology
TPE Très Petite Entreprises
PaaS Plateform as a Service
PME Petites et Moyennes Entreprises
RAM Random Access Memory
RAID Redundant Array of Independent Disks
SaaS Software as a Service
SAN Storage Area Network
vCPU virtual Central Processing Unit
VM Virtual Machine
VNC Virtual Network Computing
VPN Virtual Private Network

8
Introduction Générale
Depuis son émergence au début des années 2000, le cloud computing a connu un développement
remarquable ce qui a attiré l’intérêt de plusieurs acteurs dans le monde informatique. En effet, nom-
breux acteurs du domaine IT ont présenté leur propre solution cloud dont nous citons IBM, CISCO le
fabriquant de routeur, Microsoft et même des opérateurs de télécommunications comme le cas de
France Télécom.

Du coup, plusieurs entreprises cherchent à profiter des services offerts par le Cloud en particulier les
PME et les TPE qui sont attirées par la possibilité de payer pour consommer des ressources au lieu de
s’approprier des équipements. Mais, le problème de la sécurité reste le frein principal pour
l’adoption d’une solution Cloud.

Pour remédier à ce problème, certaines entreprises ont recours au modèle Cloud privé interne où les
ressources ne sont pas externalisées. Le seul défi à surmonter est le choix de l’hyperviseur car il est
impossible d’en changer ultérieurement. Cette étape est, donc, très importante surtout avec
l’émergence de plusieurs hyperviseurs performants ayant chacun un mode d’utilisation destiné vers
un type spécifié d’applications.

Pour bénéficier de ces caractéristiques, plusieurs entreprises cherchent à intégrer des différents hy-
perviseurs dans son environnement Cloud. C’est dans ce cadre que s’inscrit ce projet de fin d’études
intitulé ‘Mise en place d'un Cloud Privé avec gestion centralisée d’hyperviseurs hétérogènes’

Comme notre société est intéressée par ce type de projet, et elle prévoit d’avoir des marchés dans ce
domaine, c’était une occasion pour moi de monter en compétences et m’intégrer dans le domaine
de virtualisation, du coup j’ai choisi ce projet de fin d’étude parmi d’autre sujets (Qualité TL9000 …).

Tout au long de ce rapport, nous traiterons trois chapitres dont les lignes directrices sont présentées
ci-dessous.

Le premier chapitre portera sur le contour général du projet à savoir l’organisme d’accueil, les con-
cepts de virtualisation et Cloud et le cahier de charge.

Le deuxième chapitre exposera les résultats du recherche effectués pour choisir la solution la plus
adéquate vis-à-vis aux spécifications financières pour la gestion multi-hyperviseur au sein d’un seul
environnement Cloud, l’étude de l’existant et l’étude détaillée de la solution proposé (besoins fonc-
tionnels et non fonctionnels et une étude conceptuelle).

Le troisième chapitre sera consacré à l’ingénierie de dimensionnement et de la sécurité de solution

ainsi que le processus de la mise en place de la solution de test.

9
Chapitre I : Contexte du projet

Dans ce chapitre, nous passons en revue le contexte du projet : nous présentons dans un premier
temps l’organisme d’accueil ainsi qu’une description du projet et du travail demandé et nous termi-
nons par la rédaction du cahier de charge et l’étude de l’art...

1. Présentation du projet

1.1 Présentation de l’organisme d’accueil

DataBox, filiale du groupe TELNET et certifiée ISO9001 version 2008 et TL900 en 2016; opère dans
l’ingénierie et les services dans le domaine des réseaux et des télécommunications.

Crée en 1996 avec des bureaux en Tunisie, en France et en Algérie, DataBox est l’un des leaders dans
le secteur des intégrateurs systèmes et fournisseurs de solutions de réseaux servant à la fois les en-
treprises et les opérateurs sur les marchés locaux, régionaux et internationaux. DataBox est spéciali-
sé dans le déploiement des réseaux d’entreprises et des solutions d’accès clés en main pour les opé-
rateurs de télécommunications fixes et mobiles. Elle conçoit et met en œuvre des systèmes
d’information multidisciplinaires pour ses clients et fournit un large éventail de produits et de solu-
tions pour le déploiement des solutions intégrées de communications unifiées (UC).

Depuis avril 2009, DataBox opère selon un modèle Front office / Back office. Elle est présente en
Europe à travers sa filiale DataBox FRANCE. Basée à Paris, cette filiale française assure les services de
proximité clients et de développement d’affaires sur l’Europe.

DataBox est également le partenaire local en Tunisie pour de nombreux équipementiers et fabricants
de matériel de télécommunications de premier rang et offre ses services et solutions aux entreprises
et opérateurs de télécommunications.

DataBox est notamment partenaire et revendeur officiel en Tunisie de Polycom, leader mondial dans
les solutions d’audioconférence, visioconférence et téléprésence.

Au fil des ans, DataBox a mené plusieurs projets clés en main dans de nombreux pays en Afrique.
DataBox est également l’un des principaux fournisseurs de services pour Tekelec (TSP) offrant un
large éventail de services basés sur les technologies de Tekelec om à plusieurs opérateurs de télé-
coms dans la région EMEA.

Databox dispose d’une équipe technique multi disciplinaire composée de chefs de projets, ingénieurs
seniors et techniciens supérieurs disposant d’une grande expertise et expérience dans les domaines
des réseaux d’entreprise et de télécommunications comme il montre l’organigramme dans la figure
1.1.

En tant que Consultant en télécommunication au sein de la société DATABOX, je participe aux diffé-
rent projets télécommunications et informatiques. J’interviens dans les différentes phases ;
l’installation, la configuration, la mise en service et le support des solutions.

10
Figure 1.1- Organigramme Databox

1.2 Cahier des charges

Les technologies de virtualisation permettent d’exécuter sur un même ordinateur plusieurs systèmes
d’exploitation et/ou applications, sans interférer entre eux, comme s’ils fonctionnaient sur des ordi-
nateurs distincts. L’utilisation et la flexibilité du matériel sont ainsi accrues.

Depuis l’émergence de la virtualisation, Vmware était le leader du marché. Mais, dans ces dernières
années plusieurs solutions ont prouvé qu’ils sont des plateformes de virtualisation viables. Nous ci-
tons Microsoft Hyper-V, Citrix Xen, RedHat KVM,…

La virtualisation couvre aussi plusieurs domaines de l’infrastructure informatique d’une entreprise :

 Virtualisation de serveurs
 Virtualisation du stockage
 Virtualisation des applications
 Virtualisation du poste de travail

Et ça dans le but de réduire le coût de l’infrastructure virtuelle et adapter la plate-forme pour une
tâche spécifique.

Dans ce contexte, DataBox propose, dans le cadre d’un projet de fin d’études, de mettre en place un
cloud privé basé sur différents hyperviseurs.

Donc, c’est travailler sur La virtualisation des serveurs qui est une composante importante pour
l’entreprise.

11
Le projet consiste à faire l’étude des solutions de gestion des environnements multi-hyperviseurs, de
choisir la solution la plus abordable financièrement, de la dimensionner et la sécuriser.

Les bénéfices attendus par l'entreprise et de la virtualisation des serveurs sont :

 Capacité à déployer très rapidement des nouvelles infrastructures et plateformes.

 Réduction des coûts d’infrastructure.
 Augmentation des capacités de continuité d’activité.
 Augmentation de la flexibilité et la qualité des services.
 Résolution de certains problèmes technologiques.

La société possède moins de 5 serveurs physiques assez ancien et compte mettre en œuvre une solu-
tion simple et peu couteuse et donc avoir une architecture qui remplace le matériel, tout en fournis-
sant une meilleure disponibilité des serveurs applicatifs.

Des différentes solutions sont proposées:

1. Solutions de gestion « overlay »

2. NEC SigmaSystemCenter
3. Hotlink Supervisor
4. Openstack
5. CloudStack

2. Etat de l’art

2.1 Virtualisation

2.1.1 Définition
La virtualisation est l’abstraction du matériel physique afin de générer des ressources virtuelles dans
le but de faire fonctionner plusieurs machines virtuelles au sein d’une même machine physique [1].
Ainsi, la virtualisation fait intervenir trois principaux composants:

 Un système d'exploitation principal installé sur la machine physique, appelé système hôte,
car il joue le rôle d'hôte à d'autres systèmes d'exploitation;
 Un hyperviseur un outil de virtualisation installé sur le système hôte qui fournit l'environne-
ment dans lequel différentes machines virtuelles s'exécutent;
 Un système d'exploitation installé dans une machine virtuelle, appelé système invité, qui
fonctionne indépendamment des autres systèmes invités dans d'autres machines virtuelles.

On distingue plusieurs types de virtualisation :

 Virtualisation de stockage
 Virtualisation de réseau
 Virtualisation de serveurs

12
 2.1.2 Virtualisation des serveurs
La virtualisation des serveurs consiste à faire fonctionner plusieurs machines virtuelles (serveurs vir-
tuels, système d’exploitation, etc.) au sein d’un seul serveur physique. Mais dans quels intérêts ?

Il faut revenir sur le fait que, chez plusieurs entreprises, les serveurs sont utilisés uniquement à 15%
de leur capacité ce qui mène à des coûts d’investissements et de maintenance très élevés pour une
piètre performance. De coup, un serveur exploitant ces capacités s’avère plus économe qu’un en-
semble utilisant uniquement un faible pourcentage de ces capacités [2].

Ainsi, la virtualisation des serveurs offre une grande flexibilité dans la répartition des charges pour
une utilisation optimale des ressources ainsi que plusieurs autres avantages dont nous citons [2] :

 réduction des coûts en matériel et en exploitation (entretien, consommation, etc.)

 des sauvegardes et des snapshots simplifiés
 mise en place d’un cloud privé : déploiement d’un ensemble de services sous forme de ma-
chines virtuelles dimensionnées pour transformer l’informatique en un centre de services.

Figure 1.2- Virtualisation des serveurs

2.1.3 Les Hyperviseurs

L'hyperviseur est une couche logicielle permettant à un ensemble de systèmes d'exploitation de
s'installer et fonctionner simultanément sur une même machine physique.
Cette couche légère contrôle le processeur et les ressources du système hôte sur lequel il est installé
et les alloue sous forme de ressources virtuelles aux systèmes invités ainsi d’une variété de fonction-
nalité.
De nos jours, il existe une variété d’hyperviseurs payants et gratuits. On peut les classer en deux
types [1]:

 Natif : ou type 1, s'installe directement sur la couche matériel du serveur. C'est un logiciel qui
s'exécute sur une plate-forme. Cette dernière joue le rôle d'un outil de gestion des systèmes
d'exploitation hébergés. Nous citons comme exemples : Hyper-V, XenServer, VMware ESXi ;

 Hébergé : ou type 2, s'installe sur des systèmes d'exploitation installés sur les machine hôtes.
Il se démarre comme une simple application. Les machines virtuelles hébergées s'exécutent

13
 en totale abstraction du système d'exploitation hôte. Nous citons comme exemples : KVM,
VMware Workstation, VirtualBoX.

Il faut noter que chaque hyperviseur possède son propre logiciel de gestion. C’est une interface gra-
phique dans le but de simplifier l’usage de l’hyperviseur associé.

Hyperviseur type1 Hyperviseur type2

Figure 1.3- Types d’hyperviseurs

2.1.4 Étude comparative des technologies de virtualisation

Le tableau 1.1 présente un nombre d’avantages et inconvénients des principaux hyperviseurs pré-
sents dans le marché de virtualisation

Hyperviseur Logiciel de gestion Avantages Inconvénients

La solution la plus per- Coût de déploiement
ESXI Vcenter
formante élevé
Hyper-V Hyper-V manager Solution performante Coût de License élevée
Produit libre
KVM Virt-manager Intégré dans noyau de Moins performant
linux
un hyperviseur de
Déploiement rapide type I - ce qui signifie
Xen Virt-manager qui ne consomme pas qu'il se trouve sur une
trop de ressources seule couche au-
dessus du métal nu
Table 1.1- Etude comparative des différents hyperviseurs

2.2 Cloud Computing

2.2.1 Définition
« Le cloud computing ou l’informatique en nuages est une nouvelle façon de délivrer les ressources
informatiques, et non une nouvelle technologie.»
Cette définition, proposée par l'institut national de standardisation des technologies (NIST), est utili-
sée comme référence. En d’autres mots, le cloud computing permet un accès sur demande, à travers
un réseau internet, à une poule de ressources informatiques configurables (réseaux, serveurs, stock-
age, applications et services) [3].

14
 2.2.2 Les services du cloud
Nous parlons généralement de 3 services que nous utilisons différemment selon nos besoins. Cer-
tains appellent ces services les couches de clouds et nous les représentons souvent sous forme
d’une pyramide comme la montre la figure [4].

Figure 1.4- Services du cloud

IaaS : Infrastructure as a service : c’est la couche inférieure qui représente les ressources matérielles
(puissance de calcul, espace de stockages, serveur ….). Les clients, à ce niveau n’ont pas de contrôle
sur ces ressources mais plutôt sur les systèmes d’exploitation et les applications qu’ils peuvent instal-
ler sur le matériel alloué.

PaaS : Plateforme as a Service, c’est la couche intermédiaire où le fournisseur contrôle le système

d’exploitation et les outils d’infrastructure et par suite les clients n’ont le contrôle que sur les appli-
cations déployées.

SaaS : Software as a service, c’est la couche supérieure qui correspond à la mise à disposition des
applications comme étant des services accessibles via internet. Les clients n’ont plus besoin donc à
installer les applications sur ses postes.

2.2.3 Modèle de déploiement

Nous distinguons quatre modèles de déploiement qui n’ont pas une grande influence sur les sys-
tèmes déployés [4].

 Cloud public : C’est le cloud dans le sens traditionnel où les services sont offerts au grand pu-
blic et peuvent être payants ou même gratuit. Les ressources dynamiquement provisionnées
peuvent être accessibles par internet ou bien par un fournisseur.
 Cloud privé : Ce cloud est destiné entièrement à un organisme et peut être déployé sous
deux formes déférentes :
 Cloud privé interne : Hébergé et géré par l’entreprise
 Cloud privé externe : Hébergé et géré par un tiers et accessible via des réseaux de type
VPN.
 Cloud hybride : C’est la combinaison du cloud public et cloud privé par une entreprise.

15
  Cloud communautaire : Un ensemble d’organisations qui ont un intérêt commun partagent
l’infrastructure du cloud. Il est plus couteux que le cloud public mais offre d’autres avan-
tages.

2.2.4 Cloud privé

Le cloud privé est la mise en place d’un centre de données propriétaire fournissant un ensemble de
services hébergés pour un ensemble d’utilisateurs. Il peut être administré directement par
l’entreprise dans ce cas nous l’appelons cloud privé interne ou par un prestataire de confiance et
nous l’appelons dans ce cas cloud privé externe [6].

Ce modèle est le modèle le plus adopté par les entreprises, selon une enquête publiée par le cabinet
d’études Pierre Audion, avec un pourcentage de 71% contre 7% pour le cloud public. Ceci est dû au
fait que le cloud privé apporte les avantages du cloud public mais sans ses inconvénients qui sont lié
principalement à la sécurité des données [7].

2.2.5 Infrastructure as a service IaaS

L’IaaS donne l’accès à des ressources informatiques virtualisées (espace de stockage, CPU, adresse IP,
etc.). Pour simplifier, les entreprises utilisent le service IaaS pour créer ses propres solutions informa-
tiques facilement extensibles avec des coûts abordables [5].

Dans le cas d’un cloud privé externe, les ressources physiques sont localisées chez un fournisseur de
cloud alors que dans le cas d’un cloud privé interne les équipements sont hébergés chez l’entreprise.

3. Conclusion

Les éléments présentés dans ce chapitre ont aidé à mieux comprendre le projet et à dégager
l’objectif principal. Dans le chapitre suivant, on va faire une étude des solutions de gestion des hy-
perviseurs afin de sélectionner celle qui répond à cet objectif.

16
Chapitre II : Étude des solutions de gestions multi-hyperviseurs

Ce chapitre est consacré à l’étude des différentes solutions qui peuvent répondre à notre besoin:
gestion des plusieurs hyperviseurs. Après l’étude de l’existant, nous présentons, les solutions de ges-
tion « overlay ». Ensuite, nous faisons une étude comparative entre les meilleurs quatre solutions de
gestion dédiées et nous finissons par le choix le plus adéquat avec une étude conceptuelle détaillée.

Figure 2.1- Solutions de gestion multi-hyperviseurs

1. Etude de l’existant

La solution adoptée par DataBox jusqu’à présent est plutôt un réseau local qu’un cloud privé. Ce
réseau est constitué par un ensemble de plateformes basé sur des différents hyperviseurs adminis-
trés d’une manière isolée.

De plus, les serveurs tournent en deçà de leurs capacités comme le montre le tableau 2.1 et ils sont
repartis d’une manière déséquilibrée entre les différentes plateformes : Vmware utilise 80% des ser-
veurs, contre 20% pour KVM.

Quant à la sécurité, elle est restreinte à celle offerte par chacun des hyperviseurs.

Cette solution présente alors plusieurs inconvénients notamment :

 Manque de communication entre les plateformes à cause de l’hétérogénéité des hypervi-

seurs et la politique d’administration différentes.
 Mauvaise gestion de ressources
 Manque de mécanismes de sécurité : absence d’une politique de sécurité.

17
Les besoins principaux sont donc :
 Une gestion centralisée : un outil pour la fédération de différentes plateformes.
 Bénéficier des nouvelles technologies : cloud privé, sécurité.
 Étendre les capacités IaaS pour subvenir aux besoins futurs de l’entreprise suivant une stra-
tégie bien définie.

Serveur Capacité actuelle Capacité maximale

CPU 20 CPU 20 CPU
Dell R730 RAM 96 GB 3 TB
Disque 600 GB 29 TB
CPU 4 CPU 4 CPU
Dell R310 RAM 24 GB 32 GB
Disque 500 GB 8 TB
CPU 8 CPU 8 CPU
HP dl 380 G6 RAM 8 GB 192GB
Disque 4*72 GB 8 TB
CPU 2 CPU (4 cœurs) 4 CPU
HP dl 380 G5 RAM 8 GB 64 GB
Disque 200 GB 2 TB
CPU 2 CPU (4 cœurs) 4 CPU
HP dl 380 G5 RAM 16 GB 64 GB
Disque 500 GB 2 TB
Table 2.1- Etat des serveurs actuels

2. Solutions proposées

2.1 Solutions de gestion ‘overlay’

Ce type de solutions consiste en la superposition de plusieurs outils de gestion ce qui est très difficile
et coûteux surtout que les résultats obtenus ne sont pas satisfaisant puisqu’ils sont limités par les
APIs [10].

Nous citons comme exemple la superposition de Vkernel comme un outil de supervision de la per-
formance et de la capacité avec un outil de gestion applicative comme AppDynamics, BleuStripe et
finalement un outil de sauvegarde (backup) comme Veeam pour former une pile de gestion [11].

Les solutions « overlay »ne fournissent que des fonctions de base et nécessitent les consoles natives
de chaque hyperviseurs ce qui complique la gestion.

Ces inconvénients montrent bien les limites de ce type de solutions dans notre contexte.

Notre choix est alors porté vers les solutions dédiées.

2.2 Solutions de gestions dédiées

2.2.1 NEC SigmaSystemCenter

NEC SigmaSystemCenter est un produit qui prend en charge les quatres grands produits de virtualisa-
tions : Vmware, Hyper-V, XenServer et KVM et présente des fonctions de gestion (installation de
18
système d’exploitation, sauvegarde, restauration, etc.) à partir d’une seule console [10]. Nous cons-
tatons de nombreux avantages

Figure 2.2- Tableau de bord de NEC SigmaSystemCenter

Pour un environnement virtualisé parmi lesquelles nous citons :

 Allocation des ressources : NEC SigmaSystemCente surveille l’état de la charge opéra-

tionnelle, et dans le cas d’une charge élevée, la fonction permet la réallocation des
VMs pour égaliser la charge.
 Disponibilité : NEC SigmaSystemCente surveille l’état des serveurs pour détecter la
défaillance du matériel et/ou logiciel. Ceci permet de réduire et même éviter le temps
d’arrêt du système grâce à la fonction « live migration ».
Il faut noter que ce produit est propriétaire à NEC et il est payant.

2.2.2 Hotlink Supervisor

Hotlink Supervisor est un plugin qui étend les capacités de gestion de VMware vCenter pour
supporter d’autres hyperviseurs : Hyper-V, KVM et XenServer, sans l’utilisation d’autres con-
soles grâce à l’abstraction de la métadonnée de l’infra- structure virtuelle de l’hyperviseur qui
découple VMware VCentre de l’hyperviseur VMware VSphere en utilisant la technologie Ho-
tlink Transformation Engine [8].

VCenter server est utilisé pour la gestion de plusieurs hôtes ESXI (dans le cas d’un seul hôte
nous utilisons Vsphere client). Il permet l’ajout, la suppression et toutes actions de gestion
des VMs en utilisant une interface graphique.

19
Figure 2.3- Principe de fonctionnement de Hotlink SuperVisor

Hotlink Supervisor nous permet, donc, de choisir l’hyperviseur le plus adéquat pour chaque cas
d’utilisation, ainsi que plusieurs autres fonctions, citons : cloner, snapshot, migration de charge entre
les hyperviseurs.

Pour résumer, ce plugin nous permet de [10] :

- Gérer des différents hyperviseurs à partir d’une seule console.
- Eliminer les obstacles techniques mis par les vendeurs.
- Réduire le coût de l’infrastructure.
Comme le cas de NEC SygmaSystemCenter, Hotlink superVisor est une solution propriétaire avec un
coût d’achat relativement cher (environ 52 million).

2.2.3 Openstack
Openstack est une plate-forme open-source utilisée pour déployer des infra- structures de cloud
(IAAS). Il est composé d’un ensemble de projets (ou composants : Nova, Swift,etc.) qui sont étroite-
ment liés les uns par rapport aux autres [11] [13].

OpenStack prend en charge plusieurs types d’hyperviseur sur un seul cloud, et par la suite nous pou-
vons utiliser KVM, Hyper-V et Vmware dans un seul environnement avec une interopérabilité com-
plète à condition que chaque hyperviseur doive être associé à un seul nœud de calcul (compute
node) [12].

20
Figure 2.4- Solution Openstack

 Les composants d’Openstack

Comme déjà mentionné, Openstack possède une architecture modulaire : composé de plusieurs
éléments que nous allons présenter dans le tableau 2.3 ainsi que les interactions entre eux comme le
montre la figure [13].

Service Projet Description

propose une application web qui permet aux
la gestion du Cloud à travers une interface graphique.
Tableau de bord Horizon Horizon est capable d’interagir avec les APIs des diffé-
rents services d’Openstack.

contrôle l’hyperviseur et gère les ressources

Calcul Nova de l’infrastructure et les instances dans
l’environnement.
gère la partie réseau dans l’Openstack. Les
utilisateurs peuvent créer leurs propres ré- seaux et
Réseau Neutron routeurs virtuels et interconnecter leurs instances au
réseau externe
Stocke et récupère arbitrairement les objets de
données non structurés à travers le Web service
Stockage d’objet Swift RESTful. Swift est très tolérant aux erreurs dues aux
réplications de données.
Procure des blocks de stockage persistants
pour les instances en cours d’exécution.
Stockage de blocs Cinder L’architecture de son pilote facilite la création et la
gestion des blocks de stockage.
Service d’identité Keystone fournit un service d’authentification et de gestion de
rôle et autorisation.

21
 stocke les images des machines virtuelles utilisées pour
Service d’imagerie Glance lancer les instances à travers le pro- jet nova.

collecte les informations sur l’utilisation des

Télémétrie Celiometer ressources pour le service de facturation.
Orchestration Heat Orchestre les différents composants du cloud.
Service de base de installe et de gère facilement des instances de
données Trove base de données au sein d’Openstack.
Table 2.2- Les services d’Openstack

2.2.4 Cloudstack
CloudStack est une plate-forme logicielle constituée d’un ensemble de ressources informatiques
pour construire des infrastructures publiques, privées et hybrides en tant que services (IaaS) dans les
nuages. CloudStack gère le réseau, le stockage et les nœuds de calcul qui composent une infrastruc-
ture dans les nuages. Il est aussi utilisé pour déployer, gérer et configurer les environnements
d'informatiques dans les nuages.
S'étendant au-delà des machines virtuelles individuelles fonctionnant sur du matériel standard,
CloudStack offre une solution d'informatique en nuage clé en main pour fournir des centres de don-
nées virtuels comme service fournissant tous les composants essentiels pour construire, déployer et
gérer des applications 'cloud' multi-niveaux et multi-locataire. Les versions libres et Premium sont
disponibles, la version Libre offrant des caractéristiques presque identiques à celles de la version
Premium [15].

Figure 2.5– Model CloudStack

22
CloudStack travaille avec une variété d'hyperviseurs et de technologies hyperviseurs. Un seul nuage
peut contenir plusieurs implémentations d'hyperviseurs.

CloudStack prend en charge:

 BareMetal (via IPMI)

 Hyper-V

 KVM

 vSphere (via vCenter)

 Xenserver

 OVM

Figure 2.6– Architecture CloudStack

3. Solution retenue

Dans notre étude des solutions qui répondent à notre besoin, nous avons commencé par la présenta-
tion des solutions « overlay » qui montre plusieurs inconvénients par rapport aux solutions dédiées
parmi lesquelles nous avons présenté les quatre solutions les plus utilisées:

23
 NEC SigmaSystem-Center Hotlink Supervisor OpenStack CloudStack

Solution IaaS OUI OUI OUI OUI

Gestion à partir

d’une seule console OUI OUI OUI OUI

Live Migration OUI OUI OUI OUI

Colner, Snapshot OUI OUI OUI OUI

Payante OUI OUI NON NON

Table 2.3– Étude comparative entre les différentes solutions

Les services offerts par SigmaSystemCenter et Hotlink SuperVisor certes intéressantes ne justifient
pas le coût d’achat relativement cher dans notre contexte surtout que ces mêmes services sont assu-
rés par les produits open-source OpenStack et CloudStack.

En outre, la solution OpenStack sera plus efficace pour les grandes entreprises car elle se compose de
plusieurs nœuds donc elle nécessite plusieurs ressources (serveurs, RAM, disque …) d’où, notre choix
est fixé sur la solution du CloudStack et nous allons la détailler dans la suite.

3.1 CloudStack
Développée initialement par Cloud.com, la plateforme CloudStack a été acquise par Citrix en 2011 et
remise à l’Apache Software Foundation en 2012. CloudStack est un logiciel libre de la fondation
apache. Il permet de créer des Cloud Computing privés et publics. Malgré sa sortie récente, il jouit
d'une popularité chez les professionnels du secteur. L'avantage de ce logiciel c'est qui peut être faci-
lement intégrer dans une architecture déjà existante. Il est compatible avec les différentes couches
matérielles.

Ses avantages sont les suivants :

 Prend en charge un grand nombre d'hyperviseur

 Extensible

 Orienté petites et moyennes entreprises

 Documentation détaillée

 Déploiement fluide

3.2 Les versions du CloudStack

Depuis son lancement, la communauté du CloudStack a livré plusieurs versions à partir de la version
4.0.0 jusqu’au la version 4.9.2.0
24
Dans notre cas, on va installer la dernière version 4.9.2.0 vu la compatibilité de cette version avec les
ressources disponibles dans la société (serveurs, RAM …)

3.3 Les composants du CloudStack

Le CloudStack se compose de sept instances décrites dans la Figure 2.7 :

 Management Server: Responsable de toutes les tâches de gestion et d'approvisionnement

 Hosts: Serveur sur lequel les services seront approvisionnés
 Cluster: Un regroupement d'hôtes et leur stockage associé
 Pod: Collection de clusters
 Zone: Collection de Pods, offres de réseau et stockage secondaire
 Stockage Primaire: Stockage VM
 Stockage Secondaire: Modèle, capture instantanée et stockage ISO
 Réseau : Réseau logique associé à des offres de services

Figure 2.7– Composants du CloudStack

3.4 Modèle de déploiement du CloudStack

L'architecture utilisée dans un déploiement varie en fonction de la taille et du but de ce dernier.
Cette section contient des exemples d’architecture, y compris un déploiement à petite échelle utile
pour les tests et les essais et une configuration à grande échelle entièrement redondante pour les
déploiements de production [16].

25
 3.4.1 Déploiement à petite échelle
Ce diagramme illustre l'architecture réseau d'un déploiement CloudStack à petite échelle.

 Un pare-feu fournit une connexion à Internet. Le pare-feu est configuré en mode NAT. Il
transmet les requêtes HTTP et les appels API depuis Internet au serveur de gestion. Le ser-
veur de gestion réside sur le réseau de gestion.

 Un commutateur couche-2 connecte tous les serveurs physiques et le stockage.

 Un serveur NFS unique fonctionne comme stockage principal et secondaire.

 Le serveur de gestion est connecté au réseau de gestion.

On a pris le choix d’utiliser ce type de déploiement

Ce modèle de déploiement peut être installé sur un seul serveur physique comme sur plusieurs
comme le montre la figure suivante :

Figure 2.8- Déploiement à petit échelle

3.4.2 Déploiement redondant à grande échelle

Ce model illustre l'architecture réseau d'un déploiement CloudStack à grande échelle.

 Une couche de commutation de couche 3 est au cœur du centre de données. Un protocole de

redondance de routeur comme VRRP devrait être déployé. Les commutateurs de base générale-
ment haut de gamme incluent également des modules pare-feu. Des appareils pare-feu séparés
26
 peuvent également être utilisés si le commutateur couche 3 n'a pas de fonctionnalités de pare-
feu intégrées. Ils sont configurés en mode NATet ils fournissent les fonctions suivantes:

* Transmet les requêtes HTTP et les appels API depuis Internet vers le serveur de gestion.

* Lorsque le nuage s'étend sur plusieurs zones, les pare-feux doivent permettre le VPN de site à
site afin que les serveurs dans différentes zones puissent se joindre directement.

 Une couche de commutateur d'accès couche-2 est établie pour chaque module. Plusieurs com-
mutateurs peuvent être empilés pour augmenter le nombre de ports. Dans les deux cas, des
paires redondantes de commutateurs de couche 2 doivent être déployées.
 Le cluster du serveur de gestion (y compris les équilibreurs de charge, les nœuds du serveur de
gestion et la base de données MySQL) est connecté au réseau de gestion via une paire d'équili-
breurs de charge.
 Les serveurs de stockage secondaires sont connectés au réseau de gestion.
 Chaque module contient des serveurs de stockage et de calcul. Chaque serveur de stockage et de
calcul devrait avoir des NIC redondantes connectées à des commutateurs d'accès couche 2 sépa-
rés.

Figure 2.9- Déploiement à Grand échelle

27
 4. Étude Conceptuelle

Nous faisons dans cette partie une modélisation du système, qui implémente la solution retenue
dans le chapitre précédent, afin de définir les besoins fonctionnels et non fonctionnels et établir une
description du système sous forme d’un ensemble de diagrammes de cas d’utilisation en mettant en
valeur la conception de la solution dans la fin du chapitre.

4.1 Analyse des besoins

Nous allons définir en premier temps les acteurs agissant sur notre système, en deuxième temps les
besoins fonctionnels selon ces acteurs et les besoins non fonctionnels.

Nous finissons par une description détaillée de système.

4.2 Identification des acteurs

Comme nous traitons la mise en place d’un cloud privé interne où les services du cloud sont hébergés
et gérés par l’entreprise, les principaux acteurs sont :

 l’administrateur: L'administrateur est toute personne physique ayant reçu les droits d'ad-
ministration. Généralement, lors de l'installation, on configure les droits du premier adminis-
trateur.

 l’utilisateur: L'utilisateur est toute personne physique de l'entreprise ayant reçu un compte
d'accès.

4.3 Besoins fonctionnels

Selon la nature de l’acteur, notre système doit assurer les besoins fonctionnels suivants :

 L’administrateur :

-La gestion des services : Ajout et suppression ou activation et désactivation des services CloudStack
dans le système.

-La gestion des comptes : Création et modification des comptes utilisateurs en spécifiant les privi-
lèges.

-La gestion des projets : Création et modification des projets et les associer à des comptes utilisa-
teurs.

-La gestion des instances : Création et modification des instances et les associer à des projets.

 L’utilisateur :

-La gestion des instances : Création et modification des instances et les associer à des projets.

28
 4.4 Besoins non fonctionnels
Ce sont des besoins qui caractérisent le système dont nous citons :

-Accès : accès à la ressource est facile à travers un tableau de bord depuis un navigateur

-Performance : répond aux différents besoins fonctionnels

-Disponibilité : application disponible à l’usage à tout moment

4.5 Description du système

Gestion des services : Le diagramme de cas d’utilisation illustré dans la figure 3.1 présente les fonc-
tionnalités effectuées par l’administrateur dans le cadre de la gestion des services.

L’administrateur peut :

 Ajouter ou supprimer un service

 Consulter la liste des services activés,

 Modifier l’état des services (activé / désactivé).

Figure 3.1– Cas d’utilisation « Gestion des services »

29
Gestion des comptes : Le diagramme de cas d’utilisation illustré dans la figure 3.2 présente les fonc-
tionnalités effectuées par l’administrateur dans le cadre de la gestion des comptes.

L’administrateur peut :

 Créer de nouveaux comptes utilisateur

 Consulter la liste des comptes utilisateur qui ont été créés

 Désactiver ou supprimer des comptes utilisateur existants

Figure 3.2– Cas d’utilisation « Gestion des comptes »

Gestion des projets : Le diagramme de cas d’utilisation illustré dans la figure 3.3 présente les fonc-
tionnalités effectuées par l’administrateur dans le cadre de la gestion des projets.

L’administrateur peut :

 Créer des nouveaux projets,

 Supprimer ou modifier les détails d’un projet

 Affecter des utilisateurs à un projet

 Consulter la liste des projets qui ont été créés

30
Figure 3.3– Cas d’utilisation « Gestion des projets »

Gestion des instances: Le diagramme de cas d’utilisation illustré dans la figure 3.4 présente les fonc-
tionnalités effectuées par l’administrateur ou l’utilisateur dans le cadre de la gestion des instances.

L’administrateur peut :

 Créer des instances

 Supprimer, modifier et redemander une instance

 Connecter à sa console VNC

 Consulter la liste des instances existantes

31
Figure 3.4– Cas d’utilisation « Gestion des instances »

4.6 Conception du système

Selon les ressources disponibles dans la société, nous avons donc essayé la première installation sur
un seul nœud dans lequel tous les services ainsi que toutes les instances sont hébergés dans le
même serveur. Cette solution nous permet uniquement d’effectuer des tests sur le Cloud pour des
fins purement techniques.

Ci-dessous les diagrammes de séquences décrivant les manipulations faites par les administrateurs et
les utilisateurs :

32
 Diagramme de séquence du cas d'utilisation « Connexion »

Figure 3.5- Diagramme de séquence « connexion »

 Diagramme de séquence du cas d'utilisation « Création d’une machine virtuelle »

Figure 3.6- Diagramme de séquence « création d’une machine virtuelle »

33
 Diagramme de séquence du cas d'utilisation « Stocker des données »

Figure 3.7- Diagramme de séquence « stocker des données »

5. Conclusion

Nous avons identifié, dans ce chapitre, les solutions proposées, la solution adéquate ainsi que les
différents acteurs et nous avons spécifié les besoins. Nous avons effectué aussi une étude concep-
tuelle des projets que nous allons les adopter dans notre solution pour faciliter la tâche de dimen-
sionnement et l’installation présentée dans le chapitre suivant.

34
Chapitre III : Ingénierie de dimensionnement, sécurité et mise en
place de la solution

L’ingénierie est une approche scientifique rigoureuse dans le but d’étudier la conception et la réalisa-
tion d’un projet. Ce terme est souvent associé à un domaine comme l’exemple de l’ingénierie infor-
matique ou comme notre cas l’ingénierie de dimensionnement portant sur le matériel informatique
et l’ingénierie de sécurité qui traite l’ensemble des moyens assurant la sécurité d’un système infor-
matique.

L’objectif de ce chapitre est, donc, de décrire la procédure de dimensionnement de la solution, pré-

senter la politique de sécurité qui sera adoptée ainsi la mise en place de la solution.

1. Dimensionnement

Après avoir analysé la stratégie adoptée par la société et exploré ses activités futures, nous avons
abouti à identifier les besoins de la société sur les prochaines cinq années en terme de CPU, mémoire
et stockage et les présenter dans le tableau suivant.

Année vCPU RAM(GB) Storage(TB)

Fin 2017 120 276 6
2018 180 414 11
2019 234 518 18
2020 293 596 24
2021 323 656 29
Table 3.1- Besoins de la société

Dans cette section, nous allons dimensionner notre solution suivant ces besoins et les exigences mi-
nimales de notre conception.

Notre dimensionnement sera découpé en deux parties comme le montre la figure.

Figure 4.1- Etape du dimensionnement

35
 1.1 Infrastructure hyper convergée
Une architecture traditionnelle d’un Datacenter, implémentée généralement dans les PMEs, est
dimensionnée à l’avance avec une opération cyclique de remplacement des équipements : les infor-
maticiens sont obligés à dimensionner individuellement chaque ressource ce qui présente plusieurs
inconvénients notamment :

 L’achat superflu : acheter plus du matériel que nécessaire ce qui implique un gaspillage
d’argent.
 L’achat insuffisant : ne pas acheter suffisamment de matériel

Par contre, l’approche de dimensionnement est un peu différente pour les infrastructures hypercon-
vergées où les informaticiens rajoutent un ou plusieurs nœuds de ressources en fonction des besoins
à une architecture déjà dimensionnée d’une façon minimale. Le seul inconvénient est que parfois on
est obligé de rajouter des ressources de calcul et RAM alors qu’on doit agir seulement sur la capacité
de stockage c’est pourquoi on utilise les baies de stockage pour contourner ce problème [17].

Le système utilisé par DataBox est un système hyper convergé avec une infrastructure initiale com-
posée des serveurs présentés dans le tableau 2.1.

1.2 Dimensionnement des serveurs

Avant d’entamer la planification, il faut d’abord prendre en considération les serveurs dans lesquelles
les nœuds de contrôle et réseau seront déployés. Nous proposons dans ce contexte, le déploiement
de ces nœuds sous la forme des VMs sur le même serveur pour gagner plus de ressources. Ce serveur
sera donc dédié au déploiement des nœuds de contrôle et réseau et ne sera pas considérer dans la
partie dimensionnement [17].

Notre choix : serveur HP dl 380 G5

Après avoir analysé les objectifs à atteindre sur les cinq prochaines années ainsi que les capacités
actuelles des serveurs, nous constatons qu’une simple extension au niveau de RAM des serveurs
peut couvrir les besoins jusqu’à 2020.

Cependant, les serveurs de DataBox sont saturés en matière de vCPU d’où la nécessité de rajouter
des nouveaux serveurs.

Serveur vCPU
Dell R730 2*20=40
Dell R310 2*4=8
HP dl380 G6 2*2*8=32
HP dl380 G5 2*2*4=16
TOTAL 96
Table 3.2- Capacité des serveurs en matière de vCPU

36
Nous avons donc en total 96 vCPU alors que Databox a besoin de 120 vCPU à la fin de 2017.

Nous allons mener une étude comparative sur deux propositions envisageables de dimensionnement
répondant aux besoins en termes de vCPU. Cette étude aboutira à établir le choix le plus approprié
minimisant les coûts tout en garantissant la performance.

1ere proposition: 2* Dell Poweredge R930 +HP dl380 G9

Poweredge R930 est le serveur le plus puissant proposé par Dell. Il possède quatre sockets, conçu
pour les applications entreprises les plus exigeantes [27].

HP dl380 G9 est la 9éme génération des serveurs dl380, les serveurs les plus vendus au monde, con-
çu pour s’adapter à n’importe quel environnement [29].

Les caractéristiques techniques des deux serveurs sont fournies dans l’annexe.

vCPU RAM
2*Dell R930 2*96 2*6TB
HP dl 380 G9 36 3TB
Total 228 15TB
Table 3.3- Capacité offerte par la 1ere proposition

2éme proposition: 6*Dell Poweredge R730

Poweredge R730 est parmi les serveurs les plus puissants proposés par Dell. Il possède deux sockets,
conçu pour les applications entreprises les plus exigeantes [28].

vCPU RAM
6*Dell R730 6*40 6*1.5TB
Total 240 9TB
eme
Table 3.4- Capacité offerte par la 2 proposition

Le choix entre ces deux cas de figure sera basé entièrement sur des critères relatifs au coût et à
l’espace physique occupé. Il y a d’autres critères comme le bruit et la chaleur dégagée mais comme
les serveurs sont dans une salle isolée et climatisée, nous pouvons ne pas les considérer.

HP G9 R930 R730
Support 2U 4U 2U
End of life - - -
Prix Environ 15 million Environ 50 million Environ 25 million
Table 3.5- Tableau comparatif entre les serveurs

Pour finaliser notre choix, nous proposons dans le tableau une comparaison entre les deux proposi-
tions.

1ere proposition 2eme proposition

Support 10U 12U
Coût Environ 115 million Environ 150 million
Table 3.6- Tableau comparatif entre les deux propositions

37
 1.3 Dimensionnement du stockage
Pour bien dimensionner le stockage dans notre solution, nous allons, tout d’abord, rappeler les con-
cepts de base sur les baies de stockage.

1.3.1 Baie de stockage

Une baie de stockage est un équipement de sauvegarde de donnée composé de [19]:

 Ensemble de disques : ou les données seront emmagasinées

 Processeur : pour traiter toutes les informations ainsi que les demandes d’écriture et de lecture
 Connecteur : ISCSI, FC, Ethernet
 Bus : élément permettant la communication entre les différents composants de la baie

1.3.2 Système de stockage

On distingue trois types de stockage :

i. Stockage direct DAS :

La baie de stockage est directement liée à un serveur en particulier via SCSI. Elle est non accessible à
d’autres serveurs. Contrairement au système SAN et NAS, les données ne sont pas envoyées à travers
un réseau ce qui fournit de meilleurs performances. Par contre, le stockage DAS est complexe à
administrer, en effet, il faut gérer autant d’espace qu’il y a de serveurs puisque le stockage n’est pas
mutualisé [19].

ii. Storage Area Network SAN :

C’est un réseau de stockage dédié et indépendant basé sur le protocole Fiber Channel constitué de :

 Réseau très haut débit à fibre optique

 Equipement d’interconnexion exemple commutateur

 Baies de stockage

Le stockage SAN offre, donc, des performances de haute qualité avec la possibilité de partager des
données entre plusieurs serveurs ou ordinateurs puisque le trafic SAN est séparé de celui des utilisa-
teurs.

Cependant, le coût d’un stockage SAN est très élevé vu la nécessité d’équipements dédiés qui sont
encore chers [18][19].

38
Figure 4.2-- Stockage SAN

iii. Stockage en réseau (NAS) :

La baie de stockage, permettant le stockage et le partage des fichiers, est liée au réseau local (Ether-
net). En effet, la baie de stockage possède sa propre adresse IP et elle est connectée directement au
réseau local de l’entreprise [18] [19].

Figure 4.3- Stockage NAS

1.3.3 Les disques durs

En matière de stockage le choix des disques est très important non seulement sur le niveau tech-
nique mais aussi sur le niveau financier [19] [20].

 Disque SATA :

SATA (Serial Advanced Technology Attachement) est un protocole de transfert utilisé pour relier une
unité de masse généralement disque dur à une carte mémoire.

Les disques SATA utilisent ce protocole pour l’envoie des commandes. Cependant, ces disques ne
peuvent envoyer qu’une commande à la fois : écriture ou lecture, c’est ce qu’on appelle la technolo-
gie « half duplex ».

Les disques SATA sont utilisés souvent dans les PC et rarement dans des serveurs.

Caractéristiques :

39
  Débit max : 6GB
 Tour/min max : 7200 Tr/min
 Format disponible : 2.5 pouce, 3.5 pouce

 Disque SAS :

SAS (Serial Attached SCSI) est une solution d’interface de stockage. C’est une évolution du bus SCSI
parallèle dérivé du modèle SATA.

Contrairement au disque SATA, un disque SAS possède un seul connecteur pour l’alimentation et le
transfert des données et utilise la technologie « full duplex » puisqu’il peut envoyer deux com-
mandes en même temps.

Ce type de disques est utilisé généralement sur des serveurs pour supporter les applications de
virtualisation et de base de données.

Caractéristiques :

 Débit max : 12GB

 Tour/min max : 15000 Tr/min
 Format disponible : 2.5 pouce, 3.5 pouce

1.3.4 Choix de la baie de stockage

Pour le moment, Databox utilise la technologie iSCSI dans son système de stockage avec l’intention
de migrer vers la technologie Ethernet dans un premier temps et vers la fibre optique dans un se-
cond temps.

Pour cela, en considérant les notions définies précédemment, nous recommandons l’achat des bais
de stockage HP MSA 1040 monté par des disques SAS disposés en RAID 5+1 (voir annexe).

Cette baie de stockage, possédant deux contrôleurs iSCSI et deux ports réseaux, peut être utilisé avec
les technologies iSCSI, Ethernet ou bien Fiber Channel d’où lors de la migration, la société n’est pas
obligée à changer son matériel.

Stockage
MSA 30 6TB
3*MSA 1040 3*10TB
Total 36TB
Table 3.7- Capacité offerte par la solution recommandée

2. Sécurité

La sécurité du Cloud Computing est un sous domaine de la sécurité informatique, sous développé,
qui a vu le jour avec l’apparition du cloud computing. Cependant, la sécurité est aussi la raison prin-
cipale qui freine les sociétés d’adopter les services cloud.

40
Nous présentons dans cette section quelques notions utiles relatives à la sécurité dans le cloud ainsi
que la politique adoptée.

2.1 Les différents aspects de la sécurité

2.1.1 La sécurité physique

Ce type de sécurité concerne l’environnement physique du déploiement .Dans notre cas, ça ne nous
intéresse pas comme les mesures de sécurité sont déjà prise auparavant par la société [21].

Nous tenons quand même à les énumérer :

 L’emplacement des serveurs : salle isolée avec accès restreint

 Protection contre les coupures et les variations de courant : l’utilisation des onduleurs et gé-
nérateur

 Climatisation: salle équipé de climatiseur avec des capteurs de chaleur, détecteur

d’incendie etc.

2.1.2 La sécurité logique

Dans le cadre d’un modèle IaaS, comme notre cas, la virtualisation des serveurs fournissent
l’abstraction des services d’où la nécessité de sécuriser ces serveurs. Ceci peut être effectué grâce à
des pratiques de sécurité spécifiques comme la gestion de mise à jour de sécurité ainsi que la notion
d’isolation des flux : flux administratif, flux des VMs, etc.

La segmentation de réseau aussi fait partie de la sécurité logique mais nous ne pouvons pas encore
l’adopter comme nous sommes transparents par rapport aux services qui seront déployé sur le cloud
[21].

2.1.3 La sécurité des données

Pour la sécurité de données, les notions de RTO et RPO sont très importantes pour vérifier l’efficacité
de la politique utilisée.

- RTO (Recovery Time Objective) : représente le temps toléré pour le rétablissement d’un ser-
vice lors d’une panne.

- RPO (Recovery Point Objective) : représente la quantité de données tolérée lors d’une panne.

Tous les mécanismes de sécurité de données ont comme objectif la réduction du RTO et RPO, on
cite le snapshot qui permet la sauvegarde de façon plus fréquentes sur des disques ce qui répond au
besoin du RPO [21].

2.2 Politique de sécurité adoptée

La mise en œuvre d’une politique de sécurité passe par ces deux phases principales [22]:

41
 2.2.1 Identification des objectifs
Le cloud privé, comme tout système d’information, est constitué par des ressources matérielles et
logicielles. L’objectif d’une politique de sécurité est de garantir que ces ressources sont utilisées dans
leur cadre prévu. Ceci est assuré par le respect de ces critères:

 L’intégrité : s’assurer que les données sont bien celles que nous croyons l’être.
 La disponibilité : s’assurer que seules les personnes autorisées aient accès aux ressources
 La confidentialité : s’assurer du bon fonctionnement du système

2.2.2 Identification des risques

L’identification des risques est une phase indispensable pour tout projet informatique comme elle
permet de mieux appréhender son contexte d’utilisation.

Nous avons défini deux catégories de risques : ceux qui sont liés au cloud et ceux qui sont suscep-
tibles d’être présents dans tout projet informatique parmi lesquels nous citons :

 Risques non spécifiques au cloud :

- IP spoofing ou usurpation d’identité d’utilisateurs : remplacer son adresse IP pour passer
comme quelqu’un de confiance.
- DoS : rendre un service indisponible par surcharge de réseau
- Cheval de Troie : injection de code pour obtenir l’accès à une machine cible
 Risques non spécifiques au cloud :
- Usurpation de service : des services similaires offerts en d’autres points du cloud
- Malveillance dans l’utilisation : dommages causés par les administrateurs système
comme l’accès non-autorisés

3. Préparation de la mise en place de la solution adoptée

3.1 Architecture de la solution adoptée

42
Figure 4.4- Architecture de la solution adoptée

3.1.1 Les composants de l’architecture

Notre architecture représenté dans la figure est composée de :

 Un pare-feu (Firewall) [23]:

Un pare-feu est un programme, ou matériel, qui permet la protection d’un réseau interne d’un autre
réseau externe en contrôlant le trafic qui passe entre les deux réseaux.

En fait, un pare-feu filtre les flux de données qui le traversent suivant des règles fournit par
l’administrateur.

On va utiliser le firewall entreprise ASA déjà mise en place pour gérer les règles de sécurité

 Un serveur d’authentification [24]:

Un serveur d'authentification est un moyen de sécurité informatique afin de filtrer l'accès à une res-
source (réseau, information) et de garder une trace de qui a fait quoi et quand.

Ce serveur sert à la sécurisation contre les attaques provenant de l’intérieur.

On va utiliser le serveur d’authentification de l’entreprise déjà mise en place pour les aspects
d’authentification

 Un pot de miel (Honeypot) [25]:

Un pot de miel est une méthode de défense active permettant d’émuler des services sur une ma-
chine faiblement sécurisée afin d’attirer les attaquants pour les neutraliser.

43
Un pot de miel est, donc, un système de sécurité qui permet de décevoir l’attaquant qui croit avoir
accès à une machine véritable ce qui nous permet d’observer son comportement suivant ces étapes :

- la surveillance: surveiller le comportement du l’intrus.

- le collecte d’informations: collecter des informations sur le comportement de l’intrus.

- l’analyse d’information: action réalisé par l’administrateur.

On distingue deux types de pot de miel :

Pot de miel à faible interaction : la machine utilisée est une machine n’ayant pas des services véri-
tables pour minimiser le risque.

Pot de miel à forte interaction : la machine utilisée est une machine véritable plus ou moins sécurisé
ce qui augmente le risque.

 Système de détection d’intrusion (IDS) [26]:

Un IDS est un mécanisme de défense actif permettant de détecter en temps réel toutes activités
anormales sur un réseau.

On distingue trois familles d’IDS :

- NIDS : analyse du trafic réseau afin de détecter les signatures d’attaque face à un modèle de
référence.

- HIDS : analyse le fonctionnement des hôtes (journaux systèmes…) sur lesquelles ils sont ins-
tallés.

- IDS Hybride : c’est une combinaison de NIDS et HIDS permettant de surveiller à la fois le ré-
seau et les terminaux.

Ces composants de sécurité (IDS et pot de miel) ne sont pas adaptés pour détecter les attaques dis-
tribuées, en effet ces attaques sont subdivisées en sous attaques afin d'être indétectable par de tel
système de sécurité.

Elaborons plus cette idée, le problème principal lié à la collecte de données, est le grand volume de
données à analyser par l’expert humain. Parmi ces données, nous distinguons des attaques récur-
rentes et des activités normales effectuées par des utilisateurs qui testent le les IDS ou le pot de miel.
La présence de ces données volumineuses et redondantes complique la tâche d’analyse et peut ca-
cher des nouvelles attaques. Afin de résoudre ce problème, nous optons vers l’utilisation des tech-
niques d’apprentissage automatique et de data mining. Nos objectifs se résument en la détection des
nouvelles attaques, la détection des attaques de déni de service et la caractérisation de toutes les
attaques capturées.

44
 3.1.2 Mise en place de moyens de contrôle
Cette phase est très importante est doit être effectuer d’une manière cyclique. Elle est assurée par
des outils spécifiques, nous citons :

 Les audits internes : effectuer par un auditeur interne pour comparer l’état du système à un
référentiel.

 Contrôle interne : vérifier que chacun respectent les procédures.

Les résultats obtenus doivent être analysés pour mettre en place des actions d’amélioration qui peu-
vent être correctives ou préventives.

4. Mise en place de la solution

Dans ce module on va commencer par présenter l’environnement matériel et logiciel. Ensuite, les
étapes du déploiement et nous terminerons par les tests et validation de la solution.

4.1 Environnement de travail

4.1.1 Environnement matériel

Pour le déploiement de la solution, le matériel disponible chez l’entreprise est :

 Deux ordinateurs de bureau Dell :

 Disque dur 500 Go
 Processeur Intel corei5
 Ram 4GB
 Un serveur rack Dell R310
 Disque dur 500 GB
 Processeur 6 cœurs
 Ram 24GB
 Un serveur rack HP DL380 G5
 Disque dur 500 GB
 Processeur 4 cœurs
 Ram 16GB

4.1.2 Environnement logiciel

Faute au manque du matériel, nous sommes obligé d’installer les trois nœuds du CloudStack (Serveur
de management, NFS et la partie réseau) sur le même serveur, dans ce contexte nous avons installé,
sur le serveur DL380 G5, le serveur de management qui représente le serveur de gestion, NFS qui
représente la partie stockage ainsi que la partie réseau du CloudStack

Sur le deuxième serveur R310, nous avons installé un hyperviseur KVM et sur les deux ordinateurs de
bureau Dell nous avons installé XenServer 6.0.2 et HyperV [30].
45
Nous allons utiliser Centos 7 comme système d’exploitation pour CloudStack et KVM et Windows
Server 2008 R2 pour HyperV [31].

4.2 Mise en place de la solution CloudStack

La mise en place de cette solution consiste au déploiement d’un environnement comportant 3 com-
posants: Serveur de management, réseau et stockage NFS. Ensuite, l’implémentation des autres
nœuds de calcul : chaque nœud est basé sur différent hyperviseur (hyper-V, KVM et Xenserver dans
notre cas) [14].

La procédure de déploiement sera expliquée en détails dans le document: « Guide d’utilisation et de

mise en service ».

4.2.1 Serveur de management

Pour la mise en place du serveur de management, nous commençons par la préparation de
l’environnement en configurant les interfaces réseau et l’installation du serveur de temps ntp.
Ensuite, nous passons à l’installation des services de base mentionnés dans la section conception de
la solution du chapitre 2 [14].

Figure 4.5- Services installés sur Serveur de management

4.2.2 Réseau
Pour la mise en place de la partie réseau, il faut aussi préparer l’environnement en configurant les
interfaces réseau et l’installation du serveur de temps ntp qui doit être synchronisé avec le serveur
temps du nœud de contrôle. Ensuite, nous installons les composants NFS [14].

46
 Figure 4.6- Services installés partie Réseaux

4.2.3 Stockage NFS

La préparation de l’environnement est faite de la même façon. Ensuite, nous installons MySQL et
configurant certaines options pour assurer son bon fonctionnement avec CloudStack.

Figure 4.7- Services installés sur Stockage NFS

47
Remarque : Pour faciliter l’installation ainsi que la configuration des différents nœuds mentionnés
ci-dessus, nous avons mis à jour un script Shell déjà existant qui englobe toutes les étapes de confi-
guration.

Le script sera détaillé dans l’Annexe 1

Figure 4.8- Script d’installation CloudStack

4.2.4 Nœuds de calcul:

Nous installons seulement trois nœuds de calcul selon les ressources disponibles dans l’entreprise.

- Hyper-V est un serveur sur lequel nous avons installé hyper-v server 2008 R2.
- XenServer est un serveur sur lequel nous avons installé Xenserver 6.0.2.
- KVM est un serveur sur lequel nous avons installé Centos 7.

48
 5. Test et validation de la solution

Le but de cette section est de vérifier que les services sont bien installés et en état de fonctionne-
ment. Ceci est possible grâce à un ensemble de commandes détaillées dans l’Annexe 1

Nous devons aussi vérifier si notre solution est bien conforme à notre conception établie dans la
partie Etude conceptuelle. Ceci est dans le but de valider la solution.

Ci-dessous, une capture d’écran à titre d’exemple montrant une instance qui tourne correctement
après avoir fait tout le processus de configuration

Figure 4.9- Instance CloudStack

6. Conclusion

Dans ce chapitre, nous avons présenté dans un premier lieu, un aperçu sur le dimensionnement des
serveurs et du stockage. Dans un deuxième lieu, nous avons décrit la politique de sécurité entrepris
et on a terminé par décrire le processus de déploiement de l’environnement de test.

Ceci sera complété et détaillé dans l’Annexe 1

49
Conclusion et perspectives

L’objectif de notre projet de fin d’études était la mise en place d’un cloud privé basé sur des diffé-
rents hyperviseurs incluant l’étude d’ingénierie de dimensionnement et de sécurité.

La première étape était la recherche d’une solution qui permet la gestion de plusieurs hyperviseurs.
En effet, le travail de recherche et de collecte d’informations effectué dans ce projet a pris beaucoup
de temps pour trouver finalement la solution adéquate. Celle-ci est basée sur CloudStack qui res-
pecte la contrainte financière puisqu’il est open source. Nous avons par la suite fait une conception
en se basant sur les besoins fonctionnels et non fonctionnels spécifiés.

La deuxième étape était consacrée à l’ingénierie de dimensionnement et de la sécurité en se basant

sur les besoins, les contraintes financières et la conception de la solution.

La dernière partie du projet était la partie réalisation afin d’offrir au département IT un environne-
ment de test et un ensemble de documents facilitant le redéploiement.

Le choix du CloudStack n’était pas approuvé seulement parce qu’il répond à nos besoins mais aussi
pour le potentiel d’évolution énorme qu’il possède, non seulement par les commutés qui propose
chaque année au moins deux nouvelles versions, mais aussi la possibilité de rajouter des modules
personnalisés.

La solution présentée peut être encore étendue pour bénéficier des services de sécurité offerts par
CloudStack (VLAN, security group..) ainsi que les services de la haute disponibilité que nous n’avons
pas testée dans notre environnement.

On pourra aussi ajouter d’autres nœuds de calcul tel que VMware lorsqu’on aura plus de ressource
(matériel) disponibles dans la société ainsi que l’exploitation de la partie gestion de projets sur la
plateforme CloudStack.

50
BIBILIOGRAPHIE ET SITOGRAPHIE
[1] http://blog.compufirst.com/serveur/quest-ce-qu-un-hyperviseur

[2] http://www.elit-technologies.fr/editorial/qu-est-ce-que-virtualisation-serveurs/

[3] http://www.systancia.com/fr/virtualisation-et-cloud-computing

[4] http://www.systancia.com/fr/modeles-du-cloud-computing

[5] http://www.interoute.fr/what-iaas

[6] http://france.emc.com/collateral/emc-perspective/h6870-consulting-cloud-ep.pdf

[7] http://www.commentcamarche.net/faq/28158-le-cloud-prive-dans-l-entreprise#le-cloud-prive-
un-pied-dans-l-entreprise

[8] http://www.hotlink.com/resources/SuperVISOR_2.pdf

[9] https://www.virtualizationpractice.com/hotlink-supervisor-vcenter-for-hyper-v-kvm-and-
xenserver-15369/

[10] http://www.nec.com/en/global/prod/sigmasystemcenter/

[11] http://docs.openstack.org/juno/

[12] http://www.hellovinoth.com/multi-hypervisor-openstack-integrating-vmware-vcenter-and-kvm-
hypervisors-with-openstack/

[13] https://releases.openstack.org/

[14] http://cloudstack-installation.readthedocs.io/en/4.3/installation.html

[15] http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.9/

[16] http://docs.cloudstack.apache.org/projects/cloudstack-
installation/en/4.9/choosing_deployment_architecture.html

[17] http://www.hyperconverged.org/fr/blog/2014/09/18/dimensionnement-de-linfrastructure-
comparaison-des-infrastructures-hyperconvergee-et-traditionnelle/

[18] http://syskb.com/san-ou-nas-quelle-est-la-difference/

[19] http://cesar.resinfo.org/IMG/pdf/SIARS-Stockage-MR.pdf

[20] http://www.intel.com/content/www/us/en/support/boards-and-kits/000005782.html

[21] http://www.config.fr/press/Livre_Blanc_Cloud_Computing_Securit%C3%A9.Vdef.pdf

[22]https://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_des_syst%C3%A8mes_d%27information#P
hase_check_:_Mise_en_place_de_moyens_de_contr.C3.B4le

51
[23] http://searchsecurity.techtarget.com/opinion/Commercial-firewalls-vs-Open-source-firewalls

[24] https://fr.wikipedia.org/wiki/Authentification

[25] http://folk.uio.no/ingardm/sysarp/honeypot
a_supplemented_active_defense_for_network_security.pdf

[26] http://www-igm.univ-mlv.fr/~duris/NTREZO/20032004/Baudoin-Karle-IDS-IPS.pdf

[27] http://i.dell.com/sites/doccontent/shared-content/data-
sheets/en/Documents/PowerEdge_R930_spec_sheet-FINAL.pdf

[28] http://i.dell.com/sites/doccontent/shared-content/data-sheets/fr/Documents/Dell-PowerEdge-
R730-Spec-Sheet-FR-HR.pdf

[29] https://www.hpe.com/h20195/v2/GetPDF.aspx/c04227623.pdf

[30] http://www.informatiweb-pro.net/virtualisation/1-citrix/10--citrix-xenserver-installation-
configuration-mises-a-jour-et-utilisation.html

[31] http://www.toutwindows.com/ws2008r2_hyper-v.shtml

[32] Wikipedia, "Baie (centre de données)", consulté en Mai 2016,

http://fr.wikipedia.org/wiki/Baie_(centre_de_donn%C3%A9es)
[33] Segate, "Raid modes", consulté en Mai 2016,
http://www.seagate.com/fr/fr/manuals/network-storage/business-storage-nas-os/raid-
modes/
[34] Apache CloudStack Cloud Computing by Navin Sabharwal

52
ANNEXE 1: Détails Technique

I- Guide d’utilisation et mise en service

Environment
Avant de commencer, vous devez préparer l'environnement avant d'installer CloudStack. Nous allons
passer les étapes pour préparer maintenant.

Operating System
Utilisant la CentOS 6.9 x86_64 installation minimale ISO, vous devrez installer CentOS 6 sur votre
matériel. Les paramètres par défaut seront généralement acceptables pour cette installation.

Une fois cette installation terminée, vous voudrez vous connecter à votre machine récemment instal-
lée via SSH en tant qu'utilisateur root. Notez que vous ne devez pas autoriser les connexions root
dans un environnement de production, alors assurez-vous d'éteindre les connexions à distance une
fois que vous avez terminé l'installation et la configuration.

Configuring the network

Par défaut, le réseau ne s'affichera pas sur votre matériel et vous devrez le configurer pour fonction-
ner dans votre environnement. Comme nous avons indiqué qu'il n'y aurait pas de serveur DHCP dans
cet environnement, nous configurons manuellement votre interface réseau. Nous supposerons que
eth0 est la seule interface réseau qui sera connectée et utilisée.

En vous connectant via la console, vous devez vous connecter en tant que root. Vérifiez le fichier
/etc/sysconfig/network-scripts/ifcfg-eth0, il ressemblera à ceci par défaut:

DEVICE="eth0"
HWADDR="52:54:00:B9:A6:C0"
NM_CONTROLLED="yes"
ONBOOT="no"

Malheureusement, cette configuration ne vous permettra pas de se connecter au réseau et n'est pas
adapté à nos besoins avec CloudStack. Nous voulons configurer ce fichier afin qu'il spécifie l'adresse
IP, le masque de réseau, etc., comme indiqué dans l'exemple suivant:

DEVICE=eth0
HWADDR=52:54:00:B9:A6:C0
NM_CONTROLLED=no
ONBOOT=yes
BOOTPROTO=none
53
IPADDR=192.168.101.107
NETMASK=255.255.255.0
GATEWAY=192.168.101.1
DNS1=192.168.1.50
DNS2=192.168.7.4

Maintenant nous avons configuré correctement les fichiers de configuration, nous devons exécuter
quelques commandes pour démarrer le réseau:

# chkconfig network on
# service network start

Hostname

CloudStack exige que le nom d'hôte soit correctement défini. Si vous avez utilisé les options par dé-
faut dans l'installation, votre nom d'hôte est actuellement défini sur localhost.localdomain. Pour
tester cela, nous exécuterons:

# hostname --fqdn

À ce stade, il retournera probablement:

localhost

Pour remédier à cette situation - nous allons définir le nom d'hôte en éditant le fichier /etc/hosts
pour qu'il suit un format similaire à cet exemple:

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4

::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.101.107 CloudDBX

Après avoir modifié ce fichier, allez-y et redémarrez le réseau en utilisant:

# systemctl rstart network

Maintenant, vérifiez à nouveau avec la commande hostname --fqdn et assurez-vous qu'il renvoie une
réponse FQDN

SELinux

54
Pour le moment, CloudStack fonctionne correctement. SELinux doit être défini comme permissive.
Nous voulons les configurer pour les futures bottes et les modifier dans le système d'exécution ac-
tuel.
Pour configurer SELinux comme étant permissif dans le système en cours d'exécution, nous devons
exécuter la commande suivante:

# setenforce 0

Pour s'assurer qu'il reste dans cet état, nous devons configurer le fichier /etc/selinux/config pour
refléter l'état permissive, comme indiqué dans cet exemple:

# This file controls the state of SELinux on the system.

# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=targeted

NTP
La configuration NTP est une nécessité pour synchroniser toutes les horloges de vos serveurs en
nuage. Cependant, NTP n'est pas installé par défaut. Nous allons donc installer et configurer NTP à ce
stade. L'installation s'effectue comme suit:

# yum -y install ntp

Après l’installation, nous devons l’activer

# chkconfig ntpd on
# systemctl start ntpd

Configuring the CloudStack Package Repository

Nous devons configurer la machine pour utiliser un répertoire de paquet CloudStack.
Créer /etc/yum.repos.d/cloudstack.repo et insérer les informations suivantes.

[cloudstack]
name=cloudstack

55
baseurl=http://cloudstack.apt-get.eu/centos/6/4.6/
enabled=1
gpgcheck=0

NFS
Notre configuration va utiliser NFS pour le stockage primaire et secondaire. Nous allons aller de
l'avant et configurer deux actions NFS à ces fins. Nous commencerons en installant nfs-utils.

# yum -y install nfs-utils

Nous devons maintenant configurer NFS pour diffuser deux actions différentes. Cela se fait de ma-
nière relativement simple dans le fichier /etc /exports. Vous devez vous assurer qu'il a le contenu
suivant:

/secondary *(rw,async,no_root_squash,no_subtree_check)
/primary *(rw,async,no_root_squash,no_subtree_check)

Vous remarquerez que nous avons spécifié deux répertoires qui n'existent pas (encore) sur le sys-
tème. Nous allons continuer et créer ces répertoires et définir les autorisations de manière appro-
priée sur eux avec les commandes suivantes:

# mkdir /primary
# mkdir /secondary

Les versions de CentOS 6.x utilisent NFSv4 par défaut. NFSv4 exige que les paramètres de domaine
correspondent à tous les clients. Dans notre cas, le domaine est cloud.priv, alors assurez-vous que le
paramètre de domaine dans /etc/idmapd.conf est décommenté et défini comme suit: Domain =
cloud.priv

Maintenant, vous devrez dé-commenter les valeurs de configuration dans le fichier

/etc/sysconfig/nfs

LOCKD_TCPPORT=32803
LOCKD_UDPPORT=32769
MOUNTD_PORT=892
RQUOTAD_PORT=875
STATD_PORT=662
STATD_OUTGOING_PORT=2020

Maintenant, nous devons configurer le pare-feu pour permettre les connexions NFS entrantes. Modi-
fier le fichier /etc/sysconfig/iptables

-A INPUT -s 192.168.101.0/24 -m state --state NEW -p udp --dport 111 -j ACCEPT

56
-A INPUT -s 192.168.101.0/24 -m state --state NEW -p tcp --dport 111 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -m state --state NEW -p tcp --dport 2049 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -m state --state NEW -p tcp --dport 32803 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -m state --state NEW -p udp --dport 32769 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -m state --state NEW -p tcp --dport 892 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -m state --state NEW -p udp --dport 892 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -m state --state NEW -p tcp --dport 875 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -m state --state NEW -p udp --dport 875 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -m state --state NEW -p tcp --dport 662 -j ACCEPT
-A INPUT -s 192.168.101.0/24 -m state --state NEW -p udp --dport 662 -j ACCEPT

Maintenant, vous pouvez redémarrer le service iptables avec la commande suivante:

# service iptables restart

Nous devons maintenant configurer le service nfs pour commencer le démarrage et le démarrer sur
l'hôte en exécutant les commandes suivantes:

# systemctl start rpcbind

# systemctl start nfs
# chkconfig rpcbind on
# chkconfig nfs on

Management Server Installation

Nous allons installer le serveur de gestion CloudStack et les outils environnants.

Database Installation and Configuration

Nous allons commencer par installer MySQL et configurer certaines options afin de garantir son bon
fonctionnement avec CloudStack.
Installez en exécutant la commande suivante:

# yum -y install mysql-server

Après l’installation de, nous devons apporter quelques modifications de configuration à

/etc/my.cnf. Plus précisément, nous devons ajouter les options suivantes à la section [mysqld]:

innodb_rollback_on_timeout=1
innodb_lock_wait_timeout=600
max_connections=350
log-bin=mysql-bin
57
binlog-format = 'ROW'

MySQL est correctement configuré, nous pouvons le démarrer et le configurer pour commencer le
démarrage comme suit:

# systemctl start mysqld

# chkconfig mysqld on

Installation
Nous allons maintenant installer le serveur de gestion. Nous le faisons en exécutant la commande
suivante:

# yum -y install cloudstack-management

Avec l'application elle-même installée, nous pouvons maintenant configurer la base de données,
nous allons le faire avec la commande et les options suivantes:

# cloudstack-setup-databases cloud:password@localhost --deploy-as=root

Lorsque ce processus est terminé, vous devriez voir un message comme "CloudStack a réussi à initia-
liser la base de données".
Maintenant, la base de données a été créée, nous pouvons prendre la dernière étape dans la confi-
guration du serveur de gestion en émettant la commande suivante:

# cloudstack-setup-management

System Template Setup

CloudStack utilise un certain nombre de machines virtuelles pour fournir des fonctionnalités pour
accéder à la console de machines virtuelles, fournir divers services de réseau et gérer différents as-
pects du stockage. Cette étape acquerra ces images système prêtes à être déployées lorsque nous
amorcerons votre nuage.
Maintenant, nous devons télécharger le modèle VM du système et le déployer sur le partage que
nous venons de créer. Le serveur de gestion comprend un script pour manipuler correctement les
images de VM du système.

/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt \
-m /secondary \
-u http://cloudstack.apt-get.eu/systemvm/4.6/systemvm64template-4.6.0-kvm.qcow2.bz2 \
-h kvm -F

Cela conclut notre configuration du serveur de gestion. Nous avons encore besoin de configurer
CloudStack, mais nous le ferons après avoir configuré notre hyperviseur.

KVM Setup and Installation

58
KVM est l'hyperviseur que nous allons utiliser, nous allons récupérer la configuration initiale qui a
déjà été effectuée sur l'hôte de l'hyperviseur et couvrir l'installation du logiciel de l'agent, vous pou-
vez utiliser les mêmes étapes pour ajouter des nœuds KVM supplémentaires à votre environnement
CloudStack.

Installation
L'installation de l'agent KVM est trivial avec une simple commande, mais ensuite, nous devrons con-
figurer quelques éléments.

# yum -y install cloudstack-agent

KVM Configuration
Nous avons deux parties différentes de KVM pour configurer, libvirt et QEMU.

QEMU Configuration
La configuration de KVM est relativement simple à un seul élément. Nous devons modifier la configu-
ration QEMU VNC. Cela se fait en éditant /etc/libvirt/qemu.conf et en garantissant que la ligne sui-
vante est présente et n'est pas commentée.
Vnc_listen = 0.0.0.0

Libvirt Configuration
CloudStack utilise libvirt pour la gestion de machines virtuelles. Par conséquent, il est vital que libvirt
soit correctement configuré. Libvirt est une dépendance de cloud-agent et devrait déjà être installé.
1. Pour avoir une migration en direct, libvirt doit écouter les connexions TCP non sécurisées. Nous
devons également désactiver la tentative de libvirts d'utiliser la publicité DNS Multicast. Ces deux
paramètres sont dans /etc/libvirt/libvirtd.conf
Définissez les paramètres suivants:

listen_tls = 0
listen_tcp = 1
tcp_port = "16059"
auth_tcp = "none"
mdns_adv = 0

2. L’activation de "listen_tcp" dans libvirtd.conf ne suffit pas, nous devons également modifier les
paramètres, nous devons également modifier /etc/sysconfig/libvirtd:
Dé-commentant la ligne suivante:

#LIBVIRTD_ARGS="--listen"

Redemarrer libvirt

59
 # systemctl restart libvirtd

KVM configuration complete

Par souci d'exhaustivité, vérifiez si KVM fonctionne correctement sur votre machine:

# lsmod | grep kvm

kvm_intel 55496 0
kvm 337772 1 kvm_intel

Cela conclut notre installation et configuration de KVM, et nous allons maintenant utiliser l'interface
utilisateur CloudStack pour la configuration actuelle de notre nuage.

Configuration

Comme nous l'avons noté précédemment, nous utiliserons des groupes de sécurité pour fournir un
isolement et, par défaut, cela implique que nous allons utiliser un réseau plat de couche 2. Cela signi-
fie également que la simplicité de notre configuration signifie que nous pouvons utiliser l'installateur
rapide.

UI Access

Pour accéder à l'interface Web de CloudStack, il suffit de pointer votre navigateur vers
http://192.168.101.107:8080/client. Le nom d'utilisateur par défaut est «admin» et le mot de passe
par défaut est «mot de passe». Vous devriez voir un écran de démarrage qui vous permet de choisir
plusieurs options pour configurer CloudStack. Vous devez choisir l'option Continuer avec configura-
tion de base.

Vous devriez maintenant voir une invite vous demandant de modifier le mot de passe de l'utilisateur
administrateur. S'il-vous-plaît faites ainsi.

Setting up a Zone

Une zone est la plus grande entité d'organisation de CloudStack - et nous allons en créer une, ce de-
vrait être l'écran que vous voyez en face de vous maintenant. Et pour nous, il y a 5 informations dont
nous avons besoin.

1. Nom - nous allons définir ceci à la «Zone1» toujours descriptive pour notre nuage.

2. DNS public 1 - nous allons définir ceci à '192.168.1.50' pour notre nuage.

3. DNS public 2 - nous allons définir ceci à '192.168.7.4' pour notre nuage.

4. DNS1 interne - nous allons également définir cela sur '192.168.1.50' pour notre nuage.

5. DNS2 interne - nous allons également définir cela sur '192.168.7.4' pour notre nuage.

60
Pod Configuration

Maintenant que nous avons ajouté une zone, la prochaine étape qui se pose est une invite pour
l'information regain une puce. Qui recherche plusieurs articles.

1. Nom - Nous utiliserons Pod1 pour notre nuage.

2. Passerelle - Nous utiliserons 192.168.101.1 comme notre passerelle

3. Masque de Net - Nous utiliserons 255.255.255.0

4. Démarrez / fermez les IP du système réservé- nous allons utiliser 192.168.101.141-

192.168.101.145

5. Passerelle invité- Nous allons utiliser 192.168.101.1

6. Guest netmask - Nous allons utiliser 255.255.255.0

7. Guest start / end IP - Nous allons utiliser 192.168.101.146-192.168.101.152

Cluster

Après l’ajout de la zone, il suffit d'ajouter quelques autres éléments pour configurer le cluster.

1. Nom - Cluster1

2. Hypervisor - KVM

Vous devriez être invité à ajouter le premier hôte à votre cluster à ce stade. Seuls quelques éléments
d'information sont nécessaires.

1. Nom d'hôte: nous utiliserons l'adresse IP 192.168.101.106 car nous n'avons pas configuré de ser-
veur DNS.

2. Nom d'utilisateur - 'root'

3. Mot de passe: entrez le mot de passe du système d'exploitation pour l'utilisateur root

Primary Storage

Avec votre cluster maintenant configuré- vous devriez être invité à fournir des informations de
stockage principales. Choisissez NFS comme type de stockage, puis saisissez les valeurs suivantes
dans les champs:

1. Nom - 'Primary1'

2. Serveur - Nous allons utiliser l'adresse IP 192.168.101.107

3. Chemin - Bien défini /Primary comme chemin d'accès que nous utilisons
61
Secondary Storage
S'il s'agit d'une nouvelle zone, vous serez invité à fournir des informations de stockage secondaires -
remplissez-le comme suit:

1. Serveur NFS - Nous allons utiliser l'adresse IP 192.168.101.107

2. Chemin d'accès - Nous allons utiliser /Secondary

Maintenant, cliquez sur Lancer et votre nuage devrait commencer l'installation. Cela peut
prendre plusieurs minutes en fonction de la vitesse de connexion Internet pour que l'instal-
lation soit finalisée.

C'est ça, vous avez fini avec l'installation de votre nuage Apache CloudStack.

Script :
Comme on a mention dans le rapport, on peut utiliser un script qui englobe toutes ces
étapes, et il suffit de remplir les informations demandées par ce script.

#!/bin/sh

SSH_PUBLIC_KEY='insert_your_ssh_public_key_here'

function add_ssh_public_key() {

cd

mkdir -p .ssh

chmod 700 .ssh

echo "$SSH_PUBLIC_KEY" >> .ssh/authorized_keys

chmod 600 .ssh/authorized_keys

function get_network_info() {

echo '* settings for cloud agent'

read -p ' hostname (ex:cloudstack) : ' HOSTNAME

read -p ' ip address (ex:192.168.1.2) : ' IPADDR

read -p ' netmask (ex:255.255.255.0): ' NETMASK

read -p ' gateway (ex:192.168.1.1) : ' GATEWAY

read -p ' dns1 (ex:192.168.1.1) : ' DNS1

62
 read -p ' dns2 (ex:8.8.4.4) : ' DNS2

function get_nfs_info() {

echo '* settings for nfs server'

read -p ' NFS Server IP: ' NFS_SERVER_IP

read -p ' Primary mount point (ex:/export/primary) : ' NFS_SERVER_PRIMARY

read -p ' Secondary mount point (ex:/export/secondary): ' NFS_SERVER_SECONDARY

function get_nfs_network() {

echo '* settings for nfs server'

read -p ' accept access from (ex:192.168.1.0/24): ' NETWORK

function install_common() {

yum update -y

sed -i -e 's/SELINUX=enforcing/SELINUX=permissive/g' /etc/selinux/config

setenforce permissive

echo "[cloudstack-4.7]

name=cloudstack

baseurl=http://packages.shapeblue.com/cloudstack/upstream/centos/4.7

enabled=1

gpgcheck=0" > /etc/yum.repos.d/CloudStack.repo

sed -i -e "s/localhost/$HOSTNAME localhost/" /etc/hosts

yum install ntp wget -y

service ntpd start

chkconfig ntpd on

wget http://download.cloud.com.s3.amazonaws.com/tools/vhd-util

mkdir -p /usr/share/cloudstack-common/common/scripts/vm/hypervisor/xenserver

mv vhd-util /usr/share/cloudstack-common/common/scripts/vm/hypervisor/xenserver

63
function install_management() {

yum install cloudstack-management mysql-server expect -y

head -7 /etc/my.cnf > /tmp/before

tail -n +7 /etc/my.cnf > /tmp/after

cat /tmp/before > /etc/my.cnf

echo "innodb_rollback_on_timeout=1

innodb_lock_wait_timeout=600

max_connections=350

log-bin=mysql-bin

binlog-format = 'ROW'" >> /etc/my.cnf

cat /tmp/after >> /etc/my.cnf

rm -rf /tmp/before /tmp/after

service mysqld start

chkconfig mysqld on

expect -c "

set timeout 10

spawn mysql_secure_installation

expect \"Enter current password for root (enter for none): \"

send \"\n\"

expect \"Set root password?\"

send \"Y\n\"

expect \"New password: \"

send \"password\n\"

expect \"Re-enter new password: \"

send \"password\n\"

expect \"Remove anonymous users?\"

send \"Y\n\"

expect \"Disallow root login remotely?\"

64
send \"Y\n\"

expect \"Remove test database and access to it?\"

send \"Y\n\"

expect \"Reload privilege tables now?\"

send \"Y\n\"

interact

"

cloudstack-setup-databases cloud:password@localhost --deploy-as=root:password

echo "Defaults:cloud !requiretty" >> /etc/sudoers

cloudstack-setup-management

chkconfig cloudstack-management on

chown cloud:cloud /var/log/cloudstack/management/catalina.out

function initialize_storage() {

service rpcbind start

chkconfig rpcbind on

service nfs start

chkconfig nfs on

mkdir -p /mnt/primary

mkdir -p /mnt/secondary

mount -t nfs ${NFS_SERVER_IP}:${NFS_SERVER_PRIMARY} /mnt/primary

sleep 10

mount -t nfs ${NFS_SERVER_IP}:${NFS_SERVER_SECONDARY} /mnt/secondary

sleep 10

rm -rf /mnt/primary/*

rm -rf /mnt/secondary/*

/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /export/secondary -u
http://packages.shapeblue.com.s3-eu-west-
1.amazonaws.com/systemvmtemplate/4.6/new/systemvm64template-4.6-xen.vhd.bz2 -h xenserver -s password -
F

65
 /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /export/secondary -u
http://packages.shapeblue.com.s3-eu-west-
1.amazonaws.com/systemvmtemplate/4.6/new/systemvm64template-4.6-hyperv.vhd.zip -h hyperv -s password -
F

/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /export/secondary
-u http://packages.shapeblue.com.s3-eu-west-
1.amazonaws.com/systemvmtemplate/4.6/new/systemvm64template-4.6-vmware.ova -h vmware -s password -F

/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /export/secondary
-u http://packages.shapeblue.com.s3-eu-west-
1.amazonaws.com/systemvmtemplate/4.6/new/systemvm64template-4.6-kvm.qcow2.bz2 -h kvm -s password -F

sync

umount /mnt/primary

umount /mnt/secondary

rmdir /mnt/primary

rmdir /mnt/secondary

function install_agent() {

yum install qemu-kvm cloudstack-agent bridge-utils vconfig -y

modprobe kvm-intel

echo "group virt {

cpu {

cpu.shares=9216;

}" >> /etc/cgconfig.conf

service cgconfig restart

echo "listen_tls = 0

listen_tcp = 1

tcp_port = \"16509\"

auth_tcp = \"none\"

mdns_adv = 0" >> /etc/libvirt/libvirtd.conf

sed -i -e 's/#LIBVIRTD_ARGS="--listen"/LIBVIRTD_ARGS="--listen"/g' /etc/sysconfig/libvirtd

service libvirtd restart

66
 HWADDR=`grep HWADDR /etc/sysconfig/network-scripts/ifcfg-eth0 | awk -F '"' '{print $2}'`

echo "DEVICE=eth0

HWADDR=$HWADDR

NM_CONTROLLED=no

ONBOOT=yes

IPADDR=$IPADDR

NETMASK=$NETMASK

GATEWAY=$GATEWAY

DNS1=$DNS1

DNS2=$DNS2

BRIDGE=cloudbr0" > /etc/sysconfig/network-scripts/ifcfg-eth0

echo "DEVICE=cloudbr0

HWADDR=$HWADDR

NM_CONTROLLED=no

ONBOOT=yes

IPADDR=$IPADDR

NETMASK=$NETMASK

GATEWAY=$GATEWAY

DNS1=$DNS1

DNS2=$DNS2

TYPE=Bridge" > /etc/sysconfig/network-scripts/ifcfg-cloudbr0

function install_nfs() {

yum install nfs-utils -y

service rpcbind start

chkconfig rpcbind on

service nfs start

chkconfig nfs on

67
 mkdir -p $NFS_SERVER_PRIMARY

mkdir -p $NFS_SERVER_SECONDARY

echo "$NFS_SERVER_PRIMARY *(rw,async,no_root_squash)" > /etc/exports

echo "$NFS_SERVER_SECONDARY *(rw,async,no_root_squash)" >> /etc/exports

exportfs -a

echo "LOCKD_TCPPORT=32803

LOCKD_UDPPORT=32769

MOUNTD_PORT=892

RQUOTAD_PORT=875

STATD_PORT=662

STATD_OUTGOING_PORT=2020" >> /etc/sysconfig/nfs

INPUT_SECTION_LINE=`cat -n /etc/sysconfig/iptables | egrep -- '-A INPUT' | head -1 | awk '{print $1}'`

head -`expr $INPUT_SECTION_LINE - 1` /etc/sysconfig/iptables > /tmp/before

tail -$INPUT_SECTION_LINE /etc/sysconfig/iptables > /tmp/after

cat /tmp/before > /etc/sysconfig/iptables

echo "-A INPUT -s $NETWORK -m state --state NEW -p udp --dport 111 -j ACCEPT

-A INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 111 -j ACCEPT

-A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 111 -j ACCEPT

-A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 2049 -j ACCEPT

-A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 32803 -j ACCEPT

-A INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 32769 -j ACCEPT

-A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 892 -j ACCEPT

-A INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 892 -j ACCEPT

-A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 875 -j ACCEPT

-A INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 875 -j ACCEPT

68
-A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 662 -j ACCEPT

-A INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 662 -j ACCEPT" >> /etc/sysconfig/iptables

cat /tmp/after >> /etc/sysconfig/iptables

rm -rf /tmp/before /tmp/after

service iptables restart

service iptables save

if [ $# -eq 0 ]

then

OPT_ERROR=1

fi

while getopts "acnmhr" flag; do

case $flag in

\?) OPT_ERROR=1; break;;

h) OPT_ERROR=1; break;;

a) opt_agent=true;;

c) opt_common=true;;

n) opt_nfs=true;;

m) opt_management=true;;

r) opt_reboot=true;;

esac

done

shift $(( $OPTIND - 1 ))

if [ $OPT_ERROR ]

then

69
 echo >&2 "usage: $0 [-cnamhr]

-c : install common packages

-n : install nfs server

-a : install cloud agent

-m : install management server

-h : show this help

-r : reboot after installation"

exit 1

fi

if [ "$opt_agent" = "true" ]

then

get_network_info

fi

if [ "$opt_nfs" = "true" ]

then

get_nfs_network

fi

if [ "$opt_management" = "true" ]

then

get_nfs_info

fi

if [ "$opt_common" = "true" ]

then

add_ssh_public_key

install_common

fi

if [ "$opt_agent" = "true" ]

70
then

install_agent

fi

if [ "$opt_nfs" = "true" ]

then

install_nfs

fi

if [ "$opt_management" = "true" ]

then

install_management

initialize_storage

fi

if [ "$opt_reboot" = "true" ]

then

sync

sync

sync

reboot

fi

71
72
 II- Document de Test et Validation
Tableau de bord

73
Zone

74
Pod

75
Cluster

Hôte

76
Stockage primaire

77
Stockage secondaire

78
Instance

79
ANNEXE 2 : Notions Diverses

I- SERVEUR RACK [32]

Un serveur Rack est un serveur qui s’intègre dans une baie Rack. Une baie étant une armoire métal-
lique généralement à glissières fermé par une porte en verre ou métal afin de protéger les machines.
Elle permet la mutualisation de l’alimentation électrique et les solutions de stockage ou sauvegarde.

L’Unité U est l’unité de Rack utilisée pour définir la hauteur des serveurs : 1U

= 44.45 mm. Quant à la profondeur, elle diffère selon le standard utilisé qui varie d’un secteur
d’industrie à un autre. Le standard des racks 19 pouces est le plus répandu : 48,26 cm de large et
43,18 cm de profondeur.

II- NIVEAU DE RAID [33]

Le RAID pour « Redundant Array of Independent Disks »ou « regroupement redondant de disques
indépendants »est un ensemble de technique de virtualisation de stockage utilisé pour le but
d’améliorer selon le besoin la performance, la sécurité ou la tolérance aux pannes.

En effet, un système RAID permet la répartition des données sur plusieurs disques durs soit pour
améliorer les performances (RAID 0) soit pour assurer la redondance (RAID 1) soit les deux en-
sembles (RAID 5).

RAID 0 : « volume agrégé par bandes »

RAID 0 permet d’augmenter les performances en faisant travailler plusieurs disques durs en parallèle.
L’appellation volume agrégé par bandes revient au fait que les données sont découpées en plusieurs
bandes qui seront disposés sur les différents disques. L’inconvénient principal de ce niveau est le
manque de la redondance et la protection des données. Si un disque tombe en panne, toutes les
données deviennent inaccessibles.

Figure II.1 – Niveau RAID 0

80
RAID 1 : « Disques en miroir »

RAID 1 utilise plusieurs disques redondants, chaque disque contenant à tout moment exactement les
mêmes données, d’où l’appellation « miroir ». Contraire- ment au RAID 0, cette redondance offre un
niveau de sécurité : si un seul disque tombe en panne, les données restent disponibles sur les autres
disques. Par contre, le RAID 1 diminue les capacités d’au moins 50 %.

Figure II.2 – Niveau RAID 1

RAID 5 : « volume agrégé par bandes à parité répartie »

Le RAID 5 combine la méthode du volume agrégé par bandes (striping) à une parité répartie circu-
laire. En cas de défaillance d’un seul disque, les données peuvent être récupérées à partir du bloc de
parité et les autres blocs de données. Cependant, si un autre disque tombe en panne les données
seront perdues.

RAID 5 avec spare

Figure II.3 – Niveau RAID 5

En cas de défaillance d’un disque, les données sont synchronisées avec le disque de rechange. Et par
suite, nous n’avons pas à attendre l’arrivée d’un disque de remplacement et lorsque le disque défail-
lant est remplacé, le disque de remplacement devient le nouveau disque de rechange.

81
Figure II.4 – Niveau RAID 5 avec spare

82