在云计算解决安全隐忧并成为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。运维
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.
====
====
•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.
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,这样配置更加灵活。示例中采用后者。
按照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设计运算需求动态调整。
openlava的机器须要进行状态监控以防备如下两种异常状况。
* 机器状态异常,好比机器宕机或者网络断线。
* 机器上服务异常,好比openlava的LIM进程或者BSD进程异常中断。
这两种异常都会影响服务器上运行着的job,同时会减小可用算力,因此须要及时发现,及时解决。通常来讲zabbix等IT运维管理软件就能够实现基础的机器/服务状态监控。
另外还有一些更加个性化的监控需求。好比当整的openlava队列资源使用率超过80%的时候,因为队列设置的缘由,通常用户就能明显感受到job投递困难,任务运行缓慢,openlava的维护者须要可以及时发现这种(以及其它的)情况,这样的个性需求可能就须要CAD本身开发一些定制化的监控工具来实现。
因为大多数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等)。若有合理的开发需求也能够直接联系我。
为了更加高效地利用利用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已知问题及解决方法
这多半是因为运行机器和显示机器显示长宽设置不一致致使的,这属于openlava的已知bug,最终版本(4.0)中没有修复。部分工具的解决方式以下。
若是是在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`
执行如下命令
stty columns 279 (tput cols >> 279)
stty rows 25 (tput lines >> 25)
或者在innovus中输入长命令时手工用“\”换行。
有时候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就恢复正常了。
openlava的lsb.params中“JOB_SPOOL_DIR”参数用于控制openlava job的cmd和stdout/stderr临时文件保存路径,当这个目录磁盘使用量超限之后,cmd和stdout/stderr的文件会产生在bsub执行主机上的/tmp目录下,若是文件尺寸过大,占满了/tmp路径,就会影响机器上全部进程的运行。
openlava log存储目录占满,openlava master/slave机器tmp空间占满,都会致使openlava响应速度减慢。
网络防火墙开启有可能影响openlava进程通信,减缓响应速度。
下述openlava的debug setting会致使openlava slave机器上sbatchd服务异常。
lsf.conf
========
LSF_LOG_MASK=LOG_DEBUG3
LSF_DEBUG_RES=...
LSB_DEBUG_SBD=...
LSF_DEBUG_LIM=...
========