26Z29a

QK·2026년 8월 28일

맞습니다. RHEL 10.2라면 오히려 GPU Operator 26.3 기준으로 공식 지원 OS에 들어가므로 Ubuntu로 바꿀 필요가 없습니다. 다만 이전 답변에서 중요한 부분 하나를 수정해야 합니다.

가장 큰 차이는 RHEL 10.2 + Intel E810 + GPUDirect RDMA 조합입니다. GPU Operator 자체의 RHEL 10.2 지원과, NVIDIA가 GPUDirect RDMA까지 공식 검증한 네트워크 구성은 별개의 문제입니다. NVIDIA의 GPU Operator 26.3 문서에서 RHEL 10.0/10.1/10.2 + K8s 1.32–1.36은 GPU Operator 지원 조합이지만, GPUDirect RDMA 지원 표는 RHEL 10.0 + Network Operator 26.1.0으로 별도 표기되어 있고, Network Operator는 기본적으로 NVIDIA 네트워크 장비 중심입니다. (NVIDIA Docs)

따라서 E810에서 GPUDirect RDMA까지 실제로 되는지는 POC에서 반드시 별도로 검증해야 합니다.

1. RHEL 10.2로 바뀌면서 달라지는 부분

① OS는 오히려 그대로 사용해도 됨

현재:

RHEL 10.2
Kubernetes 1.33
B300
Intel E810

이면 GPU Operator 26.3의 공식 지원 범위에 들어갑니다.

NVIDIA 문서:

RHEL 10.0 / 10.1 / 10.2
Kubernetes 1.32–1.36

을 명시하고 있습니다. (NVIDIA Docs)

따라서:

Ubuntu 24.04

로 변경할 이유가 없습니다.

오히려 현재 클러스터가 RHEL 10 기반이라면 GPU node도 RHEL 10.2로 통일하는 것이 운영 측면에서 더 좋습니다.

2. 가장 큰 차이: RHEL에서는 NVIDIA driver 설치 방식을 신중하게 결정

GPU Operator가 driver를 설치하도록 할 수 있습니다.

즉:

RHEL 10.2
   │
   ├── ice
   ├── irdma
   └── NVIDIA GPU Operator
          │
          ├── NVIDIA GPU Driver
          ├── Container Toolkit
          ├── Device Plugin
          └── DCGM

구조입니다.

NVIDIA 공식 설치 문서도 GPU Operator의 기본 설치가 GPU Driver, Container Toolkit, Device Plugin, DCGM Exporter, MIG Manager 등을 GPU worker에 배포한다고 설명합니다. (NVIDIA Docs)

따라서 NVIDIA driver를 RHEL host에 미리 설치할 필요는 없습니다.

3. 그런데 RHEL 10.2에서 kernel이 중요

먼저 확인해야 합니다.

cat /etc/redhat-release
uname -r

예:

Red Hat Enterprise Linux release 10.2
5.14.x

여기서 중요한 것은 RHEL 버전뿐 아니라 실제 kernel version입니다.

NVIDIA GPU Operator의 driver container가 해당 kernel에서 정상적으로 module을 build/load할 수 있어야 합니다.

따라서 GPU node를 Kubespray로 추가할 때 기존 GPU node와 kernel을 동일하게 관리하는 것을 권합니다.

4. E810 부분은 거의 동일

Intel E810은:

ice
  ↓
irdma
  ↓
RoCEv2

입니다.

Intel 공식 문서도 E810의 Linux RDMA stack을:

Base driver = ice
RDMA driver = irdma
Protocol = RoCEv2 / iWARP

로 명시합니다. (Intel)

그리고 현재 Intel의 E810 driver release는 RHEL 10.2를 명시적으로 지원하고 있습니다. 최신 Intel Ethernet release 기준 E810 계열에서 RHEL 10.2가 지원 OS이고, 800-series RDMA driver도 제공됩니다. (Intel)

5. 따라서 ice/irdma는 NVIDIA GPU Operator와 분리

