LSF Handbook
搜索文档…
项目组的项目模式
Project groups use a ProjectGroup section to build a hierarchical project structure, which you can use to set limits on projects that span multiple clusters.
Depending on your license usage, you can configure different project groups for different license features, or reuse the same hierarchical structure.
Each license feature in project mode can either use projects or project groups. Changing from projects to project groups involves adding a ProjectGroup section and changing the license token distribution that is configured in the Feature section. Other configuration remains the same.
Parent topic:

Configuring project groups

About this task

ProjectGroup sections use configured projects (each with a Projects section in the lsf.licensescheduler file) to form a hierarchical structure for each feature.
Note
The Feature section GROUP parameter is used to group projects together, simplifying configuration, and is not the same as a ProjectGroup section.

Procedure

  1. 1.
    Add a ProjectGroup section to the lsf.licensescheduler file:
    1
    Begin ProjectGroup
    2
    GROUP SHARES OWNERSHIP LIMITS NON_SHARED
    3
    End Projectgroup
    Copied!
    If LS_FEATURE_PERCENTAGE=Y or LS_ACTIVE_PERCENTAGE=Y in lsf.licensescheduler, values for OWNERSHIP, LIMITS, and NON_SHARED are expressed as a percentage of the total licenses, not as an absolute number.
  2. 2.
    For each branch in the hierarchy, add a line to the ProjectGroup section.
    1. 1.
      Under the heading GROUP, indicate the project that branches, and direct descendants in the hierarchy (group(member ...)).
    2. 2.
      Under the heading SHARES, set the integer share for each member project.
    3. 3.
      Under the heading OWNERSHIP, set the integer ownership for each bottom-level group member (leaf node), with a dash (-) representing no ownership. The OWNERSHIP value must be greater than or equal to the NON_SHARED value.
    4. 4.
      Under the heading LIMITS set the integer license limit for each member project, with a dash (-) representing unlimited. The LIMITS value must be greater than or equal to the OWNERSHIP value.
    5. 5.
      Under the heading NON_SHARED, set the integer number of non-shared licenses each bottom-level group member (leaf node) uses exclusively, with ’-’ representing none.
    6. 6.
      Optionally, under the heading DESCRIPTION, add a description up to 64 characters long, using a backslash () to extend to multiple lines.
    For example, the branch g4 splits into three members:
    1
    GROUP SHARES OWNERSHIP LIMITS NON_SHARED
    2
    (g4 (p4 p5 p6)) (1 1 1) (1 1 1) () (- 3 -)
    Copied!
  3. 3.
    In the Feature section, set parameter GROUP_DISTRIBUTION to the top level of the ProjectGroup section hierarchy.
    The DISTRIBUTION parameter that is used for projects is no longer used.
  4. 4.
    In the Feature section, list service domains in the SERVICE_DOMAINS parameter.
    Unlike for projects, service domains are not included in the distribution for project groups.

Project group examples

img
This hierarchy is implemented by the project group configuration:
1
Begin ProjectGroup
2
GROUP SHARES OWNERSHIP LIMITS NON_SHARED
3
(topgrp (g1 g2)) (1 1) () (10 10) ()
4
(g1 (g3 g4)) (1 1) () (10 10) ()
5
(g2 (g5 g6)) (1 1) () (- 5) ()
6
(g3 (p1 p2 p3)) (1 1 2) () (3 4 5) ()
7
(g4 (p4 p5 p6)) (1 1 1) (1 3 1) () (0 3 0)
8
(g5 (p7 p8 p9)) (1 1 1) (2 0 2) () (1 0 1)
9
(g6 (p10 p11 p12)) (1 1 1) (2 2 2) (4 4 4) (1 0 1)
10
End ProjectGroup
Copied!
License feature configuration that uses this project group:
1
Begin Feature
2
NAME = AppZ
3
GROUP_DISTRIBUTION = topgrp
4
SERVICE_DOMAINS = LanServer WanServer
5
End Feature
Copied!
Use the LIMITS column to limit token use, so tokens are sometimes not distributed even if they are available. By default, License Scheduler distributes all available tokens if possible. For example, if total of six licenses are available:
1
Begin ProjectGroup
2
GROUP SHARES OWNERSHIP LIMITS NON_SHARED
3
(Root(A B)) (1 1) () () ()
4
(A (c d)) (1 1) () (1 1) ()
5
(B (e f)) (1 1) () () ()
6
End ProjectGroup
Copied!
When there is no demand for license tokens, License Scheduler allocates only five tokens according to the distribution. License Scheduler gives three tokens to group A and three tokens to group B, but project c and project d are limited to one token each, so one token is not allocated within group A. As more demand comes in for project e and project f, the tokens that are not allocated are distributed to group B.

