Characterizing the Grid: Attributes, Definition, and Formalisms

1
Characterizing the GridAttributes, Definition,
and Formalisms

• Journal of Grid computing (Vol.1, Issue.1)
• Zsolt Nemeth and Vaidy Sunderam
• Kyung-Lang Park
• (2003. 7. 23)

2
Contents

• Introduction (motivation)
• ASM (Abstract State Machine)
• Distributed Computing versus Grids
• Universes, signature and rules of
• Distributed computing
• Grids
• Discussion

3
Introduction

• There are two perspectives on Grids
• Utility perspective
• Resource sharing perspective not new
• Although the motivations and goals for Grids are
  obvious, there is no clear definition
• The real differences between Grid and Distributed
  computing have not been clearly articulated
• This paper presents a formal definition of what a
  Grid system should provide (using Abstract State
  Machine)

4
Abstract State Machine

• ASM is a mathematically well-founded framework
  for system design and analysis
• Universe A basic set (e.g., PROCESS, RESOURCE)
• Signature A finite set of function names
• gcd PosInts PosInts -gt Nat
• Rule A set of statement like programming
  language
• If OUTPUT undef then
• if (A mod B 0) then Output B
• else
• A B
• B A mod B
• endif
• endif

5
ASM Example

• The superuniverse X
• Universes TOKEN, COLOUR, VALUE
• Signature
• val TOKEN -gt VALUE
• col TOKEN -gt COLOUR
• Rule
• If col(t) red then
• val(t) val(t) 1
• col(t) blue

6
Distributed computing vs. Grid
7
Distributed computing vs. Grid

• Grids
• A virtual pool of resources
• A user has access to pool but not to individual
  nodes
• Access to a resources may be restricted
• The user has a little or no knowledge about each
  resource
• Resources span multiple trust domains
• Elements in the pool gtgt 100, dynamic

• Conventional distributed com
• A virtual pool of computational nodes
• A user has access (credential) to all the nodes
  in the pool
• Access to a node means access to all resources on
  the node
• The user is aware of the capabilities and
  features of the nodes
• Nodes belong to a single trust domain
• Elements in the pool 10-100, more or less static

8
Universes and signatures

• app PROCESS -gt APPLICATION
• user PROCESS -gt USER
• request PROCESS ?RESOURCE -gt true, false
• uses PROCESS ?RESOURCE -gt true, false
• mapped PROCESS -gt NODE
• belongsTo RESOURCE ?NODE -gt true, false
• installed TASK NODE -gt true, false
• attr RESOURCE, NODE, TASK -gt ATTR
• arch RESOURCE -gt ARCH
• location RESOURCE -gt LOCATION
• compatible ATTR ATTR -gt true, false
• canLogin USER NODE -gt true, false
• canUse USER RESORUCE -gt true, false
• state PROCESS -gt running, waiting,
  receive_waiting
• from MESSAGE -gt PROCESS
• to MESSAGE -gt PROCESS
• expecting PROCESS -gt PROCESS any

9
Rules for DC
10
Initial state

