Once you have configured Platform License Scheduler in project mode with projects or project groups, you may want to include some additional configuration that is not required, but can be useful.
With ownership defined, projects with demand for licenses are able to reclaim licenses up to the assigned ownership share for the project. With active ownership enabled, ownership is expressed as a percent of the total ownership for active projects, and the actual ownership for each project decreases as more projects become active. This allows ownership to automatically adjust based on project activity.
Active ownership can be used with projects, groups of projects, and project groups. Set percentage ownership values to total more than 100% to benefit from active ownership.
When active ownership is enabled, ownership settings for inactive projects are disregarded during license token distribution.
Jobs requiring a license feature but not submitted to a license project for that feature are submitted to the default project. For jobs to run, a share of license tokens must be assigned to the default project.
If you do not want the default project to get shares of license tokens, you do not need to define a default project in the distribution policy for a feature, however jobs in the default project will pend by default.
To avoid having jobs submitted without a project pend, either assign shares to the default project, or disable default projects so jobs are rejected.
Configuring groups of projects lets you set shares and ownership for each group and distribute license features to groups of projects. A license project should only belong to one group. Preemption first occurs between groups of projects, and then occurs between projects.
The following tables show changes in preemption behavior based on ownership configured for groups of projects, with a total of 20 licenses. With groups of projects configured, GroupA is able to preempt in order to reclaim 10 owned licenses. Since Lp2 is not using all 5 owned licenses, Lp1 can use more than the share it owns.
Begin FeatureNAME = AppYDISTRIBUTION = LanServer1(Lp1 5/5 Lp2 5/5 Lp3 5/5 Lp4 5/5)GROUP = GroupA(Lp1 Lp2) GroupB (Lp3 Lp4)End Feature
In this example, Lp1 and Lp2 belong to the group GroupA. Lp3 and Lp4 belong to the GroupB group.
By default, interactive (taskman) jobs do not receive a share of the license token allocation, while all clusters receive equal shares.
You can allocate a share of all license features to interactive jobs in the Parameters section.
In lsf.licensescheduler, edit the Parameters section:
When the change in configuration takes effect, interactive tasks are allocated the same share (by default) as each cluster.
By default in project mode, each cluster receives one allocation share from a license feature, and interactive tasks receive no shares.
You can modify the allocation of license shares across clusters and to interactive tasks in individual Feature sections.
For example, this ALLOCATION setting matches the default when ALLOCATION is undefined and interactive jobs are enabled with ENABLE_INTERACTIVE=Y. An equal share is allocated to each cluster and to interactive jobs.
Begin FeatureNAME = AppXDISTRIBUTION = LanServer1 (Lp1 1)ALLOCATION = Lp1 (Cluster1 1 Cluster2 1 interactive 1)End Feature
In this example licenses are shared equally between cluster1 and interactive tasks, with cluster2 receiving nothing:
Begin Parameters...ENABLE_INTERACTIVE = y...End ParametersBegin FeatureNAME = AppYDISTRIBUTION = LanServer (Lp1 1)ALLOCATION = Lp1(cluster1 2 cluster2 0 interactive 2)End Feature
In the following example, even though the global allocation to interactive jobs is disabled (ENABLE_INTERACTIVE = N), ALLOCATION defined in the Feature section can assign a share to interactive jobs for this license feature.
Begin FeatureNAME = AppZDISTRIBUTION = LanServer (Lp1 1)ALLOCATION = Lp1(cluster1 0 cluster2 1 interactive 2)End Feature
Given a total of 12 licenses, 4 are allocated to cluster2 and 8 are allocated to interactive tasks.
When FEATURE_LIST is configured for a group of license features in lsf.licensescheduler, you can view detailed information about the groups.
License feature locality allows you to limit features from different service domains to a specific cluster, so that License Scheduler does not grant tokens to jobs from license that legally cannot be used on the cluster requesting the token.
Setting locality means that license resources requested from different clusters are mapped to different tokens in License Scheduler
Features with different locality are treated a different tokens by License Scheduler. You must configure separate feature sections for same feature with different localities.
When License Scheduler receives license requests from LSF, it knows where the request is from, and it interprets the request into demands for tokens usable by that cluster. For example, if clusterA sends a request to the bld asking for 1 hspice license, License Scheduler marks the demand for both hspice@clusterA and hspice. When the job gets either token to run, the demand is cleaned up for both tokens.
LOCAL_TO allows you to limit features from different service domains to specific clusters, so License Scheduler only grants tokens of a feature to jobs from clusters that are entitled to them.
For example, if your license servers restrict the serving of license tokens to specific geographical locations, use LOCAL_TO to specify the locality of a license token if any feature cannot be shared across all the locations. This avoids having to define different distribution and allocation policies for different service domains, and allows hierarchical group configurations.
License Scheduler manages features with different localities as different resources.
Some of your service domains may have geographical restrictions when serving licenses. In this example, two clusters in one location can run hspice jobs. and 4 service domains are defined for the hpsice feature:
The geographical license checkout restrictions are:
Begin Feature
NAME = hspice
DISTRIBUTION = SD1 (Lp1 1 Lp2 1)
LOCAL_TO = clusterA
End Feature
Begin Feature
NAME = hspice
DISTRIBUTION = SD2 (Lp1 1 Lp2 1)
LOCAL_TO = clusterB
End Feature
Begin Feature
NAME = hspice
DISTRIBUTION = SD3 (Lp1 1 Lp2 1) SD4 (Lp1 1 Lp2 1)
End Feature
Or use the hierarchical group configuration (GROUP_DISTRIBUTION):
Begin Feature
NAME = hspice
GROUP_DISTRIBUTION = group1
SERVICE_DOMAINS = SD1
LOCAL_TO = clusterA
End Feature
Begin Feature
NAME = hspice
GROUP_DISTRIBUTION = group1
SERVICE_DOMAINS = SD2
LOCAL_TO = clusterB
End Feature
Begin Feature
NAME = hspice
GROUP_DISTRIBUTION = group1
SERVICE_DOMAINS = SD3 SD4
End Feature
The following table shows various combinations of LOCAL_TO and other feature section parameters:
You can define different License Scheduler tokens for the same FlexNet feature. The the service domain names (in either the DISTRIBUTION line or the SERVICE_DOMAINS for group configurations) of the same FlexNet feature in different feature sections must be exclusive. They cannot overlap.
When LOCAL_TO is configured for a feature, you can define different License Scheduler tokens for the same FlexNet feature with different localities. The constraints are:
For the same FlexNet feature, service domains must be exclusive.
The location name of LOCAL_TO defines the locality of that feature, so the name must be unique for all tokens with same FlexNet feature.
You should use same location name for different FlexNet features with the same pattern of locality, but License Scheduler does not check whether the same location name of a different feature contains the same list of clusters.
Features must either have a different NAME or have LOCAL_TO defined. The service domains for each License Scheduler token of same FlexNet feature must be exclusive.
The LOCAL_TO parameter simplifies the ALLOCATION configuration. Most of the time you are only interested in who can participate to share a particular token. LOCAL_TO gives the equal share for all the clusters defined in LOCAL_TO and applies to all the projects. Use ALLOCATION to fine tune the shares for individual projects between different clusters:
Except for the keyword interactive, all the cluster names defined in ALLOCATION must also be defined in the LOCAL_TO parameter.
The global parameter ENABLE_INTERACTIVE and ALLOCATION with interactive share defined works same as before. If ALLOCATION is configured, it ignores the global setting of the ENABLE_INTERACTIVE parameter.
If ALLOCATION is not defined, but LOCAL_TO is defined, the default value for ALLOCATION will be equal shares for all the clusters defined in LOCAL_TO parameter. This applies to all license projects defined in DISTRIBUTION or GROUP_DISTRIBUTION.
If both ALLOCATION and LOCAL_TO are defined, ALLOCATION parameter can be used to fine tune the shares between the clusters for different projects.
The following table shows example configurations with two clusters and 12 hspice licenses distributed as follows:
The License Scheduler command taskman is a job starter for taskman jobs to use License Scheduler without bsub. taskman checks out a license token and manages interactive UNIX applications.
If LOCAL_TO is specified for a feature, taskman jobs need to specify feature names with locality information similar to submission with bsub. You need to know which token can be used from the location where task is going to run. For example: