mnt-lustre.mount 自愈 —— 诊断与方案（待决策）¶
主题：
lustre_mount_selfheal_20261007｜状态：诊断完成，方案待决策（未执行任何变更） 触发：HANDOFF §3 #9（env_facts_sync_20261004/SOP.md附录 A 为其根因记录）
1. 问题（复核后的准确表述）¶
原描述：「mnt-lustre.mount 无自动重试，Lustre 不可用时静默失败、4 天无人察觉
（2026-09-29 .18–.20 故障根因）」。
2026-10-07 核实后：问题不只是"缺一个重试"，而是——健康保障层整层声明了却没落地：
| 层 | 配置（config/slurm_deploy.yaml §health_ensure） |
现场实测（.18） |
判定 |
|---|---|---|---|
| 机制 A：slurmd 内置 HealthCheck | install_healthcheck: true、health_check_program: /usr/local/bin/slurm_health_check.sh、health_check_interval: 300 |
slurm.conf 无 HealthCheckProgram（脚本在场但未挂接） |
未落地 |
| 机制 B：控制节点巡检 watchdog | install_watchdog: true、watchdog_script: /usr/local/bin/cluster_health_check.py、watchdog_interval: 15min |
/usr/local/bin/ 下无 cluster_health_check.py；无 health timer（systemctl list-timers 无） |
未落地 |
| 挂载检查项 | extra_check_mounts: []、extra_writable_dirs: [] |
现场脚本 NFS_MOUNTS=""、WRITABLE_DIRS=""（第 27/29 行） |
列表为空 |
- 现场脚本
slurm_health_check.sh（1468 B，2026-09-18 05:35）确实下发过，但因列表为空， 它实际只检查「根可写 / tmp 可写 / 内存 / 磁盘 / munge」——完全不检查任何共享挂载。 - 3 台计算节点当前
State=IDLE，没有误 DRAIN（未启用 = 无副作用，也无保护）。
为什么现在不能只"加一条检查"：机制 A 的语义是判定健康（失败 → slurmd 自动 DRAIN 节点）—— 把「Lustre 挂载失败」纳入 A，等于选择「Lustre 一挂就停掉该节点接作业」；而自愈动作（重启挂载） 放在 A 里语义不合（自愈成功仍要返回 0，逻辑绕）。自愈天然属于机制 B（巡检 + 修复，不动调度状态）。
2. 方案选项（二选一，或 A 单独先行）¶
| 方案 A：只启用机制 B（巡检自愈） | 方案 B：A + 启用机制 A（HealthCheck+DRAIN） | |
|---|---|---|
| 动作 | 部署 cluster_health_check.py + slurm-cluster-health.timer（15min）；在其中新增「/mnt/lustre 挂载检查 + reset-failed + start 自愈」 |
在 A 之上，把 HealthCheckProgram 写进 slurm.conf 并重启各计算节点 slurmd |
| 对调度的影响 | 无（不改节点状态） | 有：任一检查失败即 DRAIN，需人 scontrol update 恢复 |
| 能否解决 #9 | 能（挂载失败 15min 内自动恢复） | 能，但代价是故障期节点被 DRAIN |
| 风险 | 低：新增常驻 timer；--fix 动作需限定在挂载类 |
中：DRAIN 会静默减少算力，且依赖检查项配置正确 |
| 范围 | 建议先「slurm 侧节点」（.18–.20 + .28）；.25–.27 属 LSF，归 lustre_ins §3.1 #14 |
同左（HealthCheckProgram 只对跑 slurmd 的节点有意义） |
推荐：先做方案 A。理由：它直接消解 #9 的根因（静默失败无人察觉 → 15min 内自动恢复）， 且不改变调度语义（不引入 DRAIN 这种需要人介入的副作用）；机制 A 是否启用可作为后续独立决策， 届时再按「挂载失败该不该停节点接作业」单独拍板。
无论选哪个，都应同时：把 extra_check_mounts 填为当前环境
（/home /projects /tools /pdk /opt/modulefiles /mnt/lustre）、extra_writable_dirs 填
（/home /projects /local_scratch）—— 现在为空是配置缺陷（脚本里的旧集群默认值 /mnt/nfs、/opt/lsf
早已不适用；注意只读层 /tools、/pdk 绝不能进"可写"列表）。
3. 验收（实施时用）¶
systemctl is-failed mnt-lustre.mount为真时，≤1 个巡检周期内变active；- 人为
systemctl stop mnt-lustre.mount后，timer 能自动恢复（故障注入验证， 须在无在跑作业的窗口做，且验证后确认/mnt/lustre可读写）； - 部署器复跑「待执行 0 / 幂等跳过」；
slurm.conf与节点状态不受影响（方案 A 下节点保持 IDLE、无 DRAIN）。
4. 本轮未做的事（有意）¶
- 未启用任何一层：启用 = 改变系统行为（常驻 timer / DRAIN 语义），且涉及范围与调度策略选择，需先定方案。
- 未改
extra_check_mounts等配置：改了不跑部署器不生效；跑了就等于启用机制 A（见上）。 - 未动
slurm_health_ensure/下的旧资产（slurm_health_check.sh、cluster_health_check.py、SLURM_HEALTHCHECK_STANDARD_SOP.md）：该目录是旧集群（192.168.0.x / CentOS7 / k8s-node-0x //home/rian）资料，其 SOP 与 service 文件（ExecStart=/root/.pyenv/versions/3.9.6/...）均不适用于当前集群； 实施方案 A 时应按当前环境新写 watchdog，而不是复用旧资产。
来源：
/home/rain/Documents/slurm/slurm_ins/lustre_mount_selfheal_20261007/README.md｜ 最后更新：2026-10-07 03:24（由build/sync.py同步，请勿在站点侧修改）