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

# Slurm 3.8.0 版中的動態節點配置策略
<a name="scheduler-node-allocation-v3-3.8.0"></a>

從 ParallelCluster 3.8.0 版開始，ParallelCluster 使用**任務層級恢復**或**任務層級擴展**作為預設動態節點分配策略來擴展叢集：ParallelCluster 會根據每個任務的需求、分配給任務的節點數量，以及需要恢復哪些節點來擴展叢集。ParallelCluster 會從 SLURM\_RESUME\_FILE 環境變數取得此資訊。

動態節點的擴展是一個兩步驟程序，涉及啟動 EC2 執行個體，以及將啟動的 Amazon EC2 執行個體指派給Slurm節點。這兩個步驟都可以使用**all-or-nothing**或**最佳嘗試**邏輯來完成。

若要啟動 Amazon EC2 執行個體：
+ **all-or-nothing**啟動 Amazon EC2 API，目標下限等於總目標容量
+ **盡最大努力**呼叫最低目標等於 1 且總目標容量等於請求容量的啟動 Amazon EC2 API

若要將 Amazon EC2 執行個體指派給Slurm節點：
+ 只有在可以為每個請求的Slurm節點指派 Amazon EC2 執行個體時，**all-or-nothing**Amazon EC2 執行個體指派給節點
+ **盡最大努力**將 Amazon EC2 執行個體指派給Slurm節點，即使 Amazon EC2 執行個體容量未涵蓋所有請求的節點

  上述策略的可能組合會轉換為 ParallelCluster 啟動策略。

