기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# AWS PCS의 컴퓨팅 노드 부트스트랩 및 등록 문제 해결
컴퓨팅 노드가 부트스트랩에 실패하거나 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 통합** - 인스턴스가 Slurm 클러스터를 실행`slurmd`하고 조인합니다. 다음과 같은 문제로 인해 장애가 발생할 수 있습니다.
+ 권한
+ [보안 그룹 구성](#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에서 작동하는 방식
이는 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` 데몬은 할당된 노드에서 작업을 실행합니다.
## 인스턴스 로그 검색
컴퓨팅 노드 부트스트랩 문제를 해결하는 첫 번째 단계는 인스턴스 로그를 검색하는 것입니다. 다음 방법 중 하나를 사용할 수 있습니다.
------
#### [ 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 그룹 검색
컴퓨팅 노드 문제를 해결하려면 인스턴스와 연결된 VPC, 서브넷 및 보안 그룹에 대한 정보를 검색해야 할 수 있습니다. 인스턴스 IDs 모르는 경우 섹션을 참조하세요[AWS PCS에서 컴퓨팅 노드 그룹 인스턴스 찾기](working-with_compute-instances.md).
------
#### [ AWS Management Console ]
**VPC, 서브넷 및 보안 그룹을 가져오는 방법**
1. [Amazon EC2 콘솔](https://console.aws.amazon.com/ec2)을 엽니다.
1. **인스턴스**를 선택합니다.
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
```
------
## 노드 등록 문제
노드 등록은 부트스트랩 중에 컴퓨팅 노드가 실행하는 첫 번째 작업입니다. 노드는 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
<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.
```
### 잘못된 인스턴스 프로파일
잘못된 인스턴스 프로파일로 인해 노드를 등록할 수 없는 경우 다음 오류가 표시됩니다.
```
<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:::assumed-role// is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:::cluster/ 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 엔드포인트에 연결할 수 없음
컴퓨팅 노드가 프라이빗 서브넷에 있는 경우 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 엔드포인트
다음과 유사한 오류 메시지가 표시되면 AWS PCS VPC 엔드포인트와 연결된 정책을 확인합니다.
```
com.amazon.coral.security.AccessDeniedException: User: arn:aws:sts::xxx:assumed-role// is not authorized to perform: pcs:RegisterComputeNodeGroupInstance on resource: arn:aws:pcs:::cluster/ as either the resource does not exist, some policy explicitly denies access, or no policy grants access
```
AWS PCS용 VPC 인터페이스 엔드포인트를 구성하는 방법에 대한 자세한 내용은 섹션을 참조하세요[인터페이스 엔드포인트를 AWS Parallel Computing Service 사용한 액세스(AWS PrivateLink)](vpc-interface-endpoints.md).
### 퍼블릭 IP가 없는 퍼블릭 서브넷의 인스턴스
서브넷에 **퍼블릭 IP 자동 할당**이 활성화되어 있지 않고 라우팅 구성이 인터넷 게이트웨이를 사용하는 경우 인스턴스가 AWS PCS API와 통신할 수 없습니다.
인터넷 게이트웨이가 있는 서브넷의 인스턴스에는 퍼블릭 IP 주소가 있어야 합니다. 이 문제를 해결하려면 다음 옵션 중 하나를 선택합니다.
+ 클러스터 VPC에 AWS PCS용 VPC 엔드포인트를 추가합니다. 이렇게 하면 퍼블릭 IP 주소가 인터넷 게이트웨이를 통과할 필요 없이 인스턴스가 AWS PCS와 통신할 수 있습니다.
+ 퍼블릭 IP 주소가 필요하지 않도록 NAT 게이트웨이와 함께 프라이빗 서브넷을 사용합니다.
+ 인스턴스가 인터넷 게이트웨이를 통해 API에 연결할 수 있도록 서브넷 또는 시작 템플릿을 통해 자동 퍼블릭 IP 주소 할당을 활성화합니다. 이 옵션은 다중 네트워크 인터페이스 인스턴스에는 유효하지 않습니다.
### 퍼블릭 서브넷의 다중 NIC 인스턴스
여러 네트워크 인터페이스(NICs)가 있는 인스턴스 유형을 사용하는 경우 프라이빗 서브넷을 사용해야 합니다.
AWS 퍼블릭 IP 주소는 단일 네트워크 인터페이스로 시작된 인스턴스에만 할당할 수 있습니다. IP 주소에 대한 자세한 내용은 Linux [인스턴스용 Amazon EC2 사용 설명서의 인스턴스 시작 중 퍼블릭 IPv4 주소 할당](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#public-ip-addresses)을 참조하세요. *Amazon EC2 *
다중 NIC 인스턴스 유형은 AWS PCS 엔드포인트에 액세스하려면 서브넷의 NAT 게이트웨이 또는 내부 프록시가 필요합니다. 또는 클러스터 VPC에 AWS PCS용 VPC 엔드포인트를 추가할 수 있습니다.
### 클러스터 보안 암호가 삭제되었거나 삭제 대상으로 표시되었습니다.
AWS Secrets Manager의 Slurm 공유 보안 암호가 삭제되었거나 삭제 대상으로 표시된 경우 컴퓨팅 노드가 등록되지 않고 클러스터가 손상됩니다.
AWS 클러스터를 생성할 때 PCS는 AWS Secrets Manager에서 Slurm 공유 보안 암호를 자동으로 생성합니다(이름 형식: `pcs!slurm-secret-`). 이 보안 암호는 클러스터의 보안 통신에 필요합니다. 자세한 내용은 [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 클러스터 조인 문제
노드 등록에 성공하면 컴퓨팅 노드가 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"] ----
```
### 보안 그룹 구성
컴퓨팅 노드와 Slurm 컨트롤러 간의 통신을 허용하도록 보안 그룹이 올바르게 구성되어 있는지 확인합니다. 보안 그룹은 다음 트래픽을 허용해야 합니다.
+ 가 통신`slurmd`할 포트 6817 `slurmctld`
+ 용 포트 6818에서 ping`slurmctld`으로 `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 드라이버 누락
인스턴스가 올바르게 부트스트랩되지만 작업이 시작되지 않고 인스턴스 로그에 다음과 유사한 오류 메시지가 표시되면 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에 도달함
노드가 비정상으로 인해 컴퓨팅 노드와 해당 EC2 인스턴스가 종료되면 AWS PCS가 AMI를 지원하지 않거나 네트워크 문제가 있을 수 있습니다. EC2 인스턴스는 Slurm의 ResumeTimeout에 도달할 때까지 약 30분 동안 실행되고 노드를 로 표시합니다`DOWN`.
인스턴스가 올바르게 부트스트랩되지 않고 AWS PCS에 등록되지 않은 경우(EC2 인스턴스에 대한 `RegisterComputeNodeGroupInstance` 호출 없음) 인스턴스 로그에 다음과 유사한 오류 메시지가 있는지 확인합니다.
```
/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할 수 없음
인스턴스가 부트스트랩 절차를 올바르게 실행하고 AWS PCS에 등록되었지만 인스턴스를 보고 작업을 제출할 `slurmctld` 수 없는 경우 인스턴스는 잠시 `DOWN` 후에 로 설정된 다음 종료됩니다.
이는 잘못 구성된 보안 그룹으로 인해 발생할 수 있습니다. 예를 들어 포트 6817이와 `slurmd` 통신할 수 있도록 활성화되어 `slurmctld`있지만 포트 6818이 누락되어에 ping`slurmctld`을 허용합니다`slurmd`.
에 설명된 대로 보안 그룹에 필요한 모든 규칙이 포함되어 있는지 확인합니다[보안 그룹 요구 사항 및 고려 사항](working-with_networking_sg.md#working-with_networking_sg-requirements).