Learn more about Platform products at http://www.platform.com

[ Platform Documentation ] [ Title ] [ Contents ] [ Previous ] [ Next ] [ Index ]



Configuring the Components in LSF Desktop Support


Once LSF desktop support is installed, it is designed to run out of the box. You need to specify very few parameters to begin using the LSF desktop support. However, you may need to periodically update configuration parameters for the desktop clients.

Contents

[ Top ]


Configuring Desktop Clients

When you want to change the configuration of all of the desktop clients, you can edit the desktop client configuration file, SEDConfig.xml.

SEDConfig.xml is located on the directory service server in the directory specified by the CONFIGDIRECTORY value in install.config. You can use an XML editor or a text editor such as vi to modify this file.

Each desktop client in the LSF desktop support environment reports to the desktop server on startup and once every 24 hours, checking for an updated configuration. If the desktop client detects a new version of the configuration, it downloads the new configuration file and applies it.

You can configure the following options for desktop clients:

Example: SEDConfig.xml

<?xml version="1.0"?>
<SEDConfig>
<MEDDSURL>http://dirservhost.platform.com/servlet/DynamicSEDConfig</
	 MEDDSURL>
<MEDURL>http://dirservhost.platform.com/servlet/SedSoap</MEDURL>
<SEDFullyKillNTJob>yes</SEDFullyKillNTJob>
<SEDPollInterval>300</SEDPollInterval>
<SEDLatestVersion>41</SEDLatestVersion>
<SEDLatestVersionURL>http://dirservhost.platform.com/SED/sedupd.exe
	 </SEDLatestVersionURL>
</SEDConfig>

Changing the time between work requests from an idle desktop client

Edit the SEDPollInterval parameter in SEDConfig.xml:

<SEDPollInterval>300</SEDPollInterval>

To change the amount of time between requests for work from an idle desktop client, specify the time the desktop client waits before requesting another job or reporting status in seconds. The default is 300 seconds, which is five minutes.

Setting the time period for which a desktop client pauses

Edit the SEDOptOutInterval parameter in SEDConfig.xml to specify the number of seconds for which the desktop client pauses. At the end of this time period, the desktop client starts processing again.

Specify the time period as follows:

<SEDOptOutInterval>ssssss</SEDOptOutInterval>

where ssssss is the number of seconds. For example, to pause the desktop client for 2 hours, specify 7200 seconds.

Updating desktop client applications with a new version


Note: The sedupd.exe file is included with patch kits.

Edit the following parameters in SEDConfig.xml:

Changing the Directory Services host

Edit the MEDDSURL parameter in SEDConfig.xml to specify the host name in the URL pointing to the updated configuration file. Specify the URL as follows:

<MEDDSURL>http://dirservhost.platform.com/servlet/DynamicSEDCo
nfig</MEDDSURL>


Do not change other values in the URL other than the host name (dirservhost.platform.com).

All desktop server host names must be included in the MED.lst file. The location of this file is specified by the CONFIGDIRECTORY parameter in install.config. If CONFIGDIRECTORY is not defined, the default location is $ACH_TOP/config.

The dynamic Web page reads the MED.lst file and returns the name of an desktop server in the MEDURL field of the XML file. The desktop client then uses this desktop server until the next reconfiguration.

Ensuring full cleanup on an Windows desktop client

When a job completes on an Windows desktop client, some child processes associated with the job may still be running. You can enable an option to kill all processes associated with seduser (or the user account that runs the jobs) when a job completes, using the SEDFullyKillNTJob option. By default, this option is not enabled.

Edit the SEDFullyKillNTJob parameter in SEDConfig.xml. Change the value from no to yes as follows:

<SEDFullyKillNTJob>yes</SEDFullyKillNTJob>


Warning: Make sure that the user account under which LSF desktop support jobs run on Windows is not a real end-user's account--the user's processes could also be killed when the Windows job completes.

Setting the conditions for a desktop client requesting work

Specify the circumstances under which a desktop client requests work

Set the SEDMode parameter in SEDConfig.xml to one of the following values:

If no valid value is specified, then the default value of Screensaver is used.

For example: <SEDMode>Logon</SEDMode>

Determine whether the desktop client mode is configurable by individual desktop client users

Use the SEDModeSelectableByUser parameter in SEDConfig.xml to determine whether the desktop client mode (defined by the value of the SEDMode parameter, described above,) is configurable by individual desktop client users.

Valid values are yes or no. Otherwise, the default value is used. Default value is yes (case insensitive).

