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

# 對擴展問題進行故障診斷
<a name="troubleshooting-v3-scaling-issues"></a>

本節與使用 3.0.0 版及更新 AWS ParallelCluster 版本搭配Slurm任務排程器安裝的叢集相關。如需設定多個佇列的詳細資訊，請參閱 [多個佇列的組態](configuration-of-multiple-queues-v3.md)。

如果其中一個執行中的叢集發生問題，請在開始疑難排解之前執行下列命令，將叢集置於 `STOPPED` 狀態。這可避免產生任何非預期的成本。

```
$ pcluster update-compute-fleet --cluster-name mycluster \
   --status STOP_REQUESTED
```

您可以使用 [`pcluster list-cluster-log-streams`](pcluster.list-cluster-log-streams-v3.md)命令列出叢集節點可用的日誌串流，並使用其中一個失敗節點`private-dns-name`的 或前端節點進行篩選：

```
$ pcluster list-cluster-log-streams --cluster-name mycluster --region eu-west-1 \
 --filters 'Name=private-dns-name,Values=ip-10-0-0-101'
```

然後，您可以使用 [`pcluster get-cluster-log-events`](pcluster.get-cluster-log-events-v3.md)命令擷取日誌串流的內容來分析日誌串流，並將`--log-stream-name`對應的 傳遞至下節提到的其中一個金鑰日誌：

```
$ pcluster get-cluster-log-events --cluster-name mycluster \
--region eu-west-1 --log-stream-name ip-10-0-0-13.i-04e91cc1f4ea796fe.cfn-init
```

AWS ParallelCluster 在日誌群組中建立叢集 CloudWatch 日誌串流。您可以在 CloudWatch 主控台**自訂儀表板**或日誌**群組中檢視這些日誌**。如需詳細資訊，請參閱[與 Amazon CloudWatch Logs 的整合](cloudwatch-logs-v3.md)及[Amazon CloudWatch 儀表板](cloudwatch-dashboard-v3.md)。

