1 / 30

CNGrid Software Progress

EU Grid At Asia Workshop June 23, 2005, Beijing. CNGrid Software Progress. Zhiwei Xu zxu@ict.ac.cn www.cngrid.org Institute of Computing Technology Software Team Chinese Academy of Sciences China National Grid. Contents. CNGrid Software Objectives Approach and Roadmap Status

prem
Download Presentation

CNGrid Software Progress

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EU Grid At Asia WorkshopJune 23, 2005, Beijing CNGrid Software Progress Zhiwei Xu zxu@ict.ac.cn www.cngrid.org Institute of Computing Technology Software Team Chinese Academy of Sciences China National Grid

  2. Contents • CNGrid Software Objectives • Approach and Roadmap • Status • Software Development and Applications • Research Focus and Techniques • Ideas for EU cooperation

  3. CNGrid Software Objectives • Support applications in four areas • Connect distributed resources into single system images: eliminate silos • Mask resource heterogeneity and distribution • Automate common requirements • Reduce lifecycle cost of distributed applications, thus enabling sharing and cooperation

  4. App Scope of CNGrid Software Manufacturing Resources and Environment Services Sector ScienceResearch CNGrid Software Distributed Resources and Services

  5. CNGrid Software provides automated common supports Application Grids SQL GIS WebSphere MySql Single System Image Single System Image Windows HP-UX AIX Linux AMD VLIW Power4 IA-32 Connectivity, Transparency, Automation Data Miner MatLab PDESolver Simulator Analyzer Oracle Solaris SPARC

  6. CNGrid Software Grid PortalGriDaEnGrishieldVega GOS Web Browser C/S Client Other Client Grid Security Effective Resources Grid Portal Web Style Grid Portal C/S Style OtherStyle GOS API and Utilities OGSAPlatformLayer Vega GOS Constructs and Services ▪ Resource Info ▪ Resource Mgmt ▪ Jobs ▪ User ▪ Monitoring ▪ Accounting ▪ Data Virtual Resources GOS Kernel （Apache, OMII, GT4,） GT Services，Web Services Physical Resources HPC Storage Database Software Files

  7. GS GR GS GR GS GR GR GS GOS Constructs GSML Page GSML Page GSML Page Client Composer Mapper Internet Effective Virtual Physical Agora 2 Agora 1 Grip3 Grip4 Grip1 Grip2 Grid Operating System（GOS Kernel, Core, Libraries, Utilities） DawningDagger Beijing Node Shanghai Node Xi’an Node PhysicalResource Server Grid Router Grid Switch VirtualResource Composing EffectiveResource Mapping

  8. Grishield: CNGrid Security • End-to-End • From user log-on to physical resource execution • Details are hidden from user/developer • Based on WS-Security • Cert based authentication; Token based authorization & AC; signature Web Other Client uCert uCert uid/pass Agora pCert pCert Portal/Server pCert pCert Grip Container User Res AA uTK uTK uTK pCert pCert pCert pCert uTK uTK uTK uTK Phy Svc Phy SVC Phy SVC Phy SVC

  9. GridDaEn: Grid Data Engine • System level service of GOS developed by NUDT • Provide uniform data operations over global namespace uCert Browser Grid Application uCert user cert Grid Portal Grid Portal Engine Agora Service u_p Grip Container uTK DRB Service DRB Service DRB Service DRB Service

  10. GridDaEn: Grid Data Engine • Global logical view  • Utilize a uniform three-level naming scheme that shields users from low-level heterogeneous storage resources • Provide global logical view of data resources in multiple domains for users • Uniform access  • Provide a set of uniform APIs and SDKs to access and manage geographically distributed data resources.     • Federated services  • A distributed structure: distributed DRB (Data Request Broker) and distributed MDIS (Metadata Information Server) • Several DRBs combined to provide federated services • Distributed data replication and caching

  11. Grid Data Engine

  12. Vega GOS

  13. Vega GOS and OGSA V1.0 • Vega is an implementation of (part of) OGSA • Vega would like to contribute to OGSA • After implementation and testing (running codes) • Loose coupling • Partner with other groups • Focus on 4 key issues and aim at minimal common requirements • Naming, Process/States, VO, Programming • Vega complements existing grid projects • Focus on implementation architecture, not protocols/services • Use computer systems approach, not middleware or network • Utilize existing software • At Vega GOS kernel level • Apache; OMII, GT4; Commercial • As services • At Vega GOS application level

  14. Naming in OGSA and Vega GOS • Vega matches OGSA 3-level naming convention • OGSA Human-Oriented Abstract Address • Vega (EVP) Effective Virtual Physical • As the primary way for virtualization • OGSA Naming specification must include • Precise definitions and axioms • Syntax and semantics (rough consensus) • Who provides, uses, and maintains such names • Scoping and name/address space • Lifecycle and exception handling • Mapping, resolution, binding • Provision for resources

  15. Layered Resource Naming And Mapping Effective resource Agora1 Agora2 Top Layer(Agora) E2 E3 ERes1 eres://an:ren eres://agora_name:res_e_name PT(V4→E3) PT(V3→E2) PT(V1→E1) PT(V2→E1) PT(V2→E2) Virtual resource Overlaps V2 V3 VRes1 V4 Bottom Layer(Router) vres://router_name:res_v_name Physical resource Service ContainerA Router1 Service Container B Router2 PRes1 P2 P4 P3 http://hostname:port/suffixes

  16. VO in OGSA and Vega GOS • There is no precise definition of VO in OGSA • Agora is a concrete example of VO (community) • Agora has a precise definition, and it holds • Subjects, objects, context/policies information • Agora-related system services • Agora is persistent and “static” • Application programmer knows the agora concept, but agora does not appear in app codes

  17. Inner Structure of Agora Tomcat+Axis Agora Access Control Mechanism User Login Resource Authorization Resource Selection User Mgmt. Interface Resource Mgmt. Interface AC Policy Mgmt. Authorization Engine Resource Mgmt. Client User Mgmt. Client AAA Client Tomcat+Axis Tomcat+Axis Tomcat+Axis Resource Mgmt. Service User Mgmt. Service Authorization Authority Service VRes ERes Mapping PT User Name Role Proxy profile

  18. Process/States in OGSA and Vega GOS • There is no process concept in OGSA 1.0 • Grip is distributed process in grids environment • A runtime construct representing a subject (a grid user running a grid application) to access and utilize objects (grid resources and services) • Classification of “states” • Session related • Application logic specific • Grid system related • Resource related • Service specific Grip

  19. Grip authentication Agora Service uid/pass create grip Proxy, Profile ERes name grip bind • uCert,Profile VRes name, Token, PT • uCert ProfileVResTokenPTPRes • uCert ProfileVResTokenPT • resource selection • resource authorization grip invoke • uCert ProfileVResTokenPT PResRet grip getResult resource locating close • return • cache service invocation Network of Resource Routers Physical Service Physical Service Physical Service

  20. Put It Together UI and Utility Tools Web Other Client Grip User, App Logic Address Space, States Agora Policies:Security and Selection Common Supportsnot per-service or per-application codes Core and Kernel System ServicesResource Services Phy Svc Phy SVC Phy SVC Phy SVC Follow the E2E and KISS principlesLoose coupling; Hide details, reduce coding; Try to minimize abstractions 4 abstractions: User, (Effective) Service, Grip, Agora 5 API “functions”

  21. GSML : Grid Service Markup Language • A new programming language for end users • XML-based, descriptive rather than imperative • Event-driven model • Component-based design • Focus on interaction Main Constructs of the language: Pipes are software components consuming various resources (include services). At runtime, pipes are independent, concurrent, event-driven processes (or threads). The only way for interacting with pipes is sending events to or intercepting events from them.

  22. Edit Area GSML Software Suite: A WYSIWYG Composer Resource Repositories Event Properties

  23. GSML: Demo Applications Resource Information Monitor Digital library E-learning Collaboration

  24. GSML:A Simple Example <head><title>untitled</title></head> <body> <row><cell> <pipe id="pService" type="WSInvoker"> <eventset> <event source="System" type="pageload"/> <target destination=“pService" type="WSInvoke"> <para> <name>wsdlLocation</name> <value><![CDATA[http://www.webservicex.com/stockquote.asmx?WSDL]]></value> </para> <para> <name>portName</name> <value>StockQuoteSoap</value> </para> …. </target> </eventset> </pipe> </cell></row> </body>

  25. Aviation and Space Simulation Computing

  26. Biological Computing - Genome Sequence Tracing

  27. Geological Computing - Underground Water Evaluation

  28. CNGrid Software Roadmap in 2005 • 2004.11 2.0 preview Sample Apps • 2005.2 2.0 alpha • 2005.4 2.0 beta CNGrid Apps • 2005.6 2.0 CNGrid Deploy • 2005.7- 2.0 on OMII and GT4 • 2005.11.30-12.3 CI6016 & GCC 2005 Exhibit • www.ict.ac.cn/ci6016

  29. Suggestions for EU Cooperation • Infrastructure Projects • Connect China National Grid to EU grids • CNGrid Software to connect resources and applications • Research Projects • Net-centric OS • Architecture • Key OS abstractions and constructs (Naming/Virtualization, VO, Grip) • Exception handling • Optimization • Programming Environment • Language and tools • Debugging

More Related