Specify the period of inactivity before the desktop client can request work

Use the SEDConsoleIdle parameter in SEDConfig.xml to specify the period of keyboard or mouse inactivity in seconds before the desktop client can request work. This is relevant only if the SEDMode parameter, described above, is specified as Idle.

The default is 900 seconds (15 minutes). Any integer above 300 seconds is a valid value. Otherwise, the default value is used, and a warning is logged in the SED log file.

Changes to the above configuration parameters take effect only when the desktop client next checks the desktop server for configuration changes. By default, this check occurs every 24 hours. You can use the SEDUpdateCheckInterval parameter in SEDConfig.xml to configure this interval, as described below, in Specifying the interval to check for configuration changes.

Specifying the interval to check for configuration changes

Edit the SEDUpdateCheckInterval parameter in SEDConfig.xml to specify, in hours, the interval at which the desktop client checks the desktop server for configuration changes. The default value is 24 (hours).

Note that the desktop client only checks for configuration changes if it is idle, i.e. if it is not currently running a job. If the desktop client is not idle when the check is scheduled to occur, it occurs the next time the desktop client becomes idle.

Setting conditions for jobs running on battery power

Edit the SEDSuspendOnBattery parameter in SEDConfig.xml to indicate whether jobs can run if the desktop client is running on a machine using battery power (e.g. a laptop computer). If this parameter is set to Yes, then if the desktop client switches to battery power:

Specifying whether desktop clients can write to the cache

Edit the SEDDisableCache parameter in SEDConfig.xml to indicate whether the desktop client can write to the cache. Valid values are yes, true, false, and no (the default), case insensitive.


Note: The LSB_MED_CACHEFILE_DEFAULT parameter in med.conf specifies the default file caching setting for all desktop clients connecting to a specific desktop server. For additional information, see Desktop Server Configuration Settings and refer to the Platform LSF Desktop Support User's Guide.

Enabling file caching on the desktop client

The desktop client transparently uses Microsoft Internet Explorer's cache to upload and download files. In Windows 2000, Windows 2003 Server, and Windows XP, the desktop client runs as the LocalSystem account. Therefore, for each desktop client user, you need to specify:


Note: Changing any of these settings requires restarting the desktop client to take effect.

For detailed instructions on changing these settings, see Enabling Caching on the Desktop Client.

[ Top ]


Configuring EGO Management of Platform LSF Desktop Support Services

You can configure EGO management of the master execution daemon (MED) and the Web server components (Tomcat and Apache) so that they run as EGO services. This enables automatic startup of these services, which improves availability.

IMPORTANT


EGO must be enabled in the LSF cluster to configure EGO management of LSF desktop support services. See Administering Platform LSF for information about enabling EGO for LSF.

About EGO management of LSF desktop support services

With EGO management of LSF desktop support services enabled, you can

Configuring EGO management of LSF desktop support services provides additional high availability in cases where the MED or Web services fail during job execution. EGO can restart the services, which prevents rerunnable jobs from wasting valuable CPU time by rerunning unnecessarily.

In the following examples, the term MED/WS refers to the master execution daemon and web server processes running on a Platform LSF desktop support server.

Without EGO management of LSF desktop support services (feature not enabled): Web service

Stage Process Action Result
1
mbatchd
Dispatches a job to MED/WS on hostA
Job waits on MED/WS on hostA
2
SED
Requests a job from the MED/WS on hostA
WS on hostA sends a job to the SED
3
SED
Initiates the job to run on the client host
Client host successfully runs the job
4
Tomcat or Apache or both
Crash on hostA while the job is running
Jobs cannot be redispatched, because mbatchd sees that MED is running.
5
SED
Tries to upload job results to the WS
Upload of job results fails
6
SED
Tries again to upload job results a maximum of 5 times
CPU time to run job is wasted and there is a performance cost due to the SED querying the Directory Service

With EGO management of LSF desktop support services enabled: Web service

Stage Process Action Result
1 -3

Same as with EGO management of LSF desktop support services not enabled

4
Tomcat or Apache or both
Crash on hostA while the job is running
Jobs cannot be redispatched, because mbatchd sees that MED is running.
5
EGO
Automatically restarts failed service
SED can upload job results
6
SED
Uploads job results to the WS
CPU time is not wasted because the job ran only once

Without EGO management of LSF desktop support services (feature not enabled): MED

