Mary Fran Yafchak, SURA Jim Jokl, University of Virginia

1. Development & Implementation of an Inter-institutional Multi-purpose GridSURAgrid, 11/22/05UNC-Charlotte: Grid Computing-ITSC 4010-001 Mary Fran Yafchak, SURA Jim Jokl, University of Virginia Art Vandenberg, Georgia State University

2. Presentation agenda • About SURAgrid - Mary Fran Yafchak • SURAgrid authN/authZ - Jim Jokl • SURAgrid portal - Need to decide who • SURAgrid applications - Art Vandenberg • Q&A - All This is a living, breathing project. Exchange of ideas encouraged throughout!

3. About SURAgrid • A “beyond regional” initiative in support of SURA regional strategy “Mini-About” SURA: • SURA region: 16 states & DC; Delaware to Texas • SURA membership: 62 SE research universities • SURA mission: Foster excellence in scientific research, strengthen capabilities, provide training opportunities • Evolved from the NMI Testbed Grid project, part of the NMI Integration Testbed Program • http://www1.sura.org/3000/NMI-Testbed.html

4. SURAgrid Goals • SURAgrid: Organizations collaborating to bring grids to the level of seamless, shared infrastructure • Goals: • To develop grid infrastructure that is scalable and that leverages local identity and authorization while managing access to shared resources • To promote use of this infrastructure for the broad research and education community • To provide a forum for participants to share experience with grid technology, and participate in collaborative project development

5. University of Alabama at Birmingham* University of Alabama in Huntsville* University of Arkansas* University of Florida* George Mason University* Georgia State University* Great Plains Network University of Kentucky* University of Louisiana at Lafayette* Louisiana State University* University of Michigan Mississippi Center for SuperComputing Research* University of North Carolina, Charlotte North Carolina State University* Old Dominion University* University of South Carolina* University of Southern California Southeastern Universities Research Association (SURA)** Texas A&M University* Texas Advanced Computing Center (TACC)* Texas Tech University Tulane University* Vanderbilt University* University of Virginia* Resources on grid *SURA member **Project planning SURAgrid Participants

6. Focus Areas • Authentication & Authorization • Themes: maintain local autonomy, leverage enterprise infrastructure • Grid-Building • Themes: heterogeneity, flexibility, interoperability, scalability • Application Development • Themes: immediate benefit to applications, applications drive development • Project Planning • Themes: cooperative, representative, sustainable

7. In the Coming Months… • Continue evolving key areas • Grow and solidify grid infrastructure • Continue expanding and exploring authN/authZ • Identify & “grid-enable” new applications • “Formal” work on organizational definition • Charter, membership, policies, governance • Develop funding & collaboration opportunities • Some areas of interest: scalable mechanisms for shared, dynamic access; interoperability in grid products; grid-enabling applications; grids for education; broadening participation; support and management of large-scale grid operations

8. Jim Jokl, University of VirginiaSURAgrid authN/authZ

9. SURAgrid Authentication • Goal • Develop a scalable inter-campus solution • Preferred mechanisms • Leverage campus middleware activities • Researchers should not need to operate their own authentication systems • Use local campus credentials inter-institutionally • Rely on existing higher education inter-institutional authentication efforts

10. Inter-campus Globus Authentication • Globus uses PKI credentials for authentication • Leverage native campus PKI credentials on SURAgrid • Users do all of their work using local campus PKI credentials • How do we create the inter-campus trust fabric? • Standard inter-campus PKI trust mechanisms include • Operating a single Grid CA or trusting other campus CAs • Cross-certification and Bridge PKIs • How well does Globus operate in a bridged PKI? • OpenSSL PKI in Globus is not bridge-aware • Known to work from NMI Testbed project • Decision: intercampus trust based on a PKI Bridge • Leverage EDUCAUSE Higher Education Bridge CA (HEBCA) when ready