• Common state
• User(pi) u ? USER
• Request(pi,r) true
• Uses(pi,r) false
• Tasks(pi) ? undef, Mapped(pi) undef
• Only in DC (not for Grids)
• CanLogin(u,ni) true (1 lt i lt l)
• Installed(taks(pi),n) true
• Compatible(arch(task(pi),arch(n))

11
Rule 1Mapping

• If mapped(p) undef then
• Choose n in NODE satisfying CanLogin(user(p),n)
  installed(task(p),n)
• Mapped(p) n
• endchoose

12
Rule 2 Resource grant

• If (?r ? RESOURCE) request(p,r) true
  BelongsTo(r, mapped(p))
• Then
• Uses(p,r) true
• Request(p,r) false

13
Rule 3 State transition

• If (?r ? RESOURCE) request(p,r) false
  expecting(p) undef
• Then
• State(p) running

14
Rule 4 Resource request

• If state(p) running event (task(p))
  req_res(reslist) then state(p) waiting
• do forall r ? RESOURCE r ? reslist
• request(p,r) true
• enddo

15
Rule 5 Process spawning

• If state(p) running event(task(p))
  spawn(reslist) then
• extend PROCESS by p with
• user(p) user(p)
• app(p) app(p)
• state(p) waiting
• mapped(p) undef
• do forall r ? RESOURCE r ? reslist
• request(p,r) true
• Enddo
• endextend

16
Rule 6 Send (communication)

• If state(p) running event(task(p)) send(p)
  then
• extend MESSAGE by msg with
• to(msg) p
• From(msg) p
• endextend
• if expecting(p) ? p expecting(p) ? any then
• expecting(p) p
• state(p) waiting
• endif

17
Rule 7 Receive (communication)

• If state(p) running event(task(p))
  receive(p any) then
• if (?msg ?MESSAGE) to(msg) p
  from(msg) ptrue
• then
• MESSAGE(msg) false
• expecting(from(msg)) undef
• else
• expecting(p) p any
• state(p) receive_waiting
• endif

18
Rule 8 Termination

• If state(p) running event(task(p))
  terminate then PROCESS(p) false

19
Rules for Grids
20
Initial state

• Common state
• User(pi) u ? USER
• Request(pi,r) true
• Uses(pi,r) false
• Tasks(pi) ? undef, Mapped(pi) undef
• Only in Grids
• CanUse(u,ri) true (1 lt i lt m)

21
Rule 9 Resource selection

• If (?r ? RESOURCE) request(p,r) true
• CanUse(user(p),r)
• Then
• if type(r) resource0 then
• mapped(p) location (r)
• installed(task(p), location(r)) true
• endif
• request(p,r) false
• uses(p,r) true

22
Resource abstraction

• Conventional distributed systems
• -there is an implicit mapping of abstract
  resources onto physical ones.
• -This is possible becuase the process has been
  (already) assigned to a node and its resource
  needs are satisfied by local resources present on
  the node.
• -BelongsTo checks the validity of the implicit
  mapping in Rule 2.

• Grid environments
• -A process' resource needs can be satisfied from
  various nodes in various ways, therefore
  uses(p,r) cannot cannot be interpreted for an
  abstract r.
• -There must be an explicit mapping between
  abstract resource needs and physical resource
  objects that selects one of thousands of possible
  candidate resources that conforms to abstract
  resource needs.

23
Resource_mapping

• If (?ar ? ARESOURCE, pr ? PRESOURCE)
• Mappedresource(pr,ar) undef
• request(pr, ar) true
• Then
• choose r in PRESOURCE
• satisfying compatible (attr(ar), attr)
• mappedresource(pr,ar) r
• endchoose

24
Resource abstraction

• Let r mappedresource(p,ar)
• If (?ar ? ARESOURCE) request(p,ar) true
• r ? undef
• CanUse(user(p),r)
• Then
• if type(r) resource0 then
• mapped(p) location (r)
• installed(task(p), location(r)) true
• endif
• request(p,ar) false
• uses(p,r) true

25
Changed signature

• app PROCESS -gt APPLICATION
• user PROCESS -gt USER
• request PROCESS ?ARESOURCE -gt true, false
• uses PROCESS ?PRESOURCE -gt true, false
• mapped PROCESS -gt NODE
• belongsTo PRESOURCE ?NODE -gt true, false
• installed TASK NODE -gt true, false
• attr ARESOURCE, PRESOURCE, NODE, TASK -gt ATTR
• arch RESOURCE -gt ARCH
• location PRESOURCE -gt LOCATION
• compatible ATTR ATTR -gt true, false
• canLogin USER NODE -gt true, false
• canUse USER PRESORUCE -gt true, false
• state PROCESS -gt running, waiting,
  receive_waiting
• from MESSAGE -gt PROCESS
• to MESSAGE -gt PROCESS
• expecting PROCESS -gt PROCESS any

26
Access control mechanism

• Let r mappedresource(p,ar)
• If (?ar ? ARESOURCE) request(p,ar) true
• r ? undef
• CanUse(user(p),r)
• Then
• if type(r) resource0 then
• mapped(p) location (r)
• installed(task(p), location(r)) true
• else if (?/ p ?PROCESS) handler(r) p
• extend PROCESS by p with
• mapped(p) location(r)
• installed(task(p), location) true
• handler(r) p
• do forall ar ? ARESOURCE
• request(p, ar) false
• enddo
• endextend
• endif
• request(p,ar) false

27
User_mapping

• Let r mappedresource(p,ar)
• If (?ar ? ARESOURCE) request(p,ar) true
• r ? undef
• CanUse(user(p),r)
• Then
• if type(r) resource0 then
• mapped(p) location (r)
• installed(task(p), location(r)) true
• else if (?/ p ?PROCESS) handler(r) p
• extend PROCESS by p with
• mapped(p) location(r)
• installed(task(p), location) true
• handler(r) p
• do forall ar ? ARESOURCE
• request(p, ar) false
• enddo
• endextend

28
Definition for Grid

• A Grid must minimally provide user and resource
  abstraction

29
Discussion

• From Abstract Functionalities (What)
• to Real services (How)
• Applying the Criteria
• Seti_at_home
• Condor
• OGSA

30
From what to how
31
Applying criteria

• Seti_at_home
• User has no a priori knowledge about the actual
  physical resource
• User has no login access on the individual
  resource node
• Condor
• It clearly realizes resource abstraction
• the boundaries of a single pool can be extended
  (flocking)
• Login access governed by the rules of resource
  owners agreement

32
Applying criteria

• Open Grid Service Architecture (OGSA)
• OGSA is a more refined and well structured
  formulation of the same principles
• Virtualization introduce another level of
  abstraction instead of physical resources