CASSIOPEIA. CLOUD Application Supplying Secure Infrastructures Over Pre- Existing Intranet Architecture. Proyecto de Grado - Georges Chaudy

CASSIOPEIA CLOUD Application Supplying Secure Infrastructures Over Pre- Existing Intranet Architecture Proyecto de Grado - Georges Chaudy Universidad de los Andes Facultad de Ingeneria DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C. JUNIO 2012 1

CASSIOPEIA CLOUD Application Supplying Secure Infrastructures Over Pre- Existing Intranet Architecture Proyecto de Grado - Georges Chaudy Proyecto de grado presentado al departamento de Ingeniero de Sistemas y computación de la Universidad de Los Andes Director: PhD. Claudia Lucia Jiménez Guarín Profesora Asociada Universidad de los Andes Facultad de Ingeneria DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C. JUNIO 2012 2

Table des matières 1 Synthèse... 6 2 Introduction... 6 2.1 Les systèmes distribués et ses outils... 6 2.2 Les contraintes associées aux systèmes distribués... 7 2.3 Description du problème... 8 3 Antécédents et contexte... 8 3.1 MAGOS et son histoire... 8 3.2 MAGOS CLOUD SECURE en quelques lignes... 9 3.3 Les points fort de MAGOS CLOUD SECURE... 11 3.3.1 Infrastructure As A Service... 11 3.3.2 Un système déclaratif... 11 3.3.3 Virtualisation au cœur de MAGOS CLOUD SECURE... 11 3.3.4 Opportunisme... 12 3.3.5 La tolérance à l'erreur... 12 3.3.6 Sécurité... 12 3.3.7 La configuration automatique des machines générées.... 13 3.4 Les faiblesses de MAGOS CLOUD SECURE... 13 3.4.1 Attribution des adresses IP... 13 3.4.2 Complexité du déploiement... 13 3.4.3 Risques de failles des serveurs... 14 3.4.4 Complexité de génération de nouvelles plateformes... 14 3.4.5 Absence de GUI... 14 3.4.6 Evolution de PUPPET... 14 3.4.7 Sécurité partielle... 15 3.5 CASSIOPEIA prend la relève... 15 4 Description générale de la solution... 16 4.1 Objectif général... 16 4.2 Objectifs spécifiques... 16 4.3 Stratégie globale... 16 4.4 Stratégies spécifiques... 16 4.4.1 Architecture réseau... 17 4.4.2 Architecture logicielle... 19 5 Architecture du système... 23 3

5.1 Cas d'utilisation... 23 5.2 Diagramme de classes... 24 5.3 Diagrammes de déploiement et composants... 25 5.3.1 Infrastructure physique... 25 5.3.2 Infrastructure virtuelle... 27 5.3.3 Diagrammes de séquence... 29 5.4 Sécurité du système... 36 5.4.1 Politique de sécurité... 36 5.4.2 Mécanismes de sécurité... 37 6 Implémentation... 38 6.1.1 Langage Ruby... 38 6.1.2 Ruby on Rails... 39 6.1.3 EnvironnementsCASSIOPEIA... 39 6.1.4 Gestionnaire de version... 40 6.1.5 Versions des logiciels... 40 7 Validation et résultats... 40 8 Conclusion et travaux ultérieurs... 41 9 Bibliographie... 42 4

Table des illustrations : Figure 1 Composants de MAGOS CLOUD SECURE... 9 Figure 2 Réseau Privé Virtuel N2N... 18 Figure 3 Réseau Privé Virtuel OpenVPN... 19 Figure 4 Diagramme de cas d'utilisation... 23 Figure 5 Diagramme de classe... 25 Figure 6 Diagramme de déploiement... 26 Figure 7 Diagramme de composants du serveur CASSIOPEIA... 26 Figure 8 Diagramme de composant d'un nœud CASSIOPEIA... 27 Figure 9 Diagramme de déploiement d'une machine virtuelle... 28 Figure 10 Diagramme de déploiement de l'infrastructure virtuelle... 28 Figure 11 Diagramme de séquence. Installation... 29 Figure 12 Diagramme de séquence. Gérer les utilisateurs... 31 Figure 13 CRON jobs... 32 Figure 14 Utilisation de l'api Rest de Puppet... 32 Figure 15 Diagramme de séquence. Surveillance Nagios... 33 Figure 16 Diagramme de séquence. Déployer une plateforme... 34 Figure 17 Diagramme de séquence. Déployer une application... 34 Figure 18 Communication sécurisée avec puppet... 37 Figure 19 Isolation des machines virtuelles offerte par VMware sur une machine physique... 38 5

1 Synthèse Les systèmes distribués prennent une place de plus en plus importante de par le monde. Ils permettent aux entreprises et universités le stockage et le calcul intensif, en utilisant des machines bon marché. De nombreux outils font surface dans les communautés open source facilitant la création d applications d E-Science et Web 2.0. Les applications actuelles, que ce soit dans le contexte scientifique ou industriel, doivent considérer l utilisation d infrastructures distribuées pour répondre à un nombre grandissant d utilisateurs et permettre la gestion d un volume important de données. Malheureusement, la mise en place d infrastructures distribuées est un défi difficile à relever. Les frais d achat, d entretien, de maintenance et d administration des machines s avèrent très importants. De plus, les connaissances nécessaires pour apprendre à maitriser de tels systèmes et comprendre les rouages internes sont difficiles à acquérir. Enfin, la sécurité de l infrastructure doit être en permanence assurée. CASSIOPEIA propose une solution simple afin de générer rapidement et à moindre coût des plateformes sûres, pouvant être mises à l échelle, équipées des dernières technologies en matière de systèmes répartis. CASSIOPEIA s'adresse aux chercheurs et développeurs Web désireux d'utiliser des systèmes répartis et disposant déjà d'un réseau d'ordinateurs au sein de leur entreprise ou université qu ils souhaitent rentabiliser en capitalisant l espace et le temps de calcul sous-utilisé. 2 Introduction 2.1 Les systèmes distribués et ses outils Le stockage et le traitement de grands volumes de données est au cœur de l innovation scientifique.de plus en plus, les systèmes distribués s imposent dans les entreprises et universités, permettant d augmenter de manière significative la capacité de traitement et de stockage des données, ainsi que de créer des applications destinées à un nombre croissant d utilisateurs. L apparition des réseaux sociaux marque une étape majeure dans l évolution des systèmes distribués. Les grandes entreprises comme Google, Facebook ou Amazon construisent de gigantesques data center aux quatre coins du monde afin de disposer de la puissance de calcule nécessaire pour leurs applications CLOUD. Chaque data center héberge plusieurs milliers de serveurs reliés au monde par plusieurs connections très haut débit. Les données y sont encryptées, dupliquées et protégées par plusieurs couches de sécurité. Ce type d infrastructure permet de proposer des services tels que Youtube où sont stockées chaque minute près de 60 heures de nouvelles vidéos, regardés chaque jour près de quatre milliards d enregistrements et analysésquotidiennement près de 100 ans de contenu [1]. 6

Le monde scientifique, de son côté, collabore dans des projets comme EGEE [2]afin de créer des infrastructures de type GRID et augmenter sa capacité de traitement. Ainsi, ce sont plus 15 petabytes de données générées chaque année par le LHC, l accélérateur de particules du CERN, qui sont transmis et traités dans près de 200 sites sur trois continents. [3] Les applications actuelles, que ce soit dans le contexte scientifique ou industriel, doivent considérer l utilisation d infrastructures distribuées pour répondre à un nombre grandissant d utilisateurs et permettre la gestion d un volume important de données.heureusement, de nombreux outils permettant le traitementet le stockage en parallèle sont aujourd hui disponibles dans les communautés open source. On peut distinguer deux catégories d outils principales.d'une part, les bases de données dites NoSQL, [4] qui permettent le stockage en parallèle de grands volumes de données. A la différencedes bases de données relationnelles, ces outils garantissent un temps d'accès relativement faible quelle que soit la quantité d information stockée [5]. Les données sont réparties et dupliquées surun cluster d'ordinateurs. Plus le nombre de machines composants le cluster est grand, plus la capacité de stockage du système augmente. Malheureusement, ce type d outils ne peut être transactionnel, ne pouvant offrir qu une cohérence partielle des données au profit d un temps d accès minimal. Pour citer un exemple, Cassandra, l'hériter libre du système NoSQL de Facebook est largement utilisé à travers le monde, notamment au sein d'applications Web [6]. Dans un deuxième temps, on trouve les outils permettant le traitement en parallèle des données. Hadoop [7], la version libre du File Système de Google [8], est une référence dans le domaine. Très apprécié dans le milieu de la recherche, il permet de traiter en parallèle des données sur de grands clusters de machines, tout en garantissant leur intégrité. Puissants, les outils de calcul reparti sont à la pointe de l'innovation et permettent une infinité d'applications. Méconnus, ils sont souvent substitués par des outils plus conventionnels tels que les bases de données relationnelles, moins efficaces à grande échelle. 2.2 Les contraintes associées aux systèmes distribués Les systèmes distribués peuvent être utilisés pour une infinité d usages distincts. On les retrouve souvent au cœur d application de type Web 2.0 comme les moteurs de recherche ou les réseaux sociaux. On les retrouve aussi au sein d applications d E-science, par exemple dans des applications de biologie ou de physique qui requièrent l analyse de grandes quantités de données. Bien que les systèmes répartis soient très utiles, leur mise en place est un défi souvent difficile à relever. Plusieurs facteurs empêchent les développeurs de faire le choix de ces technologies.le premier facteur limitant est bien sûrmatériel et donc financier. Le calcul distribué repose sur des clusters de machines dédiées autraitement et stockage des données. Certes, les machines nécessaires peuvent être de bon marché. En effet, les systèmes répartis disposant de mécanismes de récupération, l état global du système n est pas compromis en cas de faille. Néanmoins, les frais d'achat, de maintenance, d'administration ne peuvent pas être ignorés et restent très importants. La facture finale peut s'avérersalée. 7

