Surveillance contextuelle des ressources distribuées S. Ravelomanana, M. Sibilla Université P. Sabatier, Laboratoire IRIT Toulouse, France raveloma@irit.fr, sibilla@irit.fr

La gestion des grilles Performances, disponibilité, Répartition de charge, tolérance aux pannes De part sa vocation une grille se doit d’être performante, fiable et disponible. Et pour cela, on doit mettre en œuvre des mécanismes comme la répartition de charge ou encore tolérance aux pannes . Et pour réaliser ces fonctionnalités qui sont assez complexes, on met en place du monitoring Surveillance Consistante, distribuée, en temps réel

Constats Approches et outils: Observation: Grid Monitoring Architecture/GGF Monitoring and Discovery System/Globus toolkit Ganglia Observation: l’état d’un système est traité indépendamment de l’état des autres les influences des événements qui surviennent ne sont pas traitées automatiquement Pour répondre à ces questions, nous avons étudié des architectures et outils de surveillance des grilles. Nous avons concentré principalement nos recherches sur: GMA: Grid Monitoring Architecture qui a été proposé par le groupe GGF: global grid forum qui est un organisme de standardisation des grilles. MDS: Monitoring Directory Service conçue par les concepteurs de Globus toolkit qui est l’outil le plus utilisé dans le domaine Puis enfin nous avons décidé d’étudier les outils du projet GRID’5000, dans lequel nous menons nos expérimentations

La surveillance contextuelle DEFINITION Surveiller une entité en tenant compte de son environnement d’exécution BESOINS Un Modèle Informationnel, qui représente l’entité gérée, son environnement d’exécution et les relations entre eux. Un Modèle d’événement pour modéliser, lever et s’abonner à un événement Un Modèle de Comportement pour lier les deux modèles afin d’automatiser les aspects dynamiques de la surveillance Pour combler ces lacunes, nous proposons la surveillance contextuelle. La surveillance contextuelle consiste à surveiller une entité dans son environnement d’exécution. C’est-à-dire prendre en compte les influences de l’environnement d’exécution sur l’entité gérée, et donc gérer les dépendances entre l’environnement et l’entité. Et en plus prendre en compte les événements qui surviennent et qui peuvent influencer l’état de l’entité gérée. Prenons maintenant un petit exemple. On a ici des services qui tournent sur des machines interconnectées par un petit réseau et accessibles depuis l’extérieur via un routeur. Du point de vue de l’utilisateur si le routeur ne marche plus, les services ne sont plus accessibles. C’est ce genre d’expertise que nous avons automatisé ... Approche conduite par les modèles

Modélisation CIM/DMTF Common Information Model Modèle Informationnel Extract from CIM Meta-Model   NamedElement Modèle Informationnel Modèle d’événement Class CIM_ManagedElement CIM_ManagedSystemElement OperationalStatus Status ElementName CIM_Dependency CIM_Component Association Indication CIM_Component Antecedent : REF Dependent : REF CIM_Dependency CIM_Indication TMN Service Systèmes&Réseaux Éléments   CORE Extract from CIM Core schema Application Network System COMMON

