并行计算机中基于令牌的许可证管理

2014-09-15曹宏嘉卢宇彤

计算机工程与科学 2014年3期

关键词：令牌许可证进程

曹宏嘉,卢宇彤,2

(1.国防科学技术大学计算机学院，湖南长沙 410073;2.国防科学技术大学高性能计算国家重点实验室，湖南长沙 410073)

并行计算机中基于令牌的许可证管理

曹宏嘉1,卢宇彤1,2

(1.国防科学技术大学计算机学院，湖南长沙 410073;2.国防科学技术大学高性能计算国家重点实验室，湖南长沙 410073)

提出一种适用于并行计算机系统的基于令牌的许可证管理模型。该模型将软件许可证的使用显式分开为申请与检出两步，许可证的释放分开为检入和回收两步，并由资源管理系统代理软件进行许可证资源的申请和回收。在此模型中，软件许可证的使用将由资源管理系统完全控制与调度，避免了现有模型中存在的资源管理系统外作业使用许可证、作业错误指定许可证信息、应用进程残留等情景下，出现用户作业因许可证不可用而造成的运行失败或资源浪费。设计了两种在现存遗留应用软件和许可证管理软件上实现基于令牌的许可证管理模型的方法，充分表明了此模型的现实意义。

资源管理;作业调度;许可证管理;令牌

1 引言

现在的并行计算机一般使用资源管理系统RMS(Resource Management System)对系统中的各种资源进行管理调度，分配给作业使用。在CAD、CAE等应用领域，大部分第三方软件都通过许可证机制进行产权保护，控制软件可以运行的节点位置与/或可同时运行的软件副本数量。当许可证不可用时，应用软件将报错退出，或占用计算资源等待。在并行计算机的多用户、多道作业环境下，许可证作为一种昂贵的软件资源需要RMS调度作业时予以管理和调度分配，以避免在不合适的计算节点或时机加载作业运行，导致作业由于许可证不足而运行失败或系统资源利用率低下。

由于现存的许可证管理软件LM(License Manager)在设计时未能考虑到应用软件以作业的形式通过资源管理系统运行， LM都未能提供与RMS交互的接口。现在的RMS和LM大多使用一种通过RMS向LM轮询可用许可证计数的方法，试图保持RMS和LM的许可证可用计数的一致性。然而，由于应用场景的复杂性，以及作业加载时间与软件实际使用许可证的时间之间存在间隔，这种方法中存在竞争条件，并不能完全避免作业运行失败的情况。

本文提出一种基于令牌的许可证资源管理模型。通过将应用软件对许可证的使用分开为许可证资源分配和许可证检出两步，并允许RMS代理应用软件进行许可证分配，此模型能够有效解决并行计算机系统中RMS与LM共同进行许可证资源管理的协同问题。模型的关键在于软件在检出许可证时需要以所分配的许可证令牌为凭证。文章给出了在现有遗留软件与LM上实现基于令牌的许可证管理模型的两种可行机制，表明此模型具有重要的现实意义。

2 许可证管理与资源调度

2.1 并行计算机系统资源调度

随着并行计算技术的发展，高性能计算机越来越普及，并行系统的规模越来越大，应用场景也越来越复杂。为了有效管理并行计算机系统中海量的计算、通信、I/O等资源，协调多用户、多作业对资源的访问，当前的并行计算机系统一般都通过资源管理系统进行作业调度与资源分配。资源管理系统负责监控系统中各种资源的状态与可用情况，并为用户作业选择合适的资源，调度其运行。一般而言，在一个并行系统中资源管理系统是用户使用和管理员管理资源的入口，系统限制不经过RMS的资源使用，以维持系统状态的一致性，避免资源冲突带来的作业性能下降。

一般的资源管理系统在为作业分配资源时仅考虑到作业的处理器、内存、磁盘空间等资源需求，某些系统会考虑节点负载、I/O及通信带宽等。对于需要使用软件许可证的第三方软件，RMS在为用户作业分配资源时就必须考虑其对许可证的需求，避免出现给用户作业分配许可证不可用的节点，或者是调度作业运行时许可证数目不足，导致作业无法运行。而且，软件许可证是一种昂贵的资源，其使用效率严重影响用户的计算体验。

2.2 软件许可证管理

目前最常用的许可证管理软件是FlexNet Publisher(FNP)，它是FlexLM的升级[1]。典型的由FNP控制的许可证使用场景与部署如图1所示。

Figure 1 License management with FNP图1 FNP的许可证管理

