项目地图（PROJECT-MAP）— slurm

接任务先查第 1 节路由表；问「现在什么状态、下一步做什么」去 slurm_ins/docs/HANDOFF.md；问「怎么操作、怎么排障」去对应工程的 SOP.md / RUNBOOK.md。 本文件只描述工程的身份与结构（有哪些工程、谁依赖谁、任务该进哪个门），不写当前状态、待办与操作步骤。 身份标签四档：活工程（仍在用、会被重跑或继续开发）/ 服务档案（对应一个在运行的服务）/ 留档（已结束的一次性主题，供追溯）/ 数据源（提供事实与索引，不承载变更）。

1. 任务路由表

任务 / 症状	进哪个目录	先读哪份文档	入口命令
Slurm 集群重跑部署、单节点基线变更、幂等验收	slurm_ins	docs/RUNBOOK.md、docs/SOP.md 第 5 章	.venv/bin/python main.py --config config/slurm_deploy.yaml
模块环境 / modulefile（Lmod）、节点环境、用户与 LDAP 同步、健康保障、本地 scratch、存储布局、scratch 生命周期清理、提交节点纳管	slurm_ins	docs/RUNBOOK.md、docs/SOP.md	.venv/bin/python main.py --{node-env\|module-env\|user-mgmt\|health-ensure\|local-scratch\|storage-layout\|scratch-gc\|submit-node} [--dry-run]
要集群拓扑、登录方式、存储三层口径、机制性陷阱与命令速查	slurm_ins	docs/BASELINE.md（稳定层，权威源为 rainchen-env skill §5 与 k8s_ins/env-inventory/hpc-simulation-env.yaml）	无（环境事实与速查）
集群历次变更做了什么、某次决策经过、部署排障台账	slurm_ins	docs/SOP.md、docs/INCIDENT-20260918-*.md	无（历史档案）
集群日常运维：启停、扩缩容、同步、配置管理、备份恢复、故障场景 A–I	slurm_ins	docs/RUNBOOK.md	无（手册与场景）
追溯某次变更的档案（Lmod family 作用域、csh 站点脚本、csh 环境注入双轨、三层存储事实同步、提交节点纳管、存储差距）	slurm_ins/<主题>_<YYYYMMDD>/、slurm_ins/eda_storage_gap/	各目录内 SOP.md / README.md	无
新集群实施 EDA 行业存储标准时找参考（结构、基线取值、幂等设计）；或追溯旧集群的存储标准化做法	eda_storage_standardization	deploy/docs/SOP.md、deploy/docs/troubleshoot.md、docs/HANDOFF.md	无（旧集群参考档案，不上机、不改造；原入口 python3 main.py --config config/deploy.yaml 面向已清退的旧集群 192.168.0.x，已不可用）
epilog scratch 老化清理规则	eda_storage_standardization/epilog	SOP.md	定位同 eda_storage_standardization（旧集群参考，不承载变更）
Slurm 监控：Prometheus / Grafana / Alertmanager / slurm-exporter 迁移与排障	slurm_monitoring_prometheus	SLURM_PROMETHEUS_GRAFANA_SUMMARY.md、迁移子目录 SOP-slurm监控迁移k8s-prometheus87.md	deploy-slurm监控-新版k8s.sh / rollback-slurm监控.sh
三层存储事实同步与计算节点 Lustre 挂载修复（2026-10-04）	env_facts_sync_20261004	顶层 SOP.md（附录 A 为 mnt-lustre.mount 无自愈根因）	无（变更档案）
追溯稳定层 BASELINE.md 的建立与 HANDOFF 收敛过程	baseline_layer_20261004	backup/README.md	无（备份与回滚保障）
Slurm 学习路线、EDA 芯片设计流程、教程类资料	slurm_study	slurm_study_plan/学习规划.md、eda_flow/EDA芯片设计全流程图.md	无（资料索引）

2. 分层依赖图

