曹宏嘉,盧宇彤,2

(1.國防科學技術大學計算機學院，湖南 長沙 410073;2.國防科學技術大學高性能計算國家重點實驗室，湖南 長沙 410073)

并行計算機中基于令牌的許可證管理

曹宏嘉1,盧宇彤1,2

(1.國防科學技術大學計算機學院，湖南 長沙 410073;2.國防科學技術大學高性能計算國家重點實驗室，湖南 長沙 410073)

提出一種適用于并行計算機系統(tǒng)的基于令牌的許可證管理模型。該模型將軟件許可證的使用顯式分開為申請與檢出兩步，許可證的釋放分開為檢入和回收兩步，并由資源管理系統(tǒng)代理軟件進行許可證資源的申請和回收。在此模型中，軟件許可證的使用將由資源管理系統(tǒng)完全控制與調度，避免了現(xiàn)有模型中存在的資源管理系統(tǒng)外作業(yè)使用許可證、作業(yè)錯誤指定許可證信息、應用進程殘留等情景下，出現(xiàn)用戶作業(yè)因許可證不可用而造成的運行失敗或資源浪費。設計了兩種在現(xiàn)存遺留應用軟件和許可證管理軟件上實現(xiàn)基于令牌的許可證管理模型的方法，充分表明了此模型的現(xiàn)實意義。

資源管理;作業(yè)調度;許可證管理;令牌

1 引言

現(xiàn)在的并行計算機一般使用資源管理系統(tǒng)RMS(Resource Management System)對系統(tǒng)中的各種資源進行管理調度，分配給作業(yè)使用。在CAD、CAE等應用領域，大部分第三方軟件都通過許可證機制進行產權保護，控制軟件可以運行的節(jié)點位置與/或可同時運行的軟件副本數(shù)量。當許可證不可用時，應用軟件將報錯退出，或占用計算資源等待。在并行計算機的多用戶、多道作業(yè)環(huán)境下，許可證作為一種昂貴的軟件資源需要RMS調度作業(yè)時予以管理和調度分配，以避免在不合適的計算節(jié)點或時機加載作業(yè)運行，導致作業(yè)由于許可證不足而運行失敗或系統(tǒng)資源利用率低下。

由于現(xiàn)存的許可證管理軟件LM(License Manager)在設計時未能考慮到應用軟件以作業(yè)的形式通過資源管理系統(tǒng)運行， LM都未能提供與RMS交互的接口。現(xiàn)在的RMS和LM大多使用一種通過RMS向LM輪詢可用許可證計數(shù)的方法，試圖保持RMS和LM的許可證可用計數(shù)的一致性。然而，由于應用場景的復雜性，以及作業(yè)加載時間與軟件實際使用許可證的時間之間存在間隔，這種方法中存在競爭條件，并不能完全避免作業(yè)運行失敗的情況。

本文提出一種基于令牌的許可證資源管理模型。通過將應用軟件對許可證的使用分開為許可證資源分配和許可證檢出兩步，并允許RMS代理應用軟件進行許可證分配，此模型能夠有效解決并行計算機系統(tǒng)中RMS與LM共同進行許可證資源管理的協(xié)同問題。模型的關鍵在于軟件在檢出許可證時需要以所分配的許可證令牌為憑證。文章給出了在現(xiàn)有遺留軟件與LM上實現(xiàn)基于令牌的許可證管理模型的兩種可行機制，表明此模型具有重要的現(xiàn)實意義。

2 許可證管理與資源調度

2.1 并行計算機系統(tǒng)資源調度

隨著并行計算技術的發(fā)展，高性能計算機越來越普及，并行系統(tǒng)的規(guī)模越來越大，應用場景也越來越復雜。為了有效管理并行計算機系統(tǒng)中海量的計算、通信、I/O等資源，協(xié)調多用戶、多作業(yè)對資源的訪問，當前的并行計算機系統(tǒng)一般都通過資源管理系統(tǒng)進行作業(yè)調度與資源分配。資源管理系統(tǒng)負責監(jiān)控系統(tǒng)中各種資源的狀態(tài)與可用情況，并為用戶作業(yè)選擇合適的資源，調度其運行。一般而言，在一個并行系統(tǒng)中資源管理系統(tǒng)是用戶使用和管理員管理資源的入口，系統(tǒng)限制不經過RMS的資源使用，以維持系統(tǒng)狀態(tài)的一致性，避免資源沖突帶來的作業(yè)性能下降。

一般的資源管理系統(tǒng)在為作業(yè)分配資源時僅考慮到作業(yè)的處理器、內存、磁盤空間等資源需求，某些系統(tǒng)會考慮節(jié)點負載、I/O及通信帶寬等。對于需要使用軟件許可證的第三方軟件，RMS在為用戶作業(yè)分配資源時就必須考慮其對許可證的需求，避免出現(xiàn)給用戶作業(yè)分配許可證不可用的節(jié)點，或者是調度作業(yè)運行時許可證數(shù)目不足，導致作業(yè)無法運行。而且，軟件許可證是一種昂貴的資源，其使用效率嚴重影響用戶的計算體驗。