FNP Manager Daemon是许可证管理器守护进程，负责与应用程序进行初始联系，并连接到适当的软件供应商守护进程。许可证管理器守护进程还负责供应商守护进程的启动。Vendor Daemon是供应商守护进程，负责监视软件许可证的使用。许可证文件中记录了所授权的软件许可证及其数目，可由管理员编辑。供应商守护进程可以有自己的配置文件。FNP管理服务还会生成许可证使用的一些日志用于调试或报表生成。

应用软件链接到FNP客户端代码，通过TCP/IP与FNP管理服务进行交互。应用软件请求检出(check-out)指定数目的许可证时，管理服务根据许可证文件配置和当前许可证使用情况，许可或拒绝软件对许可证的使用。根据软件设计不同，在许可证使用被拒绝时，软件可能报错退出，或者占用计算资源等待。应用软件运行完毕或使用许可证完毕后，将所使用的许可证检入(check-in)，以供其它软件后续使用。

FNP控制的许可证分为节点锁定许可证和浮点许可证。节点锁定许可证不限制使用数目，但仅在特定节点上可用。作业请求节点锁定的许可证相当于请求只能从一组特定节点中分配资源，目前的RMS均能处理这种需求。浮动许可证不限制使用许可证的位置，但限制最多同时并发使用许可证的数目。并行作业的许可证资源冲突主要由浮动许可证引起。下文的许可证管理即指浮动许可证的管理。

除FNP外，常用的LM还包括RLM[2]、Sentinel RMS[3]等；其工作原理和存在的问题与FNP类似。

2.3 问题与挑战

大部分的 LM 都是商业软件,并不提供开放接口进行许可证的控制。例如，FNP中仅提供了一个命令行工具lmutil进行许可证状态查询和简单控制功能。这给LM和RMS的结合带来了很大困难。而且，对软件许可证的使用不是由LM完全控制，而是涉及多种多样的应用软件。目前的RMS系统不能完全与LM协调，控制对软件许可证的使用与分配。例如，在当前版本的SLURM(Simple Linux Utility for Resource Management)[4]系统中，仅在RMS内部对许可证的使用进行简单计数，而没有与LM进行交互。在LSF(Load Sharing Facility)[5]系统中，通过定期查询LM中的许可证使用情况，以将软件对许可证的使用反映到RMS中，作为作业调度决策依据。

不与LM进行交互，或者仅查询LM中可用的许可证数目，而不进行访问控制，很容易出现RMS中可用的许可证计数与LM中实际可用的计数不一致的情况。常见的原因[6]包括：

(1)用户不分配资源，直接运行应用程序并占用许可证。由于RMS不能感知应用程序对许可证的使用情况，这将导致RMS计数少于实际可用数目，提前调度作业运行，导致作业运行失败。

(2)用户作业实际使用许可证数目与申请分配的数目不一致。用户提交作业时可能(无意或有意)指定错误的许可证数目。指定过多的许可证却不使用将导致昂贵的许可证资源浪费；指定过少的许可证但实际检出更多的许可证会导致RMS中的可用计数少于LM中实际可用许可证计数，导致提前调度作业运行并失败。

(3)残留用户进程占用许可证。在系统故障等条件下，可能出现作业运行结束，但应用软件的进程仍残留在计算节点上的情况。这种情况下，进程将仍占用宝贵的许可证资源，造成系统效率低下。在理想情况下，作业结束后应强制其释放分配的全部资源，包括程序检出的许可证资源。这样，即使有进程残留，其检出的许可证也因失效而被回收。

(4)资源管理系统调度作业运行与应用软件实际检出许可证之间存在时间差。用户的作业可能需要前处理等耗时操作，或者复杂软件需要多种许可证，分别在不同时间段检出。即便将轮询LM与调度作业运行的时间间隔缩得再小，也不能避免因此时间差导致的LM中实际可用许可证数目发生变化。

由于目前的许可证管理软件在设计时未能考虑资源管理系统的存在和需求，现存的RMS和LM交互困难，给并行系统的运行效率带来负面效应，导致用户体验下降。并行系统中需要一种新的模型来适应具有RMS的作业运行环境。

3 基于令牌的许可证管理模型

为解决查询许可证数量与使用许可证的时间差产生竞争条件问题，本节提出一个适用于并行计算机系统的基于令牌的许可证管理模型(简称令牌模型)。其核心思想是将许可证的分配与使用分开，并且许可证的分配由RMS代理应用软件进行，从而容许通过RMS对许可证资源进行完全控制与调度。

3.1 令牌模型

基于令牌的许可证管理模型如图2所示。在此模型中， LM负责对许可证使用的控制，而RMS负责许可证的调度分配。

Figure 2 Token-based license management model图2 基于令牌的许可证管理模型

