26O06b1

Об этом предложении

네 환경이라면 AIStor를 “GPU용 공유 filesystem”처럼 취급하기보다 S3 기반의 durable object tier로 두고, GPU 노드에는 local NVMe scratch/cache를 두는 2-tier 구조 를 우선 추천합니다. MinIO도 GPU/K8s AI workload에서 S3-native access를 기본 데이터 경로로 설명하고 있고, 최신 AIStor에는 S3 over RDMA도 별도 고성능 경로로 들어가 있습니다. MinIO Kubernetes ┌─────────────────────────────────────────────────────────┐ │ │ │ GPU Node 1 GPU Node 2 GPU Node N │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ GPU x8 │ │ GPU x8 │ │ GPU x8 │ │ │ │ Training / │ │ Training / │ │ vLLM/etc. │ │ │ │ Inference │ │ Inference │ │ │ │ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ │ ┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼─────┐│ │ │ Local NVMe │ │ Local NVMe │ │ Local NVMe ││ │ │ scratch / │ │ scratch / │ │ scratch / ││ │ │ cache │ │ cache │ │ cache ││ │ └──────┬──────┘ └──────┬──────┘ └──────┬─────┘│ │ │ │ │ │ │ └─────────────┬───────┴────────────────────┘ │ │ │ │ │ S3 API / HTTPS │ │ (high-speed Ethernet fabric) │ │ │ │ │ ┌───────────▼───────────┐ │ │ │ MinIO AIStor │ │ │ │ dataset / model │ │ │ │ checkpoint / output │ │ │ └───────────────────────┘ │ └─────────────────────────────────────────────────────────┘ 제가 권장하는 데이터 경로 핵심은 AIStor → GPU memory를 모든 I/O마다 직접 읽는 구조로 만들지 않는 것 입니다. 데이터 권장 위치 GPU workload 접근 Raw dataset AIStor S3 Preprocessed dataset AIStor S3 → local cache Model weights AIStor S3 → local NVMe → load Training checkpoint local NVMe → AIStor async/주기적 upload Training temporary files GPU node NVMe local filesystem Inference model AIStor → node cache startup 시 stage KV cache GPU/HBM/CPU/NVMe/MemKV 계층 AIStor와 분리 Logs/results/artifacts AIStor S3 upload 특히 checkpoint를 매번 AIStor에 synchronous write해서 training iteration을 block시키는 설계는 피하는 편이 좋습니다. 먼저 node-local NVMe에 checkpoint를 만들고 완료된 checkpoint를 AIStor로 flush하는 패턴이 GPU utilization 측면에서 유리합니다. MinIO의 현재 GPU workload 가이드도 training pod에 local NVMe scratch PVC를 두고 AIStor S3 endpoint를 별도로 사용하는 구조를 제시합니다. MinIO K8s에서는 CSI mount보다 S3 API를 우선 예를 들어 GPU Pod에서는 대략 이런 논리 구조가 됩니다. GPU Pod | +-- /scratch -> local NVMe PVC | +-- S3_ENDPOINT -> https://aistor.ai-storage.svc:9000 | +-- AWS_ACCESS_KEY_ID +-- AWS_SECRET_ACCESS_KEY +-- AWS_CA_BUNDLE 애플리케이션은 boto3 / MinIO SDK / S3 SDK / framework connector 등을 통해 AIStor에 접근합니다. 즉, Dataset loading AIStor │ │ S3 GET (parallel) ▼ GPU Node RAM │ ├── optional local NVMe cache │ ▼ GPU memory 반대로 checkpoint는 GPU │ ▼ local NVMe │ │ parallel multipart PUT ▼ AIStor 방향을 권장합니다. MinIO도 AIStor의 GPU workload에서 S3-native API를 primary data path 로 설명하고 있으며 large-object transfer에 parallelism과 multipart tuning을 사용하는 방식을 권장합니다. MinIO 중요한 포인트: Ethernet과 InfiniBand/NDR을 구분 앞에서 이야기했던 네 환경처럼 GPU compute fabric에 NDR InfiniBand가 있고 storage/service 쪽 Ethernet fabric이 따로 있다면 , 저는 초기 구성에서는 이렇게 분리하겠습니다. ┌───────────────┐ │ GPU H100/ │ │ B200/B300 │ └──────┬────────┘ │ ┌─────────────┴──────────────┐ │ │ NDR InfiniBand Ethernet │ │ GPU ↔ GPU traffic S3 traffic NCCL / MPI AIStor RDMA collectives K8s │ management │ │ IB Leaf/Spine Eth Leaf/Spine │ ┌─────▼─────┐ │ AIStor │ └───────────┘ 즉 NDR은 GPU collective traffic , Ethernet은 AIStor S3 traffic으로 시작하는 것이 운영 측면에서 가장 명확합니다. 네가 앞서 말한 Cilium native routing + BGP + ECMP 환경과도 잘 맞습니다. AIStor traffic은 Ethernet L3 fabric으로 보내고 GPU-to-GPU NCCL traffic은 IB fabric에 남겨두는 식입니다. 그런데 AIStor + RDMA가 하나 더 있습니다 여기서 조금 재미있는 부분이 있습니다. 현재 AIStor에는 S3 over RDMA 가 있습니다. MinIO 설명상 application buffer를 등록한 뒤 object payload를 RDMA로 전송하여 일반적인 kernel network stack 경로의 copy를 줄이는 방식입니다. MinIO AIStor Documentation 따라서 발전 단계는 이렇게 잡는 게 좋습니다. Phase 1 ======= GPU │ │ S3 / HTTPS / TCP ▼ Ethernet │ ▼ AIStor Phase 2 ======= GPU │ │ S3 over RDMA ▼ RDMA Fabric │ ▼ AIStor 다만 여기서 “NDR IB가 있으니 AIStor를 바로 NDR에 붙이자” 로 가는 것은 권하지 않습니다. 먼저 baseline S3/TCP 성능을 측정해야 합니다. 예를 들어 GPU node당 Ethernet이 2×100/200/400GbE라면 dataset loader가 실제로 그 bandwidth를 얼마나 사용하는지 확인하고, GPU starvation이 storage path 때문에 발생하는지 본 뒤 RDMA를 검토하는 게 맞습니다. GPUDirect Storage와도 구분해야 합니다 이 부분이 자주 혼동됩니다. S3 over TCP AIStor → NIC → CPU memory → application → GPU S3 over RDMA AIStor → RDMA → registered application memory → GPU pipeline GPUDirect Storage Storage → NIC/NVMe → GPU memory (CPU bounce 감소/회피) NVIDIA의 GDS는 GPU와 storage 사이 I/O 경로를 최적화하는 기술이고, object-storage 쪽에는 별도로 cuObject 경로도 있습니다. NVIDIA Docs 그래서 “AIStor S3 over RDMA = GDS”라고 보면 안 됩니다. 이 둘은 별개의 계층입니다. AIStor 자체 storage node 구성 AIStor 서버 쪽은 가능하면 이렇게 가져가는 것이 좋습니다. AIStor Node CPU │ ├── 100/200/400GbE NIC │ ├── NVMe ├── NVMe ├── NVMe ├── NVMe └── ... JBOD │ XFS │ AIStor Server HW RAID → filesystem → AIStor 보다는 직접 연결된 NVMe/SSD JBOD를 AIStor가 관리하게 하는 쪽이 권장됩니다. MinIO도 성능을 위해 direct-attached flash, 특히 NVMe를 권장하고, Kubernetes에서는 host-local PV를 관리하는 CSI 방식을 제시합니다. MinIO AIStor Documentation 그래서 GPU cluster와 AIStor cluster를 물리적으로 분리할 수 있다면 저는 오히려 GPU Nodes AIStor Nodes ───────── ──────────── 8x GPU CPU local NVMe NVMe x N 400GbE NIC =================== 400GbE NIC NDR IB NIC 처럼 구성하는 쪽을 선호합니다. AIStor를 GPU node에 같이 배치하면 network hop 하나를 줄일 수 있지만 CPU/RAM/NVMe/network contention이 생길 수 있기 때문에, 대규모 B300 cluster라면 dedicated AIStor nodes + 같은 고속 Ethernet fabric 이 운영상 더 깔끔할 가능성이 높습니다. Air-gap에서는 이것도 설계에 포함해야 합니다 네 환경에서는 이 부분이 상당히 중요합니다. Internet Zone │ │ approved transfer ▼ Air-gap boundary │ ├── Private OCI Registry │ ├ NVIDIA images │ ├ AIStor images │ └ application images │ ├── Private Helm Registry │ ├ AIStor Operator │ └ AIStor ObjectStore │ └── Internal CA / DNS AIStor 공식 air-gap 절차도 container image와 Helm chart를 외부에서 준비하여 내부 private registry로 반입 하는 2단계 방식을 사용합니다. Production AIStor라면 license도 사전에 준비해야 합니다. MinIO AIStor Documentation 특히 다음은 외부 dependency가 하나라도 남지 않도록 해야 합니다: NVIDIA GPU Operator 이미지, driver/container toolkit 관련 이미지, AIStor Operator/Server/sidecar, Helm charts, training/inference container, Python wheels/Conda packages, model/dataset, CA/CRL 및 필요한 OS repository mirror. 네 환경에 적용한다면 앞선 환경을 기준으로 저는 1차 목표 architecture를 아래처럼 잡겠습니다. ┌─────────────────────┐ │ Kubernetes Control │ └─────────────────────┘ GPU / Compute Nodes ┌──────────────────────────────────────────┐ │ B300 x8 │ │ │ │ local NVMe │ │ ├ dataset cache │ │ ├ model staging │ │ └ checkpoint scratch │ │ │ │ NDR IB ───────── NCCL / GPU traffic │ │ │ │ 400GbE x2 ────── S3 / K8s traffic │ └────────────────┬─────────────────────────┘ │ Ethernet Fabric BGP + ECMP + Cilium │ ┌──────────┴───────────┐ │ │ ┌─────▼─────┐ ┌─────▼─────┐ │ AIStor #1 │ ... │ AIStor #N │ │ NVMe JBOD │ │ NVMe JBOD │ └───────────┘ └───────────┘ Buckets ├── datasets/ ├── models/ ├── checkpoints/ ├── inference-artifacts/ └── results/ 그리고 NDR IB에 AIStor traffic을 넣는 것은 Phase 2 최적화 항목 으로 남겨두겠습니다. 먼저 400GbE S3/TCP baseline → GPU data-loader throughput → GPU idle/I/O wait → checkpoint throughput을 측정한 뒤, 병목이 object path로 확인되면 S3 over RDMA를 검증하는 순서가 안전합니다. 특히 네가 이전에 정리하던 B300 + AIStor + MemKV 테스트 구조 와 연결하면 역할을 아주 깔끔하게 나눌 수 있습니다: GPU HBM ▲ │ KV / tensors │ ┌─────┴─────┐ │ MemKV │ ← hot / low-latency tier └───────────┘ Local NVMe ← scratch/cache/staging ▲ │ ┌─────┴─────┐ │ AIStor │ ← durable/capacity tier └───────────┘ ▲ │ dataset/model/checkpoint 즉 AIStor = durable object/data lake tier , Local NVMe = GPU staging/scratch tier , MemKV = KV/cache hot tier , NDR = GPU collective/RDMA fabric 으로 역할을 분리하면 전체 구조가 상당히 명확해집니다. 이 구분은 이전 v13_1에서 remote_object(AIStor) 와 memkv_tcp / memkv_rdma 를 분리했던 이유와도 정확히 맞습니다. GPU 노드의 8개 NVMe가 AIStor의 영구 저장소가 아니라 dataset/model staging, scratch, checkpoint 임시 저장용 이라는 전제라면, RHEL 10에서는 RAID5/6 같은 parity RAID보다 JBOD 또는 RAID0 계열 을 우선 고려하는 게 좋습니다. 제가 이 환경에서 가장 먼저 검토할 구성은 8개 NVMe를 하나의 mdadm RAID0 + XFS 로 묶는 방식입니다. NVMe0 ─┐ NVMe1 ─┤ NVMe2 ─┤ NVMe3 ─┤ NVMe4 ─┼── mdadm RAID0 ── XFS ── /scratch NVMe5 ─┤ NVMe6 ─┤ NVMe7 ─┘ ├── dataset-cache/ ├── model-cache/ ├── checkpoints/ └── tmp/ 왜 RAID0인가? 이 구조에서는 AIStor가 authoritative/durable copy 이고 local NVMe는 다시 만들 수 있는 데이터만 담도록 설계하는 게 핵심입니다. 예를 들어: AIStor │ │ dataset/model ▼ 400GbE │ ▼ 8 x NVMe RAID0 │ │ DataLoader ▼ CPU RAM │ ▼ GPU HBM NVMe 하나가 죽으면 RAID0 전체가 깨질 수 있지만, /scratch 를 비우고 AIStor에서 다시 stage하면 됩니다. 그 대가로 8개 NVMe의 bandwidth와 IOPS를 모두 활용할 수 있습니다. RHEL 10에서는 mdadm + XFS를 우선 추천 구성 자체는 단순합니다. /dev/nvme0n1 ─┐ /dev/nvme1n1 ─┤ /dev/nvme2n1 ─┤ /dev/nvme3n1 ─┤ /dev/nvme4n1 ─┼── /dev/md0 ── XFS ── /scratch /dev/nvme5n1 ─┤ /dev/nvme6n1 ─┤ /dev/nvme7n1 ─┘ 개념적인 생성은 다음과 같습니다. mdadm --create /dev/md0 \ --level=0 \ --raid-devices=8 \ /dev/nvme0n1 \ /dev/nvme1n1 \ /dev/nvme2n1 \ /dev/nvme3n1 \ /dev/nvme4n1 \ /dev/nvme5n1 \ /dev/nvme6n1 \ /dev/nvme7n1 mkfs.xfs /dev/md0 mkdir -p /scratch mount -o noatime /dev/md0 /scratch 다만 실제 서버에서는 OS disk와 scratch NVMe를 정확히 구분한 뒤 WWN/serial 기반으로 자동화해야 합니다. /dev/nvme0n1 같은 이름은 부팅/하드웨어 변경에 따라 식별 용도로 쓰기 적합하지 않습니다. 그런데 B300급 GPU node라면 두 가지를 비교해보는 게 좋습니다 8개를 전부 RAID0으로 묶는 방법 외에 4+4 RAID0 도 꽤 좋은 선택입니다. Option A NVMe x8 │ ▼ RAID0 │ ▼ /scratch 장점 - 가장 단순 - 최대 aggregate bandwidth - DataLoader에서 사용 편함 단점 - NVMe 1개 장애 → 전체 scratch 소실 반면: Option B NVMe0 ─┐ NVMe1 ─┤ NVMe2 ─┤── RAID0 ── /scratch0 NVMe3 ─┘ NVMe4 ─┐ NVMe5 ─┤ NVMe6 ─┤── RAID0 ── /scratch1 NVMe7 ─┘ 이 구성은 NUMA topology 를 활용할 수 있다는 장점이 있습니다. 예를 들어 8-GPU node가 dual-socket이고 PCIe topology가 다음처럼 되어 있다면: NUMA 0 NUMA 1 CPU0 CPU1 │ │ ├ GPU0 ├ GPU4 ├ GPU1 ├ GPU5 ├ GPU2 ├ GPU6 ├ GPU3 ├ GPU7 │ │ ├ NVMe0 ├ NVMe4 ├ NVMe1 ├ NVMe5 ├ NVMe2 ├ NVMe6 └ NVMe3 └ NVMe7 │ │ RAID0 RAID0 │ │ /scratch0 /scratch1 이 경우 8개짜리 RAID0 하나보다 NUMA-local 4+4 RAID0가 더 좋은 결과를 낼 가능성 이 있습니다. GPU가 반대쪽 NUMA의 NVMe를 읽으면서 CPU interconnect를 넘어가는 traffic을 줄일 수 있기 때문입니다. 그래서 네 B300 환경이라면 저는 바로 8 x NVMe → RAID0 으로 확정하기보다 아래 순서로 결정하겠습니다. 구성 추천도 용도 8×NVMe 각각 사용 ★★★ application이 직접 striping/cache 관리 4+4 RAID0 + XFS ★★★★★ dual-NUMA 8-GPU node 8 RAID0 + XFS ★★★★★ topology가 중요하지 않을 때 RAID10 ★★★ local checkpoint도 어느 정도 보호 RAID5 ★ GPU scratch 비추천 RAID6 ★ GPU scratch 비추천 LVM striping ★★★ volume 관리가 필요할 때 여기서 중요한 것은 실제 PCIe topology 입니다. RHEL에서 다음 정보를 보면 결정할 수 있습니다. lscpu -e=CPU,NODE,SOCKET,CORE numactl --hardware lspci -tv nvidia-smi topo -m for d in /sys/block/nvme*n1; do echo "$d" cat "$d/device/numa_node" done 예를 들어 결과가 NUMA0 NUMA1 GPU 0 1 2 3 4 5 6 7 NVMe 0 1 2 3 4 5 6 7 NIC eth0 eth1 처럼 깔끔하게 나뉜다면 저는 4+4 RAID0 쪽으로 갑니다. K8s에서는 그 위에