Modélisation Diagramme Etat Transition [IRIT/SIERA] CIM CORE Model CIM_ManagedElement CIM_ManagedSystemElement OperationalStatus Status ElementName CIM_Dependency CIM_Component CIM CORE Model Ready Down Busy anElement state diagram Modèle de Comportement class Sercive { actions ("start", ”stop"); state Ready { on enter { BEGIN_JAVA // your specific behavior //END_JAVA } } // end of state Ready state Down { // your specific behavior //END_JAVA } } // end of state Down } // end of >Provider state description Grammaire CNES

La vue « nœud » MODELISATION INFORMATIONNELLE DES GRILLES La vue nœud représente un nœud de la grille. Un nœud est identifié par un UnitaryComputerSystem et peut avoir un ou plusieurs Processor, OperatingSystem et des FileSystem. Un nœud exécute aussi des tâches, mais nous nous sommes surtout intéressés sur la partie physique. Un modèle complet de la gestion de tâches est proposé par le groupe Job Submission Information Model du GGF.

La vue “Grille” MODELISATION INFORMATIONNELLE DES GRILLES Nous présentons maintenant la vue cluster. Un cluster est identifié par la classe Cluster qui a été déjà dans CIM, et plusieurs ComputerSytem et ses descendants peuvent participer à un cluster.

La vue « Réseau » MODELISATION INFORMATIONNELLE DES GRILLES La vue réseau représente un lien de communication entre deux systèmes informatique. Nous avons ici choisi de le modéliser logiquement, un lien est un regroupement de protocolEndPoint qui est accessible via un NetworkPort. Et pour rassembler les informations concernant le lien et son état, on a mis en place la classe IRIT_Link.

Exemple d’interconnexion de grilles MODELISATION INFORMATIONNELLE DES GRILLES Exemple d’interconnexion de grilles Voici maintenant un exemple d’interconnexion de clusters. À droite il y a la grille qui est composée de deux grilles locales. Le switch S2 est représenté en CIM par un ComputerSystem et possède un ou plusieurs NetworkPort. Puis la communication entre le switch S2 et le router R2 est représenté par le regroupement de ProtocolEndPoint. Et le Router de sortie R2 comme le S2 est représenté par un ComputerSystem et peut aussi avoir un ou plusieurs NetworkPort. Puis il y a la communication entre les deux router et le router R1.

La modélisation du comportement MODELISATION INFORMATIONNELLE DES GRILLES La modélisation du comportement Identification des règles de comportement Si la charge moyenne des processeurs d’un nœud atteint les 80%  les processeurs et le nœud passent à l’état « dégradé » Si k% des grilles locales sont « dégradées »  la grille nationale passe à l’état « dégradé » Si le service d’accès (le service d’authentification par exemple) de la grille locale est tombé  elle sera inaccessible pour ses utilisateurs … Maintenant nous rentrons dans la modélisation du comportement. Mais pour ce faire, nous avons d’abord identifié des expertises de gestion comme : Si la mémoire d’un nœud est saturée à 80%  l’état du nœud passe à « dégradé  » Si k% des clusters sont « dégradé »  la grille qu’ils composent passe à l’état « dégradé » Si le service d’accès (le service d’authentification par exemple) à la grille locale est tombé  elle sera inaccessible pour ses utilisateurs Plusieurs expertises de ce genre ont été identifiées mais ici nous n’avons présenté que ces trois.

Modélisation de la règle 1 Si la charge moyenne des processeurs d’un nœud atteint les 80%  le processeur et le nœud passent à l’état « dégradé » Processor.loadPercentage>80 ProcessorChange ComputerSystem.Status=Normal

Description textuelle de la règle 1 class CIM_Processor { set ( {"LoadPercentage", "LoadPercentage"} ); state Degraded{ transition ( "Normal" ) { on change_event ( BEGIN_JAVA (Integer.parseInt(LoadPercentage)<80) //END_JAVA ), {BEGIN_JAVA System.out.println(« OK »); }; } } // end of state Degraded state Normal{ transition ("Degraded"){ (Integer.parseInt(LoadPercentage)>80) //chercher le CS associé au Processor CIMInstanceObservable [] associationsCSP =_omf.getAssociationOfClass(_context,"CIM_ComputerSystemProcessor"); String objectPathCS=""; if(associationsCSP.length==1){ objectPathCS =associationsCSP[0].getCIMInstance().getProperty("GroupComponent").getValue().getValue().toString(); _omf.setProperty(objectPathCS ,"Status",new CIMValue( "Degraded" ,new CIMDataType( CIMDataType.STRING) )); javax.swing.JOptionPane.showMessageDialog(null,"Le CS associé passe à Dégradé"); }else{ javax.swing.JOptionPane.showMessageDialog(null,"la charge moyenne est "+moyenneDesCharges); } // end of state Degrade } // end of class CIM_Processor definition Événement Condition Action

Observation Le modèle obtenu est applicable pour l’ensemble des grilles Une indépendance du modèle par rapport aux plates-formes de développement

Intégration et Implémentation State.jar Ready Down OM Plate-forme CAMELEON utilisation de Parser/Scaner MofJAVA/CORBA Chaque « Object Manager » possède les fonctions de gestion des états, gestion des Diagrammes états transitions et des événements  automatisation du traitement Composants d’intégration (Object Provider) À ce jour, différents plates-formes de développement existent mais cette approche basée sur les modèles est implémentée dans le produit CAMELEON fruit de la collaboration entre le CNES, ALCATEL et IRIT. CAMELEON possède un composant appelé composant de gestion qui renferme un référentiel. C’est un genre de base de données qui stocke les descriptions du modèle et ses instanciations. Pour garnir ce référentiel on utilise un Parser/Scaner qui transforme la description textuelle du modèle en code Java/Corba afin de l’injecter dans la plate-forme. Chaque composant de gestion possède les fonctions de gestion des états, des relations actives et des événements afin d’automatiser le traitement. C’est-à-dire qu’on décrit seulement dans le format MOF le modèle et ses instances, puis on passe le Parser/scaner enfin ceci est injecté dans la plate-forme et c’est ce dernier qui gère tout . D’un autre coté, il y a les composants d’intégration appelés Object Provider. Ils sont là pour reporter les informations du monde réel vers les composants de gestion. Nous avons dû développer l’OPGRID qui reporte les informations de la grille, et réutiliser les composants OPSNMP et OPUNIX. Une passerelle web services a été aussi développée pour faire communiquer la grille et les composants de gestion. Un agent a été programmé pour instrumenter les nœuds de la grille. Il peut aussi être supprimé et remplacé par un autre outil de surveillance. L’implémentation a été rapide due à la généricité de l’approche et à la réutilisation de certains composants.

Architecture OM Interface JAVA/CORBA Get Set Invoke … MgtFct° ססס ססס State.jar Ready Down Config État Relations Événement OM

UML State code generator Architecture OBJECT MANAGER UML Editor Classes & Instances Textual notation (MOF/DMTF) State.jar Ready Down OM Fichiers mof Cameleon MOF Parser objectX state diagram Ready Busy Down Cameleon UML State code generator Java classes Fichiers STATE (grammaire CNES)

Object Provider OM OM OM Existant Développé À Développer Intégration State.jar Ready Down OM State.jar Ready Down OM State.jar Ready Down OM Existant Développé À Développer Intégration OPCorba OPUNIX OPSNMP OPNode OPNWS A A Instrumentation A CORBA Réseau

Démonstration Résultat: Une vue des informations de la grille

Démonstration Résultat: Dégradation de l’état d’un nœud

Démonstration Résultat: Dégradation de l’état de la grille locale

Bilan des expérimentations et résultats MONITORING Création automatique des vues « Nœud » et « Grille » par découverte Contrôle automatique des influences : Nœud  Composants (Charge,Mémoire,espace disque,…) Nœuds  Grille Locale (Disponibilité, accessibilité) Grille  Réseau (Perte de lien, défaillance de composant réseau) Délégation de la surveillance réseau à une plate-forme de gestion telle que OpenView et intégration des alarmes réseaux (trap SNMP, événements propriétaires) auprès des OMs de la grille Prise en compte d’événements hétérogènes dans les diagrammes État/Transition Le résultat d’interprétation des diagrammes E/T est liée au contexte découvert Gestion d’états composite: Test validé à moyenne échelle (DMTF draft) Limite de la généricité des diagrammes État/Transition Spécialisation/Personnalisation des diagrammes E/T Intégration dans le processus de développement MODELISATION DE LA DYNAMIQUE

PUBLICATIONS A Contextual GRID Monitoring by a Model Driven Approach. S. Ravelomanana, S. C. S. Bianchi, C. Joumaa, M. Sibilla. AICT2006, SAPIR 2: Monitoring Interactions. 19-22 Febuary, 2006. Gestion des grilles : Surveillance Contextuelle de la QoS par une approche conduite par des modèles. M. Ravelomanana. GDR ASR. 2ième journée de l'action ADAPT«  Adaptation dynamique aux environnements d’exécution ». 6 avril 2006. ENST, Paris. DMTF Behavior and State Specification (GRID statechart diagram examples). Draft document. en cours de rédaction. Unified model based three dimensional tool for managing computer networks. M. Dodo, P. Torguet, M. Sibilla, J.-P. Jessel. WEBIST 2006 – 2nd International Conference on Web Information Systems and Technologies, Setúbal, Portugal, 11 avril 13 avril 2006.

Conclusion Création dynamique des contextes d’exécution chaque ressource, et réutilisation des spécifications formelles associées Réactivité à travers les actions que l’ont peut exécuter lorsqu’une ressource passe dans un état donné  Proactivité : déduction d’influence avant constat  Exemple: rediriger les jobs vers d’autres ressources tant que l’état de la ressource demandée est dégradé, afin qu’elle puisse repasser à l’état normal. Affiner la connaissance d’exploitation des ressources par la modélisation du comportement. Automatisation et réutilisation d’expertises de gestion. Ouverture de la solution à d’autres fonctionnalités : La tolérance aux pannes Disponibilité Facturation Gestion de la qualité de service (coté client, coté administrateur de la grille)  Jusqu’ici, nous avons obtenu une vue Vues standards des grilles et des informations de gestion associées c’est-à-dire des état, relations etc.. Le choix des dépendances actives pour la partie expérimentale offre une base suffisante dans un premier temps. Et en suivant les phases de l’approche Modelware, la surveillance contextuelle des grilles a été facile et rapide à réaliser. Les dépendances actives sont en phase de test. Et on espère étendre la surveillance contextuelle à l’échelle nationale.

Perspectives Prise en compte des dégradations de la qualité de service. Déploiement au niveau national (sujet Master) Représentation 3D avec animation de la dynamique (sujet de Doctorat). Intégration dans des middlewares de placement Surveillance du middleware lui-même.

Merci

Les Composants de l’Architecture DEPENDENCY CAMELEON CORBA CORBA CORBA OM OPENVIEW OM SERVICES Object Provider NNM Evènement Serveur NNM CLIC D’un côté nous disposons de la plate-forme CAMELEON qui assure la gestion des services ainsi que la corrélation de dépendances. Deux Objects Managers distincts disposent de ces informations de gestion. D’un autre côté nous avons la plate-forme OpenView. Pour réaliser l’intégration de cette plate-forme dans CAMELEON, deux possibilités étaient envisageables: enrichir la plate-forme OpenView elle-même en intégrant un programme capable d’envoyer ses évènements, ou configurer les évènements au cas par cas. Cela montre bien une volonté d’intégration des outils, mais pas d’ouverture. Mais dans tous les cas, un Object Manager de CAMELEON doit offrir une vue des entités gérées par OpenView. Enfin une dernière entité jouant le rôle de passerelle est nécessaire pour faire correspondre les deux modèles d’informations source et cible. Un serveur CORBA extérieur au deux plates-formes est déployé. Il est capable de recevoir les évènements d’OpenView et de les aiguiller vers la plate-forme CAMELEON. Ce serveur étant indépendant des outils de gestion, il peut aiguiller les informations vers d’autres systèmes d’information. Nous allons maintenant détailler la phase de configuration de la plate-forme OpenView. Domaine Service Evènement Domaine Réseau NNM OpenView 27

Présentation de la Démo À chaque nœud on associe un Agent en JAVA/CORBA Enregistrement de chaque Agent NamingService Découverte des nœuds et leurs caractéristiques A

Monde Réel Supervision IHM Requête Réponse OPNode OMGrid A State.jar Ready Down Réponse OMGrid A Supervision