2.2 軟件許可證管理

目前最常用的許可證管理軟件是FlexNet Publisher(FNP)，它是FlexLM的升級[1]。典型的由FNP控制的許可證使用場景與部署如圖1所示。

Figure 1 License management with FNP圖1 FNP的許可證管理

FNP Manager Daemon是許可證管理器守護進程，負責與應用程序進行初始聯(lián)系，并連接到適當?shù)能浖淌刈o進程。許可證管理器守護進程還負責供應商守護進程的啟動。Vendor Daemon是供應商守護進程，負責監(jiān)視軟件許可證的使用。許可證文件中記錄了所授權的軟件許可證及其數(shù)目，可由管理員編輯。供應商守護進程可以有自己的配置文件。FNP管理服務還會生成許可證使用的一些日志用于調試或報表生成。

應用軟件鏈接到FNP客戶端代碼，通過TCP/IP與FNP管理服務進行交互。應用軟件請求檢出(check-out)指定數(shù)目的許可證時，管理服務根據(jù)許可證文件配置和當前許可證使用情況，許可或拒絕軟件對許可證的使用。根據(jù)軟件設計不同，在許可證使用被拒絕時，軟件可能報錯退出，或者占用計算資源等待。應用軟件運行完畢或使用許可證完畢后，將所使用的許可證檢入(check-in)，以供其它軟件后續(xù)使用。

FNP控制的許可證分為節(jié)點鎖定許可證和浮點許可證。節(jié)點鎖定許可證不限制使用數(shù)目，但僅在特定節(jié)點上可用。作業(yè)請求節(jié)點鎖定的許可證相當于請求只能從一組特定節(jié)點中分配資源，目前的RMS均能處理這種需求。浮動許可證不限制使用許可證的位置，但限制最多同時并發(fā)使用許可證的數(shù)目。并行作業(yè)的許可證資源沖突主要由浮動許可證引起。下文的許可證管理即指浮動許可證的管理。

除FNP外，常用的LM還包括RLM[2]、Sentinel RMS[3]等；其工作原理和存在的問題與FNP類似。

2.3 問題與挑戰(zhàn)

大部分的 LM 都是商業(yè)軟件,并不提供開放接口進行許可證的控制。例如，F(xiàn)NP中僅提供了一個命令行工具lmutil進行許可證狀態(tài)查詢和簡單控制功能。這給LM和RMS的結合帶來了很大困難。而且，對軟件許可證的使用不是由LM完全控制，而是涉及多種多樣的應用軟件。目前的RMS系統(tǒng)不能完全與LM協(xié)調，控制對軟件許可證的使用與分配。例如，在當前版本的SLURM(Simple Linux Utility for Resource Management)[4]系統(tǒng)中，僅在RMS內部對許可證的使用進行簡單計數(shù)，而沒有與LM進行交互。在LSF(Load Sharing Facility)[5]系統(tǒng)中，通過定期查詢LM中的許可證使用情況，以將軟件對許可證的使用反映到RMS中，作為作業(yè)調度決策依據(jù)。

不與LM進行交互，或者僅查詢LM中可用的許可證數(shù)目，而不進行訪問控制，很容易出現(xiàn)RMS中可用的許可證計數(shù)與LM中實際可用的計數(shù)不一致的情況。常見的原因[6]包括：

(1)用戶不分配資源，直接運行應用程序并占用許可證。由于RMS不能感知應用程序對許可證的使用情況，這將導致RMS計數(shù)少于實際可用數(shù)目，提前調度作業(yè)運行，導致作業(yè)運行失敗。

(2)用戶作業(yè)實際使用許可證數(shù)目與申請分配的數(shù)目不一致。用戶提交作業(yè)時可能(無意或有意)指定錯誤的許可證數(shù)目。指定過多的許可證卻不使用將導致昂貴的許可證資源浪費；指定過少的許可證但實際檢出更多的許可證會導致RMS中的可用計數(shù)少于LM中實際可用許可證計數(shù)，導致提前調度作業(yè)運行并失敗。

(3)殘留用戶進程占用許可證。在系統(tǒng)故障等條件下，可能出現(xiàn)作業(yè)運行結束，但應用軟件的進程仍殘留在計算節(jié)點上的情況。這種情況下，進程將仍占用寶貴的許可證資源，造成系統(tǒng)效率低下。在理想情況下，作業(yè)結束后應強制其釋放分配的全部資源，包括程序檢出的許可證資源。這樣，即使有進程殘留，其檢出的許可證也因失效而被回收。

