ProActive Architecture and Application for the Management of Electrical Networks
E. ZimeoDepartment of Engineering - RCOSTUniversity of Sannio, Benevento, Italy
ProActive User Group and ContextSophia Antipolis, Nizza, France
18 October 2004
Introduction 1/4
• On-line power systems security analysis (OPSSA) is one of the most relevant assessments made to assure the optimal control and management of electrical networks
• There are many phenomena (contingencies) that can compromise power systems operation– an unexpected variation in the power system structure – a sudden change of the operational conditions
• OPSSA deals with the assessment of the security and reliability levels of the system under any possible contingency
Introduction 2/4
Three main steps:
1. Screening of the most “credible” contingences
2. Predicting their impact on the entire system operation • the contingencies analysis is performed according to the (n-1)
criterion• for each credible contingency, the simulation of the system
behaviour and the verification of operational limits violations• the system behavior is verified finding the solution of the
system state equations (power flow or load flow equations)
3. Preventive and corrective controlling • identification of proper control actions able to reduce the risk
of system malfunctioning
Introduction 3/4
• Focus: on-line prediction (step 2)– computation times should be less than few minutes for
information to be useful
• Unfortunately OPSSA is computing and data intensive– structure of modern power systems– computational complexity of algorithms– number of contingencies to analyze
• New methodologies to reduce computational times– parallel processing on supercomputers and then on cluster
and network of workstations (to reduce costs) has been employed (i.e. PVM)
Introduction 4/4
• Our proposal:– A java-based distributed architecture instead of PVM
• Advantages:– Programming is easier– Portability is assured on each architecture implementing a JVM – Better integration with Web technologies– Object-Oriented programming allows for adopting architectural
and design patterns
• Disadvantages:– Efficiency is reduced due to Java communication overheads– Execution time is higher due to interpretation
The overall distributed architecture
Inte
rnet
- H
TT
P in
tera
ctio
ns Internet - T CP and HT T P interactions
ElectricalGrid
FEM
FEM
FEM
FEM
IEDIED
IED
IED
IED
IED
DBMS
Com putationalEngine
Presentation tier Middle tier Storage tier
. . .. . .
W eb Server Application Se rv e r
Serv let
JSP
BusinessLogic
BusinessLogic
Web Browser
Applet
HT M L client
Web Browser
Applet
HT M L client
..........
scalability accessibility manageability
Inte
rnet
- H
TT
P in
tera
ctio
ns Internet - T CP and HT T P interactions
ElectricalGrid
FEM
FEM
FEM
FEM
IEDIED
IED
IED
IED
IED
DBMS
Com putationalEngine
Presentation tier Middle tier Storage tier
. . .. . .
W eb Server Application Se rv e r
Serv let
JSP
BusinessLogic
BusinessLogic
Web Browser
Applet
HT M L client
Web Browser
Applet
HT M L client
..........
A network of field power meters (FEMs)
- distributed in the most critical sections of the electrical grid
- to provide input field data for power flow equations, such as active, reactive and apparent energy
- based on ION 7330-7600TM units
- equipped with an on-board web server for their full remote control
Inte
rnet
- H
TT
P in
tera
ctio
ns Internet - T CP and HT T P interactions
ElectricalGrid
FEM
FEM
FEM
FEM
IEDIED
IED
IED
IED
IED
DBMS
Com putationalEngine
Presentation tier Middle tier Storage tier
. . .. . .
W eb Server Application Se rv e r
Serv let
JSP
BusinessLogic
BusinessLogic
Web Browser
Applet
HT M L client
Web Browser
Applet
HT M L client
..........
A network of distributed Intelligent Electronic Devices (IEDs)
- distributed in the most critical sections of the electrical grid
- to monitor continuously the thermal state of critical sections of the electrical grid
- to analyse system behavior
- to verify limits violations (such as load capability)
- remote controlled by the TCP/IP protocol
Inte
rnet
- H
TT
P in
tera
ctio
ns Internet - T CP and HT T P interactions
ElectricalGrid
FEM
FEM
FEM
FEM
IEDIED
IED
IED
IED
IED
DBMS
Com putationalEngine
Presentation tier Middle tier Storage tier
. . .. . .
W eb Server Application Se rv e r
Serv let
JSP
BusinessLogic
BusinessLogic
Web Browser
Applet
HT M L client
Web Browser
Applet
HT M L client
..........
Clients
- used by the power systems operators
- to access OPSSA information for system monitoring and management
Inte
rnet
- H
TT
P in
tera
ctio
ns Internet - T CP and HT T P interactions
ElectricalGrid
FEM
FEM
FEM
FEM
IEDIED
IED
IED
IED
IED
DBMS
Com putationalEngine
Presentation tier Middle tier Storage tier
. . .. . .
W eb Server Application Se rv e r
Serv let
JSP
BusinessLogic
BusinessLogic
Web Browser
Applet
HT M L client
Web Browser
Applet
HT M L client
..........
Web components
- handle the presentation at the server-side
Inte
rnet
- H
TT
P in
tera
ctio
ns Internet - T CP and HT T P interactions
ElectricalGrid
FEM
FEM
FEM
FEM
IEDIED
IED
IED
IED
IED
DBMS
Com putationalEngine
Presentation tier Middle tier Storage tier
. . .. . .
W eb Server Application Se rv e r
Serv let
JSP
BusinessLogic
BusinessLogic
Web Browser
Applet
HT M L client
Web Browser
Applet
HT M L client
..........
Business Logic Components
- access data stored in a DBMS
- continuously monitor the power system, coordinating the execution of security analysis
Inte
rnet
- H
TT
P in
tera
ctio
ns Internet - T CP and HT T P interactions
ElectricalGrid
FEM
FEM
FEM
FEM
IEDIED
IED
IED
IED
IED
DBMS
Com putationalEngine
Presentation tier Middle tier Storage tier
. . .. . .
W eb Server Application Se rv e r
Serv let
JSP
BusinessLogic
BusinessLogic
Web Browser
Applet
HT M L client
Web Browser
Applet
HT M L client
..........
A DataBase Management System (DBMS)
- used to permanently store output data
- remote accessed
Inte
rnet
- H
TT
P in
tera
ctio
ns Internet - T CP and HT T P interactions
ElectricalGrid
FEM
FEM
FEM
FEM
IEDIED
IED
IED
IED
IED
DBMS
Com putationalEngine
Presentation tier Middle tier Storage tier
. . .. . .
W eb Server Application Se rv e r
Serv let
JSP
BusinessLogic
BusinessLogic
Web Browser
Applet
HT M L client
Web Browser
Applet
HT M L client
..........
Computational Engine
- a parallel and distributed processing system
- to execute power flow equations in a short time
Computational engine: algorithm
• Sequential algorithm • Concurrent algorithm
i < = N e
N O
YES
Any c ons train tvio lated ?
Contingenc ylis t em pty ?
YES
N O
N O
YES
Ac quire f ielddata
Com pute thes tate es tim ation
S elec t ac ontingenc y
Com pute thepow er f low
s olution
Chec k the voltage andpow er c ons train ts
Chec k theequipm entc ons train ts
i = i + 1
G enerate analarm
Any c ons train tv io lated ?
YES
N O
Any c ons train tv io lated ?
YES
N O
. . . .
. . . . . .
.
.
.
Ac quire f ielddata
S ubdivide theJ ob
S elec t thec ontingenc y 1
Com pute thepow er f low
s olu tion
Chec k thec ons train ts
S elec t thec ontingenc y N
Com pute thepow er f low
s olu tion
Chec k thec ons train ts
Chec k thec ons train ts of the
equipm ent 1 inc ontingenc y 1
Chec k thec ons train ts of theequipm ent N e in
c ontingenc y 1
Chec k thec ons train ts of the
equipm ent 1 inc ontingenc y N
Chec k thec ons train ts of theequipm ent N e inc ontingenc y N
G enerate analarm
G enerate analarm
Com pute s tatees tim ation
Adopting a concurrent algorithm based on the domain decomposition
Computational Engine: design goals
• The computational engine is designed as a framework, whose main goals are:1. high performance
– The framework is to be able to compute the analysis of each contingency in parallel with the others
2. flexibility and scalability– The framework is to be able to exploit all the available
resources to minimize the computation time
3. hierarchy– The framework is to be able to exploit clusters of
workstations or networks of workstations handled by front-ends
• Architectural design solution: hierarchical master/slave model
The hierachical m/s model 1/3
master
sub-master slave slavesub-master
slave
slave
slave slave
slave
slave
input data s tructure
– hierarchical master/slave model
• object-level parallelism
• master and slaves are transparently
created
The hierachical m/s model 2/3
• Three implementation problems:– Task allocation in order to minimize the execution
time• Time minimization algorithm
– Object-oriented design to support a transparent hierarchical master/slave model
• Hierarchical master/slave pattern
– Object-oriented implementation to support a distributed and parallel implementation of the hierarchical master/slave pattern
• RMI based implementation• ProActive based implementation
Task allocation: time minimization
• This phase is important and complex due to the heterogeneity of hardware architectures– to minimize load imbalance, the workload should be distributed
dynamically and adaptively to the changing conditions of resources.
• We consider only static information– Defined N as the number of independent sub-tasks in which the
overall task is divided;
– n as the number of available resources at a certain level;
– and ti as the elapsed time that the resource i needs to complete a
single sub-task;
– ni the number of sub-tasks assigned to the resource i
– the problem to minimize the execution time using assigned resources can be formulated as follows:
Nn
tntntnn
ii
nn
1
2211 ...
The hierachical m/s pattern• M/S pattern:
– splitWork() is used to create slave objects, to allocate them onto the available resources, and to partition a task into sub-tasks.
– callSlaves() is used to call the method service() on all the slave objects, which perform the same computation with different inputs.
– combineResults() is used to combine the partial results in order to produce the final result.
• Hierarchical M/S pattern:– An additional class (Server) is
introduced– service()is used to hide the
difference between master and slave objects
M as te r
+ s ervic e(O bjec t) :O bjec t+ s plitW ork()+ c allS laves ()+ c om bineRes ults ()
S erve r
+serv ice(Object):Object
Slave
+ s ervic e(O bjec t) :O bjec t
C lie nt
+ us e_s erv ic e_AP I()
HM/S pattern implementation
• To support distributed and parallel implementation of HM/S pattern– service() has to be asynchronously invoked– Each service() method has to be executed by a different
computational resources
• Solutions: an object-oriented middleware based on remote method invocations– RMI – the well known middleware provided by SUN– ProActive - Java library for seamless sequential, concurrent
and distributed programming
RMI implementation of HM/S pattern
• Each Server – is defined as a remote object – is allocated onto a different computational resource– its method service() has to be asynchronously and remotely
invoked by the client– the asynchronous invocation is implemented by invoking service() within a dedicated thread of control
:M as ter
:T h re a d :M as terRM I
RM I
RM I
:Applic ationc om ponent
C o m pu ta t io n a l En g in e
s e rv ic e ()
s e rv ic e ()
s e rv ic e ()
s e rv ic e () :T h re a d
:T h re a d
< < c re a t e > >
< < c re a t e > >
< < c re a t e > >
. . . . .
H os t H os t
H os t
:S laveRM I
RM I
RM I
H os t
H os t
H os t
:J M atLink
:S lave :JM a th Lin k
:S lave :JM a th Lin k
:S laveRM I
RM I
H os t
H os t
:JM a th Lin k
:S lave :JM a th Lin k
s e rv ic e ()
:T h r e a d
:T h r e a d
:M as ter
:T h r e a d
:T h r e a d
H os t
:M as ter :T h r e a d
S e rve rs
R D B M S
D e vic e sfor m onitor inga n e le c tr ic a lgr id
ProActive implementation of HM/S p.
• Each Server– is defined as an active object (that can be dynamically created)– is allocated on a different computational resource (dynamically)– its method service() has to be asynchronously and remotely
invoked by the client. – the asynchronous invocation is directly supported by ProActive
:M as ter
:M a s t e r
:Applic ationc om ponent
C o m pu ta t io n a l En g in e
s e rv ic e ()
. . . . .
H os t
H os t
H os t
:S lave
H os t
H os t
:S lave
:M a s t e r
H os t
ì:M a s t e r
:S lave
H os t
H os t
:S lave
:S lave
H os t
H os t
:S lave
s e rv ic e ()
S e rv e rs
R D B M S
D e vic e form onitor inga n e le c tr ic a lgr id
:J M athLink
:J M athLink
:J M athLink
:J M athLink
:J M athLink
:J M athLink
Software platform evaluation on a testbed 1/2
• RMI - ProActive• Tomcat 4.1• Java SDK 1.4.1• MATLAB 6.5
• Standard IEEE 118-nodes test network
• electrical network description is local to each computational resource
• The experiments refer to 186 contingencies
• A COW with P1 proc.• P1 = Pentium II 350 MHz
• A NOW with P2 proc.• P2 = Pentium IV 2 GHz
In ternet
Clien t
S erv let Container
P 1
P 1
P 1
P 1
P 1
P 1
P 1
P 1
P 2
P 2
P 2
P 2
M as ter1 M as ter2
M as ter
l evel 0
l evel 1
l evel 2
P 1 P 2
2421
1821
35...
6...
Pnnn
Pnnn
Software platform evaluation on a testbed 2/2
• The framework shows good results• RMI vs ProActive:
– Exibhit almost the same results (ProActive is based on RMI)– ProActive simplifies parallel and distributed programming– ProActive enables group communication (not used in this work)
Execution times Speed up
Open problems
• Problem 1: – The method splitWorks has to know dynamically the number of
computers to use, the computational power of each computer
• Solution 1: – A broker based architecture
• Problem 2: – Too much code for invoking the same method on each slave
• Solution 2: – Adopting groups to simplify the code in the master/slave model
• Problem 3: – Too much data communication
• Solution 3: – Implementation of group communication on multicast protocols
Broker based architecture: a step further toward flexibility and efficiency
A Grid-based Computational Engine
• At the University of Sannio we have developed a broker-based middleware – HiMM (Hierarchical Metacomputer Middleware)
• a middleware that provides an object-based programming model
HiMM collective layer
:BusinessCom ponent
:Inform ationSystem
HiM
:Broker
- Code- Input- Application description- QoS requirem ents
Resource selectionT ask m apping
Com putational Engine
results
Resourcediscovery
User
Com putationalresources
• Economy-driven resource broker
- ease application submission
- simplifying the application
deployment
- functionalities of resource
management
• Application description–JDF – Job Description Format
– Application QoS requirements–URDF – User Requirements Description Format–the deadline and the budget–time optimisation algorithm or cost optimisation algorithm
OPSSA deployment and evaluation 1/3
• The work load is distributed among the available resources according to their performance and price
20
40
60
80
R0 R1 R0 R1 R0 R1 R0 R1 R0 R1 R0 R1
N. o
f co
ntin
ge
nci
es
Resources
N. of Contingencies assigned to each Resource (Deadline = 900 sec)
80 (B=800$)
92 (B=1000$) 98 (B=1200$) 105 (B=140$) 112 (B=1600$) 118 (B=1800$)
OPSSA deployment and evaluation 2/3
• The resources were temporarily dedicated to OPSSA computations• The budget is limited
100
200
300
400
500
600
700
800
900
30 40 50 60 70 80 90 100 110 120
Exe
cutio
n tim
e (s
ec)
Total n. of sub-tasks
Execution Time (Deadline=900 sec. Budget=1800$)
Estimated TimeMeasured Time
OPSSA deployment and evaluation 3/3
100
200
300
400
500
600
700
800
900
40 60 80 100 120 140 160 186
Exe
cutio
n tim
e (s
ec)
Total n. of sub-tasks
Execution Time (Deadline=900 sec. Budget=(illimited)1000000$)
Estimated TimeMeasured Time
• The resources were temporarily dedicated to OPSSA computations• The budget is unlimited
Which programming paradigm for OPSSA on HiMM ?
OPSSA on HiMM uses a specific implementation of ProActive
Integration HiMM / ProActive 1/2
• The implementation of P/H has been made easy thanks to the particular organization of both software systems– ProActive is heavily based on the Adapter Pattern
– HiMM is implemented following the Component Framework approach.
N E on node x
P ro A ct iv eM es s ag e
C o n s u m erL e v e l Se n d e r
E P s
O b je c t A
B P r o x y
N E on node y
P ro A ct iv eM es s ag e
C o n s u m erL e v e l Se n d e r
E P s
O b je c t B
A B o d y
L N
R e s u lt
Exec ution Environm ent
L N
N M
a c c e s s to G r id f e a tu r e s
H iM M T r a n s p o r t l a y e r( T C P , R U D P , F M )
H B A
H B A idH B A id
F u tu r e P o o l
H B AH B o d y
G lo b al U ID fo r H iM M G lo b al O b ject s
P ro A ct iv e co m p o n en t o f an act iv e o b ject
H iM M A d ap ters
H B A = H B o d y A d ap terH B A id = H B o d y A d ap ter s tu b co n tain s o n ly th e G U ID o f th e rem o te ad ap ter
H B o d y = H al fB o d y
A B o d y = A ct iv eB o d yS tu b g en erated b y B cel
R eferen ceIn v o cat io n o r d ata t ran s fer
H N A
H N A = H N o d eA d ap ter
Integration HiMM / ProActive 2/2
public class MatrixMultiply extends ProActiveExecutionEnvironment { private NodeMgr nodeMgr; private volatile boolean stop = false; public void init (NodeMgr nm) { super.init(nm); nodeMgr = nm; NodeFactory.setFactory(“himm”, new HNodeFactory()); } public void start() { stop = false; if(nodeMgr.isRoot()) { HMatrix[] mDxActiveGroup=null; int dim=0; System.out.println("Insert matrix size:"); <read dim>; Matrix mDx = new Matrix(dim); LevelMgr lm = nodeMgr.downLevelMgr(); int size = lm.size()-1; Object[] po = new Object[]{mDx.getTab()}; mDxActiveGroup = new Matrix[size]; for(int i =0; i<size; i++)
mDxActiveGroup[i] = (HMatrix) ProActive.newActive(HMatrix.class.getName(), po, NodeFactory.getNode(“himm://”+(i+1)), null, HMetaObjectFactory.newInstance()); Matrix mSx = new Matrix(dim); while (!stop) { Matrix[] results = multiply(mSx, mDxActiveGroup); Matrix result = Matrix.rebuild(results, dim); ... } } }…}
public class HMatrix extends Matrix implements InitActive, RunActive, EndActive {
private HMatrix[] subMats; public void initActivity(Body body){ HBodyAdapter hba =(HBodyAdapter) body.getRemoteAdapter(); NodeMgr nodeMgr = hba.getNodeMgr(); if(nodeMgr.isCoordinator()) { LevelMgr lm = nodeMgr.downLevelMgr(); int size = lm.size()-1; subMats = new Matrix[size]; Object[] po = {tab}; for(int i =0; i<size; i++) { subMats[i] = (HMatrix)ProActive.newActive(HMatrix.class.getName(),
po, NodeFactory.getNode(“himm://”+(i+1)),null, HMetaObjectFactory.newInstance()); } } } public void runActivity(Body body) { Service service = new Service(body); while (body.isActive()) { Request r = service.blockingRemoveOldest(); HBodyAdapter hba =(HBodyAdapter) body.getRemoteAdapter(); NodeMgr nodeMgr = hba.getNodeMgr(); if(r.getMethodName().equals("multiply")&& nodeMgr.isCoordinator()){ HiMMRequest rr = (HiMMRequest)r; float[][]mSxtab =(float[][])rr.methodCall.getParameter(0); Matrix mSx = new Matrix(mSxtab); Matrix[] results = new Matrix[subMats.length]; Object[] subSxMats = mSx.createSubMatrixes(subMats.length); for(int i=0; i< subMats.length; i++) results[i] = subMats[i].multiply((float[][])subSxMats[i]); Matrix result = Matrix.rebuild(results, mSxtab.length); Object[] params = new Object[]{result}; Class[] classes = new Class[]{Matrix.class}; try { Method m = HMatrix.class.getMethod("getResult", classes); rr.methodCall = MethodCall.getMethodCall(m, params); } catch (NoSuchMethodException e){ … } service.serve(rr); } else service.serve(r); } }
Performance analisys 1/2
• We have conducted an analysis to compare RMI with HiMM and P/R with P/H • The benchmark is the invocation of a remote method (with one parameter and an empty
body) and the return of an integer value, for a varying size of the parameter• The figure shows that for a small size (1 byte) of the parameter, RMI RTT (0.9 ms) is
smaller than HiMM RTT (1.3 ms), but P/H RTT (7.8 ms) is smaller than P/R RTT (9.2 ms) – Even if the HiMM transport layer is not optimized, P/H behaves better than P/R due to the use of
asynchronous messaging that allows low-level ProActive operations to be overlapped with communication
1
10
100
1000
1 10 100 1000 10000 100000
Th
rou
ghp
ut (
me
tho
d in
voca
tion
s / s
)
Parameter Size
RMI(S-R)/H
P/HP/R
1
10
100
1 10 100 1000 10000 100000
RT
T (
ms)
Parameter Size
RMIS-R/H
P/HP/R
Performance analisys 2/2
• A further analysis has aimed to measure the speedup factor by running a simple application benchmark
• The benchmark is the product of two square matrixes with different sizes of the matrixes.
• The performance obtained with P/H is slightly better than the one obtained with P/R, especially when the size of the matrixes is small
– This is mainly due to the improvement of remote method invocation implemented by HiMM– When the size of the matrixes is large, the execution time is dominated by the time of the matrix
serialization, which is the same in P/H and P/R
0
1
2
3
4
5
100 200 300 400 500 600 700 800 9001000 1200
Spe
edup
Fac
tor
Matrix Size
P/H 2 nodesP/R 2 nodesP/H 4 nodesP/R 4 nodesP/H 6 nodesP/R 6 nodes
0
500
1000
1500
2000
2500
100 200 300 400
Exe
cutio
n ti
me
(m
s)
Matrix Size
S-R/HP/HP/R
On going work
ProActive Groups over Reliable Multicast
• We intend to implement the OPSSA by using ProActive Hierarchical Groups
• Group at different hierarchical levels will be mapped on HiMM macro-nodes
• HiMM will provide reliable multicast to ProActive groups for communication among members
:M as ter
:M a s t e r
:Applic ationc om ponent
C o m pu ta t io n a l En g in e
s e rv ic e ()
. . . . .
H os t
H os t
H os t
:S lave
H os t
H os t
:S lave
:M a s t e r
H os t
ì:M a s t e r
:S lave
H os t
H os t
:S lave
:S lave
H os t
H os t
:S lave
s e rv ic e ()
S e rv e rs
R D B M S
D e vic e form onitor inga n e le c tr ic a lgr id
:J M athLink
:J M athLink
:J M athLink
:J M athLink
:J M athLink
:J M athLink
Group
Group
Group
Group
Web services for process coordination in OPSSA
Inte
rnet
- H
TT
P in
tera
ctio
ns Internet - T CP and HT T P interactions
ElectricalGrid
FEM
FEM
FEM
FEM
IEDIED
IED
IED
IED
IED
DBMS
Com putationalEngine
Presentation tier Middle tier Storage tier
. . .. . .
W eb Server Application Se rv e r
Serv let
JSP
BusinessLogic
BusinessLogic
Web Browser
Applet
HT M L client
Web Browser
Applet
HT M L client
..........
scalability accessibility manageability
WSRF + BPEL Engine
Generic Middleware for Sensor Networks
Inte
rnet
- H
TT
P in
tera
ctio
ns Internet - T CP and HT T P interactions
ElectricalGrid
FEM
FEM
FEM
FEM
IEDIED
IED
IED
IED
IED
DBMS
Com putationalEngine
Presentation tier Middle tier Storage tier
. . .. . .
W eb Server Application Se rv e r
Serv let
JSP
BusinessLogic
BusinessLogic
Web Browser
Applet
HT M L client
Web Browser
Applet
HT M L client
..........
scalability accessibility manageability
WSRF + BPEL Engine
Sensor Networks MW
HiMM connectivity layer
• HiMM manages resources according to a hierarchical topology (Hierarchical Metacomputers) in order to– meet the constraints of the Internet
organization
– exploit the heterogeneity of networks
– improve scalability • Clusters of computers hidden from the
Internet or intra-connected by fast networks are seen as macro-nodes– A macro-node is a high-level concept that
allows clusters to be transparently used as a single powerful machine
– A macro-node can in turn contain other macro-nodes
• A metacomputer can be organized according to a recursive tree topology
• The Coordinator interfaces the macro-node with the metacomputer network
N et-IPN et-IP
Root
W SW S
M ac ro-nodeM ac ro-node
M ac ro-node
C C
C
N et-IP
N et-F P
C lus te r
D o m a inX M L c f g f i l e
C o nso le
C
D o m a inX M L c f g f i l e
C lu s t e rX M L c f g f i l e
U s e rX M L c f g f i l e
N ode
H M H M
C re a t e a n o d e
N o d e c re a t io nc o m m a n d
HiMM resource layer
• A macro-node is characterized by two main components:– The Host Manager (HM)– The Resource Manager (RM)
• The HM runs on each node wanting to donate CPU cycles
• The RM is use to publish the available computing power at each level
• A macro-node manages another important component: – the Distributed Class Storage
System (DCSS)– This component allows a HiM to
run applications even if application code is not present on nodes
N et-IPN et- IP
Root
W SW S
M ac ro-node M ac ro-node
M ac ro-node
C C
C
N et-IP
N et-F P
R M
R M R M
R M
C lus te r
C o nso le
s ubs c r ibe
publis h
p 1.3 .2 .1 p 1.3 .2 .3
p 1.3 .2 .2
p 1.3 .2 = p 1.3 .2 .1+ p 1.3 .2 .2+ p 1.3 .2 .3p1.3 .1
p 1.3= p 2.1+ p 2.2p 1.1p 1.2
p 1.4
p 1.1 = p 1.1 .1+ p 1.1 .2+ p 1.1 .3p 1.2p 1.3 = p 1.3 .1+ (p 1.3 .2 .1+ p 1.3 .2 .2+ p 1.3 .2 .3 )p 1.4
H M H MH MH M
H M H M H M
p : c o m p u t in g p o w e r o f a h o s to r a m a c ro -n o d e
H M H M
C
p 1.1 .1 p 1.1 .2 p 1.1 .3
HiMM node architecture
• HiMM implements its services in several software components whose interfaces are designed according to a Component Framework approach
• Both nodes and coordinators are processes in which a set of software components are loaded either at start-up or at run-time
• The main components are: – the Node Manager (NM)
• guarantees macro-node consistency• provides users with services for
writing distributed applications• takes charge of some system tasks,
such as the creation of new nodes at run-time
– the Node Engine (NE)• The Message Consumer (MC)• The Execution Environment (EE)• The Level Sender (LS)
N ode E ngine N ode M a na ge r(Le v e l M a n a g e r)
E x e c u t io nE n v i r o n m e n t
M e s s a g eC o n s u m e rL e v e l Se n d e r
E P s
L o a da c o m p o n e n t
I n s t a l la c o m p o n e n t
a C o m p o n e n t
N o d e M a n a g er (N M ) : m an ag es a n o d e in o rd er to g u aran tee th e H iM co n s i s ten cyN o d e E n g i n e (N E ) : d efin es th e b eh av io r o f a n o d eL ev el S en d er (L S ) : s en d s a m es s ag e (an o b ject ) to a n o d e o r a g ro u p o f n o d esM es s a g e C o n s u m er (M C ) : receiv es m es s ag es fro m th e n etw o rkE x ecu ti o n E n v i ro n m en t (E E ) : s to res a co m p o n en t o f a d i s t rib u ted ap p l icat io n
HiMM communication API
• HiMM allows nodes to communicate using the component LevelSender
• A LevelSender can be customized even if a default one is always available – This component provides users with simple communication
mechanisms based on the asynchronous sending of objects
class DefaultLevelSender impements LevelSender {
public void send(Object m, int node) { … }
public void broadcast(Object m) { … }
public void deepBroadcast (Object m) { … }
}
HiMM: interaction among components
HO S T
HO S THM
HiM N ode
Configurator
N o d e M g r
G UI
EE
LS M C
S end a command
C o n s o le
N o d e En g in e
class Application implements ExecutionEnvironment { void init(NodeMgr nm) throws … { nodeMgr = nm; } void start() { … nodeMgr.downLevelSender().send(msg, node); nodeMgr.downLevelMgr().addNode(…); Object o = nodeMgr.downLevelMsgConsumer().receive(); … }}