26S05h

GPU Node 온보딩 & 클러스터 연동 계획

0. 현황 정리 및 전제

구분	내용
GPU Node NIC	ConnectX-6 (외부망), Intel E810 (private망 예정, 미구성)
기존 Compute Cluster	bond1(내부망)로 연결
기존 Storage Cluster	bond1(내부망)로 연결
목표	GPU Node를 즉시 join하지 않고, 단계적 검증 후 연동

주의: ConnectX-6는 Mellanox/NVIDIA 계열로 RDMA/GPUDirect(RoCE, GPUDirect Storage, NCCL 가속)에 최적화된 카드인데 현재 외부망에 물려 있고, private망(스토리지/내부 통신 예정 구간)에는 Intel E810이 붙어 있습니다. E810도 RoCEv2를 지원하지만 GPUDirect RDMA/GPUDirect Storage 생태계 성숙도는 ConnectX 계열보다 낮습니다. Phase 3~5에서 스토리지 처리량이나 멀티 GPU 통신 성능이 기대치에 못 미치면 NIC 역할을 바꾸는 것(케이블 재배선)을 재검토 대상으로 열어두는 것을 권장합니다.

Phase 0. 사전 설계 (Private망 구성 전 반드시 결정할 것)

Private망이 없는 상태이므로, "당장 GPU 노드를 어떻게 접근/제어할 것인가"부터 정해야 합니다.

구성 단계

GPU Node 임시 접근 경로 결정: 외부망(ConnectX-6) 통한 SSH/관리 접근으로 우선 운용
Private망 설계 확정: subnet, VLAN ID, MTU(Jumbo frame 사용 여부 — storage/GPU 트래픽이면 9000 권장), bonding 정책(기존 compute/storage가 bond1이므로 GPU node도 동일 bonding mode 맞출지 결정)
스위치 포트 매핑 및 방화벽/ACL 정책 초안 작성 (외부망 노출 최소화 원칙)
DNS/hosts, NTP, 사설 저장소(yum/apt mirror), 시간 동기화 서버를 임시로 외부망 경유로 붙일지 결정
오케스트레이션 방식 확정 (bare-metal / Slurm / Kubernetes 등) — 이후 단계 설치 방식에 영향

체크 포인트 (테스트 아님, 의사결정)

Private망 subnet/VLAN 확정
GPU Node bonding 구성 방식(모드 802.3ad 등) 기존 cluster와 일치 여부
외부망 임시 접근에 대한 보안 정책(방화벽, 접근 IP 제한) 확정

Phase 1. Node 확인 및 기본 테스트

구성 단계
1. 하드웨어 인벤토리 확인 (CPU, RAM, GPU 개수/모델, NIC, NVMe/디스크 구성)
2. BMC/IPMI(iDRAC, iLO 등) 원격 관리 접속 확인, FW 버전 점검
3. BIOS 설정 점검: SR-IOV, VT-d/IOMMU, NUMA 설정, Above 4G Decoding, Power Profile(Performance 모드)
4. OS 설치 (기존 cluster와 동일 배포판/커널 버전 맞추는 것 권장)
5. NIC 펌웨어/드라이버 버전 확인 및 최신화 (ConnectX-6는 MFT/mlxconfig, E810은 ice 드라이버)
6. 커널 파라미터 기본 설정: hugepages, net.core.rmem/wmem, vm.swappiness 등 baseline
7. 시간 동기화(NTP/chrony), 로컬 계정/패스워드 정책, OS 보안 패치 baseline 적용

테스트

CPU/메모리 sanity test (stress-ng, memtester)
NVMe/디스크 기본 I/O 테스트 (fio baseline, SMART 상태 확인)
dmesg / journalctl 에러(특히 PCIe, ECC, NIC link flap) 확인
센서/전력/온도 baseline 기록 (ipmitool sensor, 추후 burn test와 비교군)
ConnectX-6 링크 속도/상태 확인 (ethtool, mlxlink) — 외부망 연결 기준
E810 링크 상태 확인 (private망 미구성이어도 link up/negotiation은 점검 가능)
외부망 통한 기본 네트워크 처리량 측정 (iperf3) — 이후 private망 구성 후 비교 기준점 확보

Phase 2. GPU Driver 설치 및 GPU Burn Test

구성 단계
1. NVIDIA Driver 설치 (기존 compute cluster에 GPU가 있다면 버전 정합성 확인, 없다면 vLLM이 지원하는 CUDA 버전 기준으로 driver 선정)
2. CUDA Toolkit 설치 (필요 시), nvidia-persistenced persistence mode 활성화
3. Multi-GPU 노드라면 NVLink 여부 확인 후 nvidia-fabricmanager 설치/활성화
4. NVIDIA Container Toolkit 설치 (컨테이너로 vLLM 운용 예정이라면 필수)
5. MIG(Multi-Instance GPU) 사용 여부 결정 및 설정 (vLLM 운용 방식에 따라)
6. DCGM(Data Center GPU Manager) 설치 — 모니터링/burn test용