**Example**  [ ScalingStrategy](Scheduling-v3.md#yaml-Scheduling-ScalingStrategy)

**all-or-nothing**擴展：

此策略涉及為每個任務 AWS ParallelCluster 啟動 Amazon EC2 啟動執行個體 API 呼叫，這需要請求的運算節點成功啟動所需的所有執行個體。這可確保叢集僅在每個任務所需的容量可用時擴展，避免在擴展程序結束時留下閒置的執行個體。

策略使用**all-or-nothing**邏輯來啟動每個任務的 Amazon EC2 執行個體，以及將 Amazon EC2 執行個體指派給Slurm節點的**all-or-nothing**邏輯。

策略群組會分批啟動請求，每個請求的運算資源各一個，每個節點最多 500 個。對於跨越多個運算資源或超過 500 個節點的請求，ParallelCluster 會依序處理多個批次。

任何單一資源批次的失敗都會導致所有相關未使用容量的終止，確保擴展程序結束時不會留下閒置的執行個體。

限制
+ 擴展所需的時間與每次執行Slurm繼續程式時提交的任務數量直接成正比。
+ 擴展操作受限於 RunInstances 資源帳戶限制，預設為 1000 個執行個體。此限制符合 AWS EC2 API 限流政策，如需詳細資訊，請參閱 [Amazon EC2 API 限流文件](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html) 
+ 當您在具有單一執行個體類型的運算資源中提交任務時，在跨越多個可用區域的佇列中，只有在單一可用區域中可以提供所有容量時，**all-or-nothing** EC2 啟動 API 呼叫才會成功。
+ 當您在具有多個執行個體類型的運算資源中提交任務時，在具有單一可用區域的佇列中，只有在所有容量都可以由單一執行個體類型提供時，**all-or-nothing** Amazon EC2 啟動 API 呼叫才會成功。
+ 當您在具有多個執行個體類型的運算資源中提交任務時，在跨越多個可用區域的佇列中，不支援**all-or-nothing**Amazon EC2 啟動 API 呼叫，而 ParallelCluster 會改為執行**最佳嘗試**擴展。

**greedy-all-or-nothing** 擴展：

此all-or-nothing策略變體仍可確保叢集僅在每個任務所需的容量可用時擴展，避免擴展程序結束時的閒置執行個體，但涉及 ParallelCluster 啟動 Amazon EC2 啟動執行個體 API 呼叫，其目標容量下限為 1，嘗試將啟動的節點數量最大化至請求的容量。此策略使用最佳努力邏輯來啟動所有任務的 EC2 執行個體，以及將 Amazon EC2 執行個體指派給每個任務Slurm節點**all-or-nothing**邏輯。

策略群組會分批啟動請求，每個請求的運算資源各一個，每個節點最多 500 個。對於跨越多個運算資源或超過 500 個節點的請求，ParellelCluster 會依序處理多個批次。

它可確保擴展程序結束時不會留下閒置的執行個體，方法是在擴展程序期間以暫時過度擴展的成本將輸送量最大化。

限制
+ 暫時過度擴展是可能的，導致在擴展完成之前轉換為執行中狀態的執行個體產生額外的成本。
+ 根據 AWS RunInstances 資源帳戶限制，適用all-or-nothing策略相同的執行個體限制。

**最佳嘗試**擴展：

此策略會以 1 的最小容量為目標來呼叫 Amazon EC2 啟動執行個體 API 呼叫，如果並非所有請求的容量都可用，則以擴展程序執行後離開閒置執行個體的成本達到請求的總容量。此策略使用最佳努力邏輯來啟動所有任務的 Amazon EC2 執行個體，以及為每個任務指派 Amazon EC2 執行個體至 Slurm 節點**的最佳努力**邏輯。

策略群組會分批啟動請求，每個請求的運算資源各一個，每個節點最多 500 個。對於跨越多個運算資源或超過 500 個節點的請求，ParallelCluster 會依序處理多個批次。

此策略允許擴展遠超過多個擴展程序執行的預設 1000 個執行個體限制，而成本是在不同擴展程序中擁有閒置執行個體。

限制
+ 擴展程序結束時可能的閒置執行中執行個體，適用於無法配置任務請求的所有節點的情況。

以下範例顯示動態節點的擴展如何使用不同的 **ParallelCluster 啟動策略**。假設您已提交兩個任務，每個請求 20 個節點，總共 40 個相同類型的節點，但只有 30 個 Amazon EC2 執行個體可用於涵蓋 EC2 上請求的容量。

**all-or-nothing**擴展：
+ 對於第一個任務，呼叫**all-or-nothing**Amazon EC2 啟動執行個體 API，請求 20 個執行個體。成功的呼叫會導致啟動 20 個執行個體
+ 成功將 20 **all-or-nothing**啟動的執行個體指派給第一個任務的Slurm節點
+ 呼叫另一個**all-or-nothing** Amazon EC2 啟動執行個體 API，為第二個任務請求 20 個執行個體。呼叫不成功，因為只有其他 10 個執行個體的容量。目前未啟動任何執行個體

**greedy-all-or-nothing** 擴展：
+ 呼叫**盡最大努力**的 Amazon EC2 啟動執行個體 API，請求 40 個執行個體，這是所有任務請求的總容量。這會導致啟動 30 個執行個體
+ 成功指派 20 **all-or-nothing**啟動的執行個體至第一個任務的Slurm節點
+ 嘗試將其餘啟動的執行個體指派給第二個任務Slurm節點的另一個**all-or-nothing**指派，但由於任務請求總數 20 中只有 10 個可用執行個體，因此指派不成功
+ 10 個未指派的啟動執行個體已終止

**最佳嘗試**擴展：
+ 呼叫**盡最大努力的** Amazon EC2 啟動執行個體 API，請求 40 個執行個體，這是所有任務請求的總容量。這會導致啟動 30 個執行個體。
+ **成功**將 20 個啟動的執行個體指派到第一個任務的Slurm節點。
+ 即使請求的總容量為 20，其餘 10 個啟動的執行個體也會成功****指派給第二個任務的Slurm節點。但是，由於任務正在請求 20 個節點，並且可以將 Amazon EC2 執行個體指派給其中只有 10 個節點，因此任務無法啟動，且執行個體會保持閒置狀態，直到找到足夠的容量在稍後呼叫擴展程序時啟動缺少的 10 個執行個體，或排程器在其他已執行的運算節點上排程任務為止。