Agents in Grid - PowerPoint PPT Presentation

agents in grid n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Agents in Grid PowerPoint Presentation
Download Presentation
Agents in Grid

play fullscreen
1 / 34
Agents in Grid
136 Views
Download Presentation
jonah
Download Presentation

Agents in Grid

- - - - - - - - - - - - - - - - - - - - - - - - - - - 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