Slurm 概念、術語、節點屬性、節點狀態、 Partition 屬性詳解表
===
###### tags: `Slurm`
###### tags: `Slurm`, `HPC`, `Linux`, `Slinky`, `SlinkyProject`, `Cluster` `Scheduler` `Slurmctld` `Slurmd` `Slurmstepd` `Slurmdbd` `Accounting` `JobAccounting` `TRES` `TRES-Tracking` `Billing` `GRES` `GPU` `Federation` `Multi-Cluster` `Association` `Account` `QoS` `FairShare` `Backfill` `Job` `JobStep` `JobArray` `Node` `Node-Attributes` `Node-State` `Partition` `Partition-Attributes` `Drain` `Draining` `DRAINED` `DRAINING` `Prolog` `Epilog` `Authentication` `AuthType` `auth-munge` `MUNGE` `auth-slurm` `SACK` `sackd` `TLS` `LDAP` `Kubernetes` `K8s` `Slurm-on-Kubernetes` `slurm-operator` `Configless` `scontrol` `sinfo` `squeue` `sbatch` `srun` `salloc` `sacct` `sacctmgr` `sreport` `sshare`

<br>

[TOC]

<br>

## 概念
### 作業會計 (Job Accounting)
- **用途**：
- **儲存作業歷史**: 所有提交的作業 (job)、步驟 (step)、資源使用情況
- **追蹤資源消耗**: CPU 時間、記憶體使用、GPU 使用 (`AccountingStorageTRES: gres/gpu`)
- **作業狀態記錄**: 開始/結束時間、退出碼、執行節點資訊

### 資源計量 (TRES Tracking)
- **配置**: AccountingStorageTRES=gres/gpu
- **用途**：
- 追蹤 **Trackable RESources** (CPU、記憶體、GPU、節點數等)
- 提供給 **資源配額 (QoS)** 和 **計費 (Billing)** 系統使用
- 支援 GPU 等特殊資源的使用統計

### 多叢集管理 (Federation Support)
- **設定位置**: `helm/slurm/values.yaml:42` (`clusterName`)
- **用途**：
- **單一資料庫儲存多個 Slurm 叢集** 的會計資料
- 支援跨叢集的資源使用報表
- 提供統一的使用者配額管理

### 使用者與專案管理
- **功能**：
- **Association 管理**: 使用者與帳號 (account) 的關聯
- **QoS (Quality of Service)**: 資源使用限制與優先權設定
- **Fair Share 排程**: 基於歷史使用量的公平排程
- **範例指令**：

    sacctmgr add account research
    sacctmgr add user alice account=research
    sacct -j 12345  # 查詢作業 12345 的會計資訊

### 歷史資料查詢
- **對應指令**：
- `sacct`: 查詢已完成作業的詳細資訊
- `sreport`: 生成叢集使用報表
- `sshare`: 查看 Fair Share 資訊
- **實際應用**：
- 追蹤過去 6 個月的 GPU 使用率
- 計算各專案的運算成本
- 分析節點故障對作業完成率的影響

### Slurmdbd 是必要的原因
1. **持久化儲存**: Slurmctld 的 `StateSaveLocation` 只儲存當前狀態，作業完成後資訊會被清理
2. **歷史查詢**: 所有的作業歷史、資源使用報表都需要 Slurmdbd
3. **進階功能**: Fair Share、QoS、Multi-cluster 等企業級功能的基礎
4. **審計需求**: 提供完整的資源使用審計軌跡
5. **當啟用 accounting 時**：
| 功能 | 無 Slurmdbd | 有 Slurmdbd |
|------|------------|------------|
| 作業歷史查詢 | ❌ 無法使用 `sacct` | ✅ 完整歷史記錄 |
| Fair Share 排程 | ❌ 無法計算 | ✅ 基於歷史使用量 |
| 資源配額管理 | ❌ 只能硬限制 | ✅ 動態 QoS 控制 |
| 多叢集管理 | ❌ 各叢集獨立 | ✅ 統一管理 |
| GPU 使用追蹤 | ❌ 無記錄 | ✅ 精確計量 |

<br>

---

<br>

## 術語
> by Claude Sonnet-4.5 (2025/11/21)

