動態節點的叢集擴展 - AWS ParallelCluster

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

動態節點的叢集擴展

ParallelCluster 支持通過使用Slurm的省電插件動態擴展集群Slurm的方法。如需詳細資訊，請參閱Slurm文件中的雲端排程指南和省Slurm電指南。

從 3.8.0 ParallelCluster 版開始， ParallelCluster 使用 Job 層級履歷或工作層級調整作為預設動態節點配置策略來擴展叢集： ParallelCluster 根據每個作業的需求、配置給作業的節點數目以及需要恢復的節點來擴展叢集。 ParallelCluster 從「文件」環境變量中獲取此信息。

動態節點的擴展是兩個步驟的程序，包括啟動 EC2 執行個體以及將已啟動的 EC2 執行個體指派給 Slurm 節點。這兩個步驟中的每一個都可以使用all-or-nothing或盡力邏輯來完成。

若要啟動 EC2 執行個體：

  • all-or-nothing呼叫啟動 EC2 API 的最小目標等於總目標容量

  • 盡最大努力呼叫啟動 EC2 API，最小目標等於 1，且目標容量總計等於請求的容量

若要將 EC2 執行個體指派給 Slurm 節點：

  • all-or-nothing只有在可以將 EC2 實例分配給每個請求的節點時，才將 EC2 實例分配給 Slurm 節點

  • 盡最大努力將 EC2 執行個體指派給 Slurm 節點，即使 EC2 執行個體容量未涵蓋所有請求的節點

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

The available ParallelCluster 啟動策略 that can be set into the ScalingStrategy cluster configuration to be used with 工作層級縮放 are:

all-or-nothing縮放：

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

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

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

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

限制

  • 縮放所花費的時間與每次執行 Slurm 恢復程式所提交的作業數量成正比。

  • 擴展操作受 RunInstances 資源帳號限制的限制，依預設設定為 1000 個執行個體。此限制符合 AWS EC2 API 節流政策，如需詳細資訊，請參閱 AWS EC2 API 節流文件

  • 當您在跨多個可用區域的佇列中，在具有單一執行個體類型的運算資源中提交任務時，只有在單一可用區域中提供所有容量時，all-or-nothingEC2 啟動 API 呼叫才會成功。

  • 當您在具有單一可用區域的佇列中，在具有多個執行個體類型的運算資源中提交任務時，只有在單一執行個體類型可提供所有容量時，all-or-nothingEC2 啟動 API 呼叫才會成功。

  • 當您在具有多個執行個體類型的運算資源中提交任務時，在跨多個可用區域的佇列中，不支援 all-or-nothingEC2 啟動 API 呼叫，而是以最佳方式 ParallelCluster 進行擴展。

greedy-all-or-nothing縮放：

該 all-or-nothing 策略的這種變體仍可確保叢集只有在每個任務所需的容量可用時才擴展，避免在擴展程序結束時發生閒置執行個體，但是它涉及 ParallelCluster 啟動旨在最小目標容量為 1 的 Amazon EC2 啟動執行個體 API 呼叫，嘗試將啟動到所請求容量的節點數量最大化。該策略使用盡最大努力邏輯來啟動所有任務的 EC2 執行個體，加上將 EC2 執行個體指派給每個任務的 Slurm 節點的all-or-nothing邏輯。

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

它可確保在擴展程序結束時不會留下任何閒置的執行個體，方法是在擴展程序期間最大化輸送量，而代價是暫時過度擴充的代價。

限制

  • 暫時過度擴展是可能的，導致執行個體在擴展完成之前轉換為執行中狀態的額外成本。

  • 與 all-or-nothing 策略中 AWS的執行個體限制相同，需視乎 RunInstances 資源帳號限制而定。

盡最大努力擴展：

此策略以最小容量為 1 的目標來呼叫 EC2 啟動執行個體 API 呼叫，如果並非所有請求的容量都可用，則以在擴展程序執行後離開閒置執行個體的代價來達到請求的總容量。該策略使用盡最大努力的邏輯來啟動所有任務的 EC2 執行個體，加上將 Amazon EC2 執行個體指派給每個任務的 Slurm 節點的最大努力邏輯。

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

此策略允許在多個擴展程序執行上擴展到遠遠超過預設 1000 個執行個體限制，代價是在不同的擴展流程中使用閒置執行個體。

限制

  • 在擴展程序結束時，可能會有閒置執行個體，適用於無法配置作業要求的所有節點的情況。

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

all-or-nothing縮放：

  • 對於第一項任務，會呼叫 all-or-nothingEC2 啟動執行個體 API，請求 20 個執行個體。成功的呼叫會導致啟動 20 個執行個體

  • all-or-nothing 將 20 個啟動的執行個體指派給第一個工作的 Slurm 節點成功

  • 另一個 all-or-nothingEC2 啟動實例 API 被調用，請求 20 個實例進行第二個任務。呼叫不成功，因為只有另外 10 個執行個體的容量。目前沒有啟動任何執行個體

greedy-all-or-nothing縮放：

  • 最大努力的 EC2 啟動實例 API 被稱為，請求 40 個實例，這是所有任務請求的總容量。這導致啟動了 30 個實例

  • 將 20 個已啟動的執行個體all-or-nothing指派給第一個工作的 Slurm 節點成功

  • 嘗試將剩餘啟動的執行個體all-or-nothing指派給第二個工作的 Slurm 節點，但由於工作要求的總數 20 個中只有 10 個可用的執行個體，因此指派不成功

  • 終止 10 個未指派啟動的執行個體

