séminaire interne adam – 19 octobre 2007 – lille

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 !

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

2020


• 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

2323


• 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

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

séminaire interne adam – 19 octobre 2007 – lille

Documents