Stage Process Action Result
1
mbatchd
Dispatches a job to MED/WS on hostA
Job waits on MED/WS on hostA
2
SED
Requests a job from the MED/WS on hostA
WS on hostA sends a job to the SED
3
SED
Initiates the job to run on the client host
Client host successfully runs the job
4
MED
Crashes on hostA while the job is running
mbatchd redispatches the job
5
SED
Uploads job results to the WS that is still running on hostA
Job results are lost when the job is redispatched, because the job reruns on a new host
6
SED
Tries again to upload job results. Job fails after 5 retries.
CPU time to run job is wasted because the job was rerun even though it already completed successfully

With EGO management of LSF desktop support services enabled: MED

Stage Process Action Result
1 -3

Same as with EGO management of LSF desktop support services not enabled

4
MED
Crashes on hostA while the job is running
EGO restarts MED, mbatchd does not need to redispatch the job
5
SED
Uploads job results to the WS on hostA
CPU time is not wasted because the job ran only once

Scope and Limitations

EGO management of LSF desktop support services applies to the MED and to the Web servers (Tomcat and Apache). With EGO management of LSF desktop support services enabled, you should not use the command lsfac_daemons to start or stop Apache or Tomcat services. Instead, you should use the egosh command to start and stop these services.

Configuration to enable EGO management of LSF desktop support services

Enable EGO management of the MED

Configuration file Parameter and syntax Behavior
lsf.conf
LSF_EGO_DAEMON_CONTROL=Y
  • Enables EGO Service Controller to control LSF res, sbatchd, and MED startup. Set the value to "Y" at installation if you want EGO Service Controller to start services, and restart services if they fail.

Enable EGO management of LSF desktop support Web services

During installation, the files LSFDesktopApache.xml and LSFDesktopTomcat.xml are created in the directory $AC_TOP/config, using the correct variable values. To enable EGO management of LSF desktop support Web services, you must copy these files and increase the number of available slots to accommodate the two additional services (Apache and Tomcat) managed by the EGO Service Controller.

  1. Copy LSFDesktopApache.xml and LSFDesktopTomcat.xml to EGO_ESRVDIR/esc/conf/service
  2. Increase the availableSlots in the InternalResourceGroup by 2, as shown in the following example.

    Configuration file Parameter and syntax
    LSF_CONFDIR/ego/cluster_name/ ResourceGroup.xml
    <ResourceGroup ResourceGroupName="InternalResourceGroup" availableSlots="5"/>

Important


To add the new services, you must restart EGO using the command
egosh ego restart all. See Administering and Using Platform EGO.

[ Top ]


Configuring Platform LSF Desktop Support High Availability

The high availability feature provides a way to maximize CPU usage by ensuring that successfully completed rerunnable jobs run only once, even if master execution daemon (MED) and Web server (WS) processes fail during job execution. With high availability enabled, client hosts can upload job results to a new desktop server if they can no longer connect to the original desktop server.

About LSF desktop support high availability

There are three key components of the Platform LSF desktop support high availability feature:

Without high availability (feature not enabled)

In the following description, the term MED/WS refers to the master execution daemon and web server processes running on a Platform LSF desktop support server.

Stage Process Action Result
1
mbatchd
Dispatches a job to MED/WS on hostA
Job waits on MED/WS on hostA
2
SED
Requests a job from the MED/WS on hostA
WS on hostA sends a job to the SED
3
SED
Initiates the job to run on the client host
Client host successfully runs the job
4
MED and Tomcat or Apache
Crash on hostA while the job is running
mbatchd thinks hostA is down
5
mbatchd
Redispatches the job to another desktop sever
SED does not know the job was redispatched
6
SED
Tries to send job completion results to the WS on hostA
CPU time to run job is wasted because the job was rerun even though it already completed successfully

With high availability enabled

Stage Process Action Result
1 -4

Same as with high availability not enabled

5
mbatchd
Redispatches the job to another MED
A new desktop server owns the redispatched job
6
SED
Tries to send job results to hostA
SED cannot upload the job results to hostA
7
SED
Contacts the Directory Service and requests the identity of the new desktop sever
Directory Service looks in the job status pool directory for the information
8
Directory Service
Gets the identity of the new desktop server from the job status pool and sends this information to the SED
SED knows where to send the job results, and the job does not run again
9
SED
Uploads job results to new desktop server
CPU time is not wasted because the job ran only once

Scope and behavior

