[ Platform Documentation ] [ Title ] [ Contents ] [ Previous ] [ Next ] [ Index ]
This chapter describes LSF desktop support, previously known as ActiveCluser, and explains how it works.
[ Top ]
About This Guide
This guide is your starting point for learning how to use and manage Platform LSF desktop support. It provides an overview of LSF desktop support concepts, licensing information, how to install and configure LSF desktop support, some basic commands, and some troubleshooting tips.
Who should use this guide
This guide is written for LSF desktop support administrators who want to familiarize themselves with the fundamentals of managing and using an LSF desktop support environment.
What you should already know
This guide assumes that you are familiar with basic LSF administration, and that you are familiar with basic LSF concepts such as clusters, jobs, servers, and hosts.
How this guide is organized
Introducing Platform LSF Desktop Support introduces Platform LSF desktop support, the various components, architecture and configuration, and basic data flow.
Planning the Installation describes issues you need to consider when planning your Platform LSF desktop support installation.
Installing LSF Desktop Support guides you through the installation process.
Configuring the Components in LSF Desktop Support describes the configuration parameters and the ways you use them to configure your environment.
Managing LSF Desktop Support describes those procedures you may use periodically to maintain your environment.
Troubleshooting provides some troubleshooting tips.
[ Top ]
Overview
Platform LSF desktop support enables you to take advantage of unused computing cycles on standard Microsoft Windows 2000, Windows 2003 Server, and Windows XP desktop client computers. LSF desktop support replaces the standard LSF job execution mechanism with its own: running large, compute-intensive jobs across Windows desktop clients.
LSF desktop support maintains the integrity and security of the Windows desktop client--it has no authority on the desktop client, so it cannot access data besides its own files. LSF desktop support provides automatic failure recovery--it automatically restarts failed or canceled jobs on desktop clients.
LSF desktop support has undergone extensive testing in a 16-server environment with over 75,000 desktop clients across the Internet.
Using a desktop server with a fast processor and 2 GB of memory, you can run 2000 half-hour jobs per hour on 1000 desktop clients.
LSF desktop support uses resource-aware scheduling to match jobs to desktop clients with the appropriate resources. LSF desktop support has built-in resource definitions and also provides support for user-defined resources.
Desktop clients are automatically upgraded from a central desktop server, reducing maintenance time and effort.
LSF desktop support provides Web browser interfaces for job submission and to see both job progress and environment status.
LSF desktop support uses ACPI-compliant power management features on laptops, so it does not run a battery down when the laptop is not plugged in.
LSF desktop support can be used to run any application, provided that application can be made available on the desktop client. Applications and data do not need to reside on the desktop client--they can be transferred with the job that runs them. However, data files are cached so that they are not transferred multiple times, tying up valuable network bandwidth.
For security purposes, you can specify that applications running on the desktop client should not write to the cache.
[ Top ]
Components
An LSF desktop support environment consists of the following components:
- LSF master host
- Desktop servers
- Desktop clients
- Directory Services host--when load balancing between desktop servers is used
When load balancing of desktop servers is used
The following diagram illustrates the components in an LSF desktop support environment that uses load balancing between desktop servers via a Directory Services host:
![]()
For more information about load balancing, see Load Balancing and the Directory Services Host.
When load balancing of desktop servers is not used
The following diagram illustrates the components in an LSF desktop support environment when load balancing between desktop servers is not used:
![]()
LSF master host
LSF desktop support uses the LSF master host for scheduling. Users submit jobs to an LSF desktop support queue, and the LSF master host selects the appropriate desktop server, and dispatches the job to it.
Directory Services host
If load balancing of desktop servers is enabled, Directory Services hosts are configured, which provides load balancing within the LSF desktop support environment. When a desktop client is ready for its first job, it goes to the Directory Services host, where it receives the URL for the next desktop server. The desktop client then goes to that URL to request a job. When the job is completed, the desktop client returns its results to the desktop server. At a configured interval (the default is every 24 hours), the desktop client goes back to the Directory Services host, where it receives a new desktop server URL and any updates to its binary files.
Desktop server
The desktop server is part of an LSF cluster, and it is sometimes referred to as the MED. It receives jobs to dispatch from the LSF master host, and awaits a request for a job from a desktop client. A desktop client goes to the desktop server and downloads a job and any related files. When the job completes, the desktop client passes job status and job results to the desktop server, which in turn passes it to the LSF master host.
The desktop server uses an Apache Web server to serve files and a Tomcat Java application server to make the jobs available to the desktop clients and to provide environment status to you and your users.
The desktop server supports a set of Web pages that provide status information about both activity within the LSF desktop support environment and individual job status.
The desktop server is automatically monitored and restarted in the event of a failure. It automatically obtains its configuration parameters when restarted, so it is easily reconfigured.
LSF dispatches groups of jobs at a time using job-level compression, to minimize network traffic. The desktop server avoids network traffic by:
- Caching files that are common to many jobs
- Supporting staging of files during non-busy network periods
- Maintaining minimal communication between desktop server and desktop clients
- Performing no polling--desktop clients initiate all communication with the desktop server
The desktop clients cache reusable input and reference files.
Desktop client
The desktop client resides on Windows machines and is sometimes referred to as an SED. If load balancing is used, the desktop client obtains the URL of the desktop server it should connect to from the Directory Services host. This URL is updated at pre- configured intervals. The default is 24 hours. If load balancing is not used, the desktop client is assigned a URL for a desktop server at installation time.
The desktop client polls the desktop server at preset intervals, requesting a job. The desktop client reports its available resources. If a job is waiting, and the desktop client has sufficient resources to run the job, the desktop client downloads the job from the Tomcat server and any files required for the job from the Apache Web server. It runs the job and, at its next polling interval, it returns job status and results to the Tomcat server. If the job has completed, it requests another job.
The desktop client can run jobs in the background at all times. It runs jobs at the lowest priority to minimize interference with the desktop client user.
Generally, the user is not aware of the jobs running, unless the machine has limited memory available, or if a job requires transfer of one or more large files. However, if a user feels that a job is impacting the performance of the machine, that user can temporarily remove the desktop client from the LSF desktop support environment. The desktop client remains out of the LSF desktop support environment for a time period configured by the administrator, or until the user explicitly resumes the desktop client processing.
The desktop client can run in one of four modes:
- Always mode, where the desktop client runs jobs in the background at all times. The desktop client runs jobs at the lowest priority to minimize interference with the desktop client user.
- Screen saver mode, where the desktop client runs jobs only when a screen saver is active (default).
- Logon mode, where the desktop client runs jobs only when no user is logged on to the desktop client. A user is logged on during an interactive session initiated from a Windows logon dialog box.
- Idle mode, where the desktop client runs jobs only when the desktop client has been idle for a configurable period.
When running in any mode where the desktop client is allowed control, the user can pause the desktop client if required. At any time, the user can then resume desktop client processing.
![]()
The desktop client automatically restarts after a system failure or reboot, and automatically obtains its configuration parameters from the Web server.
The desktop client can provide an interface for the desktop client user, accessed from an LSF desktop support system tray icon:
- Right-clicking the system tray icon opens the menu, where the user can pause or resume desktop client processing, go to the Details dialog, or hide the system tray icon.
- Double-clicking the system tray icon opens the Details dialog, where the user can specify the desktop client mode, as described above.
Desktop client user ID
The desktop client runs jobs under a user ID specific to LSF desktop support. By default, this user ID is
seduser
, but you can change the user ID as part of a silent installation. The desktop client runs using the SED service. The desktop client installer modifies local security settings to grant the Log on as batch job privilege to the LSF desktop support user ID. If the target machine is in a Windows 2000 domain, and the Domain Group Policy settings overwrite this privilege, the desktop client may be unable to work.[ Top ]
Data Flow
The data flow process discussed here occurs in an LSF desktop support environment, whether or not load balancing is performed. It occurs after the desktop client receives the URL designating from which desktop server to request a job.
![]()
The LSF desktop support job cycle is as follows:
- The desktop client reports to Apache that it is idle and provides its available resources (memory, disk, number and type of processors, processor speed).
- Apache forwards the desktop client resource information to Tomcat, and Tomcat returns an appropriate job to the desktop client through Apache.
- The desktop client gets files from Apache.
- The desktop client runs a job.
- The desktop client returns results and job status to Apache, and Apache forwards the job status to Tomcat.
Submitting a job
- The user submits a job to an LSF desktop support queue (the default is AC_QUEUE), and specifies the applications and data files and any resources required to run the job.
- LSF dispatches the job to a desktop server based on the queue specified.
- The job is pushed to the desktop server.
- The desktop server waits for a qualified desktop client to request a job, and gives the desktop client the URL to locate the job.
- The desktop client connects to the URL and downloads the job and its associated applications and data.
Running a job
- The desktop client runs the job at its first opportunity.
- The desktop client returns the status of the job to the desktop server.
Type of jobs you can run
LSF desktop support can run jobs that execute the following types of commands:
Typically, LSF desktop support runs jobs that require more than a few minutes to run.
All jobs that run within an LSF desktop support environment are assumed to be re- runnable, i.e., if a job overruns its run limits on a desktop client, the desktop client terminates it, and the desktop server re-dispatches the job to another desktop client.
Types of applications you can run
LSF desktop support can run commercial off-the-shelf applications, and it can distribute any Windows or DOS application to a desktop client. Some commercial applications require pre-installation on the desktop client. For example, Java applications require JVM and Java runtime libraries.
Any applications that a desktop client is requested to execute while running a job must be transferred to the desktop client, or must reside in the Program Files directory.
LSF desktop support supports all scripting and interpretive languages--VBScript, Perl, Python, Windows batch files, and Java and other compile-on-demand languages.
Changing desktop client user rights
By default, the desktop client user (by default,
seduser
) runs with the right to Log on as a batch job. Certain scripting languages may require additional user rights to function correctly. For example, CScript, a version of Windows Scripting Host, requires the desktop client user to have the right to Log on locally.The exact method for changing user rights depends on the version of Windows. The following example changes the rights of the default
seduser
user to run CScript in Windows 2000 Professional:
- Click Start > Settings > Control Panel > Administrative Tools > Services > SED.
- Select Action > Stop to stop the desktop service.
- Return to the Administrative Tools window, and select Local Security Policies.
- In the Local Security Settings window, expand Local Policies > User Rights Assignment.
- Allow the
seduser
user to log on locally:- Return to the Administrative Tools window, and select Services > SED.
- Select Action > Start to restart the desktop service.
See Configuring the Components in LSF Desktop Support for information about configuring Windows Group Policies for SED users.
Execution limits
The user can place limits on jobs:
- Execution limits and elapsed time limits, set in the LSF desktop support queue or at job submission time
- Memory limits, set in the LSF desktop support queue or at job submission time
- Disk limits, number and type of CPUs required
Submitter can control jobs
Users can see the status of their jobs, and kill jobs, if necessary.
The following LSF commands are supported within an LSF desktop support environment:
badmin
bhist
bhosts
bjobs
bkill
(most options)bqueues
bsub
(used to submit jobs)
Note: In earlier versions, the LSF desktop support-onlyasub
command was also used to submit jobs directly to the LSF desktop support queue.The asub command is obsolete.
busers
lsadmin
Order in which jobs are run
Generally, LSF desktop support jobs run on a first-in, first-out basis. However, if a user specifies particular desktop client resource requirements when submitting a job, the order in which the jobs run depends on the availability of desktop clients that meet the specified requirements.
[ Top ]
Configuration Overview
LSF desktop support uses the following configuration files:
LSF desktop support configuration files
Configuration File Location Description For more information, see install.config
<
LSF Server Host
>/install
Specifies the configuration settings
Configuring this file is part of the process that converts an LSF Server to a desktop server.
Converting the LSF Server Host to a Desktop Server
med.conf
<
d
esktop server
>/etc
Configures the desktop server after installation, specifying the URLs required by the desktop server and the desktop clients for file and data transfer and for status reporting.
Desktop Server Configuration Settings
sedsetup.cmd
User-defined, in a central location, in the same directory containing lsf7Update2_desktop.msi
, which used to run the silent installation on the desktop client.
Specifies the configuration settings for the desktop client before running the silent installation on the desktop client.
Installing the Desktop Client
SEDConfig.xml
<Directory Service Server>/<directory specified by CONFIGDIRECTORY in install.config
>
Configures all desktop clients after installation.
Configuring Desktop Clients
wscache.conf
TOMCAT_HOME
Specifies location of job completion log files.
Changing Job Completion Log Location
LSF configuration files
Configuration File Location Description For more information, see lsb.queues
By default, this file is installed in LSB_CONFDIR/
cluster_name/configdir
.
[ Top ]
[ Platform Documentation ] [ Title ] [ Contents ] [ Previous ] [ Next ] [ Index ]
Date Modified: January 29, 2009
Platform Computing: www.platform.com
Platform Support: support@platform.com
Platform Information Development: doc@platform.com
Copyright © 1994-2009 Platform Computing Corporation. All rights reserved.