기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 에서 지원하는 스케줄러 AWS ParallelCluster AWS ParallelCluster 는 [`scheduler`](cluster-definition.md#scheduler) 설정을 사용하여 설정된 여러 스케줄러를 지원합니다. **참고** 버전 2.11.5부터 SGE 또는 Torque 스케줄러 사용을 지원하지 AWS ParallelCluster 않습니다. 2.11.4 이하의 버전에서는 계속 사용할 수 있지만 AWS 서비스 및 AWS 지원 팀의 향후 업데이트 또는 문제 해결 지원을 받을 수 없습니다. **Topics** + [Son of Grid Engine](schedulers.sge.md) + [Slurm Workload Manager](schedulers.slurm.md) + [Torque Resource Manager](schedulers.torque.md) + [AWS Batch](awsbatchcli.md) # Son of Grid Engine (`sge`) **참고** 버전 2.11.5부터 SGE 또는 Torque 스케줄러 사용을 지원하지 AWS ParallelCluster 않습니다. 2.11.4 이하의 버전에서는 계속 사용할 수 있지만 AWS 서비스 및 AWS 지원 팀의 향후 업데이트 또는 문제 해결 지원을 받을 수 없습니다. AWS ParallelCluster 버전 2.11.4 이하에서는 Son of Grid Engine 8.1.9를 사용합니다. # Slurm Workload Manager (`slurm`) AWS ParallelCluster 버전 2.11.9는 Slurm 20.11.9을 사용합니다. 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) 섹션을 참조하세요. **중요** AWS ParallelCluster 는 기본적으로 제공되는 Slurm 구성 파라미터로 테스트됩니다. 이러한 Slurm 구성 파라미터를 변경하는 데 따른 위험은 사용자 본인이 감수해야 합니다. 이 서비스는 최선의 작업을 기반으로 지원됩니다. | AWS ParallelCluster 버전(들) | 지원되는 Slurm 버전 | | --- | --- | | 2.11.7, 2.11.8, 2.11.9 | 20.11.9 | | 2.11.4에서 2.11.6까지 | 20.11.8 | | 2.11.0에서 2.11.3까지 | 20.11.7 | | 2.10.4 | 20.02.7 | | 2.9.0에서 2.10.3까지 | 20.02.4 | | 2.6에서 2.8.1까지 | 19.05.5 | | 2.5.0, 2.5.1 | 19.05.3-2 | | 2.3.1에서 2.4.1까지 | 18.08.6-2 | | 2.3.1 이전 | 16.05.3-1 | # 다중 대기열 모드 AWS ParallelCluster 버전 2.9.0에는 여러 대기열 모드가 도입되었습니다. [`scheduler`](cluster-definition.md#scheduler)를 `slurm`로 설정하고 [`queue_settings`](cluster-definition.md#queue-settings) 설정을 정의하면 다중 대기열 모드가 지원됩니다. 이 모드를 사용하면 컴퓨팅 노드에서 다양한 인스턴스 유형이 공존할 수 있습니다. 다양한 인스턴스 유형을 포함하는 컴퓨팅 리소스는 필요에 따라 스케일 업 또는 스케일 다운할 수 있습니다. 대기열 모드에서는 최대 5개의 대기열이 지원되며 각 [`[queue]` 섹션](queue-section.md)은 최대 3개의 [`[compute_resource]` 섹션](compute-resource-section.md)을 참조할 수 있습니다. 각 [`[queue]` 섹션](queue-section.md)은 Slurm Workload Manager의 파티션입니다. 자세한 내용은 [다중 대기열 모드를 위한 Slurm 가이드](multiple-queue-mode-slurm-user-guide.md) 및 [다중 대기열 모드 자습서](tutorial-mqm.md) 섹션을 참조하세요. 대기열의 각 [`[compute_resource]` 섹션은](compute-resource-section.md) 서로 다른 인스턴스 유형을 가져야 하며, 각 `[compute_resource]`는 다시 정적 노드와 동적 노드로 구분됩니다. 각 `[compute_resource]`의 정적 노드는 1부터 [`min_count`](compute-resource-section.md#compute-resource-min-count)의 값까지 번호가 매겨집니다. 각 `[compute_resource]`의 동적 노드는 1부터 ([`max_count`](compute-resource-section.md#compute-resource-max-count)-`min_count`)까지 번호가 매겨집니다. 예를 들어, `min_count`가 2이고 `max_count`가 10인 경우 `[compute_resource]`의 동적 노드는 1에서 8까지 번호가 매겨집니다. 언제든지 `[compute_resource]`에는 0과 동적 노드의 최대 수 사이의 번호가 있을 수 있습니다. 컴퓨팅 플릿으로 시작되는 인스턴스는 동적으로 할당됩니다. 이를 관리하는 데 도움이 되도록 각 노드에 대해 호스트 이름이 생성됩니다. 호스트 이름 형식은 다음과 같습니다. `$HOSTNAME=$QUEUE-$STATDYN-$INSTANCE_TYPE-$NODENUM` + `$QUEUE`은 대기열의 이름입니다. 예를 들어 섹션이 시작되면 `[queue queue-name]` "`$QUEUE`"는 "*queue-name*"입니다. + `$STATDYN`은 정적 노드에는 `st` 또는 동적 노드에는 `dy`입니다. + `$INSTANCE_TYPE`은 [`instance_type`](compute-resource-section.md#compute-resource-instance-type) 설정에 있는 `[compute_resource]`의 인스턴스 유형입니다. + `$NODENUM`은 노드의 번호입니다. `$NODENUM`은 정적 노드의 경우 1과 [`min_count`](compute-resource-section.md#compute-resource-min-count)의 값 사이, 동적 노드의 경우 1과 ([`max_count`](compute-resource-section.md#compute-resource-max-count)-`min_count`) 사이입니다. 호스트 이름과 FQDN(정규화된 도메인 이름)은 모두 Amazon Route 53 호스팅 영역을 사용하여 생성됩니다. FQDN은 `$HOSTNAME.$CLUSTERNAME.pcluster`입니다. 여기서 `$CLUSTERNAME`는 클러스터에 사용되는 [`[cluster]` 섹션](cluster-definition.md)의 이름입니다. 구성을 대기열 모드로 변환하려면 [`pcluster-config convert`](pcluster-config.md#pcluster-config-convert) 명령을 사용합니다. 이름이 `[queue compute]`인 단일 [`[queue]` 섹션](queue-section.md)으로 업데이트된 구성을 작성합니다. 해당 대기열에는 이름이 `[compute_resource default]`인 단일 [`[compute_resource]` 섹션이](compute-resource-section.md)이 있습니다. `[queue compute]` 및 `[compute_resource default]`는 지정된 [`[cluster]` 섹션](cluster-definition.md)에서 마이그레이션된 설정이 있습니다. # 다중 대기열 모드를 위한 Slurm 가이드 AWS ParallelCluster 버전 2.9.0에는 여러 대기열 모드와 Slurm Workload Manager (Slurm)에 대한 새로운 조정 아키텍처가 도입되었습니다. 다음 섹션은 새로 도입된 확장 아키텍처가 적용된 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` 상태로 전환될 수 있습니다. 다음 목록은 클라우드 노드 수명 주기에서 이러한 상태의 여러 측면을 자세히 설명합니다. + `~` 상태의 노드는 `sinfo`에서 `POWER_SAVING` 접미사(예: `idle~`)와 함께 표시됩니다. 이 상태에서는 노드를 지원하는 EC2 인스턴스가 없습니다. 하지만 Slurm은 여전히 노드에 작업을 할당할 수 있습니다. + `POWER_UP` 상태로 전환되는 노드는 `sinfo`에서 `#` 접미사(예: `idle#`)와 함께 표시됩니다. + Slurm이 `POWER_SAVING` 상태의 노드에 작업을 할당하면 노드가 자동으로 `POWER_UP` 상태로 전환됩니다. 그렇지 않으면 `scontrol update nodename=nodename state=power_up` 명령을 사용하여 노드를 수동으로 `POWER_UP` 상태로 전환할 수 있습니다. 이 단계에서는 `ResumeProgram`가 호출되고 EC2 인스턴스가 시작되고 `POWER_UP` 노드를 지원하도록 구성됩니다. + 현재 사용할 수 있는 노드는 `sinfo`에 접미사(예: `idle`)가 없는 상태로 표시됩니다. 노드가 설정되고 클러스터에 가입되면 작업을 실행할 수 있게 됩니다. 이 단계에서는 노드가 적절하게 구성되고 사용할 준비가 됩니다. 일반적으로 EC2의 인스턴스 수는 사용 가능한 노드의 수와 같게 하는 것이 좋습니다. 대부분의 경우 정적 노드는 클러스터가 생성된 후에 항상 사용할 수 있습니다. + `POWER_DOWN` 상태로 전환되는 노드는 `sinfo`에서 `%` 접미사(예: `idle%`)와 함께 표시됩니다. 동적 노드는 [`scaledown_idletime`](scaling-section.md#scaledown-idletime) 이후에 자동으로 `POWER_DOWN` 상태가 됩니다. 반면 정적 노드는 대부분의 경우 전원이 꺼지지 않습니다. 하지만 `scontrol update nodename=nodename state=powering_down` 명령을 사용하여 노드를 수동으로 `POWER_DOWN` 상태로 전환할 수 있습니다. 이 상태에서는 노드와 연결된 인스턴스가 종료되고 노드는 다시 해당 `POWER_SAVING` 상태로 재설정되며 [`scaledown_idletime`](scaling-section.md#scaledown-idletime) 이후에 사용할 수 있습니다. `scaledown-idletime` 설정이 Slurm 구성에 `SuspendTimeout` 설정으로 저장됩니다. + 오프라인 상태인 노드는 `sinfo`에서 `*` 접미사(예: `down*`)와 함께 나타납니다. Slurm 컨트롤러가 노드에 연결할 수 없거나 정적 노드가 비활성화되고 지원 인스턴스가 종료되면 노드는 오프라인 상태가 됩니다. 이제 다음 `sinfo` 예제에 표시된 노드 상태를 고려해 보세요. ``` $ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST efa up infinite 4 idle~ efa-dy-c5n18xlarge-[1-4] efa up infinite 1 idle efa-st-c5n18xlarge-1 gpu up infinite 1 idle% gpu-dy-g38xlarge-1 gpu up infinite 9 idle~ gpu-dy-g38xlarge-[2-10] ondemand up infinite 2 mix# ondemand-dy-c52xlarge-[1-2] ondemand up infinite 18 idle~ ondemand-dy-c52xlarge-[3-10],ondemand-dy-t2xlarge-[1-10] spot* up infinite 13 idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3] spot* up infinite 2 idle spot-st-t2large-[1-2] ``` `spot-st-t2large-[1-2]` 및 `efa-st-c5n18xlarge-1` 노드에는 이미 백업 인스턴스가 설정되어 있고 사용할 수 있습니다. `ondemand-dy-c52xlarge-[1-2]` 노드는 현재 `POWER_UP` 상태이며 몇 분 이내에 사용할 수 있습니다. `gpu-dy-g38xlarge-1` 노드는 현재 `POWER_DOWN` 상태이고 [`scaledown_idletime`](scaling-section.md#scaledown-idletime)(기본값 120초) 이후 `POWER_SAVING` 상태로 전환됩니다. 다른 모든 노드는 이를 지원하는 EC2 인스턴스가 없는 `POWER_SAVING` 상태입니다. ## 사용 가능한 노드로 작업하기 사용 가능한 노드는 EC2 인스턴스에서 지원합니다. 기본적으로 노드 이름을 사용하여 인스턴스에 직접 SSH로 연결할 수 있습니다(예:`ssh efa-st-c5n18xlarge-1`). `scontrol show nodes nodename` 명령과 `NodeAddr` 필드 확인을 사용하여 인스턴스의 사설 IP 주소를 검색할 수 있습니다. 사용할 수 없는 노드의 경우 `NodeAddr` 필드는 실행 중인 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-c5n18xlarge-[1-4] efa up infinite 1 idle efa-st-c5n18xlarge-1 gpu up infinite 10 idle~ gpu-dy-g38xlarge-[1-10] ondemand up infinite 20 idle~ ondemand-dy-c52xlarge-[1-10],ondemand-dy-t2xlarge-[1-10] spot* up infinite 13 idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3] spot* up infinite 2 idle spot-st-t2large-[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-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2] 13 gpu wrap ubuntu CF 0:05 1 gpu-dy-g38xlarge-1 7 spot wrap ubuntu R 2:48 1 spot-st-t2large-1 8 efa wrap ubuntu R 0:39 1 efa-dy-c5n18xlarge-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-c5n18xlarge-[2-4] efa up infinite 1 mix efa-dy-c5n18xlarge-1 efa up infinite 1 idle efa-st-c5n18xlarge-1 gpu up infinite 1 mix~ gpu-dy-g38xlarge-1 gpu up infinite 9 idle~ gpu-dy-g38xlarge-[2-10] ondemand up infinite 10 mix# ondemand-dy-c52xlarge-[1-8],ondemand-dy-t2xlarge-[1-2] ondemand up infinite 10 idle~ ondemand-dy-c52xlarge-[9-10],ondemand-dy-t2xlarge-[3-10] spot* up infinite 13 idle~ spot-dy-c5xlarge-[1-10],spot-dy-t2large-[1-3] spot* up infinite 1 mix spot-st-t2large-1 spot* up infinite 1 idle spot-st-t2large-2 ``` ## 노드 상태 및 특성 대부분의 경우 노드 상태는이 주제의 앞부분에서 설명한 클라우드 노드 수명 주기의 특정 프로세스에 AWS ParallelCluster 따라에서 완전히 관리됩니다. 그러나는 `DOWN` 및 `DRAINED` 상태의 비정상 노드와 비정상 지원 인스턴스가 있는 노드 AWS ParallelCluster 도 교체하거나 종료합니다. 자세한 내용은 [`clustermgtd`](processes.md#clustermgtd) 단원을 참조하십시오. ## 파티션 상태 AWS ParallelCluster 는 다음과 같은 파티션 상태를 지원합니다. Slurm 파티션은 AWS ParallelCluster의 대기열입니다. + `UP`: 파티션이 활성 상태임을 나타냅니다. 이것은 파티션의 기본 상태입니다. 이 상태에서는 파티션의 모든 노드가 활성화되어 사용할 수 있습니다. + `INACTIVE`: 파티션이 비활성 상태임을 나타냅니다. 이 상태에서는 비활성 파티션의 노드를 지원하는 모든 인스턴스가 종료됩니다. 비활성 파티션의 노드에 대해서는 새 인스턴스가 시작되지 않습니다. ## pcluster 시작 및 중지 [`pcluster stop`](pcluster.stop.md)이 실행되면 모든 파티션이 `INACTIVE` 상태로 전환되고 AWS ParallelCluster 프로세스는 파티션을 `INACTIVE` 상태로 유지합니다. [`pcluster start`](pcluster.start.md)를 실행하면 모든 파티션이 초기에 `UP` 상태로 전환됩니다. 그러나 AWS ParallelCluster 프로세스는 파티션을 `UP` 상태로 유지하지 않습니다. 파티션 상태를 수동으로 변경해야 합니다. 몇 분 후 모든 고정 노드를 사용할 수 있습니다. 참고로 파티션을 `UP`으로 설정해도 동적 용량은 증가하지 않습니다. [`initial_count`](compute-resource-section.md#compute-resource-initial-count)이 [`max_count`](compute-resource-section.md#compute-resource-max-count)보다 크면 [`initial_count`](compute-resource-section.md#compute-resource-initial-count)은 파티션 상태가 `UP` 상태로 변경될 때 만족하지 않을 수 있습니다. [`pcluster start`](pcluster.start.md) 및 [`pcluster stop`](pcluster.stop.md)가 실행되고 있는 경우 [`pcluster status`](pcluster.status.md) 명령을 실행하고 `ComputeFleetStatus`를 확인하여 클러스터의 상태를 확인할 수 있습니다. 다음과 같은 잠재적인 상태가 있습니다. + `STOP_REQUESTED`: [`pcluster stop`](pcluster.stop.md) 요청이 클러스터로 전송됩니다. + `STOPPING`: `pcluster` 프로세스가 현재 클러스터를 중지하는 중입니다. + `STOPPED`: `pcluster` 프로세스가 중지 프로세스를 완료했고, 모든 파티션이 `INACTIVE` 상태에 있으며, 모든 컴퓨팅 인스턴스가 종료되었습니다. + `START_REQUESTED`: [`pcluster start`](pcluster.start.md) 요청이 클러스터로 전송됩니다. + `STARTING`: `pcluster` 프로세스가 현재 클러스터를 시작하는 중입니다. + `RUNNING`: `pcluster` 프로세스가 시작 프로세스를 마쳤고, 모든 파티션이 `UP` 상태에 있으며, 몇 분 후에 정적 노드를 사용할 수 있습니다. ## 대기열 수동 제어 클러스터의 노드 또는 대기열(Slurm 파티션이라고 함)을 수동으로 제어해야 하는 경우도 있습니다. 다음과 같은 일반적인 절차를 통해 클러스터의 노드를 관리할 수 있습니다. + `POWER_SAVING` 상태의 동적 노드 전원 켜기: `scontrol update nodename=nodename state=power_up` 명령을 실행하거나 특정 수의 노드를 요청하는 플레이스홀더 `sleep 1` 작업을 제출하고 Slurm에 의존하여 필요한 수의 노드에 전원을 공급하세요. + 이전의 동적 노드 전원 끄기[`scaledown_idletime`](scaling-section.md#scaledown-idletime): `scontrol update nodename=nodename state=down` 명령을 `DOWN` 사용하여 동적 노드를 로 설정합니다.는 중단된 동적 노드를 AWS ParallelCluster 자동으로 종료하고 재설정합니다. 일반적으로 `scontrol update nodename=nodename state=power_down` 명령을 사용하여 노드를 `POWER_DOWN`으로 직접 설정하지 않는 것이 좋습니다. AWS ParallelCluster 가 전원 차단 프로세스를 자동으로 처리하기 때문입니다. 수동 개입이 필요하지 않습니다. 따라서 가능하면 노드를 `DOWN`로 설정하는 것이 좋습니다. + 대기열(파티션)을 비활성화하거나 특정 파티션의 모든 정적 노드를 중지하세요. `scontrol update partition=queue name state=inactive` 명령을 사용하여 특정 대기열을 `INACTIVE`로 설정하세요. 이렇게 하면 파티션의 노드를 지원하는 모든 인스턴스가 종료됩니다. + 대기열(파티션) 활성화: `scontrol update partition=queue name state=up` 명령으로 특정 대기열을 `INACTIVE`로 설정합니다. ## 동작 및 조정 규모 조정 다음은 일반적인 규모 조정 워크플로의 예입니다. + 스케줄러는 두 개의 노드가 필요한 작업을 수신합니다. + 스케줄러는 두 노드를 `POWER_UP` 상태로 전환하고 노드 이름(예: `queue1-dy-c5xlarge-[1-2]`)을 사용하여 `ResumeProgram`을 호출합니다. + `ResumeProgram`은 EC2 인스턴스 2개를 시작하고 `queue1-dy-c5xlarge-[1-2]`의 프라이빗 IP 주소와 호스트 이름을 할당합니다. 이후 `ResumeTimeout`을 기다린 후[기본 60분(1시간)] 노드를 재설정합니다. + 인스턴스가 구성되어 클러스터에 들어갑니다. 인스턴스에서 작업이 실행되기 시작합니다. + 작업이 완료되었습니다. + 구성된 `SuspendTime`이 경과한 후([`scaledown_idletime`](scaling-section.md#scaledown-idletime)로 설정), 스케줄러는 인스턴스를 `POWER_SAVING` 상태로 전환합니다. 스케줄러는 `queue1-dy-c5xlarge-[1-2]`을 `POWER_DOWN` 상태를 설정하고 노드 이름을 사용하여 `SuspendProgram`을 호출합니다. + 두 노드에 대해 `SuspendProgram`이 호출됩니다. 예를 들어 노드는 `SuspendTimeout`[기본 120초(2분)]을 위해 `idle%`로 남아 있음으로써 `POWER_DOWN` 상태로 유지됩니다. 노드의 전원이 꺼지고 있음을 `clustermgtd`가 감지하면 지원 인스턴스가 종료됩니다. 그런 다음 `queue1-dy-c5xlarge-[1-2]`을 유휴 상태로 구성하고 사설 IP 주소와 호스트 이름을 재설정하여 향후 작업에 다시 사용할 수 있도록 합니다. 이제 문제가 발생하여 특정 노드의 인스턴스를 어떤 이유로 시작할 수 없는 경우 다음과 같은 상황이 발생합니다. + 스케줄러는 두 개의 노드가 필요한 작업을 수신합니다. + 스케줄러는 두 개의 클라우드 버스팅 노드를 `POWER_UP` 상태로 전환하고 노드 이름을 사용하여 `ResumeProgram`를 호출합니다(예: `queue1-dy-c5xlarge-[1-2]`). + `ResumeProgram`은 EC2 인스턴스 1개만 시작하고 `queue1-dy-c5xlarge-1`를 구성하지만 `queue1-dy-c5xlarge-2`에 대한 인스턴스를 시작하지 못했습니다. + `queue1-dy-c5xlarge-1`은 영향을 받지 않으며 `POWER_UP` 상태에 도달하면 온라인 상태가 됩니다. + `queue1-dy-c5xlarge-2`은 `POWER_DOWN` 상태가 되고 Slurm이 노드 장애를 감지했으므로 작업이 자동으로 대기열에 추가됩니다. + `queue1-dy-c5xlarge-2`은 `SuspendTimeout` 이후에 사용할 수 있습니다[기본 120초(2분)]. 그동안에는 작업이 대기되며 다른 노드에서 실행을 시작할 수 있습니다. + 장애가 발생하지 않고 사용 가능한 노드에서 작업을 실행할 수 있을 때까지 위 프로세스가 반복됩니다. 필요한 경우 두 가지 타이밍 매개 변수를 조정할 수 있습니다. + `ResumeTimeout`[기본 60분(1시간)]: `ResumeTimeout`은 노드를 작동 중지 상태로 전환하기 전에 Slurm이 대기하는 시간을 제어합니다. + 사전/사후 설치 프로세스가 그렇게 오래 걸린다면 이것을 연장하는 것이 유용할 수 있습니다. + 또한 문제가 있는 경우 노드를 교체하거나 재설정하기 전에가 AWS ParallelCluster 대기하는 최대 시간입니다. 시작 또는 설정 중에 오류가 발생하면 컴퓨팅 노드가 자동으로 종료됩니다. 그런 다음 인스턴스가 종료된 것을 확인하면 AWS ParallelCluster 프로세스가 노드를 대체하기도 합니다. + `SuspendTimeout`[기본 120초(2분)]: `SuspendTimeout`은 노드를 시스템에 다시 배치하고 다시 사용할 준비가 되는 시간을 제어합니다. + `SuspendTimeout`이 짧을수록 노드가 더 빨리 재설정되고, Slurm는 인스턴스를 더 자주 시작하려고 할 수 있습니다. + `SuspendTimeout`이 길수록 장애가 발생한 노드의 재설정 속도가 느려집니다. 그러는 동안 Slurm은 다른 노드를 사용하려고 합니다. `SuspendTimeout`이 몇 분 이상이면 Slurm가 시스템의 모든 노드를 순환하려 합니다. 대규모 시스템(1,000개 이상의 노드)에서는 Slurm가 받는 스트레스를 줄이기 위해 장애가 발생한 작업을 다시 대기열에 추가하려고 할 때 더 긴 `SuspendTimeout`을 사용하는 것이 유용할 수 있습니다. + `SuspendTimeout`는 노드의 백업 인스턴스를 종료하기 위해 AWS ParallelCluster 대기한 시간을 참조하지 않습니다. `power down` 노드의 백업 인스턴스는 즉시 종료됩니다. 종료 프로세스는 일반적으로 몇 분 이내에 완료됩니다. 하지만 이 기간 동안에는 노드가 전원 차단 상태를 유지하며 스케줄러에서 사용될 수 없습니다. ## 새 아키텍처에 대한 로그 다음 목록에는 다중 대기열 아키텍처의 키 로그가 포함되어 있습니다. Amazon CloudWatch Logs에 사용되는 로그 스트림 이름은 `{hostname}.{instance_id}.{logIdentifier}` 형식을 사용합니다. 여기서 *LogiDentifier*는 로그 이름 뒤에 옵니다. 자세한 내용은 [Amazon CloudWatch Logs와 통합](cloudwatch-logs.md) 단원을 참조하십시오. + `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` 로그에서 자세한 내용을 확인하세요. 이유가 EC2와 관련된 것이라면 는 도구를 사용하여 해당 인스턴스의 상태 또는 로그를 확인합니다. 예를 들어 인스턴스에 예약된 이벤트가 있는지 또는 EC2 상태 확인에 실패했는지 확인할 수 있습니다. + `clustermgtd`가 노드를 종료하지 않은 경우 `computemgtd`가 노드를 종료했는지 또는 EC2가 스팟 인스턴스를 회수하기 위해 인스턴스를 종료했는지 확인하세요. + 노드 장애 + 대부분의 경우 노드에 장애가 발생하면 작업이 자동으로 대기열에 추가됩니다. `slurmctld` 로그에서 작업이나 노드에 장애가 발생한 이유를 확인하고 거기에서 상황을 분석하세요. 인스턴스 교체 또는 종료 시 실패, 노드 전원 차단 시 실패**** + 일반적으로 `clustermgtd`가 모든 예상 인스턴스 종료 작업을 처리합니다. `clustermgtd` 로그에서 노드 교체 또는 종료에 실패한 이유를 확인하세요. + 동적 노드가 [`scaledown_idletime`](scaling-section.md#scaledown-idletime)에 실패한 경우 `SuspendProgram` 로그에서 `slurmctld` 프로그램이 특정 노드를 인수로 사용하여 호출했는지 확인하세요. `SuspendProgram`는 실제로 특정 작업을 수행하지 않습니다. 그보다는 호출될 때만 로그를 기록합니다. 모든 인스턴스 종료 및 `NodeAddr` 재설정은 `clustermgtd`가 완료합니다. Slurm는 `SuspendTimeout` 후 노드를 `IDLE`로 만듭니다. **기타 문제** + AWS ParallelCluster 는 작업 할당 또는 조정 결정을 내리지 않습니다. Slurm의 지침에 따라 리소스를 시작, 종료 및 유지 관리하려고 시도할 뿐입니다. 작업 할당, 노드 할당 및 규모 조정 결정과 관련된 문제는 `slurmctld` 로그에서 오류를 확인하세요. # Torque Resource Manager (`torque`) **참고** 버전 2.11.5부터 SGE 또는 Torque 스케줄러 사용을 지원하지 AWS ParallelCluster 않습니다. 2.11.4 이하의 버전에서는 계속 사용할 수 있지만 AWS 서비스 및 AWS 지원 팀의 향후 업데이트 또는 문제 해결 지원을 받을 수 없습니다. AWS ParallelCluster 버전 2.11.4 이하에서는 Torque Resource Manager 6.1.2를 사용합니다. Torque Resource Manager 6.1.2에 대한 자세한 내용은 [http://docs.adaptivecomputing.com/torque/6-1-2/releaseNotes/torquerelnote.htm](http://docs.adaptivecomputing.com/torque/6-1-2/releaseNotes/torquerelnote.htm) 섹션을 참조하세요. 설명서는 [http://docs.adaptivecomputing.com/torque/6-1-2/adminGuide/torque.htm](http://docs.adaptivecomputing.com/torque/6-1-2/adminGuide/torque.htm) 섹션을 참조하세요. 소스 코드는 [https://github.com/adaptivecomputing/torque/tree/6.1.2](https://github.com/adaptivecomputing/torque/tree/6.1.2) 섹션을 참조하세요. AWS ParallelCluster 버전 2.4.0 이하에서는 Torque Resource Manager 6.0.2를 사용합니다. 릴리스 정보는 [http://docs.adaptivecomputing.com/torque/6-0-2/releaseNotes/torqueReleaseNotes6.0.2.pdf](http://docs.adaptivecomputing.com/torque/6-0-2/releaseNotes/torqueReleaseNotes6.0.2.pdf) 섹션을 참조하세요. 설명서는 [http://docs.adaptivecomputing.com/torque/6-0-2/adminGuide/help.htm](http://docs.adaptivecomputing.com/torque/6-0-2/adminGuide/help.htm) 섹션을 참조하세요. 소스 코드는 [https://github.com/adaptivecomputing/torque/tree/6.0.2](https://github.com/adaptivecomputing/torque/tree/6.0.2) 섹션을 참조하세요. # AWS Batch (`awsbatch`) 에 대한 자세한 내용은 단원을 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 CLI 명령이 AWS ParallelCluster 헤드 노드에 자동으로 설치 AWS Batch 됩니다. CLI는 AWS Batch API 작업을 사용하며 다음 작업을 허용합니다. + 작업 제출 및 관리 + 작업, 대기열 및 호스트 모니터링 + 기존 스케줄러 명령 미러링 **중요** AWS ParallelCluster 는에 대한 GPU 작업을 지원하지 않습니다 AWS Batch. 자세한 내용은 [GPU 작업](https://docs.aws.amazon.com/batch/latest/userguide/gpu-jobs.html)을 참조하세요. **Topics** + [`awsbsub`](awsbatchcli.awsbsub.md) + [`awsbstat`](awsbatchcli.awsbstat.md) + [`awsbout`](awsbatchcli_awsbout.md) + [`awsbkill`](awsbatchcli_awsbkill.md) + [`awsbqueues`](awsbatchcli_awsbqueues.md) + [`awsbhosts`](awsbatchcli_awsbhosts.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*** 작업을 위해 예약할 노드 수를 지정합니다. 다중 노드 병렬 제출을 사용하려면 이 파라미터의 값을 지정합니다. [`cluster_type`](cluster-definition.md#cluster-type) 파라미터가 `spot`로 설정된 경우 다중 노드 병렬 작업은 지원되지 않습니다. **-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