【物理 / 宿主层】
  KVM 宿主 dell-R620（本机，192.168.31.249=br0 / .250=eno2；**同机双网口**；也是 NFS 服务端）
    ├── slurm   .16/.17（控制主备 HA）+ .18/.19/.20（计算 node-01~03）
    ├── hpc     .28（统一提交节点 hpc-submit，无 slurmd）
    ├── lustre  .21（MGS/MDS）+ .22（OSS）
    ├── lsf     .23/.24（主备）+ .25/.26/.27（计算，与 Slurm 共用 modulefiles）
    ├── license .29（FlexLM）
    └── k8s     .10/.13/.14/.15（**不在本项目内**，监控栈所在）
      │ 装机/装载来源：各集群无专属部署工程，由 `k8s_ins/env-inventory` 提供事实索引
      ▼
【兼容 / OS 层】
  全节点 Rocky 9.8；Lmod + modulefile（`.16` 生成 → 各节点装载）；csh 站点 Lmod 脚本；
  机制性陷阱（Lmod family 两级语义、Epilog `set -u`、configless、`qemu-img --force-share`）详 `slurm_ins/docs/BASELINE.md` 第 3 节
      │
      ▼
【服务层】
  Slurm 26.05 主备 HA：`slurmdbd` → `slurmctld(.16→.17)` → `slurmd(.18~.20)`；记账 + QoS；
  装配能力：LDAP 用户同步、健康保障、Lmod 模块环境、本地 scratch、存储布局、scratch 生命周期清理
  相邻服务：LSF(.23~.27)、Lustre(.21/.22)、FlexLM(.29)、NFS 服务端（宿主）
  监控消费：slurm-exporter → k8s `monitoring` 命名空间（Prometheus / Grafana / Alertmanager）
      │
      ▼
【入口层】
  SSH 登录 + LDAP 认证；作业提交经 `.28`（hpc-submit，仅客户端，不跑守护进程）
      │
      ▼
【数据 / 存储层】
  Tier1 NFS（宿主）：`/projects` 读写、`/home`、`/tools`、`/pdk` 只读 —— 长期
  Tier0 Lustre（.21/.22）：`/mnt/lustre/scratch/users/<用户>/<jobid>` 为跨节点 workdir，容量 295G、单 MDT/OST 无法条带化、老化 30 天
  本地层：`/local_scratch/users/<用户>/<jobid>`（即 `$TMPDIR`，prolog 注入，老化 7 天）
  数据流：`/projects` 读入 → Lustre workdir → 结果写 `$TMPDIR` → 必要文件 stage-out 回 `/projects`
  Tier2 Archive：仅方案层定义（对象存储 / 磁带），尚无落地

结构性的关键点：NFS 服务端与 Slurm 计算 VM 同处宿主 dell-R620，属同源故障域；Lustre 为跨节点作业的唯一并行工作区。

3. 子项目卡片

活工程

目录	定位	关键产物与入口	上下游
slurm_ins	Slurm 26.05 主备集群的核心部署与运维工程（幂等收敛、模块化 deployer）	main.py、deployer.py、config_renderer.py、utils/、各 *_assets.py + *_deployer.py（node_env / module_env / user_mgmt / health_ensure / local_scratch / storage_layout / scratch_gc / submit_node / slurm）、config/slurm_deploy.yaml（600，配置唯一事实源）、docs/{HANDOFF,BASELINE,SOP,RUNBOOK}.md、docs/INCIDENT-20260918-*.md	上游：rainchen-env skill 与 k8s_ins/env-inventory/hpc-simulation-env.yaml（权威事实源）；被 baseline_layer_20261004、env_facts_sync_20261004 引用；见「工程内变更档案」

服务档案

