좋음. 기존에 설명했던 내용을 Confluence에 바로 붙여 넣을 수 있는 운영/구축 문서 형태로 다시 정리하면 아래 구조가 적합함.
특히 현재 환경인 RHEL 10.2 + Kubernetes 1.33 + Kubespray + B300 8-GPU + Intel E810 + bond0/bond1 + GPU Operator 26.7 + NVIDIA Network Operator 26.4.1 + AIStor 별도 K8s cluster를 기준으로 작성함.

NVIDIA B300 GPU Node 구축 및 RDMA/RoCE 연동 가이드

1. 구축 범위 및 목표

1.1 대상 환경

구분	구성
Kubernetes	1.33
Kubernetes 설치	Kubespray
GPU Node OS	RHEL 10.2
GPU	NVIDIA B300 × 8
GPU Driver 관리	NVIDIA GPU Operator 26.7
Network Operator	NVIDIA Network Operator 26.4.1
NIC	Intel E810
NIC Driver	ice / RDMA irdma
외부망	bond0
Cluster 내부망	bond1
Bonding	Active-Active LACP 3+4
CNI	Cilium
Object Storage	MinIO AIStor
AIStor Cluster	별도 Kubernetes cluster
RDMA	RoCEv2
InfiniBand	미사용

1.2 구축 목표

최종적인 통신 구조는 다음과 같이 구성하는 것을 목표로 함.

                         External
                            │
                         bond0
                            │
                     ┌──────┴──────┐
                     │   GPU Node  │
                     │             │
                     │ B300 × 8    │
                     │             │
                     │ Intel E810  │
                     │             │
                     │   bond1     │
                     └──────┬──────┘
                            │
                   ┌────────┴─────────┐
                   │                  │
             K8s/Cilium traffic   RoCEv2 traffic
                   │                  │
                   │             GPUDirect RDMA
                   │                  │
             일반 K8s 통신         AIStor
                                      │
                                Storage K8s

단, 현재 AIStor가 실제로 Intel E810 기반 RoCEv2 + GPUDirect RDMA 경로를 지원하는지와 AIStor 버전별 지원 범위는 구축 전에 NVIDIA/MinIO 양쪽에 확인하는 것을 필수 조건으로 둠.

---

2. 전체 구축 단계

전체 작업은 다음 8개 대분류로 구분함.

단계	대분류	주요 내용
1	사전 환경 검증	OS, Kernel, GPU, NIC, Network 확인
2	Kubernetes Node 추가	Kubespray를 이용한 GPU Node Join
3	NVIDIA GPU Driver 기반 준비	Driver 방식 및 Kernel Module 결정
4	GPU Operator 설치	Driver, Device Plugin, CDI, DCGM 등 구성
5	RoCE/RDMA 구성	Intel E810 + irdma + RDMA Device Plugin
6	Network Operator/Multus 구성	필요 시 RDMA 전용 NetworkAttachment 구성
7	GPU/RDMA 통합 검증	CUDA, NCCL, RDMA, GPUDirect 검증
8	AIStor E2E 성능 검증	GPU → RoCE → AIStor 성능 및 비교

---

3. Step 1 — 사전 환경 검증

3.1 RHEL 10.2 확인

GPU Node에서 다음 확인함.

cat /etc/redhat-release

uname -r

uname -m

hostnamectl

예상 결과:

Red Hat Enterprise Linux 10.2
x86_64

Kubernetes 기존 worker node와 다음 항목을 비교함.

uname -r
cat /etc/os-release

특히 GPU workload를 실행할 node group은 GPU Driver Container 사용 시 OS/kernel 호환성을 사전에 검증함.

---

3.2 Kernel Module 확인

Intel E810의 기본 NIC module 확인함.

lsmod | grep ice

RDMA module 확인함.

lsmod | grep irdma

또는:

modinfo irdma

확인 대상:

ice
irdma
rdma_cm
ib_core
ib_uverbs

필요 시:

modprobe irdma

후 확인함.

lsmod | grep -E 'ice|irdma|rdma'

중요