Le tempset les connaissances nécessaires à la mise en place de systèmes distribués peuvent aussi être considéréscomme une limitation. En effet, les outils de calcul distribués sont récents et souvent mal documentés. Leur installation peut être complexe. Il faut d'abord configurer l environnement d'exécution, choisir le système d'exploitation, installer les dépendances, configurer les droits d'accès, tout un ensemble de petites choses qui demande de vastes connaissances. Ensuite, le temps de configuration du réseau ne doit pas être pris à la légère. L'interconnexion des machines, la définition d'une politique de nommage, l'attribution des plages d'adresses demandent de la patience. Pour finir, il faut du temps pour apprendre à maitriser le système et comprendreen détail les rouages internes. Un dernier facteur, souvent négligé, est la sécurité de l'infrastructure. Bien plus complexe qu'un système présent sur une seule machine, plusieurs niveaux de sécurité doivent être pris en compte. An niveau logiciel, il faut configurer les doits d'accès et la sécurité des communications. Au niveau de la machine, la configuration des pare-feux, des accès SSH et politique d assignation des mots de passe. Enfin, au niveau du réseau, il faut s'assurer configurer les règles de routeur et contrôler les flux de données. L'utilisation de systèmes répartis requière des connaissances transversales, ainsi qu un investissement matériel, financier et humain important. Bien que les possibilités offertes par de tels systèmes soient attrayantes, beaucoup de gens préfèrent encore se tourner vers des systèmes plus traditionnels, moins complexes, probablement car ils sont plus rassurants. 2.3 Description du problème CASSIOPEIA propose une solution simple afin de générer rapidement et à moindre coût des plateformes sûres, pouvant être mises à l échelle, équipées des dernières technologies en matière de systèmes répartis. CASSIOPEIA s'adresse aux chercheurs et développeurs Web désireux d'utiliser des systèmes répartis et disposant déjà d'un réseau d'ordinateurs, au sein de leur entreprise ou université, qu ils souhaitent rentabiliser en capitalisant l espace et le temps de calcul sous-utilisé. 3 Antécédents et contexte Le projet CASSIOPEIA est le résultat d'une longue évolution qui débutât il y a plusieurs années avec le projet MAGOS [9]. Au fil des itérations, le projet a grandipermettant d'englober un plus grand spectre d utilisateurs, tout en augmentant la fiabilité du système et sa sécurité. L'évolution des technologies associées au projet nous permet aujourd'hui de revoir l'architecture du système et de proposer une meilleureexpérience d'utilisation. 3.1 MAGOS et son histoire Le projet MAGOS (Middleware Architecture for GridOriented Services) [9]débutât avec la volonté d'offrir aux développeurs SOA une gestion facile de sur une infrastructure type GRID. L'utilisateur déclarait au moyen d un fichier XML les besoins fonctionnels qu'il attendait d'une infrastructure de 8

type GRID, définissait les flux de travail et fournissait un ensemble de fichiers à traiter. MAGOS se chargeait alors de générer l'infrastructure nécessaire à l'exécution du flot de données de l'utilisateur. Après les premières utilisations du système, l'équipe MAGOS prit conscience de nombreuses améliorations possibles, dont deux principales. Tout d'abord que les besoins des utilisateurs ne se limitaient pas à la création de flots de données, notamment dans le monde de la biologie et que MAGOS devait permettre la création de processus plus complexes. Ensuite, que beaucoup d'applications reposaient sur des sources de données autres que des fichiers, comme le Web, bases de données distribuées, capteurs. Ainsi naquit MAGOSCLOUD qui marque le changement du paradigme GRID à celui de CLOUD, MAGOSCLOUD reposant sur la virtualisation, la mutualisation des ressources et la génération d infrastructures de systèmes distribués. L'ultime version du middleware, intitulée MAGOS CLOUD SECURE, marque une évolution majeure avec l ajout de la couche d authentification des utilisateurs et les sécurisations des communications. Dans la suite de cette section, nous souhaitons analyser en détail les points forts et faiblesses de MAGOS CLOUD SECURE afin d y proposer un ensemble d améliorations. 3.2 MAGOS CLOUD SECURE en quelques lignes MAGOS CLOUD SECURE est un middleware permettant de générer et configurer des machines virtuelles sur une infrastructure d ordinateurs existante. Cette infrastructure physique est composée d un ensemble d ordinateurs qui, lorsqu ils ne sont pas utilisés, sont exploités par MAGOS CLOUD SECURE afin d héberger jusqu à deux machines virtuelles. On parle d architecture opportuniste car l application utilise les ressources inexploitées de l entreprise. Les machines physiques, pour être compatible avec MAGOS CLOUD SECURE, doivent disposer d un système d exploitation Windows, de l hyperviseur de virtualisation VMware Workstation et pouvoir exécuter des applications JAVA. Figure 1 Composants de MAGOS CLOUD SECURE 9

MAGOS CLOUD SECURE s organise autour de huit composants principaux : 3.2.1.1 PUPPET Chaque machine virtuelle est configurée par le gestionnaire de configuration PUPPET. Un client Puppet est installé sur chaque machine virtuelle. Il se connecte à un serveur Puppetconfiguré pour satisfaire les besoins de l application. PUPPET se charge d installer la configuration décrite par l utilisateur sur une machine Debian vierge. PUPPETinstalle par exemple automatiquement Java, Hadoop ou Glassfish sur la machine spécifiée. Pour savoir quelle configuration installer sur quel serveur, PUPPET communique avec le composant MCServer au moyen d un script shell appelé ExternalNode [10]. 3.2.1.2 MCNode C est une application Java exécutée sur les machines physiques Windows. Elle reçoit depuis le composant MCLoadBalancer des demandes de création de machines virtuelles. Afin de créer celles-ci, le composant génère un Link Clone [11]à partir d une machine virtuelle Debian Template. Il démarre ensuite la machine virtuelle grâce à l API de communication VMware VIX [12], lui attribue une adresse IP publique et y démarre le client PUPPET. Le composant se charge ensuite de surveiller l état de la machine physique qu il transmet au composant MCLoadBalancer. 3.2.1.3 MCInstance Cette application Java est exécutée sur les machines virtuelle Linux. Elle est pré installée, tout comme PUPPET, sur les machines virtuellestemplate Debian. Elle reçoit les demandes de mis-à-jour de la machine virtuelle en provenance du composant MCserver. Suite à une demande de mise à jour, le client Puppet est éxécuté. Le composant se charge aussi de surveiller l état de la machine virtuelle qu il transmet au composant MCLoadBalancer 3.2.1.4 MCLoadBalancer Cette application Java est exécutée sur un serveur Linux autonome. Elle reçoit les demandes de création de nouvelles plateformes depuis le composant MCServer qu elle transforme en demandes de création de machines virtuelles. L application prend en compte l occupation réelle des machines physique et leur charge de travail CPU afin de choisir celle qui est la plus apte à héberger une nouvelle machine virtuelle. Une fois la machine cible identifiée, MCLoadBalancer envoie au composant MCNodede cette dernière la demande de création de machine afin qu il procède au déploiement de la machine virtuelle. 3.2.1.5 Serveur Kerberos Le système de sécurité de MAGOS CLOUD SECURE s organise autour d un serveur Kerberos assurant la sécurité de l infrastructure à plusieurs niveaux. Il permet d abord de garantir la sécurité des communications entre chaque composant du système. Ensuite, il offre un système d authentification unique (Single Sign in) aux utilisateurs. Pour finir, il permet d associer un rôle à chaque utilisateur, d associer une liste d actions autorisées pour chaque rôle, ainsi quede vérifier que l utilisateur est en droit d effectuer une action suivant son rôle. 3.2.1.6 Serveur LDAP Ce serveur est associé au serveur Kerberos. Il est utilisé comme répertoire pour stocker les clés générées par le serveur kerberos. Ce serveur peut potentiellement être remplacé par un serveur LDAP déjà existant au sein de l entreprise. 10

3.2.1.7 Serveur DNS Ce serveur permet de stocker l association entre noms de domaines et adresse IP des machines générées par MAGOS CLOUD SECURE. 3.2.1.8 MCServer Il s agit du cœur de l application, implémentant tous les objets métier et l intelligence du système. MCServer est une application JAVA exécuté sur serveur autonome. Il fonctionne en symbiose avec le serveur Puppet, lui fournissant les informations nécessaires pour configurer les machines virtuelles de l infrastructure. 3.2.1.9 MySQL server Le serveur MySQL permet la persistance des objets métiers générés par MAGOS CLOUD SECURE. Le serveur possède un script SQL de configuration. 3.3 Les points fort de MAGOS CLOUD SECURE MAGOS CLOUD SECUREest défini par un certain nombre de caractéristiques qui font sa force. Afin de mieux comprendre ce qu'est MAGOS CLOUD SECURE, nous souhaitons les illustrer en détail cidessous. 3.3.1 Infrastructure As A Service MAGOS CLOUD SECURE est un service CLOUD permettant la génération d'infrastructures comme Service. L'utilisateur choisit dans le catalogue l infrastructure ou système distribué qu'il souhaite pour réaliser son application. Par exemple, un développeur d'applications d'e-science pourra formuler la demande d'une infrastructure Hadoop composée d'une machine maîtresse et quatre machines esclaves. MAGOS CLOUD SECURE se charge alors de la génération des cinq machines, leur assigne une adresse IP propre, déploie le système distribué Hadoop, puis remet les codes d'accès de la machine maîtresse à l'utilisateur afin qu'il y installe son application. MAGOS CLOUD SECURE permet ainsi de livrer des infrastructuresprêtes à l'emploi à ses utilisateurs. 3.3.2 Un système déclaratif MAGOS CLOUD SECURE s'adapte aux demandes des utilisateurs. En effet, chaque utilisateur et chaque application est unique. De la même manière, chaque plateforme doit être unique et correspondre au mieux à besoins fonctionnelles du système. Au moyen d'un fichier XML, l'utilisateur spécifie ses besoins et MAGOSCLOUD se charge du reste. Par exemple, dans le projet SismoMAGOS, l utilisateur installe une application d E-science spécifique au domaine de la sismologie et parallélise le traitement des données grâce au système distribué Hadoop. 3.3.3 Virtualisation au cœur de MAGOS CLOUD SECURE Afin de générer les plateformes spécifiées par l'utilisateur, MAGOS CLOUD SECUREvirtualise les machinespour plusieurs raisons. D'une part, la virtualisation permet une abstractiondumatériel physique et d'uniformiser les ressources. Ainsi, MAGOSCLOUD n'a pas à se soucier de la gestion de 11

