OpenLava 完全入门（五）：生产部署与运维实战
OpenLava 完全入门（五）：生产部署与运维实战
摘要：前面四篇讲了功能和用法，这一篇讲生产环境怎么管。内容涵盖：集群高可用（Master 主备切换）、监控告警（Prometheus + Grafana）、日志管理、性能调优、常见故障排查（LIM 失联、作业卡死、调度慢）、集群扩容缩容、备份恢复、安全加固。最后附上生产环境 Checklist。掌握这些，你就是合格的 OpenLava 运维负责人。
这是 OpenLava 系列的最后一篇，讲生产运维干货。
零、读前必看
0.1 适合谁
- ✅ 负责维护 OpenLava 集群的运维/系统工程师
- ✅ 集群已经在跑，想知道怎么管得稳
- ✅ 想把测试集群升级为生产集群
0.2 你将学到
| 主题 | 重点 |
|---|---|
| 高可用 | Master 主备切换、LIM 选主机制 |
| 监控告警 | 指标采集、Grafana 看板、常见告警规则 |
| 日志管理 | 日志种类、轮转、集中收集 |
| 性能调优 | 调度参数、网络优化、文件系统 |
| 故障排查 | 8 类常见问题 + 排查思路 |
| 扩容缩容 | 加节点 / 减节点流程 |
| 备份恢复 | 配置备份、作业数据备份、灾备 |
| 安全加固 | 用户权限、网络、审计 |
一、高可用架构
1.1 为什么需要高可用
单 Master 节点的 OpenLava 集群有单点故障：Master 挂了 → 整个集群不能提交新作业、调度停了。
生产环境必须做主备。
1.2 OpenLava 的高可用机制
OpenLava 内置了 LIM 选主机制：
┌─────────────┐
│ master01 │ ← 当前 Master（Active）
│ (lim + │
│ mbatchd) │
└──────┬──────┘
│
┌──────┴──────┐
│ master02 │ ← 备节点（Standby）
│ (lim) │
└─────────────┘
│
计算节点连接到 Active Master工作原理：
- 所有节点的 LIM 互相通信
- 配置文件里指定哪些是 Master 候选节点
- 当前 Master 挂了，备用 LIM 自动选举出新的 Master
- mbatchd 跟着在新 Master 上启动
1.3 配置高可用
1.3.1 修改 lsf.cluster
Begin ClusterAdmins
Administrators = lsf
End ClusterAdmins
Begin Master
# 候选 Master 列表，排在前面的优先级高
master01 master02
End Master
Begin Host
HOSTNAME model type server r1m mem swp RESOURCES
master01 IntelI7 linux 1 3.5 32G 64G (mg master candidate)
master02 IntelI7 linux 1 3.5 32G 64G (mg master candidate)
compute01 IntelI7 linux 1 3.5 64G 128G (compute)
compute02 IntelI7 linux 1 3.5 64G 128G (compute)
compute03 IntelI7 linux 1 3.5 64G 128G (compute)
End Host**关键**：`Begin Master / End Master` 段列出候选 Master 节点。
1.3.2 共享存储
Master 上的关键数据需要两台都能访问：
| 数据 | 建议方案 |
|---|---|
$LSF_ENVDIR 配置文件 |
NFS / rsync 同步 |
$LSF_LOGDIR 日志 |
本地（各记各的） |
$LSB_SHAREDIR 作业数据 |
必须共享（NFS） |
# lsf.conf 里配置
LSB_SHAREDIR=/opt/openlava/share
# 这个目录必须放在共享存储上（NFS / NAS）LSB_SHAREDIR 存的是：
- 作业历史数据（
lsb.acct、lsb.events） - 正在运行的作业状态
- mbatchd 的状态文件
**没有共享存储的后果**：主备切换后，mbatchd 丢失作业状态，正在运行的作业信息全没了。
1.4 验证主备切换
# 1. 看当前 Master
lsid
# My cluster name is openlava
# My master name is master01
# 2. 模拟主节点宕机（在 master01 上执行）
lsadmin limshutdown
# 3. 在备节点或任意节点看新 Master
lsid
# My master name is master02 ← 切过去了
# 4. 恢复 master01
lsadmin limstartup
# master01 起来后会接管（因为列表里排在前面）1.5 高可用最佳实践
| 建议 | 说明 |
|---|---|
| Master 节点不跑业务作业 | MXJ=0，避免作业负载影响调度 |
| 两台 Master 配置一样 | 硬件规格、OS 版本、OpenLava 版本都一致 |
| 配置共享存储 | LSB_SHAREDIR 必须在共享存储上 |
| VIP（可选） | 用 Keepalived 配虚拟 IP，用户不用感知切换 |
| 定时验证主备切换 | 每月演练一次，别等真挂了才发现切不过去 |
二、监控告警
2.1 监控什么
| 层级 | 监控项 | 告警阈值参考 |
|---|---|---|
| 系统层 | CPU、内存、磁盘、网络 | 磁盘 > 85%、内存 > 90% |
| 服务层 | LIM、sbatchd、mbatchd、mbschd 进程存活 | 进程挂了立即告警 |
| 集群层 | 可用节点数、空闲槽位数 | 可用节点 < N-1、槽位利用率 > 95% |
| 作业层 | PEND 作业数、失败作业率、长作业 | PEND > 阈值、失败率 > 10% |
| 调度层 | 调度延迟、调度周期 | 调度延迟 > 60s |
2.2 用命令行监控
日常巡检用这些命令：
# 1. 集群状态
lsid # 当前 Master、集群名
bparams # batch 参数
# 2. 主机状态
bhosts # 主机槽位使用
lsload # 主机负载
lshosts # 主机属性
# 3. 队列状态
bqueues # 队列使用情况
bqueues -l # 详细
# 4. 作业状态
bjobs -u all # 所有作业
bjobs -sum -u all # 汇总统计
bjobs -p -u all | wc -l # PEND 作业数
# 5. 用户使用
busers # 用户 FairShare 使用
bacct -u all -d # 昨日作业统计
# 6. 调度器状态
badmin showstatus # mbatchd 状态2.3 Prometheus + Grafana 监控
推荐用 openlava_exporter（社区有开源实现），核心指标：
# 核心指标（示例）
openlava_nodes_total{status="ok"} # 在线节点数
openlava_nodes_total{status="unavail"} # 失联节点数
openlava_slots_total # 总槽位数
openlava_slots_used # 已用槽位数
openlava_jobs_total{status="RUN"} # RUN 作业数
openlava_jobs_total{status="PEND"} # PEND 作业数
openlava_jobs_total{status="EXIT"} # 失败作业数
openlava_queue_slots_used{queue="normal"} # 队列槽位使用2.4 关键告警规则
# 1. Master 节点宕机
- alert: MasterDown
expr: openlava_master_status == 0
for: 1m
severity: critical
# 2. 计算节点失联 > 1
- alert: ComputeNodeDown
expr: openlava_nodes_total{status="unavail"} > 1
for: 5m
severity: warning
# 3. PEND 作业太多
- alert: TooManyPendingJobs
expr: openlava_jobs_total{status="PEND"} > 100
for: 10m
severity: warning
# 4. 槽位利用率过高
- alert: SlotUtilizationHigh
expr: openlava_slots_used / openlava_slots_total > 0.95
for: 30m
severity: warning
# 5. 作业失败率高
- alert: HighJobFailureRate
expr: rate(openlava_jobs_total{status="EXIT"}[1h]) / rate(openlava_jobs_total[1h]) > 0.1
for: 1h
severity: warning
# 6. 磁盘满
- alert: DiskAlmostFull
expr: node_filesystem_avail_bytes / node_filesystem_size_bytes < 0.15
for: 5m
severity: warning2.5 日常巡检脚本
写个脚本每天早上自动发巡检报告：
#!/bin/bash
# /opt/openlava/scripts/daily_check.sh
echo "========== OpenLava 每日巡检报告 =========="
echo "时间: $(date)"
echo
echo "--- 集群信息 ---"
lsid
echo
echo "--- 节点状态 ---"
bhosts
echo
echo "--- 队列状态 ---"
bqueues
echo
echo "--- 作业统计 ---"
echo "RUN: $(bjobs -r -u all 2>/dev/null | wc -l)"
echo "PEND: $(bjobs -p -u all 2>/dev/null | wc -l)"
echo "SUSP: $(bjobs -s -u all 2>/dev/null | wc -l)"
echo
echo "--- TOP 5 用户（按运行作业数）---"
bjobs -u all 2>/dev/null | awk 'NR>1 {print $2}' | sort | uniq -c | sort -rn | head -5三、日志管理
3.1 日志种类
| 日志文件 | 位置 | 内容 | 谁写的 |
|---|---|---|---|
lim.log. |
$LSF_LOGDIR |
LIM 日志（资源采集、选主） | LIM |
mbatchd.log |
$LSB_SHAREDIR/log |
mbatchd 日志（作业接收、调度） | mbatchd |
mbschd.log |
$LSB_SHAREDIR/log |
调度器日志（调度决策） | mbschd |
sbatchd.log. |
$LSF_LOGDIR |
sbatchd 日志（本地作业管理） | sbatchd |
res.log. |
$LSF_LOGDIR |
res 日志（执行代理） | res |
lsb.acct |
$LSB_SHAREDIR/log |
作业记账日志 | mbatchd |
lsb.events |
$LSB_SHAREDIR/log |
作业事件流 | mbatchd |
# 查看日志目录
echo $LSF_LOGDIR
ls -la $LSF_LOGDIR3.2 常用排错日志
| 问题 | 看哪个日志 |
|---|---|
| 节点失联 | lim.log. |
| 作业调度异常 | mbatchd.log / mbschd.log |
| 作业执行失败 | sbatchd.log. / res.log. |
| 主备切换 | 两个节点的 lim.log |
| 作业历史分析 | lsb.acct |
3.3 日志轮转
日志文件会越来越大，必须配置轮转：
# /etc/logrotate.d/openlava
/opt/openlava/log/*.log /opt/openlava/share/log/*.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
copytruncate
dateext
}**关键参数**：
- `copytruncate`：先复制再清空，不用重启进程
- `rotate 30`：保留 30 天
- `compress`：压缩老日志
3.4 日志集中收集
生产环境建议把日志集中到 ELK / Loki：
计算节点日志 → Filebeat → Elasticsearch → Kibana
↑
Master 日志关键查询：
level:ERROR：所有错误lim：LIM 相关日志mbatchd：调度相关job exit：作业异常退出
四、性能调优
4.1 调度参数调优
lsb.params 里的关键参数：
Begin Parameters
MBD_SLEEP_TIME = 10 # mbatchd 调度间隔（秒），默认 60，调低响应更快
SBD_SLEEP_TIME = 7 # sbatchd 汇报间隔
JOB_SCHEDULING_INTERVAL = 30 # 作业调度间隔
MAX_RSCHED_TIME = 60 # 单次调度最长时间
CONCURRENT_QUERY_MAX = 50 # 并发查询数
End Parameters调小 MBD_SLEEP_TIME：调度更频繁，短作业响应更快。但 Master CPU 消耗增加。
调大 MBD_SLEEP_TIME：Master 负载低，但调度延迟高。
**经验值**：
- 小集群（< 50 节点）：`MBD_SLEEP_TIME = 10`
- 中集群（50-200 节点）：`MBD_SLEEP_TIME = 20`
- 大集群（> 200 节点）：`MBD_SLEEP_TIME = 30-60`
4.2 LIM 采集间隔
lsf.conf 里：
LSF_LIM_INTERVAL = 30 # LIM 采集间隔（秒）
LSF_SBD_INTERVAL = 30 # sbatchd 心跳间隔4.3 网络优化
| 优化项 | 建议 |
|---|---|
| Master 和计算节点用同一网段 | 减少延迟 |
| 万兆网络 | 节点间数据传输快 |
| 网卡绑定（bonding） | 高可用 + 带宽 |
| TCP 参数调优 | net.core.somaxconn = 1024 等 |
4.4 文件系统优化
| 目录 | 建议 |
|---|---|
LSB_SHAREDIR |
NAS / 分布式存储（不能是本地盘） |
| 作业工作目录 | NFS / Lustre / GPFS（共享 + 高性能） |
tmp 目录 |
本地 SSD（临时文件读写快） |
| 日志目录 | 本地盘（避免网络影响日志写入） |
4.5 Master 节点资源
Master 节点规格建议：
| 集群规模 | CPU | 内存 | 磁盘 |
|---|---|---|---|
| < 50 节点 | 8 核 | 16G | 200G SSD |
| 50-200 节点 | 16 核 | 32G | 500G SSD |
| > 200 节点 | 32 核 | 64G | 1T SSD |
Master 是调度大脑，**不能省资源**。CPU 不够 → 调度慢 → 作业排队多。
五、常见故障排查
5.1 节点失联（unavail）
# 现象
bhosts
# compute01 unavail ...
# 排查步骤
# 1. 网络通不通
ping compute01
ssh compute01 hostname
# 2. 进程在不在
ssh compute01 ps aux | grep lim
# 3. 看日志
ssh compute01 tail -100 $LSF_LOGDIR/lim.log.compute01
# 4. 重启 LIM
lsadmin limrestart compute01
badmin hrestart compute01常见原因：
- 机器宕机 / 网络断了
- LIM 进程异常退出
/etc/hosts改了，主机名解析不对- 时间不同步（NTP 挂了）
5.2 作业一直 PEND
# 第一步：看 PEND 原因
bjobs -p <jobid>
# 第二步：看节点资源
bhosts
lsload
# 第三步：看队列限制
bqueues -l <queue>
# 第四步：看调度日志
tail -f $LSB_SHAREDIR/log/mbschd.log常见原因：
| 原因 | 排查 |
|---|---|
| 槽位不够 | bhosts 看 NJOBS / MAX |
| 资源不足 | bjobs -p 看需求，lsload 看实际 |
| 队列上限 | bqueues -l 看 QJOB_LIMIT |
| 用户上限 | busers 看 UJOB_LIMIT |
| 依赖没满足 | bjobs -l 看依赖条件 |
| 调度窗口没到 | 队列的 DISPATCH_WINDOW |
5.3 作业 RUN 但没输出
# 1. 看作业有没有真在跑
bpeek -f <jobid>
# 2. 进节点看进程
ssh <exec_host> ps aux | grep <jobname>
# 3. 看 sbatchd 日志
ssh <exec_host> tail -100 $LSF_LOGDIR/sbatchd.log.<host>常见原因：
- 程序卡死（死循环 / 等 IO）
- 输出缓冲没刷新（加
stdbuf -oL或 fflush） - 挂在某个等待上（等 license、等文件锁）
5.4 作业 EXIT 异常退出
# 1. 看退出码
bjobs -l <jobid> | grep Exit_code
# 2. 看错误输出
cat <job_err_file>
# 3. 看作业历史
bhist -l <jobid>退出码速查：
| 退出码 | 含义 |
|---|---|
| 0 | 正常结束（DONE 状态） |
| 1 | 程序错误（通用失败） |
| 130 | 被 Ctrl+C / SIGINT 杀掉 |
| 137 | 被 bkill -r / SIGKILL 杀掉 |
| 139 | 段错误（Segfault） |
| 143 | 被 SIGTERM 杀掉（正常 bkill） |
| -10 / 138 | 被 bkill（SIGBUS 等） |
5.5 Master 切换后调度不工作
# 1. 确认新 Master
lsid
# 2. mbatchd 起来了吗
ps aux | grep mbatchd
# 3. 看 mbatchd 日志
tail -100 $LSB_SHAREDIR/log/mbatchd.log
# 4. 手动重配置
badmin reconfig常见原因：
LSB_SHAREDIR共享目录没挂载上- 新 Master 上的 mbatchd 启动失败
- 配置文件不完整（没同步过来）
5.6 调度变慢
# 1. 看 Master CPU
top # 看 mbatchd / mbschd CPU 使用率
# 2. 看调度周期
# mbschd.log 里每次调度的耗时
# 3. 看作业总数
bjobs -u all | wc -l常见原因：
- Master CPU 不够
- 作业量太大（几千个 PEND 作业）
- 资源需求太复杂（导致调度计算慢）
- 日志盘 I/O 慢
5.7 数据不完整 / 作业历史丢失
# 检查 lsb.acct 文件
ls -la $LSB_SHAREDIR/log/lsb.acct*
# 检查 lsb.events
ls -la $LSB_SHAREDIR/log/lsb.events*常见原因：
- 磁盘满了（日志轮转失败，写不进去）
- 共享存储断了
- 手动删了日志
5.8 用户提交作业报权限错
# 1. 用户在不在允许列表里
bqueues -l <queue> | grep USERS
# 2. 用户在 lsf.users 里吗
cat $LSF_ENVDIR/lsf.users
# 3. 看 mbatchd 日志
grep <user> $LSB_SHAREDIR/log/mbatchd.log | tail -20六、集群扩容缩容
6.1 加计算节点
# ===== 新节点上操作 =====
# 1. 基础配置（hostname / hosts / NTP / 关防火墙 / 创建 lsf 用户）
# （参考第一篇）
# 2. 安装 OpenLava（从现有节点 scp 过去）
scp -r master:/opt/openlava /opt/
chown -R lsf:lsf /opt/openlava
# 3. 配置环境变量
scp master:/etc/profile.d/openlava.sh /etc/profile.d/
source /etc/profile.d/openlava.sh
# 4. 挂载 NFS（如果有）
echo "master:/home/lsf /home/lsf nfs defaults 0 0" >> /etc/fstab
mount -a
# ===== Master 上操作 =====
# 5. 修改 lsf.cluster，加入新节点
vi $LSF_ENVDIR/lsf.cluster.openlava
# 在 Host 段加一行：
# compute04 IntelI7 linux 1 3.5 64G 128G (compute)
# 6. 修改 lsb.hosts
vi $LSF_ENVDIR/lsb.hosts
# 加一行：compute04 8 - () 1.00
# 7. 重新加载配置
lsadmin reconfig
badmin reconfig
# 8. 在新节点启动服务
ssh compute04 "su - lsf -c 'lsadmin limstartup && lsadmin resstartup && badmin hstartup'"
# 9. 验证
bhosts compute04
lsload compute046.2 减计算节点
# 1. 关闭节点（不再接新作业）
badmin hclose compute04
# 2. 等现有作业跑完（或手动杀掉）
badmin -m compute04 bjobs # 看上面还有没有作业
# 3. 停服务
badmin hshutdown compute04
lsadmin limshutdown compute04
lsadmin resshutdown compute04
# 4. 从配置里移除（可选）
# vi lsf.cluster.openlava
# vi lsb.hosts
# lsadmin reconfig
# badmin reconfig**安全下线**：先 `hclose` 不接新作业，等老作业跑完再停机，不要直接拔电源。
七、备份与恢复
7.1 什么需要备份
| 内容 | 频率 | 保留时长 |
|---|---|---|
配置文件（$LSF_ENVDIR） |
每天 / 每次修改 | 30 天 |
作业数据（$LSB_SHAREDIR） |
每天 | 90 天 |
| 日志文件 | 每天 | 30 天 |
| 用户数据（家目录） | 每天 | 按业务要求 |
7.2 备份脚本
#!/bin/bash
# /opt/openlava/scripts/backup.sh
BACKUP_DIR=/data/backup/openlava
DATE=$(date +%Y%m%d_%H%M)
mkdir -p $BACKUP_DIR
# 1. 配置文件
tar czf $BACKUP_DIR/config_$DATE.tar.gz -C /opt/openlava etc/
# 2. 作业数据
tar czf $BACKUP_DIR/share_$DATE.tar.gz -C /opt/openlava share/
# 3. 删除 30 天前的备份
find $BACKUP_DIR -name "*.tar.gz" -mtime +30 -delete
echo "Backup completed: $DATE"加到 crontab：
0 2 * * * /opt/openlava/scripts/backup.sh >> /var/log/openlava_backup.log 2>&17.3 恢复流程
# 1. 停掉所有服务
lsadmin limshutdown all
badmin hshutdown all
# 2. 恢复配置
tar xzf config_YYYYMMDD_HHMM.tar.gz -C /opt/openlava
# 3. 恢复作业数据
tar xzf share_YYYYMMDD_HHMM.tar.gz -C /opt/openlava
# 4. 重启服务
lsadmin limstartup
badmin hstartup
# 5. 验证
lsid
bhosts
bqueues八、安全加固
8.1 用户权限
| 措施 | 说明 |
|---|---|
限制 badmin 用户 |
只有集群管理员能执行 badmin |
| 队列级用户控制 | USERS 参数限制谁能提交 |
| 项目级控制 | 用 -P project 分类计费 |
| 禁止 root 提交 | 一般不让 root 直接跑作业 |
8.2 网络安全
| 措施 | 说明 |
|---|---|
| 防火墙限制 | 只开放必要端口（6881、6882 等） |
| 内网部署 | 计算节点不接公网 |
| SSH 加固 | 计算节点只允许特定 IP 登录 |
8.3 审计
# lsb.acct 记录了所有作业，可以做审计
# 谁、什么时候、跑了什么、用了多少资源
# 月度审计示例
bacct -u all -b "2024:01:01" -e "2024:01:31" > jan_usage.txt九、生产环境 Checklist
部署到生产前，逐项打勾：
架构：
- [ ] Master 节点 HA（至少 2 台候选）
- [ ]
LSB_SHAREDIR在共享存储上 - [ ] NTP 时间同步（所有节点）
- [ ] DNS / hosts 解析正确
资源：
- [ ] Master CPU/内存足够
- [ ] 计算节点资源规划合理（CPU/内存比例）
- [ ] 共享存储容量满足需求
监控：
- [ ] 基础监控（CPU/内存/磁盘/网络）
- [ ] OpenLava 服务监控（LIM/mbatchd 进程）
- [ ] 关键告警（节点宕机、PEND 堆积、磁盘满）
- [ ] 日常巡检脚本 / 报表
安全：
- [ ] 防火墙配置
- [ ] 管理员用户受限
- [ ] 队列用户权限划分
- [ ] 审计日志开启
运维：
- [ ] 备份脚本（配置 + 数据 + 日志）
- [ ] 备份恢复演练过
- [ ] 主备切换演练过
- [ ] 扩容缩容流程文档化
- [ ] 故障排查 SOP 文档
十、写在最后
五篇 OpenLava 教程到这里就结束了。回顾一下整个系列：
- 入门篇 — 认识 OpenLava + 从零部署
- 作业管理篇 — bsub / bjobs / bkill 等核心命令
- 队列资源篇 — 队列配置 + 自定义资源 +
-R表达式 - 高级功能篇 — 并行 / 依赖 / 数组 / FairShare
- 生产运维篇 — HA / 监控 / 调优 / 排错 / 备份
从"是什么"到"怎么用"再到"怎么管"，一条线走下来。
OpenLava 是一个功能完整且稳定的开源调度系统，EDA、渲染、科研计算等场景用它完全够用。社区虽然不如 Slurm 活跃，但胜在 LSF 兼容、上手简单、运维成本低。
生产环境真正的挑战不在于功能，而在于：
- 监控够不够完善（出事了能不能第一时间知道）
- 排查流程清不清晰（出问题了能不能快速定位）
- 文档完不完备（换人了能不能接手）
把这三件事做好，集群就稳了。
本系列五篇全部完成。你觉得哪一篇最有用？有没有想深入了解的话题？ 评论区告诉我。
OpenLava #LSF #高可用 #监控 #运维 #故障排查 #HPC #生产环境
声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。