**Topics**
+ [除錯的金鑰日誌](#troubleshooting-v3-key-logs)
+ [在我無法執行任務`slurm_resume.log`時看到`InsufficientInstanceCapacity`錯誤，或在我無法建立叢集`clustermgtd.log`時看到錯誤](#compute-node-initialization-ice-failure-v3-c2)
+ [故障診斷節點初始化問題](#troubleshooting-v3-node-init)
+ [**對非預期的節點替換和終止進行故障診斷**](#troubleshooting-v3-unexpected-node-replacements-and-terminations)
+ [**取代、終止或關閉有問題的執行個體和節點**](#replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3)
+ [佇列 （分割區） `Inactive` 狀態](#troubleshooting-v3-queues)
+ [故障診斷其他已知節點和任務問題](#troubleshooting-v3-other-node-job-issues)

## 除錯的金鑰日誌
<a name="troubleshooting-v3-key-logs"></a>

下表提供前端節點金鑰日誌的概觀：
+  `/var/log/cfn-init.log` - 這是 CloudFormation 初始化日誌。它包含設定執行個體時執行的所有命令。使用它來疑難排解初始化問題。
+  `/var/log/chef-client.log` - 這是 Chef 用戶端日誌。它包含透過 Chef/CINC 執行的所有命令。使用它來疑難排解初始化問題。
+  `/var/log/parallelcluster/slurm_resume.log` - 這是`ResumeProgram`日誌。它會啟動動態節點的執行個體。使用它來疑難排解動態節點啟動問題。
+  `/var/log/parallelcluster/slurm_suspend.log` - 這是`SuspendProgram`日誌。當動態節點的執行個體終止時，稱為 。使用它來疑難排解動態節點終止問題。檢查此日誌時，您也應該檢查`clustermgtd`日誌。
+  `/var/log/parallelcluster/clustermgtd` - 這是`clustermgtd`日誌。它執行為管理大多數叢集操作動作的集中式協助程式。使用它來疑難排解任何啟動、終止或叢集操作問題。
+  `/var/log/slurmctld.log` - 這是Slurm控制常駐程式 log. AWS ParallelCluster doesn 不會做出擴展決策。相反地，它只會嘗試啟動資源以滿足Slurm需求。它適用於擴展和配置問題、任務相關問題，以及任何排程器相關的啟動和終止問題。
+  `/var/log/parallelcluster/compute_console_output` - 此日誌記錄來自靜態運算節點範例子集的主控台輸出，這些節點已意外終止。如果靜態運算節點終止且運算節點日誌無法在 CloudWatch 中使用，請使用此日誌。當您使用 Amazon EC2 主控台或 AWS CLI 擷取執行個體主控台輸出時，您收到`compute_console_output log`的內容相同。

以下是運算節點的金鑰日誌：
+  `/var/log/cloud-init-output.log` - 這是 [cloud-init](https://cloudinit.readthedocs.io/) 日誌。它包含設定執行個體時執行的所有命令。使用它來疑難排解初始化問題。
+  `/var/log/parallelcluster/computemgtd` - 這是`computemgtd`日誌。它會在每個運算節點上執行，以監控頭節點上`clustermgtd`協助程式離線的不常見事件中的節點。使用它來疑難排解非預期的終止問題。
+  `/var/log/slurmd.log` - 這是Slurm運算協助程式日誌。使用它來疑難排解初始化和運算失敗問題。

## 在我無法執行任務`slurm_resume.log`時看到`InsufficientInstanceCapacity`錯誤，或在我無法建立叢集`clustermgtd.log`時看到錯誤
<a name="compute-node-initialization-ice-failure-v3-c2"></a>

如果叢集使用Slurm排程器，表示您遇到容量不足的問題。如果提出執行個體啟動請求時沒有足夠的執行個體可用，則會傳回`InsufficientInstanceCapacity`錯誤。

對於靜態執行個體容量，您可以在 的`clustermgtd`日誌中找到錯誤`/var/log/parallelcluster/clustermgtd`。

對於動態執行個體容量，您可以在 的`ResumeProgram`日誌中找到錯誤`/var/log/parallelcluster/slurm_resume.log`。

訊息看起來與下列範例類似：

```
An error occurred (InsufficientInstanceCapacity) when calling the RunInstances/CreateFleet operation...
```

根據您的使用案例，請考慮使用下列其中一種方法來避免取得這些類型的錯誤訊息：
+ 如果啟用放置群組，請將其停用。如需詳細資訊，請參閱[置放群組和執行個體啟動問題](troubleshooting-v3-placemment-groups.md)。
+ 預留執行個體的容量，並使用 ODCR （隨需容量預留） 啟動它們。如需詳細資訊，請參閱[使用隨需容量預留 (ODCR) 啟動執行個體](launch-instances-odcr-v3.md)。
+ 使用不同的執行個體類型設定多個運算資源。如果您的工作負載不需要特定的執行個體類型，您可以使用多個運算資源來利用快速容量不足容錯移轉。如需詳細資訊，請參閱[Slurm 叢集快速容量不足容錯移轉](slurm-short-capacity-fail-mode-v3.md)。
+ 在相同的運算資源中設定多個執行個體類型，並利用多個執行個體類型配置。如需設定多個執行個體的詳細資訊，請參閱 [使用 Slurm 進行多個執行個體類型配置](slurm-multiple-instance-allocation-v3.md)和 [`Scheduling`](Scheduling-v3.md) / [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) / [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) / [`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)。
+ 透過變更叢集組態 [`Scheduling`](Scheduling-v3.md)/ / [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) / [`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking) 中的子網路 ID，將佇列移至不同的可用區域[`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-SubnetIds)。
+ 如果您的工作負載未緊密耦合，請將佇列跨越不同的可用區域。如需設定多個子網路的詳細資訊，請參閱 [`Scheduling`](Scheduling-v3.md) / [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) / [`Networking`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-Networking) / [`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-SubnetIds)。

## 故障診斷節點初始化問題
<a name="troubleshooting-v3-node-init"></a>

本節說明如何對節點初始化問題進行疑難排解。這包括節點無法啟動、開啟電源或加入叢集的問題。

**Topics**
+ [前端節點](#troubleshooting-v3-node-init.head-node)
+ [運算節點](#troubleshooting-v3-node-init.compute-node)

### 前端節點
<a name="troubleshooting-v3-node-init.head-node"></a>

適用的日誌：
+  `/var/log/cfn-init.log` 
+  `/var/log/chef-client.log` 
+  `/var/log/parallelcluster/clustermgtd` 
+  `/var/log/parallelcluster/slurm_resume.log` 
+  `/var/log/slurmctld.log` 

檢查 `/var/log/cfn-init.log`和 `/var/log/chef-client.log`日誌或對應的日誌串流。這些日誌包含設定前端節點時執行的所有動作。在設定期間發生的大多數錯誤都應有位於 `/var/log/chef-client.log` 日誌中的錯誤訊息。如果在叢集的組態中指定 `OnNodeStart`或 `OnNodeConfigured`指令碼，請再次檢查指令碼是否透過日誌訊息成功執行。

建立叢集時，前端節點必須等待運算節點加入叢集，才能加入叢集。因此，如果運算節點無法加入叢集，則前端節點也會失敗。您可以根據您使用的運算備註類型，遵循下列其中一組程序，來疑難排解此類問題：

### 運算節點
<a name="troubleshooting-v3-node-init.compute-node"></a>
+ 適用的日誌：
  + `/var/log/cloud-init-output.log`
  + `/var/log/slurmd.log`
+ 如果啟動運算節點，請先檢查 `/var/log/cloud-init-output.log`，其中應包含類似於前端節點上日誌的設定`/var/log/chef-client.log`日誌。在設定期間發生的大多數錯誤都應在 `/var/log/cloud-init-output.log`日誌中顯示錯誤訊息。如果在叢集組態中指定預先安裝或安裝後指令碼，請檢查它們是否已成功執行。
+ 如果您使用自訂 AMI 修改Slurm組態，則可能會發生 Slurm相關錯誤，導致運算節點無法加入叢集。如需排程器相關錯誤，請檢查`/var/log/slurmd.log`日誌。

**動態運算節點：**
+ 搜尋您運算節點名稱的`ResumeProgram`日誌 (`/var/log/parallelcluster/slurm_resume.log`)，以查看是否`ResumeProgram`曾經使用節點呼叫 。（如果`ResumeProgram`從未呼叫 ，您可以檢查`slurmctld`日誌 (`/var/log/slurmctld.log`) 來判斷 是否Slurm曾經嘗試`ResumeProgram`使用節點呼叫 )。
+ 請注意，不正確的 許可`ResumeProgram`可能會導致 以無提示方式`ResumeProgram`失敗。如果您使用自訂 AMI 並修改`ResumeProgram`設定，請檢查 `ResumeProgram` 是否為`slurm`使用者所擁有，並具有 `744`(`rwxr--r--`) 許可。
+ 如果呼叫 `ResumeProgram` ，請檢查是否已為節點啟動執行個體。如果未啟動任何執行個體，您可以看到描述啟動失敗的錯誤訊息。
+ 如果執行個體已啟動，則設定程序期間可能發生問題。您應該會從`ResumeProgram`日誌中看到對應的私有 IP 地址和執行個體 ID。此外，您可以查看特定執行個體的對應設定日誌。如需使用運算節點對設定錯誤進行故障診斷的詳細資訊，請參閱下一節。

 **靜態運算節點：**
+ 檢查 `clustermgtd`(`/var/log/parallelcluster/clustermgtd`) 日誌，查看是否已為節點啟動執行個體。如果未啟動，則應該會出現明確錯誤訊息，詳細說明啟動失敗。
+ 如果執行個體已啟動，則設定程序期間會發生一些問題。您應該會從`ResumeProgram`日誌中看到對應的私有 IP 地址和執行個體 ID。此外，您可以查看特定執行個體對應的設定日誌。

 **Spot 執行個體支援的運算節點：**
+ 如果這是您第一次使用 Spot 執行個體，且任務仍處於 PD （待定狀態），請再次檢查`/var/log/parallelcluster/slurm_resume.log`檔案。您可能會發現類似以下的錯誤：

  ```
  2022-05-20 13:06:24,796 - [slurm_plugin.common:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['spot-dy-t2micro-2']: An error occurred (AuthFailure.ServiceLinkedRoleCreationNotPermitted) when calling the RunInstances operation: The provided credentials do not have permission to create the service-linked role for Amazon EC2 Spot Instances.
  ```

  使用 Spot 執行個體時，`AWSServiceRoleForEC2Spot`服務連結角色必須存在於您的帳戶中。若要使用 在帳戶中建立此角色 AWS CLI，請執行下列命令：

  ```
  $ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com
  ```

  如需詳細資訊，請參閱 AWS ParallelCluster 《Amazon EC2 使用者指南[使用 競價型執行個體](spot-v3.md)》中的 [Spot 執行個體請求的使用者指南和服務連結角色](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests)。 *Amazon EC2 *

## **對非預期的節點替換和終止進行故障診斷**
<a name="troubleshooting-v3-unexpected-node-replacements-and-terminations"></a>

本節繼續探索如何對節點相關問題進行故障診斷，特別是當節點遭到意外取代或終止時。
+ **適用的日誌：**
  + `/var/log/parallelcluster/clustermgtd` （前端節點）
  + `/var/log/slurmctld.log` （前端節點）
  + `/var/log/parallelcluster/computemgtd` （運算節點）

 **節點意外取代或終止** 
+  檢查`clustermgtd`日誌 (`/var/log/parallelcluster/clustermgtd`) 中的 是否`clustermgtd`取代或終止節點。請注意， `clustermgtd`會處理所有正常節點維護動作。
+  如果`clustermgtd`取代或終止節點，則應該會出現一則訊息，詳細說明為什麼對節點採取此動作。如果原因與排程器相關 （例如，因為節點位於 `DOWN`)，請查看 `slurmctld`日誌以取得更多資訊。如果原因是與 Amazon EC2 相關，則應有資訊性訊息詳細說明需要替換的 Amazon EC2 相關問題。
+  如果 `clustermgtd`未終止節點，請先檢查這是否為 Amazon EC2 的預期終止，特別是 Spot 終止。如果 `clustermgtd` 被判定為運作狀態不佳，`computemgtd`則在運算節點上執行的 也可以終止節點。檢查`computemgtd`日誌 (`/var/log/parallelcluster/computemgtd`) 以查看節點是否已`computemgtd`終止。

 **節點失敗 ** 
+ 簽入`slurmctld`日誌 (`/var/log/slurmctld.log`) 以查看任務或節點失敗的原因。請注意，如果節點失敗，任務會自動重新排入佇列。
+ 如果 `slurm_resume`報告啟動節點，並在幾分鐘後`clustermgtd`報告該節點的 Amazon EC2 中沒有對應的執行個體，則節點可能會在設定期間失敗。若要從運算 (`/var/log/cloud-init-output.log`) 擷取日誌，請執行下列步驟：
  + 提交任務，讓 Slurm 啟動新的節點。
  + 等待運算節點啟動。
  + 修改執行個體啟動的關閉行為，以便停止失敗的運算節點，而不是終止。

    ```
    $ aws ec2 modify-instance-attribute \
        --instance-id i-1234567890abcdef0 \
        --instance-initiated-shutdown-behavior "{\"Value\": \"stop\"}"
    ```
  + 啟用終止保護。

    ```
    $ aws ec2 modify-instance-attribute \
        --instance-id i-1234567890abcdef0 \
        --disable-api-termination
    ```
  + 標記節點以方便識別。

    ```
    $ aws ec2 create-tags \
        --resources i-1234567890abcdef0 \
        --tags Key=Name,Value=QUARANTINED-Compute
    ```
  + 變更 `parallelcluster:cluster-name`標籤，從叢集分離節點。

    ```
    $ aws ec2 create-tags \
        --resources i-1234567890abcdef0 \
        --tags Key=parallelcluster:clustername,Value=QUARANTINED-ClusterName
    ```
  + 使用此命令從節點擷取主控台輸出。

    ```
    $ aws ec2 get-console-output --instance-id i-1234567890abcdef0 --output text
    ```

## **取代、終止或關閉有問題的執行個體和節點**
<a name="replacing-terminating-or-powering-down-problematic-instances-and-nodes-v3"></a>
+ **適用的日誌：**
  + `/var/log/parallelcluster/clustermgtd` （前端節點）
  + `/var/log/parallelcluster/slurm_suspend.log` （前端節點）
+ 在大多數情況下， 會`clustermgtd`處理所有預期的執行個體終止動作。請檢查`clustermgtd`日誌，了解為何無法取代或終止節點。
+ 對於失敗的動態節點[`SlurmSettings` 屬性](Scheduling-v3.md#Scheduling-v3-SlurmSettings.properties)，請檢查`SuspendProgram`日誌中的 是否`SuspendProgram`以特定節點做為引數`slurmctld`呼叫 。請注意， 實際上`SuspendProgram`不會執行任何動作。相反地，它只會在呼叫時記錄。所有執行個體終止和`NodeAddr`重設都是由 完成`clustermgtd`。 會在 之後`SuspendTimeout`自動Slurm讓節點回到 `POWER_SAVING` 狀態。
+ 如果運算節點因為引導失敗而持續失敗，請確認它們是否在[Slurm 叢集保護模式](slurm-protected-mode-v3.md)啟用的情況下啟動。如果未啟用受保護模式，請修改受保護模式設定以啟用受保護模式。對引導指令碼進行故障診斷和修正。

## 佇列 （分割區） `Inactive` 狀態
<a name="troubleshooting-v3-queues"></a>

如果您執行 `sinfo`且輸出顯示`AVAIL`狀態為 的佇列`inact`，您的叢集可能[Slurm 叢集保護模式](slurm-protected-mode-v3.md)已啟用，且佇列在預先定義的期間內已設定為 `INACTIVE` 狀態。

## 故障診斷其他已知節點和任務問題
<a name="troubleshooting-v3-other-node-job-issues"></a>

另一種已知問題類型是 AWS ParallelCluster 可能無法配置任務或做出擴展決策。發生這類問題時， AWS ParallelCluster 只會根據Slurm指示啟動、終止或維護資源。針對這些問題，請檢查`slurmctld`日誌進行故障診斷。