IC-CAD Methodology企业实战之openlava

在云计算解决安全隐忧并成为IC界主流运算平台之前，私有的服务器集群系统仍然是各大IC公司的计算资源平台首选。

现在主流的服务器集群管理系统包括lsf，openlava，SkyForm，三者都属于lsf一系。lsf是IBM公司开发的服务器集群管理系统，性能优异，且有商业支持，平台组件丰富，十分易用，唯一的问题就是价格昂贵。openlava是兼容lsf的开源软件，最终版本为openlava4.0，相当于早期的lsf，其主要的用法和功能类似于lsf，因而lsf用户基本可以无缝切换到openlava，并且它开源免费免费，受到广大IC厂商的欢迎。SkyForm脱胎于openlava，后来经过天云软件的重新开发，也避免了重用IBM原始代码的侵权问题，其用法兼容与lsf和openlava，有商业支持，平台组件丰富，收费（价格应该不太贵，没有咨询过），属于一种折中的选择。

由于lsf和SkyForm收费，考虑到国内IC公司一贯勤俭节约，openlava的用户体量应该是最大的，所以本文主要针对openlava来讲，其它服务器集群管理系统有共通之处。

对IC-CAD工程师而言，对openlava需要关注一下几点。

1. openlava基本命令

2. openlava配置。

3. 硬件状况采集，机器/服务异常报警。

4. 针对用户的openlava状态（job/host/queue）信息展示系统（最好为GUI界面工具或者网页，lsf为网页）

5. 更进一步的基本数据采集，存储，分析，通过更多个性化的插件化工具辅助将openlava的应用智能型和便捷性提升到更高的层次。

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响应速度减慢。