在令牌模型中，应用软件对许可证的使用被显式地分成两步：许可证资源分配与许可证检出。其中，许可证资源分配可以由RMS代替应用软件进行。典型的作业运行并使用许可证的流程如下：

(1)用户提交作业到RMS，注明作业的许可证资源需求；

(2)RMS在调度作业时，判断许可证资源的可用性，并向LM申请使用许可证；

(3)LM向RMS返回一个令牌(token)，用于标识所申请的许可证资源；

(4)RMS加载作业运行时，将令牌传递给应用软件进程；

(5)应用软件凭令牌从LM检出许可证使用。

许可证的释放也显式地分为两步。应用进程退出前或使用许可证结束后，向LM检入所使用的许可证；作业运行结束时RMS通知LM，LM使该令牌失效并强制回收许可证。这样即使应用进程残留，也不能继续占用相应的许可证。

3.2 RMS与LM交互接口

在令牌模型中，RMS与LM交互的主要接口包括：

(1)get_feature_count：获取指定许可证特性的可用数目。

(2)allocate_feature：分配指定数目的许可证特性，如果分配成功，将返回一个令牌。

(3)return_feature：回收指定令牌对应的许可证特性。

引入get_feature_count接口的目的是便于RMS向LM查询当前可用许可证数目。由于RMS进行作业调度时需要多次判断作业的许可证资源是否可用，一个低开销的查询接口可以避免因调用分配许可证接口引入的较大开销而造成调度性能低下。

4 令牌模型的实现方法

在一个新的LM中实现令牌模型及与RMS的交互接口很直接。但现实中存在大量的遗留应用软件，它们所采用的许可证管理方式并不是基于令牌模型设计的。一个好的许可证管理模型需要充分考虑现存遗留软件，支持现有的LM尤其是FNP，才具有现实可行性。本节探讨在现有广泛使用的许可证管理软件上实现令牌管理模型的方法。从第3节的介绍可知，实现的关键在于限制许可证的非分配使用。

4.1 基于预留的机制

FNP支持对软件许可证进行预留[7]，通过修改许可证文件以及第三方软件供应商配置文件，可以将指定数量的许可证特性预留给指定的用户、用户组、主机或者项目。基于此可以实现上述的令牌模型。在此实现方式中，作业、RMS及LM的交互流程如下：

(1)在FNP许可配置文件中，为供应商守护进程设置配置文件。

(2)RMS初始化时，通过修改供应商配置文件，预留全部许可证给root用户以及项目RMS。将许可证全部预留给root用户实际上实现了对非分配许可证使用的限制。

(3)get_feature_count接口：lmutil命令的包装，通过解析lmutil命令的输出获得可用许可证数目。

(4)allocate_feature接口：编辑供应商配置文件，将所请求数目的许可证从预留给root用户和项目RMS转为预留给提交作业的用户和项目RMS_JOB_jobid，其中jobid为作业在RMS中的标识；然后指示FNP管理守护进程重读配置文件。

(5)RMS加载作业运行时，为应用程序设置环境变量LM_PROJECT=RMS_JOB_jobid，以指示应用软件以该项目使用许可证。

(6)return_feature接口:编辑供应商配置文件，将为作业用户和项目所预留的许可证转为为root用户和项目RMS预留；然后指示FNP管理守护进程重读配置文件。

在此实现机制中，许可证令牌即是作业的用户身份以及FNP项目RMS_JOB_jobid。虽然项目名字未加密，但由于FNP会限制检出许可证的用户，因此其它用户无法通过伪造项目名字而窃取使用许可证。此机制的另一个问题是，需要避免其它用户或软件对供应商配置文件的编辑，以免引发冲突和竞争。由于管理员可以限制只有root用户才能编辑供应商配置文件，这种冲突可以通过协调管理员的行为避免。

4.2 基于代理的机制

并非所有的LM均支持对许可证的预留。本文设计的另一种在遗留应用和LM上实现令牌模型的方法是，通过控制应用软件与LM之间的通信来控制对许可证的使用。在此机制中设计了两个代理软件：LM Proxy和App Proxy，来完成对应用软件与LM之间通信的控制。此实现机制如图3所示。

Figure 3 Implementation mechanism based on proxy图3 基于代理的实现机制

在基于代理的实现机制中，RMS不与LM直接进行交互，而是通过LM Proxy和App Proxy完成对许可证资源的使用控制。实现要点如下：

(1)所有应用软件与LM的通信都必须经过LM Proxy的许可才能进行。这可以通过控制LM所运行的节点上的防火墙规则，或者由LM Proxy转发所有到LM的通信报文来完成。