drivers et est compatible avec toute machine supportant les outils de virtualisation. Dans un deuxième temps, la virtualisation permet de mutualiser les ressources et installer plusieurs machines virtuelles sur une même machine physique. Cela permet de garantir un usage optimal des ressources. Enfin, la virtualisation facilite la gestion du parc de machines, permettant une gestion à distance, le déplacement des machines virtuelles et bien plus encore. 3.3.4 Opportunisme L'originalité de MAGOSCLOUD est sa capacité de s'intégrer à une infrastructure physique existante. Les universités, par exemple, disposent en général d'un ensemble d'ordinateurs disponibles pour ses élèves, représentant un capital de ressourcesnon négligeable. Après une analyse détaillée de l'utilisation des ordinateurs d'une de ses salles informatiques, l'université Los Andes a conclu que seul 10% des ressources de celle-ci sont utilisées en moyenne. Les élèves étant présents en journée, réalisant non seulement des tâches de bureautique peu gourmandes comme la saisie de rapport ou la vérification d'emails, mais aussi des travaux de programmation et de modélisation bien plus consommateur en ressources. Ils conclurent qu'il serait dommage de laisser un tel capital inexploité. MAGOS CLOUD SECURE est dit opportuniste car il sonde les machines existantes et y déploie ses machines virtuelles lorsqu elles ne sont pas utilisées. Pour cela, MAGOS CLOUD SECURE utilise des hyperviseurs de niveau 2, c est-à-dire installé au-dessus d un système d exploitation comme logiciel, pour déployer ses machines virtuelles. Plus précisément, MAGOS CLOUD SECURE utilise Vmwareworkstation pour réaliser cette tâche. 3.3.5 La tolérance à l'erreur L infrastructure physique de MAGOS CLOUD étant opportuniste, il est impossible de garantir la stabilité des machines. En effet, les ordinateurs hôtes peuvent être arrêtés par mégarde, ou tout simplement être réquisitionnés par un élève ou employé de l entreprise. MAGOSse charge alors de redéployer les machines virtuelles vers une autre machine hôte afin de garantir une continuité de service. L utilisateur ne perçoit pas l indisponibilité des machines, ni lors du processus de déploiement d une infrastructure, ni lors de l exécution de son application. 3.3.6 Sécurité La sécurité est la préoccupation principale de MAGOS CLOUD SECURE. Plusieurs niveaux de sécurité ont été mis en place. D une part, l authentification des utilisateurs. Chaque utilisateur se voit attribuer un rôle et un ensemble d action autorisée. L utilisation d un système Kerberos permet d assurer cette tâche. D autre part, MAGOS CLOUD SECURE crypte les communications entre chacun de ses composants. Ce niveau de sécurité est essentiel car toutes les communications passent par l infrastructure hôte et peuvent être facilement interceptées. Pour finir, MAGOS CLOUD SECURE cherche à encrypter les communications issues des systèmes distribués générés. La communication entre plusieurs machines d un cluster Hadoop peut ainsi être sécurisée. 12

3.3.7 La configuration automatique des machines générées. La stratégie de déploiement des machines virtuelles utilisée par MAGOS CLOUD SECURE se base sur l utilisation d un gestionnaire de configuration. En effet, MAGOS CLOUD SECURE déploie des machines virtuelles contenant un système d exploitation Debian de base. Une fois fonctionnel, le gestionnaire de configuration se charge de l installation des outils définis par l utilisateur. Le travail d un développeur expert consiste donc en la traduction du processus d installation d un système réparti en langage PUPPET. Ce processus est plus ou moins simple. L installation de Cassandra, par exemple, requière l installation de Java, l extraction de l archive tar de Cassandra, la modification des fichiers de configuration et pour finir l exécution d un script de démarrage. Un simple fichier décrivant ce processus en langagepuppet permet l installation sur une nouvelle machine virtuelle. 3.4 Les faiblesses de MAGOS CLOUD SECURE Au fur et à mesure de l utilisation de MAGOS Cloud Sécure, un certain nombre de faiblesses du logiciel ont fait surface. 3.4.1 Attribution des adresses IP L attribution de l adresse IP d une machine générée par MAGOS CLOUD SECURE est réalisée à partir d une liste d adresses mises à disposition par le propriétaire de la plateforme physique. Une telle architecture possède des contraintes. Une première contrainte est liée au caractère évolutif du système. En effet, la capacité de création, ou nombre de machines virtuelles qui peuvent être créées par MAGOS CLOUD SECURE, est restreinte par le nombre d adresses publiques allouées par l administrateur. Une petite entreprise ne disposant que de deux adresses publiques ne pourra pas générer une plateforme Hadoop de 5 machines, même si elle dispose d un nombre d hôtes suffisant pour les accueillir. Bien plus grave, l attribution d une adresse publique à chaque machine entraine une vulnérabilité importante. Toute machine sera alors visible depuis le réseau local, voir depuis internet, la rendant vulnérable aux attaques non prévues par le système. 3.4.2 Complexité du déploiement Le processus de mise en service de MAGOS CLOUD SECURE est très complexe. A l heure actuelle, le déploiement de MAGOS CLOUD SECURE requière : L installation et la configuration de 8 serveurs différents : MCServer, MCBalancer, MCNode, Kerberos, LDAP, MYSQL, DNS et PUPPET server. La modification du code source : où sont inscrites les adresses des autres servers qui composent MAGOS CLOUD SECURE. 13

La version de production de MAGOS CLOUD SECURE est présente sur trois machines différentes, dont une virtuelle, rendant l identification des problèmes un véritable challenge. 3.4.3 Risques de failles des serveurs A l inverse des plateformes générées, les serveurs de MAGOS CLOUD SECURE sont vulnérables en cas de faille. Ne disposant pas de système de récupération, l arrêt d un des serveurs entraine la mise hors-service de la totalité du système. 3.4.4 Complexité de génération de nouvelles plateformes L un des points forts de MAGOS CLOUD SECURE est la possibilité de mettre de nouveaux types de plateformes à disposition des utilisateurs. Un développeur expert du système distribué Cassandra, peut ainsi décider de suivre le processus de création d un type de plateforme. Cette plateforme sera ensuite disponible pour tous les utilisateurs. Le processus de création d un type de plateforme est composé de3 étapes : Création des fichiers de configuration en langage PUPPET. Ajouts du type de plateforme dans la base de données Modification du code source de MAGOS CLOUD SECURE pour prendre en charge le nouveau type de plateforme. Une machine Hadoop Master a par exemple besoin de connaitre son facteur de réplication, ainsi que la liste des adresses et noms de ses esclaves. Les deux premières étapes requièrent une connaissance de PUPPET et de SQL, mais ne posent aucun problème particulier. La dernière étape requière une connaissance détaillée du code de MAGOS CLOUD SECURE, rendant bien complexe l ajout d un nouveau type de plateforme. 3.4.5 Absence de GUI L interface de communication existante pour ajouter des utilisateurs, déployer une plateforme, partager des ressources est constituée d un ensemble de scripts Windows et Linux. Ses scripts doivent être exécutés avec les droits appropriés, sur la bonne machine. Le besoin d une interface graphique pour centraliser les actions se fait ressentir. 3.4.6 Evolution de PUPPET PUPPET est une référence dans le domaine de la configuration automatique de machines. Depuis MAGOS CLOUD SECURE, PUPPET à connue plusieurs évolutions majeures, notamment trois importantes. Premièrement, la compatibilité avec les machines Windows. L utilisation de cette fonctionnalité permettrait de simplifier significativement le flot de communication du système. Deuxièmement, la possibilité depuis le serveur de forcer le client à se rafraichir sa configuration. Jusqu à présent, MAGOS CLOUD SECURE implémentait lui-même cette fonctionnalité en envoyant un signal de MCServer à MCBalancer, de MCBalancer à MCNode puis de MCNode à MCInstance. Enfin, 14

PUPPET dispose maintenant d'une API Web pour exécuter les commandes de base et récupérer les rapports d état des machines. 3.4.7 Sécurité partielle Plusieurs failles dans la sécurité de MAGOS CLOUD SECURE ont été identifiées. MAGOS CLOUD SECURE effectue un travail remarquable pour protéger les machines virtuelles qu il génère des attaques extérieures. Comme nous l avons vue précédemment, toute machine générée se voit attribuer une adresse IP publique et est accessible depuis le réseau extérieur. La mise en place de pare-feux et la gestion des droits d accès rendent les attaques complexes. Plus le nombre de machines virtuelles générées est grand, plus un attaquant dispose de portes d entrée potentielles. Il faut donc veiller en permanence à la mise à jour des systèmes de protection pour éviter les attaques connues et répertoriées. Un aspect de la sécurité pris en compte partiellement par MAGOS CLOUD SECURE est la protection contre les attaques venant du réseau interne, plus précisément en provenance des machines physiques de l infrastructure. En effet, les utilisateurs des machines physiques peuvent potentiellement écouter le trafic circulant sur la carte réseau de la machine, dont les communications sortantes des machines virtuelles hébergées sur la machine. Par défaut, le système est donc en permanence confronté à des attaques de type Man in the middle. Heureusement, les communications entre les composants de MAGOS CLOUD SECURE sont cryptées par le serveur Kerberos et protégées pour ce type d attaque. Malheureusement, les autres communications entre machines virtuelles, comme les requêtes ARP, DNS ou les requêtes venant d une application utilisateur peuvent être interceptés. L attaquant peut ainsi disposer d informations critiques sur le système. On remarquera notamment qu un mouchard, installé sur une ou plusieurs machines physiques, permettrait d enregistrer un grand volume d information qui, une fois croisé et analysé, pourrait révéler des informations compromettantes. Pour finir, nous remarquons que le système d authentification fourni par le serveur Puppet est complètement désactivé. Cette faille est la plus importante. Une machine extérieure à l infrastructure peut ainsi facilement se faire passer par une machine virtuelle de MAGOS CLOUD SECURE. En effet, il lui suffit seulement de connaitre le nom de la machine cible pour pirater le système. 3.5 CASSIOPEIA prend la relève Il est important de signaler le côté obsolète du nom de MAGOS CLOUD SECURE. L acronyme du nom MAGOS(Middleware Architecture for Grid Oriented Services) est associé au concept de GRID, alors que le système est de type CLOUD. Aussi, depuis sa seconde version, le système n est plus orienté service ce qui rentre en contradiction avec son nom. Un rafraichissement du nom MAGOS CLOUD SECURE s impose. CASSIOPEIA, ou Cassiopée en Français, est l une des plus belles constellations qui illuminent nos nuits. Elle raconte la belle histoire d Andromède, fille de la reine Cassiopée et du roi Céphée, 15

