26O07n2
현재 환경과 신규 하드웨어 구성을 함께 고려하면, 저는 GPU 전용 Kubernetes 클러스터를 별도로 구축하고, 기존 Compute·Storage 클러스터와 Cilium ClusterMesh로 선택적으로 연동하는 방안을 우선 추천합니다.
다만 GPU 노드가 12대뿐이라는 점에서, 운영 복잡성과 GPU 워크로드 특성에 따라 Compute 클러스터에 GPU Worker를 추가하는 방안도 충분히 경쟁력이 있습니다.
중요한 것은 ClusterMesh를 사용한다고 세 클러스터가 하나의 Kubernetes 클러스터처럼 동작하는 것은 아니라는 점입니다. 네트워크 연결과 서비스 검색은 확장할 수 있지만, Kubernetes Scheduler·API Server·RBAC·GPU 자원 스케줄링은 여전히 클러스터별로 독립적입니다.
1. 비교할 세 가지 아키텍처
A. Compute 클러스터에 GPU Worker 추가
운영 단순
Compute와 GPU가 동일한 API Server·Scheduler·Cilium 환경을 공유합니다.
B. Storage 클러스터에 GPU Worker 추가
GPU와 AIStor가 같은 클러스터에 있지만, RDMA 성능이 자동으로 향상되는 것은 아닙니다.
C. GPU 전용 클러스터 구축
추천
GPU 드라이버·RDMA·스케줄링·유지보수 정책을 독립적으로 운영합니다.
2. 장단점 비교
| 평가 항목 | A. Compute에 GPU 추가 | B. Storage에 GPU 추가 | C. GPU 독립 클러스터 |
|---|---|---|---|
| 구축 난이도 | 낮음 | 낮음~중간 | 높음 |
| Control Plane 추가 | 불필요 | 불필요 | 필요 |
| GPU Operator 운영 | 기존 클러스터에 추가 | Storage 클러스터에 추가 | 독립 관리 |
| CUDA/드라이버 업그레이드 | Compute와 영향 범위 공유 | Storage와 영향 범위 공유 | 격리 가능 |
| GPU/NCCL 스케줄링 | 가능 | 가능 | 전용 정책 적용 용이 |
| AIStor RDMA 성능 | 동일 조건에서 차이 없음 | 동일 조건에서 차이 없음 | 동일 조건에서 차이 없음 |
| 장애 영향 범위 | Compute와 공유 | Storage와 공유 | 독립 |
| 일반 CPU/GPU 작업 연계 | 가장 편리 | 불편 | 클러스터 간 연계 필요 |
| 운영 비용 | 낮음 | 낮음~중간 | 높음 |
| 장기 확장성 | 좋음 | 제한적 | 매우 좋음 |
A. Compute 클러스터에 GPU Worker 추가
이 방안의 가장 큰 장점은 CPU 전처리 → GPU 학습 → 후처리를 동일 Kubernetes 클러스터에서 실행할 수 있다는 점입니다.
예를 들어 CPU 기반 데이터 전처리 Job과 GPU 학습 Job을 하나의 워크플로로 묶기 쉽고, 동일한 Scheduler와 Kubernetes API를 사용할 수 있습니다.
반면 B300에서는 NVIDIA GPU Operator, Network Operator, CUDA, ConnectX-7 RDMA, NCCL 관련 구성이 추가됩니다. NVIDIA 공식 문서에서도 GPU Operator와 Network Operator가 드라이버 및 RDMA 관련 구성요소를 관리한다고 설명합니다.
NVIDIA GPU Operator
+1
기존 Compute 클러스터에 추가하면 이러한 구성의 설치·업그레이드 및 일부 클러스터 공통 구성 변경이 Compute 운영에도 영향을 줄 수 있습니다. 물론 GPU 노드만 대상으로 설정하고 업그레이드를 제한하면 위험을 상당 부분 줄일 수 있습니다.
적합한 경우: CPU/GPU 혼합 워크로드가 많고, 하나의 Kubernetes API와 스케줄러로 관리하는 것이 중요한 경우입니다.
B. Storage 클러스터에 GPU Worker 추가
가장 큰 장점은 GPU와 AIStor를 동일 클러스터에서 관리할 수 있다는 것입니다. 하지만 이것이 S3 over RDMA나 GPUDirect 성능을 높여주지는 않습니다.
GPU와 AIStor가 별도 클러스터여도 NDR InfiniBand의 물리적 연결과 RDMA 지원 클라이언트가 올바르게 구성되어 있다면 동일한 고속 데이터 경로를 사용할 수 있습니다.
반대로 GPU 학습에서 발생하는 대량 Pod 생성, Job 재시도, GPU Operator 변경 등이 Storage 클러스터의 API Server나 공통 구성요소에 부담을 줄 수 있습니다.
55대 AIStor는 여러 GPU 워크로드에 데이터를 제공하는 핵심 저장소이므로, Storage 클러스터의 안정성을 GPU 워크로드의 변화로부터 보호하는 것이 더 중요하다고 봅니다.
적합한 경우: GPU가 독립적인 학습 플랫폼이라기보다 Storage 클러스터 내부의 데이터 처리 가속기로 사용되는 경우입니다.
C. GPU 독립 클러스터 + ClusterMesh
가장 큰 장점은 GPU 소프트웨어 스택과 운영 정책의 독립성입니다.
B300 전용 클러스터에서는 GPU Operator, Network Operator, NCCL, RDMA, 드라이버 업그레이드, GPU 노드 유지보수를 Compute 및 Storage 클러스터와 분리할 수 있습니다.
또한 향후 GPU 서버가 추가되거나 학습과 추론을 분리해야 할 때 확장하기 좋습니다.
단점은 Control Plane, 인증·권한, 모니터링, GitOps, GPU Job 배포 및 장애 대응을 별도로 관리해야 한다는 점입니다. CPU 전처리와 GPU 학습을 연결하려면 Argo Workflows 같은 워크플로 도구나 별도의 멀티클러스터 Job orchestration이 필요할 수 있습니다.
적합한 경우: GPU 학습 플랫폼의 독립적인 운영, 버전 관리, 성능 격리 및 장기 확장이 중요한 경우입니다.
3. ClusterMesh가 실제로 제공하는 것과 제공하지 않는 것
Cilium ClusterMesh는 공식적으로 클러스터 간 Pod 연결, 서비스 검색, 글로벌 서비스 로드밸런싱 및 네트워크 정책을 지원합니다.
Cilium 1.20.2 documentation
+1
| 기능 | ClusterMesh 지원 |
|---|---|
| Compute Pod ↔ GPU Pod IP 통신 | 가능 |
| GPU Pod ↔ Storage Pod IP 통신 | 가능 |
| Cross-cluster NetworkPolicy | 가능 |
| Global Service / MCS-API | 가능 |
| GPU 클러스터의 Pod를 Compute Scheduler가 직접 배치 | 불가 |
| Kubernetes Job의 자동 클러스터 간 이동 | 불가 |
| 클러스터 간 GPU 자원 공유 스케줄링 | 불가 |
| InfiniBand RDMA 경로 구성 | 별도 필요 |
즉 ClusterMesh는 네트워크 연결 기술이지 멀티클러스터 스케줄러가 아닙니다.
그리고 GPU와 AIStor 사이의 S3/RDMA 데이터 경로를 반드시 ClusterMesh로 통과시킬 필요도 없습니다.
4. 권장 구성: 3개 클러스터 + 독립 NDR Fabric
현재 장비 구성에서는 다음 아키텍처를 권장합니다.
개념도: GPU와 AIStor의 NDR 연결은 ClusterMesh와 독립적으로 구성합니다. Compute 노드는 NDR에 연결하지 않습니다.
여기서 운영 설계상 중요한 것은 다음 네 가지입니다.
-
GPU Control Plane을 어디에 배치할지: GPU 12대를 모두 Worker로 활용하려면 HPE Compute 서버 일부를 GPU 클러스터의 전용 Control Plane/Infra 노드로 할당하는 방안을 권합니다. 동일 물리 노드를 두 Kubernetes 클러스터에 동시에 가입시키는 방식은 피합니다.
-
ClusterMesh 연결 조건: 세 클러스터의 PodCIDR은 겹치지 않아야 하고, Cilium datapath mode와 버전 호환성, Node IP 상호 연결을 검증해야 합니다. 현재 공식 문서는 Cilium 버전 차이를 최대 1개 minor로 제한합니다.
Cilium 1.20.2 documentation
-
Storage 접근 경로: AIStor의 일반 S3 서비스는 안정적인 라우팅 가능한 endpoint로 제공하고, RDMA는 NDR를 통해 별도로 연결합니다. Storage 서비스 가용성을 ClusterMesh 상태에만 의존시키지 않는 것이 좋습니다.
-
보안 및 장애 격리: ClusterMesh에 연결된 클러스터들은 Cilium 관점에서 하나의 신뢰 도메인을 형성하므로, 별도 클러스터라고 해서 네트워크 보안까지 완전히 격리되는 것은 아닙니다.
Cilium 1.20.2 documentation
5. 최종 의사결정
현재 환경에 대한 제 평가
정성적 비교
GPU 독립 클러스터
5/5
Compute 클러스터에 GPU 추가
4/5
Storage 클러스터에 GPU 추가
2/5
GPU 운영 독립성, Storage 안정성, 기존 Cilium 활용도, 운영 복잡도를 종합한 설계 판단이며 벤치마크 점수는 아닙니다.
제가 권하는 선택은 C안, GPU 전용 클러스터입니다. 특히 이번에는 B300 96개와 AIStor 40PB급 저장소가 별도 인프라로 도입되므로, GPU 소프트웨어 스택을 독립적으로 관리할 실익이 큽니다.
다만 최종 결정을 위해 한 가지를 더 확인하고 싶습니다.
현재 Compute 클러스터의 주요 역할이 무엇인가요?
GPU 학습을 위한 데이터 전처리 및 후처리가 주력
일반 애플리케이션·API·배치·전처리 등 혼합
주로 Kubernetes 인프라 및 공통 서비스
이 조건으로 아키텍처 구체화
이 정보에 따라 Compute+GPU 통합의 이점이 큰지, 독립 GPU 클러스터의 이점이 더 큰지를 보다 정확히 판단할 수 있습니다.
===
현재 Compute 클러스터가 일반 애플리케이션, API, 배치, 데이터 전처리를 함께 수행한다면, 저는 GPU 클러스터를 분리하는 3-Cluster 구조를 추천합니다.
다만 GPU 클러스터를 완전히 독립된 섬처럼 운영하기보다는, 클러스터는 분리하고 사용자 인증·워크플로·모델 API·모니터링은 공통화하는 구조가 적합합니다.
이번 설계에서 가장 중요한 결정은 다음 세 가지입니다.
- GPU 12대는 모두 GPU Worker로 유지하고, GPU 클러스터 Control Plane은 HPE 서버에 배치합니다.
- Compute 클러스터는 CPU 전처리·API·일반 배치·공통 플랫폼 서비스를 담당하고, GPU 클러스터는 학습·추론·GPU 전용 Job을 담당합니다.
- Cilium ClusterMesh는 클러스터 간 IP 통신과 서비스 연결에 사용하되, 학습 Job 배포와 GPU 자원 할당은 별도의 워크플로·스케줄링 계층에서 처리합니다.
1. 권장 전체 아키텍처
논리 아키텍처입니다. NDR는 GPU·AIStor의 별도 물리 인터페이스를 사용하며 Cilium ClusterMesh를 통과하지 않습니다.
이 구조에서 Compute 클러스터는 GPU 클러스터에 대한 플랫폼 서비스 제공자 역할을 하게 됩니다. 예를 들어 사용자는 Compute 쪽의 API/포털로 요청하고, 워크플로 시스템이 GPU 클러스터에 Job을 생성하며, 결과는 AIStor에 저장하는 방식입니다.
2. HPE DL380 60대의 구체적인 할당
현재 HPE DL380 Gen12는 총 60대이며, 각 서버가 CPU 96코어와 RAM 1TB를 제공합니다.
제 추천은 HPE 9대를 세 클러스터의 Control Plane으로 전용 할당하고, 나머지 51대를 Compute 클러스터에 배치하는 것입니다.
HPE 60대 권장 배분
48 Compute Workers
3
3
3
3
Compute Workers
48대
Compute CP
3대
GPU CP
3대
AIStor CP
3대
공통 Infra
3대
| 클러스터 | HPE Control Plane | Worker |
|---|---|---|
| Compute | 3대 | HPE 48대 |
| GPU | 3대 | XE9780 12대 |
| AIStor | 3대 | SR650 V4 55대 |
| 공통 Infra | 별도 HPE 3대 | 공통 플랫폼 서비스 |
| 합계 | HPE 12대(Infra 포함) | HPE 48 + GPU 12 + AIStor 55 |
여기서 공통 Infra 3대는 Compute 클러스터의 전용 Infra Worker로 가입시키는 것을 권장합니다. 즉 네 번째 클러스터를 만드는 것은 아닙니다.
서버 배치 예시
| 서버 ID | 할당 | 역할 |
|---|---|---|
| HPE-01~03 | Compute | Control Plane / etcd |
| HPE-04~06 | GPU | Control Plane / etcd |
| HPE-07~09 | AIStor | Control Plane / etcd |
| HPE-10~12 | Compute | 공통 Infra Worker |
| HPE-13~60 | Compute | 일반 CPU Worker |
| GPU-01~12 | GPU | B300 GPU Worker |
| AIStor-01~55 | AIStor | Storage Worker |
이 배치의 장점은 GPU 12대 모두를 학습·추론에 사용한다는 점입니다. GPU 서버에 Control Plane을 배치하거나 일반 플랫폼 서비스를 상주시킬 필요가 없습니다.
단, 실제 물리 서버를 배치할 때는 각 클러스터의 Control Plane 3대를 서로 다른 Rack/PDU/Leaf 장애 도메인에 분산해야 합니다. GPU 및 AIStor 클러스터의 HPE Control Plane은 NDR가 없어도 되며, 해당 클러스터의 Ethernet 관리 네트워크에 접근할 수 있어야 합니다.
또한 HPE 96코어/1TB 서버를 Control Plane 전용으로 사용하는 것은 자원 측면에서 상당히 큰 할당입니다. 이미 사용 가능한 VM 기반 Control Plane 플랫폼이 있다면 물리 HPE 9대 전용 할당 대신 VM 9개로 구성하고 CPU Worker 수를 늘리는 방안도 비교할 가치가 있습니다.
3. 클러스터별 Kubernetes 구성
| 항목 | Compute | GPU | AIStor |
|---|---|---|---|
| Cilium Native | 사용 | 사용 | 사용 |
| BGP / ECMP | 사용 | 사용 | 사용 |
| ClusterMesh | 선택적 연결 | 선택적 연결 | 선택적 연결 |
| GPU Operator | 불필요 | 필수 | 보통 불필요 |
| Network Operator | 필요 시 | RDMA용 검토 | AIStor RDMA 방식에 맞게 |
| AIStor Operator | 불필요 | 불필요 | 사용 |
| Local NVMe | Batch/Scratch | Model/Dataset Cache | Object Data |
| 주요 스케줄러 | Kubernetes 기본 | Kubernetes + GPU Batch | Kubernetes 기본 |
| 주요 서비스 | API/전처리/공통 플랫폼 | 학습/추론 | S3/RDMA |
여기서 GPU 클러스터는 처음부터 복잡한 스케줄러를 여러 개 설치하기보다, Kubernetes 기본 Scheduler + Kueue를 우선 검토하겠습니다.
Kueue는 대기열, quota, admission 및 GPU 자원 할당 정책을 관리하고, 실제 Pod 배치는 Kubernetes Scheduler가 수행합니다.
NCCL 기반 multi-node training에서 gang scheduling이나 topology-aware scheduling 요구가 강하다면 해당 기능을 지원하는 Kubernetes/Kueue 버전을 검증하거나 Volcano를 비교하는 것이 좋습니다.
4. CPU 전처리부터 GPU 학습까지의 스케줄링 구조
현재 Compute 클러스터의 역할을 고려하면 전처리는 Compute, 학습은 GPU, 데이터 저장은 AIStor로 역할을 분리하는 것이 자연스럽습니다.
권장 AI 학습 파이프라인
1. 사용자 / API / Workflow
Compute Cluster · Job 요청 · 인증 · 정책 검사
2. CPU 데이터 전처리
Compute Worker · 변환 · Tokenization · Dataset Sharding
3. AIStor에 Dataset 저장
S3 Bucket · Dataset Version · Manifest
4. GPU 학습 Job
GPU Cluster · Kueue Admission · B300 · NCCL
5. AIStor에 Checkpoint / Model 저장
S3 over TCP 또는 검증된 RDMA 경로
6. GPU 추론 배포
vLLM · Inference Service · Compute API Gateway
여기서 중요한 설계 원칙은 워크플로 제어와 대용량 데이터 이동을 분리하는 것입니다.
Compute 클러스터의 Workflow Controller가 GPU 클러스터에 학습 Job을 제출할 수 있지만, 수 TB의 학습 데이터를 Compute Pod를 경유해서 전달할 필요는 없습니다.
전처리 결과를 AIStor에 저장하고 GPU Job이 해당 데이터를 직접 읽도록 하면 됩니다.
추천 스케줄링 구성
| 계층 | 추천 기술 | 역할 |
|---|---|---|
| 워크플로 | Argo Workflows 등 | CPU→GPU→저장 파이프라인 |
| 클러스터 간 Job 제출 | Kubernetes API / 전용 Job Controller | GPU 클러스터에 Job 생성 |
| GPU 자원 Admission | Kueue | Quota, 대기열, 우선순위 |
| GPU Pod 배치 | Kubernetes Scheduler | GPU Worker에 Pod 할당 |
| 분산학습 | Kubeflow Trainer 등 | PyTorch 분산학습 Job 관리 |
| 추론 | vLLM + Kubernetes | GPU 모델 서빙 |
| 배포/설정 | Argo CD 등 | 클러스터별 GitOps |
Kueue의 MultiKueue 기능을 활용하면 중앙 대기열에서 여러 Worker 클러스터로 Job을 전달하는 구조도 검토할 수 있습니다. 다만 지금은 GPU 클러스터가 하나이므로 GPU 클러스터 내부 Kueue부터 시작하는 것이 더 단순합니다.
5. GPU 96개의 학습·추론 자원 관리
GPU 클러스터를 분리하면 Compute의 일반 배치 작업과 독립적으로 GPU 사용량을 제어할 수 있습니다.
예를 들어 초기 운영 프로파일을 다음처럼 정의할 수 있습니다.
| 프로파일 | 학습 | 추론 | 합계 |
|---|---|---|---|
| 주간 예시 | 32 GPU | 64 GPU | 96 |
| 야간 예시 | 80 GPU | 16 GPU | 96 |
| 대규모 학습 | 96 GPU | 0 GPU | 96 |
이는 설계 예시이며 확정 권장값은 아닙니다. 실제 배분은 모델별 TP/PP/DP/EP, HBM, KV Cache, 동시성 및 Stage7 성능 테스트 결과로 결정해야 합니다.
또한 GPU 서버당 B300이 8개이므로 실제 배치는 8-GPU 노드 단위의 locality와 분산학습 topology를 고려해야 합니다. 32 GPU 학습이라면 4노드, 80 GPU 학습이라면 10노드가 하나의 단순한 배치 예시가 됩니다.
Kueue quota 변경만으로 실행 중인 vLLM Pod나 학습 Job이 자동 재배치되는 것은 아닙니다. 주간·야간 전환에는 GitOps, CronJob 또는 별도 Controller를 통해 안전한 drain/scale 정책을 구현해야 합니다.
6. ClusterMesh는 어디까지 연결할까?
현재 Compute와 Storage는 이미 Cilium Native Routing + BGP/ECMP + ClusterMesh를 사용하고 있으므로, GPU 클러스터도 동일한 기본 네트워크 철학으로 운영할 수 있습니다.
다만 모든 서비스를 Global Service로 만들 필요는 없습니다.
| 연결 | 권장 방식 |
|---|---|
| Compute → GPU 추론 API | ClusterMesh 또는 내부 Gateway |
| Compute → GPU Job 제출 | GPU Kubernetes API, 인증된 서비스 계정 |
| Compute → AIStor S3 | 안정적인 S3 Endpoint |
| GPU → AIStor 일반 S3 | Ethernet의 라우팅 가능한 Endpoint |
| GPU → AIStor S3 over RDMA | NDR400 InfiniBand |
| GPU ↔ GPU NCCL | NDR400 InfiniBand |
| 모니터링/로그 | 중앙 수집 또는 클러스터별 수집 후 통합 |
특히 AIStor S3 서비스를 ClusterMesh에만 의존시키지 않는 것을 권장합니다. ClusterMesh에 장애가 발생하더라도 GPU 및 Compute가 독립적인 S3 Endpoint를 통해 AIStor에 접근할 수 있도록 설계하는 편이 안정적입니다.
추가로 Cilium BGP와 ClusterMesh가 사용하는 CIDR, 라우팅, 방화벽 정책을 세 클러스터 전체에서 일관되게 설계해야 합니다. ClusterMesh를 사용하려면 PodCIDR 충돌이 없어야 하며, Service CIDR과 글로벌 서비스의 주소·이름 정책도 별도로 검토해야 합니다.
7. 운영 관점에서 추가로 결정해야 할 사항
| 항목 | 제안 |
|---|---|
| 인증 | Keycloak/OIDC 등 공통 IAM |
| Kubernetes 권한 | 클러스터별 RBAC 분리 |
| GPU 사용자 Quota | Kueue ClusterQueue/LocalQueue |
| 학습 Job 우선순위 | 사용자/프로젝트별 정책 |
| GPU 모니터링 | DCGM Exporter + Prometheus |
| NDR 모니터링 | UFM/IB Telemetry + NCCL 지표 |
| AIStor 모니터링 | S3 latency, throughput, disk/network |
| 배포 관리 | GitOps Repository 분리 |
| 장애 격리 | GPU/Storage Control Plane 독립 |
| 업그레이드 | 클러스터별 독립 유지보수 창 |
여기서 한 가지 주의할 점은 공통 Infra를 Compute 클러스터에 배치하면 Compute 클러스터 전체 장애 시 해당 공통 서비스도 영향을 받는다는 것입니다. 초기에는 운영 단순성을 위해 이 구조가 적절하지만, 인증·배포·관측 시스템의 요구 가용성이 높다면 별도의 관리 인프라 또는 외부 HA 서비스를 검토해야 합니다.
최종 권장 구성
3-Cluster Architecture
51
HPE Compute 소속
48 CPU + 3 Infra
12
GPU Workers
96 B300 GPUs
55
AIStor Workers
약 40.55PB Raw
Control Plane: HPE 3대 × 3개 클러스터 = 9대
Network: Cilium Native + BGP/ECMP + 선택적 ClusterMesh
High-Speed Data: GPU↔GPU 및 GPU↔AIStor NDR400
Job Scheduling: Compute Workflow → GPU Kueue/Scheduler
Storage: AIStor S3/RDMA + PowerScale POSIX
이 구성을 최종 1차 설계안으로 추천합니다.
특히 Compute 클러스터가 일반 애플리케이션과 배치를 함께 운영하는 환경이라면, GPU의 드라이버·RDMA·NCCL·스케줄링 정책을 별도 클러스터로 격리하는 장점이 운영 비용 증가보다 클 가능성이 높습니다.
다음 설계 단계에서는 HPE Control Plane 9대의 실제 네트워크 연결, GPU 클러스터의 Kueue/학습 Job 구조, Compute↔GPU 인증과 Job 제출 방식, 세 클러스터의 PodCIDR/BGP/ClusterMesh 주소 설계를 구체화하면 됩니다.
