Combining State and Model-based approaches for Mobile Agent Load Balancing Georgousopoulos Christos Omer F. Rana

Combining State and Model-based approaches for Mobile Agent Load Balancing

Georgousopoulos Christos

Omer F. Rana

http://www.cs.cf.ac.uk/Digital-Library/

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

Our approach on LBOur 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)

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

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


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


E X S A

U R A


U A A

U M A

W eb S erver

Voyage r p la tform


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


Voyage r p la tform


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


M E TA -DATA

E X S A

U R A S

U R A

U R A



LA A LR A

LM AU A A

U M A

LS A

LIG A

D B

FILEA R C H IV E


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



E X S A

U R A


U A A

U M A

W eb S erver

Voyage r p la tform


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


Voyage r p la tform


EX M AS

W eb SERVER 2

m essag e exchang e

creation of a gent


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


M E TA -DATA

The SARA architectureThe SARA architecture

EXSA

U R AS

U R A

U R A

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


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


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

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

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

(3/4) Information maintained by management agents(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

SARA LB uses the global network map for decentralized information distribution with a slight variation …

(4/4) Communication between management agents(4/4) Communication between management agents(state-based approach)(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

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:

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 )


The model may be better expressed with reference to the agents’ task…


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

S e rv e r is a v a ilab le

(iii)

(iv)

(v )

(v i)

(v ii)

(v iii)

(ix)

(ii)

(i)


s

N o

Ye s


c s





c s




BS

UUT codea

av

sav

x2

.*

case 3:Agent’s task Similar (cashed) Exactlythe same Need filtering Custom filter

case 5:Agent’s task Not similar (not chased) 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

Parameters server 1 server 2 server 3 server 4 server 5 server 6 server 7 server 8 server 9 server 10

Agents (α) = 14 22 18 9 13 26 7 25 25 12

Av.Task.T (μ) = 17 27 25 22 27 16 31 12 11 13

Proc.Power (L) = 13 22 22 9 10 27 13 26 25 8

Utiliz.Server (Us) = 18.3 27 20.45 22 35.1 15.4 16.6 11.5 11 19.5

AgentCode (Sa.code)= 7148 7148 7148 7148 7148 7148 7148 7148 7148 7148

Bandwidth Sx-Sy (B2)= 2412 2104 2355 2005 2500 1704 2006 2205 1988 2055

Av.Util.allServ (Uav) = 19.6 19.6 19.6 19.6 19.6 19.6 19.6 19.6 19.6 19.6

Av.Task (Tav) = 20.1 20.1 20.1 20.1 20.1 20.1 20.1 20.1 20.1 20.1

x = 21.73 31.09 24.01 26.13 38.85 19.99 20.59 15.04 14.88 23.48

0

5

10

15

20

25

30

35

40

45

server 1 server 2 server 3 server 4 server 5 server 6 server 7 server 8 server 9 server 10

Agent (α) Av.Task.T (μ) Proc.Power (L) x


Agent’s task Not similar (not chased) Do not need filtering

Mathematica simulation of Case 5

( L= x*100000 ops )

( Sa = Kbytes/sec )

( B2 = Kbytes/sec )

Advantages of the proposed LB techniqueAdvantages 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)

Conclusion – Future workConclusion – 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

implement the proposed LB technique…

… to optimize the intelligence of the management agents

The EndThe End

Combining State and Model-based approaches for Mobile Agent Load Balancing Georgousopoulos Christos Omer F. Rana

Documents

multiple management

agents requirements

number of agents

mobile agents itinerary

agent tasks

statebased approaches

distribution of information

minimization of information