테스트

nvidia-smi 인식 GPU 개수/모델/드라이버 버전 확인
nvidia-smi topo -m 으로 GPU-GPU, GPU-NIC 간 PCIe/NVLink topology 확인
PCIe Link Width/Speed가 스펙대로 잡히는지 확인 (lspci -vv, x16 Gen4/5 여부 — 절반만 잡히는 경우 흔함)
ECC 에러 카운트 확인 (nvidia-smi -q -d ECC)
GPU Burn Test (gpu-burn, 또는 dcgmi diag -r 3) — 최소 30분~수 시간, 클럭/온도/전력 스로틀링 여부 관찰
멀티 GPU면 NCCL 테스트 (nccl-tests의 all_reduce_perf 등)로 GPU간 대역폭 확인
Burn test 중 전력/온도 로그와 Phase1 baseline 비교, 스로틀링/에러 없는지 확인
장시간(soak) 안정성 테스트 (예: 4~12시간 idle 대비 부하 반복)

Phase 3. vLLM 설치 및 Compute Cluster 연동 테스트

구성 단계
1. Python 가상환경/conda 또는 컨테이너 이미지로 vLLM 설치 (CUDA 버전과 vLLM 요구 버전 호환성 확인 필수)
2. 모델 저장 경로 결정 — 이 시점엔 storage cluster 연동이 안 된 상태이므로 우선 로컬 NVMe 캐시로 모델 다운로드/테스트
3. vLLM API 서버 기동 (OpenAI-compatible endpoint) 및 포트/방화벽 오픈 정책 수립
4. Compute cluster → GPU node 호출 경로 확보:

임시로는 외부망(ConnectX-6) 경유 또는 접근 가능한 임시 라우팅으로 연결
인증/TLS 적용 여부 결정 (사내망이라도 임시 우회 경로면 최소한의 인증 권장)

로깅/모니터링 연동 (Prometheus exporter 등, vLLM 자체 metrics endpoint 활용)

테스트

단일 요청 inference 정상 동작 확인 (latency, 토큰 생성 속도 ms/token)
동시 요청(concurrency) 부하 테스트 — throughput, queueing 지연 확인
Compute cluster 노드에서 실제 API 호출 테스트 (기존 서비스 로직과 동일한 방식으로)
네트워크 장애 시나리오: 링크 단절/재접속 시 재시도 로직 동작 확인
장시간 연속 요청 시 GPU 메모리 누수/OOM 여부 확인
Compute cluster ↔ GPU node 간 왕복 지연(RTT) 측정 — 추후 private망 구성 후 재측정 위한 baseline

Phase 4. Storage Cluster ↔ GPU Node 연동 확인 및 테스트

구성 단계
1. Storage cluster 접근 프로토콜 확인 (NFS / Ceph(RBD, CephFS) / Object storage(S3 호환) / 병렬 파일시스템 등 — 프로토콜에 따라 구성이 크게 달라지므로 우선 확인 필요)
2. Private망 구성이 완료되었다면 E810을 통해 storage 네트워크 경로 연결, 미완료 시 임시 경로(외부망) 사용 여부 결정
3. Mount point / 클라이언트 패키지 설치, 인증(Kerberos, cephx 등) 설정
4. 네트워크 튜닝: MTU 일치(Jumbo Frame), RDMA(RoCE) 사용 여부에 따른 설정 (E810의 RoCEv2 지원 활용 시 별도 설정 필요)

테스트

연결성/마운트 정상 확인
처리량 테스트 (fio, dd) — sequential/random read 성능, 특히 대용량 모델 체크포인트 로딩 시나리오 기준
실제 모델 파일(수십 GB급)을 storage에서 GPU node로 로딩하는 시간 측정 → 로컬 NVMe 캐시 대비 비교
대량 동시 접근(다중 GPU 프로세스가 동시에 모델 로딩) 시 성능 저하 여부
네트워크 단절/재연결 시 마운트 복구 동작 확인
(RDMA 사용 시) RDMA 정상 협상 여부 및 미사용 대비 처리량/CPU 사용률 비교

Phase 5. 전체 성능 테스트 (End-to-End)

시나리오 기반 테스트