目录	定位	关键产物与入口	上下游
slurm_monitoring_prometheus	Slurm 集群监控接入 k8s Prometheus + Grafana 的部署与迁移档案（对应 k8s monitoring 命名空间中运行中的监控服务）	slurm监控迁移k8s新版_20260903/（deploy / rollback 脚本、SOP-slurm监控迁移k8s-prometheus87.md、yaml、备份）、顶层 slurm-exporter-k8s.yaml、slurm-alerts.yaml、alertmanager.yaml、slurm-dashboard.json、slurm-exporter.service、inventory.yaml、SLURM_PROMETHEUS_GRAFANA_SUMMARY.md	上游：k8s 集群（monitoring 命名空间）；对象：各节点的 slurm-exporter 指标

数据源

目录	定位	关键产物	关联
slurm_study	Slurm 学习资料与索引（六阶段学习规划、EDA 芯片设计全流程图、少量运维变更样例）	slurm_study_plan/（阶段 1~6 + 学习规划.md）、eda_flow/EDA芯片设计全流程图.md、inventory.yaml（演示用）	不承载变更；其中 运维变更_日志分离与MPI默认/ 为样例变更档案

留档

目录	定位	关键产物	关联
eda_storage_standardization	旧集群（192.168.0.x / CentOS7 / Slurm 21.08）实施 EDA 行业存储标准的落地产物（方案 + Python 存储部署器 + epilog 清理 + NFS 客户端）；不承载变更、不上机，仅作新集群实施 EDA 行业存储标准的参考	deploy/main.py、deploy/deployer.py、deploy/config/deploy.yaml、deploy/utils/、deploy/docs/{SOP,troubleshoot}.md、epilog/（含自身 SOP.md）、cleanup/、nfs_client/mount_nfs_client.sh、顶层 LDAP组织结构改造计划.md、docs/HANDOFF.md（2026-10-07 建立，同日定位澄清）	存储口径与 slurm_ins 同源（Tier0/Tier1 生命周期一致），新集群可借鉴其结构与基线取值；目标主机网段已不可达（旧集群工程 2026-10-04 清退）
env_facts_sync_20261004	三层存储事实同步（rainchen-env skill + hpc-simulation-env.yaml）+ 计算节点 /mnt/lustre 挂载修复	顶层 SOP.md（附录 A）、backup/{slurm_ins,k8s_ins,trae-cn}/	触及 slurm_ins、k8s_ins/env-inventory、全局 rainchen-env skill

工程内变更档案（slurm_ins/ 下）

