the unicore project n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
The Unicore Project PowerPoint Presentation
Download Presentation
The Unicore Project

Loading in 2 Seconds...

play fullscreen
1 / 68

The Unicore Project - PowerPoint PPT Presentation


  • 161 Views
  • Uploaded on

The Unicore Project. Adam Belloum Computer Architecture & Parallel Systems group University of Amsterdam adam@science.uva.nl. UNICORE Objectives. UNICORE was to hide the seams resulting from different hardware architectures.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'The Unicore Project' - rue


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
the unicore project

The Unicore Project

Adam Belloum

Computer Architecture & Parallel Systems group

University of Amsterdam

adam@science.uva.nl

unicore objectives
UNICORE Objectives
  • UNICORE was to hide the seams resulting from different hardware architectures.
  • Security is built into the design of UNICORE from the start relying on the emerging X.509 standard.
  • UNICORE is usable by scientists and engineers without having to study vendor or site specifications.
  • A GUI assists the user in creating and managing complex jobs and integrating applications.
unicore functions
Unicore Functions
  • Job creation and submission:
  • Job management:
  • Data management:
  • Application support:
  • Flow control:
  • Meta-computing:
  • Single sign-on:
  • Support for legacy jobs:
  • Resource management:
the unicore functionality and architecture
The UNICORE Functionality and Architecture

The UNICORE system provides functionality to both the end-user and the computer centers

  • The end-user
    • Seamless, uniform access to computing and data resources
    • Move computing jobs between different platforms
  • The computer centers (or Grid sites)
    • Gain a solid authentication mechanism fully integrated into their administration procedures
  • The plugin mechanism allows integrating easy-to-use interfaces, increasing end-user productivity.
end user functionality
End-User Functionality
  • The end-users of UNICORE interact with all sites and systems in a UNICORE Grid via a graphical Client.
  • Regardless of the target site for a job, the connection process is always the same:
    • User unlocks the UNICORE certificate (keystore password).
    • Client loads plugins configured in the plugin directory.
    • Client automatically connects to the Grid sites from a user or system–defined list.
different tasks can be performed
Different tasks can be performed
  • Construct/modify a (batch) job and submit it
  • Inspect the queued, running/completed jobs and retrieve results.
  • Perform data transfer or file management functions.
  • Access functions of the loaded plugins.
  • Manage the local keystore, i.e.
    • add/modify user certificates,
    • select an identity from several certificates,
    • Select trusted certification authorities for Gateways/plugins.
job construction and submission
Job Construction and Submission
  • Jobs are constructed as a directed acyclic graph (DAG)
  • Job is constructed using abstract terms,
  • The end user :
    • specify on which system a job should run
    • specify the resourcesrequired to run the task
    • Save the job on the machine running the client, and later make modifications or submit the job again.
job monitoring
Job Monitoring
  • UNICORE NJS server tracks the status of jobs/tasks/job groups and can kill or put them on hold.
  • A task or sub-job is terminated (by job monitor commands, or because a failure),
    • the user can retrieve the results (standard output, standard error, result files) and transmit them to the local workstation.
  • After all results have been retrieved, the job information can be purged from the UNICORE system.

NJS : Network Job Supervisor

job states
Job States
  • SUCCESSFUL: job or task has been run successfully.
    • For a job, this means that all components have run successfully
  • FAILED: execution of the job group or task has failed.
    • For a job at least one of the components has failed.
    • For a task, this means that the task has failed.
    • The end–user can inspect the status of the components to find out which have failed.
job states1
Job States
  • PENDING: job/task is queued.
    • This happens if a predecessor task has not yet been executed, or if the whole job has not yet been started at all.
  • QUEUED: job/task is queued in the target batch system.
    • This happens if the resources on the target system are used by other jobs which may or may not be UNICORE jobs.
  • EXECUTING: job or task is currently executing,
    • For a job group, this is indicated if at least one component is being executed.
file and data management
File and Data Management
  • The UNICORE system includes functions to Transmit files between
    • the local user workstation and file systems
    • or archives that can be accessed from the UNICORE site.
  • Perform Unix–style file management functions
    • copy, move, delete, chmod, etc. on files residing on file systems or archives that can be accessed from the UNICORE site, and generate directory listings.
