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 : ……….….…………..
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.
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
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
Liste des figures
Figure 1.1- Organigramme Databox……….. 11
Figure 1.2- Virtualisation des serveurs………. Figure 1.3- Types d’hyperviseurs………. Figure 1.4- Services du cloud …………..……….……… 1314 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………..
Figure 4.2- Stockage SAN………...………..
Figure 4.3- Stockage NAS………...………..
Figure 4.4- Architecture de la solution adoptée………..
Figure 4.5- Services installés sur Serveur de management………..
Figure 4.6- Services installés partie Réseaux ……….
Figure 4.7- Services installés sur Stockage NFS ………
Figure 4.8- Script d’installation CloudStack……….………..
Figure 4.9- Instance CloudStack………..
35 3939 4246 4747 48 49
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 1ereproposition………. 37
Table 3.4- Capacité offerte par la 2emeproposition……… 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
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
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.
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.
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
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
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.
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
ESXI Vcenter La solution la plus per-
formante Coût de déploiement
élevé
Hyper-V Hyper-V manager Solution performante Coût de License élevée
KVM Virt-manager Produit libre
Intégré dans noyau de
linux Moins performant
Xen Virt-manager Déploiement rapide
qui ne consomme pas trop de ressources
un hyperviseur de type I - ce qui signifie qu'il se trouve sur une 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].
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.
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.
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é.
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
Dell R730 CPU 20 CPU 20 CPU
RAM 96 GB 3 TB
Disque 600 GB 29 TB
Dell R310 CPU 4 CPU 4 CPU
RAM 24 GB 32 GB
Disque 500 GB 8 TB
HP dl 380 G6 CPU 8 CPU 8 CPU
RAM 8 GB 192GB
Disque 4*72 GB 8 TB
HP dl 380 G5 CPU 2 CPU (4 cœurs) 4 CPU
RAM 8 GB 64 GB
Disque 200 GB 2 TB
HP dl 380 G5 CPU 2 CPU (4 cœurs) 4 CPU
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
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.
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].
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
Tableau de bord Horizon
propose une application web qui permet aux
la gestion du Cloud à travers une interface graphique.
Horizon est capable d’interagir avec les APIs des diffé- rents services d’Openstack.
Calcul Nova contrôle l’hyperviseur et gère les ressources
de l’infrastructure et les instances dans l’environnement.
Réseau Neutron
gère la partie réseau dans l’Openstack. Les
utilisateurs peuvent créer leurs propres ré- seaux et routeurs virtuels et interconnecter leurs instances au réseau externe
Stockage d’objet Swift
Stocke et récupère arbitrairement les objets de données non structurés à travers le Web service RESTful. Swift est très tolérant aux erreurs dues aux réplications de données.
Stockage de blocs Cinder
Procure des blocks de stockage persistants
pour les instances en cours d’exécution.
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.
Service d’imagerie Glance stocke les images des machines virtuelles utilisées pour lancer les instances à travers le pro- jet nova.
Télémétrie Celiometer collecte les informations sur l’utilisation des ressources pour le service de facturation.
Orchestration Heat Orchestre les différents composants du cloud.
Service de base de
données Trove installe et de gère facilement des instances de 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
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:
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
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].
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
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
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.
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 »
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
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
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 :
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 »
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.
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.
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
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.
1ereproposition: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 1ereproposition 2émeproposition: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
Table 3.4- Capacité offerte par la 2emeproposition
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.
1ereproposition 2emeproposition
Support 10U 12U
Coût Environ 115 million Environ 150 million
Table 3.6- Tableau comparatif entre les deux propositions
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].
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 :
