Project mode using projects

License projects allow you to configure license distribution when running in project mode. Each distribution policy is applied locally, within service domains.

Tip:

Although license projects are not the same as LSF projects, you can map your license project names to LSF project names for easier monitoring.

Configure parameters

  1. Project mode can be set globally, or for individual license features. Set individually when using project mode for some features and cluster mode for some features.
    1. If using project mode for all license features, define CLUSTER_MODE=N in the Parameters section of lsf.licensescheduler.
    2. If using project mode for some license features, define CLUSTER_MODE=N for individual license features in the Feature section of lsf.licensescheduler.

      The Feature section setting of CLUSTER_MODE overrides the global Parameter section setting.

  2. List the License Scheduler hosts.

    By default with an LSF installation, the HOSTS parameter is set to the LSF_MASTER_LIST.

    • List the hosts in order from most preferred to least preferred. The first host is the master license scheduler host.

    • Specify a fully qualified host name such as hostX.mycompany.com unless all your License Scheduler clients run in the same DNS domain.

    HOSTS=host1 host2

  3. Specify the data collection frequency between License Scheduler and FlexNet.

    The default is 30 seconds.

    LM_STAT_INTERVAL=seconds

  4. Specify the path to the FlexNet command lmstat.

    For example, if lmstat is located in /etc/flexlm/bin:

    LMSTAT_PATH=/etc/flexlm/bin

Configure clusters

Configure the clusters permitted to use Platform License Scheduler in the Clusters section of the lsf.licensescheduler file.

This is only required if you are using more than one cluster.

In the Clusters section, list all clusters that can use Platform License Scheduler.

For example:

Begin Clusters 
CLUSTERS 
cluster1 
cluster2
End Clusters 

Configure projects

Each project defined in a Projects section of lsf.licensescheduler can have a distribution policy applied in the Feature section, where projects can be associated with license features.

Define the projects with or without priority.
Begin Projects 
PROJECTS       PRIORITY 
Lp1             3 
Lp2             1 
Lp3             2 
default         0 
End Projects

The higher the number, the higher the priority. When 2 projects have the same priority number configured, the first listed project has a higher priority. Priority is taken into account when license preemption occurs, where lower priority projects are prempted first.

If not explicitly configured, the default project has the priority of 0. A default project is used when no license project is specified during job submission.

Add project description

Optionally, you can add a project description of up to 64 characters to your projects to help identify them.

In the Project section of lsf.licensescheduler, find the project and add a description in the DESCRIPTION column.

For example:

Begin Projects
PROJECTS PRIORITY DESCRIPTION
p1       10       "Engineering project 123"
p2       9        "QA build project 2C"
P3       8        ""
End Projects

When running blinfo -Lp or blinfo -G, any existing project descriptions display.

Project mode service domains

A service domain is a group of one or more FlexNet license servers. Platform License Scheduler manages the scheduling of the license tokens, but the license server actually supplies the licenses. You must configure at least one service domain for Platform License Scheduler.

In project mode, each cluster can access licenses from multiple WAN and LAN service domains. Platform License Scheduler collects license availability and usage from FlexNet license server hosts, and merges this with license demand and usage information from LSF clusters to make distribution and preemption decisions.

Note:

Unless you require multiple service domains for some specific reason, we recommend configuring both modes with at most one LAN and one WAN for each feature in a cluster. Because Platform License Scheduler does not control license checkout, running with one cluster accessing multiple service domains is not optimal.

Configure service domains

You configure each service domain, with the license server names and port numbers that serve licenses to a network, in the ServiceDomain section of the lsf.licensescheduler file.

  1. Add a ServiceDomain section, and define NAME for each service domain.

    For example:

    Begin ServiceDomain 
    NAME=DesignCenterA 
    End ServiceDomain
  2. Specify the FlexNet license server hosts for that domain, including the host name and FlexNet port number.

    For example:

    Begin ServiceDomain 
    NAME=DesignCenterA 
    LIC_SERVERS=((1700@hostA)) 
    End ServiceDomain

    For multiple license servers:

    LIC_SERVERS=((1700@hostA)(1700@hostB))

    For redundant servers, the parentheses are used to group the three hosts that share the same license.dat file:

    LIC_SERVERS=((1700@hostD 1700@hostE 1700@hostF))

    Note:

    If FlexNet uses a port from the default range, you can specify the host name without the port number. See the FlexNet documentation for the values of the default port range.

    LIC_SERVERS=((@hostA))

