# Presentation: 051094

## Dynamic Creation and Management of Runtime Environments in the Grid

- Kate Keahey
- Matei Ripeanu
- Karl Doering

## Overview

- An execution in a Grid environment requires support for dynamic actions
- Current state
- Statically configured user accounts
- Administrative burden
- Statically created, do not reflect dynamically changing VO policies
- We propose
- Runtime environments
- Dynamically created and managed
- Leverage OGSI abstractions to implement them
- Show how this concept can be applied
- Planet Lab

## Driving the Design

- Requirements
- Protection
- User protection
- Resource protection
- Controlled resource usage
- Fine-grain enforcement
- Authorization
- Audit
- Objectives
- Automating administration
- Enables dynamic management
- Formalizing creation and management
- Enables a variety of underlying implementations based on need and availability (sandboxes, VMs)

## Key abstractions

- RTEFactory: creates RTE services
- Creates both a service and underlying implementation
- Invokes initialization/configuration procedures
- Writes access policy
- Currently simply gives the request initiator the right to use the account
- Implemented in the GT3 gridmapfile
- RTEService
- Interface to the dynamically created runtime environment
- Identified by a GSH
- SDEs:
- RTE_Implementation
- Local name
- Termination Time (with default settings)
- RTE properties (currently: quota)
- Termination implies account destruction and policy update
- Using soft-state termination and defining termination semantics ensures that the account will be properly terminated

## An Interaction Scenario

-                          User

## PlanetLab 

- A testbed for a class of networked services
- DHTs, CDNs, Fast data transfers, RONs, etc.
- Deployed over 180 nodes, 70 sites, 5 continents
- Allocation unit: a slice = a set of virtual machines,  one at each node.
- Sounds like a good starting point for a Grid Services testbed!

## So, what is missing?

- Need to authenticate users and allocate resources independent of PlanetLab mechanisms.
- No sharing between VMs on same node.
- Solution: Work within one slice: a GSLab user gets an account on each VM in GSLab slice.
-  Also: show how GT3 can be used to manage PlanetLab resources.

## GSLab - Functionality

- Manage user accounts across a set of VMs
- Additional functionality provided to users:
- Submit jobs to and login on these accounts
- Create fresh, start, stop, restart GS containers across a set of accounts (scripts).
- Deploy services in containers (more scripts).

## GSLab - Overall architecture

- User

- RTEFactory Service

*4. Extend RTE lifetime; change RTE parameters; destroy RTE*

- User authentication and authorization
- Resource allocation
- Monitoring and management of  the testbed

**Admin Point (AP)**

**Local nodes**

- gsisshd

**Notes:**
AP - Implements a resource allocation policy

## Current Work and Status

- Prototype implementation available
- Dynamic accounts
- www.mcs.anl.gov/~keahey/DS/DynamicSessions.htm
- GSLab (matei@cs.uchicago.edu)
- Current work
- Research
- Exploring sandboxing and VMs
- Relationship to WS-Agreement
- Deployment
- Offer GSLab as a service to the community: obtain account on GSLab for a short time

## Conclusions

- Were GS abstractions useful: yes
- Lessons Learned
- Expose GS containers as grid services.
- Ability to deploy any service dynamically
- Authorization service
- Canonical form for GSH
- GT3: more documentation, maturity