26Z31c
좋음. 이 부분은 단순히 nvidia-smi가 정상인지 확인하는 수준으로 보면 안 되고, ① GPU 자체 → ② GPU↔NIC P2P → ③ RDMA → ④ RoCE fabric → ⑤ AIStor RDMA → ⑥ 실제 S3-over-RDMA → ⑦ 실제 vLLM workload 순서로 계층을 분리해서 검증하는 것이 좋음.
특히 최신 AIStor 문서도 RDMA는 하위 계층부터 순서대로 검증해야 하며, 문제가 있어도 TCP로 조용히 fallback할 수 있기 때문에 "서비스가 정상이다 = RDMA가 정상이다"가 아님을 명시하고 있음. (MinIO AIStor Documentation)
아래는 현재 환경인 RHEL 10.2 + K8s 1.33 + B300 × 8 + Intel E810 + RoCEv2 + 별도 AIStor K8s를 기준으로 한 실제 테스트 계획임.
1. GPU/RDMA 통합 검증
1.1 전체 검증 구조
GPU Node에서 다음 순서로 올라가는 구조임.
┌───────────────────────────────────────────────┐
│ GPU Node │
│ │
│ B300 × 8 │
│ │ │
│ │ CUDA │
│ ▼ │
│ NVIDIA Driver │
│ │ │
│ ├──────────────┐ │
│ │ │ │
│ ▼ ▼ │
│ NCCL GPUDirect RDMA │
│ │ │
│ ▼ │
│ Intel E810 │
│ │ │
│ irdma │
│ │ │
└─────────────────────┼─────────────────────────┘
│
RoCEv2
│
Switch
│
RoCEv2
│
AIStor E810검증 단계는 다음과 같이 구성하는 것을 권장함.
| 단계 | 테스트 | 검증 대상 |
|---|---|---|
| G1 | GPU 인식 | B300 × 8 |
| G2 | CUDA | GPU compute |
| G3 | GPU topology | PCIe/NVLink/NVSwitch |
| R1 | RDMA device | E810 + irdma |
| R2 | Host-memory RDMA | E810 ↔ E810 |
| R3 | GPU-memory RDMA | GPU ↔ E810 |
| R4 | RoCE congestion | PFC/ECN |
| R5 | Kubernetes RDMA | Pod → RDMA |
| R6 | NCCL | GPU collective |
| R7 | GPUDirect RDMA | GPU memory ↔ remote NIC |
2. G1 — B300 × 8 기본 검증
가장 먼저 Kubernetes와 관계없이 OS에서 GPU가 정상인지 확인함.
nvidia-sminvidia-smi -L8개가 모두 표시되어야 함.
GPU 0
GPU 1
GPU 2
...
GPU 7그리고:
nvidia-smi topo -m결과를 저장함.
nvidia-smi topo -m > gpu-topology.txt이 결과는 이후 NCCL 성능의 기준값이 됨.
3. G2 — CUDA 기본 검증
GPU Operator가 설치되었다고 CUDA application까지 정상이라고 판단하면 안 됨.
CUDA sample 또는 CUDA container를 이용해 실제 GPU kernel execution을 검증함.
예:
kubectl run cuda-test \
--rm -it \
--restart=Never \
--image=nvidia/cuda:<validated-version>-runtime \
-- nvidia-smi실제 운영 환경에서는 air-gapped registry에 동일 image를 mirror해서 사용하는 것이 적절함.
PASS 기준
8 GPU 모두 정상 인식
CUDA application 정상 실행
GPU Xid error 없음확인:
nvidia-smi -q | grep -i "error"4. R1 — E810 RDMA 기본 검증
GPU 테스트와 별도로 RDMA를 검증함.
rdma link showibv_devicesibv_devinfo정상적인 RDMA port가:
PORT_ACTIVE이어야 함.
AIStor 공식 validation도 ibv_devinfo에서 active RDMA port를 확인하는 것을 첫 단계로 제시함. (MinIO AIStor Documentation)
Intel E810에서는 다음도 함께 확인함.
lsmod | grep -E 'ice|irdma'ethtool -i <E810-interface>예상:
driver: ice5. R2 — Host Memory RDMA
이 테스트가 가장 먼저 해야 할 RDMA 성능 테스트임.
GPU를 완전히 배제하고:
Host RAM
│
▼
E810
│
RoCEv2
│
▼
E810
│
▼
Host RAM만 테스트함.
이 테스트의 목적은:
GPU Operator와 관계없이 E810 + irdma + Switch + RoCEv2가 정상인지 확인
하는 것임.
5.1 ib_write_bw
서버:
ib_write_bw -d <rdma_device> -a클라이언트:
ib_write_bw \
-d <rdma_device> \
-a \
<server-ip>NVIDIA의 RDMA troubleshooting에서도 ib_write_bw를 point-to-point bandwidth baseline으로 사용하도록 안내함. (NVIDIA Docs)
테스트 message size
최소:
4 KB
64 KB
1 MB
4 MB
16 MB
64 MB
256 MB
1 GB정도로 sweep하는 것을 권장함.
concurrency/QP
초기:
QP = 1부터 시작하고:
1
2
4
8
16
32로 증가시키는 방식이 좋음.
6. R2의 중요한 PASS 기준
단순히 "100Gbps가 나왔다"처럼 평가하면 안 됨.
다음 네 가지를 동시에 봐야 함.
① Bandwidth
Gbps② Latency
ib_write_lat③ Retransmission / error
rdma statistic④ Switch PFC/ECN counter
즉:
Bandwidth OK
Latency OK
RDMA errors 0
PFC pause 정상 범위
ECN congestion 상황에서만 증가를 봐야 함.
NVIDIA 문서에서도 rdma statistic의 rnr_nak_retry_err, packet_seq_err, local_ack_timeout_err 등의 증가를 packet loss/retry의 중요한 지표로 제시함. (NVIDIA Docs)
7. R3 — GPU Memory RDMA
여기부터가 GPUDirect RDMA 검증임.
Host memory 테스트:
RAM → E810 → E810 → RAM에서 다음으로 변경함.
GPU Memory
│
▼
E810
│
RoCEv2
│
▼
E810
│
▼
Host/GPUNVIDIA의 perftest도 GPU memory를 사용하는 ib_write_bw --use_cuda 방식의 검증을 권장하고 있음. (NVIDIA Docs)
예:
ib_write_bw \
-d <rdma_device> \
--use_cuda=0 \
-a \
<server-ip>단, Intel E810 + RHEL 10.2에서 사용하는 perftest build가 해당 GPU-memory 옵션을 실제 지원하는지 먼저 ib_write_bw --help로 확인해야 함.
8. Host RDMA vs GPUDirect RDMA를 반드시 비교
이 테스트가 굉장히 중요함.
동일한:
Message size
QP
MTU
NIC
Switch조건에서:
Test A
Host RAM → E810 → E810 → Host RAMTest B
GPU Memory → E810 → E810 → Host/GPU비교함.
예:
| Size | Host RDMA | GPUDirect RDMA | 차이 |
|---|---|---|---|
| 1 MB | X | Y | % |
| 4 MB | X | Y | % |
| 16 MB | X | Y | % |
| 64 MB | X | Y | % |
| 256 MB | X | Y | % |
| 1 GB | X | Y | % |
엔지니어링 관점의 핵심
GPUDirect RDMA가 항상 host RDMA보다 wire bandwidth 자체가 크게 증가한다는 의미는 아님.
핵심 이점은:
기존
GPU
↓
CPU/Host memory
↓
Kernel/network stack
↓
NIC
vs
GPUDirect
GPU
↓
NIC처럼 GPU↔CPU memory copy 및 kernel/network stack 관여를 줄이는 것임.
따라서 GPU workload에서는 다음을 같이 봐야 함.
Network bandwidth
CPU utilization
GPU utilization
GPU kernel overlap
Latency9. R4 — PFC/ECN Stress Test
여기서는 평상시 RDMA bandwidth만 보는 것이 아니라 congestion 상황에서 안정성을 보는 것이 중요함.
현재 구조:
GPU Node 1
GPU Node 2
GPU Node 3
...
│
▼
Switch
│
▼
AIStor Nodes에서 여러 sender가 동시에 하나의 receiver로 보내는 incast를 만들어야 함.
예:
GPU1 ─┐
GPU2 ─┤
GPU3 ─┤──> AIStor Node
GPU4 ─┤
GPU5 ─┘테스트
QP:
1
4
8
16
32Sender:
1
2
4
8조합으로 수행함.
10. PFC/ECN에서 볼 지표
NIC
ethtool -S <E810-interface>RDMA
rdma statisticDCB
dcb pfc show dev <interface>
dcb ets show dev <interface>
dcb app show dev <interface>Switch
다음 counter를 확보하는 것이 좋음.
PFC pause frames
ECN marked packets
packet drops
buffer occupancy
queue dropsPASS 기준
정상 상태
→ packet drop 없음
Congestion
→ ECN mark 증가
→ PFC pause 발생
→ packet drop 최소/0
→ bandwidth degradation이 controlled
→ RDMA error 급증 없음11. R5 — Kubernetes Pod에서 RDMA 검증
OS에서 RDMA가 된다고 Kubernetes에서 되는 것은 아님.
따라서:
Host
↓
Pod
↓
RDMA Device를 검증함.
kubectl describe node gpu01에서 RDMA resource 확인함.
그리고 RDMA test Pod를 실행함.
Pod 내부:
rdma linkibv_devicesibv_devinfo까지 정상이어야 함.
PASS
Pod에서 E810 RDMA device 확인
Pod → remote RDMA node bandwidth 정상
Pod → remote RDMA latency 정상12. R6 — NCCL 테스트
B300 × 8이므로 NCCL은 반드시 별도 테스트하는 것을 권장함.
먼저 동일 GPU node에서:
GPU0 ↔ GPU1
GPU0 ↔ GPU2
...
GPU0 ↔ GPU7그리고 collective:
AllReduce
AllGather
Broadcast
ReduceScatter등을 테스트함.
NCCL 테스트의 목적은:
GPU 자체의 communication topology와 CUDA/NCCL stack이 정상인지 확인
하는 것임.
이 단계에서는 아직 AIStor를 넣지 않음.
13. R7 — 최종 GPUDirect RDMA 검증
여기까지 오면 다음 경로가 정상인지 확인함.
B300 GPU Memory
│
│ P2P DMA
▼
Intel E810
│
│ RoCEv2
▼
Switch
│
▼
Remote E810그리고 PCIe ACS/P2P 설정도 확인해야 함.
AIStor 공식 문서에서도 S3-over-RDMA에는 GPU-to-NIC peer-to-peer DMA가 필요하고 PCIe ACS redirect가 영향을 줄 수 있음을 명시함. (MinIO AIStor Documentation)
따라서:
lspci -vvv -s <bridge-BDF> | grep ACSCtl에서:
ReqRedir-
CmpltRedir-상태를 확인함.
14. 여기까지가 GPU/RDMA 통합 검증임
최종적으로 다음 표를 PASS/FAIL matrix로 관리하면 좋음.
| ID | Test | PASS 기준 |
|---|---|---|
| G1 | B300 detection | 8/8 GPU |
| G2 | CUDA | CUDA workload 정상 |
| G3 | GPU topology | 예상 topology |
| R1 | E810 RDMA | PORT_ACTIVE |
| R2 | Host RDMA BW | 목표 bandwidth |
| R3 | Host RDMA latency | 목표 latency |
| R4 | GPU RDMA BW | Host baseline 대비 정상 |
| R5 | GPU RDMA latency | 안정적인 tail latency |
| R6 | RDMA errors | 증가 없음 |
| R7 | PFC/ECN | congestion control 정상 |
| R8 | K8s RDMA | Pod에서 RDMA 가능 |
| R9 | NCCL | 8 GPU collective 정상 |
| R10 | GPUDirect | GPU→NIC P2P 정상 |
15. 이제 AIStor E2E 테스트
여기서부터는 완전히 다른 단계임.
핵심 질문은:
"GPUDirect RDMA가 된다"가 아니라 "GPU application이 AIStor에서 실제 object를 RDMA로 읽고 쓰면서 성능이 좋아지는가?"
임.
AIStor의 S3-over-RDMA는 GetObject, PutObject, UploadPart에 대해 지원하며 client가 x-amz-rdma-token을 보내면 server가 RDMA로 처리함. 성공하면 x-amz-rdma-reply: 200 또는 206을 반환함. (MinIO AIStor Documentation)
16. E2E 테스트는 4단계로 나누는 것을 권장
E1
AIStor TCP baseline
E2
AIStor Inter-node RDMA
E3
S3-over-RDMA Host Memory
E4
S3-over-RDMA GPU Memory
E5
vLLM 실제 workload사실상 5단계로 보는 것이 좋음.
17. E1 — AIStor TCP Baseline
먼저 RDMA를 완전히 배제함.
GPU/CPU client
│
│ TCP
▼
AIStor테스트 목적:
현재 AIStor의 순수 TCP 성능을 baseline으로 확보
권장 Object Size
AI workload 기준:
1 MB
4 MB
16 MB
64 MB
256 MB
1 GB
4 GB특히:
64 MB
256 MB
1 GB를 중요하게 봄.
AIStor의 기본 object performance benchmark도 64 MiB를 기본값으로 사용하고 있음. (MinIO AIStor Documentation)
18. E2 — AIStor Inter-node RDMA
이것은:
AIStor Node
↕
AIStor Node사이의 RDMA임.
GPU와 무관함.
AIStor erasure coding의 shard traffic이 RDMA를 사용하는지 검증함.
여기서 반드시 확인할 metric:
minio_system_network_internode_rdma_write_bytes_total그리고:
minio_system_network_internode_rdma_errors_total
minio_system_network_internode_rdma_pool_fallbacks_total
minio_system_network_internode_rdma_nic_inflight_writes등을 봄. (MinIO AIStor Documentation)
19. E3 — S3-over-RDMA Host Memory
GPU를 사용하지 않고:
Host RAM
↓
E810
↓
RoCE
↓
AIStor를 테스트함.
이 테스트의 목적은:
S3-over-RDMA protocol 자체가 정상인지 확인
하는 것임.
AIStor 공식 문서에서도 S3-over-RDMA는 GPU memory뿐 아니라 host memory buffer도 사용 가능하다고 명시함. (MinIO AIStor Documentation)
20. E4 — S3-over-RDMA GPU Memory
여기가 이번 구축의 핵심 테스트임.
vLLM/Test Application
│
▼
B300 GPU Memory
│
│ GPUDirect RDMA
▼
Intel E810
│
│ RoCEv2
▼
Switch
│
▼
AIStor E810
│
▼
AIStor여기서는 반드시 AIStor의 RDMA response를 확인해야 함.
성공:
x-amz-rdma-reply: 200또는 ranged/part request:
x-amz-rdma-reply: 206실패:
x-amz-rdma-reply: 501AIStor 문서상 501은 "HTTP로 fallback해서 성공했다"는 의미가 아니라 server가 RDMA request를 거절한 S3 error임. Client가 header 없이 재시도해야 함. (MinIO AIStor Documentation)
21. AIStor metric으로 RDMA 사용 여부를 확인
이게 매우 중요함.
client가 "RDMA를 사용했다"고 말하는 것만 믿지 않는 것을 권장함.
AIStor에서:
curl http://<aistor>:9000/minio/metrics/v3/api/rdma확인함.
특히:
minio_api_rdma_read_bytes_total
minio_api_rdma_write_bytes_total를 확인함. (MinIO AIStor Documentation)
예를 들어 GET 테스트 전:
read_bytes_total = 100 GB테스트 후:
read_bytes_total = 600 GB라면:
500 GB가 S3-over-RDMA로 처리되었음을 확인할 수 있음.
22. E2E에서 가장 중요한 비교
다음 4개를 같은 조건으로 비교하는 것을 권장함.
| Test | Data path |
|---|---|
| T1 | TCP + Host memory |
| T2 | RDMA + Host memory |
| T3 | TCP + GPU memory |
| T4 | RDMA + GPU memory |
실제 관심사는:
T1 → T2와
T3 → T4임.
특히:
T3 vs T4에서 GPUDirect RDMA의 효과를 봐야 함.
23. 반드시 측정해야 할 지표
단순 throughput 하나만 보면 안 됨.
Network
Gbps
Packet rate
PFC pause
ECN mark
Drops
RDMA retransmissionAIStor
PUT throughput
GET throughput
IOPS
TTFB
p50
p95
p99
p99.9
RDMA bytes
RDMA ops
RDMA errors
RDMA fallbackGPU
GPU utilization
GPU memory utilization
PCIe TX/RX
GPU power
SM utilizationCPU
CPU utilization
softirq
system CPU
IRQ
context switchStorage
Drive latency
IOPS
Throughput
Queue depth24. 특히 AIStor에서는 fallback을 반드시 봐야 함
최신 AIStor에는 inter-node RDMA receive-buffer pool fallback metric이 있음.
minio_system_network_internode_rdma_pool_fallbacks_total증가한다고 무조건 장애는 아님.
AIStor 문서에 따르면 buffer pool이 부족하거나 shard가 slab보다 커서 TCP로 fallback하는 경우에도 증가함. 이 경우 RDMA가 일부 workload만 처리하고 나머지는 TCP가 처리하는 혼합 상태가 될 수 있음. (MinIO AIStor Documentation)
따라서 성능 테스트에서는:
RDMA throughput
+
TCP throughput
+
fallback count를 같이 봐야 함.
25. Concurrency 테스트
현재 B300 × 8이므로 다음 정도를 추천함.
Object size
4 MB
16 MB
64 MB
256 MB
1 GBConcurrent requests
1
2
4
8
16
32
64
128
256
512단, 처음부터 512까지 갈 필요는 없음.
다음처럼 단계적으로 증가시키는 것이 좋음.
1
4
16
64
256각 단계에서:
Throughput
p50
p95
p99
CPU
GPU
RDMA errors
PFC
ECN을 기록함.
26. GET과 PUT을 반드시 분리
GET
AIStor
↓
Network
↓
E810
↓
GPU MemoryPUT
GPU Memory
↓
E810
↓
Network
↓
AIStor두 경로가 다르므로 반드시 별도로 측정함.
그리고 mixed:
70% GET
30% PUT또는 실제 application workload 비율을 적용함.
27. Multipart Upload 테스트
AI workload에서는 큰 object가 많기 때문에:
UploadPart도 별도 테스트해야 함.
AIStor S3-over-RDMA가 UploadPart도 RDMA path를 지원함. (MinIO AIStor Documentation)
예:
Object = 4 GB
Part size:
64 MB
128 MB
256 MB
512 MB를 비교함.
특히:
Part size
×
concurrency조합이 중요함.
28. 실제 vLLM E2E
마지막에야 vLLM을 넣음.
구조:
vLLM
│
┌─────┴─────┐
│ │
CPU B300
│
GPU Memory
│
GPUDirect RDMA
│
E810
│
RoCEv2
│
Switch
│
E810
│
AIStor여기서 측정할 것은:
Model loading time
Time to first token
Inter-token latency
Tokens/sec
Request/sec
GPU utilization
GPU memory utilization
CPU utilization
AIStor GET bandwidth
RDMA bandwidth임.
29. vLLM에서 특히 비교해야 하는 시나리오
Scenario A
vLLM
↓
AIStor over TCP
↓
GPUScenario B
vLLM
↓
AIStor S3 over RDMA
↓
GPU그리고 동일 모델/동일 dataset/동일 request pattern에서:
Model loading time
TTFT
ITL
tokens/sec
GPU utilization
CPU utilization을 비교함.
이것이 최종적으로 "GPUDirect RDMA가 우리 AI workload에 실제 가치가 있는가"를 판단하는 테스트가 됨.
30. 성능 비교에서 가장 중요한 것은 "Network bandwidth"가 아님
예를 들어:
TCP 22 GB/s
RDMA 23 GB/s이면 "RDMA 효과가 4.5%밖에 안 된다"고 단순 평가하면 안 됨.
실제로는:
TCP
GPU
↓
Host memory copy
↓
Kernel
↓
TCP
↓
NIC대:
RDMA
GPU
↓
NIC에서 CPU utilization이:
TCP 45%
RDMA 12%로 떨어지고,
GPU utilization이:
TCP 65%
RDMA 85%가 된다면 실제 vLLM throughput에서는 RDMA의 가치가 훨씬 커질 수 있음.
따라서 최종 평가식은:
RDMA Benefit
=
Throughput improvement
+
CPU reduction
+
GPU utilization improvement
+
Latency reduction으로 보는 것이 좋음.
31. 제가 추천하는 최종 Benchmark Matrix
실제 Excel에는 아래 정도의 matrix를 만드는 것을 권장함.
| Test | Path | Size | Concurrency | 주요 지표 |
|---|---|---|---|---|
| B01 | Host TCP | 64M | 1 | BW/latency |
| B02 | Host RDMA | 64M | 1 | BW/latency |
| B03 | Host TCP | 256M | 16 | BW/CPU |
| B04 | Host RDMA | 256M | 16 | BW/CPU |
| B05 | GPU TCP | 256M | 16 | BW/CPU/GPU |
| B06 | GPU RDMA | 256M | 16 | BW/CPU/GPU |
| B07 | GPU RDMA | 1G | 16 | BW/latency |
| B08 | GPU RDMA | 1G | 64 | BW/latency |
| B09 | GPU RDMA | 1G | 256 | BW/latency |
| B10 | S3 TCP GET | 256M | 64 | GET |
| B11 | S3 RDMA GET | 256M | 64 | GET |
| B12 | S3 TCP PUT | 256M | 64 | PUT |
| B13 | S3 RDMA PUT | 256M | 64 | PUT |
| B14 | Multipart TCP | 4G | 16 | throughput |
| B15 | Multipart RDMA | 4G | 16 | throughput |
| B16 | vLLM TCP | 실제 workload | 실제 | TTFT/ITL |
| B17 | vLLM RDMA | 실제 workload | 실제 | TTFT/ITL |
32. PASS/FAIL 기준은 이렇게 잡는 것을 추천
절대값 하나를 미리 정하기보다 baseline 대비 상대 기준을 같이 사용하는 것이 좋음.
RDMA Layer
PASS
Bandwidth ≥ 90% of expected line-rate
Latency stable
RDMA error counter = 0 증가
Packet drop = 0 또는 허용범위S3-over-RDMA
PASS
x-amz-rdma-reply = 200/206
RDMA bytes counter 증가
RDMA error 증가 없음
TCP fallback 없음 또는 사전 정의 threshold 이하E2E
예:
RDMA throughput ≥ TCP × 1.10
OR
CPU utilization ≥ 20% 감소
OR
TTFT ≥ 10% 개선
OR
ITL ≥ 10% 개선중 실제 workload에 의미가 있는 항목을 KPI로 선정함.
33. 특히 현재 환경에서 제가 가장 중요하게 보는 테스트
현재 구조라면 다음 6개를 반드시 수행하는 것을 권장함.
① E810 ↔ E810
ib_write_bw↓
② GPU Memory ↔ E810
ib_write_bw --use_cuda↓
③ GPU Node Pod ↔ AIStor Node
RDMA↓
④ AIStor S3 TCP
GET/PUT baseline↓
⑤ AIStor S3-over-RDMA
GPU Memory GET/PUT↓
⑥ vLLM
TCP vs S3-over-RDMA이렇게 하면 어디에서 문제가 생겼는지 명확해짐.
① 실패 → E810/RoCE 문제
② 실패 → GPUDirect/PCIe 문제
③ 실패 → Kubernetes/RDMA exposure 문제
④ 실패 → AIStor 자체 문제
⑤ 실패 → AIStor S3-over-RDMA 문제
⑥ 효과 없음 → Application workload 특성 문제34. 마지막으로 AIStor에서 반드시 확인할 metric
Grafana에 최소한 다음 패널을 만드는 것을 권장함.
S3-over-RDMA
minio_api_rdma_read_bytes_total
minio_api_rdma_write_bytes_totalInter-node RDMA
minio_system_network_internode_rdma_write_bytes_total
minio_system_network_internode_rdma_errors_total
minio_system_network_internode_rdma_pool_fallbacks_total
minio_system_network_internode_rdma_nic_inflight_writes
minio_system_network_internode_rdma_nic_credit_waits_total
minio_system_network_internode_rdma_nic_writes_throttled_totalAIStor 공식 문서에서도 이 metric들을 이용해서 실제로 RDMA가 traffic을 운반하고 있는지, fallback이 발생하는지, fabric congestion이 있는지 확인하도록 안내하고 있음. (MinIO AIStor Documentation)
결론
이번 테스트의 핵심은 "RDMA가 된다/안 된다"가 아니라 아래처럼 계층별로 증명하는 것임.
┌───────────────┐
│ vLLM │
└───────┬───────┘
│
E5. 실제 workload
│
┌───────▼───────┐
│ S3 over RDMA │
└───────┬───────┘
│
E4. GPU Memory
│
┌───────▼───────┐
│ GPUDirect RDMA│
└───────┬───────┘
│
R3. GPU↔NIC
│
┌───────▼───────┐
│ RoCEv2 │
└───────┬───────┘
│
R2. E810↔E810
│
┌───────▼───────┐
│ Intel E810 │
└───────────────┘특히 AIStor에서는 실제 RDMA 사용 여부를 x-amz-rdma-reply와 minio_api_rdma_* metric으로 이중 확인하는 것이 핵심임. AIStor가 RDMA를 사용하지 않아도 일반 서비스 자체는 정상적으로 동작할 수 있기 때문임. (MinIO AIStor Documentation)
그리고 현재처럼 Intel E810 + bond1 공유 + Cilium + RoCEv2 + AIStor 별도 cluster라는 구조에서는 다음 단계로 실제 실행 가능한 테스트 스크립트/명령어 세트까지 만드는 것이 좋음. 즉 GPU node 1대 + AIStor node 2대를 가정해서 서버/클라이언트 명령어 → QP/concurrency → 64MB/256MB/1GB 데이터 → Prometheus query → PFC/ECN counter → PASS/FAIL → 결과를 Excel에 넣는 항목까지 하나의 Runbook으로 만들 수 있음.
