Slurm 잡 실행 시 IO 타임아웃 발생 및 해결
안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 이번에는 Slurm 잡 실행 시 IO 타임아웃 발생 및 해결 방법에 대해 정리해 봤습니다.
Slurm을 검증한 내용은 아래 블로그에서 확인할 수 있습니다.
Slurm 잡 실행 시 connect io: Connection timed out 오류 해결
Slurm 클러스터를 구성한 후 간단한 srun 테스트를 진행하던 중, 예상치 못한 I/O 타임아웃 오류를 만났습니다.
처음에는 Slurm 데몬(slurmctld, slurmd)이 정상적으로 실행 중이었고, 필요한 포트도 모두 열려 있는 것으로 보여 원인을 쉽게 찾지 못했습니다. 하지만 문제는 Slurm이 작업 실행 시 사용하는 Ephemeral Port(임시 포트) 에 있었습니다.
이번 글에서는 발생했던 오류와 원인, 그리고 해결 방법을 정리해보겠습니다.
문제 상황
클러스터 구성이 끝난 후 간단하게 hostname을 실행해 보았습니다.
srun --nodes=1 --ntasks=1 hostname
하지만 아무런 출력도 나오지 않은 채 수십 초 동안 멈춰 있다가 다음과 같은 오류가 발생했습니다.
error: connect io: Connection timed out
error: _fork_all_tasks: IO setup failed: Slurmd could not connect IO
처음에는 다음과 같은 문제를 의심했습니다.
slurmd가 실행되지 않은 경우slurmctld와의 통신 문제- DNS 또는 Hostname 설정 문제
- Munge 인증 문제
하지만 이 모든 항목은 정상적으로 동작하고 있었습니다.
원인
원인은 Slurm의 I/O 연결 방식에 있었습니다.
많은 사람들이 Slurm은 6817, 6818 포트만 열면 된다고 생각합니다.
대표적으로 사용하는 포트는 다음과 같습니다.
| 포트 | 용도 |
|---|---|
| 6817 | slurmctld |
| 6818 | slurmd |
| 6819 | slurmdbd(선택) |
실제로 저 역시 보안 그룹(Security Group)에 위 포트들을 모두 허용해 두었습니다.
그래서 처음에는 네트워크 문제가 아니라고 생각했습니다.
Slurm은 작업 실행 시 별도의 I/O 채널을 만든다
srun으로 작업을 실행하면 단순히 slurmctld와 통신만 하는 것이 아닙니다.
실행 과정은 대략 다음과 같습니다.
srun
│
▼
slurmctld (Master)
│
▼
slurmd (Worker)
│
▼
Task 실행
여기까지는 대부분 알고 있는 구조입니다.
하지만 작업이 시작되는 순간 하나의 과정이 더 있습니다.
Worker
│
│ (Ephemeral Port)
▼
Master
워커 노드에서 실행된 프로세스의 표준 입력(stdin), 표준 출력(stdout), 표준 에러(stderr) 를 전달하기 위해 별도의 I/O 연결을 생성합니다.
이 연결은 Slurm 전용 포트(6817, 6818)가 아니라 운영체제가 할당하는 Ephemeral Port(임시 포트) 를 사용합니다.
Linux에서 일반적으로 사용하는 Ephemeral Port 범위는 다음과 같습니다.
1024-65535
환경에 따라 다를 수 있지만 대부분의 배포판에서는 이 범위 또는 이와 유사한 범위를 사용합니다.
Worker
│
├── 6818 → slurmd 통신
│
└── 임시 포트 → IO 통신
처럼 두 종류의 연결이 동시에 이루어집니다.
왜 타임아웃이 발생했을까?
제가 구성한 환경은 AWS EC2 기반의 Slurm 클러스터였습니다.
Master Security Group에는 다음 포트만 열려 있었습니다.
6817
6818
Slurm 데몬끼리의 통신은 정상적으로 이루어졌습니다.
하지만 Worker가 Master로 새로운 I/O 연결을 생성하려고 하자,
Worker
│
│ 54321
▼
Master
보안 그룹이 해당 포트를 차단하면서 연결이 이루어지지 않았습니다.
결국 일정 시간 동안 재시도하다가 다음 오류를 출력했습니다.
error: connect io: Connection timed out
error: _fork_all_tasks: IO setup failed:
Slurmd could not connect IO
즉, Slurm 자체는 정상 동작하고 있었지만 I/O 채널만 생성하지 못했던 것입니다.
이 때문에 잡이 시작되지 않은 것처럼 보였습니다.
해결 방법
해결 방법은 매우 간단했습니다.
Master 노드의 Security Group 인바운드 규칙에 다음 항목을 추가했습니다.
| 포트 범위 | 프로토콜 | 소스 |
|---|---|---|
| 1024-65535 | TCP | Worker Security Group |
중요한 점은 인터넷 전체(0.0.0.0/0) 에 개방하는 것이 아니라 Worker Security Group만 허용하는 것입니다.
이렇게 하면 필요한 노드끼리만 Ephemeral Port 통신이 가능하므로 보안도 유지할 수 있습니다.
적용 후 테스트
보안 그룹을 수정한 직후 다시 동일한 명령을 실행했습니다.
srun --nodes=1 --ntasks=1 hostname
이번에는 즉시 정상적으로 실행되었습니다.
ip-10-0-yyy-yyy.ap-northeast-1.compute.internal
별다른 Slurm 설정 변경 없이 Security Group 수정만으로 문제가 해결되었습니다.
왜 처음에는 원인을 찾기 어려웠을까?
이 문제는 Slurm을 처음 구성할 때 흔히 겪을 수 있는 함정입니다.
대부분의 설치 가이드에서는 다음 포트만 설명합니다.
- 6817 (
slurmctld) - 6818 (
slurmd) - 6819 (
slurmdbd, 선택)
그래서 "필요한 포트는 모두 열려 있다"고 생각하기 쉽습니다.
하지만 srun을 통한 작업 실행에서는 워커 노드가 마스터 노드로 별도의 I/O 연결을 생성하며, 이 연결은 운영체제가 동적으로 할당하는 임시 포트를 사용합니다.
온프레미스 환경에서는 방화벽 정책이 비교적 느슨하거나 내부 네트워크에서 자유롭게 통신할 수 있는 경우가 많아 문제가 드러나지 않을 수 있습니다. 반면 AWS Security Group처럼 기본적으로 허용된 포트만 통신 가능한 환경에서는 이 제약이 그대로 나타나 connect io: Connection timed out 오류로 이어질 수 있습니다.
마무리
error: connect io: Connection timed out와 Slurmd could not connect IO 오류가 발생한다고 해서 반드시 Slurm 설정이나 Munge 인증에 문제가 있는 것은 아닙니다.
클러스터의 기본 통신은 정상이어도 잡 실행 시 생성되는 I/O 채널이 방화벽이나 Security Group에 의해 차단되면 동일한 증상이 발생할 수 있습니다.
AWS 환경에서 Slurm 클러스터를 운영한다면 다음 사항을 함께 확인해 보시기 바랍니다.
6817,6818포트가 정상적으로 열려 있는지- Master와 Worker 간 Security Group 규칙이 올바른지
- Worker에서 Master 방향으로 Ephemeral Port(1024–65535/TCP) 통신이 허용되는지
srun hostname과 같은 간단한 명령으로 먼저 실행 테스트를 수행하는지
이번 사례처럼 Slurm 설정에는 문제가 없었지만 네트워크 정책 때문에 잡이 실행되지 않는 경우가 생각보다 흔합니다. connect io: Connection timed out 오류를 만난다면 Slurm 설정뿐 아니라 보안 그룹과 방화벽 정책까지 함께 점검해 보는 것을 추천합니다.
