기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 에서 지원하는 스케줄러 AWS ParallelCluster
AWS ParallelCluster 는 [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler) 설정을 사용하여 설정된 Slurm 및 AWS Batch 스케줄러를 지원합니다. 다음 주제에서는 각 스케줄러와 이를 사용하는 방법을 설명합니다.
**Topics**
+ [Slurm Workload Manager (`slurm`)](slurm-workload-manager-v3.md)
+ [에서 AWS Batch (`awsbatch`) 스케줄러 사용 AWS ParallelCluster](awsbatchcli-v3.md)
# Slurm Workload Manager (`slurm`)
## 클러스터 용량 크기 및 업데이트
클러스터의 용량은 클러스터가 규모 조정할 수 있는 컴퓨팅 노드 수에 따라 정의됩니다. 컴퓨팅 노드는 AWS ParallelCluster 구성의 컴퓨팅 리소스 내에 정의된 Amazon EC2 인스턴스에 의해 지원되며 `(Scheduling/SlurmQueues/`ComputeResources`)`1:1을 Slurm 파티션에 매핑`(Scheduling/SlurmQueues)`하는 대기열로 구성됩니다.
컴퓨팅 리소스 내에서 클러스터()에서 항상 실행되어야 하는 최소 컴퓨팅 노드(인스턴스) 수와 컴퓨팅 리소스가 ([`MaxCount`3](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)`MinCount`)으로 확장할 수 있는 최대 인스턴스 수를 구성할 수 있습니다.
클러스터 생성 시 또는 클러스터 업데이트 시는 클러스터에 정의된 각 컴퓨팅 리소스(`Scheduling/SlurmQueues/ ComputeResources`)에 `MinCount` 대해에 구성된 수만큼 Amazon EC2 인스턴스를 AWS ParallelCluster 시작합니다. 클러스터의 컴퓨팅 리소스에 대한 최소 노드 수를 포함하도록 시작된 인스턴스를 ***정적 노드***라고 합니다. 일단 시작되면 정적 노드는 클러스터에서 영구적이어야 하며 특정 이벤트 또는 조건이 발생하지 않는 한 시스템에 의해 종료되지 않습니다. 이러한 이벤트에는 Slurm 또는 Amazon EC2 상태 확인 실패 및 Slurm 노드 상태를 DRAIN 또는 DOWN으로 변경 등이 포함됩니다.
클러스터의 증가된 부하를 처리하기 위해 온디맨드 방식으로 시작된 `1` - `‘MaxCount - MinCount’`(`MaxCount ` *-* ` MinCount)` 범위의 Amazon EC2 인스턴스를 ***동적 노드***라고 합니다. 속성은 일시적이며 보류 중인 작업을 제공하기 위해 시작되고 클러스터 구성에서 `Scheduling/SlurmSettings/ScaledownIdletime`에 정의된 기간 동안 유휴 상태로 유지되면 종료됩니다(기본값: 10분).
정적 노드 및 동적 노드는 다음 이름 지정 스키마를 준수합니다.
+ 정적 노드 `-st--` ` = 1..ComputeResource/MinCount`
+ 동적 노드 `-dy--` ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
예를 들어 다음과 같은 AWS ParallelCluster 구성이 있습니다.
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
다음 노드는 Slurm에서 정의됩니다.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
컴퓨팅 리소스에 `MinCount == MaxCount`가 있으면 해당하는 모든 컴퓨팅 노드가 정적이 되고 클러스터 생성/업데이트 시간에 모든 인스턴스가 시작되어 계속 실행됩니다. 예제:
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## 클러스터 용량 업데이트
클러스터 용량 업데이트에는 대기열 추가 또는 제거, 리소스 계산 또는 컴퓨팅 리소스의 `MinCount/MaxCount` 변경 등이 포함됩니다. AWS ParallelCluster 버전 3.9.0부터 대기열 크기를 줄이려면 클러스터 업데이트가 발생하기 전에 컴퓨팅 플릿을 중지하거나 [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)를 TERMINATE로 설정해야 합니다. 다음과 같은 경우 컴퓨팅 플릿을 중지하거나 [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)를 TERMINATE로 설정할 필요가 없습니다.
+ 예약/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)에 새 대기열 추가
+ 대기열에 새 컴퓨팅 리소스 `Scheduling/SlurmQueues/ComputeResources` 추가
+ 컴퓨팅 리소스의 `MaxCount` 증가
+ 컴퓨팅 리소스의 MinCount 증가 및 적어도 동일한 양의 동일한 컴퓨팅 리소스의 MaxCount 증가
## 고려 사항 및 제한 사항
이 섹션에서는 클러스터 용량 크기를 조정할 때 고려해야 하는 중요한 요인, 제약 또는 제한 사항을 간략하게 설명합니다.
+ 이름이 `-*`인 모든 컴퓨팅 노드 `Scheduling/SlurmQueues`에서 대기열을 제거하면 정적 및 동적 모두 Slurm 구성에서 제거되고 해당 Amazon EC2 인스턴스가 종료됩니다.
+ 대기열에서 `Scheduling/SlurmQueues/ComputeResources` 컴퓨팅 리소스를 제거하면 정적 및 동적 모두 이름이 `-*--*`인 모든 컴퓨팅 노드가 Slurm 구성에서 제거되고 해당 Amazon EC2 인스턴스가 종료됩니다.
컴퓨팅 리소스의 `MinCount` 파라미터를 변경할 때 `MaxCount`가 `MinCount`(정적 용량만 해당)와 같고 `MaxCount`가 `MinCount`(정적 및 동적 용량 혼합)보다 큰 경우 두 가지 시나리오를 구분할 수 있습니다.
### 정적 노드만 있는 용량 변경
+ `MinCount == MaxCount`인 경우 `MinCount`(및 `MaxCount`)를 늘릴 때 정적 노드 수를 `MinCount` `-st--`의 새 값으로 확장하여 클러스터를 구성하고 시스템은 필요한 새 정적 용량을 충족하기 위해 Amazon EC2 인스턴스를 계속 시작하려고 시도합니다.
+ `MinCount == MaxCount`인 경우 N 양 `MinCount`(및 `MaxCount`)을 줄일 때 마지막 N 정적 노드 `-st--...]`를 제거하여 클러스터를 구성하고 시스템은 해당 Amazon EC2 인스턴스를 종료합니다.
+ 원래 상태 `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ `MinCount` 및 `MaxCount: MinCount = MaxCount = 70`에서 `-30` 업데이트
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### 혼합 노드의 용량 변경
`MinCount < MaxCount`인 경우 N 양(`MaxCount`가 변경되지 않은 상태로 유지된다고 가정)만큼 `MinCount`를 늘리면 정적 노드 수를 `MinCount`(`old_MinCount + N`)의 새 값으로 확장하여 클러스터가 구성되고 `-st--` 및 시스템은 필요한 새 정적 용량을 충족하기 위해 Amazon EC2 인스턴스를 계속 시작하려고 시도합니다. 또한 컴퓨팅 리소스의 `MaxCount` 용량을 적용하기 위해 *마지막 N 동적 노드 를 제거*하여 클러스터 구성이 업데이트되고 `-dy--[...]` 및 시스템은 해당 Amazon EC2 인스턴스를 종료합니다.
+ 원래 상태: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ \$130을 `MinCount : MinCount = 130 (MaxCount = 150)`으로 업데이트
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
`MinCount < MaxCount`인 경우 `MinCount` 및 `MaxCount`을 동일한 N 양만큼 늘리면 정적 노드 수를 `MinCount`(`old_MinCount + N`)의 새 값으로 확장하여 클러스터가 구성되고 `-st--` 시스템은 필요한 새 정적 용량을 충족하기 위해 Amazon EC2 인스턴스를 계속 시작하려고 시도합니다. 또한 새 노드를 적용하기 위해 동적 노드 수를 변경하지 않습니다.
`MaxCount` 값
+ 원래 상태: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ \$130을 `MinCount : MinCount = 130 (MaxCount = 180)`으로 업데이트
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
`MinCount < MaxCount`인 경우 `MinCount`를 N 양만큼 줄일 경우(`MaxCount`는 변경되지 않는다고 가정) 마지막 N 정적 노드를 제거하여 클러스터를 구성하고 `-st--[...` 시스템은 해당 Amazon EC2 인스턴스를 종료합니다. 또한 컴퓨팅 리소스의 `MaxCount` 용량을 수용하기 위해 클러스터 구성은 격차를 메울 동적 노드 수를 확장하여 업데이트됩니다. `MaxCount - new_MinCount: -dy--[1..]` 이 경우 동적 노드이므로 스케줄러에 새 노드에서 보류 중인 작업이 없는 한 새 Amazon EC2 인스턴스가 시작되지 않습니다.
+ 원래 상태: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ `MinCount : MinCount = 70 (MaxCount = 120)`에서 -30 업데이트
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
`MinCount < MaxCount`인 경우 `MinCount` 및 `MaxCount`를 동일한 N 양으로 줄일 때 마지막 N 정적 노드를 제거하여 클러스터를 구성하고 `-st--...]` 시스템은 해당 Amazon EC2 인스턴스를 종료합니다.
또한 새 `MaxCount` 값을 적용하기 위해 동적 노드 수를 변경하지 않습니다.
+ 원래 상태: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ `MinCount : MinCount = 70 (MaxCount = 120)`에서 -30 업데이트
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
`MinCount < MaxCount`인 경우 `MaxCount`를 N(`MinCount`는 변경되지 않은 상태로 유지된다고 가정)만큼 줄이면 마지막 N 동적 노드를 제거하여 클러스터가 구성되고 `-dy--]` 시스템이 실행 중인 해당하는 Amazon EC2 인스턴스를 종료합니다. 정적 노드에는 영향을 미치지 않습니다.
+ 원래 상태: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ `MaxCount : MinCount = 100 (MaxCount = 120)`에서 -30 업데이트
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## 작업에 미치는 영향
노드가 제거되고 Amazon EC2 인스턴스가 종료되는 모든 경우, 작업 요구 사항을 충족하는 다른 노드가 없는 경우를 제외하고 제거된 노드에서 실행되는 sbatch 작업이 다시 대기열에 추가됩니다. 이 마지막 경우 NODE\$1FAIL 상태로 작업이 실패하고 대기열에서 사라지므로 수동으로 다시 제출해야 합니다.
클러스터 크기 조정 업데이트를 수행하려는 경우 계획된 업데이트 중에 제거될 노드에서 작업이 실행되지 않도록 할 수 있습니다. 이는 유지 관리에서 노드를 제거하도록 설정하여 가능합니다. 유지 관리에서 노드를 설정해도 결국 노드에서 이미 실행 중인 작업에는 영향을 주지 않습니다.
계획된 클러스터 크기 조정 업데이트를 통해 노드를 제거한다고 가정해 보겠습니다 `qeueu-st-computeresource-[9-10`]. 다음 명령을 사용하여 Slurm 예약을 생성할 수 있습니다.
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
이렇게 하면 노드 `qeueu-st-computeresource-[9-10]`에 `maint_for_update` 이름이 지정된 Slurm 예약이 생성됩니다. 예약이 생성된 시점부터 더 이상 `qeueu-st-computeresource-[9-10]` 노드로 실행될 수 있는 작업이 없습니다. 예약으로 인해 `qeueu-st-computeresource-[9-10]` 노드에 작업이 최종 할당되는 것을 막을 수는 없습니다.
클러스터 크기 조정 업데이트 후 크기 조정 업데이트 중에 제거된 노드에서만 Slurm 예약이 설정된 경우 유지 관리 예약이 자동으로 삭제됩니다. 대신 클러스터 크기 조정 업데이트 후에도 여전히 존재하는 노드에 대한 Slurm 예약을 생성한 경우 다음 명령을 사용하여 크기 조정 업데이트가 수행된 후 노드에 대한 유지 관리 예약을 제거할 수 있습니다.
```
sudo -i scontrol delete ReservationName=maint_for_update
```
Slurm 예약에 대한 자세한 내용은 [여기](https://slurm.schedmd.com/reservations.html)에서 공식 SchedMD 문서를 참조하세요.
## 용량 변경에 대한 클러스터 업데이트 프로세스
스케줄러 구성이 변경되면 클러스터 업데이트 프로세스 중에 다음 단계가 실행됩니다.
+ 중지 AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ AWS ParallelCluster 구성에서 업데이트된 Slurm 파티션 구성 생성
+ `slurmctld` 재시작(Chef 서비스 레시피를 통해 수행)
+ `slurmctld` 상태 확인 `(systemctl is-active --quiet slurmctld.service)`
+ Slurm 구성 다시 로드 `(scontrol reconfigure)`
+ `clustermgtd (supervisorctl start clustermgtd)` 시작
Slurm에 대한 자세한 내용은 [https://slurm.schedmd.com](https://slurm.schedmd.com)을 참조하세요. 다운로드에 대해서는 [https://github.com/SchedMD/slurm/tags](https://github.com/SchedMD/slurm/tags)를 참조하세요. 소스 코드는 [https://github.com/SchedMD/slurm](https://github.com/SchedMD/slurm)을 참조하세요.
## 지원되는 클러스터 및 SLURM 버전
다음 표에는에서 지원하는 AWS ParallelCluster 및 Slurm 버전이 나열되어 있습니다 AWS .
| AWS ParallelCluster 버전(들) | 지원되는 Slurm 버전 |
| --- | --- |
| 3.13.0 | 24.05.07 |
| 3.12.0 | 23.11.10 |
| 3.11.0 | 23.11.10 |
| 3.9.2, 3.9.3, 3.10.0 | 23.11.7 |
| 3.9.0, 3.9.1 | 23.11.4 |
| 3.8.0 | 23.02.7 |
| 3.7.2 | 23.02.6 |
| 3.7.1 | 23.02.5 |
| 3.7.0 | 23.02.4 |
| 3.6.0, 3.6.1 | 23.02.2 |
| 3.5.0, 3.5.1 | 22.05.8 |
| 3.4.0, 3.4.1 | 22.05.7 |
| 3.3.0, 3.3.1 | 22.05.5 |
| 3.1.4, 3.1.5, 3.2.0, 3.2.1 | 21.08.8-2 |
| 3.1.2, 3.1.3 | 21.08.6 |
| 3.1.1 | 21.08.5 |
| 3.0.0 | 20.11.8 |
**Topics**
+ [클러스터 용량 크기 및 업데이트](#cluster-capacity-size-and-update)
+ [클러스터 용량 업데이트](#cluster-capacity-update)
+ [고려 사항 및 제한 사항](#considerations-limitations)
+ [작업에 미치는 영향](#impacts-on-jobs)
+ [용량 변경에 대한 클러스터 업데이트 프로세스](#cluster-update-process)
+ [지원되는 클러스터 및 SLURM 버전](#cluster-slurm-version-table)
+ [다중 대기열 구성](configuration-of-multiple-queues-v3.md)
+ [다중 대기열 모드를 위한 Slurm 가이드](multiple-queue-mode-slurm-user-guide-v3.md)
+ [Slurm 클러스터 보호 모드](slurm-protected-mode-v3.md)
+ [Slurm 클러스터 빠른 용량 부족 장애 조치](slurm-short-capacity-fail-mode-v3.md)
+ [Slurm 메모리 기반 스케줄링](slurm-mem-based-scheduling-v3.md)
+ [Slurm을 사용하여 여러 인스턴스 유형 할당](slurm-multiple-instance-allocation-v3.md)
+ [동적 노드의 클러스터 스케일링](scheduler-node-allocation-v3.md)
+ [Slurm를 사용한 회계 AWS ParallelCluster](slurm-accounting-v3.md)
+ [Slurm 구성 사용자 지정](slurm-configuration-settings-v3.md)
+ [Slurm 및 `prolog``epilog`](slurm-prolog-epilog-v3.md)
+ [클러스터 용량 크기 및 업데이트](slurm-cluster-capacity-size-and-update.md)
# 다중 대기열 구성
AWS ParallelCluster 버전 3에서는를 [`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler)로 설정하고 구성 파일[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)에서에 대해 둘 이상의 대기열을 `slurm` 지정하여 여러 대기열을 구성할 수 있습니다. 이 모드에서는 구성 파일의 [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) 섹션에 지정된 컴퓨팅 노드에 여러 인스턴스 유형이 공존합니다. 인스턴스 유형이 다른 [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)은 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)의 필요에 따라 스케일 업 또는 스케일 다운될 수 있습니다.
워크로드가 동일한 기본 인프라 및 리소스(예: 공유 스토리지, 네트워킹 또는 로그인 노드)를 공유하는 경우 단일 클러스터 내의 여러 *대기열*이 일반적으로 여러 클러스터보다 선호됩니다. 워크로드의 컴퓨팅, 스토리지 및 네트워킹 요구 사항이 유사한 경우 단일 클러스터 내에서 여러 대기열을 사용하는 것이 리소스 공유를 허용하고 불필요한 중복을 방지하기 때문에 더 효율적입니다. 이 접근 방식은 관리를 간소화하고 오버헤드를 줄이는 동시에 효율적인 작업 예약 및 리소스 할당을 허용합니다. 반면 워크로드 간에 강력한 보안, 데이터 또는 운영 격리 요구 사항이 있는 경우 여러 *클러스터*를 사용해야 합니다. 예를 들어 서로 다른 일정, 업데이트 주기 또는 액세스 정책으로 워크로드를 독립적으로 관리하고 운영해야 하는 경우 여러 클러스터가 더 적합합니다.
**클러스터 대기열 및 컴퓨팅 리소스 할당량**
| 리소스 | 할당량 |
| --- | --- |
| [`Slurm queues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) | 클러스터당 50개의 대기열 |
| [`Compute resources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) | 대기열당 50개의 컴퓨팅 리소스 클러스터당 50개의 컴퓨팅 리소스 |
노드 수****
[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) 대기열의 각 컴퓨팅 리소스에는 고유한 [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name), [`InstanceType`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-InstanceType), [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) 및 [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)가 있어야 합니다. [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) 및 [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)는 [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) 대기열의 컴퓨팅 리소스 인스턴스 범위를 정의하는 기본값이 있어야 합니다. [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) 및 [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)에 대해 고유한 값을 지정할 수도 있습니다. [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)의 각 컴퓨팅 리소스는 1에서 [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) 값 사이의 번호가 매겨진 정적 노드와 [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) 값에서 [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount) 값 사이의 번호가 매겨진 동적 노드로 구성됩니다.
구성의 예제****
다음은 클러스터 구성 파일의 [일정 예약](Scheduling-v3.md) 섹션 예제입니다. 이 구성에는 이름이 `queue1` 및 `queue2`인 대기열이 두 개 있으며 각 대기열에는 [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)가 지정된 [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)가 있습니다.
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
- InstanceType: c4.xlarge
MaxCount: 5
Name: c4xlarge
- Name: queue2
ComputeResources:
- InstanceType: c5.xlarge
MaxCount: 5
Name: c5xlarge
```
Hostnames****
컴퓨팅 플릿으로 시작되는 인스턴스는 동적으로 할당됩니다. 호스트 이름는 각 노드에 대해 생성됩니다. 기본적으로 AWS ParallelCluster 는 다음 형식의 호스트 이름을 사용합니다.
`$HOSTNAME=$QUEUE-$STATDYN-$COMPUTE_RESOURCE-$NODENUM`
+ `$QUEUE`은 대기열의 이름입니다. 예를 들어 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) 섹션에 “`queue-name`”으로 설정된 [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-Name) 항목이 있는 경우 “`$QUEUE`”는 “`queue-name`”입니다.
+ `$STATDYN`은 정적 노드에는 `st` 또는 동적 노드에는 `dy`입니다.
+ `$COMPUTE_RESOURCE`은 이 노드에 대응하는 [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) 컴퓨팅 리소스의 [`Name`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Name)입니다.
+ `$NODENUM`은 노드의 번호입니다. `$NODENUM`은 정적 노드의 경우 1과 [`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount)의 값 사이, 동적 노드의 경우 1과 [`MaxCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount)\$1[`MinCount`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MinCount) 사이입니다.
위의 예제 구성 파일에서 `queue1`와 컴퓨팅 리소스 `c5xlarge`의 특정 노드는 호스트 이름 `queue1-dy-c5xlarge-1`을 가집니다.
호스트 이름과 FQDN(정규화된 도메인 이름)은 모두 Amazon Route 53 호스팅 영역을 사용하여 생성됩니다. FQDN은 `$HOSTNAME.$CLUSTERNAME.pcluster`입니다. 여기서 `$CLUSTERNAME`는 클러스터의 이름입니다.
Slurm 노드 이름에도 동일한 형식이 사용됩니다.
사용자는에서 사용하는 기본 호스트 이름 형식 대신 컴퓨팅 노드에 전원을 공급하는 인스턴스의 기본 Amazon EC2 호스트 이름을 사용하도록 선택할 수 있습니다 AWS ParallelCluster. [`UseEc2Hostnames`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Dns-UseEc2Hostnames) 파라미터를 true로 설정하면 됩니다. 그러나 Slurm 노드 이름은 기본 AWS ParallelCluster 형식을 계속 사용합니다.
# 다중 대기열 모드를 위한 Slurm 가이드
여기에서 대기열(파티션) 노드 AWS ParallelCluster 를 Slurm 관리하고 대기열 및 노드 상태를 모니터링하는 방법을 배울 수 있습니다.
## 개요
확장 아키텍처는 Slurm의 [클라우드 스케줄링 가이드](https://slurm.schedmd.com/elastic_computing.html) 및 절전 플러그인을 기반으로 합니다. 절전 플러그인에 대한 자세한 내용은 [Slurm 절전 가이드](https://slurm.schedmd.com/power_save.html)를 참조하세요. 아키텍처에서 클러스터에 사용할 수 있는 리소스는 일반적으로 Slurm 구성에서 클라우드 노드로 미리 정의됩니다.
## 클라우드 노드 수명 주기
클라우드 노드는 수명 주기 내내 `POWER_SAVING`, `POWER_UP`(`pow_up`), `ALLOCATED`(`alloc`), `POWER_DOWN`(`pow_dn`) 상태 중 여러 개 또는 전부로 전환됩니다. 경우에 따라 클라우드 노드가 `OFFLINE` 상태로 전환될 수 있습니다. 다음 목록은 클라우드 노드 수명 주기에서 이러한 상태의 여러 측면을 자세히 설명합니다.
+ `POWER_SAVING` 상태의 노드****는 `sinfo`에서 `~` 접미사(예:`idle~`)와 함께 표시됩니다. 이 상태에서는 노드를 지원하는 EC2 인스턴스가 없습니다. 하지만 Slurm은 여전히 노드에 작업을 할당할 수 있습니다.
+ `POWER_UP` 상태로 전환되는 노드****는 `sinfo`에서 `#` 접미사(예:`idle#`)와 함께 표시됩니다. Slurm이 `POWER_SAVING` 상태의 노드에 작업을 할당하면 노드는 자동으로 `POWER_UP` 상태로 전환됩니다.
또는 다음 명령을 사용하여 `su` 루트 사용자로서 노드를 수동으로 `POWER_UP` 상태로 전환할 수 있습니다.
```
$ scontrol update nodename=nodename state=power_up
```
이 단계에서는 `ResumeProgram`이 호출되고, EC2 인스턴스가 시작 및 구성되고, 노드가 `POWER_UP` 상태로 전환됩니다.
+ 현재 사용할 수 있는 노드****는 `sinfo`에서 접미사(예:`idle`)가 없는 것으로 나타납니다. 노드가 설정되고 클러스터에 가입되면 작업을 실행할 수 있게 됩니다. 이 단계에서는 노드가 적절하게 구성되고 사용할 준비가 됩니다.
일반적으로 Amazon EC2의 인스턴스 수는 사용 가능한 노드의 수와 같게 하는 것이 좋습니다. 대부분의 경우 정적 노드는 클러스터를 생성한 후에 사용할 수 있습니다.
+ `POWER_DOWN` 상태로 전환되는 노드****는 `sinfo`에서 `%` 접미사(예:`idle%`)와 함께 표시됩니다. 동적 노드는 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 이후 `POWER_DOWN` 상태가 자동으로 입력됩니다. 반면 정적 노드는 대부분의 경우 전원이 꺼지지 않습니다. 하지만 다음 명령을 사용하여 수동으로 `su` 루트 사용자로 노드를 `POWER_DOWN` 상태에 배치할 수 있습니다.
```
$ scontrol update nodename=nodename state=down reason="manual draining"
```
이 상태에서는 노드와 연결된 인스턴스가 종료되고 노드는 다시 해당 `POWER_SAVING` 상태로 설정되며 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 이후에 사용할 수 있습니다.
[`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 설정이 Slurm 구성 `SuspendTimeout` 설정에 저장됩니다.
+ 오프라인 상태인 노드****는 `sinfo`에서 `*` 접미사(예:`down*`)와 함께 나타납니다. Slurm 컨트롤러가 노드에 연결할 수 없거나 정적 노드가 비활성화되고 지원 인스턴스가 종료되면 노드는 오프라인 상태가 됩니다.
다음 `sinfo` 예제에 표시된 노드 상태를 고려해 보세요.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 4 idle~ efa-dy-efacompute1-[1-4]
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 1 idle% gpu-dy-gpucompute1-1
gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10]
ondemand up infinite 2 mix# ondemand-dy-ondemandcompute1-[1-2]
ondemand up infinite 18 idle~ ondemand-dy-ondemandcompute1-[3-10],ondemand-dy-ondemandcompute2-[1-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 2 idle spot-st-spotcompute2-[1-2]
```
`spot-st-spotcompute2-[1-2]` 및 `efa-st-efacompute1-1` 노드에는 이미 백업 인스턴스가 설정되어 있고 사용할 수 있습니다. `ondemand-dy-ondemandcompute1-[1-2]` 노드는 현재 `POWER_UP` 상태이며 몇 분 이내에 사용할 수 있습니다. `gpu-dy-gpucompute1-1` 노드는 현재 `POWER_DOWN` 상태이고 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 이후 `POWER_SAVING` 상태로 전환됩니다(기본값 10분).
다른 모든 노드는 이를 지원하는 EC2 인스턴스가 없는 `POWER_SAVING` 상태입니다.
## 사용 가능한 노드로 작업하기
사용 가능한 노드는 Amazon EC2 인스턴스에서 지원합니다. 기본적으로 노드 이름을 사용하여 인스턴스에 직접 SSH로 연결할 수 있습니다(예:`ssh efa-st-efacompute1-1`). 다음 명령을 사용하여 인스턴스의 프라이빗 IP 주소를 검색할 수 있습니다.
```
$ scontrol show nodes nodename
```
반환된 `NodeAddr` 필드에서 IP 주소를 확인합니다.
사용할 수 없는 노드의 경우 `NodeAddr` 필드는 실행 중인 Amazon EC2 인스턴스를 가리키면 안 됩니다. 그보다는 노드 이름과 동일해야 합니다.
## 작업 상태 및 제출
대부분의 경우 제출된 작업은 시스템의 노드에 즉시 할당되거나, 모든 노드가 할당되면 보류 상태로 전환됩니다.
작업에 할당된 노드에 특정 `POWER_SAVING` 상태의 노드가 포함된 경우 작업은 `CF` 또는 `CONFIGURING` 상태로 시작됩니다. 이때 작업은 `POWER_SAVING` 상태의 노드가 해당 `POWER_UP` 상태로 전환되어 사용 가능한 상태가 될 때까지 기다립니다.
작업에 할당된 모든 노드를 사용할 수 있게 되면 작업은 `RUNNING`(`R`) 상태가 됩니다.
기본적으로 모든 작업은 기본 대기열(Slurm에서 파티션이라고 함)에 제출됩니다. 이는 대기열 이름 뒤에 `*` 접미사가 붙는 것으로 표시됩니다. `-p` 작업 제출 옵션을 사용하여 대기열을 선택할 수 있습니다.
모든 노드는 작업 제출 명령에 사용할 수 있는 다음 기능으로 구성됩니다.
+ 인스턴스 유형(예: `c5.xlarge`)
+ 노드 유형(`dynamic` 또는 `static`)
다음 명령을 사용하여 특정 노드의 특성을 확인할 수 있습니다.
```
$ scontrol show nodes nodename
```
반환할 때는 `AvailableFeatures` 목록을 확인하세요.
`sinfo` 명령을 실행하여 확인할 수 있는 클러스터의 초기 상태를 고려해 보세요.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 4 idle~ efa-dy-efacompute1-[1-4]
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 10 idle~ gpu-dy-gpucompute1-[1-10]
ondemand up infinite 20 idle~ ondemand-dy-ondemandcompute1-[1-10],ondemand-dy-ondemandcompute2-[1-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 2 idle spot-st-spotcompute2-[1-2]
```
`spot`이 기본 대기열이라는 점에 유의하세요. `*` 접미사로 표시됩니다.
기본 대깅열(`spot`)에 있는 정적 노드 하나에 작업을 제출합니다.
```
$ sbatch --wrap "sleep 300" -N 1 -C static
```
`EFA` 대기열에 있는 한 동적 노드에 작업을 제출합니다.
```
$ sbatch --wrap "sleep 300" -p efa -C dynamic
```
`ondemand` 대기열에 있는 8개의 `c5.2xlarge` 노드와 2개의 `t2.xlarge` 노드에 작업을 제출하세요.
```
$ sbatch --wrap "sleep 300" -p ondemand -N 10 -C "[c5.2xlarge*8&t2.xlarge*2]"
```
`gpu` 대기열에 있는 GPU 노드 하나에 작업을 제출하세요.
```
$ sbatch --wrap "sleep 300" -p gpu -G 1
```
`squeue` 명령을 사용하여 작업 상태를 살펴보세요.
```
$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
12 ondemand wrap ubuntu CF 0:36 10 ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
13 gpu wrap ubuntu CF 0:05 1 gpu-dy-gpucompute1-1
7 spot wrap ubuntu R 2:48 1 spot-st-spotcompute2-1
8 efa wrap ubuntu R 0:39 1 efa-dy-efacompute1-1
```
작업 7 및 8(`spot` 및 `efa` 대기열에 있음)은 이미 실행 중입니다(`R`). 작업 12와 13은 여전히 구성 중이며(`CF`), 아마도 인스턴스를 사용할 수 있을 때까지 기다리고 있을 것입니다.
```
# Nodes states corresponds to state of running jobs
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
efa up infinite 3 idle~ efa-dy-efacompute1-[2-4]
efa up infinite 1 mix efa-dy-efacompute1-1
efa up infinite 1 idle efa-st-efacompute1-1
gpu up infinite 1 mix~ gpu-dy-gpucompute1-1
gpu up infinite 9 idle~ gpu-dy-gpucompute1-[2-10]
ondemand up infinite 10 mix# ondemand-dy-ondemandcompute1-[1-8],ondemand-dy-ondemandcompute2-[1-2]
ondemand up infinite 10 idle~ ondemand-dy-ondemandcompute1-[9-10],ondemand-dy-ondemandcompute2-[3-10]
spot* up infinite 13 idle~ spot-dy-spotcompute1-[1-10],spot-dy-spotcompute2-[1-3]
spot* up infinite 1 mix spot-st-spotcompute2-1
spot* up infinite 1 idle spot-st-spotcompute2-2
```
## 노드 상태 및 특성
대부분의 경우 노드 상태는이 주제의 앞부분에서 설명한 클라우드 노드 수명 주기의 특정 프로세스에 AWS ParallelCluster 따라에서 완전히 관리됩니다.
그러나는 `DOWN` 및 `DRAINED` 상태의 비정상 노드와 비정상 지원 인스턴스가 있는 노드 AWS ParallelCluster 도 교체하거나 종료합니다. 자세한 내용은 [`clustermgtd`](processes-v3.md#clustermgtd-v3) 단원을 참조하십시오.
## 파티션 상태
AWS ParallelCluster 는 다음과 같은 파티션 상태를 지원합니다. Slurm 파티션은 AWS ParallelCluster의 대기열입니다.
+ `UP`: 파티션이 활성 상태임을 나타냅니다. 이것은 파티션의 기본 상태입니다. 이 상태에서는 파티션의 모든 노드가 활성화되어 사용할 수 있습니다.
+ `INACTIVE`: 파티션이 비활성 상태임을 나타냅니다. 이 상태에서는 비활성 파티션의 노드를 지원하는 모든 인스턴스가 종료됩니다. 비활성 파티션의 노드에 대해서는 새 인스턴스가 시작되지 않습니다.
## pcluster update-compute-fleet
+ **컴퓨팅 플릿 중지** - 다음 명령이 실행되면 모든 파티션이 `INACTIVE` 상태로 전환되고 AWS ParallelCluster 프로세스가 파티션을 `INACTIVE` 상태로 유지합니다.
```
$ pcluster update-compute-fleet --cluster-name testSlurm \
--region eu-west-1 --status STOP_REQUESTED
```
+ 컴퓨팅 플릿 시작**** - 다음 명령을 실행하면 모든 파티션이 처음에 `UP` 상태로 전환됩니다. 그러나 AWS ParallelCluster 프로세스는 파티션을 `UP` 상태로 유지하지 않습니다. 파티션 상태를 수동으로 변경해야 합니다. 몇 분 후 모든 고정 노드를 사용할 수 있습니다. 참고로 파티션을 `UP`으로 설정해도 동적 용량은 증가하지 않습니다.
```
$ pcluster update-compute-fleet --cluster-name testSlurm \
--region eu-west-1 --status START_REQUESTED
```
`update-compute-fleet`가 실행되면 `pcluster describe-compute-fleet` 명령을 실행하고 `Status`를 확인하여 클러스터의 상태를 확인할 수 있습니다. 다음과 같은 잠재적인 상태가 있습니다.
+ `STOP_REQUESTED`: 컴퓨팅 플릿 중지 요청이 클러스터로 전송됩니다.
+ `STOPPING`: `pcluster` 프로세스에서 현재 컴퓨팅 플릿을 중지하고 있습니다.
+ `STOPPED`: `pcluster` 프로세스가 중지 프로세스를 완료했고, 모든 파티션이 `INACTIVE` 상태에 있으며, 모든 컴퓨팅 인스턴스가 종료되었습니다.
+ `START_REQUESTED`: 컴퓨팅 플릿 시작 요청이 클러스터로 전송됩니다.
+ `STARTING`: `pcluster` 프로세스가 현재 클러스터를 시작하는 중입니다.
+ `RUNNING`: `pcluster` 프로세스가 시작 프로세스를 마쳤고, 모든 파티션이 `UP` 상태에 있으며, 몇 분 후에 정적 노드를 사용할 수 있습니다.
+ `PROTECTED`: 이 상태는 일부 파티션에서 일관된 부트스트랩 오류가 발생했음을 나타냅니다. 영향을 받는 파티션은 비활성 상태입니다. 문제를 조사한 다음 `update-compute-fleet` 실행하여 플릿을 다시 활성화하세요.
## 대기열 수동 제어
클러스터의 노드 또는 대기열(Slurm 파티션이라고 함)을 수동으로 제어해야 하는 경우도 있습니다. `scontrol` 명령을 사용하여 다음과 같은 일반적인 절차를 통해 클러스터의 노드를 관리할 수 있습니다.
+ **`POWER_SAVING` 상태에 있는 동적 노드의 전원을 켜세요.**
`su` 루트 사용자로 명령을 실행합니다.
```
$ scontrol update nodename=nodename state=power_up
```
특정 수의 노드를 요청하는 플레이스홀더 `sleep 1` 작업을 제출한 다음 Slurm에 의존하여 필요한 수의 노드에 전원을 공급할 수도 있습니다.
+ **[`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime) 전에 먼저 동적 노드의 전원을 끄세요.**
해당 명령을 사용하여 `su` 루트 사용자로서 동적 노드를 `DOWN`으로 설정하는 것이 좋습니다.
```
$ scontrol update nodename=nodename state=down reason="manually draining"
```
AWS ParallelCluster 는 중단된 동적 노드를 자동으로 종료하고 재설정합니다.
일반적으로 `scontrol update nodename=nodename state=power_down` 명령을 사용하여 노드를 `POWER_DOWN`으로 직접 설정하지 않는 것이 좋습니다. AWS ParallelCluster 가 전원 차단 프로세스를 자동으로 처리하기 때문입니다.
+ **대기열(파티션)을 비활성화하거나 특정 파티션의 모든 정적 노드를 중지합니다.**
해당 명령을 사용하여 `su` 루트 사용자로서 특정 대기열을 `INACTIVE`로 설정합니다.
```
$ scontrol update partition=queuename state=inactive
```
이렇게 하면 파티션의 노드를 지원하는 모든 인스턴스가 종료됩니다.
+ **대기열(파티션) 활성화**
해당 명령을 사용하여 `su` 루트 사용자로서 특정 대기열을 `UP`로 설정합니다.
```
$ scontrol update partition=queuename state=up
```
## 규모 조정 동작 및 조정
**다음은 일반적인 규모 조정 워크플로의 예입니다.**
+ 스케줄러는 두 개의 노드가 필요한 작업을 수신합니다.
+ 스케줄러는 두 노드를 `POWER_UP` 상태로 전환하고 노드 이름(예: `queue1-dy-spotcompute1-[1-2]`)을 사용하여 `ResumeProgram`을 호출합니다.
+ `ResumeProgram`은 Amazon EC2 인스턴스 두 개를 시작하고 `queue1-dy-spotcompute1-[1-2]`의 프라이빗 IP 주소와 호스트 이름을 할당합니다. 이후 `ResumeTimeout`을 기다린 후(기본 30분) 노드를 재설정합니다.
+ 인스턴스가 구성되어 클러스터에 들어갑니다. 인스턴스에서 작업이 실행되기 시작합니다.
+ 작업이 완료되고 실행이 중지됩니다.
+ 구성된 `SuspendTime`이 경과한 후([`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)로 설정되어 있음), 스케줄러는 인스턴스를 `POWER_SAVING` 상태로 설정합니다. 그러면 스케줄러가 `queue1-dy-spotcompute1-[1-2]`를 `POWER_DOWN` 상태를 설정하고 노드 이름으로 `SuspendProgram`을 호출합니다.
+ 두 노드에 대해 `SuspendProgram`이 호출됩니다. 예를 들어 노드는 `SuspendTimeout`[기본 120초(2분)]을 위해 `idle%`로 남아 있음으로써 `POWER_DOWN` 상태로 유지됩니다. 노드의 전원이 꺼지고 있음을 `clustermgtd`가 감지하면 지원 인스턴스가 종료됩니다. 그런 다음 `queue1-dy-spotcompute1-[1-2]`을 유휴 상태로 전환하고, 향후 작업을 위해 준비를 마칠 수 있도록 사설 IP 주소와 호스트 이름을 재설정합니다.
**문제가 발생하여 특정 노드의 인스턴스를 어떤 이유로 시작할 수 없는 경우 다음과 같은 상황이 발생합니다.**
+ 스케줄러는 두 개의 노드가 필요한 작업을 수신합니다.
+ 스케줄러는 두 개의 클라우드 버스팅 노드를 `POWER_UP` 상태로 전환하고 노드 이름을 사용하여 `ResumeProgram`를 호출합니다(예: `queue1-dy-spotcompute1-[1-2]`).
+ `ResumeProgram`은 Amazon EC2 인스턴스 1개만 시작하고 `queue1-dy-spotcompute1-2` 인스턴스 1개로 `queue1-dy-spotcompute1-1`를 구성하지만 시작에 실패합니다.
+ `queue1-dy-spotcompute1-1`는 영향을 받지 않으며 `POWER_UP` 상태에 도달하면 온라인 상태가 됩니다.
+ `queue1-dy-spotcompute1-2`은 `POWER_DOWN` 상태로 전환되고 Slurm이 노드 장애를 감지하므로 작업이 자동으로 대기열에 추가됩니다.
+ `queue1-dy-spotcompute1-2`은 `SuspendTimeout` 이후에 사용할 수 있습니다[기본 120초(2분)]. 그동안에는 작업이 대기되며 다른 노드에서 실행을 시작할 수 있습니다.
+ 장애가 발생하지 않고 사용 가능한 노드에서 작업을 실행할 수 있을 때까지 위 프로세스가 반복됩니다.
**필요한 경우 두 가지 타이밍 매개 변수를 조정할 수 있습니다.**
+ `ResumeTimeout`(기본값은 30분)****: `ResumeTimeout`은 Slurm가 대기하는 시간을 제어한 후 노드를 다운 상태로 전환합니다.
+ 사전/사후 설치 프로세스가 그렇게 오래 걸린다면 `ResumeTimeout`을 연장하는 것이 유용할 수 있습니다.
+ `ResumeTimeout`은 AWS ParallelCluster 가 문제가 있는 경우 노드를 교체하거나 재설정하기 전에 대기하는 최대 시간이기도 합니다. 컴퓨팅 노드는 시작 또는 설정 중에 오류가 발생하면 자체 종료됩니다. AWS ParallelCluster 프로세스가 종료된 인스턴스가 감지되면 노드를 대체합니다.
+ `SuspendTimeout`[기본 120초(2분)]****: `SuspendTimeout`이 노드를 시스템에 다시 배치하고 다시 사용할 준비가 되는 시간을 제어합니다.
+ `SuspendTimeout`이 짧을수록 노드가 더 빨리 재설정되고, Slurm는 인스턴스를 더 자주 시작하려고 할 수 있습니다.
+ `SuspendTimeout`이 길수록 장애가 발생한 노드의 재설정 속도가 느려집니다. 그러는 동안 Slurm은 다른 노드를 사용하려고 합니다. `SuspendTimeout`이 몇 분 이상이면 Slurm가 시스템의 모든 노드를 순환하려 합니다. 대규모 시스템(1,000개 이상의 노드)에서는 Slurm가 받는 스트레스를 줄이기 위해 장애가 발생한 작업을 다시 대기열에 추가하려고 할 때 더 긴 `SuspendTimeout`을 사용하는 것이 유용할 수 있습니다.
+ `SuspendTimeout`는가 노드의 백업 인스턴스를 종료하기 위해 AWS ParallelCluster 대기하는 시간을 참조하지 않습니다. `POWER_DOWN` 노드의 백업 인스턴스는 즉시 종료됩니다. 종료 프로세스는 일반적으로 몇 분 이내에 완료됩니다. 하지만 이 기간 동안에는 노드가 `POWER_DOWN` 상태를 유지하며 스케줄러가 사용할 수 없습니다.
## 아키텍처 로그
다음 목록 키 로그를 포함합니다. Amazon CloudWatch Logs에 사용되는 로그 스트림 이름은 `{hostname}.{instance_id}.{logIdentifier}` 형식을 사용합니다. 여기서 *LogiDentifier*는 로그 이름 뒤에 옵니다.
+ `ResumeProgram`: `/var/log/parallelcluster/slurm_resume.log` (`slurm_resume`)
+ `SuspendProgram`: `/var/log/parallelcluster/slurm_suspend.log` (`slurm_suspend`)
+ `clustermgtd`: `/var/log/parallelcluster/clustermgtd.log` (`clustermgtd`)
+ `computemgtd`: `/var/log/parallelcluster/computemgtd.log` (`computemgtd`)
+ `slurmctld`: `/var/log/slurmctld.log` (`slurmctld`)
+ `slurmd`: `/var/log/slurmd.log` (`slurmd`)
## 일반적인 문제 및 디버그 방법:
**시작, 전원 켜기 또는 클러스터 조인에 실패한 노드**
+ 동적 노드:
+ `ResumeProgram` 로그를 확인하여 노드와 함께 `ResumeProgram` 호출되었는지 확인하세요. 그렇지 않은 경우 `slurmctld` 로그를 확인하여 Slurm가 노드로 `ResumeProgram`을 호출하려 했는지 확인하세요. `ResumeProgram` 권한이 올바르지 않으면 로그가 자동으로 실패할 수 있다는 점에 유의하세요.
+ `ResumeProgram`가 호출되면 해당 노드에 대한 인스턴스가 시작되었는지 확인하세요. 인스턴스가 시작되지 않은 경우 인스턴스 시작 실패 이유에 대한 명확한 오류 메시지가 표시되어야 합니다.
+ 인스턴스가 시작된 경우 부트스트랩 프로세스 중에 문제가 발생했을 수 있습니다. `ResumeProgram` 로그에서 해당 프라이빗 IP 주소와 인스턴스 ID를 찾고 CloudWatch Logs에서 특정 인스턴스에 대한 해당 부트스트랩 로그를 확인합니다.
+ 고정 노드:
+ `clustermgtd` 로그를 확인하여 해당 노드의 인스턴스가 시작되었는지 확인합니다. 인스턴스가 시작되지 않았다면 인스턴스 시작 실패 이유에 대한 명확한 오류가 있을 것입니다.
+ 인스턴스가 시작된 경우 부트스트랩 프로세스에 문제가 있는 것입니다. `clustermgtd` 로그에서 해당 프라이빗 IP와 인스턴스 ID를 찾고 CloudWatch Logs에서 특정 인스턴스에 대한 해당 부트스트랩 로그를 확인합니다.
**노드가 예기치 않게 교체되거나 종료되었으며, 노드 장애가 발생했습니다.**
+ 노드가 예기치 않게 교체/종료됨:
+ 대부분의 경우 `clustermgtd`가 모든 노드 유지 관리 작업을 처리합니다. `clustermgtd`가 노드를 교체하거나 종료했는지를 확인하려면 `clustermgtd` 로그를 확인하세요.
+ `clustermgtd`가 노드를 교체하거나 종료한 경우 작업 이유를 나타내는 메시지가 표시되어야 합니다. 이유가 스케줄러와 관련된 경우(예: 노드가 `DOWN`이었음) `slurmctld` 로그에서 자세한 내용을 확인하세요. 이유가 Amazon EC2와 관련된 경우 Amazon CloudWatch 또는 Amazon EC2 콘솔, CLI 또는 SDK와 같은 도구를 사용하여 해당 인스턴스의 상태 또는 로그를 확인하세요. 예를 들어 인스턴스에 예약된 이벤트가 있는지 또는 Amazon EC2 상태 확인에 실패했는지 확인할 수 있습니다.
+ `clustermgtd`가 노드를 종료하지 않은 경우 `computemgtd`가 노드를 종료했는지 또는 EC2가 스팟 인스턴스를 회수하기 위해 인스턴스를 종료했는지 확인하세요.
+ 노드 장애:
+ 대부분의 경우 노드에 장애가 발생하면 작업이 자동으로 대기열에 추가됩니다. `slurmctld` 로그에서 작업이나 노드에 장애가 발생한 이유를 확인하고 거기에서 상황을 평가하세요.
인스턴스 교체 또는 종료 시 실패, 노드 전원 차단 시 실패****
+ 일반적으로 `clustermgtd`가 모든 예상 인스턴스 종료 작업을 처리합니다. `clustermgtd` 로그에서 노드 교체 또는 종료에 실패한 이유를 확인하세요.
+ 동적 노드가 [`ScaledownIdletime`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ScaledownIdletime)에 실패한 경우 `SuspendProgram` 로그에서 `slurmctld` 프로세스가 특정 노드를 인수로 사용하여 호출했는지 확인하세요. `SuspendProgram`는 실제로 특정 작업을 수행하지 않습니다. 그보다는 호출될 때만 로그를 기록합니다. 모든 인스턴스 종료 및 `NodeAddr` 재설정은 `clustermgtd`가 완료합니다. Slurm는 `SuspendTimeout` 후 노드를 `IDLE`로 전환합니다.
기타 문제:****
+ AWS ParallelCluster 는 작업 할당 또는 조정 결정을 내리지 않습니다. Slurm의 지침에 따라 리소스를 시작, 종료 및 유지 관리하려고 시도할 뿐입니다.
작업 할당, 노드 할당 및 규모 조정 결정과 관련된 문제는 `slurmctld` 로그에서 오류를 확인하세요.
# Slurm 클러스터 보호 모드
보호 모드가 활성화된 상태로 클러스터가 실행되면는 컴퓨팅 노드가 시작될 때 컴퓨팅 노드 부트스트랩 실패를 AWS ParallelCluster 모니터링하고 추적합니다. 이는 이러한 장애가 지속적으로 발생하는지 여부를 감지하기 위한 것입니다.
대기열(파티션)에서 다음이 감지되면 클러스터는 보호 상태로 전환됩니다.
1. 연이은 컴퓨팅 노드 부트스트랩 장애가 계속 발생하며 컴퓨팅 노드가 성공적으로 시작되지 않습니다.
1. 실패 수가 사전 정의된 임계값에 도달했습니다.
클러스터가 보호 상태로 전환되면는 사전 정의된 임계값 이상으로 장애가 발생한 대기열을 AWS ParallelCluster 비활성화합니다.
Slurm 클러스터 보호 모드가 AWS ParallelCluster 버전 3.0.0에 추가되었습니다.
보호 모드를 사용하면 컴퓨팅 노드 부트스트랩 장애 사이클링에 소요되는 시간과 리소스를 줄일 수 있습니다.
## 보호 모드 파라미터
**`protected_failure_count`**
`protected_failure_count`는 클러스터 보호 상태를 활성화하는 대기열(파티션)의 연속 실패 수를 지정합니다.
기본값 `protected_failure_count`는 10이며 보호 모드가 활성화되어 있습니다.
`protected_failure_count`가 0보다 크면 보호 모드가 활성화됩니다.
`protected_failure_count`가 0보다 작거나 같으면 보호 모드가 비활성화됩니다.
`HeadNode`의 `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf`에 있는 `clustermgtd` 구성 파일에 파라미터를 추가하여 `protected_failure_count` 값을 변경할 수 있습니다.
이 파라미터는 언제든지 업데이트할 수 있으며 이를 위해 컴퓨팅 플릿을 중지할 필요가 없습니다. 실패 횟수가 `protected_failure_count`에 도달하기 전에 대기열에서 시작이 성공하면 실패 횟수가 0으로 재설정됩니다.
## 보호된 상태에서 클러스터 상태를 확인합니다.
클러스터가 보호 상태인 경우 컴퓨팅 플릿 상태와 노드 상태를 확인할 수 있습니다.
### 컴퓨팅 플릿 상태
컴퓨팅 플릿의 상태는 보호 상태로 실행 중인 클러스터에 있는 `PROTECTED`입니다.
```
$ pcluster describe-compute-fleet --cluster-name --region
{
"status": "PROTECTED",
"lastStatusUpdatedTime": "2022-04-22T00:31:24.000Z"
}
```
### 노드 상태
보호 상태를 활성화한 부트스트랩 장애가 발생한 대기열(파티션)을 알아보려면 클러스터에 로그인하고 `sinfo` 명령을 실행하세요. 부트스트랩 실패 횟수가 `protected_failure_count` 이상인 파티션은 현재 `INACTIVE` 상태입니다. 부트스트랩 실패 횟수가 `protected_failure_count` 이상이 아닌 파티션은 `UP` 상태이며 예상대로 작동합니다.
`PROTECTED` 상태는 실행 중인 작업에 영향을 주지 않습니다. 부트스트랩 실패 횟수가 `protected_failure_count` 이상인 파티션에서 작업이 실행되는 경우 해당 파티션은 실행 중인 작업이 완료된 후 `INACTIVE`로 설정됩니다.
다음 예제에 표시된 노드 상태를 고려해 보세요.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* inact infinite 10 down% queue1-dy-c5xlarge-[1-10]
queue1* inact infinite 3490 idle~ queue1-dy-c5xlarge-[11-3500]
queue2 up infinite 10 idle~ queue2-dy-c5xlarge-[1-10]
```
파티션 `queue1`이 `INACTIVE`인 이유는 10개의 연속적인 컴퓨팅 노드 부트스트랩 장애가 감지되었기 때문입니다.
노드 뒤에 있는 인스턴스가 `queue1-dy-c5xlarge-[1-10]`를 시작했지만 비정상 상태로 인해 클러스터에 조인하지 못했습니다.
클러스터가 보호 상태에 있습니다.
`queue1`의 부트스트랩 실패는 파티션 `queue2`에 영향을 주지 않습니다. `UP` 상태이며 여전히 작업을 실행할 수 있습니다.
## 보호 상태를 비활성화하는 방법
부트스트랩 오류가 해결된 후 다음 명령을 실행하여 클러스터를 보호 상태에서 해제할 수 있습니다.
```
$ pcluster update-compute-fleet --cluster-name \
--region \
--status START_REQUESTED
```
## 보호 상태를 활성화하는 부트스트랩 장애
보호 상태를 활성화하는 부트스트랩 오류는 다음 세 가지 유형으로 세분됩니다. 유형과 문제를 식별하기 위해 AWS ParallelCluster 생성된 로그가 있는지 확인할 수 있습니다. 로그가 생성된 경우 해당 로그에서 오류 세부 정보를 확인할 수 있습니다. 자세한 내용은 [로그 검색 및 보존](troubleshooting-v3-get-logs.md) 단원을 참조하십시오.
1. 부트스트랩 오류로 인해 인스턴스가 자체 종료됩니다****.
부트스트랩 프로세스 초기에 인스턴스가 실패합니다. 예를 들어 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`CustomActions`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-CustomActions)/[`OnNodeStart`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeStart)/[`OnNodeConfigured`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomActions-OnNodeConfigured) 스크립트의 오류로 인해 자체 종료되는 인스턴스가 있습니다.
동적 노드의 경우 다음과 비슷한 오류가 있는지 확인하세요.
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
정적 노드의 경우 `clustermgtd` 로그(`/var/log/parallelcluster/clustermgtd`)에서 다음과 비슷한 오류가 있는지 확인하세요.
```
Node bootstrap error: Node ... is in power up state without valid backing instance
```
1. 노드 `resume_timeout` 또는 `node_replacement_timeout` 만료.****
인스턴스는 `resume_timeout`(동적 노드의 경우) 또는 `node_replacement_timeout`(정적 노드의 경우) 내에서 클러스터에 조인할 수 없습니다. 타임아웃 전에는 자체 종료되지 않습니다. 예를 들어 클러스터에 네트워킹이 제대로 설정되지 않고 노드가 제한 시간 만료 후 Slurm에 의해 `DOWN` 상태로 설정됩니다.
동적 노드의 경우 다음과 비슷한 오류가 있는지 확인하세요.
```
Node bootstrap error: Resume timeout expires for node
```
정적 노드의 경우 `clustermgtd` 로그(`/var/log/parallelcluster/clustermgtd`)에서 다음과 비슷한 오류가 있는지 확인하세요.
```
Node bootstrap error: Replacement timeout expires for node ... in replacement.
```
1. 노드 상태 확인에 실패****.
노드 뒤에 있는 인스턴스가 Amazon EC2 상태 확인 또는 예정된 이벤트 상태 확인에 실패하고, 해당 노드는 부트스트랩 장애 노드로 간주됩니다. 이 경우 인스턴스는 제어 범위를 벗어난 이유로 종료됩니다 AWS ParallelCluster.
`clustermgtd` 로그(`/var/log/parallelcluster/clustermgtd`)에서 다음과 비슷한 오류가 있는지 확인하세요.
```
Node bootstrap error: Node %s failed during bootstrap when performing health check.
```
1. 컴퓨팅 노드가 Slurm 등록에 실패****.
Slurm 제어 대몬(daemon)(`slurmctld`)을 통한 `slurmd` 대몬(daemon) 등록이 실패하고 컴퓨팅 노드 상태가 `INVALID_REG` 상태로 변경됩니다. 잘못 구성된 Slurm 컴퓨팅 노드로 인해 이 오류가 발생할 수 있습니다(예: [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings) 컴퓨팅 노드 사양 오류로 구성된 컴퓨팅 노드).
헤드 노드의 `slurmctld` 로그 파일(`/var/log/slurmctld.log`) 또는 장애가 발생한 컴퓨팅 노드의 `slurmd` 로그 파일(`/var/log/slurmd.log`)에서 다음과 유사한 오류가 있는지 확인하세요.
```
Setting node %s to INVAL with reason: ...
```
## 보호 모드를 디버깅하는 방법
클러스터가 보호 상태이고에서 `clustermgtd` 로그`HeadNode`를 생성하고 문제가 있는 컴퓨팅 노드에서 `cloud-init-output` 로그를 AWS ParallelCluster 생성한 경우 로그에서 오류 세부 정보를 확인할 수 있습니다. 로그 검색에 대한 자세한 내용은 [로그 검색 및 보존](troubleshooting-v3-get-logs.md) 섹션을 참조하세요.
헤드 노드의 `clustermgtd` 로그(`/var/log/parallelcluster/clustermgtd`)****
로그 메시지에는 부트스트랩 오류가 발생한 파티션과 해당 부트스트랩 실패 수가 표시됩니다.
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - INFO - Partitions
bootstrap failure count: {'queue1': 2}, cluster will be set into protected mode if protected failure count reach threshold.
```
`clustermgtd` 로그에서 `Found the following bootstrap failure nodes`를 검색하여 부트스트랩에 실패한 노드를 찾으세요.
```
[slurm_plugin.clustermgtd:_handle_protected_mode_process] - WARNING -
Found the following bootstrap failure nodes: (x2) ['queue1-st-c5large-1(192.168.110.155)', 'broken-st-c5large-2(192.168.65.215)']
```
`clustermgtd` 로그에서 `Node bootstrap error`를 검색하여 실패 원인을 찾으세요.
```
[slurm_plugin.clustermgtd:_is_node_bootstrap_failure] - WARNING - Node bootstrap error:
Node broken-st-c5large-2(192.168.65.215) is currently in replacement and no backing instance
```
컴퓨팅 노드의 `cloud-init-output`로그(`/var/log/cloud-init-output.log`)****
`clustermgtd` 로그에서 부트스트랩 장애 노드 프라이빗 IP 주소를 획득한 후 컴퓨팅 노드에 로그인하거나 지침에 따라 [로그 검색 및 보존](troubleshooting-v3-get-logs.md)에서 로그를 검색하여 해당 컴퓨팅 노드 로그를 찾을 수 있습니다. 대부분의 경우 문제가 있는 노드의 `/var/log/cloud-init-output` 로그에는 컴퓨팅 노드 부트스트랩 장애를 일으킨 단계가 나와 있습니다.
# Slurm 클러스터 빠른 용량 부족 장애 조치
AWS ParallelCluster 버전 3.2.0부터 클러스터는 기본적으로 빠른 용량 부족 장애 조치 모드가 활성화된 상태로 실행됩니다. 이렇게 하면 Amazon EC2 용량 부족 오류가 감지될 때 작업을 대기열에 재시도하는 데 소요되는 시간을 최소화할 수 있습니다. 이는 다른 인스턴스 유형을 사용하는 여러 컴퓨팅 리소스로 대기열을 구성할 때 특히 효과적입니다.
**Amazon EC2에서 용량 부족 장애를 감지했습니다.**
+ `InsufficientInstanceCapacity`
+ `InsufficientHostCapacity`
+ `InsufficientReservedInstanceCapacity`
+ `MaxSpotInstanceCountExceeded`
+ `SpotMaxPriceTooLow`: 스팟 요청 가격이 필요한 최소 스팟 요청 이행 가격보다 낮습니다.
+ `Unsupported`: 특정에서 지원되지 않는 인스턴스 유형을 사용하여 활성화됩니다 AWS 리전.
빠른 용량 부족 장애 조치 모드에서 작업이 [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) /에 할당될 때 용량 부족 오류가 감지되면는 다음을 [`compute resource`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) AWS ParallelCluster 수행합니다.
1. 미리 정의된 기간 동안 컴퓨팅 리소스를 비활성화(`DOWN`) 상태로 설정합니다.
1. 컴퓨팅 리소스 장애가 발생한 노드 작업을 취소하고 장애가 발생한 노드를 일시 중단하기 위해 `POWER_DOWN_FORCE`를 사용합니다. 장애가 발생한 노드를 `IDLE` 및 `POWER_DOWN (!)` 상태로 설정한 다음, `POWERING_DOWN (%)`로 설정합니다.
1. 작업을 다른 컴퓨팅 리소스에 대기열에 추가합니다.
비활성화된 컴퓨팅 리소스의 정적 노드와 전원이 켜진 노드는 영향을 받지 않습니다. 이러한 노드에서 작업을 완료할 수 있습니다.
이 주기는 작업이 컴퓨팅 리소스 노드 또는 여러 노드에 성공적으로 할당될 때까지 반복됩니다. 노드 상태에 대한 내용은 [다중 대기열 모드를 위한 Slurm 가이드](multiple-queue-mode-slurm-user-guide-v3.md) 섹션을 참조하세요.
작업을 실행할 컴퓨팅 리소스가 없는 경우 작업은 미리 정의된 기간이 경과할 때까지 `PENDING` 상태로 설정됩니다. 이 경우 다음 섹션에 설명된 대로 사전 정의된 기간을 수정할 수 있습니다.
## 용량 제한 시간 초과 파라미터 부족
**`insufficient_capacity_timeout`**
`insufficient_capacity_timeout` 용량 부족 오류가 감지된 경우 컴퓨팅 리소스가 비활성화(`down`) 상태로 유지되는 기간(초)을 지정합니다.
기본값은 `insufficient_capacity_timeout`가 활성화됩니다.
`insufficient_capacity_timeout`의 기본값은 600초(10분)입니다.
`insufficient_capacity_timeout` 값이 0보다 작거나 같으면 빠른 용량 부족 장애 조치 모드가 비활성화됩니다.
`HeadNode`의 `/etc/parallelcluster/slurm_plugin/parallelcluster_clustermgtd.conf`에 있는 `clustermgtd` 구성 파일에 파라미터를 추가하여 `insufficient_capacity_timeout` 값을 변경할 수 있습니다.
컴퓨팅 플릿을 중지하지 않고도 언제든지 파라미터를 업데이트할 수 있습니다.
예제:
+ `insufficient_capacity_timeout=600`:
용량 부족 오류가 감지되면 컴퓨팅 리소스가 비활성화(`DOWN`)로 설정됩니다. 10분 후 장애가 발생한 노드는 `idle~`(`POWER_SAVING`) 상태로 설정됩니다.
+ `insufficient_capacity_timeout=60`:
용량 부족 오류가 감지되면 컴퓨팅 리소스는 비활성화(`DOWN`) 상태가 됩니다. 1분 후 장애가 발생한 노드는 `idle~` 상태로 설정됩니다.
+ `insufficient_capacity_timeout=0`:
빠른 용량 부족 장애 조치 모드가 비활성화되었습니다. 컴퓨팅 리소스는 비활성화되지 않았습니다.
**참고**
용량 부족 오류로 인해 노드에 장애가 발생하는 시간과 클러스터 관리 대몬(daemon)이 노드 장애를 감지하는 시간 사이에는 최대 1분의 지연이 있을 수 있습니다. 이는 클러스터 관리 데몬이 노드 용량 부족 장애를 확인하고 컴퓨팅 리소스를 1분 간격으로 `down` 상태로 설정하기 때문입니다.
## 빠른 용량 부족 장애 조치 모드 상태
클러스터가 빠른 용량 부족 장애 조치 모드에 있는 경우 클러스터의 상태와 노드 상태를 확인할 수 있습니다.
### 노드 상태
컴퓨팅 리소스 동적 노드에 작업이 제출되고 용량 부족 오류가 감지되면 해당 노드는 이유가 있는 `down#` 상태로 전환됩니다.
```
(Code:InsufficientInstanceCapacity)Failure when resuming nodes.
```
그러면 전원이 꺼진 노드(`idle~` 상태의 노드)가 이유가 있는 `down~`로 설정됩니다.
```
(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity.
```
작업은 대기열에 있는 다른 컴퓨팅 리소스로 대기열에 추가됩니다.
컴퓨팅 리소스 정적 노드 및 `UP`이 빠른 용량 부족 장애 조치 모드의 영향을 받지 않는 노드입니다.
다음 예제에 표시된 노드 상태를 고려해 보세요.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
노드 하나가 필요한 작업을 queue1에 제출합니다.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 1 down# queue1-dy-c-1-1
queue1* up infinite 15 idle~ queue1-dy-c-2-[1-15]
queue1* up infinite 14 down~ queue1-dy-c-1-[2-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
작업을 실행하기 위해 노드 `queue1-dy-c-1-1`이 시작됩니다. 그러나 용량 부족 오류로 인해 인스턴스가 시작되지 않았습니다. 노드 `queue1-dy-c-1-1`이 `down`으로 설정되었습니다. 컴퓨팅 리소스(`queue2-dy-c-1`) 내의 전원이 꺼진 동적 노드는 `down`으로 설정되어 있습니다.
`scontrol show nodes`로 노드 이유를 확인할 수 있습니다.
```
$ scontrol show nodes queue1-dy-c-1-1
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Failure when resuming nodes [root@2022-03-10T22:17:50]
$ scontrol show nodes queue1-dy-c-1-2
NodeName=broken-dy-c-2-1 Arch=x86_64 CoresPerSocket=1
CPUAlloc=0 CPUTot=96 CPULoad=0.00
...
ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s
Reason=(Code:InsufficientInstanceCapacity)Temporarily disabling node due to insufficient capacity [root@2022-03-10T22:17:50]
```
작업이 대기열 컴퓨팅 리소스 내의 다른 인스턴스 유형에 대기됩니다.
`insufficient_capacity_timeout`이 경과하면 컴퓨팅 리소스의 노드가 `idle~` 상태로 재설정됩니다.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 30 idle~ queue1-dy-c-1-[1-15],queue1-dy-c-2-[1-15]
queue2 up infinite 30 idle~ queue2-dy-c-1-[1-15],queue2-dy-c-2-[1-15]
```
`insufficient_capacity_timeout`이 경과하고 컴퓨팅 리소스의 노드가 해당 `idle~` 상태로 재설정되면, Slurm 스케줄러는 노드에 더 낮은 우선 순위를 부여합니다. 스케줄러는 다음 중 하나가 발생하지 않는 한 가중치가 더 높은 다른 대기열 컴퓨팅 리소스에서 노드를 계속 선택합니다.
+ 작업 제출 요구 사항은 복구된 컴퓨팅 리소스와 일치합니다.
+ 용량이 충분하기 때문에 다른 컴퓨팅 리소스를 사용할 수 없습니다.
+ `slurmctld`가 다시 시작됩니다.
+ AWS ParallelCluster 컴퓨팅 플릿이 중지되고 모든 노드의 전원이 꺼지고 켜지기 시작합니다.
### 관련 로그
용량 부족 오류 및 빠른 용량 부족 장애 조치 모드와 관련된 로그는 Slurm의 `resume` 로그 및 헤드 노드의 `clustermgtd` 로그에서 확인할 수 있습니다.
**Slurm `resume` (`/var/log/parallelcluster/slurm_resume.log`)**
용량이 부족하여 노드 시작에 실패할 때 나타나는 오류 메시지.
```
[slurm_plugin.instance_manager:_launch_ec2_instances] - ERROR - Failed RunInstances request: dcd0c252-90d4-44a7-9c79-ef740f7ecd87
[slurm_plugin.instance_manager:add_instances_for_nodes] - ERROR - Encountered exception when launching instances for nodes (x1) ['queue1-dy-c-1-1']: An error occurred
(InsufficientInstanceCapacity) when calling the RunInstances operation (reached max retries: 1): We currently do not have sufficient p4d.24xlarge capacity in the
Availability Zone you requested (us-west-2b). Our system will be working on provisioning additional capacity. You can currently get p4d.24xlarge capacity by not
specifying an Availability Zone in your request or choosing us-west-2a, us-west-2c.
```
**Slurm `clustermgtd` (`/var/log/parallelcluster/clustermgtd`)**
용량이 부족하여 queue1의 컴퓨팅 리소스 c-1이 비활성화되었습니다.
```
[slurm_plugin.clustermgtd:_reset_timeout_expired_compute_resources] - INFO - The following compute resources are in down state
due to insufficient capacity: {'queue1': {'c-1': ComputeResourceFailureEvent(timestamp=datetime.datetime(2022, 4, 14, 23, 0, 4, 769380, tzinfo=datetime.timezone.utc),
error_code='InsufficientInstanceCapacity')}}, compute resources are reset after insufficient capacity timeout (600 seconds) expired
```
용량 부족 제한 시간이 만료되면 컴퓨팅 리소스가 재설정되고 컴퓨팅 리소스 내의 노드는 `idle~`로 설정됩니다.
```
[root:_reset_insufficient_capacity_timeout_expired_nodes] - INFO - Reset the following compute resources because insufficient capacity
timeout expired: {'queue1': ['c-1']}
```
# Slurm 메모리 기반 스케줄링
버전 3.2.0부터는 [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings) / [`EnableMemoryBasedScheduling`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-EnableMemoryBasedScheduling) 클러스터 구성 파라미터를 사용한 Slurm 메모리 기반 예약을 AWS ParallelCluster 지원합니다.
**참고**
AWS ParallelCluster 버전 3.7.0부터 인스턴스에서 여러 인스턴스 유형을 구성하는 경우를 활성화`EnableMemoryBasedScheduling`할 수 있습니다. [](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
AWS ParallelCluster 버전 3.2.0\$13.6.*x*의 경우 [인스턴스](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)에서 여러 인스턴스 유형을 구성하는 경우를 활성화`EnableMemoryBasedScheduling`할 수 없습니다.
**주의**
`EnableMemoryBasedScheduling`이 활성화된 상태에서 Slurm 대기열 컴퓨팅 리소스에 여러 인스턴스 유형을 지정하는 경우 `RealMemory` 값은 모든 인스턴스 유형에 사용할 수 있는 최소 메모리 양입니다. 메모리 용량이 매우 다른 인스턴스 유형을 지정하는 경우 이로 인해 사용되지 않은 메모리가 상당량 발생할 수 있습니다.
`EnableMemoryBasedScheduling: true`를 사용하면, Slurm 스케줄러가 각 노드에서 각 작업에 필요한 메모리 양을 추적합니다. 그런 다음 Slurm 스케줄러는 이 정보를 사용하여 동일한 컴퓨팅 노드에서 여러 작업을 스케줄링합니다. 노드에서 작업에 필요한 총 메모리 양은 사용 가능한 노드 메모리보다 클 수 없습니다. 스케줄러는 작업이 제출될 때 요청된 것보다 더 많은 메모리를 작업이 사용하지 않도록 합니다.
`EnableMemoryBasedScheduling: false`를 사용하면 공유 노드의 메모리를 놓고 작업이 경쟁하여 작업 실패 및 `out-of-memory` 이벤트가 발생할 수 있습니다.
**주의**
Slurm은 레이블에 2의 거듭제곱 표기법(예: MB 또는 GB)을 사용합니다. 이 레이블을 각각 MiB 및 GiB로 읽습니다.
## Slurm 구성 및 메모리 기반 스케줄링
`EnableMemoryBasedScheduling: true`를 사용하면 Slurm는 다음과 같은 Slurm 구성 파라미터를 설정합니다.
+ `slurm.conf`의 [https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory](https://slurm.schedmd.com/slurm.conf.html#OPT_CR_CPU_Memory). 이 옵션은 노드 메모리를 Slurm에서 사용 가능한 리소스로 구성합니다.
+ Slurm `cgroup.conf`의 [https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace](https://slurm.schedmd.com/cgroup.conf.html#OPT_ConstrainRAMSpace). 이 옵션을 사용하면 작업이 제출될 때 요청한 메모리 양만큼 작업의 메모리 액세스가 제한됩니다.
**참고**
이 두 옵션이 설정된 경우 다른 여러 Slurm 구성 파라미터가 Slurm 스케줄러 및 리소스 관리자의 동작에 영향을 줄 수 있습니다. 자세한 내용은 [Slurm 설명서](https://slurm.schedmd.com/documentation.html)를 참조하세요.
## Slurm 스케줄러 및 메모리 기반 스케줄링
**`EnableMemoryBasedScheduling: false`(기본값)**
기본적으로 `EnableMemoryBasedScheduling`는 false로 설정됩니다. false인 경우, Slurm은 스케줄링 알고리즘에 메모리를 리소스로 포함하지 않으며 작업에서 사용하는 메모리를 추적하지 않습니다. 사용자는 작업에 필요한 노드당 최소 메모리 양을 설정하는 `--mem MEM_PER_NODE` 옵션을 지정할 수 있습니다. 이렇게 하면 스케줄러는 작업을 예약할때 `RealMemory` 값이 최소한 `MEM_PER_NODE`인 노드를 선택해야 합니다.
예를 들어, 한 사용자가 `--mem=5GB`를 사용하여 두 개의 작업을 제출한다고 가정해 보겠습니다. CPU 또는 GPU와 같은 요청된 리소스를 사용할 수 있는 경우 8GiB 메모리가 있는 노드에서 작업을 동시에 실행할 수 있습니다. 이 두 작업은 `RealMemory` 5GiB 미만의 컴퓨팅 노드에서는 스케줄되지 않습니다.
**주의**
메모리 기반 스케줄링이 비활성화되면 Slurm은 작업에서 사용하는 메모리 양을 추적하지 않습니다. 동일한 노드에서 실행되는 작업은 메모리 리소스를 놓고 경쟁하여 다른 작업이 실패할 수 있습니다.
메모리 기반 스케줄링을 사용하지 않도록 설정한 경우에는 사용자가 [https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-cpu) 또는 [https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu](https://slurm.schedmd.com/srun.html#OPT_mem-per-gpu) 옵션을 지정하지 않는 것이 좋습니다. 이러한 옵션으로 인해 [Slurm 설명서](https://slurm.schedmd.com/documentation.html)에 설명된 것과 다른 동작이 발생할 수 있습니다.
**`EnableMemoryBasedScheduling: true`**
`EnableMemoryBasedScheduling`를 true로 설정하면 Slurm은 각 작업의 메모리 사용량을 추적하여 `--mem` 제출 옵션에서 요청한 것보다 많은 메모리를 작업에 사용하지 않도록 합니다.
이전 예제를 사용하면 한 사용자가 `--mem=5GB`를 사용하여 두 개의 작업을 제출합니다. 메모리가 8GiB인 노드에서는 작업을 동시에 실행할 수 없습니다. 필요한 총 메모리 양이 노드에서 사용 가능한 메모리보다 많기 때문입니다.
메모리 기반 스케줄링이 활성화된 상태에서 `--mem-per-cpu` 및 `--mem-per-gpu`는 Slurm 설명서에 설명된 것과 일관되게 작동합니다. 예를 들어, 작업이 `--ntasks-per-node=2 -c 1 --mem-per-cpu=2GB`로 제출됩니다. 이 경우 Slurm은 각 노드에 총 4GiB를 작업에 할당합니다.
**주의**
메모리 기반 스케줄링이 활성화된 경우 사용자가 작업을 제출할 때 `--mem` 사양을 포함하는 것이 좋습니다. 에 포함된 기본 Slurm 구성의 경우 메모리 옵션( AWS ParallelCluster,`--mem` `--mem-per-cpu`또는 `--mem-per-gpu`)이 포함되지 않은 경우는 CPUs 또는 GPU와 같은 다른 리소스의 일부만 요청하더라도 할당된 노드의 전체 메모리를 작업에 Slurm 할당합니다. GPUs 이렇게 하면 다른 작업에 사용할 수 있는 메모리가 없으므로 작업이 완료될 때까지 노드 공유를 효과적으로 방지할 수 있습니다. 이는 작업 제출 시 메모리 사양이 제공되지 않은 경우 Slurm이 작업의 노드당 메모리를 [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerNode)로 설정하기 때문에 발생합니다. 이 파라미터의 기본값은 0이며 노드 메모리에 대한 무제한 액세스를 지정합니다.
동일한 대기열에 메모리 양이 다른 여러 유형의 컴퓨팅 리소스가 있는 경우 메모리 옵션 없이 제출된 작업에는 노드마다 다른 양의 메모리가 할당될 수 있습니다. 이는 스케줄러가 작업에 사용할 수 있는 노드에 따라 달라집니다. 사용자는 Slurm 구성 파일의 클러스터 또는 파티션 수준에서 `DefMemPerNode` 또는 [https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU](https://slurm.schedmd.com/slurm.conf.html#OPT_DefMemPerCPU) 같은 옵션에 대한 사용자 지정 값을 정의하여 이러한 동작을 방지할 수 있습니다.
## Slurm RealMemory 및 AWS ParallelCluster SchedulableMemory
는 함께 제공되는 Slurm 구성을 사용하여 [RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory)를 작업에 사용할 수 있는 노드당 메모리 양으로 AWS ParallelClusterSlurm 해석합니다. 버전 3.2.0부터 기본적으로는 [Amazon EC2 인스턴스 유형에 나열](https://aws.amazon.com/ec2/instance-types)되고 Amazon EC2 API [DescribeInstanceTypes](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceTypes.html)에서 반환되는 메모리의 `RealMemory` 95%로 AWS ParallelCluster 설정됩니다.
메모리 기반 스케줄링이 비활성화되면 Slurm 스케줄러는 사용자가 `RealMemory`를 사용해서 `--mem`이 지정된 작업을 제출할 때 노드를 필터링합니다.
메모리 기반 스케줄링이 활성화된 경우 Slurm 스케줄러는 `RealMemory`를 컴퓨팅 노드에서 실행 중인 작업에 사용할 수 있는 최대 메모리 양으로 해석합니다.
기본 설정은 모든 인스턴스 유형에 적합하지 않을 수 있습니다.
+ 이 설정은 노드가 실제로 액세스할 수 있는 메모리 양보다 많을 수 있습니다. 이는 컴퓨팅 노드가 작은 인스턴스 유형일 때 발생할 수 있습니다.
+ 이 설정은 노드가 실제로 액세스할 수 있는 메모리 양보다 적을 수 있습니다. 이는 컴퓨팅 노드가 인스턴스 유형이 크고 사용되지 않은 메모리가 상당히 많을 때 발생할 수 있습니다.
[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues) / [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources) /[`SchedulableMemory`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-SchedulableMemory)를 사용하여 컴퓨팅 노드에 AWS ParallelCluster 대해에서 `RealMemory` 구성된 값을 미세 조정할 수 있습니다. 기본값을 재정의하려면 클러스터 구성에 맞게 `SchedulableMemory`의 사용자 지정 값을 정의하세요.
컴퓨팅 노드의 실제 사용 가능한 메모리를 확인하려면 노드에서 `/opt/slurm/sbin/slurmd -C` 명령을 실행합니다. 이 명령은 [https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory](https://slurm.schedmd.com/slurm.conf.html#OPT_RealMemory) 값을 포함하여 노드의 하드웨어 구성을 반환합니다. 자세한 내용은 [https://slurm.schedmd.com/slurmd.html#OPT_-C](https://slurm.schedmd.com/slurmd.html#OPT_-C) 단원을 참조하십시오.
컴퓨팅 노드의 운영 체제 프로세스에 충분한 메모리가 있는지 확인하세요. 이렇게 하려면 `SchedulableMemory` 값을 `slurmd -C` 명령이 반환한 `RealMemory` 값보다 낮게 설정하여 작업에 사용할 수 있는 메모리를 제한하세요.
# Slurm을 사용하여 여러 인스턴스 유형 할당
AWS ParallelCluster 버전 3.3.0부터 컴퓨팅 리소스의 정의된 인스턴스 유형 세트에서 할당하도록 클러스터를 구성할 수 있습니다. Amazon EC2 Fleet 저비용 또는 최적의 용량 전략을 기반으로 할당할 수 있습니다.
정의된 인스턴스 유형 집합은 모두 동일한 수의 vCPU를 가져야 하며, 멀티스레딩이 비활성화된 경우 코어 수가 같아야 합니다. 또한 인스턴스 유형 집합은 동일한 제조업체의 액셀러레이터 수가 같아야 합니다. [`Efa`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa)/[`Enabled`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Efa-Enabled)가 `true`로 설정된 경우 인스턴스는 EFA를 지원해야 합니다. 요구 사항에 대한 자세한 내용은 [`Scheduling`](Scheduling-v3.md)/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy) 및 [`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances) 섹션을 참조하세요.
[`AllocationStrategy`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-AllocationStrategy)는 [CapacityType](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CapacityType) 구성에 따라 `lowest-price` 또는 `capacity-optimized`로 설정할 수 있습니다.
[`Instances`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)에서 인스턴스 유형 집합을 구성할 수 있습니다.
**참고**
AWS ParallelCluster 버전 3.7.0부터 인스턴스에서 여러 인스턴스 유형을 구성하는 경우를 활성화`EnableMemoryBasedScheduling`할 수 있습니다. [](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances)
AWS ParallelCluster 버전 3.2.0\$13.6.*x*의 경우 인스턴스에서 [여러 인스턴스 유형을 구성하는 경우를](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-Instances) 활성화`EnableMemoryBasedScheduling`할 수 없습니다.
다음 예에서는 vCPU, EFA 지원 및 아키텍처의 인스턴스 유형을 쿼리하는 방법을 보여줍니다.
96개의 vCPU 및 x86\$164 아키텍처를 사용하여 InstanceTypes을 쿼리합니다.
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-vcpus,Values=96" "Name=processor-info.supported-architecture,Values=x86_64" \
--query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
64코어, EFA 지원 및 arm64 아키텍처를 사용하여 InstanceTypes을 쿼리합니다.
```
$ aws ec2 describe-instance-types --region region-id \
--filters "Name=vcpu-info.default-cores,Values=64" "Name=processor-info.supported-architecture,Values=arm64" "Name=network-info.efa-supported,Values=true" --query "sort_by(InstanceTypes[*].{InstanceType:InstanceType,MemoryMiB:MemoryInfo.SizeInMiB,CurrentGeneration:CurrentGeneration,VCpus:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Architecture:ProcessorInfo.SupportedArchitectures[0],MaxNetworkCards:NetworkInfo.MaximumNetworkCards,EfaSupported:NetworkInfo.EfaSupported,GpuCount:GpuInfo.Gpus[0].Count,GpuManufacturer:GpuInfo.Gpus[0].Manufacturer}, &InstanceType)" \
--output table
```
다음 예제 클러스터 구성 조각은 이러한 InstanceType과 AllocationStrategy 속성을 사용하는 방법을 보여줍니다.
```
...
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue-1
CapacityType: ONDEMAND
AllocationStrategy: lowest-price
...
ComputeResources:
- Name: computeresource1
Instances:
- InstanceType: r6g.2xlarge
- InstanceType: m6g.2xlarge
- InstanceType: c6g.2xlarge
MinCount: 0
MaxCount: 500
- Name: computeresource2
Instances:
- InstanceType: m6g.12xlarge
- InstanceType: x2gd.12xlarge
MinCount: 0
MaxCount: 500
...
```
# 동적 노드의 클러스터 스케일링
ParallelCluster는 Slurm의 절전 플러그인을 사용하여 클러스터를 동적으로 규모 조정하는 Slurm의 메서드를 지원합니다. 자세한 내용은 Slurm 설명서의 [클라우드 일정 가이드](https://slurm.schedmd.com/elastic_computing.html) 및 [Slurm 절전 가이드](https://slurm.schedmd.com/power_save.html)를 참조하세요. 다음 주제에서는 각 버전의 Slurm 전략을 설명합니다.
**Topics**
+ [버전 3.8.0의 Slurm 동적 노드 할당 전략](scheduler-node-allocation-v3-3.8.0.md)
+ [Slurm 버전 3.7.x의 동적 노드 할당 전략](scheduler-dynamic-node-allocation-v3-3.7.x.md)
+ [버전 3.6.x 이전의 Slurm 동적 노드 할당 전략](scheduler-dynamic-node-allocation-v3-3.6.x.md)
# 버전 3.8.0의 Slurm 동적 노드 할당 전략
ParallelCluster 버전 3.8.0부터 ParallelCluster는 **작업 수준 재개** 또는 **작업 수준 규모 조정**을 기본 동적 노드 할당 전략으로 사용하여 클러스터를 규모 조정합니다. ParallelCluster는 각 작업의 요구 사항, 작업에 할당된 노드 수 및 재개해야 하는 노드에 따라 클러스터를 규모 조정합니다. ParallelCluster는 SLURM\$1RESUME\$1FILE 환경 변수에서 이 정보를 가져옵니다.
동적 노드의 규모 조정은 EC2 인스턴스를 시작하고 시작된 Amazon EC2 인스턴스를 Slurm 노드에 할당하는 두 단계 프로세스입니다. 이 두 단계는 **all-or-nothing** 또는 **best-effort** 로직을 사용하여 수행할 수 있습니다.
Amazon EC2 인스턴스를 시작하는 경우:
+ **all-or-nothing**은 최소 목표가 총 목표 용량과 동일한 시작 Amazon EC2 API를 직접적으로 호출합니다.
+ **best-effort**는 최소 목표가 1이고 총 목표 용량이 요청된 용량과 동일한 Amazon EC2 API 시작을 직접적으로 호출합니다.
Amazon EC2 인스턴스를 Slurm 노드에 할당하는 경우:
+ 요청된 모든 Slurm 노드에 Amazon EC2 인스턴스를 할당할 수 있는 경우에만 **all-or-nothing**이 노드에 Amazon EC2 인스턴스를 할당합니다.
+ 요청된 모든 Slurm 노드가 Amazon EC2 인스턴스 용량에 포함되지 않더라도 **best-effort**는 Amazon EC2 인스턴스를 노드에 할당합니다.
위 전략의 가능한 조합은 ParallelCluster 시작 전략으로 변환됩니다.
**Example** [ ScalingStrategy](Scheduling-v3.md#yaml-Scheduling-ScalingStrategy)
**all-or-nothing** 규모 조정:
이 전략에는 요청된 컴퓨팅 노드 AWS ParallelCluster 를 성공적으로 시작하는 데 필요한 모든 인스턴스가 필요한 각 작업에 대해 Amazon EC2 시작 인스턴스 API 호출을 시작하는 작업이 포함됩니다. 이렇게 하면 작업당 필요한 용량을 사용할 수 있는 경우에만 클러스터가 규모 조정되므로 규모 조정 프로세스가 끝날 때 유휴 인스턴스가 남아 있지 않습니다.
이 전략은 각 작업에 대해 Amazon EC2 인스턴스를 시작하는 데 **all-or-nothing** 로직을 사용하고 Amazon EC2 인스턴스를 Slurm 노드에 할당하는 데 **all-or-nothing** 로직을 사용합니다.
전략 그룹은 요청된 각 컴퓨팅 리소스당 하나씩, 각각 최대 500개의 노드를 배치로 시작 요청을 그룹화합니다. 여러 컴퓨팅 리소스에 걸쳐 있거나 500개 노드를 초과하는 요청의 경우 ParallelCluster는 여러 배치를 순차적으로 처리합니다.
단일 리소스의 배치가 실패하면 연결된 모든 미사용 용량이 종료되므로 규모 조정 프로세스가 끝날 때 유휴 인스턴스가 남지 않습니다.
제한 사항
+ 규모 조정에 걸리는 시간은 Slurm 재개 프로그램 실행당 제출된 작업 수에 직접적으로 비례합니다.
+ 규모 조정 작업은 기본적으로 인스턴스 1000개로 설정된 RunInstances 리소스 계정 제한에 의해 제한됩니다. 이 제한은 AWS EC2 API 제한 정책에 따릅니다. 자세한 내용은 [Amazon EC2 API 제한 설명서를 참조하세요.](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html)
+ 단일 인스턴스 유형의 컴퓨팅 리소스, 여러 가용 영역에 걸친 대기열에 작업을 제출하면 단일 가용 영역에서 모든 용량을 제공할 수 있는 경우에만 전부 또는 전무**** EC2 시작 API 직접 호출이 성공합니다.
+ 단일 가용 영역이 있는 대기열에 있는 여러 인스턴스 유형이 있는 컴퓨팅 리소스에서 작업을 제출하면 단일 인스턴스 유형에서 모든 용량을 제공할 수 있는 경우에만 **all-or-nothing** Amazon EC2 시작 API 직접 호출이 성공합니다.
+ 여러 가용 영역에 걸친 대기열에서 여러 인스턴스 유형이 있는 컴퓨팅 리소스에 작업을 제출하면 **all-or-nothing** Amazon EC2 시작 API 직접 호출은 지원되지 않으며, ParallelCluster는 대신 **best-effort** 규모 조정을 수행합니다.
**greedy-all-or-nothing** 규모 조정:
all-or-nothing 전략의 이 변형은 작업당 필요한 용량이 사용 가능한 경우에만 클러스터가 규모 조정되도록 하여 규모 조정 프로세스가 끝날 때 유휴 인스턴스를 방지하지만, ParallelCluster가 최소 목표 용량 1을 목표로 하는 Amazon EC2 시작 인스턴스 API 직접 호출을 시작하여 요청된 용량까지 시작된 노드 수를 최대화하려고 시도합니다. 이 전략은 모든 작업에 대한 EC2 인스턴스를 시작하는 데 best-effort 로직과 각 작업에 대한 Slurm 노드에 Amazon EC2 인스턴스를 할당하는 데 **all-or-nothing** 로직을 사용합니다.
전략 그룹은 요청된 각 컴퓨팅 리소스당 하나씩, 각각 최대 500개의 노드를 배치로 시작 요청을 그룹화합니다. 여러 컴퓨팅 리소스에 걸쳐 있거나 500개를 초과하는 요청의 경우 ParellelCluster는 여러 배치를 순차적으로 처리합니다.
규모 조정 프로세스 중에 임시 과대 규모 조정으로 처리량을 극대화하여 규모 조정 프로세스가 끝날 때 유휴 인스턴스가 남아 있지 않도록 합니다.
제한 사항
+ 임시 과대 규모 조정이 가능하므로 규모 조정 완료 전에 실행 상태로 전환되는 인스턴스에 대한 추가 비용이 발생합니다.
+ all-or-nothing 전략과 동일한 인스턴스 제한이 적용되며, AWS의 RunInstances 리소스 계정 제한이 적용됩니다.
**best-effort** 규모 조정:
이 전략은 최소 용량 1을 목표로 하고 모든 요청 용량을 사용할 수 없는 경우 규모 조정 프로세스 실행 후 유휴 인스턴스를 남겨두는 데 드는 비용으로 총 요청 용량을 달성하는 것을 목표로 하여 Amazon EC2 시작 인스턴스 API 직접 호출을 직접적으로 호출합니다. 이 전략은 모든 작업에 대해 Amazon EC2 인스턴스를 시작하는 데 best-effort 로직과 각 작업에 대해 Slurm 노드에 Amazon EC2 인스턴스를 할당하는 데 **best-effort** 로직을 사용합니다.
전략 그룹은 요청된 각 컴퓨팅 리소스당 하나씩, 각각 최대 500개의 노드를 배치로 시작 요청을 그룹화합니다. 여러 컴퓨팅 리소스에 걸쳐 있거나 500개 노드를 초과하는 요청의 경우 ParallelCluster는 여러 배치를 순차적으로 처리합니다.
이 전략을 사용하면 여러 스케일링 프로세스에서 유휴 인스턴스를 보유하는 대신 다중 규모 조정 프로세스 실행에 대해 기본 1000 인스턴스 제한을 훨씬 초과하여 규모를 조정할 수 있습니다.
제한 사항
+ 작업에서 요청한 모든 노드를 할당할 수 없는 경우 규모 조정 프로세스 종료 시 유휴 실행 인스턴스가 있을 수 있습니다.
다음은 다양한 **ParallelCluster 시작 전략**을 사용하여 동적 노드를 조정하는 방법을 보여주는 예제입니다. 동일한 유형의 총 40개의 노드에 대해 각각 20개의 노드를 요청하는 두 개의 작업을 제출했지만 EC2에서 요청한 용량을 충당할 수 있는 Amazon EC2 인스턴스가 30개뿐이라고 가정해 보겠습니다.
**all-or-nothing** 규모 조정:
+ 첫 번째 작업의 경우 **all-or-nothing** Amazon EC2 시작 인스턴스 API가 직접적으로 호출되어 인스턴스 20개를 요청합니다. 성공적인 직접 호출로 인해 인스턴스 20개가 시작됩니다.
+ 첫 번째 작업에 대해 시작된 인스턴스 20개를 Slurm 노드에 **all-or-nothing**할당합니다.
+ 또 다른 **all-or-nothing** Amazon EC2 시작 인스턴스 API를 직접적으로 호출하여 두 번째 작업에 대해 20개의 인스턴스를 요청합니다. 다른 10개의 인스턴스에 대한 용량만 있으므로 직접 호출에 성공하지 못했습니다. 현재 인스턴스가 시작되지 않음
**greedy-all-or-nothing** 규모 조정:
+ 모든 작업에서 요청한 총 용량인 40개의 인스턴스를 요청하는 **best-effort** Amazon EC2 시작 인스턴스 API를 직접적으로 호출합니다. 이렇게 하면 인스턴스 30개가 시작됩니다.
+ 첫 번째 작업에 대해 시작된 인스턴스 20개를 Slurm 노드에 **all-or-nothing** 할당합니다.
+ 두 번째 작업을 위해 시작된 나머지 인스턴스를 Slurm 노드에 **all-or-nothing** 할당하지만, 작업에서 요청한 총 20개 중 사용 가능한 인스턴스가 10개뿐이므로 할당에 실패합니다.
+ 할당되지 않은 시작 인스턴스 10개가 종료됩니다.
**best-effort** 규모 조정:
+ 모든 작업에서 요청한 총 용량인 40개의 인스턴스를 요청하는 **best-effort** Amazon EC2 시작 인스턴스 API를 직접적으로 호출합니다. 이렇게 하면 인스턴스 30개가 시작됩니다.
+ 첫 번째 작업을 위해 시작된 인스턴스 중 20개를 Slurm 노드에 **best-effort** 할당합니다.
+ 나머지 10개의 시작 인스턴스를 두 번째 작업을 위해 Slurm 노드에 할당하는 또 다른 **best-effort** 할당은 요청된 총 용량이 20이더라도 성공합니다. 그러나 작업이 20개의 노드를 요청하고 있고 Amazon EC2 인스턴스를 10개에만 할당할 수 있었기 때문에 나중에 규모 조정 프로세스를 직접적으로 호출할 때 누락된 10개의 인스턴스를 시작하기에 충분한 용량이 발견되거나 스케줄러가 이미 실행 중인 다른 컴퓨팅 노드에서 작업을 예약하기 전까지는 작업을 시작할 수 없고 인스턴스가 유휴 상태로 유지됩니다.
# Slurm 버전 3.7.x의 동적 노드 할당 전략
ParallelCluster는 두 가지 유형의 동적 노드 할당 전략을 사용하여 클러스터를 규모 조정합니다.
+
**사용 가능한 요청 노드 정보를 기반으로 한 할당:**
+ 모든 노드 재개**** 또는 노드 목록**** 규모 조정:
Slurm의 `ResumeProgram`이 실행될 때 ParallelCluster는 Slurm의 요청된 노드 목록 이름만을 기반으로 한 클러스터를 스케일 업합니다. 노드 이름으로만 노드에 컴퓨팅 리소스를 할당합니다. 노드 이름 목록은 여러 작업에 걸쳐 있을 수 있습니다.
+ 직무 수준 재개**** 또는 직무 수준**** 규모 조정:
ParallelCluster는 각 작업의 요구 사항, 작업에 할당된 현재 노드 수, 재개해야 하는 노드에 따라 클러스터를 스케일 업합니다. ParallelCluster는 `SLURM_RESUME_FILE` 환경 변수에서 이 정보를 가져옵니다.
+
**Amazon EC2 출시 전략을 사용한 할당:**
+ 최선의**** 규모 조정:
ParallelCluster는 최소 목표 용량이 1인 Amazon EC2 시작 인스턴스 API 직접 호출을 사용하여 클러스터를 스케일 업하여 요청된 노드를 지원하는 데 필요한 모든 인스턴스는 아니지만 일부 인스턴스를 시작합니다.
+ 전부 또는 전무**** 규모 조정:
ParallelCluster는 요청된 노드를 지원하는 데 필요한 모든 인스턴스가 시작된 경우에만 성공하는 Amazon EC2 시작 인스턴스 API 직접 호출을 사용하여 클러스터를 스케일 업합니다. 이 경우 요청된 총 용량과 동일한 최소 목표 용량을 사용하여 Amazon EC2 시작 인스턴스 API를 직접적으로 호출합니다.
기본적으로, ParallelCluster는 요청된 노드를 지원하는 데 필요한 모든 인스턴스는 아니지만 일부 인스턴스를 시작하기 위해 **best-effort** Amazon EC2 시작 전략과 함께 **node-list** 규모 조정을 사용합니다. 제출된 워크로드를 처리하기 위해 최대한 많은 용량을 프로비저닝하려고 합니다.
ParallelCluster 버전 3.7.0부터 ParallelCluster는 **단독 모드**로 제출된 작업에 대해 **all-or-nothing** EC2 시작 전략을 적용한 **작업 수준** 규모 조정을 사용합니다. 단독 모드에서 작업을 제출하면 작업은 할당된 노드에 독점적으로 액세스할 수 있습니다. 자세한 내용은 Slurm 설명서의 [단독](https://slurm.schedmd.com/slurm.conf.html#OPT_EXCLUSIVE)을 참조하세요.
단독 모드에서 작업을 제출하려면:
+ 클러스터에 Slurm 작업을 제출할 때 단독 플래그를 전달하세요. 예를 들어 `sbatch ... --exclusive`입니다.
또는
+ [`JobExclusiveAllocation`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-JobExclusiveAllocation)이 `true`로 설정된 상태로 구성된 클러스터 대기열에 작업을 제출합니다.
단독 모드에서 작업을 제출하는 경우:
+ ParallelCluster는 현재 최대 500개의 노드를 포함하도록 시작 요청을 일괄 처리합니다. 작업이 500개 이상의 노드를 요청하는 경우 ParallelCluster는 각 500개 노드 집합에 대해 **all-or-nothing** 시작 요청을 하고 나머지 노드에 대해서는 추가 시작 요청을 합니다.
+ 노드 할당이 단일 컴퓨팅 리소스에 있는 경우 ParallelCluster는 각 500개 노드 집합에 대해 **all-or-nothing** 시작 요청을 보내고 나머지 노드에 대해서는 추가 시작 요청을 합니다. 시작 요청이 실패하면 ParallelCluster는 모든 시작 요청에서 생성된 미사용 용량을 종료됩니다.
+ 노드 할당이 여러 컴퓨팅 리소스에 걸친 경우, ParallelCluster는 각 컴퓨팅 리소스에 대해 **all-or-nothing** 시작 요청을 해야 합니다. 이러한 요청도 일괄 처리됩니다. 컴퓨팅 리소스 중 하나에 대한 시작 요청이 실패하면 ParallelCluster는 모든 컴퓨팅 리소스 시작 요청에서 생성된 미사용 용량을 종료합니다.
알려진 제한 사항을 적용한 전부 또는 전무**** 시작 전략 을 사용한 직무 수준**** 규모 조정:
+ 단일 인스턴스 유형의 컴퓨팅 리소스, 여러 가용 영역에 걸친 대기열에 작업을 제출하면 단일 가용 영역에서 모든 용량을 제공할 수 있는 경우에만 전부 또는 전무**** EC2 시작 API 직접 호출이 성공합니다.
+ 단일 가용 영역이 있는 대기열에 있는 여러 인스턴스 유형이 있는 컴퓨팅 리소스에서 작업을 제출하면 단일 인스턴스 유형에서 모든 용량을 제공할 수 있는 경우에만 **all-or-nothing** Amazon EC2 시작 API 직접 호출이 성공합니다.
+ 여러 가용 영역에 걸친 대기열에서 여러 인스턴스 유형이 있는 컴퓨팅 리소스에 작업을 제출하면 **all-or-nothing** Amazon EC2 시작 API 직접 호출은 지원되지 않으며, ParallelCluster는 대신 **best-effort** 규모 조정을 수행합니다.
# 버전 3.6.x 이전의 Slurm 동적 노드 할당 전략
AWS ParallelCluster 는 한 가지 유형의 동적 노드 할당 전략만 사용하여 클러스터를 확장합니다.
+ 사용 가능한 요청 노드 정보를 기반으로 한 할당:
+ **All-nodes resume** 또는 **node-list** 규모 조정: ParallelCluster는 Slurm의 `ResumeProgram`이 실행될 때 Slurm의 요청된 노드 목록 이름만 기반으로 클러스터를 스케일 업합니다. 노드 이름으로만 노드에 컴퓨팅 리소스를 할당합니다. 노드 이름 목록은 여러 작업에 걸쳐 있을 수 있습니다.
+ Amazon EC2 출시 전략을 사용한 할당:
+ **Best-effort** 규모 조정: ParallelCluster는 최소 목표 용량이 1인 Amazon EC2 시작 인스턴스 API 직접 호출을 사용하여 클러스터를 스케일 업하여 요청된 노드를 지원하는 데 필요한 모든 인스턴스는 아니지만 일부 인스턴스를 시작합니다.
ParallelCluster는 요청된 노드를 지원하는 데 필요한 모든 인스턴스는 아니지만 일부 인스턴스를 시작하기 위해 **best-effort** Amazon EC2 시작 전략과 함께 **node-list** 규모 조정을 사용합니다. 제출된 워크로드를 처리하기 위해 최대한 많은 용량을 프로비저닝하려고 합니다.
제한 사항
+ 작업에서 요청한 모든 노드를 할당할 수 없는 경우 규모 조정 프로세스 종료 시 유휴 실행 인스턴스가 있을 수 있습니다.
# Slurm를 사용한 회계 AWS ParallelCluster
버전 3.3.0부터 클러스터 구성 파라미터 [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings) / [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)로 Slurm 회계를 AWS ParallelCluster 지원합니다.
버전 3.10.0부터는 클러스터 구성 파라미터 [SlurmSettings](Scheduling-v3.md#Scheduling-v3-SlurmSettings) / ExternalSlurmdbd를 사용하여 외부 Slurmdbd[ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd)로 Slurm 회계를 AWS ParallelCluster 지원합니다. 여러 클러스터가 동일한 데이터베이스를 공유하는 경우 외부 Slurmdbd를 사용하는 것이 좋습니다.
Slurm 회계를 사용하면 외부 계정 데이터베이스를 통합하여 다음 작업을 수행할 수 있습니다.
+ 클러스터 사용자 또는 사용자 그룹 및 기타 엔터티를 관리합니다. 이 기능을 사용하면 리소스 제한 적용, 공정 공유 및 QOS와 같은 Slurm의 고급 기능을 사용할 수 있습니다. QOSs
+ 작업을 실행한 사용자, 작업 기간, 사용한 리소스와 같은 작업 데이터를 수집하고 저장합니다. `sacct` 유틸리티를 사용하여 저장된 데이터를 볼 수 있습니다.
**참고**
AWS ParallelCluster 는 [Slurm 지원되는 MySQL 데이터베이스 서버의](https://slurm.schedmd.com/accounting.html#mysql-configuration) Slurm 회계를 지원합니다.
## AWS ParallelCluster v3.10.0 이상Slurmdbd에서 외부를 사용하여 Slurm 회계 작업
Slurm 회계를 구성하기 전에 기존 외부 데이터베이스 서버에 연결하는 기존 Slurmdbd 데이터베이스 서버가 있어야 합니다.
이를 구성하려면 다음을 정의합니다.
+ [ExternalSlurmdbd](Scheduling-v3.md#Scheduling-v3-SlurmSettings-ExternalSlurmdbd) / [Host](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-ExternalSlurmdbd-Host)의 외부 Slurmdbd 서버 주소. 서버가 존재하고 헤드 노드에서 연결할 수 있어야 합니다.
+ [MungeKeySecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-MungeKeySecretArn)의 외부 Slurmdbd 서버와 통신할 munge 키.
튜토리얼을 단계별로 진행하려면 [외부 Slurmdbd 회계를 사용하여 클러스터 생성](external-slurmdb-accounting.md)을 참조하세요.
**참고**
Slurm 데이터베이스 회계 엔터티를 관리할 책임은 사용자에게 있습니다.
AWS ParallelCluster 외부 SlurmDB 지원 기능의 아키텍처를 사용하면 여러 클러스터가 동일한 데이터베이스SlurmDB와 동일한 데이터베이스를 공유할 수 있습니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/parallelcluster/latest/ug/images/External_Slurmdbd_Architecture_ASG.png)
**주의**
AWS ParallelCluster 와 외부 간의 트래픽SlurmDB은 암호화되지 않습니다. 신뢰할 수 있는 네트워크에서 클러스터와 외부 SlurmDB를 실행하는 것이 좋습니다.
## AWS ParallelCluster v3.3.0 이상Slurmdbd에서 헤드 노드를 사용한 Slurm 회계 작업
Slurm 회계를 구성하기 전에 `mysql` 프로토콜을 사용하는 기존 외부 데이터베이스 서버 및 데이터베이스가 있어야 합니다.
를 사용하여 Slurm 회계를 구성하려면 다음을 정의 AWS ParallelCluster해야 합니다.
+ [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[Uri](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-Uri)에 있는 외부 데이터베이스 서버의 URI입니다. 서버가 존재하고 헤드 노드에서 연결할 수 있어야 합니다.
+ [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database) / [PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn) 및 [Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database) / [UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName).에 정의된 외부 데이터베이스에 액세스하기 위한 자격 증명은이 정보를 AWS ParallelCluster 사용하여 헤드 노드의 Slurm 수준 및 `slurmdbd` 서비스에서 회계를 구성합니다. `slurmdbd`는 클러스터와 데이터베이스 서버 간의 통신을 관리하는 데몬입니다.
튜토리얼을 단계별로 진행하려면 [Slurm 화계를 사용하여 클러스터 생성](tutorials_07_slurm-accounting-v3.md)을 참조하세요.
**참고**
AWS ParallelCluster 는 기본 클러스터 사용자를 데이터베이스의 데이터베이스 관리자로 설정하여 Slurm 회계 Slurm 데이터베이스의 기본 부트스트랩을 수행합니다. AWS ParallelCluster 는 회계 데이터베이스에 다른 사용자를 추가하지 않습니다. 고객은 Slurm 데이터베이스의 회계 엔터티를 관리할 책임이 있습니다.
AWS ParallelCluster 는 클러스터가 Slurm 데이터베이스 서버에 자체 데이터베이스를 갖도록 [https://slurm.schedmd.com/slurmdbd.html](https://slurm.schedmd.com/slurmdbd.html)를 구성합니다. 동일한 데이터베이스 서버를 여러 클러스터에서 사용할 수 있지만 각 클러스터에는 별도의 고유한 데이터베이스가 있습니다.는 클러스터 이름을 AWS ParallelCluster 사용하여 `slurmdbd` 구성 파일 [https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageLoc) 파라미터에서 데이터베이스의 이름을 정의합니다. 다음 상황을 고려하세요. 데이터베이스 서버에 있는 데이터베이스에는 활성 클러스터 이름에 매핑되지 않는 클러스터 이름이 포함되어 있습니다. 이 경우 해당 클러스터 이름으로 새 클러스터를 만들어 해당 데이터베이스에 매핑할 수 있습니다. Slurm은 데이터베이스를 새 클러스터에 재사용합니다.
**주의**
한 번에 같은 데이터베이스를 사용하기 위해 두 개 이상의 클러스터를 설정하지 않는 것이 좋습니다. 이렇게 하면 성능 문제가 발생하거나 데이터베이스 교착 상태가 발생할 수 있습니다.
클러스터의 헤드 노드에서 Slurm 회계를 활성화한 경우 강력한 CPU, 더 많은 메모리, 더 높은 네트워크 대역폭을 갖춘 인스턴스 유형을 사용하는 것이 좋습니다. Slurm 회계는 클러스터의 헤드 노드에 부담을 가중시킬 수 있습니다.
회계 기능의 현재 아키텍처 AWS ParallelCluster Slurm에서 각 클러스터에는 다음 다이어그램 예제 구성과 같이 `slurmdbd` 데몬의 자체 인스턴스가 있습니다.
![\[\]](http://docs.aws.amazon.com/ko_kr/parallelcluster/latest/ug/images/slurm-acct-arch.png)
클러스터 환경에 사용자 지정 Slurm 다중 클러스터 또는 페더레이션 기능을 추가하는 경우 모든 클러스터가 동일한 `slurmdbd` 인스턴스를 참조해야 합니다. 이 대안의 경우 한 클러스터에서 회계를 활성화 AWS ParallelCluster Slurm하고 첫 번째 클러스터에서 호스팅`slurmdbd`되는에 연결하도록 다른 클러스터를 수동으로 구성하는 것이 좋습니다.
AWS ParallelCluster 버전 3.3.0 이전 버전을 사용하는 경우이 [HPC 블로그 게시물](https://aws.amazon.com/blogs/compute/enabling-job-accounting-for-hpc-with-aws-parallelcluster-and-amazon-rds/)에 설명된 Slurm 회계를 구현하는 대체 방법을 참조하세요.
## Slurm 회계 고려 사항
### 서로 다른 VPC의 데이터베이스 및 클러스터
Slurm 회계를 활성화하려면 `slurmdbd` 대몬(daemon)이 수행하는 읽기 및 쓰기 작업을 위한 백엔드 역할을 하는 데이터베이스 서버가 필요합니다. Slurm 회계를 활성화하도록 클러스터가 생성되거나 업데이트되기 전에 헤드 노드가 데이터베이스 서버에 연결할 수 있어야 합니다.
클러스터가 사용하는 VPC가 아닌 다른 VPC에 데이터베이스 서버를 배포해야 하는 경우 다음 사항을 고려하세요.
+ 클러스터 측의 `slurmdbd`과 데이터베이스 서버 간의 통신을 활성화하려면 두 VPC 간의 연결을 설정해야 합니다. 자세한 내용은 Amazon Virtual Private Cloud 사용 설명서**의 [VPC 피어링](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)을 참조하세요.
+ 클러스터의 VPC에 있는 헤드 노드에 연결할 보안 그룹을 만들어야 합니다. 두 VPC가 피어링된 후에는 데이터베이스 측과 클러스터 측 보안 그룹 간의 상호 연결을 사용할 수 있습니다. 자세한 내용을 알아보려면 Amazon Virtual Private Cloud 사용 설명서**의 [보안 그룹 규칙](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules)을 참조하세요.
### 데이터베이스 서버와 `slurmdbd` 간의 TLS 암호화 구성
가 AWS ParallelCluster 제공하는 기본 Slurm 회계 구성을 사용하면 서버가 Amazon RDS와 같은 TLS encryption. AWS database 서비스를 지원하고 기본적으로 TLS 암호화를 Amazon Aurora 지원하는 경우는 데이터베이스 서버에 대한 TLS 암호화 연결을 `slurmdbd` 설정합니다.
데이터베이스 서버에서 `require_secure_transport` 파라미터를 설정하여 서버 측의 보안 연결을 요구할 수 있습니다. 이는 제공된 CloudFormation 템플릿에서 구성됩니다.
최상의 보안을 위해 `slurmdbd` 클라이언트에서 서버 ID 확인도 활성화하는 것이 좋습니다. 이렇게 하려면 `slurmdbd.conf`에서 [StorageParameter](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_StorageParameters)를 구성하세요. 서버 CA 인증서를 클러스터의 헤드 노드에 업로드합니다. 그런 다음 `StorageParameters`의 [SSL\$1CA](https://slurm.schedmd.com/slurmdbd.conf.html#OPT_SSL_CA) 옵션을 헤드 노드의 서버 CA 인증서 `slurmdbd.conf` 경로로 설정합니다. 이렇게 하면 `slurmdbd` 측의 서버 ID 확인이 가능해집니다. 이러한 변경을 수행한 후에는 `slurmdbd` 서비스를 다시 시작하여 ID 검증이 활성화된 상태에서 데이터베이스 서버와의 연결을 다시 설정하세요.
### 데이터베이스 보안 인증 업데이트
[Database](Scheduling-v3.md#Scheduling-v3-SlurmSettings-Database)/[UserName](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-UserName) 또는 [PasswordSecretArn](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-Database-PasswordSecretArn)의 값을 업데이트하려면 먼저 컴퓨팅 플릿을 중지해야 합니다. 보안 암호에 저장된 AWS Secrets Manager 보안 암호 값이 변경되고 해당 ARN이 변경되지 않는다고 가정해 보겠습니다. 이 경우 클러스터는 데이터베이스 비밀번호를 새 값으로 자동 업데이트하지 않습니다. 새 암호 값에 맞게 클러스터를 업데이트하려면 헤드 노드에서 다음 명령을 실행합니다.
```
$ sudo /opt/parallelcluster/scripts/slurm/update_slurm_database_password.sh
```
**주의**
계정 데이터 손실을 방지하려면 컴퓨팅 플릿이 중지된 경우에만 데이터베이스 비밀번호를 변경하는 것이 좋습니다.
### 데이터베이스 모니터링
AWS 데이터베이스 서비스의 모니터링 기능을 활성화하는 것이 좋습니다. 자세한 내용은 [Amazon RDS 모니터링](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) 또는 [Amazon Aurora 모니터링](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/MonitoringAurora.html) 설명서를 참조하세요.
# Slurm 구성 사용자 지정
AWS ParallelCluster 버전 3.6.0부터 AWS ParallelCluster 클러스터 `slurm.conf` Slurm 구성에서 구성을 사용자 지정할 수 있습니다.
클러스터 구성에서 다음 클러스터 구성 설정을 사용하여 Slurm 구성 파라미터를 사용자 지정할 수 있습니다.
+ 둘 다 지정하면 [`SlurmSettings`](Scheduling-v3.md#Scheduling-v3-SlurmSettings) / [`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettings) 또는 [`CustomSlurmSettingsIncludeFile`](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-CustomSlurmSettingsIncludeFile) parameter. AWS ParallelCluster fails를 사용하여 전체 클러스터의 Slurm 파라미터를 사용자 지정합니다.
+ [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-CustomSlurmSettings)(Slurm 파티션에 매핑됨)를 사용하여 대기열의 Slurm 파라미터를 사용자 지정합니다.
+ [`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)/[`ComputeResources`](Scheduling-v3.md#Scheduling-v3-SlurmQueues-ComputeResources)/[`CustomSlurmSettings`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-CustomSlurmSettings)(Slurm 노드에 매핑됨)를 사용하여 컴퓨팅 리소스의 Slurm 파라미터를 사용자 지정합니다.
## Slurm 사용 시 구성 사용자 지정 제한 및 고려 사항 AWS ParallelCluster
+ `CustomSlurmSettings` 및 `CustomSlurmSettingsIncludeFile` 설정의 경우 클러스터를 구성하는 데 사용하는 [Slurm 버전](slurm-workload-manager-v3.md)에서 지원하는 AWS ParallelCluster 버전에 포함된 `slurm.conf` 파라미터만 지정하고 업데이트할 수 있습니다.
+ `CustomSlurmSettings` 파라미터에서 사용자 지정 Slurm 구성을 지정하는 경우 AWS ParallelCluster 는 검증 검사를 AWS ParallelCluster 수행하고 로직과 충돌하는 Slurm 구성 파라미터를 설정하거나 업데이트하지 못하도록 합니다. 와 충돌하는 것으로 알려진 Slurm 구성 파라미터는 거부 목록에서 식별 AWS ParallelCluster 됩니다. 다른 Slurm 기능이 추가되면 향후 AWS ParallelCluster 버전에서 거부 목록이 변경될 수 있습니다. 자세한 내용은 [`CustomSlurmSettings`을 위한 거부 목록에 등록된 Slurm 구성 파라미터](#slurm-configuration-denylists-v3) 단원을 참조하십시오.
+ AWS ParallelCluster 는 파라미터가 거부 목록에 있는지만 확인합니다. AWS ParallelCluster 는 사용자 지정 Slurm 구성 파라미터 구문 또는 의미 체계를 검증하지 않습니다. 사용자 지정 Slurm 구성 파라미터의 유효성을 검사하는 것은 사용자의 책임입니다. 잘못된 사용자 지정 Slurm 구성 파라미터로 인해 Slurm 대몬(daemon) 장애가 발생하여 클러스터 생성 및 업데이트 실패로 이어질 수 있습니다.
+ 에서 사용자 지정 Slurm 구성을 지정하는 경우 검증`CustomSlurmSettingsIncludeFile` AWS ParallelCluster 을 수행하지 않습니다.
+ 컴퓨팅 플릿을 중지하고 시작하지 않고도 `CustomSlurmSettings` 및 `CustomSlurmSettingsIncludeFile`을 업데이트할 수 있습니다. 이 경우 `slurmctld`는 데몬을 AWS ParallelCluster 다시 시작하고 `scontrol reconfigure` 명령을 실행합니다.
일부 Slurm 구성 파라미터에는 변경 내용이 전체 클러스터에 등록되기 전에 다른 작업이 필요할 수 있습니다. 예를 들어 클러스터의 모든 대몬(daemon)을 다시 시작해야 할 수 있습니다. 업데이트 중에 사용자 지정 Slurm 구성 파라미터 설정을 전파하기에 AWS ParallelCluster 작업이 충분한지 확인하는 것은 사용자의 책임입니다. AWS ParallelCluster 작업이 충분하지 않은 경우 [Slurm 설명서](https://slurm.schedmd.com/documentation.html)의 권장 사항에 따라 업데이트된 설정을 전파하는 데 필요한 추가 작업을 제공하는 것은 사용자의 책임입니다.
## `CustomSlurmSettings`을 위한 거부 목록에 등록된 Slurm 구성 파라미터
다음 표에는 AWS ParallelCluster 버전 3.6.0부터 사용을 거부하는 버전이 포함된 파라미터가 나열되어 있습니다. `CustomSlurmSettings`는 버전 3.6.0 이전 AWS ParallelCluster 버전에서는 지원되지 않습니다.
**클러스터 수준에서 거부 목록에 등록된 파라미터 목록:**
| Slurm 파라미터 | AWS ParallelCluster 버전에 거부 등록됨 |
| --- | --- |
| CommunicationParameters | 3.6.0 |
| Epilog | 3.6.0 |
| GresTypes | 3.6.0 |
| LaunchParameters | 3.6.0 |
| Prolog | 3.6.0 |
| ReconfigFlags | 3.6.0 |
| ResumeFailProgram | 3.6.0 |
| ResumeProgram | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| SlurmctldHost | 3.6.0 |
| SlurmctldLogFile | 3.6.0 |
| SlurmctldParameters | 3.6.0 |
| SlurmdLogfile | 3.6.0 |
| SlurmUser | 3.6.0 |
| SuspendExcNodes | 3.6.0 |
| SuspendProgram | 3.6.0 |
| SuspendTime | 3.6.0 |
| TaskPlugin | 3.6.0 |
| TreeWidth | 3.6.0 |
**클러스터 구성에서 [네이티브 Slurm 회계 통합](slurm-accounting-v3.md)이 구성된 경우 클러스터 수준에서 거부 목록에 있는 파라미터:**
| Slurm 파라미터 | AWS ParallelCluster 버전에 거부 등록됨 |
| --- | --- |
| AccountingStorageType | 3.6.0 |
| AccountingStorageHost | 3.6.0 |
| AccountingStoragePort | 3.6.0 |
| AccountingStorageUser | 3.6.0 |
| JobAcctGatherType | 3.6.0 |
**다음에서 관리하는 대기열의 대기열(파티션) 수준에서 거부 목록에 있는 파라미터 AWS ParallelCluster:**
| Slurm 파라미터 | AWS ParallelCluster 버전에 거부 등록됨 |
| --- | --- |
| 노드 | 3.6.0 |
| PartitionName | 3.6.0 |
| ResumeTimeout | 3.6.0 |
| State | 3.6.0 |
| SuspendTime | 3.6.0 |
**다음에서 관리하는 컴퓨팅 리소스에 대한 컴퓨팅 리소스(노드) 수준에서 거부 목록에 있는 파라미터 AWS ParallelCluster:**
| Slurm 파라미터 | AWS ParallelCluster 버전 이상에서 거부 목록 |
| --- | --- |
| CPU | 3.6.0 |
| 특성 | 3.6.0 |
| Gres | 3.6.0 |
| NodeAddr | 3.6.0 |
| NodeHostname | 3.6.0 |
| NodeName | 3.6.0 |
| 가중치 | 3.7.0 |
# Slurm 및 `prolog``epilog`
AWS ParallelCluster 버전 3.6.0부터에 AWS ParallelCluster 배포된 Slurm 구성에는 `Prolog` 및 `Epilog` 구성 파라미터가 포함됩니다.
```
# PROLOG AND EPILOG
Prolog=/opt/slurm/etc/scripts/prolog.d/*
Epilog=/opt/slurm/etc/scripts/epilog.d/*
SchedulerParameters=nohold_on_prolog_fail
BatchStartTimeout=180
```
자세한 내용은 Slurm 설명서의 [Prolog 및 Epilog 안내서](https://slurm.schedmd.com/prolog_epilog.html)를 참조하세요.
AWS ParallelCluster 에는 다음 prolog 및 epilog 스크립트가 포함되어 있습니다.
+ `90_plcuster_health_check_manager`(`Prolog` 폴더 내)
+ `90_pcluster_noop`(`Epilog` 폴더 내)
**참고**
`Prolog` 및 `Epilog` 폴더는 각각 적어도 하나 이상의 파일을 포함해야 합니다.
각 해당 `Prolog` 및 `Epilog` 폴더에 사용자 지정 `prolog` 또는 `epilog` 스크립트를 추가하여 사용할 수 있습니다.
**주의**
Slurm은 폴더에 있는 모든 스크립트를 알파벳 역순으로 실행합니다.
`prolog` 및 `epilog` 스크립트의 실행 시간은 작업을 실행하는 데 필요한 시간에 영향을 줍니다. 여러 스크립트 또는 장기 실행 `prolog` 스크립트를 실행하는 경우 `BatchStartTimeout` 구성 설정을 업데이트하세요. 기본값은 3분입니다.
사용자 지정 `prolog` 및 `epilog` 스크립트를 사용하는 경우 각 `Prolog` 및 `Epilog` 폴더에서 스크립트를 찾으세요. 모든 사용자 지정 스크립트보다 먼저 실행되는 `90_plcuster_health_check_manager` 스크립트를 유지하는 것이 좋습니다. 자세한 내용은 [Slurm 구성 사용자 지정](slurm-configuration-settings-v3.md) 단원을 참조하십시오.
# 클러스터 용량 크기 및 업데이트
클러스터의 용량은 클러스터가 규모 조정할 수 있는 컴퓨팅 노드 수에 따라 정의됩니다. 컴퓨팅 노드는 AWS ParallelCluster 구성의 컴퓨팅 리소스 내에 정의된 Amazon EC2 인스턴스에 의해 지원되며 `(Scheduling/SlurmQueues/ ComputeResources)`1:1을 Slurm 파티션에 매핑`(Scheduling/SlurmQueues)`하는 대기열로 구성됩니다.
컴퓨팅 리소스 내에서 클러스터(`MinCount`)에서 항상 실행되어야 하는 최소 컴퓨팅 노드(인스턴스) 수와 컴퓨팅 리소스가 ([`MaxCount`3](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-ComputeResources-MaxCount))으로 규모 조정할 수 있는 최대 인스턴스 수를 구성할 수 있습니다.
클러스터 생성 시 또는 클러스터 업데이트 시는 클러스터에 정의된 각 컴퓨팅 리소스(`Scheduling/SlurmQueues/ ComputeResources`)에 `MinCount` 대해에 구성된 수만큼 Amazon EC2 인스턴스를 AWS ParallelCluster 시작합니다. 클러스터의 컴퓨팅 리소스에 대한 최소 노드 수를 포함하도록 시작된 인스턴스를 ***정적 노드***라고 합니다. 일단 시작되면 정적 노드는 클러스터에서 영구적이어야 하며 특정 이벤트 또는 조건이 발생하지 않는 한 시스템에 의해 종료되지 않습니다. 이러한 이벤트에는 Slurm 또는 Amazon EC2 상태 확인 실패 및 Slurm 노드 상태를 DRAIN 또는 DOWN으로 변경 등이 포함됩니다.
클러스터의 증가된 부하를 처리하기 위해 온디맨드 방식으로 시작된 `1` - `‘MaxCount - MinCount’`(`MaxCount ` *-* ` MinCount)` 범위의 Amazon EC2 인스턴스를 ***동적 노드***라고 합니다. 속성은 일시적이며 보류 중인 작업을 제공하기 위해 시작되고 클러스터 구성에서 `Scheduling/SlurmSettings/ScaledownIdletime`에 정의된 기간 동안 유휴 상태로 유지되면 종료됩니다(기본값: 10분).
정적 노드 및 동적 노드는 다음 이름 지정 스키마를 준수합니다.
+ 정적 노드 `-st--` ` = 1..ComputeResource/MinCount`
+ 동적 노드 `-dy--` ` = 1..(ComputeResource/MaxCount - ComputeResource/MinCount)`
예를 들어 다음과 같은 AWS ParallelCluster 구성이 있습니다.
```
Scheduling:
Scheduler: Slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 150
```
다음 노드는 Slurm에서 정의됩니다.
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
컴퓨팅 리소스에 `MinCount == MaxCount`가 있으면 해당하는 모든 컴퓨팅 노드가 정적이 되고 클러스터 생성/업데이트 시간에 모든 인스턴스가 시작되어 계속 실행됩니다. 예시:
```
Scheduling:
Scheduler: slurm
SlurmQueues:
- Name: queue1
ComputeResources:
- Name: c5xlarge
Instances:
- InstanceType: c5.xlarge
MinCount: 100
MaxCount: 100
```
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## 클러스터 용량 업데이트
클러스터 용량 업데이트에는 대기열 추가 또는 제거, 리소스 계산 또는 컴퓨팅 리소스의 `MinCount/MaxCount` 변경 등이 포함됩니다. AWS ParallelCluster 버전 3.9.0부터 대기열 크기를 줄이려면 클러스터 업데이트가 발생하기 전에 컴퓨팅 플릿을 중지하거나 [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)를 TERMINATE로 설정해야 합니다. 다음과 같은 경우 컴퓨팅 플릿을 중지하거나 [QueueUpdateStrategy](Scheduling-v3.md#yaml-Scheduling-SlurmSettings-QueueUpdateStrategy)를 TERMINATE로 설정할 필요가 없습니다.
+ 예약/[`SlurmQueues`](Scheduling-v3.md#Scheduling-v3-SlurmQueues)에 새 대기열 추가
+ 대기열에 새 컴퓨팅 리소스 `Scheduling/SlurmQueues/ComputeResources` 추가
+ 컴퓨팅 리소스의 `MaxCount` 증가
+ 컴퓨팅 리소스의 MinCount 증가 및 적어도 동일한 양의 동일한 컴퓨팅 리소스의 MaxCount 증가
## 고려 사항 및 제한 사항
이 섹션에서는 클러스터 용량 크기를 조정할 때 고려해야 하는 중요한 요인, 제약 또는 제한 사항을 간략하게 설명합니다.
+ 이름이 `-*`인 모든 컴퓨팅 노드 `Scheduling/SlurmQueues`에서 대기열을 제거하면 정적 및 동적 모두 Slurm 구성에서 제거되고 해당 Amazon EC2 인스턴스가 종료됩니다.
+ 대기열에서 `Scheduling/SlurmQueues/ComputeResources` 컴퓨팅 리소스를 제거하면 정적 및 동적 모두 이름이 `-*--*`인 모든 컴퓨팅 노드가 Slurm 구성에서 제거되고 해당 Amazon EC2 인스턴스가 종료됩니다.
컴퓨팅 리소스의 `MinCount` 파라미터를 변경할 때 `MaxCount`가 `MinCount`(정적 용량만 해당)와 같고 `MaxCount`가 `MinCount`(정적 및 동적 용량 혼합)보다 큰 경우 두 가지 시나리오를 구분할 수 있습니다.
### 정적 노드만 있는 용량 변경
+ `MinCount == MaxCount`인 경우 `MinCount`(및 `MaxCount`)를 늘릴 때 정적 노드 수를 `MinCount` `-st--`의 새 값으로 확장하여 클러스터를 구성하고 시스템은 필요한 새 정적 용량을 충족하기 위해 Amazon EC2 인스턴스를 계속 시작하려고 시도합니다.
+ `MinCount == MaxCount`인 경우 N 양 `MinCount`(및 `MaxCount`)을 줄일 때 마지막 N 정적 노드 `-st--...]`를 제거하여 클러스터를 구성하고 시스템은 해당 Amazon EC2 인스턴스를 종료합니다.
+ 원래 상태 `MinCount = MaxCount = 100`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ `MinCount` 및 `MaxCount: MinCount = MaxCount = 70`에서 `-30` 업데이트
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
### 혼합 노드의 용량 변경
`MinCount < MaxCount`인 경우 N 양(`MaxCount`가 변경되지 않은 상태로 유지된다고 가정)만큼 `MinCount`를 늘리면 정적 노드 수를 `MinCount`(`old_MinCount + N`)의 새 값으로 확장하여 클러스터가 구성되고 `-st--` 및 시스템은 필요한 새 정적 용량을 충족하기 위해 Amazon EC2 인스턴스를 계속 시작하려고 시도합니다. 또한 컴퓨팅 리소스의 `MaxCount` 용량을 적용하기 위해 *마지막 N 동적 노드 를 제거*하여 클러스터 구성이 업데이트되고 `-dy--[...]` 및 시스템은 해당 Amazon EC2 인스턴스를 종료합니다.
+ 원래 상태: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ \$130을 `MinCount : MinCount = 130 (MaxCount = 150)`으로 업데이트
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
`MinCount < MaxCount`인 경우 `MinCount` 및 `MaxCount`을 동일한 N 양만큼 늘리면 정적 노드 수를 `MinCount`(`old_MinCount + N`)의 새 값으로 확장하여 클러스터가 구성되고 `-st--` 시스템은 필요한 새 정적 용량을 충족하기 위해 Amazon EC2 인스턴스를 계속 시작하려고 시도합니다. 또한 새 노드를 적용하기 위해 동적 노드 수를 변경하지 않습니다.
`MaxCount` USD 상당.
+ 원래 상태: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ \$130을 `MinCount : MinCount = 130 (MaxCount = 180)`으로 업데이트
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 130 idle queue1-st-c5xlarge-[1-130]
```
`MinCount < MaxCount`인 경우 `MinCount`를 N 양만큼 줄일 경우(`MaxCount`는 변경되지 않는다고 가정) 마지막 N 정적 노드를 제거하여 클러스터를 구성하고 `-st--[...` 시스템은 해당 Amazon EC2 인스턴스를 종료합니다. 또한 컴퓨팅 리소스의 `MaxCount` 용량을 수용하기 위해 클러스터 구성은 격차를 메울 동적 노드 수를 확장하여 업데이트됩니다. `MaxCount - new_MinCount: -dy--[1..]` 이 경우 동적 노드이므로 스케줄러에 새 노드에서 보류 중인 작업이 없는 한 새 Amazon EC2 인스턴스가 시작되지 않습니다.
+ 원래 상태: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ `MinCount : MinCount = 70 (MaxCount = 120)`에서 -30 업데이트
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-80]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
`MinCount < MaxCount`인 경우 `MinCount` 및 `MaxCount`를 동일한 N 양으로 줄일 때 마지막 N 정적 노드를 제거하여 클러스터를 구성하고 `-st--...]` 시스템은 해당 Amazon EC2 인스턴스를 종료합니다.
또한 새 `MaxCount` 값을 적용하기 위해 동적 노드 수를 변경하지 않습니다.
+ 원래 상태: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ `MinCount : MinCount = 70 (MaxCount = 120)`에서 -30 업데이트
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 80 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 70 idle queue1-st-c5xlarge-[1-70]
```
`MinCount < MaxCount`인 경우 `MaxCount`를 N(`MinCount`는 변경되지 않은 상태로 유지된다고 가정)만큼 줄이면 마지막 N 동적 노드를 제거하여 클러스터가 구성되고 `-dy--]` 시스템이 실행 중인 해당하는 Amazon EC2 인스턴스를 종료합니다. 정적 노드에는 영향을 미치지 않습니다.
+ 원래 상태: `MinCount = 100; MaxCount = 150`
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 50 idle~ queue1-dy-c5xlarge-[1-50]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
+ `MaxCount : MinCount = 100 (MaxCount = 120)`에서 -30 업데이트
+
```
$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue1* up infinite 20 idle~ queue1-dy-c5xlarge-[1-20]
queue1* up infinite 100 idle queue1-st-c5xlarge-[1-100]
```
## 작업에 미치는 영향
노드가 제거되고 Amazon EC2 인스턴스가 종료되는 모든 경우, 작업 요구 사항을 충족하는 다른 노드가 없는 경우를 제외하고 제거된 노드에서 실행되는 sbatch 작업이 다시 대기열에 추가됩니다. 이 마지막 경우 NODE\$1FAIL 상태로 작업이 실패하고 대기열에서 사라지므로 수동으로 다시 제출해야 합니다.
클러스터 크기 조정 업데이트를 수행하려는 경우 계획된 업데이트 중에 제거될 노드에서 작업이 실행되지 않도록 할 수 있습니다. 이는 유지 관리에서 노드를 제거하도록 설정하여 가능합니다. 유지 관리에서 노드를 설정해도 결국 노드에서 이미 실행 중인 작업에는 영향을 주지 않습니다.
계획된 클러스터 크기 조정 업데이트를 통해 노드를 제거한다고 가정해 보겠습니다 `qeueu-st-computeresource-[9-10`]. 다음 명령을 사용하여 Slurm 예약을 생성할 수 있습니다.
```
sudo -i scontrol create reservation ReservationName=maint_for_update user=root starttime=now duration=infinite flags=maint,ignore_jobs nodes=qeueu-st-computeresource-[9-10]
```
이렇게 하면 노드 `qeueu-st-computeresource-[9-10]`에 `maint_for_update` 이름이 지정된 Slurm 예약이 생성됩니다. 예약이 생성된 시점부터 더 이상 `qeueu-st-computeresource-[9-10]` 노드로 실행될 수 있는 작업이 없습니다. 예약으로 인해 `qeueu-st-computeresource-[9-10]` 노드에 작업이 최종 할당되는 것을 막을 수는 없습니다.
클러스터 크기 조정 업데이트 후 크기 조정 업데이트 중에 제거된 노드에서만 Slurm 예약이 설정된 경우 유지 관리 예약이 자동으로 삭제됩니다. 대신 클러스터 크기 조정 업데이트 후에도 여전히 존재하는 노드에 대한 Slurm 예약을 생성한 경우 다음 명령을 사용하여 크기 조정 업데이트가 수행된 후 노드에 대한 유지 관리 예약을 제거할 수 있습니다.
```
sudo -i scontrol delete ReservationName=maint_for_update
```
Slurm 예약에 대한 자세한 내용은 [여기](https://slurm.schedmd.com/reservations.html)에서 공식 SchedMD 문서를 참조하세요.
## 용량 변경에 대한 클러스터 업데이트 프로세스
스케줄러 구성이 변경되면 클러스터 업데이트 프로세스 중에 다음 단계가 실행됩니다.
+ 중지 AWS ParallelCluster `clustermgtd (supervisorctl stop clustermgtd)`
+ AWS ParallelCluster 구성에서 업데이트된 Slurm 파티션 구성 생성
+ `slurmctld` 재시작(Chef 서비스 레시피를 통해 수행)
+ `slurmctld` 상태 확인 `(systemctl is-active --quiet slurmctld.service)`
+ Slurm 구성 다시 로드 `(scontrol reconfigure)`
+ `clustermgtd (supervisorctl start clustermgtd)` 시작
# 에서 AWS Batch (`awsbatch`) 스케줄러 사용 AWS ParallelCluster
**주의**
AWS CodeBuild 아시아 태평양(말레이시아)(`ap-southeast-5`) 및 아시아 태평양(태국)(`ap-southeast-7`) 리전에서는가 지원되지 않습니다. 따라서 ParallelCluster AWS Batch 통합은 해당 리전에서 지원되지 않습니다.
AWS ParallelCluster 는 AWS Batch 스케줄러도 지원합니다. 다음 주제에서 AWS Batch사용 방법을 설명합니다. 에 대한 자세한 내용은 단원을 AWS Batch참조하십시오[AWS Batch](https://aws.amazon.com/batch/). 설명서는 [AWS Batch 사용 설명서](https://docs.aws.amazon.com/batch/latest/userguide/)를 참조하세요.
**AWS ParallelCluster 에 대한 CLI 명령 AWS Batch**
`awsbatch` 스케줄러를 사용하면에 대한 AWS ParallelCluster AWS Batch CLI 명령이 AWS ParallelCluster 헤드 노드에 자동으로 설치됩니다. CLI는 AWS Batch API 작업을 사용하며 다음 작업을 허용합니다.
+ 작업 제출 및 관리
+ 작업, 대기열 및 호스트 모니터링
+ 기존 스케줄러 명령 미러링
**중요**
AWS ParallelCluster 는에 대한 GPU 작업을 지원하지 않습니다 AWS Batch. 자세한 내용은 [GPU 작업](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html)을 참조하세요.
이 CLI는 별도의 패키지로 배포됩니다. 자세한 내용은 [스케줄러 지원](moving-from-v2-to-v3.md#scheduler_support) 단원을 참조하십시오.
**Topics**
+ [`awsbsub`](awsbatchcli.awsbsub-v3.md)
+ [`awsbstat`](awsbatchcli.awsbstat-v3.md)
+ [`awsbout`](awsbatchcli.awsbout-v3.md)
+ [`awsbkill`](awsbatchcli.awsbkill-v3.md)
+ [`awsbqueues`](awsbatchcli.awsbqueues-v3.md)
+ [`awsbhosts`](awsbatchcli.awsbhosts-v3.md)
# `awsbsub`
작업을 클러스터의 작업 대기열에 제출합니다.
```
awsbsub [-h] [-jn JOB_NAME] [-c CLUSTER] [-cf] [-w WORKING_DIR]
[-pw PARENT_WORKING_DIR] [-if INPUT_FILE] [-p VCPUS] [-m MEMORY]
[-e ENV] [-eb ENV_DENYLIST] [-r RETRY_ATTEMPTS] [-t TIMEOUT]
[-n NODES] [-a ARRAY_SIZE] [-d DEPENDS_ON]
[command] [arguments [arguments ...]]
```
**중요**
AWS ParallelCluster 는에 대한 GPU 작업을 지원하지 않습니다 AWS Batch. 자세한 내용은 [GPU 작업](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html)을 참조하세요.
## 위치 인수
***command***
작업을 제출(지정된 명령이 컴퓨팅 인스턴스에서 사용 가능해야 함)하거나 전송할 파일 이름을 지정합니다. 또한 `--command-file` 섹션도 참조하세요.
**arguments**
(선택 사항) 명령 또는 명령 파일의 인수를 지정합니다.
## 이름 지정된 인수
**-jn *JOB\$1NAME*, --job-name *JOB\$1NAME***
작업 이름을 지정합니다. 첫 번째 자리는 문자 또는 숫자여야 합니다. 작업 이름은 최대 128자까지 포함할 수 있으며, 대문자와 소문자, 숫자, 하이픈(-), 밑줄(\$1)을 포함할 수 있습니다.
**-c *CLUSTER*, --cluster *CLUSTER***
사용할 클러스터를 지정합니다.
**-cf, --command-file**
명령이 컴퓨팅 인스턴스로 전송될 파일임을 나타냅니다.
기본값: False
**-w *WORKING\$1DIR*, --working-dir *WORKING\$1DIR***
작업의 작업 디렉터리로 사용할 폴더를 지정합니다. 작업 디렉터리가 지정되지 않으면 작업이 사용자의 홈 디렉터리에 있는 `job-` 하위 폴더에서 실행됩니다. 이 파라미터 또는 `--parent-working-dir` 파라미터를 사용할 수 있습니다.
**-pw *PARENT\$1WORKING\$1DIR*, --parent-working-dir *PARENT\$1WORKING\$1DIR***
작업의 작업 디렉터리에서 상위 폴더를 지정합니다. 상위 작업 디렉터리가 지정되지 않은 경우, 사용자의 홈 디렉터리가 기본적으로 지정됩니다. 상위 작업 디렉터리에 `job-`라는 하위 폴더가 만들어집니다. 이 파라미터 또는 `--working-dir` 파라미터를 사용할 수 있습니다.
**-if *INPUT\$1FILE*, --input-file *INPUT\$1FILE***
작업의 작업 디렉터리에서 컴퓨팅 인스턴스로 전송할 파일을 지정합니다. 여러 입력 파일 파라미터를 지정할 수 있습니다.
**-p *VCPUS*, --vcpus *VCPUS***
컨테이너를 위해 예약할 vCPU 개수를 지정합니다. `–nodes`와 함께 사용할 경우 노드당 vCPU 수를 식별합니다.
기본값: 1
**-m *MEMORY*, --memory *MEMORY***
작업에 제공할 메모리의 하드 제한(MiB)을 지정합니다. 작업에서 여기서 지정된 메모리 제한을 초과하려고 하면 해당 작업이 종료됩니다.
기본값: 128
**-e *ENV*, --env *ENV***
작업 환경으로 내보낼 환경 변수 이름의 목록을 쉼표로 구분하여 지정합니다. 모든 환경 변수를 내보내려면 'all'을 지정하세요. `–env-blacklist` 파라미터에 나열된 변수, 또는 `PCLUSTER_*`나 `AWS_*`로 시작하는 변수는 'all' 환경 변수 목록에 포함되지 않습니다.
**-eb *ENV\$1DENYLIST*, --env-blacklist *ENV\$1DENYLIST***
작업 환경으로 내보내지 않을**** 환경 변수 이름의 목록을 쉼표로 구분하여 지정합니다. 기본적으로, `HOME`, `PWD`, `USER`, `PATH`, `LD_LIBRARY_PATH`, `TERM` 및 `TERMCAP`은 내보내지 않습니다.
**-r *RETRY\$1ATTEMPTS*, --retry-attempts *RETRY\$1ATTEMPTS***
작업을 `RUNNABLE` 상태로 전환하는 횟수를 지정합니다. 1부터 10까지 시도 횟수를 지정할 수 있습니다. 시도 횟수가 1보다 큰 경우 작업이 실패하면 `RUNNABLE` 상태로 전환될 때까지 지정된 횟수만큼 다시 시도됩니다.
기본값: 1
**-t *TIMEOUT*, --timeout *TIMEOUT***
완료되지 않은 경우가 작업을 AWS Batch 종료하는 시간을 초 단위(작업 시도의 `startedAt` 타임스탬프에서 측정)로 지정합니다. 제한 시간 값은 60초 이상이어야 합니다.
**-n *NODES*, --nodes *NODES***
작업을 위해 예약할 노드 수를 지정합니다. 다중 노드 병렬 제출을 사용하려면 이 파라미터의 값을 지정합니다.
[`Scheduler`](Scheduling-v3.md#yaml-Scheduling-Scheduler)/[`AwsBatchQueues`](Scheduling-v3.md#Scheduling-v3-AwsBatchQueues)/[`CapacityType`](Scheduling-v3.md#yaml-Scheduling-AwsBatchQueues-CapacityType) 매개 변수를 `SPOT`으로 설정하면 다중 노드 병렬 작업이 지원되지 않습니다**. 또한 사용자 계정에는 `AWSServiceRoleForEC2Spot` 서비스 연결 역할이 있어야 합니다. 다음 AWS CLI 명령을 사용하여이 역할을 생성할 수 있습니다.
```
$ aws iam create-service-linked-role --aws-service-name spot.amazonaws.com
```
자세한 내용은 *Linux 인스턴스용 Amazon Elastic Compute Cloud 사용 설명서*의 [스팟 인스턴스 요청의 서비스 연결 역할](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests)을 참조하세요.
**-a *ARRAY\$1SIZE*, --array-size *ARRAY\$1SIZE***
배열의 크기를 지정합니다. 2\$110,000 범위의 값을 지정할 수 있습니다. 작업에 배열 속성을 지정하면 배열 작업이 됩니다.
**-d *DEPENDS\$1ON*, --depends-on *DEPENDS\$1ON***
작업에 대해 세미콜론으로 구분된 종속성 목록을 지정합니다. 작업은 최대 20개의 작업에 종속될 수 있습니다. 배열 작업의 작업 ID를 지정하지 않고 `SEQUENTIAL` 유형의 종속성을 지정할 수 있습니다. 순차 종속성을 사용하면 각 하위 배열 작업을 인덱스 0부터 순차적으로 완료할 수 있습니다. 배열 작업의 작업 ID로 N\$1TO\$1N 유형의 종속성을 지정할 수도 있습니다. N\$1TO\$1N 종속성이란 이 작업의 각 인덱스 하위 항목은 각 종속성의 해당 인덱스 하위 항목이 완료될 때까지 기다린 후에만 시작할 수 있다는 의미입니다. 이 파라미터의 구문은 "jobId=**,type=**;..."입니다.
# `awsbstat`
클러스터의 작업 대기열에 제출된 작업을 표시합니다.
```
awsbstat [-h] [-c CLUSTER] [-s STATUS] [-e] [-d] [job_ids [job_ids ...]]
```
## 위치 인수
***job\$1ids***
출력에 표시할 작업 ID 목록을 공백으로 구분하여 지정합니다. 작업이 작업 배열이면 모든 하위 작업이 표시됩니다. 단일 작업이 요청되면 자세한 버전으로 표시됩니다.
## 이름 지정된 인수
**-c *CLUSTER*, --cluster *CLUSTER***
사용할 클러스터를 지정합니다.
**-s *STATUS*, --status *STATUS***
포함할 작업 상태 목록을 쉼표로 구분하여 지정합니다. 기본 작업 상태는 “활성”입니다. 허용되는 값: `SUBMITTED`, `PENDING`, `RUNNABLE`, `STARTING`, `RUNNING`, `SUCCEEDED`, `FAILED` 및 `ALL`
기본값: “`SUBMITTED`,`PENDING`,`RUNNABLE`,`STARTING`,`RUNNING`”
**-e, --expand-children**
하위 항목(배열 및 다중 노드 병렬 모두)을 사용하여 작업을 확장합니다.
기본값: False
**-d, --details**
작업 세부 정보를 표시합니다.
기본값: False
# `awsbout`
지정된 작업의 출력을 표시합니다.
```
awsbout [-h] [-c CLUSTER] [-hd HEAD] [-t TAIL] [-s] [-sp STREAM_PERIOD] job_id
```
## 위치 인수
***job\$1id***
작업 ID를 지정합니다.
## 이름 지정된 인수
**-c *CLUSTER*, --cluster *CLUSTER***
사용할 클러스터를 지정합니다.
**-hd *HEAD*, --head *HEAD***
작업 출력의 첫 번째 *HEAD* 행을 가져옵니다.
**-t *TAIL*, --tail *TAIL***
작업 출력의 마지막 행을 가져옵니다.
**-s, --stream**
작업 출력을 가져온 다음 추가 출력이 생성될 때까지 대기합니다. 이 인수는 -tail과 함께 사용하여 작업 출력의 마지막 행에서 시작할 수 있습니다.
기본값: False
**-sp *STREAM\$1PERIOD*, --stream-period *STREAM\$1PERIOD***
스트리밍 기간을 설정합니다.
기본값: 5
# `awsbkill`
클러스터에 제출된 작업을 취소하거나 종료합니다.
```
awsbkill [-h] [-c CLUSTER] [-r REASON] job_ids [job_ids ... ]
```
## 위치 인수
***job\$1ids***
작업을 취소하거나 종료할 작업 ID 목록을 공백으로 구분하여 지정합니다.
## 이름 지정된 인수
**-c *CLUSTER*, --cluster *CLUSTER***
사용할 클러스터의 이름을 나타냅니다.
**-r *REASON*, --reason *REASON***
작업에 첨부할 메시지를 표시하고 취소 이유를 설명합니다.
기본값: “Terminated by the user”
# `awsbqueues`
클러스터와 연관된 작업 대기열을 표시합니다.
```
awsbqueues [-h] [-c CLUSTER] [-d] [job_queues [job_queues ... ]]
```
## 위치 인수
***job\$1queues***
표시할 대기열 이름의 목록을 공백으로 구분하여 지정합니다. 단일 대기열이 요청되면 자세한 버전으로 표시됩니다.
## 이름 지정된 인수
**-c *CLUSTER*, --cluster *CLUSTER***
사용할 클러스터의 이름을 지정합니다.
**-d, --details**
대기열의 세부 정보 표시 여부를 나타냅니다.
기본값: False
# `awsbhosts`
클러스터의 컴퓨팅 환경에 속한 호스트를 표시합니다.
```
awsbhosts [-h] [-c CLUSTER] [-d] [instance_ids [instance_ids ... ]]
```
## 위치 인수
***instance\$1ids***
공백으로 구분된 인스턴스 ID 목록을 지정합니다. 단일 인스턴스가 요청되면 자세한 버전으로 표시됩니다.
## 이름 지정된 인수
**-c *CLUSTER*, --cluster *CLUSTER***
사용할 클러스터의 이름을 지정합니다.
**-d, --details**
호스트의 세부 정보 표시 여부를 나타냅니다.
기본값: False