functionality relevant for the computer centers comprises
functionality relevant for the computer centers comprises
  • Provision of a strong user authentication mechanism (X.509 certificates)
  • Extensibility by site specific user authentication methods (like SecurID cards, skey one-time passwords, etc.)
  • Compatibility to the center’s authorization mechanisms and policy (mapping of UNICORE userids to local Unix userids, accounting, disk quotas etc.).
functionality relevant for the computer centers comprises1
Functionality relevant for the computer centers comprises
  • Site and system specific incarnation of UNICORE jobs driven by a declarative Incarnation Database that can be adapted to the center’s needs
  • Declarative description of available resources,
    • capacity resources(processor count, computation time, memory size)
    • capability resources (like available software packages and special hardware capabilities).
    • Special support for applications that simplifies the entry and definition of jobs, or provides steering or control functionality
unicore architecture2
Unicore Architecture
  • User is running the UNICORE Client
    • on a local workstation or PC.
  • Participating computer center defines UNICORE Grid site(s)
    • (Usite) that Clients can connect to.
  • A Usite offers access to computing or data resources.
    • organized as virtual sites (or Vsites) representing the execution or storage systems.
  • In the Client, the user addresses the Vsites to submit UNICORE jobs or sub-jobs to.
unicore architecture3
Unicore Architecture
  • A list of available UNICORE Gateways
    • is maintained as an XML document under www.unicore.de, but the user can configure own list of sites.
  • A user certificate is needed to establish to a Gateway and to sign the submitted jobs from
    • Job Preparation Agent (JPA) part of the Client.
  • The user can look for the status of the jobs and for results with
    • Job Monitor Controller (JMC) part of the Client.
network job supervisor njs

optional firewall

Network Job Supervisor (NJS)

AJO/UPL

Unsafe Internet (SSL)

  • Manages all submitted jobs,
  • It performs the user authorization
    • by looking for a mapping of the user certificate to a valid login in the UNICORE User Data Base (UUDB)
  • It is the NJS’ task to consider the dependencies between
    • job components and to schedule the components accordingly
  • The NJS server stores all job
    • status and result information,
    • replies to status/result requests from the client

User authentication

UNICORE Gateway

Safe Intranet

(TCP)

User mapping,job incarnation,

job scheduling

Network Job Supervisor

(NJS)

IDB

IDB

UUDB

Incarnated job

Status request

Target System Interface(TSI)

SV1

Commands

files

Batch Subsystem

the network job supervisor
The Network Job Supervisor
  • The NJS performs the following functions:
    • Receive UPL requests from the upstream Gateway.
    • Interpret requests for resource information (GetResources task),
    • send back the available resources in an array of resource objects.
    • Interpret the consign of a UNICORE job.

UPL: UNICORE protocol layer

the network job supervisor1
The Network Job Supervisor
  • If a group is encountered
    • Contact Usite/Vsite with a NJS client certificate, and submit the job group.
    • Poll for status updates until execution of the job group has been completed.
  • Run tasks on the local systems
    • using the Incarnation DB to create a scripts that executes a correct interpretation of the job.
  • Whenever tasks/job groups have completed execution, save the status information & result files for later retrieval.
  • Interpret requests to list known jobs or to send job status and job results according to the local knowledge about job/task status.
the network job supervisor2
The Network Job Supervisor
  • The NJS is customized by a configuration file that is first read at start-up and then repeatedly to pick up any changes. The settings include:
    • Address & port for the incoming connections from the Gateway
    • Path to the NJS certificates
    • Path to Incarnation DB
    • Path to UNICORE User DB
  • The addresses and ports of TSI instances are specified in the Incarnation Data Base.
the network job supervisor3
The Network Job Supervisor
  • The NJS keeps a non-volatile up to date copy of its state and so can be stopped and restarted without loss of executing jobs.
  • The state is sufficiently up-to-date to allow the NJS to recover from most crashes as well.
  • NJS provides an administrator interface.
    • Administrator can list all executing jobs at various levels of details with different selection criteria
    • Administrator can terminate, hold and resume abstract actions on the NJS.
