本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # Slurm 適用於多個佇列模式的 指南 AWS ParallelCluster 2.9.0 版為 Slurm Workload Manager(Slurm) 引進了多個佇列模式和新的擴展架構。 下列各節提供使用Slurm叢集搭配新推出的擴展架構的一般概觀。 ## 概觀 新的擴展架構是以 Slurm的[雲端排程指南](https://slurm.schedmd.com/elastic_computing.html)和省電外掛程式為基礎。如需省電外掛程式的詳細資訊，請參閱[Slurm省電指南](https://slurm.schedmd.com/power_save.html)。在新的架構中，可能可供叢集使用的資源通常會在Slurm組態中預先定義為雲端節點。 ## 雲端節點生命週期 在整個生命週期中，如果不是下列所有狀態，則雲端節點會進入數個 ：`POWER_SAVING`、 `POWER_UP`(`pow_up`)、 `ALLOCATED` (`alloc`) 和 `POWER_DOWN`(`pow_dn`)。在某些情況下，雲端節點可能會進入 `OFFLINE` 狀態。下列清單詳細說明雲端節點生命週期中這些狀態的數個層面。 + 狀態中的節點`POWER_SAVING`會在 中顯示`~`尾碼 （例如 `idle~`)`sinfo`。在此狀態下，沒有支援節點的 EC2 執行個體。不過， 仍然Slurm可以將任務配置給節點。 + 轉換為 `POWER_UP` 狀態的節點會在 中顯示尾碼 `#` （例如`idle#`)`sinfo`。 + 當 將任務Slurm配置到 `POWER_SAVING` 狀態的節點時，節點會自動傳輸到 `POWER_UP` 狀態。否則，可以使用 `scontrol update nodename=nodename state=power_up`命令手動將節點置於 `POWER_UP` 狀態。在此階段中，會`ResumeProgram`叫用 ，並啟動和設定 EC2 執行個體以傳回`POWER_UP`節點。 + 目前可供使用的節點會在 中顯示不含任何尾碼 （例如 `idle`)`sinfo`。節點設定完成並加入叢集後，即可執行任務。在此階段中，節點已正確設定並可供使用。一般而言，我們建議 EC2 中的執行個體數目與可用節點數目相同。在大多數情況下，建立叢集之後，靜態節點一律可用。 + 轉換為`POWER_DOWN`狀態的節點會在 中顯示`%`尾碼 （例如 `idle%`)`sinfo`。動態節點會在 之後自動進入 `POWER_DOWN` 狀態[`scaledown_idletime`](scaling-section.md#scaledown-idletime)。相反地，在大多數情況下，靜態節點不會關閉電源。不過，可以使用 `scontrol update nodename=nodename state=powering_down`命令手動將節點置於 `POWER_DOWN` 狀態。在此狀態下，與節點相關聯的執行個體會終止，而節點會在 之後重設回 `POWER_SAVING` 狀態以供未來使用[`scaledown_idletime`](scaling-section.md#scaledown-idletime)。`scaledown-idletime` 設定會儲存到Slurm組態做為`SuspendTimeout`設定。 + 離線的節點會在 中顯示`*`尾碼 （例如 `down*`)`sinfo`。如果Slurm控制器無法聯絡節點，或靜態節點已停用且備份執行個體終止，則節點會離線。 現在請考慮下列`sinfo`範例中顯示的節點狀態。 ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST efa up infinite 4 idle~ efa-dy-c5n18xlarge-[1-4] efa up infinite 1 idle efa-st-c5n18xlarge-1 gpu up infinite 1 idle% gpu-dy-g38xlarge-1 gpu up infinite 9 idle~ gpu-dy-g38xlarge-[2-10] ondemand up infinite 2 mix# ondemand-dy-c52xlarge-[1-2] ondemand up infinite 18 idle~ ondemand-dy-c52xlarge-[3-10],ondemand-dy-t2xlarge-[1-10] spot* up infinite 13 idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3] spot* up infinite 2 idle spot-st-t2large-[1-2] ``` `spot-st-t2large-[1-2]` 和 `efa-st-c5n18xlarge-1`節點已設定備份執行個體，且可供使用。`ondemand-dy-c52xlarge-[1-2]` 節點處於 `POWER_UP` 狀態，應該可在幾分鐘內使用。`gpu-dy-g38xlarge-1` 節點處於 `POWER_DOWN` 狀態，並在 [`scaledown_idletime`](scaling-section.md#scaledown-idletime)（預設為 120 秒） 之後轉換為 `POWER_SAVING` 狀態。 所有其他節點都處於 `POWER_SAVING` 狀態，沒有支援它們的 EC2 執行個體。 ## 使用可用的節點 可用的節點由 EC2 執行個體支援。根據預設，節點名稱可用來直接將 SSH 傳入執行個體 （例如 `ssh efa-st-c5n18xlarge-1`)。您可以使用 `scontrol show nodes nodename`命令並檢查 `NodeAddr` 欄位來擷取執行個體的私有 IP 地址。對於無法使用的節點， `NodeAddr` 欄位不應指向執行中的 EC2 執行個體。相反地，它應該與節點名稱相同。 ## 任務狀態和提交 在大多數情況下提交的任務會立即配置到系統中的節點，如果配置了所有節點，則會置於待定狀態。 如果為任務配置的節點包含任何處於 `POWER_SAVING` 狀態的節點，任務會以 `CF`、 或 `CONFIGURING` 狀態開始。此時，任務會等待`POWER_SAVING`處於 狀態的節點轉換為 `POWER_UP` 狀態並變成可用。 在為任務配置的所有節點都可用之後，任務會進入 `RUNNING`(`R`) 狀態。 根據預設，所有任務都會提交至預設佇列 （在 中稱為分割區Slurm)。這是由佇列名稱後面的`*`尾碼所表示。您可以使用`-p`任務提交選項來選取佇列。 所有節點都設定了下列功能，可用於任務提交命令： + 執行個體類型 （例如 `c5.xlarge`) + 節點類型 （這是 `dynamic`或 `static`。) 您可以使用 `scontrol show nodes nodename`命令並檢查`AvailableFeatures`清單，查看特定節點可用的所有功能。 另一個考量是任務。首先考慮叢集的初始狀態，您可以透過執行 `sinfo`命令來檢視。 ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST efa up infinite 4 idle~ efa-dy-c5n18xlarge-[1-4] efa up infinite 1 idle efa-st-c5n18xlarge-1 gpu up infinite 10 idle~ gpu-dy-g38xlarge-[1-10] ondemand up infinite 20 idle~ ondemand-dy-c52xlarge-[1-10],ondemand-dy-t2xlarge-[1-10] spot* up infinite 13 idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3] spot* up infinite 2 idle spot-st-t2large-[1-2] ``` 請注意， `spot`是預設佇列。它以`*`尾碼表示。 將任務提交至一個靜態節點至預設佇列 (`spot`)。 ``` $ sbatch --wrap "sleep 300" -N 1 -C static ``` 將任務提交至`EFA`佇列的一個動態節點。 ``` $ sbatch --wrap "sleep 300" -p efa -C dynamic ``` 將任務提交至八 (8) 個`c5.2xlarge`節點，並將兩 (2) 個`t2.xlarge`節點提交至`ondemand`佇列。 ``` $ sbatch --wrap "sleep 300" -p ondemand -N 10 -C "[c5.2xlarge*8&t2.xlarge*2]" ``` 將任務提交至佇列的一個 GPU 節點`gpu`。 ``` $ sbatch --wrap "sleep 300" -p gpu -G 1 ``` 現在使用 `squeue`命令來考慮任務的狀態。 ``` $ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 12 ondemand wrap ubuntu CF 0:36 10 ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2] 13 gpu wrap ubuntu CF 0:05 1 gpu-dy-g38xlarge-1 7 spot wrap ubuntu R 2:48 1 spot-st-t2large-1 8 efa wrap ubuntu R 0:39 1 efa-dy-c5n18xlarge-1 ``` 任務 7 和 8 （在 `spot`和 `efa`佇列中） 已在執行 ()`R`。任務 12 和 13 仍在設定 (`CF`)，可能正在等待執行個體變成可用。 ``` # Nodes states corresponds to state of running jobs $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST efa up infinite 3 idle~ efa-dy-c5n18xlarge-[2-4] efa up infinite 1 mix efa-dy-c5n18xlarge-1 efa up infinite 1 idle efa-st-c5n18xlarge-1 gpu up infinite 1 mix~ gpu-dy-g38xlarge-1 gpu up infinite 9 idle~ gpu-dy-g38xlarge-[2-10] ondemand up infinite 10 mix# ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2] ondemand up infinite 10 idle~ ondemand-dy-c52xlarge-[9-10],ondemand-dy-t2xlarge-[3-10] spot* up infinite 13 idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3] spot* up infinite 1 mix spot-st-t2large-1 spot* up infinite 1 idle spot-st-t2large-2 ``` ## 節點狀態和功能 在大多數情況下，節點狀態由 AWS ParallelCluster 依據本主題稍早所述的雲端節點生命週期中的特定程序進行完整管理。 不過， AWS ParallelCluster 也會取代或終止 `DOWN`和 `DRAINED` 狀態中運作狀態不佳的節點，以及具有運作狀態不佳後端執行個體的節點。如需詳細資訊，請參閱[`clustermgtd`](processes.md#clustermgtd)。 ## 分割區狀態 AWS ParallelCluster 支援下列分割區狀態。Slurm 分割區是 中的佇列 AWS ParallelCluster。 + `UP`：表示分割區處於作用中狀態。這是分割區的預設狀態。在此狀態下，分割區中的所有節點皆為作用中且可供使用。 + `INACTIVE`：表示分割區處於非作用中狀態。在此狀態下，非作用中分割區的所有執行個體備份節點都會終止。不會為非作用中分割區中的節點啟動新的執行個體。 ## pcluster 啟動和停止 執行 [`pcluster stop`](pcluster.stop.md) 時，所有分割區都會置於 `INACTIVE` 狀態，而 AWS ParallelCluster 程序會將分割區保持在 `INACTIVE` 狀態。 執行 [`pcluster start`](pcluster.start.md) 時，所有分割區一開始都會處於 `UP` 狀態。不過， AWS ParallelCluster 程序不會將分割區保持在 `UP` 狀態。您需要手動變更分割區狀態。所有靜態節點會在幾分鐘後可用。請注意，將分割區設定為 `UP`不會啟動任何動態容量。如果 [`initial_count`](compute-resource-section.md#compute-resource-initial-count) 大於 [`max_count`](compute-resource-section.md#compute-resource-max-count)，則當分割區狀態變更為 `UP` 狀態時， [`initial_count`](compute-resource-section.md#compute-resource-initial-count) 可能無法滿足。 執行 [`pcluster start`](pcluster.start.md)和 [`pcluster stop`](pcluster.stop.md) 時，您可以執行 [`pcluster status`](pcluster.status.md)命令並檢查 ，以檢查叢集的狀態`ComputeFleetStatus`。下列列出可能的狀態： + `STOP_REQUESTED`：[`pcluster stop`](pcluster.stop.md)請求會傳送至叢集。 + `STOPPING`：`pcluster`程序目前正在停止叢集。 + `STOPPED`：`pcluster`程序已完成停止程序、所有分割區都處於 `INACTIVE` 狀態，且所有運算執行個體都會終止。 + `START_REQUESTED`：[`pcluster start`](pcluster.start.md)請求會傳送至叢集。 + `STARTING`：`pcluster`程序目前正在啟動叢集 + `RUNNING`：`pcluster`程序已完成啟動程序、所有分割區都處於 `UP` 狀態，且靜態節點將在幾分鐘後可用。 ## 對佇列的手動控制 在某些情況下，您可能想要對叢集中的節點或佇列 （在 中稱為分割區Slurm) 進行一些手動控制。您可以透過下列常見程序來管理叢集中的節點。 + 啟動處於 `POWER_SAVING` 狀態的動態節點：執行 `scontrol update nodename=nodename state=power_up`命令或提交請求特定數量節點的預留位置`sleep 1`任務，並依賴 Slurm 來啟動所需數量的節點。 + 在 之前關閉動態節點的電源[`scaledown_idletime`](scaling-section.md#scaledown-idletime)：`DOWN`使用 `scontrol update nodename=nodename state=down` command. AWS ParallelCluster automatic 終止和重設關閉的動態節點，將動態節點設定為 。一般而言，我們不建議`POWER_DOWN`直接使用 `scontrol update nodename=nodename state=power_down`命令將節點設定為 。這是因為 AWS ParallelCluster 會自動處理關機程序。不需要手動介入。因此，我們建議您`DOWN`盡可能嘗試將節點設定為 。 + 停用佇列 （分割區） 或停止特定分割區中的所有靜態節點：`INACTIVE`使用 `scontrol update partition=queue name state=inactive`命令將特定佇列設定為 。這樣做會終止分割區中所有備份節點的執行個體。 + 啟用佇列 （分割區）：`INACTIVE`使用 `scontrol update partition=queue name state=up`命令將特定佇列設定為 。 ## 擴展行為和調整 以下是正常擴展工作流程的範例： + 排程器會收到需要兩個節點的任務。 + 排程器會將兩個節點轉換為 `POWER_UP` 狀態，並使用`ResumeProgram`節點名稱呼叫 （例如 `queue1-dy-c5xlarge-[1-2]`)。 + `ResumeProgram` 會啟動兩個 EC2 執行個體，並指派 的私有 IP 地址和主機名稱`queue1-dy-c5xlarge-[1-2]`，等待 `ResumeTimeout`（預設期間為 60 分鐘 (1 小時）)，然後再重設節點。 + 執行個體已設定並加入叢集。任務開始在執行個體上執行。 + 任務已完成。 + 經過設定的 `SuspendTime` （設定為 [`scaledown_idletime`](scaling-section.md#scaledown-idletime)) 之後，排程器會將執行個體置於 `POWER_SAVING` 狀態。排程器`queue1-dy-c5xlarge-[1-2]`會進入 `POWER_DOWN` 狀態`SuspendProgram`，並使用節點名稱呼叫 。 + `SuspendProgram` 會針對兩個節點呼叫 。節點會保持 `POWER_DOWN` 狀態，例如，保留 `idle%` `SuspendTimeout`（預設期間為 120 秒 (2 分鐘）)。在 `clustermgtd`偵測到節點正在關閉電源後，它會終止備份執行個體。然後，它會`queue1-dy-c5xlarge-[1-2]`將 設定為閒置狀態，並重設私有 IP 地址和主機名稱，以便再次為未來的任務開啟電源。 現在，如果發生錯誤，且特定節點的執行個體因為某些原因而無法啟動，則會發生下列情況。 + 排程器收到需要兩個節點的任務。 + 排程器會將兩個雲端爆量節點置於 `POWER_UP` 狀態，並使用節點名稱`ResumeProgram`呼叫 （例如 `queue1-dy-c5xlarge-[1-2]`)。 + `ResumeProgram` 只會啟動一 (1) 個 EC2 執行個體並設定 `queue1-dy-c5xlarge-1`，但無法啟動 的執行個體`queue1-dy-c5xlarge-2`。 + `queue1-dy-c5xlarge-1` 不會受到影響，且會在達到 `POWER_UP` 狀態後上線。 + `queue1-dy-c5xlarge-2` 處於 `POWER_DOWN` 狀態，且任務會自動排入佇列，因為 Slurm偵測到節點故障。 + `queue1-dy-c5xlarge-2` 會在 `SuspendTimeout`（預設值為 120 秒 (2 分鐘）) 後變成可用。同時，任務會重新排入佇列，並且可以在另一個節點上開始執行。 + 上述程序會重複執行，直到任務可以在可用的節點上執行，而不會發生故障為止。 如有需要，可以調整兩個計時參數。 + `ResumeTimeout` （預設值為 60 分鐘 (1 小時）)： `ResumeTimeout`控制節點處於關閉狀態之前Slurm等待的時間。 + 如果您的安裝前/後程序需要近乎這麼長的時間，擴展此項目可能很有用。 + 如果發生問題，這也是在取代或重設節點之前 AWS ParallelCluster 等待的時間上限。如果在啟動或設定期間發生任何錯誤，運算節點會自行終止。接著， AWS ParallelCluster 程序也會在看到執行個體終止時取代節點。 + `SuspendTimeout` （預設值為 120 秒 (2 分鐘）)：`SuspendTimeout`控制節點放回系統並準備好再次使用的速度。 + 較短`SuspendTimeout`表示節點將更快重設，並且Slurm能夠更頻繁地嘗試啟動執行個體。 + 較長`SuspendTimeout`會使失敗的節點重設速度變慢。同時，Slurm輪胎會使用其他節點。如果 `SuspendTimeout` 超過幾分鐘， Slurm 會嘗試循環系統中的所有節點。較長`SuspendTimeout`的時間可能有助於大規模系統 （超過 1，000 個節點）Slurm，透過經常重新佇列失敗的任務來減少對 的壓力。 + 請注意， `SuspendTimeout`不是指等待 AWS ParallelCluster 終止節點備份執行個體的時間。`power down` 節點的備份執行個體會立即終止。終止程序通常會完成幾分鐘。不過，在此期間，節點會保持關機狀態，且無法在排程器中使用。 ## 新架構的日誌 下列燈光包含多個佇列架構的金鑰日誌。與 Amazon CloudWatch Logs 搭配使用的日誌串流名稱格式為 `{hostname}.{instance_id}.{logIdentifier}`，其中 *logIdentifier* 遵循日誌名稱。如需詳細資訊，請參閱[與 Amazon CloudWatch Logs 的整合](cloudwatch-logs.md)。 + `ResumeProgram`: `/var/log/parallelcluster/slurm_resume.log` (`slurm_resume`) + `SuspendProgram`: `/var/log/parallelcluster/slurm_suspend.log` (`slurm_suspend`) + `clustermgtd`: `/var/log/parallelcluster/clustermgtd.log` (`clustermgtd`) + `computemgtd`: `/var/log/parallelcluster/computemgtd.log` (`computemgtd`) + `slurmctld`: `/var/log/slurmctld.log` (`slurmctld`) + `slurmd`: `/var/log/slurmd.log` (`slurmd`) ## 常見問題以及如何除錯： **無法啟動、開啟電源或加入叢集的節點： ** + 動態節點： + 檢查`ResumeProgram`日誌，查看是否`ResumeProgram`曾經使用節點呼叫 。如果沒有，請檢查`slurmctld`日誌以判斷是否Slurm曾經嘗試`ResumeProgram`使用節點呼叫 。請注意， 上的許可不正確`ResumeProgram`可能會導致其無提示失敗。 + 如果呼叫 `ResumeProgram` ，請檢查是否已為節點啟動執行個體。如果無法啟動執行個體，則應有清楚的錯誤訊息，說明執行個體無法啟動的原因。 + 如果執行個體已啟動，在引導程序期間可能有些問題。從`ResumeProgram`日誌尋找對應的私有 IP 地址和執行個體 ID，並在 CloudWatch Logs 中查看特定執行個體的對應引導日誌。 + 靜態節點： + 檢查`clustermgtd`日誌，查看是否已為節點啟動執行個體。如果沒有，執行個體無法啟動的原因應該會發生明確的錯誤。 + 如果執行個體已啟動，則在引導程序期間會發生一些問題。從`clustermgtd`日誌尋找對應的私有 IP 和執行個體 ID，並查看 CloudWatch Logs 中特定執行個體的對應引導日誌。 **節點意外取代或終止、節點故障** + 節點意外取代/終止 + 在大多數情況下， 會`clustermgtd`處理所有節點維護動作。若要檢查是否已`clustermgtd`取代或終止節點，請檢查`clustermgtd`日誌。 + 如果`clustermgtd`取代或終止節點，應該會出現一則訊息，指出動作的原因。如果原因與排程器相關 （例如，節點是 `DOWN`)，請查看`slurmctld`日誌以取得更多詳細資訊。如果原因與 EC2 相關，請使用 工具來檢查該執行個體的狀態或日誌。例如，您可以檢查執行個體是否有排程事件或 EC2 運作狀態檢查失敗。 + 如果 `clustermgtd`未終止節點，請檢查是否已`computemgtd`終止節點，或 EC2 是否已終止執行個體以回收 Spot 執行個體。 + 節點故障 + 在大多數情況下，如果節點失敗，任務會自動重新排入佇列。在`slurmctld`日誌中查看任務或節點失敗的原因，並從那裡分析情況。 **更換或終止執行個體時失敗，關閉節點時失敗** + 一般而言， `clustermgtd`會處理所有預期的執行個體終止動作。查看`clustermgtd`日誌，了解為什麼無法取代或終止節點。 + 對於 故障的動態節點[`scaledown_idletime`](scaling-section.md#scaledown-idletime)，請查看 `SuspendProgram`日誌，查看 的程式是否`slurmctld`以特定節點做為引數。請注意， 實際上`SuspendProgram`不會執行任何特定動作。相反地，它只會在呼叫時記錄。所有執行個體終止和`NodeAddr`重設都是由 完成`clustermgtd`。 會在 `IDLE`之後將節點Slurm放入 `SuspendTimeout`。 **其他問題** + AWS ParallelCluster 不會進行任務配置或擴展決策。它會簡單地嘗試根據 Slurm的指示啟動、終止和維護資源。 如需有關任務配置、節點配置和擴展決策的問題，請查看`slurmctld`日誌是否有錯誤。