Séminaire Interne ADAM – 19 octobre 2007 – Lille

1. DeployWare : Une approche à base de modèles pour un déploiement 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 Séminaire Interne ADAM – 19 octobre 2007 – Lille

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

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 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

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. 1er Challenge : Expression • Comment exprimer le déploiement de systèmes hétérogènes • Comment exprimer • 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

8. 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 ?

9. 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

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 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

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 d’un logiciel • Packaging 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

12. Le paquetage de l’expert logiciel

13. Le paquetage de l’admin 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 d’autonomie • Les actions manipulent les concepts du méta-modèle

16. 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. 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. 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

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 d’un 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

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

25. 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

26. Machine Virtuelle DeployWare = FDF • Réification sous forme de composants (Fractal) • Plus fine granularité que d’autres approches (JADE) • 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

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

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

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

30. Le passage à l’echelle de FDF • FDF optimisé pour utilisation à large échelle • Motifs d’architecture • 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. 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

32. Travaux relatifs

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 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

34. 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 • Evaluer 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

35. Perspectives personnelles • Continuer l’opé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 d’autonomie • Pour l’ubiquitaire (Projet CAPUCCINO) • Pour les grilles de calcul • Se positionner par rapport aux mesures classiques de l’AC • Écrire une thèse sur tout ça 

36. Merci Questions ? Suggestions ? Critiques ?