| 術語 | 英文 | 中文 | 說明 |
|------|------|------|------|
| Account | Account | 帳戶 | 用於追蹤和限制資源使用的帳戶群組 |
| Allocation | Allocation | 資源分配 | 分配給作業的資源集合 |
| Association | Association | 關聯 | 使用者、帳戶和叢集之間的關係 |
| Backfill | Backfill Scheduling | 回填排程 | 允許較小的作業在等待佇列中提前執行的排程策略 |
| Burst Buffer | Burst Buffer | 突發緩衝區 | 高速臨時儲存空間，用於提升 I/O 效能 |
| Cluster | Cluster | 叢集 | Slurm 管理的計算資源集合 |
| Controller | Controller (slurmctld) | 控制器 | Slurm 的中央管理守護程序 |
| Daemon | Daemon (slurmd) | 守護程序 | 在計算節點上運行的 Slurm 代理程序 |
| Federation | Federation | 聯邦 | 多個 Slurm 叢集的集合 |
| GRES | Generic RESource | 通用資源 | GPU、網路卡等特殊硬體資源 |
| Job | Job | 作業 | 使用者提交的計算任務 |
| Job Array | Job Array | 作業陣列 | 批次提交的多個相似作業 |
| Job Step | Job Step | 作業步驟 | 作業內的個別執行任務 |
| Node | Node | 節點 | 叢集中的單一計算伺服器 |
| Partition | Partition | 分區 | 具有特定限制和優先權的節點群組 |
| Priority | Priority | 優先權 | 決定作業排程順序的數值 |
| QoS | Quality of Service | 服務品質/資源配額 | 定義資源使用限制和優先權的策略 |
| Reservation | Reservation | 預留 | 為特定使用者或群組預留的資源 |
| SBATCH | SBATCH | 批次作業提交 | 用於提交批次作業的命令 |
| Scheduler | Scheduler | 排程器 | 決定作業執行順序和資源分配的元件 |
| SRUN | SRUN | 執行命令 | 在分配的節點上執行並行作業的命令 |
| Task | Task | 任務 | Job Step 中的單一程序實例 |
| TRES | Trackable RESources | 可追蹤資源 | CPU、記憶體、GPU 等可計量和追蹤的資源 |
| Wckey | Workload Characterization Key | 工作負載特徵鍵 | 用於追蹤和分類不同類型工作負載的標籤 |

<br>

---

<br>

## Slurm 節點範例
### `scontrol show nodes`

root@slurm-login-slinky-5f786bb6f9-dqcrw:/tmp# scontrol show nodes     
NodeName=c2m4-0 Arch=x86_64 CoresPerSocket=22 
   CPUAlloc=0 CPUEfctv=4 CPUTot=88 CPULoad=16.79
   AvailableFeatures=c2m4
   ActiveFeatures=c2m4
   Gres=(null)
   NodeAddr=10.244.65.123 NodeHostName=c2m4-0 Version=25.11.0
   OS=Linux 5.15.0-144-generic #157-Ubuntu SMP Mon Jun 16 07:33:10 UTC 2025 
   RealMemory=515856 AllocMem=0 FreeMem=53539 Sockets=2 Boards=1
   CoreSpecCount=42 CPUSpecList=2-43,46-87 MemSpecLimit=511760
   State=IDLE+DYNAMIC_NORM ThreadsPerCore=2 TmpDisk=0 Weight=1 Owner=N/A MCS_label=N/A
   BootTime=2025-07-22T02:59:20 SlurmdStartTime=2025-12-05T04:07:10
   LastBusyTime=2025-12-05T04:07:10 ResumeAfterTime=None
   CfgTRES=cpu=4,mem=515856M,billing=4
   AllocTRES=
   CurrentWatts=0 AveWatts=0
   Comment={"namespace":"slurm","podName":"slurm-worker-c2m4-0","node":"ntuh-dev-master01"}

<br>

---

<br>

### **節點 (Node) 屬性**

