Knowledge Center         Contents    Previous  Next    Index  
Platform Computing Corp.

Running Interactive and Remote Tasks

This chapter provides instructions for running tasks interactively and remotely with non-batch utilities such as lsrun, lsgrun, and lslogin.

Contents

Running Remote Tasks

lsrun is a non-batch utility to run tasks on a remote host. lsgrun is a non-batch utility to run the same task on many hosts, in sequence one after the other, or in parallel.

The default for lsrun is to run the job on the host with the least CPU load (represented by the lowest normalized CPU run queue length) and the most available memory. Command-line arguments can be used to select other resource requirements or to specify the execution host.

To avoid typing in the lsrun command every time you want to execute a remote job, you can also use a shell alias or script to run your job.

For a complete description of lsrun and lsgrun options, see the lsrun(1) and lsgrun(1) man pages.

In this section

Run a task on the best available host

  1. To run mytask on the best available host, enter:
    2. lsrun mytask 
 
    
LSF automatically selects a host of the same type as the local host, if one is available. By default the host with the lowest CPU and memory load is selected.

Run a task on a host with specific resources

If you want to run mytask on a host that meets specific resource requirements, you can specify the resource requirements using the -R res_req option of lsrun.

1 lsrun -R 'cserver && swp>100' mytask

In this example mytask must be run on a host that has the resource cserver and at least 100 MB of virtual memory available.

You can also configure LSF to store the resource requirements of specific tasks. If you configure LSF with the resource requirements of your task, you do not need to specify the -R res_req option of lsrun on the command-line. If you do specify resource requirements on the command line, they override the configured resource requirements.

See the Platform LSF Configuration Reference for information about configuring resource requirements in the lsf.task file.

Resource usage

Resource reservation is only available for batch jobs. If you run jobs using only LSF Base, LIM uses resource usage to determine the placement of jobs. Resource usage requests are used to temporarily increase the load so that a host is not overloaded. When LIM makes a placement advice, external load indices are not considered in the resource usage string. In this case, the syntax of the resource usage string is 

res[=value]:res[=value]: ... :res[=value]

The res is one of the resources whose value is returned by the lsload command. 

rusage[r1m=0.5:mem=20:swp=40]

The above example indicates that the task is expected to increase the 1-minute run queue length by 0.5, consume 20 MB of memory and 40 MB of swap space.

If no value is specified, the task is assumed to be intensive in using that resource. In this case no more than one task will be assigned to a host regardless of how many CPUs it has.

The default resource usage for a task is r15s=1.0:r1m=1.0:r15m=1.0. This indicates a CPU-intensive task which consumes few other resources.

Run a task on a specific host

  1. If you want to run your task on a particular host, use the lsrun -m option:
    2. lsrun -m hostD mytask

Run a task by using a pseudo-terminal

Submission of interaction jobs using pseudo-terminal is not supported for Windows for either lsrun or bsub LSF commands.

Some tasks, such as text editors, require special terminal handling. These tasks must be run using a pseudo-terminal so that special terminal handling can be used over the network.

  1. The -P option of lsrun specifies that the job should be run using a pseudo-terminal:
    2. lsrun -P vi

Run the same task on many hosts in sequence

The lsgrun command allows you to run the same task on many hosts, one after the other, or in parallel.

  1. For example, to merge the /tmp/out file on hosts hostA, hostD, and hostB into a single file named gout, enter:
    2. lsgrun -m "hostA hostD hostB" cat /tmp/out >> gout

Run parallel tasks

lsgrun -p

The -p option tells lsgrun that the task specified should be run in parallel. See lsgrun(1) for more details.

  1. To remove the /tmp/core file from all 3 hosts, enter:
    2. lsgrun -m "hostA hostD hostB" -p rm -r /tmp/core

Run tasks on hosts specified by a file

lsgrun -f host_file
  1. The lsgrun -f host_file option reads the host_file file to get a list of hosts on which to run the task.

Interactive Tasks

LSF supports transparent execution of tasks on all server hosts in the cluster. You can run your program on the best available host and interact with it just as if it were running directly on your workstation. Keyboard signals such as CTRL-Z and CTRL-C work as expected.

