# Presentation: 667250

## A Standard Grid Services Model

**A Standard Grid Services Model**

- HPSS

- HPSS

- Myrinet

- Myrinet

- 1176p IBM SP
- Blue Horizon

- 1500p Origin

- UniTree

- 1024p IA-32
-   320p IA-64

- HPSS

- Standard grid services (defined protocols, specifications, API’s) implemented on resources.

## Defining Standard Services

**Defining Standard Services**

- IA-64 Linux Cluster Runtime

- File-based Data Service

- Collection-based Data Service

- Volume-Render Service

- Interactive Collection-Analysis Service

**Grid**
**Applications**

- IA-64 Linux Cluster Interactive Development

- Finite set of TeraGrid services- applications see *standard services* rather than *particular implementations*...

- ...but sites also provide additional services that can be discovered and exploited.

## Standards  Cyberinfrastructure

**Standards ******** Cyberinfrastructure**

- Runtime

- File-based Data Service

- Collection-based Data Service

- Visualization Services

- Interactive Collection-Analysis Service

**Grid**
**Applications**

- Interactive Development

- IA-64 Linux Clusters

- Alpha Clusters

- IA-32 Linux Clusters

- Visualization Services

_*Data/Information*_

_*Compute*_

_*Analysis*_

- Relational dBase Data Service

- TeraGrid Certificate Authority

- Certificate Authority

- Certificate Authority

- Certificate Authority

- Certificate Authority

- Grid Info Svces

- TeraGrid:  focus on a finite set of service specifications applicable to TeraGrid resources.
- If done well, other IA-64 cluster sites would adopt TeraGrid service specifications, increasing users’ leverage in writing to the specification, and others would adopt the framework for developing similar services (for Alpha, IA-32, etc.)
- Note the specification should attempt to offer improvement over general Globus runtime environment without bogging down attempting to do everything (for which a user is better off running interactively!)

## Strategy: Define Standard Services

**Finite Number of TeraGrid Services**
- Defined as specifications, protocols, API’s
- Separate from implementation
**Extending TeraGrid**
- Adoption of TeraGrid specifications, protocols, API’s
- What protocols does it speak, what data formats are expected, what features can I expect (how does it behave)
- Service Level Agreements (SLA)
- Extension and expansion via:
- Additional services not defined in TeraGrid
- e.g. Alpha Cluster Runtime service
- Additional instantiations of TeraGrid services
- e.g. IA-64 runtime service implemented on cluster at a new site
**Example: File-based Data Service**
- API/Protocol:  Supports *FTP* and *GridFTP, GSI *authentication
- SLA: All TeraGrid users have access to *N* TB storage, available 24/7 with *M*% availability, >= *R* Gb/s read, >= *W* Gb/s write, etc..

## Example: Runtime Environment (hosting)

- Globus
- Credential

- Site 2

- Certificate

- Authenticated
- interprocess
- communication

**CREDENTIAL**

- Mutual
- user-resource
- authentication

- Mappingtolocal ids

- Assignment of
- credentials to
- “user proxies”

- Single sign-on via “grid-id”

## Globus Runtime Environment

**Minimal set of environment variables and values available for use via RSL**
**...****and Resource Description Language (RSL)**
- Given knowledge about the host, can define an environment
- Can also submit a shell script...

**Potential variables set for the job's environment:**
- HOME *, LOGNAME *, KRB5CCNAME *, NLSPATH *, TZ *, LANG *, X509_CERT_DIR, X509_USER_PROXY, GLOBUS_GRAM_JOB_CONTACT, GLOBUS_GRAM_MYJOB_CONTACT, GLOBUS_DEPLOY_PATH, GLOBUS_INSTALL_PATH    (* fork jobmanagers only)
**Default RSL substitution variables:**
- HOME, LOGNAME, GLOBUS_ID, GLOBUS_GRAM_JOB_CONTACT, GLOBUS_ORG_DN, GLOBUS_GRAM_RDN, GLOBUS_HOST_DN, GLOBUS_HOST_MANUFACTURER, GLOBUS_HOST_CPUTYPE, GLOBUS_HOST_OSNAME, GLOBUS_HOST_OSVERSION, GLOBUS_GATEKEEPER_HOST, GLOBUS_GATEKEEPER_PORT, GLOBUS_GATEKEEPER_SUBJECT, GLOBUS_DEPLOY_PREFIX, GLOBUS_TOOLS_PREFIX, GLOBUS_SERVICES_PREFIX, GLOBUS_INSTALL_PREFIX, GLOBUS_DEPLOY_PATH, GLOBUS_TOOLS_PATH, GLOBUS_SERVICES_PATH, GLOBUS_INSTALL_PATH, GLOBUS_CONDOR_ARCH,  GLOBUS_CONDOR_OS  (* for condor jobmanagers only)

## Resource Description Language (RSL)

**Can be used to customize, but some knowledge about environment needed**

