Open Science Grid Ecosystem

Transcription

1

2 Open Science Grid Ecosystem Consortium Infrastructures Project Satellites Services: Consulting Production Software Mission: The Open Science Grid aims to promote discovery and collaboration in data-intensive research by providing a computing facility and services that integrate distributed, reliable and shared resources to support computation at all scales. 2

3 Introduction to OSG Resources accessible through the OSG are contributed by the community. Their autonomy is retained. Resources can be distributed locally as a campus infrastructure. >30 research communities >100 sites >70,000 cores accessible Users communities / Virtual Organizations (VOs) and Campus Infrastructures bring: 1) Users and/or 2) Resources Introduction to OSG: General OSG User Documentation: 3

4 Basic Architecture Virtual Organizations Common Services & Software Resources: Sites, Campuses, Clouds 4

5 Using the OSG The prevalent OSG job submission mechanism is via Glide-ins which submit Pilot jobs to Gram gatekeepers, where the Pilots then create a Condor overlay environment across the sites and manage the user job queues and execution. Sites also accept many job submission mechanisms: glitewms*, Globus, PANDA. Security is X509 PKI certificate based, using the glite VO Management System (VOMS) and extended attributes (including groups and roles). * European Grid Infrastructure (EGI) Lightweight Middleware for Grid Computing 5

6 Site System & Software Environment No specific hardware requirements but there are recommendations as to the size of memory, local disk, server nodes depending on the expected usage. The OSG software supports several Linux flavors of OS: - SL5, some packages in CentOS and Debian, SL6 on the horizon OSG Software Stack - Alain Roy (U. Wisconsin Madison) is Software Team Lead - The current software release is RPM based (OSG 3.0). - Previous software releases used Pacman (a tarball based software installer) for distribution and installation. Worker Nodes - No specific requirement - Expect site to install the OSG Worker Node Client which is in practice needed for most VO applications The OSG Software is NOT the User Application VOs typically manage their own User Applications 6

7 The Job Environment The configuration of individual sites is very diverse When using glideins, jobs can require certain basic resource characteristics (memory, disk, architecture, etc.) In general when running, jobs can discover their environment via - Std Linux cmd (rpm, ldd, etc.) - OSG-init ed env vars ($OSG_APP, etc.): see next slide - Query OSG Info System (DBII, etc.): cumbersome Jobs cannot assume the presence of a dependency. If that cannot be shipped with the job or installed by the VO (e.g. gcc), the app can run only at a few friendly sites. 7

8 Storage for User Applications and Data VOs are typically responsible for installing Apps and Data, NOT the sites Typically sites provide these kinds of storage - persistent shared space for VO applications - $OSG_APP - shared space for VO data - $OSG_DATA - Convenient / local Storage Element - $OSG_DEFAULT_SE - >10 GB per WN local scratch space - $OSG_WN_TMP Applications and Data are pushed to storage via standard interfaces (SRM, GridFTP) or pulled by jobs. More and more sites are supporting CVMFS for application distribution LocalStorageConfiguration 8

9 User Application Deployment If the app is small (50 MB) it can be shipped with every job. $OSG_APP is >10GB and typically mounted read-only on the worker nodes in the cluster Clusters typically allow installation jobs on the gatekeeper node (sometimes on all nodes) Users with appropriate software installation privileges submit the installation jobs Depending on the complexity of the installation activity jobs are submitted manually or via semi-automated means (OSGMM deprecated in 2012). Post installation tests are recommended. Applications can rely ONLY on standard OS dependencies and the OSG WN libraries Need to install (if possible) all other dependencies Several communities (esp. from EGI) start to rely on CVMFS for application distribution. The app can be cached at the WN, which saves on bandwidth. 9

10 Integration with Workload Management Recall that Pilot jobs run on WN to procure resources on behalf of the VO. Pilot jobs characterize the resource with attributes (memory, OS, etc.). User jobs match their requirements to those attributes. Pilot jobs explore $OSG_APP and use VOspecific attributes to describe its content. Jobs can go to machines that have access to specific software distributions. The same integration is possible when using CVMFS 10