SNAP : A Protocol for Negotiating Service Level Agreement and Coordinating Resource Management in Distributed Systems

Transcription

1 Fournel Nicolas DEA DISIC SYC2 SNAP : A Protocol for Negotiating Service Level Agreement and Coordinating Resource Management in Distributed Systems Karl Czajkowski, Ian Foster, Carl Kesselman, Volker Sander et Steven Tuecke I Introduction Dans les systèmes distribués tels que les Grids, un besoin commun est l'obtention de l'accès aux ressources ainsi que leur gestion. Ces ressources sont réparties le plus souvent dans des domaines adminitratifs différents de celui du demandeur. Dans ce processus, les besoins en compétition du client et du propriétaire des ressources compliquent les choses. Le client requière un certain nombre d'informations concernant ces ressources pour guarantir, par exemple, un certain niveau de QoS. Le propriétaire, lui, désire conserver le contrôle de ces ressources. Une solution à ce problème est la négociation de contrats entre les deux partis. Ces contrats sont des SLA, que nous décrirons dans une première partie. Nous présenterons ensuite le protocole proposé par les auteurs, SNAP. Enfin nous aborderons la problématique de l'implémentation de ce protocôle. II Les Service Level Agreement (SLA) Ces accords sont négociés entre le client et un fournisseur de ressource, et permettent la réservation d'une capacité mesurable ou la soumission d'une tâche à

2 accomplir. Les auteurs proposent trois types de SLA pour résoudre le problème de la répartition des ressources dans une grille de calcul. Ces trois types sont : Task Service Level Agreement (TSLA) : négociation de la réalisation d'une tâche. Resource Service Level Agreement (RSLA) : négociation de l'obtention du droit d'utiliser une ressource. Binding Service Level Agreement (BSLA) : négociation de l'application d'une ressource à une tâche. Le modèle de SLA proposé est indépendant du service géré, en fait, la sémantique du service n'est pas véhiculée par le type de SLA mais par le contenu et les détails de ce SLA. Cette généricité permet aux auteurs de faire référence au protocole de négociation de ces SLA comme Service Negotiation and Acquisition Protocol (SNAP). III SNAP L'architecture SNAP est basée sur une organisation Client-Service. En effet, chaque opération suit un modèle de communication assimilable au RPC (Remote Procedure-Call). 1) Transitions d'états Dans le protocole SNAP, les auteurs dénombrent quatres états : S0 : Aucun SLA ou, expiration ou annulation des SLA. S1 : Existence de TSLA et de RSLA mais non liés les uns aux autres. S2 : Existence de BSLA, correspondance entre un TSLA et un RSLA. S3 : Utilisation des ressources, execution réelle de la tâche. Ces quatres états s'organisent de la manière suivante : Transitions d'états Comportement interne du manager. Action du client

3 2)Contenu des SLA Tous les SLA ont le même contenu, il est composé de : I un identifiant c le nom du client avec lequel le SLA est passé t dead une date d'expiration d une description spécifique au type de SLA (TSLA, RSLA ou BSLA) Pour definir le contenu du champ description, un langage extensible est envisagé. A vrai dire, deux langages sont définis mais un des deux est un sousensemble du second. Tout d'abord, on remarque que en ce qui concerne le RSLA, le langage doit permettre la description des ressources, alors que dans le cas des T/BSLA, on doit pouvoir présenter la description des tâches, y compris la description des besoins. On nommera donc le langage de description des ressources R, qui est un sousensemble du langage de description des tâches J. Dans ce dernier langage, on peut remarquer que l'on peut référencer un RSLA dans une descritpion en J. Les auteurs définissent sur ce langage deux opérations principales permettant de gérer cette inclusion, par exemple. 3)Opérations dans le protocole Pour la négociation des SLA, sujet même du protocôle, les auteurs définissent un certain nombre d'opérations : Allocation d'identifiant getident(t dead) : permet à un client d'obtenir un identifiant valable jusqu'à t dead. useident(i, t dead) : reponse du manager. Opération d'accord request(i,c, t dead,a) : permet à un client de négocier un SLA de desciption a. agree(i,c, t dead,a') : reponse du manager, qui accorde a'. Opération de modification d'échéance setdeath(i, t dead) : permet à un client de changer l'échéance du SLA. willdie(i,t dead) : reponse du manager. Dans ce protocole, on permet au client de renégocier son accord en réutilisant l'opération request(i,c, t dead,a). Le manager doit être capable de déterminer s'il s'agit d'un

4 nouvel accord, d'une vérification ou d'une mise à jour. IV Langage de description Comme présenté précédement, les auteurs définissent un méta-langage qu'ils nomment J, celui-ci joue un rôle important dans le protocole. Ils ne spécifient pas une syntaxe concrète, mais apportent les structures minimales que doit comporter ce langage. Une des caractéristique de ce langage, avant toute chose, est qu'il doit être extensible dynamiquement. Le langage est donc défini de la manière suivante : Métrique de ressource : - temps - scalaire x u (x valeur réelle, u unité) - limite maximum - limite minimum Composites - Set [r 1, r 2,...] combinaison de ressources. - Typed Set [r 1, r 2,...] type combinaison de ressource spécifique à un type. - Array n x r combinaison de n ressources identiques. Séquence temporelle r=[[r 1 ] [t 0,t 1 ],[r 2 ] [t 1, t 2 ],,[r n ] [t n 1,t n ] ] [t 0,t n ] Alternative Alternative V(r 1,r 2,...) une seule ressource est choisie dans la liste. Configuration de ressource Configure a:=v spécifie une configuration arbitraire d'un attribut a qui doit avoir la valeur v. On peut noter qu'il s'agit du point qui différencie J de R. Lien RSLA Comme dit précédement, dans un T/BSLA on peut référencer un RSLA en J : RSLA Binding [r,i B] bind V Implémentation de SNAP Cet article ne fait que définir un modèle de Gestion de Ressource/Service, il n'est pas question d'une implémentation.celle-ci est toutefois envisagée mais pas décrite dans cet article. Cependant les auteurs fournissent un certain nombre de principe nécéssaire pour cette implémentation. Une première chose est que les auteurs n'envisagent pas une implémentation de ce protocole seul, mais au dessus d'une couche fournissant des fonctions de base. L'implémetation envisagée s'appuyerait sur OGSA (Open Grid Services Architecture). Elle s'appuyerait donc sur des Services tels que : Authentification et Controle d'acces,

5 Monitoring, Decouverte de ressource et de service,... VI Conclusion Le modèle proposé par les auteurs est un modèle extensible et relativement ouvert, c'est à dire que la manière de traiter les informations du protocole n'est pas fixé par les auteurs, mais reste à définir pour l'implémentation. Un autre point fort du modèle est son extensibilité. Cependant ce modèle n'est pas validé. Ce qui nous permet de penser qu'il est bon, est qu'une majorité des concepts est issu d'experiences précédentes des auteurs (GRAM/GARA autour de Globus).