- (**directory** = value)	Default: Current working directory (as set by the gatekeeper).
- (**executable** = value)	Default: None [*required*]
- (**arguments** = value [value] [value] ...)	Default: NULL
- (**stdin** = value)	Default: /dev/null
- (**stdout** = value)	Default: /dev/null
- (**stderr** = value)	Default: /dev/null
- (**count** = value) 	Default: 1  [number of times to invoke the executable]
- (**environment** = (var value) [(var value)] ...)	Default: NULL
- 	The environment variables that will be defined for the executable in addition to default set that is
- 	given to the job by the jobmanager, see    _[www.globus.org/gram/job_excution_environment.html](http://www.globus.org/gram/job_excution_environment.html)_
- (**maxTime** = *value*)	Default: None.  Accepts local scheduler default if any.
- (**maxWallTime** = *value*) 	Default: None.  Accepts local scheduler default if any.
- (**maxCpuTime** = *value*) 	Default: None.  Accepts local scheduler default if any.
- (**jobType** = single|multiple|mpi|condor) 	Default: multiple (start *count* processes or threads)
- (**gramMyJob** = independent|collective) 	Default: collective
- (**queue** = *value*) 	Default: None (value  =  queue class
- (**project** = *value*) 	Default: None (project account)
- (**hostCount** = *value*) 	Default: None
- (**dryRun** = yes|no) 	Default: no
- (**minMemory** = *value*) 	Default: None
- (**maxMemory** = *value*) 	Default: None
- (**save_state** = *yes|no*) * 	Default: No
- (**two_phase** = *<int>*) * 	Default: None
- (**restart** = *<old JM contact>*) * 	Default: None
- (**stdout_position** = *<int>*) * 	Default: None
- (**stderr_position** = *<int>*) 	Default: None
- (**remote_io_url** = *<url base>*) * 	Default: None

## Proposal: Initial TeraGrid Services

**Initial Set of ****Tera****Grid Services**
- Cluster_Runtime_Batch
- As seen by executable via Globus
- Cluster_Interactive
- For interactive use, including development/debug/porting
- File_Based_Data_Service
- Generic service implemented via UniTree, HPSS, etc.
- Streamed_IO_Service
- Essential for visualization...
**Advanced ****Tera****Grid Services**
- Cluster_Runtime_Interactive
- Database_Data_Service
- Visualization_Service(s)
- May be multiple types, e.g. Volume_Render, etc.
- Scheduler_Service

## Proposal: Cluster_Runtime_Batch

**Runtime v1.0**
- Objective:  Support execution of compiled binaries
- Assumptions (policy)
- 1 user per node, dedicated to the user (only) during runtime, accessible for login (minimal environment)
- Static linked binary
- TeraGrid cluster compute node to TeraGrid cluster compute node
- Data staged manually
- Software environment
- Default OS = Redhat 7.2
- Oldest Kernel = 2.4.7
- MPICH version
- I/O
- Local space: $TG_Local
- Home space: $TG_Home
- Global (Shared) space: $TG_Global
- Inter-node communication (protocol(s), naming)

## Breakout Groups

| Breakouts: Development/refinement of application goals and requirements

Agenda: 
What are the attributes (capabilities or building blocks to build capabilities) necessary for this type of computing? (separate question from the settings, quantities, etc. of those attributes) Example- capability to pre-stage data – involves attributes such as scratch storage, storage reservations, etc.  Separate questions are how much scratch storage or how long it is available, etc.
What is the set of 6-8 “services” that would make up the initial TeraGrid environment?
Focus today on Cluster_Runtime_Batch as a worked example (set of attributes, suggested values to support this type of application).
 |  |  |
| --- | --- | --- |
|  |  |  |
| Distributed data-intensive
(ATLAS, CMS, LIGO, SDSS/NVO)

Moderators: Phil Andrews (producer), Dick Crutcher (consumer) | Metacomputing
(Cactus, Climate, Sensor nets)

Moderators: John Towns (producer), Ed Seidel (consumer) | On-demand
(NEES, BIRN, Radio Astronomy)

Moderators: Rob Pennington (producer), Mark Ellisman (consumer) |

- Cafeteria dining room B is reserved for our group...

*Room C101*
*(downstairs, opposite corner of bldg)*

*Room A261*
*(end of hall straight out this room door)*

*A216*
*(here)*

## Data_Intensive_Runtime_Batch (notes)

**Runtime v1.0**
- Objective:  Support execution of compiled binaries
- Assumptions (policy)
- 1 user per node, dedicated to the user (only) during runtime, accessible for login (minimal environment)
- Static linked binary
- TeraGrid cluster compute node to TeraGrid cluster compute node
- Data staged manually
- Software environment
- Default OS = Redhat 7.2
- Oldest Kernel = 2.4.7
- MPICH version
- I/O
- Local space: $TG_Local
- Home space: $TG_Home
- Global (Shared) space: $TG_Global
- Reservation Protocol
- Parameters:  size available to reserve, length of time before run, length of time after run (requires a reservation protocol, likely need to ‘charge’ for space to influence good behavior- need to make sure the algorithm is understood and factored into allocation requests to begin with)
- Inter-node communication (protocol(s), naming)