The high availability feature applies only to jobs submitted as rerunnable, and when both the MED, the lim, and one or more components of the associated WS fail. For cases where high availability does not apply, you can configure EGO to control MED, Apache, and Tomcat as services that EGO automatically restarts.

In the following description, (ok) indicates that a process is running and (-) indicates that the process failed during job execution.

High availability takes effect MED and LIM Apache Tomcat Behavior
Yes
-
-
-
Jobs can be redispatched, because mbatchd sees the desktop server (MED/WS) host as down. The SED sends the job results to the new desktop server.
-
ok
-
-
-
ok
-
ok
ok
No
ok
ok
-
Jobs cannot be redispatched, because mbatchd sees that the MED is running. If EGO control of LSF services is enabled, EGO can restart Apache and Tomcat automatically.
ok
-
ok
ok
-
-

Configuration to enable the high availability feature

The high availability feature is configured for desktop servers (MED) in wscache.conf and for desktop clients (SED) in SEDConfig.xml. You must configure both servers and clients.

Before you enable the high availability feature:

To enable the high availability feature, you must define the following parameters.

Configuration file Parameter and syntax Default Behavior
wscache.conf
FTDIRECTORY path_name
Not defined
  • Enables high availability for the desktop server
  • Specifies the absolute path to the directory that will contain the job status pool
  • Must be defined on every desktop server host
SEDConfig.xml
<SEDJobFaultTolerance>
Yes
</SEDJobFaultTolerance>
Not defined
  • Enables high availability for the desktop client
  • If left undefined or set to No, high availability is not enabled

<MEDBACKUPDSURL>
URL;URL;URL...
</MEDBACKUPDSURL>
Not defined
  • Specifies the URL for the backup Directory Service(s)
  • Not required if your Directory Services are configured as round-robin

Important


To apply configuration changes to desktop servers, you must restart the Web services on all desktop server hosts. To apply changes to desktop clients, you can either restart all SEDs or let each SED automatically get the new values when the SED checks for configuration changes.

Configuration to modify the high availability feature

You can define the following optional parameter to modify the length of time a desktop server holds a job before dispatching the job to a new SED.

Configuration file Parameter and syntax Default Behavior
wscache.conf
FTOVERTIME hours
24
  • Specifies the amount of time in hours that the desktop server waits to receive job results from the SED
  • The desktop server waits the specified amount of time before redispatching the job to a new SED
  • If the original SED contacts the desktop server within the specified time, the job is not redispatched
  • The value must be an integer greater than zero

[ Top ]


Changing Job Completion Log Location

Each desktop server has a log file job_completion_log with a date stamp in the YYYY_MM_DD format in which daily job completion information is stored. For example: job_completion_log.host_name.2001_12_31

The location of the log file is specified by the JOBDIRECTORY parameter in wscache.conf in the TOMCAT_HOME directory of each desktop server.

Whenever a job is completed, a line is logged in the file. If no jobs are completed on a specific day, no file is created for the day. Each day has a separate log file.

Job completion log file format

TimeStamp|HumanReadableTime|JobID:rerun|SedID|ExitedCode|FailureCode|
	 ElapsedTime|UserTime|KernelTime

For example:

1010985060497|15/01/2002 14:30:15|123[34]:0|CR185119-B_886056_1|0|0|2908|0|7531

To change the directory in which job log files are stored:

You can change the location where the log files are stored.

  1. On the desktop server, locate and open the file wscache.conf for editing. It is located in the TOMCAT_HOME directory.
  2. To change the location where the job completion log files are stored, in the JOBDIRECTORY parameter, specify the full path for the directory. For example:

    JOBDIRECTORY ACH_TOP/wscache

  3. Save the file.

[ Top ]


Setting Up Licensing

Make sure that you have the correct number of licenses for your desktop servers and your desktop clients.

To set up licensing:

  1. Contact Platform Technical Support to get authorization keys for the following:
    • Each desktop server requires an LSF Server license
    • A feature license for the appropriate number of desktop servers
    • A feature license for the appropriate number of desktop clients
  2. Follow the procedures in the Platform LSF Administrator's Guide to set up licenses for your desktop servers.

[ Top ]


Configuring the Default LSF Desktop Support Queue

The default LSF desktop support queue is AC_QUEUE, which is configured during the installation using the default options. Because LSF desktop support uses a subset of the standard LSF queue parameters, do not add to or delete parameters from this queue. If required, you can change the following values:

