翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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` ログには、コンピューティングノードのブートストラップ障害の原因となった手順が示されています。