여기서 irdma가 존재한다고 해서 RoCE 통신이 이미 완성된 상태라는 의미는 아님.

다음 계층을 모두 확인해야 함.

Application
   ↓
RDMA API
   ↓
RDMA subsystem
   ↓
irdma
   ↓
Intel E810
   ↓
Switch
   ↓
Intel E810
   ↓
irdma
   ↓
RDMA API

---

4. Step 2 — Intel E810 및 bond1 검증

4.1 NIC 확인

lspci | grep -i ethernet

상세 정보:

lspci -nnk | grep -A3 -i ethernet

Intel E810의 driver가 ice인지 확인함.

ethtool -i <interface>

예:

ethtool -i ens5f0

확인 항목:

driver: ice
firmware-version: ...
bus-info: ...

---

4.2 Bond 구성 확인

cat /proc/net/bonding/bond1

확인 대상:

Bonding Mode
LACP
Slave Interface
MII Status
Aggregator ID

예상 구조:

bond1
 ├── E810 port 1
 └── E810 port 2

LACP 상태도 확인함.

ip -d link show bond1

---

5. Step 3 — Kubespray를 이용한 GPU Node 추가

GPU Node를 기존 Kubernetes cluster에 추가함.

핵심은 GPU Node라는 이유로 별도의 Kubernetes cluster를 만들 필요가 없다는 점임.

현재 구조에서는:

Existing Compute K8s Cluster
│
├── CPU Node
├── CPU Node
├── CPU Node
└── GPU Node
      └── B300 × 8

형태로 추가 가능함.

Kubespray inventory에 GPU Node를 worker로 추가함.

예:

[kube_node]
worker01
worker02
gpu01

GPU workload 전용 node로 관리하기 위해 label/taint를 적용하는 것을 권장함.

kubectl label node gpu01 accelerator=nvidia-b300

필요 시:

kubectl taint node gpu01 \
  accelerator=nvidia-b300:NoSchedule

그러면 GPU workload에만 toleration을 요구할 수 있음.

---

6. Step 4 — GPU Operator 26.7 설치

6.1 GPU Operator가 담당하는 범위

GPU Operator 설치 후 주요 component는 다음과 같음.

                    GPU Operator
                         │
          ┌──────────────┼──────────────┐
          │              │              │
       Driver       Device Plugin      CDI
          │              │
          │              └── GPU allocation
          │
          └── NVIDIA kernel driver

          ┌──────────────┼──────────────┐
          │              │              │
         GFD           DCGM        DCGM Exporter
          │              │              │
      GPU labeling    GPU health      Prometheus

주요 역할은 다음과 같음.

Component	역할
NVIDIA Driver	GPU kernel driver 제공
Container Toolkit	Container에서 GPU 사용 가능하도록 runtime 구성
Device Plugin	Kubernetes에 GPU resource 등록
CDI	Container에 GPU device 전달
GFD	GPU 관련 node label 생성
DCGM	GPU 관리/모니터링
DCGM Exporter	Prometheus metric 제공
Validator	설치 상태 검증
MIG Manager	MIG 지원 GPU의 MIG configuration 관리

---

7. Step 5 — Driver 설치 방식 결정

현재 환경에서는 우선 ClusterPolicy 기반 Driver 설치를 권장함.

GPU Operator
      │
      ▼
ClusterPolicy
      │
      ▼
NVIDIA Driver DaemonSet
      │
      ▼
RHEL 10.2 GPU Node

설치 전 kernelModuleType을 결정함.

일반적으로:

driver:
  kernelModuleType: auto

부터 검토함.

B300/RHEL 10.2 조합에서 open kernel module 지원 여부와 GPU Operator 26.7의 지원 matrix를 기준으로 최종 결정함.

---

8. Step 6 — GPU Operator 설치 및 기본 검증

GPU Operator namespace 생성:

kubectl create namespace gpu-operator

Helm repository 등록:

helm repo add nvidia \
  https://helm.ngc.nvidia.com/nvidia

helm repo update

설치:

helm install gpu-operator \
  nvidia/gpu-operator \
  -n gpu-operator \
  --create-namespace