| 屬性名稱 | 說明 | 用途 | 範例值 | 備註 |
|---------|------|------|--------|------|
| **CPU 相關** |
| `CPUTot` | 節點總 CPU 數量 | 硬體實際的 CPU 總數（邏輯核心） | 88 | Sockets × CoresPerSocket × ThreadsPerCore |
| `CPUEfctv` | 有效可用 CPU 數 | 扣除系統保留後，可分配給 job 的 CPU 數 | 4 | CPUTot - CoreSpecCount |
| `CPUAlloc` | 已分配 CPU 數 | 當前已被 job 使用的 CPU 數量 | 0 | 用於監控資源使用率 |
| `CPULoad` | CPU 負載 | 節點當前的平均負載 | 18.03 | 系統實際負載，非 Slurm 控制 |
| `Sockets` | CPU 插槽數 | 實體 CPU 數量 | 2 | 硬體配置 |
| `CoresPerSocket` | 每插槽核心數 | 每顆 CPU 的實體核心數 | 22 | 硬體配置 |
| `ThreadsPerCore` | 每核心執行緒數 | 超執行緒技術，通常為 1 或 2 | 2 | 1=關閉超執行緒，2=開啟 |
| `CoreSpecCount` | 系統保留核心數 | 保留給系統使用的核心數，不分配給 job | 42 | **過高會導致可用 CPU 極少** |
| `CPUSpecList` | 系統保留 CPU 列表 | 具體保留哪些 CPU ID | 2-43,46-87 | 與 CoreSpecCount 對應 |
| **記憶體相關** |
| `RealMemory` | 實體記憶體總量 | 節點實際的 RAM 容量 (MB) | 515856M (~504GB) | 硬體配置 |
| `FreeMem` | 當前可用記憶體 | 系統層級的可用記憶體 | 53539M (~52GB) | 實時監控值 |
| `AllocMem` | 已分配記憶體 | Slurm 已分配給 job 的記憶體 | 0 | Slurm 層級的分配 |
| `MemSpecLimit` | 系統保留記憶體上限 | 保留給系統使用的記憶體量 (MB) | 511760M | **過高會導致可分配記憶體極少** |
| **狀態相關** |
| `State` | 節點狀態 | 當前運作狀態 | `IDLE` / `DOWN` | 詳見狀態表 |
| `Reason` | 狀態原因 | 非正常狀態的原因說明 | "Not responding" | DOWN 時必有原因 |
| **TRES (Trackable Resources)** |
| `CfgTRES` | 配置的可追蹤資源 | Slurm 管理的資源總量 | cpu=4,mem=515856M | 基於 CPUEfctv 計算 |
| `AllocTRES` | 已分配的資源 | 當前已分配給 job 的資源 | (空) | 用於資源追蹤 |
| **其他** |
| `Gres` | 通用資源 | GPU 等特殊資源配置 | (null) / gpu:2 | 需要額外配置 |
| `Weight` | 節點權重 | 調度優先級，數字越大越優先 | 1 | 影響 job 分配順序 |
| `TmpDisk` | 臨時磁碟空間 | /tmp 可用空間 (MB) | 0 | 0 表示未配置 |

<br>

---

<br>

### **節點狀態 (State)**

| 狀態 | 說明 | 原因 | 處理方式 |
|------|------|------|---------|
| `IDLE` | 閒置可用 | 無 job 運行，可接受新 job | 正常狀態 |
| `ALLOCATED` | 已分配 | 有 job 正在運行 | 正常狀態 |
| `MIXED` | 部分使用 | 部分 CPU/記憶體已分配，仍有空餘 | 正常狀態 |
| `DOWN` | 離線 | slurmd 未運行或網路問題 | 檢查節點服務 |
| `DRAINED` | 排空中 | 管理員手動設為不接受新 job | 使用 `scontrol update state=resume` |
| `DRAINING`(`drng`) | 排空中 | 等待現有 job 完成後下線 | 等待或取消 job |
| `NOT_RESPONDING` | 無回應 | slurmd 停止回應 | 重啟 slurmd |
| `DYNAMIC_NORM` | 動態正常 | 節點可動態創建/銷毀（雲環境） | 正常標記 |

- ### **ALLOCATED** 和 **MIXED** 的關鍵差異：
| 狀態 | 說明 | 資源使用狀態 |
|------|------|-------------|
| **ALLOCATED** | **整個節點**已被一個或多個 job 完全佔用 | 所有 CPU/記憶體資源已分配，**無剩餘資源**可供新 job 使用 |
| **MIXED** | **部分資源**已被 job 佔用 | 仍有**部分 CPU/記憶體空閒**，可接受新 job（若配置允許 job 共享節點） |

**簡單來說：**
- `ALLOCATED` = 節點滿載
- `MIXED` = 節點部分使用，仍有空間