To configure the default queue:

  1. Find the default LSF desktop support queue AC_QUEUE in lsb.queues.
  2. HOSTS parameter. Optional. You can change the desktop server host name for this queue as follows:
    HOSTS=host_name
    

  3. RUNLIMIT parameter. Optional. If you want to change the amount of time that a job in this queue can run before the job is terminated automatically, specify the following:
    RUNLIMIT = [hh:mm] maxhh:mm
    

    where maxhh:mm is the maximum run limit allowed, and hh:mm, if specified, is the default run limit for the queue. The default is 120 10000000, which sets the default run limit to 2 hours and the maximum to 10 million minutes.


    Note: The value of RUNLIMIT in the queue is scaled based on the CPU factor of the execution host. In Platform LSF desktop support, it is scaled by the speed of the desktop server rather than by the speed of the desktop client. Therefore, in the queue, you should set DEFAULT_HOST_SPEC=pc_host_model. For additional information refer to the Platform LSF Reference.

  4. SWAPLIMIT parameter. Optional. If you want to change the total virtual memory that a job in this queue can use before the job is terminated automatically, specify the following:
    SWAPLIMIT = nnnn
    

    where nnnn is the maximum number of kilobytes. The default is 102400, or 100 MB.

  5. AC_RES_REQ parameter. Optional. If you want to specify desktop client resource requirements that apply to all jobs submitted to this queue, specify a resource requirements statement using this parameter. For example:
    AC_RES_REQ=cput==PII&&mem>128
    

    The above states that all jobs submitted to this queue require a Pentium II processor with more than 128 megabytes of free physical memory. See Built-in resource definitions for the possible values you can specify for resources.

  6. STOP_COND parameter. Optional. If you want to stop a job and submit it to a different desktop client if the available memory on the desktop client drops beneath a certain threshold, you can set the threshold level here using the STOP_COND parameter. The only accepted threshold is mem. For example:
    STOP_COND=mem<50
    
  7. RERUNNABLE parameter. Optional. If yes, enables automatic job rerun (restart). Rerun is disabled when RERUNNABLE is set to no. The yes and no arguments are not case sensitive.:
  8. Run badmin reconfig to reconfigure mbatchd.

[ Top ]


Creating an Additional LSF Desktop Support Queue

If you want to use multiple queues in your LSF desktop support, make sure that the queues you create are LSF desktop support-compatible. LSF desktop support supports a limited set of LSF queue parameters. Therefore the recommended method for creating an additional queue is to copy the queue created by the install script.

To create an additional queue:

  1. Find the default LSF desktop support queue AC_QUEUE in lsb.queues.
  2. Copy AC_QUEUE. You can edit the new queue, but do not delete or add any parameters to the queue. The default queue contains all of the valid parameters for an LSF desktop support queue.
  3. QUEUE_NAME parameter. Required. Change the name of the queue as follows:
    QUEUE_NAME = newname
    

    Specify any ASCII string up to 40 characters long. You can use letters, digits, underscores (_) or dashes (-). You cannot use blank spaces, and you cannot use the reserved name default.

  4. Specify the remaining parameters as described in Configuring the Default LSF Desktop Support Queue.
  5. Run badmin reconfig to reconfigure mbatchd.

[ Top ]


Desktop Server Configuration Settings

The desktop server configuration file /etc/med.conf contains the URLs required by the desktop server and the desktop clients for file and data transfer, and for status reporting.

When you installed the desktop server, the install script install.config configured the desktop server for you. A description of each of the parameters is included here to help your understanding of the configuration.

CAUTION


Do not change the values in this file. To change the values, edit the install script and reinstall the desktop server.

About med.conf parameters

The following parameters are defined within med.conf:

Example med.conf

LSB_MED_WEB_URL=http://host1/servlet/P2PServer
LSB_MED_DATA_WEB_URL=http://host
LSB_MED_STAGE_DIR="/usr/local/lsfac/apache/htdocs"
LSB_MED_TOP_DIR=/usr/local/lsfac
LSB_MED_SHARED_FILESYS=y
LSB_API_CONNTIMEOUT=60
LSB_API_READTIMEOUT=120
USER_ID=99
GROUP_ID=99

[ Top ]


Supporting Desktop Client Resource Requirements

LSF desktop support supports desktop client resource requirement specifications--the user can specify the minimum configuration of the desktop client required to run a particular job. Alternatively, you can set up LSF desktop support queues that define the minimum configuration required for all jobs submitted to that queue.

The desktop client resource types must first be defined to the cluster, and the desktop clients must be enabled to report on their resource availability before the user can successfully specify resource requirements.