princesse d Éthiopie. L utilisation de CASSIOPEIA comme nom permet de mettre en avant le concept de constellation de machines. 4 Description générale de la solution 4.1 Objectif général Revoir l architecture et l implémentation de MAGOS CLOUD SECURE dans le but de simplifier son déploiement, surveiller l état de l infrastructure, augmenter la stabilité du système, faciliter le développement de nouveaux types de plateforme et simplifier son utilisation, tout cela dans un environnement sécurisé. 4.2 Objectifs spécifiques Regrouper les machines virtuelles générées au sein d un réseau virtuel privé. Surveiller l état du système à l aide d outils spécialisés. Simplifier le processus de développement de nouvelles plateformes. Créer une interface graphique. 4.3 Stratégie globale Afin de mettre en place les améliorations citées ci-dessus, deux approches distinctes s offrent à nous. La première consiste en la modification de l application existante. Il s agit donc de réaliser un audit détaillé de l application afin d identifier les bugs, les fonctionnalités manquantes et implémenter les modifications nécessaires. La deuxième alternative consiste à réaliser une révision complète de l architecture de MAGOS CLOUD SECURE en reprenant l implémentation sur des bases saines. Après une analyse préliminaire du code source de MAGOS CLOUD SECURE, des évolutions technologiques, la décision fut prise de ré implémenter complètement MAGOS CLOUD SECURE. L architecture vieillissante rendant complexe l ajout de nouvelles fonctionnalités. Les évolutions technologiques permettant une simplification importante des processus. Deux critères en particulier ont fait pencher la bascule. Le code source de MAGOS CLOUD SECURE est fragmenté en un ensemble de scripts répartis sur plusieurs serveurs communiquant entre eux au travers de protocoles mal documentés. 4.4 Stratégies spécifiques Deux axes de réflexions ont été identifiés pour définir la nouvelle architecture du système. D une part, une révision de l architecture du réseau. D autre part, une mise à niveau de l architecture du logiciel. 16

4.4.1 Architecture réseau Le premier axe de réflexion porte sur la question de l organisation du réseau et des machines de CASSIOPEIA. Plus haut, nous évoquions la problématique liée à l attribution d une adresse IP à chaque machine générée par MAGOS CLOUD SECURE. Une machine virtuelle se voyait attribuer une adresse IP de classe A, accessible depuis n importe accès internet dans le monde. Le réseau était donc vulnérable en tout point à des attaques venant de l extérieur, avec un grand risque de piratage. Pour résoudre ce problème, la décision fut prise de regrouper les machines virtuelles au sein d un même réseau virtuel privé, ou VPN. Cette stratégie offre plusieurs avantages. Tout d abord, cela permet d isoler complètement les plateformes du reste du monde. Ainsi, seuls les membres du VPN sont en mesure de se contacter les uns les autres. En réalité, les seuls hôtes qui nécessitent une adresse publique sont les serveurs Web et certaines bases de données. Le deuxième avantage majeur est l encryptions de toutes les communications, automatique au sein d un VPN. Rappelons que toutes les communications entre machines passent par la plateforme physique et le réseau local de l entreprise. Tout utilisateur présent sur le réseau est donc en mesure d écouter les communications et d avoir accès au contenu des transmissions. L utilisation d un VPN permet de garantir l intégrité et l authenticité des données. A la différence de MAGOS CLOUD SECUREoù les communications étaient sécurisées au niveau de la couche applicative, l utilisation permet de crypter les communications au niveau de la couche réseau. Cela permet de garantir une sécurité accrue et continue du système, s assurant qu aucun message ne soit transmit en claire. Nous avons étudié deux technologies VPN différentes permettant l implémentation d un VPN. 4.4.1.1 Réseau Virtuel Privé pair à pair La première technologie étudiée est VPN de type paire à paire (P2P). L implémentation la plus connue s appelle N2N [13]. Son architecture se base sur deux composants (cf Figure 2 Réseau Privé Virtuel N2N). Les Edgenodess installent sur les machines virtuelles et permettent au réseau d être créé. Une interface réseau Tun/Tap est ajoutée à la machine et sert de point d entrée au VPN. Les Supernodes, de leur côté, sont utilisés pour initialiser la connexion et accéder aux nœuds cachés derrière des Firewall. Ce sont les seuls nécessitants une adresse IP publique. 17

Figure 2 Réseau Privé Virtuel N2N L avantage principal de la technologie Pair é Pair est sa capacité de mise à l échelle. Ce type d infrastructure fonctionne très bien avec un nombre important d EdgeNodes. En effet, une fois la communication entre un Edgenodeet un Supernode initialisée, les Edgenodes peuvent ensuite directement communiquer entre eux. La charge au niveau d un supernode est donc minime. Malheureusement, N2N possède deux inconvénients majeurs. D une part, son manque de documentation. Bien que très attrayant, il est peu utilisé et il est difficile de trouver de l aide en cas de problème. Un deuxième inconvénient est l impossibilité de créer des sous réseaux différents. Les machines virtuelles générées pour un utilisateur doivent être en mesure de communiquer entre elles, mais ne doivent pas être accessibles par les machines générées pour un autre utilisateur. 4.4.1.2 Réseau virtuel privé client-serveur La deuxième technologie étudiée est une architecture de type Client-Serveur. Openvpn [14] est une référence dans le domaine. Son architecture se base sur deux composants (cf Figure 3 Réseau Privé Virtuel OpenVPN), les clients et les serveurs. Une interface réseau de type Tun/Tap est ajoutée à chaque machine du réseau, client comme serveur, et sert de point d entrée au VPN. Tous les clients se connectent à un serveur et communiquent sur un canal sécurisé avec lui. Les communications entre deux clients passent donc par un serveur qui a le rôle d intermédiaire. 18

Figure 3 Réseau Privé Virtuel OpenVPN Openvpn a le grand avantage d être entièrement libre, bien documenté, facile de configuration et dispose d une communauté forte disponible en cas de problème. A la différence de N2N, les serveurs constituent un goulot d étranglement important, lié au fait qu ils centralisent toutes les communications. Cependant, la mise à l échelle de l infrastructure est garantie en multipliant le nombre de serveurs. Au moment de se connecter à un serveur, un client choisit aléatoirement parmi la liste des serveurs celui auquel il souhaite se connecter. Aussi, Openvpn possède la capacité de créer facilement des sous réseaux. Les serveurs, en tant qu intermédiaires entre les clients, peuvent contrôler le flux de communications et bloquer les connections entre deux sous réseaux distincts si nécessaire. La décision fut prise d utiliser OpenVpn pour interconnecter les machines virtuelles générées par CASSIOPEIA au sein d un même réseau virtuel privé. 4.4.2 Architecture logicielle Un deuxième axe de réflexion porte sur la question de l architecture logicielle de CASSIOPEIA. Nous évoquions antérieurement la difficulté de déploiement de MAGOS CLOUD SECURE. Cette difficulté repose principalement sur la nécessité d installer, de configurer et surveiller sept serveurs différents afin de commencer à utiliser le système. Nous avons donc étudié la possibilité de centraliser les serveurs au sein d une seule et même application. En plus de simplifier le déploiement, le fait de regrouper les serveurs permettrait aussi de supprimer d office les serveurs Kerberos et LDAP. En effet, le serveur Kerberos permet l authentification unique des utilisateurs (single sign in), lui évitant ainsi d avoir à se connecter séparément aux cinq applications java composant MAGOS CLOUD SECURE. Le serveur LDAP, lui, permet le stockage des clés générées par Kerberos. La sécurisation des communications entre les différents composants fournis par Kerberos serait inutile dans le cas d une application unique Deux serveurs sur huit serait ainsi supprimés. Cependant, il faut prendre en compte les risques liés à l assemblage des composants de MAGOS CLOUD SECURE. Deux risques majeurs sont à éviter. 19

Premièrement, il est important d éviter les goulots d étranglement. Plus l application a de taches à effectuer, plus la charge de la machine qui l héberge augmente. Pour éviter de saturer la machine hôte, Il nous faut donc simplifier au maximum les taches assignées à l application et déléguer les processus complexes aux autres machines de l infrastructure. Dans un deuxième temps, il limite les risques en cas de failles du système. Aucune application n est parfaite et une erreur est vite arrivée. 4.4.2.1 Déléguer la communication à PUPPET Comme nous l avons vu dans l introduction, de nombreuses fonctionnalités ont été ajoutées au gestionnaire de configuration PUPPET depuis la première version de MAGOS CLOUD SECURE. Grâce à celles-ci, la plupart des communications nécessaires au bon fonctionnement de CASSIOPEIApeuvent être déléguées à PUPPET, nous obligeant à exploiter au maximum les fonctionnalités proposées par ce dernier. PUPPET est un logiciel largement utilisé à travers le monde et sa stabilité est éprouvée. Deux types de communicationspeuvent ainsi être pris en charge par PUPPET. Dans un premier temps, tout le mécanisme de déploiement des machines virtuelle impliquant les composants MCServer, MCLoadBalancer, MCInstance et MCNodepeut être ré implémenté à l aide de PUPPET. En effet, la prise en charge des machines Windows ajouté dans les versions 2.7.X de PUPPET nous permet aujourd hui de gérer la configuration de toutes les machines physiques de CASSIOPEIA. Ensuite, le processus de rafraichissement des machines, autrefois implémenté manuellement par les composants MCLoadBalancer, MCNode et MCInstance, est remplacé par la commande Kick offerte par PUPPET. De la sorte, après une modification de l infrastructure coté serveur, CASSIOPEIA demande ainsi aux machines nécessitant une modification de mettre à jour leur configuration. 4.4.2.2 Surveillance de l infrastructure avec PUPPET MAGOS CLOUD SECURE implémentait toute un processus pour récupérer l état des machines. Les composants MCNode et MCInstance sondaient respectivement l état des machines physiques et machines virtuelles, puis transmettaient un rapport au composant MCBalancer. Une fonctionnalité bien intéressante de PUPPET qui est sa capacité de gestion des Facts. Le client PUPPET collecte un certain nombre d informations de sa machine hôte, qu il transmet ensuite au serveur qui les utilise pour adapter la configuration de la machine cible. Par exemple, le serveur connait ainsi le type de système d exploitation, le nom de la machine, le type de CPU, la mémoire libre et bien plus encore. Mieux encore, PUPPET nous permet de créer des faits personnalisés afin de récupérer tout type d information à propos de la machine cible. Le développeur n a qu à spécifier les commandes à exécuter sur les machines cibles et PUPPET se charge de tout le processus d exécution et de récupération de l information. Grace à cette fonctionnalité, nous pouvons vérifier par exemple quels composants sont installés sur une machine physique, le nombre d utilisateurs connectés, ou encore l état des machines virtuelles. 20