11. Background: Cross-certification I: UABS: UAB I: UVAS: UVA • Top section • Traditional hierarchical validation example • Bottom section • Validation using cross certification example • UVA signed a certificate request from the UAB CA • UAB signed a certificate request from the UVA CA • This pair of cross certificates enables each school to trust certs from the other using only their own root as a trust anchor • An n2 problem I: UABS: User-2 I: UVAS: User-1 I: UABS: UAB I: UVAS: UVA I: UABS: UVA Cross Certs I: UVAS: UAB I: UVAS: User-1 I: UABS: User-2

12. Bridge CA Cross-certificate pairs Campus A Campus B Campus n Mid-A Mid-B User A1 User B1 User B1 User A2 Background: Bridged PKI • Used to enable trust between multiple hierarchical CAs • Generally more infrastructure than just the cross-certificate pairs • Typically involves strong policy & practices • Solves the n2 problem • For SURAgrid we preload cross-certs

13. SURAgrid Authentication Schematic Campus F Grid F’s PKI SURAgrid Bridge CA Campus E Grid E’s PKI Cross-cert pairs D’s PKI Campus D Grid A’s PKI B’s PKI C’s PKI Campus A Grid Campus B Grid Campus C Grid

14. SURAgrid Authentication Status • SURAgrid Bridge CA • Off-line system • Used Linux and OpenSSL to build bridge • Cross-certifications with the bridge complete or in progress for 8 SURAgrid sites • Several more planned in near future • SURAgrid Bridge Web Site • Interesting PKI issues discussed in paper

15. Higher Education Bridge Certification Authority (HEBCA) • A project of EDUCAUSE • Implement a bridge for higher education based on the Federal PKI bridge model • Support both campus PKIs and sector hierarchical PKIs • Cross-certify with the Federal bridge (and others as appropriate) • Should form an excellent permanent trust fabric for a bridge-based Grid

16. Model SURAgrid Authentication Campus F Grid F’s PKI HEBCA Campus E Grid E’s PKI Cross-cert pairs D’s PKI Campus D Grid A’s PKI B’s PKI C’s PKI Campus A Grid Campus B Grid Campus C Grid

17. FBCA HEBCA SAFE Commercial Others Bridge to Bridge Context • A federal view on how the inter-bridge environment is likely to develop • FBCA – Federal Bridge • SAFE – Pharmaceutical • HEBCA – Higher Ed • Commercial - aerospace and defense • Grid extensible across PKI bridges?

18. SURAgrid AuthN/AuthZ Status • Bridge CA and cross-certification process • Forms the basic AuthN infrastructure • Builds a trust fabric that enables each site to trust the certificates issued by the other sites • The grid-mapfile • Controls the basic (binary) AuthZ process • Sites add certificate Subject DNs from remote sites to their grid-mapfile based on email from SURAgrid sites

19. SURAgrid AuthZ Development • Grid-mapfile automation • Sites that use a recent version of Globus will use a LDAP callout that replaces the grid-mapfile • For other sites there will be some software that provides and updates a grid-mapfile for their gatekeeper

20. SURAgrid AuthZ Development • LDAP AuthZ Directory • Web interface for site administrators to add and remove their SURAgrid users • Directory holds and coordinates • Certificate Subject DN • Unix login name (prefixed by school initials) • Allocated Unix UID (high numbers) • Some Unix GIDs? (high numbers) • Perhaps SSH public key, perhaps gsissh only • Other (tbd) • Reliability • Replication to sites that want local copies

21. SURAgrid AuthZ Development • Sites contributing non-dedicated resources to SURAgrid greatly complicate the equation • We will provide a code template for editing grid-mapfiles to manage SURAgrid users • Publish our LDAP schema • Sites may query LDAP to implement their own SURAgrid AuthZ/AuthN interface