Storage에서 모델 로드 → vLLM 기동 → Compute cluster에서 실제 요청 발생 → 응답까지 전체 파이프라인 E2E 테스트
실제 서비스 트래픽 패턴을 모사한 부하 테스트 (동시 사용자 수, 요청 분포)
장기 안정성(soak) 테스트 — 최소 24시간 이상 연속 운영, 메모리/온도/에러 로그 모니터링
장애 주입 테스트 (Chaos): 네트워크 단절, storage 일시 접속 불가, GPU 프로세스 강제 종료 시 복구 동작
성능 지표 종합: GPU 활용률, 처리량(req/s, tokens/s), P50/P95/P99 latency, 네트워크 대역폭 활용률, storage I/O 처리량
Phase 1~4에서 기록한 baseline과 비교하여 병목 구간(네트워크? storage? GPU?) 최종 판별

종합 고려사항 및 리스크

NIC 역할 배치 문제: ConnectX-6(고성능/RDMA 특화)가 외부망에, E810이 private망(storage/내부 트래픽 예상)에 배치되어 있어, 향후 GPUDirect Storage나 NCCL 기반 멀티노드 통신이 필요해지면 케이블/역할 재배치가 필요할 수 있습니다. 초기 설계 단계에서 미리 논의해 두는 것이 좋습니다.
임시 우회 경로의 보안 리스크: Private망 구성 전 외부망을 통해 GPU node ↔ compute/storage를 연동할 경우, 인증/방화벽 없이 노출되면 보안 사고 위험이 있습니다. 최소한 IP 화이트리스트 + 인증은 필수로 적용 권장.
Bonding 정책 불일치: 기존 cluster는 bond1로 구성되어 있는데 GPU node의 bonding 모드/정책이 다르면 나중에 private망 편입 시 네트워크 재설계가 필요할 수 있습니다. 가능하면 Phase 0에서 미리 맞추는 것이 좋습니다.
Driver/CUDA/vLLM 버전 정합성: vLLM은 특정 CUDA/PyTorch 버전에 민감하므로, 기존 compute cluster에 GPU 워크로드가 있다면 버전 불일치로 인한 운영 복잡도가 생길 수 있습니다.
GPU Burn Test 시 전력/냉각: GPU node가 랙에 새로 들어온 직후라면 랙 전력 용량과 냉각(공조) 여력을 사전에 확인해야 burn test 중 스로틀링/장애를 오진단하지 않습니다.
Storage 프로토콜 미확정 리스크: Phase 4는 storage cluster의 프로토콜(NFS/Ceph/기타)에 따라 구성이 크게 달라집니다. 이 부분이 정해지지 않았다면 Phase 3~4 사이에 반드시 확정해야 합니다.
RDMA 활용 여부: E810이 RoCEv2를 지원하긴 하지만, 실제로 storage cluster/스위치 인프라가 RDMA/RoCE를 지원하지 않으면 일반 TCP/IP 경로로 fallback되어 기대 성능이 안 나올 수 있습니다. 스위치 단에서 PFC/ECN(Lossless Ethernet) 설정 여부도 확인이 필요합니다.
Rollback 계획: 각 Phase마다 실패 시 이전 단계로 되돌릴 수 있는 기준(예: burn test 실패 시 드라이버/펌웨어 롤백, 네트워크 설정 롤백)을 미리 정의해두면 일정 지연을 최소화할 수 있습니다.
모니터링 공백: GPU node가 아직 기존 모니터링 체계(Zabbix/Prometheus 등)에 편입되지 않았다면, 임시로라도 DCGM exporter + node exporter를 붙여서 Phase 2부터 지표를 남겨두는 것이 이후 성능 이슈 원인 분석에 큰 도움이 됩니다.

===

RHEL 10.2 Bare-Metal NVIDIA GPU Driver 설치 가이드

핵심 변경 사항 (RHEL 8/9와의 차이)

RHEL 10부터 Red Hat이 NVIDIA/AMD AI 가속기 드라이버를 자체 Secure Software Supply Chain으로 빌드/서명하여 Extensions 리포지토리로 제공합니다. 이 방식을 쓰면:

rhel-drivers라는 통합 설치 명령 하나로 GPU 감지 + 드라이버 설치가 자동으로 됨 (nvidia-detect 불필요)
Secure Boot 활성화 상태에서도 MOK(Machine Owner Key) 수동 enroll 없이 바로 동작 (Red Hat 서명 키가 이미 신뢰 체인에 포함)

반면 기존처럼 NVIDIA 공식 CUDA repo(dnf module 방식)로 설치하면, Secure Boot 환경에서는 MOK enroll이 별도로 필요합니다. 두 방법을 아래에 모두 정리하니 환경에 맞게 선택하세요. (데이터센터 GPU + Secure Boot 환경이면 방법 A를 우선 권장합니다.)

