Slurm이 내부적으로 자원 할당을 처리하는 방식

HPC 클러스터(HPC clusters)에서 작업한다면, 작업을 제출하고, 큐(queues)를 모니터링하며, 컴퓨팅 자원을 관리하기 위해 매일 Slurm을 사용할 가능성이 높습니다. 대부분의 사용자는 sbatch, squeue, sinfo와 같은 명령어를 알고 있지만, 작업이 제출될 때 내부적으로 실제로 어떤 일이 일어나는지 이해하는 사람은 적습니다. 이 글은 작업 제출부터 컴퓨팅 노드(compute nodes)에서의 실행까지, Slurm이 배후에서 자원 할당을 어떻게 처리하는지 설명합니다.

⸻

작업을 제출하면 어떤 일이 발생할까요?

사용자가 다음을 실행할 때:
sbatch job.sh

Slurm은 내부적으로 다단계 워크플로우(multi step workflow)를 시작합니다. 관련된 주요 구성 요소는 다음과 같습니다:

• slurmctld → 중앙 컨트롤러 데몬 (Central controller daemon)
• slurmd → 컴퓨팅 노드 데몬 (Compute node daemon)
• slurmdbd → 계정 데이터베이스 데몬 (Accounting database daemon) (선택 사항이지만 일반적임)
• 스케줄러 플러그인 (Scheduler plugin)
• 선택 플러그인 (Select plugin)
• Cgroups/task 플러그인

각 구성 요소는 자원 할당에서 특정 역할을 수행합니다.

⸻

1단계: 작업 제출 (Job Submission)

sbatch 명령어는 작업을 slurmctld로 보냅니다. 요청에는 다음 내용이 포함됩니다:

• 노드 수 (Number of nodes)
• CPU
• 메모리 (Memory)
• GPU
• 시간 제한 (Time limit)
• 파티션 (Partition)
• 제약 조건 (Constraints)
• QoS
• 계정 정보 (Account information)

예시:
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=32
#SBATCH --mem=128G
#SBATCH --time=04:00:00

이 단계에서 Slurm은 작업 레코드(job record)를 생성하고 이를 대기 큐(pending queue)에 배치합니다.

⸻

2단계: 작업 검증 (Job Validation)

작업을 스케줄링하기 전에 Slurm은 내부적으로 여러 가지를 검증합니다.

사용자 및 계정 확인 (User & Account Checks)
Slurm은 다음을 확인합니다:

• 사용자 권한 (User permissions)
• 계정 연관성 (Account associations)
• QoS 제한 (QoS limits)
• Fairshare 정책 (Fairshare policies)
• 파티션 접근 (Partition access)

계정 관리(accounting)가 활성화되어 있다면, slurmdbd가 사용 통계 및 제한 사항을 제공합니다.

⸻

3단계: 스케줄러 평가 (Scheduler Evaluation)

이제 스케줄러가 작업을 평가하기 시작합니다. Slurm의 기본 스케줄러는 다음과 같습니다:

sched/backfill

이 스케줄러는 두 가지 중요한 작업을 수행합니다:

주요 스케줄링 패스 (Main Scheduling Pass)
다음 사항을 확인합니다:

• 가용 자원 (Available resources)
• 작업 우선순위 (Job priority)
• 노드 상태 (Node states)
• 예약 (Reservations)
• 제한 (Limits)

백필 스케줄링 (Backfill Scheduling)
백필(Backfill)은 더 높은 우선순위의 작업을 지연시키지 않으면서 더 작은 작업들이 실행될 수 있도록 합니다. 이는 전반적인 클러스터 활용도(cluster utilization)를 향상시킵니다.

⸻

작업 우선순위는 어떻게 계산되는가

Slurm은 동적 우선순위 점수(dynamic priority score)를 계산합니다.

요소는 다음과 같습니다:

Fairshare 사용량, 작업 연령 (Job age), 작업 크기 (Job size), 파티션 우선순위 (Partition priority), QoS 우선순위 (QoS priority), 연관 우선순위 (Association priority). 내부적으로 우선순위 플러그인 (priority plugin)은 이러한 값들을 하나의 점수로 결합합니다. 예시: 우선순위 (Priority) = 연령 (Age) + Fairshare + 작업 크기 (JobSize) + 파티션 (Partition) + QoS. 점수가 높을수록 더 일찍 스케줄링됩니다.

⸻

4단계: 자원 선택 (Resource Selection)

스케줄러가 작업을 실행하기로 결정하면, Slurm은 선택 플러그인 (select plugin)을 사용합니다. 대부분의 클러스터는 다음을 사용합니다:

select/cons_tres

이 플러그인은 TRES를 사용하여 소비 가능한 자원 (consumable resources)을 처리합니다.

⸻

TRES란 무엇인가?

TRES는 다음의 약자입니다:

Trackable RESources (추적 가능한 자원)

예시:

• CPU
• Memory
• GPU
• Node
• License
• Burst buffer

이 모델을 통해 Slurm은 자원을 매우 정밀하게 추적할 수 있습니다.

⸻

내부 노드 선택 (Internal Node Selection)

이제 선택 플러그인이 다음 사항을 결정합니다:

• 어떤 노드가 적격한지
• CPU가 어떻게 분배되는지
• 메모리 할당 (Memory allocation)
• GPU 배치 (GPU placement)
• 소켓/코어 바인딩 (Socket/core binding)

