Slurm 適用於多個佇列模式的 指南 - AWS ParallelCluster
概觀雲端節點生命週期使用可用的節點任務狀態和提交節點狀態和功能分割區狀態pcluster 啟動和停止對佇列的手動控制擴展行為和調整新架構的日誌常見問題以及如何除錯：

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

Slurm 適用於多個佇列模式的 指南

AWS ParallelCluster 2.9.0 版為 Slurm Workload Manager(Slurm) 引進了多個佇列模式和新的擴展架構。

下列各節提供使用Slurm叢集搭配新推出的擴展架構的一般概觀。

概觀

新的擴展架構是以 Slurm的雲端排程指南和省電外掛程式為基礎。如需省電外掛程式的詳細資訊，請參閱Slurm省電指南。在新的架構中，可能可供叢集使用的資源通常會在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。相反地，在大多數情況下，靜態節點不會關閉電源。不過，可以使用 scontrol update nodename=nodename state=powering_down命令手動將節點置於 POWER_DOWN 狀態。在此狀態下，與節點相關聯的執行個體會終止，而節點會在 之後重設回 POWER_SAVING 狀態以供未來使用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（預設為 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。

分割區狀態

AWS ParallelCluster 支援下列分割區狀態。Slurm 分割區是 中的佇列 AWS ParallelCluster。

  • UP：表示分割區處於作用中狀態。這是分割區的預設狀態。在此狀態下，分割區中的所有節點皆為作用中且可供使用。

  • INACTIVE：表示分割區處於非作用中狀態。在此狀態下，非作用中分割區的所有執行個體後端節點都會終止。不會為非作用中分割區中的節點啟動新的執行個體。

pcluster 啟動和停止

執行 pcluster stop 時，所有分割區都會置於 INACTIVE 狀態，而 AWS ParallelCluster 程序會將分割區保持在 INACTIVE 狀態。

pcluster start 執行 時，所有分割區一開始都會處於 UP 狀態。不過， AWS ParallelCluster 程序不會讓分割區保持 UP 狀態。您需要手動變更分割區狀態。所有靜態節點會在幾分鐘後可用。請注意，將分割區設定為 UP不會啟動任何動態容量。如果 initial_count 大於 max_count，則在分割區狀態變更為 UP 狀態時initial_count可能無法滿足。

執行 pcluster start和 pcluster stop 時，您可以執行 pcluster status命令並檢查 ，以檢查叢集的狀態ComputeFleetStatus。下列列出可能的狀態：

  • STOP_REQUESTED：pcluster stop請求會傳送至叢集。

  • STOPPING：pcluster程序目前正在停止叢集。

  • STOPPED：pcluster程序已完成停止程序、所有分割區都處於 INACTIVE 狀態，且所有運算執行個體都會終止。

  • START_REQUESTED：pcluster start請求會傳送至叢集。

  • STARTING：pcluster程序目前正在啟動叢集

  • RUNNING：pcluster程序已完成啟動程序、所有分割區都處於 UP 狀態，且靜態節點將在幾分鐘後可用。

對佇列的手動控制

在某些情況下，您可能想要對叢集中的節點或佇列 （稱為 中的分割區Slurm) 進行一些手動控制。您可以透過下列常見程序來管理叢集中的節點。

  • 啟動處於 POWER_SAVING 狀態的動態節點：執行 scontrol update nodename=nodename state=power_up命令或提交請求特定數量節點的預留位置sleep 1任務，並依賴 Slurm 來啟動所需數量的節點。

  • 在 之前關閉動態節點的電源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) 之後，排程器會將執行個體置於 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 的整合。

  • 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，請查看 SuspendProgram 日誌中的 程式是否slurmctld以特定節點做為引數。請注意， 實際上SuspendProgram不會執行任何特定動作。相反地，它只會在呼叫時記錄。所有執行個體終止和NodeAddr重設都是由 完成clustermgtd。 會在 IDLE之後將節點Slurm放入 SuspendTimeout。

其他問題

  • AWS ParallelCluster 不會進行任務配置或擴展決策。它會簡單地嘗試根據 Slurm的指示啟動、終止和維護資源。

    如需有關任務配置、節點配置和擴展決策的問題，請查看slurmctld日誌是否有錯誤。