(4)資源管理系統(tǒng)調度作業(yè)運行與應用軟件實際檢出許可證之間存在時間差。用戶的作業(yè)可能需要前處理等耗時操作，或者復雜軟件需要多種許可證，分別在不同時間段檢出。即便將輪詢LM與調度作業(yè)運行的時間間隔縮得再小，也不能避免因此時間差導致的LM中實際可用許可證數(shù)目發(fā)生變化。

由于目前的許可證管理軟件在設計時未能考慮資源管理系統(tǒng)的存在和需求，現(xiàn)存的RMS和LM交互困難，給并行系統(tǒng)的運行效率帶來負面效應，導致用戶體驗下降。并行系統(tǒng)中需要一種新的模型來適應具有RMS的作業(yè)運行環(huán)境。

3 基于令牌的許可證管理模型

為解決查詢許可證數(shù)量與使用許可證的時間差產生競爭條件問題，本節(jié)提出一個適用于并行計算機系統(tǒng)的基于令牌的許可證管理模型(簡稱令牌模型)。其核心思想是將許可證的分配與使用分開，并且許可證的分配由RMS代理應用軟件進行，從而容許通過RMS對許可證資源進行完全控制與調度。

3.1 令牌模型

基于令牌的許可證管理模型如圖2所示。在此模型中， LM負責對許可證使用的控制，而RMS負責許可證的調度分配。

Figure 2 Token-based license management model圖2 基于令牌的許可證管理模型

在令牌模型中，應用軟件對許可證的使用被顯式地分成兩步：許可證資源分配與許可證檢出。其中，許可證資源分配可以由RMS代替應用軟件進行。典型的作業(yè)運行并使用許可證的流程如下：

(1)用戶提交作業(yè)到RMS，注明作業(yè)的許可證資源需求；

(2)RMS在調度作業(yè)時，判斷許可證資源的可用性，并向LM申請使用許可證；

(3)LM向RMS返回一個令牌(token)，用于標識所申請的許可證資源；

(4)RMS加載作業(yè)運行時，將令牌傳遞給應用軟件進程；

(5)應用軟件憑令牌從LM檢出許可證使用。

許可證的釋放也顯式地分為兩步。應用進程退出前或使用許可證結束后，向LM檢入所使用的許可證；作業(yè)運行結束時RMS通知LM，LM使該令牌失效并強制回收許可證。這樣即使應用進程殘留，也不能繼續(xù)占用相應的許可證。

3.2 RMS與LM交互接口

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

(1)get_feature_count：獲取指定許可證特性的可用數(shù)目。

(2)allocate_feature：分配指定數(shù)目的許可證特性，如果分配成功，將返回一個令牌。

(3)return_feature：回收指定令牌對應的許可證特性。

引入get_feature_count接口的目的是便于RMS向LM查詢當前可用許可證數(shù)目。由于RMS進行作業(yè)調度時需要多次判斷作業(yè)的許可證資源是否可用，一個低開銷的查詢接口可以避免因調用分配許可證接口引入的較大開銷而造成調度性能低下。

4 令牌模型的實現(xiàn)方法

在一個新的LM中實現(xiàn)令牌模型及與RMS的交互接口很直接。但現(xiàn)實中存在大量的遺留應用軟件，它們所采用的許可證管理方式并不是基于令牌模型設計的。一個好的許可證管理模型需要充分考慮現(xiàn)存遺留軟件，支持現(xiàn)有的LM尤其是FNP，才具有現(xiàn)實可行性。本節(jié)探討在現(xiàn)有廣泛使用的許可證管理軟件上實現(xiàn)令牌管理模型的方法。從第3節(jié)的介紹可知，實現(xiàn)的關鍵在于限制許可證的非分配使用。

4.1 基于預留的機制

FNP支持對軟件許可證進行預留[7]，通過修改許可證文件以及第三方軟件供應商配置文件，可以將指定數(shù)量的許可證特性預留給指定的用戶、用戶組、主機或者項目?；诖丝梢詫崿F(xiàn)上述的令牌模型。在此實現(xiàn)方式中，作業(yè)、RMS及LM的交互流程如下：

(1)在FNP許可配置文件中，為供應商守護進程設置配置文件。

(2)RMS初始化時，通過修改供應商配置文件，預留全部許可證給root用戶以及項目RMS。將許可證全部預留給root用戶實際上實現(xiàn)了對非分配許可證使用的限制。

(3)get_feature_count接口：lmutil命令的包裝，通過解析lmutil命令的輸出獲得可用許可證數(shù)目。

(4)allocate_feature接口：編輯供應商配置文件，將所請求數(shù)目的許可證從預留給root用戶和項目RMS轉為預留給提交作業(yè)的用戶和項目RMS_JOB_jobid，其中jobid為作業(yè)在RMS中的標識；然后指示FNP管理守護進程重讀配置文件。