Configure license features

Each type of license requires a Feature section in the lsf.licensescheduler file.

The Feature section includes the license distribution policy.

  1. Define the feature name used by FlexNet to identify the type of license.

    You only need to specify this parameter if the License Scheduler token name is not identical to the FlexNet feature name.

    Begin Feature
    FLEX_NAME=201-AppZ 
    End Feature
  2. Optionally, use the NAME parameter to define an alias between License Scheduler and FlexNet feature names.

    LSF does not support names that start with a number, or names containing a dash or hyphen character (-), which may be used in the FlexNet feature name. In these cases, define a NAME for the feature as well.

    In this example, the FlexNet feature name 201-AppZ has an alias of AppZ201.

    Begin Feature
    FLEX_NAME=201-AppZ 
    NAME=AppZ201 
    End Feature
  3. Define a distribution policy.

    A distribution policy defines the license fairshare policy in the format:

    DISTRIBUTION = ServiceDomain1 (project1 share_ratio project2 share_ratio ...) ServiceDomain2 (project3 share_ratio ...)

    For example, a basic configuration assigns shares:

    Begin Feature 
    FLEX_NAME=201-AppZ 
    NAME=AppZ201 
    DISTRIBUTION = DesignCenterA (LpA 2 LpB 1 default 1)
    End Feature

    LpA has the right to twice as many licenses as LpB. Jobs submitted without a license project specified can run under the default project.

  4. Optionally, add owned licenses to the distribution policy in the format:
    DISTRIBUTION = ServiceDomain1 (project1 share_ratio/number_owned project2 share_ratio/number_owned ...) ServiceDomain2 (project3 share_ratio ...)

    If LS_FEATURE_PERCENTAGE=Y or LS_ACTIVE_PERCENTAGE=Y in lsf.licensescheduler, number_owned is expressed as a percentage of the total licenses.

    Example 1:

    DISTRIBUTION = LanServer(Lp1 1 Lp2 1/10)

    This example assumes there are 10 licenses in total, all owned by Lp2.

    The two Platform License Scheduler projects, Lp1 and Lp2, and share the licenses, but grant ownership of the licenses to one of the projects (Lp2).

    When Lp2 has no work to be done, Lp1 can use the licenses. When Lp2 has work to do, Lp1 must return the license immediately to Lp2. The license utilization is always at the maximum, showing that all licenses are in use even while the license distribution policies are being enforced.

    Example 2:

    DISTRIBUTION=LanServer1(Lp1 1 Lp2 2/6)

    Lp1 is set to use one third of the available licenses and Lp2 to use two thirds of the licenses. However, Lp2 is always entitled to six licenses and preempts other license project jobs when licenses are needed immediately.

    If the projects are competing for a total of 12 licenses, Lp2 is entitled to eight (six on demand, and two more as soon as they are free).

    If the projects are competing for only six licenses in total, Lp2 is entitled to all of them, and Lp1 can only use licenses when Lp2 does not need them.

Track partial and unspecified license use

