SOP — 环境事实同步（三层存储）与计算节点 Lustre 挂载修复¶
- 变更日期：2026-10-04
- 变更类型：C 类（交付物变更 + 系统状态变更）
- 交付物目录：
env_facts_sync_20261004/（本文件、backup/） - 关联：
rainchen-envskill、k8s_ins/env-inventory/hpc-simulation-env.yaml、slurm_ins/docs/HANDOFF.md
1. 背景¶
起因是核对 ~/.trae-cn/skills/rainchen-env/SKILL.md（自建环境使用指南）与环境事实是否一致，核对中发现三项偏差：
- 三层存储只写了「二层」：skill §5 原为「工作区二分」（
/projects+/mnt/lustre），漏掉本地层/local_scratch（EDA 元数据减压最敏感的一层），也未讲三层数据流、scratch 目录结构与生命周期清理。 - Tier0 在计算节点实际不可用（故障）：
.18/.19/.20自 2026-09-29 18:43 起/mnt/lustre挂载失败，已持续 4 天，三份档案（SOP/RUNBOOK/HANDOFF）均无记载。 - skill §6 红线过时：写「改系统状态须等用户确认再执行」，与现行规则
rule-ops-scenario-routing（声明即执行、有备份免确认）冲突。
2. 目标¶
- 三台计算节点
/mnt/lustre恢复挂载，/mnt/lustre/scratch可读写。 rainchen-envskill 与权威清单hpc-simulation-env.yaml同步为三层存储口径，且两处一致。- skill 红线口径与现行规则对齐。
3. 前置条件¶
- 本机（192.168.31.249）对
.16~.29可 root 免密 ssh。 - 执行前
squeue为空、三计算节点idle（避免在有作业节点上动作）。 - 已备份 skill 与 yaml（见第 7 章）。
4. 影响范围¶
| 项 | 内容 |
|---|---|
| 主机 | .18（slurm-work-01）、.19（slurm-work-02）、.20（slurm-work-03） |
| 组件 | Lustre 客户端挂载 mnt-lustre.mount；不影响 slurmd、MDS/OSS |
| 是否停服 | 否。挂载操作不重启任何 daemon |
| 在跑作业 | 无（squeue 空、三节点 idle，2026-10-04 00:14 实测） |
| 窗口 | 无特殊要求 |
5. 分步操作¶
步骤 1：前置核查（只读）¶
确认无在跑作业与节点状态，避免在有作业的节点上动作。
timeout 15 ssh root@192.168.31.16 '/usr/local/slurm/bin/squeue; /usr/local/slurm/bin/sinfo -N -o "%N %T"'
预期：squeue 仅表头；三节点 idle。失败判断：若有作业 → 停止本次变更。
步骤 2：备份 skill 与权威清单（高危前必备份）¶
TS=$(date +%Y%m%d-%H%M%S); D=env_facts_sync_20261004/backup
mkdir -p "$D/trae-cn/skills/rainchen-env" "$D/k8s_ins/env-inventory"
cp -a ~/.trae-cn/skills/rainchen-env/SKILL.md "$D/trae-cn/skills/rainchen-env/SKILL.md.bak.$TS"
cp -a ~/Documents/k8s_ins/env-inventory/hpc-simulation-env.yaml "$D/k8s_ins/env-inventory/hpc-simulation-env.yaml.bak.$TS"
预期：两份 .bak.20261004-001505 生成。见 backup/README.md。
步骤 3：恢复三台计算节点 Lustre 挂载¶
故障根因（见附录 A）：MDS 于 09-29 进入客户端恢复窗口拒连，客户端 fstab 带 nofail 静默跳过，mnt-lustre.mount 落到 failed 后不会自愈。故只需重启该 unit 重试挂载，不需要改 fstab 或重启服务。
for h in 18 19 20; do
timeout 45 ssh root@192.168.31.$h 'systemctl restart mnt-lustre.mount; sleep 3; findmnt -no SOURCE,FSTYPE -M /mnt/lustre'
done
预期：三台各自输出 192.168.31.21@tcp:/edafs lustre。
失败判断：仍 NOT-MOUNTED → 查 journalctl -u mnt-lustre.mount -n 20 与 dmesg | grep Lustre；若 MDS 仍在恢复窗口，稍后重试（幂等）。
步骤 4：更新 skill 正文（三层存储 + 红线）¶
rainchen-env/SKILL.md 定点修订（SearchReplace，不整篇重写）：
- §5 第 4 条「工作区二分」→ 展开为三层（Tier1 NFS / Tier0 Lustre / 本地
$TMPDIR）+ 数据流 + cwd 坑 + 三层清理。 - §6 末条 → 现行口径（声明即执行、有备份免确认，三类例外）。
步骤 5：更新权威清单 hpc-simulation-env.yaml¶
storage.mounts 内 /mnt/lustre 补 tier/scratch_layout，并新增 /local_scratch 条目（node_local: true）；storage 尾部「工作区选择建议」注释改为三层分工与生命周期说明；作业模板补三层存储注释。
6. 验证¶
# ① 三节点挂载 + scratch 可写
for h in 18 19 20; do echo "== .$h =="; timeout 15 ssh root@192.168.31.$h \
'findmnt -no SOURCE,FSTYPE -M /mnt/lustre; ls /mnt/lustre/scratch; touch /mnt/lustre/scratch/tmp/.probe_$$ && echo WRITABLE && rm -f /mnt/lustre/scratch/tmp/.probe_$$'; done
# ② yaml 语法与挂载项
python3 -c "import yaml;d=yaml.safe_load(open('$HOME/Documents/k8s_ins/env-inventory/hpc-simulation-env.yaml'));print([m['mount'] for m in d['storage']['mounts']])"
# ③ skill frontmatter 未破坏
head -4 ~/.trae-cn/skills/rainchen-env/SKILL.md
实测结果（2026-10-04）：
- 三台均 192.168.31.21@tcp:/edafs lustre，scratch/{projects,tmp,users} 可见，WRITABLE。
- yaml 解析成功，mounts 含 /local_scratch：['/home','/projects','/tools','/pdk','/opt/modulefiles','/mnt/lustre','/local_scratch','/data/nfs/lsf']。
- skill frontmatter name: rainchen-env 完好。
7. 回滚¶
| 对象 | 回滚动作 |
|---|---|
| Lustre 挂载（若需还原故障态） | 各计算节点 umount /mnt/lustre（正常态无需回滚） |
| skill | cp -a backup/trae-cn/skills/rainchen-env/SKILL.md.bak.20261004-001505 ~/.trae-cn/skills/rainchen-env/SKILL.md |
| yaml | cp -a backup/k8s_ins/env-inventory/hpc-simulation-env.yaml.bak.20261004-001505 ~/Documents/k8s_ins/env-inventory/hpc-simulation-env.yaml |
回滚触发判据：挂载后节点异常（slurmd 不健康、sinfo 显示 drain）→ 先 umount，再查 MDS 侧。
备份位置与删除时机见 backup/README.md。
8. 风险说明¶
| 风险 | 缓解 |
|---|---|
| MDS 仍在客户端恢复窗口，重启后仍拒连 | 挂载失败即维持原状（nofail）；MDS 恢复后重跑步骤 3，幂等 |
| 变更涉及全局 skill（跨项目生效） | 只改正文，未动 description；按现行结论，正文改动不进每轮前缀、无需新会话 |
| 两层文档再次漂移 | skill 与 yaml 本轮同步改，且 skill 指向 yaml 为权威源 |
附录 A：Tier0 故障记录（根因与证据）¶
时间线
| 时间 | 事件 |
|---|---|
| 2026-09-29 18:41 | MDS（.21）进入客户端恢复窗口，日志 Denying connection for new client ... waiting for 7 known clients (0 recovered ...) to recover |
| 2026-09-29 18:43~18:45 | .18/.19/.20 挂载尝试被拒（rc = -16），mnt-lustre.mount → failed (Result: timeout)；/mnt/lustre 为空目录 |
| 2026-09-29 18:46 | MDS 端 disconnecting 7 stale clients，服务端恢复；客户端 unit 已 failed，不自动重试 |
| 2026-10-04 00:14 | 本次发现（已持续 4 天）：.18/.19/.20 均 NOT-MOUNTED；.28 正常 |
| 2026-10-04 00:19 | 重启三台 mnt-lustre.mount，恢复成功 |
证据
# 计算节点（.18，同形于 .19/.20）
$ systemctl status mnt-lustre.mount
× mnt-lustre.mount - /mnt/lustre
Active: failed (Result: timeout) since Tue 2026-09-29 18:43:17 CST; 4 days ago
$ dmesg | grep -i lustre | tail
LustreError: edafs-MDT0000-mdc-...: operation mds_connect to node 192.168.31.21@tcp failed: rc = -16
LustreError: ... llite: Unable to mount <unknown>: rc = -16
# MDS（.21）
Lustre: edafs-MDT0000: Denying connection for new client ... (at 192.168.31.19@tcp), waiting for 7 known clients ... to recover
Lustre: edafs-MDT0000: disconnecting 7 stale clients
根因：MDS 客户端恢复窗口期间拒绝新挂载（预期行为），叠加客户端 nofail 静默跳过 + systemd failed unit 不自动重试，导致故障被「静默固定」——不是文件系统故障，是恢复窗口与挂载重试策略的组合缺陷。
遗留建议（未实施）：为 mnt-lustre.mount 增加重试或加 Restart= / 由 HPC 健康检查覆盖该挂载点，避免同类静默失败长期潜伏。
附录 B：交付物清单¶
| 文件 | 说明 |
|---|---|
SOP.md |
本文件 |
backup/README.md |
备份台账 |
backup/trae-cn/skills/rainchen-env/SKILL.md.bak.20261004-001505 |
改前 skill |
backup/k8s_ins/env-inventory/hpc-simulation-env.yaml.bak.20261004-001505 |
改前权威清单 |
来源：
/home/rain/Documents/slurm/env_facts_sync_20261004/SOP.md｜ 最后更新：2026-10-04 00:16（由build/sync.py同步，请勿在站点侧修改）