本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # Slurm 適用於多個佇列模式的 指南 在這裡，您可以了解如何 AWS ParallelCluster 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_UP` 狀態的節點時，節點會自動轉換為 `POWER_SAVING` 狀態。 或者，您可以使用 命令，以`su`根使用者身分手動將節點轉換為 `POWER_UP` 狀態： ``` $ scontrol update nodename={{nodename}} state=power_up ``` 在此階段中，會`ResumeProgram`叫用 、啟動和設定 EC2 執行個體，以及節點轉換為 `POWER_UP` 狀態。 + **目前可供使用的節點會在 **中顯示沒有尾碼 （例如 `idle`)`sinfo`。節點設定完成並加入叢集後，即可執行任務。在此階段中，節點已正確設定並可供使用。 一般而言，我們建議 Amazon EC2 執行個體的數量與可用節點的數量相同。在大多數情況下，靜態節點會在建立叢集後可用。 + **轉換為`POWER_DOWN`狀態的節點會在 **中顯示`%`尾碼 （例如 `idle%`)`sinfo`。動態節點會在 之後自動進入 `POWER_DOWN` 狀態[`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)。相反地，在大多數情況下，靜態節點不會關閉電源。不過，您可以使用 命令，以`su`根使用者身分手動將節點置於 `POWER_DOWN` 狀態： ``` $ scontrol update nodename={{nodename}} state=down reason="manual draining" ``` 在此狀態下，與節點相關聯的執行個體會終止，而節點會設回 `POWER_SAVING` 狀態，並在 之後使用[`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)。 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 設定會儲存至Slurm組態設定`SuspendTimeout`。 + **離線的節點會在 **中顯示`*`尾碼 （例如 `down*`)`sinfo`。如果Slurm控制器無法聯絡節點，或靜態節點已停用且備份執行個體終止，節點就會離線。 考慮以下`sinfo`範例中顯示的節點狀態。 ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST efa up infinite 4 idle~ efa-dy-efacompute1-[1-4] efa up infinite 1 idle efa-st-efacompute1-1 gpu up infinite 1 idle% gpu-dy-gpucompute1-1 gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10] ondemand up infinite 2 mix# ondemand-dy-ondemandcompute1-[1-2] ondemand up infinite 18 idle~ ondemand-dy-ondemandcompute1-[3-10],ondemand-dy-ondemandcompute2-[1-10] spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3] spot* up infinite 2 idle spot-st-spotcompute2-[1-2] ``` `spot-st-spotcompute2-[1-2]` 和 `efa-st-efacompute1-1`節點已設定備份執行個體，且可供使用。`ondemand-dy-ondemandcompute1-[1-2]` 節點處於 `POWER_UP` 狀態，應該可在幾分鐘內使用。`gpu-dy-gpucompute1-1` 節點處於 `POWER_DOWN` 狀態，並在 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)（預設為 10 分鐘） 之後轉換為 `POWER_SAVING` 狀態。 所有其他節點都處於 `POWER_SAVING` 狀態，沒有 EC2 執行個體支援這些節點。 ## 使用可用的節點 可用的節點由 Amazon EC2 執行個體支援。根據預設，節點名稱可用來直接將 SSH 傳入執行個體 （例如 `ssh efa-st-efacompute1-1`)。您可以使用 命令擷取執行個體的私有 IP 地址： ``` $ scontrol show nodes {{nodename}} ``` 檢查傳回`NodeAddr`欄位中的 IP 地址。 對於無法使用的節點， `NodeAddr` 欄位不應指向執行中的 Amazon 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-efacompute1-[1-4] efa up infinite 1 idle efa-st-efacompute1-1 gpu up infinite 10 idle~ gpu-dy-gpucompute1-[1-10] ondemand up infinite 20 idle~ ondemand-dy-ondemandcompute1-[1-10],ondemand-dy-ondemandcompute2-[1-10] spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3] spot* up infinite 2 idle spot-st-spotcompute2-[1-2] ``` 請注意， `spot`是預設佇列。它以`*`尾碼表示。 將任務提交至預設佇列中的一個靜態節點 (`spot`)。 ``` $ sbatch --wrap {{"sleep 300"}} -N {{1}} -C {{static}} ``` 將任務提交至`EFA`佇列中的一個動態節點。 ``` $ sbatch --wrap {{"sleep 300"}} -p {{efa}} -C {{dynamic}} ``` 將任務提交至`ondemand`佇列中的八 (8) 個`c5.2xlarge`節點和兩 (2) 個`t2.xlarge`節點。 ``` $ 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-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2] 13 gpu wrap ubuntu CF 0:05 1 gpu-dy-gpucompute1-1 7 spot wrap ubuntu R 2:48 1 spot-st-spotcompute2-1 8 efa wrap ubuntu R 0:39 1 efa-dy-efacompute1-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-efacompute1-[2-4] efa up infinite 1 mix efa-dy-efacompute1-1 efa up infinite 1 idle efa-st-efacompute1-1 gpu up infinite 1 mix~ gpu-dy-gpucompute1-1 gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10] ondemand up infinite 10 mix# ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2] ondemand up infinite 10 idle~ ondemand-dy-ondemandcompute1-[9-10],ondemand-dy-ondemandcompute2-[3-10] spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3] spot* up infinite 1 mix spot-st-spotcompute2-1 spot* up infinite 1 idle spot-st-spotcompute2-2 ``` ## 節點狀態和功能 在大多數情況下，節點狀態由 AWS ParallelCluster 依據本主題稍早所述的雲端節點生命週期中的特定程序進行完整管理。 不過， AWS ParallelCluster 也會取代或終止 `DOWN`和 `DRAINED` 狀態中運作狀態不佳的節點，以及具有運作狀態不佳後端執行個體的節點。如需詳細資訊，請參閱[`clustermgtd`](processes-v3.md#clustermgtd-v3)。 ## 分割區狀態 AWS ParallelCluster 支援下列分割區狀態。Slurm 分割區是其中的佇列 AWS ParallelCluster。 + `UP`：表示分割區處於作用中狀態。這是分割區的預設狀態。在此狀態下，分割區中的所有節點皆為作用中且可供使用。 + `INACTIVE`：表示分割區處於非作用中狀態。在此狀態下，非作用中分割區的所有執行個體備份節點都會終止。不會為非作用中分割區中的節點啟動新的執行個體。 ## pcluster update-compute-fleet + **停止運算機群** - 執行下列命令時，所有分割區都會轉換為 `INACTIVE` 狀態，而 AWS ParallelCluster 程序會將分割區保持在 `INACTIVE` 狀態。 ``` $ pcluster update-compute-fleet --cluster-name {{testSlurm}} \ --region {{eu-west-1}} --status STOP_REQUESTED ``` + **啟動運算機群** - 執行下列命令時，所有分割區一開始都會轉換為 `UP` 狀態。不過， AWS ParallelCluster 程序不會將分割區保持在 `UP` 狀態。您需要手動變更分割區狀態。所有靜態節點會在幾分鐘後可用。請注意，將分割區設定為 `UP`不會啟動任何動態容量。 ``` $ pcluster update-compute-fleet --cluster-name {{testSlurm}} \ --region {{eu-west-1}} --status START_REQUESTED ``` 執行 `update-compute-fleet` 時，您可以執行 `pcluster describe-compute-fleet`命令並檢查 ，以檢查叢集的狀態`Status`。下列列出可能的狀態： + `STOP_REQUESTED`：停止運算機群請求會傳送至叢集。 + `STOPPING`：`pcluster`程序目前正在停止運算機群。 + `STOPPED`：`pcluster`程序已完成停止程序、所有分割區都處於 `INACTIVE` 狀態，且所有運算執行個體都會終止。 + `START_REQUESTED`：啟動運算機群請求會傳送至叢集。 + `STARTING`：`pcluster`程序目前正在啟動叢集。 + `RUNNING`：`pcluster`程序已完成啟動程序、所有分割區都處於 `UP` 狀態，且幾分鐘後可使用靜態節點。 + `PROTECTED`：此狀態表示某些分割區具有一致的引導失敗。受影響的分割區處於非作用中狀態。請調查問題，然後執行 `update-compute-fleet`以重新啟用機群。 ## 手動控制佇列 在某些情況下，您可能想要對叢集中的節點或佇列 （在 中稱為分割區Slurm) 進行一些手動控制。您可以使用 `scontrol`命令，透過下列常見程序來管理叢集中的節點。 + **啟動處於 `POWER_SAVING` 狀態的動態節點** 以`su`根使用者身分執行 命令： ``` $ scontrol update nodename={{nodename}} state=power_up ``` 您也可以提交請求特定數量節點的預留位置`sleep 1`任務，然後依賴 Slurm 來啟動所需的節點數量。 + **在 之前關閉動態節點 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)** 我們建議您使用 命令將動態節點設定為 `DOWN`作為`su`根使用者： ``` $ scontrol update nodename={{nodename}} state=down reason="manually draining" ``` AWS ParallelCluster 會自動終止和重設下降的動態節點。 一般而言，我們不建議您`POWER_DOWN`直接使用 `scontrol update nodename={{nodename}} state=power_down`命令將節點設定為 。這是因為 AWS ParallelCluster 會自動處理關機程序。 + **停用佇列 （分割區） 或停止特定分割區中的所有靜態節點** 使用 命令將特定佇列設定為 `INACTIVE`做為`su`根使用者： ``` $ scontrol update partition={{queuename}} state=inactive ``` 這樣做會終止分割區中的所有執行個體備份節點。 + **啟用佇列 （分割區）** 使用 命令`UP`將特定佇列設定為`su`根使用者： ``` $ scontrol update partition={{queuename}} state=up ``` ## 擴展行為和調整 **以下是正常擴展工作流程的範例：** + 排程器會收到需要兩個節點的任務。 + 排程器會將兩個節點轉換為 `POWER_UP` 狀態，並使用`ResumeProgram`節點名稱呼叫 （例如 `queue1-dy-spotcompute1-[1-2]`)。 + `ResumeProgram` 會啟動兩個 Amazon EC2 執行個體，並指派 的私有 IP 地址和主機名稱`queue1-dy-spotcompute1-[1-2]`，等待 `ResumeTimeout`（預設期間為 30 分鐘，然後再重設節點。 + 已設定執行個體並加入叢集。任務開始在執行個體上執行。 + 任務完成並停止執行。 + 經過設定的 `SuspendTime` （設定為 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)) 之後，排程器會將執行個體設定為 `POWER_SAVING` 狀態。排程器接著會`queue1-dy-spotcompute1-[1-2]`設定為 `POWER_DOWN` 狀態`SuspendProgram`，並使用節點名稱呼叫 。 + `SuspendProgram` 會針對兩個節點呼叫 。節點會保持 `POWER_DOWN` 狀態，例如，保留 `idle%` `SuspendTimeout`（預設期間為 120 秒 (2 分鐘）)。在 `clustermgtd`偵測到節點正在關閉電源後，它會終止備份執行個體。然後，它會轉換為`queue1-dy-spotcompute1-[1-2]`閒置狀態，並重設私有 IP 地址和主機名稱，以便為未來的任務做好準備。 **如果發生錯誤，且特定節點的執行個體因為某些原因而無法啟動，則會發生下列情況：** + 排程器會收到需要兩個節點的任務。 + 排程器會將兩個雲端爆量節點轉換為 `POWER_UP` 狀態`ResumeProgram`，並使用節點名稱呼叫 （例如 `queue1-dy-spotcompute1-[1-2]`)。 + `ResumeProgram` 只會啟動一 (1) 個 Amazon EC2 執行個體`queue1-dy-spotcompute1-1`，並設定 ，其中一 (1) 個執行個體 `queue1-dy-spotcompute1-2`無法啟動。 + `queue1-dy-spotcompute1-1` 不會受到影響，並在達到 `POWER_UP` 狀態後上線。 + `queue1-dy-spotcompute1-2` 會轉換為 `POWER_DOWN` 狀態，且任務會自動排入佇列，因為 Slurm偵測到節點故障。 + `queue1-dy-spotcompute1-2` 會在 `SuspendTimeout`（預設值為 120 秒 (2 分鐘）) 之後提供。同時，任務會重新排入佇列，並且可以在另一個節點上開始執行。 + 上述程序會重複執行，直到任務可以在可用的節點上執行，而不會發生失敗。 **如有需要，可以調整兩個計時參數：** + **`ResumeTimeout` （預設值為 30 分鐘）**：`ResumeTimeout`控制節點轉換為停機狀態之前Slurm等待的時間。 + `ResumeTimeout` 如果您的安裝前/後程序需要近乎這麼長的時間，擴展可能很有用。 + `ResumeTimeout` 如果發生問題， 也是取代或重設節點之前 AWS ParallelCluster 等待的時間上限。如果在啟動或設定期間發生任何錯誤，運算節點會自行終止。 會在偵測到已終止的執行個體時 AWS ParallelCluster 處理取代節點。 + **`SuspendTimeout` （預設值為 120 秒 (2 分鐘）)**：`SuspendTimeout`控制節點放回系統並準備好再次使用的速度。 + 較短`SuspendTimeout`表示節點重設速度更快，並且Slurm可以嘗試更頻繁地啟動執行個體。 + 較長`SuspendTimeout`表示失敗的節點重設速度較慢。同時， Slurm 會嘗試使用其他節點。如果 `SuspendTimeout` 超過幾分鐘， Slurm 會嘗試循環系統中的所有節點。較長`SuspendTimeout`的時間可能有利於大規模系統 （超過 1，000 個節點），以減少其嘗試頻繁重新排入佇列失敗任務Slurm時的壓力。 + 請注意， `SuspendTimeout`不是指 AWS ParallelCluster 等待終止節點備份執行個體的時間。`POWER_DOWN` 節點的備份執行個體會立即終止。終止程序通常會在幾分鐘內完成。不過，在此期間，節點會保持 `POWER_DOWN` 狀態，且不適用於排程器。 ## 架構的日誌 下列清單包含金鑰日誌。與 Amazon CloudWatch Logs 搭配使用的日誌串流名稱格式為 `{{{hostname}}}.{{{instance_id}}}.{{{logIdentifier}}}`，其中 {{logIdentifier}} 遵循日誌名稱。 + `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`日誌以取得更多詳細資訊。如果原因與 Amazon EC2 相關，請使用 Amazon CloudWatch 或 Amazon EC2 主控台、CLI 或 SDKs 等工具來檢查該執行個體的狀態或日誌。例如，您可以檢查執行個體是否有排程事件或 Amazon EC2 運作狀態檢查失敗。 + 如果 `clustermgtd`未終止節點，請檢查是否已`computemgtd`終止節點，或 EC2 是否已終止執行個體以回收 Spot 執行個體。 + 節點故障： + 在大多數情況下，如果節點失敗，任務會自動重新排入佇列。在`slurmctld`日誌中查看任務或節點失敗的原因，並從那裡評估情況。 **更換或終止執行個體時失敗，關閉節點時失敗** + 一般而言， `clustermgtd`會處理所有預期的執行個體終止動作。在`clustermgtd`日誌中查看 無法取代或終止節點的原因。 + 對於 故障的動態節點[`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)，請查看`SuspendProgram`日誌中的 `slurmctld` 程序是否使用特定節點做為引數進行呼叫。請注意， 實際上`SuspendProgram`不會執行任何特定動作。相反地，它只會在呼叫時記錄。所有執行個體終止和`NodeAddr`重設都會由 完成`clustermgtd`。 會在 `IDLE`之後將節點Slurm轉換為 `SuspendTimeout`。 **其他問題：** + AWS ParallelCluster 不會進行任務配置或擴展決策。它只會嘗試根據 Slurm的指示啟動、終止和維護資源。 如需有關任務配置、節點配置和擴展決策的問題，請查看`slurmctld`日誌是否有錯誤。