대규모 베어메탈 환경에서 Dual-Socket 이상 Intel Xeon(Sapphire Rapids/Emerald Rapids 등) 프로세서를 기반으로 Cilium Native Routing, 고성능 분산 스토리지(MinIO AIStor), 그리고 연산 엔진(StarRocks, Spark)을 구동할 때 UPI(Ultra Path Interconnect) 버...

네. 이 환경에서는 “NUMA를 잘 쓰는 서버 설정”보다 “NUMA를 Kubernetes resource allocation → NIC/Storage locality → application process/thread locality까지 일관되게 연결하는 것”이 핵심입니다. 특히 현재 환경처럼 Xeon + 다중 NUMA + K8s + Cilium nati...

RHEL 10.2 + Kubespray K8s 클러스터 NUMA 최적화 전략 대상 환경 요약 OS: RHEL 10.2 (Intel Xeon, 멀티소켓 = 멀티 NUMA) 배포: Kubespray CNI: Cilium (Native Routing, BGP, ECMP, ClusterMesh) Storage: MinIO AIStor, OpenEBS DB/Run...

SFTPGo Pod 배포 & AIStor(S3) 연동 구성 가이드 0. 아키텍처 개요 및 핵심 결정사항 먼저 결정해야 할 것 3가지 FTP passive mode 노출 방식: FTP는 제어 채널(21) 외에 데이터 채널을 매번 별도 포트로 협상합니다(passive mode). 쿠버네티스에서는 이 포트 range를 그대로 열어줘야 하므로, 일반 Clus...

네. SFTPGo를 MinIO AIStor 앞단의 FTP/FTPS/SFTP Gateway로 두는 방식은 꽤 괜찮은 아키텍처라고 봅니다. 특히 지금 말씀하신 것처럼 기존 클라이언트가 S3 API가 아니라 FTP 계열로 파일을 올려야 하는 요구라면, AIStor 자체에 FTP 기능을 억지로 붙이는 것보다 SFTPGo를 별도 계층으로 두는 게 훨씬 깔끔합니다. ...

네. 가능합니다. 오히려 지금 말씀하신 구조라면 private network가 구축되기 전에 RDMA 사전 검증을 해보는 것이 꽤 좋은 방법입니다. 다만 핵심은 “L3 routing이 가능하냐”가 아니라, RoCEv2가 그 L3 구간을 통과하도록 구성되어 있고 중간 스위치/라우터가 RDMA QoS를 제대로 보장하느냐입니다. 결론부터 현재 구조가 예를 ...

네. 지금 상황이라면 “GPU node를 당장 기존 Compute Cluster에 join시키는 것”을 1차 목표로 잡지 않는 것이 좋습니다. 오히려 GPU node 단독 검증 → GPU SW stack 검증 → 외부망을 통한 Compute 연동 → Private망 개통 후 K8s 편입 → Storage/RDMA → E2E 성능 순으로 가는 것이 리스크가 ...