Interactive tasks communicate with the user in real time. Programs like vi use a text-based terminal interface. Computer Aided Design and desktop publishing applications usually use a graphic user interface (GUI).

This section outlines issues for running interactive tasks with the non-batch utilities lsrun, lsgrun, etc. To run interactive tasks with these utilities, use the -i option.

For more details, see the lsrun(1) and lsgrun(1) man pages.

In this section

Interactive tasks on remote hosts

Job controls

When you run an interactive task on a remote host, you can perform most of the job controls as if it were running locally. If your shell supports job control, you can suspend and resume the task and bring the task to background or foreground as if it were a local task.

For a complete description, see the lsrun(1) man page.

Hiding remote execution

You can also write one-line shell scripts or csh aliases to hide remote execution. For example: 

#!/bin/sh
# Script to remotely execute mytask
exec lsrun -m hostD mytask

or 

alias mytask "lsrun -m hostD mytask"

Interactive processing and scheduling policies

LSF lets you run interactive tasks on any computer on the network, using your own terminal or workstation. Interactive tasks run immediately and normally require some input through a text-based or graphical user interface. All the input and output is transparently sent between the local host and the job execution host.

Shared files and user IDs

When LSF runs a task on a remote host, the task uses standard UNIX system calls to access files and devices. The user must have an account on the remote host. All operations on the remote host are done with the user's access permissions.

Tasks that read and write files access the files on the remote host. For load sharing to be transparent, your files should be available on all hosts in the cluster using a file sharing mechanism such as NFS or AFS. When your files are available on all hosts in the cluster, you can run your tasks on any host without worrying about how your task will access files.

LSF can operate correctly in cases where these conditions are not met, but the results may not be what you expect. For example, the /tmp directory is usually private on each host. If you copy a file into /tmp on a remote host, you can only read that file on the same remote host.

LSF can also be used when files are not available on all hosts. LSF provides the lsrcp command to copy files across LSF hosts. You can use pipes to redirect the standard input and output of remote commands, or write scripts to copy the data files to the execution host.

Shell mode for remote execution

On UNIX, shell mode support is provided for running interactive applications through RES.

Not supported for Windows.

Shell mode support is required for running interactive shells or applications that redefine the CTRL-C and CTRL-Z keys (for example, jove).

The -S option of lsrun, ch or lsgrun creates the remote task with shell mode support. The default is not to enable shell mode support.

Run windows

Some run windows are only applicable to batch jobs. Interactive jobs scheduled by LIM are controlled by another set of run windows.

Redirect streams to files

By default, both standard error messages and standard output messages of interactive tasks are written to stdout on the submission host.

To separate stdout and stderr and redirect to separate files, set LSF_INTERACTIVE_STDERR=y in lsf.conf or as an environment variable.

  1. To redirect both stdout and stderr to different files with the parameter set:
    2. lsrun mytask 2>mystderr 1>mystdout 
 
    
The result of the above example is for stderr to be redirected to mystderr, and stdout to mystdout. Without LSF_INTERACTIVE_STDERR set, both stderr and stdout will be redirected to mystdout.

    
 
    
See the Platform LSF Configuration Reference for more details on LSF_INTERACTIVE_STDERR.

Load Sharing Interactive Sessions

There are different ways to use LSF to start an interactive session on the best available host.

Log on to the least loaded host

  1. To log on to the least loaded host, use the lslogin command.

    2. When you use lslogin, LSF automatically chooses the best host and does an rlogin to that host.

    With no argument, lslogin picks a host that is lightly loaded in CPU, has few login sessions, and whose binary is compatible with the current host.

Log on to a host with specific resources

  1. If you want to log on a host that meets specific resource requirements, use the lslogin -R res_req option.
    2. lslogin -R "solaris order[ls:cpu]" 
 
    
This command opens a remote login to a host that has the sunos resource, few other users logged in, and a low CPU load level. This is equivalent to using lsplace to find the best host and then using rlogin to log in to that host:

    
rlogin 'lsplace -R "sunos order[ls:cpu]"'

