Personal tools
You are here: Home → Developer → Interest Groups → Distributed Execution → Archive → Distributed Kepler Use Cases and Requirements
Log in


Forgot your password?
New user?
 

Distributed Kepler Use Cases and Requirements

STATUS:

Red TriangleThis page is out of date and is currently being updated to reflect new goals and requirements. What follows are older notes collcted from other locations.

 

Overview

Goals and requirements as well as possible methods and evaluation criteria for a distributed Kepler system.

Goals and Requirements

GOAL: Users can log into Kepler Grid and the System

  1. Certification?
  2. Role-based access

GOAL: Users can configure Kepler Grid access and execution parameters

  1. The portions of workflows should be inherently parallel.
  2. The workflows should be able to execute on different processors on the same system or on different nodes in a distributed network.
  3. The system needs to minimize the configuration efforts by the user, or even hide the technical details from the user to the maximum extend that is possible.
    ---The user should also have the freedom to see and update the hidden technical details if wanted.
  4. The system needs to have the ability to pass .ksw files using references on the remote end.
  5. The system should allow usage of ad-hoc user communities.
  6. The system should be able to discover a list of available nodes.
  7. The user should be given the option to set up:
    1. Number of nodes to distribute the execution
    2. The users/groups/roles to share this execution
    3. ...

GOAL: Kepler will have the ability to do failure recovery

GOAL: Users can be able to detach from the workflow and then connect again

Assesment of Possible Methods

The 4 methods we've proposed to have are:
  1. Nimrod/APST style grid jobs
  2. Distributed kepler in 3 stages
    1. separate client/server sides of kepler to allow remote execution on multiple server nodes, no user interaction with server side
    2. Add interaction where two directors know about each other and can send messages (GUI output plus user interaction)
    3. Add kepler as a remote deployment system, any kepler node is a client server system that allows others to submit jobs to it with access control

Evaluation Criteria:

Other than looking for the satisfaction of the above requirements, we have evaluated the mentioned 4 approaches using the following criteria:

  • Be independent of a specific Grid/Distributed Technology (this might be too much/too hard)
  • Allow parallel/concurrent processing
  • Effort to implement
  • Allow a range of computing power/capability
  • Easily configurable without an IT expert
  • Link computers with different computational capabilities and owners easily together
Document Actions