the incarnation database idb
The Incarnation Database (IDB)
  • Addresses and ports of TSI instances
  • Incarnations of abstract commands
  • Declarations of available capacity/capability resources
    • For the prescribed capacity resources, three entries must be included: mini,max, and default supported values
    • The essential capacity resources are:
      • Processor and node counts
      • Computation time
      • Core memory size
      • Disk space
the incarnation database idb1
The Incarnation Database (IDB)
  • The incarnation of commands the IDB contains a set of rules that map
    • the abstract commands/options of the abstract tasks
    • to concrete command sequences/options.
  • For each abstract task,
    • the NJS incarnation engine applies the matching rules, until all abstract terms have been translated.
the incarnation database idb2
The Incarnation Database (IDB)
  • The context and application resources are specified as software resources in the IDB
  • The capability resources indicating the availability of special hardware/software support can be defined:
    • Storage servers: long-term storage or archive partitions,
    • Context resources: Parallel execution systems (MPI), debugging support, performance analysis support,
    • Application resources: Availability of application libraries or of standard applications.
the user data base uudb
The User Data Base (UUDB)
  • The User Database (UUDB) is indexed by the user certificates and an optional accounting string
  • A UUDB may be shared between several Vsites at a UNICORE site.
    • depends on whether the computer center grants all users in the UUDB the access to all the target systems of the Vsites.
  • The UUDB returns
    • information whether the user is authorized to compute on the Vsite and the Unix userid.
    • tasks to be executed at the Vsite are executed with userid, called the Xlogin.
the user data base uudb1
The User Data Base (UUDB)
  • The usual model will be to map different U-users to different Xlogins.
  • several U-users can be mapped to the same Xlogin,
  • To administrate the User DB, a set of administration commands
    • adding, listing, changing and removing U-users are available.

typical UNICORE user

User has to specify Xlogin in job

ASP without specificlogin per user

target system interface tsi

optional firewall

Target System Interface (TSI)

UNICORE

Site List

AJO/UPL

Unsafe Internet (SSL)

  • To run jobs on a Vsite at a different Usite,
    • NJS takes the role of a Client and submits the sub-job to the remote Gateway
    • Because of the SSL connection this means that a certificate for the NJS itself is also required.
  • UNICORE Target System Interface (TSI)
    • accepts incarnated job components from NJS
    • passes them to the local batch systems
    • Handles file import and export tasks
    • implements low–level status reporting and control of batch jobs.

User authentication

UNICORE Gateway

Safe Intranet

(TCP)

User mapping,job incarnation,

job scheduling

Network Job Supervisor

(NJS)

IDB

IDB

UUDB

Incarnated job

Status request

Target System Interface(TSI)

SV1

Commands

files

Batch Subsystem

the target system interface

optional firewall

The Target System Interface

UNICORE

Site List

AJO/UPL

Unsafe Internet (SSL)

  • The NJS server uses the UNICORE Target System Interface (TSI)
    • to access the actual execution platforms using the UNICORE Target System Interface (TSI).
    • The TSI provides functionality to interface to a batch subsystem or an interactive shell, or to operate on the file system of the target system.

User authentication

UNICORE Gateway

Safe Intranet

(TCP)

User mapping,job incarnation,

job scheduling

Network Job Supervisor

(NJS)

IDB

IDB

UUDB

Incarnated job

Status request

Target System Interface(TSI)

SV1

Commands

files

Batch Subsystem

the target system interface1

optional firewall

The Target System Interface

AJO/UPL

UNICORE Site

  • All TSI processes are running as server daemons that communicate with the NJS via plain sockets.
  • Different sockets are used for the transfer of commands and data.
  • A TSI worker issues batch sub-system (or shell) commands on behalf of a given user (Xlogin) indicated in the NJS request.
  • To do this, the TSI worker must have permission to change its effective user and group ids.

UNICORE Gateway

Safe Intranet

(TCP)

NJS

IDB

UUDB

...

TSI

TSI

Blade

Any cluster

management system

the target system interface2
The Target System Interface
  • Create an execution dir for a job group.
  • Submit a sequence of concrete commands transmitted as a batch script into a queue.
  • Execute a transmitted shell script immediately
    • used to transmit data from/to the execution space of a job.
  • Create files in the execution space;
    • data is sent inline.

Lookup login for user certificate

NJS

UUDB

Execute job on target system

IDB

TSI

