Successfully reported this slideshow.

Zou Layered VO PDCAT2008 V0.5 Concise

520 views

Published on

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

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Zou Layered VO PDCAT2008 V0.5 Concise

  1. 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. 2 Outline  What’s a “good” VO architecture?  Related work  Layered VO architecture  Implementation and Evaluation  Conclusion and Future work
  3. 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. 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. 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. 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. 7 What’s a “good” VO architecture?  Flexibility  Has multiple ways to organize users and resources  Supports Portable applications
  8. 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. 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. 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. 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. 12 Layered VO architecture: Agora Physical layer: manages resources Naming layer: manages information of global entities Logic Layer: provides agora functionalities
  13. 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. 14 Naming Layer : GNode  Global entities: User, Resource, Agora, etc  GNode: an uniform data structure for all entities
  15. 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. 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. 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. 18 Agora Architecture at runtime Agora Naming Grip Grip Naming Agora RControlle r RControlle r RControlle r Context
  19. 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. 20 Deployment
  21. 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. 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. 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. 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. 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. 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. 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. 28 Thanks! Q&A

×