AD
Téléchargé parAbdelmadjid Djebbari
400 vues

Deploiement solution_ha_de_stockage_ceph_sous_une_plateforme_virtualisee_vsphere-openstack_-_bts_encadre_par_djebbari

Ce mémoire de fin de formation présente un projet sur l'administration en cloud computing et la virtualisation, réalisé au sein de l'entreprise Naftal. Il décrit les technologies de virtualisation, les solutions de cloud, ainsi qu'une étude comparative des différentes options disponibles. Le travail inclut également des scénarios pratiques d'application de ces technologies, ainsi qu'une analyse des besoins fonctionnels et de la supervision des ressources.

Intégrer la présentation

Télécharger pour lire hors ligne
1 / 141
2 / 141
3 / 141
4 / 141
5 / 141
6 / 141
7 / 141
8 / 141
9 / 141
10 / 141
11 / 141
12 / 141
13 / 141
14 / 141
15 / 141
16 / 141
17 / 141
18 / 141
19 / 141
20 / 141
21 / 141
22 / 141
23 / 141
24 / 141
25 / 141
26 / 141
27 / 141
28 / 141
29 / 141
30 / 141
31 / 141
32 / 141
33 / 141
34 / 141
35 / 141
36 / 141
37 / 141
38 / 141
39 / 141
40 / 141
41 / 141
42 / 141
43 / 141
44 / 141
45 / 141
46 / 141
47 / 141
48 / 141
49 / 141
50 / 141
51 / 141
52 / 141
53 / 141
54 / 141
55 / 141
56 / 141
57 / 141
58 / 141
59 / 141
60 / 141
61 / 141
62 / 141
63 / 141
64 / 141
65 / 141
66 / 141
67 / 141
68 / 141
69 / 141
70 / 141
71 / 141
72 / 141
73 / 141
74 / 141
75 / 141
76 / 141
77 / 141
78 / 141
79 / 141
80 / 141
81 / 141
82 / 141
83 / 141
84 / 141
85 / 141
86 / 141
87 / 141
88 / 141
89 / 141
90 / 141
91 / 141
92 / 141
93 / 141
94 / 141
95 / 141
96 / 141
97 / 141
98 / 141
99 / 141
100 / 141
101 / 141
102 / 141
103 / 141
104 / 141
105 / 141
106 / 141
107 / 141
108 / 141
109 / 141
110 / 141
111 / 141
112 / 141
113 / 141
114 / 141
115 / 141
116 / 141
117 / 141
118 / 141
119 / 141
120 / 141
121 / 141
122 / 141
123 / 141
124 / 141
125 / 141
126 / 141
127 / 141
128 / 141
129 / 141
130 / 141
131 / 141
132 / 141
133 / 141
134 / 141
135 / 141
136 / 141
137 / 141
138 / 141
139 / 141
140 / 141
141 / 141
REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE MINISTERE DE LA FORMATION ET DE L’ENSEIGNEMENT PROFESSIONNELS INSTITUT NATIONAL SPECIALISE DE FORMATION PROFESSIONNELLE DE BOU-ISMAIL WILAYA DE TIPAZA Mémoire de Fin de Formation en Vue de l’Obtention du Diplôme de Brevet de Technicien Supérieur Spécialité : Informatique/Option : Administration Cloud computing et virtualisation Code de la Spécialité : INT1704 THEME : L’Organisme d’Accueil : SG. NAFTAL Elaboré par : Encadré par : - HADJI Younes Fethi M. DJEBBARI Abdelmadjid - LAROUCI Mostafa - BOUKROUMA Abd El Moumen Co-Encadreur : M. MANSSORI Djamel PROMOTION : Février 2020
REMERCIEMENTS Nous remercions tout d’abord « ALLAH » de nous avoir donné le courage d’entamer et de finir ce mémoire dans les bonnes conditions. Nous remercions vivement notre encadreur, Le professeur Mr. Djebbari Abd El Madjid, d’avoir encadré ce travail avec beaucoup de compétences. Nous remercions notre promoteur Mr. Mansouri Djamel Merci pour votre indéfectible disponibilité, votre rigueur scientifique et la confiance que vous nous avez accordée au cours de l’élaboration de ce mémoire ; Merci pour l’acuité de vos critiques et pour vos conseils éclairés. Nous remercions également les membres du jury d’avoir accepté d’évaluer ce travail. Nos remerciements vont également à tous les enseignants qui ont à notre formation. Nos profondes gratitudes s’orientent vers Mr. Abd El Karim ; grâce à lui nous étions des stagiaires à la D.G NAFTAL. Ainsi que tout le personnel du département DCSI de NAFTAL.
DEDICACE Je dédie ce modeste travail à : A la mémoire de mon Père Aucune dédicace ne saurait exprimer l’amour, l’estime, le dévouement et le respect que j’ai toujours eu pour vous. A ma très chère mère Aucune dédicace ne saurait être assez éloquente pour exprimer ce que tu mérites pour tous les sacrifices que tu n’as cessé de me donner depuis ma naissance, durant mon enfance et même à l’âge adulte. Tu as fait plus qu’une mère puisse faire pour que ses enfants suivent le bon chemin dans leur vie et leurs études. Je te dédie ce travail en témoignage de mon profond amour. Puisse Dieu, le tout puissant, te préserver et t’accorder santé, longue vie et bonheur. A mes chères sœurs Je vous souhaite un avenir plein de joie, de bonheur, de réussite et de sérénité. Je vous exprime à travers ce travail mes sentiments de fraternité et d’amour. Hadji Younes Fethi
DEDICACE Je dédie ce modeste travail à : Mes chers parents Rien au monde ne vaut les efforts fournis jour et nuit pour mon éducation et mon bien être. Ce travail est le fruit de tes sacrifices que tu as consentis pour mon éducation et ma formation. A mon très cher frère Samir Mon cher frère, les mots ne suffisent guère pour exprimer l’attachement, l’amour et l’affection que je porte pour vous. Mon ange gardien et mon fidèle compagnon dans les moments les plus délicats de cette vie mystérieuse. Je vous dédie ce travail avec tous mes vœux de bonheur, de santé et de réussit. A Mes chères frères et sœurs En témoignage de l’attachement, de l’amour et de l’affection que je porte pour vous. Je vous dédie ce travail avec tous mes vœux de bonheur, de santé et de réussite. A tous les membres de ma famille Petits et grands Veuillez trouver dans ce modeste travail l’expression de mon affection. A Mes chères Mohamed, Arbi, Ben Omar et Oussama ; Que dieu vous assistes. Larouci Moustafa
DEDICACE Je dédie ce modeste travail à : Mes chers parents Pour tous leurs sacrifices, leur amour, leur tendresse, leur soutien et leurs prières tout au long de mes études. Que ce travail soit l’accomplissement de vos vœux tant allégués, et le fuit de votre soutien infaillible. A Mes chères sœurs Je vous dédie ce travail avec tous mes vœux de bonheur, de santé et de réussite. A Mes enseignants Un profond respect et un remerciement particulier pour vous. A mes Amis A tous ceux qui me sont chers Boukrouma Abd El Moumen
Table des matières : Remerciements Dédicaces Introduction générale Problématique Objectifs du projet Chapitre 1 : présentation de l’entreprise (lieu du stage)…………………………………...1 Section I : Fiche signalétique de NAFTAL District Carburants.……………………….1 A. Historique de NAFTAL ………………………………………………………..1 B. Principales tâches et responsabilités de NAFTAL ……………………...…….1 C. Organisation de NAFTAL ……………………………………………………...2 1. Service Informations de Gestion (ING) : sa mission consiste à……………2 2. Département AMG (administration et moyen généraux) : Les missions du département AMG sont…………………………………………………….2 3. Département finances et comptabilité : Le département finance et comptabilité a pour mission de…………………………………………….2 4. Département Transport & Technique : Il a pour mission………………....3 Section II : Les Moyens et de l’entreprise NAFTAL…………..……………………….4 A. Les moyens de l’entreprise NAFTAL…………………………………..………4 B. Produits commercialisés par l’entreprise…………………………………….…5 1. Carburants………………………………………………………………....5 2. Gaz de pétrole liquéfié ……………………………………………….……6 Chapitre 2 : Technologie de Virtualisation et de Cloud : Etat de L'art………………...…..9 I. Introduction………………………………………………………………….…...9 II. Technologie de Virtualisation....…………………………………………....…...9 1. Définition...………………………………………………………………….9 2. Historique de la virtualisation………...……………………………………..9 2.1. Premiers pas…………………………………………………..…….9 2.2. Machines virtuelles…………………………………...……………..9
2.3. Amélioration des technologies………………………….………….10 2.4. Intérêt du grand public……………………………………..……….10 3. Les types de virtualisations.………………………………………………..10 3.1. La virtualisation complète.………………………………………....10 3.2. La paravirtualisation ……………………………………………13 3.3. Virtualisation matérielle …………………………………………..15 4. Techniques de virtualisation …..…………………………………………...17 4.1. L’Isolation et Le Cloisonnement …………………….…………....17 III. Technologie de Cloud Computing ……………………………………………..17 1. Technologie de Datacenter ………………………………………………...17 2. Historique du Cloud Computing….……………………..........................18 3. Bénéfices du cloud Computing ……………………………………………18 3.1. Pour le fournisseur ………………………………………….……..18 3.2. Pour l'entreprise ...…………………………………………………18 IV. Les différents services…………………………………………………………19 V. Types et Modèles de déploiement de cloud……………………………………19 VI. Les solutions de cloud…………………………………………………………20 1. Eucalyptus……………………………………………………….…………20 2. OpenNebula………………………………………………………………..20 3. OpenStack…………………………………………………………….……20 Chapitre 3 : Etude Comparative et Choix de la solution………………………….………23 I. Introduction…………………………………………………….……………...23 II. Solutions de Virtualisation …………………….……………………………...23 1. VMware (vSphere, ESXi...) ...………….……………………………….....24 1.1. VMware vSphere ………………………………………………..…24 1.2. Composants et fonctionnalités…………………………………..….25 2. Citrix (Xenserver...) ……………………………………………………..…30 2.1. Composants et fonctions…………………………………………....32 2.1.1 . Composants principaux…………………………………….....32 2.1.2 . Composants supplémentaires…………………………………35
III. Solutions de cloud…………………………………………………………...36 1. Solution Eucalyptus ……………………………………………………......36 2. Solutions OpenNebula……………………………………………………...37 3. Solutions Openstack………………………………………………………..38 Chapitre 4 : Technologies de stockage et Haute Disponibilité…………………………….43 I. Introduction…………………………………………………………...………43 1. Technologies de stockage (NAS SAN...)…………………………….……44 1) Fonctionnement………………………………………………….…47 2) Quel type de réseau utilise un réseau SAN?......................................47 3) Quels types de commutateurs sont appropriés SAN?........................48 4) Peut-on bâtir un réseau SAN sur réseau existant?.............................48 5) Qu'est-ce qu'un serveur SAN?...........................................................48 6) Topologie…………………………………………………………..49 7) Applications………………………………………………………..49 8) Défauts et qualités…………………………………………….....49 A. Défauts………………………………………………….....49 B. Qualités………………………………………………….....49 2. Systèmes de stockage (CEPH NFS...) ………………………………….....51 A. Architecture de CEPH ………………………………………………..52 B. Les services CEPH……………………………………………………53 C. Gestion de stockage CEPH……………………………….…………...53 C.1. Les pools……………………………………………….…….....53 C.2. Réplication de données………………………………………....54 a. Clonage……………………………….....................................54 b. Utilisation de code à effacement (erasurecoding)…………….54 D. Implantation de stockage distribué à travers Proxmox VE……....…..55 D.1.Implémentation du système de stockage tolérance aux pannes développées pour la virtualisation: le Ceph…………………………………….…..55 a. Configuration du réseau dédié à Ceph…………………….….55 D.2.Installation des paquets CEPH ………………………………...56 D.3.Création de la configuration initiale Ceph……………………..56 D.4.Mise en place des services Ceph……………………………….56 a.Création des moniteurs Ceph………………………………....56
b.Création des OSD Ceph ……………………………………...57 D.5. Création de pool Ceph…………………………………………57 3. Concepts et techniques de la haute disponibilité …………………………59 3.1. Mesure du taux de disponibilité……………………………...……59 3.2. Techniques améliorant Ha disponibilité……………………….....60 3.3. Dépendance vis-à-vis des autres applications…………………….61 3.4. Répartition de charge et sensibilité……………………………….62 3.5. Redondance différentielle………………………………………...62 3.6. Redondance avec système de vote………………………………..62 3.7. Shadow opérations………………………………………………..63 4. Les processus qui permettent d'améliorer la haute disponibilité……...….63 4.1. Les processus qui réduisent le nombre de pannes………………….63 4.2. Les processus réduisant la durée des pannes………………………..63 5. Cluster haute disponibilités ……………………………………………...63 Chapitre 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins……………66 I. Introduction…………………………………………………………………66 II. Scénario 1 : Serveur web virtualisé au sein d'Openstack …………………..66 1. Scénario 1a : Système de stockage NFS …………………………………………66 1.1 Les entités physiques………………………………………………..67 1.2 L’utilité des services Openstack…………………………………….68 1.3 Echange de messages………………………………………………..69 1.4 Les services OpenStack…………………………………………………70 1.4.1 Administration de l’infrastructure Openstack ……………...70 1.4.2 Gestion de la virtualisation …………………………………71 1.4.3 Gestion de l’authentification (Keystone)……………………72 1.4.4 Les Bases de Données……………………………………….74 1.5 Profil d’une VM……………………………………………………..75 1.6 Processus de démarrage d’une VM ………………………………...77 1.7 Réseau des VMs……………………………………………………..79 1.8 Stockage par fichier des VMs………………………………………..81
1.9 Conclusion du Scénario 1a ………………………………………….82 2. Scénario lb : Gestion du stockage par bloc ………………………………..82 2.1. Schéma du scénario lb ……………………………………………....82 2.2. Composition de Cinder……………………………………………....83 2.3. Fonctionnement de Cinder…………………………………………...83 2.4. Problèmes rencontrés…………………………………………………84 2.5. Conclusion du Scénario 1b…………………………………………...85 III. Scénario 2 : Haute Disponibilité du Cloud Controller ……………………..85 1. Qu'est-ce que la HA ………………………………………………………..85 1.1 La HA Active/Active………………………………………………....86 1.2 La HA Active/Passive………………………………………………..86 1.3 L’IP flottante ou virtuelle…………………………………………….87 1.4 Services Stateless ou Statefull………………………………………..87 2. Scénario 2 : La HA au sein des AP] OpenStack……………………………88 2.1. Schéma du scénario 2a……………………………………………….88 2.2. But du Scénario…………………………………………………........89 2.3. Éléments physiques…………………………………………………..89 2.4. HA Active/Active avec HAProxy……………………………………89 2.5. HA Load Balancer avec KeepAlived………………………………...90 2.6. Bilan Scénario 2a…………………………………………………….90 3. HA SQL (Active/Active Statefull) ………………………………………...92 3.1. Schéma du Cluster SQL……………………………………………...92 3.2. Théorème du CAP……………………………………………………93 3.3. Gestion du Cluster SQL……………………………………………....94 IV. Scénario 3 : Collecte et entreposage des Logs………………………………95 1. Cahier des Charges………………………………………………………….95 2. Contraintes………………………………………………………………….95 3. Variantes de stockage de Logs………………………………………………96 3.1. Variante 1 : Stockage des Logs sous forme de fichiers……………….96 3.2. Variante 2 : Logstash-­‐> ElasticSearch……………………………....98 3.3. Variante3 : Logstash-­‐> Redis -­‐> Logstash -­‐>ElasticSearch……..102 3.4. Variante 4 : Abolition du serveur de Logs physique………………….103 3.5. Comparaison des quatre variantes et choix…………………………...103 3.6. Choix de la variante…………………………………………………..105
4. Supervision des ressources physiques……………………………………....105 5. Problèmes rencontrés………………………………………………………..106 6. Bilan du scénario 3…………………………………………………………..106 Chapitre 6 : Supervision des ressources avec Shinken……………………………………...108 I. Introduction……………………………………………………………………..108 1. But du scénario……………………………………………………………….108 2. Schéma de principe…………………………………………………………..108 3. Supervision des services d'APl OpenStack…………………………………...108 3.1. Problème au niveau des tests via l'IP Virtuelle ………………………..110 4. Supervision des ressources physiques………………………………………...110 5. Mise en place de tests interdépendants………………………………………..111 5.1 Finalité du test…………………………………………………………..111 5.2 Plugin de démarrage d’une VM intégré à Shinken……………………..112 6. Bilan du scénario………………………………………………………………113 Conclusion générale……………………………………………………………………………114 Bibliographie……………………………………………………………………………………115 Liste des abréviations …………………………………………………………………………116
Liste des figures : Numéro Désignation page Figure 2.1 Virtualisation complète 11 Figure 2.2 Couches d’abstraction pour la gestion de la mémoire 12 Figure 2.3 Paravirtualisation 14 Figure 2.4 Hyperviseur 16 Figure2.5 Les services de cloud 19 Figure 3.1 Relations entre les couches de composants de VMware vSphere 24 Figure 3.2 VMware ESXI 25 Figure 3.3 VMware vSphere Client 26 Figure 3.4 VMware vSphere Web Client 27 Figure 3.5 VMware VCenter Server 27 Figure 3.6 vSphere vMotion 28 Figure 3.7 vSphere Storage vMotion 29 Figure 3.8 vSphere High Availability (HA) 29 Figure 3.9 vSphere Fault Tolerance 30 Figure 3.10 Xen server architecture 31 Figure 3.11 les composants principaux d’un déploiement typique 32 Figure 3.12 Citrix Studio 34 Figure 3.13 Architecture d’Eucalyptus 37 Figure 3.14 Les déférents couches d’OpenNebula 38 Figure 3.15 Les déférents taches d’Openstack 39 Figure 3.16 Les différents services d’openstack 41 Figure 4.1 L’architecture de réseau NAS 44 Figure 4.2 Protocole de stockage NAS 46 Figure 4.3 L’architecture de réseau SAN 47 Figure 4.4 Topologie de réseau SAN 49 Figure 4.5 L’architecture de réseau DAS 50 Figure 4.6 Topologie de réseau DAS 51 Figure 4.7 Architecture Cèph 52 Figure 4.8 Organisation des données dans Ceph 54 Figure 4.9 Illustration des deux modes de réplication des données 55 Figure 4.10 Création d'une carte réseau en mode agrégation 56 Figure 4.11 OSD installé 57 Figure 4.12 L'état de cluster Ceph 58 Figure 5.1 But des services OpenStack 68 Figure5.2 Différents types de messages 70 Figure5.3 Interface GUI Horizon 71 Figure5.4 Authentification Keystone 73 Figure5.5 Disques virtuels d'une VM 76 Figure5.6 Démarrage d'une VMs 77 Figure5.7 Configuration de la future VM 78 Figure5.8 Gestion de l'IP flottante 80 Figure5.9 Security-Group sous Horizon 81 Figure 5.10 Graphiques générés par Kibana 101 Figure 5.11 Chargement des JSON distants 102 Figure5.12 Aperçu du Cluster 106 Figure 6.1 Infrastructure opérationnelle 109 Figure 6.2 Fonctionnement de la HA malgré un des deux Horizon Down 109
Liste des Schémas : Numéro Désignation page Schéma 5.1 schéma Scénario 1a 67 Schéma 5.2 schéma Scénario 1b 82 Schéma 5.3 Attribution d'un volume par bloc 83 Schéma 5.4 Principe de HA 85 Schéma 5.5 HA Active/Passive 86 Schéma 5.6 Gestion IP virtuelle 87 Schéma 5.7 HA au sein de l'API OpenStack 88 Schéma 5.8 HA au niveau SQL 92 Schéma 5.9 Théorème du CAP 93 Schéma 5.10 Récolte des Logs en un point central 96 Schéma 5.11 Producteurs de logs -> Consommateurs 98 Schéma 5.12 Cluster ElasticSearch 100 Schéma 5.13 Récupération des Logs avec Kibana 101 Schéma 5.14 Mémoire tampon de Logs 102 Schéma 5.15 Cluster ELS variante 2 103 Schéma 6.1 Monitoring des API et serveurs physiques 108 Schéma 6.2 Diagrammes de tests Shinken 112
I INTRODUCTION GENERALE: Surfer dans les nuages a toujours été le rêve des hommes. Ce domaine était longtemps réservé aux poètes, et leur offrait la possibilité de s’évader des problèmes quotidiens qui les assaillaient. Mais depuis le jour où les avions et autres objets volants, conquirent le grand espace ciel, une grande majorité de gens pouvait sillonner plusieurs types de nuages. Ce rêve est également devenu réalité, dans le domaine de l’informatique. Actuellement, on parle beaucoup de Cloud Computing, et ce n’est pas par hasard. En effet, le matériel et les systèmes informatiques associés évoluent pour satisfaire les besoins de calcul qui s’accroîent chaque jour. Pour cela, les chercheurs et les technologues travaillent dur et péniblement afin de simplifier la gestion des infrastructures informatiques, la continuité d’activité et la réduction du coût qui représente une stratégie des entreprises d’aujourd’hui pour se focaliser sur leur métier spécifique marqué par une concurrence aiguë. Les solutions présentes sur le marché actuellement sont souvent complexes et très coûteuses. En parallèle, les évolutions quotidiennes au niveau des infrastructures réseaux et les systèmes d’information ont conduit à l’arrivée de nouveaux périphériques et technologies, ce qui rend la tâche de déploiement et de gestion encore plus difficile à assurer. De toutes ces contraintes est né le besoin de « la virtualisation » qui est survenu comme une solution révolutionnaire à un grand nombre de défis auxquels l’entreprise devait faire face. Assurément, remplacer un parc de serveurs physiques par une architecture virtualisée constitue une véritable révolution dans la conception des systèmes d’information. L’objectif de cette technique est d’augmenter la flexibilité et d’améliorer l’utilisation des ressources matérielles à moindre coût, tout en assurant la performance et la disponibilité des services. Cette notion a évoluée encore plus, et a fait apparaître un nouveau terme : le Cloud Computing. Dans les dernières années, cette terminologie, qui se base sur la virtualisation, a envahi le monde de la commercialisation, et s’est présentée comme une solution inédite arrivant jusqu’aux clients distants. Toutefois, cette tendance divulgue des défaillances, qui ont été souvent ignorées lors de ces déploiements en raison du coût, ou la complexité de mise en place. Les entreprises ont besoin de mettre en place plusieurs outils et services pour pouvoir exécuter leurs travaux, afin de bien assurer la gestion des projets, leurs qualités et la productivité des équipes ainsi que l’évolution sûre du produit pour une meilleure compétitivité sur le marché. C’est sous cette optique, que nous allons réaliser au niveau de ce PFE, une plateforme de virtualisation qui permet de migrer de l’architecture physique existante vers un environnement virtuel et déployer une solution haute disponibilité de stockage.
II Problématique : Parmi les problèmes et les limites que nous avons étudiées taus allons citer : • Le non interoperabi lite entre les diffèrent types d'hyperviseurs (ESXi, KVM) • Facturation selon la performance des ressources répondre aux besoins des clients par fournit des machines et des serveurs virtuels de performances précises selon leurs besoins. • Cout élevé. A. Les hypothèses : Les principales motivations pouvant influences l'adoption d’une solution alternative aux posses de travail physiques traditionnels sont les suivantes : • Minimiser les coûts. • Gestion des postes de travail plus facile. • Accès distant. Facile • Flexibilité assurée. B. Le plan de travail : • Technologie de Virtualisation et de Cloud : Etat de L'art. • Etude Comparative et Choix de la solution. • Technologies de stockage et Haute Disponibilité. • Branche Fonctionnelle : Analyse et Spécification des Besoins. • Supervision des ressources avec Shinken. • Branche Technique : Spécifications Techniques. • -Perspectives futures. C. Les méthodes de recherche adoptées : Le projet a été mené en suivant 6 étapes : • Etude préalable. • Recueil des besoins. • Etude et conception du projet. • Phase de réalisation. • Mise en œuvre. • Evaluation.
III D. Les raisons du choix du thème : Nous avons choisi ce thème car il nous permettre de : • Pouvoir faire les bons choix de configuration. • Savoir déployer manuellement un cloud Vsphére / OpenStack pour fournir du IaaS. • -Connaitre les bonnes pratiques de déploiement d’OpenStack et de Vsphére. • Être capable de déterminer l’origine d’une erreur dans OpenStack et un Vsphére. • -Savoir réagir face à un bug.
IV Objectif du thème : - Avoir une solution fiable et efficace pour anticiperles difficultés quepourrait rencontrer un internaute et qui permettra de mettre en place des actions et des paramètres techniques, pour qu’une infrastructure informatique soit toujours en mesure de répondre à la requête d’un utilisateur - Manipuler et orchestrer des ressources dans un cloud Vsphére / OpenStack. - Définir, déployer et maintenir une infrastructure dans le cloud. - Connaitre le fonctionnement du projet Vsphére / OpenStack et ses possibilités Comprendre le fonctionnement de chacun des composants d’OpenStack /Vsphére. Les contraintes affrontées durant la réalisation du travail : Ce PFE a été effectué dans une période insuffisante. Au début du PFE, le sujet n'était pas encore clairement défini. En plus la difficulté de collecte des données et des informations avec le manque de références et matériel. Nous avons également eu de la difficulté à communiquer les uns avec les autres en raison de la séparation à cause de virus Corona.
CHAPITRE 1
CHAPITRE 1 : Présentation de l’entreprise (lieu du stage) 1 • Présentation de l’organisme d’accueil : Section I : Fiche signalétique de NAFTAL District Carburants. A.Historique de NAFTAL : Issue de SONATRACH (Société National pour la recherche, Transport, production, transformation, la commercialisation des hydrocarbures), l’entreprise nationale de raffinage et de distribution de produits pétroliers (ERDP) a été crée par le décret N°80-101 datant du 06 Avril 1980. Entrée en activité le 01er Janvier 1982, elle fut chargée de l’industrie de raffinage et de la distribution de produits pétroliers. Le 04 Mars 1985, les districts suivants carburants, lubrifiants, pneumatiques et bitumes ont été regroupés sous le nom UND (Unité NAFTAL de Distribution). Durant l’année 1987, l’activité de raffinage est séparée de la distribution, conformément au Décret N°87-189 du 25 Aout 1987.Modifiant ainsi le décret N°80-101 du 06 Avril 1980, donnant naissance a une nouvelle entreprise nationale dénommée : « Entreprise nationale de commercialisation et de distribution de produits pétroliers » Sous le sigle de « NAFTAL ». Dès l’année 1998, elle change de statut et devient une société par action SPA et filiale SONATRACH a 100 %, elle interviendra par la suite dans les domaines suivants : • Dans l’enfûtage GPL. • Dans la formulation des bitumes. • Dans la distribution, stockage et commercialisation des carburants, GPL, lubrifiants, bitumes, pneumatiques, GPL/produits spéciaux. • Dans le transport des produits pétroliers. Le 01er Janvier 2000, l’activité GPL enfutage est séparée de l’activité CLP. Par décision N°S 554 du 29 mars 2000, il a été procédé à l’organisation générale de la division CLP et l’identification des zones de distribution « CLP » (Carburants Lubrifiants et Pneumatiques). Par décision N° 555 du 29 Mars 2000, il a été procédé à la création des zones de distribution CLP. Par décision N°S 606 du 10 Février 2001, il a été procédé à l’organisation et la classification des centres Bitumes de la division Bitume. Par décision N°S 705 du 17 juin 2002, il a été procédé à la re-nomination des zones de distribution CLP et GPL en District. Par décision N°S766 du 22 Décembre 2003, il a été procédé à la dissolution de la branche CLPB. Par la décision N°S 770 du 03 Janvier 2004, il a été procédé à la dissolution des districts CLP et création des districts commercialisation. A partir du 01er décembre 2006 l’activité carburant est séparée de l’activité commercialisation (L’activité carburant se charge du stockage et déstockage des carburants et l’activité commercialisation s’occupe essentiellement des achats, ventes, bilan annuel, projets…etc.). B.Principales tâches et responsabilités de NAFTAL : • Identifier et recenser les infrastructures, équipements et autres moyens matériels camions, canalisation) relevant de l’activité carburants du district, les structures d’organisation (services, maintenance, installations fixes, surveillance et entretien canalisations, reconnaissance produits…) et les moyens humains œuvrant pour l’activité carburants. • Suivre les plans établis par la branche carburant pour l’approvisionnement et le ravitaillement en carburants des dépôts et communiqué régulièrement les états d’exécution aux structures concernées.
CHAPITRE 1 : Présentation de l’entreprise (lieu du stage) 2 • Exécuter les programmes de la distribution établis par les districts commercialisation pour la livraison de la clientèle. • Gérer les stocks en carburants au niveau des dépôts et communiques régulièrement des points de situation aux structures concernées de la branche. • Suivre l’exploitation et la maintenance des infrastructures de stockage et autres moyens (camions, canalisations) carburants des branches rattachées au district. • NAFTAL est responsable, en liaison avec les responsables concernés des centres carburants et canalisations, de la sûreté interne des installations et des moyens. • Gérer en liaison avec les structures de la branche, les relations avec les directions des raffineries NAFTEC, capotage et transport SNTR et tiers et les transmettre aux structures de la branche pour règlement. • Approuver les bordereaux inter unités (BIU) émis par les districts commercialisation vers le district carburant. C.Organisation de NAFTAL : Comme toute entreprise NAFTAL possède sa propre organisation nous illustrons les principaux services : 1. Service Informations de Gestion (ING) : sa mission consiste à : • Collecter, vérifier et analyser les informations de gestion de district. • Elaborer les tableaux de bord et rapports de l’activité du District. • Assurer l’installation et l’exploitation et la sauvegarde des logiciels de gestion et données afférentes. • Prêter assistance aux structures en matière d’exploitation des applications informatiques opérationnelles. 2. Département AMG (administration et moyen généraux) : Les missions du département AMG sont : • Assurer la gestion des moyens généraux du district • Assurer la gestion des ressources humaines • Assurer la gestion de l’administration • Assurer la gestion des œuvres sociales et culturelles 3. Département finances et comptabilité : Le département finance et comptabilité a pour mission de : • Coordonner et suivre toutes les activités de comptabilité de trésorier, budget et patrimoine. • Consolider, analyser les états comptables et veiller à la sincérité des comptes du District. • Veiller à la concordance des écritures comptables avec les flux physiques et financiers. Service trésorerie : il est composé de deux sections, la Section recettes et la section dépense.
CHAPITRE 1 : Présentation de l’entreprise (lieu du stage) 3 Sa mission est de : • Suivre et contrôler les flux, recettes et dépenses de trésorerie. • Traiter les dossiers de paiement d’investigation, fournisseurs et autres dépenses. • Etablir les situations de rapprochement des comptes (recettes et dépenses) • Contrôler et effectuer les comptabilisations des comptes et grands livres de trésorerie. • Etablir des rapports d’activités. Service comptabilité générale : il est composé de deux sections, la Section SVCD et la Section comptabilité. Sa mission est de : • Procéder aux écritures comptables conformément aux préconisations du plan comptable national. • Elaborer les documents comptables (Bilans, balances et livres). • Contrôler les arrêtés de comptes et préparer les inventaires et bilans. • Elaborer les analyses et synthèses comptables. • Procéder aux opérations des clôtures et réouvertures des comptes. Service budgets et coûts : Ses diverses missions sont : • Elaborer les budgets prévisionnels d’investissement et de fonctionnement du District. • Consolider l’ensemble des charges nécessaires à la détermination du coût • Contrôler et traiter les situations financières du District • Procéder aux ajustements des budgets et crédits • Assurer le suivi régulier de la comptabilité analytique 4. Département Transport & Technique : Il a pour mission : • Elaborer les plans de maintenance préventive et curative des équipements, dépôts, et canalisation et en suivre l’exécution. • Elabore les plans annuels et pluriannuels de transport, en prenant en charge les besoins de distribution et ravitaillement des produits commercialisés. • Suivi de la réalisation des travaux. • Elaborer les plans et budgets d’investissement (rénovation, extension, remise à niveau, remplacement) des installations fixes, canalisation, réseau de stations-services et autres. • Etablir un rapport d’activité périodique. Ce département comporte les services suivants : Service exploitation et maintenance : Sa mission est de : • Vérifier l’application des prescriptions du règlement d’exploitation, de sécurité des équipements et installation fixes. • Etablir les performances de maintenance. • Assurer la maintenance des installations au niveau des dépôts carburants
CHAPITRE 1 : Présentation de l’entreprise (lieu du stage) 4 Service études et réalisation : Sa mission est : • D’établir la partie technique des cahiers de charges. • De contrôler et diriger les différents travaux. • De suivre les travaux programmés ayants traits aux projets. Le District dispose de deux (02) dépôts carburants à Bejaïa, un (01) à TAHER /W. JIJEL, un (01) à Bordj Bou Arreridj et un (01) à M’SILA. Section II : Les Moyens et de l’entreprise NAFTAL : A.Les moyens de l’entreprise NAFTAL : Avec un personnel de 31500 agents. Affectif au 31/12/2009, NAFTAL est le premier et le seul distributeur de produit pétroliers en Algérie. Elle contribue de 51 % de l’énergie finale en fournissant plus de 10 millions de tonnes de produits pétroliers par an sous forme de : • Carburant. • Gaz de pétrole liquéfié. • Bitumes. • Lubrifiants Pour cela NAFTAL dispose de : • 67 centres et dépôts de distribution et stockage carburant. Lubrifiants et pneumatique. • 55 dépôts d’avitaillement d’aéronefs, centres et point de ventes à la mer. • 45 centres d’emballage GOL d’une capacité d’enfutage de 1.2 million de tonnes/an. • 59 dépôts relais de stockage GPL. ¬ 05 centres vrac GPL. • 16 unités de formulation de bitumes de 360.000 tonnes/an. • 3500 véhicules de distribution et 1800 engins de manutention et de maintenance. • 380 km de pipe-lines multi produits carburants et GPL. Et son réseau de distribution s’étend sur : • 1732 stations de service dont 328 en gestion directe par NAFTAL. • 124 points de vente d’essence sans plomb. • 268 points de vente GPL/CARBURANT. • 14550 points de vente GPL. La couverture des besoins du marché national en produit pétroliers implique des transports massifs de carburants et GPL depuis les sources de production vers les zones de consommation qui sont les districts.
CHAPITRE 1 : Présentation de l’entreprise (lieu du stage) 5 Pour assurer cet équilibre entre l’offre et la demande, NAFTAL met à contribution plusieurs modes de transport : • Cabotage pipe : pour l’approvisionnement des entreprises à partir des raffineries. • Rail/chemin de fer : pour le ravitaillement des dépôts de l’intérieure du pays à partir des entrepôts. • Route : pour la livraison des clients et le ravitaillement des dépôts non desservis par le rail. • Pour accomplir sa mission de distribution des pétroliers, NAFTAL dispose d’un parc dépassant les 3 mille véhicules de distribution constitue de : • Tracteur routier. • Semi-remorques plateaux. • Semi-remorques citernes. • Camion citernes. • Camion plateaux. • Camion porte palettes. Ça lui permet d’assurer 70 à 75 % des livraisons clients, le reste étant assuré par les transporteurs tiers ou par les clients eux-mêmes. Par ailleurs, NAFTAL dispose de (7) barges pour le soutage des navires et affrète en permanence auprès des entreprises publiques de transport : • 160 citernes carburantes (SNTR). • 960 wagons-citernes (SNTF). • 04 caboteurs (SNTM/HYPROC). B.Produits commercialisés par l’entreprise : 1. Carburants :  Terre : NAFTAL commercialise quatre (4) types de carburants « terre » pour la motrice essence et diesel : • Essence super. • Essence normale. • Essence sans plomb. • Gas-oil. Ces produits stockés et distribués par NAFTAL sont tous issus des raffineries de NAFTEC et répondent entièrement aux normes de qualité algérienne.  Aviation : Jet a1-for Jos issus 18 kérosène utilisé par les avions.  Marine : FUEL BUNKERC • Norme iso 9217 FUEL 80(BTS), utilisée par les navires.
CHAPITRE 1 : Présentation de l’entreprise (lieu du stage) 6 2. Gaz de pétrole liquéfié  Nature et composition : Les GPL désignent : gaz de pétrole liquéfié. Ce sont les mélanges de butane 4) et de propane (3). Les GPL peuvent être obtenus à partir de traitement des hydrocarbures tels que : • Le traitement du gaz naturel ou gaz associés. • Le raffinage du gaz naturel. • La liquéfaction du gaz naturel. Dans la gamme des produits GPL, NAFTAL commercialise trois (3) produits essentiels : • Le butane commercial. • Le propane commercial ; • Le GPL carburant « SIRGHAZ ». Suite à une phase d’étude d’expérimentation entamée en 1977.la décision d’introduire le GPL carburant « SIRGHAZ » est intervenue en 1983 avec l’adoption de bicarburation et de la mise en place de la réglementation liée aux conditions d’utilisation du GPL/C.  Lubrifiants : A travers son réseau de distribution étendu sur le territoire national, NAFTAL commercialise une gamme complète de lubrifiants qui couvrent tous les besoins du secteur automobile et industriel. Répondant à des normes d’emballages variés, depuis la boite de ½ litre au fut de 180 kg Les gammes commercialisées par NAFTAL sont : • Les huiles motrices à essence. • Les huiles motrices à diesel. • Les huiles motrices industrielles. • Les graisses.  Pneumatiques : Grace à des infrastructures de stockage et son réseau de distribution, NAFTAL commercialise des pneumatiques des grandes marques dans les catégories de véhicules les plus diverses : • Tourisme. • Camionnette. • Poids lourds. • Industriel. • Manutention. • Agraire. • Génie civil. • Cycle.
CHAPITRE 1 : Présentation de l’entreprise (lieu du stage) 7 Portant le label de constructeurs renommés, les pneumatiques proposés par NAFTAL sont fournis après contrôle de qualités les plus strictes pour garantir la sécurité des utilisateurs et répondent amplement aux exigences requises.  Bitume : NAFTAL commercialise à partir de ses centres quatre (4) formes de bitumes : • Les bitumes purs 80/100 et 40/50 utilisés dans les domaines de la construction et des chaussées. • Les bitumes oxydés 85/25 utilisés pour l’étanchéité multicouches, pour l’isolement thermique et phonique et pour la protection des ouvrages d’art. • Ils sont commercialisés en vrac et sous deux (2) formes de conditionnement, en sacs de 20 kg et en futs de 200 kg. • Les bitumes fluidifiés ou CUT-BACKS ; ils sont obtenus en fluidifiant les bitumes purs avec le kérosène. • Les émulsions de bitumes sont des dispersions de bitumes pures dans une solution aqueuse.
CHAPITRE 2
CHAPITRE 2 : Technologie de Virtualisation et de Cloud : Etat de L'art 8 I. Introduction : Alors que les données informatiques augmentent de façon exponentielle, et que les entreprises font de plus en plus appel aux processus informatiques pour gagner en productivité et en compétitivité, la possible réduction des coûts de gestion des infrastructures informatiques est une des principales priorités des entreprises. Ces dernières années, plusieurs moyens sont apparus pour aborder cette réduction des coûts, parmi lesquels, la virtualisation, et le Cloud Computing. La virtualisation et le Cloud Computing sont deux concepts différents, mais pourtant complémentaires. Nous allons dans ce chapitre nous attacher à vous présenter et vous définir ces deux notions, ainsi que leurs types et les usages possibles pour les entreprises. II. Technologie de Virtualisation : 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. 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'environnement 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 2. Historique de la virtualisation : Les premiers ordinateurs, qui occupaient plusieurs pièces d’un bâtiment, n’étaient pas faits pour exécuter plusieurs programmes à la fois. On concevait un programme (qui était à l’époque une simple succession de calculs), on le mettait dans la file d’attente des programmes, et quand le système d’exploitation avait fini de traiter un programme, on lui donnait le suivant dans la liste. 2.1. Premiers pas Très vite, dès la fin des années cinquante, l’idée de pouvoir exécuter plusieurs programmes en parallèle voit le jour. On parle de temps partagé (time sharing), de multiprogrammation, etc. L’idée était de pouvoir faire cohabiter plusieurs programmes au même moment, ayant tous accès au même matériel, sans qu’ils ne se gênent mutuellement. La virtualisation est très proche de concept. 2.2. Machines virtuelles Au milieu des années soixante, IBM effectue des recherches sur les systèmes virtualisés avec le projet M44/44X. L’architecture du système se basait sur des systèmes d’exploitation virtualisés (nommés 44X) s’exécutant au-dessus du matériel (une machine M44). Les systèmes invités étaient
CHAPITRE 2 : Technologie de Virtualisation et de Cloud : Etat de L'art 9 gérés par une simple multiprogrammation. En 1967 est lancé, toujours par IBM, le système CP-40, le premier système offrant une virtualisation complète. Le CP-40 sera suivi par plusieurs évolutions, amenant chacune de nouvelles fonctionnalités pour les utilisateurs. On peut notamment citer Le système VM/370, qui a connu un très fort succès dans les entreprises, et est parfois encore en usage dans certaines entreprises aujourd’hui. 2.3. Amélioration des technologies Après le succès des machines virtuelles introduites par IBM, les technologies ont assez peu évolué. Le système hôte a vite été réduit à l’état de simple arbitre entre les systèmes invités, amenant la notion d’hyperviseur. Toutefois, toutes ces technologies de virtualisation étaient réservées au monde professionnel, destinées à être utilisées sur des mainframes coûtant plusieurs millions de dollars. Parallèlement à cela, le monde de la recherche (souvent financé par ces mêmes entreprises) a continué à étudier différentes possibilités pour améliorer les performances et à essayer de nouvelles technologies. La plupart de ces travaux de recherche sont toutefois restés assez confidentiels et n’ont que rarement été transposés sur un produit.1 2.4. Intérêt du grand public L’orientation « grand public » des technologies de virtualisation est beaucoup plus récente. Dans les années quatre-vingt-dix, l’intérêt pour les émulateurs de consoles de jeu ainsi que l’explosion du marché de l’informatique personnelle (les ordinateurs de type PC) ont fait prendre conscience aux entreprises qu’il y avait un marché pour la virtualisation sur PC. Des sociétés ont alors commencé à créer des produits de virtualisation basés sur des machines virtuelles pour les petites entreprises c’est à dire celles ne pouvant s’offrir des serveurs à plusieurs millions de dollars et pour les particuliers. À partir de ce moment-là, les technologies ont vraiment progressé, avec l’arrivée de nouveaux acteurs toujours prêts à innover pour se démarquer des concurrents. 3. Les types de virtualisations : 3.1. La virtualisation complète : La virtualisation complète (full virtualization), dénommée ainsi par opposition à la para- virtualisation, consiste à émuler l’intégralité d’une machine physique pour le système invité. Le système invité « croit » s’exécuter sur une véritable machine physique. Le logiciel chargé d’émuler cette machine s’appelle une machine virtuelle, son rôle est de transformer les instructions du système invité en instructions pour le système hôte. En effet, la machine virtuelle est un programme comme un autre du point de vue du système hôte, au même titre qu’un navigateur Internet ou un traitement de texte. Or, un système d’exploitation doit normalement manipuler le matériel à un niveau très bas. Les programmes utilisateurs n’ont pas d’accès direct au matériel, mais uniquement aux couches d’abstraction. La machine virtuelle émule donc de manière logique (c’est à dire avec du code) tout le matériel habituel de l’architecture de l’ordinateur cible. Le rectangle en fond vert est le système d’exploitation, seule partie à avoir un accès direct au matériel, ici représenté avec un fond bleu. Le rectangle en fond blanc est une application utilisateur, qui ne peut utiliser que la couche d’abstraction du système d’exploitation pour accéder indirectement au matériel. 1 Alain-B. TCHANA .Système d'Administration Autonome Adaptable: application au Cloud ,novembre 2011
CHAPITRE 2 : Technologie de Virtualisation et de Cloud : Etat de L'art 10 En pratique, le disque dur de la machine virtuelle est la plupart du temps géré comme un (volumineux) fichier pour le système hôte, alors que la mémoire vive dont le système invité dispose est réservée par le programme de la machine virtuelle. Le reste de l’architecture de l’ordinateur peut Varier grandement selon les implémentations, mais on retrouve généralement au moins une carte réseau bas de gamme, un clavier 105 touches « standard » et une carte graphique bas de gamme.2 Figure 2.1 : Virtualisation complète L’utilisation de périphériques bas de gamme s’explique par le fait qu’il y a toujours un nombre minimal d’opérations supportées par toute catégorie de matériel sur un ordinateur : la vitesse de transfert la plus lente pour un disque dur, la résolution d’affichage la plus faible pour une carte graphique, etc. Or comme le comportement de ces périphériques est entièrement implémenté de manière logicielle par la machine virtuelle, émuler un périphérique avec le minimum de fonctionnalités permet de limiter la quantité de code à développer pour en couvrir le comportement. C’est la raison pour laquelle les cartes graphiques et les cartes réseaux sont la plupart du temps aux standards en vigueur dans les années quatre-vingt. Ce n’est toutefois pas la seule raison de l’émulation de périphériques bas de gamme. En effet, la plupart des évolutions ultérieures du matériel visent à améliorer les performances des périphériques, par exemple en augmentant le débit du disque dur ou la résolution supportée par la carte graphique. Cependant, les optimisations de performances sont dans ce cas sans objet, car elles ne se répercutent de toute manière pas sur un matériel physique en mesure de les supporter. La 2 Bhaskar Prasad Rimal, Eunmi Choi, and Ian Lumb. A taxonomy and survey of cloud computing systems. In Proceedings of the 2009 Fifth International Joint Conference on INC, IMS and IDC, NCM '09, pages 44_51, Washington, DC, USA, 2009. IEEE Computer Society.
CHAPITRE 2 : Technologie de Virtualisation et de Cloud : Etat de L'art 11 rapidité du disque dur virtuel est par exemple limitée par la vitesse d’accès au fichier le représentant sur le système hôte. Le système s’exécutant dans la machine virtuelle est un système d’exploitation à part entière, tel qu’on pourrait en installer sur une machine physique : Microsoft Windows, GNU/Linux, Mac OS X, etc. Cette particularité est la caractéristique principale de la virtualisation complète : les systèmes invités n’ont pas à être modifiés pour être utilisés dans une machine virtuelle utilisant une technologie de virtualisation. Dans la pratique, c’est le cas pour les systèmes d’exploitation et les machines virtuelles les plus répandus. Le système invité peut à son tour exécuter n’importe quel programme prévu pour ce système, dans la mesure où il ne nécessite pas de matériel non fourni par la machine virtuelle (i.e. pas de carte graphique dernière génération ou de périphérique peu courant). Cette possibilité est due au fait que le système d’exploitation sert (entre autres) de couche d’abstraction entre le matériel et les applications, donc à partir du moment où le système fonctionne correctement, les applications s’exécutant par-dessus fonctionneront aussi. La traduction au vol des instructions du système invité est néanmoins une opération complexe et coûteuse en temps. En effet, la machine virtuelle ne peut pas, dans la plupart des cas, exécuter directement les instructions du système invité sur le système hôte. Les instructions de manipulation de la RAM, par exemple, doivent être interprétées par la machine virtuelle pour aboutir au résultat attendu, car c’est le processeur de la machine virtuelle qui est censé s’occuper de la gestion physique de la mémoire, et non le processeur de la machine hôte. La machine virtuelle doit donc implémenter en logiciel une gestion complète de la mémoire de l’invité, en utilisant les couches d’abstraction de l’hôte pour accéder à la RAM. Cet empilement de couches réduit significativement les performances, surtout en cas de forte pression sur la mémoire (i.e. quand la mémoire est utilisée de manière in00tensive : lecture, écriture, déplacement de données, etc.). La figure 2.2 détaille les couches d’abstraction entrant en jeu pour la gestion de la mémoire. Dans cette figure, le cadre en bleu foncé représente la couche matérielle ; le cadre vert est le système d’exploitation, qui a un accès privilégié au matériel. Le cadre en fond blanc est une application utilisateur, qui doit utiliser les couches d’abstraction du système d’exploitation représentées en vert foncé pour accéder au matériel. Le cadre bleu ciel représente le matériel émulé par la machine virtuelle, qui doit se comporte comme le matériel réel d’un ordinateur pour le système invité.
CHAPITRE 2 : Technologie de Virtualisation et de Cloud : Etat de L'art 12 Figure 2.2 : Couches d’abstraction pour la gestion de la mémoire Cet empilage de couches est sensiblement identique pour tous les périphériques émulés par la machine virtuelle. On retrouve, du plus bas niveau au plus haut niveau : o Le matériel; o Le pilote du matériel pour le système hôte; o La couche d’abstraction du système hôte; o Le matériel émulé par la machine virtuelle; o Le pilote du matériel pour le système invité; o La couche d’abstraction du système invité. Les performances de la machine virtuelle sont donc limitées par les performances de la couche d’abstraction du système hôte et par la qualité de l’émulation du matériel implémenté. La séparation nette entre la machine virtuelle et le système hôte est un avantage certain pour la sécurité et la stabilité de la machine. En effet, comme la machine virtuelle est un simple programme, on peut très facilement limiter la quantité de mémoire qu’elle peut allouer, le temps processeur consommé, sa priorité par rapport aux autres programmes, etc. Toutes les possibilités d’administration et de configuration des applications offertes par le système hôte s’appliquent à la machine virtuelle. Cela permet par exemple d’attribuer une faible priorité à une machine virtuelle mais de lui permettre de réserver plus de mémoire, alors qu’une autre machine virtuelle aura plus de temps processeur à disposition, mais moins de RAM. Bien évidemment, comme les machines virtuelles sont de simples programmes utilisateurs, on peut en exécuter plusieurs à la fois sur le même système hôte, tant que les ressources sont disponibles. Ainsi, une machine multiprocesseur et disposant de suffisamment de mémoire vive et d’espace de stockage peut aisément accueillir plusieurs machines virtuelles, le système hôte répartissant au mieux la charge entre les différents processeurs.
CHAPITRE 2 : Technologie de Virtualisation et de Cloud : Etat de L'art 13 Cependant du fait de l’empilement de couches d’abstraction et de l’impossibilité pour la machine virtuelle d’accéder directement au matériel, les performances du système invité sont assez éloignées de celles d’un système « natif ». Selon les implémentations, diverses solutions sont utilisées pour accélérer les machines virtuelles, par exemple en passant la plupart des instructions destinées au processeur virtuel directement au processeur physique3 . Cela accélère la vitesse de calcul du système invité. Il reste cependant le problème des Entrées/Sorties (E/S), c’est à dire les accès au disque, à la RAM, à la carte graphique, à la carte réseau, etc. D’une manière générale, on appelle Entrées/Sorties (I/O ou Input/Output) tout ce qui consiste à transférer des informations ou des données entre un périphérique et le système d’exploitation. Les E/S sont beaucoup plus dures à optimiser, car chaque système d’exploitation a une façon propre de gérer cela. Il faut donc cohabiter étroitement à la fois avec le système hôte pour l’accès réel au matériel et avec le système invité pour que ses accès au matériel soient le plus rapide possible. Cela amène une plus grande complexité de code, et une séparation en couches moins marquée que dans le modèle vu sur la figure 2.1. Cette « rupture » dans le modèle en couches est exploitée par une autre technologie de virtualisation : le para virtualisation. 3.2 La paravirtualisation : La para virtualisation (para virtualization ou encore para-virtualization) est très proche du concept de la virtualisation complète, dans le sens où c’est toujours un système d’exploitation complet qui s’exécute sur le matériel émulé par une machine virtuelle, cette dernière s’exécutant au-dessus d’un système hôte. Toutefois, dans une solution de para virtualisation, le système invité est modifié pour être exécuté par la machine virtuelle. Les modifications effectuées visent à rendre le système émulé « au courant » du fait qu’il s’exécute dans une machine virtuelle. De ce fait, il pourra collaborer plus étroitement avec le système hôte, en utilisant une interface spécifique, au lieu d’accéder au matériel virtuel via les couches d’abstraction. Au final, l’architecture obtenue est plus performante que l’empilement de couches d’abstraction de la figure 2.2. Le terme para-virtualisation a été mentionné pour la première fois dans [WSG02], où les auteurs définissent la para virtualisation comme la modification sélective de certaines parties de l’architecture virtuelle pour améliorer les performances, la réactivité sous forte charge et la simplicité de conception. L’idée du para virtualisation est toutefois plus ancienne que cela. Les premiers gros systèmes utilisant une architecture de virtualisation avaient déjà une technologie similaire, dès les années soixante-dix, même si elle n’avait pas de nom. En pratique, un système paravirtualisé possède quelques pilotes de périphériques et sous- systèmes modifiés, qui lui permettent de communiquer directement avec la machine virtuelle, sans avoir passé par une couche d’abstraction pour parler au matériel virtuel. Les pilotes para virtualisés échangent directement des données avec la machine virtuelle, sans avoir à passer par une émulation du comportement du matériel. Les parties du système hôte généralement modifiées pour tirer profit de la para virtualisation sont la gestion de la mémoire et la gestion des E/S. En effet, ce sont véritablement les deux goulets d’étranglement d’un système virtualisé, du fait du nombre de couches d’abstraction à traverser. Il est donc logique que les optimisations se portent là-dessus. La figure 2.3 montre la structure d’une machine virtuelle et d’un système hôte supportant le para virtualisation. Les pilotes non modifiés interagissent toujours avec le matériel émulé par la machine virtuelle (rectangle bleu ciel), alors que les pilotes modifiés communiquent directement les fonctions de la machine virtuelle (rectangle jaune)4 . La simplification qui en résulte communique 3 EuroCloud France. L'évolution maitrisée vers l’IaaS/PaaS. novembre 2011 4 Ignacio M. LlorenteBorja Sotomayor, Ruben S. Montero and Ian Foster
CHAPITRE 2 : Technologie de Virtualisation et de Cloud : Etat de L'art 14 presque directement avec le système hôte, en contournant les couches d’abstraction virtuelles (i.e. le matériel émulé). Le reste de l’architecture est inchangé, la machine virtuelle est toujours une application utilisateur (rectangle blanc) et le système d’exploitation (rectangle vert) est toujours le seul à avoir un accès privilégié au matériel (rectangle bleu). Figure 2.3 : Paravirtualisation Les détails sur comment sont réalisées ces optimisations varient selon les implémentations, mais il s’agit en général pour le système invité d’utiliser des appels systèmes ou des instructions spécifiques pour renseigner la machine virtuelle sur les actions à entreprendre. Cette dernière réalise alors ces actions, et communique le résultat au système invité. Le type d’actions à effectuer varie également selon les implémentations, mais on retrouve en général tout ce qui est déplacement de données entre l’hôte et l’invité (accès disque, transfert réseau, etc.) et gestion de la mémoire. La paravirtualisation apporte un gain de performances avéré, du fait du contournement des couches d’abstraction. En effet, comme le système invité collabore activement avec la machine virtuelle, il ne se comporte plus comme un système d’exploitation à part entière s’exécutant directement sur du matériel. Au contraire, il adapte son comportement pour que les accès au matériel souvent difficiles à interpréter de manière efficace par la machine virtuelle soient transformés en des appels directs à cette dernière. De plus, étant donné que seules les couches de bas niveau du système invité ont été modifiées, toutes les applications qui pouvaient fonctionner dans une architecture de virtualisation complète peuvent aussi être utilisées dans une architecture paravirtualisée. Toutefois, cette augmentation des performances est restreinte à certains systèmes. En effet, comme le système invité doit être modifié pour être paravirtualisé, il faut bien évidemment que l’on ait la possibilité de réaliser cette opération de portage. Or, cela nécessite à la fois l’accès au code source du système d’exploitation et la permission du détenteur des droits de le modifier. Si cela ne pose aucun problème pour un système libre (notamment GNU/Linux et les systèmes BSD), il n’en va pas de même pour les systèmes propriétaires, tels que Microsoft Windows et Mac OS. L’usage de la paravirtualisation est donc généralement limité aux systèmes libres, sauf à utiliser une solution de
CHAPITRE 2 : Technologie de Virtualisation et de Cloud : Etat de L'art 15 virtualisation propriétaire compatible avec un seul système d’exploitation invité, comme les produits que Microsoft propose pour ses systèmes d’exploitation. Tout comme la virtualisation complète, la paravirtualisation garde une séparation nette entre le système invité et le système hôte (cf. figures 2.1 et 2.3). De ce fait, seul le système hôte a un accès direct et exclusif au matériel. Le système invité doit donc toujours passer par la machine virtuelle pour accéder au matériel, qui passe à son tour par la couche d’abstraction. On peut donc améliorer davantage le processus en laissant au système invité un accès direct mais contrôlé au matériel. C’est le but des systèmes à hyperviseur 3.3 Virtualisation matérielle : L’utilisation d’un hyperviseur (hypervisor) est en quelque sorte l’évolution logique de la paravirtualisation, si l’on recherche encore une amélioration des performances. Dans les technologies précédentes, le système hôte était le seul à avoir un accès direct au matériel; avec un hyperviseur, le système hôte partage cet accès avec les systèmes invités. Au démarrage de l’ordinateur, c’est normalement le système d’exploitation qui prend la main et contrôle le matériel. Dans le cas de l’utilisation d’un hyperviseur, c’est un système minimaliste — l’hyperviseur — qui prend le contrôle du matériel. Ensuite, il fait appel à un système d’exploitation complet, qui sera donc exécuté par- dessus l’hyperviseur. Ainsi, le système d’exploitation doit passer par l’hyperviseur pour tout accès au matériel. On peut donc très facilement instancier un deuxième système d’exploitation, qui passera lui aussi par l’hyperviseur pour l’accès au matériel. Comme les systèmes d’exploitation doivent obligatoirement passer par ce dernier pour tout accès au matériel, l’hyperviseur peut s’assurer qu’ils n’accèdent qu’aux ressources autorisées, sans perturber le fonctionnement des autres systèmes. Figure 2.4 : Hyperviseur
CHAPITRE 2 : Technologie de Virtualisation et de Cloud : Etat de L'art 16 La figure 2.4 détaille le principe de fonctionnement de l’hyperviseur. À la différence des technologies exposées précédemment, il n’y a cette fois pas d’accès direct au matériel (rectangle bleu) pour le système d’exploitation, uniquement une couche d’abstraction minimale fournie par l’hyperviseur (rectangle vert). L’hyperviseur est le seul à avoir un accès privilégié au matériel. Dans cette représentation, les systèmes cohabitent au même niveau de privilège, uniquement régulés par l’hyperviseur. Toutefois, selon les implémentations, il y a souvent un système privilégié, qui est en général le premier système démarré par l’hyperviseur. Ce système est alors autorisé à modifier les paramètres de l’hyperviseur ou à instancier de nouveaux systèmes invités. À l’opposé, sur d’autres implémentations, la différence entre hôte et invité est inexistante, tous les systèmes ont les mêmes privilèges et l’hyperviseur est alors contrôlé d’une autre manière. Si les deux technologies vues précédemment (virtualisation complète et paravirtualisation) utilisaient une machine virtuelle pour émuler le matériel, il n’en va pas de même avec un hyperviseur. Chaque système d’exploitation a un accès presque direct au matériel, par l’intermédiaire de l’hyperviseur. Il n’y a donc plus de couche d’abstraction logicielle, le matériel accessible est celui de la machine physique, avec toutes les fonctionnalités qu’il peut offrir. Le gain de performances est parfois significatif, notamment dans le cas des E/S, où le système peut utiliser toutes les extensions des périphériques pour accélérer les transferts. Ressources, alors que dans un système d’exploitation, on s’assurera qu’un programme utilisateur ne dérange pas les autres programmes du système. Au final, le contrôle des priorités est plus précis, et permet de garantir qu’un système invité isolé n’influera jamais sur l’accès aux ressources d’un autre système. Avec une architecture à base de virtualisation complète, si le système hôte est monopolisé par un processus utilisateur (par exemple un programme consommant énormément de mémoire), les systèmes invités peuvent se voir fortement ralentis dans leur activité. Tous les systèmes destinés à s’exécuter au-dessus d’un hyperviseur doivent être portés, comme les systèmes invités pour la paravirtualisation. Cette opération vise à adapter les couches bas niveau du système d’exploitation pour qu’elles communiquent avec l’hyperviseur plutôt qu’avec le matériel. Les inconvénients sont donc les mêmes que pour la paravirtualisation : il est nécessaire d’avoir accès au code source de tous les systèmes ainsi que l’autorisation du détenteur des droits. En outre, le portage est beaucoup plus lourd à réaliser pour fonctionner sur un hyperviseur. En effet, pour la paravirtualisation, seuls quelques pilotes et sous-systèmes avaient besoin d’être réécrits pour tirer parti de l’accélération. Au contraire, un hyperviseur nécessite la modification de toutes les couches d’accès au matériel; la complexité du code s’en trouve grandement augmentée, augmentant par là même la difficulté de maintenir le code. Le portage sur un hyperviseur revient quasiment à porter le système d’exploitation sur une nouvelle architecture matérielle. Les techniques vues jusqu’à présent étaient de complexité croissante, c’est à dire que chaque technologie était un peu plus complexe à mettre en œuvre et à que la précédente. Avec les technologies ayant trait au cloisonnement, c’est différent. En effet, le cloisonnement était au départ utilisé pour sécuriser et isoler des applications, sans rapport avec le fait d’isoler des systèmes d’exploitation, c’est seulement récemment que l’idée d’utiliser ces techniques pour la virtualisation a vu le jour. 4. Techniques de virtualisation : 4.1. L’Isolation et Le Cloisonnement : Une autre pratique répandue dans le domaine de la virtualisation est le cloisonnement. Derrière ce nom se cachent plusieurs technologies visant à séparer fortement les processus s’exécutant sur un même système d’exploitation. Le cloisonnement vise à isoler chaque processus
CHAPITRE 2 : Technologie de Virtualisation et de Cloud : Etat de L'art 17 dans un conteneur dont il est théoriquement impossible de sortir. Un processus isolé de la sorte ne saura pas quels autres processus s’exécutent sur le même système, et n’aura qu’une vision limitée de son environnement. Le but principal de cette technologie est d’améliorer la sécurité du système d’exploitation et des applications. Isolé. Par exemple, si le système hôte est Solaris, alors tous les processus s’exécutant à l’intérieur d’une zone auront accès à la même version de ce Solaris. Les technologies de cloisonnement sont aussi utilisées dans d’autres domaines que les systèmes d’exploitation. Par exemple, le langage Java (de Sun Microsystems) propose une machine virtuelle (qui n’a rien à voir avec les machines virtuelles étudiées ici) qui est un interpréteur pour le langage Java. Cet interpréteur exécute tous les programmes Java dans un conteneur isolé, dont ils ne peuvent pas sortir. Le terme utilisé pour décrire cette technologie est sandbox (bac à sable). Le sandboxing est aussi une technologie de cloisonnement, mais au niveau d’un processus, sans que le système intervienne. Même si l’engouement pour la virtualisation est assez récent, les technologies de virtualisation et l’idée même de la virtualisation sont presque aussi anciennes que l’informatique. La section suivante fera un bref historique de la virtualisation. III. Technologie de Cloud Computing : 1. Technologie de Datacenter : Le datacenter ou centre de données informatique est le site physique où sont regroupées les différentes infrastructures, comme les baies de serveurs et de stockage. Ces sites de production informatique, équipés de systèmes d’alimentation et de refroidissement, hébergent les applications et données des entreprises, ou des particuliers dans le cadre de la mise à disposition de services applicatifs comme la messagerie ou le stockage de données dans le Cloud. Les géants du Cloud, les hébergeurs et les opérateurs disposent tous de multiples datacenters, plus ou moins grands. L’efficacité énergétique de ces datacenters est notamment mesurée grâce à un indicateur, le PUE. Pour des raisons de consommation d’énergie et environnementales, les opérateurs de datacenters s’efforcent d’atteindre un PUE le plus bas possible. Une des tendances du moment dans le datacenter porte sur les technologies de convergence et d'hyper-convergence. Et le mouvement de convergence entre les couches réseau, stockage et calcul ne s'arrête plus à l'échelle du rack. Il touche le centre de données, et permet l'automatisation et l'orchestration des ressources informatiques, via l'utilisation par la DSI d'outils software defined 2. Historique du Cloud Computing : Le Cloud computing est un concept assez récent. Sa première énonciation date de 1960 (John McCarthy), mais sa réelle mise en application a commencé au début des années 2000. Salesforce.com fut le premier hébergeur de Cloud en 1999, suivi en 2002 par Amazon. Le Cloud Computing met en œuvre l'idée de l’informatique utilitaire du type service public, proposée par John McCarthy en 1961 qui suggère que la technologie informatique partagée pourrait construire un bel avenir dans lequel la puissance de calcul et même les applications spécifiques pourraient être vendues comme un service public.
CHAPITRE 2 : Technologie de Virtualisation et de Cloud : Etat de L'art 18 L’apparition du Cloud Computing vient d'une évolution de certaines technologies telles que la virtualisation du matériel informatique, les services web, ou l'architecture orientée services SOA (Service Oriented Architecture). La virtualisation a été la première pierre de l'ère du Cloud Computing. En effet, cette notion permet d'optimiser les ressources matérielles en les partageants entre plusieurs environnements dans le but De pouvoir exécuter plusieurs systèmes « virtuels » sur une seule ressource physique et fournir une couche supplémentaire d’abstraction du matériel. Le Cloud computing est donc la juxtaposition de ces technologies pour passer à la vitesse supérieure sur l’exploitation de données à travers Internet. 3. Bénéfices du cloud Computing : 3.1. Pour le fournisseur : • Aucun investissement préalable. • Service d'une grande disponibilité. • Facturation à la consommation. • Version toujours à jour et identique pour tous les utilisateurs (cas du SaaS). • Architecture sur mesure adaptable selon les besoins. 3.2. Pour l'entreprise : • La sécurité des données • La réduction des coûts • Une parfaite adaptation aux besoins métiers des entreprises • Une prise en charge optimale de l’infrastructure informatique • Une technologie flexible et évolutive IV. Les différents services : Nous parlons généralement de 3 services que nous utilisons différemment selon nos besoins. Certains appellent ces services les couches de cloud et nous les représentons souvent sous forme d’une pyramide comme la montre
CHAPITRE 2 : Technologie de Virtualisation et de Cloud : Etat de L'art 19 Figure2.5 : Les services de 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 installer 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 applications 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. V. Types et Modèles de déploiement de cloud : Nous distinguons quatre modèles de déploiement qui n’ont pas une grande influence sur les systèmes déployés 5 • Cloud public: C’est le cloud dans le sens traditionnel où les services sont offerts au grand public 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 5 JunjiePeng, Xuejun Zhang, Zhou Lei, Bofeng Zhang, Wu Zhang, and Qing Li. Comparison of several Cloud computing plateforms. In Proceedings of the 2009 Second International Symposium on Information Science and Engineering, ISISE '09, pages 23_27, Washington, DC, USA, 2009. IEEE Computer Society.
CHAPITRE 2 : Technologie de Virtualisation et de Cloud : Etat de L'art 20 • 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 VI. Les solutions de cloud : 1. Eucalyptus : Eucalyptus est un outil open source issu d’un projet de recherche de l’université de Californie. Il est développé en C, Java, Python et est disponible sous deux licences. Une licence GPL gratuite supportant les hyperviseurs Xen et KVM et une licence commerciale offrant des fonctionnalités avancées telles que le support de VMware. Il permet de construire aussi bien les solutions privées du cloud computing que les solutions publiques. Son grand avantage est qu’il est intégré dans les distributions Ubuntu et Debian. Eucalyptus offre des interfaces compatibles avec les services EC2 d’Amazon. Ce qui lui confère la possibilité d’être employé pour les solutions hybrides de cloud computing. L’architecture d’Eucalyptus est constituée de quatre composants principaux (Nurmi et al, 2008 ; Alrwais, 2011). • Le contrôleur de nœud (Node controller NC) : contrôle l’exécution, et l’arrêt des machines virtuelles présentes sur le nœud où il est exécuté. • Le contrôleur de cluster (cluster controller CC) : collecte les informations sur les différents nœuds d’un cluster et planifie l’exécution des machines virtuelles sur chaque nœud. Le contrôleur de stockage (Warlus) : c’est le composant qui gère l’accès au service de stockage. Il est souvent intégré au contrôleur du cloud (CLC). • Le contrôleur de cloud (CLC): C’est le point d’entrée (Front end) des utilisateurs et administrateurs du système. Il collecte des informations sur les nœuds et planifie leur exécution au travers des contrôleurs de clusters (CCs). Il expose les services du cloud à travers une application Web mais également à travers des interfaces compatibles EC2. 2. OpenNebula OpenNebula, purement open source permet de déployer des Cloud privés, hybrides et publics. Ecrite en C++, Ruby et Shell, elle supporte les plateformes de virtualisation Xen, KVM et VMware ainsi que le service “on-demand” d’Amazon EC2. Le projet est publié sous licence Apache 2.0. Parmi ses fonctionnalités : gestion centralisée des machines virtuelles et des ressources physiques, répartition des charges, extension des capacités par ajout de serveurs physiques. Beaucoup de ces solutions sont avant tout des solutions d’infrastructure permettant une gestion simplifiée d’architectures matérielles complexes.
CHAPITRE 2 : Technologie de Virtualisation et de Cloud : Etat de L'art 21 3. OpenStack Il est né de la fusion de deux projets portés l’un par la Nasa et l’autre issu de l’offre de l’hébergeur américain Rackspace Cloud Server. L’ensemble de la plateforme est disponible sous licence Apache 2.0. OpenStack est un logiciel libre qui permet la construction de Cloud privé et public. Il est aussi une communauté et un projet en plus d'un logiciel qui a pour but d'aider les organisations à mettre en œuvre un système de serveur et de stockage virtuel. Il s'installe sur un système d'exploitation libre comme Ubuntu ou Debian et se configure entièrement en ligne de commande. C'est un système robuste et qui a fait ses preuves auprès des professionnels du domaine. En comparaison avec les autres produits, OpenStack semble avoir la plus grande et la plus active communauté. Les membres de la communauté sont toujours prêts à aider les autres à trouver des solutions aux problèmes qui se posent. La technologie est populaire parmi une vaste communauté de spécialistes et est soutenue par des sociétés telles que Cisco, Dell, NASA, Intel, AMD, Citrix, Rackspace, et RightScale.  Les caractéristiques principales d’OpenStack sont les suivantes : • Capacité à gérer les ressources du serveur de produits virtualisés. • Capacité à gérer des réseaux locaux. • Gestion de l'image de la machine virtuelle. • Groupes de sécurité. • Contrôle d'accès basé sur les rôles. • VNC proxy via un navigateur Web.
CHAPITRE 3
CHAPITRE 3 : Etude comparative et choix de la solution 22 I. Introduction : Avant toute chose, rappelons ce qu'est la virtualisation : la virtualisation est une couche d'abstraction informatique qui permet de faire fonctionner plusieurs serveurs, systèmes ou applications sur un même serveur physique (tout dépend du type de virtualisation choisie) La virtualisation a donc permis par ce processus d'ouvrir de nombreuses portes, et constitue la pierre angulaire du Cloud1 . En effet, elle représente donc une formidable ouverture à différents niveaux : utilisateurs, entreprises, services IT... Les avantages sont nombreux : en termes économiques (moins coûteux), de centralisation, de sécurité et de partage de données, en termes de performances (virtualisation applicative/de bureau) etc... Il est également important de comprendre la notion d'hyperviseur et d'hyperviseur de type 1 et 2. Tout d'abord, un hyperviseur est cette fameuse couche d'abstraction qui rend possible la virtualisation : il permet à plusieurs systèmes d'exploitation (OS) de fonctionner simultanément sur une même machine physique. L'hyperviseur de type 1 (natif) s'exécute directement sur la plateforme matérielle alors qu'un hyperviseur de type 2 (hosté) s'exécute à l'intérieur d'un même système d'exploitation. Un hyperviseur héberge des machines virtuelles (VM), qui sont le "résultat" de la virtualisation et ce à partir de quoi on travaille. Il existe différents types de virtualisation (attention ce n'est pas la même chose que le type d'hyperviseur) donc différentes "natures" de VM, qui nécessitent chacune une solution spécifique (n'importe quelle solution ne peut virtualiser n'importe quoi): - La virtualisation de bureau, - La virtualisation d’applicative, - La virtualisation de de réseau, - La virtualisation de de stockage, Etc... II. Solutions de Virtualisation : Le marché des solutions de virtualisation est un marché extrêmement concurrentiel. Parmi les principaux acteurs composant ce marché, nous détaillerons les offres des trois principaux éditeurs, à savoir VMware, Citrix et Microsoft. VMware est le plus vieux et le plus gros éditeur sur le marché de la virtualisation, filiale du groupe EMC et fondée en 1998, cette compagnie propose une gamme de produits et services complète associée à la virtualisation2 . 1 Le cloud computing une nouvelle filière fortement structurante,septembre2012 2 Marvin Rambhadjan and Arthur Schutijser. SURFnet cloud computing solutions.
CHAPITRE 3 : Etude comparative et choix de la solution 23 Pour mettre en place notre plateforme de virtualisation, nous avons choisi la solution VMware qui est le leader du marché dans le domaine. 1. VMware (vSphere, ESXi...) : 1.1. VMware vSphere : VMware vSphere gère de grandes collections d'infrastructure (par exemple des processeurs, le stockage et la gestion de réseau) sous la forme d'un environnement d'exploitation transparent et dynamique, ainsi que la complexité d'un centre de données. La pile logicielle VMware vSphere est constituée des couches de virtualisation, de gestion et d'interfaces. Figure 3.1 : Relations entre les couches de composants de VMware vSphere • Couche de virtualisation : La couche de virtualisation de VMware vSphere inclut des services d'infrastructure et d'application. L'infrastructure fournit, entre autres, les services de traitement et de stockage et les services réseau extraient, agrègent et allouent les
CHAPITRE 3 : Etude comparative et choix de la solution 24 ressources matérielles ou d'infrastructure. Les services d'infrastructure comprennent les types suivants : • Services de traitement : Inclut les fonctions VMware qui permettent de ne pas tenir compte des ressources serveur hétérogènes sous-jacentes. Les services de traitement agrègent ces ressources sur un grand nombre de serveurs discrets les affectent aux applications. • Services de stockage : Il s'agit de l'ensemble de technologies qui permettent d'utiliser et de gérer efficacement le stockage dans les environnements virtuels. • Services de réseau : Il s'agit de l'ensemble de technologies qui simplifient et améliorent la gestion de réseau dans les environnements virtuels. • Couche de gestion : VMware vCenter Server est le point central de la configuration, du provisionnement et de la gestion des environnements informatiques virtualisés. • Couche d'interfaces : Les utilisateurs peuvent accéder au centre de données VMware vSphere via des clients à interface graphique, tels que vSphere Client ou vSphere Web Client. En outre, ils peuvent accéder au centre de données via des machines clientes qui utilisent des interfaces de ligne de commande et des kits SDK pour la gestion automatique. 1.2 Composants et fonctionnalités : VMware vSphere Une présentation des composants et fonctions de VMware vSphere explique les composants et leurs interactions. VMware vSphere inclut les composants et fonctions suivants : • VMware ESXi : Une couche de virtualisation fonctionne sur des serveurs physiques qui analysent le processeur, la mémoire, le stockage et les ressources dans les machines virtuelles multiples Figure 3.2 : VMware ESXI
CHAPITRE 3 : Etude comparative et choix de la solution 25 • VMware vSphere Client : Une interface permettant aux utilisateurs de se connecter à distance vCenter Server ou ESXi depuis n'importe quel PC Windows Figure 3.3 : VMware vSphere Client • VMware vSphere Web Client : Une interface Web permet aux utilisateurs de se connecter à distance à vCenter Server depuis divers navigateurs Web et systèmes d'exploitation.
CHAPITRE 3 : Etude comparative et choix de la solution 26 Figure 3.4 : VMware vSphere Web Client • VMware vCenter Server : Le point central pour configurer, approvisionner et gérer des environnements informatiques virtualisés. Il fournit les services essentiels du centre de données : contrôle d'accès, surveillance des performances et • Gestion des alarmes.
CHAPITRE 3 : Etude comparative et choix de la solution 27 Figure 3.5 : VMware VCenter Server • VSphere vMotion : Permet de migrer des machines virtuelles sous tension depuis un serveur physique vers un autre sans interruption avec une disponibilité de service continue et une intégrité de transaction complète . Figure 3.6 : vSphere vMotion • VSphere Storage vMotion : Permet de migrer des fichiers de machine virtuelle d'une banque de données vers une autre sans interruption de service. Vous placez la machine virtuelle et tous ses disques dans un seul emplacement ou sélectionnez des emplacements distincts pour le fichier de configuration de la machine virtuelle et chaque disque virtuel. La machine virtuelle reste sur le même hôte pendant Storage vMotion. La migration avec Storage vMotion permet de transférer les disques virtuels ou le fichier de configuration d'une machine virtuelle vers une nouvelle banque de données alors que la machine
CHAPITRE 3 : Etude comparative et choix de la solution 28 virtuelle s'exécute. La migration avec Storage vMotion permet de transférer le stockage d'une machine virtuelle sans interrompre la disponibilité de la machine virtuelle3 . Figure 3.7 : vSphere Storage vMotion • VSphere High Availability (HA) : Fonction qui offre une haute disponibilité pour les machines virtuelles. En cas de panne d'un serveur, les machines virtuelles affectées sont redémarrées sur d'autres serveurs disponibles ayant une capacité disponible. 3 Peter Sempolinski and Douglas Thain. A comparison and critique of eucalyptus, opennebula and nimbus. In Proceedings of the 2010 IEEE Second International Conference on Cloud Computing Technology and Science , CLOUDCOM '10, pages 417_426, Washington, DC, USA, 2010. IEEE Computer Society.
CHAPITRE 3 : Etude comparative et choix de la solution 29 Figure 3.8 : vSphere High Availability (HA) • VSphere Fault Tolerance : Assure la disponibilité permanente en protégeant une machine virtuelle avec une copie. Lorsque cette fonction est activée pour une machine virtuelle, une seconde copie de la machine d'origine (ou principale) est créée. Toutes les actions effectuées sur la machine virtuelle primaire sont également effectuées sur la seconde machine virtuelle. Si la machine virtuelle principale devient indisponible, la seconde machine devient active immédiatement.
CHAPITRE 3 : Etude comparative et choix de la solution 30 Figure 3.9 : vSphere Fault Tolerance 2. Citrix (Xenserver...) : • Citrix XenServer est une solution de virtualisation qui permet de déployer rapidement et simplement des machines virtuelles Windows et Linux hautes performances. • Xenservers’appuie sur l’hyperviseur open source Xen qui installe une fine couche logicielle sur le matériel de la machine nue, ce qui lui rend plus rapide et plus sûre par rapport aux autres hyperviseurs. Il s’appuie en outre sur les toutes dernières solutions Intel VT et AMD-V de virtualisation assistée par matériel. • XenServer permet en outre de gérer ces machines et les ressources réseau et de stockage qui leur sont associées à partir d’une console de gestion unique et très simple d’emploi. • La technologie XenServer s’appuie sur les toutes dernières solutions Intel VT et AMD-V de virtualisation assistée par matériel. L’hyperviseur Xen est exceptionnellement léger (moins de 50 000 lignes de code), ce qui se traduit pour l’hôte par une charge extrêmement faible et des performances quasi natives. • Citrix XenServer est performant et sécuritaire. Sa technologie et ouverte aux capacités de gestion étendues de XenCenter qui constitue une plateforme de virtualisation idéale, parfaitement adaptée à la consolidation des serveurs, au développement et au test de logiciels et aux projets de continuité de service.
CHAPITRE 3 : Etude comparative et choix de la solution 31 Figure 3.10 : Xen server architecture 2.1 Composants et fonctions : 2.1.1 . Composants principaux : Cette illustration affiche les composants principaux d’un déploiement typique, qui est appelé un site. Figure 3.11 : les composants principaux d’un déploiement typique
CHAPITRE 3 : Etude comparative et choix de la solution 32 • Delivery Controller : Delivery Controller est le composant de gestion centralisée d’un site. Chaque site possède un ou plusieurs Delivery Controller. Il est installé sur au moins un serveur dans le centre de données. Pour la fiabilité et la disponibilité du site, installez des Controller sur plusieurs serveurs4 . Si votre déploiement comprend un hyperviseur ou un service de cloud, les services Controller communiquent avec lui pour distribuer des applications et des bureaux, s’authentifier et gérer l’accès des utilisateurs, négocier des connexions entre les utilisateurs et leurs applications et bureaux, optimiser l’utilisation des connexions et équilibrer la charge de ces connexions. Le service broker du Controller contrôle quels utilisateurs sont connectés et depuis quel endroit, quelles ressources de session les utilisateurs possèdent-ils et si les utilisateurs doivent se reconnecter aux applications existantes. Le service broker exécute des applets de commande PowerShell et communique avec l’agent broker situé sur les VDA via le port TCP 80. Il n’est pas possible d’utiliser le port TCP 4435 . Monitor Service collecte les données historiques et les places dans la base de données de contrôle. Ce service utilise le port TCP 80 ou 443. Les données provenant des services Controller sont stockées dans la base de données du site. Le Controller gère l’état des bureaux, les démarre ou les arrête à la demande et en fonction de la configuration de l’administration. Dans certaines éditions, le Controller permet d’installer Profile Management pour gérer les paramètres de personnalisation des utilisateurs dans des environnements Windows physiques ou virtualisés. • Base de données : Au moins une base de données Microsoft SQL Server est requise pour chaque site pour stocker toutes les informations de configuration et de session. Cette base de données stocke les données collectées et gérés par les services qui constituent le Controller. Installez la base de données dans votre centre de données et assurez-vous qu’elle possède une connexion permanente au Controller. Le site utilise également une base de données de journalisation de la configuration et une base de données de contrôle. Par défaut, ces bases de données sont installées dans le même emplacement que la base de données du site, mais vous pouvez modifier ce paramètre. • Virtual Delivery Agent (VDA) : Le VDA est installé sur chaque machine physique ou virtuelle de votre site que vous mettez à disposition des utilisateurs. Ces machines fournissent des applications ou des postes de travail. Le VDA permet aux machines de s’enregistrer auprès du Controller, qui permet à la machine et aux ressources qu’elle héberge d’être mise à la disposition des utilisateurs. Les VDA établissent et gèrent la connexion entre la machine et l’appareil de l’utilisateur6 . Les VDA vérifient également qu’une 4 ThiagoDamascenoCordeiro, Douglas BritoDamalio, NadilmaCintra 5 Vivansas.p.r.l.Cloud Computing Enjeux, Perspectives et Impacts métiers ,septempre 2009 6 WygwanLe Cloud Computing : Réelle révolution ou simple évolution ? Webographie
CHAPITRE 3 : Etude comparative et choix de la solution 33 licence Citrix est disponible pour l’utilisateur ou la session et appliquent les stratégies configurées pour la session. Le VDA communique des informations de session au service Broker dans le Controller via l’agent Broker dans le VDA. L’agent broker héberge de multiples plug-ins et collecte des données en temps réel. Il communique avec le Controller sur le port TCP 80. Le mot « VDA » est souvent utilisé pour faire référence à l’agent ainsi qu’à la machine sur laquelle il est installé. Les VDA sont disponibles pour les systèmes d’exploitation Windows mono-session et multi- session. Les VDA pour les systèmes d’exploitation multi-session Windows autorisent plusieurs utilisateurs à se connecter au serveur à un moment donné. Les VDA pour les systèmes d’exploitation mono-session Windows ne permettent qu’à un seul utilisateur de se connecter au bureau à la fois. Les VDA Linux sont également disponibles. • Citrix StoreFront : StoreFront authentifie les utilisateurs et gère les magasins de bureaux et d’applications auxquels les utilisateurs accèdent. Il peut héberger votre magasin d’applications d’entreprise qui fournit aux utilisateurs un accès en libre-service aux bureaux et aux applications que vous mettez à leur disposition. Il assure également le suivi des abonnements aux applications des utilisateurs, des noms de raccourcis et d’autres données. Cela permet de garantir que les utilisateurs ont une expérience cohérente sur plusieurs appareils. • Application Citrix Workspace : Installée sur les machines utilisateur et autres points de terminaison, tels que les bureaux virtuels, l’application Citrix Workspace offre aux utilisateurs un accès en libre-service, rapide et sécurisé aux documents, applications et bureaux. L’application Citrix Workspace offre également un accès à la demande aux applications Windows, Web et Saas (Software as a Service). Pour les périphériques qui ne peuvent pas installer le logiciel de l’application Citrix Workspace spécifique au périphérique, l’application Citrix Workspace pour HTML5 offre une connexion via un navigateur Web compatible HTML5. • Citrix Studio : Studio est la console de gestion où vous configurez et gérez votre déploiement Citrix Virtual Apps and Desktops. Studio élimine le besoin de consoles de gestion distinctes pour gérer la mise à disposition des applications et des postes de travail. Studio offre des assistants pour vous guider dans le processus de configuration de votre environnement, créer des charges de travail pour héberger les applications et bureaux, et attribuer des applications et des bureaux aux utilisateurs. Vous pouvez également utiliser Studio pour allouer et suivre les licences Citrix pour votre site. Studio obtient les informations qu’il affiche à partir du Broker Service dans le Controller, communiquant via le port TCP 80. Voici un aperçu de Studio :
CHAPITRE 3 : Etude comparative et choix de la solution 34 Figure 3.12 : Citrix Studio • Citrix Director : Director est un outil Web qui permet aux équipes d’assistance informatique de surveiller un environnement, de résoudre les problèmes avant qu’ils ne deviennent critiques et de réaliser des tâches d’assistance pour les utilisateurs finaux. Vous pouvez utiliser un déploiement de Director pour vous connecter à et contrôler plusieurs sites Citrix Virtual Apps ou Citrix Virtual Desktops. Director affiche les éléments suivants :  Données de session en temps réel à partir du Broker Service dans le Controller, qui comprennent des données que le service Broker obtient depuis l’agent broker dans le VDA.  Données de site historiques provenant du service Monitoring dans le Controller. Director utilise les données de performances et heuristiques ICA capturées par l’appareil Citrix Gateway pour créer des analyses à partir des données, puis les présenter aux administrateurs. Vous pouvez également afficher et interagir avec les sessions d’un utilisateur via Director, à l’aide de l’Assistance à distance Windows. • Serveur de licences Citrix : Le serveur de licences gère les licences de vos produits Citrix. Il communique avec le Controller pour gérer les licences pour chaque session utilisateur et avec Studio pour allouer les fichiers de licences. Un site doit avoir au moins un serveur de licences pour stocker et gérer vos fichiers de licences. • Hyperviseur ou service de cloud : L’hyperviseur ou le service de cloud héberge les machines virtuelles de votre site. Il peut s’agir des machines virtuelles que vous utilisez pour héberger les applications et les bureaux, ainsi
CHAPITRE 3 : Etude comparative et choix de la solution 35 que les machines virtuelles que vous utilisez pour héberger les composants de Citrix Virtual Apps and Desktops. Un hyperviseur est installé sur un ordinateur hôte entièrement dédié à l’exécution de l’hyperviseur et l’hébergement des machines virtuelles. Les solutions Citrix Virtual Apps and Desktops prennent en charge divers hyperviseurs et services cloud. Bien que de nombreux déploiements requièrent un hyperviseur, vous n’en avez pas besoin pour fournir un accès PC distant. De même, un hyperviseur n’est pas requis lorsque vous utilisez Provisioning Services (PVS) pour provisionner des machines virtuelles. Pour plus d’informations, consultez : • Ports réseau. • Bases de données. • Services Windows des composants de Citrix Virtual Apps and Desktops : Configurer les droits des utilisateurs. • Hyperviseurs et services de cloud pris en charge : Configuration système requise. 2.1.2 . Composants supplémentaires : Les composants supplémentaires suivants, non affichés dans le diagramme ci-dessus, peuvent également être inclus dans les déploiements Citrix Virtual Apps and Desktops. Pour de plus amples informations, consultez leur documentation respective. • Citrix Provisioning : Citrix Provisioning (anciennement Provisioning Services) est un composant facultatif disponible avec certaines éditions. Il offre une alternative à MCS pour le provisioning des machines virtuelles. Alors que MCS permet de créer des copies d’une image principale, PVS livre l’image principale en streaming vers les machines utilisateur. PVS ne nécessite pas d’hyperviseur pour effectuer cette opération, vous pouvez donc l’utiliser pour héberger des machines physiques. PVS communique avec le Controller afin de fournir aux utilisateurs des ressources. • Citrix Gateway : Lorsque les utilisateurs se connectent en dehors du pare-feu d’entreprise, Citrix Virtual Apps and Desktops peut utiliser la technologie Citrix Gateway (anciennement Access Gateway et NetScaler Gateway) pour sécuriser les connexions avec le protocole TLS. L’Appliance virtuelle Citrix Gateway ou VPX est une appliance SSL VPN déployée dans la zone démilitarisée (DMZ). Il fournit un point d’accès sécurisé unique via le pare-feu d’entreprise. • Citrix SD-WAN : Dans les déploiements dans lesquels des bureaux virtuels sont mis à disposition auprès des utilisateurs dans des emplacements distants, des succursales par exemple, la technologie Citrix SD- WAN peut être utilisée pour optimiser les performances. Les répéteurs accélèrent les performances sur les réseaux étendus. Avec les répéteurs, les utilisateurs des succursales bénéficient des performances d’un réseau local sur le réseau étendu. Citrix SD-WAN permet de définir des priorités dans l’expérience des utilisateurs, par exemple pour éviter une dégradation des performances au niveau de la succursale en cas d’envoi de fichiers volumineux ou de tâches d’impression importantes sur le réseau. L’optimisation WAN HDX assure une compression avec système de jetons et déduplication des données, réduisant considérablement les besoins en bande passante tout en améliorant les performances.
CHAPITRE 3 : Etude comparative et choix de la solution 36 III. Solutions de cloud : 1. Solution Eucalyptus : Eucalyptus est un outil open source issu d’un projet de recherche de l’université de Californie. Il est développé en C, Java, Python et est disponible sous deux licences. Une licence GPL gratuite supportant les hyperviseurs Xen et KVM et une licence commerciale offrant des fonctionnalités avancées telles que le support de VMware. Il permet de construire aussi bien les solutions privées du cloud computing que les solutions publiques. Son grand avantage est qu’il est intégré dans les distributions Ubuntu et Debian. Eucalyptus offre des interfaces compatibles avec les services EC2 d’Amazon. Ce qui lui confère la possibilité d’être employé pour les solutions hybrides de cloud computing. L’architecture d’Eucalyptus est constituée de quatre composants principaux (Nurmi et al, 2008 ; Alrwais, 2011)7 . - Le contrôleur de nœud (Node controller NC) : contrôle l’exécution, et l’arrêt des machines virtuelles présentes sur le nœud où il est exécuté. - Le contrôleur de cluster (cluster controller CC) : collecte les informations sur les différents nœuds d’un cluster et planifie l’exécution des machines virtuelles sur chaque nœud. - Le contrôleur de stockage (Warlus) : c’est le composant qui gère l’accès au service de stockage. Il est souvent intégré au contrôleur du cloud (CLC). - Le contrôleur de cloud (CLC): C’est le point d’entrée (Front end) des utilisateurs et administrateurs du système. Il collecte des informations sur les nœuds et planifie leur exécution au travers des contrôleurs de clusters (CCs). Il expose les services du cloud à travers une application Web mais également à travers des interfaces compatibles EC2. 7 Abicloud. Http ://community.abiquo.com/.
CHAPITRE 3 : Etude comparative et choix de la solution 37 Figure 3.13 : Architecture d’Eucalyptus 2. Solutions OpenNebula : Il s’agit d’une plateforme purement open source permettant de déployer des cloud privés, publics et hybrides. Mais l’idée fondamentale de la solution d’OpenNebula est orientée vers une implémentation en privé afin de permettre aux utilisateurs de se connecter aux ressources internes via une interface Web (Sempolinski et Thain, 2010). La solution OpenNebula est rigidement centralisée autour d’un nœud appelé front-end, chargé de la supervision de toute l’architecture. Elle est basée sur un haut niveau de personnalisation en fournissant plusieurs modules configurables et adaptables aux besoins. Cette haute modularité est à la fois un avantage, en ce sens qu’elle permet de construire l’architecture à sa manière, mais aussi un inconvénient parce qu’elle conduit à des difficultés de configuration entrainant des erreurs de mise en œuvre et des échecs de déploiement des machines virtuelles dans le réseau (Sempolinski et Thain, 2010)8 . OpenNebula supporte les hyperviseurs XEN, KVM et optionnellement VMware. L’architecture interne d’OpenNebula est constituée de trois couches d’éléments appelées respectivement : tools, core et drivers (Figure 3.14). - Tools : c’est l’ensemble des outils de gestion de l’architecture. Il est constitué des interfaces de lignes de commandes CLI (Command Line Interface) pour l’interaction avec le système, d’un portail Web d’administration et d’utilisation du cloud, appelé sunstone localisé au niveau du nœud central de l’architecture. 8 Amazon web srrvice. http://aws.amazon.com/fr/.
CHAPITRE 3 : Etude comparative et choix de la solution 38 - Core : ce niveau consiste en un ensemble de composants impliqués dans la gestion et le contrôle des nœuds, des utilisateurs et des machines virtuelles de l’architecture. Ces différents composants communiquent en utilisant le protocole XML RPC. - Driver : c’est à ce niveau que se déroulent les processus liés aux transferts de machines virtuelles d’un nœud à un autre. Ces différentes couches s’observent sur le nœud frontal de l’architecture. Ce dernier est ensuite relié aux nœuds d’exécution (hosts) par l’intermédiaire d’un réseau local (Figure 3.14). Les nœuds d’exécution (hosts) ne requièrent l’installation d’aucun service d’OpenNebula. Seul le front-end héberge tous les services de supervision et de gestion du cloud ; ce qui rend ce nœud l’unique point de défaillance du système. Figure 3.14 : Les déférents couches d’OpenNebula 3. Solutions Openstack : OpenStack est l'une des options d'exploitation cloud les plus populaires aujourd'hui. C’est un projet open source permettant de déployer une infrastructures IaaS (Infrastructure en tant que service). Il est d’ailleurs considéré par certains, comme l'un des plus grands projets open-source. Nombreuses entreprises (VMware, IBM, Amazon, OVH, …) ont rejoint la fondation, pour faire évoluer davantage le projet et d'autres l'utilisent même pour la gestion de leur cloud, qu'il soit public ou privé. La technologie possède une architecture modulaire composée de plusieurs projets corrélés (Nova, Swift, Glance ...) qui permettent de contrôler les différentes ressources des machines virtuelles tel que la puissance de calcul, le stockage ou encore le réseau. OpenStack supporte de nombreux hyperviseurs dont VMware vSphere, Hyper-V, Citrix Xen ou encore KVM (le plus souvent utilisé). Il propose également de nombreuses API standardisée EC2 (Elastic Compute Cloud), permettant d'exposer une couche Cloud "normalisée" indépendante de l'infrastructure de virtualisation sous-jacente (découplage). OpenStack intègre également la technologie des conteneurs, une alternative à la virtualisation classique, qui permet un gain considérable de ressources (CPU, Stockage, …) à l’instar des machines virtuelles qui
CHAPITRE 3 : Etude comparative et choix de la solution 39 embarquent tout un système d’exploitation. Cette technologie apporte également un plus dans la sécurité grâce à l’isolation des conteneurs. L'image suivante décrit dans l'ensemble tout ce qu'on peut faire avec OpenStack: Figure 3.15 : Les déférents taches d’Openstack Comme nous l'avons dit plus haut, OpenStack est un ensemble de projets correlés, dont chaque projet a une tâche bien précise. Il y'en a vraiment beaucoup, et donc parmi ces projets nous pouvons en citer quelques-uns, qui constitue le socle même d'OpenStack: - Keystone: c'est le service d'dentité d'OpenStack, c'est lui qui gère toute l'authentification au système, il gère les accès, les droits, les domaines, les tenants. Il gère également l'accès aux différentes apis du système, les endpoint qui permettront de gérer l'accès aux autres services. - Glance: le service d’image d'OpenStack, il permet la découverte, l'envoi et la distribution d'image disque vers les instances de machines virtuelles. Vous pouvez stocker les images de machine virtuelle mises à disposition par le service d’image dans différents emplacements, du simple système de fichiers au système de stockage objet (Swift). Les images stockées font
CHAPITRE 3 : Etude comparative et choix de la solution 40 office de modèle de disque. Le service glance permet aussi de stocker des sauvegardes de ces disques. Glance ne stocke pas seulement des images, mais aussi des informations sur celles- ci, les métadonnées. Ces métadonnées sont par exemple le format du disque (comme QCOW2 ou RAW) ou les conteneurs de celles-ci (OVF par exemple), qui peuvent être intérrogées à travers une API REST. - Nova: le service de calcul (virtualisation) d'OpenStack, permet d'héberger et gérer les services d'un système de cloud computing. Le service de calcul est la partie principale d'un système Iaas (Infrastructure as a service). Les principaux modules sont implémentés en Python. Nova interragit avec le service d'identité d'OpenStack (Keystone) pour l'authentification, le service d'image (Glance) pour fournir des images disques sur la base desquelles seront déployées les instances de serveur, et le tableau de bord qui offre aux utilisateurs, une interface pour gérer leurs machines virtuelles. - Neutron: le composant Réseau OpenStack (neutron) gère tous les aspects réseau pour l’infrastructure de réseau virtuel et les aspects de la couche d’accès à l’infrastructure de réseau physique dans votre environnement OpenStack. Le réseau OpenStack permet aux tenants de créer des topologies de réseau virtuel avancées qui peuvent inclure des services comme un firewall, un load balancer, et un réseau privé virtuel (VPN). Le composant Réseau fournit des réseaux, sous-réseaux et routeurs comme des abstractions objet. Chaque abstraction a des fonctionnalités qui imitent son homologue physique: les réseaux contiennent des sous-réseaux, et les routeurs dirige le trafic entre les différents sous-réseaux et réseaux. Chaque routeur a une unique passerelle qui se connecte à un réseau et de multiples interfaces connectées à des sous-réseaux. Les sous-réseaux peuvent accéder à des machines sur d’autres sous-réseaux connectés au même routeur. Ainsi un utilisateur peut créer son propre réseau de machines virtuelles. - Horizon: le tableau de bord OpenStack (horizon) est une interface web qui permet aux administrateurs et aux utilisateurs du cloud de gérer les différentes ressources et services OpenStack. Le tableau de bord permet des interactions de type web avec le contrôleur du cloud OpenStack à travers les différentes APIs. Pour chaque service ajouté à votre environnement OpenStack, Horizon l'intègrera automatiquement dans son interface. En plus du thème de base qu'il vous propose, il vous offre aussi la possibilité de le personnaliser à votre façon. - Cinder: le service de stockage par blocks (cinder) fournit aux machines virtuelles un stockage persistant. Il fournit une infrastructure pour gérer les volumes, et interragit avec le service de calcul d'OpenStack pour fournir des volumes aux instances de machines virtuelles. Il gère donc les opérations de création, d'attachement et de détachement de ces périphériques sur les serveurs. Le stockage en mode bloc est utilisé pour des scénarios performant comme celui du stockage de base de données, mais aussi pour fournir au serveur un accès bas niveau au périphérique de stockage. Cinder gère aussi la création d'instantanés (snapshots), très utile pour sauvegarder des données contenues dans les périphériques de type bloc. Les instantanées peuvent être restaurées ou utilisées pour créer de nouveaux volumes. - Swift: le service de Stockage Objet (swift) permet le stockage et la récupération d’objets à travers une API REST. C'est le type de stockage le plus souvent utilisé pour stocker tout type de fichiers. Ainsi grâce à votre cloud, vous pourrez y accéder de partout. Il n'est pas juste un simple stockage car il assure également la réplication des données sur plusieurs disques, qui peuvent même être sur des serveurs différents. Donc de base ce service intègre déjà plus ou moins de la haute disponibilité, même s’il vaut ieux s'en assurer personnellement; Tout dépend de votre activité et de votre utilisation du cloud. Il permet d'offrir également un espace de stockage pour le service d'image, qui est utilisé pour déployer des instances. Pour
CHAPITRE 3 : Etude comparative et choix de la solution 41 que Swift fonctionne l'environnement doit inclure au minimum le service d’identité (keystone) avant de déployer le service de stockage d’objet9 . - Heat: le service d'orchestration d'OpenStack (heat) permet d'orchestrer des tâches dans le cloud computing. Il permet de plannifier et d'automatiser certaines tâches en gérant ls ressources du cloud tel que les instances virtuelles, les adresses IP flottantes, les volumes, les images, les groupes de sécurité, les utilisateurs. Il fournit également des fonctionnalités tels que la haute disponibilité des instances, l'auto-scaling (extensibilité) des instances, en décrivant via un template heat (HOT) qui est une sorte de langage, comment on souhaite gérer les ressources du cloud. - Ceilometer: le service de télémétrie d'OpenStack (ceilometer). Il permet de collecter différentes métriques sur l'utilisation du cloud. Par exemple il permet de récolter le nombre d'instances lancé dans un projet et depuis combien de temps. Ces métriques peuvent être utilisées pour fournir des informations nécessaires à un système de facturation par exemple. Ces métriques sont aussi utilisées dans les applications ou par d'autres composants d'Openstack pour définir des actions en fonction de certains seuils comme avec le composant d'orchestration. Les services décrits plus haut sont les services les plus souvent utilisés quand on déploie un cloud (en particulier avec OpenStack). Bien entendu OpenStack possède encore beaucoup d'autres modules que pouvez installer (troove, ironic, sahara, designate, barbican, zaqar, magnum, manila...). Tout cela dépend de ce que vous souhaitez faire. Et ceci est même un des gros avantages qu'OpenStack possède par rapport à d'autres solutions de cloud computing come VMWare vCloud, ou encore Microsoft System Center, qui non seulement sont des solutions propriétaires et payantes, mais en plus ne s'installent pas par modules, c'est-à-dire que vous n'avez pas réellement le choix sur ce que vous décidez d'installer ou pas. Par exemple si vous souhaitez uniquement faire du cloud de stockage, avec OpenStack vous aurez juste besoin d'installer le service de stockage Swift, sans avoir à déployer Nova, ou encore Neutron, et ceci rendra votre environnement plus léger, par contre les autres solutions intègre directement des fonctionnalités sans doute bien, mais dont vous n'avez pas forcément besoin, et qui peut même rendre le déploiement complexe. Voici un schéma illustrant, les relations entre les différents services d'OpenStack: 9 Eucalyptus. http://www.eucalyptus.com/. [15] Kvm. http://www.linux-kvm.org/.
CHAPITRE 3 : Etude comparative et choix de la solution 42 Figure 16 : Les différents services d’openstack
CHAPITRE 4
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 43 Introduction : Ces dernières années, l’impressionnant grossissement du volume d’information et de leur sauvegarde dirigée par une nouvelle classe de d’applications gourmandes en données, d’applications entreprise web-enabled, et de l’Internet a créé une augmentation sans précédent des besoins de stockage. L’approche traditionnelle du stockage par les entreprises impliquait un lien direct entre un serveur et le system de stockage local. Ces méthodes de stockage par lien direct engendrent des îlots de stockage compliqués à gérer et limitant la flexibilité. Voilà pourquoi une nouvelle approche du stockage est apparue, permettant la mutualisation des données, la simplification de la gestion et l’amélioration de la flexibilité. Cette nouvelle approche est le stockage réseau. Aujourd’hui, c’est un enjeu essentiel. Pour qu’une entreprise puisse se développer et fonctionner, un système d’information disponible et fiable est primordial. Auquel cas, il y a un risque de pertes de productivité (baisse du CA), de matériels, mais également de coûts supplémentaires (liées aux pannes, aux ressources à déployer, etc.). La haute disponibilité (ou High Availability ou HA) permet d’assurer et de garantir le bon fonctionnement des services ou applications proposées et ce 7j/7 et 24h/24. Cela consiste donc à mettre en place toutes les actions et dispositions techniques pour qu’une infrastructure informatique soit toujours disponible en appliquant certains principes tels que la réplication des données, la sauvegarde, la répartition de la charge, la redondance, etc. pour limiter l’indisponibilité d’un SI1 . 1 Microsoft. http ://www.microsoft.com/.
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 44 1. Technologies de stockage (NAS SAN...) :  NAS : Figure 4.1 : L’architecture de réseau NAS Un serveur de stockage en réseau (NAS) est une architecture de stockage en mode fichier, constituée d'un ou de plusieurs serveurs dotés de disques dédiés où les données sont stockées et partagées avec de nombreux clients connectés à un réseau. Le NAS est l'une des trois principales architectures de stockage, avec les réseaux locaux de stockage (SAN) et le stockage en attachement direct (DAS). C'est la seule qui soit à la fois en réseau (par définition) et entièrement responsable de l'ensemble du stockage du réseau. Si l'on compare le NAS à des volumes de stockage qui vous sont plus familiers, comme le disque dur de votre ordinateur, un disque dur externe, un CD ou une clé USB, on constate qu'une architecture NAS vous permet de stocker et de partager des fichiers de la même manière. La différence est ailleurs. En effet, un disque dur, interne ou externe, un CD et une clé USB ne peuvent se connecter qu'à un seul périphérique à la fois, tandis que le NAS relie plusieurs périphériques en même temps. Les unités NAS sont conçues pour distribuer les données sous la forme de fichiers. Bien qu'ils soient techniquement capables d'effectuer des tâches de serveur général, les unités NAS
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 45 ont souvent un rôle qui se limite à l'exécution d'un logiciel qui protège les données et gère les autorisations. C'est pour cette raison qu'elles n'ont pas besoin d'un système d'exploitation complet. La plupart des unités NAS incluent un système d'exploitation léger, configuré pour le stockage et la présentation des données. Pour présenter ces fichiers, l'unité NAS utilise des protocoles fichiers standard, tels que NFS (Network File System), SMB (Server Message Block), CIFS (Common Internet File System) ou AFP (Apple Filing Protocol), qui communiquent avec les périphériques Linux, UNIX, Microsoft Windows et Apple. Voici les principaux avantages d'un serveur NAS : • Évolutivité : pour augmenter la capacité de stockage d'un NAS, il suffit d'y ajouter des disques durs. Pas besoin de mettre à niveau ni de remplacer des serveurs, et encore moins de désactiver le réseau. • Performances : comme le NAS est un système de fichiers, les autres périphériques du réseau n'ont pas besoin de se charger du partage des fichiers. De plus, le NAS est souvent configuré pour une utilisation bien précise (stockage de Big Data ou de contenus multimédias, par exemple), ce qui permet d'obtenir des performances plus élevées. • Configuration simple : les architectures NAS sont souvent accompagnées de scripts simples ou encore fournies sous la forme d'appliances préinstallées avec un système d'exploitation rationalisé, ce qui réduit considérablement le temps de configuration et de gestion du système. • Accessibilité : tous les périphériques en réseau ont accès au NAS. • Tolérance aux pannes : il est possible de formater le NAS de sorte qu'il prenne en charge des disques répliqués, un système RAID ou le codage à effacement afin d'assurer l'intégrité des données. Fonctionnement : Pour faire simple, le NAS est une approche qui vise à simplifier l'accès aux données stockées entre les périphériques d'un réseau. En installant un logiciel spécialisé sur du matériel dédié, les entreprises peuvent tirer parti d'un accès partagé à point unique assorti de fonctions de sécurité, de gestion et de tolérance aux pannes. Le NAS communique avec les autres périphériques à l'aide de protocoles fichiers. C'est l'un des formats les plus faciles à utiliser, notamment par rapport aux systèmes de stockage en mode bloc ou objet. Matériel : Le matériel qui compose un NAS est généralement appelé boîtier NAS, unité NAS ou serveur NAS. Le serveur en lui-même est essentiellement composé de disques de stockage, de processeurs et de mémoire RAM, comme la plupart des autres serveurs. Il est possible d'ajouter plus de mémoire RAM à une unité NAS ou de personnaliser le type et la capacité des disques selon les besoins spécifiques. La différence principale entre un NAS et un serveur de stockage généraliste se situe plutôt au niveau du logiciel. Logiciels : Une unité NAS comprend un logiciel déployé sur un système d'exploitation allégé, généralement intégré au matériel. Quant au serveur généraliste, il est doté d'un système d'exploitation complet et il envoie et reçoit des centaines ou des milliers de petites requêtes
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 46 uniques par seconde. Le système d'exploitation d'un NAS, lui, ne gère que deux tâches : le stockage des données et le partage des fichiers. Protocoles : Figure 4.2 : Protocole de stockage NAS Une unité NAS est formatée avec des protocoles de transfert de données, fréquemment utilisés pour l'envoi de données entre plusieurs périphériques. Les clients peuvent accéder à ces protocoles via un commutateur réseau, c'est-à-dire un serveur central qui connecte tous les éléments du réseau et achemine les requêtes. En pratique, les protocoles de transfert de données vous permettent d'accéder aux fichiers stockés sur un autre ordinateur, comme s'il s'agissait des vôtres. Sur un réseau, plusieurs protocoles peuvent être utilisés, mais les deux plus importants sont les suivants : le protocole IP (Internet Protocol) et le protocole TCP (Transmission Control Protocol). Le protocole TCP permet de regrouper les données en paquets avant de les envoyer via le protocole IP. Pour simplifier les choses, les paquets TCP sont comparables à des fichiers ZIP et le protocole IP à des adresses e-mail. Si vos grands-parents ne sont pas inscrits sur les réseaux sociaux et qu'ils n'ont pas accès à votre cloud personnel, vous devez leur envoyer vos photos de vacances par e-mail. Vous pouvez également rassembler ces photos dans des fichiers ZIP pour éviter de les envoyer une par une. De la même manière, le protocole TCP rassemble les fichiers dans des paquets avant de les envoyer sur un réseau via des adresses IP2 . Les fichiers transférés via ces protocoles peuvent être aux formats suivants : • NFS (Network File System) : ce protocole est fréquemment utilisé sur les systèmes Linux et UNIX. Ce protocole indépendant fonctionne sur tout type de matériel, de systèmes d'exploitation et d'architectures de réseau. • SMB (Server Message Block) : la plupart des systèmes qui utilisent le protocole SMB exécutent Microsoft Windows. Il est alors appelé « Réseau Microsoft Windows ». Ce 2 Microsoft. Windows azure http : // www.microsoft.com/windowsazure/.
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 47 protocole a été développé à partir du protocole CIFS (Common Internet File System) et c'est pour cette raison qu'il apparaît parfois sous l'appellation CIFS/SMB. • AFP (Apple Filing Protocol) : il s'agit d'un protocole propriétaire, réservé aux périphériques Apple qui exécutent MacOS.  SAN : Dans la gestion des infrastructures informatiques, la consolidation des données est une priorité. La qualité d’une solution de stockage consolidée est jugée sur la facilité de sa gestion et de sa maintenance. Selon les impératifs du responsable IT, en termes de disponibilité, de fiabilité, de performance et de sécurité, la plateforme évoluera vers une complexité plus élevée, à savoir des configurations redondantes, miroirs et même distantes. Cela dépend de la vocation de la solution. Figure 4.3 : L’architecture de réseau SAN 1) Fonctionnement : Le SAN fonctionne en SCSI est fondé sur un sous réseau à haut débit reliant les serveurs applicatifs et les équipements de stockage (baies Raid, robots de sauvegarde). Ses fonctions comprennent le stockage proprement dit, la sauvegarde, la réplication, la sécurisation, le partage et l'administration des données. Son unité de base est le bloc de données, et non pas le fichier. 2) Quel type de réseau utilise un réseau SAN? Le SAN est d'un point de vue topologique comparable au LAN et au WAN auxquels il est couplé. Il se compose de contrôleurs (cartes d'interfaces), de câbles cuivre ou optique, de commutateurs, de concentrateurs, de routeurs et de passerelles. Au milieu des années quatre- vingt-dix, le SAN reposait exclusivement sur des liens Fibre Channel, une technologie de transport série à haut débit et longue distance. Aujourd'hui, il exploite souvent en combinaison les technologies de transport Fibre Channel, Gigabit Ethernet et ATM, et les protocoles FCP, IP et iSCSI. Au sein du SAN, les échanges se font en mode point à point, sur des canaux offrant la totalité de la bande passante nominale. Deux topologies sont en concurrence. La première, la
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 48 boucle arbitrée (FC-AL) consiste à placer les équipements sur une boucle avec des concentrateurs, un seul canal est ouvert à un moment donné entre deux noeuds, les autres noeuds étant inactifs. La seconde, la matrice FC (FC Fabric) exploite des commutateurs pour assurer de l’échange point à point simultanés, plus puissante et plus souple, elle tend à remplacer la boucle arbitrée. Les commutateurs fonctionnent généralement à 2 Gbit/s. Quelle que soit la couche physique, il faut se souvenir qu'un réseau SAN est un réseau à proprement parler; il présente les mêmes problèmes de sécurité et de gestion qu'un réseau local critique. De fait, structurer le réseau SAN interne en le répartissant en zones distinctes avec différents droits d'accès et configurations physiques permet d'accroître la sécurité et la fiabilité. 3) Quels types de commutateurs sont appropriés SAN? Il existe deux catégories principales de commutateur: directeur et matrice. Les commutateurs directeurs sont les cuirassés: ils sont dotés d'un grand nombre de ports, de composants du noyau redondants et remplaçables à chaud, et d'autres fonctionnalités architecturales qui améliorent la fiabilité. Résultat, un bon fonctionnement 99,999% du temps. Leur prix est en conséquence. Les commutateurs de matrice affichent pour leur part des spécifications inférieures. 4) Peut-on bâtir un réseau SAN sur réseau existant? En théorie, oui. Dans la pratique, si un réseau SAN offre tant d'avantages, c'est parce qu'il dispose d'une bande passante dédiée. S'il doit assurer un trafic qui n'est pas lié au stockage, la fiabilité et les temps de réponse en pâtiront. Il est donc préférable de considérer le réseau SAN comme une entité indépendante. Le réseau local existant en bénéficiera également, car les tâches de traitement de gros volumes de données, telles que les sauvegardes et réplications, peuvent s'effectuer en dehors de l'environnement local général. 5) Qu'est-ce qu'un serveur SAN? Dans un réseau SAN ordinaire, le réseau de stockage est principalement un moyen de communication, l'allocation des données aux dispositifs de stockage s'effectuant sur un serveur. Un serveur SAN réside au sein du réseau de stockage et joue l'intermédiaire pour chaque opération, centralisant le contrôle de la répartition des données. Il peut également gérer la redondance pour les contrôleurs de disque. Bien que ce fonctionnement soulage les serveurs d'une partie des impératifs de traitement et contribue à simplifier la gestion, le serveur SAN peut se transformer en goulet d'étranglement, et peut poser lui-même des problèmes de fiabilité.
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 49 6) Topologie : Figure 4.4 : Topologie de réseau SAN 7) Applications : Pour simplifier, on peut dire que le SAN répond aux exigences des grandes entreprises en termes de disponibilité de bande passante comme de criticité des applications. Il est destiné aux applications nécessitant le transfert de volumes élevés de données. Il se destine à travailler dans un environnement de type back-end -applications pour la lecture et l’écriture d'informations en interne. 8) Défauts et qualités : A. Défauts : Ils sont : • Le principal défaut du SAN est son coût. En effet, il nécessite un réseau spécifique à très haut débit très coûteux généralement à base de Fiber Channel mais aussi ATM ou Gi Gigabit Ethernet. • Il ne peut pas se baser sur un réseau déjà existant car il provoquera vrai semblablement de très importants engorgements perdants de ce fait tous ses avantages. B. Qualités : Elles sont la performance d’accès aux données, la disponibilité, la fiabilité, la stabilité, la sécurité des données et enfin, l’économie des personnes destinées à la gestion journalière. Les forces d’un SAN se situent à trois niveaux :
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 50 •Le SAN est un réseau spécialisé. Il est affecté à la connexion des unités de stockage, tels que disques, librairies de backup, robots de backup... aux serveurs. Objectif : accès des utilisateurs aux données sans charger le réseau de l’entreprise (LAN).En spécialisant les réseaux, les machines sont reliées entre elles par un réseau réservé à cette fin. Dès lors, à son poste de travail, l’utilisateur dispose d’un réseau libéré donc plus performant. Effet immédiat : le temps de réponse s’améliore nettement. •Une architecture traditionnelle de server-attached storage demande le shutdown du serveur pour tout ajout de capacité de stockage. Le SAN, quant à lui, permet d’ajouter des unités de stockage sans interruption de service. Dès lors son utilisation est justifiée dans le cadre d’applications qui connaissent une forte dynamique de croissance. •Le SAN autorise la centralisation des backups. Avantage direct : la garantie de l’intégrité et de la sécurité des données.  DAS : Le DAS est l’architecture standard de stockage avec connexion directe aux serveurs. C’est encore l’architecture la plus courante aujourd’hui. L’hôte et ses éléments de stockage sont connectés un à un par des liens SCSI. Figure 4.5 : L’architecture de réseau DAS Fonctionnement : Le stockage (DAS) est un dispositif interne ou externe qui se branche directement à un seul serveur. Ce dispositif contient des disques indépendants de type RAID tolérant la panne de disques sans perte de données et qui fonctionne de façon indépendante des systèmes d’exploitation.
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 51 Dans cette topologie de stockage, à un serveur correspond un équipement de stockage. Aucune fonctionnalité de réseau n’est alors déployée. Par conséquent, pour accéder à ce dispositif, les usagers doivent accéder au serveur auquel il est branché. Topologie : Figure 4.6 : Topologie de réseau DAS • Défauts et qualités : Comme de plus en plus d’espaces de stockages et de serveurs sont ajoutés pour répondre aux demandes des entreprises, l’environnement DAS peut causer une prolifération de serveurs et d’îlots de stockage. Cela engendre donc une immense charge de gestion pour les administrateurs et une utilisation inefficace des ressources. Le partage des données dans ce type d’environnement est aussi très limité. Cependant, il est très simple de mettre en place un DAS puisqu'il n’y a qu'un serveur branché au dispositif de stockage.
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 52 2. Systèmes de stockage (CEPH NFS...) :  CEPH : Ceph est un système de stockage distribué open-source répondant aux besoins de stockage modernes. Il est flexible jusqu'au niveau exaoctet et son architecture ne contient pas d'un point unique de défaillance, c'est à dire que le système n'est pas dépendant d'un disque, dont la panne entraînerait l'arrêt complet du système. Cela le rend idéal pour les applications nécessitant un stockage flexible hautement disponible. À partir de Proxmox VE version 4.1, le serveur Ceph a été intégré à Proxmox pour coexister sur le même nœud. La capacité à gérer les grappes Cephpar l’interface graphique Proxmox a également été ajoutée. A. Architecture de CEPH : L'architecture de Ceph se base sur RADOS, un système de stockage d'objets répartis géré par plusieurs serveurs indépendants appelés nœuds de stockage3 . Figure 4.7 : Architecture Cèph La couche supérieure correspond à une API et une librairie librados permettant à une application d’interagir directement avec le stockage d'objets. Cette librairie est utilisée par Ceph pour fournir à l'utilisateur trois modes d'accès aux objets : • Une interface directe au stockage d'objet RadosGW, compatible avec les composants de stockage du cloud : S3 d'AWS et Swift d'Openstack. • Une interface de type bloc, RBD, utilisable par un client Linux, une machine virtuelle dans notre cas. • Une interface de type système de fichiers distribué, CephFS, utilisable par un client Linux. Ce système n'est cependant pas encore mature. L'environnement Proxmox intégrant l'accès au stockage en mode blocs, l'accès à Ceph se fera à travers le module RBD. Celui-ci autorise les utilisateurs à monter Ceph comme un périphérique bloc. 3 DELHOMME(Olivier): Mise en oeuvre de CEPH, GNU/Linux Magazine France.N°180 (Mars 2015), p.30-39.
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 53 Lorsqu'une application écrit des données sur le périphérique bloc, Ceph réplique les données automatiquement à travers le cluster. B. Les services CEPH : La partie serveur de Ceph est assurée par trois types de services à déployer : OSD : qui a pour rôle de stocker efficacement les objets. Il utilise pour cela le disque local du serveur, via un système de fichiers local classique (XFS, EXT). MON : qui surveille et contrôle l’état du cluster, maintient une cartographie de l’état de celui- ci. Ne stocke aucune donnée. MDS : qui a pour rôle de gérer les métadonnées pour CephFS. Il n'est pas utilisé car nous utilisons uniquement le module RBD. Le déploiement de plusieurs démons dans un ensemble de machines constitue un cluster Ceph. Le caractère redondant de ces services permet de se défaire d'un SPOFet ainsi d'assurer une haute disponibilité du stockage. C. Gestion de stockage CEPH : L’architecture de Ceph est modulaire. Elle repose sur plusieurs concepts propres au système de stockage open-source : C.1. Les pools : Les pools permettent le partitionnement logique de l'espace de stockage du cluster. Il est possible d'indiquer quelques paramètres qui seront spécifiques à chaque pool : − Le nombre de réplicats pour les objets et le nombre minimal de réplicats acceptables pour continuer de fonctionner en mode dégradé. − Les propriétaires et les droits d'accès. − Le nombre de groupes de placement : il s'agit de fragments de pools permettant de segmenter la distribution des objets entre OSD. L'objectif étant de créer un niveau d'indirection supplémentaire afin de faciliter la reconstruction des données en cas de panne d'un composant. − La règle CRUSH à utiliser : L'algorithme CRUSH est chargé du calcul de l'emplacement d'un objet. Il permet de définir comment les serveurs OSD peuvent tomber en panne et donc induire le placement des données pour permettre cela. − Les moniteurs (Mons): Chaque cluster Ceph nécessite la mise en œuvre de moniteurs installés sur des serveurs indépendants. Ces moniteurs sont utilisés par les clients Ceph pour obtenir la carte la plus à jour du cluster.
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 54 Figure 4.8 : Organisation des données dans Ceph C.2. Réplication de données : La réplication des données dans le système Ceph se fait directement sur les pools selon deux techniques : a. Clonage : Le système stocke autant de copies que spécifié de chaque donnée. L'OSD primaire copie l'objet vers le(s) OSD secondaire(s). Dans ce cas, le coût du stockage augmente avec le nombre de copies spécifié. Ainsi, plus le nombre de copies est important, plus on peut se permettre de pannes. b. Utilisation de code à effacement (erasurecoding) : Chaque objet écrit sur le cluster est découpé en n segments (avec n = k + m, k correspondant au nombre de segments de données et m le nombre de segments contenant les données de parité). Dans ce cas, lors de la réplication d'un pool, l'OSD primaire découpe l'objet en segments, génère les segments contenant les calculs de parité et distribue l'ensemble de ces segments vers les OSD secondaires en écrivant également un segment en local. Il est important de noter que le mode bloc RBD utilisé n'est supporté que sur les pools répliqués.
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 55 Figure 4.9 : Illustration des deux modes de réplication des données. D. Implantation de stockage distribué à travers Proxmox VE : Un des principaux avantages de Proxmox VE est l'intégration de plusieurs types de stockages partagés (NFS, RBD/Ceph...) Une fois le cluster a été créé et les trois nœuds redémarrés nous pouvons passer à l'installation de l'architecture de stockage distribué à haute utilisés conjointement. D.1. Implémentation du système de stockage tolérance aux pannes développées pour la virtualisation: le Ceph a. Configuration du réseau dédié à Ceph : Séparer les réseaux d’administration de Proxmox et du réseau de stockage Ceph parce que le trafic des données de stockage Ceph nécessite un réseau privé performant. Pour cela nous devons ajouter une autre carte réseau Bond0 avec deux interfaces, que nous configurons en agrégation, nous lui affectons la plage d'adresses 192.168.1.0/24 " même plage avec stockage NFS". A partir de l'interface web de Proxmox VE nous configurons sur chaque nœud le nouveau réseau simplement en ajoutant un commutateur linux bond interfaçant (ens19 et ens20) avec l'adresse correspondant au nœud dans le réseau privé. Cette configuration peut se faire en ligne de commande en modifiant le fichier :/etc/network/interfaces sur chaque nœud puis redémarrer.
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 56 Figure 4.10 : Création d'une carte réseau en mode agrégation D.2. Installation des paquets CEPH : L'installation des paquets ceph sur les 3 nœuds se fait grâce à la commande : #pvecephinstall --version luminous Yes D.3. Création de la configuration initiale Ceph Exécutez la commande suivante sur un seul nœud pour initialiser le réseau Ceph. root@pve-3# pvecephinit --network 192.168.1.0/24 Ce qui crée le fichier de configuration /etc/pve/ceph.conf D.4. Mise en place des services Ceph : Le déploiement du cluster Ceph requiert un certain nombre de serveurs mon et osd pour se trouver dans un état stable. Il est recommandé d'installer un nombre impair de moniteurs afin de pouvoir identifier la panne au sein du cluster Ceph. Dans le cas présent, nous avons décidé d'utiliser un service de chaque type par nœud : nous disposons donc au total de 3 mon et 3 osd. a. Création des moniteurs Ceph : L'activation d'au moins un moniteur,sur un nœud est nécessaire en utilisant la commande: root@pev1:~# pvecephcreatemon Puis, via l’interface web Proxmoxnous avons créé des monitors sur les 2 nœuds restants pour
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 57 la redondance: pve-2CephMonitorCreate et pve-3CephMonitorCreate b. Création des OSD Ceph : La configuration se fait sur chaque nœud de cluster via l'interface de ligne de commande ou via l'interface graphique comme suit: Choisir un nœud puis sélectionner Ceph/DISKS/OSD/creatosd/select disque comme osd et journal bleustore ''préférable un disque ssd pour journal les autre sans journal '' Figure 4.11 : OSD installé D.5. Création de pool Ceph : Un pool est un groupe logique pour stocker des objets. Pour créer le pool ceph : Dans l'onglet principale Ceph, cliquez sur l’onglet « Pool" puis sur create.
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 58 Figure 4.12 : L'état de cluster Ceph  NFS : Un système de fichiers réseau (ou NFS de l’anglais Network File System), permet aux hôtes distants de monter des systèmes de fichiers sur un réseau et de les utiliser exactement comme des systèmes de fichiers locaux. Ceci permet aux administrateurs système de stocker des ressources sur des serveurs centralisés sur le réseau. A. Comment ça marche : NFS consiste en deux éléments principaux: un serveur et un ou plusieurs clients. Le client accède à distance aux données stockées sur la machine serveur. Afin que tout cela fonctionne correctement quelques processus doivent être configurés et en fonctionnement. Exemples pratiques d’utilisation : Il existe de nombreuses applications pratiques de NFS. Les plus communes sont présentées ci- dessous: • Configurer plusieurs machines pour partager un CDROM ou un autre médium. C'est moins cher et souvent une méthode plus pratique pour installer des logiciels sur de multiples machines. • Sur les réseaux importants, il peut être plus pratique de configurer un serveur NFS central sur lequel tous les répertoires utilisateurs sont stockés. Ces répertoires utilisateurs peuvent alors être exportés vers le réseau, les utilisateurs devraient alors toujours avoir le même répertoire utilisateur indépendamment de la station de travail sur laquelle ils ouvrent une session. • Plusieurs machines pourront avoir un répertoire /usr/ports/distfiles commun. De cette manière, quand vous avez besoin d'installer un logiciel porté sur plusieurs machines, vous pouvez accéder rapidement aux sources sans les télécharger sur chaque machine.
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 59 B. Les avantages de NFS : • Les stations de travail utilisent moins d'espace disque en local parce que les données utilisées en commun peuvent être stockées sur une seule machine tout en restant accessibles aux autres machines sur le réseau. • Les utilisateurs n'ont pas besoin d'avoir un répertoire personnel sur chaque machine du réseau. Les répertoires personnels pourront se trouver sur le serveur NFS et seront disponibles par l'intermédiaire du réseau. • Les périphériques de stockage comme les lecteurs de disquettes, de CDROM, de disquettes Zip® peuvent être utilisés par d'autres machines sur le réseau. Cela pourra réduire le nombre de lecteurs de medias amovibles sur le réseau. 3. Concepts et techniques de la haute disponibilité : Un service 100% disponible n’existe pas, car il y a plusieurs variables à prendre en compte tels que des aspects techniques ou remplacement de matériels. On considère un système hautement disponible lorsque son taux de disponibilité est de 99,96%. On parle également de SLA (Service Level Agrement), un indice permettant d’évaluer le degré de garantie et d’engagement du prestataire4 La conception des systèmes à haute disponibilité repose sur :  La modularité.  Fail fast.  Indépendance des modes de défaillance.  Redondance et réparation.  Elimination des points de défaillance unique 3.1. Mesure du taux de disponibilité : La disponibilité se mesure souvent en pourcentage : Disponibilité en % Indisponibilité par année Indisponibilité par mois3 Indisponibilité par semaine 90 % (« un neuf ») 36,5 jours 72 heures 16,8 heures 95 % 18,25 jours 36 heures 8,4 heures 98 % 7,30 jours 14,4 heures 3,36 heures 4 Microsoft hyper. http : //www.microsoft.com/hyper-v-server/en/us/default.aspx.
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 60 99 % (« deux neuf ») 3,65 jours 7,20 heures 1,68 heures 99,5 % 1,83 jours 3,60 heures 50,4 minutes 99,8 % 17,52 heures 86,23 minutes 20,16 minutes 99,9 % (« trois neuf ») 8,76 heures 43,2 minutes 10,1 minutes 99,95 % 4,38 heures 21,56 minutes 5,04 minutes 99,99 % (« quatre neuf ») 52,56 minutes 4,32 minutes 1,01 minutes 99,999 % (« cinq neuf ») 5,26 minutes 25,9 secondes 6,05 secondes 99,9999 % (« six neuf ») 31,5 secondes 2,59 secondes 0,605 secondes L'amalgame est souvent fait, à tort, entre la haute disponibilité et le plan de reprise d'activité. Il s'agit de deux tâches différentes, complémentaires pour atteindre la disponibilité continue. 3.2. Techniques améliorant Ha disponibilité : De nombreuses techniques sont utilisées pour améliorer la disponibilité : • la redondance des matériels et la mise en cluster ; • la sécurisation des données : RAID, snapshots, Oracle Data Guard (en), BCV (Business Copy Volume), SRDF (Symmetrix Remote Data Facility), DRBD ; • la possibilité de reconfigurer le serveur « à chaud » (c’est-à-dire lorsque celui-ci fonctionne) ; • mode dégradé ou un mode panique ; • plan de secours ; • et sécurisation des sauvegardes : externalisation, centralisation sur site tiers.
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 61 La haute disponibilité exige le plus souvent un local adapté: alimentation stabilisée, climatisation sur plancher, avec filtre à particules, service de maintenance, service de gardiennage et de sécurité contre la malveillance et le vol. Attention aussi au risque d'incendie et de dégât des eaux. Les câbles d'alimentation et de communication doivent être multiples et enterrés. Ils ne doivent pas être saillants dans le parking souterrain de l'immeuble, ce qui est trop souvent vu dans les immeubles parisiens. Ces critères sont les premiers à entrer en compte lors du choix d'un prestataire d'hébergement (cas de la location d'un local à haute disponibilité). Pour chaque niveau de l’architecture, pour chaque composant, chaque liaison entre composants, il faut établir : • Comment détecter une panne ? Exemples : Tests de vie TCP Health Check implémenté par un boîtier Alteon, programme de test invoqué périodiquement (« heartbeat »), interface de type « diagnostic » sur les composants… • Comment le composant est-il sécurisé, redondé, secouru… Exemples : serveur de secours, cluster système, clustering WebSphere, stockage RAID, sauvegardes, double attachement SAN, mode dégradé, matériel non utilisé libre (spare) prêt à être réinstallé.. • Comment désire-t-on enclencher la bascule en mode secours / dégradé. Manuellement après analyse ? Automatiquement ? • Comment s’assurer que le système de secours reparte sur un état stable et connu. Exemples : on repart d’une copie de la base et on réapplique les archives logs, relance des batchs depuis un état connu, commit à 2 phases pour les transactions mettant à jour plusieurs gisements de données… • Comment l’application redémarre sur le mécanisme de secours. Exemples : redémarrage de l’application, redémarrage des batchs interrompus, activation d’un mode dégradé, reprise de l’adresse IP du serveur défaillant par le serveur de secours… • Comment reprendre éventuellement les transactions ou sessions en cours. Exemples : persistance de session sur le serveur applicatif, mécanisme pour assurer une réponse à un client pour une transaction qui s’est bien effectuée avant défaillance mais pour laquelle le client n’a pas eu de réponse… • Comment revenir à la situation nominale. Exemples : o si un mode dégradé permet en cas de défaillance d’une base de données de stocker des transactions en attente dans un fichier, comment les transactions sont-elles réappliquées quand la base de données redevient active. o si un composant défaillant a été désactivé, comment s’effectue sa réintroduction en service actif (nécessité par exemple de resynchroniser des données, de retester le composant…) 3.3. Dépendance vis-à-vis des autres applications : Pour une application qui sollicite d’autres applications avec des middlewares en mode synchrone (service webs en http, Tuxedo, Corba, EJB) le taux de disponibilité de l’application sera fortement lié à la disponibilité des applications dont elle dépend. La sensibilité des applications dont on dépend doit donc être équivalente ou supérieure à la sensibilité de l’application elle-même. Sinon, il faut envisager
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 62 • l’utilisation d’un middleware asynchrone : MQ Series, JMS, SonicMQ, CFT • la mise en œuvre d’un mode dégradé quand une application dont on dépend est défaillante. Pour cette raison on privilégiera l’utilisation de middlewares asynchrones pour privilégier une bonne disponibilité quand c’est possible. 3.4. Répartition de charge et sensibilité : La sensibilité est souvent gérée en redondant les éléments avec un mécanisme de répartition de charge. (Un cluster Websphere avec un load-balancing Alteon par exemple). Pour que ce système apporte un réel gain en termes de fiabilité, il faut vérifier que si un des éléments est défaillant, les éléments restants disposent d’une puissance suffisante pour assurer le service. Autrement dit, dans le cas de deux serveurs actifs avec répartition de charge, la puissance d’un seul serveur doit permettre d’assurer la totalité de la charge. Avec trois serveurs, la puissance d’un seul serveur doit permettre d’assurer 50 % de la charge (en supposant que la probabilité d’avoir un incident sur deux serveurs en même temps est négligeable). Pour assurer une bonne disponibilité, il est inutile de mettre un grand nombre de serveurs se secourant mutuellement. Par exemple, un élément disponible à 99 % redondé une fois donne une disponibilité de 99,99 % (probabilité que les deux éléments soit défaillants au même moment = 1/100x1/100 = 1/10000)5 . 3.5. Redondance différentielle : La redondance d’un élément est généralement effectuée en choisissant de redonder avec plusieurs composants identiques. Ceci suppose, pour être efficace, qu’une défaillance d’un des composants est aléatoire et indépendante d’une défaillance d’un des autres composants. C’est par exemple le cas des pannes matérielles. Ce n’est pas le cas de toutes les défaillances : par exemple, une faille du système d’exploitation ou une anomalie d’un composant logiciel peuvent survenir, quand les conditions sont favorables, sur l’ensemble des composants à la fois. Pour cette raison, quand l’application est extrêmement sensible, on considèrera de redonder les éléments avec des composants de natures différentes mais assurant les mêmes fonctions. Ceci peut conduire à : • Choisir des serveurs de nature différentes, avec des OS différents, des produits logiciels d’infrastructure différents ; • développer le même composant deux fois en respectant à chaque fois les contrats d’interface qui s’appliquent au composant 3.6. Redondance avec système de vote Dans ce mode, différents composants traitent les mêmes entrées et produisent donc (en principe) les mêmes sorties. Les résultats produits par tous les composants sont collectés, puis un algorithme est mis en œuvre pour produire le résultat final. L’algorithme peut être simple (vote à la majorité) ou complexe (moyenne, moyenne pondérée, médiane…), l’objectif étant d’éliminer les résultats 5 Nimbus. http://www.nimbusproject.org/.
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 63 erronés imputables à un dysfonctionnement sur l’un des composants et/ou de fiabiliser un résultat en combinant plusieurs résultats légèrement différents. Ce procédé : • ne permet pas de répartition de charge ; • Introduit le problème de fiabilisation du composant gérant l’algorithme de vote. Ce procédé est utilisé généralement dans les cas suivants • Des systèmes reposant sur des capteurs (exemple : capteurs de température) pour lesquels les capteurs sont redondés • Des systèmes ou plusieurs composants différents assurant la même fonction sont utilisés (cf. redondance différentielle) et pour lesquels un meilleur résultat final peut être obtenu en combinant les résultats produits par les composants (exemple : système de reconnaissance de formes utilisant plusieurs algorithmes pour obtenir un meilleur taux de reconnaissance. 3.7. Shadow opérations : Lors du dysfonctionnement d’un composant redondé et après l’avoir réparé, on peut souhaiter le réintroduire en service actif, vérifier son bon fonctionnement effectif, mais sans que les résultats soient utilisés. Dans ce cas, les entrées sont traitées par un (ou plusieurs) composants réputés fiables. Ceux-ci produisent le résultat exploité par le reste du système. Les mêmes entrées sont également traitées par le composant réintroduit qui est dit en mode « shadow ». On peut vérifier le bon fonctionnement du composant en comparant les résultats produits avec ceux des composants fiables. Ce procédé est souvent utilisé dans les systèmes à base de vote car il suffit d’exclure le composant en mode « shadow » du vote final. 4. Les processus qui permettent d'améliorer la haute disponibilité : On peut distinguer deux rôles dans ces processus : 4.1. Les processus qui réduisent le nombre de pannes : En se basant sur le fait que mieux vaut prévenir que guérir, mettre en place des processus de contrôle qui permettront de réduire le nombre d'incidents sur le système permet d'améliorer la disponibilité. Deux processus permettent de jouer ce rôle : • Le processus de gestion des changements : 60 % des erreurs sont liées à un changement récent. En mettant en place un processus formalisé, accompagné de tests suffisants (et réalisés dans un environnement de pré-production correct), de nombreux incidents peuvent être éliminés. • Un processus de gestion pro-active des erreurs : les incidents peuvent bien souvent être détectés avant de survenir : les temps de réponse augmentent… Un processus affecté à cette tâche, et muni des outils adéquats (système de mesure, de reporting…) pourra intervenir avant même que l'incident n'arrive. En mettant en place ces deux processus, de nombreux incidents peuvent être évités. 4.2. Les processus réduisant la durée des pannes : Les pannes finissent toujours par arriver. À ce moment-là, le processus de reprise en cas d'erreur est primordial pour que le service soit restauré au plus vite. Ce processus doit avoir un
CHAPITRE 4 : Technologies de stockage et Haute Disponibilité 64 objectif : permettre à l'utilisateur d'utiliser un service le plus rapidement possible. La réparation définitive doit donc être évitée car elle prend beaucoup plus de temps. Ce processus devra donc mettre en place une solution de contournement du probleme. 5. Cluster haute disponibilités : Un cluster haute disponibilité (par opposition à un cluster de calcul) est une grappe d'ordinateurs dont le but est d'assurer un service en évitant au maximum les indisponibilités. Voici une liste non exhaustive d'applications de clustering pour UNIX (fonctionnant sous AIX, HP-UX, Linux ou Solaris) : • Evidian SafeKit [archive] (load balancing, réplication temps réel et failover) • HP MC/ServiceGuard pour HP-UX • IBM HACMP • Bull Application Roll-over Facility • Symantec Veritas Cluster Server • Open Source Linux Pacemaker (logiciel) • OpenSVC [archive] (Logiciels Libres Gratuits) • Oracle Solaris Cluster [archive] (ex SUN Cluster)
CHAPITRE 5
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 65 I. Introduction : Une bonne méthodologie de réalisation d'une application suppose une bonne maitrise de l'analyse et de la conception, cette dernière nous offre tous les modèles destinés à assurer le fonctionnement du logiciel. Ces modèles permettent d'expliciter les fonctionnalités. De manière globale, elle offre une vue panoramique sur l'ensemble des éléments et les interactions pris en compte dans la conception, à savoir le modèle logique, le modèle physique. II. Scénario 1 : Serveur web virtualisé au sein d'Openstack : Ce scénario a pour but de mettre en place une infrastructure virtualisée fonctionnelle, afin de mieux comprendre les interactions entre chaque service intervenant au sein d’Openstack. Au final, nous aurons un serveur web hébergé sur une VM que nous pourrons interroger depuis une adresse IP public. Dans un souci de bonnes pratiques, et dans le but de garantir la sécurité, le port 80 de la VM sera le seul port ouvert. Ce scénario va se matérialiser sous forme de deux variantes afin de mettre en évidence les différents types de stockage que nous offre OpenStack. La première sera la mise en place d’un stockage partagé basé sur le protocole NFS grâce au NAS QNAP. La deuxième sera l’intégration d’un système de stockage par bloc grâce au protocole iSCSI. La gestion d’une infrastructure virtualisée fait intervenir de nombreux éléments tels que la gestion des VMs avec Libvirt, et la gestion du réseau. OpenStack est donc constitué de nombreux services, permettant de piloter ces différents éléments de manière totalement dynamique. Comme les différents services sont répartis sur plusieurs PC physiques, ils doivent communiquer entre eux grâce au LAN Bleu. Pour cela, ils vont utiliser le protocole Advanced Message Queuing Protocol (Message AMQP) (voir §1.3)1 . 1. Scénario 1a : Système de stockage NFS : Le schéma représente les différentes entités physiques exécutant les différents services utiles au bon fonctionnement de l’infrastructure Openstack. 1 Openstack. http://www.openstack.org/.
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 66 Schéma 5.1: schéma Scénario 1a 1.1 Les entités physiques : Tous les serveurs physiques, utilisent Fedora 19. J’ai choisi cette distribution, du fait de ces nombreux points communs avec la distribution professionnelle Red Hat Entreprise Linux (RHEL) proposée par Red Hat. La future version de RHEL (RHEL 7), sera basée sur Fedora 19. Fedora est la version Open Source de RHEL, c’est à dire que la version professionnelle propose en plus uniquement le support, mais les fonctionnalités sont identiques. Toutes les entités physiques sont basées sur le même hardware : • Carte mère : Asus P8Q77-M • CPU : Intel Core i5-3330 • RAM : 8GB ! • Disque Dur : 320GB • Cartes réseaux 1Gb/s Intel
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 67 Voici le rôle de chaque serveur physique : ▪ L’administrateur du Cloud : Personne physique, qui depuis un navigateur web, va dialoguer avec le Cloud Controller pour démarrer une VM, gérer les contrôles d’accès ou administrer notre infrastructure. ▪ Cloud Controller : La pièce maitresse de notre infrastructure, il va piloter les différentes parties de notre infrastructure en envoyant des messages aux autres éléments physiques. ▪ Compute-Node : Héberge la couche de virtualisation (Hyperviseur), qui dans notre cas est matérialisée par le module KVM (Kernel-Based Virtual Machine) qui sera rajouté au Noyau Linux. Dans le jargon Openstack un hyperviseur est appelé un Compute Node. ▪ Network Node : Gestion des réseaux dédiés aux VMs, il va aiguiller les paquets venant du réseau public jusqu’à la VM. Cette entité va servir de lien entre le réseau public et le réseau privé en appliquant des règles de sécurité, tout comme un firewall. ▪ Le client de la VM : Dans notre scénario, ce client va interroger via son browser, le serveur Web situé sur une VM possédant une IP public. ▪ Le QNAP : Serveur NFS, afin d’héberger le disque virtuel de la VM. Les différents services seront présentés en §1.4 1.2 L’utilité des services Openstack : Le but premier d’Openstack est d’ajouter un service au-dessus des éléments intégrés au noyau Linux. Ils vont traduire les messages standardisés transitant à travers le réseau, en commandes interprétables par les modules du noyau tels que KVM ou Iptables. Message traduit en Commandes Systèmes compréhensibles par QEMU-KVM Figure 5.1 : But des services OpenStack Service Virtualisation Openstack Module QEMU-KVM Compute Node Message Standardisé Provenant d'un autre service
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 68 A travers Figure5.1, nous pouvons comprendre que le service de virtualisation d’Openstack situé au niveau de l’hyperviseur, va recevoir des messages standardisés du Cloud Controller et va les traduire en commandes compréhensibles par KVM. Grâce à ce service, un même message pourrait démarrer une VM soit sur un hyperviseur KVM ou soit sur l’hyperviseur ESX. Ces derniers posséderaient chacun un service de virtualisation OpenStack, qui traduirait le message en commandes interprétables par son système. 1.3 Echange de messages : Deux types de communications vont s’effectuer au sein de notre infrastructure : ▪ Communication via API : Les différents services Openstack fournissent une API2, c’est à dire que le service va proposer une interface afin de pouvoir interagir avec ces méthodes ou fonctionnalités. Pour interagir avec les API, le système de requêtes REST (Representational State Transfer) est très employé au sein de l’infrastructure OpenStack, c’est à dire que l’on peut envoyer au service une URL, contenant tous les paramètres que la méthode a besoin pour s’exécuter3. Cet échange se fait via le protocole http. L’API va nous retourner un objet JSON, qui pourra être interprété par le client. Un service d’API, comme présent sur le Cloud Controller va écouter sur un port particulier afin de recevoir les requêtes http, et va convertir ces dernières en message AMQP. ▪ Communication via file de messages (Advanced Message Queuing Protocol) AMQP : Afin d’unifier la communication réseau entre les services, le système adopté a été de mettre en place une infrastructure de communication inter-serveur basée sur des files de messages, grâce au protocole AMQP. Le protocole est géré par le serveur Qpid qui est le courtier hébergé sur le Cloud Controller. Le système de queues permet aux services de travailler de manières non synchronisées pour qu’ils puissent s’envoyer des messages en mêmes temps. Les appels de procédures distantes entre les services se font par l’envoi de messages RPC (Remote procedure call) encapsulé dans le protocole AMQP. Chaque service Openstack instancie deux queues : o Une queue pour recevoir les messages envoyés à tous les nœuds d’un même type, donc par exemple tous les Nova-Compute. o Une queue spécifique à serveur physique, afin d’envoyer une instruction correspondant à un serveur physique en particulier grâce à son ID. Par exemple instancier une VM sur un hyperviseur en particulier. Le Scheduler (Qpid Server) va servir de table de routage afin d‘aiguiller les messages. Il connaît la description de tous les nœuds ainsi que toutes les procédures que l’on peut appeler à distances. Les services recevant des messages AMQP comme NovaCompute, n’écoutent pas sur port particulier, mais maintiennent une liaison permanente en Unicast avec le serveur QPID. Au moment d’installer l’infrastructure, l’analyse des messages AMQP se révèle un très bon moyen pour comprendre les interactions entre les différents services, et nous renseigne sur les différents problèmes entres les services car les messages échangés sont stockés dans les Logs (Voir §1.6 exemple d’échange). En ce qui concerne le Scheduler, je n’ai pas eu besoin
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 69 d’aller analyser le comportement des queues de communication, car cette partie est correctement implémentée au sein des différents services. Figure5.2 résume les deux types d’échanges qui résident au sein d’OpenStack (extrait de http://docs.openstack.org/developer/nova/devref/rpc.html) : Figure5.2: Différents types de messages En 1, sont représentés les services réceptionnant les requêtes http provenant d’un client d’API (voir §1.4.1). Cette requête va être transformée sous forme de message AMQP (2), afin d’être distribuée au service concerné, par l’intermédiaire du QPID serveur. L’avantage de ce type de message est qu’il utilise un formatage prédéfini. Par conséquent, un même message peut être compris par différents langages de programmation et différents services. 1.4 Les services OpenStack : Pour fonctionner correctement, notre infrastructure Openstack a besoin de plusieurs éléments ayant des rôles bien spécifiques. Openstack est constitué de plusieurs services pouvant communiquer entre eux afin de gérer toutes les facettes de notre infrastructure. 1.4.1 Administration de l’infrastructure Openstack : Pour administrer notre infrastructure, deux solutions s’offrent à nous. En ce qui concerne l’envoi de commandes comme par exemple une création de VM se fait via des requêtes http à une API. Nous pouvons utiliser un client d’API (par exemple python-novaclient) CLI écrit en python, qui va se charger d’encapsuler dans une requête http les paramètres de la commande : nova boot --flavor 2 --image 397e713c-b95b-4186-ad46-6126863ea0a9 Réception des requêteshttp 1 2 http
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 70 Nous avons aussi la possibilité d’administrer notre infrastructure via une interface Web appelée Horizon Dashboard. Cette interface Web va se charger de communiquer avec les différentes API. L’utilisateur effectue une requête auprès du site Web Horizon, et le serveur Web se charge de dialoguer avec l’API en question. Figure5.3 : Interface GUI Horizon 1.4.2 Gestion de la virtualisation : Quand nous parlons de gestion de la virtualisation, nous devons piloter le module de virtualisation QEMU-KVM de l’hyperviseur, ainsi que les règles du firewall afin de contrôler les points d’entrées depuis le réseau public, pour cela nous avons besoin des services Nova. Trois éléments vont constituer cette gestion4 : Nova-API : Ce service propose une API qui pourra être utilisée via CLI en effectuant des requêtes REST par l’administrateur physique. Les requêtes envoyées par l’administrateur vont être redirigées via des messages AMPQ aux différents services pouvant remplir la tâche voulue par l’administrateur. Il pourra remonter des informations sur la VM, comme son adresse IP, ou recevoir des ordres de création de VMs. Nova-Compute : Ce service est installé sur l’hyperviseur et communique directement avec le module QEMU-KVM, grâce à la librairie libvirt. Il va traduire les messages AMQP reçu de Nova-API en commandes compréhensibles par KVM. Ordonnanceur OpenStack: Au sein d’une infrastructure possédant plusieurs hyperviseurs, un service d’orchestration doit être mis en place afin de pouvoir choisir judicieusement sur quel hyperviseur une VM va être démarrée. Nous avons deux types de techniques d’occupation des VMs sur l’hyperviseur :
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 71 ▪ Répandre : L’ordonnanceur essaie de répartir les VMs sur l’ensemble des hyperviseurs, afin d’équilibrer les charges entre chacun. Il va regarder celui qui a le plus de RAM disponible. ▪ Remplir : L’ordonnanceur essaie de remplir au maximum les hyperviseurs afin d’en solliciter un minimum. Cette technique est intéressante afin de réduire son empreinte écologique car un minimum de machines physiques est opérationnel. Par conséquent, celles activent risquent d’être surchargées en cas de pic de charge. Cependant l’ordonnanceur présente des limites au moment où les hyperviseurs ont des quantités de RAM hétérogènes. Si un hyperviseur possède beaucoup plus de RAM que tous les autres, malgré le fait que l’on favorise l’étalement, il sera plus sollicité à cause de son importante RAM disponible. Donc il est vivement conseiller d’avoir du matériel uniforme, ou que l’ordonnanceur ajoute dans son choix la quantité de vCPU disponible par hyperviseur. Pour effectuer les mesures de charges, chaque hyperviseur envoie à l’ordonnanceur sa quantité de RAM disponible. Cette mesure est effectuée à partir des profiles attribués aux VMs s’exécutant sur l’hyperviseur. Par conséquent, si une VM est éteinte la quantité de RAM physique qui lui est allouée est considérée comme consommée. Les valeurs sont statiques et non dynamiques. Nova-Network : Ce service est installé sur notre Network Node, il va physiquement faire la liaison entre le réseau public (rouge) et le réseau privé des VMs, car dans notre scénario la VM hébergeant un serveur Web doit pouvoir être interrogée depuis le réseau Internet global. Le service va interagir avec le firewall iptables, cette entité physique doit être vue comme un routeur. Le service Nova-Network va pouvoir proposer une IP public à une VM, pour cela il va utiliser la technique du floating IP (Voir §1.7). 1.4.3 Gestion de l’authentification (Keystone) : Le service Keystone situé sur le Cloud Controller permet d’offrir une gestion des identités et des autorisations d’accès pour les utilisateurs. Le service Keystone va permettre de contrôler de façon centralisée les accès aux différentes API. Le système de validation est basé sur un système de token. Ce système a été implémenté afin d’avoir des périodes d’accès limitées dans le temps. Nous pouvons également cloisonner les utilisateurs, car ils peuvent se voir attribuer un token qui leur permettra uniquement de créer des VMs, ou un autre uniquement pour la gestion des volumes de stockages. En somme nous pouvons créer des contrôles d’accès aux APIs. Comme nous avons une infrastructure de type PKI, le token signé est contenu dans un message CMS « Cryptographique Message Syntax5 », par conséquent Keystone est une autorité de certification (CA) 6. Figure5.5 représente les échanges d’authentification de l’administrateur désirant envoyer une requête à une API2 . 2 Opennebula. http://opennebula.org/.
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 72 Figure5.4 : Authentification Keystone A l’installation du service Keystone, de par son rôle d’autorité de certification, nous devons générer en local sur le Cloud Controller grâce à l’outil OpenSSL: ▪ La clé privée de la CA : Openssl genrsa -out /etc/keystone/ssl/certs/cakey.pem 2048 -config /etc/keystone/ssl/certs/openssl.conf ▪ Générer le certificat de la CA avec sa clé privée : Openssl req -new -x509 -extensions v3_ça -passin pass: None -key /etc/keystone/ssl/certs/cakey.pem -out /etc/keystone/ssl/certs/ca.pem -days 3650 -config /etc/keystone/ssl/certs/openssl.conf -subj /C=US/ST=Unset/L=Unset/O=Unset/CN=www.example.com ▪ Génération de la clé privée pour signer les Tokens : Openssl genrsa -out /etc/keystone/ssl/private/signing_key.pem 2048 -config /etc/keystone/ssl/certs/openssl.conf ▪ Génération du certificat pour vérifier les Token : Openssl req -key /etc/keystone/ssl/private/signing_key.pem -new -nodes -out /etc/keystone/ssl/certs/req.pem -config /etc/keystone/ssl/certs/openssl.conf -subj /C=US/ST=Unset/L=Unset/O=Unset/CN=www.example.com • Explications des points 1 et 2 du Figure5.4 : 1. Une fois la vérification Username/Password effectuée, Keystone va générer un token signé sous la forme d’un CMS en utilisant sa clé privée (Signing_key.pem) grâce à la commande OpenSSL: Openssl cms -sign -signer /etc/keystone/ssl/certs/signing_cert.pem -inkey /etc/keystone/ssl/private/signing_key.pem -outform PEM -nosmimecap -nodetach -nocerts - noattr User Name/Password Token (Format CMS) Requête http + Token Contrôle de la validité du Token Envoie de la réponse à la requête http Contrôle Username Password Si le certificat est valide Réponse de Keystone si OK 1 2
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 73 2. L’API envoie à Keystone le token reçu afin qu’il puisse vérifier sa signature grâce au certificat req.pem. 1.4.4 Les Bases de Données : Afin de stocker les différentes informations relatives à notre infrastructure, le Cloud Controller possède un serveur de base de données MariaDB7, qui est un dérivé de MySQL. Pour configurer OpenStack, je n’ai pas eu besoin d’effectuer des requêtes SQL, donc les contenus des bases sont présents à titre indicatif. Le serveur va posséder deux bases de données : ▪ Base Keystone : Contient les utilisateurs, les tokens délivrées, ainsi que leurs périodes de validités Aperçu des champs de la table user de la base Keystone : MariaDB []> use keystone; MariaDB [keystone]> describe user; Field Type Null Key Default Extra Id Name Extra Password Enabled Domain_id Default_project_id Varchar (64) Varchar (255) Text Varchar (128) tinyint (1) Varchar (64) Varchar (64) NO NO YES YES YES NO YES PRI MUL NULL NULL NULL NULL NULL NULL NULL ▪ Base nova : Contient toutes les informations des VMs, comme leurs informations réseaux, leurs caractéristiques, et également la liste des computes nodes à disposition : Comme par exemple la table « Computes_Nodes » : MariaDB []> use nova; MariaDB [nova]> describe compute_nodes ;
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 74 1.5 Profil d’une VM : Dans ce chapitre, nous allons étudier sur les différents éléments qui caractérisent une VM. Pour créer une nouvelle VM (ou instance chez Openstack), nous devons renseigner le Compute Node sur les caractéristiques techniques Hardware qu’elle possédera comme : ▪ Le nombre de VCPU ▪ La taille des disques durs ▪ La quantité de RAM virtuelle Ces caractéristiques sont regroupées par profils appelés « Flavors8 ». Ce système de profil simplifie grandement la tâche pour l’administrateur, du fait que sa VM aura un profil Hardware prédéfini. Voici une liste des Flavors disponible par défaut, mais que l’on peut éditer sans aucun problème : En ce qui concerne la distinction entre Disk et Ephemeral: Une VM peut avoir deux types de disques virtuels. Ces deux types de disques suivent le cycle de vie, ils seront donc supprimés au moment où l’on supprime la VM. Les disques virtuels au niveau de l’hyperviseur correspondent à un fichier. Figure5.5, illustre les deux disques que la VM a à disposition.
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 75 Figure5.5 : Disques virtuels d'une VM Les deux disques virtuels sous formes de fichiers sont stockés dans le dossier /var/lib/nova/instances/ du Compute Node, mais ce dossier pointe sur le serveur NFS du QNAP via le réseau de Storage Jaune : ▪ Disk (Bleu): Héberge la partition Root / de l’OS ▪ Ephemeral Disc (Rouge): Peut-être une deuxième partition pour la VM Au moment où l’on fait un fdisk -l dans la VM, voici les disques que nous voyons : Disque /dev/vda : 75.2 Go -> Root Disc Disque /dev/vdb : 21.5 Go -> Ephemeral Disc Ephemeral est en réalité l’ajout d’une deuxième partition à la VM. Quand nous regardons le fichier XML généré par Libvirt afin de créer la VM : <disk type="file" device="disk"> <driver name="qemu" type="qcow2" cache="none"/> <Sourcefile="/var/lib/nova/instances/84673e27-e948-49c0-a44f-a842aac7684b/disk"/> <target bus="virtio" dev="vda"/> </disk> <Disk type="file" device="disk"> <Driver name="qemu" type="qcow2" cache="none"/> Fedora 19 VM Fichier Disk0 Stockage NFS QNAP Dossier dans Compute Node : /var/lib/nova/instances/ Ephemeral /dev/vdb Disk /dev/vda Fichier Disk1
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 76 <sourcefile="/var/lib/nova/instances/84673e27-e94849c0a44fa842aac7684b/disk.local"/> <target bus="virtio" dev="vdb"/> </disk> Nous voyons bien la définition des deux disques, le premier est le Disk et le deuxième est le Ephemeral d’après le Flavor. Dans mon cas l’ajout d’un deuxième disque (Ephemeral), n’est pas d’une grande utilité, sachant qu’il va être détruit au moment de la suppression de la VM. Voilà pourquoi, j’ai mis en place une unité Cinder dans le §.2. 1.6 Processus de démarrage d’une VM : Figure5.6 résume les communications entre les différents services d’OpenStack : Figure5.6 : Démarrage d'une VMs 1. L’administrateur via l’interface Web ou une commande, indique le Flavor de la VM, la liste des Security Group. Tous ces paramètres sont envoyés à l’API Nova via une requête http. Par souci de lisibilité je n’ai pas représenté le contrôle d’autorisation avec Keystone (voir §1.4.3). Administrateur Démarrage de VM Nova-API Nova-Network Nova-Compute Nova DataBase QEMU-KVM VM IPTABLES Filtering IPTABLES NAT DHCP-Serveur 1 2 3 4 5 6 7 8 99 6 Protocole http Message AMQP Commande Système Protocole DHCP
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 77 Figure5.7 : Configuration de la future VM 2. Tous les messages AMQP doivent transiter par un QPID serveur que je n’ai pas représenté, également par souci de lisibilité. Nova-API envoie au service NovaCompute le profil de la VM qui va être créé Extrait des Logs AMQP de Nova-API : 3. Nova-Compute envoie à KVM, les caractéristiques reçues par message AMPQ, la VM démarre. Le service Nova envoie le profil complet de la VM à Libvirt (Extrait du fichier de log ne Nova Compute:
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 78 4. Le serveur DHCP envoie une IP à la nouvelle VM, et écrit dans un fichier la MAC IP /var/lib/nova/networks/nova-br100.conf : Fa:16:3e:20:1b:65, vm-test. Novalocal,192.168.1.8 5. Le service Nova-Network lit ce fichier 6. Nova-Network envoie les informations réseaux à Nova-API 7. Nova-API écrit dans la base de données les informations réseaux ainsi que les caractéristiques de la nouvelle VM. Extrait de la table « instances » de la DB Nova : 8. Les informations de Floating IP sont envoyées au Nova-Network et les securitygroup au Nova-Compute 9. Les deux services vont configurer les règles NAT et Filtering des Iptables. 1.7 Réseau des VMs : Dans ce chapitre nous allons étudier en détail la gestion du Floating IP, ainsi que les Security Group, au niveau IPTABLES et interfaces physiques, en faisant abstraction des services Openstack. ▪ Le Floating IP : Le Floating IP est utilisé pour attribuer une IP public à une VM. Dans notre exemple, la VM va posséder comme IP public : 129.194.184.85. Le principe est de rajouter une deuxième adresse IP sur une carte Ethernet physique. Dans notre cas, la carte Eth2 possède l’adresse IP : 129.194.184.91 et grâce au IP Alias nous ajoutons une seconde adresse IP : 129.194.184.85. Il est possible de rajouter N IPs flottantes sur cette interface physique, correspondant aux IPs Publics de N VMs. IP Alias est une fonction intégrée dans le kernel linux. Pour afficher la configuration des IP Flottantes sur la carte réseau eth2, nous ne pouvons plus utiliser la commande ifconfig devenue obsolète. Il faut utiliser les outils plus élaborés comme le package iproute2, avec la commande ip :
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 79 ▪ Trajet (Vert) d’un paquet http venant du réseau public : Figure5.8 : Gestion de l'IP flottante Nous supposons que les Security-Group et le Floating IP ont déjà été configurés par les services Nova-Network et Nova-Compute. Je vais analyser le contenu des IPTABLES-NAT et IPTABLES-Filtering. La règle de Security-group est d’autoriser uniquement le trafic IP à destination du port 80. 1. Le client envoie une requête http au serveur Web possédant l’adresse IP 129.194.184.85. Le paquet traverse l’interface Eth2 ayant l’allias 129.194.184.85. Pour afficher le contenu des tables NAT d’Iptables, nous faisons : iptables -S -t nat Voici un extrait de la table NAT de l’IPTABLES : nova-network-PREROUTING -d 129.194.184.85/32 -j DNAT --to-destination 192.168.1.2 Compute-Node Network node Eth2 Eth1 vSwitch Eth1 vSwitch VM Fed-19-Web IP: 192.168.1.2 SRV DHCP IPTABLES-NAT Eth0 Eth2Eth0 IPTABLES-Filtering Réseau Public Client IP : 109.190.146.132 Requête http sur 129.194.184.85 IP Eth2 : 129.194.184.91 Alias : 129.194.184.85 1 2 3 LAN Management LAN Privé des VM
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 80 Les paquets ayant comme IP destination 129.194.184.5 sont redirigés vers l’adresse IP 192.168.1.2. IPTABLES va modifier l’adresse IP de destination par 192.168.1.2. Nous pouvons le voir en faisant un TCPDUMP -i eth1 : 109.190.146.132.50875 > 192.168.1.2. Http 3 2. Le paquet sort du Network-Node via l’interface Eth1 et rentre dans le Compute Node, mais avant d’arriver à la VM le paquet va être filtré par IPTABLES-Filtering qui a été modifié à partir des Security-Group : Nova-compute-inst-9 -p tcp -m tcp --dport 80 -j ACCEPT Les paquets à destination du port 80 de la VM (nova-compute-inst-9) sont autorisés. Il faut voir ces règles de Security comme des règles de Firewalls de types statefulls. Nous contrôlons les paquets qui viennent du réseau Public en direction de la VM. Ces règles vont être traduites en règles IPtables. Voici une capture d’écran concernant les règles IPtables de l’interface Horizon pour autoriser l’ouverture du port 80: Figure5.9 : Security-Group sous Horizon 3. En faisant un TCPDUMP dans la VM nous voyons le paquet possédant l’adresse source du client : 109.190.146.132.52353 > 192.168.1.2. http En conclusion nous voyons que toutes les règles de filtrage et de NAT doivent être dynamiques car la VM ou le Floating peuvent changer d’adresse IP, il est primordial que les différents services Nova-Network et Nova-Compute fassent remonter les informations et puissent être contrôlés depuis un système centralisé : Nova-api. 1.8 Stockage par fichier des VMs : Plusieurs architectures de stockage s’offrent à nous. Le stockage des disques virtuels des VMs doit être externe à l’hyperviseur, afin d’avoir une unité de stockage centralisée, pour pouvoir effectuer de la live-migration et faciliter la gestion des systèmes de stockages. Mais l’OS de l’hyperviseur physique est lui stocké sur son propre disque dur. Le fait d’avoir un réseau dédié (jaune) a l’avantage de pouvoir augmenter les débits grâce à l’activation par exemple des Jumbo Frames. 3 ] redhat. http://www.redhat.com/products/cloud-computing/cloudforms/
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 81 Cette architecture est moins performante qu’un stockage par bloc, car le système de fichier est hébergé du côté du serveur de stockage. Cependant, grâce au NFS, nous pouvons avoir un système de fichier partagé simple. Comme représenté sur le schéma global en §1, le stockage du disque virtuel de la VM est hébergé sur le QNAP. Il serait Judicieux d’ajouter un second système de stockage, mais cette fois-ci, il devra être par bloc et être persistant. En effet, si la VM est supprimée l’unité de stockage reste. L’étude de l’unité Cinder se fera au §2 1.9 Conclusion du Scénario 1a : A travers ce scénario, j’ai pu comprendre les interactions entre différents services qui évoluent au sein de mon infrastructure. J’ai passé beaucoup de temps dans la compréhension des interactions entre ces différents éléments. En effet, la documentation OpenStack au niveau de la configuration des services est relativement bien étoffée. Cependant le rôle que remplit chaque service est beaucoup moins bien documenté, c’est pour cela que j’ai dû analyser de nombreuses lignes de Logs, aller voir dans le code-source des différents services. L’infrastructure Openstack peut être qualifiée de complexe, de par ces nombreux systèmes qui s’imbriquent les uns dans les autres. Les différents services doivent en permanence communiquer entres eux, car nous sommes dans un milieu totalement dynamique. 2. Scénario lb : Gestion du stockage par bloc : A travers ce scénario, je vais explorer les stockages par bloc proposés par le Projet Cinder9. Cinder est un service OpenStack permettant de créer des volumes par bloc gérés par le protocole iSCSI. Cette unité de stockage n’est plus créée par l’ordonnanceur au démarrage de la VM, mais par l’administrateur, donc il ne va plus suivre le cycle de vie de la VM, du fait que lorsqu’elle sera détruite, ce volume ne sera pas supprimé. L’avantage d’un volume comme celui-ci permet d’héberger des données persistantes. Par exemple ce volume pourrait être monté au niveau du dossier /var/www (emplacement contenant généralement les pages web sur un serveur web), si la VM est hors-service, on pourra en démarrer une autre et lui ajouter ce volume à cette nouvelle instance. 2.1 . Schéma du scénario lb :
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 82 Schéma 5.2 : Scénario 1b 2.2 Composition de Cinder : Sur le schéma 5.2, j’ai ajouté un élément physique Cible-iSCSI-Cinder. Cet élément va être piloté par le service placé dans le Cloud Controller : Cinder-api. Cinder est composé de deux éléments : ▪ Cinder API: Va recevoir les commandes envoyées par l’utilisateur via une requête REST contenant par exemple la taille du volume à créer et sur quelle VM il faut greffer le volume. ▪ Cinder Volume : Ce service va communiquer directement avec l’unité de stockage. Plusieurs possibilités s’offres nous, cette communication va se faire via l’utilisation de différents drivers : o Piloter la création de cible iSCSI situé dans un SAN propriétaire comme SolidFire10 o Un Cinder-Volume qui contient un serveur iSCSI et un volume LVM. L’API Cinder va piloter la création de la cible iSCSI afin de l’attacher à la VM, en fournissant à Libvirt l’IQN de la cible iSCSI11 2.3 Fonctionnement de Cinder :
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 83 Schéma 5.3 : Attribution d'un volume par bloc Cinder-Volumes communique avec le serveur iSCSI pour créer une nouvelle cible pour la VM en question. La chaîne de lancement pour créer une unité de stockage par bloc est décrite par les numéros turquoise dans le schéma 5.3 : 1. L’administrateur envoie une commande de création d’un volume via l’api Cinder, via une requête http, contenant la taille du volume et sur quelle VM le greffer ou par CLI : cinder create --display_name Test_Vol 3GB 2. Cinder-API va envoyer un message AMPQ à l’unité de stockage (Cible-iSCSICinder 3. Le service Cinder-Volume communique avec le manager de cible iSCSI intégré à Fedora « tgtadm ». Extrait du code source de Cinder indiquant l’appelle au service « tgadm » : 4. Une fois la cible iSCSI créée, le service Cinder-volume envoie à Cinder-API les informations de la cible iSCSI qui va les relayer à Nova-API, et va créer une nouvelle entrée pour ce volume dans la base de données MySQL Compute Node Cinder-Volume LVM Volume iSCSI Tgt Cinder-API Nova-Compute Controller Node Nova-API DB Cinder Administrateur : Création d'un volume à attaché à la VM KVM VM AMPQ AMPQ REST iSCSI Commandes Tgt 1 3 2 4 5 6 Cible-iSCSI Cinder
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 84 5. Nova-API envoie l’ordre d’ajout d’un nouveau volume à Nova-Compute, qui va transférer ces informations à KVM. Voici un exemple du template généré par Libvirt pour décrire la configuration du nouveau volume iSCSI: 6. La VM possède un nouveau volume monté en /dev/vdc : 2.4 Problèmes rencontrés : J’ai eu quelques problèmes en ce qui concerne l’analyse de Cinder-API et Cinder- Volume, du fait que la plupart du temps, Cinder Volume est couplé avec un SAN propriétaire. La documentation indiquant comment faire fonctionner Cinder-Volume avec le gestionnaire de cible iSCI (tgtadm) intégré à Linux n’est pas très riche. Un des gros problèmes avec la documentation OpenStack, est d’interpréter sur quelle unité physique tels ou tels services s’installent. Dans la théorie, chaque service peut s’installer sur n’importe quelle entité physique. Mais dans le cas du Cinder-volume qui pilote la cible iSCSI, il faut qu’il soit installé sur le même serveur physique que le LVM Volume, car le service python fait des appels de commandes en local. 2.5 Conclusion du Scénario lb : A travers ce scénario j’ai pu ajouter un volume persistant à une VM. De plus, ce volume est un stockage par bloc interrogeable via le protocole iSCSI. Comme application, nous pourrions héberger une base de données MySQL, afin d’avoir des performances plus élevées que si nous avions uniquement un stockage par fichier NFS. L’unité Cinder possède un gros avantage de flexibilité, grâce à l’ajout dynamique d’unités de volume. III. Scénario 2 : Haute Disponibilité du Cloud Controller : Au cours des scénarios précédents, nous avons obtenu une infrastructure fonctionnelle, accueillant des VMs pouvant héberger nos applications métiers. Cependant, il réside un gros point faible dans notre infrastructure, concernant un de nos composants de gestion. En effet, si le Cloud Controller venait à être hors-service, il nous serait alors impossible de gérer nos VMs ou d’en créer de nouvelles. Par conséquent, nous devons repenser l’infrastructure afin de mettre en place des systèmes redondants pour limiter au maximum des situations d’échec. Ceci pourra être mis en place grâce à des mécanismes permettant de construire un environnement de Haute- Disponibilité (High Availability -> HA).
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 85 De nombreuses solutions de HA existent, mais parfois, elles peuvent vite représenter une lourdeur supplémentaire, et par conséquent compliquer grandement notre système en risquant de le rendre instable. A travers ce chapitre, je vais faire cohabiter plusieurs types de HA, qui auront toutes un rôle précis pour chaque élément que je dois rendre disponible. 1. Qu'est-ce que la HA : La HA peut être appliquée sur une multitude de services afin de garantir un service opérationnel. Comme le montre le schéma de principe 14, il faudrait par exemple que l’administrateur puisse toujours démarrer des VMs, donc grâce à la HA, nous allons lutter contre les indisponibilités, en installant un second Cloud Controller physique (voir schéma 5.7 du Scénario 2 pour un contexte réel) afin de dupliquer les services. 1 2 3 HA Active/Passive Stateless HA Active/Active Stateless HA Active/Active Statefull Schéma 5.4 : Principe de HA Le schéma 5.4, montre les différents types de mécanismes de HA appliqués à chaque élément de mon infrastructure. Dans les points suivants, je vais m’intéresser uniquement aux éléments 1 et 2, la HA SQL (élément 3) sera traitée au §3. 1.1 La HA Active/Active : Ce type de HA (Elément 2 Schéma 5.4) oblige la mise en place de deux serveurs physiques Master + Master (Cloud Controller 1 et 2) ayant les mêmes services installés et démarrés. Par conséquent les deux serveurs sont en permanence actifs, ce qui limite les temps d’indisponibilité au moment de la mise en échec d’un des deux. Comme les deux serveurs peuvent répondre aux requêtes, j’ai dû installer un load balancer qui se charge de répartir les charges entre mes deux serveurs. C’est-à- dire que le client s’adresse au Load Balancer (Flèche Verte) et ce dernier va aiguiller les paquets vers les serveurs disponibles (Flèches Bleues). Ce service de load balancing sera géré par HAProxy (voir §2.4 pour le fonctionnement de HAProxy). Comme tout le trafic traverse le load balancer, il présente un « point of failure », par conséquent, nous devons intégrer la HA pour cet élément, mais qui ne pourra pas être traité avec de la HA Active/Active. 1.2 La HA Active/Passive : Ce type de HA met en place deux serveurs : Master + Salve. Sur ces deux serveurs sont installés les mêmes services, mais sur le MASTER ils sont démarrés, tandis que sur le SLAVE ils sont stoppés. Voici un schéma représentant le système : API OpenStack Load Balancer 1 Load Balancer 2 Nova 1 Nova 2 Cinder 1 Cinder 2 Horizon 1 Horizon 2 Client Envoie requêtes http Roundrobin Echange IP virtuelle KeepAlived Noeud1 MySQL ou MariaDB Noeud2 MySQL ou MariaDB Réplication des Données Cluster MySQL
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 86 Si les services ne sont pas ON, le Slave démarre son service Schéma 5.5 : HA Active/Passive Si un des services ne répond plus, l’autre service va démarrer sur le SLAVE. Le problème de ce type de HA, est que le SLAVE a ces services OFF, donc nous pouvons avoir un temps d’indisponibilité important entre le moment où le service commence son démarrage et devient opérationnel. En effet, le script de démarrage du service peut effectuer de nombreuses tâches, comme par exemple, se connecter à une base MySQL et attendre la réponse du serveur QPID. Ce type de chaîne de lancement au sein des services Openstack est couramment utilisé. J’ai implémenté ce type de HA uniquement au niveau du load balancing (Elément 1). En effet, l’intégration d’un deuxième Load Balancer considéré comme Slave est primordial mais seul l’un des deux sera actif. Dès que le Master ne répondra plus, le Slave prendra le relai. Le client s’adresse à l’un des loads balancer via une adresse IP Virtuelle, qui sera gérée par un service choisissant quel load balancer se verra attribuer cette IP. 1.3 L’IP flottante ou virtuelle : Pour avoir un système basé sur de la HA Active/Passive avec deux load balancer, l’un des deux doits pouvoir répondre aux requêtes. Pour cela nous allons utiliser le principe d’IP flottante comme vu dans §1.7. Ce service géré par « Keepalived13 », va attribuer une adresse IP supplémentaire (virtuelle) sur le Serveur actif. L’utilitaire installé sur les deux serveurs va tester si un service est ON, s’il ne l’est pas, l’IP flottante passe du Master au Slave. Service 1 (ON) Service 2 (ON) Service 3 (ON) Service de Controle de HA (ON) Service 1 (OFF) Service 2 (OFF) Service 3 (OFF) Service de Controle de HA (ON) Slave teste si les services du MASTER sont toujours ON
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 87 Schéma 5.6 : Gestion IP virtuelle D’après le schéma 5.6, grâce à cette technique le client aura toujours la même IP de destination mais ne s’adressera pas toujours au même Load Balancer. Les deux services Keepalived communiquent entres eux via le protocole VRRP14 (Virtual Router Redundancy Protocol), pour que le Master transmette au Slave l’échec de son service. Ce protocole permet l’élection d’une passerelle possédant l’IP flottante, afin qu’il puisse répondre aux requêtes ARP (voir §2.5 pour un cas concret). 1.4 Services Stateless ou Statefull : Les services ne réagissent pas tous de la même manière au moment où ils sont dupliqués. C’est pour cela que nous devons gérer la haute disponibilité différemment si nous sommes en présence de services Stateless ou Statefull. ▪ Services Stateless : Un service n’a pas besoin de connaître son état précédent, donc les services dupliqués n’ont pas d’obligation à communiquer entre eux afin de se partager leurs états. Par exemple, les Services d’API OpenStack sont Stateless, ils sont indépendants les uns des autres. ▪ Services Statefull : Un service dit Statefull est obligé de connaître son état précédent pour répondre à une requête. Donc au moment où nous implémentons de la HA Statefull, nous devons Rajouter un système de réplication, afin de propager la donnée au sein de tous les services redondants. Par exemple, une base de données est un service Statefull. La donnée que l’on a écrite de sur un nœud SQL doit être propagée dans tous les autres nœuds SQL. Les notions Statefull et Stateless sont indépendantes de la HA Active/Active ou Active/Passive. En effet, nous pouvons très bien travailler en Active/Passive avec des services Statefull. Le service Master envoie son état au Slave qui est off, afin que ce dernier possède l’état du Master au moment où il démarrera.
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 88 2. Scénario 2 : La HA au sein des AP] OpenStack : Dans ce scénario, je vais implémenter la HA au sein de mon Cloud Controller sur l’ensemble des API qui composent mon Infrastructure OpenStack : ▪ Interface Web Horizon ▪ API Nova ▪ API Cinder ▪ API Keystone J’ai choisi d’installer les bases de données MySQL (Keystone DB, Nova DB et Cinder DB) sur une autre machine physique, afin de ne m’attarder que sur la HA au niveau des requêtes http avec les API. En effet la HA MySQL doit être traitée avec une approche différente. Pour rappel, le contact d’une API se fait par l’envoi d’une requête http. L’API écoute sur un port particulier. Le schéma 5.7 résume la cohésion entres les différents éléments physiques au moment où un administrateur envoie une requête sur l’interface web Horizon écoutant sur le port 80. Pour mettre en place ce scénario, je me suis basé sur la documentation fournie par RedHat 15 et Mirantis 16 (société fournissant des services dans l’implémentation d’OpenStack). 2.1 Schéma du scénario 2a : Schéma 5.7 : HA au sein de l'API OpenStack 2.2 But du Scénario : Sans intégration de HA, avec l’infrastructure du Scénario 1, au moment où l’on stoppe un des services d’API OpenStack tel que Nova API nous obtenons ce message d’erreur : Horizon Port : 80 Nova-API Port : 8774 Cinder-API Port : 8776 Keystone Port : 5000 HAProxy Eth0 10.2.4.101 KeepAlived Horizon Port : 80 Nova-API Port : 8774 Cinder-API Port : 8776 Keystone Port : 5000 HAProxy Eth0 10.2.4.106 KeepAlived Cloud Controller 1 Cloud Controller 2 Utilisateur Navigateur Web Echange Multicast pour savoir où est placé l'IP virtuelle Redirection depuis le HAProxy vers les 2 API disponibles IP Virtuelle : 10.2.4.100
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 89 A travers ce scénario, je vais limiter l’apparition de ce message en ajoutant un second Cloud Controller permettant de répondre également aux requêtes de l’administrateur et de prendre le relais en cas de défaillance du Controller 1. Lorsqu’un câble réseau du Controller 1 de l’interface Eth0 est débranché pour simuler une panne générale, il sera alors toujours possible de gérer la création de VMs. En réalité, le paquet a été aiguillé vers le Controller 2. 2.3 Éléments physiques : Au niveau des machines physiques, j’ai quasiment la même infrastructure que dans les scénarios précédents, j’ai ajouté un deuxième Cloud Controller qui possède la même configuration que le premier. Pour avoir de plus amples détails à propos du paramétrage des différentes machines physiques, voici mon dépôt Github : https://github.com/hepiatelecom- labs/Openstack_Config/tree/master/Object_config/HA qui regroupe les fichiers de configuration utilisés dans mon infrastructure. 2.4 HA Active/Active avec HAProxy : Ce type de HA comme vu au §1.1 est assuré par un Load Balancer Open Source HAProxy. Je l’ai installé sur les deux Cloud Controllers afin de ne pas dédier deux machines physiques à cette tâche et de garantir la HA sur les Load Balancer au cas où l’un d’eux serait non-opérationnel. Voici une partie de la configuration de HAProxy afin de comprendre les interactions entre les IP des serveurs physiques et l’IP virtuelle pour une requête émise par l’administrateur au serveur web horizon : La configuration du HAProxy doit être identique sur les deux Controller. Le Proxy écoute sur le port 80 au niveau de l’IP virtuelle (10.2.4.100) et va aiguiller les paquets sur les serveurs situés en backend (controller-1 et controller-2). La technique d’aiguillage est basée sur le RoundRobin, c’est-à-dire que la charge va être répartie équitablement sur les deux serveurs web des deux Controller. Il va également tester le serveur cible à qui il choisit d’envoyer le
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 90 paquet, en faisant par exemple une requête http sur le port d’une API. Si l’API du controller-1 ne répond pas, il va aiguiller le paquet sur controller-2. 2.5 HA Load Balancer avec KeepAlived : KeepAlived va assurer la disponibilité des Load balancer, en étant installé sur les deux Controller. Voici un extrait des deux fichiers de configurations des deux services KieepAlived : Les deux KeepAlived communiquent entre eux par VRRP, ils possèdent le même « virtual_router_id » que l’on peut apparenter à leur fréquence de communication. L’attribution de l’adresse IP Virtuelle est basée sur un système d’élection entre les deux KeepAlived. Comme nous le voyons dans les fichiers de configuration, j’ai arbitrairement choisi que le Controller 1 dans un fonctionnement normal serait MASTER, de par sa priorité qui est de 101 et de son état initial (state) MASTER. Au moment où deux KeepAlived démarrent en même temps, ils procéderont à l’élection du Master : celui qui a la plus haute priorité possède l’IP virtuelle4 . Le service KeepAlived va tester toutes les 0.1 secondes l’état du service, dans le cas où il est STOP le Master passe en Backup et transmet l’IP Virtuelle au deuxième KeepALived. Dans mon infrastructure de HA, la relation Active/Passive, est uniquement présente dans la gestion de l’IP Virtuelle administrée par KeepAlived, car il n’y a qu’un seul Load Balancer qui peut répondre à la fois. Autrement, passé les Load Balancers, tous les services OpenStack font de la HA Actif/Actif. 2.6 Bilan Scénario 2a : Ce scénario m’a permis de comprendre comment fonctionne la HA. De plus, un certain nombre d’éléments interviennent dans cette topologie et il est donc important de comprendre comment ils interagissent entres eux. A la fin de ce scénario, au moment où je débranche le câble réseau de mon Controller1, je peux sans autre continuer à naviguer sur mon interface web, et gérer mes VMs sans pertes de connexions. Pour visualiser l’échange d’IP Virtuelle nous pouvons analyser les Log, en faisant : 4 Salesforce. http://www.salesforce.com/fr/.
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 91 A travers ces extraits de Log nous voyons bien que la transition de l’IP Virtuelle se fait très rapidement, de l’ordre de quelques secondes, ce qui explique que pour l’administrateur, le fait de perdre un des deux Controller est totalement transparent. Il ne va détecter aucune interruption de service. Au niveau de cette architecture de HA, j’ai installé deux Cloud Controller, mais il serait aisé de rajouter N autre Cloud Controller. Il faudrait juste ajouter l’IP des nouveaux serveurs backends dans le fichier de configuration de chaque HAProxy et modifier les priorités des KeepAlived dans leurs fichiers de configurations. Avec la HA Active/Active, l’ajout d’un grand nombre de Controller permet également une meilleure répartition des charges entre tous les Cloud Controller grâce au Load Balancer. Un problème réside à travers ce scénario, comment détecter la perte d’un Controller du fait que les échanges de Load Balancing se font automatiquement. Par conséquent pour déceler un problème, il est indispensable de se connecter sur chaque Controller et faire défiler les Logs à la main. Par la suite, il serait judicieux de mettre en place un système de monitoring avec Shinken, qui permettrait d’automatiser les tests de disponibilités pour que nous soyons alertés automatiquement des éventuels problèmes de pertes de services. De plus, la mise en place d’un serveur centralisé de Logs est indispensable, afin de faciliter leurs analyses en cas de panne. 3. HA SQL (Active/Active Statefull) : Dans ce chapitre, je vais traiter de la haute disponibilité au niveau des bases de données SQL. Comme nous l’avons vu en §1, nous sommes en présence d’un système Actif/Actif Statefull. Voici les lignes directrices de mise en œuvre, afin de comprendre au mieux les interactions entre les différents nœuds SQL. Pour effectuer de la HA, au niveau de notre base
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 92 de données, nous allons dupliquer cette base au sein de plusieurs nœuds, et l’ensemble des nœuds va constituer notre Cluster. 3.1 Schéma du Cluster SQL : Schéma 5.8 : HA au niveau SQL Le schéma 5.8 nous illustre une vue globale des différents types de HA qui interviennent uniquement au niveau de la partie SQL. Cette représentation montre un client qui désire écrire dans une base de données. L’élément omniprésent pour une HA Active/Active est le Load Balancer, qui va répartir les requêtes de manière round robin auprès des différents serveurs SQL. Depuis l’entrée en fonction de Fedora 19, le serveur MariaDB remplace le serveur MySQL suite au rachat de ce dernier par Sun Microsystems. 3.2 Théorème du CAP : Ce théorème basé sur la conjecture « Brewer’s Conjecture » réalisé par le Professeur Eric Brewer de l’université de Berkley, a été prouvé par Nancy Lynch et Seth Gilbert du Massachusetts Institute of Technology. Il énonce qu’un système distribué est régi par trois contraintes :
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 93 ▪ Consistance (Cohérence) : Le fait d’avoir la même donnée sur tous les nœuds à un instant. ▪ Availability (Disponibilité) : Les clients peuvent en permanence trouver les données. ▪ Résistance au morcèlement (Partition Tolérance) : Le système fonctionne malgré des problèmes réseaux. Mais d’après ce théorème, le système ne peut pas se trouver dans plus de deux états à la fois. Prenons un exemple : Si l’on favorise la cohésion des données, les utilisateurs devront attendre que tous les nœuds se synchronisent entres eux avant de pouvoir effectuer une opération d’écriture ou de lecture. Si l’on favorise la disponibilité des données, comme dans le cas de Google, un utilisateur effectuant une recherche et obtenant un résultat, ne va pas forcément obtenir le même résultat qu’un autre. L’importance de ce système est de pouvoir retourner un résultat, bien que la cohérence de ce dernier ne soit pas la règle prioritaire. L’accent est effectivement mis sur la disponibilité. Schéma 5.9 : Théorème du CAP Le schéma 5.9 résume les trois états où peut se situer le Cluster. Dans notre cas, notre Cluster de base de données se situera dans la partie Consistency et Availability. L’accent sera donné sur la consistance des données. Par exemple, il est primordial que la base qui héberge les informations des VMs soit en permanence synchronisée, car si elle nous retourne une information fausse, toute notre prise de décision à propos du management des VMs sera erronée. Au final mieux vaut un petit temps de latence dû à la synchronisation, mais permettant d’obtenir des données crédibles. 3.3 Gestion du Cluster SQL :
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 94 Comme nous pouvons le voir sur le schéma 5.8, les deux nœuds SQL sont basés sur Fedora 19, et les bases sont gérées par MariaDB. Comme je l’ai énoncé plus haut, la HA est de type Statefull, donc nous devons mettre en place un système de réplications des données ainsi que la gestion de la disponibilité de notre Cluster SQL. ▪ Galera : Un outil Open Source qui va gérer la consistance des données au sein de notre Cluster. Sa mise en place est très bien documentée : https://wiki.deimos.fr/MariaDB_Galera_Cluster_:_la_réplication_multi_maitres Je ne l’ai pas mis en place du fait que sa mise en pratique ne rentrait pas dans le périmètre du projet. Comme je l’ai indiqué dans §3.2, nous portons une attention toute particulière à la consistance des données auprès de tous les nœuds. Donc avant que le client reçoive un ACK l’informant que sa donnée est bien écrite dans la base, il faut que tous les nœuds soient synchronisés. L’avantage de mettre en place Galera, est que tous les nœuds de notre Cluster peuvent recevoir des requêtes, et donc nous avons l’abolition de la relation Master/Slave présente au sein d’un Cluster SQL standard ne possédant pas cette surcouche. Le point négatif de ce système, est que tant que la réplication n’est pas acquittée par tous, le cluster ne peut pas recevoir de requête supplémentaire. Donc le temps de traitement de la requête dépendra intrinsèquement du nœud le plus lent. IV. Scénario 3 : Collecte et entreposage des Logs : Comme indiqué ci-dessus, avec la topologie du scénario 2, il m’est impossible de diagnostiquer l’état des services OpenStack. Grâce à ce scénario, mon infrastructure Openstack va pouvoir réellement héberger une application qui permettra le stockage des Logs. Ce scénario va porter sur l’étude de différentes variantes d’acheminement des Logs à une base de données dédiée. De par la complexité de l’infrastructure, ainsi que des multiples services qui
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 95 interviennent au sein d’un Cloud OpenStack, il devient nécessaire d’avoir un point central qui récupère les Logs, en vue d’une analyse du comportement des services. 1. Cahier des Charges : Les Logs sont des éléments essentiels dans la gestion d’un Système d’Information. Ils servent à analyser son comportement ou déceler diverses erreurs. Mais le gros problème réside dans le fait qu’ils sont souvent répartis sur différentes machines physiques, ce qui rend impossible la vision globale de l’état du système. LeShop.ch au sein de son infrastructure récolte des centaines de milliers de lignes de Logs/min provenant de ses différentes applications métiers. LeShop.ch demande : ▪ La mise en place d’une infrastructure de stockage centralisée des Logs générés par les services d’OpenStack ▪ L’entreposage de manière durable au sein d’une base de données (DB) dédiée aux Logs ▪ La mise en place d’un moyen de visualisation des Logs, afin de déceler divers problèmes ou effectuer des recherches rapides dans la base de données 2. Contraintes : La liste des contraintes : ▪ La DB stockant les Logs doit se situer sur des VMs ▪ L’accent doit être mis sur la disponibilité des données. Par conséquent, il faut que la DB soit toujours disponible malgré la perte de deux VMs ▪ Il faut scinder au maximum les rôles de chaque VM intervenant dans la chaîne de traitement des Logs. Dans le cas contraire, en regrouper une majorité au sein d’une VM, va charger à 100% sa RAM et son CPU et risque de faire crasher ses services ▪ La suite d’outils développée en JAVA donc veiller à optimiser la Java Virtual Machine ▪ Travailler en temps réel, du fait que les Logs affluent continuellement ▪ Intégrer au maximum des éléments de HA en essayant de dupliquer au maximum les services. Comme ils sont installés sur des VMs, le fait de les dupliquer ne demande pas de ressources physiques supplémentaires 3. Variantes de stockage de Logs : Pour mettre ces variantes sur pieds j’ai suivi ce très bon lien proposé par le CERN : http://indico.cern.ch/getFile.py/access?contribId=57&sessionId=1&resId=0&materialId=sli des&confId=220443 Quatre variantes vont être étudiées, qui vont se baser sur ces éléments communs :
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 96 ▪ DB ElasticSearch: DB Clés-Valeurs qui stockera les Logs ▪ Serveur physique stockant les Logs : envoyés par les différents services OpenStack grâce au protocole Syslog, de manière temporaire, avant de les envoyer à la DB. Le fonctionnement du serveur sera développé dans la variante 1 ▪ Outil de visualisation des Logs : Kibana: Se matérialise par un serveur Web s’exécutant du côté de l’administrateur désirant avoir une vue d’ensemble des Logs dans le but de rechercher quels services génèrent des Logs d’erreurs 3.1 Variante 1 : Stockage des Logs sous forme de fichiers : Cette variante vise à mettre en place un serveur physique de Logs sous forme de fichier. Les différents services d’une distribution vont écrire dans un fichier tous leurs événements. Les services ont la possibilité d’être plus ou moins prolixe, nous avons le mode Debug, où un maximum d’informations sera stocké dans les Logs. Mais il est très utile pour analyser le comportement d’un service, et analyser quels messages il reçoit ou envoie. De base, chaque fichier de Logs des services est hébergé en local sur la machine physique qui l’exécute. Cette architecture ne permet pas une analyse aisée car il faut se connecter sur chaque machine physique pour interroger les Logs en local. Donc il faut absolument mettre en place une architecture qui centralise les Logs. L’infrastructure est la même qu’en §2.1, mais un PC qui va héberger les Logs de tous les services a été ajouté. Schéma 5.10 : Récolte des Logs en un point central A travers le schéma 5.10, nous avons tous les services OpenStack qui envoient leurs Logs via le client Syslog-ng au serveur de Log. Syslog-ng est un package Open Source qui regroupe les fonctions client-serveur en ce qui concerne l’envoie des Logs via le protocole Syslog. Chaque client va établir une connexion avec le serveur Syslog afin de lui envoyer les Logs des services qu’il héberge. Et ensuite le serveur va stocker en local, les différents Logs en les séparant dans différents fichiers en fonction des règles de filtrages que j’ai construites.
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 97 ▪ Les Logs des services OpenStack : Chaque service Openstack stocke ces Logs en local sur la machine physique qui l’héberge. Voici un exemple de Log généré par le service Nova-Network stocké dans /var/log/nova/nova.conf du Network Node: La majorité des Logs sont des messages AMQP à cause de l’activation du mode Debug. ▪ Problématique de la provenance des Logs : Comme nous avons pu le voir dans l’exemple du message précédent, en voyant uniquement cette ligne nous ne savons pas par quel service a généré cette ligne, excepté en faisant la commande : nano /var/log/nova/network.log sur le Network Node. Ceci est un problème car sur le Serveur de Log, il serait intéressant de répartir les Logs au sein de différents fichiers propres à chaque service et répartis dans différents dossiers correspondants à chaque entité physique. Voici un exemple de configuration que nous aimerions avoir sur notre Serveur de Logs. Serveur Log Pour cela les clients Syslog ne vont pas parcourir les différents fichiers de chaque service, ils vont interroger et envoyer les lignes s’ajoutant au fichier /var/log/messages. J’ai choisi d’envoyer les lignes qui s’ajoutent dans ce fichier car les éléments qui s’y inscrivent possèdent un formatage plus simple à extraire. Voici un extrait du /var/log/messages/ du Network-Node :
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 98 Comme nous pouvons le voir, les lignes générées dans ce fichier centralisent les Logs de tous les services indexant leur journal d’événement. De plus le formatage des lignes est généré en suivant le standard proposé par la RFC3164. Le message est constitué d’un HEADER : ▪ Dec 1 03:27:37 : Timestamp, à quelle date et heure a été généré le message ▪ Network : La machine physique qui a généré le message ▪ Nova-network [10131] : Le nom du processus avec son numéro de PID qui a généré cette ligne Au final, les Logs sont centralisés sur notre serveur de Logs, mais sous la forme de fichier. A ce stade, pour analyser le comportement des services OpenStack, nous sommes toujours limités par la lisibilité des Logs. Pour ce faire, l’idéal serait de pouvoir les interroger depuis une interface Web. De plus le stockage des Logs sous forme de fichiers est un grand consommateur d’espace disque. 3.2 Variante 2 : Logstash-­‐> ElasticSearch : Schéma 5.11 : Producteurs de logs -> Consommateurs Le schéma 5.11 représente la chaîne de traitement qui va acheminer les Logs contenus sous forme de fichier jusqu’à une DB dédiée à ce stockage. Cette variante permet :
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 99 ▪ La récolte des Logs sous forme de fichiers grâce au protocole Syslog des différents PC gérant l’infrastructure OpenStack au sein du serveur de Logs. (Voir variante 1 §1.3) ▪ La conversion des Logs grâce à Logstash (Exécuté sur serveur de Logs): Pour centraliser les Logs dans la base de données, nous ne pouvons pas les garder sous forme de fichiers, car ceci consommerait trop de ressources CPU de parcourir tous ces fichiers de Logs au moment où nous faisons des requêtes d’extractions. Pour cela nous devons utiliser un outil écrit en JAVA qui va transformer les Logs bruts (ligne d’un fichier) en Objet JSON afin de les envoyer à notre DB en http (voir Annexe A.4 pour une explication des objets JSON). Exemple d’un objet JSON transformer à partir d’une ligne de Log: Remarque: Lien détaillant la structure des Logs de HAProxy: http://www.exceliance.fr/sites/default/files/biblio/aloha_load_balancer_memo_log.pdf Cet outil, Logstash a besoin d’un fichier de configuration qui regroupe les filtres que j’ai a dû créer manuellement dans le but d’obtenir un template pour découper notre ligne de Log en un objet JSON. Voici un exemple d’un fichier de configuration de Logstash : https://github.com/hepiatelecomlabs/Openstack_Config/blob/master/Object_config/HA/Rsysl og_serv/Logstash/config_els.conf Chaque Log est représenté par un Objet comportant des champs facilitant le classement au sein de la DB et permettra des recherches plus fines avec notre outil de visualisation des Logs. ▪ La DB ElasticSearch : ElasticSearch est une DB permettant le stockage de données de types JSON, la particularité de ce gestionnaire de documents est le fait de traiter l’entrée de données en temps réel. La DB va recevoir les Logs de Logstash, pour les entreposer. Pour la consultation, elle va recevoir des requêtes via son API, et va retourner au client les différents objets JSON concernés par sa requête. La DB est hébergée sur des VMs ce qui permet d’augmenter facilement la taille de notre Cluster sans rajouter d’éléments physiques.
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 100 Schéma 5.12 : Cluster ElasticSearch Voici le cœur du stockage, nous retrouvons trois types de VMs : o VM-Els-Indexer : Ne possède aucune unité de stockage au niveau de la vue du Cluster, mais doit estampiller avec un ID chaque Objet JSON pour qu’ils puissent être classés dans les VMs de stockages. o VM-Els-0.3 : Hébergent les Objets JSON en effectuant en permanence des réplications pour maintenir une consistance des données au sein du Cluster. o VM-Els-Out : Reçoit les requêtes depuis Internet pour transmettre les Logs à l’outil de visualisation. Ce cloisonnement de rôle a été mis en place pour étaler au maximum les charges CPU et RAM, et également faciliter l’expansion du Cluster. ▪ Exploitation des Logs :
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 101 Le serveur Web Kibana s’exécutant sur le PC local de l’administrateur peut interroger la DB afin de récupérer les Logs. A l’aide des outils fournis par Kibana, il est possible d’afficher ces derniers sous la forme de graphiques (histogrammes et camembert) afin de détecter d’éventuelles erreurs. Cette interface GUI est entièrement personnalisable du fait que l’on choisit de générer ces graphiques en fonction des clés des Objets JSON. Voici les différents graphiques que l’on peut générer avec Kibana : Figure 5.10 : Graphiques générés par Kibana La particularité de ce serveur Web ne va pas s’exécuter sur le Cluster mais sur le poste de l’administrateur, déchargeant ainsi le Cluster de la gestion des templates html. Schéma 5.13 : Récupération des Logs avec Kibana
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 102 Comme nous le voyons sur le schéma 5.13, toute la gestion du template du serveur Web est gérée local, s’exécutant sur le poste de l’administrateur. Le serveur dialogue avec la DB ElasticSearch uniquement pour récupérer les objets JSON. En utilisant l’inspecteur réseau intégrer au Browser Firefox, nous voyons bien le chargement du template en local et la récupération des Objets JSON distant : Figure 5.11 : Chargement des JSON distants Au final, cette variante permet de stocker nos Logs de manière centralisée dans une DB pouvant être toujours opérationnelle malgré la perte de deux VMs de stockage. De plus, l’utilisation de Kibana permet de ressortir les Logs en vue d’analyse de comportement de notre infrastructure. 3.3 Variante3 : Logstash-­‐> Redis -­‐> Logstash -­‐>ElasticSearch : Sachant que les Logs inscrits dans les fichiers .log du serveur Physique de Logs arrivent plus vite qu’ils ne sortent vers la DB ElasticSearch, Logstash est obligé de les buffériser en interne, mais ses performances de ce domaine sont plus que médiocre. Par conséquent, cette deuxième variante va intégrer un élément supplémentaire servant de Buffer de Logs (VM- Buffer), qui sera géré par l’outil Redis. La grande force de cet outil est de stocker les Objets JSON dans la RAM, ce qui le rend très performant dans la mise en mémoire des Objets envoyés par Logstash. Schéma 5.14 : Mémoire tampon de Logs Le fonctionnement de Logstash dans le Serveur Physique de Logs a toujours la même fonctionnalité que précédemment, mais il maintient une connexion TCP avec le Buffer Redis, afin de lui envoyer les Logs transformés à la volée.
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 103 Un deuxième Logstash est installé sur cette VM, il va être utilisé uniquement pour envoyer les objets JSON à ElasticSearch. Nous avons la présence de deux VMs Buffer pour créer de la redondance afin que le flow de Logs ne soit pas interrompu. Si la connexion TCP tombe avec le premier il bascule sur la 2ème VM-Buffer. La communication entre le Logstash des VM-Buffer et ElasticSearch se fait par Multicast donc contrairement à la variante 2, il n’a plus besoin de dialoguer avec la VMIndexer. Cette topologie permet d’intégrer les Logstash des VM-Buffer comme un nœud du Cluster, les Logs peuvent être alors envoyés à n’importe quelle VM-Data, et par conséquent nous n’avons plus de « point of failure »: Schéma 5.15: Cluster ELS variante 2 3.4 Variante 4 : Abolition du serveur de Logs physique : Cette variante a pour but de supprimer le serveur physique de Logs, et d’installer Logstash sur chaque serveur physique. Chaque serveur physique gérant l’infrastructure communiquerait avec les deux VMs Buffer pour leurs envoyer les Logs sous format JSON. 3.5 Comparaison des quatre variantes et choix : ▪ Bilan Variante 1 : Cette variante a permis de centraliser les Logs de tous les éléments de l’infrastructure OpenStack au sein d’un même serveur. Mais elle ne remplit pas pleinement le cahier des charges car les logs sous forme de fichiers sont impossibles à exploiter. ▪ Bilan Variante 2 : Cette variante a pour but de mettre en place une gestion des Logs avec les éléments essentiels qui sont : o La récupération des Logs o La conversion o Le stockage
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 104 o La visualisation des Logs de manière à effectuer des recherches d’aides à la décision  Points Positifs : o Remplit le cahier des charges dans la majorité des points o Bonne séparation des tâches pour l’acheminement des Logs o Kibana permet de faire du regroupement de données, pour que l’administrateur qui consulte ces Logs puissent faire ressortir les informations qui lui semblent pertinentes  Points Négatifs : o Le goulet d’étranglement est le buffer géré par Logstash o La disponibilité n’est pas vraiment au rendez-vous entre Logstash et ELS. Du fait que Logstash ne communique qu’avec un seul point de la DB ElasticSearch en http. Notre serveur physique de Logs est également un élément sensible ▪ Bilan Variante 3 :  Points Positifs : o On décharge le buffer de Logstash du serveur physique et donc un gain de performance o De par la présence de deux VMs Buffer, nous augmentons la HA. o Les Logstasch des VM-Buffer sont considérés comme un nœud du Cluster (inutilité de la VM-Indexer)  Points Négatifs :  Présence de notre serveur physique récupérant les Logs ▪ Bilan Variante 4  Point Positif : o Abolition du serveur physique qui centralise les Logs, ce sont les producteurs de Logs qui hébergent chacun un Logstash  Points négatifs : o Comme Logstash est un service JAVA, il a besoin de la Java Virtual Machine pour s’exécuter. Cette JVM peut vite devenir très gourmande en ressource. Il faut absolument dimensionner correctement la JVM, qui n’est pas une tâche facile o Comme Logstash a besoin d’un fichier de configuration qui contient les règles de transformations des lignes de Logs en objets JSON, il faudra veiller à ce que tous les Logstash aient le bon fichier de configuration, ce qui rajoute une couche supplémentaire de contrôle
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 105 3.6 Choix de la variante : Suite aux différents points évoqués, je préconise comme système de gestion des Logs la variante n°3 (§3.3). Même si le « Point of Failure » est le serveur physique de Logs, nous n’encombrons pas les Producteurs de Logs avec le service Logstash qui peut vite s’avérer gourmand en ressource. Grâce à cette variante les Logs sont également dans une DB gérant les réplications des données au sein de son Cluster, afin de pouvoir survivre à la perte de deux VM- Els. Comme nous sommes dans un univers virtualisé, il est aisé de rajouter des VMs afin d’augmenter nos capacités de stockages. 4. Supervision des ressources physiques : Le but de ce stockage de Logs, a été de générer de la charge au sein de mes différentes VMs grâce à l’important volume que produisent les services OpenStack en mode Debug. J’ai mis en place la variante n°2, ma DB ElasticSearch est composé de  4 VM-ELS-Node (VM-Data), 1 VM-Els-Indexer et 1 VM-Els-Out: o 1 vCPU o 1024 MB de RAM o 20 GB de disque virtuel Au sein des VM-Data, j’ai appliqué une réplication de deux, c’est-à-dire pour une donnée inscrite sur un nœud, elle va être répliqué sur deux autres nœuds. Donc au niveau de la disponibilité de la DB, on peut perdre jusqu’à deux nœuds pour toujours garder la consistance des données. Grâce à un plugin GUI intégré à la DB ElasticSearch, j’ai pu voir le nombre d’objets JSON enregistrait pendant 24h. Il faut savoir que Logstash va affilier ces objets JSON à un index, et cet index change toutes les 24 heures. Voici un aperçu de l’interface GUI : Figure5.12 : Aperçu du Cluster
CHAPITRE 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins 106 Nous voyons à gauche la liste de tous les nœuds du Cluster ElasticSearch, et les 4 VM- Data ont à droite les parties de données qu’elle possède. Attardons-nous maintenant sur les chiffres : rien que le 21 janvier entre 00h et 23 :59, les services OpenStack ont généré environ 6'400'000 lignes de Logs ou Objet JSON, ce qui représente 4.73GB, mais avec le répliqua de deux, ces Logs occupent au sein du Cluster 14.2GB. Sachant qu’il n’y a que 4 VMs de Data, je peux stocker un peu moins de 80GB, c’est- à-dire environ 5 jours et demi de Logs. A travers ces chiffres, le stockage peut vite devenir problématique, car ma « petite » infrastructure, génère déjà 14.2GB/Jour de Logs avec la réplication, pour conserver une année de Logs il faudrait 5TB, ce qui est infime face au volume généré par les services Web au sein de LeShop.ch. Au niveau de la vitesse de génération de Logs, ceci représente environ 4'500 Objets JSON/Minute. Malgré cette charge importante au sein des VMs, il est toujours possible de démarrer de nouvelles VMs, et les services OpenStack sont toujours disponibles. 5. Problèmes rencontrés : J’ai passé beaucoup de temps à travailler sur les formatages des Logs afin que Logstash puisse créer des objets JSON standards quel que soit le service OpenStack générant les Logs. Un problème topologique au niveau du réseau s’est posé. Comme illustré dans mes différents schémas d’infrastructure, les VMs possèdent leur propre réseau (LAN Orange), qui est physiquement séparé du réseau administratif (LAN Bleu). Pour faire remonter les objets JSON de Logstash vers ElasticSearch situé sur une VM, j’ai installé une seconde carte réseau à mon serveur de Logs, pour qu’il puisse se connecter au réseau privé des VMs. Ceci n’est pas recommandé dans la pratique, je le fais uniquement pour générer du trafic au sein des VMs. 6. Bilan du scénario 3 : A travers ce scénario, j’ai pu étudier et mettre en place une réelle stratégie de gestion de Logs, avec l’intégration d’un système de recherche performant. Ce scénario s’adapte parfaitement à un environnement virtualisé, où le maître mot est la « scalability ». Si nous voyons notre Cluster devenir trop faible au niveau stockage, nous pouvons ajouter une nouvelle VM facilement. Ce sont les ressources telles que les VMs qui s’adaptent à la demande, grâce à ce type de gestion, nous ne sommes jamais dans des cas extrêmes de sous-dimensionnement ou surdimensionnement.
CHAPITRE 6
CHAPITRE 6 : Supervision des ressources avec Shinken 107 A travers ce scénario, j’ai ajouté à mon serveur de Log une fonction de supervision grâce à l’outil Shinken. Ce scénario ne va pas vous faire découvrir le fonctionnement de l’outil Shinken, mais comment j’ai monitoré la HA des API OpenStack. Le Projet d’Approfondissement de Master de M. Lionel Schaub propose une vue détaillée des possibilités qu’offre Shinken : http://www.tdeig.ch/shinken/Schaub_RPA.pdf 1. But du scénario : Le but de ce scénario est de monitorer la HA que j’ai mise en place au cours des scénarios précédents. Je vais également monitorer les ressources physiques tels que la quantité de RAM utilisée de mes deux Controller ainsi que de mon Compute-Node. La page de mon dépôt GitHub à propos des différents fichiers de configuration que j’ai utilisés pour configurer les services et les hôtes se trouvent: https://github.com/hepiatelecom- labs/Openstack_Config/tree/master/Object_config/HA/Rsyslog_serv/Shinken 2.Schéma de principe : Schéma 6.1 : Monitoring des API et serveurs physiques 3. Supervision des services d'APl OpenStack : Dans Shinken, j’ai créé deux types de tests http : 1) Http sur l’IP physique : Teste le service en l’interrogeant directement sur l’adresse IP d’un des deux Controller (10.2.4.101 et 10.2.4.106). 2) Http sur Virtual IP : Teste le service mais en passant par HAProxy en envoyant une requête sur l’adresse IP Virtuelle, donc le paquet sera aiguillé sur l’un ou l’autre Controller
CHAPITRE 6 : Supervision des ressources avec Shinken 108 En testant les API via leur adresse IP virtuelle, même si par exemple le service de l’interface Web est inactif sur le Controller1, le service Web dans sa globalité est toujours en fonction car il sera redirigé vers l’autre Controller. Etat du Système où tous les services OpenStack sont actifs: Figure 6.1: Infrastructure opérationnelle Voici la situation où le service Horizon est inactif sur le Controller1 : Figure 6.2: Fonctionnement de la HA malgré un des deux Horizon Down
CHAPITRE 6 : Supervision des ressources avec Shinken 109 Nous voyons que l’interface Horizon est toujours disponible pour l’administrateur qui l’interroge via l’IP virtuelle. Grâce à ce procédé, je peux contrôler le fonctionnement de ma HA. 3.1 Problème au niveau des tests via l'IP Virtuelle : J’ai rencontré un problème lorsque mes deux services horizons étaient inactifs sur les deux Controllers. Le test au niveau du ClusterAPI indiquait que le service horizon était actif, car j’utilisais uniquement la commande check_tcp. Comme HAProxy en cas d’indisponibilité de service renvoie une réponse http avec un code 503 (Service indisponible), le check_tcp de Shinken restait à OK, car il arrivait à établir une liaison TCP avec HAProxy. Par conséquent, il a fallu que j’utilise le test check_http, pour qu’il puisse détecter les différentes réponses http. Voici la réponse en faisant un « Curl » sur HAProxy en cas d’indisponibilité des deux services sur les deux Controllers : 4.Supervision des ressources physiques : J’utilise Shinken non plus pour tester la disponibilité d’une API, mais pour remonter les informations de charge CPU, la quantité d’espace disque utilisée et la quantité de RAM utilisée. Pour cela, Shinken va se connecter en ssh au différentes machines physiques afin d’exécuter des commandes qui nous retourne ces différentes informations. Comme par exemple, la charge CPU est obtenue en faisant : Cat /proc/loadavg 0.21 0.15 0.10 -> Retourne la moyenne de la charge sur 1 minute, 5 minutes et 15 minutes1 . Grâce à ces différents tests, nous pouvons fixer des alertes au moment où le système devient trop critique. 1 Vmwarevsphare. http://www.arumtec.net/fr/outils-virtualisation/outils-devirtualisation/ vmware- vsphere-4.1/presentation-de-vmware-vsphere-4.1.
CHAPITRE 6 : Supervision des ressources avec Shinken 110 Par exemple, au moment où je crée 10 VMs qui vont démarrer en même temps sur le Compute Node, Shinken passe la charge CPU en critique : Ces plugins de récupération de charges développées par M. Sébastien Pasche et M. Jean Gabes (Fondateur de Shinken), permettent de s’affranchir de différents agents (nrpe) installés sur les machines testées. Cet agent va recevoir les commandes envoyées par Shinken et les exécuter en local. Toutefois ceci nécessite de rajouter un programme sur les différentes machines physiques, tandis qu’avec ssh on utilise un protocole de communication déjà employé à travers mon infrastructure. 5.Mise en place de tests interdépendants : Précédemment, j’ai mis en place deux types tests : le premier teste la disponibilité des API et le second teste les ressources physiques. A l’heure actuelle, les tests que fait Shinken sont indépendants les uns des autres. Il serait intéressant d’effectuer des successions de tests pour desseller à quel niveau se situerait le problème. Par manque de temps, j’ai uniquement fait une analyse théorique des tests imbriqués. Par exemple, si le Serveur d’API du Controller 2 ne répond pas au check_http et le check RAM indique une erreur critique. On pourrait immédiatement savoir que le problème se trouve au niveau du serveur et que le problème réseau est à écarter, car un processus utilise toute la RAM. Grâce à ce type de tests interdépendants, en fonction du type d’erreur que Shinken remonte, il pourrait avertir soit la personne gérant le réseau, soit la personne en charge de la gestion des serveurs. 5.1 Finalité du test : Comme nous l’avons vu tout au long de ce projet, OpenStack est constitué d’une multitude de services dédiés à la gestion de l’infrastructure. Pour avoir une vue d’ensemble des services opérationnels, Shinken va monitorer grâce à une suite de tests dépendants, les éléments intervenant dans le démarrage d’une VM2 . Au final, nous devons être capable de savoir si notre infrastructure pourra :  Recevoir les commandes envoyées par l’administrateur : o Tester si les API répondent aux requêtes http via l’IP virtuelle. Ce test est critique, car s’il y a une erreur, ceci veut dire que les deux Controllers sont en échec. o Tester sans passer par l’IP Virtuelle, si l’un des deux Controllers ne répond pas, ceci est moins critique grâce à la HA mise en place.  Tester les ressources physiques de chaque serveur : o Le degré de gravité change pour les types de serveurs. Un Compute Node sera plus chargé, que les deux Controllers. Par conséquent, si les Controller sont surchargés, il faudra y porter plus d’importance, car normalement ils n’hébergent que des services d’API peu gourmands en ressources. 2 Xen. http://www.xen.org/.
CHAPITRE 6 : Supervision des ressources avec Shinken 111  Tester si l’on peut écrire dans la DB MySQL.  Tester si les différents services OpenStack sont démarrés. Au final, nous devons être capable de tester toute la chaîne qui s’exécute au moment où l’administrateur décide de démarrer une VM. Le schéma 27 représente la chaîne de tests que Shinken va effectuer afin de détecter la moindre erreur ou panne intervenant dans l’infrastructure. Schéma 6.2: Diagrammes de tests Shinken Les tests s’effectuant dans la zone rouge sont critiques, si l’un d’entre eux échoue, aucune VM ne pourra être démarrée. Les tests dans la zone jaune sont moins critiques, mais, peuvent quand même présenter une anomalie. Prenons le test n°1, le « Check_Load Tous les commute Node » indique une erreur si tous les Compute Node sont chargés à 100%, ceci est important car plus aucune VM supplémentaire ne pourrait démarrer. Tandis que si un Compute Node est chargé à 100%, les VMs pourront toujours être démarrées sur le deuxième. 5.2 Plugin de démarrage d’une VM intégré à Shinken : Pour rendre notre système de supervision le plus complet possible, il serait intéressant de développer un plugin, afin que Shinken puisse simuler le comportement de l’administrateur en démarrant une VM et vérifier qu’elle est bien active3 . En intégrant ce test avec les tests du schéma 27, il sera alors possible de superviser tous les services de cette infrastructure en vue 3 Xen. http://wiki.xen.org/.
CHAPITRE 6 : Supervision des ressources avec Shinken 112 de déceler les moindres changements comportementaux du système. La chaîne de lancement du plugin va se dérouler comme suit: 1. Démarrer une VM avec le client python d’OpenStack 2. Attendre 5 secondes que la VM reçoive une IP 3. Récupérer l’IP de cette VM en interrogeant le fichier du serveur DHCP sur le Network Node contenant la corrélation : MAC, Nom_VM, IP 4. Au bout d’une dizaine de secondes, se connecter en ssh à la VM et effectuer un Ping sur un serveur distant. A travers ces deux tests, nous contrôlons si nous la VM est accessible par ssh et si le Network Node aiguille correctement les paquets du réseau privé vers le réseau public. 5. Détruire la VM grâce au client python, et regarder sur le QNAP que le disque virtuel sous forme de fichier est bien supprimé 6. Si l’ensemble des tests est OK, l’infrastructure OpenStack est fonctionnelle 6.Bilan du scénario : Avec une telle infrastructure, constituée de nombreux services répartis sur plusieurs serveurs physiques, il est essentiel de mettre sur pieds un élément de supervision, afin de remonter les différentes erreurs. Ce système va permettre d’anticiper d’éventuelles pannes critiques qui rendraient l’infrastructure inutilisable. Pour effectuer ces différents tests, il est nécessaire de connaître le comportement des différents services. Le fait d’intégrer de la HA, dédouble le nombre de serveurs physiques, ce qui va augmenter le nombre de tests. Par conséquent, il va être essentiel de prioriser les tests grâce aux dépendances, afin de ressortir des erreurs pertinentes.
113 Conclusion Générale Le cloud computing est un domaine en plein essor qui répond un grand nombre de besoins des entreprises. L'investissement dans ce domaine attire donc de plus en plus les ingénieurs réseaux qui ne cessent de proposer des solutions de Cloud variées en qualité de service liable et rentable. Ce projet de fin d’études, proposé pour but de mettre en place une plateforme de virtualisation et le déploiement d’une solution Cloud OpenStack. Notre plateforme est composé d’une couche de virtualisation VMware dans laquelle les différentes machines virtuelles créées et déployées pour garantir la fiabilité et l’efficacité du système d’information et d’une plateforme du Cloud privé IaaS basé sur OpenStack. Choisir une solution dont la communauté est trop faible. Dont le développement est presque nul ou dont la documentation serait proche du néant pourrait mener le projet à l'échec avant la production (avec de la chance) ou imposer d'importantes difficulté pouvant aller de l'instabilité de la plateforme jusqu'à l‘obligations de changer l'infrastructure complète. en production. II s'impose alors l’analyser ces caractéristiques. A court terme et en se basant sur l'étude technique réalisée sur le Cloud Computing, nous pourrons mettre en place un environnement Cloud si les contraintes matérielles seront relaxées. Ceci nous permettra l'utilisation de notre propre environnement pour mener à terme nos expérimentations à tous les niveaux du Cloud. L'élaboration de ce projet nous a permis de concrétiser et d'approfondir nos connaissances particulièrement dans les domaines de la virtualisation et de cloud Computing.
114 Bibliographie : Chapitre 2 : [1] Alain-B. TCHANA .Système d'Administration Autonome Adaptable: application au Cloud, novembre 2011 [2] Bhaskar Prasad Rimal, Eunmi Choi, and Ian Lumb. A taxonomy and survey of cloud computing systems. In Proceedings of the 2009 Fifth International Joint Conference on INC, IMS and IDC, NCM '09, pages 44_51, Washington, DC, USA, 2009. IEEE Computer Society. [3] EuroCloud France. L'évolution maitrisée vers le IaaS/PaaS. novembre 2011 [4] Ignacio M. LlorenteBorja Sotomayor, Ruben S. Montero and Ian Foster. [5] JunjiePeng, Xuejun Zhang, Zhou Lei, Bofeng Zhang, Wu Zhang, and Qing Li. Comparison of several cloud computing platforms. In Proceedings of the 2009 Second International Symposium on Information Science and Engineering, ISISE '09, pages 23_27, Washington, DC, USA, 2009. IEEE Computer Society. CHAPITRE 3 : [1] le cloud computing une nouvelle filière fortement structurante, septembre2012 [2] Marvin Rambhadjan and Arthur Schutijser. SURFnet cloud computing solutions. [3] Peter Sempolinski and Douglas Thain. A comparison and critique of eucalyptus, opennebula and nimbus. In Proceedings of the 2010 IEEE Second International Conference on Cloud Computing Technology and Science, CLOUDCOM '10, pages 417_426, Washington, DC, USA, 2010. IEEE Computer Society. [4] ThiagoDamascenoCordeiro, Douglas BritoDamalio, NadilmaCintra [5] Vivansas.p.r.l.Cloud Computing Enjeux, Perspectives et Impacts métiers, septempre 2009 [6] WygwanLe Cloud Computing : Réelle révolution ou simple évolution ? Webographie [7] Abicloud. http://community.abiquo.com/. [8] Amazon web srrvice. http://aws.amazon.com/fr/. [9] Eucalyptus. http://www.eucalyptus.com/. CHAPITRE 4 : [1] Microsoft. http://www.microsoft.com/. [2] Microsoft. Windows azure http://www.microsoft.com/windowsazure/. [3] Microsoft hyperv. http://www.microsoft.com/hyper-v-server/en/us/default.aspx. [4] Nimbus. http://www.nimbusproject.org/.
115 CHAPITRE 5 : [1] Openstack. http://www.openstack.org/. [2] Opennebula. http://opennebula.org/. [3] redhat. http://www.redhat.com/products/cloud-computing/cloudforms/. [4] Salesforce. http://www.salesforce.com/fr/. CHAPITRE 6 : [1] Vmwarevsphare. http://www.arumtec.net/fr/outils-virtualisation/outils-devirtualisation/ vmware-vsphere-4.1/presentation-de-vmware-vsphere-4.1. [2] Xen. http://www.xen.org/. [3] Xen. http://wiki.xen.org/.
Liste des abréviations : SONATRACH : Société National pour la recherche, Transport, production, transformation, la commercialisation des hydrocarbures ERDP : l’entreprise nationale de raffinage et de distribution de produits pétroliers UND : Unité NAFTAL de Distribution SPA : société par action NAFTAL : Entreprise nationale de commercialisation et de distribution de produits pétroliers CLP : Carburants Lubrifiants et Pneumatiques BIU : les bordereaux inter unités ING : Service Informations de Gestion AMG : administration et moyen généraux GPL : gaz de pétrole liquéfié IBM : International Business Machines BSD : Berkeley Software Distribution PUE : Power usage effectiveness SOA : Service Oriented Architecture IaaS : Infrastructure as a service PaaS : Plateforme as a Service Saas : Software as a service VPN : virtual private network CLC : contrôleur de cloud CC : cluster controller VM : machines virtuelles OS : Operating System (systèmes d'exploitation)
ESXI : Elastic Sky X Integrated HA : High Availability (haute disponibilité) VDA : Virtual Delivery Agent PVS : Provisioning Services DMZ : demilitarized zone (zone démilitarisée) VPX : Virtual Provisioning X CLI : Command Line Interface XML : eXtensible Markup Language EC2 : Elastic Compute Cloud CPU : Central processing unit API : Application Programming Interface NAS : Network Attached Storage SAN : Storage Area Network DAS : Direct Attached Storage NFS : Network File System SMB : Server Message Block CIFS : Common Internet File System AFP : Apple Filing Protocol IP : Internet Protocol TCP : Transmission Control Protocol SCSI : Small Computer System Interface SLA : Service Level Agrement SRDF : Symmetrix Remote Data Facility BCV : Business Copy Volume QNAP : Quality Network Appliance Provider RHEL : Red Hat Entreprise Linux KVM : Kernel-Based Virtual Machine
REST : Representational State Transfer AMQP : Advanced Message Queuing Protocol RPC : Remote procedure call DHCP : Dynamic Host Configuration Protocol VRRP : Virtual Router Redundancy Protocol

Contenu connexe

PDF
Mise En Place d'une Solution de Supervision Réseau
parYaya N'Tyeni Sanogo
 
DOCX
Rapport PFE : Cloud Insights
parahmed oumezzine
 
PDF
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
parBader Nassiri
 
PDF
Rapport de stage pfe odoo 8
parayoub damir
 
PDF
Memoire_Fallou_Mbengue.pdf
parfalloumbengue1
 
PDF
Rapport du projet fin d'etudes
parTahani RIAHI
 
PDF
Medical openerp
parHORIYASOFT
 
PDF
Rapport finiale
parmarwenbencheikhali
 
Mise En Place d'une Solution de Supervision Réseau
parYaya N'Tyeni Sanogo
 
Rapport PFE : Cloud Insights
parahmed oumezzine
 
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
parBader Nassiri
 
Rapport de stage pfe odoo 8
parayoub damir
 
Memoire_Fallou_Mbengue.pdf
parfalloumbengue1
 
Rapport du projet fin d'etudes
parTahani RIAHI
 
Medical openerp
parHORIYASOFT
 
Rapport finiale
parmarwenbencheikhali
 

Tendances

PDF
Rapport Projet de Fin d'Etudes
parHosni Mansour
 
PDF
Mise en place d'une infrastructure basée sur OpenStack
parAhmed Slim
 
PDF
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
parMohamed Amine Mahmoudi
 
PDF
rapport PFE ingénieur génie logiciel INSAT
parSiwar GUEMRI
 
PDF
Mémoire : Cloud iaas Slim Hannachi
parslim Hannachi
 
PDF
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING PRIVÉ BASÉE SUR UN ...
parBorel NZOGANG
 
PDF
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
parTidiane Sylla
 
PDF
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
parMohamed Amine Mahmoudi
 
PDF
Rapport PFE Ahmed BEN JEMIA
parAhmed BEN JEMIA
 
PDF
Rapport pfe
parAhmed rebai
 
DOCX
Rapport PFE Développent d'une application bancaire mobile
parNader Somrani
 
PDF
Rapport Projet de fin d'etude sur le parc informatique
parHicham Ben
 
PDF
Rapport de stage développement informatique
parMehdiOuqas
 
PDF
Rapport Stage Alstom
parOtmaneDouieb
 
PDF
Rapport projet fin d'étude
parHibaFarhat3
 
PDF
Pfe master fst_final_decembre2015
parGhali Rahma
 
PDF
Rapport de stage PFE - Mémoire master: Développement d'une application Android
parBadrElattaoui
 
DOCX
Rapport pfa
parGhizlane ALOZADE
 
PDF
Rapport Stage Alstom Otmane Douieb
parOtmaneDouieb
 
PDF
Rapport de fin d'etude
parUniversité de Sherbrooke
 
Rapport Projet de Fin d'Etudes
parHosni Mansour
 
Mise en place d'une infrastructure basée sur OpenStack
parAhmed Slim
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
parMohamed Amine Mahmoudi
 
rapport PFE ingénieur génie logiciel INSAT
parSiwar GUEMRI
 
Mémoire : Cloud iaas Slim Hannachi
parslim Hannachi
 
ETUDE ET MISE EN PLACE D'UNE SOLUTION DE CLOUD COMPUTING PRIVÉ BASÉE SUR UN ...
parBorel NZOGANG
 
ETUDE ET MISE EN PLACE D’UNE SOLUTION DE GESTION DE LA SECURITE DU RESEAU : C...
parTidiane Sylla
 
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
parMohamed Amine Mahmoudi
 
Rapport PFE Ahmed BEN JEMIA
parAhmed BEN JEMIA
 
Rapport pfe
parAhmed rebai
 
Rapport PFE Développent d'une application bancaire mobile
parNader Somrani
 
Rapport Projet de fin d'etude sur le parc informatique
parHicham Ben
 
Rapport de stage développement informatique
parMehdiOuqas
 
Rapport Stage Alstom
parOtmaneDouieb
 
Rapport projet fin d'étude
parHibaFarhat3
 
Pfe master fst_final_decembre2015
parGhali Rahma
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
parBadrElattaoui
 
Rapport pfa
parGhizlane ALOZADE
 
Rapport Stage Alstom Otmane Douieb
parOtmaneDouieb
 
Rapport de fin d'etude
parUniversité de Sherbrooke
 

Similaire à Deploiement solution_ha_de_stockage_ceph_sous_une_plateforme_virtualisee_vsphere-openstack_-_bts_encadre_par_djebbari

PDF
Rapport pfe-ayoub mkharbach
parAyoub Mkharbach
 
PDF
Rapport de stage de fin d'études ISI 2015
parAnouar Kacem
 
DOCX
mémoire de projet de fin d'études
parMortadhaBouallagui
 
PDF
Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)
parGhali Rahma
 
PDF
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
parkarimatorkhani
 
PDF
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
parKarima Torkhani
 
PDF
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
parKarima Torkhani
 
PDF
Concéption et réalisation d'un processus décisionnel, tableau de bord social.
parRim ENNOUR
 
PDF
Conception et développement d’un système d’alerte et notification d’une tou...
parBilel Khaled ☁
 
DOCX
587928374-Rapport-PFE-Clo ud.docx
parsoufianelmorsli666
 
PDF
Ce document englobe mon projet de fin d’étude
parYoldezDenjel
 
Rapport pfe-ayoub mkharbach
parAyoub Mkharbach
 
Rapport de stage de fin d'études ISI 2015
parAnouar Kacem
 
mémoire de projet de fin d'études
parMortadhaBouallagui
 
Rapport-PFE2013-RahmaGhali-Gestion des Candidatures(Jaas,Primefaces,JFS2,JPA)
parGhali Rahma
 
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
parkarimatorkhani
 
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
parKarima Torkhani
 
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
parKarima Torkhani
 
Concéption et réalisation d'un processus décisionnel, tableau de bord social.
parRim ENNOUR
 
Conception et développement d’un système d’alerte et notification d’une tou...
parBilel Khaled ☁
 
587928374-Rapport-PFE-Clo ud.docx
parsoufianelmorsli666
 
Ce document englobe mon projet de fin d’étude
parYoldezDenjel
 

Deploiement solution_ha_de_stockage_ceph_sous_une_plateforme_virtualisee_vsphere-openstack_-_bts_encadre_par_djebbari

  • 1.
    REPUBLIQUE ALGERIENNE DEMOCRATIQUEET POPULAIRE MINISTERE DE LA FORMATION ET DE L’ENSEIGNEMENT PROFESSIONNELS INSTITUT NATIONAL SPECIALISE DE FORMATION PROFESSIONNELLE DE BOU-ISMAIL WILAYA DE TIPAZA Mémoire de Fin de Formation en Vue de l’Obtention du Diplôme de Brevet de Technicien Supérieur Spécialité : Informatique/Option : Administration Cloud computing et virtualisation Code de la Spécialité : INT1704 THEME : L’Organisme d’Accueil : SG. NAFTAL Elaboré par : Encadré par : - HADJI Younes Fethi M. DJEBBARI Abdelmadjid - LAROUCI Mostafa - BOUKROUMA Abd El Moumen Co-Encadreur : M. MANSSORI Djamel PROMOTION : Février 2020
  • 2.
    REMERCIEMENTS Nous remercions toutd’abord « ALLAH » de nous avoir donné le courage d’entamer et de finir ce mémoire dans les bonnes conditions. Nous remercions vivement notre encadreur, Le professeur Mr. Djebbari Abd El Madjid, d’avoir encadré ce travail avec beaucoup de compétences. Nous remercions notre promoteur Mr. Mansouri Djamel Merci pour votre indéfectible disponibilité, votre rigueur scientifique et la confiance que vous nous avez accordée au cours de l’élaboration de ce mémoire ; Merci pour l’acuité de vos critiques et pour vos conseils éclairés. Nous remercions également les membres du jury d’avoir accepté d’évaluer ce travail. Nos remerciements vont également à tous les enseignants qui ont à notre formation. Nos profondes gratitudes s’orientent vers Mr. Abd El Karim ; grâce à lui nous étions des stagiaires à la D.G NAFTAL. Ainsi que tout le personnel du département DCSI de NAFTAL.
  • 3.
    DEDICACE Je dédie cemodeste travail à : A la mémoire de mon Père Aucune dédicace ne saurait exprimer l’amour, l’estime, le dévouement et le respect que j’ai toujours eu pour vous. A ma très chère mère Aucune dédicace ne saurait être assez éloquente pour exprimer ce que tu mérites pour tous les sacrifices que tu n’as cessé de me donner depuis ma naissance, durant mon enfance et même à l’âge adulte. Tu as fait plus qu’une mère puisse faire pour que ses enfants suivent le bon chemin dans leur vie et leurs études. Je te dédie ce travail en témoignage de mon profond amour. Puisse Dieu, le tout puissant, te préserver et t’accorder santé, longue vie et bonheur. A mes chères sœurs Je vous souhaite un avenir plein de joie, de bonheur, de réussite et de sérénité. Je vous exprime à travers ce travail mes sentiments de fraternité et d’amour. Hadji Younes Fethi
  • 4.
    DEDICACE Je dédie cemodeste travail à : Mes chers parents Rien au monde ne vaut les efforts fournis jour et nuit pour mon éducation et mon bien être. Ce travail est le fruit de tes sacrifices que tu as consentis pour mon éducation et ma formation. A mon très cher frère Samir Mon cher frère, les mots ne suffisent guère pour exprimer l’attachement, l’amour et l’affection que je porte pour vous. Mon ange gardien et mon fidèle compagnon dans les moments les plus délicats de cette vie mystérieuse. Je vous dédie ce travail avec tous mes vœux de bonheur, de santé et de réussit. A Mes chères frères et sœurs En témoignage de l’attachement, de l’amour et de l’affection que je porte pour vous. Je vous dédie ce travail avec tous mes vœux de bonheur, de santé et de réussite. A tous les membres de ma famille Petits et grands Veuillez trouver dans ce modeste travail l’expression de mon affection. A Mes chères Mohamed, Arbi, Ben Omar et Oussama ; Que dieu vous assistes. Larouci Moustafa
  • 5.
    DEDICACE Je dédie cemodeste travail à : Mes chers parents Pour tous leurs sacrifices, leur amour, leur tendresse, leur soutien et leurs prières tout au long de mes études. Que ce travail soit l’accomplissement de vos vœux tant allégués, et le fuit de votre soutien infaillible. A Mes chères sœurs Je vous dédie ce travail avec tous mes vœux de bonheur, de santé et de réussite. A Mes enseignants Un profond respect et un remerciement particulier pour vous. A mes Amis A tous ceux qui me sont chers Boukrouma Abd El Moumen
  • 6.
    Table des matières: Remerciements Dédicaces Introduction générale Problématique Objectifs du projet Chapitre 1 : présentation de l’entreprise (lieu du stage)…………………………………...1 Section I : Fiche signalétique de NAFTAL District Carburants.……………………….1 A. Historique de NAFTAL ………………………………………………………..1 B. Principales tâches et responsabilités de NAFTAL ……………………...…….1 C. Organisation de NAFTAL ……………………………………………………...2 1. Service Informations de Gestion (ING) : sa mission consiste à……………2 2. Département AMG (administration et moyen généraux) : Les missions du département AMG sont…………………………………………………….2 3. Département finances et comptabilité : Le département finance et comptabilité a pour mission de…………………………………………….2 4. Département Transport & Technique : Il a pour mission………………....3 Section II : Les Moyens et de l’entreprise NAFTAL…………..……………………….4 A. Les moyens de l’entreprise NAFTAL…………………………………..………4 B. Produits commercialisés par l’entreprise…………………………………….…5 1. Carburants………………………………………………………………....5 2. Gaz de pétrole liquéfié ……………………………………………….……6 Chapitre 2 : Technologie de Virtualisation et de Cloud : Etat de L'art………………...…..9 I. Introduction………………………………………………………………….…...9 II. Technologie de Virtualisation....…………………………………………....…...9 1. Définition...………………………………………………………………….9 2. Historique de la virtualisation………...……………………………………..9 2.1. Premiers pas…………………………………………………..…….9 2.2. Machines virtuelles…………………………………...……………..9
  • 7.
    2.3. Amélioration destechnologies………………………….………….10 2.4. Intérêt du grand public……………………………………..……….10 3. Les types de virtualisations.………………………………………………..10 3.1. La virtualisation complète.………………………………………....10 3.2. La paravirtualisation ……………………………………………13 3.3. Virtualisation matérielle …………………………………………..15 4. Techniques de virtualisation …..…………………………………………...17 4.1. L’Isolation et Le Cloisonnement …………………….…………....17 III. Technologie de Cloud Computing ……………………………………………..17 1. Technologie de Datacenter ………………………………………………...17 2. Historique du Cloud Computing….……………………..........................18 3. Bénéfices du cloud Computing ……………………………………………18 3.1. Pour le fournisseur ………………………………………….……..18 3.2. Pour l'entreprise ...…………………………………………………18 IV. Les différents services…………………………………………………………19 V. Types et Modèles de déploiement de cloud……………………………………19 VI. Les solutions de cloud…………………………………………………………20 1. Eucalyptus……………………………………………………….…………20 2. OpenNebula………………………………………………………………..20 3. OpenStack…………………………………………………………….……20 Chapitre 3 : Etude Comparative et Choix de la solution………………………….………23 I. Introduction…………………………………………………….……………...23 II. Solutions de Virtualisation …………………….……………………………...23 1. VMware (vSphere, ESXi...) ...………….……………………………….....24 1.1. VMware vSphere ………………………………………………..…24 1.2. Composants et fonctionnalités…………………………………..….25 2. Citrix (Xenserver...) ……………………………………………………..…30 2.1. Composants et fonctions…………………………………………....32 2.1.1 . Composants principaux…………………………………….....32 2.1.2 . Composants supplémentaires…………………………………35
  • 8.
    III. Solutions decloud…………………………………………………………...36 1. Solution Eucalyptus ……………………………………………………......36 2. Solutions OpenNebula……………………………………………………...37 3. Solutions Openstack………………………………………………………..38 Chapitre 4 : Technologies de stockage et Haute Disponibilité…………………………….43 I. Introduction…………………………………………………………...………43 1. Technologies de stockage (NAS SAN...)…………………………….……44 1) Fonctionnement………………………………………………….…47 2) Quel type de réseau utilise un réseau SAN?......................................47 3) Quels types de commutateurs sont appropriés SAN?........................48 4) Peut-on bâtir un réseau SAN sur réseau existant?.............................48 5) Qu'est-ce qu'un serveur SAN?...........................................................48 6) Topologie…………………………………………………………..49 7) Applications………………………………………………………..49 8) Défauts et qualités…………………………………………….....49 A. Défauts………………………………………………….....49 B. Qualités………………………………………………….....49 2. Systèmes de stockage (CEPH NFS...) ………………………………….....51 A. Architecture de CEPH ………………………………………………..52 B. Les services CEPH……………………………………………………53 C. Gestion de stockage CEPH……………………………….…………...53 C.1. Les pools……………………………………………….…….....53 C.2. Réplication de données………………………………………....54 a. Clonage……………………………….....................................54 b. Utilisation de code à effacement (erasurecoding)…………….54 D. Implantation de stockage distribué à travers Proxmox VE……....…..55 D.1.Implémentation du système de stockage tolérance aux pannes développées pour la virtualisation: le Ceph…………………………………….…..55 a. Configuration du réseau dédié à Ceph…………………….….55 D.2.Installation des paquets CEPH ………………………………...56 D.3.Création de la configuration initiale Ceph……………………..56 D.4.Mise en place des services Ceph……………………………….56 a.Création des moniteurs Ceph………………………………....56
  • 9.
    b.Création des OSDCeph ……………………………………...57 D.5. Création de pool Ceph…………………………………………57 3. Concepts et techniques de la haute disponibilité …………………………59 3.1. Mesure du taux de disponibilité……………………………...……59 3.2. Techniques améliorant Ha disponibilité……………………….....60 3.3. Dépendance vis-à-vis des autres applications…………………….61 3.4. Répartition de charge et sensibilité……………………………….62 3.5. Redondance différentielle………………………………………...62 3.6. Redondance avec système de vote………………………………..62 3.7. Shadow opérations………………………………………………..63 4. Les processus qui permettent d'améliorer la haute disponibilité……...….63 4.1. Les processus qui réduisent le nombre de pannes………………….63 4.2. Les processus réduisant la durée des pannes………………………..63 5. Cluster haute disponibilités ……………………………………………...63 Chapitre 5 : Branche Fonctionnelle : Analyse et Spécification des Besoins……………66 I. Introduction…………………………………………………………………66 II. Scénario 1 : Serveur web virtualisé au sein d'Openstack …………………..66 1. Scénario 1a : Système de stockage NFS …………………………………………66 1.1 Les entités physiques………………………………………………..67 1.2 L’utilité des services Openstack…………………………………….68 1.3 Echange de messages………………………………………………..69 1.4 Les services OpenStack…………………………………………………70 1.4.1 Administration de l’infrastructure Openstack ……………...70 1.4.2 Gestion de la virtualisation …………………………………71 1.4.3 Gestion de l’authentification (Keystone)……………………72 1.4.4 Les Bases de Données……………………………………….74 1.5 Profil d’une VM……………………………………………………..75 1.6 Processus de démarrage d’une VM ………………………………...77 1.7 Réseau des VMs……………………………………………………..79 1.8 Stockage par fichier des VMs………………………………………..81
  • 10.
    1.9 Conclusion duScénario 1a ………………………………………….82 2. Scénario lb : Gestion du stockage par bloc ………………………………..82 2.1. Schéma du scénario lb ……………………………………………....82 2.2. Composition de Cinder……………………………………………....83 2.3. Fonctionnement de Cinder…………………………………………...83 2.4. Problèmes rencontrés…………………………………………………84 2.5. Conclusion du Scénario 1b…………………………………………...85 III. Scénario 2 : Haute Disponibilité du Cloud Controller ……………………..85 1. Qu'est-ce que la HA ………………………………………………………..85 1.1 La HA Active/Active………………………………………………....86 1.2 La HA Active/Passive………………………………………………..86 1.3 L’IP flottante ou virtuelle…………………………………………….87 1.4 Services Stateless ou Statefull………………………………………..87 2. Scénario 2 : La HA au sein des AP] OpenStack……………………………88 2.1. Schéma du scénario 2a……………………………………………….88 2.2. But du Scénario…………………………………………………........89 2.3. Éléments physiques…………………………………………………..89 2.4. HA Active/Active avec HAProxy……………………………………89 2.5. HA Load Balancer avec KeepAlived………………………………...90 2.6. Bilan Scénario 2a…………………………………………………….90 3. HA SQL (Active/Active Statefull) ………………………………………...92 3.1. Schéma du Cluster SQL……………………………………………...92 3.2. Théorème du CAP……………………………………………………93 3.3. Gestion du Cluster SQL……………………………………………....94 IV. Scénario 3 : Collecte et entreposage des Logs………………………………95 1. Cahier des Charges………………………………………………………….95 2. Contraintes………………………………………………………………….95 3. Variantes de stockage de Logs………………………………………………96 3.1. Variante 1 : Stockage des Logs sous forme de fichiers……………….96 3.2. Variante 2 : Logstash-­‐> ElasticSearch……………………………....98 3.3. Variante3 : Logstash-­‐> Redis -­‐> Logstash -­‐>ElasticSearch……..102 3.4. Variante 4 : Abolition du serveur de Logs physique………………….103 3.5. Comparaison des quatre variantes et choix…………………………...103 3.6. Choix de la variante…………………………………………………..105
  • 11.
    4. Supervision desressources physiques……………………………………....105 5. Problèmes rencontrés………………………………………………………..106 6. Bilan du scénario 3…………………………………………………………..106 Chapitre 6 : Supervision des ressources avec Shinken……………………………………...108 I. Introduction……………………………………………………………………..108 1. But du scénario……………………………………………………………….108 2. Schéma de principe…………………………………………………………..108 3. Supervision des services d'APl OpenStack…………………………………...108 3.1. Problème au niveau des tests via l'IP Virtuelle ………………………..110 4. Supervision des ressources physiques………………………………………...110 5. Mise en place de tests interdépendants………………………………………..111 5.1 Finalité du test…………………………………………………………..111 5.2 Plugin de démarrage d’une VM intégré à Shinken……………………..112 6. Bilan du scénario………………………………………………………………113 Conclusion générale……………………………………………………………………………114 Bibliographie……………………………………………………………………………………115 Liste des abréviations …………………………………………………………………………116
  • 12.
    Liste des figures: Numéro Désignation page Figure 2.1 Virtualisation complète 11 Figure 2.2 Couches d’abstraction pour la gestion de la mémoire 12 Figure 2.3 Paravirtualisation 14 Figure 2.4 Hyperviseur 16 Figure2.5 Les services de cloud 19 Figure 3.1 Relations entre les couches de composants de VMware vSphere 24 Figure 3.2 VMware ESXI 25 Figure 3.3 VMware vSphere Client 26 Figure 3.4 VMware vSphere Web Client 27 Figure 3.5 VMware VCenter Server 27 Figure 3.6 vSphere vMotion 28 Figure 3.7 vSphere Storage vMotion 29 Figure 3.8 vSphere High Availability (HA) 29 Figure 3.9 vSphere Fault Tolerance 30 Figure 3.10 Xen server architecture 31 Figure 3.11 les composants principaux d’un déploiement typique 32 Figure 3.12 Citrix Studio 34 Figure 3.13 Architecture d’Eucalyptus 37 Figure 3.14 Les déférents couches d’OpenNebula 38 Figure 3.15 Les déférents taches d’Openstack 39 Figure 3.16 Les différents services d’openstack 41 Figure 4.1 L’architecture de réseau NAS 44 Figure 4.2 Protocole de stockage NAS 46 Figure 4.3 L’architecture de réseau SAN 47 Figure 4.4 Topologie de réseau SAN 49 Figure 4.5 L’architecture de réseau DAS 50 Figure 4.6 Topologie de réseau DAS 51 Figure 4.7 Architecture Cèph 52 Figure 4.8 Organisation des données dans Ceph 54 Figure 4.9 Illustration des deux modes de réplication des données 55 Figure 4.10 Création d'une carte réseau en mode agrégation 56 Figure 4.11 OSD installé 57 Figure 4.12 L'état de cluster Ceph 58 Figure 5.1 But des services OpenStack 68 Figure5.2 Différents types de messages 70 Figure5.3 Interface GUI Horizon 71 Figure5.4 Authentification Keystone 73 Figure5.5 Disques virtuels d'une VM 76 Figure5.6 Démarrage d'une VMs 77 Figure5.7 Configuration de la future VM 78 Figure5.8 Gestion de l'IP flottante 80 Figure5.9 Security-Group sous Horizon 81 Figure 5.10 Graphiques générés par Kibana 101 Figure 5.11 Chargement des JSON distants 102 Figure5.12 Aperçu du Cluster 106 Figure 6.1 Infrastructure opérationnelle 109 Figure 6.2 Fonctionnement de la HA malgré un des deux Horizon Down 109
  • 13.
    Liste des Schémas: Numéro Désignation page Schéma 5.1 schéma Scénario 1a 67 Schéma 5.2 schéma Scénario 1b 82 Schéma 5.3 Attribution d'un volume par bloc 83 Schéma 5.4 Principe de HA 85 Schéma 5.5 HA Active/Passive 86 Schéma 5.6 Gestion IP virtuelle 87 Schéma 5.7 HA au sein de l'API OpenStack 88 Schéma 5.8 HA au niveau SQL 92 Schéma 5.9 Théorème du CAP 93 Schéma 5.10 Récolte des Logs en un point central 96 Schéma 5.11 Producteurs de logs -> Consommateurs 98 Schéma 5.12 Cluster ElasticSearch 100 Schéma 5.13 Récupération des Logs avec Kibana 101 Schéma 5.14 Mémoire tampon de Logs 102 Schéma 5.15 Cluster ELS variante 2 103 Schéma 6.1 Monitoring des API et serveurs physiques 108 Schéma 6.2 Diagrammes de tests Shinken 112
  • 14.
    I INTRODUCTION GENERALE: Surfer dansles nuages a toujours été le rêve des hommes. Ce domaine était longtemps réservé aux poètes, et leur offrait la possibilité de s’évader des problèmes quotidiens qui les assaillaient. Mais depuis le jour où les avions et autres objets volants, conquirent le grand espace ciel, une grande majorité de gens pouvait sillonner plusieurs types de nuages. Ce rêve est également devenu réalité, dans le domaine de l’informatique. Actuellement, on parle beaucoup de Cloud Computing, et ce n’est pas par hasard. En effet, le matériel et les systèmes informatiques associés évoluent pour satisfaire les besoins de calcul qui s’accroîent chaque jour. Pour cela, les chercheurs et les technologues travaillent dur et péniblement afin de simplifier la gestion des infrastructures informatiques, la continuité d’activité et la réduction du coût qui représente une stratégie des entreprises d’aujourd’hui pour se focaliser sur leur métier spécifique marqué par une concurrence aiguë. Les solutions présentes sur le marché actuellement sont souvent complexes et très coûteuses. En parallèle, les évolutions quotidiennes au niveau des infrastructures réseaux et les systèmes d’information ont conduit à l’arrivée de nouveaux périphériques et technologies, ce qui rend la tâche de déploiement et de gestion encore plus difficile à assurer. De toutes ces contraintes est né le besoin de « la virtualisation » qui est survenu comme une solution révolutionnaire à un grand nombre de défis auxquels l’entreprise devait faire face. Assurément, remplacer un parc de serveurs physiques par une architecture virtualisée constitue une véritable révolution dans la conception des systèmes d’information. L’objectif de cette technique est d’augmenter la flexibilité et d’améliorer l’utilisation des ressources matérielles à moindre coût, tout en assurant la performance et la disponibilité des services. Cette notion a évoluée encore plus, et a fait apparaître un nouveau terme : le Cloud Computing. Dans les dernières années, cette terminologie, qui se base sur la virtualisation, a envahi le monde de la commercialisation, et s’est présentée comme une solution inédite arrivant jusqu’aux clients distants. Toutefois, cette tendance divulgue des défaillances, qui ont été souvent ignorées lors de ces déploiements en raison du coût, ou la complexité de mise en place. Les entreprises ont besoin de mettre en place plusieurs outils et services pour pouvoir exécuter leurs travaux, afin de bien assurer la gestion des projets, leurs qualités et la productivité des équipes ainsi que l’évolution sûre du produit pour une meilleure compétitivité sur le marché. C’est sous cette optique, que nous allons réaliser au niveau de ce PFE, une plateforme de virtualisation qui permet de migrer de l’architecture physique existante vers un environnement virtuel et déployer une solution haute disponibilité de stockage.
  • 15.
    II Problématique : Parmi lesproblèmes et les limites que nous avons étudiées taus allons citer : • Le non interoperabi lite entre les diffèrent types d'hyperviseurs (ESXi, KVM) • Facturation selon la performance des ressources répondre aux besoins des clients par fournit des machines et des serveurs virtuels de performances précises selon leurs besoins. • Cout élevé. A. Les hypothèses : Les principales motivations pouvant influences l'adoption d’une solution alternative aux posses de travail physiques traditionnels sont les suivantes : • Minimiser les coûts. • Gestion des postes de travail plus facile. • Accès distant. Facile • Flexibilité assurée. B. Le plan de travail : • Technologie de Virtualisation et de Cloud : Etat de L'art. • Etude Comparative et Choix de la solution. • Technologies de stockage et Haute Disponibilité. • Branche Fonctionnelle : Analyse et Spécification des Besoins. • Supervision des ressources avec Shinken. • Branche Technique : Spécifications Techniques. • -Perspectives futures. C. Les méthodes de recherche adoptées : Le projet a été mené en suivant 6 étapes : • Etude préalable. • Recueil des besoins. • Etude et conception du projet. • Phase de réalisation. • Mise en œuvre. • Evaluation.
  • 16.
    III D. Les raisonsdu choix du thème : Nous avons choisi ce thème car il nous permettre de : • Pouvoir faire les bons choix de configuration. • Savoir déployer manuellement un cloud Vsphére / OpenStack pour fournir du IaaS. • -Connaitre les bonnes pratiques de déploiement d’OpenStack et de Vsphére. • Être capable de déterminer l’origine d’une erreur dans OpenStack et un Vsphére. • -Savoir réagir face à un bug.
  • 17.
    IV Objectif du thème: - Avoir une solution fiable et efficace pour anticiperles difficultés quepourrait rencontrer un internaute et qui permettra de mettre en place des actions et des paramètres techniques, pour qu’une infrastructure informatique soit toujours en mesure de répondre à la requête d’un utilisateur - Manipuler et orchestrer des ressources dans un cloud Vsphére / OpenStack. - Définir, déployer et maintenir une infrastructure dans le cloud. - Connaitre le fonctionnement du projet Vsphére / OpenStack et ses possibilités Comprendre le fonctionnement de chacun des composants d’OpenStack /Vsphére. Les contraintes affrontées durant la réalisation du travail : Ce PFE a été effectué dans une période insuffisante. Au début du PFE, le sujet n'était pas encore clairement défini. En plus la difficulté de collecte des données et des informations avec le manque de références et matériel. Nous avons également eu de la difficulté à communiquer les uns avec les autres en raison de la séparation à cause de virus Corona.
  • 18.
  • 19.
    CHAPITRE 1 :Présentation de l’entreprise (lieu du stage) 1 • Présentation de l’organisme d’accueil : Section I : Fiche signalétique de NAFTAL District Carburants. A.Historique de NAFTAL : Issue de SONATRACH (Société National pour la recherche, Transport, production, transformation, la commercialisation des hydrocarbures), l’entreprise nationale de raffinage et de distribution de produits pétroliers (ERDP) a été crée par le décret N°80-101 datant du 06 Avril 1980. Entrée en activité le 01er Janvier 1982, elle fut chargée de l’industrie de raffinage et de la distribution de produits pétroliers. Le 04 Mars 1985, les districts suivants carburants, lubrifiants, pneumatiques et bitumes ont été regroupés sous le nom UND (Unité NAFTAL de Distribution). Durant l’année 1987, l’activité de raffinage est séparée de la distribution, conformément au Décret N°87-189 du 25 Aout 1987.Modifiant ainsi le décret N°80-101 du 06 Avril 1980, donnant naissance a une nouvelle entreprise nationale dénommée : « Entreprise nationale de commercialisation et de distribution de produits pétroliers » Sous le sigle de « NAFTAL ». Dès l’année 1998, elle change de statut et devient une société par action SPA et filiale SONATRACH a 100 %, elle interviendra par la suite dans les domaines suivants : • Dans l’enfûtage GPL. • Dans la formulation des bitumes. • Dans la distribution, stockage et commercialisation des carburants, GPL, lubrifiants, bitumes, pneumatiques, GPL/produits spéciaux. • Dans le transport des produits pétroliers. Le 01er Janvier 2000, l’activité GPL enfutage est séparée de l’activité CLP. Par décision N°S 554 du 29 mars 2000, il a été procédé à l’organisation générale de la division CLP et l’identification des zones de distribution « CLP » (Carburants Lubrifiants et Pneumatiques). Par décision N° 555 du 29 Mars 2000, il a été procédé à la création des zones de distribution CLP. Par décision N°S 606 du 10 Février 2001, il a été procédé à l’organisation et la classification des centres Bitumes de la division Bitume. Par décision N°S 705 du 17 juin 2002, il a été procédé à la re-nomination des zones de distribution CLP et GPL en District. Par décision N°S766 du 22 Décembre 2003, il a été procédé à la dissolution de la branche CLPB. Par la décision N°S 770 du 03 Janvier 2004, il a été procédé à la dissolution des districts CLP et création des districts commercialisation. A partir du 01er décembre 2006 l’activité carburant est séparée de l’activité commercialisation (L’activité carburant se charge du stockage et déstockage des carburants et l’activité commercialisation s’occupe essentiellement des achats, ventes, bilan annuel, projets…etc.). B.Principales tâches et responsabilités de NAFTAL : • Identifier et recenser les infrastructures, équipements et autres moyens matériels camions, canalisation) relevant de l’activité carburants du district, les structures d’organisation (services, maintenance, installations fixes, surveillance et entretien canalisations, reconnaissance produits…) et les moyens humains œuvrant pour l’activité carburants. • Suivre les plans établis par la branche carburant pour l’approvisionnement et le ravitaillement en carburants des dépôts et communiqué régulièrement les états d’exécution aux structures concernées.
  • 20.
    CHAPITRE 1 :Présentation de l’entreprise (lieu du stage) 2 • Exécuter les programmes de la distribution établis par les districts commercialisation pour la livraison de la clientèle. • Gérer les stocks en carburants au niveau des dépôts et communiques régulièrement des points de situation aux structures concernées de la branche. • Suivre l’exploitation et la maintenance des infrastructures de stockage et autres moyens (camions, canalisations) carburants des branches rattachées au district. • NAFTAL est responsable, en liaison avec les responsables concernés des centres carburants et canalisations, de la sûreté interne des installations et des moyens. • Gérer en liaison avec les structures de la branche, les relations avec les directions des raffineries NAFTEC, capotage et transport SNTR et tiers et les transmettre aux structures de la branche pour règlement. • Approuver les bordereaux inter unités (BIU) émis par les districts commercialisation vers le district carburant. C.Organisation de NAFTAL : Comme toute entreprise NAFTAL possède sa propre organisation nous illustrons les principaux services : 1. Service Informations de Gestion (ING) : sa mission consiste à : • Collecter, vérifier et analyser les informations de gestion de district. • Elaborer les tableaux de bord et rapports de l’activité du District. • Assurer l’installation et l’exploitation et la sauvegarde des logiciels de gestion et données afférentes. • Prêter assistance aux structures en matière d’exploitation des applications informatiques opérationnelles. 2. Département AMG (administration et moyen généraux) : Les missions du département AMG sont : • Assurer la gestion des moyens généraux du district • Assurer la gestion des ressources humaines • Assurer la gestion de l’administration • Assurer la gestion des œuvres sociales et culturelles 3. Département finances et comptabilité : Le département finance et comptabilité a pour mission de : • Coordonner et suivre toutes les activités de comptabilité de trésorier, budget et patrimoine. • Consolider, analyser les états comptables et veiller à la sincérité des comptes du District. • Veiller à la concordance des écritures comptables avec les flux physiques et financiers. Service trésorerie : il est composé de deux sections, la Section recettes et la section dépense.
  • 21.
    CHAPITRE 1 :Présentation de l’entreprise (lieu du stage) 3 Sa mission est de : • Suivre et contrôler les flux, recettes et dépenses de trésorerie. • Traiter les dossiers de paiement d’investigation, fournisseurs et autres dépenses. • Etablir les situations de rapprochement des comptes (recettes et dépenses) • Contrôler et effectuer les comptabilisations des comptes et grands livres de trésorerie. • Etablir des rapports d’activités. Service comptabilité générale : il est composé de deux sections, la Section SVCD et la Section comptabilité. Sa mission est de : • Procéder aux écritures comptables conformément aux préconisations du plan comptable national. • Elaborer les documents comptables (Bilans, balances et livres). • Contrôler les arrêtés de comptes et préparer les inventaires et bilans. • Elaborer les analyses et synthèses comptables. • Procéder aux opérations des clôtures et réouvertures des comptes. Service budgets et coûts : Ses diverses missions sont : • Elaborer les budgets prévisionnels d’investissement et de fonctionnement du District. • Consolider l’ensemble des charges nécessaires à la détermination du coût • Contrôler et traiter les situations financières du District • Procéder aux ajustements des budgets et crédits • Assurer le suivi régulier de la comptabilité analytique 4. Département Transport & Technique : Il a pour mission : • Elaborer les plans de maintenance préventive et curative des équipements, dépôts, et canalisation et en suivre l’exécution. • Elabore les plans annuels et pluriannuels de transport, en prenant en charge les besoins de distribution et ravitaillement des produits commercialisés. • Suivi de la réalisation des travaux. • Elaborer les plans et budgets d’investissement (rénovation, extension, remise à niveau, remplacement) des installations fixes, canalisation, réseau de stations-services et autres. • Etablir un rapport d’activité périodique. Ce département comporte les services suivants : Service exploitation et maintenance : Sa mission est de : • Vérifier l’application des prescriptions du règlement d’exploitation, de sécurité des équipements et installation fixes. • Etablir les performances de maintenance. • Assurer la maintenance des installations au niveau des dépôts carburants
  • 22.
    CHAPITRE 1 :Présentation de l’entreprise (lieu du stage) 4 Service études et réalisation : Sa mission est : • D’établir la partie technique des cahiers de charges. • De contrôler et diriger les différents travaux. • De suivre les travaux programmés ayants traits aux projets. Le District dispose de deux (02) dépôts carburants à Bejaïa, un (01) à TAHER /W. JIJEL, un (01) à Bordj Bou Arreridj et un (01) à M’SILA. Section II : Les Moyens et de l’entreprise NAFTAL : A.Les moyens de l’entreprise NAFTAL : Avec un personnel de 31500 agents. Affectif au 31/12/2009, NAFTAL est le premier et le seul distributeur de produit pétroliers en Algérie. Elle contribue de 51 % de l’énergie finale en fournissant plus de 10 millions de tonnes de produits pétroliers par an sous forme de : • Carburant. • Gaz de pétrole liquéfié. • Bitumes. • Lubrifiants Pour cela NAFTAL dispose de : • 67 centres et dépôts de distribution et stockage carburant. Lubrifiants et pneumatique. • 55 dépôts d’avitaillement d’aéronefs, centres et point de ventes à la mer. • 45 centres d’emballage GOL d’une capacité d’enfutage de 1.2 million de tonnes/an. • 59 dépôts relais de stockage GPL. ¬ 05 centres vrac GPL. • 16 unités de formulation de bitumes de 360.000 tonnes/an. • 3500 véhicules de distribution et 1800 engins de manutention et de maintenance. • 380 km de pipe-lines multi produits carburants et GPL. Et son réseau de distribution s’étend sur : • 1732 stations de service dont 328 en gestion directe par NAFTAL. • 124 points de vente d’essence sans plomb. • 268 points de vente GPL/CARBURANT. • 14550 points de vente GPL. La couverture des besoins du marché national en produit pétroliers implique des transports massifs de carburants et GPL depuis les sources de production vers les zones de consommation qui sont les districts.
  • 23.
    CHAPITRE 1 :Présentation de l’entreprise (lieu du stage) 5 Pour assurer cet équilibre entre l’offre et la demande, NAFTAL met à contribution plusieurs modes de transport : • Cabotage pipe : pour l’approvisionnement des entreprises à partir des raffineries. • Rail/chemin de fer : pour le ravitaillement des dépôts de l’intérieure du pays à partir des entrepôts. • Route : pour la livraison des clients et le ravitaillement des dépôts non desservis par le rail. • Pour accomplir sa mission de distribution des pétroliers, NAFTAL dispose d’un parc dépassant les 3 mille véhicules de distribution constitue de : • Tracteur routier. • Semi-remorques plateaux. • Semi-remorques citernes. • Camion citernes. • Camion plateaux. • Camion porte palettes. Ça lui permet d’assurer 70 à 75 % des livraisons clients, le reste étant assuré par les transporteurs tiers ou par les clients eux-mêmes. Par ailleurs, NAFTAL dispose de (7) barges pour le soutage des navires et affrète en permanence auprès des entreprises publiques de transport : • 160 citernes carburantes (SNTR). • 960 wagons-citernes (SNTF). • 04 caboteurs (SNTM/HYPROC). B.Produits commercialisés par l’entreprise : 1. Carburants :  Terre : NAFTAL commercialise quatre (4) types de carburants « terre » pour la motrice essence et diesel : • Essence super. • Essence normale. • Essence sans plomb. • Gas-oil. Ces produits stockés et distribués par NAFTAL sont tous issus des raffineries de NAFTEC et répondent entièrement aux normes de qualité algérienne.  Aviation : Jet a1-for Jos issus 18 kérosène utilisé par les avions.  Marine : FUEL BUNKERC • Norme iso 9217 FUEL 80(BTS), utilisée par les navires.
  • 24.
    CHAPITRE 1 :Présentation de l’entreprise (lieu du stage) 6 2. Gaz de pétrole liquéfié  Nature et composition : Les GPL désignent : gaz de pétrole liquéfié. Ce sont les mélanges de butane 4) et de propane (3). Les GPL peuvent être obtenus à partir de traitement des hydrocarbures tels que : • Le traitement du gaz naturel ou gaz associés. • Le raffinage du gaz naturel. • La liquéfaction du gaz naturel. Dans la gamme des produits GPL, NAFTAL commercialise trois (3) produits essentiels : • Le butane commercial. • Le propane commercial ; • Le GPL carburant « SIRGHAZ ». Suite à une phase d’étude d’expérimentation entamée en 1977.la décision d’introduire le GPL carburant « SIRGHAZ » est intervenue en 1983 avec l’adoption de bicarburation et de la mise en place de la réglementation liée aux conditions d’utilisation du GPL/C.  Lubrifiants : A travers son réseau de distribution étendu sur le territoire national, NAFTAL commercialise une gamme complète de lubrifiants qui couvrent tous les besoins du secteur automobile et industriel. Répondant à des normes d’emballages variés, depuis la boite de ½ litre au fut de 180 kg Les gammes commercialisées par NAFTAL sont : • Les huiles motrices à essence. • Les huiles motrices à diesel. • Les huiles motrices industrielles. • Les graisses.  Pneumatiques : Grace à des infrastructures de stockage et son réseau de distribution, NAFTAL commercialise des pneumatiques des grandes marques dans les catégories de véhicules les plus diverses : • Tourisme. • Camionnette. • Poids lourds. • Industriel. • Manutention. • Agraire. • Génie civil. • Cycle.
  • 25.
    CHAPITRE 1 :Présentation de l’entreprise (lieu du stage) 7 Portant le label de constructeurs renommés, les pneumatiques proposés par NAFTAL sont fournis après contrôle de qualités les plus strictes pour garantir la sécurité des utilisateurs et répondent amplement aux exigences requises.  Bitume : NAFTAL commercialise à partir de ses centres quatre (4) formes de bitumes : • Les bitumes purs 80/100 et 40/50 utilisés dans les domaines de la construction et des chaussées. • Les bitumes oxydés 85/25 utilisés pour l’étanchéité multicouches, pour l’isolement thermique et phonique et pour la protection des ouvrages d’art. • Ils sont commercialisés en vrac et sous deux (2) formes de conditionnement, en sacs de 20 kg et en futs de 200 kg. • Les bitumes fluidifiés ou CUT-BACKS ; ils sont obtenus en fluidifiant les bitumes purs avec le kérosène. • Les émulsions de bitumes sont des dispersions de bitumes pures dans une solution aqueuse.
  • 26.
  • 27.
    CHAPITRE 2 :Technologie de Virtualisation et de Cloud : Etat de L'art 8 I. Introduction : Alors que les données informatiques augmentent de façon exponentielle, et que les entreprises font de plus en plus appel aux processus informatiques pour gagner en productivité et en compétitivité, la possible réduction des coûts de gestion des infrastructures informatiques est une des principales priorités des entreprises. Ces dernières années, plusieurs moyens sont apparus pour aborder cette réduction des coûts, parmi lesquels, la virtualisation, et le Cloud Computing. La virtualisation et le Cloud Computing sont deux concepts différents, mais pourtant complémentaires. Nous allons dans ce chapitre nous attacher à vous présenter et vous définir ces deux notions, ainsi que leurs types et les usages possibles pour les entreprises. II. Technologie de Virtualisation : 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. 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'environnement 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 2. Historique de la virtualisation : Les premiers ordinateurs, qui occupaient plusieurs pièces d’un bâtiment, n’étaient pas faits pour exécuter plusieurs programmes à la fois. On concevait un programme (qui était à l’époque une simple succession de calculs), on le mettait dans la file d’attente des programmes, et quand le système d’exploitation avait fini de traiter un programme, on lui donnait le suivant dans la liste. 2.1. Premiers pas Très vite, dès la fin des années cinquante, l’idée de pouvoir exécuter plusieurs programmes en parallèle voit le jour. On parle de temps partagé (time sharing), de multiprogrammation, etc. L’idée était de pouvoir faire cohabiter plusieurs programmes au même moment, ayant tous accès au même matériel, sans qu’ils ne se gênent mutuellement. La virtualisation est très proche de concept. 2.2. Machines virtuelles Au milieu des années soixante, IBM effectue des recherches sur les systèmes virtualisés avec le projet M44/44X. L’architecture du système se basait sur des systèmes d’exploitation virtualisés (nommés 44X) s’exécutant au-dessus du matériel (une machine M44). Les systèmes invités étaient
  • 28.
    CHAPITRE 2 :Technologie de Virtualisation et de Cloud : Etat de L'art 9 gérés par une simple multiprogrammation. En 1967 est lancé, toujours par IBM, le système CP-40, le premier système offrant une virtualisation complète. Le CP-40 sera suivi par plusieurs évolutions, amenant chacune de nouvelles fonctionnalités pour les utilisateurs. On peut notamment citer Le système VM/370, qui a connu un très fort succès dans les entreprises, et est parfois encore en usage dans certaines entreprises aujourd’hui. 2.3. Amélioration des technologies Après le succès des machines virtuelles introduites par IBM, les technologies ont assez peu évolué. Le système hôte a vite été réduit à l’état de simple arbitre entre les systèmes invités, amenant la notion d’hyperviseur. Toutefois, toutes ces technologies de virtualisation étaient réservées au monde professionnel, destinées à être utilisées sur des mainframes coûtant plusieurs millions de dollars. Parallèlement à cela, le monde de la recherche (souvent financé par ces mêmes entreprises) a continué à étudier différentes possibilités pour améliorer les performances et à essayer de nouvelles technologies. La plupart de ces travaux de recherche sont toutefois restés assez confidentiels et n’ont que rarement été transposés sur un produit.1 2.4. Intérêt du grand public L’orientation « grand public » des technologies de virtualisation est beaucoup plus récente. Dans les années quatre-vingt-dix, l’intérêt pour les émulateurs de consoles de jeu ainsi que l’explosion du marché de l’informatique personnelle (les ordinateurs de type PC) ont fait prendre conscience aux entreprises qu’il y avait un marché pour la virtualisation sur PC. Des sociétés ont alors commencé à créer des produits de virtualisation basés sur des machines virtuelles pour les petites entreprises c’est à dire celles ne pouvant s’offrir des serveurs à plusieurs millions de dollars et pour les particuliers. À partir de ce moment-là, les technologies ont vraiment progressé, avec l’arrivée de nouveaux acteurs toujours prêts à innover pour se démarquer des concurrents. 3. Les types de virtualisations : 3.1. La virtualisation complète : La virtualisation complète (full virtualization), dénommée ainsi par opposition à la para- virtualisation, consiste à émuler l’intégralité d’une machine physique pour le système invité. Le système invité « croit » s’exécuter sur une véritable machine physique. Le logiciel chargé d’émuler cette machine s’appelle une machine virtuelle, son rôle est de transformer les instructions du système invité en instructions pour le système hôte. En effet, la machine virtuelle est un programme comme un autre du point de vue du système hôte, au même titre qu’un navigateur Internet ou un traitement de texte. Or, un système d’exploitation doit normalement manipuler le matériel à un niveau très bas. Les programmes utilisateurs n’ont pas d’accès direct au matériel, mais uniquement aux couches d’abstraction. La machine virtuelle émule donc de manière logique (c’est à dire avec du code) tout le matériel habituel de l’architecture de l’ordinateur cible. Le rectangle en fond vert est le système d’exploitation, seule partie à avoir un accès direct au matériel, ici représenté avec un fond bleu. Le rectangle en fond blanc est une application utilisateur, qui ne peut utiliser que la couche d’abstraction du système d’exploitation pour accéder indirectement au matériel. 1 Alain-B. TCHANA .Système d'Administration Autonome Adaptable: application au Cloud ,novembre 2011
  • 29.
    CHAPITRE 2 :Technologie de Virtualisation et de Cloud : Etat de L'art 10 En pratique, le disque dur de la machine virtuelle est la plupart du temps géré comme un (volumineux) fichier pour le système hôte, alors que la mémoire vive dont le système invité dispose est réservée par le programme de la machine virtuelle. Le reste de l’architecture de l’ordinateur peut Varier grandement selon les implémentations, mais on retrouve généralement au moins une carte réseau bas de gamme, un clavier 105 touches « standard » et une carte graphique bas de gamme.2 Figure 2.1 : Virtualisation complète L’utilisation de périphériques bas de gamme s’explique par le fait qu’il y a toujours un nombre minimal d’opérations supportées par toute catégorie de matériel sur un ordinateur : la vitesse de transfert la plus lente pour un disque dur, la résolution d’affichage la plus faible pour une carte graphique, etc. Or comme le comportement de ces périphériques est entièrement implémenté de manière logicielle par la machine virtuelle, émuler un périphérique avec le minimum de fonctionnalités permet de limiter la quantité de code à développer pour en couvrir le comportement. C’est la raison pour laquelle les cartes graphiques et les cartes réseaux sont la plupart du temps aux standards en vigueur dans les années quatre-vingt. Ce n’est toutefois pas la seule raison de l’émulation de périphériques bas de gamme. En effet, la plupart des évolutions ultérieures du matériel visent à améliorer les performances des périphériques, par exemple en augmentant le débit du disque dur ou la résolution supportée par la carte graphique. Cependant, les optimisations de performances sont dans ce cas sans objet, car elles ne se répercutent de toute manière pas sur un matériel physique en mesure de les supporter. La 2 Bhaskar Prasad Rimal, Eunmi Choi, and Ian Lumb. A taxonomy and survey of cloud computing systems. In Proceedings of the 2009 Fifth International Joint Conference on INC, IMS and IDC, NCM '09, pages 44_51, Washington, DC, USA, 2009. IEEE Computer Society.
  • 30.
    CHAPITRE 2 :Technologie de Virtualisation et de Cloud : Etat de L'art 11 rapidité du disque dur virtuel est par exemple limitée par la vitesse d’accès au fichier le représentant sur le système hôte. Le système s’exécutant dans la machine virtuelle est un système d’exploitation à part entière, tel qu’on pourrait en installer sur une machine physique : Microsoft Windows, GNU/Linux, Mac OS X, etc. Cette particularité est la caractéristique principale de la virtualisation complète : les systèmes invités n’ont pas à être modifiés pour être utilisés dans une machine virtuelle utilisant une technologie de virtualisation. Dans la pratique, c’est le cas pour les systèmes d’exploitation et les machines virtuelles les plus répandus. Le système invité peut à son tour exécuter n’importe quel programme prévu pour ce système, dans la mesure où il ne nécessite pas de matériel non fourni par la machine virtuelle (i.e. pas de carte graphique dernière génération ou de périphérique peu courant). Cette possibilité est due au fait que le système d’exploitation sert (entre autres) de couche d’abstraction entre le matériel et les applications, donc à partir du moment où le système fonctionne correctement, les applications s’exécutant par-dessus fonctionneront aussi. La traduction au vol des instructions du système invité est néanmoins une opération complexe et coûteuse en temps. En effet, la machine virtuelle ne peut pas, dans la plupart des cas, exécuter directement les instructions du système invité sur le système hôte. Les instructions de manipulation de la RAM, par exemple, doivent être interprétées par la machine virtuelle pour aboutir au résultat attendu, car c’est le processeur de la machine virtuelle qui est censé s’occuper de la gestion physique de la mémoire, et non le processeur de la machine hôte. La machine virtuelle doit donc implémenter en logiciel une gestion complète de la mémoire de l’invité, en utilisant les couches d’abstraction de l’hôte pour accéder à la RAM. Cet empilement de couches réduit significativement les performances, surtout en cas de forte pression sur la mémoire (i.e. quand la mémoire est utilisée de manière in00tensive : lecture, écriture, déplacement de données, etc.). La figure 2.2 détaille les couches d’abstraction entrant en jeu pour la gestion de la mémoire. Dans cette figure, le cadre en bleu foncé représente la couche matérielle ; le cadre vert est le système d’exploitation, qui a un accès privilégié au matériel. Le cadre en fond blanc est une application utilisateur, qui doit utiliser les couches d’abstraction du système d’exploitation représentées en vert foncé pour accéder au matériel. Le cadre bleu ciel représente le matériel émulé par la machine virtuelle, qui doit se comporte comme le matériel réel d’un ordinateur pour le système invité.
  • 31.
    CHAPITRE 2 :Technologie de Virtualisation et de Cloud : Etat de L'art 12 Figure 2.2 : Couches d’abstraction pour la gestion de la mémoire Cet empilage de couches est sensiblement identique pour tous les périphériques émulés par la machine virtuelle. On retrouve, du plus bas niveau au plus haut niveau : o Le matériel; o Le pilote du matériel pour le système hôte; o La couche d’abstraction du système hôte; o Le matériel émulé par la machine virtuelle; o Le pilote du matériel pour le système invité; o La couche d’abstraction du système invité. Les performances de la machine virtuelle sont donc limitées par les performances de la couche d’abstraction du système hôte et par la qualité de l’émulation du matériel implémenté. La séparation nette entre la machine virtuelle et le système hôte est un avantage certain pour la sécurité et la stabilité de la machine. En effet, comme la machine virtuelle est un simple programme, on peut très facilement limiter la quantité de mémoire qu’elle peut allouer, le temps processeur consommé, sa priorité par rapport aux autres programmes, etc. Toutes les possibilités d’administration et de configuration des applications offertes par le système hôte s’appliquent à la machine virtuelle. Cela permet par exemple d’attribuer une faible priorité à une machine virtuelle mais de lui permettre de réserver plus de mémoire, alors qu’une autre machine virtuelle aura plus de temps processeur à disposition, mais moins de RAM. Bien évidemment, comme les machines virtuelles sont de simples programmes utilisateurs, on peut en exécuter plusieurs à la fois sur le même système hôte, tant que les ressources sont disponibles. Ainsi, une machine multiprocesseur et disposant de suffisamment de mémoire vive et d’espace de stockage peut aisément accueillir plusieurs machines virtuelles, le système hôte répartissant au mieux la charge entre les différents processeurs.
  • 32.
    CHAPITRE 2 :Technologie de Virtualisation et de Cloud : Etat de L'art 13 Cependant du fait de l’empilement de couches d’abstraction et de l’impossibilité pour la machine virtuelle d’accéder directement au matériel, les performances du système invité sont assez éloignées de celles d’un système « natif ». Selon les implémentations, diverses solutions sont utilisées pour accélérer les machines virtuelles, par exemple en passant la plupart des instructions destinées au processeur virtuel directement au processeur physique3 . Cela accélère la vitesse de calcul du système invité. Il reste cependant le problème des Entrées/Sorties (E/S), c’est à dire les accès au disque, à la RAM, à la carte graphique, à la carte réseau, etc. D’une manière générale, on appelle Entrées/Sorties (I/O ou Input/Output) tout ce qui consiste à transférer des informations ou des données entre un périphérique et le système d’exploitation. Les E/S sont beaucoup plus dures à optimiser, car chaque système d’exploitation a une façon propre de gérer cela. Il faut donc cohabiter étroitement à la fois avec le système hôte pour l’accès réel au matériel et avec le système invité pour que ses accès au matériel soient le plus rapide possible. Cela amène une plus grande complexité de code, et une séparation en couches moins marquée que dans le modèle vu sur la figure 2.1. Cette « rupture » dans le modèle en couches est exploitée par une autre technologie de virtualisation : le para virtualisation. 3.2 La paravirtualisation : La para virtualisation (para virtualization ou encore para-virtualization) est très proche du concept de la virtualisation complète, dans le sens où c’est toujours un système d’exploitation complet qui s’exécute sur le matériel émulé par une machine virtuelle, cette dernière s’exécutant au-dessus d’un système hôte. Toutefois, dans une solution de para virtualisation, le système invité est modifié pour être exécuté par la machine virtuelle. Les modifications effectuées visent à rendre le système émulé « au courant » du fait qu’il s’exécute dans une machine virtuelle. De ce fait, il pourra collaborer plus étroitement avec le système hôte, en utilisant une interface spécifique, au lieu d’accéder au matériel virtuel via les couches d’abstraction. Au final, l’architecture obtenue est plus performante que l’empilement de couches d’abstraction de la figure 2.2. Le terme para-virtualisation a été mentionné pour la première fois dans [WSG02], où les auteurs définissent la para virtualisation comme la modification sélective de certaines parties de l’architecture virtuelle pour améliorer les performances, la réactivité sous forte charge et la simplicité de conception. L’idée du para virtualisation est toutefois plus ancienne que cela. Les premiers gros systèmes utilisant une architecture de virtualisation avaient déjà une technologie similaire, dès les années soixante-dix, même si elle n’avait pas de nom. En pratique, un système paravirtualisé possède quelques pilotes de périphériques et sous- systèmes modifiés, qui lui permettent de communiquer directement avec la machine virtuelle, sans avoir passé par une couche d’abstraction pour parler au matériel virtuel. Les pilotes para virtualisés échangent directement des données avec la machine virtuelle, sans avoir à passer par une émulation du comportement du matériel. Les parties du système hôte généralement modifiées pour tirer profit de la para virtualisation sont la gestion de la mémoire et la gestion des E/S. En effet, ce sont véritablement les deux goulets d’étranglement d’un système virtualisé, du fait du nombre de couches d’abstraction à traverser. Il est donc logique que les optimisations se portent là-dessus. La figure 2.3 montre la structure d’une machine virtuelle et d’un système hôte supportant le para virtualisation. Les pilotes non modifiés interagissent toujours avec le matériel émulé par la machine virtuelle (rectangle bleu ciel), alors que les pilotes modifiés communiquent directement les fonctions de la machine virtuelle (rectangle jaune)4 . La simplification qui en résulte communique 3 EuroCloud France. L'évolution maitrisée vers l’IaaS/PaaS. novembre 2011 4 Ignacio M. LlorenteBorja Sotomayor, Ruben S. Montero and Ian Foster
  • 33.
    CHAPITRE 2 :Technologie de Virtualisation et de Cloud : Etat de L'art 14 presque directement avec le système hôte, en contournant les couches d’abstraction virtuelles (i.e. le matériel émulé). Le reste de l’architecture est inchangé, la machine virtuelle est toujours une application utilisateur (rectangle blanc) et le système d’exploitation (rectangle vert) est toujours le seul à avoir un accès privilégié au matériel (rectangle bleu). Figure 2.3 : Paravirtualisation Les détails sur comment sont réalisées ces optimisations varient selon les implémentations, mais il s’agit en général pour le système invité d’utiliser des appels systèmes ou des instructions spécifiques pour renseigner la machine virtuelle sur les actions à entreprendre. Cette dernière réalise alors ces actions, et communique le résultat au système invité. Le type d’actions à effectuer varie également selon les implémentations, mais on retrouve en général tout ce qui est déplacement de données entre l’hôte et l’invité (accès disque, transfert réseau, etc.) et gestion de la mémoire. La paravirtualisation apporte un gain de performances avéré, du fait du contournement des couches d’abstraction. En effet, comme le système invité collabore activement avec la machine virtuelle, il ne se comporte plus comme un système d’exploitation à part entière s’exécutant directement sur du matériel. Au contraire, il adapte son comportement pour que les accès au matériel souvent difficiles à interpréter de manière efficace par la machine virtuelle soient transformés en des appels directs à cette dernière. De plus, étant donné que seules les couches de bas niveau du système invité ont été modifiées, toutes les applications qui pouvaient fonctionner dans une architecture de virtualisation complète peuvent aussi être utilisées dans une architecture paravirtualisée. Toutefois, cette augmentation des performances est restreinte à certains systèmes. En effet, comme le système invité doit être modifié pour être paravirtualisé, il faut bien évidemment que l’on ait la possibilité de réaliser cette opération de portage. Or, cela nécessite à la fois l’accès au code source du système d’exploitation et la permission du détenteur des droits de le modifier. Si cela ne pose aucun problème pour un système libre (notamment GNU/Linux et les systèmes BSD), il n’en va pas de même pour les systèmes propriétaires, tels que Microsoft Windows et Mac OS. L’usage de la paravirtualisation est donc généralement limité aux systèmes libres, sauf à utiliser une solution de
  • 34.
    CHAPITRE 2 :Technologie de Virtualisation et de Cloud : Etat de L'art 15 virtualisation propriétaire compatible avec un seul système d’exploitation invité, comme les produits que Microsoft propose pour ses systèmes d’exploitation. Tout comme la virtualisation complète, la paravirtualisation garde une séparation nette entre le système invité et le système hôte (cf. figures 2.1 et 2.3). De ce fait, seul le système hôte a un accès direct et exclusif au matériel. Le système invité doit donc toujours passer par la machine virtuelle pour accéder au matériel, qui passe à son tour par la couche d’abstraction. On peut donc améliorer davantage le processus en laissant au système invité un accès direct mais contrôlé au matériel. C’est le but des systèmes à hyperviseur 3.3 Virtualisation matérielle : L’utilisation d’un hyperviseur (hypervisor) est en quelque sorte l’évolution logique de la paravirtualisation, si l’on recherche encore une amélioration des performances. Dans les technologies précédentes, le système hôte était le seul à avoir un accès direct au matériel; avec un hyperviseur, le système hôte partage cet accès avec les systèmes invités. Au démarrage de l’ordinateur, c’est normalement le système d’exploitation qui prend la main et contrôle le matériel. Dans le cas de l’utilisation d’un hyperviseur, c’est un système minimaliste — l’hyperviseur — qui prend le contrôle du matériel. Ensuite, il fait appel à un système d’exploitation complet, qui sera donc exécuté par- dessus l’hyperviseur. Ainsi, le système d’exploitation doit passer par l’hyperviseur pour tout accès au matériel. On peut donc très facilement instancier un deuxième système d’exploitation, qui passera lui aussi par l’hyperviseur pour l’accès au matériel. Comme les systèmes d’exploitation doivent obligatoirement passer par ce dernier pour tout accès au matériel, l’hyperviseur peut s’assurer qu’ils n’accèdent qu’aux ressources autorisées, sans perturber le fonctionnement des autres systèmes. Figure 2.4 : Hyperviseur
  • 35.
    CHAPITRE 2 :Technologie de Virtualisation et de Cloud : Etat de L'art 16 La figure 2.4 détaille le principe de fonctionnement de l’hyperviseur. À la différence des technologies exposées précédemment, il n’y a cette fois pas d’accès direct au matériel (rectangle bleu) pour le système d’exploitation, uniquement une couche d’abstraction minimale fournie par l’hyperviseur (rectangle vert). L’hyperviseur est le seul à avoir un accès privilégié au matériel. Dans cette représentation, les systèmes cohabitent au même niveau de privilège, uniquement régulés par l’hyperviseur. Toutefois, selon les implémentations, il y a souvent un système privilégié, qui est en général le premier système démarré par l’hyperviseur. Ce système est alors autorisé à modifier les paramètres de l’hyperviseur ou à instancier de nouveaux systèmes invités. À l’opposé, sur d’autres implémentations, la différence entre hôte et invité est inexistante, tous les systèmes ont les mêmes privilèges et l’hyperviseur est alors contrôlé d’une autre manière. Si les deux technologies vues précédemment (virtualisation complète et paravirtualisation) utilisaient une machine virtuelle pour émuler le matériel, il n’en va pas de même avec un hyperviseur. Chaque système d’exploitation a un accès presque direct au matériel, par l’intermédiaire de l’hyperviseur. Il n’y a donc plus de couche d’abstraction logicielle, le matériel accessible est celui de la machine physique, avec toutes les fonctionnalités qu’il peut offrir. Le gain de performances est parfois significatif, notamment dans le cas des E/S, où le système peut utiliser toutes les extensions des périphériques pour accélérer les transferts. Ressources, alors que dans un système d’exploitation, on s’assurera qu’un programme utilisateur ne dérange pas les autres programmes du système. Au final, le contrôle des priorités est plus précis, et permet de garantir qu’un système invité isolé n’influera jamais sur l’accès aux ressources d’un autre système. Avec une architecture à base de virtualisation complète, si le système hôte est monopolisé par un processus utilisateur (par exemple un programme consommant énormément de mémoire), les systèmes invités peuvent se voir fortement ralentis dans leur activité. Tous les systèmes destinés à s’exécuter au-dessus d’un hyperviseur doivent être portés, comme les systèmes invités pour la paravirtualisation. Cette opération vise à adapter les couches bas niveau du système d’exploitation pour qu’elles communiquent avec l’hyperviseur plutôt qu’avec le matériel. Les inconvénients sont donc les mêmes que pour la paravirtualisation : il est nécessaire d’avoir accès au code source de tous les systèmes ainsi que l’autorisation du détenteur des droits. En outre, le portage est beaucoup plus lourd à réaliser pour fonctionner sur un hyperviseur. En effet, pour la paravirtualisation, seuls quelques pilotes et sous-systèmes avaient besoin d’être réécrits pour tirer parti de l’accélération. Au contraire, un hyperviseur nécessite la modification de toutes les couches d’accès au matériel; la complexité du code s’en trouve grandement augmentée, augmentant par là même la difficulté de maintenir le code. Le portage sur un hyperviseur revient quasiment à porter le système d’exploitation sur une nouvelle architecture matérielle. Les techniques vues jusqu’à présent étaient de complexité croissante, c’est à dire que chaque technologie était un peu plus complexe à mettre en œuvre et à que la précédente. Avec les technologies ayant trait au cloisonnement, c’est différent. En effet, le cloisonnement était au départ utilisé pour sécuriser et isoler des applications, sans rapport avec le fait d’isoler des systèmes d’exploitation, c’est seulement récemment que l’idée d’utiliser ces techniques pour la virtualisation a vu le jour. 4. Techniques de virtualisation : 4.1. L’Isolation et Le Cloisonnement : Une autre pratique répandue dans le domaine de la virtualisation est le cloisonnement. Derrière ce nom se cachent plusieurs technologies visant à séparer fortement les processus s’exécutant sur un même système d’exploitation. Le cloisonnement vise à isoler chaque processus
  • 36.
    CHAPITRE 2 :Technologie de Virtualisation et de Cloud : Etat de L'art 17 dans un conteneur dont il est théoriquement impossible de sortir. Un processus isolé de la sorte ne saura pas quels autres processus s’exécutent sur le même système, et n’aura qu’une vision limitée de son environnement. Le but principal de cette technologie est d’améliorer la sécurité du système d’exploitation et des applications. Isolé. Par exemple, si le système hôte est Solaris, alors tous les processus s’exécutant à l’intérieur d’une zone auront accès à la même version de ce Solaris. Les technologies de cloisonnement sont aussi utilisées dans d’autres domaines que les systèmes d’exploitation. Par exemple, le langage Java (de Sun Microsystems) propose une machine virtuelle (qui n’a rien à voir avec les machines virtuelles étudiées ici) qui est un interpréteur pour le langage Java. Cet interpréteur exécute tous les programmes Java dans un conteneur isolé, dont ils ne peuvent pas sortir. Le terme utilisé pour décrire cette technologie est sandbox (bac à sable). Le sandboxing est aussi une technologie de cloisonnement, mais au niveau d’un processus, sans que le système intervienne. Même si l’engouement pour la virtualisation est assez récent, les technologies de virtualisation et l’idée même de la virtualisation sont presque aussi anciennes que l’informatique. La section suivante fera un bref historique de la virtualisation. III. Technologie de Cloud Computing : 1. Technologie de Datacenter : Le datacenter ou centre de données informatique est le site physique où sont regroupées les différentes infrastructures, comme les baies de serveurs et de stockage. Ces sites de production informatique, équipés de systèmes d’alimentation et de refroidissement, hébergent les applications et données des entreprises, ou des particuliers dans le cadre de la mise à disposition de services applicatifs comme la messagerie ou le stockage de données dans le Cloud. Les géants du Cloud, les hébergeurs et les opérateurs disposent tous de multiples datacenters, plus ou moins grands. L’efficacité énergétique de ces datacenters est notamment mesurée grâce à un indicateur, le PUE. Pour des raisons de consommation d’énergie et environnementales, les opérateurs de datacenters s’efforcent d’atteindre un PUE le plus bas possible. Une des tendances du moment dans le datacenter porte sur les technologies de convergence et d'hyper-convergence. Et le mouvement de convergence entre les couches réseau, stockage et calcul ne s'arrête plus à l'échelle du rack. Il touche le centre de données, et permet l'automatisation et l'orchestration des ressources informatiques, via l'utilisation par la DSI d'outils software defined 2. Historique du Cloud Computing : Le Cloud computing est un concept assez récent. Sa première énonciation date de 1960 (John McCarthy), mais sa réelle mise en application a commencé au début des années 2000. Salesforce.com fut le premier hébergeur de Cloud en 1999, suivi en 2002 par Amazon. Le Cloud Computing met en œuvre l'idée de l’informatique utilitaire du type service public, proposée par John McCarthy en 1961 qui suggère que la technologie informatique partagée pourrait construire un bel avenir dans lequel la puissance de calcul et même les applications spécifiques pourraient être vendues comme un service public.
  • 37.
    CHAPITRE 2 :Technologie de Virtualisation et de Cloud : Etat de L'art 18 L’apparition du Cloud Computing vient d'une évolution de certaines technologies telles que la virtualisation du matériel informatique, les services web, ou l'architecture orientée services SOA (Service Oriented Architecture). La virtualisation a été la première pierre de l'ère du Cloud Computing. En effet, cette notion permet d'optimiser les ressources matérielles en les partageants entre plusieurs environnements dans le but De pouvoir exécuter plusieurs systèmes « virtuels » sur une seule ressource physique et fournir une couche supplémentaire d’abstraction du matériel. Le Cloud computing est donc la juxtaposition de ces technologies pour passer à la vitesse supérieure sur l’exploitation de données à travers Internet. 3. Bénéfices du cloud Computing : 3.1. Pour le fournisseur : • Aucun investissement préalable. • Service d'une grande disponibilité. • Facturation à la consommation. • Version toujours à jour et identique pour tous les utilisateurs (cas du SaaS). • Architecture sur mesure adaptable selon les besoins. 3.2. Pour l'entreprise : • La sécurité des données • La réduction des coûts • Une parfaite adaptation aux besoins métiers des entreprises • Une prise en charge optimale de l’infrastructure informatique • Une technologie flexible et évolutive IV. Les différents services : Nous parlons généralement de 3 services que nous utilisons différemment selon nos besoins. Certains appellent ces services les couches de cloud et nous les représentons souvent sous forme d’une pyramide comme la montre
  • 38.
    CHAPITRE 2 :Technologie de Virtualisation et de Cloud : Etat de L'art 19 Figure2.5 : Les services de 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 installer 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 applications 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. V. Types et Modèles de déploiement de cloud : Nous distinguons quatre modèles de déploiement qui n’ont pas une grande influence sur les systèmes déployés 5 • Cloud public: C’est le cloud dans le sens traditionnel où les services sont offerts au grand public 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 5 JunjiePeng, Xuejun Zhang, Zhou Lei, Bofeng Zhang, Wu Zhang, and Qing Li. Comparison of several Cloud computing plateforms. In Proceedings of the 2009 Second International Symposium on Information Science and Engineering, ISISE '09, pages 23_27, Washington, DC, USA, 2009. IEEE Computer Society.
  • 39.
    CHAPITRE 2 :Technologie de Virtualisation et de Cloud : Etat de L'art 20 • 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 VI. Les solutions de cloud : 1. Eucalyptus : Eucalyptus est un outil open source issu d’un projet de recherche de l’université de Californie. Il est développé en C, Java, Python et est disponible sous deux licences. Une licence GPL gratuite supportant les hyperviseurs Xen et KVM et une licence commerciale offrant des fonctionnalités avancées telles que le support de VMware. Il permet de construire aussi bien les solutions privées du cloud computing que les solutions publiques. Son grand avantage est qu’il est intégré dans les distributions Ubuntu et Debian. Eucalyptus offre des interfaces compatibles avec les services EC2 d’Amazon. Ce qui lui confère la possibilité d’être employé pour les solutions hybrides de cloud computing. L’architecture d’Eucalyptus est constituée de quatre composants principaux (Nurmi et al, 2008 ; Alrwais, 2011). • Le contrôleur de nœud (Node controller NC) : contrôle l’exécution, et l’arrêt des machines virtuelles présentes sur le nœud où il est exécuté. • Le contrôleur de cluster (cluster controller CC) : collecte les informations sur les différents nœuds d’un cluster et planifie l’exécution des machines virtuelles sur chaque nœud. Le contrôleur de stockage (Warlus) : c’est le composant qui gère l’accès au service de stockage. Il est souvent intégré au contrôleur du cloud (CLC). • Le contrôleur de cloud (CLC): C’est le point d’entrée (Front end) des utilisateurs et administrateurs du système. Il collecte des informations sur les nœuds et planifie leur exécution au travers des contrôleurs de clusters (CCs). Il expose les services du cloud à travers une application Web mais également à travers des interfaces compatibles EC2. 2. OpenNebula OpenNebula, purement open source permet de déployer des Cloud privés, hybrides et publics. Ecrite en C++, Ruby et Shell, elle supporte les plateformes de virtualisation Xen, KVM et VMware ainsi que le service “on-demand” d’Amazon EC2. Le projet est publié sous licence Apache 2.0. Parmi ses fonctionnalités : gestion centralisée des machines virtuelles et des ressources physiques, répartition des charges, extension des capacités par ajout de serveurs physiques. Beaucoup de ces solutions sont avant tout des solutions d’infrastructure permettant une gestion simplifiée d’architectures matérielles complexes.
  • 40.
    CHAPITRE 2 :Technologie de Virtualisation et de Cloud : Etat de L'art 21 3. OpenStack Il est né de la fusion de deux projets portés l’un par la Nasa et l’autre issu de l’offre de l’hébergeur américain Rackspace Cloud Server. L’ensemble de la plateforme est disponible sous licence Apache 2.0. OpenStack est un logiciel libre qui permet la construction de Cloud privé et public. Il est aussi une communauté et un projet en plus d'un logiciel qui a pour but d'aider les organisations à mettre en œuvre un système de serveur et de stockage virtuel. Il s'installe sur un système d'exploitation libre comme Ubuntu ou Debian et se configure entièrement en ligne de commande. C'est un système robuste et qui a fait ses preuves auprès des professionnels du domaine. En comparaison avec les autres produits, OpenStack semble avoir la plus grande et la plus active communauté. Les membres de la communauté sont toujours prêts à aider les autres à trouver des solutions aux problèmes qui se posent. La technologie est populaire parmi une vaste communauté de spécialistes et est soutenue par des sociétés telles que Cisco, Dell, NASA, Intel, AMD, Citrix, Rackspace, et RightScale.  Les caractéristiques principales d’OpenStack sont les suivantes : • Capacité à gérer les ressources du serveur de produits virtualisés. • Capacité à gérer des réseaux locaux. • Gestion de l'image de la machine virtuelle. • Groupes de sécurité. • Contrôle d'accès basé sur les rôles. • VNC proxy via un navigateur Web.
  • 41.
  • 42.
    CHAPITRE 3 :Etude comparative et choix de la solution 22 I. Introduction : Avant toute chose, rappelons ce qu'est la virtualisation : la virtualisation est une couche d'abstraction informatique qui permet de faire fonctionner plusieurs serveurs, systèmes ou applications sur un même serveur physique (tout dépend du type de virtualisation choisie) La virtualisation a donc permis par ce processus d'ouvrir de nombreuses portes, et constitue la pierre angulaire du Cloud1 . En effet, elle représente donc une formidable ouverture à différents niveaux : utilisateurs, entreprises, services IT... Les avantages sont nombreux : en termes économiques (moins coûteux), de centralisation, de sécurité et de partage de données, en termes de performances (virtualisation applicative/de bureau) etc... Il est également important de comprendre la notion d'hyperviseur et d'hyperviseur de type 1 et 2. Tout d'abord, un hyperviseur est cette fameuse couche d'abstraction qui rend possible la virtualisation : il permet à plusieurs systèmes d'exploitation (OS) de fonctionner simultanément sur une même machine physique. L'hyperviseur de type 1 (natif) s'exécute directement sur la plateforme matérielle alors qu'un hyperviseur de type 2 (hosté) s'exécute à l'intérieur d'un même système d'exploitation. Un hyperviseur héberge des machines virtuelles (VM), qui sont le "résultat" de la virtualisation et ce à partir de quoi on travaille. Il existe différents types de virtualisation (attention ce n'est pas la même chose que le type d'hyperviseur) donc différentes "natures" de VM, qui nécessitent chacune une solution spécifique (n'importe quelle solution ne peut virtualiser n'importe quoi): - La virtualisation de bureau, - La virtualisation d’applicative, - La virtualisation de de réseau, - La virtualisation de de stockage, Etc... II. Solutions de Virtualisation : Le marché des solutions de virtualisation est un marché extrêmement concurrentiel. Parmi les principaux acteurs composant ce marché, nous détaillerons les offres des trois principaux éditeurs, à savoir VMware, Citrix et Microsoft. VMware est le plus vieux et le plus gros éditeur sur le marché de la virtualisation, filiale du groupe EMC et fondée en 1998, cette compagnie propose une gamme de produits et services complète associée à la virtualisation2 . 1 Le cloud computing une nouvelle filière fortement structurante,septembre2012 2 Marvin Rambhadjan and Arthur Schutijser. SURFnet cloud computing solutions.
  • 43.
    CHAPITRE 3 :Etude comparative et choix de la solution 23 Pour mettre en place notre plateforme de virtualisation, nous avons choisi la solution VMware qui est le leader du marché dans le domaine. 1. VMware (vSphere, ESXi...) : 1.1. VMware vSphere : VMware vSphere gère de grandes collections d'infrastructure (par exemple des processeurs, le stockage et la gestion de réseau) sous la forme d'un environnement d'exploitation transparent et dynamique, ainsi que la complexité d'un centre de données. La pile logicielle VMware vSphere est constituée des couches de virtualisation, de gestion et d'interfaces. Figure 3.1 : Relations entre les couches de composants de VMware vSphere • Couche de virtualisation : La couche de virtualisation de VMware vSphere inclut des services d'infrastructure et d'application. L'infrastructure fournit, entre autres, les services de traitement et de stockage et les services réseau extraient, agrègent et allouent les
  • 44.
    CHAPITRE 3 :Etude comparative et choix de la solution 24 ressources matérielles ou d'infrastructure. Les services d'infrastructure comprennent les types suivants : • Services de traitement : Inclut les fonctions VMware qui permettent de ne pas tenir compte des ressources serveur hétérogènes sous-jacentes. Les services de traitement agrègent ces ressources sur un grand nombre de serveurs discrets les affectent aux applications. • Services de stockage : Il s'agit de l'ensemble de technologies qui permettent d'utiliser et de gérer efficacement le stockage dans les environnements virtuels. • Services de réseau : Il s'agit de l'ensemble de technologies qui simplifient et améliorent la gestion de réseau dans les environnements virtuels. • Couche de gestion : VMware vCenter Server est le point central de la configuration, du provisionnement et de la gestion des environnements informatiques virtualisés. • Couche d'interfaces : Les utilisateurs peuvent accéder au centre de données VMware vSphere via des clients à interface graphique, tels que vSphere Client ou vSphere Web Client. En outre, ils peuvent accéder au centre de données via des machines clientes qui utilisent des interfaces de ligne de commande et des kits SDK pour la gestion automatique. 1.2 Composants et fonctionnalités : VMware vSphere Une présentation des composants et fonctions de VMware vSphere explique les composants et leurs interactions. VMware vSphere inclut les composants et fonctions suivants : • VMware ESXi : Une couche de virtualisation fonctionne sur des serveurs physiques qui analysent le processeur, la mémoire, le stockage et les ressources dans les machines virtuelles multiples Figure 3.2 : VMware ESXI
  • 45.
    CHAPITRE 3 :Etude comparative et choix de la solution 25 • VMware vSphere Client : Une interface permettant aux utilisateurs de se connecter à distance vCenter Server ou ESXi depuis n'importe quel PC Windows Figure 3.3 : VMware vSphere Client • VMware vSphere Web Client : Une interface Web permet aux utilisateurs de se connecter à distance à vCenter Server depuis divers navigateurs Web et systèmes d'exploitation.
  • 46.
    CHAPITRE 3 :Etude comparative et choix de la solution 26 Figure 3.4 : VMware vSphere Web Client • VMware vCenter Server : Le point central pour configurer, approvisionner et gérer des environnements informatiques virtualisés. Il fournit les services essentiels du centre de données : contrôle d'accès, surveillance des performances et • Gestion des alarmes.
  • 47.
    CHAPITRE 3 :Etude comparative et choix de la solution 27 Figure 3.5 : VMware VCenter Server • VSphere vMotion : Permet de migrer des machines virtuelles sous tension depuis un serveur physique vers un autre sans interruption avec une disponibilité de service continue et une intégrité de transaction complète . Figure 3.6 : vSphere vMotion • VSphere Storage vMotion : Permet de migrer des fichiers de machine virtuelle d'une banque de données vers une autre sans interruption de service. Vous placez la machine virtuelle et tous ses disques dans un seul emplacement ou sélectionnez des emplacements distincts pour le fichier de configuration de la machine virtuelle et chaque disque virtuel. La machine virtuelle reste sur le même hôte pendant Storage vMotion. La migration avec Storage vMotion permet de transférer les disques virtuels ou le fichier de configuration d'une machine virtuelle vers une nouvelle banque de données alors que la machine
  • 48.
    CHAPITRE 3 :Etude comparative et choix de la solution 28 virtuelle s'exécute. La migration avec Storage vMotion permet de transférer le stockage d'une machine virtuelle sans interrompre la disponibilité de la machine virtuelle3 . Figure 3.7 : vSphere Storage vMotion • VSphere High Availability (HA) : Fonction qui offre une haute disponibilité pour les machines virtuelles. En cas de panne d'un serveur, les machines virtuelles affectées sont redémarrées sur d'autres serveurs disponibles ayant une capacité disponible. 3 Peter Sempolinski and Douglas Thain. A comparison and critique of eucalyptus, opennebula and nimbus. In Proceedings of the 2010 IEEE Second International Conference on Cloud Computing Technology and Science , CLOUDCOM '10, pages 417_426, Washington, DC, USA, 2010. IEEE Computer Society.
  • 49.
    CHAPITRE 3 :Etude comparative et choix de la solution 29 Figure 3.8 : vSphere High Availability (HA) • VSphere Fault Tolerance : Assure la disponibilité permanente en protégeant une machine virtuelle avec une copie. Lorsque cette fonction est activée pour une machine virtuelle, une seconde copie de la machine d'origine (ou principale) est créée. Toutes les actions effectuées sur la machine virtuelle primaire sont également effectuées sur la seconde machine virtuelle. Si la machine virtuelle principale devient indisponible, la seconde machine devient active immédiatement.
  • 50.
    CHAPITRE 3 :Etude comparative et choix de la solution 30 Figure 3.9 : vSphere Fault Tolerance 2. Citrix (Xenserver...) : • Citrix XenServer est une solution de virtualisation qui permet de déployer rapidement et simplement des machines virtuelles Windows et Linux hautes performances. • Xenservers’appuie sur l’hyperviseur open source Xen qui installe une fine couche logicielle sur le matériel de la machine nue, ce qui lui rend plus rapide et plus sûre par rapport aux autres hyperviseurs. Il s’appuie en outre sur les toutes dernières solutions Intel VT et AMD-V de virtualisation assistée par matériel. • XenServer permet en outre de gérer ces machines et les ressources réseau et de stockage qui leur sont associées à partir d’une console de gestion unique et très simple d’emploi. • La technologie XenServer s’appuie sur les toutes dernières solutions Intel VT et AMD-V de virtualisation assistée par matériel. L’hyperviseur Xen est exceptionnellement léger (moins de 50 000 lignes de code), ce qui se traduit pour l’hôte par une charge extrêmement faible et des performances quasi natives. • Citrix XenServer est performant et sécuritaire. Sa technologie et ouverte aux capacités de gestion étendues de XenCenter qui constitue une plateforme de virtualisation idéale, parfaitement adaptée à la consolidation des serveurs, au développement et au test de logiciels et aux projets de continuité de service.
  • 51.
    CHAPITRE 3 :Etude comparative et choix de la solution 31 Figure 3.10 : Xen server architecture 2.1 Composants et fonctions : 2.1.1 . Composants principaux : Cette illustration affiche les composants principaux d’un déploiement typique, qui est appelé un site. Figure 3.11 : les composants principaux d’un déploiement typique
  • 52.
    CHAPITRE 3 :Etude comparative et choix de la solution 32 • Delivery Controller : Delivery Controller est le composant de gestion centralisée d’un site. Chaque site possède un ou plusieurs Delivery Controller. Il est installé sur au moins un serveur dans le centre de données. Pour la fiabilité et la disponibilité du site, installez des Controller sur plusieurs serveurs4 . Si votre déploiement comprend un hyperviseur ou un service de cloud, les services Controller communiquent avec lui pour distribuer des applications et des bureaux, s’authentifier et gérer l’accès des utilisateurs, négocier des connexions entre les utilisateurs et leurs applications et bureaux, optimiser l’utilisation des connexions et équilibrer la charge de ces connexions. Le service broker du Controller contrôle quels utilisateurs sont connectés et depuis quel endroit, quelles ressources de session les utilisateurs possèdent-ils et si les utilisateurs doivent se reconnecter aux applications existantes. Le service broker exécute des applets de commande PowerShell et communique avec l’agent broker situé sur les VDA via le port TCP 80. Il n’est pas possible d’utiliser le port TCP 4435 . Monitor Service collecte les données historiques et les places dans la base de données de contrôle. Ce service utilise le port TCP 80 ou 443. Les données provenant des services Controller sont stockées dans la base de données du site. Le Controller gère l’état des bureaux, les démarre ou les arrête à la demande et en fonction de la configuration de l’administration. Dans certaines éditions, le Controller permet d’installer Profile Management pour gérer les paramètres de personnalisation des utilisateurs dans des environnements Windows physiques ou virtualisés. • Base de données : Au moins une base de données Microsoft SQL Server est requise pour chaque site pour stocker toutes les informations de configuration et de session. Cette base de données stocke les données collectées et gérés par les services qui constituent le Controller. Installez la base de données dans votre centre de données et assurez-vous qu’elle possède une connexion permanente au Controller. Le site utilise également une base de données de journalisation de la configuration et une base de données de contrôle. Par défaut, ces bases de données sont installées dans le même emplacement que la base de données du site, mais vous pouvez modifier ce paramètre. • Virtual Delivery Agent (VDA) : Le VDA est installé sur chaque machine physique ou virtuelle de votre site que vous mettez à disposition des utilisateurs. Ces machines fournissent des applications ou des postes de travail. Le VDA permet aux machines de s’enregistrer auprès du Controller, qui permet à la machine et aux ressources qu’elle héberge d’être mise à la disposition des utilisateurs. Les VDA établissent et gèrent la connexion entre la machine et l’appareil de l’utilisateur6 . Les VDA vérifient également qu’une 4 ThiagoDamascenoCordeiro, Douglas BritoDamalio, NadilmaCintra 5 Vivansas.p.r.l.Cloud Computing Enjeux, Perspectives et Impacts métiers ,septempre 2009 6 WygwanLe Cloud Computing : Réelle révolution ou simple évolution ? Webographie
  • 53.
    CHAPITRE 3 :Etude comparative et choix de la solution 33 licence Citrix est disponible pour l’utilisateur ou la session et appliquent les stratégies configurées pour la session. Le VDA communique des informations de session au service Broker dans le Controller via l’agent Broker dans le VDA. L’agent broker héberge de multiples plug-ins et collecte des données en temps réel. Il communique avec le Controller sur le port TCP 80. Le mot « VDA » est souvent utilisé pour faire référence à l’agent ainsi qu’à la machine sur laquelle il est installé. Les VDA sont disponibles pour les systèmes d’exploitation Windows mono-session et multi- session. Les VDA pour les systèmes d’exploitation multi-session Windows autorisent plusieurs utilisateurs à se connecter au serveur à un moment donné. Les VDA pour les systèmes d’exploitation mono-session Windows ne permettent qu’à un seul utilisateur de se connecter au bureau à la fois. Les VDA Linux sont également disponibles. • Citrix StoreFront : StoreFront authentifie les utilisateurs et gère les magasins de bureaux et d’applications auxquels les utilisateurs accèdent. Il peut héberger votre magasin d’applications d’entreprise qui fournit aux utilisateurs un accès en libre-service aux bureaux et aux applications que vous mettez à leur disposition. Il assure également le suivi des abonnements aux applications des utilisateurs, des noms de raccourcis et d’autres données. Cela permet de garantir que les utilisateurs ont une expérience cohérente sur plusieurs appareils. • Application Citrix Workspace : Installée sur les machines utilisateur et autres points de terminaison, tels que les bureaux virtuels, l’application Citrix Workspace offre aux utilisateurs un accès en libre-service, rapide et sécurisé aux documents, applications et bureaux. L’application Citrix Workspace offre également un accès à la demande aux applications Windows, Web et Saas (Software as a Service). Pour les périphériques qui ne peuvent pas installer le logiciel de l’application Citrix Workspace spécifique au périphérique, l’application Citrix Workspace pour HTML5 offre une connexion via un navigateur Web compatible HTML5. • Citrix Studio : Studio est la console de gestion où vous configurez et gérez votre déploiement Citrix Virtual Apps and Desktops. Studio élimine le besoin de consoles de gestion distinctes pour gérer la mise à disposition des applications et des postes de travail. Studio offre des assistants pour vous guider dans le processus de configuration de votre environnement, créer des charges de travail pour héberger les applications et bureaux, et attribuer des applications et des bureaux aux utilisateurs. Vous pouvez également utiliser Studio pour allouer et suivre les licences Citrix pour votre site. Studio obtient les informations qu’il affiche à partir du Broker Service dans le Controller, communiquant via le port TCP 80. Voici un aperçu de Studio :
  • 54.
    CHAPITRE 3 :Etude comparative et choix de la solution 34 Figure 3.12 : Citrix Studio • Citrix Director : Director est un outil Web qui permet aux équipes d’assistance informatique de surveiller un environnement, de résoudre les problèmes avant qu’ils ne deviennent critiques et de réaliser des tâches d’assistance pour les utilisateurs finaux. Vous pouvez utiliser un déploiement de Director pour vous connecter à et contrôler plusieurs sites Citrix Virtual Apps ou Citrix Virtual Desktops. Director affiche les éléments suivants :  Données de session en temps réel à partir du Broker Service dans le Controller, qui comprennent des données que le service Broker obtient depuis l’agent broker dans le VDA.  Données de site historiques provenant du service Monitoring dans le Controller. Director utilise les données de performances et heuristiques ICA capturées par l’appareil Citrix Gateway pour créer des analyses à partir des données, puis les présenter aux administrateurs. Vous pouvez également afficher et interagir avec les sessions d’un utilisateur via Director, à l’aide de l’Assistance à distance Windows. • Serveur de licences Citrix : Le serveur de licences gère les licences de vos produits Citrix. Il communique avec le Controller pour gérer les licences pour chaque session utilisateur et avec Studio pour allouer les fichiers de licences. Un site doit avoir au moins un serveur de licences pour stocker et gérer vos fichiers de licences. • Hyperviseur ou service de cloud : L’hyperviseur ou le service de cloud héberge les machines virtuelles de votre site. Il peut s’agir des machines virtuelles que vous utilisez pour héberger les applications et les bureaux, ainsi
  • 55.
    CHAPITRE 3 :Etude comparative et choix de la solution 35 que les machines virtuelles que vous utilisez pour héberger les composants de Citrix Virtual Apps and Desktops. Un hyperviseur est installé sur un ordinateur hôte entièrement dédié à l’exécution de l’hyperviseur et l’hébergement des machines virtuelles. Les solutions Citrix Virtual Apps and Desktops prennent en charge divers hyperviseurs et services cloud. Bien que de nombreux déploiements requièrent un hyperviseur, vous n’en avez pas besoin pour fournir un accès PC distant. De même, un hyperviseur n’est pas requis lorsque vous utilisez Provisioning Services (PVS) pour provisionner des machines virtuelles. Pour plus d’informations, consultez : • Ports réseau. • Bases de données. • Services Windows des composants de Citrix Virtual Apps and Desktops : Configurer les droits des utilisateurs. • Hyperviseurs et services de cloud pris en charge : Configuration système requise. 2.1.2 . Composants supplémentaires : Les composants supplémentaires suivants, non affichés dans le diagramme ci-dessus, peuvent également être inclus dans les déploiements Citrix Virtual Apps and Desktops. Pour de plus amples informations, consultez leur documentation respective. • Citrix Provisioning : Citrix Provisioning (anciennement Provisioning Services) est un composant facultatif disponible avec certaines éditions. Il offre une alternative à MCS pour le provisioning des machines virtuelles. Alors que MCS permet de créer des copies d’une image principale, PVS livre l’image principale en streaming vers les machines utilisateur. PVS ne nécessite pas d’hyperviseur pour effectuer cette opération, vous pouvez donc l’utiliser pour héberger des machines physiques. PVS communique avec le Controller afin de fournir aux utilisateurs des ressources. • Citrix Gateway : Lorsque les utilisateurs se connectent en dehors du pare-feu d’entreprise, Citrix Virtual Apps and Desktops peut utiliser la technologie Citrix Gateway (anciennement Access Gateway et NetScaler Gateway) pour sécuriser les connexions avec le protocole TLS. L’Appliance virtuelle Citrix Gateway ou VPX est une appliance SSL VPN déployée dans la zone démilitarisée (DMZ). Il fournit un point d’accès sécurisé unique via le pare-feu d’entreprise. • Citrix SD-WAN : Dans les déploiements dans lesquels des bureaux virtuels sont mis à disposition auprès des utilisateurs dans des emplacements distants, des succursales par exemple, la technologie Citrix SD- WAN peut être utilisée pour optimiser les performances. Les répéteurs accélèrent les performances sur les réseaux étendus. Avec les répéteurs, les utilisateurs des succursales bénéficient des performances d’un réseau local sur le réseau étendu. Citrix SD-WAN permet de définir des priorités dans l’expérience des utilisateurs, par exemple pour éviter une dégradation des performances au niveau de la succursale en cas d’envoi de fichiers volumineux ou de tâches d’impression importantes sur le réseau. L’optimisation WAN HDX assure une compression avec système de jetons et déduplication des données, réduisant considérablement les besoins en bande passante tout en améliorant les performances.
  • 56.
    CHAPITRE 3 :Etude comparative et choix de la solution 36 III. Solutions de cloud : 1. Solution Eucalyptus : Eucalyptus est un outil open source issu d’un projet de recherche de l’université de Californie. Il est développé en C, Java, Python et est disponible sous deux licences. Une licence GPL gratuite supportant les hyperviseurs Xen et KVM et une licence commerciale offrant des fonctionnalités avancées telles que le support de VMware. Il permet de construire aussi bien les solutions privées du cloud computing que les solutions publiques. Son grand avantage est qu’il est intégré dans les distributions Ubuntu et Debian. Eucalyptus offre des interfaces compatibles avec les services EC2 d’Amazon. Ce qui lui confère la possibilité d’être employé pour les solutions hybrides de cloud computing. L’architecture d’Eucalyptus est constituée de quatre composants principaux (Nurmi et al, 2008 ; Alrwais, 2011)7 . - Le contrôleur de nœud (Node controller NC) : contrôle l’exécution, et l’arrêt des machines virtuelles présentes sur le nœud où il est exécuté. - Le contrôleur de cluster (cluster controller CC) : collecte les informations sur les différents nœuds d’un cluster et planifie l’exécution des machines virtuelles sur chaque nœud. - Le contrôleur de stockage (Warlus) : c’est le composant qui gère l’accès au service de stockage. Il est souvent intégré au contrôleur du cloud (CLC). - Le contrôleur de cloud (CLC): C’est le point d’entrée (Front end) des utilisateurs et administrateurs du système. Il collecte des informations sur les nœuds et planifie leur exécution au travers des contrôleurs de clusters (CCs). Il expose les services du cloud à travers une application Web mais également à travers des interfaces compatibles EC2. 7 Abicloud. Http ://community.abiquo.com/.
  • 57.
    CHAPITRE 3 :Etude comparative et choix de la solution 37 Figure 3.13 : Architecture d’Eucalyptus 2. Solutions OpenNebula : Il s’agit d’une plateforme purement open source permettant de déployer des cloud privés, publics et hybrides. Mais l’idée fondamentale de la solution d’OpenNebula est orientée vers une implémentation en privé afin de permettre aux utilisateurs de se connecter aux ressources internes via une interface Web (Sempolinski et Thain, 2010). La solution OpenNebula est rigidement centralisée autour d’un nœud appelé front-end, chargé de la supervision de toute l’architecture. Elle est basée sur un haut niveau de personnalisation en fournissant plusieurs modules configurables et adaptables aux besoins. Cette haute modularité est à la fois un avantage, en ce sens qu’elle permet de construire l’architecture à sa manière, mais aussi un inconvénient parce qu’elle conduit à des difficultés de configuration entrainant des erreurs de mise en œuvre et des échecs de déploiement des machines virtuelles dans le réseau (Sempolinski et Thain, 2010)8 . OpenNebula supporte les hyperviseurs XEN, KVM et optionnellement VMware. L’architecture interne d’OpenNebula est constituée de trois couches d’éléments appelées respectivement : tools, core et drivers (Figure 3.14). - Tools : c’est l’ensemble des outils de gestion de l’architecture. Il est constitué des interfaces de lignes de commandes CLI (Command Line Interface) pour l’interaction avec le système, d’un portail Web d’administration et d’utilisation du cloud, appelé sunstone localisé au niveau du nœud central de l’architecture. 8 Amazon web srrvice. http://aws.amazon.com/fr/.
  • 58.
    CHAPITRE 3 :Etude comparative et choix de la solution 38 - Core : ce niveau consiste en un ensemble de composants impliqués dans la gestion et le contrôle des nœuds, des utilisateurs et des machines virtuelles de l’architecture. Ces différents composants communiquent en utilisant le protocole XML RPC. - Driver : c’est à ce niveau que se déroulent les processus liés aux transferts de machines virtuelles d’un nœud à un autre. Ces différentes couches s’observent sur le nœud frontal de l’architecture. Ce dernier est ensuite relié aux nœuds d’exécution (hosts) par l’intermédiaire d’un réseau local (Figure 3.14). Les nœuds d’exécution (hosts) ne requièrent l’installation d’aucun service d’OpenNebula. Seul le front-end héberge tous les services de supervision et de gestion du cloud ; ce qui rend ce nœud l’unique point de défaillance du système. Figure 3.14 : Les déférents couches d’OpenNebula 3. Solutions Openstack : OpenStack est l'une des options d'exploitation cloud les plus populaires aujourd'hui. C’est un projet open source permettant de déployer une infrastructures IaaS (Infrastructure en tant que service). Il est d’ailleurs considéré par certains, comme l'un des plus grands projets open-source. Nombreuses entreprises (VMware, IBM, Amazon, OVH, …) ont rejoint la fondation, pour faire évoluer davantage le projet et d'autres l'utilisent même pour la gestion de leur cloud, qu'il soit public ou privé. La technologie possède une architecture modulaire composée de plusieurs projets corrélés (Nova, Swift, Glance ...) qui permettent de contrôler les différentes ressources des machines virtuelles tel que la puissance de calcul, le stockage ou encore le réseau. OpenStack supporte de nombreux hyperviseurs dont VMware vSphere, Hyper-V, Citrix Xen ou encore KVM (le plus souvent utilisé). Il propose également de nombreuses API standardisée EC2 (Elastic Compute Cloud), permettant d'exposer une couche Cloud "normalisée" indépendante de l'infrastructure de virtualisation sous-jacente (découplage). OpenStack intègre également la technologie des conteneurs, une alternative à la virtualisation classique, qui permet un gain considérable de ressources (CPU, Stockage, …) à l’instar des machines virtuelles qui
  • 59.
    CHAPITRE 3 :Etude comparative et choix de la solution 39 embarquent tout un système d’exploitation. Cette technologie apporte également un plus dans la sécurité grâce à l’isolation des conteneurs. L'image suivante décrit dans l'ensemble tout ce qu'on peut faire avec OpenStack: Figure 3.15 : Les déférents taches d’Openstack Comme nous l'avons dit plus haut, OpenStack est un ensemble de projets correlés, dont chaque projet a une tâche bien précise. Il y'en a vraiment beaucoup, et donc parmi ces projets nous pouvons en citer quelques-uns, qui constitue le socle même d'OpenStack: - Keystone: c'est le service d'dentité d'OpenStack, c'est lui qui gère toute l'authentification au système, il gère les accès, les droits, les domaines, les tenants. Il gère également l'accès aux différentes apis du système, les endpoint qui permettront de gérer l'accès aux autres services. - Glance: le service d’image d'OpenStack, il permet la découverte, l'envoi et la distribution d'image disque vers les instances de machines virtuelles. Vous pouvez stocker les images de machine virtuelle mises à disposition par le service d’image dans différents emplacements, du simple système de fichiers au système de stockage objet (Swift). Les images stockées font
  • 60.
    CHAPITRE 3 :Etude comparative et choix de la solution 40 office de modèle de disque. Le service glance permet aussi de stocker des sauvegardes de ces disques. Glance ne stocke pas seulement des images, mais aussi des informations sur celles- ci, les métadonnées. Ces métadonnées sont par exemple le format du disque (comme QCOW2 ou RAW) ou les conteneurs de celles-ci (OVF par exemple), qui peuvent être intérrogées à travers une API REST. - Nova: le service de calcul (virtualisation) d'OpenStack, permet d'héberger et gérer les services d'un système de cloud computing. Le service de calcul est la partie principale d'un système Iaas (Infrastructure as a service). Les principaux modules sont implémentés en Python. Nova interragit avec le service d'identité d'OpenStack (Keystone) pour l'authentification, le service d'image (Glance) pour fournir des images disques sur la base desquelles seront déployées les instances de serveur, et le tableau de bord qui offre aux utilisateurs, une interface pour gérer leurs machines virtuelles. - Neutron: le composant Réseau OpenStack (neutron) gère tous les aspects réseau pour l’infrastructure de réseau virtuel et les aspects de la couche d’accès à l’infrastructure de réseau physique dans votre environnement OpenStack. Le réseau OpenStack permet aux tenants de créer des topologies de réseau virtuel avancées qui peuvent inclure des services comme un firewall, un load balancer, et un réseau privé virtuel (VPN). Le composant Réseau fournit des réseaux, sous-réseaux et routeurs comme des abstractions objet. Chaque abstraction a des fonctionnalités qui imitent son homologue physique: les réseaux contiennent des sous-réseaux, et les routeurs dirige le trafic entre les différents sous-réseaux et réseaux. Chaque routeur a une unique passerelle qui se connecte à un réseau et de multiples interfaces connectées à des sous-réseaux. Les sous-réseaux peuvent accéder à des machines sur d’autres sous-réseaux connectés au même routeur. Ainsi un utilisateur peut créer son propre réseau de machines virtuelles. - Horizon: le tableau de bord OpenStack (horizon) est une interface web qui permet aux administrateurs et aux utilisateurs du cloud de gérer les différentes ressources et services OpenStack. Le tableau de bord permet des interactions de type web avec le contrôleur du cloud OpenStack à travers les différentes APIs. Pour chaque service ajouté à votre environnement OpenStack, Horizon l'intègrera automatiquement dans son interface. En plus du thème de base qu'il vous propose, il vous offre aussi la possibilité de le personnaliser à votre façon. - Cinder: le service de stockage par blocks (cinder) fournit aux machines virtuelles un stockage persistant. Il fournit une infrastructure pour gérer les volumes, et interragit avec le service de calcul d'OpenStack pour fournir des volumes aux instances de machines virtuelles. Il gère donc les opérations de création, d'attachement et de détachement de ces périphériques sur les serveurs. Le stockage en mode bloc est utilisé pour des scénarios performant comme celui du stockage de base de données, mais aussi pour fournir au serveur un accès bas niveau au périphérique de stockage. Cinder gère aussi la création d'instantanés (snapshots), très utile pour sauvegarder des données contenues dans les périphériques de type bloc. Les instantanées peuvent être restaurées ou utilisées pour créer de nouveaux volumes. - Swift: le service de Stockage Objet (swift) permet le stockage et la récupération d’objets à travers une API REST. C'est le type de stockage le plus souvent utilisé pour stocker tout type de fichiers. Ainsi grâce à votre cloud, vous pourrez y accéder de partout. Il n'est pas juste un simple stockage car il assure également la réplication des données sur plusieurs disques, qui peuvent même être sur des serveurs différents. Donc de base ce service intègre déjà plus ou moins de la haute disponibilité, même s’il vaut ieux s'en assurer personnellement; Tout dépend de votre activité et de votre utilisation du cloud. Il permet d'offrir également un espace de stockage pour le service d'image, qui est utilisé pour déployer des instances. Pour
  • 61.
    CHAPITRE 3 :Etude comparative et choix de la solution 41 que Swift fonctionne l'environnement doit inclure au minimum le service d’identité (keystone) avant de déployer le service de stockage d’objet9 . - Heat: le service d'orchestration d'OpenStack (heat) permet d'orchestrer des tâches dans le cloud computing. Il permet de plannifier et d'automatiser certaines tâches en gérant ls ressources du cloud tel que les instances virtuelles, les adresses IP flottantes, les volumes, les images, les groupes de sécurité, les utilisateurs. Il fournit également des fonctionnalités tels que la haute disponibilité des instances, l'auto-scaling (extensibilité) des instances, en décrivant via un template heat (HOT) qui est une sorte de langage, comment on souhaite gérer les ressources du cloud. - Ceilometer: le service de télémétrie d'OpenStack (ceilometer). Il permet de collecter différentes métriques sur l'utilisation du cloud. Par exemple il permet de récolter le nombre d'instances lancé dans un projet et depuis combien de temps. Ces métriques peuvent être utilisées pour fournir des informations nécessaires à un système de facturation par exemple. Ces métriques sont aussi utilisées dans les applications ou par d'autres composants d'Openstack pour définir des actions en fonction de certains seuils comme avec le composant d'orchestration. Les services décrits plus haut sont les services les plus souvent utilisés quand on déploie un cloud (en particulier avec OpenStack). Bien entendu OpenStack possède encore beaucoup d'autres modules que pouvez installer (troove, ironic, sahara, designate, barbican, zaqar, magnum, manila...). Tout cela dépend de ce que vous souhaitez faire. Et ceci est même un des gros avantages qu'OpenStack possède par rapport à d'autres solutions de cloud computing come VMWare vCloud, ou encore Microsoft System Center, qui non seulement sont des solutions propriétaires et payantes, mais en plus ne s'installent pas par modules, c'est-à-dire que vous n'avez pas réellement le choix sur ce que vous décidez d'installer ou pas. Par exemple si vous souhaitez uniquement faire du cloud de stockage, avec OpenStack vous aurez juste besoin d'installer le service de stockage Swift, sans avoir à déployer Nova, ou encore Neutron, et ceci rendra votre environnement plus léger, par contre les autres solutions intègre directement des fonctionnalités sans doute bien, mais dont vous n'avez pas forcément besoin, et qui peut même rendre le déploiement complexe. Voici un schéma illustrant, les relations entre les différents services d'OpenStack: 9 Eucalyptus. http://www.eucalyptus.com/. [15] Kvm. http://www.linux-kvm.org/.
  • 62.
    CHAPITRE 3 :Etude comparative et choix de la solution 42 Figure 16 : Les différents services d’openstack
  • 63.
  • 64.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 43 Introduction : Ces dernières années, l’impressionnant grossissement du volume d’information et de leur sauvegarde dirigée par une nouvelle classe de d’applications gourmandes en données, d’applications entreprise web-enabled, et de l’Internet a créé une augmentation sans précédent des besoins de stockage. L’approche traditionnelle du stockage par les entreprises impliquait un lien direct entre un serveur et le system de stockage local. Ces méthodes de stockage par lien direct engendrent des îlots de stockage compliqués à gérer et limitant la flexibilité. Voilà pourquoi une nouvelle approche du stockage est apparue, permettant la mutualisation des données, la simplification de la gestion et l’amélioration de la flexibilité. Cette nouvelle approche est le stockage réseau. Aujourd’hui, c’est un enjeu essentiel. Pour qu’une entreprise puisse se développer et fonctionner, un système d’information disponible et fiable est primordial. Auquel cas, il y a un risque de pertes de productivité (baisse du CA), de matériels, mais également de coûts supplémentaires (liées aux pannes, aux ressources à déployer, etc.). La haute disponibilité (ou High Availability ou HA) permet d’assurer et de garantir le bon fonctionnement des services ou applications proposées et ce 7j/7 et 24h/24. Cela consiste donc à mettre en place toutes les actions et dispositions techniques pour qu’une infrastructure informatique soit toujours disponible en appliquant certains principes tels que la réplication des données, la sauvegarde, la répartition de la charge, la redondance, etc. pour limiter l’indisponibilité d’un SI1 . 1 Microsoft. http ://www.microsoft.com/.
  • 65.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 44 1. Technologies de stockage (NAS SAN...) :  NAS : Figure 4.1 : L’architecture de réseau NAS Un serveur de stockage en réseau (NAS) est une architecture de stockage en mode fichier, constituée d'un ou de plusieurs serveurs dotés de disques dédiés où les données sont stockées et partagées avec de nombreux clients connectés à un réseau. Le NAS est l'une des trois principales architectures de stockage, avec les réseaux locaux de stockage (SAN) et le stockage en attachement direct (DAS). C'est la seule qui soit à la fois en réseau (par définition) et entièrement responsable de l'ensemble du stockage du réseau. Si l'on compare le NAS à des volumes de stockage qui vous sont plus familiers, comme le disque dur de votre ordinateur, un disque dur externe, un CD ou une clé USB, on constate qu'une architecture NAS vous permet de stocker et de partager des fichiers de la même manière. La différence est ailleurs. En effet, un disque dur, interne ou externe, un CD et une clé USB ne peuvent se connecter qu'à un seul périphérique à la fois, tandis que le NAS relie plusieurs périphériques en même temps. Les unités NAS sont conçues pour distribuer les données sous la forme de fichiers. Bien qu'ils soient techniquement capables d'effectuer des tâches de serveur général, les unités NAS
  • 66.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 45 ont souvent un rôle qui se limite à l'exécution d'un logiciel qui protège les données et gère les autorisations. C'est pour cette raison qu'elles n'ont pas besoin d'un système d'exploitation complet. La plupart des unités NAS incluent un système d'exploitation léger, configuré pour le stockage et la présentation des données. Pour présenter ces fichiers, l'unité NAS utilise des protocoles fichiers standard, tels que NFS (Network File System), SMB (Server Message Block), CIFS (Common Internet File System) ou AFP (Apple Filing Protocol), qui communiquent avec les périphériques Linux, UNIX, Microsoft Windows et Apple. Voici les principaux avantages d'un serveur NAS : • Évolutivité : pour augmenter la capacité de stockage d'un NAS, il suffit d'y ajouter des disques durs. Pas besoin de mettre à niveau ni de remplacer des serveurs, et encore moins de désactiver le réseau. • Performances : comme le NAS est un système de fichiers, les autres périphériques du réseau n'ont pas besoin de se charger du partage des fichiers. De plus, le NAS est souvent configuré pour une utilisation bien précise (stockage de Big Data ou de contenus multimédias, par exemple), ce qui permet d'obtenir des performances plus élevées. • Configuration simple : les architectures NAS sont souvent accompagnées de scripts simples ou encore fournies sous la forme d'appliances préinstallées avec un système d'exploitation rationalisé, ce qui réduit considérablement le temps de configuration et de gestion du système. • Accessibilité : tous les périphériques en réseau ont accès au NAS. • Tolérance aux pannes : il est possible de formater le NAS de sorte qu'il prenne en charge des disques répliqués, un système RAID ou le codage à effacement afin d'assurer l'intégrité des données. Fonctionnement : Pour faire simple, le NAS est une approche qui vise à simplifier l'accès aux données stockées entre les périphériques d'un réseau. En installant un logiciel spécialisé sur du matériel dédié, les entreprises peuvent tirer parti d'un accès partagé à point unique assorti de fonctions de sécurité, de gestion et de tolérance aux pannes. Le NAS communique avec les autres périphériques à l'aide de protocoles fichiers. C'est l'un des formats les plus faciles à utiliser, notamment par rapport aux systèmes de stockage en mode bloc ou objet. Matériel : Le matériel qui compose un NAS est généralement appelé boîtier NAS, unité NAS ou serveur NAS. Le serveur en lui-même est essentiellement composé de disques de stockage, de processeurs et de mémoire RAM, comme la plupart des autres serveurs. Il est possible d'ajouter plus de mémoire RAM à une unité NAS ou de personnaliser le type et la capacité des disques selon les besoins spécifiques. La différence principale entre un NAS et un serveur de stockage généraliste se situe plutôt au niveau du logiciel. Logiciels : Une unité NAS comprend un logiciel déployé sur un système d'exploitation allégé, généralement intégré au matériel. Quant au serveur généraliste, il est doté d'un système d'exploitation complet et il envoie et reçoit des centaines ou des milliers de petites requêtes
  • 67.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 46 uniques par seconde. Le système d'exploitation d'un NAS, lui, ne gère que deux tâches : le stockage des données et le partage des fichiers. Protocoles : Figure 4.2 : Protocole de stockage NAS Une unité NAS est formatée avec des protocoles de transfert de données, fréquemment utilisés pour l'envoi de données entre plusieurs périphériques. Les clients peuvent accéder à ces protocoles via un commutateur réseau, c'est-à-dire un serveur central qui connecte tous les éléments du réseau et achemine les requêtes. En pratique, les protocoles de transfert de données vous permettent d'accéder aux fichiers stockés sur un autre ordinateur, comme s'il s'agissait des vôtres. Sur un réseau, plusieurs protocoles peuvent être utilisés, mais les deux plus importants sont les suivants : le protocole IP (Internet Protocol) et le protocole TCP (Transmission Control Protocol). Le protocole TCP permet de regrouper les données en paquets avant de les envoyer via le protocole IP. Pour simplifier les choses, les paquets TCP sont comparables à des fichiers ZIP et le protocole IP à des adresses e-mail. Si vos grands-parents ne sont pas inscrits sur les réseaux sociaux et qu'ils n'ont pas accès à votre cloud personnel, vous devez leur envoyer vos photos de vacances par e-mail. Vous pouvez également rassembler ces photos dans des fichiers ZIP pour éviter de les envoyer une par une. De la même manière, le protocole TCP rassemble les fichiers dans des paquets avant de les envoyer sur un réseau via des adresses IP2 . Les fichiers transférés via ces protocoles peuvent être aux formats suivants : • NFS (Network File System) : ce protocole est fréquemment utilisé sur les systèmes Linux et UNIX. Ce protocole indépendant fonctionne sur tout type de matériel, de systèmes d'exploitation et d'architectures de réseau. • SMB (Server Message Block) : la plupart des systèmes qui utilisent le protocole SMB exécutent Microsoft Windows. Il est alors appelé « Réseau Microsoft Windows ». Ce 2 Microsoft. Windows azure http : // www.microsoft.com/windowsazure/.
  • 68.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 47 protocole a été développé à partir du protocole CIFS (Common Internet File System) et c'est pour cette raison qu'il apparaît parfois sous l'appellation CIFS/SMB. • AFP (Apple Filing Protocol) : il s'agit d'un protocole propriétaire, réservé aux périphériques Apple qui exécutent MacOS.  SAN : Dans la gestion des infrastructures informatiques, la consolidation des données est une priorité. La qualité d’une solution de stockage consolidée est jugée sur la facilité de sa gestion et de sa maintenance. Selon les impératifs du responsable IT, en termes de disponibilité, de fiabilité, de performance et de sécurité, la plateforme évoluera vers une complexité plus élevée, à savoir des configurations redondantes, miroirs et même distantes. Cela dépend de la vocation de la solution. Figure 4.3 : L’architecture de réseau SAN 1) Fonctionnement : Le SAN fonctionne en SCSI est fondé sur un sous réseau à haut débit reliant les serveurs applicatifs et les équipements de stockage (baies Raid, robots de sauvegarde). Ses fonctions comprennent le stockage proprement dit, la sauvegarde, la réplication, la sécurisation, le partage et l'administration des données. Son unité de base est le bloc de données, et non pas le fichier. 2) Quel type de réseau utilise un réseau SAN? Le SAN est d'un point de vue topologique comparable au LAN et au WAN auxquels il est couplé. Il se compose de contrôleurs (cartes d'interfaces), de câbles cuivre ou optique, de commutateurs, de concentrateurs, de routeurs et de passerelles. Au milieu des années quatre- vingt-dix, le SAN reposait exclusivement sur des liens Fibre Channel, une technologie de transport série à haut débit et longue distance. Aujourd'hui, il exploite souvent en combinaison les technologies de transport Fibre Channel, Gigabit Ethernet et ATM, et les protocoles FCP, IP et iSCSI. Au sein du SAN, les échanges se font en mode point à point, sur des canaux offrant la totalité de la bande passante nominale. Deux topologies sont en concurrence. La première, la
  • 69.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 48 boucle arbitrée (FC-AL) consiste à placer les équipements sur une boucle avec des concentrateurs, un seul canal est ouvert à un moment donné entre deux noeuds, les autres noeuds étant inactifs. La seconde, la matrice FC (FC Fabric) exploite des commutateurs pour assurer de l’échange point à point simultanés, plus puissante et plus souple, elle tend à remplacer la boucle arbitrée. Les commutateurs fonctionnent généralement à 2 Gbit/s. Quelle que soit la couche physique, il faut se souvenir qu'un réseau SAN est un réseau à proprement parler; il présente les mêmes problèmes de sécurité et de gestion qu'un réseau local critique. De fait, structurer le réseau SAN interne en le répartissant en zones distinctes avec différents droits d'accès et configurations physiques permet d'accroître la sécurité et la fiabilité. 3) Quels types de commutateurs sont appropriés SAN? Il existe deux catégories principales de commutateur: directeur et matrice. Les commutateurs directeurs sont les cuirassés: ils sont dotés d'un grand nombre de ports, de composants du noyau redondants et remplaçables à chaud, et d'autres fonctionnalités architecturales qui améliorent la fiabilité. Résultat, un bon fonctionnement 99,999% du temps. Leur prix est en conséquence. Les commutateurs de matrice affichent pour leur part des spécifications inférieures. 4) Peut-on bâtir un réseau SAN sur réseau existant? En théorie, oui. Dans la pratique, si un réseau SAN offre tant d'avantages, c'est parce qu'il dispose d'une bande passante dédiée. S'il doit assurer un trafic qui n'est pas lié au stockage, la fiabilité et les temps de réponse en pâtiront. Il est donc préférable de considérer le réseau SAN comme une entité indépendante. Le réseau local existant en bénéficiera également, car les tâches de traitement de gros volumes de données, telles que les sauvegardes et réplications, peuvent s'effectuer en dehors de l'environnement local général. 5) Qu'est-ce qu'un serveur SAN? Dans un réseau SAN ordinaire, le réseau de stockage est principalement un moyen de communication, l'allocation des données aux dispositifs de stockage s'effectuant sur un serveur. Un serveur SAN réside au sein du réseau de stockage et joue l'intermédiaire pour chaque opération, centralisant le contrôle de la répartition des données. Il peut également gérer la redondance pour les contrôleurs de disque. Bien que ce fonctionnement soulage les serveurs d'une partie des impératifs de traitement et contribue à simplifier la gestion, le serveur SAN peut se transformer en goulet d'étranglement, et peut poser lui-même des problèmes de fiabilité.
  • 70.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 49 6) Topologie : Figure 4.4 : Topologie de réseau SAN 7) Applications : Pour simplifier, on peut dire que le SAN répond aux exigences des grandes entreprises en termes de disponibilité de bande passante comme de criticité des applications. Il est destiné aux applications nécessitant le transfert de volumes élevés de données. Il se destine à travailler dans un environnement de type back-end -applications pour la lecture et l’écriture d'informations en interne. 8) Défauts et qualités : A. Défauts : Ils sont : • Le principal défaut du SAN est son coût. En effet, il nécessite un réseau spécifique à très haut débit très coûteux généralement à base de Fiber Channel mais aussi ATM ou Gi Gigabit Ethernet. • Il ne peut pas se baser sur un réseau déjà existant car il provoquera vrai semblablement de très importants engorgements perdants de ce fait tous ses avantages. B. Qualités : Elles sont la performance d’accès aux données, la disponibilité, la fiabilité, la stabilité, la sécurité des données et enfin, l’économie des personnes destinées à la gestion journalière. Les forces d’un SAN se situent à trois niveaux :
  • 71.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 50 •Le SAN est un réseau spécialisé. Il est affecté à la connexion des unités de stockage, tels que disques, librairies de backup, robots de backup... aux serveurs. Objectif : accès des utilisateurs aux données sans charger le réseau de l’entreprise (LAN).En spécialisant les réseaux, les machines sont reliées entre elles par un réseau réservé à cette fin. Dès lors, à son poste de travail, l’utilisateur dispose d’un réseau libéré donc plus performant. Effet immédiat : le temps de réponse s’améliore nettement. •Une architecture traditionnelle de server-attached storage demande le shutdown du serveur pour tout ajout de capacité de stockage. Le SAN, quant à lui, permet d’ajouter des unités de stockage sans interruption de service. Dès lors son utilisation est justifiée dans le cadre d’applications qui connaissent une forte dynamique de croissance. •Le SAN autorise la centralisation des backups. Avantage direct : la garantie de l’intégrité et de la sécurité des données.  DAS : Le DAS est l’architecture standard de stockage avec connexion directe aux serveurs. C’est encore l’architecture la plus courante aujourd’hui. L’hôte et ses éléments de stockage sont connectés un à un par des liens SCSI. Figure 4.5 : L’architecture de réseau DAS Fonctionnement : Le stockage (DAS) est un dispositif interne ou externe qui se branche directement à un seul serveur. Ce dispositif contient des disques indépendants de type RAID tolérant la panne de disques sans perte de données et qui fonctionne de façon indépendante des systèmes d’exploitation.
  • 72.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 51 Dans cette topologie de stockage, à un serveur correspond un équipement de stockage. Aucune fonctionnalité de réseau n’est alors déployée. Par conséquent, pour accéder à ce dispositif, les usagers doivent accéder au serveur auquel il est branché. Topologie : Figure 4.6 : Topologie de réseau DAS • Défauts et qualités : Comme de plus en plus d’espaces de stockages et de serveurs sont ajoutés pour répondre aux demandes des entreprises, l’environnement DAS peut causer une prolifération de serveurs et d’îlots de stockage. Cela engendre donc une immense charge de gestion pour les administrateurs et une utilisation inefficace des ressources. Le partage des données dans ce type d’environnement est aussi très limité. Cependant, il est très simple de mettre en place un DAS puisqu'il n’y a qu'un serveur branché au dispositif de stockage.
  • 73.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 52 2. Systèmes de stockage (CEPH NFS...) :  CEPH : Ceph est un système de stockage distribué open-source répondant aux besoins de stockage modernes. Il est flexible jusqu'au niveau exaoctet et son architecture ne contient pas d'un point unique de défaillance, c'est à dire que le système n'est pas dépendant d'un disque, dont la panne entraînerait l'arrêt complet du système. Cela le rend idéal pour les applications nécessitant un stockage flexible hautement disponible. À partir de Proxmox VE version 4.1, le serveur Ceph a été intégré à Proxmox pour coexister sur le même nœud. La capacité à gérer les grappes Cephpar l’interface graphique Proxmox a également été ajoutée. A. Architecture de CEPH : L'architecture de Ceph se base sur RADOS, un système de stockage d'objets répartis géré par plusieurs serveurs indépendants appelés nœuds de stockage3 . Figure 4.7 : Architecture Cèph La couche supérieure correspond à une API et une librairie librados permettant à une application d’interagir directement avec le stockage d'objets. Cette librairie est utilisée par Ceph pour fournir à l'utilisateur trois modes d'accès aux objets : • Une interface directe au stockage d'objet RadosGW, compatible avec les composants de stockage du cloud : S3 d'AWS et Swift d'Openstack. • Une interface de type bloc, RBD, utilisable par un client Linux, une machine virtuelle dans notre cas. • Une interface de type système de fichiers distribué, CephFS, utilisable par un client Linux. Ce système n'est cependant pas encore mature. L'environnement Proxmox intégrant l'accès au stockage en mode blocs, l'accès à Ceph se fera à travers le module RBD. Celui-ci autorise les utilisateurs à monter Ceph comme un périphérique bloc. 3 DELHOMME(Olivier): Mise en oeuvre de CEPH, GNU/Linux Magazine France.N°180 (Mars 2015), p.30-39.
  • 74.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 53 Lorsqu'une application écrit des données sur le périphérique bloc, Ceph réplique les données automatiquement à travers le cluster. B. Les services CEPH : La partie serveur de Ceph est assurée par trois types de services à déployer : OSD : qui a pour rôle de stocker efficacement les objets. Il utilise pour cela le disque local du serveur, via un système de fichiers local classique (XFS, EXT). MON : qui surveille et contrôle l’état du cluster, maintient une cartographie de l’état de celui- ci. Ne stocke aucune donnée. MDS : qui a pour rôle de gérer les métadonnées pour CephFS. Il n'est pas utilisé car nous utilisons uniquement le module RBD. Le déploiement de plusieurs démons dans un ensemble de machines constitue un cluster Ceph. Le caractère redondant de ces services permet de se défaire d'un SPOFet ainsi d'assurer une haute disponibilité du stockage. C. Gestion de stockage CEPH : L’architecture de Ceph est modulaire. Elle repose sur plusieurs concepts propres au système de stockage open-source : C.1. Les pools : Les pools permettent le partitionnement logique de l'espace de stockage du cluster. Il est possible d'indiquer quelques paramètres qui seront spécifiques à chaque pool : − Le nombre de réplicats pour les objets et le nombre minimal de réplicats acceptables pour continuer de fonctionner en mode dégradé. − Les propriétaires et les droits d'accès. − Le nombre de groupes de placement : il s'agit de fragments de pools permettant de segmenter la distribution des objets entre OSD. L'objectif étant de créer un niveau d'indirection supplémentaire afin de faciliter la reconstruction des données en cas de panne d'un composant. − La règle CRUSH à utiliser : L'algorithme CRUSH est chargé du calcul de l'emplacement d'un objet. Il permet de définir comment les serveurs OSD peuvent tomber en panne et donc induire le placement des données pour permettre cela. − Les moniteurs (Mons): Chaque cluster Ceph nécessite la mise en œuvre de moniteurs installés sur des serveurs indépendants. Ces moniteurs sont utilisés par les clients Ceph pour obtenir la carte la plus à jour du cluster.
  • 75.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 54 Figure 4.8 : Organisation des données dans Ceph C.2. Réplication de données : La réplication des données dans le système Ceph se fait directement sur les pools selon deux techniques : a. Clonage : Le système stocke autant de copies que spécifié de chaque donnée. L'OSD primaire copie l'objet vers le(s) OSD secondaire(s). Dans ce cas, le coût du stockage augmente avec le nombre de copies spécifié. Ainsi, plus le nombre de copies est important, plus on peut se permettre de pannes. b. Utilisation de code à effacement (erasurecoding) : Chaque objet écrit sur le cluster est découpé en n segments (avec n = k + m, k correspondant au nombre de segments de données et m le nombre de segments contenant les données de parité). Dans ce cas, lors de la réplication d'un pool, l'OSD primaire découpe l'objet en segments, génère les segments contenant les calculs de parité et distribue l'ensemble de ces segments vers les OSD secondaires en écrivant également un segment en local. Il est important de noter que le mode bloc RBD utilisé n'est supporté que sur les pools répliqués.
  • 76.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 55 Figure 4.9 : Illustration des deux modes de réplication des données. D. Implantation de stockage distribué à travers Proxmox VE : Un des principaux avantages de Proxmox VE est l'intégration de plusieurs types de stockages partagés (NFS, RBD/Ceph...) Une fois le cluster a été créé et les trois nœuds redémarrés nous pouvons passer à l'installation de l'architecture de stockage distribué à haute utilisés conjointement. D.1. Implémentation du système de stockage tolérance aux pannes développées pour la virtualisation: le Ceph a. Configuration du réseau dédié à Ceph : Séparer les réseaux d’administration de Proxmox et du réseau de stockage Ceph parce que le trafic des données de stockage Ceph nécessite un réseau privé performant. Pour cela nous devons ajouter une autre carte réseau Bond0 avec deux interfaces, que nous configurons en agrégation, nous lui affectons la plage d'adresses 192.168.1.0/24 " même plage avec stockage NFS". A partir de l'interface web de Proxmox VE nous configurons sur chaque nœud le nouveau réseau simplement en ajoutant un commutateur linux bond interfaçant (ens19 et ens20) avec l'adresse correspondant au nœud dans le réseau privé. Cette configuration peut se faire en ligne de commande en modifiant le fichier :/etc/network/interfaces sur chaque nœud puis redémarrer.
  • 77.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 56 Figure 4.10 : Création d'une carte réseau en mode agrégation D.2. Installation des paquets CEPH : L'installation des paquets ceph sur les 3 nœuds se fait grâce à la commande : #pvecephinstall --version luminous Yes D.3. Création de la configuration initiale Ceph Exécutez la commande suivante sur un seul nœud pour initialiser le réseau Ceph. root@pve-3# pvecephinit --network 192.168.1.0/24 Ce qui crée le fichier de configuration /etc/pve/ceph.conf D.4. Mise en place des services Ceph : Le déploiement du cluster Ceph requiert un certain nombre de serveurs mon et osd pour se trouver dans un état stable. Il est recommandé d'installer un nombre impair de moniteurs afin de pouvoir identifier la panne au sein du cluster Ceph. Dans le cas présent, nous avons décidé d'utiliser un service de chaque type par nœud : nous disposons donc au total de 3 mon et 3 osd. a. Création des moniteurs Ceph : L'activation d'au moins un moniteur,sur un nœud est nécessaire en utilisant la commande: root@pev1:~# pvecephcreatemon Puis, via l’interface web Proxmoxnous avons créé des monitors sur les 2 nœuds restants pour
  • 78.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 57 la redondance: pve-2CephMonitorCreate et pve-3CephMonitorCreate b. Création des OSD Ceph : La configuration se fait sur chaque nœud de cluster via l'interface de ligne de commande ou via l'interface graphique comme suit: Choisir un nœud puis sélectionner Ceph/DISKS/OSD/creatosd/select disque comme osd et journal bleustore ''préférable un disque ssd pour journal les autre sans journal '' Figure 4.11 : OSD installé D.5. Création de pool Ceph : Un pool est un groupe logique pour stocker des objets. Pour créer le pool ceph : Dans l'onglet principale Ceph, cliquez sur l’onglet « Pool" puis sur create.
  • 79.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 58 Figure 4.12 : L'état de cluster Ceph  NFS : Un système de fichiers réseau (ou NFS de l’anglais Network File System), permet aux hôtes distants de monter des systèmes de fichiers sur un réseau et de les utiliser exactement comme des systèmes de fichiers locaux. Ceci permet aux administrateurs système de stocker des ressources sur des serveurs centralisés sur le réseau. A. Comment ça marche : NFS consiste en deux éléments principaux: un serveur et un ou plusieurs clients. Le client accède à distance aux données stockées sur la machine serveur. Afin que tout cela fonctionne correctement quelques processus doivent être configurés et en fonctionnement. Exemples pratiques d’utilisation : Il existe de nombreuses applications pratiques de NFS. Les plus communes sont présentées ci- dessous: • Configurer plusieurs machines pour partager un CDROM ou un autre médium. C'est moins cher et souvent une méthode plus pratique pour installer des logiciels sur de multiples machines. • Sur les réseaux importants, il peut être plus pratique de configurer un serveur NFS central sur lequel tous les répertoires utilisateurs sont stockés. Ces répertoires utilisateurs peuvent alors être exportés vers le réseau, les utilisateurs devraient alors toujours avoir le même répertoire utilisateur indépendamment de la station de travail sur laquelle ils ouvrent une session. • Plusieurs machines pourront avoir un répertoire /usr/ports/distfiles commun. De cette manière, quand vous avez besoin d'installer un logiciel porté sur plusieurs machines, vous pouvez accéder rapidement aux sources sans les télécharger sur chaque machine.
  • 80.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 59 B. Les avantages de NFS : • Les stations de travail utilisent moins d'espace disque en local parce que les données utilisées en commun peuvent être stockées sur une seule machine tout en restant accessibles aux autres machines sur le réseau. • Les utilisateurs n'ont pas besoin d'avoir un répertoire personnel sur chaque machine du réseau. Les répertoires personnels pourront se trouver sur le serveur NFS et seront disponibles par l'intermédiaire du réseau. • Les périphériques de stockage comme les lecteurs de disquettes, de CDROM, de disquettes Zip® peuvent être utilisés par d'autres machines sur le réseau. Cela pourra réduire le nombre de lecteurs de medias amovibles sur le réseau. 3. Concepts et techniques de la haute disponibilité : Un service 100% disponible n’existe pas, car il y a plusieurs variables à prendre en compte tels que des aspects techniques ou remplacement de matériels. On considère un système hautement disponible lorsque son taux de disponibilité est de 99,96%. On parle également de SLA (Service Level Agrement), un indice permettant d’évaluer le degré de garantie et d’engagement du prestataire4 La conception des systèmes à haute disponibilité repose sur :  La modularité.  Fail fast.  Indépendance des modes de défaillance.  Redondance et réparation.  Elimination des points de défaillance unique 3.1. Mesure du taux de disponibilité : La disponibilité se mesure souvent en pourcentage : Disponibilité en % Indisponibilité par année Indisponibilité par mois3 Indisponibilité par semaine 90 % (« un neuf ») 36,5 jours 72 heures 16,8 heures 95 % 18,25 jours 36 heures 8,4 heures 98 % 7,30 jours 14,4 heures 3,36 heures 4 Microsoft hyper. http : //www.microsoft.com/hyper-v-server/en/us/default.aspx.
  • 81.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 60 99 % (« deux neuf ») 3,65 jours 7,20 heures 1,68 heures 99,5 % 1,83 jours 3,60 heures 50,4 minutes 99,8 % 17,52 heures 86,23 minutes 20,16 minutes 99,9 % (« trois neuf ») 8,76 heures 43,2 minutes 10,1 minutes 99,95 % 4,38 heures 21,56 minutes 5,04 minutes 99,99 % (« quatre neuf ») 52,56 minutes 4,32 minutes 1,01 minutes 99,999 % (« cinq neuf ») 5,26 minutes 25,9 secondes 6,05 secondes 99,9999 % (« six neuf ») 31,5 secondes 2,59 secondes 0,605 secondes L'amalgame est souvent fait, à tort, entre la haute disponibilité et le plan de reprise d'activité. Il s'agit de deux tâches différentes, complémentaires pour atteindre la disponibilité continue. 3.2. Techniques améliorant Ha disponibilité : De nombreuses techniques sont utilisées pour améliorer la disponibilité : • la redondance des matériels et la mise en cluster ; • la sécurisation des données : RAID, snapshots, Oracle Data Guard (en), BCV (Business Copy Volume), SRDF (Symmetrix Remote Data Facility), DRBD ; • la possibilité de reconfigurer le serveur « à chaud » (c’est-à-dire lorsque celui-ci fonctionne) ; • mode dégradé ou un mode panique ; • plan de secours ; • et sécurisation des sauvegardes : externalisation, centralisation sur site tiers.
  • 82.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 61 La haute disponibilité exige le plus souvent un local adapté: alimentation stabilisée, climatisation sur plancher, avec filtre à particules, service de maintenance, service de gardiennage et de sécurité contre la malveillance et le vol. Attention aussi au risque d'incendie et de dégât des eaux. Les câbles d'alimentation et de communication doivent être multiples et enterrés. Ils ne doivent pas être saillants dans le parking souterrain de l'immeuble, ce qui est trop souvent vu dans les immeubles parisiens. Ces critères sont les premiers à entrer en compte lors du choix d'un prestataire d'hébergement (cas de la location d'un local à haute disponibilité). Pour chaque niveau de l’architecture, pour chaque composant, chaque liaison entre composants, il faut établir : • Comment détecter une panne ? Exemples : Tests de vie TCP Health Check implémenté par un boîtier Alteon, programme de test invoqué périodiquement (« heartbeat »), interface de type « diagnostic » sur les composants… • Comment le composant est-il sécurisé, redondé, secouru… Exemples : serveur de secours, cluster système, clustering WebSphere, stockage RAID, sauvegardes, double attachement SAN, mode dégradé, matériel non utilisé libre (spare) prêt à être réinstallé.. • Comment désire-t-on enclencher la bascule en mode secours / dégradé. Manuellement après analyse ? Automatiquement ? • Comment s’assurer que le système de secours reparte sur un état stable et connu. Exemples : on repart d’une copie de la base et on réapplique les archives logs, relance des batchs depuis un état connu, commit à 2 phases pour les transactions mettant à jour plusieurs gisements de données… • Comment l’application redémarre sur le mécanisme de secours. Exemples : redémarrage de l’application, redémarrage des batchs interrompus, activation d’un mode dégradé, reprise de l’adresse IP du serveur défaillant par le serveur de secours… • Comment reprendre éventuellement les transactions ou sessions en cours. Exemples : persistance de session sur le serveur applicatif, mécanisme pour assurer une réponse à un client pour une transaction qui s’est bien effectuée avant défaillance mais pour laquelle le client n’a pas eu de réponse… • Comment revenir à la situation nominale. Exemples : o si un mode dégradé permet en cas de défaillance d’une base de données de stocker des transactions en attente dans un fichier, comment les transactions sont-elles réappliquées quand la base de données redevient active. o si un composant défaillant a été désactivé, comment s’effectue sa réintroduction en service actif (nécessité par exemple de resynchroniser des données, de retester le composant…) 3.3. Dépendance vis-à-vis des autres applications : Pour une application qui sollicite d’autres applications avec des middlewares en mode synchrone (service webs en http, Tuxedo, Corba, EJB) le taux de disponibilité de l’application sera fortement lié à la disponibilité des applications dont elle dépend. La sensibilité des applications dont on dépend doit donc être équivalente ou supérieure à la sensibilité de l’application elle-même. Sinon, il faut envisager
  • 83.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 62 • l’utilisation d’un middleware asynchrone : MQ Series, JMS, SonicMQ, CFT • la mise en œuvre d’un mode dégradé quand une application dont on dépend est défaillante. Pour cette raison on privilégiera l’utilisation de middlewares asynchrones pour privilégier une bonne disponibilité quand c’est possible. 3.4. Répartition de charge et sensibilité : La sensibilité est souvent gérée en redondant les éléments avec un mécanisme de répartition de charge. (Un cluster Websphere avec un load-balancing Alteon par exemple). Pour que ce système apporte un réel gain en termes de fiabilité, il faut vérifier que si un des éléments est défaillant, les éléments restants disposent d’une puissance suffisante pour assurer le service. Autrement dit, dans le cas de deux serveurs actifs avec répartition de charge, la puissance d’un seul serveur doit permettre d’assurer la totalité de la charge. Avec trois serveurs, la puissance d’un seul serveur doit permettre d’assurer 50 % de la charge (en supposant que la probabilité d’avoir un incident sur deux serveurs en même temps est négligeable). Pour assurer une bonne disponibilité, il est inutile de mettre un grand nombre de serveurs se secourant mutuellement. Par exemple, un élément disponible à 99 % redondé une fois donne une disponibilité de 99,99 % (probabilité que les deux éléments soit défaillants au même moment = 1/100x1/100 = 1/10000)5 . 3.5. Redondance différentielle : La redondance d’un élément est généralement effectuée en choisissant de redonder avec plusieurs composants identiques. Ceci suppose, pour être efficace, qu’une défaillance d’un des composants est aléatoire et indépendante d’une défaillance d’un des autres composants. C’est par exemple le cas des pannes matérielles. Ce n’est pas le cas de toutes les défaillances : par exemple, une faille du système d’exploitation ou une anomalie d’un composant logiciel peuvent survenir, quand les conditions sont favorables, sur l’ensemble des composants à la fois. Pour cette raison, quand l’application est extrêmement sensible, on considèrera de redonder les éléments avec des composants de natures différentes mais assurant les mêmes fonctions. Ceci peut conduire à : • Choisir des serveurs de nature différentes, avec des OS différents, des produits logiciels d’infrastructure différents ; • développer le même composant deux fois en respectant à chaque fois les contrats d’interface qui s’appliquent au composant 3.6. Redondance avec système de vote Dans ce mode, différents composants traitent les mêmes entrées et produisent donc (en principe) les mêmes sorties. Les résultats produits par tous les composants sont collectés, puis un algorithme est mis en œuvre pour produire le résultat final. L’algorithme peut être simple (vote à la majorité) ou complexe (moyenne, moyenne pondérée, médiane…), l’objectif étant d’éliminer les résultats 5 Nimbus. http://www.nimbusproject.org/.
  • 84.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 63 erronés imputables à un dysfonctionnement sur l’un des composants et/ou de fiabiliser un résultat en combinant plusieurs résultats légèrement différents. Ce procédé : • ne permet pas de répartition de charge ; • Introduit le problème de fiabilisation du composant gérant l’algorithme de vote. Ce procédé est utilisé généralement dans les cas suivants • Des systèmes reposant sur des capteurs (exemple : capteurs de température) pour lesquels les capteurs sont redondés • Des systèmes ou plusieurs composants différents assurant la même fonction sont utilisés (cf. redondance différentielle) et pour lesquels un meilleur résultat final peut être obtenu en combinant les résultats produits par les composants (exemple : système de reconnaissance de formes utilisant plusieurs algorithmes pour obtenir un meilleur taux de reconnaissance. 3.7. Shadow opérations : Lors du dysfonctionnement d’un composant redondé et après l’avoir réparé, on peut souhaiter le réintroduire en service actif, vérifier son bon fonctionnement effectif, mais sans que les résultats soient utilisés. Dans ce cas, les entrées sont traitées par un (ou plusieurs) composants réputés fiables. Ceux-ci produisent le résultat exploité par le reste du système. Les mêmes entrées sont également traitées par le composant réintroduit qui est dit en mode « shadow ». On peut vérifier le bon fonctionnement du composant en comparant les résultats produits avec ceux des composants fiables. Ce procédé est souvent utilisé dans les systèmes à base de vote car il suffit d’exclure le composant en mode « shadow » du vote final. 4. Les processus qui permettent d'améliorer la haute disponibilité : On peut distinguer deux rôles dans ces processus : 4.1. Les processus qui réduisent le nombre de pannes : En se basant sur le fait que mieux vaut prévenir que guérir, mettre en place des processus de contrôle qui permettront de réduire le nombre d'incidents sur le système permet d'améliorer la disponibilité. Deux processus permettent de jouer ce rôle : • Le processus de gestion des changements : 60 % des erreurs sont liées à un changement récent. En mettant en place un processus formalisé, accompagné de tests suffisants (et réalisés dans un environnement de pré-production correct), de nombreux incidents peuvent être éliminés. • Un processus de gestion pro-active des erreurs : les incidents peuvent bien souvent être détectés avant de survenir : les temps de réponse augmentent… Un processus affecté à cette tâche, et muni des outils adéquats (système de mesure, de reporting…) pourra intervenir avant même que l'incident n'arrive. En mettant en place ces deux processus, de nombreux incidents peuvent être évités. 4.2. Les processus réduisant la durée des pannes : Les pannes finissent toujours par arriver. À ce moment-là, le processus de reprise en cas d'erreur est primordial pour que le service soit restauré au plus vite. Ce processus doit avoir un
  • 85.
    CHAPITRE 4 :Technologies de stockage et Haute Disponibilité 64 objectif : permettre à l'utilisateur d'utiliser un service le plus rapidement possible. La réparation définitive doit donc être évitée car elle prend beaucoup plus de temps. Ce processus devra donc mettre en place une solution de contournement du probleme. 5. Cluster haute disponibilités : Un cluster haute disponibilité (par opposition à un cluster de calcul) est une grappe d'ordinateurs dont le but est d'assurer un service en évitant au maximum les indisponibilités. Voici une liste non exhaustive d'applications de clustering pour UNIX (fonctionnant sous AIX, HP-UX, Linux ou Solaris) : • Evidian SafeKit [archive] (load balancing, réplication temps réel et failover) • HP MC/ServiceGuard pour HP-UX • IBM HACMP • Bull Application Roll-over Facility • Symantec Veritas Cluster Server • Open Source Linux Pacemaker (logiciel) • OpenSVC [archive] (Logiciels Libres Gratuits) • Oracle Solaris Cluster [archive] (ex SUN Cluster)
  • 86.
  • 87.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 65 I. Introduction : Une bonne méthodologie de réalisation d'une application suppose une bonne maitrise de l'analyse et de la conception, cette dernière nous offre tous les modèles destinés à assurer le fonctionnement du logiciel. Ces modèles permettent d'expliciter les fonctionnalités. De manière globale, elle offre une vue panoramique sur l'ensemble des éléments et les interactions pris en compte dans la conception, à savoir le modèle logique, le modèle physique. II. Scénario 1 : Serveur web virtualisé au sein d'Openstack : Ce scénario a pour but de mettre en place une infrastructure virtualisée fonctionnelle, afin de mieux comprendre les interactions entre chaque service intervenant au sein d’Openstack. Au final, nous aurons un serveur web hébergé sur une VM que nous pourrons interroger depuis une adresse IP public. Dans un souci de bonnes pratiques, et dans le but de garantir la sécurité, le port 80 de la VM sera le seul port ouvert. Ce scénario va se matérialiser sous forme de deux variantes afin de mettre en évidence les différents types de stockage que nous offre OpenStack. La première sera la mise en place d’un stockage partagé basé sur le protocole NFS grâce au NAS QNAP. La deuxième sera l’intégration d’un système de stockage par bloc grâce au protocole iSCSI. La gestion d’une infrastructure virtualisée fait intervenir de nombreux éléments tels que la gestion des VMs avec Libvirt, et la gestion du réseau. OpenStack est donc constitué de nombreux services, permettant de piloter ces différents éléments de manière totalement dynamique. Comme les différents services sont répartis sur plusieurs PC physiques, ils doivent communiquer entre eux grâce au LAN Bleu. Pour cela, ils vont utiliser le protocole Advanced Message Queuing Protocol (Message AMQP) (voir §1.3)1 . 1. Scénario 1a : Système de stockage NFS : Le schéma représente les différentes entités physiques exécutant les différents services utiles au bon fonctionnement de l’infrastructure Openstack. 1 Openstack. http://www.openstack.org/.
  • 88.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 66 Schéma 5.1: schéma Scénario 1a 1.1 Les entités physiques : Tous les serveurs physiques, utilisent Fedora 19. J’ai choisi cette distribution, du fait de ces nombreux points communs avec la distribution professionnelle Red Hat Entreprise Linux (RHEL) proposée par Red Hat. La future version de RHEL (RHEL 7), sera basée sur Fedora 19. Fedora est la version Open Source de RHEL, c’est à dire que la version professionnelle propose en plus uniquement le support, mais les fonctionnalités sont identiques. Toutes les entités physiques sont basées sur le même hardware : • Carte mère : Asus P8Q77-M • CPU : Intel Core i5-3330 • RAM : 8GB ! • Disque Dur : 320GB • Cartes réseaux 1Gb/s Intel
  • 89.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 67 Voici le rôle de chaque serveur physique : ▪ L’administrateur du Cloud : Personne physique, qui depuis un navigateur web, va dialoguer avec le Cloud Controller pour démarrer une VM, gérer les contrôles d’accès ou administrer notre infrastructure. ▪ Cloud Controller : La pièce maitresse de notre infrastructure, il va piloter les différentes parties de notre infrastructure en envoyant des messages aux autres éléments physiques. ▪ Compute-Node : Héberge la couche de virtualisation (Hyperviseur), qui dans notre cas est matérialisée par le module KVM (Kernel-Based Virtual Machine) qui sera rajouté au Noyau Linux. Dans le jargon Openstack un hyperviseur est appelé un Compute Node. ▪ Network Node : Gestion des réseaux dédiés aux VMs, il va aiguiller les paquets venant du réseau public jusqu’à la VM. Cette entité va servir de lien entre le réseau public et le réseau privé en appliquant des règles de sécurité, tout comme un firewall. ▪ Le client de la VM : Dans notre scénario, ce client va interroger via son browser, le serveur Web situé sur une VM possédant une IP public. ▪ Le QNAP : Serveur NFS, afin d’héberger le disque virtuel de la VM. Les différents services seront présentés en §1.4 1.2 L’utilité des services Openstack : Le but premier d’Openstack est d’ajouter un service au-dessus des éléments intégrés au noyau Linux. Ils vont traduire les messages standardisés transitant à travers le réseau, en commandes interprétables par les modules du noyau tels que KVM ou Iptables. Message traduit en Commandes Systèmes compréhensibles par QEMU-KVM Figure 5.1 : But des services OpenStack Service Virtualisation Openstack Module QEMU-KVM Compute Node Message Standardisé Provenant d'un autre service
  • 90.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 68 A travers Figure5.1, nous pouvons comprendre que le service de virtualisation d’Openstack situé au niveau de l’hyperviseur, va recevoir des messages standardisés du Cloud Controller et va les traduire en commandes compréhensibles par KVM. Grâce à ce service, un même message pourrait démarrer une VM soit sur un hyperviseur KVM ou soit sur l’hyperviseur ESX. Ces derniers posséderaient chacun un service de virtualisation OpenStack, qui traduirait le message en commandes interprétables par son système. 1.3 Echange de messages : Deux types de communications vont s’effectuer au sein de notre infrastructure : ▪ Communication via API : Les différents services Openstack fournissent une API2, c’est à dire que le service va proposer une interface afin de pouvoir interagir avec ces méthodes ou fonctionnalités. Pour interagir avec les API, le système de requêtes REST (Representational State Transfer) est très employé au sein de l’infrastructure OpenStack, c’est à dire que l’on peut envoyer au service une URL, contenant tous les paramètres que la méthode a besoin pour s’exécuter3. Cet échange se fait via le protocole http. L’API va nous retourner un objet JSON, qui pourra être interprété par le client. Un service d’API, comme présent sur le Cloud Controller va écouter sur un port particulier afin de recevoir les requêtes http, et va convertir ces dernières en message AMQP. ▪ Communication via file de messages (Advanced Message Queuing Protocol) AMQP : Afin d’unifier la communication réseau entre les services, le système adopté a été de mettre en place une infrastructure de communication inter-serveur basée sur des files de messages, grâce au protocole AMQP. Le protocole est géré par le serveur Qpid qui est le courtier hébergé sur le Cloud Controller. Le système de queues permet aux services de travailler de manières non synchronisées pour qu’ils puissent s’envoyer des messages en mêmes temps. Les appels de procédures distantes entre les services se font par l’envoi de messages RPC (Remote procedure call) encapsulé dans le protocole AMQP. Chaque service Openstack instancie deux queues : o Une queue pour recevoir les messages envoyés à tous les nœuds d’un même type, donc par exemple tous les Nova-Compute. o Une queue spécifique à serveur physique, afin d’envoyer une instruction correspondant à un serveur physique en particulier grâce à son ID. Par exemple instancier une VM sur un hyperviseur en particulier. Le Scheduler (Qpid Server) va servir de table de routage afin d‘aiguiller les messages. Il connaît la description de tous les nœuds ainsi que toutes les procédures que l’on peut appeler à distances. Les services recevant des messages AMQP comme NovaCompute, n’écoutent pas sur port particulier, mais maintiennent une liaison permanente en Unicast avec le serveur QPID. Au moment d’installer l’infrastructure, l’analyse des messages AMQP se révèle un très bon moyen pour comprendre les interactions entre les différents services, et nous renseigne sur les différents problèmes entres les services car les messages échangés sont stockés dans les Logs (Voir §1.6 exemple d’échange). En ce qui concerne le Scheduler, je n’ai pas eu besoin
  • 91.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 69 d’aller analyser le comportement des queues de communication, car cette partie est correctement implémentée au sein des différents services. Figure5.2 résume les deux types d’échanges qui résident au sein d’OpenStack (extrait de http://docs.openstack.org/developer/nova/devref/rpc.html) : Figure5.2: Différents types de messages En 1, sont représentés les services réceptionnant les requêtes http provenant d’un client d’API (voir §1.4.1). Cette requête va être transformée sous forme de message AMQP (2), afin d’être distribuée au service concerné, par l’intermédiaire du QPID serveur. L’avantage de ce type de message est qu’il utilise un formatage prédéfini. Par conséquent, un même message peut être compris par différents langages de programmation et différents services. 1.4 Les services OpenStack : Pour fonctionner correctement, notre infrastructure Openstack a besoin de plusieurs éléments ayant des rôles bien spécifiques. Openstack est constitué de plusieurs services pouvant communiquer entre eux afin de gérer toutes les facettes de notre infrastructure. 1.4.1 Administration de l’infrastructure Openstack : Pour administrer notre infrastructure, deux solutions s’offrent à nous. En ce qui concerne l’envoi de commandes comme par exemple une création de VM se fait via des requêtes http à une API. Nous pouvons utiliser un client d’API (par exemple python-novaclient) CLI écrit en python, qui va se charger d’encapsuler dans une requête http les paramètres de la commande : nova boot --flavor 2 --image 397e713c-b95b-4186-ad46-6126863ea0a9 Réception des requêteshttp 1 2 http
  • 92.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 70 Nous avons aussi la possibilité d’administrer notre infrastructure via une interface Web appelée Horizon Dashboard. Cette interface Web va se charger de communiquer avec les différentes API. L’utilisateur effectue une requête auprès du site Web Horizon, et le serveur Web se charge de dialoguer avec l’API en question. Figure5.3 : Interface GUI Horizon 1.4.2 Gestion de la virtualisation : Quand nous parlons de gestion de la virtualisation, nous devons piloter le module de virtualisation QEMU-KVM de l’hyperviseur, ainsi que les règles du firewall afin de contrôler les points d’entrées depuis le réseau public, pour cela nous avons besoin des services Nova. Trois éléments vont constituer cette gestion4 : Nova-API : Ce service propose une API qui pourra être utilisée via CLI en effectuant des requêtes REST par l’administrateur physique. Les requêtes envoyées par l’administrateur vont être redirigées via des messages AMPQ aux différents services pouvant remplir la tâche voulue par l’administrateur. Il pourra remonter des informations sur la VM, comme son adresse IP, ou recevoir des ordres de création de VMs. Nova-Compute : Ce service est installé sur l’hyperviseur et communique directement avec le module QEMU-KVM, grâce à la librairie libvirt. Il va traduire les messages AMQP reçu de Nova-API en commandes compréhensibles par KVM. Ordonnanceur OpenStack: Au sein d’une infrastructure possédant plusieurs hyperviseurs, un service d’orchestration doit être mis en place afin de pouvoir choisir judicieusement sur quel hyperviseur une VM va être démarrée. Nous avons deux types de techniques d’occupation des VMs sur l’hyperviseur :
  • 93.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 71 ▪ Répandre : L’ordonnanceur essaie de répartir les VMs sur l’ensemble des hyperviseurs, afin d’équilibrer les charges entre chacun. Il va regarder celui qui a le plus de RAM disponible. ▪ Remplir : L’ordonnanceur essaie de remplir au maximum les hyperviseurs afin d’en solliciter un minimum. Cette technique est intéressante afin de réduire son empreinte écologique car un minimum de machines physiques est opérationnel. Par conséquent, celles activent risquent d’être surchargées en cas de pic de charge. Cependant l’ordonnanceur présente des limites au moment où les hyperviseurs ont des quantités de RAM hétérogènes. Si un hyperviseur possède beaucoup plus de RAM que tous les autres, malgré le fait que l’on favorise l’étalement, il sera plus sollicité à cause de son importante RAM disponible. Donc il est vivement conseiller d’avoir du matériel uniforme, ou que l’ordonnanceur ajoute dans son choix la quantité de vCPU disponible par hyperviseur. Pour effectuer les mesures de charges, chaque hyperviseur envoie à l’ordonnanceur sa quantité de RAM disponible. Cette mesure est effectuée à partir des profiles attribués aux VMs s’exécutant sur l’hyperviseur. Par conséquent, si une VM est éteinte la quantité de RAM physique qui lui est allouée est considérée comme consommée. Les valeurs sont statiques et non dynamiques. Nova-Network : Ce service est installé sur notre Network Node, il va physiquement faire la liaison entre le réseau public (rouge) et le réseau privé des VMs, car dans notre scénario la VM hébergeant un serveur Web doit pouvoir être interrogée depuis le réseau Internet global. Le service va interagir avec le firewall iptables, cette entité physique doit être vue comme un routeur. Le service Nova-Network va pouvoir proposer une IP public à une VM, pour cela il va utiliser la technique du floating IP (Voir §1.7). 1.4.3 Gestion de l’authentification (Keystone) : Le service Keystone situé sur le Cloud Controller permet d’offrir une gestion des identités et des autorisations d’accès pour les utilisateurs. Le service Keystone va permettre de contrôler de façon centralisée les accès aux différentes API. Le système de validation est basé sur un système de token. Ce système a été implémenté afin d’avoir des périodes d’accès limitées dans le temps. Nous pouvons également cloisonner les utilisateurs, car ils peuvent se voir attribuer un token qui leur permettra uniquement de créer des VMs, ou un autre uniquement pour la gestion des volumes de stockages. En somme nous pouvons créer des contrôles d’accès aux APIs. Comme nous avons une infrastructure de type PKI, le token signé est contenu dans un message CMS « Cryptographique Message Syntax5 », par conséquent Keystone est une autorité de certification (CA) 6. Figure5.5 représente les échanges d’authentification de l’administrateur désirant envoyer une requête à une API2 . 2 Opennebula. http://opennebula.org/.
  • 94.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 72 Figure5.4 : Authentification Keystone A l’installation du service Keystone, de par son rôle d’autorité de certification, nous devons générer en local sur le Cloud Controller grâce à l’outil OpenSSL: ▪ La clé privée de la CA : Openssl genrsa -out /etc/keystone/ssl/certs/cakey.pem 2048 -config /etc/keystone/ssl/certs/openssl.conf ▪ Générer le certificat de la CA avec sa clé privée : Openssl req -new -x509 -extensions v3_ça -passin pass: None -key /etc/keystone/ssl/certs/cakey.pem -out /etc/keystone/ssl/certs/ca.pem -days 3650 -config /etc/keystone/ssl/certs/openssl.conf -subj /C=US/ST=Unset/L=Unset/O=Unset/CN=www.example.com ▪ Génération de la clé privée pour signer les Tokens : Openssl genrsa -out /etc/keystone/ssl/private/signing_key.pem 2048 -config /etc/keystone/ssl/certs/openssl.conf ▪ Génération du certificat pour vérifier les Token : Openssl req -key /etc/keystone/ssl/private/signing_key.pem -new -nodes -out /etc/keystone/ssl/certs/req.pem -config /etc/keystone/ssl/certs/openssl.conf -subj /C=US/ST=Unset/L=Unset/O=Unset/CN=www.example.com • Explications des points 1 et 2 du Figure5.4 : 1. Une fois la vérification Username/Password effectuée, Keystone va générer un token signé sous la forme d’un CMS en utilisant sa clé privée (Signing_key.pem) grâce à la commande OpenSSL: Openssl cms -sign -signer /etc/keystone/ssl/certs/signing_cert.pem -inkey /etc/keystone/ssl/private/signing_key.pem -outform PEM -nosmimecap -nodetach -nocerts - noattr User Name/Password Token (Format CMS) Requête http + Token Contrôle de la validité du Token Envoie de la réponse à la requête http Contrôle Username Password Si le certificat est valide Réponse de Keystone si OK 1 2
  • 95.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 73 2. L’API envoie à Keystone le token reçu afin qu’il puisse vérifier sa signature grâce au certificat req.pem. 1.4.4 Les Bases de Données : Afin de stocker les différentes informations relatives à notre infrastructure, le Cloud Controller possède un serveur de base de données MariaDB7, qui est un dérivé de MySQL. Pour configurer OpenStack, je n’ai pas eu besoin d’effectuer des requêtes SQL, donc les contenus des bases sont présents à titre indicatif. Le serveur va posséder deux bases de données : ▪ Base Keystone : Contient les utilisateurs, les tokens délivrées, ainsi que leurs périodes de validités Aperçu des champs de la table user de la base Keystone : MariaDB []> use keystone; MariaDB [keystone]> describe user; Field Type Null Key Default Extra Id Name Extra Password Enabled Domain_id Default_project_id Varchar (64) Varchar (255) Text Varchar (128) tinyint (1) Varchar (64) Varchar (64) NO NO YES YES YES NO YES PRI MUL NULL NULL NULL NULL NULL NULL NULL ▪ Base nova : Contient toutes les informations des VMs, comme leurs informations réseaux, leurs caractéristiques, et également la liste des computes nodes à disposition : Comme par exemple la table « Computes_Nodes » : MariaDB []> use nova; MariaDB [nova]> describe compute_nodes ;
  • 96.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 74 1.5 Profil d’une VM : Dans ce chapitre, nous allons étudier sur les différents éléments qui caractérisent une VM. Pour créer une nouvelle VM (ou instance chez Openstack), nous devons renseigner le Compute Node sur les caractéristiques techniques Hardware qu’elle possédera comme : ▪ Le nombre de VCPU ▪ La taille des disques durs ▪ La quantité de RAM virtuelle Ces caractéristiques sont regroupées par profils appelés « Flavors8 ». Ce système de profil simplifie grandement la tâche pour l’administrateur, du fait que sa VM aura un profil Hardware prédéfini. Voici une liste des Flavors disponible par défaut, mais que l’on peut éditer sans aucun problème : En ce qui concerne la distinction entre Disk et Ephemeral: Une VM peut avoir deux types de disques virtuels. Ces deux types de disques suivent le cycle de vie, ils seront donc supprimés au moment où l’on supprime la VM. Les disques virtuels au niveau de l’hyperviseur correspondent à un fichier. Figure5.5, illustre les deux disques que la VM a à disposition.
  • 97.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 75 Figure5.5 : Disques virtuels d'une VM Les deux disques virtuels sous formes de fichiers sont stockés dans le dossier /var/lib/nova/instances/ du Compute Node, mais ce dossier pointe sur le serveur NFS du QNAP via le réseau de Storage Jaune : ▪ Disk (Bleu): Héberge la partition Root / de l’OS ▪ Ephemeral Disc (Rouge): Peut-être une deuxième partition pour la VM Au moment où l’on fait un fdisk -l dans la VM, voici les disques que nous voyons : Disque /dev/vda : 75.2 Go -> Root Disc Disque /dev/vdb : 21.5 Go -> Ephemeral Disc Ephemeral est en réalité l’ajout d’une deuxième partition à la VM. Quand nous regardons le fichier XML généré par Libvirt afin de créer la VM : <disk type="file" device="disk"> <driver name="qemu" type="qcow2" cache="none"/> <Sourcefile="/var/lib/nova/instances/84673e27-e948-49c0-a44f-a842aac7684b/disk"/> <target bus="virtio" dev="vda"/> </disk> <Disk type="file" device="disk"> <Driver name="qemu" type="qcow2" cache="none"/> Fedora 19 VM Fichier Disk0 Stockage NFS QNAP Dossier dans Compute Node : /var/lib/nova/instances/ Ephemeral /dev/vdb Disk /dev/vda Fichier Disk1
  • 98.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 76 <sourcefile="/var/lib/nova/instances/84673e27-e94849c0a44fa842aac7684b/disk.local"/> <target bus="virtio" dev="vdb"/> </disk> Nous voyons bien la définition des deux disques, le premier est le Disk et le deuxième est le Ephemeral d’après le Flavor. Dans mon cas l’ajout d’un deuxième disque (Ephemeral), n’est pas d’une grande utilité, sachant qu’il va être détruit au moment de la suppression de la VM. Voilà pourquoi, j’ai mis en place une unité Cinder dans le §.2. 1.6 Processus de démarrage d’une VM : Figure5.6 résume les communications entre les différents services d’OpenStack : Figure5.6 : Démarrage d'une VMs 1. L’administrateur via l’interface Web ou une commande, indique le Flavor de la VM, la liste des Security Group. Tous ces paramètres sont envoyés à l’API Nova via une requête http. Par souci de lisibilité je n’ai pas représenté le contrôle d’autorisation avec Keystone (voir §1.4.3). Administrateur Démarrage de VM Nova-API Nova-Network Nova-Compute Nova DataBase QEMU-KVM VM IPTABLES Filtering IPTABLES NAT DHCP-Serveur 1 2 3 4 5 6 7 8 99 6 Protocole http Message AMQP Commande Système Protocole DHCP
  • 99.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 77 Figure5.7 : Configuration de la future VM 2. Tous les messages AMQP doivent transiter par un QPID serveur que je n’ai pas représenté, également par souci de lisibilité. Nova-API envoie au service NovaCompute le profil de la VM qui va être créé Extrait des Logs AMQP de Nova-API : 3. Nova-Compute envoie à KVM, les caractéristiques reçues par message AMPQ, la VM démarre. Le service Nova envoie le profil complet de la VM à Libvirt (Extrait du fichier de log ne Nova Compute:
  • 100.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 78 4. Le serveur DHCP envoie une IP à la nouvelle VM, et écrit dans un fichier la MAC IP /var/lib/nova/networks/nova-br100.conf : Fa:16:3e:20:1b:65, vm-test. Novalocal,192.168.1.8 5. Le service Nova-Network lit ce fichier 6. Nova-Network envoie les informations réseaux à Nova-API 7. Nova-API écrit dans la base de données les informations réseaux ainsi que les caractéristiques de la nouvelle VM. Extrait de la table « instances » de la DB Nova : 8. Les informations de Floating IP sont envoyées au Nova-Network et les securitygroup au Nova-Compute 9. Les deux services vont configurer les règles NAT et Filtering des Iptables. 1.7 Réseau des VMs : Dans ce chapitre nous allons étudier en détail la gestion du Floating IP, ainsi que les Security Group, au niveau IPTABLES et interfaces physiques, en faisant abstraction des services Openstack. ▪ Le Floating IP : Le Floating IP est utilisé pour attribuer une IP public à une VM. Dans notre exemple, la VM va posséder comme IP public : 129.194.184.85. Le principe est de rajouter une deuxième adresse IP sur une carte Ethernet physique. Dans notre cas, la carte Eth2 possède l’adresse IP : 129.194.184.91 et grâce au IP Alias nous ajoutons une seconde adresse IP : 129.194.184.85. Il est possible de rajouter N IPs flottantes sur cette interface physique, correspondant aux IPs Publics de N VMs. IP Alias est une fonction intégrée dans le kernel linux. Pour afficher la configuration des IP Flottantes sur la carte réseau eth2, nous ne pouvons plus utiliser la commande ifconfig devenue obsolète. Il faut utiliser les outils plus élaborés comme le package iproute2, avec la commande ip :
  • 101.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 79 ▪ Trajet (Vert) d’un paquet http venant du réseau public : Figure5.8 : Gestion de l'IP flottante Nous supposons que les Security-Group et le Floating IP ont déjà été configurés par les services Nova-Network et Nova-Compute. Je vais analyser le contenu des IPTABLES-NAT et IPTABLES-Filtering. La règle de Security-group est d’autoriser uniquement le trafic IP à destination du port 80. 1. Le client envoie une requête http au serveur Web possédant l’adresse IP 129.194.184.85. Le paquet traverse l’interface Eth2 ayant l’allias 129.194.184.85. Pour afficher le contenu des tables NAT d’Iptables, nous faisons : iptables -S -t nat Voici un extrait de la table NAT de l’IPTABLES : nova-network-PREROUTING -d 129.194.184.85/32 -j DNAT --to-destination 192.168.1.2 Compute-Node Network node Eth2 Eth1 vSwitch Eth1 vSwitch VM Fed-19-Web IP: 192.168.1.2 SRV DHCP IPTABLES-NAT Eth0 Eth2Eth0 IPTABLES-Filtering Réseau Public Client IP : 109.190.146.132 Requête http sur 129.194.184.85 IP Eth2 : 129.194.184.91 Alias : 129.194.184.85 1 2 3 LAN Management LAN Privé des VM
  • 102.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 80 Les paquets ayant comme IP destination 129.194.184.5 sont redirigés vers l’adresse IP 192.168.1.2. IPTABLES va modifier l’adresse IP de destination par 192.168.1.2. Nous pouvons le voir en faisant un TCPDUMP -i eth1 : 109.190.146.132.50875 > 192.168.1.2. Http 3 2. Le paquet sort du Network-Node via l’interface Eth1 et rentre dans le Compute Node, mais avant d’arriver à la VM le paquet va être filtré par IPTABLES-Filtering qui a été modifié à partir des Security-Group : Nova-compute-inst-9 -p tcp -m tcp --dport 80 -j ACCEPT Les paquets à destination du port 80 de la VM (nova-compute-inst-9) sont autorisés. Il faut voir ces règles de Security comme des règles de Firewalls de types statefulls. Nous contrôlons les paquets qui viennent du réseau Public en direction de la VM. Ces règles vont être traduites en règles IPtables. Voici une capture d’écran concernant les règles IPtables de l’interface Horizon pour autoriser l’ouverture du port 80: Figure5.9 : Security-Group sous Horizon 3. En faisant un TCPDUMP dans la VM nous voyons le paquet possédant l’adresse source du client : 109.190.146.132.52353 > 192.168.1.2. http En conclusion nous voyons que toutes les règles de filtrage et de NAT doivent être dynamiques car la VM ou le Floating peuvent changer d’adresse IP, il est primordial que les différents services Nova-Network et Nova-Compute fassent remonter les informations et puissent être contrôlés depuis un système centralisé : Nova-api. 1.8 Stockage par fichier des VMs : Plusieurs architectures de stockage s’offrent à nous. Le stockage des disques virtuels des VMs doit être externe à l’hyperviseur, afin d’avoir une unité de stockage centralisée, pour pouvoir effectuer de la live-migration et faciliter la gestion des systèmes de stockages. Mais l’OS de l’hyperviseur physique est lui stocké sur son propre disque dur. Le fait d’avoir un réseau dédié (jaune) a l’avantage de pouvoir augmenter les débits grâce à l’activation par exemple des Jumbo Frames. 3 ] redhat. http://www.redhat.com/products/cloud-computing/cloudforms/
  • 103.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 81 Cette architecture est moins performante qu’un stockage par bloc, car le système de fichier est hébergé du côté du serveur de stockage. Cependant, grâce au NFS, nous pouvons avoir un système de fichier partagé simple. Comme représenté sur le schéma global en §1, le stockage du disque virtuel de la VM est hébergé sur le QNAP. Il serait Judicieux d’ajouter un second système de stockage, mais cette fois-ci, il devra être par bloc et être persistant. En effet, si la VM est supprimée l’unité de stockage reste. L’étude de l’unité Cinder se fera au §2 1.9 Conclusion du Scénario 1a : A travers ce scénario, j’ai pu comprendre les interactions entre différents services qui évoluent au sein de mon infrastructure. J’ai passé beaucoup de temps dans la compréhension des interactions entre ces différents éléments. En effet, la documentation OpenStack au niveau de la configuration des services est relativement bien étoffée. Cependant le rôle que remplit chaque service est beaucoup moins bien documenté, c’est pour cela que j’ai dû analyser de nombreuses lignes de Logs, aller voir dans le code-source des différents services. L’infrastructure Openstack peut être qualifiée de complexe, de par ces nombreux systèmes qui s’imbriquent les uns dans les autres. Les différents services doivent en permanence communiquer entres eux, car nous sommes dans un milieu totalement dynamique. 2. Scénario lb : Gestion du stockage par bloc : A travers ce scénario, je vais explorer les stockages par bloc proposés par le Projet Cinder9. Cinder est un service OpenStack permettant de créer des volumes par bloc gérés par le protocole iSCSI. Cette unité de stockage n’est plus créée par l’ordonnanceur au démarrage de la VM, mais par l’administrateur, donc il ne va plus suivre le cycle de vie de la VM, du fait que lorsqu’elle sera détruite, ce volume ne sera pas supprimé. L’avantage d’un volume comme celui-ci permet d’héberger des données persistantes. Par exemple ce volume pourrait être monté au niveau du dossier /var/www (emplacement contenant généralement les pages web sur un serveur web), si la VM est hors-service, on pourra en démarrer une autre et lui ajouter ce volume à cette nouvelle instance. 2.1 . Schéma du scénario lb :
  • 104.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 82 Schéma 5.2 : Scénario 1b 2.2 Composition de Cinder : Sur le schéma 5.2, j’ai ajouté un élément physique Cible-iSCSI-Cinder. Cet élément va être piloté par le service placé dans le Cloud Controller : Cinder-api. Cinder est composé de deux éléments : ▪ Cinder API: Va recevoir les commandes envoyées par l’utilisateur via une requête REST contenant par exemple la taille du volume à créer et sur quelle VM il faut greffer le volume. ▪ Cinder Volume : Ce service va communiquer directement avec l’unité de stockage. Plusieurs possibilités s’offres nous, cette communication va se faire via l’utilisation de différents drivers : o Piloter la création de cible iSCSI situé dans un SAN propriétaire comme SolidFire10 o Un Cinder-Volume qui contient un serveur iSCSI et un volume LVM. L’API Cinder va piloter la création de la cible iSCSI afin de l’attacher à la VM, en fournissant à Libvirt l’IQN de la cible iSCSI11 2.3 Fonctionnement de Cinder :
  • 105.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 83 Schéma 5.3 : Attribution d'un volume par bloc Cinder-Volumes communique avec le serveur iSCSI pour créer une nouvelle cible pour la VM en question. La chaîne de lancement pour créer une unité de stockage par bloc est décrite par les numéros turquoise dans le schéma 5.3 : 1. L’administrateur envoie une commande de création d’un volume via l’api Cinder, via une requête http, contenant la taille du volume et sur quelle VM le greffer ou par CLI : cinder create --display_name Test_Vol 3GB 2. Cinder-API va envoyer un message AMPQ à l’unité de stockage (Cible-iSCSICinder 3. Le service Cinder-Volume communique avec le manager de cible iSCSI intégré à Fedora « tgtadm ». Extrait du code source de Cinder indiquant l’appelle au service « tgadm » : 4. Une fois la cible iSCSI créée, le service Cinder-volume envoie à Cinder-API les informations de la cible iSCSI qui va les relayer à Nova-API, et va créer une nouvelle entrée pour ce volume dans la base de données MySQL Compute Node Cinder-Volume LVM Volume iSCSI Tgt Cinder-API Nova-Compute Controller Node Nova-API DB Cinder Administrateur : Création d'un volume à attaché à la VM KVM VM AMPQ AMPQ REST iSCSI Commandes Tgt 1 3 2 4 5 6 Cible-iSCSI Cinder
  • 106.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 84 5. Nova-API envoie l’ordre d’ajout d’un nouveau volume à Nova-Compute, qui va transférer ces informations à KVM. Voici un exemple du template généré par Libvirt pour décrire la configuration du nouveau volume iSCSI: 6. La VM possède un nouveau volume monté en /dev/vdc : 2.4 Problèmes rencontrés : J’ai eu quelques problèmes en ce qui concerne l’analyse de Cinder-API et Cinder- Volume, du fait que la plupart du temps, Cinder Volume est couplé avec un SAN propriétaire. La documentation indiquant comment faire fonctionner Cinder-Volume avec le gestionnaire de cible iSCI (tgtadm) intégré à Linux n’est pas très riche. Un des gros problèmes avec la documentation OpenStack, est d’interpréter sur quelle unité physique tels ou tels services s’installent. Dans la théorie, chaque service peut s’installer sur n’importe quelle entité physique. Mais dans le cas du Cinder-volume qui pilote la cible iSCSI, il faut qu’il soit installé sur le même serveur physique que le LVM Volume, car le service python fait des appels de commandes en local. 2.5 Conclusion du Scénario lb : A travers ce scénario j’ai pu ajouter un volume persistant à une VM. De plus, ce volume est un stockage par bloc interrogeable via le protocole iSCSI. Comme application, nous pourrions héberger une base de données MySQL, afin d’avoir des performances plus élevées que si nous avions uniquement un stockage par fichier NFS. L’unité Cinder possède un gros avantage de flexibilité, grâce à l’ajout dynamique d’unités de volume. III. Scénario 2 : Haute Disponibilité du Cloud Controller : Au cours des scénarios précédents, nous avons obtenu une infrastructure fonctionnelle, accueillant des VMs pouvant héberger nos applications métiers. Cependant, il réside un gros point faible dans notre infrastructure, concernant un de nos composants de gestion. En effet, si le Cloud Controller venait à être hors-service, il nous serait alors impossible de gérer nos VMs ou d’en créer de nouvelles. Par conséquent, nous devons repenser l’infrastructure afin de mettre en place des systèmes redondants pour limiter au maximum des situations d’échec. Ceci pourra être mis en place grâce à des mécanismes permettant de construire un environnement de Haute- Disponibilité (High Availability -> HA).
  • 107.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 85 De nombreuses solutions de HA existent, mais parfois, elles peuvent vite représenter une lourdeur supplémentaire, et par conséquent compliquer grandement notre système en risquant de le rendre instable. A travers ce chapitre, je vais faire cohabiter plusieurs types de HA, qui auront toutes un rôle précis pour chaque élément que je dois rendre disponible. 1. Qu'est-ce que la HA : La HA peut être appliquée sur une multitude de services afin de garantir un service opérationnel. Comme le montre le schéma de principe 14, il faudrait par exemple que l’administrateur puisse toujours démarrer des VMs, donc grâce à la HA, nous allons lutter contre les indisponibilités, en installant un second Cloud Controller physique (voir schéma 5.7 du Scénario 2 pour un contexte réel) afin de dupliquer les services. 1 2 3 HA Active/Passive Stateless HA Active/Active Stateless HA Active/Active Statefull Schéma 5.4 : Principe de HA Le schéma 5.4, montre les différents types de mécanismes de HA appliqués à chaque élément de mon infrastructure. Dans les points suivants, je vais m’intéresser uniquement aux éléments 1 et 2, la HA SQL (élément 3) sera traitée au §3. 1.1 La HA Active/Active : Ce type de HA (Elément 2 Schéma 5.4) oblige la mise en place de deux serveurs physiques Master + Master (Cloud Controller 1 et 2) ayant les mêmes services installés et démarrés. Par conséquent les deux serveurs sont en permanence actifs, ce qui limite les temps d’indisponibilité au moment de la mise en échec d’un des deux. Comme les deux serveurs peuvent répondre aux requêtes, j’ai dû installer un load balancer qui se charge de répartir les charges entre mes deux serveurs. C’est-à- dire que le client s’adresse au Load Balancer (Flèche Verte) et ce dernier va aiguiller les paquets vers les serveurs disponibles (Flèches Bleues). Ce service de load balancing sera géré par HAProxy (voir §2.4 pour le fonctionnement de HAProxy). Comme tout le trafic traverse le load balancer, il présente un « point of failure », par conséquent, nous devons intégrer la HA pour cet élément, mais qui ne pourra pas être traité avec de la HA Active/Active. 1.2 La HA Active/Passive : Ce type de HA met en place deux serveurs : Master + Salve. Sur ces deux serveurs sont installés les mêmes services, mais sur le MASTER ils sont démarrés, tandis que sur le SLAVE ils sont stoppés. Voici un schéma représentant le système : API OpenStack Load Balancer 1 Load Balancer 2 Nova 1 Nova 2 Cinder 1 Cinder 2 Horizon 1 Horizon 2 Client Envoie requêtes http Roundrobin Echange IP virtuelle KeepAlived Noeud1 MySQL ou MariaDB Noeud2 MySQL ou MariaDB Réplication des Données Cluster MySQL
  • 108.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 86 Si les services ne sont pas ON, le Slave démarre son service Schéma 5.5 : HA Active/Passive Si un des services ne répond plus, l’autre service va démarrer sur le SLAVE. Le problème de ce type de HA, est que le SLAVE a ces services OFF, donc nous pouvons avoir un temps d’indisponibilité important entre le moment où le service commence son démarrage et devient opérationnel. En effet, le script de démarrage du service peut effectuer de nombreuses tâches, comme par exemple, se connecter à une base MySQL et attendre la réponse du serveur QPID. Ce type de chaîne de lancement au sein des services Openstack est couramment utilisé. J’ai implémenté ce type de HA uniquement au niveau du load balancing (Elément 1). En effet, l’intégration d’un deuxième Load Balancer considéré comme Slave est primordial mais seul l’un des deux sera actif. Dès que le Master ne répondra plus, le Slave prendra le relai. Le client s’adresse à l’un des loads balancer via une adresse IP Virtuelle, qui sera gérée par un service choisissant quel load balancer se verra attribuer cette IP. 1.3 L’IP flottante ou virtuelle : Pour avoir un système basé sur de la HA Active/Passive avec deux load balancer, l’un des deux doits pouvoir répondre aux requêtes. Pour cela nous allons utiliser le principe d’IP flottante comme vu dans §1.7. Ce service géré par « Keepalived13 », va attribuer une adresse IP supplémentaire (virtuelle) sur le Serveur actif. L’utilitaire installé sur les deux serveurs va tester si un service est ON, s’il ne l’est pas, l’IP flottante passe du Master au Slave. Service 1 (ON) Service 2 (ON) Service 3 (ON) Service de Controle de HA (ON) Service 1 (OFF) Service 2 (OFF) Service 3 (OFF) Service de Controle de HA (ON) Slave teste si les services du MASTER sont toujours ON
  • 109.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 87 Schéma 5.6 : Gestion IP virtuelle D’après le schéma 5.6, grâce à cette technique le client aura toujours la même IP de destination mais ne s’adressera pas toujours au même Load Balancer. Les deux services Keepalived communiquent entres eux via le protocole VRRP14 (Virtual Router Redundancy Protocol), pour que le Master transmette au Slave l’échec de son service. Ce protocole permet l’élection d’une passerelle possédant l’IP flottante, afin qu’il puisse répondre aux requêtes ARP (voir §2.5 pour un cas concret). 1.4 Services Stateless ou Statefull : Les services ne réagissent pas tous de la même manière au moment où ils sont dupliqués. C’est pour cela que nous devons gérer la haute disponibilité différemment si nous sommes en présence de services Stateless ou Statefull. ▪ Services Stateless : Un service n’a pas besoin de connaître son état précédent, donc les services dupliqués n’ont pas d’obligation à communiquer entre eux afin de se partager leurs états. Par exemple, les Services d’API OpenStack sont Stateless, ils sont indépendants les uns des autres. ▪ Services Statefull : Un service dit Statefull est obligé de connaître son état précédent pour répondre à une requête. Donc au moment où nous implémentons de la HA Statefull, nous devons Rajouter un système de réplication, afin de propager la donnée au sein de tous les services redondants. Par exemple, une base de données est un service Statefull. La donnée que l’on a écrite de sur un nœud SQL doit être propagée dans tous les autres nœuds SQL. Les notions Statefull et Stateless sont indépendantes de la HA Active/Active ou Active/Passive. En effet, nous pouvons très bien travailler en Active/Passive avec des services Statefull. Le service Master envoie son état au Slave qui est off, afin que ce dernier possède l’état du Master au moment où il démarrera.
  • 110.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 88 2. Scénario 2 : La HA au sein des AP] OpenStack : Dans ce scénario, je vais implémenter la HA au sein de mon Cloud Controller sur l’ensemble des API qui composent mon Infrastructure OpenStack : ▪ Interface Web Horizon ▪ API Nova ▪ API Cinder ▪ API Keystone J’ai choisi d’installer les bases de données MySQL (Keystone DB, Nova DB et Cinder DB) sur une autre machine physique, afin de ne m’attarder que sur la HA au niveau des requêtes http avec les API. En effet la HA MySQL doit être traitée avec une approche différente. Pour rappel, le contact d’une API se fait par l’envoi d’une requête http. L’API écoute sur un port particulier. Le schéma 5.7 résume la cohésion entres les différents éléments physiques au moment où un administrateur envoie une requête sur l’interface web Horizon écoutant sur le port 80. Pour mettre en place ce scénario, je me suis basé sur la documentation fournie par RedHat 15 et Mirantis 16 (société fournissant des services dans l’implémentation d’OpenStack). 2.1 Schéma du scénario 2a : Schéma 5.7 : HA au sein de l'API OpenStack 2.2 But du Scénario : Sans intégration de HA, avec l’infrastructure du Scénario 1, au moment où l’on stoppe un des services d’API OpenStack tel que Nova API nous obtenons ce message d’erreur : Horizon Port : 80 Nova-API Port : 8774 Cinder-API Port : 8776 Keystone Port : 5000 HAProxy Eth0 10.2.4.101 KeepAlived Horizon Port : 80 Nova-API Port : 8774 Cinder-API Port : 8776 Keystone Port : 5000 HAProxy Eth0 10.2.4.106 KeepAlived Cloud Controller 1 Cloud Controller 2 Utilisateur Navigateur Web Echange Multicast pour savoir où est placé l'IP virtuelle Redirection depuis le HAProxy vers les 2 API disponibles IP Virtuelle : 10.2.4.100
  • 111.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 89 A travers ce scénario, je vais limiter l’apparition de ce message en ajoutant un second Cloud Controller permettant de répondre également aux requêtes de l’administrateur et de prendre le relais en cas de défaillance du Controller 1. Lorsqu’un câble réseau du Controller 1 de l’interface Eth0 est débranché pour simuler une panne générale, il sera alors toujours possible de gérer la création de VMs. En réalité, le paquet a été aiguillé vers le Controller 2. 2.3 Éléments physiques : Au niveau des machines physiques, j’ai quasiment la même infrastructure que dans les scénarios précédents, j’ai ajouté un deuxième Cloud Controller qui possède la même configuration que le premier. Pour avoir de plus amples détails à propos du paramétrage des différentes machines physiques, voici mon dépôt Github : https://github.com/hepiatelecom- labs/Openstack_Config/tree/master/Object_config/HA qui regroupe les fichiers de configuration utilisés dans mon infrastructure. 2.4 HA Active/Active avec HAProxy : Ce type de HA comme vu au §1.1 est assuré par un Load Balancer Open Source HAProxy. Je l’ai installé sur les deux Cloud Controllers afin de ne pas dédier deux machines physiques à cette tâche et de garantir la HA sur les Load Balancer au cas où l’un d’eux serait non-opérationnel. Voici une partie de la configuration de HAProxy afin de comprendre les interactions entre les IP des serveurs physiques et l’IP virtuelle pour une requête émise par l’administrateur au serveur web horizon : La configuration du HAProxy doit être identique sur les deux Controller. Le Proxy écoute sur le port 80 au niveau de l’IP virtuelle (10.2.4.100) et va aiguiller les paquets sur les serveurs situés en backend (controller-1 et controller-2). La technique d’aiguillage est basée sur le RoundRobin, c’est-à-dire que la charge va être répartie équitablement sur les deux serveurs web des deux Controller. Il va également tester le serveur cible à qui il choisit d’envoyer le
  • 112.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 90 paquet, en faisant par exemple une requête http sur le port d’une API. Si l’API du controller-1 ne répond pas, il va aiguiller le paquet sur controller-2. 2.5 HA Load Balancer avec KeepAlived : KeepAlived va assurer la disponibilité des Load balancer, en étant installé sur les deux Controller. Voici un extrait des deux fichiers de configurations des deux services KieepAlived : Les deux KeepAlived communiquent entre eux par VRRP, ils possèdent le même « virtual_router_id » que l’on peut apparenter à leur fréquence de communication. L’attribution de l’adresse IP Virtuelle est basée sur un système d’élection entre les deux KeepAlived. Comme nous le voyons dans les fichiers de configuration, j’ai arbitrairement choisi que le Controller 1 dans un fonctionnement normal serait MASTER, de par sa priorité qui est de 101 et de son état initial (state) MASTER. Au moment où deux KeepAlived démarrent en même temps, ils procéderont à l’élection du Master : celui qui a la plus haute priorité possède l’IP virtuelle4 . Le service KeepAlived va tester toutes les 0.1 secondes l’état du service, dans le cas où il est STOP le Master passe en Backup et transmet l’IP Virtuelle au deuxième KeepALived. Dans mon infrastructure de HA, la relation Active/Passive, est uniquement présente dans la gestion de l’IP Virtuelle administrée par KeepAlived, car il n’y a qu’un seul Load Balancer qui peut répondre à la fois. Autrement, passé les Load Balancers, tous les services OpenStack font de la HA Actif/Actif. 2.6 Bilan Scénario 2a : Ce scénario m’a permis de comprendre comment fonctionne la HA. De plus, un certain nombre d’éléments interviennent dans cette topologie et il est donc important de comprendre comment ils interagissent entres eux. A la fin de ce scénario, au moment où je débranche le câble réseau de mon Controller1, je peux sans autre continuer à naviguer sur mon interface web, et gérer mes VMs sans pertes de connexions. Pour visualiser l’échange d’IP Virtuelle nous pouvons analyser les Log, en faisant : 4 Salesforce. http://www.salesforce.com/fr/.
  • 113.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 91 A travers ces extraits de Log nous voyons bien que la transition de l’IP Virtuelle se fait très rapidement, de l’ordre de quelques secondes, ce qui explique que pour l’administrateur, le fait de perdre un des deux Controller est totalement transparent. Il ne va détecter aucune interruption de service. Au niveau de cette architecture de HA, j’ai installé deux Cloud Controller, mais il serait aisé de rajouter N autre Cloud Controller. Il faudrait juste ajouter l’IP des nouveaux serveurs backends dans le fichier de configuration de chaque HAProxy et modifier les priorités des KeepAlived dans leurs fichiers de configurations. Avec la HA Active/Active, l’ajout d’un grand nombre de Controller permet également une meilleure répartition des charges entre tous les Cloud Controller grâce au Load Balancer. Un problème réside à travers ce scénario, comment détecter la perte d’un Controller du fait que les échanges de Load Balancing se font automatiquement. Par conséquent pour déceler un problème, il est indispensable de se connecter sur chaque Controller et faire défiler les Logs à la main. Par la suite, il serait judicieux de mettre en place un système de monitoring avec Shinken, qui permettrait d’automatiser les tests de disponibilités pour que nous soyons alertés automatiquement des éventuels problèmes de pertes de services. De plus, la mise en place d’un serveur centralisé de Logs est indispensable, afin de faciliter leurs analyses en cas de panne. 3. HA SQL (Active/Active Statefull) : Dans ce chapitre, je vais traiter de la haute disponibilité au niveau des bases de données SQL. Comme nous l’avons vu en §1, nous sommes en présence d’un système Actif/Actif Statefull. Voici les lignes directrices de mise en œuvre, afin de comprendre au mieux les interactions entre les différents nœuds SQL. Pour effectuer de la HA, au niveau de notre base
  • 114.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 92 de données, nous allons dupliquer cette base au sein de plusieurs nœuds, et l’ensemble des nœuds va constituer notre Cluster. 3.1 Schéma du Cluster SQL : Schéma 5.8 : HA au niveau SQL Le schéma 5.8 nous illustre une vue globale des différents types de HA qui interviennent uniquement au niveau de la partie SQL. Cette représentation montre un client qui désire écrire dans une base de données. L’élément omniprésent pour une HA Active/Active est le Load Balancer, qui va répartir les requêtes de manière round robin auprès des différents serveurs SQL. Depuis l’entrée en fonction de Fedora 19, le serveur MariaDB remplace le serveur MySQL suite au rachat de ce dernier par Sun Microsystems. 3.2 Théorème du CAP : Ce théorème basé sur la conjecture « Brewer’s Conjecture » réalisé par le Professeur Eric Brewer de l’université de Berkley, a été prouvé par Nancy Lynch et Seth Gilbert du Massachusetts Institute of Technology. Il énonce qu’un système distribué est régi par trois contraintes :
  • 115.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 93 ▪ Consistance (Cohérence) : Le fait d’avoir la même donnée sur tous les nœuds à un instant. ▪ Availability (Disponibilité) : Les clients peuvent en permanence trouver les données. ▪ Résistance au morcèlement (Partition Tolérance) : Le système fonctionne malgré des problèmes réseaux. Mais d’après ce théorème, le système ne peut pas se trouver dans plus de deux états à la fois. Prenons un exemple : Si l’on favorise la cohésion des données, les utilisateurs devront attendre que tous les nœuds se synchronisent entres eux avant de pouvoir effectuer une opération d’écriture ou de lecture. Si l’on favorise la disponibilité des données, comme dans le cas de Google, un utilisateur effectuant une recherche et obtenant un résultat, ne va pas forcément obtenir le même résultat qu’un autre. L’importance de ce système est de pouvoir retourner un résultat, bien que la cohérence de ce dernier ne soit pas la règle prioritaire. L’accent est effectivement mis sur la disponibilité. Schéma 5.9 : Théorème du CAP Le schéma 5.9 résume les trois états où peut se situer le Cluster. Dans notre cas, notre Cluster de base de données se situera dans la partie Consistency et Availability. L’accent sera donné sur la consistance des données. Par exemple, il est primordial que la base qui héberge les informations des VMs soit en permanence synchronisée, car si elle nous retourne une information fausse, toute notre prise de décision à propos du management des VMs sera erronée. Au final mieux vaut un petit temps de latence dû à la synchronisation, mais permettant d’obtenir des données crédibles. 3.3 Gestion du Cluster SQL :
  • 116.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 94 Comme nous pouvons le voir sur le schéma 5.8, les deux nœuds SQL sont basés sur Fedora 19, et les bases sont gérées par MariaDB. Comme je l’ai énoncé plus haut, la HA est de type Statefull, donc nous devons mettre en place un système de réplications des données ainsi que la gestion de la disponibilité de notre Cluster SQL. ▪ Galera : Un outil Open Source qui va gérer la consistance des données au sein de notre Cluster. Sa mise en place est très bien documentée : https://wiki.deimos.fr/MariaDB_Galera_Cluster_:_la_réplication_multi_maitres Je ne l’ai pas mis en place du fait que sa mise en pratique ne rentrait pas dans le périmètre du projet. Comme je l’ai indiqué dans §3.2, nous portons une attention toute particulière à la consistance des données auprès de tous les nœuds. Donc avant que le client reçoive un ACK l’informant que sa donnée est bien écrite dans la base, il faut que tous les nœuds soient synchronisés. L’avantage de mettre en place Galera, est que tous les nœuds de notre Cluster peuvent recevoir des requêtes, et donc nous avons l’abolition de la relation Master/Slave présente au sein d’un Cluster SQL standard ne possédant pas cette surcouche. Le point négatif de ce système, est que tant que la réplication n’est pas acquittée par tous, le cluster ne peut pas recevoir de requête supplémentaire. Donc le temps de traitement de la requête dépendra intrinsèquement du nœud le plus lent. IV. Scénario 3 : Collecte et entreposage des Logs : Comme indiqué ci-dessus, avec la topologie du scénario 2, il m’est impossible de diagnostiquer l’état des services OpenStack. Grâce à ce scénario, mon infrastructure Openstack va pouvoir réellement héberger une application qui permettra le stockage des Logs. Ce scénario va porter sur l’étude de différentes variantes d’acheminement des Logs à une base de données dédiée. De par la complexité de l’infrastructure, ainsi que des multiples services qui
  • 117.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 95 interviennent au sein d’un Cloud OpenStack, il devient nécessaire d’avoir un point central qui récupère les Logs, en vue d’une analyse du comportement des services. 1. Cahier des Charges : Les Logs sont des éléments essentiels dans la gestion d’un Système d’Information. Ils servent à analyser son comportement ou déceler diverses erreurs. Mais le gros problème réside dans le fait qu’ils sont souvent répartis sur différentes machines physiques, ce qui rend impossible la vision globale de l’état du système. LeShop.ch au sein de son infrastructure récolte des centaines de milliers de lignes de Logs/min provenant de ses différentes applications métiers. LeShop.ch demande : ▪ La mise en place d’une infrastructure de stockage centralisée des Logs générés par les services d’OpenStack ▪ L’entreposage de manière durable au sein d’une base de données (DB) dédiée aux Logs ▪ La mise en place d’un moyen de visualisation des Logs, afin de déceler divers problèmes ou effectuer des recherches rapides dans la base de données 2. Contraintes : La liste des contraintes : ▪ La DB stockant les Logs doit se situer sur des VMs ▪ L’accent doit être mis sur la disponibilité des données. Par conséquent, il faut que la DB soit toujours disponible malgré la perte de deux VMs ▪ Il faut scinder au maximum les rôles de chaque VM intervenant dans la chaîne de traitement des Logs. Dans le cas contraire, en regrouper une majorité au sein d’une VM, va charger à 100% sa RAM et son CPU et risque de faire crasher ses services ▪ La suite d’outils développée en JAVA donc veiller à optimiser la Java Virtual Machine ▪ Travailler en temps réel, du fait que les Logs affluent continuellement ▪ Intégrer au maximum des éléments de HA en essayant de dupliquer au maximum les services. Comme ils sont installés sur des VMs, le fait de les dupliquer ne demande pas de ressources physiques supplémentaires 3. Variantes de stockage de Logs : Pour mettre ces variantes sur pieds j’ai suivi ce très bon lien proposé par le CERN : http://indico.cern.ch/getFile.py/access?contribId=57&sessionId=1&resId=0&materialId=sli des&confId=220443 Quatre variantes vont être étudiées, qui vont se baser sur ces éléments communs :
  • 118.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 96 ▪ DB ElasticSearch: DB Clés-Valeurs qui stockera les Logs ▪ Serveur physique stockant les Logs : envoyés par les différents services OpenStack grâce au protocole Syslog, de manière temporaire, avant de les envoyer à la DB. Le fonctionnement du serveur sera développé dans la variante 1 ▪ Outil de visualisation des Logs : Kibana: Se matérialise par un serveur Web s’exécutant du côté de l’administrateur désirant avoir une vue d’ensemble des Logs dans le but de rechercher quels services génèrent des Logs d’erreurs 3.1 Variante 1 : Stockage des Logs sous forme de fichiers : Cette variante vise à mettre en place un serveur physique de Logs sous forme de fichier. Les différents services d’une distribution vont écrire dans un fichier tous leurs événements. Les services ont la possibilité d’être plus ou moins prolixe, nous avons le mode Debug, où un maximum d’informations sera stocké dans les Logs. Mais il est très utile pour analyser le comportement d’un service, et analyser quels messages il reçoit ou envoie. De base, chaque fichier de Logs des services est hébergé en local sur la machine physique qui l’exécute. Cette architecture ne permet pas une analyse aisée car il faut se connecter sur chaque machine physique pour interroger les Logs en local. Donc il faut absolument mettre en place une architecture qui centralise les Logs. L’infrastructure est la même qu’en §2.1, mais un PC qui va héberger les Logs de tous les services a été ajouté. Schéma 5.10 : Récolte des Logs en un point central A travers le schéma 5.10, nous avons tous les services OpenStack qui envoient leurs Logs via le client Syslog-ng au serveur de Log. Syslog-ng est un package Open Source qui regroupe les fonctions client-serveur en ce qui concerne l’envoie des Logs via le protocole Syslog. Chaque client va établir une connexion avec le serveur Syslog afin de lui envoyer les Logs des services qu’il héberge. Et ensuite le serveur va stocker en local, les différents Logs en les séparant dans différents fichiers en fonction des règles de filtrages que j’ai construites.
  • 119.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 97 ▪ Les Logs des services OpenStack : Chaque service Openstack stocke ces Logs en local sur la machine physique qui l’héberge. Voici un exemple de Log généré par le service Nova-Network stocké dans /var/log/nova/nova.conf du Network Node: La majorité des Logs sont des messages AMQP à cause de l’activation du mode Debug. ▪ Problématique de la provenance des Logs : Comme nous avons pu le voir dans l’exemple du message précédent, en voyant uniquement cette ligne nous ne savons pas par quel service a généré cette ligne, excepté en faisant la commande : nano /var/log/nova/network.log sur le Network Node. Ceci est un problème car sur le Serveur de Log, il serait intéressant de répartir les Logs au sein de différents fichiers propres à chaque service et répartis dans différents dossiers correspondants à chaque entité physique. Voici un exemple de configuration que nous aimerions avoir sur notre Serveur de Logs. Serveur Log Pour cela les clients Syslog ne vont pas parcourir les différents fichiers de chaque service, ils vont interroger et envoyer les lignes s’ajoutant au fichier /var/log/messages. J’ai choisi d’envoyer les lignes qui s’ajoutent dans ce fichier car les éléments qui s’y inscrivent possèdent un formatage plus simple à extraire. Voici un extrait du /var/log/messages/ du Network-Node :
  • 120.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 98 Comme nous pouvons le voir, les lignes générées dans ce fichier centralisent les Logs de tous les services indexant leur journal d’événement. De plus le formatage des lignes est généré en suivant le standard proposé par la RFC3164. Le message est constitué d’un HEADER : ▪ Dec 1 03:27:37 : Timestamp, à quelle date et heure a été généré le message ▪ Network : La machine physique qui a généré le message ▪ Nova-network [10131] : Le nom du processus avec son numéro de PID qui a généré cette ligne Au final, les Logs sont centralisés sur notre serveur de Logs, mais sous la forme de fichier. A ce stade, pour analyser le comportement des services OpenStack, nous sommes toujours limités par la lisibilité des Logs. Pour ce faire, l’idéal serait de pouvoir les interroger depuis une interface Web. De plus le stockage des Logs sous forme de fichiers est un grand consommateur d’espace disque. 3.2 Variante 2 : Logstash-­‐> ElasticSearch : Schéma 5.11 : Producteurs de logs -> Consommateurs Le schéma 5.11 représente la chaîne de traitement qui va acheminer les Logs contenus sous forme de fichier jusqu’à une DB dédiée à ce stockage. Cette variante permet :
  • 121.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 99 ▪ La récolte des Logs sous forme de fichiers grâce au protocole Syslog des différents PC gérant l’infrastructure OpenStack au sein du serveur de Logs. (Voir variante 1 §1.3) ▪ La conversion des Logs grâce à Logstash (Exécuté sur serveur de Logs): Pour centraliser les Logs dans la base de données, nous ne pouvons pas les garder sous forme de fichiers, car ceci consommerait trop de ressources CPU de parcourir tous ces fichiers de Logs au moment où nous faisons des requêtes d’extractions. Pour cela nous devons utiliser un outil écrit en JAVA qui va transformer les Logs bruts (ligne d’un fichier) en Objet JSON afin de les envoyer à notre DB en http (voir Annexe A.4 pour une explication des objets JSON). Exemple d’un objet JSON transformer à partir d’une ligne de Log: Remarque: Lien détaillant la structure des Logs de HAProxy: http://www.exceliance.fr/sites/default/files/biblio/aloha_load_balancer_memo_log.pdf Cet outil, Logstash a besoin d’un fichier de configuration qui regroupe les filtres que j’ai a dû créer manuellement dans le but d’obtenir un template pour découper notre ligne de Log en un objet JSON. Voici un exemple d’un fichier de configuration de Logstash : https://github.com/hepiatelecomlabs/Openstack_Config/blob/master/Object_config/HA/Rsysl og_serv/Logstash/config_els.conf Chaque Log est représenté par un Objet comportant des champs facilitant le classement au sein de la DB et permettra des recherches plus fines avec notre outil de visualisation des Logs. ▪ La DB ElasticSearch : ElasticSearch est une DB permettant le stockage de données de types JSON, la particularité de ce gestionnaire de documents est le fait de traiter l’entrée de données en temps réel. La DB va recevoir les Logs de Logstash, pour les entreposer. Pour la consultation, elle va recevoir des requêtes via son API, et va retourner au client les différents objets JSON concernés par sa requête. La DB est hébergée sur des VMs ce qui permet d’augmenter facilement la taille de notre Cluster sans rajouter d’éléments physiques.
  • 122.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 100 Schéma 5.12 : Cluster ElasticSearch Voici le cœur du stockage, nous retrouvons trois types de VMs : o VM-Els-Indexer : Ne possède aucune unité de stockage au niveau de la vue du Cluster, mais doit estampiller avec un ID chaque Objet JSON pour qu’ils puissent être classés dans les VMs de stockages. o VM-Els-0.3 : Hébergent les Objets JSON en effectuant en permanence des réplications pour maintenir une consistance des données au sein du Cluster. o VM-Els-Out : Reçoit les requêtes depuis Internet pour transmettre les Logs à l’outil de visualisation. Ce cloisonnement de rôle a été mis en place pour étaler au maximum les charges CPU et RAM, et également faciliter l’expansion du Cluster. ▪ Exploitation des Logs :
  • 123.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 101 Le serveur Web Kibana s’exécutant sur le PC local de l’administrateur peut interroger la DB afin de récupérer les Logs. A l’aide des outils fournis par Kibana, il est possible d’afficher ces derniers sous la forme de graphiques (histogrammes et camembert) afin de détecter d’éventuelles erreurs. Cette interface GUI est entièrement personnalisable du fait que l’on choisit de générer ces graphiques en fonction des clés des Objets JSON. Voici les différents graphiques que l’on peut générer avec Kibana : Figure 5.10 : Graphiques générés par Kibana La particularité de ce serveur Web ne va pas s’exécuter sur le Cluster mais sur le poste de l’administrateur, déchargeant ainsi le Cluster de la gestion des templates html. Schéma 5.13 : Récupération des Logs avec Kibana
  • 124.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 102 Comme nous le voyons sur le schéma 5.13, toute la gestion du template du serveur Web est gérée local, s’exécutant sur le poste de l’administrateur. Le serveur dialogue avec la DB ElasticSearch uniquement pour récupérer les objets JSON. En utilisant l’inspecteur réseau intégrer au Browser Firefox, nous voyons bien le chargement du template en local et la récupération des Objets JSON distant : Figure 5.11 : Chargement des JSON distants Au final, cette variante permet de stocker nos Logs de manière centralisée dans une DB pouvant être toujours opérationnelle malgré la perte de deux VMs de stockage. De plus, l’utilisation de Kibana permet de ressortir les Logs en vue d’analyse de comportement de notre infrastructure. 3.3 Variante3 : Logstash-­‐> Redis -­‐> Logstash -­‐>ElasticSearch : Sachant que les Logs inscrits dans les fichiers .log du serveur Physique de Logs arrivent plus vite qu’ils ne sortent vers la DB ElasticSearch, Logstash est obligé de les buffériser en interne, mais ses performances de ce domaine sont plus que médiocre. Par conséquent, cette deuxième variante va intégrer un élément supplémentaire servant de Buffer de Logs (VM- Buffer), qui sera géré par l’outil Redis. La grande force de cet outil est de stocker les Objets JSON dans la RAM, ce qui le rend très performant dans la mise en mémoire des Objets envoyés par Logstash. Schéma 5.14 : Mémoire tampon de Logs Le fonctionnement de Logstash dans le Serveur Physique de Logs a toujours la même fonctionnalité que précédemment, mais il maintient une connexion TCP avec le Buffer Redis, afin de lui envoyer les Logs transformés à la volée.
  • 125.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 103 Un deuxième Logstash est installé sur cette VM, il va être utilisé uniquement pour envoyer les objets JSON à ElasticSearch. Nous avons la présence de deux VMs Buffer pour créer de la redondance afin que le flow de Logs ne soit pas interrompu. Si la connexion TCP tombe avec le premier il bascule sur la 2ème VM-Buffer. La communication entre le Logstash des VM-Buffer et ElasticSearch se fait par Multicast donc contrairement à la variante 2, il n’a plus besoin de dialoguer avec la VMIndexer. Cette topologie permet d’intégrer les Logstash des VM-Buffer comme un nœud du Cluster, les Logs peuvent être alors envoyés à n’importe quelle VM-Data, et par conséquent nous n’avons plus de « point of failure »: Schéma 5.15: Cluster ELS variante 2 3.4 Variante 4 : Abolition du serveur de Logs physique : Cette variante a pour but de supprimer le serveur physique de Logs, et d’installer Logstash sur chaque serveur physique. Chaque serveur physique gérant l’infrastructure communiquerait avec les deux VMs Buffer pour leurs envoyer les Logs sous format JSON. 3.5 Comparaison des quatre variantes et choix : ▪ Bilan Variante 1 : Cette variante a permis de centraliser les Logs de tous les éléments de l’infrastructure OpenStack au sein d’un même serveur. Mais elle ne remplit pas pleinement le cahier des charges car les logs sous forme de fichiers sont impossibles à exploiter. ▪ Bilan Variante 2 : Cette variante a pour but de mettre en place une gestion des Logs avec les éléments essentiels qui sont : o La récupération des Logs o La conversion o Le stockage
  • 126.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 104 o La visualisation des Logs de manière à effectuer des recherches d’aides à la décision  Points Positifs : o Remplit le cahier des charges dans la majorité des points o Bonne séparation des tâches pour l’acheminement des Logs o Kibana permet de faire du regroupement de données, pour que l’administrateur qui consulte ces Logs puissent faire ressortir les informations qui lui semblent pertinentes  Points Négatifs : o Le goulet d’étranglement est le buffer géré par Logstash o La disponibilité n’est pas vraiment au rendez-vous entre Logstash et ELS. Du fait que Logstash ne communique qu’avec un seul point de la DB ElasticSearch en http. Notre serveur physique de Logs est également un élément sensible ▪ Bilan Variante 3 :  Points Positifs : o On décharge le buffer de Logstash du serveur physique et donc un gain de performance o De par la présence de deux VMs Buffer, nous augmentons la HA. o Les Logstasch des VM-Buffer sont considérés comme un nœud du Cluster (inutilité de la VM-Indexer)  Points Négatifs :  Présence de notre serveur physique récupérant les Logs ▪ Bilan Variante 4  Point Positif : o Abolition du serveur physique qui centralise les Logs, ce sont les producteurs de Logs qui hébergent chacun un Logstash  Points négatifs : o Comme Logstash est un service JAVA, il a besoin de la Java Virtual Machine pour s’exécuter. Cette JVM peut vite devenir très gourmande en ressource. Il faut absolument dimensionner correctement la JVM, qui n’est pas une tâche facile o Comme Logstash a besoin d’un fichier de configuration qui contient les règles de transformations des lignes de Logs en objets JSON, il faudra veiller à ce que tous les Logstash aient le bon fichier de configuration, ce qui rajoute une couche supplémentaire de contrôle
  • 127.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 105 3.6 Choix de la variante : Suite aux différents points évoqués, je préconise comme système de gestion des Logs la variante n°3 (§3.3). Même si le « Point of Failure » est le serveur physique de Logs, nous n’encombrons pas les Producteurs de Logs avec le service Logstash qui peut vite s’avérer gourmand en ressource. Grâce à cette variante les Logs sont également dans une DB gérant les réplications des données au sein de son Cluster, afin de pouvoir survivre à la perte de deux VM- Els. Comme nous sommes dans un univers virtualisé, il est aisé de rajouter des VMs afin d’augmenter nos capacités de stockages. 4. Supervision des ressources physiques : Le but de ce stockage de Logs, a été de générer de la charge au sein de mes différentes VMs grâce à l’important volume que produisent les services OpenStack en mode Debug. J’ai mis en place la variante n°2, ma DB ElasticSearch est composé de  4 VM-ELS-Node (VM-Data), 1 VM-Els-Indexer et 1 VM-Els-Out: o 1 vCPU o 1024 MB de RAM o 20 GB de disque virtuel Au sein des VM-Data, j’ai appliqué une réplication de deux, c’est-à-dire pour une donnée inscrite sur un nœud, elle va être répliqué sur deux autres nœuds. Donc au niveau de la disponibilité de la DB, on peut perdre jusqu’à deux nœuds pour toujours garder la consistance des données. Grâce à un plugin GUI intégré à la DB ElasticSearch, j’ai pu voir le nombre d’objets JSON enregistrait pendant 24h. Il faut savoir que Logstash va affilier ces objets JSON à un index, et cet index change toutes les 24 heures. Voici un aperçu de l’interface GUI : Figure5.12 : Aperçu du Cluster
  • 128.
    CHAPITRE 5 :Branche Fonctionnelle : Analyse et Spécification des Besoins 106 Nous voyons à gauche la liste de tous les nœuds du Cluster ElasticSearch, et les 4 VM- Data ont à droite les parties de données qu’elle possède. Attardons-nous maintenant sur les chiffres : rien que le 21 janvier entre 00h et 23 :59, les services OpenStack ont généré environ 6'400'000 lignes de Logs ou Objet JSON, ce qui représente 4.73GB, mais avec le répliqua de deux, ces Logs occupent au sein du Cluster 14.2GB. Sachant qu’il n’y a que 4 VMs de Data, je peux stocker un peu moins de 80GB, c’est- à-dire environ 5 jours et demi de Logs. A travers ces chiffres, le stockage peut vite devenir problématique, car ma « petite » infrastructure, génère déjà 14.2GB/Jour de Logs avec la réplication, pour conserver une année de Logs il faudrait 5TB, ce qui est infime face au volume généré par les services Web au sein de LeShop.ch. Au niveau de la vitesse de génération de Logs, ceci représente environ 4'500 Objets JSON/Minute. Malgré cette charge importante au sein des VMs, il est toujours possible de démarrer de nouvelles VMs, et les services OpenStack sont toujours disponibles. 5. Problèmes rencontrés : J’ai passé beaucoup de temps à travailler sur les formatages des Logs afin que Logstash puisse créer des objets JSON standards quel que soit le service OpenStack générant les Logs. Un problème topologique au niveau du réseau s’est posé. Comme illustré dans mes différents schémas d’infrastructure, les VMs possèdent leur propre réseau (LAN Orange), qui est physiquement séparé du réseau administratif (LAN Bleu). Pour faire remonter les objets JSON de Logstash vers ElasticSearch situé sur une VM, j’ai installé une seconde carte réseau à mon serveur de Logs, pour qu’il puisse se connecter au réseau privé des VMs. Ceci n’est pas recommandé dans la pratique, je le fais uniquement pour générer du trafic au sein des VMs. 6. Bilan du scénario 3 : A travers ce scénario, j’ai pu étudier et mettre en place une réelle stratégie de gestion de Logs, avec l’intégration d’un système de recherche performant. Ce scénario s’adapte parfaitement à un environnement virtualisé, où le maître mot est la « scalability ». Si nous voyons notre Cluster devenir trop faible au niveau stockage, nous pouvons ajouter une nouvelle VM facilement. Ce sont les ressources telles que les VMs qui s’adaptent à la demande, grâce à ce type de gestion, nous ne sommes jamais dans des cas extrêmes de sous-dimensionnement ou surdimensionnement.
  • 129.
  • 130.
    CHAPITRE 6 :Supervision des ressources avec Shinken 107 A travers ce scénario, j’ai ajouté à mon serveur de Log une fonction de supervision grâce à l’outil Shinken. Ce scénario ne va pas vous faire découvrir le fonctionnement de l’outil Shinken, mais comment j’ai monitoré la HA des API OpenStack. Le Projet d’Approfondissement de Master de M. Lionel Schaub propose une vue détaillée des possibilités qu’offre Shinken : http://www.tdeig.ch/shinken/Schaub_RPA.pdf 1. But du scénario : Le but de ce scénario est de monitorer la HA que j’ai mise en place au cours des scénarios précédents. Je vais également monitorer les ressources physiques tels que la quantité de RAM utilisée de mes deux Controller ainsi que de mon Compute-Node. La page de mon dépôt GitHub à propos des différents fichiers de configuration que j’ai utilisés pour configurer les services et les hôtes se trouvent: https://github.com/hepiatelecom- labs/Openstack_Config/tree/master/Object_config/HA/Rsyslog_serv/Shinken 2.Schéma de principe : Schéma 6.1 : Monitoring des API et serveurs physiques 3. Supervision des services d'APl OpenStack : Dans Shinken, j’ai créé deux types de tests http : 1) Http sur l’IP physique : Teste le service en l’interrogeant directement sur l’adresse IP d’un des deux Controller (10.2.4.101 et 10.2.4.106). 2) Http sur Virtual IP : Teste le service mais en passant par HAProxy en envoyant une requête sur l’adresse IP Virtuelle, donc le paquet sera aiguillé sur l’un ou l’autre Controller
  • 131.
    CHAPITRE 6 :Supervision des ressources avec Shinken 108 En testant les API via leur adresse IP virtuelle, même si par exemple le service de l’interface Web est inactif sur le Controller1, le service Web dans sa globalité est toujours en fonction car il sera redirigé vers l’autre Controller. Etat du Système où tous les services OpenStack sont actifs: Figure 6.1: Infrastructure opérationnelle Voici la situation où le service Horizon est inactif sur le Controller1 : Figure 6.2: Fonctionnement de la HA malgré un des deux Horizon Down
  • 132.
    CHAPITRE 6 :Supervision des ressources avec Shinken 109 Nous voyons que l’interface Horizon est toujours disponible pour l’administrateur qui l’interroge via l’IP virtuelle. Grâce à ce procédé, je peux contrôler le fonctionnement de ma HA. 3.1 Problème au niveau des tests via l'IP Virtuelle : J’ai rencontré un problème lorsque mes deux services horizons étaient inactifs sur les deux Controllers. Le test au niveau du ClusterAPI indiquait que le service horizon était actif, car j’utilisais uniquement la commande check_tcp. Comme HAProxy en cas d’indisponibilité de service renvoie une réponse http avec un code 503 (Service indisponible), le check_tcp de Shinken restait à OK, car il arrivait à établir une liaison TCP avec HAProxy. Par conséquent, il a fallu que j’utilise le test check_http, pour qu’il puisse détecter les différentes réponses http. Voici la réponse en faisant un « Curl » sur HAProxy en cas d’indisponibilité des deux services sur les deux Controllers : 4.Supervision des ressources physiques : J’utilise Shinken non plus pour tester la disponibilité d’une API, mais pour remonter les informations de charge CPU, la quantité d’espace disque utilisée et la quantité de RAM utilisée. Pour cela, Shinken va se connecter en ssh au différentes machines physiques afin d’exécuter des commandes qui nous retourne ces différentes informations. Comme par exemple, la charge CPU est obtenue en faisant : Cat /proc/loadavg 0.21 0.15 0.10 -> Retourne la moyenne de la charge sur 1 minute, 5 minutes et 15 minutes1 . Grâce à ces différents tests, nous pouvons fixer des alertes au moment où le système devient trop critique. 1 Vmwarevsphare. http://www.arumtec.net/fr/outils-virtualisation/outils-devirtualisation/ vmware- vsphere-4.1/presentation-de-vmware-vsphere-4.1.
  • 133.
    CHAPITRE 6 :Supervision des ressources avec Shinken 110 Par exemple, au moment où je crée 10 VMs qui vont démarrer en même temps sur le Compute Node, Shinken passe la charge CPU en critique : Ces plugins de récupération de charges développées par M. Sébastien Pasche et M. Jean Gabes (Fondateur de Shinken), permettent de s’affranchir de différents agents (nrpe) installés sur les machines testées. Cet agent va recevoir les commandes envoyées par Shinken et les exécuter en local. Toutefois ceci nécessite de rajouter un programme sur les différentes machines physiques, tandis qu’avec ssh on utilise un protocole de communication déjà employé à travers mon infrastructure. 5.Mise en place de tests interdépendants : Précédemment, j’ai mis en place deux types tests : le premier teste la disponibilité des API et le second teste les ressources physiques. A l’heure actuelle, les tests que fait Shinken sont indépendants les uns des autres. Il serait intéressant d’effectuer des successions de tests pour desseller à quel niveau se situerait le problème. Par manque de temps, j’ai uniquement fait une analyse théorique des tests imbriqués. Par exemple, si le Serveur d’API du Controller 2 ne répond pas au check_http et le check RAM indique une erreur critique. On pourrait immédiatement savoir que le problème se trouve au niveau du serveur et que le problème réseau est à écarter, car un processus utilise toute la RAM. Grâce à ce type de tests interdépendants, en fonction du type d’erreur que Shinken remonte, il pourrait avertir soit la personne gérant le réseau, soit la personne en charge de la gestion des serveurs. 5.1 Finalité du test : Comme nous l’avons vu tout au long de ce projet, OpenStack est constitué d’une multitude de services dédiés à la gestion de l’infrastructure. Pour avoir une vue d’ensemble des services opérationnels, Shinken va monitorer grâce à une suite de tests dépendants, les éléments intervenant dans le démarrage d’une VM2 . Au final, nous devons être capable de savoir si notre infrastructure pourra :  Recevoir les commandes envoyées par l’administrateur : o Tester si les API répondent aux requêtes http via l’IP virtuelle. Ce test est critique, car s’il y a une erreur, ceci veut dire que les deux Controllers sont en échec. o Tester sans passer par l’IP Virtuelle, si l’un des deux Controllers ne répond pas, ceci est moins critique grâce à la HA mise en place.  Tester les ressources physiques de chaque serveur : o Le degré de gravité change pour les types de serveurs. Un Compute Node sera plus chargé, que les deux Controllers. Par conséquent, si les Controller sont surchargés, il faudra y porter plus d’importance, car normalement ils n’hébergent que des services d’API peu gourmands en ressources. 2 Xen. http://www.xen.org/.
  • 134.
    CHAPITRE 6 :Supervision des ressources avec Shinken 111  Tester si l’on peut écrire dans la DB MySQL.  Tester si les différents services OpenStack sont démarrés. Au final, nous devons être capable de tester toute la chaîne qui s’exécute au moment où l’administrateur décide de démarrer une VM. Le schéma 27 représente la chaîne de tests que Shinken va effectuer afin de détecter la moindre erreur ou panne intervenant dans l’infrastructure. Schéma 6.2: Diagrammes de tests Shinken Les tests s’effectuant dans la zone rouge sont critiques, si l’un d’entre eux échoue, aucune VM ne pourra être démarrée. Les tests dans la zone jaune sont moins critiques, mais, peuvent quand même présenter une anomalie. Prenons le test n°1, le « Check_Load Tous les commute Node » indique une erreur si tous les Compute Node sont chargés à 100%, ceci est important car plus aucune VM supplémentaire ne pourrait démarrer. Tandis que si un Compute Node est chargé à 100%, les VMs pourront toujours être démarrées sur le deuxième. 5.2 Plugin de démarrage d’une VM intégré à Shinken : Pour rendre notre système de supervision le plus complet possible, il serait intéressant de développer un plugin, afin que Shinken puisse simuler le comportement de l’administrateur en démarrant une VM et vérifier qu’elle est bien active3 . En intégrant ce test avec les tests du schéma 27, il sera alors possible de superviser tous les services de cette infrastructure en vue 3 Xen. http://wiki.xen.org/.
  • 135.
    CHAPITRE 6 :Supervision des ressources avec Shinken 112 de déceler les moindres changements comportementaux du système. La chaîne de lancement du plugin va se dérouler comme suit: 1. Démarrer une VM avec le client python d’OpenStack 2. Attendre 5 secondes que la VM reçoive une IP 3. Récupérer l’IP de cette VM en interrogeant le fichier du serveur DHCP sur le Network Node contenant la corrélation : MAC, Nom_VM, IP 4. Au bout d’une dizaine de secondes, se connecter en ssh à la VM et effectuer un Ping sur un serveur distant. A travers ces deux tests, nous contrôlons si nous la VM est accessible par ssh et si le Network Node aiguille correctement les paquets du réseau privé vers le réseau public. 5. Détruire la VM grâce au client python, et regarder sur le QNAP que le disque virtuel sous forme de fichier est bien supprimé 6. Si l’ensemble des tests est OK, l’infrastructure OpenStack est fonctionnelle 6.Bilan du scénario : Avec une telle infrastructure, constituée de nombreux services répartis sur plusieurs serveurs physiques, il est essentiel de mettre sur pieds un élément de supervision, afin de remonter les différentes erreurs. Ce système va permettre d’anticiper d’éventuelles pannes critiques qui rendraient l’infrastructure inutilisable. Pour effectuer ces différents tests, il est nécessaire de connaître le comportement des différents services. Le fait d’intégrer de la HA, dédouble le nombre de serveurs physiques, ce qui va augmenter le nombre de tests. Par conséquent, il va être essentiel de prioriser les tests grâce aux dépendances, afin de ressortir des erreurs pertinentes.
  • 136.
    113 Conclusion Générale Le cloudcomputing est un domaine en plein essor qui répond un grand nombre de besoins des entreprises. L'investissement dans ce domaine attire donc de plus en plus les ingénieurs réseaux qui ne cessent de proposer des solutions de Cloud variées en qualité de service liable et rentable. Ce projet de fin d’études, proposé pour but de mettre en place une plateforme de virtualisation et le déploiement d’une solution Cloud OpenStack. Notre plateforme est composé d’une couche de virtualisation VMware dans laquelle les différentes machines virtuelles créées et déployées pour garantir la fiabilité et l’efficacité du système d’information et d’une plateforme du Cloud privé IaaS basé sur OpenStack. Choisir une solution dont la communauté est trop faible. Dont le développement est presque nul ou dont la documentation serait proche du néant pourrait mener le projet à l'échec avant la production (avec de la chance) ou imposer d'importantes difficulté pouvant aller de l'instabilité de la plateforme jusqu'à l‘obligations de changer l'infrastructure complète. en production. II s'impose alors l’analyser ces caractéristiques. A court terme et en se basant sur l'étude technique réalisée sur le Cloud Computing, nous pourrons mettre en place un environnement Cloud si les contraintes matérielles seront relaxées. Ceci nous permettra l'utilisation de notre propre environnement pour mener à terme nos expérimentations à tous les niveaux du Cloud. L'élaboration de ce projet nous a permis de concrétiser et d'approfondir nos connaissances particulièrement dans les domaines de la virtualisation et de cloud Computing.
  • 137.
    114 Bibliographie : Chapitre 2: [1] Alain-B. TCHANA .Système d'Administration Autonome Adaptable: application au Cloud, novembre 2011 [2] Bhaskar Prasad Rimal, Eunmi Choi, and Ian Lumb. A taxonomy and survey of cloud computing systems. In Proceedings of the 2009 Fifth International Joint Conference on INC, IMS and IDC, NCM '09, pages 44_51, Washington, DC, USA, 2009. IEEE Computer Society. [3] EuroCloud France. L'évolution maitrisée vers le IaaS/PaaS. novembre 2011 [4] Ignacio M. LlorenteBorja Sotomayor, Ruben S. Montero and Ian Foster. [5] JunjiePeng, Xuejun Zhang, Zhou Lei, Bofeng Zhang, Wu Zhang, and Qing Li. Comparison of several cloud computing platforms. In Proceedings of the 2009 Second International Symposium on Information Science and Engineering, ISISE '09, pages 23_27, Washington, DC, USA, 2009. IEEE Computer Society. CHAPITRE 3 : [1] le cloud computing une nouvelle filière fortement structurante, septembre2012 [2] Marvin Rambhadjan and Arthur Schutijser. SURFnet cloud computing solutions. [3] Peter Sempolinski and Douglas Thain. A comparison and critique of eucalyptus, opennebula and nimbus. In Proceedings of the 2010 IEEE Second International Conference on Cloud Computing Technology and Science, CLOUDCOM '10, pages 417_426, Washington, DC, USA, 2010. IEEE Computer Society. [4] ThiagoDamascenoCordeiro, Douglas BritoDamalio, NadilmaCintra [5] Vivansas.p.r.l.Cloud Computing Enjeux, Perspectives et Impacts métiers, septempre 2009 [6] WygwanLe Cloud Computing : Réelle révolution ou simple évolution ? Webographie [7] Abicloud. http://community.abiquo.com/. [8] Amazon web srrvice. http://aws.amazon.com/fr/. [9] Eucalyptus. http://www.eucalyptus.com/. CHAPITRE 4 : [1] Microsoft. http://www.microsoft.com/. [2] Microsoft. Windows azure http://www.microsoft.com/windowsazure/. [3] Microsoft hyperv. http://www.microsoft.com/hyper-v-server/en/us/default.aspx. [4] Nimbus. http://www.nimbusproject.org/.
  • 138.
    115 CHAPITRE 5 : [1]Openstack. http://www.openstack.org/. [2] Opennebula. http://opennebula.org/. [3] redhat. http://www.redhat.com/products/cloud-computing/cloudforms/. [4] Salesforce. http://www.salesforce.com/fr/. CHAPITRE 6 : [1] Vmwarevsphare. http://www.arumtec.net/fr/outils-virtualisation/outils-devirtualisation/ vmware-vsphere-4.1/presentation-de-vmware-vsphere-4.1. [2] Xen. http://www.xen.org/. [3] Xen. http://wiki.xen.org/.
  • 139.
    Liste des abréviations: SONATRACH : Société National pour la recherche, Transport, production, transformation, la commercialisation des hydrocarbures ERDP : l’entreprise nationale de raffinage et de distribution de produits pétroliers UND : Unité NAFTAL de Distribution SPA : société par action NAFTAL : Entreprise nationale de commercialisation et de distribution de produits pétroliers CLP : Carburants Lubrifiants et Pneumatiques BIU : les bordereaux inter unités ING : Service Informations de Gestion AMG : administration et moyen généraux GPL : gaz de pétrole liquéfié IBM : International Business Machines BSD : Berkeley Software Distribution PUE : Power usage effectiveness SOA : Service Oriented Architecture IaaS : Infrastructure as a service PaaS : Plateforme as a Service Saas : Software as a service VPN : virtual private network CLC : contrôleur de cloud CC : cluster controller VM : machines virtuelles OS : Operating System (systèmes d'exploitation)
  • 140.
    ESXI : ElasticSky X Integrated HA : High Availability (haute disponibilité) VDA : Virtual Delivery Agent PVS : Provisioning Services DMZ : demilitarized zone (zone démilitarisée) VPX : Virtual Provisioning X CLI : Command Line Interface XML : eXtensible Markup Language EC2 : Elastic Compute Cloud CPU : Central processing unit API : Application Programming Interface NAS : Network Attached Storage SAN : Storage Area Network DAS : Direct Attached Storage NFS : Network File System SMB : Server Message Block CIFS : Common Internet File System AFP : Apple Filing Protocol IP : Internet Protocol TCP : Transmission Control Protocol SCSI : Small Computer System Interface SLA : Service Level Agrement SRDF : Symmetrix Remote Data Facility BCV : Business Copy Volume QNAP : Quality Network Appliance Provider RHEL : Red Hat Entreprise Linux KVM : Kernel-Based Virtual Machine
  • 141.
    REST : RepresentationalState Transfer AMQP : Advanced Message Queuing Protocol RPC : Remote procedure call DHCP : Dynamic Host Configuration Protocol VRRP : Virtual Router Redundancy Protocol