本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 支援的排程器 AWS ParallelCluster
AWS ParallelCluster 支援 Slurm和 AWS Batch 排程器，這些排程器使用 [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler)設定。下列主題將說明每個排程器及其使用方式。
**Topics**
+ [Slurm Workload Manager (`slurm`)](slurm-workload-manager-v3.md)
+ [搭配 使用 AWS Batch (`awsbatch`) 排程器 AWS ParallelCluster](awsbatchcli-v3.md)
# Slurm Workload Manager (`slurm`)
## 叢集容量大小和更新
叢集的容量是由叢集可以擴展的運算節點數量所定義。運算節點由 AWS ParallelCluster 組態 中運算資源內定義的 Amazon EC2 執行個體提供支援`(Scheduling/SlurmQueues/`ComputeResources`)`，並組織成`(Scheduling/SlurmQueues)`對應 1：1 到Slurm分割區的佇列。
在運算資源中，您可以設定必須在叢集 () 中持續執行的運算節點 （執行個體） 數目下限，以及運算資源可擴展至 ([`MaxCount`3](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)`MinCount`) 的執行個體數目上限。
在叢集建立時間或叢集更新時， `MinCount`會針對叢集中定義的每個運算資源 (`Scheduling/SlurmQueues/ ComputeResources`)，依在 中設定的數目 AWS ParallelCluster 啟動 Amazon EC2 執行個體。啟動以涵蓋叢集中運算資源最小數量節點的執行個體稱為***靜態節點**。*啟動後，除非發生特定事件或條件，否則靜態節點應持續存在於叢集中，系統不會終止這些節點。例如，這類事件包括 Slurm或 Amazon EC2 運作狀態檢查失敗，以及Slurm節點狀態變更為 DRAIN 或 DOWN。
在 `1`到 `‘MaxCount - MinCount’`(`MaxCount ` *減去*` MinCount)` ，隨需啟動以處理叢集負載增加的 Amazon EC2 執行個體，稱為***動態節點***。 它們的性質是暫時性的，它們會啟動以提供待定任務，並在它們在叢集組態`Scheduling/SlurmSettings/ScaledownIdletime`中 定義的一段時間內保持閒置後終止 （預設值：10 分鐘）。
靜態節點和動態節點符合下列命名結構描述：
+ 靜態節點`-st--`，其中 ` = 1..ComputeResource/MinCount`
+ 動態節點，`-dy--`其中 ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
例如，假設有下列 AWS ParallelCluster 組態：
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
下列節點將在 中定義 Slurm
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
當運算資源具有 時`MinCount == MaxCount`，所有對應的運算節點都會是靜態的，而且所有執行個體都會在叢集建立/更新時間啟動，並保持啟動和執行。例如：
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## 叢集容量更新
叢集容量的更新包括新增或移除佇列、運算資源或變更運算資源`MinCount/MaxCount`的 。從 3.9.0 AWS ParallelCluster 版開始，減少佇列的大小需要停止運算機群，或將 的 [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy) 設定為 TERMINATE，才能進行叢集更新。在下列情況下，不需要停止運算機群或將 [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy) 設定為 TERMINATE：
+ 將新佇列新增至排程/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
+ 將新的運算資源`Scheduling/SlurmQueues/ComputeResources`新增至佇列
+ 增加運算資源`MaxCount`的
+ 增加運算資源的 MinCount，並增加相同運算資源至少相同數量的 MaxCount
## 考量和限制
本節旨在概述調整叢集容量時應考慮的任何重要因素、限制或限制。
+ 從名稱為 `Scheduling/SlurmQueues`的所有運算節點移除佇列時`-*`，靜態和動態都會從Slurm組態中移除，且對應的 Amazon EC2 執行個體將會終止。
+ `Scheduling/SlurmQueues/ComputeResources` 從佇列移除運算資源時，所有名稱為 的運算節點都會從Slurm組態中移除`-*--*`，且對應的 Amazon EC2 執行個體也會終止。
變更運算資源的 `MinCount` 參數時，我們可以區分兩種不同的案例：如果 `MaxCount` 保持等於 `MinCount`（僅限靜態容量），以及如果 `MaxCount` 大於 `MinCount`（混合靜態和動態容量）。
### 僅限靜態節點的容量變更
+ 如果 `MinCount == MaxCount` ，增加 `MinCount`（和 ) `MaxCount` 時，叢集的設定方式是將靜態節點數量擴展到 的新值，`MinCount``-st--`而且系統會繼續嘗試啟動 Amazon EC2 執行個體，以滿足新的必要靜態容量。
+ 如果 `MinCount == MaxCount` ，則在減少 `MinCount`（和 `MaxCount` ) 數量 N 時，將透過移除最後一個 N 個靜態節點來設定叢集，`-st--...]`且系統會終止對應的 Amazon EC2 執行個體。
+ 初始狀態 `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 在 `MinCount`和 `-30`上更新 `MaxCount: MinCount = MaxCount = 70`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### 混合節點的容量變更
如果 `MinCount < MaxCount`，增加`MinCount`數量 N 時 （假設 `MaxCount`將保持不變），叢集的設定方式是將靜態節點數目擴展到 `MinCount`() `old_MinCount + N` 的新值： `-st--` 且系統會繼續嘗試啟動 Amazon EC2 執行個體，以滿足新的必要靜態容量。此外，為了滿足運算資源的`MaxCount`容量，叢集組態會透過*移除最後一個 N 個動態節點*來更新： `-dy--[...]`且系統會終止對應的 Amazon EC2 執行個體。
+ 初始狀態： `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 將 \$130 更新為 `MinCount : MinCount = 130 (MaxCount = 150)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
如果 `MinCount < MaxCount`，在增加 `MinCount`且數量`MaxCount`相同 N 時，叢集的設定方式是將靜態節點數量擴展到 `MinCount`() `old_MinCount + N` 的新值： ，`-st--`而且系統會繼續嘗試啟動 Amazon EC2 執行個體，以滿足新的必要靜態容量。此外，不會對動態節點數量進行任何變更，以遵守新的
`MaxCount` 值。
+ 初始狀態： `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 將 \$130 更新為 `MinCount : MinCount = 130 (MaxCount = 180)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
如果 `MinCount < MaxCount`，則在減少`MinCount`數量 N 時 （假設 `MaxCount`將保持不變），則會透過移除最後一個 N 個靜態節點靜態節點來設定叢集，`-st--[...`且系統會終止對應的 Amazon EC2 執行個體。此外，為了遵守運算資源的`MaxCount`容量，透過擴展動態節點的數量來填補間隙來更新叢集組態`MaxCount - new_MinCount: -dy--[1..]`。在此情況下，由於這些是動態節點，除非排程器在新節點上有待定任務，否則不會啟動新的 Amazon EC2 執行個體。
+ 初始狀態： `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 在 上更新 -30 `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
如果 `MinCount < MaxCount`，則在減少 `MinCount`和相同數量`MaxCount`的 N 時，將透過移除最後一個 N 個靜態節點來設定叢集，`-st--...]`且系統會終止對應的 Amazon EC2 執行個體。
此外，不會對動態節點數量進行任何變更，以遵守新`MaxCount`值。
+ 初始狀態： `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 在 上更新 -30 `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
如果 `MinCount < MaxCount`，則在減少`MaxCount`數量 N 時 （假設 `MinCount`將保持不變），叢集將透過移除最後一個 N 個動態節點進行設定，`-dy--]`如果靜態節點受到 running.No 影響，系統會終止對應的 Amazon EC2 執行個體。
+ 初始狀態： `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 在 上更新 -30 `MaxCount : MinCount = 100 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## 對任務的影響
在移除節點並終止 Amazon EC2 執行個體的所有情況下，除非沒有其他節點滿足任務需求，否則在移除的節點上執行的 sbatch 任務會重新排入佇列。在此情況下，任務會失敗，狀態為 NODE\$1FAIL，並從佇列中消失，且必須手動重新提交。
如果您打算執行叢集調整大小更新，您可以防止任務在計劃更新期間將移除的節點中執行。這可以透過設定要在維護中移除的節點來實現。請注意，在維護中設定節點不會影響最終已在節點中執行的任務。
假設透過計劃的叢集調整大小更新，您將移除節點 `qeueu-st-computeresource-[9-10`】。您可以使用下列命令建立Slurm保留
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
這將在節點 `maint_for_update` 上建立名為 的Slurm保留`qeueu-st-computeresource-[9-10]`。從建立保留開始，就無法再將任何任務執行到節點 `qeueu-st-computeresource-[9-10]`。請注意，保留不會阻止任務最終配置到節點 `qeueu-st-computeresource-[9-10]`。
叢集調整大小更新後，如果僅在調整大小更新期間移除的節點上設定Slurm保留，系統會自動刪除維護保留。如果您改為在叢集調整大小更新後仍存在的節點上建立Slurm保留，我們可能會想要在執行調整大小更新後移除節點上的維護保留，方法是使用下列命令
```
sudo -i scontrol delete ReservationName=maint_for_update
```
如需Slurm保留的其他詳細資訊，請參閱[此處](https://slurm.schedmd.com/reservations.html)的官方 SchedMD 文件。
## 容量變更的叢集更新程序
在排程器組態變更時，會在叢集更新程序期間執行下列步驟：
+ 停止 AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ 從 AWS ParallelCluster 組態產生更新的Slurm分割區組態
+ 重新啟動 `slurmctld`（透過 Chef 服務配方完成）
+ 檢查`slurmctld`狀態 `(systemctl is-active --quiet slurmctld.service)`
+ 重新載入Slurm組態 `(scontrol reconfigure)`
+ 啟動 `clustermgtd (supervisorctl start clustermgtd)`
如需 的詳細資訊Slurm，請參閱 https：//[https://slurm.schedmd.com](https://slurm.schedmd.com)。如需下載，請參閱 https：//[https://github.com/SchedMD/slurm/tags](https://github.com/SchedMD/slurm/tags)。如需來源碼，請參閱 https：//[https://github.com/SchedMD/slurm](https://github.com/SchedMD/slurm)。
## 支援的叢集和 SLURM 版本
下表列出 AWS 支援的 AWS ParallelCluster 和 Slurm版本。
| AWS ParallelCluster version(s) | 支援的 Slurm 版本 |
| --- | --- |
| 3.13.0 | 24.05.07 |
| 3.12.0 | 23.11.10 |
| 3.11.0 | 23.11.10 |
| 3.9.2、3.9.3、3.10.0 | 23.11.7 |
| 3.9.0、3.9.1 | 23.11.4 |
| 3.8.0 | 23.02.7 |
| 3.7.2 | 23.02.6 |
| 3.7.1 | 23.02.5 |
| 3.7.0 | 23.02.4 |
| 3.6.0、3.6.1 | 23.02.2 |
| 3.5.0、3.5.1 | 22.05.8 |
| 3.4.0、3.4.1 | 22.05.7 |
| 3.3.0、3.3.1 | 22.05.5 |
| 3.1.4、3.1.5、3.2.0、3.2.1 | 21.08.8-2 |
| 3.1.2、3.1.3 | 21.08.6 |
| 3.1.1 | 21.08.5 |
| 3.0.0 | 20.11.8 |
**Topics**
+ [叢集容量大小和更新](#cluster-capacity-size-and-update)
+ [叢集容量更新](#cluster-capacity-update)
+ [考量和限制](#considerations-limitations)
+ [對任務的影響](#impacts-on-jobs)
+ [容量變更的叢集更新程序](#cluster-update-process)
+ [支援的叢集和 SLURM 版本](#cluster-slurm-version-table)
+ [多個佇列的組態](configuration-of-multiple-queues-v3.md)
+ [Slurm 適用於多個佇列模式的 指南](multiple-queue-mode-slurm-user-guide-v3.md)
+ [Slurm 叢集保護模式](slurm-protected-mode-v3.md)
+ [Slurm 叢集快速容量不足容錯移轉](slurm-short-capacity-fail-mode-v3.md)
+ [Slurm 記憶體型排程](slurm-mem-based-scheduling-v3.md)
+ [使用 Slurm 進行多個執行個體類型配置](slurm-multiple-instance-allocation-v3.md)
+ [動態節點的叢集擴展](scheduler-node-allocation-v3.md)
+ [Slurm 使用 會計 AWS ParallelCluster](slurm-accounting-v3.md)
+ [Slurm 組態自訂](slurm-configuration-settings-v3.md)
+ [Slurm 與 `prolog``epilog`](slurm-prolog-epilog-v3.md)
+ [叢集容量大小和更新](slurm-cluster-capacity-size-and-update.md)
# 多個佇列的組態
使用第 3 AWS ParallelCluster 版，您可以將 [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler) 設定為 ，`slurm`並在組態檔案中為 指定多個佇列[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)，以設定多個佇列。在此模式中，組態檔案 [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)區段中指定的運算節點中共存不同的執行個體類型。[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)具有不同執行個體類型的 會視需要擴展或縮減[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)。
當工作負載共用相同的基礎基礎設施和資源 （例如共用儲存、聯網或登入節點） 時，單一叢集內的多個*佇列*通常優於多個叢集。如果工作負載有類似的運算、儲存和聯網需求，在單一叢集中使用多個佇列會更有效率，因為它允許資源共用並避免不必要的重複。這種方法簡化了管理並降低了額外負荷，同時仍然允許有效率的任務排程和資源配置。另一方面，當工作負載之間有強大的安全性、資料或操作隔離需求時，應使用多個*叢集*。例如，如果您需要獨立管理和操作工作負載，使用不同的排程、更新週期或存取政策，則多個叢集更為合適。
**叢集佇列和運算資源配額**
| 資源 | 配額 |
| --- | --- |
| [`Slurm queues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) | 每個叢集 50 個佇列 |
| [`Compute resources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) | 每個佇列 50 個運算資源 每個叢集 50 個運算資源 |
**節點計數**
佇列[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)中每個運算資源都必須具有唯一的 [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name)、[`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)、 [`InstanceType`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-InstanceType)和 [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)。 [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)具有預設值，可定義[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)佇列中運算資源的執行個體範圍。您也可以為 [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)和 指定自己的值[`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)。中的每個運算資源[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)是由編號為 1 到 的靜態節點，[`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)以及編號為 [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)到 值的動態節點所組成[`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)。
**範例組態**
以下是叢集組態檔案[的排程](Scheduling-v3.md)區段範例。在此組態中，有兩個名為 `queue1`和 的佇列，`queue2`每個佇列[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)都有指定的 [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)。
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
- InstanceType: c4.xlarge
MaxCount: 5
Name: c4xlarge
- Name: queue2
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
```
**主機名稱**
在運算機群中啟動的執行個體會動態指派。系統會為每個節點產生主機名稱。根據預設， AWS ParallelCluster 會使用下列格式的主機名稱 ：
`$HOSTNAME=$QUEUE-$STATDYN-$COMPUTE_RESOURCE-$NODENUM`
+ `$QUEUE` 是佇列的名稱。例如，如果 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)區段的項目[`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Name)設定為「`queue-name`」，則「`$QUEUE`」為「`queue-name`」。
+ `$STATDYN` `st`適用於靜態節點，或`dy`適用於動態節點。
+ `$COMPUTE_RESOURCE` 是與此節點對應的[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)運算資源[`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name)的 。
+ `$NODENUM` 是節點的數目。[`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)靜態節點的 值`$NODENUM`介於一 (1) 和 之間，動態節點的 值介於一 (1) 和 [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)-[`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) 之間。
從上述範例組態檔案中，來自 `queue1`和 運算資源的指定節點`c5xlarge`具有主機名稱：`queue1-dy-c5xlarge-1`。
主機名稱和完整網域名稱 (FQDN) 都是使用 Amazon Route 53 託管區域建立。FQDN 是 `$HOSTNAME.$CLUSTERNAME.pcluster`，其中 `$CLUSTERNAME`是叢集的名稱。
請注意，相同的格式也會用於Slurm節點名稱。
使用者可以選擇使用支援運算節點之執行個體的預設 Amazon EC2 主機名稱，而非 使用的預設主機名稱格式 AWS ParallelCluster。這可以透過將 [`UseEc2Hostnames`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames) 參數設定為 true 來完成。不過，Slurm節點名稱將繼續使用預設 AWS ParallelCluster 格式。
# 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`日誌是否有錯誤。
# Slurm 叢集保護模式
當叢集在啟用受保護模式的情況下執行時， AWS ParallelCluster 監控並追蹤運算節點啟動時的運算節點引導失敗。它這樣做是為了偵測這些失敗是否持續發生。
如果在佇列 （分割區） 中偵測到下列項目，則叢集會進入受保護狀態：
1. 連續運算節點引導失敗會持續發生，而不會成功啟動運算節點。
1. 失敗計數達到預先定義的閾值。
叢集進入受保護狀態後， 會 AWS ParallelCluster 停用故障等於或高於預先定義閾值的佇列。
Slurm 3.0.0 AWS ParallelCluster 版中已新增 叢集保護模式。
您可以使用受保護模式來減少運算節點引導失敗循環所花費的時間和資源。
## 受保護模式參數
**`protected_failure_count`**
`protected_failure_count` 指定在佇列 （分割區） 中啟用叢集保護狀態的連續失敗次數。
預設值`protected_failure_count`為 10，且已啟用受保護模式。
如果 `protected_failure_count` 大於零，則會啟用受保護模式。
如果 `protected_failure_count` 小於或等於零，則會停用受保護模式。
您可以在位於 的`clustermgtd`組態檔案中新增 參數來變更`protected_failure_count`值`/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf``HeadNode`。
您可以隨時更新此參數，而且您不需要停止運算機群即可執行此操作。如果啟動在失敗計數達到 之前在佇列中成功`protected_failure_count`，則失敗計數會重設為零。
## 檢查處於受保護狀態的叢集狀態
當叢集處於受保護狀態時，您可以檢查運算機群狀態和節點狀態。
### 運算機群狀態
運算機群的狀態位於處於受保護狀態的叢集`PROTECTED`中。
```
$ pcluster describe-compute-fleet --cluster-name --region
{
"status": "PROTECTED",
"lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z"
}
```
### 節點狀態
若要了解哪些佇列 （分割區） 的引導失敗已啟用受保護狀態，請登入叢集並執行 `sinfo`命令。開機失敗等於或高於 的分割區`protected_failure_count`處於 `INACTIVE` 狀態。在 或 以上沒有引導失敗的分割區`protected_failure_count`處於 `UP` 狀態並如預期運作。
`PROTECTED` 狀態不會影響執行中的任務。如果任務在開機失敗位於 或高於 的分割區上執行`protected_failure_count`，則在執行中的任務完成後`INACTIVE`，該分割區會設定為 。
請考慮下列範例中顯示的節點狀態。
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* inact infinite 10 down% queue1-dy-c5xlarge-[1-10]
queue1* inact infinite 3490 idle~ queue1-dy-c5xlarge-[11-3500]
queue2 up infinite 10 idle~ queue2-dy-c5xlarge-[1-10]
```
分割區`queue1`是`INACTIVE`由於偵測到連續 10 個運算節點引導失敗。
節點後方的執行個體`queue1-dy-c5xlarge-[1-10]`已啟動，但由於運作狀態不佳而無法加入叢集。
叢集處於受保護狀態。
分割區`queue2`不會受到 中引導失敗的影響`queue1`。它處於 `UP` 狀態，仍然可以執行任務。
## 如何停用受保護狀態
解決引導錯誤之後，您可以執行下列命令，將叢集移出受保護的狀態。
```
$ pcluster update-compute-fleet --cluster-name \
--region \
--status START_REQUESTED
```
## 啟動受保護狀態的引導失敗
啟用受保護狀態的引導錯誤會細分為以下三種類型。若要識別類型和問題，您可以檢查 AWS ParallelCluster 產生的日誌。如果日誌已產生，您可以檢查日誌是否有錯誤詳細資訊。如需詳細資訊，請參閱[擷取和保留日誌](troubleshooting-v3-get-logs.md)。
1. **引導錯誤，導致執行個體自行終止**。
執行個體在引導程序初期失敗，例如因為 \$1 [`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)\$1 [`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart) \$1 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) [`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured)指令碼中的錯誤而自行終止的執行個體。
對於動態節點，請尋找類似下列的錯誤：
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
對於靜態節點，請查看`clustermgtd`日誌 (`/var/log/parallelcluster/clustermgtd`) 中是否有類似以下的錯誤：
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
1. **節點 `resume_timeout` 或 `node_replacement_timeout`過期**。
執行個體無法聯結 `resume_timeout`（適用於動態節點） 或 `node_replacement_timeout`（適用於靜態節點） 中的叢集。在逾時之前不會自行終止。例如，叢集的聯網設定不正確，且節點在逾時到期Slurm後設定為 `DOWN` 狀態。
對於動態節點，請尋找類似下列的錯誤：
```
Node bootstrap error: Resume timeout expires for node
```
對於靜態節點，請查看`clustermgtd`日誌 (`/var/log/parallelcluster/clustermgtd`) 中是否有類似以下的錯誤：
```
Node bootstrap error: Replacement timeout expires for node ... in replacement.
```
1. **節點運作狀態檢查失敗**。
節點後方的執行個體未通過 Amazon EC2 運作狀態檢查或排程事件運作狀態檢查，且節點視為引導失敗節點。在此情況下，執行個體會因 無法控制的原因而終止 AWS ParallelCluster。
查看`clustermgtd`日誌 (`/var/log/parallelcluster/clustermgtd`) 中是否有類似以下的錯誤：
```
Node bootstrap error: Node %s failed during bootstrap when performing health check.
```
1. **運算節點註冊失敗Slurm**。
向Slurm控制`slurmd`常駐程式 (`slurmctld`) 註冊常駐程式失敗，並導致運算節點狀態變更為 `INVALID_REG` 狀態。設定錯誤的Slurm運算節點可能會導致此錯誤，例如使用[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)運算節點規格錯誤設定的運算節點。
查看前端節點上的`slurmctld`日誌檔案 (`/var/log/slurmctld.log`)，或查看故障運算節點的`slurmd`日誌檔案 (`/var/log/slurmd.log`) 是否有類似以下的錯誤：
```
Setting node %s to INVAL with reason: ...
```
## 如何偵錯受保護模式
如果您的叢集處於受保護狀態，而且從 AWS ParallelCluster 產生的`clustermgtd`日誌`HeadNode`和有問題的運算節點產生的`cloud-init-output`日誌，則可以檢查日誌以取得錯誤詳細資訊。如需如何擷取日誌的詳細資訊，請參閱 [擷取和保留日誌](troubleshooting-v3-get-logs.md)。
**`clustermgtd` 前端節點上的 log(`/var/log/parallelcluster/clustermgtd`)**
日誌訊息會顯示哪些分割區發生引導失敗，以及對應的引導失敗計數。
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - INFO - Partitions
bootstrap failure count: {'queue1': 2}, cluster will be set into protected mode if protected failure count reach threshold.
```
在 `clustermgtd`日誌中，搜尋 `Found the following bootstrap failure nodes`以尋找引導失敗的節點。
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - WARNING -
Found the following bootstrap failure nodes: (x2) ['queue1-st-c5large-1(192.168.110.155)', 'broken-st-c5large-2(192.168.65.215)']
```
在 `clustermgtd`日誌中，搜尋 `Node bootstrap error`以尋找失敗的原因。
```
[slurm_plugin.clustermgtd:_is_node_bootstrap_failure] - WARNING - Node bootstrap error:
Node broken-st-c5large-2(192.168.65.215) is currently in replacement and no backing instance
```
**`cloud-init-output` 運算節點上的 log(`/var/log/cloud-init-output.log`)**
在`clustermgtd`日誌中取得引導失敗節點私有 IP 地址後，您可以登入運算節點或遵循 中的指引[擷取和保留日誌](troubleshooting-v3-get-logs.md)來擷取日誌，以尋找對應的運算節點日誌。在大多數情況下，來自有問題節點的`/var/log/cloud-init-output`日誌會顯示導致運算節點引導失敗的步驟。
# Slurm 叢集快速容量不足容錯移轉
從 3.2.0 AWS ParallelCluster 版開始，叢集執行時預設會啟用快速容量不足容錯移轉模式。這可將偵測到 Amazon EC2 容量不足錯誤時，重試將任務排入佇列所花費的時間降至最低。當您使用使用不同執行個體類型的多個運算資源來設定佇列時，這特別有效。
**Amazon EC2 偵測到容量不足故障：**
+ `InsufficientInstanceCapacity`
+ `InsufficientHostCapacity`
+ `InsufficientReservedInstanceCapacity`
+ `MaxSpotInstanceCountExceeded`
+ `SpotMaxPriceTooLow`：如果 Spot 請求價格低於所需的 Spot 請求履行價格下限，則會啟用。
+ `Unsupported`：使用特定 中不支援的執行個體類型來啟用 AWS 區域。
在容量快速不足容錯移轉模式下，如果在將任務指派給 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) / 時偵測到容量不足錯誤[`compute resource`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)， 會 AWS ParallelCluster 執行下列動作：
1. 它會在預先定義的期間內將運算資源設定為停用 (`DOWN`) 狀態。
1. 它使用 `POWER_DOWN_FORCE` 來取消運算資源失敗的節點任務，並暫停失敗的節點。它會將失敗的節點設定為 `IDLE`和 `POWER_DOWN (!)` 狀態，然後設定為 `POWERING_DOWN (%)`。
1. 它會將任務排入另一個運算資源的佇列。
停用之運算資源的靜態和已啟動節點不會受到影響。任務可以在這些節點上完成。
此週期會重複，直到任務成功指派給運算資源節點。如需節點狀態的資訊，請參閱 [Slurm 適用於多個佇列模式的 指南](multiple-queue-mode-slurm-user-guide-v3.md)。
如果找不到執行任務的運算資源，任務會設定為 `PENDING` 狀態，直到經過預先定義的期間為止。在此情況下，您可以修改預先定義的時段，如下節所述。
## 容量不足逾時參數
**`insufficient_capacity_timeout`**
`insufficient_capacity_timeout` 指定當偵測到容量不足錯誤時，運算資源保持在停用 (`down`) 狀態的期間 （以秒為單位）。
預設`insufficient_capacity_timeout`會啟用 。
預設值`insufficient_capacity_timeout`為 600 秒 (10 分鐘）。
如果`insufficient_capacity_timeout`值小於或等於零，則會停用快速容量不足容錯移轉模式。
您可以在位於 的`clustermgtd`組態檔案中新增 參數`/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf`來變更`insufficient_capacity_timeout`值`HeadNode`。
您可以隨時更新 參數，而無需停止運算機群。
例如：
+ `insufficient_capacity_timeout=600`:
如果偵測到容量不足錯誤，則運算資源會設為已停用 (`DOWN`)。10 分鐘後，其失敗的節點會設定為 `idle~`(`POWER_SAVING`) 狀態。
+ `insufficient_capacity_timeout=60`:
如果偵測到容量不足錯誤，表示運算資源已停用 (`DOWN`)。1 分鐘後，其失敗的節點會設定為 `idle~` 狀態。
+ `insufficient_capacity_timeout=0`:
容量不足快速容錯移轉模式已停用。運算資源不會停用。
**注意**
當節點故障時，容量不足錯誤，以及叢集管理協助程式偵測到節點故障的時間之間，可能會有最多一分鐘的延遲。這是因為叢集管理協助程式會檢查節點容量不足失敗，並以一分鐘的間隔將運算資源設定為 `down` 狀態。
## 容量快速不足容錯移轉模式狀態
當叢集處於快速容量不足容錯移轉模式時，您可以檢查其狀態和節點狀態。
### 節點狀態
當任務提交至運算資源動態節點，並偵測到容量不足錯誤時，節點會處於 `down#` 狀態並具有原因。
```
(Code:InsufficientInstanceCapacity)Failure when resuming nodes.
```
然後，關閉電源的節點 （處於 `idle~` 狀態的節點） 會設定為 `down~`並說明原因。
```
(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity.
```
任務會重新排入佇列中其他運算資源的佇列。
運算資源靜態節點和`UP`不受快速容量不足容錯移轉模式影響的節點。
請考慮以下範例中顯示的節點狀態。
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
我們會向需要一個節點的 queue1 提交任務。
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 1 down# queue1-dy-c-1-1
queue1* up infinite 15 idle~ queue1-dy-c-2-[1-15]
queue1* up infinite 14 down~ queue1-dy-c-1-[2-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
`queue1-dy-c-1-1` 啟動節點以執行任務。不過，執行個體因為容量不足錯誤而無法啟動。節點`queue1-dy-c-1-1`設定為 `down`。運算資源 (`queue2-dy-c-1`) 中的關閉電源動態節點設定為 `down`。
您可以使用 檢查節點原因`scontrol show nodes`。
```
$ scontrol show nodes queue1-dy-c-1-1
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Failure when resuming nodes [root@2022-03-10T22:17:50]
$ scontrol show nodes queue1-dy-c-1-2
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity [root@2022-03-10T22:17:50]
```
任務會排入佇列運算資源中的另一個執行個體類型佇列。
`insufficient_capacity_timeout` 經過之後，運算資源中的節點會重設為 `idle~` 狀態。
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
運算資源中的經過 `insufficient_capacity_timeout` 和節點重設為 `idle~` 狀態後，Slurm排程器會將節點的優先順序較低。除非發生下列其中一種情況，否則排程器會持續從權重較高的其他佇列運算資源中選取節點：
+ 任務的提交需求符合復原的運算資源。
+ 沒有其他運算資源可用，因為它們具有容量。
+ `slurmctld` 會重新啟動。
+ AWS ParallelCluster 運算機群會停止並開始關閉電源並開啟所有節點的電源。
### 相關日誌
與容量不足錯誤和快速容量不足容錯移轉模式相關的日誌，可在 Slurm的`resume`日誌中找到，並在前端節點中`clustermgtd`登入。
**Slurm `resume` (`/var/log/parallelcluster/slurm_resume.log`)**
當節點因為容量不足而無法啟動時的錯誤訊息。
```
[slurm_plugin.instance_manager:_launch_ec2_instances] - ERROR - Failed RunInstances request: dcd0c252-90d4-44a7-9c79-ef740f7ecd87
[slurm_plugin.instance_manager:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['queue1-dy-c-1-1']: An error occurred
(InsufficientInstanceCapacity) when calling the RunInstances operation (reached max retries: 1): We currently do not have sufficient p4d.24xlarge capacity in the
Availability Zone you requested (us-west-2b). Our system will be working on provisioning additional capacity. You can currently get p4d.24xlarge capacity by not
specifying an Availability Zone in your request or choosing us-west-2a, us-west-2c.
```
**Slurm `clustermgtd` (`/var/log/parallelcluster/clustermgtd`)**
由於容量不足，Queue1 中的運算資源 c-1 已停用。
```
[slurm_plugin.clustermgtd:_reset_timeout_expired_compute_resources] - INFO - The following compute resources are in down state
due to insufficient capacity: {'queue1': {'c-1': ComputeResourceFailureEvent(timestamp=datetime.datetime(2022, 4, 14, 23, 0, 4, 769380, tzinfo=datetime.timezone.utc),
error_code='InsufficientInstanceCapacity')}}, compute resources are reset after insufficient capacity timeout (600 seconds) expired
```
容量不足逾時過期後，運算資源會重設，運算資源內的節點會設定為 `idle~`。
```
[root:_reset_insufficient_capacity_timeout_expired_nodes] - INFO - Reset the following compute resources because insufficient capacity
timeout expired: {'queue1': ['c-1']}
```
# Slurm 記憶體型排程
從 3.2.0 版開始， AWS ParallelCluster 支援使用 / [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings) [`EnableMemoryBasedScheduling`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-EnableMemoryBasedScheduling)叢集組態參數的Slurm記憶體型排程。
**注意**
從 3.7.0 AWS ParallelCluster 版開始，如果您在[執行個體](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)中設定多個執行個體類型，`EnableMemoryBasedScheduling`則可以啟用 。
對於 3.2.0 到 3.6.*x* AWS ParallelCluster 版，如果您在[執行個體](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)中設定多個執行個體類型，則`EnableMemoryBasedScheduling`無法啟用 。
**警告**
當您在`EnableMemoryBasedScheduling`啟用 的Slurm佇列運算資源中指定多個執行個體類型時，該`RealMemory`值是可供所有執行個體類型使用的記憶體數量下限。如果您指定具有非常不同記憶體容量的執行個體類型，這可能會導致大量未使用的記憶體。
使用 `EnableMemoryBasedScheduling: true`，Slurm排程器會追蹤每個任務在每個節點上所需的記憶體量。然後，Slurm排程器會使用此資訊來排程相同運算節點上的多個任務。任務在節點上所需的記憶體總量不能大於可用的節點記憶體。排程器可防止任務使用比提交任務時請求更多的記憶體。
使用 `EnableMemoryBasedScheduling: false`，任務可能會爭奪共用節點上的記憶體，並導致任務失敗和`out-of-memory`事件。
**警告**
Slurm 為其標籤使用 2 個表示法，例如 MB 或 GB。分別將這些標籤讀取為 MiB 和 GiB。
## Slurm 組態和記憶體型排程
使用 `EnableMemoryBasedScheduling: true`，Slurm設定下列Slurm組態參數：
+ [https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory](https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory) (位於《`slurm.conf`》)。此選項會將節點記憶體設定為 中的消耗性資源Slurm。
+ [https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace](https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace) 中的 Slurm `cgroup.conf`。使用此選項，任務對記憶體的存取僅限於提交任務時請求的記憶體量。
**注意**
設定這兩個選項時，其他幾個Slurm組態參數可能會影響Slurm排程器和資源管理員的行為。如需詳細資訊，請參閱 [Slurm 文件](https://slurm.schedmd.com/documentation.html)。
## Slurm 排程器和記憶體型排程
**`EnableMemoryBasedScheduling: false` （預設）**
根據預設， `EnableMemoryBasedScheduling` 設定為 false。當 false 時， Slurm不會在其排程演算法中包含記憶體做為資源，也不會追蹤任務使用的記憶體。使用者可以指定 `--mem MEM_PER_NODE`選項，以設定任務所需的每個節點的記憶體數量下限。這會強制排程器在排程任務`MEM_PER_NODE`時選擇`RealMemory`值至少為 的節點。
例如，假設使用者使用 提交兩個任務`--mem=5GB`。如果 CPUs或 GPUs 等請求的資源可用，任務可以同時在具有 8 GiB 記憶體的節點上執行。這兩個任務不會排程在小於 5 GiB 的運算節點上`RealMemory`。
**警告**
停用記憶體型排程時， Slurm不會追蹤任務使用的記憶體量。在相同節點上執行的任務可能會競爭記憶體資源，並導致其他任務失敗。
停用記憶體型排程時，建議使用者不要指定 [https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu)或 [https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu)選項。這些選項可能會導致與 [Slurm 文件](https://slurm.schedmd.com/documentation.html)中所述行為不同的行為。
**`EnableMemoryBasedScheduling: true`**
當 `EnableMemoryBasedScheduling` 設為 true 時， 會Slurm追蹤每個任務的記憶體用量，並防止任務使用比`--mem`提交選項請求更多的記憶體。
使用上一個範例，使用者使用 提交兩個任務`--mem=5GB`。任務無法在具有 8 GiB 記憶體的節點上同時執行。這是因為所需的記憶體總量大於節點上可用的記憶體。
啟用記憶體型排程，`--mem-per-cpu`並與Slurm文件中描述`--mem-per-gpu`的內容一致。例如，使用 提交任務`--ntasks-per-node=2 -c 1 --mem-per-cpu=2GB`。在此情況下， 會為每個節點Slurm指派總計 4 GiB 的任務。
**警告**
啟用記憶體型排程時，我們建議使用者在提交任務時包含`--mem`規格。使用隨附的預設Slurm組態 AWS ParallelCluster，如果未包含記憶體選項 (`--mem`、 或 `--mem-per-gpu`)`--mem-per-cpu`， 會將已配置節點的整個記憶體Slurm指派給任務，即使它只請求一部分的其他資源，例如 CPUs或 GPUs。這樣可以有效地防止節點共用，直到任務完成為止，因為其他任務沒有可用的記憶體。這是因為當任務提交時未提供記憶體規格[https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode)時， Slurm會將任務的每個節點的記憶體設定為 。此參數的預設值為 0，並指定對節點記憶體的無限制存取。
如果具有不同記憶體數量的多種運算資源可在相同佇列中使用，則提交而沒有記憶體選項的任務可能會在不同的節點上指派不同數量的記憶體。這取決於排程器提供給任務的節點。使用者可以在Slurm組態檔案中的叢集或分割區層級定義選項的自訂值[https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU)，例如 `DefMemPerNode`或 ，以防止此行為。
## Slurm RealMemory 和 AWS ParallelCluster SchedulableMemory
使用隨附的Slurm組態 AWS ParallelCluster， Slurm 會將 [RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory) 解譯為每個節點可供任務使用的記憶體量。從 3.2.0 版開始，預設會將 `RealMemory`Amazon [Amazon EC2 執行個體類型](https://aws.amazon.com/ec2/instance-types)中列出的記憶體 AWS ParallelCluster 設定為 95%，並由 Amazon EC2 API [DescribeInstanceTypes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTypes.html) 傳回。
停用記憶體型排程時，Slurm排程器會在使用者使用`--mem`指定的 提交任務時`RealMemory`，使用 來篩選節點。
啟用記憶體型排程時，Slurm排程器會將 解譯`RealMemory`為運算節點上執行之任務可用的記憶體數量上限。
預設設定可能不適用於所有執行個體類型：
+ 此設定可能高於節點實際可存取的記憶體數量。當運算節點是小型執行個體類型時，可能會發生這種情況。
+ 此設定可能低於節點實際可存取的記憶體數量。當運算節點是大型執行個體類型，並可能導致大量未使用的記憶體時，就會發生這種情況。
您可以使用 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) / [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) / [`SchedulableMemory`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-SchedulableMemory)來微調 AWS ParallelCluster 為運算節點`RealMemory`設定的 值。若要覆寫預設值，請`SchedulableMemory`特別為您的叢集組態定義 的自訂值。
若要檢查運算節點的實際可用記憶體，請在節點上執行 `/opt/slurm/sbin/slurmd -C`命令。此命令會傳回節點的硬體組態，包括 [https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)值。如需詳細資訊，請參閱[https://slurm.schedmd.com/slurmd.html#OPT_-C](https://slurm.schedmd.com/slurmd.html#OPT_-C)。
確定運算節點的作業系統程序有足夠的記憶體。若要這樣做，請將 `SchedulableMemory`值設定為低於`slurmd -C`命令傳回`RealMemory`的值，以限制任務可用的記憶體。
# 使用 Slurm 進行多個執行個體類型配置
從 3.3.0 AWS ParallelCluster 版開始，您可以設定叢集從運算資源的一組已定義的執行個體類型進行配置。配置可以根據 Amazon EC2 機群低成本或最佳容量策略。
這組已定義的執行個體類型必須全部具有相同數量vCPUs，或者，如果停用多執行緒，則必須具有相同數量的核心。此外，這組執行個體類型必須具有相同製造商的相同加速器數量。如果 [`Efa`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa) / [`Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa-Enabled) 設定為 `true`，則執行個體必須支援 EFA。如需詳細資訊和需求，請參閱 [`Scheduling`](Scheduling-v3.md) / / [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) [`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy)和 [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) / [`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)。
您可以`capacity-optimized`根據您的 [CapacityType](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CapacityType) 組態[`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy)，將 設定為 `lowest-price`或 。
在 中[`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)，您可以設定一組執行個體類型。
**注意**
從 3.7.0 AWS ParallelCluster 版開始，如果您在[執行個體](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)中設定多個執行個體類型，`EnableMemoryBasedScheduling`則可以啟用 。
對於 3.2.0 到 3.6.*x* AWS ParallelCluster 版，如果您在[執行個體](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)中設定多個執行個體類型，則`EnableMemoryBasedScheduling`無法啟用 。
下列範例示範如何查詢 vCPUs、EFA 支援和架構的執行個體類型。
InstanceTypes 使用 96 個 vCPUs和 x86\$164 架構進行查詢。
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-vcpus,Values=96" "Name=processor-info.supported-architecture,Values=x86_64" \
--query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
InstanceTypes 具有 64 個核心、EFA 支援和 arm64 架構的查詢。
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-cores,Values=64" "Name=processor-info.supported-architecture,Values=arm64" "Name=network-info.efa-supported,Values=true" --query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
下一個範例叢集組態程式碼片段顯示如何使用這些 InstanceType和 AllocationStrategy 屬性。
```
...
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue-1
CapacityType: ONDEMAND
AllocationStrategy: lowest-price
...
ComputeResources:
- Name: computeresource1
Instances:
- InstanceType: r6g.2xlarge
- InstanceType: m6g.2xlarge
- InstanceType: c6g.2xlarge
MinCount: 0
MaxCount: 500
- Name: computeresource2
Instances:
- InstanceType: m6g.12xlarge
- InstanceType: x2gd.12xlarge
MinCount: 0
MaxCount: 500
...
```
# 動態節點的叢集擴展
ParallelCluster 支援使用 Slurm的省Slurm電工具外掛程式動態擴展叢集的方法。如需詳細資訊，請參閱 Slurm 文件中的[雲端排程指南](https://slurm.schedmd.com/elastic_computing.html)和[Slurm省電指南](https://slurm.schedmd.com/power_save.html)。下列主題說明每個版本Slurm的策略。
**Topics**
+ [Slurm 3.8.0 版中的動態節點配置策略](scheduler-node-allocation-v3-3.8.0.md)
+ [Slurm 3.7.x 版中的動態節點配置策略](scheduler-dynamic-node-allocation-v3-3.7.x.md)
+ [Slurm 3.6.x 版和舊版中的動態節點配置策略](scheduler-dynamic-node-allocation-v3-3.6.x.md)
# Slurm 3.8.0 版中的動態節點配置策略
從 ParallelCluster 3.8.0 版開始，ParallelCluster 使用**任務層級恢復**或**任務層級擴展**作為預設動態節點分配策略來擴展叢集：ParallelCluster 會根據每個任務的需求、分配給任務的節點數量，以及需要恢復哪些節點來擴展叢集。ParallelCluster 會從 SLURM\$1RESUME\$1FILE 環境變數取得此資訊。
動態節點的擴展是一個兩步驟程序，涉及啟動 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 個執行個體，或排程器在其他已執行的運算節點上排程任務為止。
# Slurm 3.7.x 版中的動態節點配置策略
ParallelCluster 使用 2 種類型的動態節點配置策略來擴展叢集：
+
**根據可用的請求節點資訊進行配置：**
+ **所有節點繼續**或**節點清單**擴展：
ParallelCluster 只會在 Slurm的`ResumeProgram`執行時，根據 請求Slurm的節點清單名稱來擴展叢集。它只會依節點名稱將運算資源配置給節點。節點名稱清單可以跨越多個任務。
+ **任務層級恢復**或**任務層級**擴展：
ParallelCluster 會根據每個任務的需求、目前分配給任務的節點數量，以及需要繼續的節點，來擴展叢集。ParallelCluster 會從`SLURM_RESUME_FILE`環境變數取得此資訊。
+
**使用 Amazon EC2 啟動策略進行配置：**
+ **最佳嘗試**擴展：
ParallelCluster 使用目標容量下限等於 1 的 Amazon EC2 啟動執行個體 API 呼叫來擴展叢集，以啟動部分但不一定是支援請求節點所需的所有執行個體。
+ **All-or-nothing**擴展：
ParallelCluster 使用 Amazon EC2 啟動執行個體 API 呼叫來擴展叢集，只有在啟動支援請求節點所需的所有執行個體時，該呼叫才會成功。在此情況下，它會呼叫目標容量下限等於總請求容量的 Amazon EC2 啟動執行個體 API。
根據預設，ParallelCluster **使用節點清單**擴展搭配**最佳 **Amazon EC2 啟動策略來啟動部分，但不一定是支援請求節點所需的所有執行個體。它會嘗試佈建盡可能多的容量，以便為提交的工作負載提供服務。
從 ParallelCluster 3.7.0 版開始，ParallelCluster 使用**任務層級**擴展搭配**all-or-nothing** EC2 啟動策略，用於以**獨家模式**提交的任務。當您以獨佔模式提交任務時，該任務具有其配置節點的獨佔存取權。如需詳細資訊，請參閱 Slurm 文件中的 [EXCLUSIVE](https://slurm.schedmd.com/slurm.conf.html#OPT_EXCLUSIVE)。
若要以排他性模式提交任務：
+ 將Slurm任務提交至叢集時傳遞獨佔旗標。例如 `sbatch ... --exclusive`。
或
+ 將任務提交至已設定為 [`JobExclusiveAllocation`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-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-nothing** EC2 啟動 API 呼叫才會成功。
+ 當您在具有多個執行個體類型的運算資源中提交任務時，在具有單一可用區域的佇列中，只有在單一執行個體類型可提供所有容量時，**all-or-nothing** Amazon EC2 啟動 API 呼叫才會成功。
+ 當您在具有多個執行個體類型的運算資源中提交任務時，在跨越多個可用區域的佇列中，不支援**all-or-nothing**Amazon EC2 啟動 API 呼叫，而 ParallelCluster 會改為執行**最佳嘗試**擴展。
# Slurm 3.6.x 版和舊版中的動態節點配置策略
AWS ParallelCluster 僅使用一種類型的動態節點配置策略來擴展叢集：
+ 根據可用的請求節點資訊進行配置：
+ **所有節點恢復**或**節點清單**擴展：ParallelCluster 只會在 Slurm的`ResumeProgram` 執行時，根據 Slurm請求的節點清單名稱擴展叢集。它只會依節點名稱將運算資源配置給節點。節點名稱清單可以跨越多個任務。
+ 使用 Amazon EC2 啟動策略進行配置：
+ **最佳努力**擴展：ParallelCluster 使用目標容量下限等於 1 的 Amazon EC2 啟動執行個體 API 呼叫來擴展叢集，以啟動部分但不一定是支援請求節點所需的所有執行個體。
ParallelCluster **使用節點清單**擴展搭配**最佳 **Amazon EC2 啟動策略來啟動部分，但不一定是支援請求節點所需的所有執行個體。它會嘗試佈建盡可能多的容量，以便為提交的工作負載提供服務。
限制
+ 擴展程序結束時可能的閒置執行中執行個體，適用於無法配置任務請求的所有節點的情況。
# Slurm 使用 會計 AWS ParallelCluster
從 3.3.0 版開始， AWS ParallelCluster 支援使用叢集組態參數 [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings)/[資料庫](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)進行Slurm會計。
從 3.10.0 版開始， AWS ParallelCluster 支援使用叢集組態參數 [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings) / ExternalSlurmdbd 的外部 Slurmdbd [ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)進行Slurm會計。如果多個叢集共用相同的資料庫，建議使用外部 Slurmdbd。
透過 Slurm 會計，您可以整合外部會計資料庫來執行下列動作：
+ 管理叢集使用者或使用者群組和其他實體。透過此功能，您可以使用 Slurm更進階的功能，例如資源限制強制執行、公平共用和 QOSs。
+ 收集並儲存任務資料，例如執行任務的使用者、任務的持續時間及其使用的資源。您可以使用 `sacct`公用程式檢視儲存的資料。
**注意**
AWS ParallelCluster 支援Slurm計算[Slurm支援的 MySQL 資料庫伺服器](https://slurm.schedmd.com/accounting.html#mysql-configuration)。
## 在 AWS ParallelCluster v3.10.0 和更新版本Slurmdbd中使用外部 進行Slurm會計
設定Slurm會計之前，您必須擁有現有的外部Slurmdbd資料庫伺服器，該伺服器會連接到現有的外部資料庫伺服器。
若要設定此項，請定義下列項目：
+ [ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)/[主機](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ExternalSlurmdbd-Host)中外部Slurmdbd伺服器的地址。伺服器必須存在且可從前端節點連線。
+ 在 [MungeKeySecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-MungeKeySecretArn) 中與外部Slurmdbd伺服器通訊的 munge 金鑰。
若要逐步完成教學課程，請參閱 [使用外部Slurmdbd會計建立叢集](external-slurmdb-accounting.md)。
**注意**
您負責管理Slurm資料庫會計實體。
AWS ParallelCluster 外部SlurmDB支援功能的架構可啟用多個共用相同SlurmDB和相同資料庫的叢集。
![\[\]](http://docs.aws.amazon.com/zh_tw/parallelcluster/latest/ug/images/External_Slurmdbd_Architecture_ASG.png)
**警告**
AWS ParallelCluster 與外部 之間的流量SlurmDB不會加密。建議在信任的網路SlurmDB中執行叢集和外部 。
## 在 AWS ParallelCluster v3.3.0 和更新Slurmdbd版本中使用前端節點進行Slurm會計
設定Slurm會計之前，您必須擁有使用`mysql`通訊協定的現有外部資料庫伺服器和資料庫。
若要使用 設定Slurm會計 AWS ParallelCluster，您必須定義下列項目：
+ [資料庫](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[Uri](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-Uri) 中外部資料庫伺服器的 URI。伺服器必須存在且可從前端節點連線。
+ 存取[資料庫](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database) / [PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn) 和[資料庫](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database) / [UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName) 中定義的外部資料庫的登入資料。 AWS ParallelCluster 會使用此資訊在 Slurm層級設定會計作業，並在前端節點上設定 `slurmdbd`服務。 `slurmdbd`是管理叢集與資料庫伺服器之間通訊的協助程式。
若要逐步完成教學課程，請參閱 [使用Slurm會計建立叢集](tutorials_07_slurm-accounting-v3.md)。
**注意**
AWS ParallelCluster 透過將預設叢集使用者設定為Slurm資料庫中的資料庫管理員，執行Slurm會計資料庫的基本引導。 AWS ParallelCluster 不會將任何其他使用者新增至會計資料庫。客戶負責管理Slurm資料庫中的會計實體。
AWS ParallelCluster 設定 [https://slurm.schedmd.com/slurmdbd.html](https://slurm.schedmd.com/slurmdbd.html) 以確保叢集在Slurm資料庫伺服器上擁有自己的資料庫。相同的資料庫伺服器可以跨多個叢集使用，但每個叢集都有自己的個別資料庫。 AWS ParallelCluster 會使用叢集名稱在`slurmdbd`組態檔案[https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc)參數中定義資料庫的名稱。請考慮下列情況。資料庫伺服器上存在的資料庫包含未對應至作用中叢集名稱的叢集名稱。在此情況下，您可以使用該叢集名稱建立新的叢集，以對應至該資料庫。 會為新叢集Slurm重複使用資料庫。
**警告**
我們不建議同時設定多個叢集來使用相同的資料庫。這樣做可能會導致效能問題，甚至是資料庫死結情況。
如果在叢集的前端節點上啟用Slurm會計，我們建議您使用具有強大 CPU、更多記憶體和更高網路頻寬的執行個體類型。 Slurm 會計可能會對叢集的前端節點增加壓力。
在會計功能的目前架構中 AWS ParallelCluster Slurm，每個叢集都有自己的`slurmdbd`協助程式執行個體，如下圖範例組態所示。
![\[\]](http://docs.aws.amazon.com/zh_tw/parallelcluster/latest/ug/images/slurm-acct-arch.png)
如果您要將自訂Slurm多叢集或聯合功能新增至叢集環境，則所有叢集都必須參考相同的`slurmdbd`執行個體。對於此替代方案，我們建議您在一個叢集上啟用 AWS ParallelCluster Slurm會計，並手動設定其他叢集以連線到在第一個叢集上託管`slurmdbd`的 。
如果您使用的 AWS ParallelCluster 是 3.3.0 版之前的版本，請參閱本 [HPC 部落格文章](https://aws.amazon.com/blogs/compute/enabling-job-accounting-for-hpc-with-aws-parallelcluster-and-amazon-rds/)中所述的實作Slurm會計的替代方法。
## Slurm 會計考量
### 不同 VPCs上的資料庫和叢集
若要啟用Slurm會計，資料庫伺服器需要做為`slurmdbd`協助程式執行的讀取和寫入操作的後端。在建立或更新叢集以啟用Slurm會計之前，前端節點必須能夠連線到資料庫伺服器。
如果您需要在叢集使用的 VPC 以外的 VPC 上部署資料庫伺服器，請考慮下列事項：
+ 若要在叢集端`slurmdbd`的 與資料庫伺服器之間啟用通訊，您必須在兩個 VPCs之間設定連線。如需詳細資訊，請參閱《*Amazon Virtual Private Cloud 使用者指南*》中的 [VPC 對等](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)互連。
+ 您必須建立要連接到叢集 VPC 上前端節點的安全群組。在兩個 VPCs 對等互連之後，即可在資料庫端和叢集端安全群組之間進行交叉連結。如需詳細資訊，請參閱《*Amazon Virtual Private Cloud 使用者指南*》中的[安全群組規則](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules)。
### 在 `slurmdbd`和資料庫伺服器之間設定 TLS 加密
使用 AWS ParallelCluster 提供的預設Slurm會計組態，如果伺服器支援 TLS encryption. AWS database 服務，例如 Amazon RDS，且預設 Amazon Aurora 支援 TLS 加密，則 會`slurmdbd`建立與資料庫伺服器的 TLS 加密連線。
您可以在資料庫伺服器上設定 `require_secure_transport` 參數，在伺服器端要求安全連線。這是在提供的 CloudFormation 範本中設定。
遵循安全最佳實務，我們建議您也在`slurmdbd`用戶端上啟用伺服器身分驗證。若要這樣做，請在 中設定 [StorageParameters](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageParameters)`slurmdbd.conf`。將伺服器 CA 憑證上傳至叢集的前端節點。接著，將 `StorageParameters`中的 [SSL\$1CA](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_SSL_CA) 選項`slurmdbd.conf`設定為前端節點上伺服器 CA 憑證的路徑。這樣做可在 `slurmdbd` 端啟用伺服器身分驗證。進行這些變更後，請重新啟動 `slurmdbd`服務，在啟用身分驗證的情況下重新建立與資料庫伺服器的連線。
### 更新資料庫登入資料
若要更新[資料庫](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName)或 [PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn) 的值，您必須先停止運算機群。假設存放在秘密中的 AWS Secrets Manager 秘密值已變更，且其 ARN 不會變更。在這種情況下，叢集不會自動將資料庫密碼更新為新值。若要更新叢集的新秘密值，請從前端節點執行下列命令。
```
$ sudo /opt/parallelcluster/scripts/slurm/update_slurm_database_password.sh
```
**警告**
為了避免遺失會計資料，建議您只在運算機群停止時變更資料庫密碼。
### 資料庫監控
建議您啟用 AWS 資料庫服務的監控功能。如需詳細資訊，請參閱 [Amazon RDS 監控](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html)或 [Amazon Aurora 監控](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/MonitoringAurora.html)文件。
# Slurm 組態自訂
從 3.6.0 AWS ParallelCluster 版開始，您可以在 AWS ParallelCluster 叢集`slurm.conf`Slurm組態中自訂組態。
在叢集組態中，您可以使用下列叢集組態設定來自訂組態Slurm參數：
+ 如果您同時指定 Slurm / [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings) [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettings)或 parameter. AWS ParallelCluster fails，即可自訂整個叢集的[`CustomSlurmSettingsIncludeFile`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettingsIncludeFile)參數。
+ 使用 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) / [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomSlurmSettings)（映射到Slurm分割區） 自訂佇列的Slurm參數。
+ 使用 / [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) / [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)（映射至Slurm節點） [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) 自訂運算資源的Slurm參數。
## Slurm 使用 時的組態自訂限制和考量事項 AWS ParallelCluster
+ 對於 `CustomSlurmSettings`和 `CustomSlurmSettingsIncludeFile`設定，您只能指定和更新包含在您用來設定叢集的[Slurm版本](slurm-workload-manager-v3.md)所支援的 AWS ParallelCluster 版本中的`slurm.conf`參數。
+ 如果您在任何`CustomSlurmSettings`參數中指定自訂Slurm組態， 會 AWS ParallelCluster 執行驗證檢查，並防止設定或更新與 AWS ParallelCluster 邏輯衝突的Slurm組態參數。已知與 衝突的Slurm組態參數 AWS ParallelCluster 會在拒絕清單中識別。如果新增其他Slurm功能，拒絕清單可能會在未來 AWS ParallelCluster 版本中變更。如需詳細資訊，請參閱[拒絕列出的Slurm組態參數 `CustomSlurmSettings`](#slurm-configuration-denylists-v3)。
+ AWS ParallelCluster 只會檢查參數是否在拒絕清單中。 AWS ParallelCluster 不會驗證您的自訂Slurm組態參數語法或語意。您有責任驗證您的自訂Slurm組態參數。無效的自訂Slurm組態參數可能會導致Slurm協助程式失敗，進而導致叢集建立和更新失敗。
+ 如果您在 中指定自訂Slurm組態`CustomSlurmSettingsIncludeFile`， AWS ParallelCluster 不會執行任何驗證。
+ 您可以更新 `CustomSlurmSettings`和 ，`CustomSlurmSettingsIncludeFile`而無需停止和啟動運算機群。在此情況下， `slurmctld` 會 AWS ParallelCluster 重新啟動協助程式並執行 `scontrol reconfigure`命令。
在整個叢集中註冊變更之前，某些Slurm組態參數可能需要不同的操作。例如，它們可能需要重新啟動叢集中的所有協助程式。您有責任驗證 AWS ParallelCluster 操作是否足以在更新期間傳播您的自訂Slurm組態參數設定。如果您發現 AWS ParallelCluster 操作不足，您有責任提供傳播更新設定所需的其他動作，如 [Slurm 文件](https://slurm.schedmd.com/documentation.html)中所建議。
## 拒絕列出的Slurm組態參數 `CustomSlurmSettings`
下表列出拒絕使用的 參數 AWS ParallelCluster 版本，從 3.6.0 版開始。 `CustomSlurmSettings`不支援 3.6.0 版之前的 AWS ParallelCluster 版本。
**叢集層級的拒絕列出參數：**
| Slurm 參數 | AWS ParallelCluster 版本中列入拒絕清單 |
| --- | --- |
| CommunicationParameters | 3.6.0 |
| Epilog | 3.6.0 |
| GresTypes | 3.6.0 |
| LaunchParameters | 3.6.0 |
| Prolog | 3.6.0 |
| ReconfigFlags | 3.6.0 |
| ResumeFailProgram | 3.6.0 |
| ResumeProgram | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| SlurmctldHost | 3.6.0 |
| SlurmctldLogFile | 3.6.0 |
| SlurmctldParameters | 3.6.0 |
| SlurmdLogfile | 3.6.0 |
| SlurmUser | 3.6.0 |
| SuspendExcNodes | 3.6.0 |
| SuspendProgram | 3.6.0 |
| SuspendTime | 3.6.0 |
| TaskPlugin | 3.6.0 |
| TreeWidth | 3.6.0 |
**在叢集組態中設定[原生Slurm會計整合](slurm-accounting-v3.md)時，叢集層級的拒絕列出參數：**
| Slurm 參數 | AWS ParallelCluster 版本中列入拒絕清單 |
| --- | --- |
| AccountingStorageType | 3.6.0 |
| AccountingStorageHost | 3.6.0 |
| AccountingStoragePort | 3.6.0 |
| AccountingStorageUser | 3.6.0 |
| JobAcctGatherType | 3.6.0 |
**佇列管理的佇列在佇列 （分割區） 層級拒絕列出的參數 AWS ParallelCluster：**
| Slurm 參數 | AWS ParallelCluster 版本中列入拒絕清單 |
| --- | --- |
| 節點 | 3.6.0 |
| PartitionName | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| State | 3.6.0 |
| SuspendTime | 3.6.0 |
**運算資源的運算資源 （節點） 層級拒絕列出的參數，管理者為 AWS ParallelCluster：**
| Slurm 參數 | 拒絕列出 AWS ParallelCluster 版本 和更新版本 |
| --- | --- |
| CPUs | 3.6.0 |
| 功能 | 3.6.0 |
| Gres | 3.6.0 |
| NodeAddr | 3.6.0 |
| NodeHostname | 3.6.0 |
| NodeName | 3.6.0 |
| Weight | 3.7.0 |
# Slurm 與 `prolog``epilog`
從 3.6.0 AWS ParallelCluster 版開始，使用 AWS ParallelCluster 部署的Slurm組態包含 `Prolog`和 `Epilog`組態參數：
```
# PROLOG AND EPILOG
Prolog=/opt/slurm/etc/scripts/prolog.d/*
Epilog=/opt/slurm/etc/scripts/epilog.d/*
SchedulerParameters=nohold_on_prolog_fail
BatchStartTimeout=180
```
如需詳細資訊，請參閱 Slurm 文件中的 [Prolog 和 Epilog 指南](https://slurm.schedmd.com/prolog_epilog.html)。
AWS ParallelCluster 包含下列 prolog 和 epilog 指令碼：
+ `90_plcuster_health_check_manager` （在 `Prolog` 資料夾中）
+ `90_pcluster_noop` （在 `Epilog` 資料夾中）
**注意**
`Prolog` 和 `Epilog` 資料夾都必須包含至少一個檔案。
您可以將自訂`prolog`或`epilog`指令碼新增至對應的 `Prolog`和 `Epilog` 資料夾，以使用它們。
**警告**
Slurm 會以反向字母順序執行資料夾中的每個指令碼。
`prolog` 和 `epilog`指令碼的執行時間持續時間會影響執行任務所需的時間。在執行多個或長時間執行的`prolog`指令碼時更新`BatchStartTimeout`組態設定。預設值為 3 分鐘。
如果您使用的是自訂`prolog`和`epilog`指令碼，請在個別的 `Prolog`和 `Epilog` 資料夾中找到指令碼。建議您保留在每個自訂`90_plcuster_health_check_manager`指令碼之前執行的指令碼。如需詳細資訊，請參閱[Slurm 組態自訂](slurm-configuration-settings-v3.md)。
# 叢集容量大小和更新
叢集的容量是由叢集可以擴展的運算節點數量所定義。運算節點由 AWS ParallelCluster 組態 中運算資源內定義的 Amazon EC2 執行個體支援`(Scheduling/SlurmQueues/ ComputeResources)`，並組織成 1：1 `(Scheduling/SlurmQueues)`對應至Slurm分割區的佇列。
在運算資源中，您可以設定必須在叢集中持續執行的運算節點 （執行個體） 數目下限 (`MinCount`)，以及運算資源可擴展至 ([`MaxCount`3) ](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)的執行個體數目上限。
在叢集建立時間或叢集更新時， `MinCount`會針對叢集中定義的每個運算資源 (`Scheduling/SlurmQueues/ ComputeResources`)，依在 中設定的數目 AWS ParallelCluster 啟動 Amazon EC2 執行個體。啟動以涵蓋叢集中運算資源最小數量節點的執行個體稱為***靜態節點**。*啟動後，除非發生特定事件或條件，否則靜態節點應持續存在於叢集中，系統不會終止這些節點。例如，這類事件包括 Slurm或 Amazon EC2 運作狀態檢查失敗，以及Slurm節點狀態變更為 DRAIN 或 DOWN。
在 `1`到 `‘MaxCount - MinCount’`(`MaxCount ` *減去*` MinCount)` ，隨需啟動以處理叢集負載增加的 Amazon EC2 執行個體，稱為***動態節點***。 它們的性質是暫時性的，它們被啟動來提供待定任務，一旦它們在叢集組態`Scheduling/SlurmSettings/ScaledownIdletime`中保持閒置一段時間後就會終止 （預設值：10 分鐘）。
靜態節點和動態節點符合下列命名結構描述：
+ 靜態節點`-st--`，其中 ` = 1..ComputeResource/MinCount`
+ 動態節點，`-dy--`其中 ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
例如，假設有下列 AWS ParallelCluster 組態：
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
下列節點將在 中定義 Slurm
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
當運算資源具有 時`MinCount == MaxCount`，所有對應的運算節點都會是靜態的，而且所有執行個體都會在叢集建立/更新時啟動，並保持啟動和執行。例如：
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## 叢集容量更新
叢集容量的更新包括新增或移除佇列、運算資源或變更運算資源`MinCount/MaxCount`的 。從 3.9.0 AWS ParallelCluster 版開始，減少佇列的大小需要停止運算機群，或將 的 [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy) 設定為 TERMINATE，才能進行叢集更新。在下列情況下，不需要停止運算機群或將 [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy) 設定為 TERMINATE：
+ 將新佇列新增至排程/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)
+ 將新的運算資源`Scheduling/SlurmQueues/ComputeResources`新增至佇列
+ 增加運算資源`MaxCount`的
+ 增加運算資源的 MinCount 並增加相同運算資源至少相同數量的 MaxCount
## 考量與限制
本節旨在概述調整叢集容量大小時應考慮的任何重要因素、限制或限制。
+ 從名稱為 `-*` `Scheduling/SlurmQueues`的所有運算節點移除佇列時，靜態和動態都會從Slurm組態中移除，且對應的 Amazon EC2 執行個體將會終止。
+ `Scheduling/SlurmQueues/ComputeResources` 從佇列移除運算資源時，所有名為 的運算節點`-*--*`，包括靜態和動態，都會從Slurm組態中移除，且對應的 Amazon EC2 執行個體將會終止。
變更運算資源的 `MinCount` 參數時，我們可以區分兩種不同的案例，如果 `MaxCount` 保持等於 `MinCount`（僅限靜態容量），如果 `MaxCount` 大於 `MinCount`（混合靜態和動態容量）。
### 僅限靜態節點的容量變更
+ 如果 `MinCount == MaxCount` ，增加 `MinCount`（和 ) `MaxCount` 時，叢集的設定方式是將靜態節點數量擴展到 的新值，`MinCount``-st--`而且系統會繼續嘗試啟動 Amazon EC2 執行個體，以滿足新的必要靜態容量。
+ 如果 `MinCount == MaxCount` ，則在減少 `MinCount`（和 `MaxCount` ) 數量 N 時，將透過移除最後一個 N 個靜態節點來設定叢集，`-st--...]`且系統會終止對應的 Amazon EC2 執行個體。
+ 初始狀態 `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 在 `MinCount`和 `-30`上更新 `MaxCount: MinCount = MaxCount = 70`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### 混合節點的容量變更
如果 `MinCount < MaxCount`，增加`MinCount`數量 N 時 （假設 `MaxCount`將保持不變），叢集的設定方式是將靜態節點數目擴展到 `MinCount`( ) `old_MinCount + N` 的新值：`-st--`且系統會繼續嘗試啟動 Amazon EC2 執行個體，以滿足新的必要靜態容量。此外，為了滿足運算資源的`MaxCount`容量，叢集組態會透過*移除最後一個 N 個動態節點*來更新： `-dy--[...]`且系統會終止對應的 Amazon EC2 執行個體。
+ 初始狀態： `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 將 \$130 更新為 `MinCount : MinCount = 130 (MaxCount = 150)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
如果 `MinCount < MaxCount`，增加 `MinCount`且數量`MaxCount`相同 N 時，叢集的設定方式是將靜態節點數量擴展到 `MinCount`() `old_MinCount + N` 的新值： ，`-st--`而且系統會繼續嘗試啟動 Amazon EC2 執行個體，以滿足新的必要靜態容量。此外，不會對動態節點數量進行任何變更，以遵守新的
`MaxCount` 值。
+ 初始狀態： `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 將 \$130 更新為 `MinCount : MinCount = 130 (MaxCount = 180)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
如果 `MinCount < MaxCount`，則在減少`MinCount`數量 N 時 （假設 `MaxCount`將保持不變），則會透過移除最後一個 N 個靜態節點靜態節點來設定叢集，`-st--[...`且系統會終止對應的 Amazon EC2 執行個體。此外，為了滿足運算資源的`MaxCount`容量，叢集組態的更新方式是擴展動態節點的數量以填補間隙`MaxCount - new_MinCount: -dy--[1..]`。在此情況下，由於這些是動態節點，除非排程器在新節點上有待定任務，否則不會啟動新的 Amazon EC2 執行個體。
+ 初始狀態： `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 在 上更新 -30 `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
如果 `MinCount < MaxCount`，當減少 `MinCount`且數量`MaxCount`相同 N 時，將透過移除最後一個 N 個靜態節點來設定叢集，`-st--...]`且系統會終止對應的 Amazon EC2 執行個體。
此外，不會對動態節點數量進行任何變更，以遵守新`MaxCount`值。
+ 初始狀態： `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 在 上更新 -30 `MinCount : MinCount = 70 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
如果 `MinCount < MaxCount`，則在減少`MaxCount`數量 N 時 （假設 `MinCount`將保持不變），叢集將透過移除最後一個 N 個動態節點進行設定，`-dy--]`如果靜態節點受到 running.No 影響，系統將終止對應的 Amazon EC2 執行個體。
+ 初始狀態： `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ 在 上更新 -30 `MaxCount : MinCount = 100 (MaxCount = 120)`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## 對任務的影響
在移除節點且 Amazon EC2 執行個體終止的所有情況下，除非沒有其他節點滿足任務需求，否則在移除的節點上執行的 sbatch 任務會重新排入佇列。在此情況下，任務會失敗，狀態為 NODE\$1FAIL，並從佇列中消失，且必須手動重新提交。
如果您打算執行叢集調整大小更新，您可以防止任務在計劃更新期間將移除的節點中執行。這可以透過設定要在維護中移除的節點來實現。請注意，在維護中設定節點不會影響最終已在節點中執行的任務。
假設透過計劃的叢集調整大小更新，您將移除節點 `qeueu-st-computeresource-[9-10`】。您可以使用下列命令建立Slurm保留
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
這將在節點 `maint_for_update` 上建立名為 的Slurm保留`qeueu-st-computeresource-[9-10]`。從建立保留開始，就無法再將任何任務執行到節點 `qeueu-st-computeresource-[9-10]`。請注意，保留不會阻止任務最終配置到節點 `qeueu-st-computeresource-[9-10]`。
叢集調整大小更新後，如果僅在調整大小更新期間移除的節點上設定Slurm保留，系統會自動刪除維護保留。如果您改為在叢集調整大小更新後仍存在的節點上建立Slurm保留，我們可能會想要在執行調整大小更新後，使用以下命令來移除節點上的維護保留
```
sudo -i scontrol delete ReservationName=maint_for_update
```
如需Slurm保留的其他詳細資訊，請參閱[此處](https://slurm.schedmd.com/reservations.html)的官方 SchedMD 文件。
## 容量變更的叢集更新程序
排程器組態變更時，會在叢集更新程序期間執行下列步驟：
+ 停止 AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ 從 AWS ParallelCluster 組態產生更新的Slurm分割區組態
+ 重新啟動 `slurmctld`（透過 Chef 服務配方完成）
+ 檢查`slurmctld`狀態 `(systemctl is-active --quiet slurmctld.service)`
+ 重新載入Slurm組態 `(scontrol reconfigure)`
+ 啟動 `clustermgtd (supervisorctl start clustermgtd)`
# 搭配 使用 AWS Batch (`awsbatch`) 排程器 AWS ParallelCluster
**警告**
AWS CodeBuild 亞太區域 （馬來西亞） (`ap-southeast-5`) 和亞太區域 （泰國） (`ap-southeast-7`) 區域不支援 。因此，這些區域不支援 ParallelCluster AWS Batch 整合。
AWS ParallelCluster 也支援 AWS Batch 排程器。下列主題說明如何使用 AWS Batch。如需 的詳細資訊 AWS Batch，請參閱 [AWS Batch](https://aws.amazon.com/batch/)。如需文件，請參閱 [AWS Batch 使用者指南](https://docs.aws.amazon.com/batch/latest/userguide/)。
**AWS ParallelCluster 的 CLI 命令 AWS Batch**
當您使用`awsbatch`排程器時， 的 AWS ParallelCluster AWS Batch CLI 命令會自動安裝在 AWS ParallelCluster 前端節點中。CLI 使用 AWS Batch API 操作並允許下列操作：
+ 提交和管理任務。
+ 監控任務、佇列和主機。
+ 鏡像傳統排程器命令。
**重要**
AWS ParallelCluster 不支援 的 GPU 任務 AWS Batch。如需詳細資訊，請參閱 [GPU 任務](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html)。
此 CLI 會以個別的套件形式分佈。如需詳細資訊，請參閱[排程器支援](moving-from-v2-to-v3.md#scheduler_support)。
**Topics**
+ [`awsbsub`](awsbatchcli.awsbsub-v3.md)
+ [`awsbstat`](awsbatchcli.awsbstat-v3.md)
+ [`awsbout`](awsbatchcli.awsbout-v3.md)
+ [`awsbkill`](awsbatchcli.awsbkill-v3.md)
+ [`awsbqueues`](awsbatchcli.awsbqueues-v3.md)
+ [`awsbhosts`](awsbatchcli.awsbhosts-v3.md)
# `awsbsub`
將任務提交至叢集的任務佇列。
```
awsbsub [-h] [-jn JOB_NAME] [-c CLUSTER] [-cf] [-w WORKING_DIR]
[-pw PARENT_WORKING_DIR] [-if INPUT_FILE] [-p VCPUS] [-m MEMORY]
[-e ENV] [-eb ENV_DENYLIST] [-r RETRY_ATTEMPTS] [-t TIMEOUT]
[-n NODES] [-a ARRAY_SIZE] [-d DEPENDS_ON]
[command] [arguments [arguments ...]]
```
**重要**
AWS ParallelCluster 不支援 的 GPU 任務 AWS Batch。如需詳細資訊，請參閱 [GPU 任務](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html)。
## 定位引數
***command***
提交任務 （指定的命令必須可用於運算執行個體） 或要傳輸的檔案名稱。另請參閱`--command-file`。
**arguments**
(選用) 指定命令或命令檔案的引數。
## 具名引數
**-jn *JOB\$1NAME*, --job-name *JOB\$1NAME***
為任務命名。第一個字元必須是字母或數字。任務名稱可包含字母 （大小寫）、數字、連字號和底線，長度上限為 128 個字元。
**-c *CLUSTER*, --cluster *CLUSTER***
指定要使用的叢集。
**-cf, --command-file**
指出命令是要傳輸至運算執行個體的檔案。
預設：False
**-w *WORKING\$1DIR*, --working-dir *WORKING\$1DIR***
指定要做為任務工作目錄的資料夾。如果未指定工作目錄，任務會在使用者主目錄的`job-`子資料夾中執行。您可以使用此參數或 `--parent-working-dir` 參數。
**-pw *PARENT\$1WORKING\$1DIR*, --parent-working-dir *PARENT\$1WORKING\$1DIR***
指定任務工作目錄的父資料夾。如果未指定父工作目錄，則會預設為使用者的主目錄。系統會在上層工作目錄中建立一個名為 `job-` 的子資料夾。您可以使用此參數或 `--working-dir` 參數。
**-if *INPUT\$1FILE*, --input-file *INPUT\$1FILE***
在任務的工作目錄中指定要傳輸至運算執行個體的檔案。您可以指定多個輸入檔案參數。
**-p *VCPUS*, --vcpus *VCPUS***
指定要保留給容器的 vCPU 數目。與 搭配使用時`–nodes`，它會識別每個節點vCPUs 數量。
預設：1
**-m *MEMORY*, --memory *MEMORY***
指定要提供給任務的記憶體的硬性限制 (以 MiB 為單位)。如果您的任務嘗試超過此處指定的記憶體限制，則任務會結束。
預設：128
**-e *ENV*, --env *ENV***
指定以逗號分隔的清單，其中列出要匯出至任務環境的環境變數名稱。若要匯出所有環境變數，請指定「所有」。請注意，「全部」環境變數的清單不包含 `–env-blacklist` 參數中列出的變數，或以 `PCLUSTER_*`或 `AWS_*`字首開頭的變數。
**-eb *ENV\$1DENYLIST*, --env-blacklist *ENV\$1DENYLIST***
指定以逗號分隔的清單，其中列出**不**匯出至任務環境的環境變數名稱。根據預設，不會匯出 `HOME`、`PWD`、`USER`、`PATH`、`LD_LIBRARY_PATH`、`TERM` 和 `TERMCAP`。
**-r *RETRY\$1ATTEMPTS*, --retry-attempts *RETRY\$1ATTEMPTS***
指定將任務移至 `RUNNABLE` 狀態的次數。您可以指定嘗試 1 至 10 次。如果嘗試的值大於 1，則會在任務失敗時重試，直到其移至指定次數`RUNNABLE`的狀態為止。
預設：1
**-t *TIMEOUT*, --timeout *TIMEOUT***
以秒為單位指定持續時間 （從任務嘗試的`startedAt`時間戳記測量），之後如果任務尚未完成，則 會 AWS Batch 終止任務。逾時值必須至少為 60 秒。
**-n *NODES*, --nodes *NODES***
指定要為任務保留的節點數目。指定此參數的值，以啟用多節點平行提交。
當 [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler) / [`AwsBatchQueues`](Scheduling-v3.md#Scheduling-v3-AwsBatchQueues) / [`CapacityType`](Scheduling-v3.md#yaml-Scheduling-AwsBatchQueues-CapacityType) 參數設定為 時`SPOT`，*不支援*多節點平行任務。此外，您的帳戶中必須有`AWSServiceRoleForEC2Spot`服務連結角色。您可以使用下列 AWS CLI 命令建立此角色：
```
$ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com
```
如需詳細資訊，請參閱《*Amazon Elastic Compute Cloud Linux *[執行個體使用者指南》中的 Spot 執行個體請求的服務連結角色](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests)。
**-a *ARRAY\$1SIZE*, --array-size *ARRAY\$1SIZE***
指出陣列的大小。您可指定介於 2 到 10,000 之間的值。如果您對任務指定陣列屬性，它會變成陣列任務。
**-d *DEPENDS\$1ON*, --depends-on *DEPENDS\$1ON***
指定以分號分隔的清單，其中列出任務的相依性。一個任務可以取決於最多 20 個任務。您可以指定`SEQUENTIAL`類型相依性，而無需指定陣列任務的任務 ID。序列相依性允許每個子陣列任務循序完成，從索引 0 開始。您也可以指定 N\$1TO\$1N 類型相依性，以及陣列任務的任務 ID。N\$1TO\$1N 相依性表示，此任務的每個索引子系必須等待各相依性對應的索引子系完成後，才能開始。此參數的語法為 "jobId=**，type=**；..."。
# `awsbstat`
顯示在叢集的任務佇列中提交的任務。
```
awsbstat [-h] [-c CLUSTER] [-s STATUS] [-e] [-d] [job_ids [job_ids ...]]
```
## 定位引數
***job\$1ids***
指定以空格分隔的清單，其中列出要在輸出中顯示的任務 ID。如果該任務為任務陣列，則會顯示所有子任務。如果請求單一任務，則會以詳細版本顯示它。
## 具名引數
**-c *CLUSTER*, --cluster *CLUSTER***
指出要使用的叢集。
**-s *STATUS*, --status *STATUS***
指定以逗號分隔的清單，其中列出要包含的任務狀態。預設任務狀態為「作用中」。可接受的值為：`SUBMITTED`、`PENDING`、`RUNNABLE`、`STARTING`、`RUNNING`、`SUCCEEDED`、`FAILED` 和 `ALL`。
預設：“`SUBMITTED`,`PENDING`,`RUNNABLE`,`STARTING`,`RUNNING`”
**-e, --expand-children**
展開具有子項 (陣列和多節點平行) 的任務。
預設：False
**-d, --details**
顯示任務詳細資訊。
預設：False
# `awsbout`
顯示特定任務的輸出。
```
awsbout [-h] [-c CLUSTER] [-hd HEAD] [-t TAIL] [-s] [-sp STREAM_PERIOD] job_id
```
## 定位引數
***job\$1id***
指定任務 ID。
## 具名引數
**-c *CLUSTER*, --cluster *CLUSTER***
指出要使用的叢集。
**-hd *HEAD*, --head *HEAD***
取得任務輸出的第一個 *HEAD* 行。
**-t *TAIL*, --tail *TAIL***
取得任務輸出的最後一個 行。
**-s, --stream**
取得任務輸出，然後等待產生額外的輸出。此引數可與 –tail 搭配使用，從任務輸出的最新 行開始。
預設：False
**-sp *STREAM\$1PERIOD*, --stream-period *STREAM\$1PERIOD***
設定串流期間。
預設：5
# `awsbkill`
取消或終止叢集中提交的任務。
```
awsbkill [-h] [-c CLUSTER] [-r REASON] job_ids [job_ids ... ]
```
## 定位引數
***job\$1ids***
指定以空格分隔的清單，其中列出要取消或終止的任務 ID。
## 具名引數
**-c *CLUSTER*, --cluster *CLUSTER***
指出要使用的叢集名稱。
**-r *REASON*, --reason *REASON***
指出要附加至任務的訊息，說明任務取消的原因。
預設：”Terminated by the user”
# `awsbqueues`
顯示與叢集相關聯的任務佇列。
```
awsbqueues [-h] [-c CLUSTER] [-d] [job_queues [job_queues ... ]]
```
## 定位引數
***job\$1queues***
指定以空格分隔的清單，其中列出要顯示的佇列名稱。如果請求單一佇列，則會以詳細版本顯示它。
## 具名引數
**-c *CLUSTER*, --cluster *CLUSTER***
指定要使用的叢集名稱。
**-d, --details**
指出是否顯示佇列的詳細資訊。
預設：False
# `awsbhosts`
顯示屬於叢集運算環境的主機。
```
awsbhosts [-h] [-c CLUSTER] [-d] [instance_ids [instance_ids ... ]]
```
## 定位引數
***instance\$1ids***
指定空格分隔的執行個體 ID 清單。如果請求單一執行個體，則會以詳細版本顯示它。
## 具名引數
**-c *CLUSTER*, --cluster *CLUSTER***
指定要使用的叢集名稱。
**-d, --details**
指出是否顯示主機的詳細資訊。
預設：False