翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# でサポートされているスケジューラ AWS ParallelCluster
AWS ParallelCluster は、 [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler) 設定を使用して設定される Slurmおよび ス AWS Batch ケジューラをサポートします。以下のトピックでは、各スケジューラとその使用方法について説明します。
**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`)`、Slurmパーティションに 1:1 をマッピング`(Scheduling/SlurmQueues)`するキューに編成されます。
コンピューティングリソース内では、クラスターで常に実行する必要があるコンピューティングノード (インスタンス) の最小数 (`MinCount`)、およびコンピューティングリソースがスケールできるインスタンスの最大数 ([`MaxCount`3](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)) を設定できます。
クラスターの作成時またはクラスターの更新時に、 はクラスターで定義された各コンピューティングリソース (`Scheduling/SlurmQueues/ ComputeResources`) `MinCount` に対して で設定された数だけ Amazon EC2 インスタンス AWS ParallelCluster を起動します。クラスター内のコンピューティングリソースの最小ノード数をカバーするために起動されたインスタンスは、***静的ノード***と呼ばれます。静的ノードは、起動されるとクラスター内で永続的となり、特定のイベントや条件が発生しない限り、システムによって終了されることはありません。このようなイベントには、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` の変更などが含まれます。 AWS ParallelCluster バージョン 3.9.0 以降では、キューのサイズを小さくするには、クラスターの更新を行う前にコンピューティングフリートを停止するか、[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` より大きい場合 (静的容量と動的容量の混合) の 2 つの異なるシナリオを区別できます。
### 静的ノードのみの容量変更
+ `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]
```
+ 更新 (`-30`) を適用した `MinCount` および `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--]`)。システムは対応する数の 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]
```
これにより、Slurm 予約が `maint_for_update` という名前でノード `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)`
+ 更新された Slurm パーティション設定を AWS ParallelCluster 設定から生成する
+ `slurmctld` を再起動する (Chef サービスレシピを使用して実行)
+ `slurmctld` のステータスを確認する `(systemctl is-active --quiet slurmctld.service)`
+ Slurm 設定を再ロードする `(scontrol reconfigure)`
+ 起動する: `clustermgtd (supervisorctl start clustermgtd)`
Slurm の詳細については、「[https://slurm.schedmd.com](https://slurm.schedmd.com)」を参照してください。ダウンロードについては、「[https://github.com/SchedMD/slurm/tags](https://github.com/SchedMD/slurm/tags)」を参照してください。ソースコードについては、「[https://github.com/SchedMD/slurm](https://github.com/SchedMD/slurm)」を参照してください。
## サポートされているクラスターと SLURM バージョン
次の表に、 がサポートする AWS AWS ParallelCluster および Slurmのバージョンを示します。
| AWS ParallelCluster バージョン (複数可) | サポートされる 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)
# 複数のキューの設定
AWS ParallelCluster バージョン 3 では、 [`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) の必要に応じてスケールアップまたはスケールダウンされます。
ワークロードが同じ基盤となるインフラストラクチャとリソース (共有ストレージ、ネットワーク、ログインノードなど) を共有する場合、通常、1 つのクラスター内の複数の*キュー*が複数のクラスターよりも優先されます。ワークロードのコンピューティング、ストレージ、ネットワークのニーズが類似している場合、1 つのクラスター内で複数のキューを使用すると、リソース共有が可能になり、不要な重複を回避できるため、効率が向上します。このアプローチは、効率的なジョブスケジューリングとリソース割り当てを可能にしながら、管理を簡素化し、オーバーヘッドを削減します。一方、ワークロード間に強力なセキュリティ、データ、または運用分離要件がある場合は、複数の*クラスター*を使用する必要があります。たとえば、異なるスケジュール、更新サイクル、またはアクセスポリシーでワークロードを個別に管理および運用する必要がある場合は、複数のクラスターが適しています。
**クラスターキューとコンピューティングリソースのクォータ**
| リソース | クォータ |
| --- | --- |
| [`Slurm queues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) | クラスターあたり 50 キュー |
| [`Compute resources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) | 1 キューあたり 50 のコンピューティングリソース 1 クラスターあたり 50 のコンピューティングリソース |
**ノード数**
キュー内の [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) の各コンピューティングリソースには、固有の [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name)、[`InstanceType`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-InstanceType)、[`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)、および [`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](Scheduling-v3.md) セクションの例を次に示します。この設定では、`queue1` および `queue2` という 2 つのキューがあり、それぞれのキューには [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) を指定した [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) があります。
```
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
```
**HostNames**
コンピューティングフリートに起動されるインスタンスは、動的に割り当てられます。各ノードにはホスト名が生成されます。デフォルトでは 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` はノードの番号です。`$NODENUM` は、静的ノードの場合は 1 から [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) までの値、動的ノードの場合は 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 ガイド
ここでは、キュー (パーティション) ノードSlurmの管理 AWS ParallelCluster 方法と、キューとノードの状態をモニタリングする方法について説明します。
## 概要:
スケーリングアーキテクチャは、Slurm の[「Cloud Scheduling Guide」](https://slurm.schedmd.com/elastic_computing.html)(クラウドスケジュールガイド) と省電力プラグインに基づいています。省電力プラグインの詳細については、「[Slurm Power Saving Guide](https://slurm.schedmd.com/power_save.html)」を参照してください。アーキテクチャでは、クラスターで利用できる可能性のあるリソースは、通常、クラウドノードとして Slurm 設定にあらかじめ定義されています。
## クラウドノードのライフサイクル
クラウドノードはそのライフサイクルを通じて、すべてではないが以下のような状態になります。`POWER_SAVING`、`POWER_UP` (`pow_up`)、`ALLOCATED` (`alloc`)、および `POWER_DOWN` (`pow_dn`)。場合によっては、クラウドノードが `OFFLINE` 状態になることがあります。次のリストは、クラウドノードのライフサイクルにおけるこれらの状態のいくつかの側面を詳細に示しています。
+ **`POWER_SAVING` 状態のノード**は、`sinfo` では `~` サフィックス (例: `idle~`) で表示されます。この状態では、ノードをバックアップする EC2 インスタンスは存在しません。ただし、Slurm は引き続きノードにジョブを割り当てることができます。
+ **`POWER_UP` 状態に遷移したノード**は、`sinfo` では `#` サフィックス (例: `idle#`) で表示されます。Slurm が `POWER_SAVING` 状態のノードにジョブを割り当てると、ノードは自動的に `POWER_UP` 状態に遷移します。
`su` ルートユーザーとして次のコマンドを使用し、手動でノードを `POWER_UP` 状態に遷移させることもできます。
```
$ scontrol update nodename=nodename state=power_up
```
この段階で `ResumeProgram` が呼び出され、EC2 インスタンスが起動して構成され、ノードが `POWER_UP` 状態に遷移します。
+ **現在使用可能なノード**は、`sinfo` にサフィックス (例: `idle`) なしで表示されます。ノードのセットアップが完了し、クラスターに参加した後、ジョブの実行が可能になります。この段階で、ノードは適切に設定され、使用可能な状態になります。
原則として、Amazon EC2 インスタンス数は利用可能なノード数と同じにすることを推奨します。通常、静的ノードはクラスター作成後に利用可能です。
+ **`POWER_DOWN` 状態に遷移しているノード**は、`sinfo` に `%` サフィックス (例: `idle%`) で表示されます。動的ノードは [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) の後、自動的に `POWER_DOWN` 状態になります。対照的に、ほとんどの場合、静的ノードの電源はオフになりません。ただし、`su` ルートユーザーとして次のコマンドを使用し、手動でノードを `POWER_DOWN` 状態に配置できます。
```
$ scontrol update nodename=nodename state=down reason="manual draining"
```
この状態では、ノードに関連するインスタンスは終了し、ノードは [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 後に使用可能になるように `POWER_SAVING` 状態に戻されます。
[`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) の設定は、Slurm の設定の `SuspendTimeout` 設定に保存されます。
+ **オフラインのノード**は、`sinfo` に `*` サフィックス (例: `down*`) で表示されます。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` 状態であり、`POWER_SAVING` (デフォルトは 10 分) 後に [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 状態へ遷移します。
他のノードはすべて `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`) の 1 つの静的ノードにジョブを送信します。
```
$ sbatch --wrap "sleep 300" -N 1 -C static
```
`EFA` キューのある動的ノードにジョブを送信します。
```
$ sbatch --wrap "sleep 300" -p efa -C dynamic
```
`ondemand` キューの `c5.2xlarge` ノード 8 台、`t2.xlarge` ノード 2 台にジョブを送信します。
```
$ 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 に従って、 によって完全に管理されます。
ただし、 は、 `DOWN`および `DRAINED`の状態の異常なノードと、異常なバッキングインスタンスを持つノード AWS ParallelCluster も置き換えまたは終了します。詳細については、「[`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) の前に動的ノードの電源を切る**
`su` ルートユーザーとしてコマンドを使用して、動的ノードを `DOWN` に設定することをお勧めします。
```
$ scontrol update nodename=nodename state=down reason="manually draining"
```
AWS ParallelCluster は、ダウンした動的ノードを自動的に終了およびリセットします。
一般的に、`scontrol update nodename=nodename state=power_down` コマンドを使用してノードを直接 `POWER_DOWN` に設定することはお勧めしません。これは、 AWS ParallelCluster が自動的にパワーダウン処理を行うためです。
+ **キュー (パーティション) を無効にするか、特定のパーティションのすべての静的ノードを停止する**
`su` ルートユーザーとしてコマンドを使用して、特定のキューを `INACTIVE` に設定します。
```
$ scontrol update partition=queuename state=inactive
```
この操作により、パーティション内のすべてのインスタンスバッキングノードが終了します。
+ **キュー (パーティション) を有効にする**
`su` ルートユーザーとしてコマンドを使用して、特定のキューを `UP` に設定します。
```
$ scontrol update partition=queuename state=up
```
## スケーリング動作および調整
**ここでは、通常のスケーリングワークフローの例を示します。**
+ スケジューラは、2 つのノードを必要とするジョブを受け取ります。
+ スケジューラは 2 つのノードを `POWER_UP` 状態に遷移させ、ノード名 (例: `queue1-dy-spotcompute1-[1-2]`) で `ResumeProgram` を呼び出す。
+ `ResumeProgram` は Amazon EC2 インスタンスを 2 つ起動し、`queue1-dy-spotcompute1-[1-2]` のプライベート IP アドレスとホストネームを割り当て、`ResumeTimeout` (デフォルトの期間は 30 分) を待ってからノードをリセットします。
+ インスタンスが設定され、クラスターに参加します。インスタンスでジョブの実行を開始します。
+ ジョブは完了し、実行は停止します。
+ 設定された `SuspendTime` が経過した後 ([`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) に設定されています)、スケジューラはインスタンスを `POWER_SAVING` 状態に設定します。次に、スケジューラは `queue1-dy-spotcompute1-[1-2]` を `POWER_DOWN` 状態に設定し、ノード名で `SuspendProgram` を呼び出します。
+ `SuspendProgram` は 2 つのノードに対して呼び出されます。ノードは、例えば `SuspendTimeout` のために `idle%` を維持することで、`POWER_DOWN` 状態を維持します (デフォルトの期間は 120 秒 (2 分))。`clustermgtd` は、ノードがパワーダウンしていることを検出した後、バッキングインスタンスを終了します。次に、`queue1-dy-spotcompute1-[1-2]` はアイドル状態に遷移し、プライベート IP アドレスとホスト名はリセットされ、今後のジョブに備えて電源を入れる準備をします。
**処理がうまくいかず、何らかの理由で特定のノードのインスタンスが起動できない場合、次のようなことが起こります。**
+ スケジューラが、2 つのノードを必要とするジョブを受け取る。
+ スケジューラが 2 つのクラウドでのバーストノードを `POWER_UP` 状態に遷移させ、ノード名 (例: `queue1-dy-spotcompute1-[1-2]`) で `ResumeProgram` を呼び出す。
+ `ResumeProgram` は 1 つの Amazon EC2 インスタンスだけを起動して `queue1-dy-spotcompute1-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 分))。その間、ジョブは再キューされ、別のノードで実行を開始することができます。
+ 上記のプロセスが、使用可能なノードで障害が発生せずにジョブを実行できるようになるまで繰り返される。
**必要に応じて調整可能な 2 つのタイミングパラメータがあります。**
+ **`ResumeTimeout` (デフォルトは 30 分)**: `ResumeTimeout` は、ノードがダウン状態に遷移するまで Slurm が待機する時間を制御します。
+ インストール前後の処理に時間がかかる場合は、`ResumeTimeout` を拡張するのも有効です。
+ `ResumeTimeout` は、また、問題が発生した場合にノードを交換またはリセットするまでに、 AWS ParallelCluster が待機する最大時間です。コンピューティングノードは、起動またはセットアップ中にエラーが発生した場合に自己終了します。 AWS ParallelCluster プロセスは、終了したインスタンスの検出時にノードを置き換えます。
+ **`SuspendTimeout` (デフォルトは 120 秒 (2 分))**: `SuspendTimeout` は、ノードがシステムに戻され、再び使用できるようになるまでの時間を制御します。
+ `SuspendTimeout` が短いと、ノードのリセットが早くなり、Slurm はより頻繁にインスタンスの起動を試みることができます。
+ `SuspendTimeout` が長いと、故障したノードのリセットが遅くなります。その間、Slurm は他のノードの使用を試みます。`SuspendTimeout` が数分以上であれば、Slurm はシステム内の全ノードの循環を試みます。1,000 ノード以上の大規模システムでは、失敗したジョブを頻繁に再キューする場合に Slurm のストレスを軽減するために、より長い `SuspendTimeout` が有効である場合があります。
+ `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、SDK などのツールを使用して、そのインスタンスのステータスまたはログを確認します。例えば、インスタンスにスケジュールされたイベントがあったかどうか、Amazon EC2 ヘルスステータスのチェックに失敗したかどうかを確認できます。
+ `clustermgtd` がノードを終了させなかった場合、`computemgtd` がノードを終了させたか、EC2 がスポットインスタンスを再要求するためにインスタンスを終了させたかどうかを確認します。
+ ノードの障害。
+ 通常、ノードに障害が発生した場合、ジョブは自動的に再キューされます。`slurmctld` ログを見て、ジョブやノードがなぜ失敗したかを確認し、そこから状況を評価します。
**インスタンスの置換やターミネーション時の障害、ノードのパワーダウン時の障害**
+ 一般に、`clustermgtd` は期待されるすべてのインスタンス終了アクションを処理します。`clustermgtd` ログを見て、ノードの置換または終了に失敗した理由を確認する。
+ [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) に失敗した動的ノードの場合、`SuspendProgram` のログから、`slurmctld` プロセスが特定のノードを引数にした呼び出しを行ったかどうかを確認します。`SuspendProgram` は実際に特定のアクションを実行するわけではありません。呼び出されたときだけログに記録されます。すべてのインスタンスの終了と `NodeAddr` リセットは `clustermgtd` により完了します。Slurm は `SuspendTimeout` の後、ノードを `IDLE` に遷移させます。
**その他の問題:**
+ AWS ParallelCluster はジョブの割り当てやスケーリングの決定を行いません。Slurm の指示に従い、リソースを起動、終了、維持を試みるだけです。
ジョブの割り当て、ノードの割り当て、スケーリングの決定に関する問題については、`slurmctld` ログを見てエラーを確認します。
# Slurm クラスター保護モード
保護モードを有効にしてクラスターを実行すると、 はコンピューティングノードの起動時にコンピューティングノードのブートストラップ障害 AWS ParallelCluster を監視および追跡します。これは、これらの障害が継続的に発生しているかどうかを検出するために行われます。
キュー (パーティション) で以下が検出されると、クラスターは保護ステータスになります。
1. コンピューティングノードが正常に起動せず、コンピューティングノードのブートストラップ障害が連続して発生する。
1. 障害カウントが事前に定義されたしきい値に達した。
クラスターが保護ステータスになると、 は、事前定義されたしきい値以上で障害が発生したキューを AWS ParallelCluster 無効にします。
Slurm クラスター保護モードが AWS ParallelCluster バージョン 3.0.0 に追加されました。
保護モードを使用すると、コンピューティングノードのブートストラップ障害サイクルに費やす時間とリソースを削減できます。
## 保護モードパラメータ
**`protected_failure_count`**
`protected_failure_count` は、クラスターの保護ステータスを有効にするキュー (パーティション) の連続した障害の数を指定します。
デフォルトの `protected_failure_count` は 10 で、保護モードは有効になっています。
`protected_failure_count` が 0 より大きい場合、保護モードは有効になります。
`protected_failure_count` が 0 以下の場合、保護モードは無効になります。
`protected_failure_count` の値は、`HeadNode` の `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf` にある `clustermgtd` 設定ファイルにパラメータを追加することで変更できます。
このパラメータはいつでも更新でき、そのためにコンピューティングフリートを停止する必要はありません。障害カウントが `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]
```
コンピューティングノードのブートストラップ障害が 10 回連続で検出されたため、パーティション `queue1` は `INACTIVE` になりました。
ノード `queue1-dy-c5xlarge-[1-10]` の背後にあるインスタンスは起動しましたが、異常状態のためクラスターに参加できませんでした。
クラスターは保護ステータスです。
パーティション `queue2` は、`queue1` のブートストラップ障害の影響を受けていません。`UP` 状態であり、まだジョブを実行することができます。
## 保護ステータスを非アクティブ化する方法
ブートストラップエラーが解決されたら、以下のコマンドを実行してクラスターを保護ステータスから解除できます。
```
$ pcluster update-compute-fleet --cluster-name \
--region \
--status START_REQUESTED
```
## 保護ステータスをアクティブ化するブートストラップ障害
保護ステータスをアクティブ化するブートストラップエラーは、次の 3 つのタイプに分割されます。タイプと問題を特定するには、ログが AWS ParallelCluster 生成されたかどうかを確認します。ログが生成された場合は、そのログでエラーの詳細を確認できます。詳細については、「[ログの取得と保存](troubleshooting-v3-get-logs.md)」を参照してください。
1. **インスタンスが自己終了する原因となるブートストラップエラー**
インスタンスが [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)/[`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart)/[`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 の登録に失敗します**。
`slurmd` デーモンと Slurm コントロールデーモン (`slurmctld`) の登録が失敗し、コンピューティングノードの状態が `INVALID_REG` 状態に変更します。[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings) コンピューティングノードの仕様エラーで設定されたコンピューティングノードなど、間違えて設定された Slurm コンピューティングノードによって、このエラーが発生する可能性があります。
ヘッドノードの `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` ログ (`/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` ログ (`/var/log/cloud-init-output.log`)**
`clustermgtd` ログでブートストラップ障害ノードのプライベート IP アドレスを取得したら、コンピューティングノードにログインするか、[ログの取得と保存](troubleshooting-v3-get-logs.md) のガイダンスに従ってログを取得することで、対応するコンピューティングノードのログを確認することができます。ほとんどの場合、問題のあるノードの `/var/log/cloud-init-output` ログには、コンピューティングノードのブートストラップ障害の原因となった手順が示されています。
# Slurm クラスタ高速容量不足フェイルオーバー
AWS ParallelCluster バージョン 3.2.0 以降、クラスターは高速容量不足フェイルオーバーモードがデフォルトで有効になっている状態で実行されます。これにより、Amazon EC2 の容量不足エラーが検出されたときに、ジョブのキューイングの再試行時間を最小限に抑えることができます。これは、異なるインスタンスタイプを使用する複数のコンピューティングリソースでキューを設定する場合に特に効果的です。
**Amazon EC2 が検出する容量不足エラー：**
+ `InsufficientInstanceCapacity`
+ `InsufficientHostCapacity`
+ `InsufficientReservedInstanceCapacity`
+ `MaxSpotInstanceCountExceeded`
+ `SpotMaxPriceTooLow`: 設定したスポットリクエスト料金が、スポットリクエストに最低限必要な料金を下回る場合、有効化します。
+ `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. ジョブを別のコンピューティングリソースに再キューします。
無効化されたコンピューティングリソースの静的なノードや電源が入っているノードには影響しません。ジョブはこれらのノードで完了できます。
このサイクルは、ジョブが 1 つまたは複数のコンピューティングリソースノードに正常に割り当てられるまで繰り返されます。ノードの状態についての詳細は、「[マルチキューモードの Slurm ガイド](multiple-queue-mode-slurm-user-guide-v3.md)」を参照してください。
ジョブを実行するコンピューティングリソースが見つからない場合、ジョブはあらかじめ定義された期間が経過するまで `PENDING` の状態に設定されます。この場合、次のセクションで説明するように、定義済みの期間を変更できます。
## 容量不足のタイムアウトパラメータ
**`insufficient_capacity_timeout`**
`insufficient_capacity_timeout` では、容量不足エラーが検出されたときに、コンピューティングリソースが無効 (`down`) 状態に保たれる時間 (秒) が指定されます。
デフォルトでは、`insufficient_capacity_timeout` は有効です。
デフォルトは 600 秒 (10 分) です。
`insufficient_capacity_timeout` の値が 0 以下の場合、高速容量不足フェイルオーバーモードは無効になります。
`insufficient_capacity_timeout` の値は、`HeadNode` の `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf`にある `clustermgtd` 設定ファイルにパラメータを追加することで変更できます。
このパラメータは、コンピューティングフリートを停止せずにいつでも更新できます。
例えば、次のようになります。
+ `insufficient_capacity_timeout=600`:
容量不足エラーが検出されると、コンピューティングリソースは無効 (`DOWN`) に設定されます。10 分後、障害が発生したノードは `idle~` (`POWER_SAVING`) 状態に設定されます。
+ `insufficient_capacity_timeout=60`:
容量不足エラーが検出されると、コンピューティングリソースは無効になります (`DOWN`)。1 分後、障害が発生したノードは `idle~` の状態に設定されます。
+ `insufficient_capacity_timeout=0`:
高速容量不足フェイルオーバーモードは無効になります。コンピューティングリソースは無効になりません。
**注記**
容量不足エラーでノードに障害が発生してから、クラスター管理デーモンがノード障害を検出するまでの間には、最大 1 分の遅延が発生する可能性があります。これは、クラスター管理デーモンがノードの容量不足の障害をチェックし、コンピューティングリソースを 1 分間隔で `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]
```
1 つのノードを必要とするジョブを 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 以降、 は / [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings) [`EnableMemoryBasedScheduling`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-EnableMemoryBasedScheduling)クラスター設定パラメータを使用したSlurmメモリベースのスケジューリング AWS ParallelCluster をサポートしています。
**注記**
AWS ParallelCluster バージョン 3.7.0 以降では、インスタンスで[複数のインスタンスタイプを設定すると、 ](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)を有効に`EnableMemoryBasedScheduling`できます。
AWS ParallelCluster バージョン 3.2.0 から 3.6.*x* では、インスタンスで[複数のインスタンスタイプを設定した場合、 ](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)を有効にする`EnableMemoryBasedScheduling`ことはできません。
**警告**
`EnableMemoryBasedScheduling` が有効になっている Slurm キューコンピューティングリソースで複数のインスタンスタイプを指定すると、`RealMemory` の値はすべてのインスタンスタイプで使用できる最小メモリ量になります。これにより、メモリ容量が大きく異なるインスタンスタイプを指定すると、大量の未使用メモリが発生する可能性があります。
`EnableMemoryBasedScheduling: true` では、Slurm スケジューラは各ジョブが各ノードで必要とするメモリ量を追跡します。次に、Slurm スケジューラはこの情報を使用して、同じコンピューティングノード上の複数のジョブをスケジュールします。ノード上でジョブが必要とするメモリの合計量は、使用可能なノードメモリを超えることはできません。スケジューラは、ジョブが、ジョブ送信時に要求された量よりも多くのメモリを使用するのを防ぎます。
`EnableMemoryBasedScheduling: false` を使用すると、ジョブが共有ノード上のメモリを奪い合い、ジョブの失敗や `out-of-memory` のイベントが発生する可能性があります。
**警告**
Slurm ラベルには MB や GB などの 2 のべき乗表記を使用します。これらのラベルをそれぞれ 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 で消費可能なリソースとして設定します。
+ Slurm `cgroup.conf` の[https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace](https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace)。このオプションでは、ジョブのメモリへのアクセスは、ジョブが送信時に要求したメモリ量に制限されます。
**注記**
これら 2 つのオプションを設定すると、Slurm スケジューラとリソースマネージャの動作に影響する Slurm 設定パラメータが他にもいくつかあります。詳細については、[Slurm のドキュメント](https://slurm.schedmd.com/documentation.html) を参照してください。
## Slurm スケジューラとメモリベースのスケジューリング
**`EnableMemoryBasedScheduling: false` (デフォルト)**
デフォルトで `EnableMemoryBasedScheduling` は false に設定されます。false の場合、Slurm はスケジューリングアルゴリズムにメモリをリソースとして含めず、ジョブが使用するメモリも追跡しません。ユーザーは、ジョブに必要なノードあたりの最小メモリ量を設定する `--mem MEM_PER_NODE` オプションを指定できます。これにより、スケジューラはジョブをスケジューリングするときに、`RealMemory` 値が少なくとも `MEM_PER_NODE` のノードを選択する必要があります。
例えば、ユーザーが `--mem=5GB` のジョブを 2 つ送信したとします。CPU や GPU などの要求されたリソースが使用可能な場合、ジョブは 8 GiB のメモリのノードで同時に実行できます。この 2 つのジョブは、`RealMemory` が 5 GiB 未満のコンピューティングノードではスケジュールされません。
**警告**
メモリベースのスケジューリングが無効になっている場合、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` のジョブを 2 つ送信します。メモリが 8 GiB のノードでは、ジョブを同時に実行することはできません。これは、必要なメモリの合計量がノードで使用可能なメモリ量よりも多いためです。
メモリベースのスケジューリングが有効になっている場合は、`--mem-per-cpu` と `--mem-per-gpu` は「Slurm documentation」に記載されている内容と一貫した動作をします。例えば、ジョブは `--ntasks-per-node=2 -c 1 --mem-per-cpu=2GB` で送信されます。この場合、Slurm はジョブに合計 4 GiB をノードごとに割り当てます。
**警告**
メモリベースのスケジューリングが有効になっている場合は、ジョブを送信する際に `--mem` 仕様を含めることをお勧めします。に含まれているSlurmデフォルト設定では AWS ParallelCluster、メモリオプション (`--mem`、、または `--mem-per-gpu`) が含まれていない場合`--mem-per-cpu`、 CPUs は CPU や GPU などの他のリソースの一部のみをリクエストしても、割り当てられたノードのメモリ全体をジョブにSlurm割り当てます。 GPUs これにより、他のジョブに使用できるメモリがなくなるため、ジョブが終了するまでノードを共有できなくなります。これは、ジョブの送信時にメモリ仕様が提供されていないとき、Slurm がジョブのノードあたりのメモリを [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode) に設定するためです。このパラメータのデフォルト値は 0 で、ノードのメモリに無制限にアクセスできるようになっています。
メモリ量の異なる複数のタイプのコンピューティングリソースが同じキューにある場合、メモリオプションなしで送信されたジョブには、異なるノードに異なる量のメモリが割り当てられる可能性があります。これは、スケジューラがどのノードをジョブに使用できるようにするかによって異なります。ユーザーは、Slurm 設定ファイルのクラスターまたはパーティションレベルで、`DefMemPerNode` や [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU) のようなオプションのカスタム値を定義して、この動作を防ぐことができます。
## Slurm RealMemory と AWS ParallelCluster SchedulableMemory
に同梱されているSlurm設定では AWS ParallelCluster、 Slurm は [RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory) をジョブで使用できるノードあたりのメモリ量として解釈します。バージョン 3.2.0 以降、デフォルトでは、 `RealMemory`は [Amazon EC2 インスタンスタイプ](https://aws.amazon.com/ec2/instance-types)にリストされ、Amazon EC2 API [DescribeInstanceTypes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTypes.html) によって返されるメモリの 95% AWS ParallelCluster に設定します。
メモリベースのスケジューリングが無効な場合、`--mem` を指定したジョブをユーザーが送信すると、Slurm スケジューラは `RealMemory` を使用しノードをフィルタリングします。
メモリーベースのスケジューリングが有効な場合、Slurm スケジューラは `RealMemory` をコンピューティングノード上で実行中のジョブに使用可能な最大メモリー容量と解釈します。
デフォルト設定は、すべてのインスタンスタイプに最適であるとは限りません。
+ この設定は、ノードが実際にアクセスできるメモリ量よりも多い場合があります。これは、コンピューティングノードが小さいインスタンスタイプである場合に発生する可能性があります。
+ この設定は、ノードが実際にアクセスできるメモリ量よりも少ない場合があります。これは、コンピューティングノードが大きいインスタンスタイプの場合に発生し、大量のメモリが未使用のままになる可能性があります。
[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) /[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/ を使用して、コンピューティングノード AWS ParallelCluster 用に によって`RealMemory`設定された の値を[`SchedulableMemory`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-SchedulableMemory)微調整できます。デフォルトをオーバーライドするには、クラスター設定専用に `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 による複数のインスタンスタイプの割り当て
AWS ParallelCluster バージョン 3.3.0 以降では、コンピューティングリソースの定義されたインスタンスタイプのセットから を割り当てるようにクラスターを設定できます。割り当ては、Amazon EC2 Fleet の低コスト戦略や最適容量戦略に基づいて行うことができます。
この定義済みのインスタンスタイプセットは、すべて同じ数の vCPU を備えているか、マルチスレッドが無効な場合は同じ数のコアを備えている必要があります。さらに、このインスタンスタイプセットには、同じ製造元の同じ数のアクセラレータが必要です。[`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)」を参照してください。
[CapacityType](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CapacityType) の設定に応じて、[`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy) を `lowest-price` または `capacity-optimized` に設定できます。
[`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances) では、一連のインスタンスタイプを設定できます。
**注記**
AWS ParallelCluster バージョン 3.7.0 以降では、インスタンスで[複数のインスタンスタイプを設定すると、 ](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)を有効に`EnableMemoryBasedScheduling`できます。
AWS ParallelCluster バージョン 3.2.0 から 3.6.*x* では、インスタンスで[複数のインスタンスタイプを設定した場合、 ](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)を有効にする`EnableMemoryBasedScheduling`ことはできません。
以下の例では、vCPUs、EFA サポート、アーキテクチャのインスタンスタイプをクエリする方法を示しています。
96 個の vCPU と x86\$164 アーキテクチャで InstanceTypes をクエリする。
```
$ 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
```
64 コア、EFA サポート、arm64 アーキテクチャで、InstanceTypes をクエリする。
```
$ 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**
+ [バージョン 3.8.0 の Slurm 動的ノード割り当て戦略](scheduler-node-allocation-v3-3.8.0.md)
+ [バージョン 3.7.x での Slurm 動的ノード割り当て戦略](scheduler-dynamic-node-allocation-v3-3.7.x.md)
+ [バージョン 3.6.x 以前での Slurm 動的ノード割り当て戦略](scheduler-dynamic-node-allocation-v3-3.6.x.md)
# バージョン 3.8.0 の Slurm 動的ノード割り当て戦略
ParallelCluster は、バージョン 3.8.0 以降、**ジョブレベルの再開**または**ジョブレベルのスケーリング**をデフォルトの動的ノード割り当て戦略として使用してクラスターをスケールします。ParallelCluster は、各ジョブの要件、ジョブに割り当てられたノードの数、再開する必要があるノードに基づいてクラスターをスケールアップします。ParallelCluster は、この情報を SLURM\$1RESUME\$1FILE 環境変数から取得します。
動的ノードのスケーリングプロセスは、Amazon EC2 インスタンスを起動するステップと、起動した EC2 インスタンスを Slurm ノードに割り当てるステップの 2 つで構成されます。これら 2 つのステップは、どちらも**オールオアナッシング**ロジックまたは**ベストエフォート**ロジックを使用して実行できます。
Amazon EC2 インスタンスを起動する場合:
+ **オールオアナッシング**では、最小ターゲット容量が合計ターゲット容量に等しい場合に Amazon EC2 API を起動します。
+ **ベストエフォート**では、最小ターゲット容量が 1 に等しく、合計ターゲット容量がリクエスト容量に等しい場合に Amazon EC2 API を起動します。
Amazon EC2 インスタンスを Slurm ノードに割り当てる場合:
+ **オールオアナッシング**では、リクエストされたすべての Slurm ノードに Amazon EC2 インスタンスを割り当てることができる場合にのみ、Amazon EC2 インスタンスをノードに割り当てます。
+ **ベストエフォート**では、リクエストされたすべての Slurm ノードを Amazon EC2 インスタンス容量でカバーできない場合でも、Amazon EC2 インスタンスをノードに割り当てます。
上の戦略の可能な組み合わせが、ParallelCluster の起動戦略になります。
**Example** [ ScalingStrategy](Scheduling-v3.md#yaml-Scheduling-ScalingStrategy)
**オールオアナッシング**のスケーリング:
この戦略では、ジョブごとに Amazon EC2 起動インスタンス API コール AWS ParallelCluster を開始し、リクエストされたコンピューティングノードが正常に起動するために必要なすべてのインスタンスが必要です。ジョブごとの必要な容量が利用可能な場合にのみクラスターがスケールするため、スケーリングプロセスの最後にアイドルインスタンスが残ることはありません。
この戦略では、ジョブごとに Amazon EC2 インスタンスを起動するのに**オールオアナッシング**ロジックを使用するとともに、Amazon EC2 インスタンスを Slurm ノードに割り当てるのにも**オールオアナッシング**ロジックを使用します。
戦略グループは、リクエストをバッチにまとめて起動します。リクエストされたコンピューティングリソースごとに 1 つのバッチを使用し、バッチごとのノード数は最大 500 です。リクエストが複数のコンピューティングリソースにまたがる場合や、500 ノードを超える場合、ParallelCluster は複数のバッチを使用して順次処理します。
いずれかのリソースのバッチに障害が発生すると、すべての関連する未使用の容量が終了するため、スケーリングプロセスの終了時にアイドルインスタンスは残りません。
制限事項
+ スケーリングにかかる時間は、Slurm 再開プログラムの実行ごとに送信されるジョブの数に正比例します。
+ スケーリングオペレーションは、デフォルトで 1,000 インスタンスに設定されている、RunInstances リソースアカウントの上限によって制限されます。この制限は、 AWSの EC2 API スロットリングポリシーに準拠しています。詳細については、[Amazon EC2 API スロットリングドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html)」を参照してください。
+ 単一のインスタンスタイプを持つコンピューティングリソースのジョブを、複数のアベイラビリティーゾーンにまたがるキューに送信する場合、**オールオアナッシング**の EC2 起動 API コールは、すべての容量を単一のアベイラビリティーゾーンで提供できる場合にのみ成功します。
+ 複数のインスタンスタイプを持つコンピューティングリソースのジョブを、単一のアベイラビリティーゾーンのキューに送信する場合、**オールオアナッシング**の Amazon EC2 起動 API コールは、すべての容量を単一のインスタンスタイプで提供できる場合にのみ成功します。
+ 複数のインスタンスタイプを持つコンピューティングリソースのジョブを、複数のアベイラビリティーゾーンにまたがるキューに送信する場合、**オールオアナッシング**の Amazon EC2 起動 API コールはサポートされず、ParallelCluster は代わりに**ベストエフォート**のスケーリングを実行します。
**貪欲なオールオアナッシング**のスケーリング:
このオールオアノッシング戦略のバリアントは、ジョブごとの必要な容量が利用可能な場合にのみクラスターをスケールし、スケーリングプロセスの最後にアイドルインスタンスが残らないようにする点は同じですが、ParallelCluster が開始する Amazon EC2 起動インスタンス API コールでは、最小ターゲット容量を 1 とし、リクエストされた容量までノードの起動数を最大化しようとします。この戦略では、すべてのジョブで EC2 インスタンスを起動するためにベストエフォートロジックを使用するとともに、ジョブごとに Amazon EC2 インスタンスを Slurm ノードに割り当てるためにも**オールオアノッシング**ロジックを使用します。
戦略グループは、リクエストをバッチにまとめて起動します。リクエストされたコンピューティングリソースごとに 1 つのバッチを使用し、バッチごとのノード数は最大 500 です。複数のコンピューティングリソースにまたがるリクエスト、または 500 ノードを超えるリクエストの場合、ParellelCluster は複数のバッチを順次処理します。
これにより、スケーリングプロセス中に一時的なオーバースケーリングが発生してもスループットを最大化することで、スケーリングプロセスの最後にアイドルインスタンスが残らないようにします。
制限事項
+ 一時的なオーバースケーリングが発生し、スケーリングの完了前にインスタンスが実行中の状態に移行した場合は追加コストが発生することがあります。
+ all-or-nothing戦略と同じインスタンス制限が適用されます。ただし、 AWSの RunInstances リソースアカウント制限が適用されます。
**ベストエフォート**のスケーリング:
この戦略で開始する Amazon EC2 起動インスタンス API コールでは、最小容量を 1 とし、リクエストされた容量のすべてには対応できずにアイドルインスタンスがスケーリングプロセスの実行後に残るとしても、リクエストされた合計容量を達成しようとします。この戦略では、すべてのジョブで Amazon EC2 インスタンスを起動するためにベストエフォートロジックを使用するとともに、ジョブごとに Amazon EC2 インスタンスを Slurm ノードに割り当てるためにも**ベストエフォート**ロジックを使用します。
戦略グループは、リクエストをバッチにまとめて起動します。リクエストされたコンピューティングリソースごとに 1 つのバッチを使用し、バッチごとのノード数は最大 500 です。リクエストが複数のコンピューティングリソースにまたがる場合や、500 ノードを超える場合、ParallelCluster は複数のバッチを使用して順次処理します。
この戦略では、さまざまなスケーリングプロセスでアイドルインスタンスが発生するとしても、複数のスケーリングプロセスの実行に対するデフォルトの 1,000 インスタンスの制限をはるかに超えてスケーリングできます。
制限事項
+ ジョブがリクエストしているノードの一部を割り当てることができない場合、スケーリングプロセスの最後にアイドル状態のインスタンスが発生する可能性があります。
**ParallelCluster 起動戦略**別に動的ノードのスケーリングがどのように動作するかについて、以下に例を示します。2 つのジョブを送信し、同じタイプのノードをそれぞれ 20 個、合計 40 個リクエストしたとします。しかし、リクエストした容量をカバーするために EC2 で利用できる Amazon EC2 インスタンスは 30 個のみです。
**オールオアナッシング**のスケーリング:
+ 最初のジョブでは、**オールオアナッシング**の Amazon EC2 起動インスタンス API を呼び出し、20 個のインスタンスをリクエストします。呼び出しは成功して、20 個のインスタンスが起動します。
+ 最初のジョブでは、起動した 20 個のインスタンスを Slurm ノードに割り当てる**オールオアナッシング**ロジックも成功します。
+ 2 番目のジョブで、別の**オールオアナッシング**の Amazon EC2 起動インスタンス API を呼び出し、20 個のインスタンスをリクエストします。10 個のインスタンスの容量しか残っていないため、この呼び出しは失敗します。この時点ではインスタンスは起動されません
**貪欲なオールオアナッシング**のスケーリング:
+ **ベストエフォート**の Amazon EC2 起動インスタンス API を呼び出し、40 個のインスタンスをリクエストします。これは、すべてのジョブがリクエストしている合計容量です。結果として、30 個のインスタンスが起動します。
+ 最初のジョブで、起動したインスタンスのうち 20 個を Slurm ノードに割り当てる**オールオアナッシング**ロジックは成功します。
+ 2 番目のジョブでは、起動した残りのインスタンスを Slurm ノードに割り当てる別の**オールオアナッシング**ロジックを試行しますが、ジョブがリクエストしている合計 20 個に対して利用可能なインスタンスは 10 個しかないため、割り当ては失敗します。
+ 割り当てられない 10 個の起動済みインスタンスは終了します。
**ベストエフォート**のスケーリング:
+ **ベストエフォート**の Amazon EC2 起動インスタンス API を呼び出し、40 個のインスタンスをリクエストします。これは、すべてのジョブがリクエストしている合計容量です。結果として、30 個のインスタンスが起動します。
+ 最初のジョブで、起動した 20 個のインスタンスを Slurm ノードに割り当てる**ベストエフォート**ロジックが成功します。
+ 2 番目のジョブで、起動した残りの 10 個のインスタンスを Slurm ノードに割り当てる別の**ベストエフォート**ロジックは、リクエストされた合計容量が 20 個であっても、成功します。ただし、ジョブは 20 個のノードをリクエストしており、そのうちの 10 個のみに Amazon EC2 インスタンスを割り当てることができたため、スケーリングプロセスの今後のコールで欠落している 10 個のインスタンスを起動するのに十分な容量が見つかるか、スケジューラが他の既に実行中のコンピューティングノードでジョブをスケジュールするまで、ジョブは開始できず、インスタンスはアイドル状態のままになります。
# バージョン 3.7.x での Slurm 動的ノード割り当て戦略
ParallelCluster は 次の 2 種類の動的ノード割り当て戦略を使用してクラスターをスケールします。
+
**リクエストされた利用可能なノード情報に基づく割り当て:**
+ **全ノード再開**または**ノードリスト**のスケーリング:
ParallelCluster は、Slurm の `ResumeProgram` の実行時に、Slurm がリクエストしたノードリストの名前のみに基づいてクラスターをスケールアップします。コンピューティングリソースはノード名のみでノードに割り当てられます。ノード名のリストは複数のジョブにまたがる場合があります。
+ **ジョブレベルの再開**または**ジョブレベル**のスケーリング。
ParallelCluster は、各ジョブの要件、ジョブに割り当てられている現在のノード数、再開する必要があるノードに基づいて、クラスターをスケールアップします。ParallelCluster は、この情報を `SLURM_RESUME_FILE` 環境変数から取得します。
+
**Amazon EC2 起動戦略による割り当て:**
+ **ベストエフォート**のスケーリング:
ParallelCluster は、最小ターゲット容量が 1 に等しい Amazon EC2 起動インスタンス API コールを使用してクラスターをスケールアップし、リクエストされたノードをサポートするのに必要なインスタンスのすべてとは言わないまでも一部を起動します。
+ **オールオアナッシング**スケーリング:
ParallelCluster は、リクエストされたノードをサポートするのに必要なすべてのインスタンスが起動された場合にのみ成功する Amazon EC2 起動インスタンス API コールを使用してクラスターをスケールアップします。この場合、最小ターゲット容量がリクエストされた容量の合計に等しい Amazon EC2 起動インスタンス API を呼び出します。
デフォルトでは、ParallelCluster は**ベストエフォート**の Amazon EC2 起動戦略で**ノードリスト**のスケーリングを使用して、リクエストされたノードをサポートするのに必要なインスタンスのすべてとは言わないまでも一部を起動します。送信されたワークロードに対応できるように、できるだけ多くの容量をプロビジョニングしようとします。
ParallelCluster は、バージョン 3.7.0 以降、**排他モード**で送信されたジョブに対し、**オールオアナッシング**の EC2 起動戦略で**ジョブレベル**のスケーリングを採用しています。排他モードでジョブを送信すると、そのジョブは割り当てられたノードに排他的にアクセスできるようになります。詳細については、「Slurm ドキュメント」の「[EXCLUSIVE](https://slurm.schedmd.com/slurm.conf.html#OPT_EXCLUSIVE)」を参照してください。
排他モードでジョブを送信するには。
+ Slurm ジョブをクラスターに送信する際に排他フラグを渡します。例えば、`sbatch ... --exclusive`。
OR
+ [`JobExclusiveAllocation`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-JobExclusiveAllocation) を `true` に設定したクラスターキューにジョブを送信します。
排他モードでジョブを送信する場合。
+ ParallelCluster は、現在、最大 500 個のノードを含むように起動リクエストをバッチ処理します。ジョブが 500 個を超えるノードをリクエストすると、ParallelCluster は 500 個のノードのセットごとに**オールオアナッシング**の起動リクエストを行い、残りのノードに対しては追加の起動リクエストを行います。
+ ノードの割り当てが単一のコンピューティングリソース内で行われる場合、ParallelCluster は 500 個のノードのセットごとに**オールオアナッシング**の起動リクエストを行い、残りのノードに対しては追加の起動リクエストを行います。1 つの起動リクエストが失敗すると、ParallelCluster はすべての起動リクエストによって作成された未使用の容量を終了します。
+ ノードの割り当てが複数のコンピューティングリソースにまたがる場合、ParallelCluster はコンピューティングリソースごとに**オールオアナッシング**の起動リクエストを行う必要があります。これらのリクエストもバッチ処理されます。1 つのコンピューティングリソースの起動リクエストが失敗すると、ParallelCluster はすべてのコンピューティングリソースの起動リクエストによって作成された未使用の容量を終了します。
**オールオアナッシング**の起動戦略を使用した**ジョブレベル**スケーリングの既知の制限事項
+ 単一のインスタンスタイプを持つコンピューティングリソースのジョブを、複数のアベイラビリティーゾーンにまたがるキューに送信する場合、**オールオアナッシング**の EC2 起動 API コールは、すべての容量を単一のアベイラビリティーゾーンで提供できる場合にのみ成功します。
+ 複数のインスタンスタイプを持つコンピューティングリソースのジョブを、単一のアベイラビリティーゾーンのキューに送信する場合、**オールオアナッシング**の Amazon EC2 起動 API コールは、すべての容量を単一のインスタンスタイプで提供できる場合にのみ成功します。
+ 複数のインスタンスタイプを持つコンピューティングリソースのジョブを、複数のアベイラビリティーゾーンにまたがるキューに送信する場合、**オールオアナッシング**の Amazon EC2 起動 API コールはサポートされず、ParallelCluster は代わりに**ベストエフォート**のスケーリングを実行します。
# バージョン 3.6.x 以前での Slurm 動的ノード割り当て戦略
AWS ParallelCluster は、1 種類の動的ノード割り当て戦略のみを使用してクラスターをスケールします。
+ リクエストされた利用可能なノード情報に基づく割り当て:
+ **全ノード再開**または**ノードリスト**のスケーリング: ParallelCluster は、Slurm の `ResumeProgram` の実行時に Slurm のリクエストされたノードリストの名前のみに基づいてクラスターをスケールアップします。コンピューティングリソースはノード名のみでノードに割り当てられます。ノード名のリストは複数のジョブにまたがる場合があります。
+ Amazon EC2 起動戦略による割り当て:
+ **ベストエフォート**のスケーリング: ParallelCluster は、最小ターゲット容量が 1 に等しい Amazon EC2 起動インスタンス API コールを使用してクラスターをスケールアップし、リクエストされたノードをサポートするのに必要なインスタンスのすべてとは言わないまでも一部を起動します。
ParallelCluster は、**ベストエフォート**の Amazon EC2 起動戦略で**ノードリスト**のスケーリングを使用して、リクエストされたノードをサポートするのに必要なインスタンスのすべてとは言わないまでも一部を起動します。送信されたワークロードに対応できるように、できるだけ多くの容量をプロビジョニングしようとします。
制限事項
+ ジョブがリクエストしているノードの一部を割り当てることができない場合、スケーリングプロセスの最後にアイドル状態のインスタンスが発生する可能性があります。
# Slurm による アカウンティング AWS ParallelCluster
バージョン 3.3.0 以降、 はクラスター設定パラメータ [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings) / [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database) によるSlurmアカウンティング AWS ParallelCluster をサポートしています。
バージョン 3.10.0 以降、 はクラスター設定パラメータ [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings) / ExternalSlurmdbd [ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd) でのSlurmアカウンティング AWS ParallelCluster をサポートしています。複数のクラスターが同じデータベースを共有する場合は、外部 Slurmdbd を使用することをお勧めします。
Slurm アカウンティングを使用すると、外部のアカウンティングデータベースを統合して次のことを行うことができます。
+ クラスターユーザーまたはユーザーのグループとその他のエンティティを管理する。この機能を使用すると、リソース制限の適用、公平配分、QOSs など、 Slurmのより高度な機能を使用できます。
+ ジョブを実行したユーザー、ジョブの期間、および使用するリソースなどのジョブデータを収集して保存する。保存したデータは `sacct` ユーティリティを使用して表示できます。
**注記**
AWS ParallelCluster は、[Slurmサポートされている MySQL データベースサーバーの](https://slurm.schedmd.com/accounting.html#mysql-configuration)Slurmアカウンティングをサポートしています。
## v3.10.0 AWS ParallelCluster 以降Slurmdbdで外部 を使用してSlurmアカウンティングを操作する
Slurm アカウンティングを設定する前に、既存の外部データベースサーバーに接続する既存の外部 Slurmdbd データベースサーバーが必要です。
これを設定するには、以下を定義します。
+ [ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)/[Host](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/ja_jp/parallelcluster/latest/ug/images/External_Slurmdbd_Architecture_ASG.png)
**警告**
AWS ParallelCluster と外部との間のトラフィックSlurmDBは暗号化されません。クラスターと外部 SlurmDB は、信頼できるネットワークで実行することをお勧めします。
## v3.3.0 AWS ParallelCluster 以降のヘッドノードを使用したSlurmアカウンティングSlurmdbdの操作
Slurm アカウンティングを設定する前に、既存の外部データベースサーバーと `mysql` プロトコルを使用するデータベースが必要です。
でSlurmアカウンティングを設定するには AWS ParallelCluster、以下を定義する必要があります。
+ [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[Uri](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-Uri) の形式で表す外部データベースサーバーの URI。サーバーが存在し、ヘッドノードから到達できる必要があります。
+ [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn) および [Database](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/ja_jp/parallelcluster/latest/ug/images/slurm-acct-arch.png)
クラスター環境に Slurm カスタムマルチクラスター機能またはフェデレーション機能を追加する場合、すべてのクラスターが同じ `slurmdbd` インスタンスを参照する必要があります。この代替方法として、1 つのクラスターでアカウンティングを有効に 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 のアカウンティングに関する考慮事項
### 異なる VPC のデータベースとクラスター
Slurm のアカウンティングを有効にするには、`slurmdbd` デーモンが実行する読み取り操作と書き込み操作のバックエンドとして機能するデータベースサーバーが必要です。クラスターを作成または更新して Slurm アカウンティングを有効にする前に、ヘッドノードがデータベースサーバーに到達できる必要があります。
クラスターが使用していない VPC にデータベースサーバーをデプロイする必要がある場合は、次の点を考慮します。
+ クラスター側の `slurmdbd` とデータベースサーバー間の通信を有効にするには、2 つの VPC 間の接続を設定する必要があります。詳細については、「Amazon Virtual Private Cloud ユーザーガイド**」の「[VPC ピア機能とは](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)」を参照してください。
+ クラスターの VPC のヘッドノードにアタッチするセキュリティグループを作成する必要があります。2 つの VPC がピアリング接続されると、データベース側とクラスター側のセキュリティグループ間のクロスリンクが使用可能になります。詳細については、「Amazon Virtual Private Cloud ユーザーガイド**」の「[セキュリティグループのルール](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules)」を参照してください。
### `slurmdbd` とデータベースサーバー間の TLS 暗号化を設定する
AWS ParallelCluster が提供するデフォルトのSlurmアカウンティング設定では、サーバーが Amazon RDS などの TLS encryption. AWS database サービスをサポートし、デフォルトで TLS 暗号化 Amazon Aurora をサポートしている場合、 はデータベースサーバーへの TLS 暗号化接続`slurmdbd`を確立します。
データベースサーバーで `require_secure_transport` パラメータを設定することにより、サーバー側の安全な接続を要求できます。これは、提供されている CloudFormation テンプレートで設定されます。
セキュリティのベストプラクティスに従って、`slurmdbd` クライアントのサーバー ID 検証も有効にすることをお勧めします。これを行うには、`slurmdbd.conf` で [StorageParameters](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageParameters) を設定します。サーバー CA 証明書をクラスターのヘッドノードにアップロードします。次に、`slurmdbd.conf` の `StorageParameters` の [SSL\$1CA](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_SSL_CA) オプションをヘッドノードのサーバー CA 証明書のパスに設定します。これにより、`slurmdbd` 側でのサーバー ID 検証が有効になります。これらの変更を行った後、`slurmdbd` サービスを再起動して ID 検証が有効になっているデータベースサーバーへの接続を再確立します。
### データベース認証情報を更新する
[Database](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 設定のカスタマイズ
AWS ParallelCluster バージョン 3.6.0 以降では、 AWS ParallelCluster クラスター`slurm.conf`Slurm設定で設定をカスタマイズできます。
クラスター設定では、以下の クラスター構成設定を使用してSlurm 設定パラメータをカスタマイズできます。
+ / または両方を指定した場合は [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettings) parameter. AWS ParallelCluster fails [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings) を使用してSlurm、クラスター全体の[`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)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings) (Slurm ノードにマッピングされています) を使用してコンピューティングリソースの Slurm パラメータをカスタマイズします。
## Slurm を使用する際の設定カスタマイズの制限と考慮事項 AWS ParallelCluster
+ `CustomSlurmSettings` および `CustomSlurmSettingsIncludeFile`設定では、クラスターの設定に使用している[Slurmバージョン](slurm-workload-manager-v3.md)でサポートされている AWS ParallelCluster バージョンに含まれる`slurm.conf`パラメータのみを指定および更新できます。
+ パラメータのいずれかでカスタムSlurm設定を指定すると`CustomSlurmSettings`、 は検証チェック AWS ParallelCluster を実行し、 AWS ParallelCluster ロジックと競合するSlurm設定パラメータの設定または更新を防止します。と競合することが知られているSlurm設定パラメータは、拒否リストで識別 AWS ParallelCluster されます。拒否リストは、他のSlurm機能が追加されると、将来の AWS ParallelCluster バージョンで変更される可能性があります。詳細については、「[`CustomSlurmSettings` で拒否リストに記載されている Slurm 設定パラメータ](#slurm-configuration-denylists-v3)」を参照してください。
+ AWS ParallelCluster は、パラメータが拒否リストにあるかどうかのみをチェックします。カスタムSlurm設定パラメータの構文またはセマンティクスは検証 AWS ParallelCluster されません。カスタム Slurm 設定パラメータはお客様の責任で検証していただく必要があります。無効なカスタム Slurm 設定パラメータは、クラスターの作成や更新の失敗につながる Slurm デーモンの障害を引き起こす可能性があります。
+ でカスタムSlurm設定を指定した場合`CustomSlurmSettingsIncludeFile`、 AWS ParallelCluster は検証を実行しません。
+ `CustomSlurmSettings` および `CustomSlurmSettingsIncludeFile` は、コンピューティングフリートを停止および起動することなく更新できます。この場合、 は`slurmctld`デーモン AWS ParallelCluster を再起動し、 `scontrol reconfigure` コマンドを実行します。
一部の Slurm 設定パラメータでは、クラスター全体に変更が登録される前に異なる操作が必要になる場合があります。例えば、クラスター内のすべてのデーモンを再起動する必要がある場合があります。更新中にカスタムSlurm設定パラメータ設定を伝達するのに AWS ParallelCluster オペレーションが十分かどうかを検証するのはお客様の責任です。 AWS ParallelCluster オペレーションが不十分な場合は、[Slurmドキュメント](https://slurm.schedmd.com/documentation.html)で推奨されているように、更新された設定を伝達するために必要な追加のアクションを提供する責任があります。
## `CustomSlurmSettings` で拒否リストに記載されている Slurm 設定パラメータ
次の表は、 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 |
**[native Slurm accounting integration](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 |
| 状態 | 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 |
| (重量) | 3.7.0 |
# Slurm および `prolog` `epilog`
AWS ParallelCluster バージョン 3.6.0 以降、 で 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 and Epilog Guide](https://slurm.schedmd.com/prolog_epilog.html)」を参照してください。
AWS ParallelCluster には、次のプロログスクリプトとエピックログスクリプトが含まれています。
+ `90_plcuster_health_check_manager` (`Prolog` フォルダ内)
+ `90_pcluster_noop` (`Epilog` フォルダ内)
**注記**
`Prolog` および `Epilog` フォルダの両方に、少なくとも 1 つのファイルが含まれている必要があります。
独自のカスタム `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)`、Slurmパーティションに 1:1 をマッピング`(Scheduling/SlurmQueues)`するキューに編成されます。
コンピューティングリソース内では、クラスターで実行し続ける必要があるコンピューティングノード (インスタンス) の最小数 (`MinCount`) と、コンピューティングリソースがスケールできるインスタンスの最大数 ([`MaxCount` 3](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)) を設定できます。
クラスターの作成時、またはクラスターの更新時に、 はクラスターで定義された各コンピューティングリソース (`Scheduling/SlurmQueues/ ComputeResources`) `MinCount` に対して で設定された数だけ Amazon EC2 インスタンス AWS ParallelCluster を起動します。クラスター内のコンピューティングリソースの最小ノード数をカバーするために起動されたインスタンスは、***静的ノード***と呼ばれます。静的ノードは、起動されるとクラスター内で永続的となり、特定のイベントや条件が発生しない限り、システムによって終了されることはありません。このようなイベントには、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` の変更などが含まれます。 AWS ParallelCluster バージョン 3.9.0 以降では、キューのサイズを小さくするには、クラスターの更新が行われる前にコンピューティングフリートを停止するか、[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` より大きい場合 (静的容量と動的容量の混合) の 2 つの異なるシナリオを区別できます。
### 静的ノードのみの容量変更
+ `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]
```
+ 更新 (`-30`) を適用した `MinCount` および `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--]`)。システムは対応する数の 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]
```
これにより、Slurm 予約が `maint_for_update` という名前でノード `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)`
+ 更新された Slurm パーティション設定を AWS ParallelCluster 設定から生成する
+ `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 IAM ユーザーガイド」](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 jobs](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 jobs](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` を指定すると、ノードごとの vCPU の数が識別されます。
デフォルト: 1
**-m *MEMORY*, --memory *MEMORY***
ジョブに送信するメモリのハード制限 (MiB 単位) を指定します。ここで指定したメモリ制限を超えようとすると、ジョブは強制終了されます。
デフォルト: 128
**-e *ENV*, --env *ENV***
ジョブ環境にエクスポートする環境変数名のカンマ区切りリストを指定します。すべての環境変数をエクスポートするには、「all」を指定します。「all」の環境変数のリストには、`–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***
ジョブが終了していない場合に がジョブ AWS Batch を終了するまでの時間 (ジョブ試行の`startedAt`タイムスタンプから測定) を秒単位で指定します。タイムアウト値は 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
```
詳細については、「*Linux インスタンス用 Amazon Elastic Compute Cloud ユーザーガイド*」の「[スポットインスタンスリクエスト向けのサービスにリンクされたロール](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 個のジョブに依存します。配列ジョブのジョブ ID を指定せずに、`SEQUENTIAL` タイプの依存関係を指定できます。シーケンシャルな依存関係では、各子配列ジョブがインデックス 0 から開始して順番に完了します。また、配列ジョブのジョブ ID を使用して N\$1TO\$1N タイプの依存関係を指定することもできます。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***
含めるジョブステータスのカンマ区切りリストを指定します。デフォルトのジョブのステータスは「active」です。有効な値は、`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