séminaire interne adam – 19 octobre 2007 – lille
DESCRIPTION
DeployWare : Une approche à base de modèles pour un déploiement fiable en environnements ouverts distribués. Jérémy Dubus , Philippe Merle [email protected] , [email protected] LIFL - GOAL Team INRIA ADAM Project Laboratoire d’Informatique Fondamentale de Lille UMR CNRS 8022. - PowerPoint PPT PresentationTRANSCRIPT
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 [email protected] , [email protected]
LIFL - GOAL TeamINRIA ADAM Project
Laboratoire d’Informatique 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 d’exé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 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
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 d’administration autonome
66
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 »
77
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
88
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 ?
99
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
1010
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
1111
Le méta-modèle DeployWare
• Déploiement distribué– Préoccupations transverses !
• Architecture globale du système – Configuration des logiciels, administration au runtimeAdministrateur système
• Définition de la procédure de déploiement d’un logiciel– Packaging des applications, description des actions
élémentaires de déploiementExpert logiciel
• Description du support matériel– Protocole d’accès à distance, transfert de fichiersExpert réseau
• Volonté de séparation des préoccupations
1212
Le paquetage de l’expert logiciel
1313
Le paquetage de l’admin système
_______Paquetage TechnoExpert _______
1414
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
1515
Le paquetage d’autonomie
• Les actions manipulent les concepts du méta-modèle
1616
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 !
1717
1818
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
1919
2020
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
2121
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
2222
2323
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
2424
2525
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
2626
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
2727
String get_login();User: String get_password();
String get_private_key();
Port: int get_port_number();
Hostname: String get_hostname();
void execute(cmd_to_exec);Shell: void setVariable(name,value);
void unsetVariable(name,value);
Protocol: void send(command);
FDF
• Composants de déploiement – Ex. exécution d’une commande distante
SH, CSH, Windows CMD…
SSH, rlogin, telnet.…
2828
FDF
• Composants « software » (personnalités)– Liaisons entre composants = dépendences
2929
Contribution Overview
DeployWareADL file
DeployWareExplorer
Deployment
Configuration
Software Components
Deployment Components
Physical Infrastructure
3030
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.)
3131
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
3232
Travaux relatifs
Générique
Granularité
LogicielleAbstractio
n
Validation/Si
mulation Autonomie
JADE/JASMINe
Oui - mais dur
(API)
Oui sauf JADENod
es Composant Non Bas niveau
TUNe Oui Oui Profil UML NonEtat/Transition
UML
J2EEML
Non - EJB seulem
ent Non DSML Non Code généré
SmartFrog Oui NonNon - API
Java Non Non
ORYA OuiNon / Pas de
proj exe Méta-modèle NonNon / Pas de
proj exe
DeployWare Oui Oui DSML OUI Oui (EOD)
3333
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
3434
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
3535
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
3636