

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

# 對 AWS PCS 中的運算節點引導和註冊問題進行故障診斷
<a name="troubleshooting-compute-node-bootstrap"></a>

當運算節點無法開機或向 AWS PCS 叢集正確註冊時，您可能會遇到下列症狀：
+ 任務未啟動
+ 您無法連線到 中的執行個體 AWS Systems Manager
+ 執行個體意外關閉
+ 執行個體會持續取代

這些故障可能是由 EC2 執行個體啟動期間或 AWS PCS 運算節點引導程序期間的問題所造成。本主題說明在 AWS PCS 節點引導程序期間協助您疑難排解問題的程序。如需有關對 EC2 執行個體啟動進行故障診斷的詳細資訊，請參閱[《Amazon Elastic Compute Cloud 使用者指南》中的對 Amazon EC2 執行個體啟動問題進行故障診斷](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html)。 **

當 EC2 執行個體成功啟動，但在加入 AWS PCS 叢集的過程中失敗時，就會發生引導失敗。引導程序包含兩個主要階段：
+ **節點註冊** – EC2 執行個體會呼叫 [RegisterComputeNodeGroupInstance](https://docs.aws.amazon.com/pcs/latest/APIReference/API_RegisterComputeNodeGroupInstance.html) AWS PCS API 動作，以向 AWS PCS 服務註冊。由於下列問題，可能會發生失敗：
  + 許可
    + [錯誤的執行個體描述檔](#troubleshooting-compute-node-bootstrap-wrong-instance-profile)
  + 聯網
    + [無法連線至 AWS PCS 端點](#troubleshooting-compute-node-bootstrap-connect-to-endpoints)
    + [設定錯誤的 AWS PCS 端點](#troubleshooting-compute-node-bootstrap-misconfigured-pcs-endpoint)
    + [沒有公有 IP 的公有子網路中的執行個體](#troubleshooting-compute-node-bootstrap-public-subnet-no-public-ip)
    + [公有子網路中的多 NIC 執行個體](#troubleshooting-compute-node-bootstrap-multi-nic-public-subnet)
  + 叢集秘密
    + [叢集秘密已刪除或標記為刪除](#troubleshooting-compute-node-bootstrap-cluster-secret-deleted)
+ **Slurm 整合** – 執行個體會執行`slurmd`並加入 Slurm 叢集。由於下列問題，可能會發生失敗：
  + 許可
    + [安全群組組態](#troubleshooting-compute-node-bootstrap-security-groups)
    + [Slurmctld 無法 ping 運算節點](#troubleshooting-compute-node-bootstrap-slurmctld-ping-issue)
  + 自訂 AMI 設定
    + [缺少 NVIDIA 驅動程式](#troubleshooting-compute-node-bootstrap-missing-nvidia-drivers)
    + [已達到 ResumeTimeout](#troubleshooting-compute-node-bootstrap-resume-timeout)

## Slurm 如何在 AWS PCS 上運作
<a name="troubleshooting-compute-node-bootstrap-how-slurm-works"></a>

這可能有助於您將標準 Slurm 的運作方式與 Slurm 在 AWS PCS 上的運作方式進行比較。

**標準 Slurm 任務處理**  
標準 Slurm 任務處理中會發生下列步驟：

1. 當您提交任務時， 會`slurmctld`驗證任務並排入佇列。

1. 當資源可用時， 會`slurmctld`配置現有的節點。

1. `slurmd` 協助程式在已配置節點上執行任務。

**AWS PCS 上的 Slurm 任務處理**  
 AWS PCS 任務處理中會發生下列步驟：

1. 當您提交任務時， 會`slurmctld`驗證任務並排入佇列。

1. **當需要額外容量時， AWS PCS 會使用運算節點群組的啟動範本來啟動新的 EC2 執行個體。**

1. **叢集中的新執行個體引導：**

   1. **執行個體向 AWS PCS 註冊。**

   1. **執行個體會加入 Slurm 叢集。**

1. 當資源準備就緒時， 會`slurmctld`配置節點 （包括新啟動的節點）。

1. `slurmd` 協助程式在已配置節點上執行任務。

## 擷取執行個體日誌
<a name="troubleshooting-compute-node-bootstrap-retrieve-logs"></a>

疑難排解運算節點引導問題的第一步是擷取執行個體日誌。您可以使用下列其中一種方法：

------
#### [ AWS CLI ]

使用下列命令從運算節點擷取主控台輸出：

```
aws ec2 get-console-output --region us-east-1 --instance-id i-1234567890abcdef0 --output text
```

將 *us-east-1* 取代為您的 AWS 區域，並將 *i-1234567890abcdef0* 取代為您的執行個體 ID。

------
#### [ AWS Systems Manager ]

如果您可以使用 Systems Manager 連線到執行個體，您可以直接檢視引導日誌檔案：

1. 使用 Systems Manager 連線至執行個體。如需詳細資訊，請參閱 *Systems Manager 使用者指南*中的[啟動工作階段](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#start-ec2-console)。

1. 檢視引導日誌檔案：

   ```
   sudo cat /var/log/amazon/pcs/bootstrap.log
   ```

**注意**  
如果在初始化階段發生問題，您可能需要等待約 20 分鐘，才能連線到執行個體。Systems Manager 和 SSH 服務只有在初始化完成後，或在發生故障時引導執行達到逾時時才會啟動。

------

## 從執行個體 ID 擷取 VPC/Subnet/Security群組
<a name="troubleshooting-compute-node-bootstrap-retrieve-vpc-info"></a>

若要疑難排解運算節點的問題，您可能需要擷取與執行個體相關聯之 VPC、子網路和安全群組的相關資訊。如果您不知道執行個體 IDs，請參閱 [尋找 AWS PCS 中的運算節點群組執行個體](working-with_compute-instances.md)。

------
#### [ AWS 管理主控台 ]

**取得 VPC、子網路和安全群組**

1. 開啟 [Amazon EC2 主控台](https://console.aws.amazon.com/ec2)。

1. 選擇 **Instances** (執行個體)。

1. 在**執行個體**表格中，選擇執行個體 ID。

1. 在執行個體的顯示執行個體摘要中尋找 **VPC ID** 和**子網路 ID**。

1. 在執行個體摘要中，選擇**安全**索引標籤。

1. 在**安全索引標籤中尋找安全群組**。 ****

------
#### [ AWS CLI ]

使用下列命令來擷取執行個體的 VPC、子網路和安全群組資訊：

```
aws ec2 describe-instances --instance-ids i-1234567890abcdef0 --query 'Reservations[*].Instances[*].{InstanceId:InstanceId,VpcId:VpcId,SubnetId:SubnetId,SecurityGroups:SecurityGroups[*].GroupId}' --output table
```

------

## 節點註冊問題
<a name="troubleshooting-compute-node-bootstrap-registration-issues"></a>

節點註冊是運算節點在引導期間執行的第一個動作。節點會呼叫 AWS PCS API 端點來向 AWS PCS 註冊。註冊失敗通常會顯示類似以下的錯誤訊息：

```
<13>Nov 13 16:23:50 user-data: [2025-11-13T16:23:50.510+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Registering node to cluster <clusterId>
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.192+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retriable exception detected.
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.193+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Response is [specific error message]
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.194+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retrying in 31 seconds...
<13>Nov 13 16:24:18 user-data: [2025-11-13T16:24:18.192+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Retriable exception detected.
...
<13>Nov 13 16:25:18 user-data: [2025-11-13T16:25:18.195+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Registration timeout (600 seconds) reached. Exiting.
<13>Nov 13 16:25:18 user-data: [2025-11-13T16:25:18.200+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: ERROR: Error: (2) occurred on line 1 when running /opt/aws/pcs/bin/pcs_bootstrap_init.sh. Shutting down instance.
```

### 錯誤的執行個體描述檔
<a name="troubleshooting-compute-node-bootstrap-wrong-instance-profile"></a>

如果節點因為執行個體描述檔錯誤而無法註冊，您會看到下列錯誤：

```
<13>Nov 13 18:43:08 user-data: [2025-11-13T18:43:08.268+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_init.sh: INFO: Response is {
<13>Nov 13 18:43:08 user-data:   "__type": "com.amazon.coral.service#AccessDeniedException",
<13>Nov 13 18:43:08 user-data:   "Message": "User: arn:aws:sts::<accountId>:assumed-role/<roleName>/<instanceId> is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:<regionCode>:<accountId>:cluster/<clusterId> as either the resource does not exist, some policy explicitly denies access, or no policy grants access",
<13>Nov 13 18:43:08 user-data:   "nodeID": null
<13>Nov 13 18:43:08 user-data: }
```

確認與運算節點相關聯的執行個體描述檔具有 `pcs:RegisterComputeNodeGroupInstance`許可。如需如何建立有效執行個體描述檔的詳細資訊，請參閱 [建立 AWS PCS 的執行個體描述檔](getting-started_create-cng_instance-profile.md)。

### 無法連線至 AWS PCS 端點
<a name="troubleshooting-compute-node-bootstrap-connect-to-endpoints"></a>

如果您的運算節點位於私有子網路中，請確定您已為 AWS PCS 設定 VPC 端點，或子網路具有路由至 NAT 閘道以進行網際網路存取。如需詳細資訊，請參閱下列內容：
+ 《*Amazon Virtual Private Cloud AWS PrivateLink*指南》中的[使用介面 VPC 端點存取 AWS 服務](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)。
+ [AWS PCS 的端點和服務配額](service-endpoints-quotas.md).
+ 《*Amazon Virtual Private Cloud 使用者指南》中的*[將您的 VPC 連線到其他網路](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) 
+ [AWS PCS 網路](working-with_networking.md)

### 設定錯誤的 AWS PCS 端點
<a name="troubleshooting-compute-node-bootstrap-misconfigured-pcs-endpoint"></a>

如果您看到類似以下的錯誤訊息，請確認與您的 AWS PCS VPC 端點相關聯的政策：

```
com.amazon.coral.security.AccessDeniedException: User: arn:aws:sts::xxx:assumed-role/<roleName>/<instanceId> is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:<regionCode>:<accountId>:cluster/<clusterId> as either the resource does not exist, some policy explicitly denies access, or no policy grants access
```

如需如何為 AWS PCS 設定 VPC 介面端點的詳細資訊，請參閱 [AWS Parallel Computing 服務 使用界面端點存取 (AWS PrivateLink)](vpc-interface-endpoints.md)。

### 沒有公有 IP 的公有子網路中的執行個體
<a name="troubleshooting-compute-node-bootstrap-public-subnet-no-public-ip"></a>

如果您的子網路未啟用**自動指派公有 IP**，且您的路由組態使用網際網路閘道，則執行個體無法與 AWS PCS API 通訊。

子網路中具有網際網路閘道的執行個體必須具有公有 IP 地址。若要解決此問題，請選擇下列其中一個選項：
+ 將 AWS PCS 的 VPC 端點新增至叢集 VPC。這可讓執行個體與 AWS PCS 通訊，而不需要公有 IP 地址即可通過網際網路閘道。
+ 使用具有 NAT 閘道的私有子網路，因此不需要公有 IP 地址。
+ 透過子網路或啟動範本啟用自動公有 IP 地址指派，讓執行個體可以透過網際網路閘道聯絡 API。請注意，此選項不適用於多網路介面執行個體。

### 公有子網路中的多 NIC 執行個體
<a name="troubleshooting-compute-node-bootstrap-multi-nic-public-subnet"></a>

如果您使用的執行個體類型具有多個網路介面 (NICs)，則必須使用私有子網路。

AWS 公有 IP 地址只能指派給使用單一網路介面啟動的執行個體。如需 IP 地址的詳細資訊，請參閱《*Amazon EC2 Linux 執行個體使用者指南*》中的在執行個體[啟動期間指派公有 IPv4 地址](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#public-ip-addresses)。

多 NIC 執行個體類型需要子網路中的 NAT 閘道或內部代理才能存取 AWS PCS 端點。或者，您可以將 AWS PCS 的 VPC 端點新增至叢集 VPC。

### 叢集秘密已刪除或標記為刪除
<a name="troubleshooting-compute-node-bootstrap-cluster-secret-deleted"></a>

如果 AWS Secrets Manager 中的 Slurm 共用秘密已刪除或標記為刪除，則運算節點將無法註冊，且您的叢集將會受損。

AWS 當您建立叢集時，PCS 會自動在 AWS Secrets Manager 中建立 Slurm 共用秘密 （名稱格式為：`pcs!slurm-secret-<cluster-id>`)。叢集中的安全通訊需要此秘密。如需詳細資訊，請參閱[在 AWS PCS 中使用叢集秘密](working-with_clusters_secrets.md)。

如果此秘密已刪除或標記為刪除，新節點將無法加入叢集，且控制器或其他叢集協助程式 （例如 `slurmd`和 `slurmdbd`) 在重新啟動時可能無法重新加入叢集。

若要解決此問題，如果已刪除的秘密仍在復原時段內，您可以還原該秘密。如需詳細說明，請參閱[還原 AWS Secrets Manager 秘密](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_restore-secret.html)。

如果復原時段過期，則無法還原秘密，也無法還原受影響的 AWS PCS 叢集。您需要建立具有相同組態的新叢集。 AWS PCS 會自動建立新的排程器秘密。

## Slurm 叢集聯結問題
<a name="troubleshooting-compute-node-bootstrap-slurm-issues"></a>

節點註冊成功後，運算節點會嘗試加入 Slurm 叢集。節點上的`slurmd`協助程式會聯絡 Slurm 控制器以向叢集註冊。Slurm 聯結失敗通常會顯示類似以下的錯誤訊息：

```
<13>Nov  5 17:20:29 user-data: [2024-11-05T17:20:28+00:00] FATAL: Mixlib::ShellOut::ShellCommandFailed: service[slurmd] (aws-pcs-slurm::finalize_slurm line 18) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'  
<13>Nov  5 17:20:29 user-data: ---- Begin output of ["/usr/bin/systemctl", "--system", "start", "slurmd"] ----  
<13>Nov  5 17:20:29 user-data: STDOUT:   
<13>Nov  5 17:20:29 user-data: STDERR: Job for slurmd.service failed because the control process exited with error code. See "systemctl status slurmd.service" and "journalctl -xe" for details.  
<13>Nov  5 17:20:29 user-data: ---- End output of ["/usr/bin/systemctl", "--system", "start", "slurmd"] ----
```

### 安全群組組態
<a name="troubleshooting-compute-node-bootstrap-security-groups"></a>

確認您的安全群組已正確設定，以允許運算節點和 Slurm 控制器之間的通訊。安全群組必須允許下列流量：
+ `slurmd` 用於與 通訊的連接埠 6817 `slurmctld`
+ `slurmctld` 用於 ping 的連接埠 6818 `slurmd`

如需安全群組需求的詳細資訊，請參閱下列主題：
+ [建立 AWS PCS 的安全群組](getting-started_create-sg.md)
+ [建立 AWS PCS 的啟動範本](getting-started_create-cng_launch-templates.md)
+ [安全群組需求和考量事項](working-with_networking_sg.md#working-with_networking_sg-requirements)

**重要**  
您在叢集建立期間與叢集相關聯的叢集安全群組也必須在運算節點群組安全群組中設定，以允許運算節點與控制器通訊。

### 缺少 NVIDIA 驅動程式
<a name="troubleshooting-compute-node-bootstrap-missing-nvidia-drivers"></a>

如果執行個體引導正確，但任務未啟動，而且您在執行個體日誌中看到類似以下的錯誤訊息，您可能會缺少 NVIDIA 驅動程式：

```
<13>Dec  2 13:52:00 user-data: [2024-12-02T13:52:00.094+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_config_always.sh: INFO: nvidia-smi not found!  
...  
<13>Dec  2 13:54:10 user-data: Job for slurmd.service failed because the control process exited with error code. See "systemctl status slurmd.service" and "journalctl -xe" for details.  
<13>Dec  2 13:54:12 user-data: [2024-12-02T13:54:12.718+00:00] - /opt/aws/pcs/bin/pcs_bootstrap_finalize.sh: INFO: systemctl could not start slurmd!
```

如果您連線到執行個體並檢查`slurmd`協助程式狀態，您可能會看到類似以下的錯誤：

```
$ systemctl status slurmd  
...  
fatal: can't stat gres.conf file /dev/nvidia0: No such file or directory
```

若要解決此問題，請在您的自訂 AMI 上安裝 NVIDIA 驅動程式。如需詳細資訊，請參閱[步驟 4 – （選用） 安裝其他驅動程式、程式庫和應用程式軟體](working-with_ami_custom_install-software.md)。

### 已達到 ResumeTimeout
<a name="troubleshooting-compute-node-bootstrap-resume-timeout"></a>

如果運算節點及其 EC2 執行個體因節點運作狀態不佳而終止， AWS PCS 可能不支援 AMI 或可能有網路問題。EC2 執行個體會執行約 30 分鐘，直到達到 Slurm 的 ResumeTimeout，並將節點標記為 `DOWN`。

如果執行個體未正確引導，且未向 AWS PCS 註冊 （不`RegisterComputeNodeGroupInstance`呼叫 EC2 執行個體），請檢查您的執行個體日誌是否有類似以下的錯誤訊息：

```
/opt/aws/pcs/bin/pcs_bootstrap_init.sh: No such file or directory
```

此錯誤表示 AWS PCS 引導軟體不屬於 AMI。若要解決此問題，請確定您的自訂 AMI 包含 AWS PCS 引導軟體。如需詳細資訊，請參閱[AWS PCS 的自訂 Amazon Machine Image AMIs)](working-with_ami_custom.md)。

### Slurmctld 無法 ping 運算節點
<a name="troubleshooting-compute-node-bootstrap-slurmctld-ping-issue"></a>

如果執行個體正確執行引導程序，並已向 AWS PCS 註冊，但`slurmctld`無法看到它並向其提交任務，執行個體會在一段時間`DOWN`後設定為 ，然後終止。

這可能是因為設定錯誤的安全群組所造成。例如，如果啟用連接埠 6817 以允許 與 `slurmd`通訊`slurmctld`，但連接埠 6818 遺失以允許 `slurmctld` ping `slurmd`。

確認您的安全群組包含所有必要的規則，如 中所述[安全群組需求和考量事項](working-with_networking_sg.md#working-with_networking_sg-requirements)。