CONGENITAL HEART DEFECTS DR. HANA OMER. CONGENITAL HEART DEFECTS D. HANA OMER.
1 Choosing a Load Balancing Scheme for Agent-Based Digital Libraries Christos Georgousopoulos and...
-
Upload
julie-mccoy -
Category
Documents
-
view
214 -
download
1
Transcript of 1 Choosing a Load Balancing Scheme for Agent-Based Digital Libraries Christos Georgousopoulos and...
1
Choosing a Load Balancing Scheme for Agent-Based Digital Libraries
Christos Georgousopoulos and Omer [email protected]
Cardiff University and Welsh e-Science Centre
http://www.cs.cf.ac.uk/http://www.wesc.ac.uk/
Joint Project: Giovanni Aloisio, Masimo Caffaro (University of Lecce, Italy) and Roy Williams (CACR, Caltech, US)
2
Earth Observation System
Final Users
Dissemination
Acquisition
Processing
Tapes
Metadata
Archiving
NASAESA ASI
Space Agencies
DLR
3
system architecture
user
UPAURA
GISGIS
UIAUIA
LIALIA
Data Archive
LIALIA
UIA: User Interface AgentURA:User Request AgentUPA:User Presentation Agent
UIA: User Interface AgentURA:User Request AgentUPA:User Presentation Agent
LIA: Local Interface Agent LIGA: Local InteGration Agent LAA:Local Assistant Agent LRA: Local Retrieval Agent LMA:Local Management Agent LSA: Local Security Agent
LIA: Local Interface Agent LIGA: Local InteGration Agent LAA:Local Assistant Agent LRA: Local Retrieval Agent LMA:Local Management Agent LSA: Local Security Agent
LMA LRALIGALAA LSA LMA LRALIGALAA LSA
4
Applications: Post-Fire Measurements
color scale:blue (rivers and lakes with no biomass) brown (non-forest areas with crown biomass of less than 4 tons/ha) light brown (areas of canopy burn with biomass of between 4-12 tons/ha) yellow (areas with a biomass of 20-35 tons/ha)green (forest with a biomass of greater than 35 ton/ha)
SIR-C/X-SAR L-band images of Yellowstone National Park, Wyoming obtained in 1994, six years following a major fire
in 1988.
map of the forest crown showing its biomass
SAR measurements of fire-affected regions can aid in monitoring forest regrowth after a fire
5
Lost city of UbarArabian Peninsula
Remote desert caravan oupost2800 B.C.-300 A.D.
Applications: Archeology
6
The FIPA interoperable SARA architecture
EXSA
URAS
URA
URA
AGENT ENVIRONMENT
AGENT ENVIRONMENT
LAA LRA
LMAUAA
UMA
LSA
LIGA
DB
FILEARCHIVE
COMPUTESERVER
META-DATA
URA
LAA LRA
LMA
LSA
LIGA
Web Server
Voyager platform
Voyager platform
FIPA-OS platform
FIPA-OS platform
EXSA
URA
AGENT ENVIRONMENT
UAA
UMA
Web Server
Voyager platform
FIPA-OS platform
CLIENT
EX MAS
EX MAS
CLIENT
EX MAS
Web SERVER 1
Information SERVER 1 Information SERVER 2
URAS
AGENT ENVIRONMENT
Voyager platform
FIPA-OS platform
EX MAS
Web SERVER 2
message exchange
creation of agent
Management agent’s interaction
movement
send/receive request
hidden architectural details
FIPA-compliant gateway
UIA: User Interface Agent
URA: User Request AgentUAA: User Assstant Agent
LIA: Local Interface AgentLAA:LMA:UMA:
LSA: LIGA: URAS: EXSA:
Local Assistant Agent Local Management AgentUniversal Management Agent
Local Security AgentLocal InterGration Agent
URA’s ServantExtermal Service Agent
LRA: Local Retrieval Agent
DB
FILEARCHIVE
COMPUTESERVER
META-DATA
7
Web Browser
Java Applet GUI
URA
ERS-1 Data in
Italy
LSA LAA LRA
UPA
1
2
3
75
9
10
LSA LAA LRA4
8
SIR-CImaging radar in
USA 6
URA
URA
URA
URA URA
Localhost
Mobile agents for data retrieving
8
Load Balancing Context
Multiple Information Servers available• Offer similar capability• Host “Management Agents”• How much intelligence in mobile vs. stationary agents?To which server should we send the mobile agent?
9
Load balance
mobile static
state model
Market mechanism
Specialized agentsgather System state
information
Aim: improve the average utilization and performance of tasks on available servers
Kinds of Load Balance (LB):
Keren & Barak:mobile LB has a
30-40% improvement over
the static placement scheme
• only a price• sophisticated auction protocols• a pricing mechanism without any negotiation
• roam through the network• bid for resources
Load Balancing
Must consider: (1) Number of agents/server; (2) Number of tasks/agent
10
State-based vs. Model-based Approaches
• State based• Gather system state (how much, how
frequently)• Use this to make mapping decisions(eg. Spawn, Dynast, OCEAN) – market based(montoring – eg Mats, Traveler)FLASH – a single (centralized) monitor that passes info to
nodes
• Model based• Attempt to predict system state – via a “model”• Use outcome of model as a means to make a mapping
decision(eg. Enterprise, Challenger (machine learning-based), etc)
11
Gathering System State
•Roaming/Scout agents•Agents look for free resources
•Report this back to nodes
•For “N” servers, requires “N-1” serialization and migrations
•Management agents•Specialist agents capture system state
•N *(N-1) message exchanges
•Reduce who to exchange state information with–“Direct Neighbour” vs. “All Neighbour” policy
12
Configuration Options
•100Mb/s network, 5 servers
•Local state info: 150 to 200 bytes–Number of active agents, utilization, resources available
•Initial agent size: 2.8KB (Voyager ORB)
•Message exchange time: 21ms to 36ms•Agent serialization time: 31ms to 47ms
•Migration time (+ time to store local state info): 564ms to 678ms
•Create reference to a proxy: 93ms to 125ms
13
Comparison Results
14
1
Efficiency Trade-off
•Each migration leads to potentially (N-1) messages:•(N-1) migration * (N-1) messages
•For N=44 roaming agent approach becomes more efficient
1 2 3 4
15
Our approach on LB
Provide a LB mechanism to evenly distribute agent tasks among the available servers
(i.e. equitably server the agents, there are no priorities between agents based on the time needed for their task to be accomplished)
We propose a LB mechanism based on a combination of the model-based and state-based approaches
(i.e. decisions on LB are based upon a model which adapts due to the information gathered from the state-based approach)
We demonstrate this approachfor a MAS operating on an active digital library composed of multi-spectral images of the Earth as part of the Synthetic Aperture Radar Atlas (SARA)
16
The SARA LB mechanism
State-based approach
Model-based approach
(4/4) Communication between management agents
(1/4) The management agents in the SARA architecture
(3/4) Information maintained by management agents
(2/4) Distribution of information among the management agents
(1/1) LB decision model
Delegate Load Balance Decision to the ManagementAgent (2 messages exchanges between mobile and managementagent)
17
Advantages of the proposed LB technique
LB decisions are supported by the management agents
Distribution of information between the management agents
More accurate LB decisions
(the variation of the global network map decentralized information distribution implies reduction of information replication)
(LB model uses the state-based information)
18
E X S A
U R A S
U R A
U R A
A G E N T E NV IR O N M E N T
A G E N T E NV IR O N M E N T
LA A LR A
LM AU A A
U M A
LS A
LIG A
D B
FILEA R C H IV E
C O M P U TES E RV E R
M E TA -DATA
U R A
LA A LR A
LM A
LS A
LIG A
W eb S erver
Voyage r p la tform
Voyage r p la tform
FIPA -O S p la tfo rm
FIPA -O S p la tfo rm
E X S A
U R A
A G E N T E NV IR O N M E N T
U A A
U M A
W eb S erver
Voyage r p la tform
FIPA -O S p la tfo rm
CLIENT
EX M AS
EX M AS
CLIENT
EX M AS
W eb SERVER 1
In form ation SERVER 1 In form ation SERVER 2
U R A S
A G E N T E NV IR O N M E N T
Voyage r p la tform
FIPA -O S p la tfo rm
EX M AS
W eb SERVER 2
m essag e exchang e
creation of a gent
M anagem ent agent’s in teraction
m ovem ent
sen d/rece ive req uest
h idden arch itec tura l deta ils
F IPA -com pliant g atew ay
U IA : User In terface A gent
U R A : U ser R equ est A gentU A A : U ser A sss tant A gent
LIA : Loca l In terface A g entLA A :LM A :U M A :
LS A : L IG A: U R A S : E X S A :
Loca l A ss istant A gent Local M ana gem ent A gent
U niversa l M anage m en t A g ent
Local S ecurity A gentLocal In terG ratio n A gent
U R A’s S ervantE xterm al S e rvice A gent
LR A : Local R etrieva l A gen t
D B
FILEA R C H IV E
C O M P U TES E RV E R
M E TA -DATA
EXSA
U R AS
U R A
U R A
AG EN T ENVIR O N M EN T
AG EN T ENVIR O N M EN T
LAA LR A
LM AU AA
U M A
LSA
LIG A
D B
FILEAR C H IVE
C O M PU TESERVER
M ETA-DATA
U R A
LAA LR A
LM A
LSA
LIG A
W eb Server
Voyage r p la tform
Voyage r p la tform
FIPA-O S platfo rm
FIPA-O S platfo rm
EXSA
U R A
AG EN T ENVIR O N M EN T
U AA
U M A
W eb Server
Voyage r p la tform
FIPA-O S platfo rm
CLIENT
EX MAS
EX MAS
CLIENT
EX MAS
Web SERVER 1
Inform ation SERVER 1 Inform ation SERVER 2
U R AS
AG EN T ENVIR O N M EN T
Voyage r p la tform
FIPA-O S platfo rm
EX MAS
Web SERVER 2
m essag e exchang e
creation of a gent
M anagem ent agent’s in teraction
m ovem ent
sen d/receive req uest
h idden architec tura l deta ils
F IPA-com pliant g atew ay
U IA : User In terface Agent
U R A: U ser R equ est AgentU AA: U ser Asss tant Agent
LIA : Loca l In terface Ag entLAA :LM A:U M A:
LSA : LIG A: U R AS: EXSA:
Local Ass istant Agent Local M ana gem ent Agent
U niversal M anage m en t Ag ent
Local Security AgentLocal In terG ratio n Agent
U R A’s ServantExterm al Se rvice Agent
LR A: Local R etrieval Agen t
D B
FILEAR C H IVE
C O M PU TESERVER
M ETA-DATA
(1/4) The management agents in the SARA architecture
Info. server LMA (Local Management Agent)
web server UMA (Universal Management Agent)
i) optimize mobile agents’ itinerary
ii) avoid unnecessary migrations
iii) identification & comparison of agent task
i) inform mobile agents for updates
A management agent exists for every server
Their common objective: optimize system performance
Why multiple management agents ?
i) no central point of failure
ii) over a centralized scheme: as the number of agents increase, the network load is increased
(state-based approach)(state-based approach)
LB decisions are supported through the management agents
19
Minimization of information transmitted over the network
Minimization of the mobile agent’s size
System optimization
Advantages of having management agents control over LB decisionsAdvantages of having management agents control over LB decisions
(i.e. only 2 messages are exchanged between a mobile agent and a management agent: the agent’s requirements & the agent’s itinerary )
(i.e. the decision support algorithm is within the management agents. Alternatively mobile agents would have to carry it during their migration)
Information used for LB decisions may also be reused for:
i) undertaking similarity analysis between agent requests i.e. tasksii) cache techniques are possible to be applied
iii) lay the foundations for an efficient monitoring system
20
(2/4) Distribution of information among the management agents(2/4) Distribution of information among the management agents
distributed scheme :information is distributed among the servers
centralized scheme :a global database is used to hold all information for each server
ii) map of the surrounding area
i) global network map
iii) neighbor map
- agent interactions
- information:
- in a case of a failure
stored in one locationnetwork overload increases
- impose agents to have a kind of intelligence
- each server has all the information: replication (for integrity)
no central point of failure
network overload decreases(provides all information for each server)
(provides information for the local server but information is reduced more and more for servers which are not in the local region)
(provides information for the local server and its neighbor servers only)
(state-based approach)(state-based approach)
21
(3/4) Information maintained by management agents
(state-based approach)(state-based approach)
LMA’s information
LMA’s information acquired by
Local: resources: software: status of voyager server, available analysis algorithms hardware: database server: status, processing power compute server: status, processing power, average data filtered per sec., maximum data filtered per sec.
local LAA
number of agent: active, persistent general (concerning database server): average completion task time, average server’s utilisation
LMA itself
Remote: servers’ resources:…
LMAs
servers’ bandwidths: server x with server y
sender agent
UMA’s information
UMA’s information acquired by
Local agent’s info: agent id: general: request, time of request
local UAA(upon URA’s creation)
time of request accomplished, status of the task location of results: server’s IP, physical location path, file-space acquired resources used: software: analysis algorithm (AA) used, size of custom AA hardware: database/file archives used, engagement time (from-to), server’s utilization (before-after), compute server used, engagement time (from-to)
local UAA(before URA’s death)
Remote agents’ info: server x,y: agent id, request, status of the task
UMAs
LMAs’ info: server x, y: … LMAs
22
Mobile-Stationary/Management Agent Interaction
23
Migration Times for Voyager-based Mobile Agents
24
(4/4) Communication between management agents
(state-based approach)
Management agents’ interaction
Event Interaction(sender – recipient)
Information exchange Type of mes.
on the initialization of the system LMA-LMAs/UMAs contents in row 1,2 of table 1 multicast
upon URA’s creation UAA-local UMA contents in row 1 of table 2 direct
UMA-UMAs information in bold of table 2 multicast
before URA’s death UAA-local UMA contents in row 2 of table 2 direct
UMA-UMAs information in bold, in row 2 of table 2 multicast
URA’s migration failure URA-local LMA/UMA
Voyager server is down (row 1, table 1) direct
LMA/UMA-LMAs/UMAs
multicast
database connection failure LRA-local LMA database is unavailable (row 1, table 1) direct
LMA-LMAs/UMAs multicast
sever will be unavailable until a specified time
LMA-LMAs/UMAs the time the server will become available (row 1, table 1)
multicast
need for further information about an agent’s task
UMA-UMA selected information of row 1,2 of table 2 based on the recipient UMA needs
direct
change on information-server’s (LMA’s) status/resources
LAA-local LMA contents in row 1 of table 1 direct
LMA-LMAs/UMAs contents in row 1,2 of table 1 multicast
change on UMA’s information (concerning URA personal details)
UMA-UMAs contents in row 3 of table 2 multicast
25
LB decision modelLB decision model(model-based approach)(model-based approach)
i) agents’ tasksii) servers’ utilization (performance load)
iii) availability of resourcesiv) network efficiency
LB decisions are based on a model which accepts as:
input: an agent’s requirements & System state informationoutput: the appropriate server where an agent should migrate to
The model is a function of:
26
Dynamic Approach – Track Selection by polygon
The user is allowed to select a polygonal area on a zoomable map of the world
The algorithm retrieves all the tracks intersecting the user’s polygon in at least one point
27
A g e n t’s Task
N e ed f ilte r in g
N e ed f ilte r in gP a rtia lly th e sa m eE x a c tly th e sam e
D o no t ne ed f ilte r in g
D o no t ne ed f ilte r in g
C u s to m fil te r
C u s to m fil te r
S e rv e r fi lte r
S e rv e r fi lte r.. ... .
S im ila r (ca ch ed ) N o t s im ila r (no t cach e d )
(model-based approach)(model-based approach)
The model may be better expressed with reference to the agents’ task…
Load Balancing
28
W ill b ec o m eav a ilab le a t T
c s
F o r u n k n o w n tim e
F o r u n k n o w n tim e
C o m p u te se rv e ris u n av a ilab le
C o m p u te se rv e ris a v a ilab le
S e rv e r is a v a ilab le
(iii)
(iv)
(v )
(v i)
(v ii)
(v iii)
(ix)
(ii)
(i)
W ill b ec o m eav a ilab le a t T
s
N o
Ye s
W ill b ec o m eav a ilab le a t T
c s
F o r u n k n o w n tim e
C o m p u te se rv e ris u n av a ilab le
C o m p u te se rv e ris a v a ilab le
W ill b ec o m eav a ilab le a t T
c s
F o r u n k n o w n tim e
C o m p u te se rv e ris u n av a ilab le
C o m p u te se rv e ris a v a ilab le
BS
UUT codea
av
sav
x2
.*
case 3:Agent’s task Similar (cached) Exactlythe same Need filtering Custom filter
case 5:Agent’s task Not similar (not cached) Do not need filtering
where:Tav = the average time an agent needs to complete a task (regarding all servers) Uav = the average utilization of all serversUs = the utilization of a serverSa.code = the file-size of an agent’s code.B2 = the bandwidth between 2 information serversΤs = time needed for a server to became available
LU
*
utilization of a server
where:a = the number of agents on that serverμ = the average task time of the agentsL = the processing power of the server
examples of different agents’ tasks…
+Ts
Load Balancing (Model-based Approach)
29
Details of experiments conducted: - 200 agents launched- 5 information-servers & 1 web-server (Sun-Ultra 5 workstation running on Solaris 8 with Voyager 4.5 as the agent platform)- 100Mbits/s network connection- data-repository maintained by Oracle 9 DBMS
on the execution of agents with mixed tasksmixed tasks (15% where complex task)
on the execution of agents with simple taskssimple tasks
Workload distribution – utilisation of Information-serversWorkload distribution – utilisation of Information-servers
30
For other systems utilising active-archives
in which the lifetime of complex tasks cannot be estimated or tend to be
erroneous
Three different LB schemes:
adaptability algorithm
Adaptability of modelAdaptability of model
Scheme No.1Scheme No.1: represents the default LB scheme adopted in SARA MAS (lifetime of complex agent tasks is known)
Scheme No.2Scheme No.2: alternative version of No.1 (lifetime of complex agent tasks is unknown and therefore not used in calculations)
Scheme No.3Scheme No.3: alternative version of No.2 (adaptable algorithm is utilised for amending the server’s utilisation)
31
Optimisation of LB scheme No.2, based on theutilisation of the adaptability algorithm
Efficiency between LB scheme No.2 & No.3
Total task time required by agentsto complete their task
optimisation in performance1.63 – 10.8 %1.63 – 10.8 %
Comparison of different LB schemesComparison of different LB schemes
32
Conclusion – Future work
were specialized stationary agents are used to gather system state information and make decisions on the distribution of mobile agents among the servers,
based on a model of probabilistic estimations in relation with the information provided by the stationary agents
we demonstrated a combination of the state and model-based approaches for mobile agent load balancing
we have implement the proposed LB technique
… need to further optimize the intelligence of the management agents
33
Load balancing overviewLoad balancing overview
Load balance
mobile static
state model
Market mechanism
Specialized agentsgather System state
information
Aim: improve the average utilization and performance of tasks on available servers
Kinds of Load Balance (LB):
Keren & Barak:mobile LB has a
30-40% improvement over
the static placement scheme
• only a price• sophistiated auction protocols• a pricing mechanism without any negotiation
• roam through the network• bid for resources
Load Balancing
34
Our approach on LBOur approach on LB
Provide a LB mechanism to evenly distribute agent tasks among the available servers
(i.e. equitably serve the agents, there are no priorities between agents based on the time needed for their task to be accomplished)
We propose a LB mechanism based on a combination of the model-based and state-based approaches
(i.e. decisions on LB are based upon a model which adapts due to the information gathered from the state-based approach)
We demonstrate this approachfor a MAS operating on an active digital library composed of multi-spectral images of the Earth as part of the Synthetic Aperture Radar Atlas (SARA)
Load Balancing
35
The SARA LB mechanismThe SARA LB mechanism
State-based approach
Model-based approach
(4/4) Communication between management agents
(1/4) The management agents in the SARA architecture
(3/4) Information maintained by management agents
(2/4) Distribution of information among the management agents
(1/1) LB decision model
Load Balancing
36
The SARA architectureThe SARA architecture
E X S A
U R A S
U R A
U R A
A G E N T E NV IR O N M E N T
A G E N T E NV IR O N M E N T
LA A LR A
LM AU A A
U M A
LS A
LIG A
D B
FILEA R C H IV E
C O M P U TES E RV E R
M E TA -DATA
U R A
LA A LR A
LM A
LS A
LIG A
W eb S erver
Voyage r p la tform
Voyage r p la tform
FIPA -O S p la tfo rm
FIPA -O S p la tfo rm
E X S A
U R A
A G E N T E NV IR O N M E N T
U A A
U M A
W eb S erver
Voyage r p la tform
FIPA -O S p la tfo rm
CLIENT
EX M AS
EX M AS
CLIENT
EX M AS
W eb SERVER 1
In form ation SERVER 1 In form ation SERVER 2
U R A S
A G E N T E NV IR O N M E N T
Voyage r p la tform
FIPA -O S p la tfo rm
EX M AS
W eb SERVER 2
m essag e exchang e
creation of a gent
M anagem ent agent’s in teraction
m ovem ent
sen d/rece ive req uest
h idden arch itec tura l deta ils
F IPA -com pliant g atew ay
U IA : User In terface A gent
U R A : U ser R equ est A gentU A A : U ser A sss tant A gent
LIA : Loca l In terface A g entLA A :LM A :U M A :
LS A : L IG A: U R A S : E X S A :
Loca l A ss istant A gent Local M ana gem ent A gent
U niversa l M anage m en t A g ent
Local S ecurity A gentLocal In terG ratio n A gent
U R A’s S ervantE xterm al S e rvice A gent
LR A : Local R etrieva l A gen t
D B
FILEA R C H IV E
C O M P U TES E RV E R
M E TA -DATA
Load Balancing
37
EXSA
U R AS
U R A
U R A
AG EN T ENVIR O N M EN T
AG EN T ENVIR O N M EN T
LAA LR A
LM AU AA
U M A
LSA
LIG A
D B
FILEAR C H IVE
C O M PU TESERVER
M ETA-DATA
U R A
LAA LR A
LM A
LSA
LIG A
W eb Server
Voyage r p la tform
Voyage r p la tform
FIPA-O S platfo rm
FIPA-O S platfo rm
EXSA
U R A
AG EN T ENVIR O N M EN T
U AA
U M A
W eb Server
Voyage r p la tform
FIPA-O S platfo rm
CLIENT
EX MAS
EX MAS
CLIENT
EX MAS
Web SERVER 1
Inform ation SERVER 1 Inform ation SERVER 2
U R AS
AG EN T ENVIR O N M EN T
Voyage r p la tform
FIPA-O S platfo rm
EX MAS
Web SERVER 2
m essag e exchang e
creation of a gent
M anagem ent agent’s in teraction
m ovem ent
sen d/receive req uest
h idden architec tura l deta ils
F IPA-com pliant g atew ay
U IA : User In terface Agent
U R A: U ser R equ est AgentU AA: U ser Asss tant Agent
LIA : Loca l In terface Ag entLAA :LM A:U M A:
LSA : LIG A: U R AS: EXSA:
Local Ass istant Agent Local M ana gem ent Agent
U niversal M anage m en t Ag ent
Local Security AgentLocal In terG ratio n Agent
U R A’s ServantExterm al Se rvice Agent
LR A: Local R etrieval Agen t
D B
FILEAR C H IVE
C O M PU TESERVER
M ETA-DATA
(1/4) The management agents in the SARA architecture (1/4) The management agents in the SARA architecture
Info. server LMA (Local Management Agent)
web server UMA (Universal Management Agent)
i) optimize mobile agents’ itinerary
ii) avoid unnecessary migrations
iii) identification & comparison of agent task
i) inform mobile agents for updates
A management agent exists for every server
Their common objective: optimize system performance
Why multiple management agents ?
i) no central point of failure
ii) over a centralized scheme: as the number of agents increase, the network load is increased
(state-based approach)(state-based approach)
LB decisions are supported through the management agents
Load Balancing