Lookup incarnation rules

  • Send back the contents of files in the execution space
    • including spooled files, outcomes, and streamed files.
  • Send status & result data for a batch job & purge the execution space.
the target system interface3
The Target System Interface

Lookup login for user certificate

NJS

UUDB

  • Monitor the status of UNICORE jobs.
  • Purge the execution space.
  • Generate a list of currently known jobs
    • executing or queued in the batch sub-system.
  • Abort jobs from the batch sub-system
    • hold/resume jobs if supported by the batch sub-system.
  • List the contents of directories on the target platform

Execute job on target system

IDB

TSI

Lookup incarnation rules

the target system interface4
The Target System Interface
  • For each command
    • TSI sends a response back to the NJS.
    • Result data is sent inline as a stream of bytes.
  • Starting up, TSI and the NJS do a simple authentication step to
    • ensure that no fraudulent programs are trying to connect.
  • TSI is not portable between systems of different vendors.
    • modifications are restricted to only 3 Perl modules
    • Configuration of an existing TSI is done by editing a single file.

Lookup login for user certificate

NJS

UUDB

Execute job on target system

IDB

TSI

Lookup incarnation rules

the unicore gateway

optional firewall

The Unicore Gateway
  • Acts as the point of entry for UPL connections.
  • It performs the following functions
    • As a SSL server, it accepts incoming SSL connections to a (configurable) port.
    • It authenticates the user certificate presented by the connecting client against a configurable list of trusted CAs.
    • It transmits other requests to the Vsite, drawing on a configurable list of known Vsites and the addresses and port numbers of the corresponding NJS or storage servers.

Arcon

Client Toolkit

User Certificate

UNICOREPro Client

User Certificate

Preparation and

Control of jobs

Runtime Interface

Job preparation/control

Plugins

UNICORE

Site List

AJO/UPL

Unsafe Internet (SSL)

AJO/UPL

UNICORE

Site List

User authentication

UNICORE Gateway

the unicore gateway1

optional firewall

optional firewall

The Unicore Gateway
  • Outside the firewall
    • Configure communication to the downstream NJS servers
    • Allow SSL traffic from the gateway tunneling the firewall to the addresses and ports of the NJS servers.
  • Inside the firewall
    • Allowing SSL traffic to the known port of the Gateway to cross the firewall.
    • Communication to the downstream NJS servers can be performed using SSL or using plain sockets, depending on internal security procedures.

AJO/UPL

Unsafe Internet (SSL)

AJO/UPL

UNICORE Site

User authentication

UNICORE Gateway

Safe Intranet

(TCP)

User mapping,job incarnation,

job scheduling

Network Job Supervisor

(NJS)

NJS

the unicore gateway2
The Unicore Gateway
  • If SSL is used for downstream communication
    • the Gateway will use a client certificate to authenticate with the NJS servers.
  • The Gateway has a “plugin” interface
    • that can be configured to handle non-UPL connections and pass them on to other servers.
    • Connections using a “plugin” have the same authentication, UNICORE protocol, connections.
the unicore security model1

Send User Certificate

Send Gateway Certificate

Establish SSL Connection

The UNICORE Security Model
  • Based on the use of X.509 certificates for the authentication of both users and software.
  • certificates are issued by a trusted Certificate Authority (CA)
  • Authorization of users is performed with mechanisms local to the UNICORE sites.
  • All communication across the outside (insecure) Internet is based on SSL.

Client

Gateway

Trust Gateway

Certificate

Issuer?

Trust User

Certificate Issuer?

the unicore security model2

AJO

AJO

User

Cert

User

Cert

The UNICORE Security Model

Send signed job object over SSL

Gateway

Client

  • Support delegation for hierarchical job
    • the sub–jobs need to be transmitted to their respective target UNICORE sites by the primary NJS
    • The primary NJS acts as the consigner for the sub–jobs it transfers to the secondary NJSs
    • The NJS performs authorization on the base of both the consigner and the endorser; the consigner information is passed by the Gateway, and the endorser certificate is contained as part of the sub-job.

AJO Certificate==

SSL Certificate?

Forward signed

job object

NJS

Lookup login for user certificate

UUDB

Execute job on

target system

IDB

TSI

Lookup incarnation rules