Configuring preemption priority within project groups

About this task

The optional PRIORITY parameter in the ProjectGroup section, if defined, is used for preemption instead of basing preemption on the accumulated inuse for each project.

Procedure

Under the heading PRIORITY, set the integer priority for each group member, with ’0’ being the lowest priority.
PRIORITY can be set for all members in the project group hierarchy.

Example

For example:
1
Begin ProjectGroup
2
GROUP SHARES OWNERSHIP LIMITS NON_SHARED PRIORITY
3
(root(A B C)) (1 1 1) () () () (3 2 -)
4
(A (P1 D)) (1 1) () () () (3 5)
5
(B (P4 P5)) (1 1) () () () ()
6
(C (P6 P7 P8)) (1 1 1) () () () (8 3 -)
7
(D (P2 P3)) (1 1) () () () (2 1)
8
End ProjectGroup
Copied!
By default, priority is evaluated from top to bottom. The priority of any specific node is first decided by the priorities of its parent nodes. The values are only comparable between siblings.
The following figure illustrates the example configuration:
img
The priority of each node is shown beside the node name. If priority is not defined, by default is set to 0 (nodes P4 and P5 under node B).
To find the highest priority leaf node in the tree, License Scheduler traverses the tree from root to node A to node D to project P2.
To find the lowest priority leaf node in the tree, License Scheduler traverses the tree from root to node C to project P8.
When two nodes have the same priority, for example, projects P4 and P5, priority is determined by accumulated inuse usage at the time the priorities are evaluated.
When a leaf node in branch A wants to preempt a token from branch B or C, branch C is picked because it has a lower priority than branch B.

Viewing hierarchical configuration

Procedure

Use blinfo -G to view the hierarchical configuration:
For the previous example:
1
blinfo -G
2
GROUP SHARES OWNERSHIP LIMITS NON_SHARED DESCRIPTION
3
(topgrp (g1 g2)) (1 1) () (10 10) () ()
4
(g1 (g3 g4)) (1 1) () (10 10) () ()
5
(g2 (g5 g6)) (1 1) () (- 5) () ()
6
(g3 (p1 p2 p3)) (1 1 2) () (3 4 5) () ()
7
(g4 (p4 p5 p6)) (1 1 1) (1 3 1) () (0 3 0) ()
8
(g5 (p7 p8 p9)) (1 1 1) (2 0 2) () (1 0 1) ()
9
(g6 (p10 p11 p12)) (1 1 1) (2 2 2) (4 4 4) (1 0 1) ()
Copied!

Viewing information about project groups

Procedure

Use blstat -G to view the hierarchical dynamic license information.
1
blstat -G
2
FEATURE: p1_f1
3
SERVICE_DOMAINS:
4
TOTAL_INUSE: 0 TOTAL_RESERVE: 0 TOTAL_FREE: 4 OTHERS: 0
5
SHARE_INFO_FOR: /topgrp
6
GROUP/PROJECT SHARE OWN INUSE RESERVE FREE DEMAND
7
g2 100.0 % 0 0 0 4 0
8
SHARE_INFO_FOR: /topgrp/g2
9
GROUP/PROJECT SHARE OWN INUSE RESERVE FREE DEMAND
10
p3 50.0 % 0 0 0 2 0
11
p4 50.0 % 0 0 0 2 0
12
FEATURE: p1_f2
13
SERVICE_DOMAINS:
14
TOTAL_INUSE: 0 TOTAL_RESERVE: 0 TOTAL_FREE: 4 OTHERS: 0
15
SHARE_INFO_FOR: /topgrp
16
GROUP/PROJECT SHARE OWN INUSE RESERVE FREE DEMAND
17
g2 100.0 % 0 0 0 4 0
18
SHARE_INFO_FOR: /topgrp/g2
19
GROUP/PROJECT SHARE OWN INUSE RESERVE FREE DEMAND
20
p3 50.0 % 0 0 0 2 0
21
p4 50.0 % 0 0 0 2 0
Copied!