11 DeployWare : Une approche à base de modèles pour un déploiement fiable en environnements ouverts distribués Séminaire Interne ADAM – 19 octobre 2007 – Lille Jérémy Dubus, Philippe Merle LIFL - GOAL Team INRIA ADAM Project Laboratoire dInformatique Fondamentale de Lille UMR CNRS 8022

22 Plan Contexte –Déploiement de systèmes distribués hétérogènes –Environnements Ouverts Distribués (EOD) –Autonomic computing Problématique –Expression du déploiement de systèmes en EOD –Validation statique des procédures de déploiement –Exécution des procédures de déploiement Proposition –Un méta-modèle DeployWare Expression de haut niveau Ajout de sémantique statique et dynamique –Une plate-forme dexécution des modèles Fractal Deployment Framework

33 Déploiement de systèmes distribués Lourde tâche Triple hétérogénéité pour les administrateurs –Hétérogénéité matérielle OS, protocoles daccès à distance, de transfert de fichier –Hétérogénéité des paradigmes Objet, Aspect, Composant, Service, Modèle –Hétérogénéité des implantations Ex: SCA, EJB, CCM pour les composants Prise en charge de ces hétérogénéités –Cauchemar

44 Illustration

55 Difficulté supplémentaire Évolution technologique des réseaux –Nombre de machines impliquées fluctuant et imprévisible Environnements ouverts distribués –Informatique Ubiquitaire/Ambiante –Grilles de calcul –Réseaux de senseurs Besoin de déploiement et dadministration autonome

66 Autonomic Computing Introduit par IBM [Kephart et al. 2003] Inspiré de mécanismes humains Ajout de politiques dautonomies dans les systèmes distribués –Reconfigurations au runtime guidées par des politiques de haut-niveau Repose sur la notion de « Boucle de Contrôle »

77 1 er Challenge : Expression Comment exprimer le déploiement de systèmes hétérogènes Comment exprimer –Comment déployer un élément dun système –Comment assembler ces éléments du système –Comment décrire le déploiement de toute la pile logicielle Librairies, Serveurs dapplications, Applications métiers Comment ajouter la gestion de louverture des environnements –Comment exprimer les boucles de contrôle

88 2 e Challenge : Validation Des mécanismes de déploiement et/ou de reconfiguration existent –Déploiement/Administration à base darchitectures réifiant le système (JADE) Description à laide dun ADL (déclaratif) –Reconfiguration darchitectures (FScript, Rainbow, JASMINe) Réalisation à laide de scripts (impératif) Seules vérifications possibles : –Syntaxe –Typage Quid des validations liées à la sémantique de déploiement ?

99 3 ème Challenge : Exécution Plate-forme capable dinterpréter les informations de haut niveau Exécuter le processus de déploiement en tenant compte –Hétérogénéités matérielles –Dépendances entre les logiciels Orchestration Indépendamment de léchelle –Performance à grande échelle Support dexécution des boucles de contrôle

10 Proposition : DeployWare DeployWare: un environnement … …à base de modèles… –DeployWare repose sur un méta-modèle …pour le déploiement fiable… –Ajout de sémantique au méta-modèle pour valider les modèles …de systèmes distribués… –Plate-forme distribuée dexécution des modèles de déploiement …en environnements ouverts distribués –Ajout des concepts et mécanismes de boucle de contrôle pour linjection dautonomie dans le déploiement

11 Le méta-modèle DeployWare Déploiement distribué –Préoccupations transverses ! Architecture globale du système –Configuration des logiciels, administration au runtime Administrateur système Définition de la procédure de déploiement dun logiciel –Packaging des applications, description des actions élémentaires de déploiement Expert logiciel Description du support matériel –Protocole daccès à distance, transfert de fichiers Expert réseau Volonté de séparation des préoccupations

12 Le paquetage de lexpert logiciel

13 Le paquetage de ladmin système _______Paquetage TechnoExpert _______

14 Le paquetage Autonomie Choix porté sur « Action-based » policies –Par opposition au « goal-based policies » et « utility functions » –Caractère évènementiel ponctuel des environnements ouvert –Granularité fine des politiques Fortement inspiré du paradigme Evènement- Condition-Action du monde des BD –Monitor -> Evènement –Analyze -> Condition –Plan -> Action

15 Le paquetage dautonomie Les actions manipulent les concepts du méta- modèle

16 Sémantique & Vérification (1) Déploiement correct uniquement sil est réversible –Retour possible à la case départ : le Repliement Vérifier que chaque type de procédure de déploiement possède son inverse –Start -> Stop, Install -> Uninstall Dans DeployWare –Types de procédures liés deux à deux –Un logiciel ne pourra pas contenir quune seule des deux –Exceptions !

17

18 Sémantique & Validation (2) Deux procédures inverses –Comportement symétrique Vérifier que pour toute instruction élémentaire dans une procédure donnée –Linstruction au comportement inverse figure dans la procédure déclarée inverse LaunchProcess dans Start KillProcess dans Stop Dans DeployWare –Type dinstructions déclarées deux à deux –Un logiciel est valide si chaque instruction de chaque procédure est « annulée » dans la procédure inverse

19