참고: 아래 절차는 RHEL 10.1 기준 공개 자료를 기반으로 검증했습니다. RHEL 10.2에서도 동일한 메커니즘(Extensions repo, rhel-drivers)이 유지되지만, 실제 설치 전 subscription-manager repos --list 등으로 10.2용 리포지토리 이름이 정확한지 한 번 확인하시길 권장합니다.

0. 사전 점검 (설치 전 필수 확인)

# OS/커널 버전 확인
cat /etc/redhat-release
uname -r

# Secure Boot 상태 확인
mokutil --sb-state

# GPU 인식 확인 (PCI 레벨)
lspci -nn | grep -i nvidia

# Subscription 등록 상태 확인
subscription-manager status

BIOS에서 SR-IOV, VT-d/IOMMU, Above 4G Decoding 활성화 확인
커널 버전이 최신 patch 상태인지 확인 (dnf update 후 재부팅 권장 — 드라이버 설치 전에 커널을 고정해두는 것이 이후 트러블슈팅에 유리)
기존에 nouveau 관련 설정이 남아있지 않은지 확인 (lsmod | grep nouveau)

방법 A. RHEL 공식 간소화 방식 (권장, Extensions repo + `rhel-drivers`)

A-1. 필요 리포지토리 활성화

sudo subscription-manager repos --enable=rhel-10-for-x86_64-appstream-rpms
sudo subscription-manager repos --enable=rhel-10-for-x86_64-baseos-rpms
sudo subscription-manager repos --enable=codeready-builder-for-rhel-10-x86_64-rpms

Extensions 리포지토리는 기본 비활성 상태이므로 별도 활성화가 필요할 수 있습니다 (버전에 따라 rhel-drivers 패키지 설치 시 자동으로 요구하는 경우도 있음):

sudo subscription-manager repos --list | grep -i extensions
# 목록에 있는 extensions repo 이름을 확인 후 활성화
sudo subscription-manager repos --enable=<확인된-extensions-repo-이름>

A-2. `rhel-drivers` 설치 및 실행

sudo dnf install -y rhel-drivers
sudo rhel-drivers install nvidia

이 명령이 GPU 모델을 자동 감지하여 적합한 커널 모듈 + 유저모드 드라이버를 함께 설치합니다.

A-3. 재부팅 및 검증

sudo reboot

nvidia-smi

정상 설치 시 드라이버 버전, GPU 모델, 온도/전력 정보가 출력됩니다.

Secure Boot 상태에서도 별도 MOK enroll 없이 바로 동작해야 합니다. 만약 nvidia-smi가 "NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver" 를 출력하면 → 아래 트러블슈팅 섹션 참고.

방법 B. 전통적 NVIDIA CUDA Repo 방식 (특정 드라이버 버전 고정이 필요할 때)

vLLM/CUDA 버전 호환성 때문에 특정 드라이버 버전을 고정해야 하는 경우 이 방법이 더 유연합니다.

B-1. 커널 개발 패키지 및 의존성 설치

sudo dnf install -y kernel-devel-$(uname -r) kernel-headers-$(uname -r) \
    gcc make dkms acpid pciutils

B-2. NVIDIA CUDA 리포지토리 등록

sudo dnf config-manager --add-repo \
  https://developer.download.nvidia.com/compute/cuda/repos/rhel10/x86_64/cuda-rhel10.repo

B-3. 드라이버 설치 (버전 고정 예시)

# 사용 가능한 드라이버 스트림 확인
sudo dnf module list nvidia-driver

# 최신 버전 설치
sudo dnf module install -y nvidia-driver:latest-dkms

# 또는 특정 버전 고정 (예: 570 브랜치)
sudo dnf module install -y nvidia-driver:570-dkms

데이터센터 GPU(A100/H100 등)라면 open-dkms(오픈소스 커널 모듈) 사용을 권장합니다 (NVIDIA가 기본 권장 방향으로 전환):

sudo dnf module install -y nvidia-driver:latest-open-dkms

B-4. Secure Boot 환경이라면 MOK Enroll 필요

DKMS 방식은 빌드 시점에 자체 키로 서명하고, 이 키를 부팅 시 MOK로 enroll해야 커널이 모듈 로드를 허용합니다.

# DKMS가 자동 생성한 키 확인
ls /var/lib/dkms/mok.pub

# MOK enroll (재부팅 후 파란 화면에서 암호 입력하여 최종 승인)
sudo mokutil --import /var/lib/dkms/mok.pub
sudo reboot

재부팅 시 "MOK management" 화면이 뜨면 Enroll MOK → Continue → 암호 입력 → 승인 순서로 진행합니다. 이 과정을 건너뛰면 드라이버가 서명 미검증으로 로드되지 않고 nouveau로 폴백됩니다.

B-5. 검증