Load Sharing X Applications

Start an xterm

  1. If you are using the X Window System, you can start an xterm that opens a shell session on the least loaded host by entering:
    2. lsrun sh -c xterm & 
 
    
The & in this command line is important as it frees resources on the host once xterm is running, by running the X terminal in the background.

    
 
    
In this example, no processes are left running on the local host. The lsrun command exits as soon as xterm starts, and the xterm on the remote host connects directly to the X server on the local host.

xterm on a PC

Each X application makes a separate network connection to the X display on the user's desktop. The application generally gets the information about the display from the DISPLAY environment variable.

X-based systems such as eXceed start applications by making a remote shell connection to the UNIX server, setting the DISPLAY environment variable, and then invoking the X application. Once the application starts, it makes its own connection to the display and the initial remote shell is no longer needed.

This approach can be extended to allow load sharing of remote applications. The client software running on the X display host makes a remote shell connection to any server host in the LSF cluster. Instead of running the X application directly, the client invokes a script that uses LSF to select the best available host and starts the application on that host. Because the application then makes a direct connection to the display, all of the intermediate connections can be closed. The client software on the display host must select a host in the cluster to start the connection. You can choose an arbitrary host for this; once LSF selects the best host and starts the X application there, the initial host is no longer involved. There is no ongoing load on the initial host.

Setting up an X terminal to start an X session on the least loaded host

If you are using a PC as a desktop machine and are running an X Window server on your PC, then you can start an X session on the least loaded host.

The following steps assume you are using Exceed from Hummingbird Communications. This procedure can be used to load share any X-based application.

You can customize host selection by changing the resource requirements specified with -R "...". For example, a user could have several icons in the xterm program group: one called Best, another called Best_Sun, another Best_SGI.

Set up Exceed to log on the least loaded host

To set up Exceed to log on to the least loaded host:

  1. Click the Xstart icon in the Exceed program group.
  2. Choose REXEC (TCP/IP, ...) as start method, program type is X window.
  3. Set the host to be any server host in your LSF cluster:
    4. lsrun -R "type==any order[cpu:mem:login]" xterm -sb -ls -display your_PC:0.0
  4. Set description to be Best.
  5. Click the Install button in the Xstart window.

    6. This installs Best as an icon in the program group you chose (for example, xterm).

    The user can now log on to the best host by clicking Best in the Xterm program group.

Start an xterm in Exceed

To start an xterm:

  1. Double-click the Best icon.

    2. An xterm starts on the least loaded host in the cluster and is displayed on your screen.

Examples

Running any application on the least loaded host

To run appY on the best machine licensed for it, you could set the command line in Exceed to be the following and set the description to appY: 

lsrun -R "type==any && appY order[mem:cpu]" sh -c "appY -display your_PC:0.0 &"

You must make sure that all the UNIX servers licensed for appY are configured with the resource "appY". In this example, appY requires a lot of memory when there are embedded graphics, so we make "mem" the most important consideration in selecting the best host among the eligible servers.

Starting an X session on the least loaded host in any X desktop environment

The above approach also applies to other X desktop environments. In general, if you want to start an X session on the best host, run the following on an LSF host: 

lsrun -R "resource_requirement" my_Xapp -display your_PC:0.0

where

resource_requirement is your resource requirement string

Script for automatically specifying resource requirements

The above examples require the specification of resource requirement strings by users. You may want to centralize this such that all users use the same resource specifications.

You can create a central script (for example lslaunch) and place it in the /lsf/bin directory. For example: 

#!/bin/sh
lsrun -R "order[cpu:mem:login]" $@
exit $?

Which would simplify the command string to: 

lslaunch xterm -sb -ls -display your_PC:0.0

Taking this one step further, you could create a script named lsxterm: 

#!/bin/sh
lsrun -R "order[cpu:mem:login]" xterm -sb -ls $@
exit $?

Which would simplify the command string to: 

lsxterm -display your_PC:0.0
Platform Computing Inc.
www.platform.com
Knowledge Center         Contents    Previous  Next    Index