Dynamic Creation and Management of Runtime Environments in the Grid

1
Dynamic Creation and Management of Runtime
Environments in the Grid

• Kate Keahey
• Matei Ripeanu
• Karl Doering

2
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

3
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)

4
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

5
An Interaction Scenario
User
6
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!

7
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.

8
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).

9
GSLab - Overall architecture
Admin Point (AP)
User

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

Local nodes
RTEFactory Service
4. Extend RTE lifetime change RTE parameters
destroy RTE
gsisshd
10
Current Work and Status

• Prototype implementation available
• Dynamic accounts
• www.mcs.anl.gov/keahey/DS/DynamicSessions.htm
• GSLab (matei_at_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

11
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