nvidia-smi
lsmod | grep nvidia   # 결과 있어야 정상
lsmod | grep nouveau  # 결과 없어야 정상

1. CUDA Toolkit 설치 (nvcc, cuBLAS, cuDNN, NCCL 등)

방법 A/B 어느 쪽으로 드라이버를 설치했든 공통:

sudo dnf config-manager --add-repo \
  https://developer.download.nvidia.com/compute/cuda/repos/rhel10/x86_64/cuda-rhel10.repo
sudo dnf install -y cuda-toolkit

PATH 설정:

echo 'export PATH=/usr/local/cuda/bin:$PATH' | sudo tee /etc/profile.d/cuda.sh
echo 'export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH' | sudo tee -a /etc/profile.d/cuda.sh
source /etc/profile.d/cuda.sh

검증:

nvcc --version

nvidia-smi에 표시되는 "CUDA Version"은 드라이버가 지원 가능한 최대 CUDA 버전을 의미할 뿐, CUDA Toolkit이 실제 설치됐다는 뜻이 아닙니다. nvcc --version으로 실제 설치 여부를 별도 확인해야 합니다.

2. 데이터센터/멀티-GPU 서버 추가 설정

GPU node가 멀티 GPU(특히 NVLink 탑재 HGX류) 서버라면 아래 추가 구성이 필요합니다.

2-1. Persistence Mode 활성화 (재부팅/유휴 시 드라이버 언로드 방지, 응답속도 개선)

sudo systemctl enable --now nvidia-persistenced
nvidia-smi -pm 1

2-2. Fabric Manager (8-GPU NVLink/NVSwitch 시스템만 해당)

sudo dnf install -y nvidia-fabric-manager
sudo systemctl enable --now nvidia-fabricmanager
systemctl status nvidia-fabricmanager

2-3. IOMMU 설정 (코어 수 많은 서버 권장)

코어 수가 많은 시스템(대략 256코어 이상)에서는 IOMMU를 끄기보다 pass-through 모드를 권장합니다. /etc/default/grub의 GRUB_CMDLINE_LINUX에 추가:

intel_iommu=on iommu=pt      # Intel CPU
amd_iommu=on iommu=pt        # AMD CPU

적용 후:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo reboot

2-4. DCGM (모니터링/Burn Test용, 이후 Phase 2 GPU burn test에 필요)

sudo dnf install -y datacenter-gpu-manager
sudo systemctl enable --now nvidia-dcgm
dcgmi discovery -l

3. NVIDIA Container Toolkit (향후 vLLM을 컨테이너로 운용할 계획이라면)

Bare-metal 드라이버 설치와는 별개로, vLLM을 컨테이너(Podman)로 띄울 계획이라면 미리 설치해두는 것을 권장합니다.

sudo dnf config-manager --add-repo \
  https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo
sudo dnf install -y nvidia-container-toolkit

# RHEL 기본 컨테이너 런타임인 Podman용 CDI 설정 생성
sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml
nvidia-ctk cdi list

검증 (컨테이너 내부에서 GPU 인식 테스트):

podman run --rm --device nvidia.com/gpu=all \
  nvidia/cuda:12.4.1-base-ubi9 nvidia-smi

트러블슈팅

증상	원인 / 조치
`nvidia-smi` 통신 실패	드라이버 커널 모듈 미로드. `lsmod \\| grep nvidia` 확인, `dmesg \\| grep -i nvidia`로 로드 실패 원인 확인
Secure Boot 상태에서 nouveau로 폴백	방법 B(DKMS) 사용 시 MOK enroll 누락. `mokutil --list-enrolled`로 확인 후 재enroll
커널 업데이트 후 드라이버 깨짐	DKMS 방식은 커널 업데이트마다 재빌드 필요 (`dkms status`로 확인). 방법 A(precompiled, Red Hat 서명)는 이 이슈가 적음
`kernel-devel` 버전 불일치 오류	`kernel-devel-$(uname -r)` 정확히 현재 실행 중인 커널 버전과 일치하는지 확인
PCIe Link Width가 예상보다 낮게 표시	`lspci -vv`로 실제 협상된 Link Width/Speed 확인, 슬롯 장착 상태·BIOS 설정(Gen4/5, bifurcation) 점검
ECC 에러 발생	`nvidia-smi -q -d ECC`로 카운트 확인, 지속 증가 시 하드웨어 이슈 가능성 → burn test(Phase 2)에서 별도 정밀 검증 필요

다음 단계 (Phase 2 연계)

드라이버 설치 후에는 이전 계획의 Phase 2 (GPU Burn Test)로 이어가면 됩니다:

nvidia-smi topo -m으로 GPU-GPU/GPU-NIC PCIe topology 확인
gpu-burn 또는 dcgmi diag -r 3로 burn test
멀티 GPU라면 nccl-tests로 GPU 간 대역폭 확인

