• Save


Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Zou Layered VO PDCAT2008 V0.5 Concise



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

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



Total Views
Slideshare-icon Views on SlideShare
Embed Views



2 Embeds 7

https://www.linkedin.com 4
http://www.linkedin.com 3



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • ApologizeIntellectual Property Hello everyone, my name is Yongqiang Zou, I come from Institute of Computing Technology, Chinese Academy of Sciences. It’s my pleasure to introduce the System Software of China National Grid. I will give a overview of it.

Zou Layered VO PDCAT2008 V0.5 Concise Zou Layered VO PDCAT2008 V0.5 Concise Presentation Transcript

  • 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 1
  • Outline What’s a “good” VO architecture?  Related work  Layered VO architecture  Implementation and Evaluation  Conclusion and Future work  2
  • VOs for high performance computing User1 User2 ShanghaiAdmin BeijingAdmin HongkongAdmin Users run portal or gSubmit gStatus CLI in different VOs BeijingVO Organize HPCVO users and HongkongVO ShanghaiVO resources into VOs BatchService FileService HPC HPC and Storage BlastApp Storages Hongkong Beijing Internet Encapsulate ModellerApp HPCs, storages BatchService and software FileService as distributed BlastApp BatchService resources HPC FileService Shanghai Storages BlastApp 3 ModellerApp
  • VOs for distributed application integration Develop Chengdu User applications based on services and run them in VOs Beijing User Nanjing User Organize users and CollaborativeVO resources BeijingVO ChengduVO into VOs NanjingVO Internet Encapsulate Database data or software EmployeeService components as EmployeeService EquipmentService distributed Beijing EquipmentService services 4 EmployeeService Chengdu Nanjing EquipmentService
  • What’s a “good” VO architecture? Minimal but  User1 User2 ShanghaiAdmin BeijingAdmin HongkongAdmin sufficient gSubmit functionalities gStatus manages users,  resources, and VO instances BeijingVO HPCVO provides  HongkongVO ShanghaiVO policies to support cross- BatchService domain access FileService HPC HPC and Storage BlastApp control, user Storages Hongkong Beijing Internet ModellerApp profile, etc BatchService FileService maintains the  BlastApp BatchService context of HPC FileService Shanghai operations Storages BlastApp 5 ModellerApp
  • What’s a “good” VO architecture? User1 Decentralization User2 ShanghaiAdmin  BeijingAdmin HongkongAdmin Sites can provide  gSubmit gStatus services independently Resource BeijingVO  HPCVO providers can HongkongVO ShanghaiVO share resources without other BatchService FileService people’s HPC HPC and Storage BlastApp Storages Hongkong Beijing Internet permission ModellerApp BatchService FileService BlastApp BatchService HPC FileService Shanghai Storages BlastApp 6 ModellerApp
  • What’s a “good” VO architecture? User1 User2 ShanghaiAdmin BeijingAdmin HongkongAdmin Flexibility  gSubmit Has multiple gStatus  ways to organize users BeijingVO and resources HPCVO HongkongVO Supports ShanghaiVO  Portable BatchService applications FileService HPC HPC and Storage BlastApp Storages Hongkong Beijing Internet ModellerApp BatchService FileService BlastApp BatchService HPC FileService Shanghai Storages BlastApp 7 ModellerApp
  • What’s a “good” VO architecture? Simplicity  Should use minimal concepts  Should have minimal uniform mechanisms  Efficiency  The overhead should be minimal  8
  • 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. 9
  • 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 10
  • 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 11
  • Layered VO architecture: Agora Physical layer: manages resources Naming layer: manages information of global entities Logic Layer: provides agora functionalities 12
  • 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  13
  • Naming Layer : GNode Global entities: User, Resource, Agora, etc  GNode: an uniform data structure for all  entities 14
  • 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 15
  • 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  16
  • Logic Layer : func. Impl. Armed with Naming and RController, it’s  straightforward to implement Agora Wrap them together RController Agora logic 17 Sequential diagram of two most “complex” agora operations: add/remove
  • Agora Architecture at runtime Grip enabled application commnication User Space User Space Fork Application Application Application Application Application Logic Logic Logic Logic Logic Context Context Context Context Context Context g1 g1 g5 g6 g6 g2 g4 g7 g7 g7 Core Space Core Space g3 g8 g8 Grip Grip g2 Grip1 Grip2 Grip3 Grip4 Grip5 Agora2 Agora1 Agora Agora Resource Routing GNode1 GNode2 GNode3 GNode4 GNode5 GNode6 GNode7 GNode8 rwxr-xr-x rwxr--r-- rwxr--r-- rwxr--r-- rwxr--r-- Naming rwxr--r-- rwxr--r-- rwxr--r-- Naming Resource Export GNode1 from agora1 to agora2 Resource Register Register RController RController RController RC RC RC RC RC RC RC Res2 Res8 Res1 Res3 Res4 Res6 Res7 Admin domain1 Admin domain2 Admin domain3 18
  • 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 19
  • Deployment GOS Core DB server Agora Function logic App GOS Core GOS Client Grip Naming Server HostEnv HostEnv RControllers client GOS server Tomcat 5.0.28, Axis Linux/Windows, JDK1.4 Internet /Intranet GOS Core HostEnv GOS server GOS server GOS Client HPC CLI Portal Storages Other apps client Computing and Linux/Windows, JDK1.4 20 Storage Cloud
  • 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 21
  • 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 22
  • 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 23
  • 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 24
  • 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. open/exec/close exec overhead Axis ping 73.38 18.36 55.02 Sec ping 482.36 239.44 242.92 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  25 The overhead can be shared: one open with multiple  executions
  • 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. 26
  • Future work Apply Agora in cloud computing  environments Employ cloud related technologies to  enhance Agora reliability and scalability Implement Agora in OS level  27
  • Thanks! Q&A 28