실제 운영 환경에서는 26.7 버전을 명시하여 설치하는 것을 권장함.

helm install gpu-operator \
  nvidia/gpu-operator \
  -n gpu-operator \
  --version <26.7-version>

설치 확인:

kubectl get pods -n gpu-operator

다음 component의 정상 상태를 확인함.

kubectl get pods -n gpu-operator

특히:

nvidia-driver-daemonset
nvidia-device-plugin-daemonset
nvidia-container-toolkit-daemonset
gpu-feature-discovery
dcgm
dcgm-exporter

등을 확인함.

---

9. Step 7 — GPU 기본 검증

9.1 Node GPU resource 확인

kubectl describe node gpu01

다음과 같은 resource가 확인되어야 함.

Capacity:
  nvidia.com/gpu: 8

Allocatable:
  nvidia.com/gpu: 8

---

9.2 NVIDIA Driver 확인

Node에서:

nvidia-smi

확인 대상:

GPU
Driver Version
CUDA Version

B300 8개가 모두 표시되는지 확인함.

nvidia-smi -L

예상:

GPU 0: NVIDIA ...
GPU 1: NVIDIA ...
...
GPU 7: NVIDIA ...

---

10. Step 8 — RDMA 구성

현재 환경에서는 ConnectX가 아니라 Intel E810 + irdma를 사용함.

따라서 구조가:

GPU
 │
 │ PCIe
 ▼
B300
 │
 │ GPUDirect RDMA
 ▼
Intel E810
 │
 │ RoCEv2
 ▼
Ethernet Switch
 │
 ▼
AIStor E810

가 됨.

---

10.1 RDMA subsystem 확인

rdma link

rdma dev

ibv_devices

ibv_devinfo

정상적으로 RDMA device가 표시되는지 확인함.

---

11. RDMA Device Plugin 설치

Kubernetes가 RDMA device를 Pod에 전달할 수 있도록 RDMA Device Plugin을 구성함.

개념적으로:

Intel E810
    │
   irdma
    │
 RDMA device
    │
    ▼
RDMA Device Plugin
    │
    ▼
Kubernetes
    │
    ▼
Pod

Pod에서 RDMA resource를 요청할 수 있도록 구성함.

예:

resources:
  limits:
    rdma/hca: 1

실제 resource name은 설치한 device plugin configuration을 기준으로 확인함.

kubectl describe node gpu01

---

12. Network Operator의 역할

여기서 GPU Operator와 NVIDIA Network Operator는 역할이 다름.

GPU Operator

GPU 관리
Driver
Device Plugin
CDI
DCGM
GFD

Network Operator

RDMA-capable networking
NIC 관련 configuration
RDMA device plugin
Multus
SR-IOV
NetworkAttachmentDefinition

등을 Kubernetes 환경에서 관리하는 역할을 수행함.

---

13. 현재 환경에서 Network Operator가 반드시 필요한가?

반드시 필요한 것은 아님.

현재 요구사항이:

bond0 → external
bond1 → Kubernetes internal

bond1 → RoCEv2

이고,

Intel E810
+ irdma

가 이미 OS에서 정상 동작한다면 단순 RDMA 통신 자체는 Network Operator 없이도 가능함.

즉:

GPU Operator
+
OS의 Intel E810/irdma
+
RDMA Device Plugin

구성으로 먼저 검증할 수 있음.

---

14. Multus가 필요한 경우

반대로 RDMA traffic을 Kubernetes network interface와 명확하게 분리하거나 SR-IOV VF를 사용하려면 Multus를 고려함.

현재 bond가:

bond0
bond1

인 경우 Multus를 추가하면 일반적으로:

eth0

는 기존 Kubernetes primary interface로 유지되고,

추가 network attachment가 Pod에:

net1
net2

형태로 추가됨.

예:

Pod
│
├── eth0 → Cilium
│
└── net1 → RDMA/SR-IOV

단, 실제 host interface 이름과 Pod interface 이름은 Multus configuration에 따라 달라짐.

---

15. RoCEv2 구성

현재 목표는:

RDMA
  ↓
RoCEv2
  ↓