L état d une machine virtuelle est défini par le développeur de CASSIOPEIA en fonction des Facts. Par exemple, une machine physique est dite disponible si VMware Player, VMware VIX et la machine virtuelle template debian sont installés. Sinon son état est indisponible. La gestion des facts permet de déléguer la surveillance de l état des machines à PUPPET, réduisant ainsi le travail à la charge de l application. L avantage principal de cette solution est qu elle n augmente pas la charge du serveur PUPPET, s intégrant au processus normal de configuration des machines. Malheureusement, cette solution pose un problème de fond. Les facts ne sont actualisés que lors de la mise à jour de la configuration de la machine cible, c est-à-dire lorsque le client PUPPET contact le serveur. Par défaut, cette mise à jour n a lieu que toutes les 30 minutes. Cette valeur peut être réduite, mais ce n est pas sans risque. Cela entrainerait une augmentation significative des connexions au risque de surcharger le serveur. 4.4.2.3 Surveillance de l infrastructure avec Nagios. Nagios [15] est un logiciel largement utilisé de par le monde permettant la surveillance des systèmes et des réseaux. Il offre aux utilisateurs une jolie interface Web permettant de visualiser l état du système. Nagios offre plusieurs fonctionnalités intéressantes pour notre application. D une part, Nagios permet de surveiller la disponibilité des machines, en envoyant régulièrement des Ping à celles-ci. Cette fonctionnalité de base permet non seulement de savoir si une machine est disponible, mais aussi d identifier quel est l état du réseau entre le serveur et la machine. La politique de Nagios considère qu une machine est indisponible après plusieurs échecs successifs afin d éviter les indisponibilités momentanées du système. Cette fonctionnalité est impossible d être réalisée avec Puppet vue que le serveur Puppet attend les connexions en provenance des clients. En cas d indisponibilité d une machine, le serveur Puppet ne recevra pas de connexion du client et les facts ne seront pas mis à jour. D autre part, Nagios permet de contrôler l état des services présents sur chaque machine. Il est ainsi possible de vérifier qu un hôte est accessible par SSH depuis l extérieur. Cette fonctionnalité est impossible d être implémentée avec PUPPET. En effet, les commandes sont exécutées directement sur la machine cible par le client PUPPET, un service pouvant fonctionner localement mais être inaccessible depuis l extérieur. Une dernière fonctionnalité, bien utile, est la possibilité d installer un service sur la machine cible pour surveiller en permanence l état du système. Ce service permet de surveiller très fréquemment l état du système, puis envoi un rapport au serveur Nagios. Le serveur ne fait que recevoir les rapports et afficher la synthèse à l utilisateur. L utilisation de cette fonctionnalité décentralise une partie de la surveillance à la machine cible, réduisant le travail à charge du serveur Nagios. Cette fonctionnalité est compatible avec les machines Windows et Linux. 4.4.2.4 Récupération en cas de faille des serveurs Dans l introduction de ce document, nous évoquions la vulnérabilité de MAGOS CLOUD SECURE en cas de faille de ses serveurs. En cas d échec, que ce soit l arrêt d une machine, le bug d un serveur ou une indisponibilité temporaire, c est tout le système qui s écroule. 21

Dans le paragraphe précédent, nous proposions l ajout d un serveur Nagios pour surveiller l état de l infrastructure de CASSIOPEIA. Cette proposition rentre en contradiction avec l idée de centraliser les composants sur un seul et même serveur. Tout le travail d installation, de configuration et de surveillance du serveur devra être effectué par administrateur, anéantissant le travail de simplification que nous cherchons à mettre en place. Afin de résoudre ses deux problèmes, nous proposons d utiliser l infrastructure de CASSIOPEIA pour générer les serveurs nécessaires au bon fonctionnement de l infrastructure. Au démarrage, CASSIOPEIA commencerait par générés les serveurs nécessaires au bon fonctionnement du système. Tous les serveurs seraient donc virtuels et exécutés sur une machine physique de CASSIOPEIA. L administrateur n aurait qu à se charger de l installation du serveur unique de CASSIOPEIA, déléguant la complexité de l installation des autres serveurs à l application. Pour permettre la virtualisation des serveurs, critères doivent être respectés. D une part, le serveur unique de CASSIOPEIA doit être autosuffisant. On peut parler d autosuffisance s il est en mesure de: Générer des machines virtuelles, tout du moins les serveurs nécessaires au bon fonctionnement de CASSIOPEIA. Surveiller la disponibilité des machines générée. CASSIOPEIA doit être capable de détecter la faille d un serveur vital au bon fonctionnement du sytème. Pouvoir redéployer un serveur en cas de faille. Dans le cas ou un serveur est hors service, le système doit être capable de le déplacer vers une nouvelle machine. Le système ne serait indisponible que durant la période nécessaire pour détecter la faille et déployer un nouveau serveur. D autre part, il doit garantir l intégrité des données stockées sur les serveurs. Prenons comme exemple une base de données. En cas de faille d une base de données, le serveur central de CASSIOPEIA doit être en mesure de créer un nouveau système de base de données en garantissant qu aucun tuple ne soit perdu dans le processus. 4.4.2.5 Conclusion La décision fut prise de centraliser les composants de MAGOS CLOUD SECURE au sein d une application unique appelée CASSIOPEIA. Pour éviter une surcharge du serveur, deux décisions importantes furent prises. Premièrement, il a été décidé de déléguer une partie des processus à d autres applications. Les évolutions technologiques de PUPPET et l utilisation de Nagios nous permettent de leur en déléguer un grande partie. Ainsi, tous les processus de communication entre les différentes machines de l infrastructure seront pris en charge par le gestionnaire de configuration PUPPET. Il en est de même pour le processus de surveillance de base de l infrastructure, laissé aussi aux mains de PUPPET. Nagios offrant une approche de la surveillance différente de celle proposée par PUPPET, sera utilisée en soutient. L ensemble des serveurs nécessaires au bon fonctionnement de CASSIOPEIA seront générés par CASSIOPEIA au démarrage de l application. Ainsi, l administrateur sera en charge d installer, de configurer et de surveiller qu un seul serveur, celui hébergeant l application CASSIOPEIA. 22

5 Architecture du système Dans cette section, nous détaillons l architecture du système CASSIOPEIA permet la réalisation des objectifs définis dans la section précédente. 5.1 Cas d'utilisation Le but des cas d utilisation est de modéliser les besoins des clients de CASSIOPEIA. Ils définissent le contour du système et permettent d identifier les fonctionnalités principales. Figure 4 Diagramme de cas d'utilisation 5.1.1.1 Les acteurs Comme pour son prédécesseur MAGOS CLOUD SECURE, le projet CASSIOPEIA identifie trois types d acteurs. Tous d'abord les utilisateurs CASSIOPEIA. Ce sont des développeurs d'application Web, science, ayant le désir d'utiliser des systèmes répartis au cœur de leur application. Ils déploient et utilisent des plateformes sur CASSIOPEIA pour héberger leurs applications. Ensuite, on identifie les développeurs CASSIOPEIA. Experts en systèmes distribués tels qu Hadoop ou Cassandra, ils créent de nouveaux types de plateforme à proposer aux utilisateurs. Enfin, les administrateurs CASSIOPEIAsont les responsables des machines physiques de CASSIOPEIAS. Ils administrent les ressources, surveillent l infrastructure et gèrent les utilisateurs. 23

5.1.1.2 Les acteurs indirects de CASSIOPEIA Deux autres types d acteurs doivent être spécifiés. Ce ne sont pas des acteurs directs de CASSIOPEIA et ne doivent pas être confondus avec les acteurs directs de CASSIOPEIA dans le paragraphe cidessus. Premièrement, les utilisateurs des applications hébergées par CASSIOPEIA. Une fois une application mise en ligne par un utilisateur CASSIOPEIA, celle-ci est utilisée par un certain nombre de nouveaux utilisateurs. Ces derniers ne doivent pas être confondus avec les utilisateurs CASSIOPEIA qui déploient les applications. Deuxièmement, il ne faut pas confondre les administrateurs du réseau physique qui peuvent être différents des administrateurs de l application CASSIOPEIA. Les premiers sont les responsables de l infrastructure physique, par exemple les administrateurs réseau de l entreprise ou de l université utilisant CASSIOPEIA, quand les seconds ne sont qu administrateurs de machines physiques. 5.1.1.3 Les fonctionnalités principales Installer l application :Suivre le processus d installation de CASSIOPEIA décrit dans la suite de ce document puis démarrer l application. Gérer les utilisateurs : Créer, modifier et supprimer les utilisateurs de CASSIOPEIA. Chaque utilisateur se voit attribuer un rôle. Il peut être soit un administrateur CASSIOPEIA, soit un développeur CASSIOPEIA, soit un utilisateur CASSIOPEIA. Administrer les machines physiques : Installer les dépenses nécessaires sur les machines destinées à héberger les machines virtuelles générées par CASSIOPEIA. Ajouter la machine à l application au travers de l interface utilisateur. Assurer l accessibilité des machines par l application. Surveiller l infrastructure : S assurer, au travers de l interface utilisateur de l application, de la disponibilité et du bon fonctionnement de l ensemble des machines du sytème. Réaliser les modifications nécessaires en cas de disfonctionnement. Ajouter de nouveaux types de plateformes : Implémenter les modifications nécessaires pour permettre aux utilisateurs de déployer un nouveau type de plateforme, par exemple MangoDB, Cassandra ou Apache. Déployer des clusters : Générer et configurer un ou plusieurs clusters de machines virtuelles hébergeant des systèmes répartis. Déployer des applications :Soumettre à CASSIOPEIA une application se reposant sur des systèmes répartis. 5.2 Diagramme de classes Le diagramme de classe défini l ensemble des méthodes, attributs associées aux objets du système(cf Figure 5 Diagramme de classe). Les données sont stockées dans un serveur SQLite installé d office avec l application. 24

