IC-CAD Methodology企業實戰之openlava

時間 2019-12-05

標籤 cad methodology 企業實戰 openlava 简体版

原文原文鏈接

在雲計算解決安全隱憂併成爲IC界主流運算平臺以前，私有的服務器集羣系統仍然是各大IC公司的計算資源平臺首選。git

如今主流的服務器集羣管理系統包括lsf，openlava，SkyForm，三者都屬於lsf一系。lsf是IBM公司開發的服務器集羣管理系統，性能優異，且有商業支持，平臺組件豐富，十分易用，惟一的問題就是價格昂貴。openlava是兼容lsf的開源軟件，最終版本爲openlava4.0，至關於早期的lsf，其主要的用法和功能相似於lsf，於是lsf用戶基本能夠無縫切換到openlava，而且它開源免費免費，受到廣大IC廠商的歡迎。SkyForm脫胎於openlava，後來通過天雲軟件的從新開發，也避免了重用IBM原始代碼的侵權問題，其用法兼容與lsf和openlava，有商業支持，平臺組件豐富，收費（價格應該不太貴，沒有諮詢過），屬於一種折中的選擇。github

因爲lsf和SkyForm收費，考慮到國內IC公司一向勤儉節約，openlava的用戶體量應該是最大的，因此本文主要針對openlava來說，其它服務器集羣管理系統有共通之處。sql

對IC-CAD工程師而言，對openlava須要關注一下幾點。shell

1. openlava基本命令安全

2. openlava配置。bash

3. 硬件情況採集，機器/服務異常報警。服務器

4. 針對用戶的openlava狀態（job/host/queue）信息展現系統（最好爲GUI界面工具或者網頁，lsf爲網頁）網絡

5. 更進一步的基本數據採集，存儲，分析，經過更多個性化的插件化工具輔助將openlava的應用智能型和便捷性提高到更高的層次。app

openlava的安裝請參照https://my.oschina.net/liyanqing/blog/1633330。運維

1. openlava基本命令

Basic Command	Usage
bsub	Submits a batch job to openlava
bjobs	See the status of jobs in the LSF queue
bkill	Kill a running job （’bkill 0’ kills all the job one user submits）
bqueues	Displays information about queues
bhosts	Displays hosts and their job condition.
lshosts	Display hosts and their resource condition (cpu/memory).
lsload	Display host and their load condition (cpu/memory).

•bsub
%bsub -o [fileName] : Save bsub standard output into the log file (for debug).
%bsub -e [fileName] : Save bsub standard error into the log file (for debug).
%bsub -n [number] : Occupied specified number of processor to run the job.

%bsub -q [queueName] : Run the job on the specified queue.

%bsub -m [hostName] : Run the job on the specified host.

%bsub -P [projectName] : Declare which project the job is for.
%bsub -Is : Submit a batch interactive job and creates a terminal with shell mode
Be sure to use this option if you want to start up application with GUI
%bsub -R : Runs the job on a host that meets the specified resource requirements

For more detailed information, please check 「man bsub」

Some examples.

====

Job need 4 cpu slots, every slot need 100G memory (Total 4*100=400G memory).
任務屬於項目PJ123，須要4個cpu核，爲每一個核預佔100G內存（內存默認按照cpu核分配，而不是按照job分配），整體預留400G內存。
bsub -P PJ123 -n 4 -R "rusage[mem=100000]" "COMMAND"
Job need 4 cpu slots, and the 4 slots must be on the same host.
任務屬於項目PJ123，須要4個cpu核，且要求4個核在同一臺機器上（在設置了「span[hosts=1]」的前提下，機器上總共剩餘100G內存任務便可投遞成功）
bsub -P PJ123 -n 4 -R "span[hosts=1] rusage[mem=100000]" "COMMAND"
Submit job into pd queue, select the hosts who have 500G+ memory, 100G+ swap, 100G+ tmp.
任務屬於項目PJ123，須要投遞到pd隊列，要求投遞的機器剩餘內存大於500G，剩餘swap大於100G，剩餘tmp空間大於100G。（select可以選擇當前知足條件的機器，可是不能預佔機器上的資源，用rusage預佔資源）
bsub -P PJ123 -q pd -R "select[mem>=500000 && swap>=100000 && tmp>=100000]" "COMMAND"
Submit job into pd queue, need 8 cpu slots, reserve 100G memory, 100G swap, select the hosts who have 100G+ tmp.
任務屬於項目PJ123，須要投遞到pd隊列，須要8個cpu核，選擇tmp空間大於100G的機器，預佔100G內存和100Gswap。
bsub -P PJ123 -q pd -n 8 -R "rusage[mem=100000:swap=100000] select[tmp>=100000]" "COMMAND"

