1 / 58

Mary Fran Yafchak, SURA Jim Jokl, University of Virginia

Development & Implementation of an Inter-institutional Multi-purpose Grid SURAgrid at Internet2 Members’ Meeting, September 2005. Mary Fran Yafchak, SURA Jim Jokl, University of Virginia Ashok Adiga, Texas Advanced Computing Center Art Vandenberg, Georgia State University.

aletta
Download Presentation

Mary Fran Yafchak, SURA Jim Jokl, University of Virginia

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. Development & Implementation of an Inter-institutional Multi-purpose GridSURAgrid at Internet2 Members’ Meeting, September 2005 Mary Fran Yafchak, SURA Jim Jokl, University of Virginia Ashok Adiga, Texas Advanced Computing Center Art Vandenberg, Georgia State University

  2. Presentation agenda • About SURAgrid - Mary Fran Yafchak • SURAgrid authN/authZ - Jim Jokl • SURAgrid portal - Ashok Adiga • SURAgrid applications - Art Vandenberg 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, from Delaware to Texas • SURA membership: 62 research universities, mostly within the region • SURA mission: Foster excellence in scientific research, strengthen capabilities, provide training opportunities • Evolved from the NMI Testbed Grid project, an outgrowth of SURA’s management 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 scalable infrastructure that leverages local institutional identity and authorization while managing access to shared resources • To promote the use of this infrastructure for the broad research and education community • To provide a forum for participants to gain additional 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 Tulane University* Vanderbilt University* University of Virginia* SURAgrid Participants *SURA member

  6. Current Status • Grid-Building • Themes: heterogeneity, flexibility, interoperability, scalability • More – Ashok Adiga, Texas Advanced Computing Center • Inter-institutional AuthN/AuthZ • Themes: maintain local autonomy; leverage enterprise infrastructure • More – Jim Jokl, University of Virginia • Application Development • Themes: immediate benefit to applications; apps drive development • More – Art Vandenberg, Georgia State University • Project Planning • Provided and facilitated by SURA • All meeting notes available on SURAgrid Web site • First in-person meeting held Sept. 7 & 8, 2005

  7. In the coming months… • Will continue evolving key areas • Grow and solidify grid infrastructure • Continue expanding and exploring authN/authZ • Build application set; help to grid-enable new applications • More formal work on organizational definition • Charter, policy, governance • Pursuit of funding opportunities and additional collaboration • Four collaborative proposals submitted this summer; more anticipated in the next six months • 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)

More Related