目录
基于用户的fairshare与用户群组的关系
之前我们介绍过在集群的队列中配置fairshare策略来增加用户之间对资源使用的相对公平性，这个fairshare是针对用户的，那么如果配置了用户群组，可否直接对群组间的资源使用进行管理呢？
答案是可以，fairshare中既可以对用户设置SHARE基准值，也可以对群组进行设置。如图：
如果在fairshare中配置了群组，fairshare的对比关系会变成树形结构。
所有直接配置在fairshare中的用户或者群组都是第一层节点，他们将根据自身作业数量和CPU使用情况，先进行priority的计算。如果第一层是群组，那么当这个群组得到了priority之后，会再继续对这个群组中的用户进行priority的分配。
例如，在上述队列q1中，用户tadmin1有两个正在运行的作业，tadmin2有一个正在运行的作业。
通过命令bqueues -l，我们可以看到群组ug1里面STARTED的作业数量是3。
因为用户tadmin1和tadmin2都属于ug1， 所以这两个用户对资源的使用的总和就被视为ug1消耗的资源，并且依次反映到ug1得到的fairshare priority数值上。
通过命令bqueues -r，我们可以进一步把ug1展开，看到ug1内部的使用情况。
我们看到，在bqueues -r的命令输出里，除了q1下直接配置的user1和ug1，ug2的fairshare情况，还列出了q1/ug1/的信息，这个就是ug1内部的fairshare情况。
我们看到，在q1/ug1/下，列出了用户tadmin1和 tadmin2，并且列出了tadmin1有两个正在运行的作业，tadmin2有一个，同时，这两个用户的作业所使用的CPU_TIME和RUN_TIME也被列了出来。不难理解，fairshare的调度策略会根据同样的公式为ug1下的用户计算各自的fairshare priority。但是这里tadmin1和tadmin2的SHARES是哪里来的呢？
同一个用户群组内，各个用户之间的share比例
其实和队列里面的fairshare类似，在默认情况下，一个群组内所有用户的SHARES也都是1，但是上面例子中出现了2和1，是因为我在用户群组的设置中配置了USER_SHARES。
打开lsb.users文件，我们可以看到以下配置：
和队列中配置FAIRSHARE的方法类似，我们也是通过方括号的方式来给每个用户指定不同的SHARES，这里也支持用关键字default配置每个用户默认的SHARES。
查看用户群组的命令是bugroup，默认情况下是看不到群组中的USER_SHARES信息的：
但是可以通过bugroup -l，看到USER_SHARES信息：
那么这个群组内的SHARES设置有什么作用呢？
比如，有部门A和部门B都可以向队列1提交作业，为了保证两个部门都能得到对应的资源，我们可以先设置两个用户群组，一个代表部门A，另一个代表部门B。
然后在队列1上，配置FAIRSHARE给群组A和群组B，这样，LSF就会平衡两个群组的作业，不让某一个群组独自占用过多的计算资源。
这时候，如果部门A或者部门B里面，有某个用户正在进行一个紧急的项目，需要比同部门其他成员占用更多的资源，我们就可以在群组内部为这个用户设置一个比其他用户更高的SHARES，这样在部门A和部门B分得的资源不变的情况下，可以保证这个用户比同组内其他用户分得更多的组内资源。
当用户同时隶属多个群组时，如何计算用户所属群组
在一些设置中，有些用户会隶属于多个部门，那么这个用户会同时是多个群组的成员，如果这些群组也同时出现在同一个队列的FAIRSHARE设置中，会出现什么情况呢？
我们将用户tadmin1同时配置在ug1和ug2中。
同时，ug1和ug2都为队列q1的fairshare节点：
用户tadmin1在q1中执行了一个作业：
这个作业只影响了ug1：
我们换一个方式提交作业，再提交作业时，增加-G命令，来指定ug2：
这一次，这个作业还会计算到ug1吗？
我们可以看到，这一次，这个作业被计算到了ug2 中。
也就是说，当一个用户隶属于多个群组时，我们可以通过bsub -G，来指定作业计算到哪个群组，这会是一个比较实用的功能。
总结
通过群组成员间的SHARES，配合队列FAIRSHARE 的USER_SHARES，我们可以制定出很详细的资源分享策略，让不同的部门和成员根据需要按照不同的比例共享集群内的计算资源，避免某些部门或者成员因为作业提交的晚而无法及时获取到对应的资源。
欢迎关注下方微信公众号【HPC常青园】，共同交流HPC集群管理经验和最佳实践。如果您有关于HPC集群的具体需求，欢迎邮件沟通交流：hpc@ivyent.cn。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