====

•bjobs
% bjobs : Display job list of current user
% bjobs -UF [jobId] : Display the detailed job information.

You can get job PEND reason and job memory/swqp usage with this command.

•bkill
% bkill -r [jobId] : Kill specified job by force.
% bkill 0 : Kill all the jobs.

•bqueues

% bqueues : Display job conditions on all queues.

Job limitation, total job number, RUN job number, pend job number, SUSP job number.

•bhosts

% bhosts : Displays hosts and their job condition.

Max job limitation, total job number, RUN job number, pend job number, SUSP job number.

•lshosts

% bhosts : Display hosts and their resource condition (cpu/memory).

cpu/memory/swp resource.

•lsload

% bhosts : Display host and their load condition (cpu/memory).

cpu/memory/swp/tmp load.

2. openlava配置策略

2.1 基礎配置

openlava配置的核心是lsb.queues，也就是隊列的配置。

先看一個基本的隊列設置。

Begin Queue
QUEUE_NAME = normal 隊列名稱
FAIRSHARE = USER_SHARES[[default,1]] 競爭策略
UJOB_LIMIT = 48 每一個用戶最大可用slot的數目
RUNLIMIT = 168:0 job最長運行時間限制，單位爲小時：分鐘
QJOB_LIMIT = 1500 queue中最大job運行數目限制
HOSTS = normal 隊列中機器設置（此處normal爲host組的名稱）
DESCRIPTION = Default queue, for normal jobs. 隊列描述
End Queue

其中須要注意如下幾點：

UJOB_LIMIT的數值必須合理配置，過小容易形成queue中運行的job的數目過少，浪費資源，太大則容易形成用戶可運行job數目太多而快速吃光資源，致使後提交任務的用戶老是得不到資源而使job處於PEND的狀態。

FAIRSHARE用於定義用戶新提交的job之間的競爭策略，示例中的設置意爲，在queue負載全滿的狀況下，全部用戶公平競爭，即不管每一個用戶PEND的job數目有多少，當有新的resource空餘出來的時候，全部用戶之間公平分配空閒resource。

HOSTS部分能夠直接定義host的名字列標，也能夠僅表示host group name，而後在lsb.hosts中定義host group name對應的具體的host name，這樣配置更加靈活。示例中採用後者。

2.2 配置策略

按照job RUNLIMIT（運行時間限制）的區分，建議分出3個隊列，short/normal/long。short通常用於運行短時就能完成的job，RUNLIMIT很短（好比一天）；normal屬於默認隊列，RUNLIMIT中等（好比一週）；long屬於運行超長時間的job（至少一個月，也能夠設成更長甚至無時間限制），爲了防着用戶濫用long隊列，其UJOB_LIMIT須要設置的較小。

按照機器資源也能夠分出一些特殊隊列，好比有些EDA工具須要大量的cpu，可是對memory不敏感，好比regression，那麼能夠把cpu核數很高的機器分到一個單獨隊列。有些EDA工具須要極大的內存，可是對cpu數目要求不高，能夠把memory極大地機器分到一個隊列。