Figure 5 Diagramme de classe On distingue trois composants principaux : Les users : Ce sont les utilisateurs du système. Les hosts :Ce sont les machines gérées par le système, que ce soit les machines physiques ou les machines virtuelles. Les hostgroups : Ce sont les groups de machines. Il y a d une part les clusters qui correspondes à un ensemble de machines hébergeant un même système distribué, par exemple un cluster Hadoop. Il y a d autre part les plateformes qui correspondent à un ensemble de clusters et d hôtes autonomes. Une plateforme pourra par exemple contenir un cluster Hadoop, un hôte Glassfish et un hôte MySQL. On remarque d une plateforme est constitué d un ensemble de machines et de clusters. Par exemple, la plateforme d un utilisateur peut être composée d un cluster Hadoop pour le traitement des données, d un cluster Cassandra pour le stockage des données et d une machine Glassfish pour héberger l application. 5.3 Diagrammes de déploiement et composants On peut décomposer le système en deux infrastructures distinctes. D un coté, l infrastructure physique, cœur de CASSIOPEIA et d un autre coté, l infrastructure virtuelle générée par le système. 5.3.1 Infrastructure physique 5.3.1.1 Diagramme de déploiement L infrastructure physique de CASSIOPEIA s organise autour de deux composants (cf Figure 6 Diagramme de déploiement), un serveur CASSIOPEIA et d un ensemble de machines physique, communément appelé Nœud CASSIOPEIA. 25

Figure 6 Diagramme de déploiement 5.3.1.2 Composants du serveur CASSIOPEIA Le serveur CASSIOPEIA est une machine Linux hébergeant 4 serveurs (cf Figure 7 Diagramme de composants du serveur CASSIOPEIA). D une part, l application CASSIOPEIA elle-même. D autre part, un serveur Puppet permettant la configuration des machines physiques. Ensuite, une base de données SQLite permettant de stocker les données. Pour finir, un daemon GOD permettant de relancer le serveur Puppet en cas de faille. Figure 7 Diagramme de composants du serveur CASSIOPEIA 5.3.1.3 Composants d un nœud CASSIOPEIA Les machines physiques ou nœuds CASSIOPEIA sont les machines hébergeant les machines virtuelles de CASSIOPEIA (cf Figure 8 Diagramme de composant d'un nœud CASSIOPEIA). Il s agit des machines ressources, véritable cœur de l application. Ce sont des machines WindowsSevenoù sont présente les applications suivante: VMware Player : permettant la création et l exécution de machines virtuelles VMware Vix : API de VMware permettant la gestion de VMware Player au moyen de lignes de commandes Windows. 26

Machine virtuelle template Debian : Cette machine virtuelle sera ensuite utilisée comme Template pour toutes les machines virtuelles générées par CASSIOPEIA. Client Puppet : ce client permet à CASSIOPEIA de mettre à jour la machine physique et d y installer les machines virtuelles nécessaires. Une première connexion avec le serveur PUPPET doit être réalisée dans la phase d installation. Figure 8 Diagramme de composant d'un nœud CASSIOPEIA 5.3.2 Infrastructure virtuelle L infrastructure virtuelle correspond à l ensemble des machines virtuelles générées par CASSIOPEIA. Elle est composée d un ensemble de trois types de machines virtuelles : Les serveurs : permettant le bon fonctionnement de CASSIOPEIA. Parmis eux, un serveur Nagios, les machines OpenVPN ou bien un serveur DNS. Les machines utilisateurs : elles sont accessibles par l utilisateur et permettent le développement d applications distribuées. Les machines de plateformes : Elles hébergent un système distribué ou une application permettant le stockage et le traitement intensif des données. 5.3.2.1 Déploiement des machines virtuelles Les machines virtuelles sont hébergées sur les machines physiques de CASSIOPEIA (cf Figure 9 Diagramme de déploiement d'une machine virtuelle ). Chaque machine physique peut héberger jusqu à deux machines virtuelles, une pour chaque processeur. En cas de surcharge de CASSIOPEIA, le système acceptera la présence de trois machines virtuelles sur la même machine physique. 27

Figure 9 Diagramme de déploiement d'une machine virtuelle 5.3.2.2 Réseau privé virtuel Toutes les machines générées par CASSIOPEIA sont regroupées au sein d un même réseau privé virtuelle, ou VPN (cf Figure 10 Diagramme de déploiement de l'infrastructure virtuelle). Ce réseau permet aux machines de communiquer entre elles sur un canal sécurisé. Le VPN permet aussi de définir des sous-réseaux de machines pouvant communiquer entre elles. Figure 10 Diagramme de déploiement de l'infrastructure virtuelle 28

Les machines générées se voient attribuer une adresse IP privée de classe A, de type 10.X.Y.Z. Nous avons choisi ce segment afin de disposer un nombre confortable d adresses privées. Ainsi, plus de 16 million d adresses IP peuvent être générés. L infrastructure virtuelle s organise de la sorte : Un serveur VPN principal permet de regroupé les machines utilisateurs et les serveurs au sein du même segment, le 10.0.0.0/32. Pour chaque plateforme générée, un nouveau serveur OpenVPN est ajouté à la plateforme CASSIOPEIA. Toutes les machines de la plateforme seront ainsi regroupées dans un même sous réseau d adresse 10.0.X.0/32, ou X est l indice de la plateforme. Une route est ajoutée au serveur OpenVPN pour permettre d une part aux machines de communiquer entre elles, et d autre part aux machines de contacter les serveurs. 5.3.3 Diagrammes de séquence 5.3.3.1 Installation de CASSIOPEIA L installation du serveur CASSIOPEIA nécessite d avoir à sa disposition une machine Linux. Tous les tests de CASSIOPEIA ont été effectués avec un système d exploitation Debian 6. En théorie, une machine Debian, Ubuntu, Redhat ou Centos, à jour, convient parfaitement aux exigences de CASSIOPEIA. Figure 11 Diagramme de séquence. Installation 29

Installation des dépendances : Comme nous le verrons par la suite, CASSIOPEIA est entièrement écrit en langage Ruby. Il existe deux manières d installer Ruby sur une machine. La première consiste à utiliser le gestionnaire d installation inclus avec le système Linux, par exemple aptitude dans le cas d un système Debian. Cette méthode est déconseillée car elle ne permet pas sélectionner la version de Ruby et des dépenses souhaitées. Nous conseillons fortement une deuxième approche qui consiste à utiliser le gestionnaire d installation de Ruby RVM. L avantage principal de RVM est qu il offre la possibilité d installer plusieurs versions de Ruby sur la même machine, facilitant ainsi l évolution du logiciel. Le processus d installation est décomposé en quelques étapes bien décrites sur le site Web de RVM. Une étape importante à ne pas oublier est l installation des dépendances requises par Ruby. La liste des dépenses est donnée en fonction du système d exploitation choisi par la commande rvmrequirements. L installation de ruby se fait ensuite grace à la commande rvm install 1.9.3. Une fois ruby en place, l installation de toutes les dépendances se fait à l aide d une commande unique à partir de répertoire de l application : bundle install. La création de la base de donnéesqlite se fait en exécutant 3 commandes. Rakedb :create pour créer la base de donnée. Rakedb :migrate pour générer les tables. Rakedb :seed pour ajouter les tuples de base. Démarrage des serveurs Trois serveurs doivent être mis en service : Le serveur rails, véritable cœur de l application CASSIOPEIA : rails server -d -p 80 Le serveur CRON : whenever -i Le serveurpuppet : god -c config/puppet.god 5.3.3.2 Gérer les utilisateurs L administrateur de CASSIOPEIA est responsable de l ajout, la modification et la suppression des utilisateurs du système(cf Figure 12 Diagramme de séquence. Gérer les utilisateurs). Chaque utilisateur se voit assigné un rôle : Administrateur, Développeur ou Utilisateur. Une fois un utilisateur créé, l application déploie une machine virtuelle de développement et lui remet les codes d accès. Cette machine dispose de droits nécessaire pour accéder aux différentes plateformes de l utilisateur. 30

Figure 12 Diagramme de séquence. Gérer les utilisateurs 5.3.3.3 Surveiller le système L administrateur du système est responsable de la surveillance de celui-ci. Deux mécanismes de surveillance ont été mis en place. La suveillance fournie par Puppet et la surveillance fournie par Nagios. 5.3.3.3.1 Surveillance avec Puppet CASSIOPEIA exploite une fonctionnalité bien intéressante de PUPPET qui est la gestion des Facts d adapter une configuration à une machine spécifique, PUPPET collecte un certain nombre d informations sur la machine hôte tel que le type de système d exploitation, le nom de la machine, le type de CPU, la mémoire libre et bien d autres encore. PUPPET nous permet aussi de créer des faits personnalisés afin de récupérer d autres informations. Grace à cette fonctionnalité, nous pouvons vérifier par exemple les composants installés sur un nœud, ou bien l état des machines virtuelles installées. Toutes les 10 minutes, l application interroge le serveur Puppet afin de connaitre l état des machines de l infrastructure (cf Figure 13 CRON jobs). Afin. Le mécanisme est déclenché au moyen de CRON. Cette fonctionnalité est livrée avec tous les systèmes d exploitation Linux. 31

Figure 13 CRON jobs La communication entre l application et le serveur Puppet se fait au moyen de l API Rest offerte par Puppet. Celle-ci permet non seulement d interroger l état des machines, mais aussi de déclencher les commandes de base de Puppet. Figure 14 Utilisation de l'api Rest de Puppet 5.3.3.3.2 Surveillance avec Nagios La surveillance fournie par Puppet est enrichie par la surveillance offerte par Nagios. Lorsque Nagios détecte l indisponibilité d une machine, il contacte le serveur CASSIOPEIA pour lui demander de mettre à jour l état de la machine. Si l indisponibilité persiste, CASSIOPEIA se chargera de redéployer la machine virtuelle vers une nouvelle machine physique. 32

Figure 15 Diagramme de séquence. Surveillance Nagios 5.3.3.4 Déployer une plateforme L utilisation de CASSIOPEIA défini au moyen de l interface Web de l application le type de plateforme qu il souhaite pour son application. Une plateforme peut être composée de plusieurs clusters distincts, comme Hadoop, Cassandra, MAGOSDB ainsi que de machines autonomes comme Glassfish ou MySQL. Une fois la plateforme définie, CASSIOPEIA se charge de la génération des machines virtuelles, ainsi que leur reprise en cas de faille. 33

