RHEL 9 EC2 환경에서 Slurm Job Scheduler 동작 검증하기
안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 이번에는 RHEL 9 EC2 환경에서 Slurm Job Scheduler 동작을 검증해 봤습니다.
원래는 LSF(Load Sharing Facility) 잡 스케줄러를 검증하려 했지만, LSF는 IBM의 상용 소프트웨어이기 때문에 직접 테스트 환경을 구성하기에는 제약이 있었습니다.
그래서 LSF와 동일한 개념으로 동작하는 오픈소스 잡 스케줄러인 Slurm을 활용해 잡 스케줄링 동작 원리를 확인했습니다.
잡 스케줄러는 CAD 시뮬레이션과 같이 많은 연산 자원을 필요로 하는 작업을 여러 사용자가 동시에 요청하는 환경에서, 서버 자원을 효율적으로 관리하고 배분하는 역할을 합니다.
예를 들어 여러 사용자가 동시에 시뮬레이션 실행을 요청하면, 잡 스케줄러는 현재 서버의 CPU, Memory 등의 자원 상태를 확인한 뒤 실행 순서와 자원 할당량을 결정합니다.
사용자 A: 시뮬레이션 실행 요청
사용자 B: 시뮬레이션 실행 요청 → Slurm / LSF → 서버 자원 상태 확인
사용자 C: 시뮬레이션 실행 요청 → 대기 순서 및 자원 할당 후 실행
LSF vs Slurm
| 항목 | LSF | Slurm |
|---|---|---|
| 비용 | 유료 (IBM) | 무료 (오픈소스) |
| 주요 명령어 | bsub, bjobs | sbatch, srun, squeue |
| 잡 관리 개념 | 동일 | 동일 |
| 주요 사용 분야 | HPC, EDA, 연구 환경 | HPC, 연구 환경, 클러스터 환경 |
LSF와 Slurm은 사용하는 명령어와 세부 기능에는 차이가 있지만, 사용자가 작업(Job)을 제출하고 스케줄러가 자원을 관리한 뒤 실행한다는 기본 동작 방식은 동일합니다.
하고 싶은 것
이번 블로그에서는 다음을 구현할 생각입니다.
- 마스터에서 srun --nodes=1 --ntasks=1 hostname 실행
- slurmctld가 워커 노드 idle 상태 확인
- 워커 노드의 slurmd에게 "hostname 실행해" 지시
- slurmd가 hostname 실행
- 결과(ip-10-0-153-127...)를 마스터로 반환
각 서버의 역할군은 다음과 같습니다.
- slurmctld (마스터)
- 전체 클러스터 관리
- 잡 큐 관리 (누가 먼저, 어디서 실행할지)
- 워커 노드 상태 모니터링
- 직접 작업을 실행하지는 않음
- slurmd (워커)
- 마스터의 지시를 받아서 실제 작업을 실행하는 데몬
- 항상 백그라운드에서 대기하고 있다가 마스터가 잡을 보내면 실행
보안 그룹 설정
먼저 마스터의 보안 그룹 인바운드 규칙을 설정합니다.
마스터 SG 인바운드
| 포트 | 프로토콜 | 소스 | 용도 |
|---|---|---|---|
| 6817 | TCP | 워커 SG | Slurm Controller |
| 6818 | TCP | 워커 SG | Slurm Daemon |
| 6819 | TCP | 워커 SG | Slurm DBD |
| 1024-65535 | TCP | 워커 SG | IO 통신 (Ephemeral Port) |
※ 1024-65535 범위는 Slurm이 IO 통신에 임시 포트(Ephemeral Port)를 사용하기 때문에 필요합니다. 이 규칙이 없으면 잡이 타임아웃됩니다.
이어서 워커의 보안 그룹 인바운드 규칙을 설정합니다.
워커 SG 인바운드
| 포트 | 프로토콜 | 소스 | 용도 |
|---|---|---|---|
| 6817 | TCP | 마스터 SG | Slurm Controller |
| 6818 | TCP | 마스터 SG | Slurm Daemon |
Step 1. 마스터 노드 설정
SSM Session Manager로 마스터 노드에 접속 후 진행합니다.
EPEL 리포지토리 추가 및 Slurm 설치
sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
sudo dnf install -y slurm slurm-slurmctld slurm-slurmd munge
Munge 키 생성 및 시작
Munge는 마스터와 워커 간 통신 인증에 사용하는 도구입니다.
sudo /usr/sbin/create-munge-key
sudo systemctl enable munge
sudo systemctl start munge
sudo systemctl status munge
slurm 유저 생성
Slurm 데몬 실행을 위한 시스템 유저를 생성합니다.
sudo useradd -r -s /sbin/nologin slurm
Slurm 설정 파일 작성
slurm.conf는 어디서 실행할지, 어떤 자원을 쓸지를 정의합니다.
- 마스터가 어디인지
- 워커 노드가 어디인지
- CPU 몇 개 쓸 수 있는지
- 포트는 몇 번인지
sudo tee /etc/slurm/slurm.conf << 'EOF'
ClusterName=test-cluster
SlurmctldHost=ip-10-0-xxx-xxx.ap-northeast-1.compute.internal
SlurmUser=slurm
SlurmctldPort=6817
SlurmdPort=6818
AuthType=auth/munge
StateSaveLocation=/var/spool/slurmctld
SlurmdSpoolDir=/var/spool/slurmd
SchedulerType=sched/backfill
SelectType=select/cons_tres
SlurmctldLogFile=/var/log/slurmctld.log
SlurmdLogFile=/var/log/slurmd.log
NodeName=ip-10-0-yyy-yyy.ap-northeast-1.compute.internal CPUs=2 State=UNKNOWN
PartitionName=debug Nodes=ip-10-0-yyy-yyy.ap-northeast-1.compute.internal Default=YES MaxTime=INFINITE State=UP
EOF
디렉토리 생성 및 slurmctld 시작
sudo mkdir -p /var/spool/slurmctld
sudo chown slurm:slurm /var/spool/slurmctld
sudo touch /var/log/slurmctld.log
sudo chown slurm:slurm /var/log/slurmctld.log
sudo systemctl enable slurmctld
sudo systemctl start slurmctld
sudo systemctl status slurmctld
실행 결과
● slurmctld.service - Slurm controller daemon
Active: active (running)
Main PID: 17575 (slurmctld)
Step 2. Munge 키를 워커 노드에 복사
마스터와 워커가 동일한 Munge 키를 가져야 인증이 됩니다.
마스터에서 키 확인
sudo cat /etc/munge/munge.key | base64
워커에 키 복사
워커 노드에 SSM으로 접속 후 실행합니다.
sudo bash -c 'echo "마스터에서_복사한_base64값" | base64 -d > /etc/munge/munge.key'
sudo chmod 400 /etc/munge/munge.key
sudo chown munge:munge /etc/munge/munge.key
Step 3. 워커 노드 설정
EPEL 리포지토리 추가 및 Slurm 설치
sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
sudo dnf install -y slurm slurm-slurmd munge
slurm 유저 생성
sudo useradd -r -s /sbin/nologin slurm
Munge 시작
sudo systemctl enable munge
sudo systemctl start munge
sudo systemctl status munge
Slurm 설정 파일 작성 (마스터와 동일)
sudo tee /etc/slurm/slurm.conf << 'EOF'
ClusterName=test-cluster
SlurmctldHost=ip-10-0-xxx-xxx.ap-northeast-1.compute.internal
SlurmUser=slurm
SlurmctldPort=6817
SlurmdPort=6818
AuthType=auth/munge
StateSaveLocation=/var/spool/slurmctld
SlurmdSpoolDir=/var/spool/slurmd
SchedulerType=sched/backfill
SelectType=select/cons_tres
SlurmctldLogFile=/var/log/slurmctld.log
SlurmdLogFile=/var/log/slurmd.log
NodeName=ip-10-0-yyy-yyy.ap-northeast-1.compute.internal CPUs=2 State=UNKNOWN
PartitionName=debug Nodes=ip-10-0-yyy-yyy.ap-northeast-1.compute.internal Default=YES MaxTime=INFINITE State=UP
EOF
디렉토리 생성 및 slurmd 시작
sudo mkdir -p /var/spool/slurmd
sudo chown slurm:slurm /var/spool/slurmd
sudo touch /var/log/slurmd.log
sudo chown slurm:slurm /var/log/slurmd.log
sudo systemctl enable slurmd
sudo systemctl start slurmd
sudo systemctl status slurmd
실행 결과
● slurmd.service - Slurm node daemon
Active: active (running)
Main PID: 17584 (slurmd)
slurmd: slurmd version 22.05.9 started
slurmd: CPUs=2 Boards=1 Sockets=2 Cores=1 Threads=1 Memory=1713
Step 4. 동작 확인
마스터 노드에서 동작을 확인합니다.
노드 상태 확인
sinfo
실행 결과
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
debug* up infinite 1 idle ip-10-0-yyy-yyy.ap-northeast-1.compute.internal
워커 노드가 idle 상태로 정상 연결된 것을 확인할 수 있습니다.
잡 실행 테스트
srun --nodes=1 --ntasks=1 hostname
실행 결과
ip-10-0-yyy-yyy.ap-northeast-1.compute.internal
마스터에서 잡을 던졌더니 워커 노드에서 실행하고 결과를 돌려준 것을 확인할 수 있습니다.
마무리
이번 검증에서는 RHEL 9 기반 EC2 환경에서 Slurm 클러스터를 구성하고, 마스터 노드에서 제출한 Job이 워커 노드에서 실행되는 전체 흐름을 확인했습니다.
단순한 hostname 명령어 실행으로 테스트했지만, 실제 HPC나 EDA 환경에서는 해당 위치에 CAD 시뮬레이션 실행 스크립트나 대규모 연산 작업을 넣어 동일한 방식으로 처리할 수 있습니다.
전체 동작 흐름은 다음과 같습니다.
사용자
↓
Job 제출 (srun / sbatch)
↓
slurmctld (마스터)
↓
자원 상태 확인 및 실행 노드 결정
↓
slurmd (워커)
↓
실제 작업 실행
↓
결과 반환
이번 테스트를 통해 LSF와 같은 상용 잡 스케줄러가 제공하는 기본적인 동작 구조를 Slurm 환경에서도 확인할 수 있었습니다.
물론 실제 운영 환경에서는 여러 대의 워커 노드 구성, GPU 자원 관리, 사용자별 Queue 설정, Job Priority 관리 등 추가적인 설정이 필요합니다. 하지만 기본적인 Job 제출 → 자원 할당 → 작업 실행 → 결과 반환이라는 핵심 동작 방식은 이번 검증 환경과 동일합니다.