盡最大努力擴展：

  • 最大努力的 EC2 啟動實例 API 被稱為，請求 40 個實例，這是所有任務請求的總容量。這會導致啟動 30 個執行個體。

  • 在第一個工作中，將 20 個已啟動執行個體的最大努力指派給 Slurm 節點是成功的。

  • 即使要求的總容量為 20，將剩餘 10 個啟動的執行個體指派給第二個工作的 Slurm 節點，也會成功完成另一個作業。但是由於工作要求 20 個節點，並且可以僅將 EC2 執行個體指派給其中 10 個節點，因此任務無法啟動且執行個體處於閒置狀態，直到找到足夠的容量以在稍後的擴展程序呼叫時啟動遺失的 10 個執行個體，否則排程器會在其他已經執行的運算節點上排程工作。

ParallelCluster 使用 2 種類型的動態節點分配策略來擴展叢集：

  • 根據可用的請求節點資訊配置：

    • 所有節點恢復或節點列表縮放：

      ParallelCluster ResumeProgram運行時Slurm僅根據請求Slurm的節點列表名稱擴展集群。它僅通過節點名稱將計算資源分配給節點。節點名稱清單可以跨越多個工作。

    • 工作層級履歷或工作層級調整：

      ParallelCluster 根據每個工作的需求、目前配置給作業的節點數目，以及需要恢復哪些節點來擴展叢集。 ParallelCluster 從SLURM_RESUME_FILE環境變數取得此資訊。

  • 使用 EC2 啟動策略分配：

    • 最大努力擴展：

      ParallelCluster 使用最小目標容量等於 1 的 EC2 啟動執行個體 API 呼叫來擴展叢集，以啟動部分但不一定是支援所請求節點所需的所有執行個體。

    • 一個ll-or-nothing縮放比例：

      ParallelCluster 使用 EC2 啟動執行個體 API 呼叫擴展叢集，該呼叫只有在支援所請求節點所需的所有執行個體都啟動時才會成功。在這種情況下，它會呼叫 EC2 啟動執行個體 API，其最小目標容量等於要求的總容量。

默認情況下， ParallelCluster 使用節點列表擴展以及盡最大努力的 EC2 啟動策略來啟動一些但不一定是支持請求節點所需的所有實例。它會嘗試佈建盡可能多的容量，以滿足提交的工作負載。

從 ParallelCluster 版本 3.7.0 開始，針對以獨佔模式提交的任務， ParallelCluster 使用 all-or-nothingEC2 啟動策略的工作層級擴展。當您以獨佔模式提交工作時，該工作具有其配置節點的獨佔存取權。如需詳細資訊，請參閱Slurm文件中的 EXCLUSIVE。

若要以獨佔模式提交工作：

  • 將Slurm工作送出至叢集時，傳送獨佔旗標。例如 sbatch ... --exclusive。

    或

  • 將工作提交至已JobExclusiveAllocation設定為的叢集佇列true。

以獨佔模式提交工作時：

  • ParallelCluster 目前批次會啟動要求，以包含最多 500 個節點。如果工作要求超過 500 個節點， ParallelCluster 則會針對每組 500 個節點提all-or-nothing出啟動要求，並針對其餘節點提出額外的啟動要求。

  • 如果節點配置位於單一計算資源中， ParallelCluster 則會針對每組 500 個節點提all-or-nothing出啟動請求，並針對其餘節點提出額外的啟動請求。如果啟動要求失敗， ParallelCluster 會終止所有啟動要求所建立的未使用容量。

  • 如果節點配置跨越多個計算資源，則 ParallelCluster 需要針對每個計算資源提all-or-nothing出啟動請求。這些請求也會批次處理。如果其中一個計算資源的啟動要求失敗，則 ParallelCluster 會終止所有計算資源啟動要求所建立的未使用容量。

具有已知限制的all-or-nothing啟動策略的工作層級擴展：

  • 當您在跨多個可用區域的佇列中，在具有單一執行個體類型的運算資源中提交任務時，只有在單一可用區域中提供所有容量時，all-or-nothingEC2 啟動 API 呼叫才會成功。

  • 當您在具有單一可用區域的佇列中，在具有多個執行個體類型的運算資源中提交任務時，只有在單一執行個體類型可提供所有容量時，all-or-nothingEC2 啟動 API 呼叫才會成功。

  • 當您在具有多個執行個體類型的運算資源中提交任務時，在跨多個可用區域的佇列中，不支援 all-or-nothingEC2 啟動 API 呼叫，而是以最佳方式 ParallelCluster進行擴展。

AWS ParallelCluster 僅使用一種類型的動態節點配置策略來擴展叢集：

  • 根據可用的請求節點資訊配置：

    • 所有節點恢復或節點列表擴展： ParallelCluster 僅在Slurm運行時Slurm根據請求的節點列表名稱擴展叢集。ResumeProgram它僅通過節點名稱將計算資源分配給節點。節點名稱清單可以跨越多個工作。

  • 使用 EC2 啟動策略分配：

    • 盡力擴展： ParallelCluster 透過使用最小目標容量等於 1 的 EC2 啟動執行個體 API 呼叫來擴展叢集，以啟動支援所請求節點所需的部分但不一定是所有執行個體。

ParallelCluster 使用節點列表擴展以及盡力的 EC2 啟動策略來啟動一些但不一定是支持請求節點所需的所有實例。它會嘗試佈建盡可能多的容量，以滿足提交的工作負載。

限制

  • 在擴展程序結束時，可能會有閒置執行個體，適用於無法配置作業要求的所有節點的情況。