(5)RMS加載作業(yè)運行時，為應用程序設置環(huán)境變量LM_PROJECT=RMS_JOB_jobid，以指示應用軟件以該項目使用許可證。

(6)return_feature接口:編輯供應商配置文件，將為作業(yè)用戶和項目所預留的許可證轉為為root用戶和項目RMS預留；然后指示FNP管理守護進程重讀配置文件。

在此實現(xiàn)機制中，許可證令牌即是作業(yè)的用戶身份以及FNP項目RMS_JOB_jobid。雖然項目名字未加密，但由于FNP會限制檢出許可證的用戶，因此其它用戶無法通過偽造項目名字而竊取使用許可證。此機制的另一個問題是，需要避免其它用戶或軟件對供應商配置文件的編輯，以免引發(fā)沖突和競爭。由于管理員可以限制只有root用戶才能編輯供應商配置文件，這種沖突可以通過協(xié)調管理員的行為避免。

4.2 基于代理的機制

并非所有的LM均支持對許可證的預留。本文設計的另一種在遺留應用和LM上實現(xiàn)令牌模型的方法是，通過控制應用軟件與LM之間的通信來控制對許可證的使用。在此機制中設計了兩個代理軟件：LM Proxy和App Proxy，來完成對應用軟件與LM之間通信的控制。此實現(xiàn)機制如圖3所示。

Figure 3 Implementation mechanism based on proxy圖3 基于代理的實現(xiàn)機制

在基于代理的實現(xiàn)機制中，RMS不與LM直接進行交互，而是通過LM Proxy和App Proxy完成對許可證資源的使用控制。實現(xiàn)要點如下：

(1)所有應用軟件與LM的通信都必須經過LM Proxy的許可才能進行。這可以通過控制LM所運行的節(jié)點上的防火墻規(guī)則，或者由LM Proxy轉發(fā)所有到LM的通信報文來完成。

(2)許可證的分配與調度在RMS內部進行。RMS生成一個加密串作為許可證令牌。在分配或釋放許可證資源之后，RMS將分配或釋放信息傳遞給LM Proxy。

(3)在加載應用進程運行時，RMS將為作業(yè)分配的許可證令牌傳遞給App Proxy。App Proxy與應用進程運行在相同的計算節(jié)點上；對于并行應用軟件，如有必要可以在運行應用軟件進程的每個節(jié)點上都運行相應的App Proxy。

(4)當應用進程需要檢出許可證時，其與LM的通信連接將被App Proxy截獲,這可以通過對應用程序外掛鉤子函數(shù)實現(xiàn)。App Proxy將首先與LM Proxy進行通信，發(fā)送應用軟件需要使用的許可證信息，包括所需特性及數(shù)量，以及相應的令牌。LM Proxy根據(jù)許可證分配信息以及App Proxy發(fā)送的信息，決定是否允許應用進程與LM之間的通信。

(5)許可證資源被RMS回收之后，相關信息被傳遞到LM Proxy，對應的許可證令牌不再有效，且原有應用進程與LM的通信被切斷，以避免殘留應用進程對許可證資源的占用。

在此實現(xiàn)機制中，關鍵的挑戰(zhàn)是App Proxy能夠獲得應用軟件要使用的許可證特性以及數(shù)量。由于應用軟件與LM的通信都是加密的，從其通信報文中解析出相關信息是不現(xiàn)實的。一般而言，應用軟件的行為可以從其運行參數(shù)、輸入條件等確定。因此，可以在軟件運行時記錄LM端的日志并進行分析，獲得應用軟件對許可證的使用規(guī)律，形成一種規(guī)則庫。App Proxy可以結合作業(yè)并行規(guī)模等RMS所提供的作業(yè)信息，結合此規(guī)則庫，確定作業(yè)對許可證的需求信息。

5 結束語

軟件許可證作為一種昂貴的資源需要進行合理的調度管理以提高資源利用率。本文提出的基于令牌的許可證管理模型可以有效地解決現(xiàn)在的許可證管理軟件與并行計算機資源管理系統(tǒng)的結合問題，避免因許可證資源分配與應用軟件實際檢出之間的時間差產生的競爭條件導致作業(yè)運行失敗問題，提升并行計算機系統(tǒng)的用戶使用體驗和資源利用率。下一步將對不同種類資源的調度分配次序以及不同的調度策略對系統(tǒng)性能的影響展開研究。

[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)，研究方向為高性能計算，容錯計算，系統(tǒng)軟件。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

A

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

曹宏嘉(1977-),男,博士，副研究員,研究方向為資源管理和系統(tǒng)軟件。E-mail:hjcao@nudt.edu.cn

通信地址：410073 湖南省長沙市國防科學技術大學計算機學院

Address:College of Computer,National University of Defense Technology，Changsha 410073,Hunan,P.R.China