<br>

---

<br>

## Slurm Partition 範例

### `scontrol show partition`

root@slurm-login-slinky-5f786bb6f9-dqcrw:/tmp# scontrol show partition        
PartitionName=cpu-set
   AllowGroups=ALL AllowAccounts=ALL AllowQos=ALL
   AllocNodes=ALL Default=YES QoS=N/A
   DefaultTime=NONE DisableRootJobs=NO ExclusiveUser=NO ExclusiveTopo=NO GraceTime=0 Hidden=NO
   MaxNodes=UNLIMITED MaxTime=UNLIMITED MinNodes=1 LLN=NO MaxCPUsPerNode=UNLIMITED MaxCPUsPerSocket=UNLIMITED
   Nodes=c2m4-0
   PriorityJobFactor=1 PriorityTier=1 RootOnly=NO ReqResv=NO OverSubscribe=NO
   OverTimeLimit=NONE PreemptMode=OFF
   State=UP TotalCPUs=88 TotalNodes=1 SelectTypeParameters=NONE
   JobDefaults=(null)
   DefMemPerNode=UNLIMITED MaxMemPerNode=UNLIMITED
   TRES=cpu=4,mem=515856M,node=1,billing=4

<br>

---

<br>

### **Partition 屬性**

| 屬性名稱 | 說明 | 用途 | 範例值 | 備註 |
|---------|------|------|--------|------|
| **基本設定** |
| `PartitionName` | Partition 名稱 | 識別不同的佇列 | cpu-set | 提交 job 時用 `-p` 指定 |
| `Nodes` | 包含的節點列表 | 此 partition 可使用的節點 | c2m4-0 | 可用逗號分隔多節點 |
| `Default` | 是否為預設 | 未指定 `-p` 時使用 | YES / NO | 只能有一個 default |
| `State` | Partition 狀態 | 是否可用 | UP / DOWN | DOWN 時無法提交 job |
| **資源限制** |
| `TotalCPUs` | 總 CPU 數 | partition 內所有節點的 CPU 總和 | 88 | 所有節點的 CPUTot 加總 |
| `TotalNodes` | 總節點數 | partition 內的節點數量 | 1 | - |
| `MinNodes` | 最小節點數 | job 至少需要的節點數 | 1 | 防止資源浪費 |
| `MaxNodes` | 最大節點數 | job 最多可使用的節點數 | UNLIMITED | 可限制大型 job |
| `MaxCPUsPerNode` | 每節點最大 CPU | 單節點可分配的最大 CPU 數 | UNLIMITED | 防止單 job 佔用過多 |
| `DefMemPerNode` | 預設記憶體 | 未指定 `--mem` 時的預設值 | UNLIMITED / 1024 | **UNLIMITED 可能導致分配失敗** |
| `MaxMemPerNode` | 最大記憶體 | 單節點可分配的最大記憶體 | UNLIMITED | 防止 OOM |
| **時間限制** |
| `DefaultTime` | 預設執行時間 | 未指定 `-t` 時的預設值 | NONE / 01:00:00 | NONE 表示使用 MaxTime |
| `MaxTime` | 最大執行時間 | job 執行時間上限 | UNLIMITED | 超時會被終止 |
| **權限控制** |
| `AllowGroups` | 允許的群組 | 哪些 Linux 群組可使用 | ALL / group1,group2 | 訪問控制 |
| `AllowAccounts` | 允許的帳號 | 哪些 Slurm 帳號可使用 | ALL / account1 | 計費和配額管理 |
| `AllowQos` | 允許的 QoS | 哪些服務品質等級可用 | ALL / normal,high | 優先級管理 |
| **調度設定** |
| `PriorityJobFactor` | Job 優先級因子 | 影響 job 調度順序 | 1 | 數字越大越優先 |
| `OverSubscribe` | 過度訂閱 | 是否允許共享節點 | NO / YES:4 | NO=獨占，YES=共享 |
| `ExclusiveUser` | 用戶獨占 | 同一用戶的 job 是否獨占節點 | NO / YES | 防止用戶間干擾 |
| `TRES` | Partition 的資源統計 | 可追蹤的資源總量 | cpu=4,mem=515856M | 基於節點的 CfgTRES |

<br>

---

<br>