Intel E810
  ↓
Ethernet

임.

InfiniBand가 없으므로:

IB
X

가 아니라:

RoCEv2
O

를 사용함.

---

16. PFC / ECN 구성

RoCEv2는 Ethernet 기반이므로 일반 TCP/IP와 같은 네트워크를 공유할 수 있음.

따라서:

bond1
│
├── 일반 K8s traffic
│
└── RoCEv2 traffic

구성이 가능함.

그리고 switch에서 traffic class를 분리하여:

Priority 3
   ↓
RoCEv2
   ↓
PFC
ECN

형태로 구성할 수 있음.

일반 K8s traffic은 기존 Best Effort class를 유지함.

---

17. 중요한 PFC/ECN 설계 원칙

목표는 다음과 같음.

                    bond1
                      │
             ┌────────┴────────┐
             │                 │
       Normal traffic       RoCEv2
             │                 │
        Best Effort        Priority 3
                               │
                          PFC / ECN

즉 bond1 전체에 PFC를 거는 것이 아니라 RoCE traffic이 사용하는 priority에 대해서만 PFC를 적용하는 것이 핵심임.

스위치에서 DSCP/PCP 기반 traffic classification을 적용함.

---

18. 단, PFC/ECN 없이도 RoCEv2 사용 가능함

다음 단계로 이해하는 것이 정확함.

RoCEv2
  ↓
PFC/ECN 없음
  ↓
동작 가능

하지만 congestion 상황에서 packet loss가 발생하면 RDMA 성능에 상당한 영향을 줄 수 있음.

따라서:

기능 검증

RoCEv2 + PFC/ECN 없음

으로 시작 가능함.

Production

RoCEv2
+
ECN
+
필요 시 PFC

를 권장함.

특히 AI/HPC traffic이 증가하면 congestion control 설계를 별도로 검증하는 것이 필요함.

---

19. GPUDirect RDMA 검증

일반 RDMA와 GPUDirect RDMA를 구분해서 검증함.

일반 RDMA

Application
 ↓
Host Memory
 ↓
E810
 ↓
RoCE
 ↓
E810
 ↓
Host Memory

GPUDirect RDMA

GPU Memory
    │
    │ PCIe
    ▼
Intel E810
    │
    │ RoCEv2
    ▼
Remote E810
    │
    ▼
Remote GPU Memory

따라서 ib_write_bw 같은 테스트에서 GPU memory를 직접 buffer로 사용하는 테스트까지 수행해야 GPUDirect RDMA 검증이 가능함.

---

20. NCCL 검증

GPU가 여러 대로 증가하면 NCCL이 중요해짐.

현재:

B300 × 8

이므로 먼저 동일 node 내부의 GPU communication을 검증함.

GPU0
 ↕
GPU1
 ↕
...
GPU7

이때 NVLink/NVSwitch topology를 확인함.

nvidia-smi topo -m

그리고 NCCL test를 수행함.

GPU
 ↓
NCCL
 ↓
NVLink/NVSwitch

향후 GPU node가 늘어나면:

GPU Node 1
    │
    │ RoCEv2
    │
GPU Node 2

구조가 되며 NCCL의 inter-node communication을 검증함.

---

21. AIStor 연동 검증

최종 목표는 다음과 같음.

vLLM
 │
 │ GPU
 ▼
B300
 │
 │ GPUDirect RDMA
 ▼
Intel E810
 │
 │ RoCEv2
 ▼
Network
 │
 ▼
Intel E810
 │
 ▼
AIStor

하지만 여기서 중요한 점은 vLLM → AIStor의 모든 I/O가 자동으로 GPUDirect RDMA가 되는 것은 아니라는 점임.

Application/library와 storage client가 실제로 GPU buffer를 RDMA 대상으로 사용하는 구조여야 함.

따라서 다음을 각각 검증해야 함.

① E810 ↔ E810
   일반 RDMA

② GPU ↔ E810
   GPUDirect RDMA

③ GPU ↔ GPU
   NCCL/RDMA

④ GPU application ↔ AIStor
   실제 application path