(2)许可证的分配与调度在RMS内部进行。RMS生成一个加密串作为许可证令牌。在分配或释放许可证资源之后，RMS将分配或释放信息传递给LM Proxy。

(3)在加载应用进程运行时，RMS将为作业分配的许可证令牌传递给App Proxy。App Proxy与应用进程运行在相同的计算节点上；对于并行应用软件，如有必要可以在运行应用软件进程的每个节点上都运行相应的App Proxy。

(4)当应用进程需要检出许可证时，其与LM的通信连接将被App Proxy截获,这可以通过对应用程序外挂钩子函数实现。App Proxy将首先与LM Proxy进行通信，发送应用软件需要使用的许可证信息，包括所需特性及数量，以及相应的令牌。LM Proxy根据许可证分配信息以及App Proxy发送的信息，决定是否允许应用进程与LM之间的通信。

(5)许可证资源被RMS回收之后，相关信息被传递到LM Proxy，对应的许可证令牌不再有效，且原有应用进程与LM的通信被切断，以避免残留应用进程对许可证资源的占用。

在此实现机制中，关键的挑战是App Proxy能够获得应用软件要使用的许可证特性以及数量。由于应用软件与LM的通信都是加密的，从其通信报文中解析出相关信息是不现实的。一般而言，应用软件的行为可以从其运行参数、输入条件等确定。因此，可以在软件运行时记录LM端的日志并进行分析，获得应用软件对许可证的使用规律，形成一种规则库。App Proxy可以结合作业并行规模等RMS所提供的作业信息，结合此规则库，确定作业对许可证的需求信息。

5 结束语

软件许可证作为一种昂贵的资源需要进行合理的调度管理以提高资源利用率。本文提出的基于令牌的许可证管理模型可以有效地解决现在的许可证管理软件与并行计算机资源管理系统的结合问题，避免因许可证资源分配与应用软件实际检出之间的时间差产生的竞争条件导致作业运行失败问题，提升并行计算机系统的用户使用体验和资源利用率。下一步将对不同种类资源的调度分配次序以及不同的调度策略对系统性能的影响展开研究。

[1] Flexera Software.FlexNet licensing[EB/OL].[2013-09-25].http://www.flexerasoftware.com/products/entitlement-management/flexnet-licensing/.

[2] Reprise software[EB/OL].[2013-09-25].http://www.reprisesoftware.com/index.php.

[3] Safenet Inc. Sentinel RMS[EB/OL].[2013-09-25].http://www.safenet-inc.com/software-monetization/sentinel-rms/.

[4] Yoo A, Jette M, Grondona M. SLURM:Simple Linux utility for resource management[C]∥Proc of JSSPP’03, 2003:44-60.

[5] Platform. Managing software licenses with LSF[EB/OL].[2013-09-25].http://www.ccs.miami.edu/hpc/lsf/7.0.6/admin/licensemgt.html.

[6] Brophy B. SLURM license management[EB/OL].[2013-09-25].http://SLURM User Group Meeting.

[7] Acresso Software. FLEXnet publisher licensing toolkit 11.7:License administration guide[M]. US:Acresso Software Inc,2009.

CAO Hong-jia,born in 1977,PhD,associate research fellow,his research interests include resource management, and system software.

卢宇彤(1969-),女,湖南长沙人，博士，教授，博士生导师，CCF会员(E200034926M)，研究方向为高性能计算，容错计算，系统软件。E-mail:ytlu@nudt.edu.cn

CAO Hong-jia,born in 1969,PhD,professor,PhD supervisor,CCF member(E200034926M)，her research interests include high performance computing，fault tolerant computing, and system software.

Token-based license management in parallel computer systems

CAO Hong-jia1,LU Yu-tong1,2
(1.College of Computer,National University of Defense Technology，Changsha 410073;2.State Key Laboratory of High Performance Computing,National University of Defense Technology，Changsha 410073,China)

A token-based license management model is proposed for parallel computer systems. In this model, license using is separated into two steps: license allocation and license check-out, namely. Accordingly license release is separated into check-in and return. License allocation and return may be performed by the resource management system for the application software. Under this model, the use of licenses is controlled by the resource management system totally, avoiding conditions such as license check-out out of resource management system, wrong number of licenses specified for jobs, and application process hang, which results in job failures and resource wasting. Two implementation mechanisms mapping this token-based model to currently popular application environment are designed for legacy applications and license managers, which show the feasibility and significance of the model.

resource management;job scheduling;license management;token

2013-10-05;

2013-12-15

国家自然科学基金资助项目(61120106005)；国家863计划资助项目(2012AA01A301)

1007-130X(2014)03-0388-05

TP311

10.3969/j.issn.1007-130X.2014.03.002