Figure 16 Diagramme de séquence. Déployer une plateforme 5.3.3.5 Déployer une application En ajoutant un serveur Glassfish à sa plateforme, l utilisateur est en mesure de déployer des applications utilisant les ressources physiques de la plateforme. La machine glassfish disposant d une adresse IP publique, son application sera visible depuis l extérieur. Une fois la machine Glassfish déployée, l utilisateur se voit remettre les codes d administration de celle-ci. Figure 17 Diagramme de séquence. Déployer une application 34

5.3.3.6 Générer nouveaux types de cluster Un des objectifs clés de la restructuration de l application est la définition d un processus complet permettant l ajout de nouveauxclusters à CASSIOPEIA. L idée est de permettre à un développeur CASSIOPEIA de générer rapidement un nouveau type de cluster, puis de lui permettre de personnaliser celle-ci au fil des modifications et de l implémentation. La technologie Ruby on Rails implémente un système connu sous le nom de générateurs [16]. Son utilisation permet de systématiser l ajout de fichier à l application. Très commune au sein des applications Rails, cette fonctionnalité est par exemple utilisée pour générer un nouvel ensemble modèle, vu, contrôleur. Ainsi, nous avons décidé de créer deuxgénérateurs différents permettant d assister le développeur dans le processus de création de types de plateformes.l exécution d un générateur ajoute plusieurs fichiers à l application. On notera Premièrement, nous avons créé un générateur permettant l ajout de nouveaux types de machines. Dans le cas d un cluster Hadoop, une machine serait par exemple une machine Hadoop esclave. L exécution du générateur ajoute à l application rails: un fichier Puppet : Celui-ci définitle processus d installation des composants nécessaires au bon fonctionnement de la machine. Par exemple, le fichier Puppet d une machine Hadoop esclave défini le processus d installation d Hadoop et de connexion à la machine maîtresse. Un modèle : Le modèle défini les attributs et les méthodes définissant la machine. Ce fichier décrit le type et les bornes de chaque attribut, les informations envoyées à Puppet lors d une mise à jour. Il décrit aussi si la machine nécessite l attribution d une adresse IP lors de son déploiement. La vue du formulaire : Celle-ci définit les champs de saisie pour personnaliser la machine lors de sa création et modification. Deuxièmement, nous avons défini un générateur permettant l ajout d un type de cluster. Dans le cas d Hadoop, le cluster serait un ensemble composé d une machine Hadoop maîtresse et de plusieurs machines Hadoop esclaves. L exécution du générateur ajoute à l application rails: Un modèle : Le modèle définit les actions à effectuer après la création du cluster, le nombre de machines de chaque type qui le compose, les attributs communs à l ensemble des machines ou encore les informations envoyées à Puppet. La vue du formulaire : Celle-ci définit les champs de saisie à remplir lors de la création d un nouveau cluster par l utilisateur. 5.3.3.7 Reprise en cas de faille d une machine Plusieurs mécanismes permettent de garantir la reprise du système en cas de faille d une machine. La décision fut prise devirtualiser les serveurs de CASSIOPEIA afin de d éviter à l administrateur d avoir à les déployer lui-même. Aussi, cela permet à CASSIOPEIA de les redéployer en cas de faille. Comme nous l avons vu précédemment, CASSIOPEIA demande périodiquement au serveur Puppet l état des machines de l infrastructure. Il peut arriver pour des raisons multiples et variées qu une machine, physique ou virtuelle, passe de l état disponible à l état indisponible. 35

Une machine physique peut passer dans l état indisponible pour plusieurs raisons. D une part, en cas de prise de contrôle de la machine par un utilisateur. En effet, la priorité d utilisation des machines physiques est accordée aux utilisateurs. L objectif de CASSIOPEIA est d exploiter les ressources non utilisé, sans compromettre l usage normal accordé aux utilisateurs. D autre part, la machine peut passer dans l état indisponible en cas d arrêt brutal ou de bug du système d exploitation. En cas d indisponibilité d une machine physique, toutes les machines virtuelles qui y étaient hébergées sont redéployées vers un nouvel hôte. Cette stratégie permet d assurer une continuité de service sans impact sur les applications de l utilisateur CASSIOPEIA. De la même manière, une machine virtuelle peut passer dans l état indisponible pour plusieurs raisons. Parmi elles, on rappellera que la cause la plus fréquente est le passage à l état indisponible de la machine hôte hébergeant la machine virtuelle. On peut aussi imaginer tout un ensemble d erreurs telles que l arrêt brutale de la machine virtuelle, un problème de connexion au VPN, une erreur système et bien d autres. Si le problème persiste, la politique adoptée par CASSIOPEIA est de redéployer la machine virtuelle sur une nouvelle machine physique. Ainsi, l utilisateur ne perçoit qu une brève indisponibilité de la machine le temps qu elle soit remise en service. Dans le cas d une machine appartenant à un système distribué, l intégrité des données est garantie par le système lui-même. Par exemple, un système Hadoop dispose d une politique de réplication de l information pour garantir qu en cas de faille d une des machines du cluster, aucune donnée ne soit perdue. Lorsque la nouvelle machine virtuelle venant remplacer celle indisponible est déployée par CASSIOPEIA, le système distribué se charge de redistribuer l information sur la machine. Malheureusement, cette stratégie pose problème dans le cas des machines virtuelles telles que Glassfish, ne disposant pas de système automatique de récupération. En cas de failles, le système sera redéployé mais les données seront perdues. Une solution à ce problème sera proposée comme travail future. 5.4 Sécurité du système CASSIOPEIA est régie par une politique de sécuritédéfinissantla stratégie utilisée pour garantir la confidentialité, l authenticité et l intégrité du système. Un certain nombre de mécanismes sont mis en place afin de garantir le respect de la politique de sécurité. 5.4.1 Politique de sécurité La politique de sécurité de CASSIOPEIA est définie par les articles suivants : Seules les machines physiques désignées par l administrateur de CASSIOPEIApourront faire partie système. Les machines virtuelles déployées par CASSIOPEIA ne seront en aucun cas accessibles depuis les machines hôtes. La sécurité (confidentialité, authenticité et intégrité) des communications entre machines de CASSIOPEIAdoit être garantie. 36

5.4.2 Mécanismes de sécurité Plusieurs mécanismes sont mis en place pour implémenter la politique de sécurité définie ci-dessus. 5.4.2.1 Authentification des machines physiques: Toute machine physique possède une paire declés privées - clé publique, qui lui est propre. La clé privée, n est accessible que par les administrateurs de la machine et ne doit en aucun cas être partagée.la clé publique, elle, peut-être distribuée à travers le réseau. Cette dernière est automatiquement transmise au serveur PUPPETau moyen d une demande de signature de certificat. Afin de garantir la sécurité du système, l administrateur CASSIOPEIA valide la signature du certificat par l autorité de certification (présente sur le serveur PUPPET), s assurant que la clé publique présent sur la machine physique et celle présente dans la demande de signature coïncident. Une fois validé, le certificat signé par le serveur PUPPET est automatiquement envoyé au client. Ce mécanisme permet une double authentification, garantie par l administrateur CASSIOPEIA. Le serveur PUPPET est certain de s adresser aux clients. Les clients sont certains de s adresser au bon serveur. 5.4.2.2 Confidentialité des communications avec le serveur PUPPET La confidentialité des communications entre client et serveur PUPPET est assurée par le cryptage de celles-ci (cf Figure 18 Communication sécurisée avec puppet). En effet, la clé publique générée du client permet au serveur de crypter toutes communications qui lui sont destinées, et qu il sera le seul à pouvoir décrypter. De la même manière, le serveur PUPPET distribue sa clé publique aux différents clients afin qu ils puissent encrypter les messages à son égare. Figure 18 Communication sécurisée avec puppet 5.4.2.3 Authentification des machines virtuelles Tout comme les machines physique, chaque machine virtuelle possède une paire de clé privée - clé publique, qui lui est propre. Contrairement aux machines physiques, cette paire de clés est générée par CASSIOPEIA, puis transmise à la machine virtuelle au travers de la machine physique hôte. En effet, une fois générée 37

par CASSIOPEIA, la clé est transmise à l hôte au travers communication sécurisée entre PUPPET client et serveur (cf Figure 18 Communication sécurisée avec puppet). La clé est ensuite copiée depuis la machine hôte sur la machine virtuelle grâce à l API VMware VIX. CASSIOPEIA génère lui-même la demande de certificat content la clé publique de la machine virtuelle, puis la transmet au serveur PUPPET. Il transmet ensuite automatiquement la demande de signature. Ce processus ne requière pas l approbation de l administrateur CASSIOPEIA car toutes les communications sont réalisées sur des canaux sécurisés. 5.4.2.4 Isolationentre machine hôte et machine virtuelles. Chaque machine physique hôte, ou NOEUD CASSIOPEIA, héberge un certain nombre de machines virtuelles. CASSIOPEIA garantie l isolation entre machine hôte et machine virtuelle par deux procédés. D une part, toutes les opérations locales à la machine sont réalisées comme administrateur du système. Nous considérons ici que les administrateurs sont en mesure d intercepter les communications entre machine hôte et machines virtuelles. Il s agit d un groupe restreint d utilisateur auquel CASSIOPEIA fait entièrement confiance. Les utilisateurs de la machine physique, n ayants pas accès aux dossiers desadministrateurs, sont donc dans l incapacité de nuire à l intégrité du système. Machine physique Figure 19 Isolation des machines virtuelles offerte par VMware sur une machine physique Aussi, VMWare garanti une isolation complète entre une machine hôte et ses machines virtuelles au moyen d un Switch virtuel (cf Figure 19 Isolation des machines virtuelles offerte par VMware sur une machine physique). En effet, les machines virtuelles sont calibrées pour utilisé un adaptateur de type Bridge [17]. Le Switch virtuel permet une séparation de la carte Ethernet de l hôte de cellesdes machines virtuelles, empêchant ainsitoute communication directe. 6 Implémentation 6.1.1 Langage Ruby Ruby est un langage de programmation interprété, orienté objet, très largement utilisé. Il s agit d un langage libre disposant, en plus des fonctionnalités traditionnelles attendues d un langage de programmation, d un ramasse-miette afin de libérer la mémoire, d une prise en charge l héritage simple, de la gestion des exceptions et de la création de threads. 38

