With the Remote Services grouping feature, you can define a subset of the nodes in your cluster as a group, and then submit jobs specifically to that group. This can be quite useful when some nodes in the cluster are different from others. For example, some nodes may have more memory or faster CPUs. Using this feature, you can force jobs to only run on the appropriate type of machines. If all nodes of the requested group are at capacity, jobs will be queued until a member of that group is available.
In order to define a group, you will need to add the GROUP property to the grb_rs.cnf configuration file and give a name to the group:
The groups are static and can only be changed in the node configuration file. If you wish to change the group of a node, you will need to stop the node, edit the configuration file, and restart the node. A node can only be a member of one group.
The grbcluster nodes command displays the assigned group for each node (in the GRP column):
> grbcluster nodes ID ADDRESS STATUS TYPE GRP LICENSE PROCESSING #Q #R JL IDLE %MEM %CPU b7d037db server1:61000 ALIVE COMPUTE group1 VALID ACCEPTING 0 0 10 19m 15.30 5.64 735c595f server2:61000 ALIVE COMPUTE group1 VALID ACCEPTING 0 0 10 19m 10.45 8.01 eb07fe16 server3:61000 ALIVE WORKER group2 VALID ACCEPTING 0 0 1 <1s 11.44 2.33 4f14a532 server4:61000 ALIVE WORKER group2 VALID ACCEPTING 0 0 1 <1s 12.20 5.60
You can submit an optimization job to a given group by using the GROUP property of the client license file (see set up a client license). You can also set the CSGROUP parameter in the programming interface.
The value of this parameter can be a single group to target a subset of nodes as explained. It can also be a list of groups, and you can also specify a priority for each group. Here is an example to submit a job to the group1 nodes with priority 10, and to group2 with priority 50.
Note that if a group is not specified for a submitted job, the job can run on any nodes of any group.