===

GPU 노드 온보딩 시나리오를 보니, 핵심 이슈는 "private망이 없는 상태에서 어떻게 안전하게 단계적으로 검증하며 기존 cluster와 연동해 나갈 것인가"로 보입니다. 5단계 계획에 각 단계별 구성/테스트 항목과, 놓치기 쉬운 리스크를 정리한 문서를 만들어 드리겠습니다.가장 눈여겨볼 지점은 ConnectX-6가 외부망에, E810이 private망(스토리지 예정 구간)에 배치되어 있다는 점입니다 — 보통은 반대로(고성능 RDMA 카드를 storage/GPU 통신용 내부망에) 두는 구성이 많아서, Phase 4~5에서 성능 병목이 나오면 이 배치를 재검토 대상으로 열어두시는 게 좋습니다.

문서에는 Phase 0(private망 설계 전 반드시 정해야 할 것들)을 별도로 추가했습니다 — 지금 private망이 없는 상태에서 GPU node에 어떻게 접근/관리할지부터 결정하지 않으면 Phase 1도 시작하기 어렵기 때문입니다.

네, 가능합니다. 다만 "가능하다"와 "그 결과가 최종 프로덕션 성능을 대표한다"는 별개의 문제라서, 전제조건과 한계를 먼저 짚어야 합니다.

결론 먼저

외부망(bond0)을 통해 GPU node(ConnectX-6) ↔ AIStor(storage) 간 RDMA/RoCE 테스트는 개념 검증(PoC) 목적으로는 유효합니다. 하지만 최종적으로는 private망(E810)에 배치될 예정이므로, 이 테스트는 "GDS 스택이 정상 동작하는가"를 검증하는 것이지 "E810 private망에서도 같은 성능이 나온다"는 것을 보장하지 않습니다.

1. 사전 확인해야 할 전제조건

네트워크/하드웨어

AIStor 노드의 bond0(외부망) NIC이 RDMA 지원 하드웨어인지 확인 (모델, 펌웨어, RoCE 활성화 여부) — storage cluster의 주력 RDMA 트래픽은 보통 bond1(내부망) 쪽에 물려있을 가능성이 높아서, 외부망 NIC이 애초에 RDMA를 지원 안 하거나 비활성 상태일 수 있습니다. 이게 안 되면 이 테스트 자체가 불가능합니다.
GPU node ↔ AIStor 사이가 동일 L2 또는 라우팅 가능한 L3인지, 중간에 방화벽/NAT가 있는지 확인 — RDMA(RoCEv2)는 NAT를 통과하지 못하거나 성능이 크게 저하될 수 있습니다.
스위치 단에서 Lossless Ethernet(PFC/ECN, DCBX) 설정이 가능한 구간인지 — 외부망은 보통 이런 QoS 설정이 안 되어 있어서, 설정 없이 진행하면 "lossy RoCE"로 동작하며 패킷 손실 시 성능이 급격히 떨어집니다.
MTU 일치 (Jumbo Frame 9000) 가능 여부
RoCEv2 사용 포트(UDP 4791) 및 관련 포트 방화벽 오픈 여부
네트워크팀/보안팀 협의: 외부망에 RDMA 트래픽을 흘려도 되는지 — "외부망"이 순수 사내 서비스망인지, 실제 인터넷向 구간과 얼마나 가까운지에 따라 리스크가 다릅니다.

GPUDirect RDMA / GPUDirect Storage(GDS) 추가 전제조건

nvidia-fs 커널 모듈 및 GDS 지원 드라이버 스택 설치
/etc/cufile.json 등 cuFile 설정 완료
AIStor(다수의 경우 MinIO 기반 오브젝트 스토리지로 알고 있습니다) 쪽에서 GDS/cuFile 연동 기능이 활성화된 버전인지 확인 — 벤더 문서에서 GDS 지원 여부와 최소 버전을 확인해야 합니다.
가장 중요한 리스크: NVIDIA GDS 공식 호환 NIC은 대부분 ConnectX 계열 중심입니다. 최종 배치될 Intel E810이 GDS 경로에서 ConnectX-6와 동일 수준으로 지원되는지는 별도 검증이 필요합니다. 즉 지금 ConnectX-6로 테스트해서 잘 되더라도, private망 구성 후 E810으로 옮기면 GDS 자체가 아예 안 되거나 성능이 다르게 나올 수 있습니다. (이게 앞서 말씀드린 "NIC 배치가 바뀐 것 같다"는 우려와 직결됩니다.)

2. 단계별 테스트 절차

Step 1 — 순수 RDMA 연결성 테스트 (GPU 배제)

