기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 규모 조정 문제 해결
이 섹션은 Slurm 작업 스케줄러와 함께 AWS ParallelCluster 버전 3.0.0 이상을 사용하여 설치된 클러스터와 관련이 있습니다. 다중 대기열 구성에 대한 자세한 내용은 [다중 대기열 구성](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`에서 또는 클러스터 실행 실패 시 `clustermgtd.log`에서 `InsufficientInstanceCapacity` 오류가 표시되는 경우](#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)
## 디버깅을 위한 키 로그
다음 표에서는 헤드 노드의 키 로그 개요를 제공합니다.
+ `/var/log/cfn-init.log` - CloudFormation init 로그입니다. 여기에는 인스턴스가 설정될 때 실행된 모든 명령이 들어 있습니다. 이를 사용하여 초기화 문제를 해결할 수 있습니다.
+ `/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` 로그입니다. 이 대몬(daemon)은 대부분의 클러스터 작업 작업을 관리하는 중앙 대몬으로 실행됩니다. 이를 사용하여 시작, 종료 또는 클러스터 운영 문제를 해결할 수 있습니다.
+ `/var/log/slurmctld.log` - 제어 Slurm 데몬 로그입니다. 조정 결정을 내 AWS ParallelCluster 리지 않습니다. 오히려 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` 대몬(daemon)이 오프라인 상태인 드문 상황에서 각 컴퓨팅 노드에서 실행되어 노드를 모니터링합니다. 이를 사용하여 예상치 못한 종료 문제를 해결할 수 있습니다.
+ `/var/log/slurmd.log` - 이것은 Slurm 컴퓨팅 대몬 로그입니다. 이를 사용하여 초기화 및 컴퓨팅 실패 문제를 해결할 수 있습니다.
## 작업 실행 실패 시 `slurm_resume.log`에서 또는 클러스터 실행 실패 시 `clustermgtd.log`에서 `InsufficientInstanceCapacity` 오류가 표시되는 경우
클러스터에서 Slurm 스케줄러를 사용하는 경우 용량 부족 문제가 발생하는 것입니다. 인스턴스 시작이 요청되었을 때 사용 가능한 인스턴스가 부족하면 `InsufficientInstanceCapacity` 오류가 반환됩니다.
정적 인스턴스 용량의 경우 `/var/log/parallelcluster/clustermgtd`의 `clustermgtd` 로그에서 오류를 찾을 수 있습니다.
동적 인스턴스 용량의 경우 `/var/log/parallelcluster/slurm_resume.log`의 `ResumeProgram` 로그에서 오류를 찾을 수 있습니다.
메시지는 다음 예제와 유사합니다.
```
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)/[`SubnetIds`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Networking-SubnetIds) 안의 서브넷 ID를 변경하여 대기열을 다른 가용 영역으로 옮기세요.
+ 워크로드가 밀접하게 연결되지 않은 경우 대기열을 여러 가용 영역에 분산시키세요. 다중 서브넷 구성에 관한 자세한 내용은 [`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)을 참조하세요.
## 노드 초기화 문제 해결
이 섹션에서는 노드 초기화 문제를 해결하는 방법을 다룹니다. 여기에는 노드가 시작, 전원 공급 또는 클러스터 조인에 실패하는 문제가 포함됩니다.
**Topics**
+ [헤드 노드](#troubleshooting-v3-node-init.head-node)
+ [컴퓨팅 노드](#troubleshooting-v3-node-init.compute-node)
### 헤드 노드
적용 가능한 로그:
+ `/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` 스크립트가 클러스터의 구성에 지정되어 있으면 로그 메시지를 통해 스크립트가 성공적으로 실행되는지 다시 확인하세요.
클러스터를 생성할 때 헤드 노드는 컴퓨팅 노드가 클러스터에 조인할 때까지 기다려야 클러스터에 조인할 수 있습니다. 따라서 컴퓨팅 노드가 클러스터에 조인하지 못하면 헤드 노드도 조인하지 못합니다. 사용하는 컴퓨팅 노드 유형에 따라 다음 일련의 절차 중 하나를 수행하여 이러한 유형의 문제를 해결할 수 있습니다.
### 컴퓨팅 노드
+ 적용 가능한 로그:
+ `/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` 로그에 오류 메시지가 있을 것입니다. 클러스터 구성에 사전 설치 또는 설치 후 스크립트가 지정된 경우 해당 스크립트가 성공적으로 실행되었는지 확인하세요.
+ Slurm 구성을 수정하여 사용자 지정 AMI를 사용하는 경우 컴퓨팅 노드가 클러스터에 조인하지 못하게 하는 Slurm 관련 오류가 있을 수 있습니다. 스케줄러 관련 오류의 경우 `/var/log/slurmd.log` 로그를 확인하세요.
**동적 컴퓨팅 노드:**
+ `ResumeProgram` 로그(`/var/log/parallelcluster/slurm_resume.log`)에서 컴퓨팅 노드 이름을 검색하여 해당 노드와 함께 `ResumeProgram`이 직접 호출된 적이 있는지 확인합니다. (`ResumeProgram`가 호출되지 않은 경우 `slurmctld` 로그(`/var/log/slurmctld.log`)를 확인하여 노드로 호출을 시도Slurm한 적이 있는지 확인할 수 `ResumeProgram` 있습니다).
+ 권한이 올바르지 않으면 `ResumeProgram`가 `ResumeProgram`를 자동으로 실패하게 할 수 있습니다. `ResumeProgram` 설정을 수정하여 사용자 지정 AMI를 사용하는 경우 `slurm` 사용자가 `ResumeProgram`를 소유하고 있으며 `744`(`rwxr--r--`) 권한이 있는지 확인하세요.
+ `ResumeProgram`가 호출되면 해당 노드에 대한 인스턴스가 시작되었는지 확인하세요. 시작된 인스턴스가 없는 경우 시작 실패를 설명하는 오류 메시지가 표시될 수 있습니다.
+ 인스턴스가 시작된 경우 설정 프로세스 중에 문제가 있을 수 있습니다. `ResumeProgram` 로그에서 해당 프라이빗 IP 주소와 인스턴스 ID를 확인할 수 있습니다. 또한 특정 인스턴스의 대응하는 설정 로그를 볼 수 있습니다. 컴퓨팅 노드 설정 오류의 문제를 해결하는 방법에 대한 자세한 내용은 다음 섹션을 참조하세요.
정적 컴퓨팅 노드:****
+ `clustermgtd`(`/var/log/parallelcluster/clustermgtd`) 로그를 확인하여 해당 노드의 인스턴스가 시작되었는지 확인합니다. 시작되지 않은 경우 시작 실패를 자세히 설명하는 명확한 오류 메시지가 있어야 합니다.
+ 인스턴스가 시작되면 설정 프로세스 중에 몇 가지 문제가 있습니다. `ResumeProgram` 로그에서 해당 프라이빗 IP 주소와 인스턴스 ID를 확인할 수 있습니다. 또한 특정 인스턴스의 대응하는 설정 로그를 볼 수 있습니다.
스팟 인스턴스가 지원하는 컴퓨팅 노드:****
+ 스팟 인스턴스를 처음 사용하고 작업이 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.
```
스팟 인스턴스를 사용할 경우 계정에 `AWSServiceRoleForEC2Spot` 서비스 연결 역할이 있어야 합니다. 를 사용하여 계정에서이 역할을 생성하려면 다음 명령을 AWS CLI실행합니다.
```
$ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com
```
자세한 내용은 사용 설명서[스팟 인스턴스 작업](spot-v3.md)의 및 *Amazon EC2 * AWS ParallelCluster 사용 설명서의 [스팟 인스턴스 요청에 대한 서비스 연결 역할을 참조하세요](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests).
## 예상치 못한 노드 교체 및 종료 문제 해결****
이 섹션에서는 특히 노드가 예기치 않게 교체되거나 종료되는 경우 노드 관련 문제를 해결하는 방법을 계속 살펴봅니다.
+ 적용 가능한 로그:****
+ `/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에 의한 예상 종료인지, 특히 스팟 종료인지 확인합니다. 컴퓨팅 노드에서 `computemgtd`실행되는는 `clustermgtd`가 비정상으로 확인되면 노드를 종료할 수도 있습니다. `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
```
## 문제가 있는 인스턴스 및 노드 교체, 종료 또는 전원 끄기****
+ 적용 가능한 로그:****
+ `/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`에 의해 수행됩니다. Slurm은 `SuspendTimeout` 이후에 노드를 자동으로 `POWER_SAVING` 상태로 되돌립니다.
+ 부트스트랩 장애로 인해 컴퓨팅 노드에 계속 장애가 발생하는 경우, [Slurm 클러스터 보호 모드](slurm-protected-mode-v3.md)가 활성화된 상태로 시작되는지 확인하세요. 보호 모드가 활성화되지 않은 경우 보호 모드 설정을 수정하여 보호 모드를 활성화하세요. 부트스트랩 스크립트 문제 해결 및 수정
## 대기열(파티션) `Inactive` 상태
`sinfo`를 실행했을 때 출력에 `AVAIL` 상태가 `inact`인 대기열이 표시되면 클러스터에 [Slurm 클러스터 보호 모드](slurm-protected-mode-v3.md)가 활성화되어 있고 대기열이 사전 정의된 기간 동안 `INACTIVE` 상태로 설정되어 있었을 수 있습니다.
## 기타 알려진 노드 및 작업 문제 해결
알려진 또 다른 유형의 문제는 작업을 할당하지 못하거나 조정 결정을 내리지 못할 AWS ParallelCluster 수 있다는 것입니다. 이러한 유형의 문제에서는 AWS ParallelCluster 가 Slurm 지침에 따라서만 리소스를 시작, 종료 또는 유지 관리합니다. 이러한 문제의 경우 `slurmctld` 로그를 확인하여 문제를 해결하세요.