When you want to manage licenses not included in job resource requirements or have applications you know use licenses for only part of the length of each job, use these optional settings.

  1. Optionally, specify DYNAMIC=Y to consider the license feature as a dynamic resource when it is only used for part of the job.

    Set DYNAMIC=Y for applications with known license use that do not use the license for the entire length of the job. Jobs submitted with duration specified then release the license when not in use.

    Begin Feature 
    NAME = p1_2 
    DISTRIBUTION= Lan1 (a 1 b 1 c 1 default 1) 
    DYNAMIC=Y 
    End Feature

    For example, a taskman job submission with duration:

    taskman -R "rusage[p1_2=1:duration=2]" myjob

  2. Optionally, set ENABLE_DYNAMIC_RUSAGE=Y in the Feature section of lsf.licensescheduler to track license use of license features not specified at job submission. For example:
    Begin Feature 
    NAME = feat2 
    DISTRIBUTION = LanServer(proj1 1 default 1) 
    ENABLE_DYNAMIC_RUSAGE = y 
    End Feature

    Submit a job to run the application, specifying the license feature name:

    bsub -R "rusage[feat1=1]" -Lp proj1 app1 

    The job runs and license feat1 is checked out:

    blstat 
    FEATURE: feat1 
    SERVICE_DOMAIN: LanServer TOTAL_INUSE: 1    TOTAL_RESERVE: 0    TOTAL_FREE: 4    OTHERS: 0  
      PROJECT                 SHARE   OWN  INUSE RESERVE FREE   DEMAND 
     proj1                    50.0 %   0     1    0      2       0
     default                  50.0 %   0     0    0      3       0
    FEATURE: feat2             
    SERVICE_DOMAIN: LanServer TOTAL_INUSE: 0    TOTAL_RESERVE: 0    TOTAL_FREE: 10   OTHERS: 0   
    PROJECT                 SHARE   OWN  INUSE RESERVE FREE   DEMAND 
     proj1                    50.0 %   0     0    0      5       0
     default                  50.0 %   0     0    0      5       0
    blusers -l 
    FEATURE  SERVICE_DOMAIN  USER   HOST    NLICS   NTASKS OTHERS  DISPLAYS PIDS 
    feat1    LanServer       user1  hostA   1       1      0     (/dev/tty) (16326)
    blusers -J 
    JOBID   USER     HOST     PROJECT          CLUSTER        START_TIME 
    1896    user1    hostA    proj1            cluster1       Aug  9 10:01:25 
    RESOURCE        RUSAGE        SERVICE_DOMAIN 
    feat1           1             LanServer

    Later, app1 checks out feature feat2. Since it was not specified at job submission, feat2 is a class C license checkout. But since it is configured with ENABLE_DYNAMIC_RUSAGE=Y, jobs that require feat2 are considered managed workload, and subject to the distribution policies of project proj1:

    blstat 
    FEATURE: feat1 
    SERVICE_DOMAIN: LanServer 
    TOTAL_INUSE: 1    TOTAL_RESERVE: 0    TOTAL_FREE: 4    OTHERS: 0 
    PROJECT                 SHARE   OWN  INUSE RESERVE FREE   DEMAND 
     proj1                    50.0 %   0     1    0      2       0
     default                  50.0 %   0     0    0      2       0
    FEATURE: feat2             
    SERVICE_DOMAIN: LanServer 
    TOTAL_INUSE: 1    TOTAL_RESERVE: 0    TOTAL_FREE: 9    OTHERS: 0 
    PROJECT                 SHARE   OWN  INUSE RESERVE FREE   DEMAND 
     proj1                    50.0 %   0     1    0      4       0
     default                  50.0 %   0     0    0      5       0
    blusers -l 
    FEATURE  SERVICE_DOMAIN  USER   HOST    NLICS  NTASKS  OTHERS  DISPLAYS   PIDS 
    feat1     LanServer       user1  hostA  1      1       0    (/dev/tty)  (16326) 
    feat2     LanServer       user1  hostA  1      1       0    (/dev/tty)  (16344)
    blusers -J 
    JOBID   USER      HOST      PROJECT             CLUSTER        START_TIME 
    1896    user1     hostA     proj1               cluser1        Aug  9 10:01:25 
    RESOURCE        RUSAGE        SERVICE_DOMAIN 
    feat1           1             LanServer 
    feat2           1             LanServer

Restart to implement configuration changes

  1. Run lsadmin limrestart or bladmin reconfig to restart the bld.
  2. If you have added, changed, or deleted any Feature sections, you may need to restart mbatchd. In this case a message is written to the log file prompting the restart.

    If required, run badmin mbdrestart to restart each LSF cluster.

View projects and descriptions

Run blinfo -Lp to view projects and descriptions.

For example:

blinfo -Lp
PROJECT PRIORITY DESCRIPTION
p1      10       Engineering project 123
p2      9        QA build project 2C
P3      8        

View license allocation

Run blstat -t token_name to view information for a specific license token (as configured in a Feature section).

blstat output differs for cluster mode and project mode.