Presentation for my paper in PDCAT’08, Dunedin, New Zealand.

1. 1
A Layered
Virtual Organization Architecture
for Grid
Yongqiang Zou, Li Zha, Xiaoning Wang, Haojie Zhou, Peixu Li
Institute of Computing Technology,
Chinese Academy of Sciences
2 Dec. 2008
Presented at PDCAT’08, Dunedin, New Zealand

2. 2
Outline
 What’s a “good” VO architecture?
 Related work
 Layered VO architecture
 Implementation and Evaluation
 Conclusion and Future work

3. 3
VOs for high performance
computing
Encapsulate
HPCs,
storages and
software as
distributed
resources
Organize
users and
resources
into VOs
Users run
portal or
CLI
in different
VOs

4. 4
VOs for distributed
application integration
Encapsulate
Database data
or software
components as
distributed
services
Organize
users and
resources
into VOs
Develop
applications
based on
services and
run them
in VOs

5. 5
What’s a “good” VO
architecture?
 Minimal but
sufficient
functionalities
 manages users,
resources, and
VO instances
 provides
policies to
support cross-
domain access
control, user
profile, etc
 maintains the
context of
operations

6. 6
What’s a “good” VO
architecture?
 Decentralization
 Sites can provide
services
independently
 Resource
providers can
share resources
without other
people’s
permission

7. 7
What’s a “good” VO
architecture?
 Flexibility
 Has multiple
ways to
organize users
and resources
 Supports
Portable
applications

8. 8
What’s a “good” VO
architecture?
 Simplicity
 Should use minimal concepts
 Should have minimal uniform mechanisms
 Efficiency
 The overhead should be minimal

9. 9
Related work
 Initial concept of Agora (JoGC’04)
 VO Concept <Subject, Object, Policies, Context> with
prototype implementation and evaluation
 More requirements and experiences are collected, goals
are refined
 CAS(PDSN Workshop’02), VOMS(EAGC’03),
VOMRS, Permis(FGCS’03), GUMS(CHENP’03),
GridShib(PKI R&D Workshop, 2005)
 Focus on detailed functionalities of user registration,
authentication, authorization, or access control policies;
 Agora provides user, resource, policy and context
management in decentralized way.

10. 10
Related work
 UNIX Operating System (C.ACM’74)
 A simple access control model
 Agora borrows the ideas of i-node and driver and
extends AC model from a local site to VO level
 VO in business, or called virtual enterprise
(VE) (JIM'98)
 Requirements also benefit Agora, such as
hierarchical organizations

11. 11
Agora design: basic concepts
 Resource
 User
 Agora: the VO instance
 Application
 Grip: “grid process”, once running of applications
 an application is represented and managed by a
grip, runs on behave of a user in a specified agora,
and may access the authorized resources in the
agora

12. 12
Layered VO architecture:
Agora
Physical layer: manages resources
Naming layer: manages information of global entities
Logic Layer: provides agora functionalities

13. 13
Physical Layer
 All kinds of external resources
 RController: an abstraction to manipulate
external resources, similar as driver
 Has uniform operations for all kinds of resources:
add, remove, open, execute, and close
 Really manages the resources
 For functionality, simplicity and efficiency

14. 14
Naming Layer : GNode
 Global entities: User, Resource, Agora, etc
 GNode: an uniform data structure for all
entities

15. 15
Naming Layer : Naming
 Naming: decentralized GNode management
system to provide a virtualized name
 Supports low latency high success rate lookup by
guid
 Supports low latency high recall rate multiple
attributes search
 For functionality, decentralization, flexibility,
simplicity

16. 16
Logic Layer : access control
 Access control model
 For owner, group and agora user, Check read,
write and execute permission
 DAC/MAC-hybrid: by self mode and delegate
mode export/link
 Decision in Agora, transfer as SAML token,
enforcement at RController
 For functionality, decentralization

17. 17
Logic Layer : func. Impl.
 Armed with Naming and RController, it’s
straightforward to implement Agora
Sequential diagram of two most “complex” agora operations: add/remove
RController Agora logicWrap them together

18. 18
Agora Architecture at runtime
Agora
Naming
Grip Grip
Naming
Agora
RControlle
r
RControlle
r
RControlle
r
Context

19. 19
Implementation
 Host environment
 JDK 1.4 or plus
 Tomcat 5.0.28 + Axis 1.2RC2
 Agora, along with grip, forms the essential
part of Grid Operation System (GOS), called
GOS Core
 Implements RController for Apache Web services
as Axis handlers
 Provides Web services interface and Java/C++
user client libraries

20. 20
Deployment

21. 21
Application environments
 China National Grid (CNGrid)
 6 cities, 10 sites, > 20TFLOPS (NPC’05)
 7 cities, 12 sites, > 200TFLOPS (in 2009)
 11 domain-specific applications
 To support high performance computing across multiple
sites
 A distributed application integration Grid
 >15 sites
 > 8 applications
 To support portable applications for serviced software
components

22. 22
Evaluation
 Minimal but sufficient functionalities
 Sufficient for our applications
 Reduce redundant operations, eg merge, split agoras
 Decentralization
 Each site is able to provide services independently by
default agora and decentralized naming
 Resource providers can autonomously provide and share
resources by DAC/MAC-hybrid access control

23. 23
Evaluation
 flexibility
 Support export/link way to organize users/resources
 Some agora usage patterns has emerged
 Doesn’t support hierarchy agoras
 portable applications
 Applications can run in different agoras, on behave of
different users, with different resource set to search and
selection, and under different AC policies
 By application model based on runtime binding
OperateContext

24. 24
Evaluation
 Simplicity
 five basic concepts
 three uniform mechanisms RController, GNode,
and the DAC/MAC-hybrid access control
mechanism for all kinds of resources
 Agora code (without blank lines or comments)
drops from 29.7 to 14.8 thousand lines

25. 25
Evaluation
 Efficiency
 Round-trip time of Ping service (ms)
 two Intel(R) Xeon(TM) 2.40GHz CPUs, 4 GB memory,
Gigabytes Ethernet, Redhat Linux AS3, MySQL 4.1.12, Sun
JDK1.5.0_06, Apache Tomcat 5.0.28, Apache Axis 1.2RC2.
 Is it acceptable?
 Open and close will involve Agora, but the execution will
bypass the Agora
 It’s overhead for flexibility and security: lookup the service,
construct the OperateContext, and SOAP signature
 The overhead vs. the real application payload
 The overhead can be shared: one open with multiple
executions
open/exec/close exec overhead
Axis ping 73.38 18.36 55.02
Sec ping 482.36 239.44 242.92

26. 26
Conclusion
 Agora proposes five goals for VO
architecture: minimal but sufficient VO
functionalities, decentralization, flexibility,
simplicity, and efficiency.
 Agora solves the problem by proposing the
three-layer architecture with RController,
GNode and DAC/MAC-hybrid AC.
 Experiences show that Agora achieves these
five goals.

27. 27
Future work
 Apply Agora in cloud computing
environments
 Employ cloud related technologies to
enhance Agora reliability and scalability
 Implement Agora in OS level

28. 28
Thanks!
Q&A