1 / 11

Dynamic Creation and Management of Runtime Environments in the Grid

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

bruis
Download Presentation

Dynamic Creation and Management of Runtime Environments in the Grid

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. 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 Dynamic Runtime Environments in the Grid

  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) Dynamic Runtime Environments in the Grid

  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 Dynamic Runtime Environments in the Grid

  5. (1) DN RTEFactory Service (4) GSH PEP gridmapfile (2) (5) setuid (3) RTESservice local RTE implementation PEP (6) Request+GSH GRAM An Interaction Scenario User Dynamic Runtime Environments in the Grid

  6. Slice N Slice N Slice N Slice N OS OS OS OS 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! Dynamic Runtime Environments in the Grid

  7. Management account Account 1 Account 2 GT3 GSLab GSLab GSLab OS OS OS GSLab OS 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. Dynamic Runtime Environments in the Grid

  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). Dynamic Runtime Environments in the Grid

  9. 1. Request (user, RTE attributes) 2. Reply: credentials signed by AP (policy statement) 0. Registration (soft-state) 3. CreateRTE request (includes credentials obtained in step 2) 6. RTE lifetime expires RTEService User RTE 5. Login to user account; Scripts 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 Dynamic Runtime Environments in the Grid

  10. 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 Dynamic Runtime Environments in the Grid

  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 Dynamic Runtime Environments in the Grid

More Related