按照IC設計的flow也能夠分出一些特殊隊列。不一樣IC設計流程所須要的運算資源也不同。好比regression須要極大量的slots，可是memory需求不高，並且job的運算時間通常較短；好比K庫通常須要極大量的slots，可是對於大型設計須要的memory也不少，並且運行時間每每也很長，通常也須要單獨的隊列。

隊列設置的總體思路是：

* 爲提升機器利用率，隊列中儘可能採用共享機器。

* 若是隊列須要接收job的時候必須有運算資源，不得不預留一部分專有機器，可是這樣有可能會形成必定程度的資源浪費，因此專有機器的數量要控制到合適範圍。

* 儘可能要預留一部分機動機器，以防備緊急任務沒有資源能夠調用。

* opelnava隊列的調整策略是一個動態的過程，須要根據IC設計運算需求動態調整。

3. 機器狀態監控

openlava的機器須要進行狀態監控以防備如下兩種異常狀況。

* 機器狀態異常，好比機器宕機或者網絡斷線。

* 機器上服務異常，好比openlava的LIM進程或者BSD進程異常中斷。

這兩種異常都會影響服務器上運行着的job，同時會減小可用算力，因此須要及時發現，及時解決。通常來講zabbix等IT運維管理軟件就能夠實現基礎的機器/服務狀態監控。

另外還有一些更加個性化的監控需求。好比當整的openlava隊列資源使用率超過80%的時候，因爲隊列設置的緣由，通常用戶就能明顯感受到job投遞困難，任務運行緩慢，openlava的維護者須要可以及時發現這種（以及其它的）情況，這樣的個性需求可能就須要CAD本身開發一些定製化的監控工具來實現。

4. openlava用戶端信息展現系統

因爲大多數ICer用戶都是openlava小白，很難要求他們系統地瞭解openlava的各類命令以獲取總體情況，包括job/host/queue，因此一些（圖形化）的輔助工具會比較易用。

lsf有提供網頁版的系統展現和信息查詢平臺，SkyForm不瞭解，應該也有。openlava則能夠按照企業需求定製化研發信息展現工具，也能夠採用開源工具openlavaMonitor，其包括數據採集和數據展現部分，可以知足基本的企業需求。

openlavaMonitor的說明見https://my.oschina.net/liyanqing/blog/1843744，github下載地址爲https://github.com/liyanqing1987/openlavaMonitor，下面作簡要說明。

openlavaMonitor採集job/host/load/queue/user信息，採用sqlite3存儲數據，採用PyQt5編寫的圖形展現界面，採用matplotlib繪製二維圖表，其主要展現信息以下所示。

圖1 openlavaMonitor job信息展現界面

圖2 openlavaMonitor jobs信息展現界面

圖3 openlavaMonitor hosts信息展現界面

圖4 openlavaMonitor queues信息展現界面

這個工具能夠知足用戶以下基本的openlava信息獲取需求。

* job基本信息，包括job生命週期內內存使用情況（若是job EXIT，能夠分析是否是memory使用過量致使的job失敗）。

* jobs的基本信息，能夠查看全部的job，也能夠按照user/status/queue/host選擇jobs。

* hosts的基本信息，包括host的情況，所屬queue，核數，job數目，cpu/memory/swap等資源總量和使用量。

* queues的基本信息，包括15天內指定queue的RUN/PEND job數目變化趨勢，用於判斷queueu間的負載變化狀況。

企業能夠按照需求本身繼續定製化開發openlavaMonitor，以展現更多信息（好比user等）。若有合理的開發需求也能夠直接聯繫我。

5. openlava自研工具

爲了更加高效地利用利用openlava系統，提高機器資源使用率，提高用戶使用便捷程度，以及經過大數據分析獲得IC相關數據（好比項目資源使用量分析，好比user工做量分析），還能夠經過自研工具，經過openlava的數據採集以及數據分析獲得。

如下是一些研發方向，按照企業實際需求僅供參考。

* 採集分析host/queue的資源使用狀況，動態調整queue-host設置以進一步提升總體的資源使用率，避免資源浪費。