22. Likely SURAgrid AuthZ Directions and Research • User directory or directory access • Group management • Person attributes • VO names • Store per-person, per-group allocations • Integrate with accounting • Local and remote stop-lists • Resource directory • Hold resource usage policies • Time of day, classifications, etc • Mapping users to resources within resource policy constraints • We’ll learn a lot more about what is actually required as we work with the early user groups

23. Ashok Adiga, Texas Advanced Computing Ctr.SURAgrid portal

24. Configuring SURAgrid nodes • SURAgrid supports dedicated & non-dedicated nodes • Common software stack being defined for dedicated nodes • Non-dedicated nodes support basic grid services • Job & data management • Authentication • Resource monitoring • Simple process to add resources to the grid • Install Globus (GRAM & gridftp) • Cross sign CA certificates with Bridge CA • Install GPIR perl provider scripts on resource and add resource description to User Portal.

25. Motivation for User Portals • Make joining the SURAgrid easier for users • Single place for users to find user information and get user support • Certain information can be displayed better in a web page than in a command shell • Allow novice users to start using grid resources securely through a Web interface • Increase productivity of SURAgrid researchers – do more science!

26. What is a Grid User Portal? • In general, a portal is a gateway to a set of distributed services accessible from a Web browser • Provides • Aggregation of different services as a set of Web pages • Single URL • Single Sign-On • Personalization • Customization

27. Characteristics of a User Portal • A User Portal can include the following services: • Documentation Services • Notification Services • User Support Services • Allocations • Accounts • Training • Consulting

28. User Portal Characteristics (cont’d)l • Collaborative Services • Calendar • Chat • Resource sharing • Information Services • Resource • Grid-wide • Interactive Services • Manage Jobs & Data • Doesn’t replace the command shell but provides a simpler, alternative interface

29. Service Aggregation User Support Consulting Notification User News Collaborative Calendar Chat Documentation User Guides Information Resource Grid Interactive Job Submission File Transfer HTTP/SSL/SOAP GSI User Portal HTTP/SSL Client Browser

30. Portal build using GridPort 4 • Developed at TACC and San Diego State University • Includes: • Portal framework-independent “portlets” • Expose backend services as customizable web interfaces • JSR168 Portlet Standard • Install into GridSphere by default • Small changes would allow portlets to run in any JSR-168 compliant portal framework • uPortal, WebSphere, Jetspeed, etc. • Portal services • Services that run in the same web container as portlets • Provide portlet cohesion and portal framework independent support for portals • Interface to grid technologies • GRAM, GridFTP, MyProxy, WSRF, science applications • Notable Technologies • Spring framework (portal services); Hibernate O/R mapping (persistence); Tomcat

31. SURAgrid Portal • Single sign-on to access all grid resources • Documentation tab has details on: • Adding resources to the grid • Setting up user ids and uploading proxy certificates

32. Information Services • Resource • State information about individual resources • Queue, Status, Load, OS Version, Uptime, Software, etc.. • Grid • Grid-wide network performance • Aggregated capability • GPIR information Web Service • Collects and provides information above

33. Resource Monitoring http://gridportal.sura.org/gridsphere/gridsphere?cid=resource-monitor

34. Interactive Services • Security • Hidden from the user as much as possible • File Management • Upload • Download • Transfer between resources • Job Submission to a single resource • Job Submission to a grid meta-scheduler (future) • Composite Job Sequencing (future)

35. Proxy Management • Upload proxy certificates to MyProxy server • Portal provides support for selecting a proxy certificate to be used in a user session

36. File Management • List directories, Move files between grid resources, Upload/download files from local machine

37. Job Management • Submit Jobs for execution on remote grid resources • Check status of submitted jobs • Cancel and delete jobs.

38. Future Directions • User Portal currently offers basic user, informational and interactive services. • Build on other services such as user support • Need to expand services as grid grows • Resource broker to automatically select resource for job execution • Workflow support for automation and better utilization of grid resources • Reliable file transfer services • Build customized application portlets

