IC-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.

====

  1. 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"
  2. 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"
  3. 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"
  4. 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响应速度减慢。

 

4. 防火墙开启致使openlava master机器bmatchd进程通信阻塞

网络防火墙开启有可能影响openlava进程通信,减缓响应速度。

 

5. openlava debug设置会致使sbatchd进程异常

下述openlava的debug setting会致使openlava slave机器上sbatchd服务异常。

lsf.conf

========

LSF_LOG_MASK=LOG_DEBUG3

LSF_DEBUG_RES=...

LSB_DEBUG_SBD=...

LSF_DEBUG_LIM=...

========

相关文章
相关标签/搜索