* 採集分析user的任務運行狀況（工做量分析）。

* 採集分析project相關數據（分析項目資源消耗量）。

* 採集分析全部job的資源申請設置以及實際的資源使用狀況，獲得job設置失誤程度，經過分析數據，有目的地知道用戶合理設置bsub指令，合理使用openlava系統。

* 直接開發頂層腳本esub（做爲bsub wrapper的一種統稱），經過數據分析以智能地替代人工經驗，提升用戶使用便捷度（好比esub自動爲bsub任務添加project等標籤，自動根據歷史記錄設置cpu/memory/swap等資源請求，經過分析歷史記錄預估正在運行job的運行時間等，從而讓用戶使用openlava更加簡易便捷）。

備註:

一些openlava已知問題及解決方法

1. 在使用交互模式時，有些EDA工具的輸出會出現折行，錯行等現象。

這多半是因爲運行機器和顯示機器顯示長寬設置不一致致使的，這屬於openlava的已知bug，最終版本（4.0）中沒有修復。部分工具的解決方式以下。

1.1 對dc_shell/pt_shell而言

若是是在csh/tcsh中，執行如下命令。

setenv LINES; unsetenv COLUMNS; setenv LINES `tput lines`; setenv COLUMNS `tput cols`

若是是在bash中，執行如下命令。

unset LINES; unset COLUMNS; export LINES=`tput lines`; export COLUMNS=`tput cols`

1.2 對innovus而言

執行如下命令

stty columns 279 (tput cols >> 279)

stty rows 25 (tput lines >> 25)

或者在innovus中輸入長命令時手工用「\」換行。

2. 飽和式job投遞致使openlava相應減緩，甚至無jobid可用

有時候openlava中bsub job失敗，說沒有jobid可用，咱們在mbatchd.log.<master>中能夠看到以下警告信息。

Feb 17 02:51:26.139054 47716 3 40 getNextJobId(): Too many jobs in the system; can't accept any new job for the moment

這個信息產生的根源是，openlava默認會保留一段時間的job信息（包括全部未完成的job和一段時間內已完成的job，用於bjobs -a或者bhists等命令查看），信息存儲週期有lsb.params中的參數CLEAN_PERIOD來決定（默認完成的job，信息保存一個小時）。若是CLEAN_PERIOD時間內完成的job和全部未完成的job數目之和超過了openlava MAX_JOBID的數值，就會致使openlava沒有可用的jobid，從而致使新的job沒法投遞。

這個問題的解決方法以下：

1. 增大lsb.params中的參數MAX_JOBID的值。（這只是個臨時解決方法）

2. 減少CLEAN_PERIOD的值到合適的時間範圍。（保存太長時間的job信息，不免致使可用jobid不足）

3. 查看下有無user大量投遞job的現象（這就相似於黑客的飽和攻擊啊），若是有，暫停起大量投遞job的行爲。

咱們遇到過一個實際的案例，用戶沒法投遞新的job，報告沒有jobid可用，同時執行bhosts等反應極其緩慢。後來最終發現是有用戶執行腳本在不停地投遞job，18小時內投遞了130萬個job，致使了jobid用光。後來解決方案就是關掉用戶的腳本，kill掉無效job，減少CLEAN_PERIOD的值（從5天縮減到1天），重啓openlava服務讓其刪除多餘jobid信息，而後openlava就恢復正常了。

3. lsbatch目錄被寫滿致使openlava無響應

openlava的lsb.params中「JOB_SPOOL_DIR」參數用於控制openlava job的cmd和stdout/stderr臨時文件保存路徑，當這個目錄磁盤使用量超限之後，cmd和stdout/stderr的文件會產生在bsub執行主機上的/tmp目錄下，若是文件尺寸過大，佔滿了/tmp路徑，就會影響機器上全部進程的運行。

openlava log存儲目錄佔滿，openlava master/slave機器tmp空間佔滿，都會致使openlava響應速度減慢。