本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
Slurm 多個佇列模式的 指南
在這裡,您可以了解如何 AWS ParallelCluster 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_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。相反地,在大多數情況下,靜態節點不會關閉電源。不過,您可以使用 命令,以su
根使用者身分手動將節點置於POWER_DOWN
狀態:$
scontrol update nodename=
nodename
state=down reason="manual draining"在此狀態下,與節點相關聯的執行個體會終止,而節點會設回
POWER_SAVING
狀態,並在 之後使用ScaledownIdletime。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(預設為 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"
-N1
-Cstatic
將任務提交至EFA
佇列中的一個動態節點。
$
sbatch --wrap
"sleep 300"
-pefa
-Cdynamic
將任務提交至ondemand
佇列中的八 (8) 個c5.2xlarge
節點和兩 (2) 個t2.xlarge
節點。
$
sbatch --wrap
"sleep 300"
-pondemand
-N10
-C "[c5.2xlarge*8&t2.xlarge*2
]"
將任務提交至gpu
佇列中的一個 GPU 節點。
$
sbatch --wrap
"sleep 300"
-pgpu
-G1
使用 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。
分割區狀態
AWS ParallelCluster 支援下列分割區狀態。Slurm 分割區是 中的佇列 AWS ParallelCluster。
-
UP
:表示分割區處於作用中狀態。這是分割區的預設狀態。在此狀態下,分割區中的所有節點都處於作用中狀態且可供使用。 -
INACTIVE
:表示分割區處於非作用中狀態。在此狀態下,非作用中分割區的所有執行個體後端節點都會終止。不會為非作用中分割區中的節點啟動新的執行個體。
pcluster update-compute-fleet
-
停止運算機群 - 執行下列命令時,所有分割區都會轉換為
INACTIVE
狀態,而 AWS ParallelCluster 程序會將分割區保持在INACTIVE
狀態。$
pcluster update-compute-fleet --cluster-name
testSlurm
\ --regioneu-west-1
--status STOP_REQUESTED -
啟動運算機群 - 執行下列命令時,所有分割區一開始都會轉換為
UP
狀態。不過, AWS ParallelCluster 處理程序不會讓分割區保持UP
狀態。您需要手動變更分割區狀態。所有靜態節點都會在幾分鐘後變成可用。請注意,將分割區設定為UP
不會開啟任何動態容量的電源。$
pcluster update-compute-fleet --cluster-name
testSlurm
\ --regioneu-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
我們建議您使用 命令將動態節點設定為
DOWN
作為su
根使用者:$
scontrol update nodename=
nodename
state=down reason="manually draining"AWS ParallelCluster 會自動終止和重設下降的動態節點。
一般而言,我們不建議您
POWER_DOWN
直接使用scontrol update nodename=
命令將節點設定為 。這是因為 AWS ParallelCluster 會自動處理關機程序。nodename
state=power_down -
停用佇列 (分割區) 或停止特定分割區中的所有靜態節點
使用 命令將特定佇列設定為
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 分鐘,然後重設節點。 -
執行個體已設定並加入叢集。任務開始在執行個體上執行。
-
任務完成並停止執行。
-
在設定的 經過 (設定為 ScaledownIdletime)
SuspendTime
之後,排程器會將執行個體設定為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,請查看
SuspendProgram
日誌中的slurmctld
處理程序是否使用特定節點做為引數進行呼叫。請注意, 實際上SuspendProgram
不會執行任何特定動作。相反地,它只會在呼叫時記錄。所有執行個體終止和NodeAddr
重設都由 完成clustermgtd
。 會在IDLE
之後將節點Slurm轉換為SuspendTimeout
。
其他問題:
-
AWS ParallelCluster 不會進行任務配置或擴展決策。它只會嘗試根據 Slurm的指示啟動、終止和維護資源。
如需任務配置、節點配置和擴展決策的問題,請查看
slurmctld
日誌是否有錯誤。