SOP — LSF 集群切换 cgroup v1（恢复作业级资源限制）

• 变更类型：C 类生产变更（改内核启动参数 + 重启节点，需停机）
• 实现体：/home/rain/Documents/LSF/lsf_ins/deploy/lsf/，阶段名 cgroup
• 文档地位：第 5 章为实现等价的操作序列，供复核与手工兜底；以实现体为准

一、背景

集群运行 IBM Spectrum LSF CE 10.1.0.12（FP12），二进制平台目录为 linux2.6-glibc2.3-x86_64， 该代二进制只支持 cgroup v1；而 5 台节点（Rocky 9.8）默认挂载 cgroup v2（/sys/fs/cgroup = cgroup2fs）， 守护进程启动即报：

cg_load_hierarchies: Please use the LSF package with higher glibc version
                     to enable LSF cgroup v2 support.

后果：作业级资源限制无法落地（lsb.params 里 LSB_NCPU_ENFORCE=1 形同虚设）。

原本的正解是升级到 FP15/FP16（新平台目录 linux3.10-glibc2.17-x86_64，支持 cgroup v2）， 但两条官方取介质通道均已实测走不通：

通道	实测结果
early-access（CE 免费包）	登录后返回 US Export Validation is Under Review，下载权限卡在美国出口管制审查
Fix Central（SPK，如 FP16 lsf-10.1-spk-2026-Jun-build603045）	已到下载页，被授权拦下：IBMAVS5548 未找到适用的 IBM 支持协议

因此改走「把运行时切回 cgroup v1」，让现有 FP12 二进制的资源限制能力恢复可用。

二、目标

#	可验证状态
1	5 台 /sys/fs/cgroup 文件系统类型为 tmpfs（即 cgroup v1 已生效）
2	5 台内核条目均含 systemd.unified_cgroup_hierarchy=0（grubby --info=ALL 可查）
3	lim/sbatchd 日志不再出现 to enable LSF cgroup v2 support 提示
4	bhosts -w 5 台全 ok；lsfd.service 全 active（重启后自动拉起，单元已 enabled）
5	作业级 CPU 限制可落地：bsub -n 2 的作业进程 Cpus_allowed_list 仅含 2 个核
6	幂等：再次执行 --stage cgroup 判「零变更、全跳过」

本次不启用内存硬限制（LSB_MEMLIMIT_ENFORCE=Y 未写入 lsb.params），按用户决定留待后续。

三、前置条件

• 作业：bjobs -u all 无活动作业（实现体在 pre_check 中强制校验，非 0 即拒停）。
• 权限：5 台 root SSH 免密可达；grubby 已安装（Rocky 默认自带）。
• 固件与引导：5 台均为 BIOS 固件，引导配置为 /boot/grub2/grub.cfg（实现体按此路径备份）。
• 可重启性：5 台为 KVM 虚拟机（运行 qemu-guest-agent），重启可接受。
• 配置：deploy/lsf/config/lsf_deploy.yaml 的 cgroup 段已就位（enable_v1: true）。
• 集群基线：执行前 bhosts -w 5/5 ok、lsf-health.timer 与 lsf-user-sync.timer active。

四、影响范围

• 主机：全部 5 台（192.168.31.23~27）。
• 是否停服：是，逐台滚动重启；每台重启期间该节点不可用、其上不承载作业。 滚动顺序固定为 worker → candidate master → primary master，任一时刻保留可用 master。
• 窗口：从 --stage cgroup 启动到 5 台全部回到 ok；单台等待上限由 cgroup.reboot_timeout_sec（默认 600 s）控制。
• 在跑作业：停机前必须为空（见第三章）。
• 联动：变更期间暂停 lsf-health.timer（其 missing-daemon 自愈会干扰节点状态判定），结束后自动恢复。
• 不可逆点：无。GRUB 参数可移除、配置全部有备份；旧平台与业务数据不受影响。
• 旁路影响：primary master（master-01）重启期间由 master-02 接管调度（数分钟），属预期行为； 恢复后 master 角色可能保留在 master-02，不影响集群功能（与 failover 演练后的表现一致）。