## **常用查詢指令**

# 查看節點詳細資訊
scontrol show node <nodename>

# 查看 partition 詳細資訊
scontrol show partition <partition_name>

# 查看節點摘要
sinfo -Nel

# 查看資源使用情況
squeue -o "%.18i %.9P %.8j %.8u %.2t %.10M %.6D %R %C"
# 範例：
# JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON) CPUS
#   168   cpu-set    sleep tj_tsai@  R       0:26      1 c2m4-0 2

# 即時監控節點狀態
watch -n 2 'sinfo -Nel'

<br>

---

<br>

## 補充術語詳解

### drain & draining 的中文
- ### Question
K8s 的 drain & draining，對應的中文翻譯為何？
- ### gpt-5.2 (2025/12/16)
在 Kubernetes（K8s）情境下：

* **drain（動詞 / 指令 `kubectl drain`）**：常翻成 **「排空」**（也有人說「疏散」或「清空節點」）
* 意思是：把某個 Node 上可搬走的 Pod **驅逐（evict）**到其他 Node，讓這台機器可以維修/下線。
* **draining（進行式 / 狀態描述）**：常翻成 **「排空中」**（或「疏散中」）
* 意思是：正在進行 drain 的過程。

實務上你會常看到這種寫法：
* **Node is draining** → **節點排空中**
* **Drain the node** → **排空節點**
* **Node drained** → **節點已排空**

<br>

---

<br>

### Prolog
- ### Google AI Mode (2025/12/11)
Slurm 的 **Prolog**（前言腳本）是系統管理員定義的一系列腳本，會在作業開始執行**之前**自動在計算節點上執行。它們是 Slurm 工作負載管理器配置的關鍵部分，主要用於準備作業環境並驗證節點是否準備就緒。

## 目的與功能

Prolog 腳本對於以下任務至關重要：

* **環境準備**：設定必要的環境變數（儘管可能需要 `TaskProlog` 來設定特定的使用者作業環境變數）。
* **資源管理**：管理資源，例如電源策略（例如，與 NVIDIA 的 DPS 整合時）。
* **健康檢查**：確保分配的計算節點在使用者作業開始前是健康的且配置正確。
* **安全與清理**：複製必要檔案、管理許可證，有時與作業完成後進行清理的 Epilog（後記腳本）協同運作。

## 執行詳情

* **時機**：Prolog 腳本在資源分配後但在作業主要任務啟動前執行。
* **位置**：腳本在分配的計算節點上執行。
* **權限**：根據使用的特定配置參數，它們通常以 `SlurmUser`（在計算節點上通常是 `root`）的身份運行，而不是提交作業的使用者身份。
* **配置**：腳本的路徑在 `slurm.conf` 配置文件中使用 `Prolog` 或 `PrologSlurmctld` 等參數定義。
* **故障處理**：如果 Prolog 腳本以非零狀態退出，則作業將不會執行，並且分配的計算節點將被設為 `DRAIN`（排空）狀態，以防止在問題解決之前被進一步使用。

有關更深入的技術文件，您可以參考 SchedMD 提供的官方 Slurm Prolog 和 Epilog 指南。

<br>

---

<br>

### sackd
> - **白話解釋**
> - 在 login node 上，執行 srun / sbatch / squeue / ... 時，要先跟叢集做認證才能授權執行
> - sackd (Slurm Auth and Cred Kiosk Daemon)，是用來協助 login 節點完成認證的角色
> - **核心概念**
> - `sackd` 是 Slurm 在「非計算節點（例如 login node/pod）」上提供的 **認證與憑證服務守護程序**，讓該節點能安全地和 `slurmctld` 互動。
> - 它通常以 **本機 Unix socket** 的形式提供服務端點，供同節點上的 Slurm client 指令使用。

- ### sackd 在 Slinky 中扮演的角色
- ### gpt-5.2 (2025/12/18)
在 **Slinky（Slurm-on-Kubernetes）** 的典型部署裡，`sackd` 通常是跑在 **Login Pod** 內的一個 Slurm 守護程序，角色/用途可以用「讓登入節點也能安全地跟 Slurm 叢集互動」來概括。 ([Amazon Web Services, Inc.][20251218-A-1])

### sackd 在 Slinky 中扮演的角色