이 부분이 중요합니다.

                  RHEL 10.2
                      │
          ┌───────────┴───────────┐
          │                       │
      Intel stack             NVIDIA stack
          │                       │
        ice                    GPU Operator
          │                       │
       irdma                  NVIDIA Driver
          │                       │
      RoCEv2                  CUDA runtime
          │                       │
          │                  Device Plugin
          │                       │
          │                     B300
          │
        E810

즉:

Intel NIC driver → OS/Ansible/Kubespray 영역

NVIDIA GPU driver → GPU Operator 영역

으로 분리합니다.

6. 그리고 중요한 정정: Network Operator

앞 답변에서는 E810 환경에서 Network Operator를 "현재 불필요"하다고 단정했는데, GPUDirect RDMA까지 목표로 한다면 그렇게 단순하게 보면 안 됩니다.

NVIDIA의 GPUDirect RDMA 공식 지원표에는 RHEL 10 + Network Operator 26.1.0 조합이 들어 있습니다. (NVIDIA Docs)

하지만 Network Operator 26.1의 지원 네트워크 장비는 NVIDIA ConnectX 계열 중심이고, 문서의 B300 지원 플랫폼 역시 ConnectX-8 SuperNIC을 명시합니다. (NVIDIA Docs)

따라서:

E810 + 일반 RDMA/RoCE

Network Operator 불필요

가능.

E810 + GPUDirect RDMA

NVIDIA 공식 지원 여부를 별도로 확인

해야 합니다.

즉 "GPU Operator + Intel E810이면 GPUDirect RDMA까지 NVIDIA 공식 지원"이라고 보면 안 됩니다.

7. 이게 이번 POC에서 가장 중요한 검증 포인트

우리가 목표로 하는 것은 사실 세 단계입니다.

Level 1

GPU
 ↓
NVIDIA driver
 ↓
Kubernetes

Level 2

E810
 ↓
ice
 ↓
irdma
 ↓
RoCEv2
 ↓
AIStor

Level 3

B300 HBM
 ↓
GPUDirect RDMA
 ↓
E810
 ↓
RoCEv2
 ↓
AIStor

Level 1, 2가 된다고 Level 3이 되는 것은 아닙니다.

NVIDIA의 GPUDirect RDMA 문서에서도 GPUDirect RDMA는 GPU와 third-party peer device 간 PCIe direct data exchange이고, DMA-BUF 방식에서는 Open GPU Kernel module + CUDA 11.7+ + Linux kernel 5.12+ 등이 필요하다고 설명합니다. (NVIDIA Docs)

8. 특히 B300이면 더 주의

B300 자체는 GPU Operator 26.3의 지원 GPU 목록에 포함되는 계열이지만, B300 + Intel E810의 GPUDirect RDMA 조합은 NVIDIA의 공식 GPUDirect RDMA 검증 matrix와 별도로 봐야 합니다.

따라서 이번 POC에서는:

"E810으로 일반 RoCE → GPUDirect RDMA까지 가능한가?"

를 기술 검증 항목으로 명확히 두는 게 좋습니다.

9. 그러면 최종 E2E 설치 절차

이제 RHEL 10.2 기준으로 다시 정리하겠습니다.

Phase 0 — 전체 구조

                         K8s 1.33
                            │
                     GPU Worker Node
                       RHEL 10.2
                            │
          ┌─────────────────┴─────────────────┐
          │                                   │
       NVIDIA                              Intel
          │                                   │
    GPU Operator                         ice / irdma
          │                                   │
      B300 GPU                             E810
          │                                   │
          └──────────────┬────────────────────┘
                         │
                       bond1
                     LACP 3+4
                         │
                      RoCEv2
                         │
                       Switch
                         │
                       E810
                         │
                       AIStor

기존:

bond0 = external
bond1 = K8s internal

은 그대로 유지합니다.

Phase 1 — Kubespray로 GPU node 추가

먼저 RHEL 10.2 node 자체를 기존 cluster에 join시킵니다.

Kubespray inventory:

gpu-node-01

을 worker group에 넣습니다.

처음에는 GPU-specific 설정을 최소화합니다.

즉:

RHEL
 ↓