20 Sémantique & Validation (3) Un logiciel utilise une instruction définie dans un autre logiciel –Ex : JOnAS et Java Vérifier que le SoftwareType JOnAS dépend bien du SoftwareType JRE Dans DeployWare –On peut associer un type dinstruction à un logiciel Ex: ExecuteJava() avec le SoftwareType JRE –Tout logiciel utilisant ce type dinstruction doit dépendre de ce type de logiciel

21 Sémantique & Validation (3bis) Un logiciel installé sans sa dépendance –Dépendances techniques Erreur pendant le déploiement –Dépendances métier Erreur interne au métier Il faut vérifier que les dépendances dun type de logiciel donné soient présentes dans le système Dans DeployWare –Pour une SoftwareInstance SI, on vérifie que dependencies contient bien des logiciels de types contenus dans le dependsOn du type SoftwareType de SI

22

23 Sémantique & Validation (4) Un logiciel déployé sur une machine –Utilise des ressources sur cette machine Système de fichiers Ports Deux logiciels sur une même machine –Ensembles de ressources disjoints Dans DeployWare –Les propriétés sont typées, on peut donc type par type vérifier que les ensembles sont bien disjoints pour tous les logiciels deux à deux

24

25 Sémantique de lautonomie Détection comportements incohérents dans les boucles de contrôle –Cycle dans le déclenchement –Déclenchement parallèle Shared Trigger Interaction Nouvelle forme de validation La règle dIntention –lintention de l« action » dune politique (« post-condition ») –Rapprochement avec un évènement –Déduction dun graphe qui révèle entre autres les cycles

26 Machine Virtuelle DeployWare = FDF Réification sous forme de composants (Fractal) Plus fine granularité que dautres approches (JADE) –Abstraction des mécanismes de base du déploiement protocoles daccès distants et de transfert de fichiers, shells, commandes, variables… –Infrastructure cible noeuds et hôtes distants, serveurs, terminaux mobiles… 3 e préoccupation du déploiement: Expert Réseau Composition afin dobtenir un composite symbolisant le processus de déploiement

27 FDF Composants de déploiement –Ex. exécution dune commande distante SH, CSH, Windows CMD… SSH, rlogin, telnet.…

28 FDF Composants « software » (personnalités) –Liaisons entre composants = dépendences

29 Contribution Overview DeployWare ADL file DeployWare Explorer Deployment Configuration Software Components Deployment Components Physical Infrastructure

30 Le passage à lechelle de FDF FDF optimisé pour utilisation à large échelle Motifs darchitecture –Factorisation des définitions –Opérationnalisation partielle des travaux de Romain [LMO 07?] –Composants pour bloc conditionnel, boucle itérative etc. Composants spécifiques pour la Grille –Encapsulant mécanismes de réservation Distribution du composite FDF lui-même –Fractal RMI optimisé –Distribution de ressources (sockets, etc.)

31 Lautonomie dans FDF Composants spécifiques pour lautonomie Dans un domaine, un Autonomic Manager est un composant FDF capable de : –Garder en mémoire la composition du domaine Knowledge local au domaine (Working memory) –Ecouter des évènements Pouvant provenir de lextérieur (sondes) –Déclencher des politiques de type ECA Ces composants sont des wrappers de moteur de règles existants (Jess, JBoss Rules) –Reconfigurer le domaine Donc ce quil réifie (i.e. le système) Grâce à la réflexivité de Fractal

32 Travaux relatifs Générique Granularité LogicielleAbstraction Validat ion/ Sim ulat ionAutonomie JADE/JASM INe Oui - mais dur (API) Oui sauf JADENo desComposantNonBas niveau TUNe Oui Profil UMLNon Etat/Transition UML J2EEML Non - EJB seuleme ntNonDSMLNonCode généré SmartFrog OuiNon Non - API JavaNon ORYA Oui Non / Pas de proj exeMéta-modèleNon Non / Pas de proj exe DeployWare Oui DSMLOUIOui (EOD)

33 Conclusion Approche de type MDE pour le déploiement –Séparation des préoccupations transverses du déploiement réparti –Description à un haut niveau dabstraction indépendant des technologies (PIM) –Sémantique statique –Génération vers une plate-forme dexécution (PSM) Multi-échelle Multi-granularité Multi-technologies

34 Perspectives Scientifiques Explorer davantage la méta-modélisation –Ajout de sémantique dynamique au méta-modèle –Capacité de simuler lexécution des modèles sans tester le déploiement Evaluer les performances théoriques Optimiser le fonctionnement –Parallélisation maximale Ajout dautres préoccupations dans le méta-modèle –Gestion transactionnelle du déploiement ? Continuer daccroître la « maîtrise » du processus de déploiement

35 Perspectives personnelles Continuer lopérationnalisation du méta- modèle avec Kermeta –Réalisation des validateurs statiques –Ajout de la sémantique opérationnelle du méta- modèle pour la simulation Approfondir/Évaluer/Optimiser les mécanismes dautonomie –Pour lubiquitaire (Projet CAPUCCINO) –Pour les grilles de calcul Se positionner par rapport aux mesures classiques de lAC Écrire une thèse sur tout ça

36