Slurm 다중 대기열 모드에 대한 가이드 - AWS ParallelCluster
개요클라우드 노드 수명 주기사용 가능한 노드로 작업하기작업 상태 및 제출노드 상태 및 특성파티션 상태pcluster 시작 및 중지대기열 수동 제어동작 및 조정 규모 조정새 아키텍처에 대한 로그일반적인 문제 및 디버그 방법:

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

Slurm 다중 대기열 모드에 대한 가이드

AWS ParallelCluster 버전 2.9.0에는 여러 대기열 모드와 에 대한 새로운 조정 아키텍처가 도입되었습니다.Slurm Workload Manager (Slurm).

다음 섹션에서는 를 사용하는 방법에 대한 일반적인 개요를 제공합니다.Slurm 새로 도입된 스케일링 아키텍처가 포함된 클러스터입니다.

개요

새로운 스케일링 아키텍처는 다음을 기반으로 합니다.Slurm의 Cloud Scheduling Guide 및 절전 플러그인. 절전 플러그인에 대한 자세한 내용은 섹션을 참조하세요. Slurm 절전 가이드 . 새 아키텍처에서는 클러스터에 사용할 수 있는 리소스가 일반적으로 에 사전 정의되어 있습니다.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는 이 호출되고 POWER_UP 노드를 백업하도록 EC2 인스턴스가 시작되고 구성됩니다.

  • 현재 사용할 수 있는 노드는 sinfo에 접미사(예: idle)가 없는 상태로 표시됩니다. 노드가 설정되고 클러스터에 가입되면 작업을 실행할 수 있게 됩니다. 이 단계에서는 노드가 적절하게 구성되고 사용할 준비가 됩니다. 일반적으로 의 인스턴스 수는 사용 가능한 노드 수와 EC2 동일한 것이 좋습니다. 대부분의 경우 정적 노드는 클러스터가 생성된 후에 항상 사용할 수 있습니다.

  • POWER_DOWN 상태로 전환되는 노드는 sinfo에서 % 접미사(예: idle%)와 함께 표시됩니다. 동적 노드는 scaledown_idletime 이후에 자동으로 POWER_DOWN 상태가 됩니다. 반면 정적 노드는 대부분의 경우 전원이 꺼지지 않습니다. 하지만 scontrol update nodename=nodename state=powering_down 명령을 사용하여 노드를 수동으로 POWER_DOWN 상태로 전환할 수 있습니다. 이 상태에서는 노드와 연결된 인스턴스가 종료되고 노드는 다시 해당 POWER_SAVING 상태로 재설정되며 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(기본값 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 단원을 참조하십시오.

파티션 상태

AWS ParallelCluster 는 다음 파티션 상태를 지원합니다. A Slurm 파티션은 의 대기열입니다 AWS ParallelCluster.

  • UP: 파티션이 활성 상태임을 나타냅니다. 이것은 파티션의 기본 상태입니다. 이 상태에서는 파티션의 모든 노드가 활성화되어 사용할 수 있습니다.

  • INACTIVE: 파티션이 비활성 상태임을 나타냅니다. 이 상태에서는 비활성 파티션의 노드를 지원하는 모든 인스턴스가 종료됩니다. 비활성 파티션의 노드에 대해서는 새 인스턴스가 시작되지 않습니다.

pcluster 시작 및 중지

pcluster stop 이 실행되면 모든 파티션이 INACTIVE 상태에 배치되고 AWS ParallelCluster 프로세스는 파티션을 INACTIVE 상태로 유지합니다.

pcluster start를 실행하면 모든 파티션이 초기에 UP 상태로 전환됩니다. 그러나 AWS ParallelCluster 프로세스는 파티션을 UP 상태로 유지하지 않습니다. 파티션 상태를 수동으로 변경해야 합니다. 몇 분 후 모든 고정 노드를 사용할 수 있습니다. 참고로 파티션을 UP으로 설정해도 동적 용량은 증가하지 않습니다. initial_count이 max_count보다 크면 initial_count은 파티션 상태가 UP 상태로 변경될 때 만족하지 않을 수 있습니다.

pcluster start 및 pcluster stop가 실행되고 있는 경우 pcluster status 명령을 실행하고 ComputeFleetStatus를 확인하여 클러스터의 상태를 확인할 수 있습니다. 다음과 같은 잠재적인 상태가 있습니다.

  • STOP_REQUESTED: pcluster stop 요청이 클러스터로 전송됩니다.

  • STOPPING: pcluster 프로세스가 현재 클러스터를 중지하는 중입니다.

  • STOPPED: pcluster 프로세스가 중지 프로세스를 완료했고, 모든 파티션이 INACTIVE 상태에 있으며, 모든 컴퓨팅 인스턴스가 종료되었습니다.

  • START_REQUESTED: pcluster start 요청이 클러스터로 전송됩니다.

  • STARTING: pcluster 프로세스가 현재 클러스터를 시작하는 중입니다.

  • RUNNING: pcluster 프로세스가 시작 프로세스를 마쳤고, 모든 파티션이 UP 상태에 있으며, 몇 분 후에 정적 노드를 사용할 수 있습니다.

대기열 수동 제어

경우에 따라 노드 또는 대기열(에서 파티션으로 알려짐 Slurm)를 클러스터에 저장합니다. 다음과 같은 일반적인 절차를 통해 클러스터의 노드를 관리할 수 있습니다.

  • POWER_SAVING 상태의 동적 노드 전원 켜기: scontrol update nodename=nodename state=power_up 명령을 실행하거나 특정 수의 노드를 요청하는 자리 표시자 sleep 1 작업을 제출하고 에 의존합니다.Slurm 필요한 수의 노드를 켭니다.

  • 이전 동적 노드 전원 끄기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 인스턴스를 시작하고 의 프라이빗 IP 주소와 호스트 이름을 할당하며 노드를 재설정하기 전에 ResumeTimeout (기본 기간은 60분(1시간))을 queue1-dy-c5xlarge-[1-2]기다립니다.

  • 인스턴스가 구성되어 클러스터에 들어갑니다. 인스턴스에서 작업이 실행되기 시작합니다.

  • 작업이 완료되었습니다.

  • 구성된 SuspendTime이 경과한 후(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개 이상의 노드)에 유용할 SuspendTimeout 수 있습니다.Slurm 실패하는 작업을 자주 다시 대기열에 추가합니다.

    • SuspendTimeout 는 노드의 백업 인스턴스를 종료하기 위해 AWS ParallelCluster 대기한 시간을 참조하지 않습니다. power down 노드의 백업 인스턴스는 즉시 종료됩니다. 종료 프로세스는 일반적으로 몇 분 이내에 완료됩니다. 하지만 이 기간 동안에는 노드가 전원 차단 상태를 유지하며 스케줄러에서 사용될 수 없습니다.

새 아키텍처에 대한 로그

다음 목록에는 다중 대기열 아키텍처의 키 로그가 포함되어 있습니다. Amazon Logs에 사용되는 CloudWatch 로그 스트림 이름의 형식은 {hostname}.{instance_id}.{logIdentifier}입니다.logIdentifier 는 로그 이름을 따릅니다. 자세한 내용은 Amazon CloudWatch Logs와의 통합 단원을 참조하십시오.

  • 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 로그에서 특정 인스턴스에 대한 해당 부트스트랩 로그를 확인합니다.

  • 고정 노드:

    • clustermgtd 로그를 확인하여 해당 노드의 인스턴스가 시작되었는지 확인합니다. 그렇지 않다면 인스턴스 시작 실패 이유에 대한 명확한 오류가 있을 것입니다.

    • 인스턴스가 시작된 경우 부트스트랩 프로세스에 문제가 있는 것입니다. clustermgtd 로그에서 해당 프라이빗 IP 및 인스턴스 ID를 찾고 CloudWatch 로그에서 특정 인스턴스에 대한 해당 부트스트랩 로그를 확인합니다.

노드가 예기치 않게 교체되거나 종료되었으며, 노드 장애가 발생했습니다.

  • 노드가 예기치 않게 교체/종료됨:

    • 대부분의 경우 clustermgtd가 모든 노드 유지 관리 작업을 처리합니다. clustermgtd가 노드를 교체하거나 종료했는지를 확인하려면 clustermgtd 로그를 확인하세요.

    • clustermgtd가 노드를 교체하거나 종료한 경우 작업 이유를 나타내는 메시지가 표시되어야 합니다. 이유가 스케줄러와 관련된 경우(예: 노드가 DOWN이었음) slurmctld 로그에서 자세한 내용을 확인하세요. 이유가 EC2 관련된 경우 도구를 사용하여 해당 인스턴스의 상태 또는 로그를 확인합니다. 예를 들어 인스턴스에 예약된 이벤트가 있는지 또는 EC2 상태 확인에 실패했는지 확인할 수 있습니다.

    • 가 노드를 종료하지 clustermgtd 않은 경우 노드가 computemgtd 종료되었는지 또는 스팟 인스턴스를 회수하기 위해 인스턴스가 EC2 종료되었는지 확인합니다.

  • 노드 장애

    • 대부분의 경우 노드에 장애가 발생하면 작업이 자동으로 대기열에 추가됩니다. slurmctld 로그에서 작업이나 노드에 장애가 발생한 이유를 확인하고 거기에서 상황을 분석하세요.

인스턴스 교체 또는 종료 시 실패, 노드 전원 차단 시 실패

  • 일반적으로 clustermgtd가 모든 예상 인스턴스 종료 작업을 처리합니다. clustermgtd 로그에서 노드 교체 또는 종료에 실패한 이유를 확인하세요.

  • 동적 노드가 scaledown_idletime에 실패한 경우 SuspendProgram 로그에서 slurmctld 프로그램이 특정 노드를 인수로 사용하여 호출했는지 확인하세요. SuspendProgram는 실제로 특정 작업을 수행하지 않습니다. 그보다는 직접 호출될 때만 로그를 기록합니다. 모든 인스턴스 종료 및 NodeAddr 재설정은 에서 완료합니다clustermgtd.Slurm 는 IDLE 이후에 노드를 에 넣습니다SuspendTimeout.

기타 문제

  • AWS ParallelCluster 는 작업 할당 또는 조정 결정을 내리지 않습니다. 에 따라 리소스를 시작, 종료 및 유지 관리하려고 시도하는 것이 간단합니다.Slurm의 지침.

    작업 할당, 노드 할당 및 규모 조정 결정과 관련된 문제는 slurmctld 로그에서 오류를 확인하세요.