* **補足 Login Pod 的「叢集認證能力」**：Login Pod 往往不跑 `slurmd`（那是 worker/compute pod 的 daemon），但使用者會在 Login Pod 上執行 `sbatch / srun / salloc` 等 Slurm client commands；`sackd` 就是用來讓這類「不跑 slurmd 的登入節點」仍能完成對叢集的認證與憑證處理。 ([Slurm][20251218-A-2])
* **支援 configless 架構（從 controller 拉設定）**：在 Slurm 的 configless 模式下，`sackd` 可以透過 `--conf-server <slurmctld host[:port]>` 向 `slurmctld` 取得設定並寫入快取（預設在 `/run/slurm/conf`，也可由 `RUNTIME_DIRECTORY` 調整）。這讓 Login Pod 不必在映像檔內硬塞完整設定檔，也比較符合雲原生的部署方式。 ([Slurm][20251218-A-2])
* **提供本機認證服務端點（Unix socket）**：`sackd` 會在 runtime 目錄下建立並維護 `sack.socket`（預設在 `/run/slurm/`，也可用 `RUNTIME_DIRECTORY` 改位置），讓同一個 pod 內的 Slurm client commands 能透過這個 socket 使用認證服務。 ([Slurm][20251218-A-2])

### 它「不是」做什麼

* `sackd` **不是排程器**（排程/決策仍在 `slurmctld`），也 **不負責啟動計算任務**（那是 `slurmd/slurmstepd` 的範疇）。它更像是 Login Pod 的「Slurm 認證/憑證前端」。 ([Slurm][2])

[20251218-A-1]: https://aws.amazon.com/blogs/containers/running-slurm-on-amazon-eks-with-slinky/ "Running Slurm on Amazon EKS with Slinky | Containers"
[20251218-A-2]: https://slurm.schedmd.com/sackd.html "Slurm Workload Manager - sackd"

- ### sackd 是採用 munge 加解密訊息嗎?
- ### gpt-5.2 (2025/12/18)
不一定；**取決於你在 `slurm.conf` 設定的 `AuthType`**。

* 如果叢集用的是 **`AuthType=auth/munge`**：Slurm 的認證會走 **MUNGE**（需要 `munged` 與共用的 `munge.key`），也就是你說的那種「用 MUNGE 產生/驗證憑證」的機制。 ([Slurm][20251218-B-1])
* 但 **`sackd` 本身是為 `auth/slurm`（SACK）設計的登入節點認證 daemon**：官方描述它是「Slurm Auth and Cred Kiosk Daemon」，用在**沒跑 `slurmd` 的 login node**，讓 client commands 也能對叢集完成認證；而且文件也明確提到「對於使用 `auth/slurm` 的站點，`sackd` 會提供 client commands 的認證」。 ([Slurm][20251218-B-2])

所以更精準地回答你的問題：

**在 `AuthType=auth/slurm` 的架構下，`sackd` 不依賴 MUNGE 來做認證；它走的是 Slurm 的 `auth/slurm`（SACK）機制。** ([Slurm][20251218-B-2])

想快速確認你目前是哪一種：看 `slurm.conf` 的 `AuthType`（`auth/munge` vs `auth/slurm`）就能判斷。 ([Slurm][20251218-B-1])

[20251218-B-1]: https://slurm.schedmd.com/authentication.html?utm_source=chatgpt.com "Authentication Plugins - Slurm Workload Manager -"
[20251218-B-2]: https://slurm.schedmd.com/sackd.html?utm_source=chatgpt.com "sackd - Slurm Workload Manager - SchedMD"