Kubespray
 ↓
K8s worker
 ↓
Cilium

까지만 먼저 성공시킵니다.

확인:

kubectl get nodes -o wide

예:

gpu-node-01   Ready

Phase 2 — bond0 / bond1 확인

GPU node:

cat /proc/net/bonding/bond0
cat /proc/net/bonding/bond1

bond1:

Bonding Mode: IEEE 802.3ad

확인.

그리고:

ip addr show bond1
ip route

확인.

이 단계에서는 RDMA 설정을 아직 하지 않습니다.

Phase 3 — E810 확인

lspci | grep -i ethernet

그리고:

ethtool -i ens5f0np0
ethtool -i ens5f1np1

확인.

원하는 결과:

driver: ice
firmware-version: ...

Phase 4 — irdma 확인

modprobe irdma

확인:

lsmod | grep irdma

그리고:

rdma link

정상적으로 RDMA device가 나타나야 합니다.

Intel의 E810 RDMA 구성은 ice + irdma입니다. (Intel)

Phase 5 — RHEL RDMA userspace

RHEL에서 필요한 패키지를 설치합니다.

dnf install -y \
    rdma-core \
    libibverbs \
    libibverbs-utils \
    perftest \
    iproute \
    ethtool

확인:

ibv_devices
ibv_devinfo

Phase 6 — E810 ↔ E810 RDMA 테스트

Kubernetes를 잠시 잊고 host-to-host RDMA부터 검증합니다.

GPU node:

ib_write_bw

AIStor node:

ib_write_bw <GPU_NODE_RDMA_IP>

또는 반대로 server/client를 구성합니다.

여기서:

RDMA
RoCEv2
E810
switch
AIStor E810

가 정상인지 확인합니다.

Phase 7 — GPU Operator 설치

이제 GPU Operator를 설치합니다.

GPU Operator 26.3의 현재 patch release는 26.3.3입니다. (NVIDIA Docs)

Air-gapped 환경이므로 실제로는 내부 Nexus에 image를 mirror해야 합니다.

설치 예:

helm upgrade --install gpu-operator \
  nvidia/gpu-operator \
  -n gpu-operator \
  --create-namespace \
  --version=v26.3.3 \
  --wait

Phase 8 — Driver 설정

여기서 저는 우선:

kernelModuleType=auto

를 권합니다.

GPU Operator 26.3에서는:

auto
open
proprietary

를 지원하고 auto가 기본/권장 옵션입니다. (NVIDIA Docs)

따라서 처음부터 무조건:

--set driver.kernelModuleType=open

으로 고정하기보다:

--set driver.kernelModuleType=auto

를 사용하고 실제 B300/driver branch 결과를 확인하는 것이 좋습니다.

단, GPUDirect RDMA DMA-BUF를 사용할 계획이라면 최종적으로 Open GPU Kernel module이 필요합니다. NVIDIA도 DMA-BUF 방식에서는 Open GPU Kernel module을 요구합니다. (NVIDIA Docs)

Phase 9 — NVIDIA driver 확인

kubectl get pods -n gpu-operator

그리고:

kubectl describe node gpu-node-01

확인.

GPU:

kubectl describe node gpu-node-01 | grep nvidia

그리고 GPU pod에서:

nvidia-smi

확인.

여기까지:

B300
 ↓
NVIDIA Driver
 ↓
Container Toolkit
 ↓
Device Plugin
 ↓
Kubernetes

완료.

Phase 10 — CUDA 확인

GPU pod에서:

nvidia-smi

CUDA runtime을 사용하는 테스트 image를 실행합니다.

이 단계에서는 아직 RDMA를 넣지 않습니다.

목표:

CUDA
 ↓
B300

정상 확인.

Phase 11 — RDMA Device Plugin

이제 Kubernetes에 RDMA device를 expose합니다.

현재 E810에서는 NVIDIA Network Operator가 아니라 Kubernetes RDMA shared device plugin 계열을 사용하는 방향이 적절합니다.

구조:

RHEL host
  │
ice
  │
irdma
  │
RDMA device
  │