目录	内容
slurm_ins/module_family_scope_20260927/	Lmod family 作用域修正（根因、八章、验证数据、已知限制、backup/）
slurm_ins/lmod_csh_profile_20260927/	csh 站点 Lmod 脚本补齐（九台同源、addto 坑、LSF 三台一次性下发）
slurm_ins/slurm_csh_profile_20261005/	csh 环境注入双轨补齐（slurm-path.csh/slurm_configless.csh 双轨 + PATH 判重 + modulefile help 文案修正，6 台下发）
slurm_ins/lmod_site_package_20261005/	Lmod 站点扩展（SitePackage.lua 消 avail 提示块）+ 取消 slurm 模块并清理遗留 Core/slurm/ + calibre 默认版本与 latest 别名（6 台下发）
slurm_ins/epilog_xdisplay_cleanup_20261005/	Epilog 新增孤儿 X 显示 / clsbd 残留清理（仅无进程者删）+ 清掉 3 台当前残留（HANDOFF #14 结案）
slurm_ins/eda_topo_audit_20261006/	EDA 存储拓扑巡检（只读）：lsf/slurm/lustre/nfs/ldap 五类服务的节点接入矩阵、权限与挂载对照、差距清单；含采集脚本与原始输出、backup/
slurm_ins/scratch_gc_exclude_20261007/	scratch 老化清理加排除能力（C 类）：purge() 逐层排除 → find -not -path，yaml 参数化；离线自测 17/17、3 台下发、幂等零变更；含 SOP.md 与 backup/
slurm_ins/nfs_export_ro_20261007/	NFS 导出收紧（C 类，单机）：/tools、/pdk 服务端 rw→ro，exportfs -v+etab 双证、幂等零变更；含 SOP.md 与 backup/；附录 B 记录「NFS soft 有意保留」决策
slurm_ins/fstab_persist_fix_20261007/	hpc-submit（.28）NFS 挂载持久化补漏（C 类，单机）：补 storage_layout_deployer.py::judge_tier1() 判据（已挂载但 fstab 缺条目 → PENDING），由部署器注入 /projects、/tools 两条（变更 2 条、幂等复跑 0）；含 SOP.md 与 backup/
slurm_ins/lustre_mount_selfheal_20261007/	mnt-lustre.mount 自愈（C 类）：启用健康巡检机制 B（.16 timer 15min → failed unit reset-failed+start）；修掉 health_assets 渲染正则空壳缺陷（此前机制 A/B 从未真正工作）+ 补齐节点间 SSH 免密；故障注入双向验证；含 SOP.md、诊断 README.md 与 backup/
slurm_ins/mirror_unify_20261007/	Rocky/EPEL 源统一改指 aliyun（本项目 .16/.17；覆盖 8 文件、makecache rc=0、非 aliyun 残留 0）；含远端整目录备份台账
slurm_ins/rollback_drill_20261007/	--submit-node --rollback 真实演练：回滚 rc=0、按设计保留产物目录、重部署完整恢复、幂等零变更；含 README.md 与三份执行日志
slurm_ins/handoff_landing_20261007/	HANDOFF 落点整理（轮次清单与已结案项清出、稳定内容回归 BASELINE/SOP、HANDOFF 整体重写）；含改前快照
slurm_ins/sync_status_concurrency_20261007/	sync_status 并发化（C 类）：基类统一远程封装 + 新增 _remote_query_many()、9 处重复删除、slurm/health_ensure/user_mgmt 批量化；离线自测 8 项通过、dry-run 变更记录逐条一致（slurm 墙钟 247.7→221.0 s）；含 SOP.md、selftest.py、verify_baseline.sh 与 backup/
slurm_ins/conn_reuse_20261007/	SSH 连接复用在本工程落地（C 类）：utils/paramiko_module.py 副本对齐共享库 py_public_modules（_pooled 归还 + close_force() + 池化命中 + per-host RLock + 建连计数）；dry-run 墙钟 221.0→134.6 s、建连 6 次；含 SOP.md、selftest.py 与 backup/；附录 B 记「双份并存 / 文件拼接」遗留
slurm_ins/efficiency_wrapup_20261011/	部署器效率改造结案（文档标注）：全盘引用结案处置、864 数字订正为实测 87/90、封存未做项（跨阶段合并探测 / sub12 预取）；含 README.md 与 backup/
slurm_ins/submit_node_onboarding/	提交节点纳管档案（含 pre_check 门禁与阶段顺序踩坑）
slurm_ins/eda_storage_gap/	历次存储类变更档案与对标差距清单
各主题 backup/README.md	备份台账（位置、原路径、回滚什么、何时可删）

4. 存疑与待澄清

