DeployWare : Une approche orientée modèle pour un déploiement autonomique fiable en environnements ouverts distribués JTE Systèmes Autonomes – 16 Novembre.

Présentation au sujet: "DeployWare : Une approche orientée modèle pour un déploiement autonomique fiable en environnements ouverts distribués JTE Systèmes Autonomes – 16 Novembre."— Transcription de la présentation:

1 DeployWare : Une approche orientée modèle pour un déploiement autonomique fiable en environnements ouverts distribués JTE Systèmes Autonomes – 16 Novembre 2007 – Toulouse Jérémy Dubus, Philippe Merle , LIFL - GOAL Team INRIA ADAM Project Laboratoire d’Informatique Fondamentale de Lille UMR CNRS 8022

2 Plan Contexte Problématique Proposition Conclusion
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 d’exécution des modèles Fractal Deployment Framework Conclusion

3 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 d’accès à distance, de transfert de fichiers 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

4 Illustration

5 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 d’administration autonome

6 Autonomic Computing Introduit par IBM [Kephart et al. 2003]
Inspiré de mécanismes humains Ajout de politiques d’autonomies 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 »

7 Le déploiement à ce jour
Trois grandes catégories d’approches Les langages de définition d’architectures (ADL) Mono-paradigme : le composant Ne permettent de déployer que la couche métier Sans prendre en compte l’ouverture des environnements Les modèles génériques de déploiement Généricité entraîne la perte de sémantique (ex. UML) Les outils dédiés de déploiement Très souvent dédiés à une technolgie Passent rarement à l’échelle Trop techniques Outils de reconfiguration Souvent APIs et/ou mécanismes bas-niveau Dédiés à une technologie

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

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

10 3ème Challenge : Exécution
Plate-forme capable d’interpré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 d’exécution des boucles de contrôle

11 Proposition : DeployWare
DeployWare: un environnement … …orienté modèle… 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 d’exécution des modèles de déploiement …en environnements ouverts distribués Ajout des concepts et mécanismes de boucle de contrôle pour l’injection d’autonomie dans le déploiement

12 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 d’un logiciel Conditionnement des applications, description des actions élémentaires de déploiement Expert logiciel Description du support matériel Protocole d’accès à distance, transfert de fichiers Expert réseau Volonté de séparation des préoccupations

13 Le paquetage de l’expert logiciel

14 Le paquetage de l’admin système
_______Paquetage TechnoExpert _______ dependsOn 0..*

15 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 Réutilisation accrue Fortement inspiré du paradigme Evénement-Condition-Action du monde des BD Monitor -> Evénement Analyze -> Condition Plan -> Action

16 Le paquetage d’autonomie
Les actions manipulent les concepts du méta-modèle

17 Sémantique & Vérification (1)
Déploiement correct uniquement s’il 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 qu’une seule des deux Exceptions !

18 dependsOn 0..*

19 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 L’instruction au comportement inverse figure dans la procédure déclarée inverse LaunchProcess dans Start KillProcess dans Stop Dans DeployWare Type d’instructions déclarées deux à deux Un logiciel est valide si chaque instruction de chaque procédure est « annulée » dans la procédure inverse

20 dependsOn 0..*

21 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 d’instruction à un logiciel Ex: ExecuteJava() avec le SoftwareType JRE Tout logiciel utilisant ce type d’instruction doit dépendre de ce type de logiciel

22 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 d’un type de logiciel donné soient présentes dans le système Conformance par rapport au type 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

23 dependsOn 0..*

24 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

25 dependsOn 0..*

26 Sémantique de l’autonomie
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 d’Intention l’intention de l’« action » d’une politique (« post-condition ») Rapprochement avec un événement Déduction d’un graphe qui révèle entre autres les cycles

27 Machine Virtuelle DeployWare = FDF
Réification sous forme de composants (Fractal) Fine granularité Abstraction des mécanismes de base du déploiement protocoles d’accès distants et de transfert de fichiers, shells, commandes, variables… Infrastructure cible noeuds et hôtes distants, serveurs, terminaux mobiles…  3e préoccupation du déploiement: Expert Réseau Composition afin d’obtenir un composite symbolisant le processus de déploiement

28 FDF Composants de déploiement Ex. exécution d’une commande distante
String getLogin (); User: getPassword getPrivateKey Port: int getPort () ; Hostname: getHostname void execute( cmd_to_exec ); Shell: setVariable( name , value unsetVariable(name,value Protocol: send (command SH, CSH, Windows CMD… SSH, rlogin, telnet.…

29 FDF Composants « software » Liaisons entre composants = dépendances

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

31 Personnalités existantes
Systèmes à base de SOA SCA Tuscany, JBI PEtALS, BPEL (Orchestra, ActiveBPEL) Systèmes à base de JEE Geronimo, JOnAS, JBoss, Glassfish, JAR, EAR Outils Web Apache, Tomcat, WAR Systèmes à base de CORBA ORBs, OpenCCM Systèmes à base de Fractal Julia, Fractal ADL et RMI Outils Java Ant, JRE, VM pour mobiles Bases de données MySQL Services réseau OpenLDAP Systèmes d’exploitation virtuels QEMU

32 Console d’administration

33 Console d’administration

34 Le passage à l’echelle de FDF
FDF optimisé pour utilisation à large échelle Motifs d’architecture Factorisation des définitions Opérationnalisation partielle de nos travaux sur les motifs d’architecture [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.)

35 Expériences / Mesures

36 Expériences / Mesures

37 L’autonomie dans FDF Composants spécifiques pour l’autonomie
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 l’exté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 qu’il réifie (i.e. le système) Grâce à la réflexivité de Fractal

38 Travaux relatifs Générique Granularité Logicielle Abstraction
Validation Autonomie JADE/JASMINe Oui mais dur (API Java) Oui ADL Non Bas niveau TUNe Méta-modèle (Profil UML) Etat/Transition UML J2EEML Non – EJB Seulement (DSML) Code généré SmartFrog API Java ORYA (?) DeployWare (DSML & UML) OUI Oui (EOD)

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

40 Conclusion (2) Méta-modèle existe (mais pas encore disponible)
Plugin Eclipse pour la création de modèles DeployWare Validations implémentées avec Kermeta Plate-forme FDF existe (et disponible) ~ 25 personnalités/technologies différentes Adopté et intégré dans JOnAS, PEtALS, JASMINe. Prototype prouvant la faisabilité de la transformation de modèle Modèle DeployWare -> Composants FDF

41 Perspectives Scientifiques
Explorer davantage la méta-modélisation Ajout de sémantique dynamique au méta-modèle Capacité de simuler l’exécution des modèles sans tester le déploiement Évaluer les performances théoriques Optimiser le fonctionnement Parallélisation maximale Ajout d’autres préoccupations dans le méta-modèle Gestion transactionnelle du déploiement ?  Continuer d’accroître la « maîtrise » du processus de déploiement

42 Perspectives techniques
Continuer l’opérationnalisation du méta-modèle avec Kermeta Ajout de la sémantique opérationnelle du méta-modèle pour la simulation Approfondir/Évaluer/Optimiser les mécanismes d’autonomie sur cas d’études Pour l’ubiquitaire Pour les grilles de calcul

43 Merci Questions ? Suggestions ? Critiques ?