the unicore security model3
The UNICORE Security Model
  • Authorizing users
    • Certificates
    • Mapping abstract identity to concrete local userid
  • Authentication and Securing Plugins
    • Client plugins have to be signed by the CA

typical UNICORE user

User has to specify Xlogin in job

ASP without specificlogin per user

the unicore job model1
The UNICORE Job Model
  • For each job a Vsite is assigned
    • for execution where all tasks immediately belonging to the job will be run.
  • sub-jobs of a job group are executed
    • in no particular order,
    • parallel execution is supported if the resources are available on the target execution systems.
the abstract job object ajo
The Abstract Job Object (AJO)
  • It contains the following components:
    • Basic UNICORE protocol layer (UPL) for
      • Client  Gateway
      • Gateway  Server communication (on top of SSL)
    • Resource object hierarchy for
      • the specification of resource requests (need certain resources)
      • the available resources (can provide certain resources)
    • Object hierarchy of abstract actions containing the definition of all supported tasks
      • user and system tasks
      • abstract UNICORE (sub-)jobs.
the unicore job model2
The UNICORE Job Model
  • A UNICORE job on user level is modeled as a directed acyclic graph (DAG) of abstract actions
    • Abstract tasks,
    • plus a resource request.
  • The DAG is signed with the user’s private key preventing tampering with the job definition while it is being transmitted.
abstract tasks
ExecuteScriptTask

UserTask

ImportTask/ExportTask:

TransferTask:

File operation tasks like CopyFile, RenameFile, DeleteFile, CreateDirectory, ChangePermissions

ListVites

GetResourceDescription

GetJobs:

GetActionStatus

RetrieveOutcome

ControlAction

If, RepeatGroup, ForGroup

abstract tasks
the unicore protocol upl
The UNICORE Protocol (UPL)
  • The UNICORE Protocol Layer (UPL) defines how data is sent between UNICORE Clients and Servers so that:
    • Clients ask Servers to execute AJOs
    • Clients get information about the services offered
  • UPL is a protocol level that is layered on top of existing transport protocols such as SSL.
the unicore protocol1
Requests and Replies have two parts;

a serialized Java object

an optional stream of bytes.

UPL is a protocol level that is layered on top of existing transport protocols such as SSL.

ConsignJob.

ConsignJob.

ConsignJobReply.

RetrieveOutcome.

RetrieveOutcomeReply.

RetrieveOutcomeReply.

RetrieveOutcomeAckReply.

ListVsites.

ListVsitesReply.

The UNICORE Protocol
unicore protocols
Unicore Protocols
  • Protocol used for File Transfer and Management is morecomplex than the UPL Protocol used for job submission.
  • The major reasons are the need
    • Synchronous communication: as the user initiates commands on the (Storage) Server and expects an immediate reply
    • A multi stage protocol to prevent the user of sending gigabytes of data to the Storage Server that cannot be stored as the user has no write privileges.
unicore protocols1
Unicore Protocols
  • Request data is stored within a Java Object that is digitally signed by the user.
  • Java Object is serialized and send using the Secure Socket Layer (SSL) protocol via the Gateway to the (SAFE) Server
  • When the request entails the transfer of a set of files from or to the server, an extended format is needed.
    • As the file data can be very large they cannot be included within a java object and serialised/de-serialiased.
the unicore data model1
The UNICORE Data Model
  • The assumption of the UNICORE Data model is
    • Data is stored either in local file spaces on the Client platform,
    • in file spaces on the execution system controlled by the UNICORE system, or in Storage Servers.
the unicore data model2
The UNICORE Data Model
  • Nspace(or Local): a local file space on the user’s workstation or on a local file server.
  • Xspace: the file space on the execution system where the home directory of the user’s account resides.
  • Uspace: a temporary working file space.
    • Each (sub-)job a dedicated temporary working directory is created which is named Uspace (UNICORE File Space).
    • Tasks of a (sub)-job are executed in the corresponding Uspace.
the unicore data model3
The UNICORE Data Model
  • The mechanisms for transferringfiles between Nspace and Uspace, or two Uspaces on different Vsites are implemented
    • using byte streaming techniques
    • File transfer is handled asynchronously.