LSF desktop support supports both built-in resource definitions and custom resource definitions. See Built-in resource definitions on this page for a list of the built-in resource definitions. See Adding New Resources to the Desktop Server for instructions on creating new resource definitions. See Resource requirement syntax for the syntax for defining the resources required, either within the queue definition, or within the job submission itself.

Built-in resource definitions

The following resource definitions are built in to LSF desktop support and available for use immediately:

Resource Name Value Type Description Example
cput
string
CPU type
PII or PIII
ncpus
numeric
How many CPUs there are
1
cpusp
numeric
Main frequency of CPU (MHZ)
500
mem
numeric
Free physical memory (MBytes)
256
maxmem
numeric
Max physical memory (MBytes)
64
disk
numeric
Max free disk space LSF desktop support jobs can use (MBytes)
1000

The following CPU types are supported:

CPU Types Description
Am486
AMD-Am486
ATHLON
AMD AthlonTM
ATHLON64
AMD AthlonTM 64
Celeron
Intel CeleronTM processor, models 5 or 6
K5
AMD-K5TM
K6
AMD-K6TM
K6-2
AMD-K6-2TM
OPTERON64
AMD OpteronTM 64
Pen
Intel Pentium® processor
PPro
Intel Pentium® Pro processor
PII
Intel Pentium® II processor, model 3 or 5
PIIX
Intel Pentium® II XeonTM processor
PIII
Intel Pentium® III processor, Intel Pentium® III Coppermine processor
PIIIX
Intel Pentium® III XeonTM processor
PIV
Genuine Intel Pentium® 4 processor

Resource requirement syntax

Specify the resource specification as a logical expression, as follows:

AC_RES_REQ=resource_name operator value[operator resource_name operator 
value...]
resource_name

The name of the resource as defined in ac.restype.xml.

operator

The operator that defines the relationship between the resource name and the value, or between nested expressions. The operators are listed below in the order of precedence (the order in which they are evaluated, from top to bottom). The operator can be one of the following:

Operator Description
(
Beginning of expression. Expressions within parentheses are evaluated first.
)
End of expression.
>
Greater than. Use only with value type numeric.
<
Less than. Use only with value type numeric.
>=
Greater than or equal to. Use only with value type numeric.
<=
Less than or equal to. Use only with value type numeric.
==
Equal to. Use with any value type.
!=
Not equal to. Use with any value type.
&&
Logical AND. Both expressions must be true.
||
Logical OR. One of the expressions must be true.

value

The value of the resource to be compared to.

To specify multiple resources, combine specifications together using && or || combination operators. You can join specifications using brackets. For example:

"AC_RES_REQ=((cput==PII||mem>256)&&disk>500)"

The above example specifies either a Pentium II CPU or 256 MB free physical memory, and 500 MB disk space available for LSF desktop support jobs.

[ Top ]


Adding New Resources to the Desktop Server

You can schedule jobs based on available resources. There are many resources built into LSF desktop support, but you can also add your own resources, and then use them in the usual way.

LSF desktop support provides powerful resource selection mechanisms, so that only the desktop clients with the required resources are allowed to run your jobs. For maximum flexibility, characterize your resources clearly, so that users can make the appropriate choices. For example, if some of your desktop clients are connected to both Ethernet and FDDI, while others are only connected to Ethernet, you probably want to define a resource called fddi and associate the fddi resource to desktop clients connected to FDDI. This way, users can specify the resource fddi if they want their jobs to run on desktop clients connected to FDDI.

