Rocky Linux 워크스테이션 2대로 클러스터 환경 구성

네트워크 및 호스트 이름 설정

두 PC가 서로를 이름으로 찾을 수 있어야 MPI·SSH·NFS가 이어집니다. 먼저 호스트명을 고정합니다.

Bash
# 마스터
sudo hostnamectl set-hostname master

# 워크 노드
sudo hostnamectl set-hostname node1

사내망과 별도로, 노드 간 통신용 사설망(192.168.100.0/24)을 설정합니다.

전용망 IP는 게이트웨이 없이 올렸습니다. 기본 라우트가 전용망으로 가면 안 되기 때문입니다.

Bash
# 전용망에 연결된 NIC 이름 확인
ip link show

# master 예: 192.168.100.100/24
sudo nmcli connection modify eth1 ipv4.addresses 192.168.100.100/24
sudo nmcli connection modify eth1 ipv4.method manual
sudo nmcli connection up eth1

# node1 예: 192.168.100.101/24
sudo nmcli connection modify eth1 ipv4.addresses 192.168.100.101/24
sudo nmcli connection modify eth1 ipv4.method manual
sudo nmcli connection up eth1

양쪽 /etc/hosts에는 ​전용망 IP 로 이름을 맞췄습니다. 루프백 줄은 그대로 두고, 아래에 클러스터 호스트만 추가했습니다.

Text
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

192.168.100.100  master
192.168.100.101  node1

확인은 양방향 ping으로 끝냈습니다.

Bash
# master에서
ping -c 2 node1

# node1에서
ping -c 2 master

사용자 계정 설정

MPI와 NFS는 양쪽 노드에 ​같은 사용자 이름·같은 UID 가 있는 편이 안전합니다. UID가 다르면 NFS에서 소유권이 어긋나 쓰기·실행이 깨지기 쉽습니다. 예제로 admin를 UID 1100에 맞춰 양쪽 모두 만들었습니다.

Bash
# master, node1 양쪽에서 동일하게
sudo useradd -u 1100 admin
sudo passwd admin

이후 SSH 키 복사·MPI 실행·공유 디렉터리 소유는 이 계정 기준으로 진행합니다.

비밀번호 없이 SSH 접속

마스터에서 워크 노드로 MPI 프로세스를 띄울 때 비밀번호 프롬프트가 나오면 바로 실패합니다. admin(또는 사용할 계정)로 로그인한 뒤 키를 만들고 복사합니다.

Bash
# master에서 해당 계정으로
ssh-keygen -t rsa   # 프롬프트는 기본값으로 Enter
ssh-copy-id admin@node1

접속 확인:

Bash
ssh node1
# 최초 1회만 yes → 이후에는 비밀번호 없이 셸이 열려야 함
ssh node1 hostname

상대 노드뿐 아니라 ​자기 자신(master, localhost)으로의 SSH 도 무암호여야 합니다. 로컬 코어만 쓰는 mpirun도 SSH로 프로세스를 띄우는 경우가 있습니다.

Bash
ssh-copy-id admin@master
ssh-copy-id admin@localhost

ssh master hostname
ssh localhost hostname

비밀번호를 묻지 않고 호스트명이 바로 나오면 SSH 단계는 통과입니다.

NFS를 이용한 디렉토리 공유

MPP를 이용하여 다중 노드에서 계산이 되려면 각 노드의 같은 경로에 입력 파일이 존재해야 합니다. 마스터를 NFS 서버로 두고 공유할 디렉터리를 export 합니다.

​마스터 (NFS 서버)

Bash
sudo dnf install nfs-utils -y
sudo mkdir -p /shared_directory
sudo chown -R admin:admin /shared_directory

shared_directory 에는 공유할 디렉토리를 입력합니다. 본인의 경우 아래 3개의 디렉토리를 /etc/exports에 워크 노드의 ​전용망 IP 만 허용했습니다.

Text
/opt 192.168.1.20/24(rw,sync,no_root_squash)
/APP 192.168.1.20/24(rw,sync,no_root_squash)
/home 192.168.1.20/24(rw,sync,no_root_squash)

Bash
sudo firewall-cmd --permanent --add-service=nfs
sudo firewall-cmd --reload
sudo systemctl enable --now nfs-server
sudo exportfs -rav

exports의 권한은 ro / rw 두 가지입니다. rx 같은 옵션은 없습니다. 실행 비트는 파일의 chmod가 담당합니다. LS-DYNA는 워크 노드에서도 결과·임시 파일을 쓰므로, 작업용 공유는 **rw**​로 두는 것이 맞았습니다. (솔버만 ro, 런 디렉터리만 rw로 나누는 구성도 가능합니다.)

/opt 전체를 넘기면 하위의 일반 파일·폴더는 같이 보이지만, /opt 아래에 ​별도 디스크를 마운트해 둔 경로 는 상위 export만으로는 비어 보일 수 있습니다. 그 경우 하위 경로를 따로 export하거나 nohide를 검토해야 합니다. 그래서 전용 디렉터리(/shared_directory 등)만 공유하는 쪽을 택했습니다.

​워크 노드 (NFS 클라이언트)

Bash
sudo dnf install nfs-utils -y
sudo mount -t nfs master:/APP /APP
sudo mount -t nfs master:/opt /opt
sudo mount -t nfs master:/home /home

