本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Slurm 叢集保護模式
當叢集在啟用受保護模式的情況下執行時， AWS ParallelCluster 監控並追蹤運算節點啟動時的運算節點引導失敗。它這樣做是為了偵測這些失敗是否持續發生。
如果在佇列 （分割區） 中偵測到下列項目，則叢集會進入受保護狀態：
1. 連續運算節點引導失敗會持續發生，而不會成功啟動運算節點。
1. 失敗計數達到預先定義的閾值。
叢集進入受保護狀態後， 會 AWS ParallelCluster 停用故障等於或高於預先定義閾值的佇列。
Slurm 3.0.0 AWS ParallelCluster 版中已新增 叢集保護模式。
您可以使用受保護模式來減少運算節點引導失敗循環所花費的時間和資源。
## 受保護模式參數
**`protected_failure_count`**
`protected_failure_count` 指定在佇列 （分割區） 中啟用叢集保護狀態的連續失敗次數。
預設值`protected_failure_count`為 10，且已啟用受保護模式。
如果 `protected_failure_count` 大於零，則會啟用受保護模式。
如果 `protected_failure_count` 小於或等於零，則會停用受保護模式。
您可以在位於 的`clustermgtd`組態檔案中新增 參數來變更`protected_failure_count`值`/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf``HeadNode`。
您可以隨時更新此參數，而且您不需要停止運算機群即可執行此操作。如果啟動在失敗計數達到 之前在佇列中成功`protected_failure_count`，則失敗計數會重設為零。
## 檢查處於受保護狀態的叢集狀態
當叢集處於受保護狀態時，您可以檢查運算機群狀態和節點狀態。
### 運算機群狀態
運算機群的狀態位於處於受保護狀態的叢集`PROTECTED`中。
```
$ pcluster describe-compute-fleet --cluster-name --region
{
"status": "PROTECTED",
"lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z"
}
```
### 節點狀態
若要了解哪些佇列 （分割區） 的引導失敗已啟用受保護狀態，請登入叢集並執行 `sinfo`命令。開機失敗等於或高於 的分割區`protected_failure_count`處於 `INACTIVE` 狀態。在 或 以上沒有引導失敗的分割區`protected_failure_count`處於 `UP` 狀態並如預期運作。
`PROTECTED` 狀態不會影響執行中的任務。如果任務在開機失敗位於 或高於 的分割區上執行`protected_failure_count`，則在執行中的任務完成後`INACTIVE`，該分割區會設定為 。
請考慮下列範例中顯示的節點狀態。
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* inact infinite 10 down% queue1-dy-c5xlarge-[1-10]
queue1* inact infinite 3490 idle~ queue1-dy-c5xlarge-[11-3500]
queue2 up infinite 10 idle~ queue2-dy-c5xlarge-[1-10]
```
分割區`queue1`是`INACTIVE`由於偵測到連續 10 個運算節點引導失敗。
節點後方的執行個體`queue1-dy-c5xlarge-[1-10]`已啟動，但由於運作狀態不佳而無法加入叢集。
叢集處於受保護狀態。
分割區`queue2`不會受到 中引導失敗的影響`queue1`。它處於 `UP` 狀態，仍然可以執行任務。
## 如何停用受保護狀態
解決引導錯誤之後，您可以執行下列命令，將叢集移出受保護的狀態。
```
$ pcluster update-compute-fleet --cluster-name \
--region \
--status START_REQUESTED
```
## 啟動受保護狀態的引導失敗
啟用受保護狀態的引導錯誤會細分為以下三種類型。若要識別類型和問題，您可以檢查 AWS ParallelCluster 產生的日誌。如果日誌已產生，您可以檢查日誌是否有錯誤詳細資訊。如需詳細資訊，請參閱[擷取和保留日誌](troubleshooting-v3-get-logs.md)。
1. **引導錯誤，導致執行個體自行終止**。
執行個體在引導程序初期失敗，例如因為 \$1 [`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)\$1 [`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart) \$1 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) [`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured)指令碼中的錯誤而自行終止的執行個體。
對於動態節點，請尋找類似下列的錯誤：
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
對於靜態節點，請查看`clustermgtd`日誌 (`/var/log/parallelcluster/clustermgtd`) 中是否有類似以下的錯誤：
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
1. **節點 `resume_timeout` 或 `node_replacement_timeout`過期**。
執行個體無法聯結 `resume_timeout`（適用於動態節點） 或 `node_replacement_timeout`（適用於靜態節點） 中的叢集。在逾時之前不會自行終止。例如，叢集的聯網設定不正確，且節點在逾時到期Slurm後設定為 `DOWN` 狀態。
對於動態節點，請尋找類似下列的錯誤：
```
Node bootstrap error: Resume timeout expires for node
```
對於靜態節點，請查看`clustermgtd`日誌 (`/var/log/parallelcluster/clustermgtd`) 中是否有類似以下的錯誤：
```
Node bootstrap error: Replacement timeout expires for node ... in replacement.
```
1. **節點運作狀態檢查失敗**。
節點後方的執行個體未通過 Amazon EC2 運作狀態檢查或排程事件運作狀態檢查，且節點視為引導失敗節點。在此情況下，執行個體會因 無法控制的原因而終止 AWS ParallelCluster。
查看`clustermgtd`日誌 (`/var/log/parallelcluster/clustermgtd`) 中是否有類似以下的錯誤：
```
Node bootstrap error: Node %s failed during bootstrap when performing health check.
```
1. **運算節點註冊失敗Slurm**。
向Slurm控制`slurmd`常駐程式 (`slurmctld`) 註冊常駐程式失敗，並導致運算節點狀態變更為 `INVALID_REG` 狀態。設定錯誤的Slurm運算節點可能會導致此錯誤，例如使用[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)運算節點規格錯誤設定的運算節點。
查看前端節點上的`slurmctld`日誌檔案 (`/var/log/slurmctld.log`)，或查看故障運算節點的`slurmd`日誌檔案 (`/var/log/slurmd.log`) 是否有類似以下的錯誤：
```
Setting node %s to INVAL with reason: ...
```
## 如何偵錯受保護模式
如果您的叢集處於受保護狀態，而且從 AWS ParallelCluster 產生的`clustermgtd`日誌`HeadNode`和有問題的運算節點產生的`cloud-init-output`日誌，則可以檢查日誌以取得錯誤詳細資訊。如需如何擷取日誌的詳細資訊，請參閱 [擷取和保留日誌](troubleshooting-v3-get-logs.md)。
**`clustermgtd` 前端節點上的 log(`/var/log/parallelcluster/clustermgtd`)**
日誌訊息會顯示哪些分割區發生引導失敗，以及對應的引導失敗計數。
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - INFO - Partitions
bootstrap failure count: {'queue1': 2}, cluster will be set into protected mode if protected failure count reach threshold.
```
在 `clustermgtd`日誌中，搜尋 `Found the following bootstrap failure nodes`以尋找引導失敗的節點。
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - WARNING -
Found the following bootstrap failure nodes: (x2) ['queue1-st-c5large-1(192.168.110.155)', 'broken-st-c5large-2(192.168.65.215)']
```
在 `clustermgtd`日誌中，搜尋 `Node bootstrap error`以尋找失敗的原因。
```
[slurm_plugin.clustermgtd:_is_node_bootstrap_failure] - WARNING - Node bootstrap error:
Node broken-st-c5large-2(192.168.65.215) is currently in replacement and no backing instance
```
**`cloud-init-output` 運算節點上的 log(`/var/log/cloud-init-output.log`)**
在`clustermgtd`日誌中取得引導失敗節點私有 IP 地址後，您可以登入運算節點或遵循 中的指引[擷取和保留日誌](troubleshooting-v3-get-logs.md)來擷取日誌，以尋找對應的運算節點日誌。在大多數情況下，來自有問題節點的`/var/log/cloud-init-output`日誌會顯示導致運算節點引導失敗的步驟。