目录
在实际的设计和生产集群中，我们会用到很多需要授权的软件，而对于批量使用的环境，一般采用网络授权的方式，也就是用户统一购买一定数量的授权，保证集群内对应数量的节点可以同时使用相应的软件。
但是随着业务规模的扩展，在繁忙时段往往会出现授权比较紧张的情况。同时，有些软件的授权是区分版本的，新版本软件必须用新版本的授权，而老版本的软件既可以使用老版本授权也可以使用新版本授权，所以用户需要根据作业需要哪种版本的软件来决定申请授权的版本范围。
LSF提供了一款叫做License Scheduler的产品，来帮助管理和调度众多的License许可证，让众多需要相同或不同授权的作业能够得到合理的调度。
目前License Scheduler可以支持Flexlm以及RLM的授权协议。一个License Scheduler可以管理一个或多个LSF集群，将所有License Scheduler中管理的license根据需要调度给这些集群中的作业使用。
License Scheduler如何管理license
License Scheduler目前支持Flexlm和RLM两种授权管理软件。
Flexlm是Globetrotter公司发明的软件加密方法Flexible License Manager；RLM是Reprise软件公司提供的授权管理系统Reprise License Manager。他们都是各大软件厂商广泛使用的授权管理体系，软件厂商通过这些管理协议发放授权，而软件的购买和使用者，也需要通过对应的命令端让每个需要运行软件的节点获得授权，软件才能够正常使用。
如果申请使用软件的节点数量超过了购买的授权协议数量，多出来的节点就无法使用软件了。所以，当集群内有很多节点都有软件使用的需求时，就需要License Scheduler来根据不同集群、项目和部门的重要程度，以及已经获得的授权数量来进行一个合理的授权调度，让多个集群、项目和部门能够合理地分配到软件授权。
License Scheduler通过调用对应license管理系统的命令来获取每种license的总数，和已经使用的数量，以及当前使用者的用户名、终端等详细信息。在License Scheduler中每一种license都是一个对应的feature，用户可以为每个feature定义有哪些project、集群能够使用当前的feature，同时为他们指定不同的配额或者分配比例。
例如图中的feature，在授权管理软件中，这个授权的实际名称是定义在LM_LICENSE_NAME中的，同时，我们可以在Feature的NAME中设定一个便于使用和记忆的名称，这个名称可以用于License Scheduler以及LSF中。
DISTRIBUTION中定义的是如何分配这个license，这一行的内容表示将sd1中的LSAutoFeature_10的license平均分给proj1，proj2和proj3三个project，每个project后面的1表示比例，都是1表示比例相同，如果是（proj1 1 proj2 2 proj3 1）则表示按照1：2：1的比例分配。sd1表示的是license server的端口和服务器名称，在License Scheduler中有专门的配置将每一个license server对应成一个简短的名字，方便配置和查看。例如：
通过blstat命令查看License Scheduler中的详细信息：
每个project后的数值含义：
▪SHARE表示每个project对应的分配比例。因为当前有三个project，分配比例是1：1：1，所以每个都显示33.3%。
▪OWN表示分配了多少可抢占的数量。就是当别的project用了比较多的license数量，而当前project使用的数量少于OWN的数值，则当前project的作业可以通过抢占的方式将其他作业已经占用的license抢回自己手里，这个属性一般用于比较重要的project。这里我们没有配置，所以显示0。
▪INUSE表示已经运行的作业申请了license，并且已经从license server成功获取了license的数量。
▪RESERVE表示作业申请了license，并且得到批准已经运行，但是暂时还没有实际从license server中获取。这个时候，单纯从license server获取时，不会看到这个作业需要的license，但是License Scheduler会为这个作业保留，不让其他作业使用，保证这个作业从license server获取license时不会失败。
▪FREE表示分配给该project多少可用的license。
▪DEMAND表示当前project有需要license的作业正在排队，DEMAND中的数值就是这个project中所有等待运行的作业所请求的license数量之和。
通过blstat -c命令，还可以看到这个feature分配到每个集群的信息：
同时，每一个License Scheduler中的feature，都会在LSF中对应成一个resource。
这里显示的TOTAL表示当前可以使用的license数量之和，注意这里是分给当前集群的所有project的可用数量的总和，而RESERVED表示当前集群中正在运行的作业所占用的license数量，也是所有project的数量之和。
如何在LSF作业中向License Scheduler申请license的使用
如果要提交一个需要license的LSF作业，可以通过bsub -R指定对应license feature的resource，用-Lp指定想要提交到哪一个License Project中去：
作业<2313>运行之后，可以通过blstat命令查看License Scheduler中对应feature的使用情况：
因为这个作业申请了1个license，并且也确实从license server获取了对应数量的license，所以显示INUSE为1，相应的FREE数量就减少了1。
同时，bhosts -s也会显示对应的信息：
License Scheduler中还提供了blusers命令，来查看更加详细的license使用情况信息：
blusers可以显示出每一个作业从哪些license server，获取了多少license，以及对应的project、集群、开始时间和LSF中作业的rusage信息。
License Scheduler中的基础调度
如果license server上只剩下少量license可用，但是两个作业同时申请了license，或者有些作业申请了license但并没有第一时间从license server中获取，在没有License Scheduler的调度时，就会导致license的争抢，从而导致一些作业失败或者影响作业效率。
License Scheduler可以通过reserve的方式更好地调度license。
例如当前的license server中，只剩下两个license：
这时，我们提交一个需要一个license的作业<2322>，但是不去license server上获取license：
虽然我们看到proj1上的FREE已经是0了，但是因为其他project上并没有作业申请使用license，所以当我们继续向proj提交license作业时，License Scheduler会尝试把分给其他project的license先调配给proj1中使用。
我们看到，如果作业没有实际从license server获取license，License Scheduler会按照作业申请的license数量，标记对应数量的license为RESERVE，并且把FREE做相应减少，防止其他作业争抢这个已经分配出去的license。
如果这时候我们再提交2个需要license的作业<2323>、<2324>，会看到只有一个作业<2323>可以运行，另一个<2324>则因为没有free的license而等待，直到有license被释放出来才能运行。
这时，我们通过blstat命令，可以看到当前的FREE是0，因为作业<2324>还在等待license，所以，proj2上显示DEMAND为1，表示这个project上还有作业需要1个license，如果这时候有license被其他作业释放出来，License Scheduler就会从多出来的FREE中调配一个license到proj2中给等待的作业使用。
License Scheduler的独立使用模式
一个License Server可以同时管理一个或多个LSF集群，同时，License Scheduler还提供了一种独立使用模式，可以独立于LSF使用。
这种模式下，通过一个叫做taskman的命令来提交需要license的作业，这些作业只需要通过License Scheduler为其调度license，一旦拿到license，就可以直接运行了， LSF中是看不到这类作业的。
通过命令bltasks可以看到等待或正在运行的taskman作业，同时，blstat也可以正常显示被这类作业所使用的license信息。
命令blstat可以显示出该作业所使用的license信息，我们在blstat -c中看到，这种taskman作业所对应的集群称为interactive，这是一个特殊的内置名称。
通过命令blusers也可以看到相应信息。
想要提前删除taskman作业，可以使用blkill命令，blkill默认会在提交命令60秒以后强制结束对应taskman作业，如果想立刻结束可以指定参数-t 0：
为作业指定多种license需求
在实际的使用中，有时候同一个作业会需要多种不同的license，我们可以通过“：”或“，”在提交作业时指定多种license 。
在这种情况下，只有当License Scheduler为所有指定的license都分配了满足需求的license数量，作业才会运行，运行后bhosts -s命令可以查看相应license feature的使用情况。
另外一种情况是，有些软件的license是分为不同版本，或者是部署在多个license server上的。对于这种情况，如果所有的作业都可以使用任意版本或者任意一个license server，那么可以在License Scheduler中将这些license合并定义成一个feature，方便使用。但是如果是有些作业可以使用所有的版本或license server，而另一些作业只能使用部分版本，或者只能从部分license server上获取license时，就只能单独定义成不同feature。在提交可以使用多种版本或多个license server的feature时，可以使用“||”将多个feature隔开，达到“或”的作用，只要License Scheduler能满足某一个feature的需求，这个作业就可以运行。
我们看到，ls01已经没有FREE的license，ls02还有，我们提交一个作业<2327>：
作业<2327>运行起来以后，我们通过bjobs -l可以看到，作业实际是通过ls02=1运行起来的，所以，在License Scheduler中，也只会为这个作业在ls02上减掉对应的free，而不会影响ls01。
License Scheduler中的基础调度
根据不同的场景和应用需求，License Scheduler提供了3种模式：
1、Project mode
这个模式是最早提供的，所以很多用户一直在使用这个模式，这相当于是一个基础模式，可以为每种不同的license指定多种License project，并且为这些License project设置不同的优先级和策略。
这是最早出现的一种模式，所以正在使用的客户最多。
缺点是每个集群的每个作业申请的license都要经过License Scheduler的调度，因此效率和license的利用率比较低。
2、Cluster mode
这个模式是专门为以下客户准备的：非常关注作业的吞吐量，只关心各个集群之间如何分享license，而并不会在集群内部再设置更复杂的调度策略。
这种模式的优势是调度非常快，License Scheduler会根据需要为每个集群分配一定数量的license，而每个集群内的作业只要需求的license总数不超过这个分配的数量，就完全由各自集群内的管理节点进行调度，license的利用率在三种模式中是最高的。
缺点是无法满足用户想在每个集群内还实现多个不同部门之间的license的调度和管理的需求。
3、Fast-dispatch mode
作为最新的mode，结合了Project mode和Cluster mode的特点，既继承了project mode绝大部分的核心调度功能，又兼具了cluster mode对性能和效率的考虑。
在配置License Scheduler的时候可以指定一个全局的默认模式，这样，所有feature都默认是这个模式，同时，也可以为每一个feature设置独立的模式，可以不同于其他feature存在。
尾声
以上就是对License Scheduler的基础功能的一个简单介绍，除了这些基本功能，License Scheduler还提供了很多调度和管理的功能，应对各种不同情况和需求，我们以后有机会再慢慢探索。
欢迎关注下方微信公众号【HPC常青园】，共同交流HPC集群管理经验和最佳实践。如果您有关于HPC集群的具体需求，欢迎邮件沟通交流：hpc@ivyent.cn。
184
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
