1 / 34

Agents in Grid

Agents in Grid. The Grid. Power grid – plug the appliance and use electric power pay for used “units of electricity” Computational Grid – plug the computer and use available resources pay for used “units of computing” Example: you do not need to buy MATLAB

jonah
Download Presentation

Agents in Grid

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Agents in Grid

  2. The Grid

  3. Power grid – plug the appliance and use electric power pay for used “units of electricity” Computational Grid – plug the computer and use available resources pay for used “units of computing” Example: you do not need to buy MATLAB you pay “3 cents” for an hour of its usage Sun wants $1 per hour – too much! Grid – introduction

  4. Local vs. global Grid • Local Grid • company / laboratory / EU-project • each node / group  has administrator • node existence “assured” • no actual economical model involved • Global Grid • collection of nodes • seti@home • no (centralized) administration • no assurances (existence / load of nodes) • how to facilitate SLA / QoS ? • economical model necessary

  5. Agents in Grids Today • B. Di Martino and O. Rana • static and mobile agents in the system (MAGDA) • static agents located within Grid nodes • mobile agents visit nodes to find resources (services) • visits based on exchanges of messages with nodes • execute a task or a part of it • AGLETS-based / no economic model • S. Manvi et. al. • attempt at adding economic model • singleagent moves, negotiates, executes • heavily based on mobility

  6. Comments • Single resource provider • “cleaning lady problem” • difficult to assure QoS / SLA • More generally • Grid is expected to be very dynamic • nodes appear and disappear • node-loads change “fast” • economic model is necessary • Mobility can be costly – what do you carry? • Proposed solution  agent teams • team based approaches seem to gain popularity

  7. Assumptions • Agents work in teams • Each team has a team leader (local master – LMaster) • Incoming workers (LAgents) can join any team based on their criteria of joining • Teams can accept workers based on their own criteria of acceptance • Each LAgent can (if needed) play role of an LMaster • Decisions about joining and accepting will utilize multi-criterial analysis • Yellow-page method for matchmaking (provided by the CIC agent)  other approaches possible

  8. Use Case of the System

  9. Finding Team to ... • LAgent checks with the CIC who • it can join • does the work it needs • LAgent negotiates with LMaster • LAgent makes decision • which team to join • which team will do the job • LAgent and LMaster collect data to be used to adapt behavior • Structure similar to the e-commerce system • CIC plays critical role

  10. Agents in Grid Ontologies

  11. Resource Ontology (1) • Lack of all agreed ontology of the Grid – work in progress • Semantic Web • Grid systems specific efforts (e.g. Unicore) • domain specific efforts • AGIO – Montpellier • Decision  utilize a simplistic ontology • when all-agree ontology will be created systems will be easily adjustable

  12. :hasMemory :a owl:DatatypeProperty; rdfs:comment "in MB"; rdfs:range xsd:float; rdfs:domain :Computer. :hasUserDiskQuota :a owl:DatatypeProperty; rdfs:comment "in MB"; rdfs:range xsd:float; rdfs:domain :Computer. :LMaster :a owl:Class; :hasContactAID :a owl:ObjectProperty; rdfs:range xsd:string; rdfs:domain :LMaster. :hasUserDiskQuota :a owl:DatatypeProperty; rdfs:comment "in MB"; rdfs:range xsd:float; rdfs:domain :Computer. Resource Ontology (2) :Computer :a owl:Class. :hasCPU :a owl:ObjectProperty; rdfs:range :CPU; rdfs:domain :Computer. :CPU :a owl:Class. :hasCPUFrequency :a owl:DataProperty; rdfs:comment "in GHz"; rdfs:range xsd:float; rdfs:domain :CPU. :hasCPUType :a owl:ObjectProperty; rdfs:range :CPUType; rdfs:domain :CPU. :CPUType :a owl:Class. Intel :a :CPUType. AMDAthlon :a :CPUType.

  13. Resource Ontology Instance :LMaster3 :hasContactAID "monster@e-plant:1099/JADE"; :hasWorker :PC2929. :PC2929 :a :Computer; :hasCPU [ a :CPU; :hasCPUType :Intel; :hasCPUFrequency "3.7"; ] ; :hasUserDiskQuota "4000"; :hasMemory "512".

  14. SPARQL query – querying the CIC PREFIX : <http://www.ibspan.waw.pl/mgrid#> SELECT ?contact WHERE { ?lmaster :hasContactAID ?contact; :a :LMaster; :hasWorker [ :a :Computer; :hasCPU [ a :CPU; :hasCPUType :Intel; :hasCPUFrequency ?freq; ]; :hasUserDiskQuota ?quota; :hasMemory ?mem; ]. FILTER (?freq >= 3.2) FILTER (?quota >= 3500) FILTER (?mem >= 512) }

  15. Agents in Grid Finding team to do the job

  16. Scenario • User specifies requirements for job execution • LAgent communicates with the CIC • obtains list of potential agent teams • Utilizes FIPA Contract Net Protocol to obtain job execution proposals • Eliminates teams that submitted proposals violating constraints • Evaluates remaining proposals using a simple linear additive model • Submits the job to selected team

  17. FIPA Contract Net Protocol Interactions

  18. Example (1)

  19. Example(2)

  20. Agents in Grid Finding team to join

  21. Scenario • User specifies requirements for team joining • LAgent communicates with the CIC • obtains list of potential agent teams • eliminates those that are not trustworthy • Utilizes FIPA Contract Net Protocol to obtain team joining proposals • Evaluates them using • best price as criterion – now • muticriterial analysis – in the future • Confirms team joining

  22. SPARQL Query PREFIX Grid: <http://Gridagents.sourceforge.net/Grid#> SELECT ?team WHERE { ?team Grid:needs ?machine . ?machine Grid:hasCPU ?cpu ; Grid:hasMemory ?mem ; Grid:hasQuota ?quota . FILTER ( ?cpu <= "3.7"^xsd:float ) . FILTER ( ?mem <= “512"^xsd:integer ) . FILTER ( ?quota <= “4000"^xsd:integer ) . }

  23. FIPA Contract Net Protocol Interactions

  24. CFP structure and content (cfp :sender (agent-identifier :name proteus@bach:1099/JADE)‏ :receiver (agent-identifier :name zerg@chopin:1099/JADE)‏ :content ((action (agent-identifier :name zerg@chopin:1099/JADE)‏ (take-me :configuration (hardware :cpu 3.7 :memory 512 :quota 4000)‏ :conditions (condition :availability (every-day :when (period :from 00000000T23500000 :to 00000000T08150000))‏ :contract-duration +00000007T000000000))‏ :language fipa-sl0 :ontology joining-ontology :protocol fipa-contract-net )‏

  25. LMaster response preparation • Similar to United Devices system scoring • Base system price • processor speed Pb  Pc • available memory Mb  Mc • available disk space Db  Dc • Bc = Pc + Mc +Dc • where α – overhead

  26. Running the system “today”

  27. Security, trust and reputation • Security  ability to send, receive and process information without unauthorized entities having access to it • Trust  peer’s belief in another peer’s capabilities, honesty and reliability based on own direct experiences • Reputation  as the above, but based on other peers believes • In the Grid  given node can assure secure computational environment, but may not be trusted, and/or have a bad reputation

  28. Trust in interactions user  team (1) • Team evaluating potential User • User that did not pay in the past should be excluded • like in e-commerce (e.g. eBay) • proxy payment system as a natural solution • PayPal • no further trust related issues necessary

  29. Trust in interactions user  team (2) • User evaluating team (x) • based on satisfaction of contract (service level agreement) • fulfillment of contract and each violation of contract (ei) has weight TA(ei)  [-α , α] associated with it • we can calculate trust score as follows Tn(x) = (1 - α|TA(ei)|) Tn-1(x) + TA(ei) α – “sensitivity” of a given User Trust(x) = (Tn(x), n, # of “negative events”) • Trust(x) used in evaluating offers from LMasters

  30. Trust in interactions worker  team (1) • Worker evaluating team • based on contract (service level agreement) • worker sells time • number of actual work does not matter • money paid for contracted time as promised • may need PayPal-type solution • overhead (α) to pay for non-working team members • based on work actually done • complicated issues arise • workers cheating in reporting time used • dynamic nature of incoming work-orders • one time a lot of work • next time nothing to do

  31. Trust in interactions worker  team (2) • Team evaluating worker • based on contract  worker “sells time” • assumption  within contract established acceptable violations • e.g. network downtime cuts off a worker for 2 hours • three situations possible • violated contract (vc) • fulfilled contract (fc) • did more than just fulfill it (ee) • worker score – triple (#vc, #fc, #ee) • used in reasoning to foresee worker “potential”

  32. Testing aliveness of team members

  33. Reputation – “under construction” • eBay model suggested • reputation is shared information about performance of worker / team • all agents / agent teams have to be registered with the CIC • CIC as the central repository of evaluations • reputation score – value from interval [0-5] • reputation score can be a part of CIC response to the LAgent • P2P model possible • LAgent asks “friends” about reputation of teams

More Related