前言
在完成了 LSF Suite 的安装和网络配置后，集群虽然”跑起来了”，但它真的健康吗？GPU 资源是否被正确识别？容器作业能否顺利调度？
本篇将提供一份系统管理员必备的健康检查清单，帮助您通过标准化的测试流程，快速验证 LSF 集群的核心功能是否就绪。
一、系统服务状态检查
LSF Suite 的守护进程（Daemons）由 systemd 统一管理。根据节点角色的不同（Master、Server、Client 或 GUI Host），运行的服务也不同。
1. 角色与服务对照表
在检查之前，请参考下表确认各节点应运行的服务：
| 服务名称 | LSF Masters | LSF Servers | LSF Clients | GUI Hosts |
|---|---|---|---|---|
| lsfd (核心服务) | ✅ | ✅ | ❌ | ✅ |
| acd (应用中心) | ❌ | ❌ | ❌ | ✅ |
| explorer (报表中心) | ❌ | ❌ | ❌ | ✅ |
| elasticsearch-for-lsf | ❌ | ❌ | ❌ | ✅ |
| filebeat-for-lsf | ✅ | ✅ | ❌ | ✅ |
| kibana-for-lsf | ❌ | ❌ | ❌ | ✅ (首个节点) |
2. 检查命令
使用 systemctl status <服务名> 来检查服务状态。例如，在 Master 节点上检查核心服务 lsfd：
1
2
3
4
5
6
7
8
9
# systemctl status lsfd
● lsfd.service - IBM Spectrum LSF
Loaded: loaded (/etc/systemd/system/lsfd.service; enabled)
Active: active (running) since ...
CGroup: /system.slice/lsfd.service
├─ 1234 lim
├─ 1235 res
├─ 1236 sbatchd
└─ 1237 mbatchd
如果服务状态显示为 Active: active (running)，且列出了 lim, res, sbatchd, mbatchd 等子进程，说明 LSF 基础服务启动正常。
二、LSF 核心守护进程检查
确认系统服务启动后，需要使用 LSF 自身命令检查集群逻辑状态。
注意：以下调试命令建议从主 Master 节点开始执行。
1. 验证 Master 状态 (lsid)
1
2
3
4
5
6
$ lsid
IBM Spectrum LSF 10.1.0.15, May 2025
Copyright International Business Machines Corp. 1992, 2025.
My cluster name is cluster1
My master name is master1
| 结果 | 说明 |
|---|---|
| ✅ 正常 | 显示集群名称和 Master 主机名 |
| ❌ 超时 | Master 未就绪，需检查服务日志 |
2. 验证节点资源与 LIM 状态
检查主机配置 (lshosts)
1
2
3
4
5
$ lshosts
HOST_NAME type model cpuf ncpus maxmem maxswp server RESOURCES
master1 linux X86_64 100.0 32 125G 62G Yes (mg)
compute1 linux X86_64 100.0 64 250G 125G Yes ()
compute2 linux X86_64 100.0 64 250G 125G Yes ()
检查输出中的 RESOURCES 字段，Master 节点应标记为 (mg)（管理组）。
检查负载状态 (lsload)
1
2
3
4
5
$ lsload
HOST_NAME status r15s r1m r15m ut pg ls it tmp swp mem
master1 ok 0.0 0.0 0.0 0% 0.0 1 0 100G 62G 120G
compute1 ok 0.0 0.0 0.0 0% 0.0 0 0 200G 125G 245G
compute2 unavail - - - - - - - - - -
| status | 含义 | 排查方向 |
|---|---|---|
ok |
✅ 正常 | - |
unavail |
❌ 不可达 | lim 守护进程未运行或被防火墙阻塞 |
3. 验证批处理系统状态 (bhosts)
1
2
3
4
5
$ bhosts
HOST_NAME STATUS JL/U MAX NJOBS RUN SSUSP USUSP RSV
master1 ok - 0 0 0 0 0 0
compute1 ok - 64 0 0 0 0 0
compute2 unreach - - - - - - -
| STATUS | 含义 | 排查思路 |
|---|---|---|
ok |
✅ 正常 | - |
unreach |
❌ 不可达 | sbatchd 守护进程有问题 |
unreach 状态排查清单
1
2
3
4
5
6
7
8
9
10
11
12
13
14
┌─────────────────────────────────────────────────────────────┐
│ bhosts 显示 unreach 排查流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 检查防火墙是否阻塞了 TCP 6882 端口 │
│ $ firewall-cmd --list-ports | grep 6882 │
│ ↓ │
│ 2. 检查机器报告的主机名与部署时的名称是否一致 │
│ $ hostname -f │
│ ↓ │
│ 3. 多网卡环境：检查 Private_IPv4_Range 是否正确配置 │
│ 确保通信没有走错误的网卡 │
│ │
└─────────────────────────────────────────────────────────────┘
三、基础作业提交测试
LSF 是批处理调度器，必须通过实际提交作业来验证。
1. 命令行 (CLI) 测试
注意：默认情况下，root 用户禁止提交作业。请切换到普通用户进行测试。
1
2
$ bsub sleep 60
Job <202> is submitted to default queue <normal>.
如果返回 Job ID，说明提交成功。
检查作业状态
1
2
3
$ bjobs
JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME
202 user1 RUN normal master1 compute1 sleep 60 Dec 12 17:30
2. 图形界面 (GUI) 测试
- 访问
http://{GUI Host name}:8080并以普通用户登录 - 导航至 Workload → New Workload
- 选择 generic 应用程序
- 在 Command 中输入
sleep 60并点击提交 - 在 Workload 仪表盘中应能看到该作业处于
Running或Done状态
四、GPU 资源与调度检查
对于 AI/HPC 集群，GPU 是核心资产。
1. 前提条件
- 集群已安装 CUDA
- 在
lsf.conf中配置了LSF_GPU_AUTOCONFIG=Y
2. 验证 GPU 识别
运行以下命令查看 LSF 识别到的 GPU 拓扑：
1
2
3
4
5
6
$ lshosts -gpu
HOST_NAME gpu_id gpu_model gpu_driver gpu_factor numa_id
compute1 0 TeslaV100 450.80 11.0 0
compute1 1 TeslaV100 450.80 11.0 0
compute1 2 TeslaV100 450.80 11.0 1
compute1 3 TeslaV100 450.80 11.0 1
输出应包含 GPU 型号、驱动版本及 NUMA 亲和性信息。
3. 提交 GPU 测试作业
通过提交一个请求 GPU 的交互式作业来验证调度功能：
1
$ bsub -gpu "num=1" -I nvidia-smi
预期输出
1
2
3
4
5
6
7
8
9
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 450.80 Driver Version: 450.80 CUDA Version: 11.0 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla V100-SXM2... On | 00000000:3B:00.0 Off | 0 |
| N/A 32C P0 42W / 300W | 0MiB / 32510MiB | 0% Default |
+-------------------------------+----------------------+----------------------+
如果输出显示了 GPU 信息且没有运行其他进程（显存占用为 0 或极低），说明 LSF 成功调度并隔离了 GPU 资源。
测试多卡调度
1
$ bsub -gpu "num=2" -I nvidia-smi
五、Docker 容器支持检查
验证 LSF 能否正确驱动 Docker 容器运行作业。
1. 准备工作
- 确保
lsfadmin用户有权限执行 docker 命令（通常需要加入 docker 组） - 在
lsb.applications中配置好 Docker 应用模板
1
2
3
4
5
6
# lsb.applications 示例配置
Begin Application
NAME = ubuntu
DESCRIPTION = Ubuntu container
CONTAINER = docker[image(ubuntu:18.04)]
End Application
2. 提交容器测试作业
1
$ bsub -I -app ubuntu cat /etc/os-release
预期输出
1
2
3
4
5
NAME="Ubuntu"
VERSION="18.04.6 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
...
如果输出显示了容器内部的 OS 版本信息（例如 Ubuntu 18.04），而不是宿主机的系统信息，说明容器作业调度成功。
健康检查清单总结
| 检查项 | 命令 | 正常结果 |
|---|---|---|
| 系统服务 | systemctl status lsfd |
active (running) |
| Master 状态 | lsid |
显示集群名和 Master 名 |
| 节点负载 | lsload |
所有节点 status=ok |
| 批处理状态 | bhosts |
所有节点 STATUS=ok |
| 作业提交 (CLI) | bsub sleep 60 |
返回 Job ID |
| 作业提交 (GUI) | Web Portal | 作业显示 Running/Done |
| GPU 识别 | lshosts -gpu |
显示 GPU 型号和拓扑 |
| GPU 调度 | bsub -gpu "num=1" -I nvidia-smi |
GPU 信息正确显示 |
| 容器调度 | bsub -I -app ubuntu cat /etc/os-release |
显示容器 OS 信息 |
下期预告：
集群健康检查通过后，它的性能表现如何？如何运行 HPL 或 STREAM 等标准基准测试来评估集群算力？在下一篇《IBM Spectrum LSF Suite 最佳实践 (4)：HPC 性能调优实战——HPL、OSU 与 STREAM》中，我们将手把手教您在 LSF 上运行经典的 HPC 跑分程序。