五、分步操作

对应实现体：deploy/lsf/stages/cgroup_v1.py::CgroupV1Module（生命周期由 base_module.BaseModule.run() 编排） 下列命令忠实反映实现体步骤，供人工复核与兜底；以实现体为准。

5.1 预演（零改动，先看清将动什么）

cd /home/rain/Documents/LSF/lsf_ins/deploy/lsf
.venv/bin/python main.py --config config/lsf_deploy.yaml --stage cgroup --dry-run
# 预期：打印 5 台 × [grub_arg, runtime_v1] 的变更清单，状态 skipped，无任何系统改动

5.2 正式执行（一键）

.venv/bin/python main.py --config config/lsf_deploy.yaml --stage cgroup

预期日志顺序：门禁通过（无 BLOCK）→ 检测到漂移 5 台 → 备份 GRUB → 写内核参数 → 暂停 lsf-health.timer → 逐台滚动重启并等待就绪 → 恢复 timer → 验证通过（5 台 cgroup v1 + bhosts 5 ok）。

5.3 实现体内部等价序列（复核 / 手工兜底）

# ① 红线：停机前确认无活动作业（实现体 pre_check 自动执行）
ssh root@192.168.31.23 'su - ldapadmin -s /bin/bash -c "bash -lc \"bjobs -u all\""'
#    预期：No unfinished job found

# ② 备份 GRUB（高危：改启动配置；实现体 backup() 自动执行）
for h in 23 24 25 26 27; do
  ssh root@192.168.31.$h "cp -a /etc/default/grub /etc/default/grub.bak.$(date +%Y%m%d-%H%M%S); \
    cp -a /boot/grub2/grub.cfg /boot/grub2/grub.cfg.bak.$(date +%Y%m%d-%H%M%S)"
done

# ③ 写内核参数（grubby 对 ALL 内核条目生效，幂等：重复执行结果一致）
for h in 23 24 25 26 27; do
  ssh root@192.168.31.$h 'grubby --update-kernel=ALL \
    --args="systemd.unified_cgroup_hierarchy=0" && \
    grubby --info=ALL | grep -c unified_cgroup_hierarchy=0'
done
#    预期：每台输出 ≥ 1

# ④ 暂停健康巡检，避免重启判定被自愈干扰
ssh root@192.168.31.23 'systemctl stop lsf-health.timer'

# ⑤ 逐台滚动重启（worker → master-02 → master-01；每台先摘除调度）
#    实现体对每台执行：badmin hclose <name> → systemctl reboot → 轮询就绪 → badmin hopen <name>
for h in 25 26 27 24 23; do
  name=$(ssh root@192.168.31.$h hostname -s)
  ssh root@192.168.31.23 "su - ldapadmin -s /bin/bash -c \"bash -lc 'badmin hclose $name'\""
  ssh root@192.168.31.$h 'systemctl reboot' &      # 高危：重启节点
  # —— 等该台恢复：启动标识变化 + /sys/fs/cgroup=tmpfs + lsfd active，再继续下一台
  sleep 60
  ssh root@192.168.31.$h 'stat -fc %T /sys/fs/cgroup; systemctl is-active lsfd'   # 预期 tmpfs / active
  ssh root@192.168.31.23 "su - ldapadmin -s /bin/bash -c \"bash -lc 'badmin hopen $name'\""
done

# ⑥ 恢复健康巡检
ssh root@192.168.31.23 'systemctl start lsf-health.timer'

六、验证