CASSIOPEIA est entièrement codé en Ruby pour plusieurs raisons. En effet, l utilisation de Ruby permet de : Limiter les dépendances fonctionnelles.cassiopeia peut être vue comme une surcouche du système PUPPET, lui aussi écrit en langage Ruby. Le processus de déploiement d un serveur CASSIOPEIA nécessite comme seul pré-requis l installation de Ruby. Etre multi plateforme. CASSIOPEIA est ainsi compatible avec la plupart des systèmes Linux. Le système de gestion de configuration PUPPET n étant pas compatible avec Windows, il en est de même de CASSIOPEIA. Une prise en charge de Windows dans les prochaines versions de PUPPET permettrait une compatibilité de CASSIOPEIA avec ce dernier. Faciliter le développement d application Web.CASSIOPEIA est avant tout une application de CLOUD computing, disposant donc d une interface utilisateur accessible depuis internet. Ruby dispose d un grand nombre de framework facilitant le développement Web. De la même manière, les langages interprétés sont mieux adaptés au développement Web car ils permettent un débogage à la volée, sans besoin de compiler l application après chaque modification. développer une application open source. Le caractère libre de Ruby en fait un candidat approprié pour le développement d applications open source. 6.1.2 Ruby on Rails Ruby on Rails est un Framework écrit en ruby permettant la création d applications Web. Il suit une architecture Modèle Vue Contrôleur, imposant ainsi une démarche structurée au développeur. Le développeur peut ainsi concentrer ses efforts sur les fonctionnalités de son application plutôt que sur les mécanismes internes.il s agit d un langage de haut niveau permettant d éviter la duplication de code. L utilisation de Ruby on Rails pour l implémentation de CASSIOPEIA offre plusieurs avantages. Tout d abord, Ruby on Rails gère automatiquement les correspondances entre les objets de l application et les tables d un système de gestion de base de données relationnelle, cela grâce au système ActiveRecord. L enregistrement et la récupération des objets depuis la base de données se fait directement sans écrire de commandes SQL. Le programmateur consacre ainsi très peu de code à l accès à la base de données et se concentre sur les fonctionnalités de l application. Active Record est compatible avec MySQL, SQLite et PostgreSQL. 6.1.3 EnvironnementsCASSIOPEIA Pour faciliter le processus d implémentation des nouvelles fonctionnalités de CASSIOPEIA, deux environnements ont été mis en place. Le premier est un environnement de développement permettant la programmation des nouvelles fonctionnalités de CASSIOPEIA. Quelques machines physiques sont ainsi utilisées comme nœuds pour héberger et tester les machines virtuelles générées le système. Le server Ruby on Rails est lui aussi exécuté en mode de développement, c est-à-dire sans mise en cache des pages et en exécutant chaque requête dans leur totalité. Ce mode de fonctionnement, sans optimisation, facilite le processus de débogage mais diminue fortement l efficacité du système. 39

Un deuxième environnement, appelé environnement de production, sert d infrastructure de preuve de CASSIOPEIA. Cet environnement est utilisé par des utilisateurs réels. Une fois une nouvelle fonctionnalité implémentée, testée et validée dans l environnement de développement, celle-ci est propagée dans l environnement de production afin d être utilisée par les utilisateurs du système. Les deux environnements de développement et de productions permettent une évaluation continue de l avancement du projet CASSIOPEIA. L utilisateur final, utilisant l environnement de production, peut en permanence évaluer le système et tester les nouvelles fonctionnalités sans être dérangé les bugs de développement. Le programmateur, utilisant l environnement de développement, peut avancer dans le développement et redémarrer ses serveurs sans perturber les utilisateurs finaux. 6.1.4 Gestionnaire de version Une évolution majeure du projet CASSIOPEIA est la mise en service d un dépôt subversion. Celui-ci permet une augmentation globale de la qualité du projet en conservant les modifications apportées à chaque amélioration du système. L organisation du dépôt suit une série de bonnes pratiques décrites en détails dans le livre en ligne «Version Control with Subversion» [18]. Le dépôt est structuré en trois répertoires. Le répertoire trunk, contenant la ligne principale de développement de CASSIOPEIA. Le répertoire branches, contenant les révisions des versions stables de CASSIOPEIA. Le répertoire tags, contenant les versions stables d exploitation de CASSIOPEIA. 6.1.5 Versions des logiciels L application CASSIOPEIA utilise les logiciels suivants : Ruby 1.9.3 Rails 3.2 Les machines physiques CASSIOPEIA utilisent les logiciels suivants : Machine virtuelle template Debian 6 VMware player 4.03 VMware VIX API 1.11 7 Validation et résultats L application CASSIOPEIA implémente les fonctionnalités suivantes : Ajout de machines physiques via l application web. Surveillance Puppet des machines physiques. Déploiement de machines virtuelles sur les machines physiques. Création de clusters de machines. Création de plateformes. Regroupage des machines virtuelles au sein d un même VPN. 40

Assignation automatique de clés SSH sur les machines virtuelles. Gestion de l authentification des machines virtuelles. Attribution d adresses IP publiques. Déploiement d une machine Glassfish Déploiement d un cluster Hadoop. Cette fonctionnalité dispose toujours d un certain nombre de disfonctionnements. Déploiement d un cluster HBase. Cette fonctionnalité dispose toujours d un certain nombre de disfonctionnements. Déploiement d une machine utilisateur. Déploiement d un serveur Nagios pour surveiller l infrastructure. Problèmes : Slow rails application outside of localhost Un certain nombre de fonctionnalités restent à être implémentés : Ajout des règles de pare-feu aux machines virtuelles. Cette fonctionnalité doit être reprise de MAGOS CLOUD SECURE. Gestion des utilisateurs et rôles via l interface web. Partage des ressources entre les utilisateurs. Ajout d un cluster CASSANDRA Implémentation d un système de fichiers distribué pour sauvegarder les fichiers de l utilisateur. Communication entre Nagios et Cassiopeia pour signaler qu une machine est hors service. Encryptage des communications entre CASSIOPEIA et l API Rest du serveur Puppet. 8 Conclusion et travaux ultérieurs La révision de l architecture de CASSIOPEIA permet une simplification significative des processus du système. Une grande partie des fonctionnalités autrefois implémentées manuellement dans MAGOS CLOUD SECUREest aujourd hui déléguée à d autres composants. L utilisation d outils éprouvés tels que Puppet ou Nagios permet d améliorer la stabilité globale du système. L implémentation d un réseau privé virtuel avec l utilisation Nagios permet d isoler les machines du reste du monde, mais aussi isoler les plateformes les unes des autres. La sécurité globale du système s en voit accrue. Les points d entrée au système sont maintenant minimes. Le travail développement de CASSIOPEIA requière des connaissances transversales et pointues dans de nombreux domaines. En effet, il est question de sécurité des systèmes, d outils de virtualisation, de surveillance de machines et de services, de configuration réseau, d applications distribuées etc. L application s implémente la fonctionnalité clé du système qui est le déploiement de plateformes virtuelles sur une infrastructure opportuniste. Elle offre en plus des outils de surveillance du système. L application doit encore grandir en maturité afin de pouvoir être utilisé de manière fiable. 41

Plusieurs améliorations doivent encore être ajoutées au système. D une part, la gestion des utilisateurs et du partage des contenus offerts par MAGOS CLOUD SECURE doit maintenant être ajoutée à la nouvelle architecture. Dans un deuxième temps, une réflexion plus poussée doit être menée pour ajouter un système de récupération des données aux serveurs ne disposant pas de système pour garantir l intégrité des données, telles que Glassfish ou Postrgres. En effet, après la faille d une telle machine, les données stockées sur le système de fichiers sont définitivement perdues. Une solution envisageable serait d ajout à CASSIOPEIAune plateforme contenant un système de fichiers distribué. Cela permettrait de garantir l intégrité des données stockées sur ce type de serveur, ainsi que les données sur les machines virtuelles des utilisateurs dans tous cas. Un logiciel tel que XtreemFS, open source, multiplateformes et permettant la réplication des données semble une très bonne alternative. 9 Bibliographie [1] Google, «Press statistics,» 2012. [En ligne]. Available: http://www.youtube.com/t/press_statistics. [Accès le 01 06 2012]. [2] EGEE, «Enabling Grid for E-sciencE,» [En ligne]. Available: http://www.eu-egee.org/. [Accès le 01 06 2012]. [3] EGEE, «EGEE in number,» [En ligne]. Available: http://project.eu-egee.org/index.php?id=417. [Accès le 01 06 2012]. [4] M. Stonebraker, "One Size Fits All : An Idea Whose Time Has Come and Gone, 2005. [5] R. Cattel, «Relational Databases, Object Databases, Key-Value Stores, Document Stores, and Extensible Record Stores: A Comparison,» 2010. [En ligne]. Available: http://www.odbms.org/blog/2010/01/rick-cattell-on-relational-databases/. [6] Apache, «Cassandra,» [En ligne]. Available: http://cassandra.apache.org/. [7] Apache, «Hadoop,» [En ligne]. Available: http://hadoop.apache.org/. [8] G. Sanjay, The Google File System, New York, USA, 2003. [9] C. L. Jiménez-Guarín, «The MAGOS Project: Middleware for easy and standard development of SOA grid applications,» Bogotá, 2009. [10] Puppet, «External nodes,» 2012. [En ligne]. Available: http://docs.puppetlabs.com/guides/external_nodes.html. [Accès le 01 06 2012]. 42

[11] VMware, «Understanding clones,» [En ligne]. Available: http://www.vmware.com/support/ws55/doc/ws_clone_overview.html. [12] VMware, «VMware VIX API,» [En ligne]. Available: http://www.vmware.com/support/developer/vix-api/. [13] Ntop, «N2N, a Layer Two Peer-to-Peer VPN,» [En ligne]. Available: www.ntop.org/products/n2n/. [14] Openvpn, «Openvpn,» 2012. [En ligne]. Available: http://openvpn.net/. [15] Nagios, «Nagios - The Industry Standard in IT Infrastructure Monitoring,» [En ligne]. Available: www.nagios.org. [16] Rails, «Creating and Customizing Rails Generators & Templates,» [En ligne]. Available: http://guides.rubyonrails.org/generators.html. [Accès le 01 06 2012]. [17] VMWare, «Bridged Networking,» [En ligne]. Available: http://www.vmware.com/support/ws55/doc/ws_net_configurations_bridged.html. [18] Subversion, «Version Control with Subversion,» [En ligne]. Available: http://svnbook.redbean.com/en/1.7/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout. 43