file transfer and management protocol
File transfer and Management Protocol
  • Request data is stored within a Java Object that is digitallysigned by the user.
  • Java Objects are serialized and send using
    • Secure Socket Layer (SSL) protocol via the Gateway to the (SAFE) Server
unicore extensions1
Unicore Extensions
  • The client functionality can be extended by the use of the plugin interface, which makes important client services available to third–party code developers:
    • Register menu extensions, create and access display panes.
    • Query the available Usites and Vsites, plus the available resources at each Vsite.
    • Create job steps and job groups, and build a UNICORE job from them.
    • Submit a UNICORE job.
    • Control job status and access result files.
unicore extensions2
Unicore Extensions
  • One motivation to use the plugin techniques is integration of application specific tasks into UNICORE.
  • A plugin needs to interact with the corresponding NJS,
    • querying to find if the version of the Application is available.
    • it necessary to add the information to the Vsite resource description.
  • A plugin can reference resources in the abstract job description
    • the receiving NJS then consults the incarnation database to instantiate the resource reference into a command
the unicore client1
The Unicore Client
  • The functions to create and submit jobs, to monitor their status, and to inspect the results
    • Are combined into a single client implemented as a Java 2 application.
  • The client exploits the capabilities of
    • Swing tool set, presenting an intuitive graphical interface to the end-user.
the unicore client enables the end user to
The UNICORE Client enables the end-user to
  • Construct UNICORE jobs
  • Check whether a job under construction is
    • correct
    • can be run on the intended target site
  • Submit a completely constructed UNICORE job
  • Save/load partially/completely constructed jobs to/from disk
  • Inspect the status of jobs known to the UNICORE system
  • Control jobs that are scheduled or running
  • Retrieve the results for completed jobs/tasks
the unicore client2
The Unicore Client
  • For the construction of a job the client shows
    • a tree display of the job’s hierarchical structure,
    • a rendition of the action graph of a selected job group.
  • Client supports construction of jobs and of tasks:
    • Script Task: The equivalent of a legacy batch script.
    • Command Task: execute a command or application.
    • Import/Export Task: import a dataset from any file space accessible to the user into the Uspace, or export a dataset from the Uspace into a file space.
    • Transfer Task: transfers files from the execution space of a job group to another job group in the same job.
the unicore client3
The Unicore Client
  • File Operations Task: Copy, rename, or delete files at run time. Create directories or modify file or directory permissions.
  • Compile/Link Task: combines the steps of compiling and linking of Fortran programs.
  • Flow control task: these allow to branch in the action graph depending on the return code of a previously completed action, the presence or properties of a file, and the current date and time of day.
the unicore client4
The Unicore Client
  • The end-user never needs to explicitly setup any Import/Export tasks;
    • Client generates these tasks from file specifications that are filled in with the help of a file browser.
    • For the access to storage or archive servers, the user enters the necessary information as a “filename prefix” from a scroll down menu.
  • Files can be imported at job submission time from the user’s workstation, and at run time from the file space accessible to the local user, including general support for specifying storage or archive servers.
the unicore client5
The Unicore Client
  • Files can be exported to the file space accessible to the local user, including general support for specifying storage or archive servers.
  • Export of results or files to the user’s workstation is possible by request of the user once a task or job group is completed.
the unicore client6
The Unicore Client
  • The client supports the mandatory AJO resources, and has a generalextension mechanism to display arbitrary resource information:
    • Number of CPU’s
    • Number of Nodes
    • Storage size
    • Disk space – permanent
    • Disk space – temporary
    • Execution time
the unicore client7
The Unicore Client
  • Availability of specialexecution contexts
    • parallel execution, use of MPI or MPI–2, is controlled using capability resources.
    • This mechanism is easily extensible. Resources are checked before submitting a job, or on request.
  • The client can save a job into a file, using either
    • Portable binary format provided by the Java Object Serialization
    • Text based XML format.
    • A saved job can be loaded, edited and submitted at any time. Compatibility with future client versions is assured.
the unicore client8
The Unicore Client
  • The job monitor part can show submitted jobs at multiple UNICORE sites and Vsites in a tree like display
  • The status (submitted, running, executed, failed) is shown by color coding.
  • By clicking on a job, detailed information, including the task graph, result files etc. can be requested.
  • The user can initiate the transmission of results to his/her workstation.