ノードが抜けたとき読む順序

한 줄 요약

Slurm 장애 진단은 sinfo 로 범위를 좁히고 slurmctld.log 에서 이유를 읽는 것으로 대부분 끝난다.

왜 이게 필요했나

"작업이 안 돕니다" 라는 신고를 받으면 확인할 곳이 여럿이다. 작업이 큐에서 대기 중인가, 노드가 빠졌는가, 인증이 깨졌는가, 설정이 잘못됐는가. 그런데 순서가 있다.

어떻게 동작하나

1단계 — 전체 상태

sinfo
sinfo -R                        # DRAIN/DOWN 이유만
sinfo -N -l                     # 노드별 상세

sinfo -R 이 특히 유용하다. 빠진 노드와 그 이유 문자열만 보여 준다.

노드 상태의 의미.

상태	뜻
idle	정상, 작업 없음
alloc / mix	전체/일부 자원이 할당됨
drain	관리자 또는 시스템이 뺐다. 자동 복귀 안 함
down	응답 없음 또는 등록 실패
inval	설정이 실제와 맞지 않음
fail / failg	하드웨어 문제 보고

2단계 — 이유 읽기

scontrol show node gpu-node01 | grep -i reason
tail -100 /var/log/slurm/slurmctld.log
tail -100 /var/log/slurm/slurmd.log     # 해당 노드에서

로그에 나오는 대표 메시지와 원인.

메시지	원인
Low socket*core*thread count	CPUs 가 소켓×코어×스레드와 불일치
Low RealMemory	설정한 메모리가 노드의 실제보다 큼
gres/gpu count reported lower than configured	slurm.conf 와 gres.conf 개수 불일치
Munge decode failed: Expired credential	시계 불일치
Munge decode failed: Invalid credential	키 불일치
partition X has unknown node Y	정의되지 않은 노드를 파티션이 참조
Node unexpectedly rebooted	노드 재부팅 후 등록

munge 오류의 두 종류를 구분하는 것이 중요하다. Expired credential 은 시계 문제라 NTP 를 보고, Invalid credential 은 키 문제라 /etc/munge/munge.key 를 비교한다. 완전히 다른 대응이다.

3단계 — 작업이 안 도는 경우

노드는 멀쩡한데 작업이 대기만 한다면 squeue 의 REASON 열을 본다.

REASON	대응
Resources	요청한 자원이 아직 안 남았다. 정상 대기
Priority	우선순위가 높은 작업이 앞에 있다
Dependency	선행 작업 대기
PartitionTimeLimit	--time 이 파티션 최대치를 넘었다
PartitionNodeLimit	요청 노드 수가 파티션 한도를 넘었다
ReqNodeNotAvail	지정한 노드가 사용 불가
QOSMax...	QOS 제한에 걸렸다

PartitionTimeLimit 같은 것은 영원히 대기한다. 자원이 생겨도 절대 시작하지 않으므로, 사용자가 요청을 고쳐 다시 제출해야 한다.

4단계 — 복구

원인을 고쳤으면 노드를 명시적으로 복귀시킨다.

scontrol update NodeName=gpu-node01 State=RESUME
scontrol update NodeName=gpu-node[01-03] State=RESUME
scontrol reconfigure                     # 설정 변경 반영

설정 파일을 고쳤다면 모든 노드에 배포한 뒤 scontrol reconfigure 를 해야 한다. 한 노드만 다르면 그 노드가 다시 빠진다.

노드가 빠지는 것을 미리 잡기

슬럼 운영에서 시간을 가장 많이 잡아먹는 것은 작업 실패가 아니라 노드가 조용히 빠지는 것이다. 사용자는 "느려졌다" 고만 느끼고, 원인은 클러스터 절반이 놀고 있는 것이다.

빠진 이유는 언제나 기록된다.

sinfo -R --format="%50E %12U %19H %N"     # 사유, 지운 사람, 시각, 노드
scontrol show node <노드> | grep -E 'State|Reason|CfgTRES|AllocTRES'

노드가 drain 이 되는 흔한 이유 셋.

사유	실제 원인
Low RealMemory	설정의 메모리 값이 실제보다 크다. 커널이 조금 가져간다
gres/gpu count too low	GPU 하나가 사라졌다(nvidia-smi 로 확인)
Kill task failed	작업 프로세스가 안 죽어 노드가 정리되지 않았다

첫 번째가 특히 자주 나온다. slurm.conf 에 물리 메모리 값을 그대로 적으면, 커널과 예약 영역 때문에 실제 가용량이 조금 적어 노드가 곧바로 빠진다. slurmd -C 가 출력하는 값을 쓰고 거기서 조금 더 낮춘다.

slurmd -C          # 이 노드가 보고하는 실제 값

설정을 바꿨으면 전파를 확인한다. slurm.conf 는 모든 노드가 같아야 하고, 바뀐 뒤에는 scontrol reconfigure 가 필요하다. 한 노드만 다르면 그 노드가 계속 빠지는데, 증상은 그 노드의 문제처럼 보인다.

정리 실패는 대개 프로세스가 안 죽어서다. epilog 가 끝나지 않으면 노드가 completing 에 갇힌다. UnkillableStepTimeout 을 넘기면 노드가 drain 된다. 자주 그렇다면 파일 시스템(특히 NFS) 대기로 프로세스가 D 상태에 있는 것이므로, 고칠 곳은 슬럼이 아니라 저장소다.

되살릴 때 사유를 지운다. 상태만 되돌리고 사유를 남기면 다음 헬스체크에서 다시 빠진다.

scontrol update NodeName=<노드> State=RESUME

현장에서 만나는 모습

시계 문제는 주기적으로 재발한다. NTP 가 죽어 있거나 방화벽이 123 포트를 막으면 며칠에 걸쳐 서서히 어긋나다가 어느 날 munge 가 거부하기 시작한다. 클러스터 모니터링에 시계 동기화 상태를 넣어 두는 것이 좋다.

DRAIN 이유 문자열을 지우지 않고 남겨 두는 습관. scontrol update ... State=RESUME 만 하면 이유가 사라진다. 조사 기록을 위해 사유를 어딘가에 남긴 뒤 복귀시키는 팀이 많다.

다음 실습에서 할 것

깨진 설정과 로그가 담긴 픽스처를 받아 원인 네 개를 각각 특정하고, 수정본을 만들고, 복구 절차를 작성하고, RCA 보고서를 남긴다.