- ### 網際網路 & Slurm 叢集元件間 & LDAP 的通訊協定與安全機制
- ### gpt-5.2 (2025/12/18)
| 場景 | 主要通訊協定 | 安全機制 | 提供的安全性重點 | 常見連接埠 | 補充 |
|------|------------|----------|---------------|----------|------|
| 網際網路 Web/API | HTTP | TLS（= HTTPS） | 機密性（加密）+完整性+伺服器驗證（可選客戶端憑證） | 80/443 | 「SSL/TLS」多半是俗稱；現代以 TLS 為主 |
| Slurm 叢集元件間（controller/worker/login/db/clients） | Slurm RPC over TCP | AuthType（`auth/munge` 或 `auth/slurm`）+（可選）TLSType（TLS） | AuthType：通訊雙方驗證/憑證；TLSType：在傳輸層提供 TLS 加密/完整性 | 常見 6817/6818 等（依設定） | 官方文件明確指出 Slurm 元件間通訊會做驗證，且可透過 `TLSType` 啟用 TLS（如 `tls/s2n`）([Slurm](https://slurm.schedmd.com/quickstart_admin.html)) |
| LDAP client ↔ server | LDAP | TLS：StartTLS 或 LDAPS | 機密性（加密）+完整性；避免 simple bind 密碼明碼傳輸 | 389（ldap/StartTLS）、636（ldaps） | OpenLDAP 文件：TLS 可透過 StartTLS 或 `ldaps://`，且 StartTLS 是標準機制；也提到常見的 389/636 ([openldap.org](https://www.openldap.org/doc/admin24/security.html)) |


- ### 延伸閱讀
- [Kubernetes Operator for Slurm Clusters -- Controller](https://slinky.schedmd.com/projects/slurm-operator/en/release-1.0/index.html#controller)
> [\!NOTE] The kubelet’s `configMapAndSecretChangeDetectionStrategy` and `syncFrequency` settings directly affect when pods have their mounted ConfigMaps and Secrets updated. By default, the kubelet is in Watch mode with a polling frequency of 60 seconds.

<br>

---

<br>

### Job vs Job Step
- ### gpt-5.2 (2026/01/07)
在 Slurm 裡：

* **Job（作業）**＝「排程與資源分配」的單位（allocation）
* **Job Step（作業步驟 / step）**＝「在這份資源裡實際啟動的一次平行執行」的單位（execution）

把它想成：

> 你去餐廳訂位（Job：訂到一張 10 人桌、2 小時）
> 在你訂到的桌子上點菜上菜（Step：先上前菜、再上主餐、也可以同時上兩道）

---

## Job 是什麼？（allocation 的擁有者）

**Job 的核心責任：**

1. **向排程器請資源**：要幾個節點、幾顆 CPU、幾張 GPU、多久、哪個 partition/QoS…
2. **排隊 / 被排到**：slurmctld 只需要決定「這個 Job 什麼時候拿到哪些資源」
3. **資源的上限框**：Job 拿到的 allocation 是上限，後面任何 step **都不能超過**這個上限

你看到的典型 Job 產生方式：

* `sbatch script.sh` → 提交一個 batch job
* `salloc ...` → 先拿 allocation（互動式）
* 有時 `srun ...`（在沒有 allocation 的情況）也會直接「申請 job + 啟一個 step」（看站台設定/用法）

---

## Job Step 是什麼？（在 allocation 裡啟動的執行）

**Step 的核心責任：**

1. **在 Job 的 allocation 裡啟動一組程序（tasks）**：例如 MPI ranks、或多節點跑你的程式
2. **定義這次啟動的執行細節**：tasks 數、每 task 幾 CPU（`--cpus-per-task`）、GPU（`--gpus-per-task`）、綁核/綁 GPU、環境變數、IO、cgroup 限制等
3. **可以有很多個**：同一個 job 裡可以跑多個 steps（可串行、也可並行）

Step 通常由這些指令產生：

* 在 job 裡呼叫 `srun ...` → 每一次 `srun` 幾乎都會建立一個新的 step
* 一些工作流會用 `srun` 啟動不同階段：前處理、訓練、後處理…（每個都是 step）

---

## 最關鍵差異：誰在管「排程」 vs 誰在管「啟動程序」

* **Job：slurmctld 管**（何時給你資源、資源給多少）
* **Step：slurmstepd / slurmd 管**（在已分配的節點上把你的 tasks 真的 fork/exec 起來、套用 cgroup/綁定等）

---

## 具體例子：一個 job 裡兩個 steps

`train.sbatch`：

    #!/bin/bash
    #SBATCH -N 2
    #SBATCH --ntasks-per-node=4
    #SBATCH --gpus-per-node=4
    #SBATCH -t 00:30:00

    # step 1：前處理（可能只用 CPU）
    srun --ntasks=2 python prep.py

    # step 2：訓練（用滿 GPU）
    srun --ntasks=8 --gpus-per-task=1 python train.py

這裡：

* **整份資源（2 nodes、每 node 4 tasks、每 node 4 GPU、30 分鐘）** 是 **Job**
* 兩行 `srun ...` 各自啟動一次平行執行，是 **兩個 Job Steps**

你在帳務/ID 上常會看到：

* JobID：`12345`
* Step：`12345.0`、`12345.1`（或 `12345.batch`、`12345.extern` 這種特殊 step 名稱）

---

## 常見誤解一次釐清

### 1) 「我已經有 sbatch 了，為什麼還要 step？」

因為 sbatch 只是拿到 allocation + 跑你的腳本；你腳本裡要啟動多節點/多 task 的程式，通常靠 `srun`，而 `srun` 就是在建立/啟動 step。

### 2) 「step 可以跟 job 要不同資源嗎？」

可以「**縮小/切片**」，但不能「超出」job allocation。

* 例如 job 拿到 8 GPUs，某個 step 可以只用 2 GPUs
* 但 step 不可能用到 10 GPUs（超過 allocation）

### 3) 「取消時差在哪？」

* `scancel <jobid>`：整個 job（所有 steps）都砍掉
* `scancel <jobid>.<stepid>`：只砍某個 step（其他 step 可能還在或之後還會跑）

---

## 一句話記法

* **Job = 你跟 Slurm「訂到的資源套餐」**
* **Step = 你在這套餐裡「按一次 srun 開跑的一次工作階段」**

如果你願意貼一段你常用的 `sbatch` 腳本（或你在 login pod 裡的 `srun` 指令），我可以直接幫你把「哪裡是 job、哪裡會產生幾個 steps、各 step 會吃到哪些資源」逐行標註出來。

<br>

---

<br>

### User Associations：General / Limits / QoS / FairShare 的功能用途？
在 Slurm 系統中，Association (關聯) 是連通「使用者 (User)」、「帳號 (Account)」與「分割區 (Partition)」的橋樑。
這四個頁籤分別定義了該使用者在該帳號下能「做什麼」以及「能用多少」：
1. **General (一般設定)**
- **功能**： 定義基礎的存取路徑。
- **用途**： 確定這個使用者在哪個 **Cluster (叢集)** 以及哪個 **Partition (分割區/佇列)** 下可以使用這個 Account。如果你希望某個使用者在 A 專案只能用 general 佇列，而在 B 專案可以用 gpu 佇列，就在這裡設定。
2. **Limits (資源限制 / 配額)**
- **功能**： 針對該「使用者 + 帳號」組合進行量化限制（TRES Limits）。
- **用途**：
- **GrpTRES (群組總量限制)**： 例如限制該使用者在此帳號下「總共」只能同時使用 100 顆 CPU 或 4 張 GPU。
- **MaxJobs / MaxSubmit**： 限制此人同時能跑幾個任務，避免單一使用者瞬間塞滿調度器。
- **MaxWall (時限)**： 限制單一任務的最長執行時間（例如不得超過 24 小時）。
3. **QoS (服務品質 - Quality of Service)**
- **功能**： 定義任務的「特權級別」與「優先順序」。
- **用途**：
- **優先權 (Priority)**： 高 QoS 的任務會在排隊時自動排到前面。
- **搶佔 (Preemption)**： 某些 QoS 允許高等級任務「踢掉」正在運行的低等級任務。
- **限制豁免**： 某些 QoS 可能允許使用者暫時超越原本的 Limits 配額。
4. **FairShare (公平分配比重)**
- **功能**： 設定調度演算法中的「權重（Shares）」。
- **用途**：
- **資源爭奪時的裁判**： 當多人同時排隊時，Slurm 會看誰的 FairShare 比較高。
- **歷史補償**： 如果某個使用者最近都沒用系統（歷史用量低），他的優先級會自動提高；反之，近期瘋狂使用的使用者，其優先級會暫時降低。
- **Raw Shares**： 你在這裡給的數字越大，代表該使用者在資源競爭時擁有的「發言權」越重。
- **總結來說：**
- **General** 決定「能不能進門」。
- **Limits** 決定「進門後能拿多少東西」。
- **QoS** 決定「拿東西時能不能插隊」。
- **FairShare** 決定「當大家都在排隊拿東西時，誰該優先」。

- ### Snapshot
- ### General
- ### Limits
- ### QoS
- ### FairShare

<br>

{%hackmd vaaMgNRPS4KGJDSFG0ZE0w %}