RDMA Device Plugin
  │
Kubernetes Pod

Pod에서:

rdma link
ibv_devices

가 보이는지 확인합니다.

Phase 12 — RDMA Pod test

RDMA resource를 할당받는 pod에서:

ibv_devinfo

확인.

그리고:

ib_write_bw

테스트.

이제:

Host RDMA
   ↓
K8s Pod RDMA

까지 검증됩니다.

Phase 13 — PFC 적용 전 baseline

처음에는:

PFC OFF
ECN OFF

상태로 성능을 측정합니다.

측정:

Bandwidth
Latency
CPU
packet drop
retransmission

Phase 14 — RoCEv2 Priority 분리

현재 목표:

bond1
 │
 ├── Cilium
 │     Priority 0
 │     TC0
 │     PFC OFF
 │
 └── RoCEv2
       Priority 3
       TC3
       PFC ON

E810에서 DSCP 기반으로 구성하는 경우:

RoCEv2
 ↓
DSCP 24
 ↓
Priority 3
 ↓
TC3

그리고 PFC:

P3 = ON
P0 = OFF

으로 합니다.

Phase 15 — Switch 설정

Switch에서도 반드시:

DSCP 24
 ↓
Priority 3
 ↓
PFC ON

으로 맞춥니다.

반면 일반 Kubernetes traffic:

DSCP 0
 ↓
Priority 0
 ↓
PFC OFF

입니다.

즉 기존 Cilium traffic에는 PFC를 적용하지 않습니다.

Phase 16 — ECN

PFC가 정상인 것을 확인한 후:

PFC
+
ECN

을 추가합니다.

최종:

RoCE
 ↓
DSCP 24
 ↓
P3
 ↓
TC3
 ↓
PFC
 +
ECN

Phase 17 — GPUDirect RDMA

이제 가장 중요한 테스트입니다.

먼저 PCIe topology:

nvidia-smi topo -m

그리고:

lspci -tv

확인합니다.

목표:

B300
 │
PCIe
 │
E810

경로가 좋게 배치되어 있어야 합니다.

Phase 18 — DMA-BUF GPUDirect RDMA

NVIDIA 권장 방식은:

B300
 ↓
DMA-BUF
 ↓
E810
 ↓
irdma
 ↓
RoCEv2

입니다.

NVIDIA 문서상 DMA-BUF GPUDirect RDMA에는:

  • Open GPU Kernel module
  • CUDA 11.7+
  • Linux kernel 5.12+
  • network driver

등이 필요합니다. (NVIDIA Docs)

여기서 Intel E810이 핵심 미검증 부분입니다.

NVIDIA 공식 GPUDirect RDMA 검증 matrix가 ConnectX 중심이므로, E810에서는 실제 DMA-BUF peer-memory path를 테스트해야 합니다.

Phase 19 — GPUDirect RDMA test

일반:

ib_write_bw

가 아니라 GPU memory를 RDMA buffer로 사용하는 테스트를 수행합니다.

최근 perftest에는 CUDA GPU memory를 이용한 RDMA 테스트 옵션이 있습니다. (GitHub)

예를 들어 환경에 따라:

ib_write_bw --use_cuda=<GPU_ID>

형태의 테스트를 구성합니다.

여기서 성공해야:

GPU HBM
 ↓
E810
 ↓
RoCE
 ↓
E810
 ↓
Remote memory

를 실제 검증했다고 볼 수 있습니다.

Phase 20 — 마지막에 AIStor

그리고 마지막이:

B300
 │
GPUDirect RDMA
 │
E810
 │
RoCEv2
 │
Switch
 │
E810
 │
AIStor

입니다.

그런데 여기서도 중요한 구분이 있습니다.

GPUDirect RDMA 테스트가 성공했다고 해서:

"AIStor가 자동으로 GPUDirect RDMA를 사용한다"

는 뜻은 아닙니다.

AIStor의 실제 storage protocol/data path가 무엇인지에 따라 달라집니다.

21. vLLM까지 생각하면

최종적으로 원하는 것이 아마:

vLLM
 │
