본문 바로가기
컴퓨터 & IT (Computer & IT)/Beowulf Cluster (Diskless Cluster)

[Diskless Cluster] Slurm error - idle* status/ Zero Bytes were transmitted or received

by UltraLowTemp-Physics 2022. 9. 2.
728x90

한동안 한국에 있는 클러스터를 사용하지 않다가, 최근에 서버를 확인해보니 slurm이 정상적으로 작동을 하지 않음을 확인하였다. 우선, 문제 상황은 아래와 같다. 

문제상황 

마스터 서버에서 sinfo 명령어로 계산노드들의 상태들을 확인하였을 때, 계산노드들의 상태들이 아래처럼 idle*/down*/unk* 로 확인이 된다. 

PARTITION AVAIL  TIMELIMIT  NODES  STATE    NODELIST
batch*       up   infinite     11  idle*  node[01-11]
batch*       up   infinite      1  idle      master

위와 같이 idle*  상태가 나온다는 것은 계산노드와 마스터 서버가 정상적으로 통신이 안된다는 것을 의미한다. 

해결방법

1. slurmctldslurmd 재시작 
  - 마스터 서버에서 slumctld를 재시작한 후, 계산 노드에서 slurmd를 재시작한다. 

#master server 
$ /etc/init.d/slurmctld restart

#slave node or computation node
$ /etc/init.d/slurmd restart

위 방법으로 해결이 되지 않는다면, 2번으로 넘어간다. 

2. /var/log/slurmctld.log 확인
마스터 서버에서 해당 로그 파일을 확인을 해서, slurm의 현재 문제점이 무엇인지를 확인한다. 나의 경우, 로그 파일의 에러 메시지가 아래와 같이 발생하였다. 

$vim /var/log/slurmctld.log
...
error: slurm_receive_msg [192.168.0.12:51340]: Zero Bytes were transmitted or received
...

따라서, 현재 문제점은 slurm 서버에서 마스터 서버와 계산 노드들이 정상적으로 데이터를 주고 받지 못하는 것을 확인할 수 있다. 

3. munge 확인
slurm은 munge를 통하여 계산노드와 마스터 서버 사이의 데이터 전송을 암호화한다. 따라서, 만일 slurm 내의 데이터 전송 내에 문제가 발생하였다면, munge에서 문제가 발생할 가능성이 있다. 따라서, 마스터 서버에서 munge를 통해 계산노드로 정상적으로 데이터가 전송이 되는지 확인하기 위해, 마스터 서버에서 아래와 같은 명령어를 입력하자. 

$ munge -n | ssh node01 unmunge
unmunge: Error: Failed to access "/run/munge/munge.socket.2": No such file or directory

위 명령어를 통해서 node01과 마스터 서버가 정상적으로 통신이 되는지 확인하였다. 하지만, 에러메시지가 발생함을 확인하였다. 

이후, 계산노드 node01로 접속 후, munge 상태를 아래 명령어를 입력하여 확인을 하자. 

root@node01:~/ $ systemctl status munge.service
● munge.service - MUNGE authentication service
     Loaded: loaded (/lib/systemd/system/munge.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Fri 2022-09-02 16:52:35 KST; 16s ago
       Docs: man:munged(8)
    Process: 12419 ExecStart=/usr/sbin/munged (code=exited, status=1/FAILURE)

Sep 02 16:52:35 node01 systemd[1]: Starting MUNGE authentication service...
Sep 02 16:52:35 node01 munged[12433]: munged: Error: Logfile is insecure: "/var/log/munge/munged.log" should be owned by UID 126
Sep 02 16:52:35 node01 systemd[1]: munge.service: Control process exited, code=exited, status=1/FAILURE
Sep 02 16:52:35 node01 systemd[1]: munge.service: Failed with result 'exit-code'.
Sep 02 16:52:35 node01 systemd[1]: Failed to start MUNGE authentication service.

 

따라서, 현재 문제점은 munge.log 파일의 소유권에서 발생함을 확인할 수 있다. /var/log/munge/로 이동 후, 문제가 되는 파일의 소유권이 어떻게 되는지를 확인하자. 

root@node01:/var/log/munge# ls -la
total 12
drwx------  2 munge munge  4096 Aug 28 00:00 .
drwxrwxr-x 13 root  syslog 4096 Sep  2 10:55 ..
-rw-------  1 root  adm       0 Aug 28 00:00 munged.log
-rw-------  1 root  adm       0 Aug 28 00:00 munged.log.1
-rw-r-----  1 munge munge   349 Aug  1  2021 munged.log.13.gz

 

munged.log의 파일의 소유권이 adm으로 되어있는 것을 확인할 수 있다. 해당 파일의 소유권은 munge로 변경을 해야한다. 따라서, 아래 명령어를 통해 해당 파일의 소유권을 변경하자. 

root@node01:/var/log/munge# chown munge:munge ./munge/*

 

이후, 계산 노드에서 munge를 재시작한 후, 상태를 확인해보면, 에러 메시지가 사라지고 정상적으로 작동을 함을 확인할 수 있다.

root@node01:/var/log/munge# /etc/init.d/munge start
Starting munge (via systemctl): munge.service.

root@node01:/var/log/munge# systemctl status munge.service
● munge.service - MUNGE authentication service
     Loaded: loaded (/lib/systemd/system/munge.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2022-09-02 17:04:41 KST; 5s ago
       Docs: man:munged(8)
    Process: 13129 ExecStart=/usr/sbin/munged (code=exited, status=0/SUCCESS)
   Main PID: 13132 (munged)
      Tasks: 4 (limit: 154443)
     Memory: 5.8M
     CGroup: /system.slice/munge.service
             └─13132 /usr/sbin/munged

Sep 02 17:04:41 node01 systemd[1]: Starting MUNGE authentication service...
Sep 02 17:04:41 node01 systemd[1]: Started MUNGE authentication service.

 

이후 마스터 서버에서 계산 서버로 munge가 정상적으로 작동하는지를 확인하자. 

root@master:/# munge -n | ssh node01 unmunge
STATUS:           Success (0)
ENCODE_HOST:      localhost (127.0.0.1)
...

 

이후, 다시한번 slurmctld와 slurmd를 재시작한다. sinfo를 통해 계산노드들의 상태들을 확인해보면 정상적으로 상태가 idle로 나옴을 확인할 수 있다.

root@master:~/# sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
batch*       up   infinite     12   idle master,node[01-11]

 

728x90

댓글