Slurm은 slurmctld에 의해 메모리에 저장된 노드 토폴로지 (node topology) 정보를 확인합니다.

예시: NodeA

• 64 CPUs
• 512 GB RAM
• 4 GPUs

만약 작업이 다음을 요청한다면:

• 32 CPUs + 2 GPUs

Slurm은 내부적으로 정확히 해당 자원들을 예약합니다.

⸻

5단계: 자원 예약 (Resource Reservation)

노드 선택 후, Slurm은 자원을 할당된 상태로 표시합니다.
내부적으로:

• CPU는 다른 작업에서 사용할 수 없게 됩니다.
• 메모리 카운터가 감소합니다.
• GPU가 예약됩니다.
• 노드 상태가 변경됩니다.

다음 명령어를 통해 이를 관찰할 수 있습니다:
scontrol show node 또는 squeue

⸻

6단계: 작업 실행 (Launching the Job)

이제 slurmctld가 할당된 노드에 있는 slurmd 데몬 (daemon)에 연락합니다. 컴퓨팅 노드 데몬은 다음을 수행합니다:

• 환경 설정 (Environment setup)
• UID/GID 검증
• Cgroup 생성
• CPU 바인딩 (CPU binding)
• 메모리 강제 적용 (Memory enforcement)
• 태스크 실행 (Task launching)

⸻

Cgroups가 제한을 강제하는 방식

현대적인 Slurm 클러스터는 Linux cgroups에 크게 의존합니다. Cgroups는 작업이 할당된 자원을 초과할 수 없도록 보장합니다.

예시:

• CPU 강제 적용 (CPU Enforcement): 할당된 CPU 코어만 접근 가능합니다.
• 메모리 강제 적용 (Memory Enforcement): 제한을 초과하는 메모리 사용은 OOM kill을 유발합니다.
• GPU 격리 (GPU Isolation): 할당된 GPU만 보입니다.

이것이 사용자가 작업 내부에서 CUDA_VISIBLE_DEVICES=0이 자동으로 설정되는 것을 보는 이유입니다.

⸻

CPU 바인딩 및 어피니티 (CPU Binding and Affinity)

Slurm은 내부적으로 CPU 어피니티 (CPU affinity)도 처리합니다.

이는 다음을 개선합니다: NUMA 지역성 (NUMA locality), 캐시 효율성 (Cache efficiency), MPI 성능 (MPI performance)

예시: srun --cpu-bind=cores

내부적으로 Slurm은 토폴로지 인식 스케줄링 (topology-aware scheduling)을 사용하여 태스크를 특정 CPU 코어에 매핑합니다.

⸻

단계 7: 작업 실행 (Job Execution)

모든 설정이 완료되면:

• 프로세스가 시작됩니다.
• 계정 관리 (Accounting)가 시작됩니다.
• 사용량 지표 (Usage metrics)가 수집됩니다.

Slurm은 다음을 추적합니다:

• CPU 시간 (CPU time)
• 메모리 사용량 (Memory usage)
• GPU 사용량 (GPU usage)
• 에너지 소비량 (Energy consumption)
• 종료 코드 (Exit codes)

이러한 통계는 나중에 다음을 통해 확인할 수 있습니다:

• sacct

⸻

작업이 종료되면 어떤 일이 발생하나요?

완료 후:

• 자원이 해제됩니다.
• 노드 상태가 업데이트됩니다.
• 계정 데이터가 저장됩니다.
• 스케줄러가 대기 중인 작업 (pending jobs)을 재평가합니다.

해제된 자원은 즉시 새로운 할당을 위해 사용 가능한 상태가 됩니다.

⸻

이것을 이해하는 것이 중요한 이유

Slurm이 자원을 할당하는 방식을 아는 것은 관리자와 사용자에게 다음과 같은 도움을 줍니다:

• 대기 중인 작업 (pending jobs)의 문제 해결
• 스케줄링 최적화
• 클러스터 활용도 향상
• CPU 또는 메모리 경합 (contention) 진단
• 페어쉐어 (fairshare) 정책 조정
• 성능 병목 현상 (performance bottlenecks) 파악

또한 다음과 같은 이슈를 다룰 때 디버깅을 훨씬 쉽게 만들어 줍니다:

• ReqNodeNotAvail (요청한 노드를 사용할 수 없음)
• 자원 (Resources)
• 우선순위 (Priority)
• QOSMaxCpuPerUserLimit (사용자당 최대 CPU QOS 제한)

⸻

맺음말

Slurm은 단순히 작업을 큐에 넣는 것 이상의 역할을 수행합니다. 내부적으로 Slurm은 다음을 수행합니다:

• 정책 검증 (Policy validation)
• 우선순위 계산 (Priority calculations)
• 토폴로지 인식 스케줄링 (Topology aware scheduling)
• 정밀한 자원 계정 관리 (Precise resource accounting)
• Cgroup 강제 적용 (Cgroup enforcement)
• 분산 태스크 실행 (Distributed task launching)

이러한 내부 동작을 이해하면 HPC 관리자는 클러스터 성능을 더 잘 제어할 수 있고, 사용자는 더 효율적인 작업을 작성할 수 있습니다. 다음에 sbatch를 실행할 때, 여러분의 워크로드가 정확히 어디서 어떻게 실행될지를 결정하기 위해 전체 스케줄링 엔진이 배후에서 작동하고 있다는 사실을 기억하십시오.