To add new resources to a desktop server:

  1. Log in to the desktop server as the LSF desktop support administrator.
  2. Open the file ac.restype.xml for editing in an XML editor or in a simple text editor such as Notepad or Textpad. Specify a name and value type for the resource, by adding the following to the file:
    <Resource>
         <ResName>name</ResName>
          <ValueType>string</ValueType>
    </Resource>
    

    where name is the name of the resource you are defining, up to 16 characters in length, and ValueType is either boolean, string or numeric. Resource names cannot begin with a number, and cannot contain any of the following characters:

    : . ( ) [ + - * / ! & | < > @ = ' "

    Resource names are case-sensitive, and a resource name cannot be any of the following reserved names:

    cput cpusp ncpus maxmem mem disk

    Refer to Example: ac.restype.xml for an example of ac.restype.xml.

  3. Save ac.restype.xml.
  4. Create an external resource plug-in that detects the new resources for all desktop clients connected to that host. See To create an external resource plug-in: for instructions.
  5. Use one of the following methods to deploy the external resource plug-in to all the desktop clients connected to this host:
    1. Use a software-management tool that can deploy software in enterprise working environments to deploy the external resource plug-in to all the desktop clients. Deploy the plug-in to the same folder as SED.exe on the desktop clients.
    2. Use the self-upgrade feature of LSF desktop support to deploy the external resource plug-in to all the desktop clients. See To build a distributable package for the plug-in: for instructions.

Example: ac.restype.xml

The following is an example of ac.restype.xml, where a new resource name hname is defined in addition to the built-in resource definitions:

<?xml Version="1.0"?>
<ACRestype>
     <Resource>
            <ResName>cput</ResName>
              <ValueType>string</ValueType>
      </Resource>
      <Resource>
            <ResName>cpusp</ResName>
              <ValueType>numeric</ValueType>
      </Resource>
      <Resource>
            <ResName>ncpus</ResName>
              <ValueType>numeric</ValueType>
      </Resource>
      <Resource>
            <ResName>mem</ResName>
              <ValueType>numeric</ValueType>
      </Resource>
      <Resource>
            <ResName>maxmem</ResName>
              <ValueType>numeric</ValueType>
      </Resource>
      <Resource>
            <ResName>disk</ResName>
              <ValueType>numeric</ValueType>
      </Resource>
      <Resource>
            <ResName>hname</ResName>
              <ValueType>string</ValueType>
      </Resource>
</ACRestype>

[ Top ]


Adding a Resource Plug-In to the Desktop Clients

To add a new resource definition to LSF desktop support, you need to add the new resource name to ac.restype.xml. If you have not already done so, go to Adding New Resources to the Desktop Server to define the new resource. Then return here to add it to the desktop client plug-in.

About the external resource plug-in

A desktop client supports only one plug-in, called extRes.dll. The plug-in must be in a Win32 dynamically-linked library. The plug-in must have two APIs called by the SED:

BOOL WINAPI getExtRes(LPTSTR lpBUFFER[out], LPDWORD 
lpnSize[in|out])
int  WINAPI getVersion()

To create an external resource plug-in:

  1. Get the sample project of an external plug-in extRes.dll from ACH_TOP/plugin_example.
  2. Open the project with Visual C++ 6.0.
  3. Read the files to know how the sample works. Be sure to modify only the recommended files.
  4. Write a function to detect the new resource just like the sample function detectDesktopName.

    Make sure that you report the resource last. For example:

    void detectDesktopName(CSEDExtRes* pClassExtRes)
    {
    TCHAR szDesktopName[256]={0};
    DWORD cchBuff=256;
    GetComputerName(szDesktopName,&cchBuff);
    pClassExtRes->reptNewExtRes("hname","string", 
    szDesktopName);
    }
    
  5. In the function reportAllResInfo(), call your function:
    void reportAllResInfo(CSEDExtRes* pC;assExtRes)
    {
    detectDesktopName(pClassExtRes);
    detectIEVersion(pClassExtRes);
    detectOS(pClassExtRes);
    }
    
  6. In the function getVersion(), set the new version number based on the last version number.

To build a distributable package for the plug-in:

You can use this method to deploy the plug-in to the desktop clients using the automatic upgrade feature. Because the plug-in will be downloaded by the desktop client, you should have the upgraded binary file digitally signed by Platform Computing. Follow these steps to create the package:

  1. Send the upgraded extRes.dll to your Platform Support representative, who will sign and package it for you in pluginupd.exe.
  2. Copy pluginupd.exe to the same directory as that specified in PluginLatestVersionURL in APACHE_TOP/htdocs/SED/SEDConfig.xml.
  3. Set the permissions of pluginupd.exe to 755.
  4. In the file SEDConfig.xml, in the PluginLatestVersion parameter, specify the exact version number of the extRes.dll and save the file. Each desktop client will check periodically for a change in the version. When it detects a change, it does to the specified location and gets the new executable, which it installs automatically.

[ Top ]


Entries in wscache.conf for Desktop Servers

The wscache.conf file is present on each desktop server and on the Directory Services host.

The following parameter is present in the ACH_TOP/jakarta-tomcat-4.1.30- LE-jdk14/wscache.conf file of desktop servers.

JOBDIRECTORY

Description

The full path to the directory in which the internal state files of the system are stored.

Example

JOBDIRECTORY /usr/local/lsfac/wscache

[ Top ]


Entries in wscache.conf for Directory Services Server

The following parameters are present in the wscache.conf file of the Directory Services host.

STATSDIRECTORY

Description

The directory in which the job completion log files are stored. Job completion log files are named as follows:

job_completion_log.host_name.YYYY-MM-DD

Example

STATSDIRECTORY /usr/local/lsfac/wscache

CONFIGDIRECTORY

Description

The location where configuration for the directory service is stored. This entry does not exist if directory services are not enabled.

Example

CONFIGDIRECTORY /usr/local/lsfac/wscache

JOBSTATISTICSURLS

Description

Automatically generated value. Do not change. URLS generated by each desktop server indicating where data about the server can be retrieved.

BLACKLIST_POLL_INTERVAL

Description

Specifies how frequently hosts on the block list connect to the desktop server to request work. For additional information and an example, see Controlling Desktop Client Access.

WHITELIST_POLL_INTERVAL

Description

Specifies how frequently hosts on the whitelist connect to the desktop server to request work. For additional information and an example, see Controlling Desktop Client Access.

DEFAULT_POLL_INTERVAL

Description

Specifies how frequently hosts on neither the blacklist nor the whitelist connect to the desktop server to request work. For additional information and an example, see Controlling Desktop Client Access.

FTDIRECTORY

Description

Enables high availability for the desktop server. Specifies the absolute path to the directory that will contain the job status pool. Must be defined on every desktop server host. For additional information and an example, see Configuring Platform LSF Desktop Support High Availability.

FTOVERTIME

Description

Specifies the amount of time in hours that the desktop server waits to receive job results from the SED. The desktop server waits the specified amount of time before redispatching the job to a new SED. If the original SED contacts the desktop server within the specified time, the job is not redispatched. The value must be an integer greater than zero. For additional information and an example, see Configuring Platform LSF Desktop Support High Availability.

[ Top ]


Adding an LSF Desktop server to your cluster

  1. Add a server host to your cluster, as described in Administering Platform LSF.
  2. Convert the new LSF server host to a desktop server.

    See Converting the LSF Server Host to a Desktop Server in Installing LSF Desktop Support.

  3. If you are implementing automatic load balancing, add the new desktop server to file MED.lst.

    Each line is a server name. The path of this file is specified by the CONFIGDIRECTORY parameter in install.config.

  4. To prevent desktop servers from running standard LSF jobs, see Excluding Desktop Servers from LSF Queues in Configuring the Components in LSF Desktop Support.
  5. Configure the Default LSF Desktop Support queue.

    Edit the HOSTS parameter of AC_QUEUE to include the new desktop server.

  6. Update the LSF host configuration.
    1. Edit lsf.cluster.cluster_name.
    2. In the host section, change the host type of the new desktop server to AC, and add activecluster to its resource list.
  7. Update the LSF resource configuration.
    1. Edit lsb.resources.
    2. In the Limit section, add the new desktop server to the PER_HOST parameter.
  8. Restart lim and mbatchd.
  9. Enable the client to use the new server:
    1. If you do not use automatic load balancing, install a client that points to the new server.
    2. If you use automatic load balancing, client will get new server name from directory server.

[ Top ]


Configuring Windows Group Policies to Define Security Settings for SED

If you have seduser as a domain account, you can set permissions by defining Group Policy to apply to all desktop in the domain.

The following example sets Group policy on a Windows 2003 server:

  1. Choose Start > Run, enter mmc to start the Microsoft Management Console, and click OK.
  2. In the Console1 window, choose File > Add/Remove Snap-in.
  3. In the Add/Remove Snap-in dialog, click Add.
  4. In the Add Standalone Snap-in dialog, choose Active directory users and computers, and click Add.
  5. Close the dialog and return to Console1 window.
  6. Click + to expand Active Directory Users and Computers.
  7. Right click on the Organizational Unit (OU) you want to create a Group Policy Object for (for example, testlab.com), and select Properties.
  8. Select the Group Policy tab.
  9. Select the Group Policy Object of your domain, and click Edit to open the Group Policy Object Editor.
  10. Expand Computer Configuration > Windows Settings > Security Settings > File System.
  11. Right click File System, and click Add File.
  12. In the Add a file or folder dialog, select a driver or folder where you want to set the permissions for seduser, and click OK.

    The Database Security dialog is displayed.

  13. In the Database Security dialog box, set the permissions of seduser for that driver or folder, and click OK.

[ 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.