B300
 │
 ├── GPU compute
 │
 └── GPU ↔ storage/network
         │
      GPUDirect RDMA
         │
        E810
         │
       RoCEv2
         │
       AIStor

일 텐데,

vLLM 자체의 GPU↔GPU 통신은 NCCL/NVLink/NVSwitch의 영역이고, AIStor와의 storage/network path는 GPUDirect RDMA/GDS의 영역입니다.

따라서 다음처럼 분리해서 성능을 봐야 합니다.

vLLM
 ├── GPU ↔ GPU
 │     └── NCCL / NVLink
 │
 └── GPU ↔ Storage
       └── GPUDirect RDMA / GDS / application path

22. 최종적으로 설치해야 할 것

현재 RHEL 10.2 + B300 + E810 + K8s 1.33 기준으로 정리하면:

구성위치필수
RHEL 10.2GPU node✅
Kubespray/K8sGPU node✅
CiliumGPU node✅
iceRHEL host✅
irdmaRHEL host✅
rdma-coreRHEL host✅
Intel E810 firmware/NVME810✅
GPU Operator 26.3.xK8s✅
NVIDIA GPU driverGPU Operator✅
NVIDIA Container ToolkitGPU Operator✅
NVIDIA Device PluginGPU Operator✅
DCGM/DCGM ExporterGPU Operator권장
NFDK8s권장
RDMA Device PluginK8s✅
MultusK8s현재 ❌
NVIDIA Network OperatorK8sE810 일반 RDMA에는 불필요
PFCSwitch/E810운영 RoCE 권장
ECNSwitch/E810운영 RoCE 권장
CUDAGPU workload✅
NCCLmulti-GPU/멀티노드 vLLM나중에 ✅
GDRCopyGPU workload선택
GDSstorage direct path 필요 시별도 검토

23. 제가 이번 POC에서 특히 주의할 부분

가장 중요한 순서는 이것입니다.

① RHEL 10.2 / K8s 1.33
        ↓
② Kubespray로 node join
        ↓
③ bond0 / bond1 / Cilium 정상
        ↓
④ E810 firmware
        ↓
⑤ ice
        ↓
⑥ irdma
        ↓
⑦ rdma-core
        ↓
⑧ E810 ↔ AIStor E810 RoCE test
        ↓
⑨ GPU Operator
        ↓
⑩ B300 / nvidia-smi
        ↓
⑪ RDMA Device Plugin
        ↓
⑫ K8s Pod RDMA test
        ↓
⑬ PFC/ECN 없이 baseline
        ↓
⑭ DSCP 24 → P3
        ↓
⑮ P3 PFC
        ↓
⑯ ECN
        ↓
⑰ B300 + E810 GPUDirect RDMA
        ↓
⑱ AIStor 실제 data path
        ↓
⑲ vLLM workload

그리고 핵심적으로 하나만 더 강조하면

RHEL 10.2 자체는 문제가 아닙니다. 오히려 GPU Operator 26.3의 공식 지원 조합입니다. (NVIDIA Docs)

하지만 이번 구성에서 진짜 리스크는:

RHEL 10.2 + B300 + Intel E810 + ice/irdma + DMA-BUF GPUDirect RDMA

입니다.

NVIDIA 공식 GPUDirect RDMA 문서는 일반적인 DMA-BUF 경로를 설명하지만, 지원 matrix는 NVIDIA 네트워크 장비 중심입니다. (NVIDIA Docs) 따라서 이번 POC에서 "E810이 B300의 GPUDirect RDMA peer로 실제 동작하는가"를 별도 Gate로 잡는 것이 맞습니다.

그리고 Intel 쪽에서는 E810이 ice + irdma로 RoCEv2를 지원하고 RHEL 10.2도 현재 driver release에서 지원합니다. (Intel)

즉, 일반 RoCE는 상당히 현실적인 구성이고, GPUDirect RDMA가 이번 POC의 핵심 기술 검증 포인트입니다.

profile
QK
engineer
이전 포스트

26Z28b3

다음 포스트

26Z29b

0개의 댓글