ibv_devinfo, rdma link show로 두 노드에서 RDMA 디바이스 인식 확인
ib_write_bw / ib_send_bw (perftest 패키지)로 GPU node ↔ AIStor 노드 간 순수 NIC-to-NIC RDMA 대역폭/지연 측정
이 단계가 실패하면 GDS는 시도할 필요도 없습니다 — 네트워크/NIC 설정부터 다시 봐야 합니다.

Step 2 — GPUDirect RDMA (peer-to-peer) 단위 테스트

perftest의 --use-cuda 옵션 또는 gdrcopy 툴로 GPU 메모리 ↔ NIC 간 직접 전송 확인
nvidia-smi topo -m으로 GPU와 ConnectX-6 간 PCIe 경로(같은 NUMA 노드/PCIe 스위치 하위인지)도 재확인 — topology가 안 좋으면 GPUDirect 이득이 거의 없습니다.

Step 3 — GPUDirect Storage 테스트

NVIDIA에서 제공하는 gdsio 벤치마크 툴로 실제 AIStor 대상 read/write 테스트
AIStor 측에 cuFile 호환 엔드포인트/설정이 있다면 그 경로로 테스트, 없다면 일반 S3/NFS 경로 대비 비교 불가하니 이 부분은 AIStor 벤더 문서·지원팀 확인이 선행되어야 합니다.

Step 4 — 비교 기준선 확보

같은 구간에서 일반 TCP/IP 경로(CPU copy 경유) 성능도 함께 측정해서, GDS 사용 시 CPU 사용률 감소·지연 감소 효과가 실제로 있는지 비교 데이터를 남겨두세요. 이 데이터는 나중에 E810/private망 결과와 비교할 baseline이 됩니다.

3. 결과 해석 시 주의할 점

이 테스트가 성공해도 이는 "ConnectX-6 + 외부망 경로에서 GDS 스택 자체는 정상 동작한다"는 것을 증명하는 것이지, private망(E810) 프로덕션 성능을 보장하지 않습니다 — private망 구성 후 반드시 재검증 필요.
외부망이라 QoS/Lossless 설정이 없다면 지금 나온 성능 수치는 "최선의 경우"가 아니라 "제약된 조건에서의 수치"일 수 있습니다. 수치가 나쁘다고 해서 인프라 자체에 문제가 있다고 단정하지 말고, 조건을 함께 기록해두세요.
임시 배선/설정이 테스트 후 다시 원복되어야 한다면, 재배선 계획과 일정도 미리 잡아두는 것을 권장합니다.
가장 근본적인 질문은 "최종적으로 GDS 트래픽이 어느 NIC(E810 vs ConnectX-6)를 탈 것인가"입니다. 만약 GDS가 핵심 요구사항이라면, 지금이라도 ConnectX-6를 private/storage망 쪽으로, E810을 외부망 쪽으로 재배치하는 안을 인프라팀과 논의해보시는 걸 권합니다. 이번 테스트 결과가 그 논의에 좋은 근거자료가 될 것입니다.

RHEL 10.2는 비교적 최근 버전이라 최신 설치 절차와 호환성 정보를 확인하고 답변드리겠습니다.RHEL 10 계열은 기존 RHEL 8/9와 드라이버 설치 방식이 꽤 달라졌습니다(Red Hat이 자체 서명한 드라이버를 Extensions 리포지토리로 제공하는 방식이 새로 생김). 두 가지 방법(공식 간소화 방식 vs 전통적인 NVIDIA repo 방식)을 비교해서 문서로 정리해 드리겠습니다.가장 큰 변화는 RHEL 10부터 Red Hat이 자체 서명한 드라이버를 제공한다는 점입니다 — rhel-drivers install nvidia 명령 하나로 Secure Boot 환경에서도 MOK enroll 없이 바로 설치됩니다 (방법 A). 반면 특정 드라이버 버전을 고정해야 하거나(vLLM/CUDA 호환성 이슈 등) 좀 더 세밀한 제어가 필요하면 기존 NVIDIA repo + DKMS 방식(방법 B)을 쓰되, 이땐 Secure Boot 상태에서 MOK enroll을 수동으로 해줘야 합니다.

멀티 GPU(NVLink/HGX) 서버라면 persistence mode, Fabric Manager, IOMMU pass-through 설정도 함께 해두시는 게 이후 Phase 2 burn test·NCCL 테스트에서 안정적인 결과를 얻는 데 도움이 됩니다.

Young-Kyoo Kim

engineer

이전 포스트

26S05d

다음 포스트

26S05h

GPU Node 온보딩 & 클러스터 연동 계획

0. 현황 정리 및 전제

Phase 0. 사전 설계 (Private망 구성 전 반드시 결정할 것)