GPU Node 온보딩 & 클러스터 연동 계획 0. 현황 정리 및 전제 | 구분 | 내용 | |---|---| | GPU Node NIC | ConnectX-6 (외부망), Intel E810 (private망 예정, 미구성) | | 기존 Compute Cluster | bond1(내부망)로 연결 | | 기존 Storage Cluster | bond1(...

vLLM 서빙에서 Throughput(전체 처리량)과 TTFT(첫 토큰 지연 시간)는 트레이드오프 관계를 가집니다. 대규모 배치 처리는 Throughput을 극대화하지만 긴 Prefill 연산으로 인해 기존 요청의 ITL과 신규 요청의 TTFT를 저하시킵니다. 워크로드 특성(RAG 기반 무거운 프롬프트 vs 실시간 대화형 서비스)에 맞춘 핵심 엔진 파라미...

GPU 노드 도입 및 검증 과정에서 클라이언트(엔지니어/운영자 PC) 접근용 UI 포트와, 각 클러스터(Compute/Storage) 간 연동 시 필요한 방화벽 오픈 대상 포트 목록입니다. 1. 클라이언트(운영자/엔지니어 PC) $\rightarrow$ GPU 노드/툴 UI 포트 인수 테스트, vLLM 테스트, 스토리지 점검 시 웹 브라우저나 데스크톱 ...

앞서 정리한 1~4단계 점검 및 테스트 과정을 현장에서 바로 실행할 수 있도록 단계별 Bash 스크립트로 분리하여 작성했습니다. 실행 환경에 맞게 스크립트 상단의 변수(CX6IFACE, E810IFACE, STORAGE_IP 등)만 지정해 사용하시면 됩니다. Phase 1: 하드웨어 및 OS 무결성 점검 스크립트 (phase1hwcheck.sh) Ph...

기존 클러스터 노드들과 마찬가지로 외부망과 내부망이 모두 존재하는 환경에서, GPU 노드 인수 직후 OS/플랫폼 팀이 수행해야 할 1단계(HW 무결성 및 시스템 점검)의 상세 실행 절차입니다. 특히 GPU 노드는 고전력 소모, 복잡한 PCIe/NUMA 토폴로지, 그리고 고속 NIC(ConnectX-6 + Intel E810)가 혼재되어 있으므로 초기 HW...

#!/usr/bin/env bash set -euo pipefail PATTERN="${1:-}" if [ -z "$PATTERN" ]; then echo "사용법: $0 " echo "예시: $0 starrocks" exit 1 fi echo "검색 패턴: '$PATTERN'" echo "클러스터 파드 정보 수집 및 분석 중..." ...

노드별 파드 개수와 할당량(Allocatable) 대비 사용률을 확인하는 Bash 원라이너 및 상세 스크립트입니다. Succeeded나 Failed 상태인 완료된 파드는 제외하고 실제 러닝 중인 워크로드만 집계합니다. 1. 터미널 즉시 실행용 원라이너 (jq 기반) 출력 결과: 2. 노드별 파드 수 + Allocatable 용량 + 사용률 요약 스크립...

Kubernetes 리소스 단위(코어 m, 메모리 Gi/Mi/Ki)를 정규화한 뒤, (Request / Limit) * 100을 계산하여 반올림한 비율별로 카운트하는 스크립트입니다. Bash와 Python(추천, 부동소수점 및 단위 변환 처리가 안정적) 중 환경에 맞는 방식을 선택해 실행할 수 있습니다. Python 인라인 스크립트 (가장 정확하고 편리...

kubectl과 jq를 사용해 특정 Pod 이름 문자열을 필터링하고 리소스(CPU 또는 메모리) 조건에 맞는 개수를 집계하는 명령어입니다. CPU 기준 집계 명령어 (단일 컨테이너 기준) 특정 네임스페이스(-n ) 또는 전체 클러스터(-A)에서 Pod 이름에 특정 문자열(YOURPODNAME_KEYWORD)이 포함된 대상을 집계합니다. 메모리(Gi 단...

대규모 클러스터(128대 이상) 환경에서 kubectl describe를 쓰면 속도가 매우 느리므로, kubectl의 JSON 출력을 파싱하거나 Kubernetes API를 직접 호출해 노드 Allocatable 대비 Pod CPU Requests 합산치, 할당률(%), 잔여 Core를 산출하는 Python 스크립트와 경량 Bash 스크립트입니다. Pyt...

{ "annotations": { "list": [] }, "editable": true, "fiscalYearStartMonth": 0, "graphTooltip": 1, "id": null, "links": [], "liveNow": false, "panels": [ { "collapsed": f...

{ "annotations": { "list": [] }, "editable": true, "fiscalYearStartMonth": 0, "graphTooltip": 1, "id": null, "links": [], "liveNow": false, "panels": [ { "collapsed": f...

{ "annotations": { "list": [ { "builtIn": 1, "datasource": { "type": "datasource", "uid": "grafana" }, "enable": true, "hide": t...