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

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

다중 대기열 모드를 위한 Slurm 가이드

여기서는 큐 (파티션) 노드를 Slurm 관리하는 방법 AWS ParallelCluster 및 큐와 노드 상태를 모니터링하는 방법을 알아볼 수 있습니다.

개요

확장 아키텍처는 Slurm의 클라우드 스케줄링 가이드 및 절전 플러그인을 기반으로 합니다. 절전 플러그인에 대한 자세한 내용은 Slurm 절전 가이드를 참조하세요. 아키텍처에서 클러스터에 사용할 수 있는 리소스는 일반적으로 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 이후 POWER_DOWN 상태가 자동으로 입력됩니다. 반면 정적 노드는 대부분의 경우 전원이 꺼지지 않습니다. 하지만 다음 명령을 사용하여 수동으로 su 루트 사용자로 노드를 POWER_DOWN 상태에 배치할 수 있습니다.

    $ scontrol update nodename=nodename state=down reason="manual draining"

    이 상태에서는 노드와 연결된 인스턴스가 종료되고 노드는 다시 해당 POWER_SAVING 상태로 설정되며 ScaledownIdletime 이후에 사용할 수 있습니다.

    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 이후 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을 참조하세요.

파티션 상태

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 전에 먼저 동적 노드의 전원을 끄세요.

    해당 명령을 사용하여 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을 호출합니다.

  • ResumeProgramAmazon EC2 인스턴스 2개를 시작하고 프라이빗 IP 주소와 호스트 이름을 할당하고 대기합니다 ResumeTimeout (기본 기간은 30분 후 노드 재설정). queue1-dy-spotcompute1-[1-2]

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

  • 작업이 완료되고 실행이 중지됩니다.

  • 구성된 SuspendTime이 경과한 후(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]).

  • ResumeProgramAmazon EC2 인스턴스 1개만 시작하고 인스턴스 1개로 queue1-dy-spotcompute1-1 구성하지만 시작에 실패합니다. queue1-dy-spotcompute1-2

  • 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을 사용하는 것이 유용할 수 있습니다.

    • 단, 노드의 지원 인스턴스가 종료되는 데 걸리는 AWS ParallelCluster 대기 시간을 SuspendTimeout 의미하지는 않습니다. 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를 찾고 Logs에서 특정 인스턴스에 해당하는 부트스트랩 로그를 확인합니다. CloudWatch

  • 고정 노드:

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

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

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

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

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

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

    • clustermgtd가 노드를 종료하지 않은 경우 computemgtd가 노드를 종료했는지 또는 EC2가 스팟 인스턴스를 회수하기 위해 인스턴스를 종료했는지 확인하세요.

  • 노드 장애:

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

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

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

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

기타 문제:

  • AWS ParallelCluster 작업 할당이나 규모 조정 결정을 내리지 않습니다. Slurm의 지침에 따라 리소스를 시작, 종료 및 유지 관리하려고 시도할 뿐입니다.

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