TASK SCHEDULING







There are two basic types of tasks in Virtual Laboratory: computational and experimental. Experiment is the specific task type for the VLab itself. It is scheduled to be run on scientific hardware and create a very challenging set of difficulties which need to be addressed. Interactive tasks need a definitely more sophisticated approach. The time in which the application GUI performing the task is presented to the user (or in other words: task execution time) has to be known in advance, and synchronized with user time preferences. The mechanism responsible for displaying the interface has to be carefully designed, to address authorization and security issues. All operations performed on batch and interactive tasks are presented in the paragraphs below.

BATCH JOBS

A general diagram describing the flowpath of batch computational tasks is presented on the figure below:


The batch computational tasks processing in the Virtual Laboratory System
The batch computational tasks processing in the Virtual Laboratory System.



The computational task is created in the Scenario Submission Application - a part of the VLab portal, responsible for creating Dynamic Measurements Scenarios. The dynamic scenario is submitted to the Scenario Management Module (SMM). At the appropriate time, during the scenario execution phase, the SMM sends the task to the Grid Gateway module via the Global Scheduler (not shown on the diagram). Grid Gateway sends the task description to the GridLab Resource Management System - an external meta scheduling system, responsible for scheduling and executing the task using the grid computational resources. The input data are passed as references to the Data Management System - the same system is used for uploading the computational results. The online task monitoring and status notification is handled by the GRMS, which contacts the Grid Gateway with the updated information about submitted tasks status.


INTERACTIVE TASKS

Handling the interactive tasks is more complicated than the batch ones. Different phases need to be specified here. They are described in the subparagraphs below.


Task submission




Interactive tasks submission
Interactive tasks submission.



Interactive tasks are submitted into the system just as the batch ones. Each consecutive step on the diagram was marked.
The detailed description:

1. Task (as a one element of the measurement scenario) is sent to the Scenario Management Module from the web portal
     (Scenario Submission Application).
2. Task is added to the database (via the Monitoring module)
3. At the appropriate time task is sent to the Global Scheduler (GS)
4. GS authorizes the user in the Grid Authorization Module
5. GS checks with Accounting whether the user has not exceeded the limit and can submit the task
6.  a) Task cannot be submitted - inform Monitoring module
     b) Task can be scheduled - send it to the Grid Gateway
7. Task is transferred to the GRMS, which schedules the task and sends the information about the results (success/failure) to the Grid Gateway.
The GG sends a query about the chosen server, and signs up for notifications concerning the scheduled task.
     a) Task cannot be submitted - inform Monitoring module


VNC session scheduling

In the previous step the interactive task was submitted into the GRMS. Now the GRMS has to decide where the interactive task should be executed. I also reserves a slot for VNC session. Information about the session schedule is returned back to the Grid Gateway (as notifications), which in turn sends it to the Monitoring module.


VNC session scheduling for interactive tasks
VNC session scheduling for interactive tasks.



The detailed operations:

1. The GRMS contacts the MDS system to gather information required for the connection preparation
     (maximum number of open VNC sessions, etc.).
2. It also contacts a VNC Session Database to check the actual sessions state. Taking all those information into account it will reserve
     a VNC session slot for interactive task invocation and update the database.
3. Scheduling information is passed as notification to the GG, which updates the task status, via the Monitoring module.


Establishing a secure connection




Establishing a secure VNC connection
Establishing a secure VNC connection.



The interactive task has been submitted to the system and the VNC session has been scheduled. The next step is to prepare the proper environment for the given task, launch it and wait for connection establishment from the VLab user.

1. The GRMS launches its scheduled task. The task is defined as an instance of the VNC Manager
     - which looks up the available port, runs the VNC server and the application.
2. The Grid Gateway is notified that everything has been prepared and the session can be established.
3. VNC Manager reports the port number in use and dynamically-generated password to the Grid Gateway..
4. The Grid Gateway propagates all gathered information to the Monitoring system.
5. The VLab user starts the SVNC Viewer with all the connection parameters taken automatically (and transparently) from Monitoring
     - and therefore has a full access to the application.


Prolonging the session




Prolonging the VNC Session
Prolonging the VNC Session.



The interactive task can be scheduled for the certain amount of time. The time period is specified by the user during task definition and submission. It may happen that the reserved time slot is too short to complete the data processing. When the reservation period is about to expire, the VLab system displays the appropriate warning and the user is given the possibility to request the session prolongation. After evaluation the actual session state (VNC Session Database) the prolonged access is granted or the request refused.

Prolonging the VNC session step by step:

1. The request is forwarded to the Global Scheduler.
2. Global Scheduler authorizes the request in the Grid Authentication Module (GAM).
3. GS checks the user limits in the Accounting module.
4. a) Verification failed - the Monitoring is informed that the session extension has failed and the process ends.
     b) Verification is positive - extension request can be sent to the Grid Gateway.
5. The request (authorized in the VLab system) is sent to the GRMS.
6. Next, the actual sessions state is looked up in the VNC Session Database and new session slot is reserved (if available).
7. The response is sent back to the Grid Gateway (as notification). GG updates the Monitoring with the new information.


Finishing the VNC session by the user




Ending the VNC session by the user
Ending the VNC session by the user.



The VLab user has the ability to end an active VNC session at any time after the session has been started.
The procedure is explained below:

1. The request is forwarded to the Grid Gateway.
2. GG sends it to the GRMS.
3. The GRMS system sends the appropriate signal to the instance of VNC Manager responsible
     for a given application. Application is closed and resources are freed.
4. GRMS updates the VNC Session Database ľ registration is removed.
5. The GRMS sends the result of this operation to the Grid Gateway as an notification.
6. Grid gateway updates monitoring information.


Finishing the VNC session by the system




Ending the VNC session by the VLab system
Ending the VNC session by the VLab system.



An active VNC session can be terminated by the VLab system (and GRMS) when the reservation period expires, or for any other reason.
The procedure is as follows:

1. After the reservation time expires, GRMS sends a signal to end the application (via VNC Manager).
2. GRMS updates the VNC Session Database.
3. GRMS sends information to Grid Gateway that the task was closed.
4. GG updates the task information in the Monitoring module.