⑤ vLLM ↔ AIStor
   실제 workload

---

22. 최종 권장 설치 순서

현재 환경에서는 아래 순서로 진행하는 것이 가장 안전함.

Phase 1
RHEL 10.2
   ↓
E810 / ice
   ↓
irdma
   ↓
RDMA 기본 테스트

↓

Phase 2
Kubespray
   ↓
GPU Node Join
   ↓
Node Label/Taint

↓

Phase 3
GPU Operator 26.7
   ↓
NVIDIA Driver
   ↓
Container Toolkit
   ↓
Device Plugin
   ↓
CDI
   ↓
DCGM
   ↓
GFD

↓

Phase 4
GPU 기본 검증
   ↓
nvidia-smi
   ↓
CUDA
   ↓
8 GPU 인식

↓

Phase 5
RDMA Device Plugin
   ↓
Kubernetes RDMA resource
   ↓
Pod RDMA access

↓

Phase 6
RoCEv2
   ↓
E810 ↔ E810
   ↓
PFC/ECN optional

↓

Phase 7
GPUDirect RDMA
   ↓
GPU Memory ↔ E810
   ↓
Bandwidth/latency 검증

↓

Phase 8
AIStor
   ↓
GPU ↔ RoCEv2 ↔ AIStor
   ↓
실제 workload
   ↓
성능 비교

---

23. 구축 시 핵심 의사결정

현재 환경에서는 다음과 같이 결정하는 것을 권장함.

항목	권장
GPU Node OS	RHEL 10.2 유지
Kubernetes	기존 1.33 cluster에 worker로 추가
GPU Operator	26.7
Driver 관리	우선 ClusterPolicy
NIC	Intel E810
NIC driver	ice
RDMA driver	irdma
RDMA protocol	RoCEv2
InfiniBand	사용하지 않음
RDMA Device Plugin	설치
Network Operator	필요한 기능이 있을 때 도입
Multus	RDMA network 분리가 필요할 때 도입
PFC	초기 기능검증에서는 optional
ECN	Production에서는 적극 검토
bond1	K8s + RoCE 공용 가능
PFC 적용	bond1 전체가 아니라 RoCE traffic class 기준 적용
GPU ↔ GPU	NCCL 검증
GPU ↔ Network	GPUDirect RDMA 검증
GPU ↔ AIStor	별도 E2E 검증 필요

---

24. 특히 현재 환경에서 가장 중요한 포인트

현재 구성에서는 "GPU Operator 설치 = RDMA/GPUDirect RDMA까지 완료"가 아님.

전체 구조를 정확히 나누면 다음과 같음.

                   GPU Node
┌─────────────────────────────────────────┐
│                                         │
│  B300 × 8                               │
│      │                                  │
│      ├── GPU Operator 26.7              │
│      │      ├── Driver                  │
│      │      ├── Device Plugin            │
│      │      ├── CDI                     │
│      │      ├── DCGM                    │
│      │      └── GFD                     │
│      │                                  │
│      │                                  │
│      └──────── GPUDirect RDMA ─────────┐ │
│                                         │ │
│  Intel E810                             │ │
│      │                                  │ │
│      └── irdma ─────────────────────────┘ │
│                                         │
│  bond0 → External                       │
│  bond1 → K8s + RoCEv2                   │
│                                         │
└────────────────────┬────────────────────┘
                     │
                  RoCEv2
                     │
              Ethernet Switch
                     │
                  RoCEv2
                     │
              AIStor E810
                     │
              ┌──────┴──────┐
              │             │
           AIStor       Storage K8s

따라서 구축 관점에서는 GPU Operator / RDMA / RoCE / GPUDirect RDMA / AIStor를 각각 독립적인 검증 단계로 나누는 것이 핵심임.

특히 AIStor가 별도 Kubernetes cluster에 존재하므로 GPU Node를 AIStor cluster에 넣을 필요는 없으며, 현재처럼 Compute K8s와 Storage K8s를 분리하고 bond1을 통해 RoCEv2로 연결하는 아키텍처를 우선 검증하는 것이 운영 측면에서도 적합함.