JTE Systèmes Autonomes – 16 Novembre 2007 – Toulouse

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

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

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

30. Configuration DeployWareExplorer DeployWareADL file Software Components Deployment Components Deployment Physical Infrastructure Contribution Overview

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

39. Conclusion • Approche de type MDE pour le déploiement • 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) • http://gforge.inria.fr/fdf • ~ 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 ?