简介openlava 4.0 源码安装包面向需要了解集群调度与管理机制的运维人员、系统管理员及入门学习者。openlava 是较为成熟的集群管理工具尽管官方已停止维护但其设计思想影响深远IBM 的 LSF 即在其基础上发展而来学习价值依然充分。压缩包内共 501 个文件以 C 语言源码250 个 c 文件和头文件65 个 h 文件为主同时包含 44 个 in 配置模板、29 个 am 自动化构建描述及 configure、install-sh 等标准编译部署脚本整体仅 1.65MB适合快速下载研究。内容覆盖 bsub、bjobs、bqueues、bhosts、bkill 等经典作业管理与负载查看命令的 man 文档便于系统梳理 openlava 的常用操作与调度逻辑。目前已有 1602 人学习下载对于希望理解集群调度核心思想、为后续上手 LSF 等商业产品作铺垫的读者是一份轻量且具备参考价值的入门资料。1. openlava-4.0.tar.gz 是什么一个让 HPC 集群不再空转的调度器源码包第一次拿到 openlava-4.0.tar.gz 的人多半会把它当成某个仿真软件直接解压运行结果在配置这台机器时卡住。其实这个压缩包里装的是一个集群调度器它把一批服务器的 CPU、内存和许可资源统一纳管排队执行提交上来的并行任务。当你手里只有 5 到 50 台机器天天要跑批量仿真、参数扫描或转码任务时它比手工写 shell 分发脚本要可靠得多也能解决资源空转和排队混乱这两个最让运维头痛的问题。我从编译、单机部署到多节点配置完整走过一遍下面直接讲落地命令和容易翻车的位置。适合想搭小型 HPC 集群又不想在商业调度器上花钱的从业者。2. 先搞懂 openlava 的调度模型再决定装不装openlava 这类调度器之所以看起来像个黑匣子是因为大家习惯了单机应用天然假设“提交任务 立即运行”。但调度器里根本不是这个逻辑任务先进入队列由主控进程根据资源情况决定什么时候、在哪台机器上执行。不理解队列、槽位和 fairshare 这三者的关系后面改配置特别容易踩坑所以我建议在解压 tar.gz 之前先用一章把模型说清楚。2.1 队列、槽位与 fairshare 的三角关系队列是任务的提交入口。每个队列可以配置允许哪些用户提交、哪些节点参与、最大运行作业数、作业优先级等。槽位slot是调度器分配的最小计算单位简单理解就是“这个节点上能同时放多少个任务”。配置这两者后还有公平性调度fairshare它控制着多个项目组之间的资源配额占比。三者的关系用一张表说明更直观概念对应配置实际作用队列lsb.queues 中的队列段限制提交入口、队列优先级、资源上限槽位lsb.hosts / 节点上的静态资源决定同一时刻能并行跑多少任务fairshare用户/项目组配额决定竞争时谁的作业先被调度单机部署时你可能觉得队列无所谓因为机器只归自己用一旦多节点接入不划分队列就会出现高内存作业把 CPU 密集型队列占满或者某个组抢走全部资源的情况。openlava 的默认配置里有一个 normal 队列所有主机都属于它所有用户都能提交初次安装用它验证最省事。真正要控制资源时再按项目组拆队列、设 fairshare。2.2 从源码包看 openlava-4.0 的目录布局与版本选型拿到 openlava-4.0.tar.gz 先别急着解压用一条命令看一下包里到底有什么tar -tzf openlava-4.0.tar.gz | head -40这里的-t表示列出包内文件清单-z表示对 gzip 格式解压流操作-f指定文件名。head -40只取前 40 行避免被完整文件列表刷屏。openlava 4.0 的源码包一般能直接看到 configure 脚本、README 以及以 lsf 命名的代码目录它从商业 HPC 调度器早期版本演化而来目录结构和配置思路保留了那种“大家族”味道所以和 LSF 的用户文档匹配度很高。版本选型上openlava-4.0.0.tar.gz 并不是最新版本却是很多小集群的保守选择它依赖的都是老牌的 C 编译器和 Perl 工具链二进制体积小配置文档也容易找到。更新版本虽然修复了一些内存泄漏和容器支持问题但同时也引入了更多配置项对只想跑通作业的人来说反而增加复杂度。我一般建议集群规模在 50 台以内、没有复杂的容器接入需求时直接用 4.0 源码包是性价比最高的如果非要上 GPU 分片和更细粒度的公平调度再考虑更新版本。2.3 编译前置条件这 4 个依赖包一个都不能少openlava 是 C 写的调度器编译阶段对依赖其实非常克制不需要数据库、不需要 Web 服务端但下面四个东西少一个都会在某个环节翻车gcc、make、Perl 以及 ncurses 库。Perl 是配置校验脚本和部分工具必须的ncurses 则被一些交互式查询命令引用。装之前先用命令自查gcc --version make --version perl -v ldconfig -p | grep -E libncurses|libtinfo前三个命令都有明确输出代表可用最后一个 grep 检查的是动态链接库里是否有 ncurses 相关文件。如果发现缺 gcc 和 make很明显是编译工具链没装全缺 libncurses 时用发行版包管理器安装即可Debian 系是apt install libncurses-devRed Hat 系是yum install ncurses-devel。注意千万别只装运行库而不装开发头文件否则 configure 能过make 时会出现找不到curses.h的错误这种错误在中途出现会让人很想放弃。依赖确认后再进入源码目录执行编译下一章完整走一遍。3. 从 tar.gz 到能提交作业本地单机安装全流程很多人看着 openlava 的官方文档会觉得很简单实际上真正做的时候卡点集中在 configure 参数、运行用户和启动顺序这三处。单机部署如果不把基础设施一次做对后面多节点扩展时要回去改配置重做非常折腾。我习惯的路径是解压、配置、编译、建用户、补目录、启动服务、提交第一个作业一步验证到位。3.1 解压与 configure 参数把 install path 和 conf path 一次定死先在打算作为集群 master 的机器上解压源码包并完成第一次编译tar -xzf openlava-4.0.tar.gz cd openlava-4.0 ./configure --prefix/opt/openlava make -j$(nproc) make installtar -xzf解压后进入源码目录./configure --prefix/opt/openlava把安装根目录固定到/opt/openlava之后所有二进制、配置模板、帮助文件都放在这个目录下避免散落在系统路径里不好维护。-j$(nproc)用机器全部 CPU 核并行编译能明显加快速度如果你在同一台机器上还要跑生产作业建议用-j4之类的保守值否则编译时可能把内存吃满。make install后二进制已经就位但不要急着启动服务此时 conf 目录里只有模板运行用户也还没创建。这里有一个常见疑问为什么不用--prefix/usr/local我试过后续升级时make install会直接覆盖系统同名文件风险更大。固定/opt后升级只需重编、留旧目录做回滚后悔药随时有。configure 阶段尽量少加额外参数openlava 4.0 默认配置已经足够覆盖大部分集群追加参数反而容易让新手在排查时多一个变量。3.2 make 与 make install 之后必须手工补的两步用户与目录编译安装完成后源码里的脚本不会自动创建运行用户。直接用 root 启动调度服务虽然能跑但产生的临时文件和日志都归 root后续普通用户提交作业时经常遇到权限错乱。所以安装后我会立刻做这两步useradd -r -m -d /home/openlava openlava mkdir -p /opt/openlava/conf /opt/openlava/log /opt/openlava/work chown -R openlava:openlava /opt/openlava cat /etc/profile.d/openlava.sh EOF export LSF_TOP/opt/openlava export LSF_CONFDIR/opt/openlava/conf export LSB_CONFDIR/opt/openlava/conf export PATH$LSF_TOP/bin:$LSF_TOP/sbin:$PATH EOF source /etc/profile.d/openlava.shuseradd -r -m创建一个系统账户并保留家目录用来隔离服务权限mkdir建立 conf、log、work 三个目录分别放配置、日志和临时工作文件chown确保所有目录归 openlava 用户所有。环境变量里LSF_TOP指向安装根目录LSF_CONFDIR和LSB_CONFDIR都指向配置文件目录这是调度器运行时寻找配置文件的关键。如果不写/etc/profile.d/openlava.sh每次登录都要手工 export代理作业脚本或ssh到其他节点时还容易丢环境所以建议写成全局脚本。这一步是很多踩坑记录的来源有人直接跳过 useradd导致后面lsadmin启动时 LIM 进程以 root 身份挂起普通用户bhosts却看不到节点。这个问题在单机不明显但多节点时计算节点上的客户端无法通过安全认证连接 master。所以别偷懒用户和目录权限一次做对。3.3 启动 lsadmin 和 badmin集群元数据怎么落盘单机安装完成、环境变量也正确之后就可以启动服务了。第一次启动调度的顺序非常关键lsadmin limstartup lsadmin resstartup badmin hstartup badmin mbdstartup bhosts bqueueslimstartup启动 LIMLoad Information Manager它负责收集每台机器的负载信息并维护集群主机列表resstartup启动 RES 资源服务负责软件许可证和资源配额hstartup计算节点上启动 sbatchd执行来自管理节点的任务mbdstartup启动主控调度进程 mbatchd所有作业的排队、调度决策都由它完成。启动顺序不能被颠倒LIM 没起来时mbatchd 无法获取节点负载会拒绝启动并报错。启动后立刻用bhosts看主机是否显示ok状态、用bqueues看队列是否Open。这一步相当于集群元数据的落盘过程配置从文本文件被加载到服务进程的内存并写入日志目录对应文件。如果bhosts只输出表头没有行多半是lsf.cluster.openlava里没有配置主机如果bqueues显示队列 closed则是lsb.queues里队列没有打开。单机验证这两条命令输出正常就可以提交第一个作业了。4. 多节点集群配置把计算节点收编进调度器单机跑通后多节点才是真正展示调度器价值的地方。多节点的难点不是安装而是三件事统一主机名互相能解析、配置里声明了节点、计算节点能连回 master。这三件事不做对作业会一直 PEND或者提交时报找不到队列。我一般按照静态配置、动态管理、作业验证三步来收编节点。4.1 配置 /etc/hosts 和 lsf.cluster.openlava静态节点表怎么写调度器内部通过主机名匹配节点所以集群内所有机器都建议先写好静态解析避免依赖 DNS 带来的不确定性。在 master 和每台计算节点上维护同一个 /etc/hosts192.168.10.11 master 192.168.10.12 comp01 192.168.10.13 comp02 192.168.10.14 comp03IP 和主机名要一一对应并且建议用短主机名。写好 hosts 后编辑/opt/openlava/conf/lsf.cluster.openlava把参与纳管的主机写进去Begin Cluster CLUSTERNAME localcluster MASTERLIST master ADMINHOSTS master End Begin Host HOSTNAME type server rserver resources master Linux 1 1 - comp01 Linux 1 1 - comp02 Linux 1 1 - comp03 Linux 1 1 - EndCLUSTERNAME是集群名必须与lsf.conf或本地配置中的命名一致MASTERLIST指明主控节点只有一个 master 时写一行即可Begin Host段中每个节点一行type表示操作系统类型server和rserver为 1 代表该主机可以作为任务执行主机。修改静态配置后必须重启 LIM 和 mbatchd 才会生效具体做法是lsadmin limshutdown lsadmin limstartup badmin mbdrestart打开这个文件时如果你发现模板里已经有Begin Host不要删除其他段只修改 HOSTNAME 和 IP 对应关系即可。静态配置负责定义“这台机器是否属于集群”而后续的动态命令负责调整“当前是否接活”。4.2 用 badmin 动态管理节点add/delete 的实际效果静态配置之外的运行时调整openlava 通过 badmin 命令完成。比如临时把一台新机器纳入计算资源badmin -a hostadd comp04 bhosts -l comp04执行后如果 comp04 在bhosts里从unavail变成ok说明主控进程已经成功在它上面启动 sbatchd。同样地把下线的节点移除badmin -a hostdel comp04 bhosts这里必须注意badmin hostadd只影响调度器的运行状态不会回写lsf.cluster.openlava文本配置。如果 master 重启或集群重启动态添加的节点会消失。所以临时扩容之后别忘了把节点真正登记到静态配置文件里否则每次重启都要重新执行。这也是我经历过的最隐蔽的坑看似节点已经加入一个意外重启后队列资源凭空少一半。4.3 作业提交验证bsub 排队到执行的完整链路节点就绪后用最简单的方式提交作业从头到尾验证整条链路bsub -q normal -n 2 -o /tmp/my_job.%J.log sleep 60 bjobs bhostsbsub -q normal指定队列-n 2申请两个槽位-o /tmp/my_job.%J.log把作业的标准输出写到/tmp/my_job.作业号.log其中%J是作业号占位符提交后会替换成真实编号。然后跑bjobs查看作业状态刚开始是 PEND调度器找到空闲槽位后变成 RUN执行完成退出后变成 DONE。bhosts可以看到当前节点的负载和已用槽位这能确认作业实际落在哪台上。如果bjobs一直 PEND用bqueues -l normal检查队列状态再确认槽位是否被占满。如果作业一提交就报错返回第 5 章看看常见原因。这条链路走通后集群已经从“手工分发脚本”变成了“排队执行”后续要做的只是把任务用 bsub 包起来。5. openlava 部署避坑新手最容易翻车的 5 个细节我在不同环境里部署 openlava踩过的坑可以整理成一张黑名单。下面是出现频率最高的 5 个问题每条按“现象 → 原因 → 解决”来说明希望能帮你省掉排查时间。5.1 现象lsadmin limstartup 提示 “Another LIM is alive”执行lsadmin limstartup时报错说 LIM 已经在运行但bhosts又看不到正常输出。原因一般是两种之前启动过 LIM 进程没有完全退出或者/tmp下的 LIM 临时文件属主错乱。解决时先查看进程ps -ef | grep -E lim|mbatchd | grep -v grep确认有残留进程就直接lsadmin limshutdown停掉如果进程已经不存在但文件属主不对清理/tmp下 openlava 相关临时文件后以 openlava 用户重新启动。要避免这个问题部署全程尽量使用同一个系统账户操作不要一会儿 root 一会儿 openlava。5.2 现象作业一直 PEND状态永远是 PEND提交后bjobs看到作业停在 PEND 不走这是新手最常问的问题。原因无外乎三类队列被关闭了、队列上没有可用槽位、节点状态进入不可用。检查命令bqueues -l normal bhosts badmin mbdrestartbqueues -l normal会显示队列是否为 Openbhosts能直接看到各主机的状态和剩余槽位。如果节点状态是unavail多半是 sbatchd 没起来用badmin hstartup补起如果队列显示 Closed编辑lsb.queues把队列打开并重启 mbatchd。5.3 现象bsub 提交后立即报 “Cannot find a suitable queue”作业提交时系统找不到可用队列。最常见原因是提交用户没有被加入lsb.users的允许列表或者提交主机不在lsb.hosts定义范围内。先用bqueues查看当前队列的 ACCESS 字段bqueues -l normal如果 normal 队列只允许某个分组提交把当前用户加进对应分组或者用bsub -q明确指定一个有权限的队列。这种事最容易发生在升级用户权限之后新用户只加了系统账户忘了同步到调度器配置里。5.4 现象跨节点作业偶发失败日志里只有信号 9多节点跑任务时作业日志里只有一行信号 9 的信息看起来像是被外部杀掉。原因通常是任务实际内存超过了节点限制触发内核 OOM另一个可能是工作目录在 master 和计算节点上路径不一致。排查时先看系统日志确认有没有 OOM 记录再用资源申请参数显式限制bsub -R rusage[mem4096] -n 2 ./job.sh-R rusage[mem4096]告诉调度器这个作业预估要 4096 MB 内存调度器会把它安排到有足够内存的节点。同时确认所有计算节点都挂了共享存储并且路径一致比如统一挂/data。路径不一致时作业在计算节点上找不到输入文件脚本退出也会留下类似半途终止的痕迹。5.5 现象重启后调度器起不来/tmp 下的 sock 文件权限错乱系统重启后lsadmin limstartup等命令报权限错误查看/tmp发现调度器生成的 socket 文件属主是 root但当前启动用户是 openlava。原因是第一次测试时用 root 启动过服务socket 文件没有随进程退出被删干净。解决方法是停止所有服务、删除这些临时文件、再切换用户启动lsadmin limshutdown badmin mbdshutdown rm -f /tmp/.openlava* /tmp/lim* /tmp/sbd*这里我习惯把/tmp/.openlava*这类文件单独列出只精确删除调度器相关目录千万不要rm -rf /tmp/*一把梭。清理后再按 openlava 用户启动一般就能恢复。说到教训整个集群只用同一个用户管理调度器可以省掉一大半这类权限玄学问题。6. 最后一个技巧用主机组与作业组做混合负载的可控混部多队列、多项目组混跑时我最常用的是把主机组和作业组组合起来主机组限制作业只能跑到哪些机器作业组则用于限制每个项目组的总负载。二者配合可以在一个集群上安全地混跑 CPU 密集型、内存密集型和短周期任务。比如在配置里定义一个专门吃 IO 的主机组提交时直接指定它bsub -g /project_a -q normal -m compute_io ./run_io.sh-g /project_a把作业归到名为 project_a 的作业组方便统计配额和后续权限控制-m compute_io限定作业只能运行在 compute_io 这个主机组里。如果主机组不存在要先在 lsb.hosts 中声明否则提交会报找不到主机。我自己的习惯是只要有 3 个以上的项目组共享集群先按项目分作业组再按业务类型分主机组调度器里只保留 2 到 3 个队列。这个容器数量越少越不容易乱混合负载也更好观察因为bqueues -l和bhosts的输出会变得非常直观。每次扩节点或加项目组时我都先拿bsub -g提交一个短任务做验收确认落在预期主机组再放量。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/15 15:50:37 · 阅读 1.2k openlava-4.0源码包安装指南：从tar.gz到HPC集群调度器部署
简介openlava 4.0 源码安装包面向需要了解集群调度与管理机制的运维人员、系统管理员及入门学习者。openlava 是较为成熟的集群管理工具尽管官方已停止维护但其设计思想影响深远IBM 的 LSF 即在其基础上发展而来学习价值依然充分。压缩包内共 501 个文件以 C 语言源码250 个 c 文件和头文件65 个 h 文件为主同时包含 44 个 in 配置模板、29 个 am 自动化构建描述及 configure、install-sh 等标准编译部署脚本整体仅 1.65MB适合快速下载研究。内容覆盖 bsub、bjobs、bqueues、bhosts、bkill 等经典作业管理与负载查看命令的 man 文档便于系统梳理 openlava 的常用操作与调度逻辑。目前已有 1602 人学习下载对于希望理解集群调度核心思想、为后续上手 LSF 等商业产品作铺垫的读者是一份轻量且具备参考价值的入门资料。1. openlava-4.0.tar.gz 是什么一个让 HPC 集群不再空转的调度器源码包第一次拿到 openlava-4.0.tar.gz 的人多半会把它当成某个仿真软件直接解压运行结果在配置这台机器时卡住。其实这个压缩包里装的是一个集群调度器它把一批服务器的 CPU、内存和许可资源统一纳管排队执行提交上来的并行任务。当你手里只有 5 到 50 台机器天天要跑批量仿真、参数扫描或转码任务时它比手工写 shell 分发脚本要可靠得多也能解决资源空转和排队混乱这两个最让运维头痛的问题。我从编译、单机部署到多节点配置完整走过一遍下面直接讲落地命令和容易翻车的位置。适合想搭小型 HPC 集群又不想在商业调度器上花钱的从业者。2. 先搞懂 openlava 的调度模型再决定装不装openlava 这类调度器之所以看起来像个黑匣子是因为大家习惯了单机应用天然假设“提交任务 立即运行”。但调度器里根本不是这个逻辑任务先进入队列由主控进程根据资源情况决定什么时候、在哪台机器上执行。不理解队列、槽位和 fairshare 这三者的关系后面改配置特别容易踩坑所以我建议在解压 tar.gz 之前先用一章把模型说清楚。2.1 队列、槽位与 fairshare 的三角关系队列是任务的提交入口。每个队列可以配置允许哪些用户提交、哪些节点参与、最大运行作业数、作业优先级等。槽位slot是调度器分配的最小计算单位简单理解就是“这个节点上能同时放多少个任务”。配置这两者后还有公平性调度fairshare它控制着多个项目组之间的资源配额占比。三者的关系用一张表说明更直观概念对应配置实际作用队列lsb.queues 中的队列段限制提交入口、队列优先级、资源上限槽位lsb.hosts / 节点上的静态资源决定同一时刻能并行跑多少任务fairshare用户/项目组配额决定竞争时谁的作业先被调度单机部署时你可能觉得队列无所谓因为机器只归自己用一旦多节点接入不划分队列就会出现高内存作业把 CPU 密集型队列占满或者某个组抢走全部资源的情况。openlava 的默认配置里有一个 normal 队列所有主机都属于它所有用户都能提交初次安装用它验证最省事。真正要控制资源时再按项目组拆队列、设 fairshare。2.2 从源码包看 openlava-4.0 的目录布局与版本选型拿到 openlava-4.0.tar.gz 先别急着解压用一条命令看一下包里到底有什么tar -tzf openlava-4.0.tar.gz | head -40这里的-t表示列出包内文件清单-z表示对 gzip 格式解压流操作-f指定文件名。head -40只取前 40 行避免被完整文件列表刷屏。openlava 4.0 的源码包一般能直接看到 configure 脚本、README 以及以 lsf 命名的代码目录它从商业 HPC 调度器早期版本演化而来目录结构和配置思路保留了那种“大家族”味道所以和 LSF 的用户文档匹配度很高。版本选型上openlava-4.0.0.tar.gz 并不是最新版本却是很多小集群的保守选择它依赖的都是老牌的 C 编译器和 Perl 工具链二进制体积小配置文档也容易找到。更新版本虽然修复了一些内存泄漏和容器支持问题但同时也引入了更多配置项对只想跑通作业的人来说反而增加复杂度。我一般建议集群规模在 50 台以内、没有复杂的容器接入需求时直接用 4.0 源码包是性价比最高的如果非要上 GPU 分片和更细粒度的公平调度再考虑更新版本。2.3 编译前置条件这 4 个依赖包一个都不能少openlava 是 C 写的调度器编译阶段对依赖其实非常克制不需要数据库、不需要 Web 服务端但下面四个东西少一个都会在某个环节翻车gcc、make、Perl 以及 ncurses 库。Perl 是配置校验脚本和部分工具必须的ncurses 则被一些交互式查询命令引用。装之前先用命令自查gcc --version make --version perl -v ldconfig -p | grep -E libncurses|libtinfo前三个命令都有明确输出代表可用最后一个 grep 检查的是动态链接库里是否有 ncurses 相关文件。如果发现缺 gcc 和 make很明显是编译工具链没装全缺 libncurses 时用发行版包管理器安装即可Debian 系是apt install libncurses-devRed Hat 系是yum install ncurses-devel。注意千万别只装运行库而不装开发头文件否则 configure 能过make 时会出现找不到curses.h的错误这种错误在中途出现会让人很想放弃。依赖确认后再进入源码目录执行编译下一章完整走一遍。3. 从 tar.gz 到能提交作业本地单机安装全流程很多人看着 openlava 的官方文档会觉得很简单实际上真正做的时候卡点集中在 configure 参数、运行用户和启动顺序这三处。单机部署如果不把基础设施一次做对后面多节点扩展时要回去改配置重做非常折腾。我习惯的路径是解压、配置、编译、建用户、补目录、启动服务、提交第一个作业一步验证到位。3.1 解压与 configure 参数把 install path 和 conf path 一次定死先在打算作为集群 master 的机器上解压源码包并完成第一次编译tar -xzf openlava-4.0.tar.gz cd openlava-4.0 ./configure --prefix/opt/openlava make -j$(nproc) make installtar -xzf解压后进入源码目录./configure --prefix/opt/openlava把安装根目录固定到/opt/openlava之后所有二进制、配置模板、帮助文件都放在这个目录下避免散落在系统路径里不好维护。-j$(nproc)用机器全部 CPU 核并行编译能明显加快速度如果你在同一台机器上还要跑生产作业建议用-j4之类的保守值否则编译时可能把内存吃满。make install后二进制已经就位但不要急着启动服务此时 conf 目录里只有模板运行用户也还没创建。这里有一个常见疑问为什么不用--prefix/usr/local我试过后续升级时make install会直接覆盖系统同名文件风险更大。固定/opt后升级只需重编、留旧目录做回滚后悔药随时有。configure 阶段尽量少加额外参数openlava 4.0 默认配置已经足够覆盖大部分集群追加参数反而容易让新手在排查时多一个变量。3.2 make 与 make install 之后必须手工补的两步用户与目录编译安装完成后源码里的脚本不会自动创建运行用户。直接用 root 启动调度服务虽然能跑但产生的临时文件和日志都归 root后续普通用户提交作业时经常遇到权限错乱。所以安装后我会立刻做这两步useradd -r -m -d /home/openlava openlava mkdir -p /opt/openlava/conf /opt/openlava/log /opt/openlava/work chown -R openlava:openlava /opt/openlava cat /etc/profile.d/openlava.sh EOF export LSF_TOP/opt/openlava export LSF_CONFDIR/opt/openlava/conf export LSB_CONFDIR/opt/openlava/conf export PATH$LSF_TOP/bin:$LSF_TOP/sbin:$PATH EOF source /etc/profile.d/openlava.shuseradd -r -m创建一个系统账户并保留家目录用来隔离服务权限mkdir建立 conf、log、work 三个目录分别放配置、日志和临时工作文件chown确保所有目录归 openlava 用户所有。环境变量里LSF_TOP指向安装根目录LSF_CONFDIR和LSB_CONFDIR都指向配置文件目录这是调度器运行时寻找配置文件的关键。如果不写/etc/profile.d/openlava.sh每次登录都要手工 export代理作业脚本或ssh到其他节点时还容易丢环境所以建议写成全局脚本。这一步是很多踩坑记录的来源有人直接跳过 useradd导致后面lsadmin启动时 LIM 进程以 root 身份挂起普通用户bhosts却看不到节点。这个问题在单机不明显但多节点时计算节点上的客户端无法通过安全认证连接 master。所以别偷懒用户和目录权限一次做对。3.3 启动 lsadmin 和 badmin集群元数据怎么落盘单机安装完成、环境变量也正确之后就可以启动服务了。第一次启动调度的顺序非常关键lsadmin limstartup lsadmin resstartup badmin hstartup badmin mbdstartup bhosts bqueueslimstartup启动 LIMLoad Information Manager它负责收集每台机器的负载信息并维护集群主机列表resstartup启动 RES 资源服务负责软件许可证和资源配额hstartup计算节点上启动 sbatchd执行来自管理节点的任务mbdstartup启动主控调度进程 mbatchd所有作业的排队、调度决策都由它完成。启动顺序不能被颠倒LIM 没起来时mbatchd 无法获取节点负载会拒绝启动并报错。启动后立刻用bhosts看主机是否显示ok状态、用bqueues看队列是否Open。这一步相当于集群元数据的落盘过程配置从文本文件被加载到服务进程的内存并写入日志目录对应文件。如果bhosts只输出表头没有行多半是lsf.cluster.openlava里没有配置主机如果bqueues显示队列 closed则是lsb.queues里队列没有打开。单机验证这两条命令输出正常就可以提交第一个作业了。4. 多节点集群配置把计算节点收编进调度器单机跑通后多节点才是真正展示调度器价值的地方。多节点的难点不是安装而是三件事统一主机名互相能解析、配置里声明了节点、计算节点能连回 master。这三件事不做对作业会一直 PEND或者提交时报找不到队列。我一般按照静态配置、动态管理、作业验证三步来收编节点。4.1 配置 /etc/hosts 和 lsf.cluster.openlava静态节点表怎么写调度器内部通过主机名匹配节点所以集群内所有机器都建议先写好静态解析避免依赖 DNS 带来的不确定性。在 master 和每台计算节点上维护同一个 /etc/hosts192.168.10.11 master 192.168.10.12 comp01 192.168.10.13 comp02 192.168.10.14 comp03IP 和主机名要一一对应并且建议用短主机名。写好 hosts 后编辑/opt/openlava/conf/lsf.cluster.openlava把参与纳管的主机写进去Begin Cluster CLUSTERNAME localcluster MASTERLIST master ADMINHOSTS master End Begin Host HOSTNAME type server rserver resources master Linux 1 1 - comp01 Linux 1 1 - comp02 Linux 1 1 - comp03 Linux 1 1 - EndCLUSTERNAME是集群名必须与lsf.conf或本地配置中的命名一致MASTERLIST指明主控节点只有一个 master 时写一行即可Begin Host段中每个节点一行type表示操作系统类型server和rserver为 1 代表该主机可以作为任务执行主机。修改静态配置后必须重启 LIM 和 mbatchd 才会生效具体做法是lsadmin limshutdown lsadmin limstartup badmin mbdrestart打开这个文件时如果你发现模板里已经有Begin Host不要删除其他段只修改 HOSTNAME 和 IP 对应关系即可。静态配置负责定义“这台机器是否属于集群”而后续的动态命令负责调整“当前是否接活”。4.2 用 badmin 动态管理节点add/delete 的实际效果静态配置之外的运行时调整openlava 通过 badmin 命令完成。比如临时把一台新机器纳入计算资源badmin -a hostadd comp04 bhosts -l comp04执行后如果 comp04 在bhosts里从unavail变成ok说明主控进程已经成功在它上面启动 sbatchd。同样地把下线的节点移除badmin -a hostdel comp04 bhosts这里必须注意badmin hostadd只影响调度器的运行状态不会回写lsf.cluster.openlava文本配置。如果 master 重启或集群重启动态添加的节点会消失。所以临时扩容之后别忘了把节点真正登记到静态配置文件里否则每次重启都要重新执行。这也是我经历过的最隐蔽的坑看似节点已经加入一个意外重启后队列资源凭空少一半。4.3 作业提交验证bsub 排队到执行的完整链路节点就绪后用最简单的方式提交作业从头到尾验证整条链路bsub -q normal -n 2 -o /tmp/my_job.%J.log sleep 60 bjobs bhostsbsub -q normal指定队列-n 2申请两个槽位-o /tmp/my_job.%J.log把作业的标准输出写到/tmp/my_job.作业号.log其中%J是作业号占位符提交后会替换成真实编号。然后跑bjobs查看作业状态刚开始是 PEND调度器找到空闲槽位后变成 RUN执行完成退出后变成 DONE。bhosts可以看到当前节点的负载和已用槽位这能确认作业实际落在哪台上。如果bjobs一直 PEND用bqueues -l normal检查队列状态再确认槽位是否被占满。如果作业一提交就报错返回第 5 章看看常见原因。这条链路走通后集群已经从“手工分发脚本”变成了“排队执行”后续要做的只是把任务用 bsub 包起来。5. openlava 部署避坑新手最容易翻车的 5 个细节我在不同环境里部署 openlava踩过的坑可以整理成一张黑名单。下面是出现频率最高的 5 个问题每条按“现象 → 原因 → 解决”来说明希望能帮你省掉排查时间。5.1 现象lsadmin limstartup 提示 “Another LIM is alive”执行lsadmin limstartup时报错说 LIM 已经在运行但bhosts又看不到正常输出。原因一般是两种之前启动过 LIM 进程没有完全退出或者/tmp下的 LIM 临时文件属主错乱。解决时先查看进程ps -ef | grep -E lim|mbatchd | grep -v grep确认有残留进程就直接lsadmin limshutdown停掉如果进程已经不存在但文件属主不对清理/tmp下 openlava 相关临时文件后以 openlava 用户重新启动。要避免这个问题部署全程尽量使用同一个系统账户操作不要一会儿 root 一会儿 openlava。5.2 现象作业一直 PEND状态永远是 PEND提交后bjobs看到作业停在 PEND 不走这是新手最常问的问题。原因无外乎三类队列被关闭了、队列上没有可用槽位、节点状态进入不可用。检查命令bqueues -l normal bhosts badmin mbdrestartbqueues -l normal会显示队列是否为 Openbhosts能直接看到各主机的状态和剩余槽位。如果节点状态是unavail多半是 sbatchd 没起来用badmin hstartup补起如果队列显示 Closed编辑lsb.queues把队列打开并重启 mbatchd。5.3 现象bsub 提交后立即报 “Cannot find a suitable queue”作业提交时系统找不到可用队列。最常见原因是提交用户没有被加入lsb.users的允许列表或者提交主机不在lsb.hosts定义范围内。先用bqueues查看当前队列的 ACCESS 字段bqueues -l normal如果 normal 队列只允许某个分组提交把当前用户加进对应分组或者用bsub -q明确指定一个有权限的队列。这种事最容易发生在升级用户权限之后新用户只加了系统账户忘了同步到调度器配置里。5.4 现象跨节点作业偶发失败日志里只有信号 9多节点跑任务时作业日志里只有一行信号 9 的信息看起来像是被外部杀掉。原因通常是任务实际内存超过了节点限制触发内核 OOM另一个可能是工作目录在 master 和计算节点上路径不一致。排查时先看系统日志确认有没有 OOM 记录再用资源申请参数显式限制bsub -R rusage[mem4096] -n 2 ./job.sh-R rusage[mem4096]告诉调度器这个作业预估要 4096 MB 内存调度器会把它安排到有足够内存的节点。同时确认所有计算节点都挂了共享存储并且路径一致比如统一挂/data。路径不一致时作业在计算节点上找不到输入文件脚本退出也会留下类似半途终止的痕迹。5.5 现象重启后调度器起不来/tmp 下的 sock 文件权限错乱系统重启后lsadmin limstartup等命令报权限错误查看/tmp发现调度器生成的 socket 文件属主是 root但当前启动用户是 openlava。原因是第一次测试时用 root 启动过服务socket 文件没有随进程退出被删干净。解决方法是停止所有服务、删除这些临时文件、再切换用户启动lsadmin limshutdown badmin mbdshutdown rm -f /tmp/.openlava* /tmp/lim* /tmp/sbd*这里我习惯把/tmp/.openlava*这类文件单独列出只精确删除调度器相关目录千万不要rm -rf /tmp/*一把梭。清理后再按 openlava 用户启动一般就能恢复。说到教训整个集群只用同一个用户管理调度器可以省掉一大半这类权限玄学问题。6. 最后一个技巧用主机组与作业组做混合负载的可控混部多队列、多项目组混跑时我最常用的是把主机组和作业组组合起来主机组限制作业只能跑到哪些机器作业组则用于限制每个项目组的总负载。二者配合可以在一个集群上安全地混跑 CPU 密集型、内存密集型和短周期任务。比如在配置里定义一个专门吃 IO 的主机组提交时直接指定它bsub -g /project_a -q normal -m compute_io ./run_io.sh-g /project_a把作业归到名为 project_a 的作业组方便统计配额和后续权限控制-m compute_io限定作业只能运行在 compute_io 这个主机组里。如果主机组不存在要先在 lsb.hosts 中声明否则提交会报找不到主机。我自己的习惯是只要有 3 个以上的项目组共享集群先按项目分作业组再按业务类型分主机组调度器里只保留 2 到 3 个队列。这个容器数量越少越不容易乱混合负载也更好观察因为bqueues -l和bhosts的输出会变得非常直观。每次扩节点或加项目组时我都先拿bsub -g提交一个短任务做验收确认落在预期主机组再放量。希望帮到你。本文还有配套的精品资源点击获取