• eda_storage_standardization 为旧集群产物、仅供参考【已确认，2026-10-07 用户明确】：该工程面向旧集群（192.168.0.x）实施 EDA 行业存储标准，config 目标主机网段已不可达；其定位是新集群实施 EDA 行业存储标准的参考（结构、基线取值、幂等设计可借鉴），不上机、不改造、不作为现行集群部署入口。原挂待办「远端执行层接入连接复用」已按用户指令取消——理由与留档见其 docs/HANDOFF.md §3；若新集群将来要复用该能力，应在新集群工程内实施，可参照 slurm_ins/conn_reuse_20261007/SOP.md。
• 旧集群（192.168.0.x / CentOS7 / Slurm 21.08）资料已清退【已确认】：原根级 6 个旧集群工程目录（deploy、license_management、openmpi_test、slurm_validation、vina_parallel、virtuoso_eda_env）已于 2026-10-04 按用户指令删除、未留备份；其资产此前已被 slurm_ins 现役工程吸收改造。仍存于库内的旧集群残留：slurm_ins/docs/故障报告-20260903-*.md、slurm_ins/docs/troubleshoot.md（旧集群排障记录，HANDOFF 已标注），以及 slurm_ins/slurm_conf_old/——后者有功能性牵连：config_renderer.py 的旧 IP→主机名映射（RUNBOOK 第 635 行）依赖该模板，不可删。
• License TRES 未启用【已确认】：config/slurm_deploy.yaml 明注「未选用 License TRES 记账」，license_management 的原 SOP（FlexLM TRES 同步）已随旧集群资料清退且无备份——将来若要启用须重写。
• slurm_ins/docs/PROJECT-MAP.md 是否存在/是否另立未定——本文件（slurm/docs/PROJECT-MAP.md）为其上级地图，slurm_ins 内部的子档案目前列在本文件第 3 节末表。
• Tier2 Archive（对象存储 / 磁带）仅见于方案层定义，无落地工程。
• slurm_study/slurm_study_plan/运维变更_日志分离与MPI默认/ 为样例还是现集群实际变更，未核实。
• 本项目根级无 README.md / docs/HANDOFF.md；交接快照位于 slurm_ins/docs/HANDOFF.md（SessionStart Hook 在 cwd 下未命中）。

5. 工程命名与文档约定

目录命名

• 核心工程：slurm_ins（Slurm 集群实施主工程）
• 一次性主题：<主题>_<YYYYMMDD>（如 module_family_scope_20260927、baseline_layer_20261004）

docs 档案位置与角色

文件	位置	管什么
PROJECT-MAP.md	slurm/docs/	本文件：工程身份与结构（定点修订，只改受影响行）
HANDOFF.md	slurm_ins/docs/	当前状态、待办、红线（覆盖式重写，SessionStart 注入）
BASELINE.md	slurm_ins/docs/	稳定层：集群拓扑与登录、存储三层、机制陷阱、命令速查
SOP.md	slurm_ins/docs/ 与各主题目录	该工程的变更档案（累积式，八章）
RUNBOOK.md	slurm_ins/docs/	集群运行与排障手册（速查、启停/扩缩容/同步、故障场景 A–I）
INCIDENT-YYYYMMDD-<主题>.md	slurm_ins/docs/	事故台账与复盘

档位标注（HANDOFF / BASELINE / 本文件通用）

• 【已确认】= 有实测证据；【未验证】= 说法未经证实；【待决策】= 尚未定论。禁止把未验证的写成已确认。

backup 台账

• 每个主题的备份放在该主题目录下的 backup/，命名 <原名>.bak.<YYYYmmdd-HHmmss>，并必须有 backup/README.md 逐条登记（文件、原路径、产生时间、因何产生、回滚什么、何时可删）。
• 含凭据明文的文件（如 config/slurm_deploy.yaml）不入文档、不入 git，仅在台账登记位置。

工程形态

• 复杂变更以 Python 工程实现：main.py + deployer.py + *_assets.py + config/ + .venv/（venv 粒度：每工程一个 .venv/）。
• 已结案的一次性主题目录不删，保留 backup/ 与 SOP.md 供追溯。
• 全局技能 rainchen-env 承载"本项目之外"的环境事实指针与凭据取用约定。

退役纪律

• 工程退役或被取代时：不删目录，改身份标签为 留档，在卡片注明被谁取代、何时。
• 新增子项目时：在路由表加一行 + 在卡片区加一条。

---

来源：/home/rain/Documents/slurm/docs/PROJECT-MAP.md ｜ 最后更新：2026-10-11 21:16（由 build/sync.py 同步，请勿在站点侧修改）