기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

AWS PCS의 컴퓨팅 노드 부트스트랩 및 등록 문제 해결

컴퓨팅 노드가 부트스트랩에 실패하거나 AWS PCS 클러스터에 제대로 등록되지 않으면 다음과 같은 증상이 발생할 수 있습니다.

이러한 장애는 EC2 인스턴스 시작 중 또는 AWS PCS 컴퓨팅 노드 부트스트랩 프로세스 중 문제로 인해 발생할 수 있습니다. 이 주제에서는 AWS PCS 노드 부트스트랩 프로세스 중에 문제를 해결하는 데 도움이 되는 절차를 설명합니다. EC2 인스턴스 시작 문제 해결에 대한 자세한 내용은 Amazon Elastic Compute Cloud 사용 설명서의 Amazon EC2 인스턴스 시작 문제 해결을 참조하세요.

부트스트랩 실패는 EC2 인스턴스가 성공적으로 시작되지만 AWS PCS 클러스터에 조인하는 과정에서 실패할 때 발생합니다. 부트스트랩 프로세스에는 두 가지 주요 단계가 포함됩니다.

Slurm이 AWS PCS에서 작동하는 방식

이는 Slurm이 작동하는 표준 방식과 Slurm이 AWS PCS에서 작동하는 방식을 비교하는 데 도움이 될 수 있습니다.

표준 Slurm 작업 처리

다음 단계는 표준 Slurm 작업 처리에서 수행됩니다.

AWS PCS에서 Slurm 작업 처리

다음 단계는 AWS PCS 작업 처리에서 수행됩니다.

인스턴스 로그 검색

컴퓨팅 노드 부트스트랩 문제를 해결하는 첫 번째 단계는 인스턴스 로그를 검색하는 것입니다. 다음 방법 중 하나를 사용할 수 있습니다.

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 사용 설명서의 세션 시작을 참조하세요.

2. 부트스트랩 로그 파일 보기:

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

참고

초기화 단계에서 문제가 있는 경우 인스턴스에 연결하기 전에 약 20분 정도 기다려야 할 수 있습니다. Systems Manager 및 SSH 서비스는 초기화가 완료된 후 또는 실패 시 부트스트랩 실행이 제한 시간에 도달한 경우에만 시작됩니다.

인스턴스 ID에서 VPC/Subnet/Security 그룹 검색

컴퓨팅 노드 문제를 해결하려면 인스턴스와 연결된 VPC, 서브넷 및 보안 그룹에 대한 정보를 검색해야 할 수 있습니다. 인스턴스 IDs 모르는 경우 섹션을 참조하세요AWS PCS에서 컴퓨팅 노드 그룹 인스턴스 찾기.

AWS Management Console

VPC, 서브넷 및 보안 그룹을 가져오는 방법

1. Amazon EC2 콘솔을 엽니다.

2. 인스턴스를 선택합니다.

3. 인스턴스 테이블에서 인스턴스 ID를 선택합니다.

4. 인스턴스에 대해 표시된 인스턴스 요약에서 VPC ID 및 서브넷 ID를 찾습니다.

5. 인스턴스 요약에서 보안 탭을 선택합니다.

6. 보안 탭에서 보안 그룹을 찾습니다.

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 <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.

잘못된 인스턴스 프로파일

잘못된 인스턴스 프로파일로 인해 노드를 등록할 수 없는 경우 다음 오류가 표시됩니다.

<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용 인스턴스 프로파일 생성.

AWS PCS 엔드포인트에 연결할 수 없음

컴퓨팅 노드가 프라이빗 서브넷에 있는 경우 AWS PCS용 VPC 엔드포인트를 구성했는지 또는 서브넷에 인터넷 액세스를 위한 NAT 게이트웨이에 대한 경로가 있는지 확인합니다. 자세한 내용은 다음을 참조하세요.

잘못 구성된 AWS PCS 엔드포인트

다음과 유사한 오류 메시지가 표시되면 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 Service 사용한 액세스(AWS PrivateLink).

퍼블릭 IP가 없는 퍼블릭 서브넷의 인스턴스

서브넷에 퍼블릭 IP 자동 할당이 활성화되어 있지 않고 라우팅 구성이 인터넷 게이트웨이를 사용하는 경우 인스턴스가 AWS PCS API와 통신할 수 없습니다.

인터넷 게이트웨이가 있는 서브넷의 인스턴스에는 퍼블릭 IP 주소가 있어야 합니다. 이 문제를 해결하려면 다음 옵션 중 하나를 선택합니다.

퍼블릭 서브넷의 다중 NIC 인스턴스

여러 네트워크 인터페이스(NICs)가 있는 인스턴스 유형을 사용하는 경우 프라이빗 서브넷을 사용해야 합니다.

AWS 퍼블릭 IP 주소는 단일 네트워크 인터페이스로 시작된 인스턴스에만 할당할 수 있습니다. IP 주소에 대한 자세한 내용은 Linux 인스턴스용 Amazon EC2 사용 설명서의 인스턴스 시작 중 퍼블릭 IPv4 주소 할당을 참조하세요. Amazon EC2

다중 NIC 인스턴스 유형은 AWS PCS 엔드포인트에 액세스하려면 서브넷의 NAT 게이트웨이 또는 내부 프록시가 필요합니다. 또는 클러스터 VPC에 AWS PCS용 VPC 엔드포인트를 추가할 수 있습니다.

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 컨트롤러 간의 통신을 허용하도록 보안 그룹이 올바르게 구성되어 있는지 확인합니다. 보안 그룹은 다음 트래픽을 허용해야 합니다.

보안 그룹 요구 사항에 대한 자세한 내용은 다음 주제를 참조하세요.

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단계 - (선택 사항) 추가 드라이버, 라이브러리 및 애플리케이션 소프트웨어 설치 단원을 참조하십시오.

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 머신 이미지(AMIs) 단원을 참조하십시오.

Slurmctld가 컴퓨팅 노드를 ping할 수 없음

인스턴스가 부트스트랩 절차를 올바르게 실행하고 AWS PCS에 등록되었지만 인스턴스를 보고 작업을 제출할 slurmctld 수 없는 경우 인스턴스는 잠시 DOWN 후에 로 설정된 다음 종료됩니다.

이는 잘못 구성된 보안 그룹으로 인해 발생할 수 있습니다. 예를 들어 포트 6817이와 slurmd 통신할 수 있도록 활성화되어 slurmctld있지만 포트 6818이 누락되어에 pingslurmctld을 허용합니다slurmd.

에 설명된 대로 보안 그룹에 필요한 모든 규칙이 포함되어 있는지 확인합니다보안 그룹 요구 사항 및 고려 사항.