/APP은 임의로 만든 디렉토리로 이 경우 권한 및 소유궈 설정을 해줍니다. 부팅 후에도 공유 디렉토리가 연결되도록 /etc/fstab에 다음을 추가합니다. hosts에 master가 전용망으로 잡혀 있으면 호스트명으로 적어도 됩니다.

Text
master:/APP             /APP                    nfs     defaults        0 0
master:/opt             /opt                    nfs     defaults        0 0
master:/home            /home                   nfs     defaults        0 0

Bash
sudo mount -a
df -h | grep /APP
# master에서 파일을 하나 만들고 node1에서 같은 경로로 보이는지 확인

왜 코어를 늘렸는데 느려지나

MPI를 활용한 복잡한 수치 계산은 매 시간 스텝마다 도메인을 나눠 계산한 뒤, 경계(halo)의 변위·힘·접촉 정보를 MPI로 동기화합니다. 단일 노드에서는 이 통신이 대부분 ​공유 메모리 로 끝나지만, 노드가 나뉘면 매 스텝 메시지가 ​물리 네트워크 를 사용합니다.

일반 기가비트 랜카드(TCP/IP)는 대략 다음 한계를 갖습니다.

CPU는 자기 몫 연산을 끝냈는데도, 상대 노드 메시지가 올 때까지 기다립니다. 코어를 늘리면 분할 경계와 통신량이 같이 늘어나므로, **​느린 인터커넥트에서는 16코어가 8코어보다 느린 “역스케일”**​이 나타날 수 있습니다.

코어 수 ≠ 속도. 인터커넥트가 받쳐 주지 않으면, 추가 코어는 “대기 시간”만 늘립니다.

소형 예제 모델이면 상황이 더 불리합니다. 코어당 요소가 적으면 연산 시간보다 MPI 동기화 비중이 커져, 1GbE뿐 아니라 이론상 빠른 망에서도 speedup이 잘 안 납니다. (실무에서는 코어당 대략 5만–10만 요소 이상을 가이드로 보는 경우가 많습니다.)

네트워크 병목인지 먼저 가려내기

하드웨어를 바꾸기 전에, “느린 게 정말 망인지”를 한 번 나눠 보는 편이 안전합니다.

Bash
# 1) 단일 노드 8코어 (기준)
mpirun -np 8 -hostlist master:8 \
  /APP/LSDYNA/.../ls-dyna_mpp_... i=job.k memory=1000m

# 2) 단일 노드에서 코어만 늘림 (물리 코어가 충분할 때)
mpirun -np 16 -hostlist master:16 \
  /APP/LSDYNA/.../ls-dyna_mpp_... i=job.k memory=1000m

# 3) 2노드 16코어 (네트워크를 탄다)
mpirun -np 16 -hostlist master:8,node1:8 \
  /APP/LSDYNA/.../ls-dyna_mpp_... i=job.k memory=1000m

해석은 단순합니다.

• (2)가 (1)보다 빠른데 (3)만 느리다 → ​노드 간 링크가 병목 입니다.

• (2)도 (1)보다 느리다 → 모델 크기·메모리(스왑)·하이퍼스레딩 등 ​노드 내부 요인 을 먼저 봅니다.

메모리 부족으로 스왑이 돌면 멀티노드가 더 느려 보일 수 있으니, 실행 중 free -m으로 여유를 확인하는 것도 좋습니다.

InfiniBand가 해결하는 지점

InfiniBand의 핵심은 RDMA(Remote Direct Memory Access) 입니다. NIC(HCA)가 OS 커널을 거의 거치지 않고 상대 노드 메모리에 데이터를 넣고 빼므로, MPI의 잦은 소형 메시지(Allreduce, Bcast 등)와 경계 교환에 유리합니다. 대역폭도 크지만, LS-DYNA처럼 스텝마다 동기화가 잦은 솔버에서는 ​지연 시간 이 체감 속도에 더 직접적으로 영향을 줍니다.

이번 환경에서는 아래처럼 IB 장치가 없었습니다.

Bash
ibv_devinfo
# No IB devices found

물리 칩셋까지 확인하면, 카드가 아예 없는지·드라이버만 빠진지 구분할 수 있습니다.

Bash
# 유틸이 없으면
sudo dnf install libibverbs-utils -y

ibv_devinfo
lspci | grep -iE 'infiniband|mellanox|ethernet|network'

1GbE만 있을 때의 현실적인 선택

당장 IB를 넣을 수 없다면, 멀티노드를 고집하기보다 아래 순서가 실무적으로 낫습니다.

1. ​단일 노드에서 물리 코어를 최대한 사용 (master:16 등). 노드 내부 통신이 1GbE보다 훨씬 빠릅니다.

2. ​모델이 충분히 클 때만 2노드를 검토합니다. 통신 대비 연산 비중이 커지면 1GbE에서도 이득이 날 수 있습니다.

3. 중기적으로는 10G/25G Ethernet(가능하면 RoCE) 또는 InfiniBand(EDR/HDR급) 를 전용망에 올립니다. “노드를 늘린 만큼” 시간이 줄어들려면, 인터커넥트가 CPU 속도를 따라가야 합니다.