Phase 1. Node 확인 및 기본 테스트

Phase 2. GPU Driver 설치 및 GPU Burn Test

Phase 3. vLLM 설치 및 Compute Cluster 연동 테스트

Phase 4. Storage Cluster ↔ GPU Node 연동 확인 및 테스트

Phase 5. 전체 성능 테스트 (End-to-End)

종합 고려사항 및 리스크

RHEL 10.2 Bare-Metal NVIDIA GPU Driver 설치 가이드

핵심 변경 사항 (RHEL 8/9와의 차이)

0. 사전 점검 (설치 전 필수 확인)

방법 A. RHEL 공식 간소화 방식 (권장, Extensions repo + `rhel-drivers`)

A-1. 필요 리포지토리 활성화

A-2. `rhel-drivers` 설치 및 실행

A-3. 재부팅 및 검증

방법 B. 전통적 NVIDIA CUDA Repo 방식 (특정 드라이버 버전 고정이 필요할 때)

B-1. 커널 개발 패키지 및 의존성 설치

B-2. NVIDIA CUDA 리포지토리 등록

B-3. 드라이버 설치 (버전 고정 예시)

B-4. Secure Boot 환경이라면 MOK Enroll 필요

B-5. 검증

1. CUDA Toolkit 설치 (nvcc, cuBLAS, cuDNN, NCCL 등)

2. 데이터센터/멀티-GPU 서버 추가 설정

2-1. Persistence Mode 활성화 (재부팅/유휴 시 드라이버 언로드 방지, 응답속도 개선)

2-2. Fabric Manager (8-GPU NVLink/NVSwitch 시스템만 해당)

2-3. IOMMU 설정 (코어 수 많은 서버 권장)

2-4. DCGM (모니터링/Burn Test용, 이후 Phase 2 GPU burn test에 필요)

3. NVIDIA Container Toolkit (향후 vLLM을 컨테이너로 운용할 계획이라면)

트러블슈팅

다음 단계 (Phase 2 연계)

결론 먼저

1. 사전 확인해야 할 전제조건

2. 단계별 테스트 절차

3. 결과 해석 시 주의할 점

26S05d

26S05o

0개의 댓글

26S05h

GPU Node 온보딩 & 클러스터 연동 계획

0. 현황 정리 및 전제

Phase 0. 사전 설계 (Private망 구성 전 반드시 결정할 것)

Phase 1. Node 확인 및 기본 테스트

Phase 2. GPU Driver 설치 및 GPU Burn Test

Phase 3. vLLM 설치 및 Compute Cluster 연동 테스트

Phase 4. Storage Cluster ↔ GPU Node 연동 확인 및 테스트

Phase 5. 전체 성능 테스트 (End-to-End)

종합 고려사항 및 리스크

RHEL 10.2 Bare-Metal NVIDIA GPU Driver 설치 가이드

핵심 변경 사항 (RHEL 8/9와의 차이)

0. 사전 점검 (설치 전 필수 확인)

방법 A. RHEL 공식 간소화 방식 (권장, Extensions repo + rhel-drivers)

A-1. 필요 리포지토리 활성화

A-2. rhel-drivers 설치 및 실행

A-3. 재부팅 및 검증

방법 B. 전통적 NVIDIA CUDA Repo 방식 (특정 드라이버 버전 고정이 필요할 때)

B-1. 커널 개발 패키지 및 의존성 설치

B-2. NVIDIA CUDA 리포지토리 등록

B-3. 드라이버 설치 (버전 고정 예시)

B-4. Secure Boot 환경이라면 MOK Enroll 필요

B-5. 검증

1. CUDA Toolkit 설치 (nvcc, cuBLAS, cuDNN, NCCL 등)

2. 데이터센터/멀티-GPU 서버 추가 설정

2-1. Persistence Mode 활성화 (재부팅/유휴 시 드라이버 언로드 방지, 응답속도 개선)

2-2. Fabric Manager (8-GPU NVLink/NVSwitch 시스템만 해당)

2-3. IOMMU 설정 (코어 수 많은 서버 권장)

2-4. DCGM (모니터링/Burn Test용, 이후 Phase 2 GPU burn test에 필요)

3. NVIDIA Container Toolkit (향후 vLLM을 컨테이너로 운용할 계획이라면)

트러블슈팅

다음 단계 (Phase 2 연계)

결론 먼저

1. 사전 확인해야 할 전제조건

2. 단계별 테스트 절차

3. 결과 해석 시 주의할 점

26S05d

26S05o

0개의 댓글

방법 A. RHEL 공식 간소화 방식 (권장, Extensions repo + `rhel-drivers`)

A-2. `rhel-drivers` 설치 및 실행