S=/data/nfs/lsf/lsf
# 1) 运行态已是 cgroup v1（5 台，预期全部 tmpfs）
for h in 23 24 25 26 27; do echo -n "192.168.31.$h: "; ssh root@192.168.31.$h 'stat -fc %T /sys/fs/cgroup'; done
# 2) 内核条目已含参数
for h in 23 24 25 26 27; do echo -n "192.168.31.$h: "; ssh root@192.168.31.$h 'grubby --info=ALL | grep -c unified_cgroup_hierarchy=0'; done
# 3) 日志无 cgroup v2 提示（对比时间戳，应无本次重启后的新记录）
grep -i "cgroup v2 support" $S/log/*.log.* | tail -3
# 4) 集群状态
ssh root@192.168.31.23 "source $S/conf/profile.lsf; bhosts -w"     # 预期 5 台 ok
ssh root@192.168.31.23 "systemctl is-active lsfd lsf-health.timer" # 预期 active / active
# 5) 作业级 CPU 限制实测（预期 Cpus_allowed_list 仅 2 个核）
ssh root@192.168.31.23 "su - ldapadmin -s /bin/bash -c \"bash -lc 'bsub -n 2 -I sh -c \\\"grep Cpus_allowed_list /proc/self/status\\\"'\""
# 6) 幂等复跑（预期：无漂移、零变更跳过）
cd /home/rain/Documents/LSF/lsf_ins/deploy/lsf
.venv/bin/python main.py --config config/lsf_deploy.yaml --stage cgroup --dry-run

失败判据（任一出现即按第七章回滚）：任一台 /sys/fs/cgroup 仍为 cgroup2fs； 重启后 lsfd 未 active 或 bhosts 不足 5 台 ok；lsf-health.timer 未恢复 active。

七、回滚

备份位置：cgroup_v1/backup/，登记见 backup/README.md。 节点侧 GRUB 备份位于各节点同目录（/etc/default/grub.bak.<时间戳>、/boot/grub2/grub.cfg.bak.<时间戳>）。

回滚步骤（需人工确认后执行——重启为高危动作，实现体不自动重启）：

# 1) 移除内核参数（实现体 rollback() 只做这一步，不自动重启）
for h in 23 24 25 26 27; do
  ssh root@192.168.31.$h 'grubby --update-kernel=ALL \
    --remove-args="systemd.unified_cgroup_hierarchy=0"'
done

# 2) 【高危】人工确认后逐台重启，回到 cgroup v2
for h in 25 26 27 24 23; do ssh root@192.168.31.$h 'systemctl reboot'; sleep 60; done

# 3) 部署器侧回滚（可选）：按 backup/README.md 的反向操作撤销本阶段代码与配置
#    最小做法：把 config 的 cgroup.enable_v1 置 false，本阶段即不再执行

# 4) 验证回到 v2
for h in 23 24 25 26 27; do echo -n "192.168.31.$h: "; ssh root@192.168.31.$h 'stat -fc %T /sys/fs/cgroup'; done   # 预期 cgroup2fs
ssh root@192.168.31.23 "source /data/nfs/lsf/lsf/conf/profile.lsf; bhosts -w"                                       # 预期 5 台 ok

GRUB 配置损坏时的兜底：用同目录备份还原后重启—— cp -a /etc/default/grub.bak.<时间戳> /etc/default/grub; grub2-mkconfig -o /boot/grub2/grub.cfg。

八、风险说明

#	风险	影响	缓解
R1	改 GRUB 内核参数导致节点无法引导	该节点失联，需 KVM 宿主介入	用 grubby（Rocky 官方方式，不手改 grub.cfg）；改前备份 /etc/default/grub 与 grub.cfg；单台验证通过再滚下一台
R2	节点重启后 LSF 未自动拉起	该节点长期 unavail	lsfd.service 已 enabled（已核实）；实现体等待 systemctl is-active lsfd=active 才判就绪，超时即中止并报警
R3	滚动重启期间 primary master 失联	调度短暂由备 master 接管（数分钟）	顺序固定 worker→备→主，任何时刻保留可用 master；master 角色留在备机属正常
R4	lsf-health.timer 自愈干扰状态判定	误判节点「已恢复」或把节点拉回	变更期间暂停该 timer，结束后自动恢复并校验 active
R5	cgroup v1 在 RHEL9 已标记 deprecated	未来 RHEL10 移除后本方案失效	属已知技术债：真正解法仍是升级到 FP15+ 二进制；本变更只是恢复现有版本的能力
R6	内存硬限制未启用，作业超内存不会被拦	资源超用风险仍在	本次范围外（用户决定）；后续如需，加 LSB_MEMLIMIT_ENFORCE=Y 并 badmin reconfig
R7	重启中断节点上其他服务	该节点全部服务短暂中断	节点仅承载 LSF（已核实运行单元列表），无业务作业；且实施前确认无活动作业

附录 A：交付物清单

文件	说明
cgroup_v1/SOP.md	本文档
cgroup_v1/backup/README.md	备份台账与反向操作说明
cgroup_v1/backup/deploy/lsf/**	部署器与配置的变更后副本
deploy/lsf/stages/cgroup_v1.py	新增阶段实现（三态探测 + 备份 + 滚动重启 + 验证/回滚）
deploy/lsf/{deployer.py,main.py,stages/__init__.py}	阶段注册与 CLI 接线
deploy/lsf/utils/config_validate.py	新增 cgroup 段校验，补 lsf.host_type/binary_tar schema
deploy/lsf/config/lsf_deploy.yaml(.example)	新增 cgroup 段；lsf 段回退到真实在用的 FP12 三件套

附录 B：与 FP15 升级的关系

FP15 升级（主题目录 fp15_upgrade/）未取消，仅挂起：代码改造、配置切换方式、备份与回滚方案均已就位。 待 IBM 出口审查通过或补上支持协议后，可直接按 ../fp15_upgrade/SOP.md 执行升级； 升级完成后再按本 SOP 第七章回滚 cgroup v1 切换（新平台二进制原生支持 cgroup v2）。

九、执行结果与结论（2026-09-24 实机）

项	结果
内核参数写入	✅ 5 台均含 systemd.unified_cgroup_hierarchy=0
滚动重启	✅ 5 台依次重启（23:07–23:10），单台就绪即续下一台
运行态 cgroup	✅ /sys/fs/cgroup = tmpfs；v1 控制器（cpu/cpuset/memory）已挂载
集群状态	✅ bhosts 5/5 ok、lsfd 全 active；本轮执行耗时 283 s
幂等复跑	✅ 第二次执行判「状态已一致、无漂移、零变更跳过」
LSF 启用 cgroup	❌ 未达成：重启后 sbatchd 仍打印同一条 v2 提示，且未建立任何 cgroup 层次

根因（为何切到 v1 仍无效）

1. FP12 二进制以「系统是否存在 cgroup2」判定环境，见到 v2 即放弃 cgroup 功能；
2. RHEL9 的 systemd 即使在 legacy 模式下仍保留 cgroup2 on /sys/fs/cgroup/unified， 且 /proc/self/cgroup 保留 0:: 层级——本环境两者实测都在【已确认】；
3. RHEL9 文档要求的第二个参数 systemd.legacy_systemd_cgroup_controller 在 Rocky 9.8 的 systemd 252 中已被移除（strings /usr/lib/systemd/systemd 查不到该参数名）， 无法用它消掉 v2 挂载。

结论与后续

• 结论：FP12 二进制 + Rocky 9 组合下 cgroup 资源限制无法启用，与 v1/v2 切换无关。 唯一解法是升级到 FP15/FP16 二进制（原生支持 cgroup v2）——与 IBM 官方修复内容一致。
• 处置决定（用户确认）：保留现状，不为回滚再重启节点；待 FP15 介质到位执行升级时 一并移除本参数（那次升级本就需要重启），见 ../fp15_upgrade/SOP.md。
• 如需回退，仍可按第七章随时执行。

---

来源：/home/rain/Documents/LSF/lsf_ins/cgroup_v1/SOP.md ｜ 最后更新：2026-09-24 23:59（由 build/sync.py 同步，请勿在站点侧修改）