39. Art Vandenberg, Georgia State UniversityApplications on SURAgrid

40. SURAgrid Applications • Need applications to inform and drive development • Want to be of immediate service to real applications • Believe in grids as infrastructure • but not “if you build it they will come”… • Identifying & Fostering Applications

41. Proposed Application Process • Continuing survey of applications • Catalog of Grid Applications; similar agency and partner databases; survey of SURA membership • Identify target applications • Region significance, multi-institutional, intersection other e-Science • Illustrating grid benefits • Test it • Globus, authN-Z/BridgeCA, compilers, portal… and more • Implementation options • 1) Immediate deployment • 2) Demonstration deployment opportunities • 3) Combined with proposal development

42. Catalog of Grid Applications • http://art11.gsu.edu:8080/grid_cat/index5.jsp • Researchers of grid, grid potential applications • Initial intent just to see who's doing what • Potentially larger resource (collaboration, regional perspective, overall trends) • 21 sites, 530+ researchers • Current focus: • Automated maintenance • Improved search, browse

43. Identify an Applications Base • Build from application activities already underway in SURAgrid • Integrate with regional strategy (SURA HPC-Grid Initiatives Planning Group) • Apply additional resources • Seeking additional collaboration, external funding • Achieve critical mass within a critical timeframe • Seek FUNDING

44. SURAgrid Applications • Multiple Genome Alignment (GSU, UAB, UVA) • Task Farming (LSU) • Muon Detector Grid (GSU) • BLAST (UAB) • ENDYNE (TTU) • SCOOP/ADCIRC (UNC, RENCI, MCNC, SCOOP partners, SURAgrid partners) • … Potential applications…

45. Seq 5-6 Seq 1-2 Seq 3-4 Sequences 1-6 Sequences 7-12 Multiple Genome Alignment-GSU, UAB, U. Virginia, U. Southern Ca. • Demoed March 2005 SURA IT Comm (used BridgeCA) • SMP cluster UAB grid SURAgrid • Iteratively advance understanding (algorithm, UAB grid, Bridge CA, multiple clusters…) • USC baseline testing Mar-Jun 2005

46. Task Farming- Louisiana State U. • Demo Nov SC2004; Mar 2005 - SURA IT Comm (BridgeCA) • Pluggable components to use different technologies • Application independent = no need to recompile • Grid enabled, supports task scheduling • HTTP interface: monitor progress, steer individual TFM

47. Muon Detector Grid-Georgia State University • Demoed Internet2 Fall 2004 • Detector grid: collectors, compute & data grid • Grid infrastructure addresses digital divide

48. BLAST- U. Alabama at Birmingham • Nearing SURAgrid deployment • Database search application for protein and nucleotide sequences • Globus: job staging, submission, retrieval • ncbiBLAST for computation • Pubcookie initial login, myproxy grid login • Simplified web interface • Sequence database pre-staged on nodes

49. Left: Simulation of the H+* + C2H2 reaction, CS END grid Right: CS wave packets trajectory on X-Z plane predicting reaction ENDYNE- Texas Tech • Run on SURAgrid, September 2005 • Electron Nuclear Dynamics simulations • Trajectory calculation in quantum phase space • Using grid enables real-time solutions

50. SCOOP/ADCIRC- UNC, RENCI, MCNC, SCOOP Partners, SURAgrid Participants • SURA program to create infrastructure for distributed Integrated Ocean Observing System (IOOS) in the southeast • Shared means for acquisition of observational data • Enables modeling, analysis and delivery of real-time data • SCOOP will serve as a model for national effort • http://www1.sura.org/3000/3300_Coastal.html • SCOOP/ADCIRC: forecast storm surge • 1: resource selection (query MDS) • 2: build package (application & data) • 3: send package to resource (gridftp) • 4: run adcirc in mpi mode (globus rsl & qsub) • 5: retrieve results from resource (gridftp)