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

• 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 컨트롤러가 노드에 연결할 수 없거나 정적 노드가 비활성화되고 지원 인스턴스가 종료되면 노드는 오프라인 상태가 됩니다.

• 인스턴스 유형(예: c5.xlarge)

• 노드 유형(dynamic 또는 static)

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

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

• 컴퓨팅 플릿 중지 - 다음 명령을 실행하면 모든 파티션이 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

• STOP_REQUESTED: 컴퓨팅 플릿 중지 요청이 클러스터로 전송됩니다.

• STOPPING: pcluster 프로세스에서 현재 컴퓨팅 플릿을 중지하고 있습니다.

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

• START_REQUESTED: 컴퓨팅 플릿 시작 요청이 클러스터로 전송됩니다.

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

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

• PROTECTED: 이 상태는 일부 파티션에서 일관된 부트스트랩 오류가 발생했음을 나타냅니다. 영향을 받는 파티션은 비활성 상태입니다. 문제를 조사한 다음 update-compute-fleet 실행하여 플릿을 다시 활성화하세요.

• 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을 호출합니다.

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

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

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

• 구성된 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]).

• 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 상태를 유지하며 스케줄러가 사용할 수 없습니다.

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

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

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