26S05c

GPU 노드 도입 및 검증 과정에서 클라이언트(엔지니어/운영자 PC) 접근용 UI 포트와, 각 클러스터(Compute/Storage) 간 연동 시 필요한 방화벽 오픈 대상 포트 목록입니다.

1. 클라이언트(운영자/엔지니어 PC) $\rightarrow$ GPU 노드/툴 UI 포트

인수 테스트, vLLM 테스트, 스토리지 점검 시 웹 브라우저나 데스크톱 도구에서 노드로 직접 붙을 때 오픈이 필요한 포트입니다.

포트 / 프로토콜	용도 및 기본 서비스	비고
8000 / TCP	vLLM OpenAI 호환 엔드포인트	Swagger UI (`/docs`) 및 추론 API 테스트 호출
9400 / TCP	NVIDIA DCGM Exporter	GPU 메트릭(온도, 전력, VRAM 사용률 등) 확인
3000 / TCP	Grafana (임시 대시보드 구동 시)	Burn-In 및 리소스 메트릭 모니터링 UI
9001 / TCP	MinIO / AIStor Console (Web UI)	스토리지 웹 관리자 콘솔 접근 (기본 콘솔 포트)
443 / TCP	서버 BMC / IPMI Web GUI	iDRAC/iLO 등 원격 콘솔, 전원 제어, SEL 센서 확인
5900 / TCP	BMC Virtual Console (KVM)	Java/HTML5 KVM 뷰어 화면 연결용

2. GPU 노드 $\leftrightarrow$ Compute / Storage 클러스터 간 방화벽 포트 매트릭스

Case 1. GPU 노드를 기존 K8s 클러스터의 Worker Node로 Join할 때

GPU 노드가 기존 Compute K8s 클러스터의 워커 노드로 합류할 때 필요한 제어 평면 및 CNI 오버레이 통신 포트입니다.

GPU Node $\rightarrow$ K8s Control Plane (출발: GPU, 목적지: 마스터 노드)
6443 / TCP: Kubernetes API Server 통신 (필수)

K8s Control Plane $\rightarrow$ GPU Node (출발: 마스터 노드, 목적지: GPU)
10250 / TCP: Kubelet API (로그 확인 kubectl logs, 파드 exec 등에 필수)

GPU Node $\leftrightarrow$ 기존 Worker Nodes (양방향)
CNI 오버레이 터널링 포트 (사용 CNI에 따라 택1):
8472 / UDP: VXLAN (Cilium / Flannel 기본)
4789 / UDP: Geneve (Calico 기본 오버레이 또는 OVN)
Direct Routing / BGP 모드인 경우: 179 / TCP (BGP Mesh)

Cilium 사용 시 추가 포트 (Cilium CNI 환경인 경우):
4240 / TCP: Cilium Node-to-Node Health Check
4244 / TCP: Hubble Relay / Server 메트릭 통신

30000-32767 / TCP: Kubernetes NodePort 서비스 접근 필요 시

Case 2. GPU Node $\rightarrow$ Storage Cluster (MinIO / AIStor) 연동

모델 가중치 로드, 임베딩 적재, 체크포인트 저장을 위해 GPU 노드가 스토리지 클러스터로 접근할 때 필요한 포트입니다.

GPU Node $\rightarrow$ Storage Cluster 노드들 / VIP (내부망 bond1/E810 경로)
9000 / TCP: AIStor / MinIO S3 API 엔드포인트 (데이터 Get/Put, 모델 다운로드에 필수)
9001 / TCP: AIStor Console UI (브라우저나 관리 도구 접근 시)

(참고) 스토리지가 S3 외에 블록/파일 인터페이스를 병행 제공하는 경우:
2049 / TCP: NFS 마운트 필요 시
3260 / TCP: iSCSI 연결 필요 시

Case 3. Compute Cluster $\rightarrow$ GPU Node 연동 (vLLM 호출 및 추론 파이프라인)

GPU 노드가 K8s에 아직 조인되지 않고 Standalone vLLM 컨테이너로 서빙 중이거나, 별도 파드로 띄운 상태에서 Compute 클러스터의 App/워크플로우가 요청을 보낼 때입니다.

Compute Cluster Nodes / Pods $\rightarrow$ GPU Node (외부망 CX-6 또는 내부망 E810)
8000 / TCP (또는 사용자 지정 포트): vLLM API 엔드포인트 (/v1/chat/completions, /v1/embeddings)
9400 / TCP: Prometheus 스크랩 (Compute 클러스터의 Prometheus/Thanos가 GPU 메트릭을 수집할 경우)
8000 / TCP (또는 /metrics): vLLM 내부 서빙 메트릭 수집 (http://<GPU_IP>:8000/metrics)

Case 4. 기타 연동 및 인프라 필수 포트

DNS & 시각 동기화 (GPU Node $\rightarrow$ 내부 인프라 서버)
53 / UDP, TCP: 사내 내부 DNS 서버 (스토리지/클러스터 도메인 질의용)
123 / UDP: NTP / Chrony 서버 (분산 환경, 토큰 발급, 인증서 검증 시 시간 오차 방지)

인증 및 레지스트리 (GPU Node $\rightarrow$ 내부 플랫폼)
389 / 636 / TCP: 사내 LDAP / LDAPS 인증 연동 (필요 시)
443 / TCP: 사내 프라이빗 컨테이너 레지스트리 (Harbor 등) 및 패키지 미러 서버

로그 및 이벤트 스트리밍 (GPU Node $\rightarrow$ Kafka / 관제)
9092 / 9094 / TCP: Kafka Broker 통신 (추론 로그, 스토리지 이벤트 알림 전송 시)

원격 접근 및 기본 관리
22 / TCP: Bastion/점프 서버 $\rightarrow$ GPU Node SSH

방화벽 정책 수립 시 주의 사항

MTU 9000 적용 대역의 ICMP Type 3 Code 4 허용:
내부망 스토리지(Case 2) 연동 시 점보 프레임을 사용할 경우, 중간 방화벽/L4 장비에서 Path MTU Discovery (PMTUD)를 위한 ICMP("Fragmentation Needed and DF set") 패킷을 차단하면 대용량 가중치 전송 시 세션이 멈추는(Blackhole) 현상이 발생합니다. ICMP 통신은 반드시 열려 있어야 합니다.

비대칭 경로:
Case 3 호출이 ConnectX-6(외부망)으로 인입되고 Case 2 스토리지가 E810(내부망)으로 나가는 환경이므로, 스테이트풀(Stateful) 방화벽을 통과할 때 돌아가는 패킷이 유실되지 않도록 라우팅 테이블(PBR)과 방화벽 인터페이스 매핑을 사전에 일치시켜야 합니다.

===

에어갭(Air-gap) 환경에서는 컨테이너 이미지가 프라이빗 Nexus/Harbor 등으로 캐싱되더라도, 대용량 LLM 모델 가중치(Weights), CUDA/드라이버 오프라인 패키지, Python Wheel 의존성, 벤치마크 바이너리 등은 인터넷 연결망(DMZ/외부 반출입 서버)에서 사전에 온전히 패키징하여 무결성 검증을 거친 뒤 반입해야 합니다.

외부망 다운로드부터 물리적/논리적 망 연계, 내부 AIStor(MinIO) 및 GPU 노드 적재까지의 전체 반입 절차를 5단계로 정리했습니다.

Step 1. 반입 대상 식별 및 패키지 카탈로그 정의

에어갭 내부에서 추가 빌드나 외부 조회가 발생하지 않도록 의존성을 완전히 고립시켜 정의합니다.

LLM 모델 가중치 및 토크나이저 에셋
*.safetensors, config.json, tokenizer.json, tokenizer_config.json, generation_config.json 등 필수 메타데이터 전수 포함.
(주의) 가중치 파일 분할(Sharding) 누락이 없도록 HuggingFace Git LFS/Snapshot 전체 확보.

드라이버 및 런타임 오프라인 아카이브 (Nexus에 없을 경우)
NVIDIA Driver .run 파일, Fabric Manager deb/rpm 패키지, DCGM deb/rpm.
Intel E810 ice 드라이버 및 DDP(Dynamic Device Personalization) 펌웨어 패키지.

추가 Python Wheel 및 벤치마크 바이너리
PyTorch, vLLM 부가 의존성 wheel 파일 (pip download --dest).
iperf3, fio, gpu-burn 빌드 아티팩트, s3-benchmark / warp 바이너리.

Step 2. 외부 다운로드 서버(DMZ/인터넷망) 수집 및 무결성 패키징

외부망 서버에서 스크립트를 통해 온전한 파일 셋을 확보하고 체크섬을 생성합니다.

HuggingFace 공식 CLI 기반 모델 Snapshot 다운로드

심볼릭 링크를 배제하고 실데이터(--local-dir-use-symlinks False)로 완전히 내려받습니다.

pip install -U "huggingface_hub[cli]"

# 토큰 필요 모델(Llama 등) 로그인
huggingface-cli login --token <HF_TOKEN>

# 모델 전체 파일 다운로드
huggingface-cli download meta-llama/Llama-3.1-70B-Instruct \
    --local-dir /export/models/Llama-3.1-70B-Instruct \
    --local-dir-use-symlinks False \
    --exclude "*.bin" "*.pth"  # Safetensors만 반입할 경우 레거시 제외

OS 패키지 및 바이너리 수집

mkdir -p /export/packages
# 예: Ubuntu 기준 의존성 일괄 다운로드
apt-get download $(apt-cache depends --recurse --no-recommends --no-suggests \
    --no-conflicts --no-breaks --no-replaces --no-enhances \
    datacenter-gpu-manager nvidia-fabricmanager-550 | grep "^\w" | sort -u)

체크섬 매니페스트(Manifest) 생성 (무결성 검증 기준점)

반입 도중 파일 깨짐이나 누락을 방지하기 위해 파일별 SHA-256 목록을 생성합니다.

cd /export
find models/ packages/ -type f -exec sha256sum {} + > manifest_sha256.txt

Step 3. 보안 검사 및 망 연계 전송 (반입 파이프라인)

사내 보안 반입 규정에 따라 승인 절차와 악성코드 검사를 수행합니다.

[인터넷망 다운로드 서버]
          │
          ▼
 [안티바이러스 / CDR 검사]  (Pickle 취약점 및 악성 스크립트 스캔)
          │
          ▼
 [망연계 솔루션 / 전용 SFTP / 외장 스토리지]
          │
          ▼
 [에어갭 내부망 인제스천 Bastion]

Safetensors 사전 점검 (보안성)
.bin이나 .pt 같은 Python pickle 기반 가중치는 임의 코드 실행(RCE) 위험이 있어 보안 검사에서 반려되는 경우가 많습니다. 가능한 순수 텐서 직렬화 포맷인 safetensors만 통과시키는 것이 원칙입니다.

망연계 시스템 전송
대용량 파일(단일 100GB 이상) 전송 시 타임아웃 방지를 위해 split -b 20G 형태로 분할하여 전송하거나, 망연계 전용 고속 SFTP/MFT(Managed File Transfer) 채널을 경유합니다.

Step 4. 내부망 도착 후 무결성 검증 및 복원

에어갭 내부 Bastion 또는 데이터 인제스천 노드에서 체크섬을 일괄 대조합니다.

분할 파일 결합 (분할 반입 시)

cat Llama-3.1-70B-Instruct.tar.gz.part* > Llama-3.1-70B-Instruct.tar.gz
tar -xvf Llama-3.1-70B-Instruct.tar.gz

SHA-256 전수 검증

sha256sum -c manifest_sha256.txt

1개 파일이라도 FAILED가 출력되면 모델 로드 시 Silent Data Corruption 또는 Weight 포맷 에러가 발생하므로 재반입해야 합니다.

Step 5. 내부 AIStor(MinIO) 업로드 및 GPU 노드 배포

검증이 끝난 모델을 내부 공용 오브젝트 스토리지(AIStor)에 업로드하고, GPU 노드가 이를 소비할 수 있도록 경로를 표준화합니다.

[내부망 Bastion] 
       │
       │ (mc / s3 API, 내부망 bond1 MTU 9000)
       ▼
[AIStor Cluster (MinIO)]  ── (S3 엔드포인트: 9000)
       │
       │ (E810 내부망 초고속 스트리밍 / 다운로드)
       ▼
[GPU Node: /data/models/ 로컬 NVMe 캐시]
       │
       ▼
[vLLM 컨테이너 바인드 마운트]

AIStor 전용 버킷에 모델 업로드

MinIO Client(mc) 또는 멀티파트 병렬 업로드 도구를 활용해 업로드합니다.

# AIStor 호스트 등록
mc alias set aistor http://<AISTOR_INTERNAL_IP>:9000 <ACCESS_KEY> <SECRET_KEY>

# 버킷 생성 및 병렬 업로드
mc mb --ignore-existing aistor/model-registry
mc cp --recursive /data/models/Llama-3.1-70B-Instruct aistor/model-registry/Llama-3.1-70B-Instruct

GPU 노드에서의 최종 모델 취합 (vLLM 기동 준비)

GPU 노드의 E810(내부망)을 통해 AIStor에서 로컬 고속 NVMe 디스크로 모델을 내려받습니다.

mkdir -p /data/models/Llama-3.1-70B-Instruct

# S3 멀티파트 동시 다운로드
mc cp --recursive aistor/model-registry/Llama-3.1-70B-Instruct/ /data/models/Llama-3.1-70B-Instruct/

다운로드가 완료되면 vLLM 기동 스크립트에서 로컬 디스크 볼륨(-v /data/models:/models)으로 즉시 연결하여 오프라인 서빙을 시작합니다.

에어갭 모델 반입 시 주요 체크리스트

점검 영역	핵심 리스크	예방 및 조치 방안
토크나이저 누락	가중치 파일만 받고 `tokenizer.json` 등 메타데이터를 빠뜨려 vLLM 구동 실패	`snapshot_download`를 써서 리포지토리 루트 전체를 통째로 다운로드
Safetensors vs Bin	보안 정책상 `.bin`(Pickle) 파일 반입 차단	`safetensors` 포맷으로만 수집 (HuggingFace 허브 상에서 safetensors 변환 버전 확보)
전송 중 체크섬 오류	대용량 전송 중 패킷 손상으로 텐서 가중치 깨짐 (추론 시 gibberish 텍스트 출력)	외부에서 생성한 `sha256sum` 매니페스트로 내부 반입 직후 전수 자동 검증
AIStor 디렉터리 구조	S3 Prefix 경로가 어긋나 vLLM 로더가 모델 루트 경로를 찾지 못함	`s3://model-registry/<Model-Name>/` 밑에 설정 파일과 safetensors가 바로 위치하도록 표준화

===

RHEL 10.2 기반 베어메탈 환경 및 에어갭(Air-gap) 제약 조건을 기준으로, 1~5단계 테스트에 필요한 툴들의 설치 방식을 정리했습니다.

RHEL 10 환경에서는 Docker 대신 기본 컨테이너 런타임으로 Podman(및 CDI 기반 NVIDIA Container Toolkit)을 사용하며, 클러스터 합류 후에는 K8s Pod로 배포됩니다.

테스트 단계별 필요 툴 맵핑 요약

단계	주요 필요 툴	주요 역할
Phase 1	`pciutils`, `iproute`, `ethtool`, `numactl`, `ipmitool`, `nvme-cli`, `stress-ng`, `fio`	하드웨어 인식, PCIe 링크, NUMA, 온도, 디스크/메모리 부하
Phase 2	`nvidia-driver`, `nvidia-fabricmanager`, `cuda-samples`, `dcgm`, `gpu-burn`	드라이버/CUDA, NVLink P2P 대역폭, VRAM 무결성, GPU 풀로드 번인
Phase 3	`vllm`, `curl`, `jq`, `netcat(ncat)`	LLM 추론 서빙, REST API 호출, 스트리밍 검증
Phase 4	`iperf3`, `fio`, `minio-client(mc)`, `warp` 또는 `s3-benchmark`	점보프레임 대역폭, S3/NFS I/O 처리량, 가중치 다운로드
Phase 5	`benchmark_serving.py`(vLLM 내장), `k6`, `locust`, `dcgm-exporter`, `prometheus`	TTFT/ITL 벤치마크, 동시성 분산 부하, 메트릭 수집

1. Phase 1: 하드웨어 및 시스템 무결성 점검 툴

이 단계는 하드웨어와 커널 상태를 직접 제어·진단해야 하므로 베어메탈 OS 직접 설치가 원칙입니다.

OS(RHEL 10.2) 기본 Repo 설치 가능 여부:
대부분 RHEL BaseOS / AppStream / EPEL(사내 Nexus 미러)에서 RPM으로 제공됩니다.

설치 방법:
[Bare-metal OS]:

# BaseOS / AppStream 기본 제공
dnf install -y pciutils iproute ethtool numactl ipmitool nvme-cli fio

# stress-ng (EPEL 저장소 필요 -> 사내 Nexus RPM 미러에서 수집)
dnf install -y stress-ng

[Podman Container] (호스트 진단용 컨테이너 실행 시):
호스트의 하드웨어 버스(--privileged, /dev, /sys)를 그대로 마운트해야 합니다.

podman run --rm -it --privileged \
    -v /dev:/dev -v /sys:/sys:ro -v /tmp:/tmp \
    nexus.internal:8082/infra/diag-tools:latest stress-ng --cpu 0 --timeout 60s

[K8s Pod]: Phase 1은 노드 인수 직후 OS 베이스라인 검증이므로 K8s Pod 설치는 부적합합니다. (불가피할 경우 privileged: true, hostPID: true, hostNetwork: true 데몬셋 사용)

2. Phase 2: GPU 드라이버 및 Burn-In 테스트 툴

드라이버와 Fabric Manager는 커널 모듈이므로 베어메탈에 설치해야 하며, 진단/번인 도구는 컨테이너 방식이 권장됩니다.

1) NVIDIA Driver & Fabric Manager

설치 위치: 반드시 Bare-metal OS
다운로드: 외부망에서 RHEL 10 호환 NVIDIA Data Center GPU 드라이버 RPM 또는 .run 파일 반입.
설치 방법:

# 오프라인 반입된 RPM 설치
dnf localinstall -y nvidia-driver-*.rpm nvidia-fabricmanager-*.rpm
systemctl enable --now nvidia-fabricmanager
systemctl enable --now nvidia-persistenced

2) CUDA Samples (`p2pBandwidthLatencyTest`) & DCGM

설치 방법:
[Bare-metal OS]: NVIDIA 공식 CUDA Toolkit / DCGM 오프라인 패키지 반입 후 설치 (dnf localinstall -y datacenter-gpu-manager-*.rpm).
[Podman Container (권장)]:
RHEL 10의 Podman은 CDI(Container Device Interface)를 통해 GPU를 인식합니다.

# P2P 대역폭 측정
podman run --rm --device nvidia.com/gpu=all \
    nexus.internal:8082/nvidia/cuda-sample:vectorAdd-cuda12.5.0 \
    p2pBandwidthLatencyTest

# DCGM 진단
podman run --rm --privileged --device nvidia.com/gpu=all \
    nexus.internal:8082/nvidia/dcgm:latest dcgmi diag -r 3

3) GPU-Burn

다운로드: 외부망에서 wilic/gpu-burn 이미지를 docker save 후 내부 Nexus에 push.
설치 방법:
[Podman Container]:

podman run --rm --device nvidia.com/gpu=all \
    nexus.internal:8082/benchmark/gpu-burn:latest 3600

[K8s Pod (추후 유지보수용)]:

apiVersion: v1
kind: Pod
metadata:
  name: gpu-burn-test
spec:
  restartPolicy: Never
  containers:
  - name: gpu-burn
    image: nexus.internal:8082/benchmark/gpu-burn:latest
    args: ["3600"]
    resources:
      limits:
        nvidia.com/gpu: "8"

3. Phase 3: vLLM 서빙 및 연동 테스트 툴

1) vLLM

OS 직접 설치 여부: 비권장 (PyTorch, FlashAttention, CUDA 라이브러리 간 컴파일 의존성이 복잡하여 RHEL 10 베어메탈 직접 빌드는 실패 위험이 매우 큼). 공식 컨테이너 이미지를 Nexus로 반입해 사용하는 것이 표준입니다.
설치 방법:
[Podman Container (조인 전 독립 구동)]:
RHEL Podman 실행 시 공유 메모리(--ipc=host 또는 --shm-size)와 디바이스 플래그가 중요합니다.

podman run -d --name vllm-server \
    --device nvidia.com/gpu=all \
    --ipc=host \
    --net=host \
    -v /data/models:/models:ro \
    nexus.internal:8082/vllm/vllm-openai:latest \
    --model /models/Llama-3.1-70B-Instruct \
    --tensor-parallel-size 8 \
    --port 8000

[K8s Pod (조인 후 워크로드 구동)]:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-serving
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: vllm
        image: nexus.internal:8082/vllm/vllm-openai:latest
        args: ["--model", "/models/Llama-3.1-70B-Instruct", "--tensor-parallel-size", "8"]
        resources:
          limits:
            nvidia.com/gpu: "8"
        volumeMounts:
        - name: model-cache
          mountPath: /models
        - name: dshm
          mountPath: /dev/shm
      volumes:
      - name: model-cache
        hostPath: { path: /data/models }
      - name: dshm
        emptyDir: { medium: Memory, sizeLimit: 32Gi }

2) 검증 클라이언트 (`curl`, `jq`, `ncat`)

설치 방법:
[Bare-metal OS / Compute Nodes]: RHEL 기본 Repo에서 제공.

dnf install -y curl jq nmap-ncat

[K8s Pod]: Compute 클러스터 디버그 파드로 배포.

kubectl run net-test --image=nexus.internal:8082/tools/curlimages:latest -- sleep 3600

4. Phase 4: 스토리지 네트워크 & I/O 벤치마크 툴

1) iperf3

설치 방법:
[Bare-metal OS]: dnf install -y iperf3 (BaseOS/AppStream 기본 제공).
[Podman Container]: podman run --net=host nexus.internal:8082/network/iperf3:latest -c <IP> -P 8
[K8s Pod]: Compute 노드와 GPU 노드에 HostNetwork 기반 파드로 배포하여 Pod 간 네트워크 병목 측정.

2) MinIO Client (`mc`) & Warp (또는 s3-benchmark)

OS 기본 제공 여부: RHEL 기본 Repo에 없음. 외부에서 단일 바이너리(Go compile standalone)를 다운로드하여 에어갭으로 반입.
설치 방법:
[Bare-metal OS]:

# 반입된 바이너리에 실행 권한 부여 후 /usr/local/bin에 배치
install -m 755 mc /usr/local/bin/mc
install -m 755 warp /usr/local/bin/warp

[Podman Container]:

podman run --rm --net=host \
    -v /data/models:/data \
    nexus.internal:8082/minio/mc:latest \
    cp --recursive aistor/model-registry/Llama-3.1-70B-Instruct/ /data/

5. Phase 5: 성능 및 부하 테스트 툴

1) vLLM 내장 벤치마크 도구 (`benchmark_serving.py`)

다운로드: vLLM 컨테이너 이미지 내부 /workspace/vllm/benchmarks/ 또는 vLLM 패키지에 포함되어 있으므로 별도 설치 불필요.
실행 방법:
[Podman Container]: 이미 실행 중인 vLLM 파드/컨테이너에 exec로 들어가거나, 동일 이미지를 띄워 실행.

podman exec -it vllm-server python3 -m vllm.entrypoints.openai.benchmark_serving \
    --backend vllm \
    --model /models/Llama-3.1-70B-Instruct \
    --dataset-path /data/ShareGPT_V3_unfiltered_cleaned_split.json \
    --request-rate 10

2) k6 / Locust (Compute Cluster $\rightarrow$ GPU 부하 생성기)

다운로드: 외부망에서 공식 바이너리(k6) 또는 도커 이미지(k6, locust)를 내부 Nexus로 반입.
설치 방법:
[Bare-metal / Bastion]: k6 독립 실행 바이너리를 반입하여 /usr/local/bin/k6로 복사.
[K8s Pod (분산 부하 권장)]: Compute 클러스터에서 부하 인스턴스를 수십 개로 분산할 때 가장 적합.

apiVersion: batch/v1
kind: Job
metadata:
  name: k6-loadtest
spec:
  parallelism: 4     # 4개 파드에서 동시 타격
  template:
    spec:
      containers:
      - name: k6
        image: nexus.internal:8082/loadtest/k6:latest
        command: ["k6", "run", "/scripts/vllm_load.js"]
        volumeMounts:
        - name: script-vol
          mountPath: /scripts
      volumes:
      - name: script-vol
        configMap: { name: k6-test-script }
      restartPolicy: Never

3) DCGM Exporter

설치 방법:
[Bare-metal OS]: RPM 설치 후 Systemd 서비스로 구동 (systemctl start nvidia-dcgm-exporter).
[Podman Container]:

podman run -d --name dcgm-exporter \
    --device nvidia.com/gpu=all \
    --net=host \
    nexus.internal:8082/nvidia/k8s-device-plugin/dcgm-exporter:latest

[K8s Pod]: 노드 조인 후 K8s GPU Operator 또는 DaemonSet 형태로 배포 (port: 9400).

배포 형태별 빠른 권장 가이드

Bare-metal OS 설치 필수: NVIDIA Driver, Fabric Manager, 커널 유틸(ethtool, ip, numactl), 로컬 벤치마크 바이너리(mc, warp).
Podman Container 실행 권장 (Phase 1~4 인수 단계): p2pBandwidthLatencyTest, gpu-burn, vllm(초기 단독 검증).
K8s Pod 실행 권장 (Compute 연동 및 Phase 5 단계): 부하 생성기(k6/locust), K8s 조인 후의 정규 vLLM 서빙 파드, dcgm-exporter.

Young-Kyoo Kim

engineer

이전 포스트

26S05b

다음 포스트

26S05c

1. 클라이언트(운영자/엔지니어 PC) $\rightarrow$ GPU 노드/툴 UI 포트

2. GPU 노드 $\leftrightarrow$ Compute / Storage 클러스터 간 방화벽 포트 매트릭스

Case 1. GPU 노드를 기존 K8s 클러스터의 Worker Node로 Join할 때

Case 2. GPU Node $\rightarrow$ Storage Cluster (MinIO / AIStor) 연동

Case 3. Compute Cluster $\rightarrow$ GPU Node 연동 (vLLM 호출 및 추론 파이프라인)

Case 4. 기타 연동 및 인프라 필수 포트

방화벽 정책 수립 시 주의 사항

Step 1. 반입 대상 식별 및 패키지 카탈로그 정의

Step 2. 외부 다운로드 서버(DMZ/인터넷망) 수집 및 무결성 패키징

Step 3. 보안 검사 및 망 연계 전송 (반입 파이프라인)

Step 4. 내부망 도착 후 무결성 검증 및 복원

Step 5. 내부 AIStor(MinIO) 업로드 및 GPU 노드 배포

에어갭 모델 반입 시 주요 체크리스트

테스트 단계별 필요 툴 맵핑 요약

1. Phase 1: 하드웨어 및 시스템 무결성 점검 툴

2. Phase 2: GPU 드라이버 및 Burn-In 테스트 툴

1) NVIDIA Driver & Fabric Manager

2) CUDA Samples (`p2pBandwidthLatencyTest`) & DCGM

3) GPU-Burn

3. Phase 3: vLLM 서빙 및 연동 테스트 툴

1) vLLM

2) 검증 클라이언트 (`curl`, `jq`, `ncat`)

4. Phase 4: 스토리지 네트워크 & I/O 벤치마크 툴

1) iperf3

2) MinIO Client (`mc`) & Warp (또는 s3-benchmark)

5. Phase 5: 성능 및 부하 테스트 툴

1) vLLM 내장 벤치마크 도구 (`benchmark_serving.py`)

2) k6 / Locust (Compute Cluster $\rightarrow$ GPU 부하 생성기)

3) DCGM Exporter

배포 형태별 빠른 권장 가이드

26S05b

26S05d

0개의 댓글

26S05c

1. 클라이언트(운영자/엔지니어 PC) →\rightarrow→ GPU 노드/툴 UI 포트

2. GPU 노드 ↔\leftrightarrow↔ Compute / Storage 클러스터 간 방화벽 포트 매트릭스

Case 1. GPU 노드를 기존 K8s 클러스터의 Worker Node로 Join할 때

Case 2. GPU Node →\rightarrow→ Storage Cluster (MinIO / AIStor) 연동

Case 3. Compute Cluster →\rightarrow→ GPU Node 연동 (vLLM 호출 및 추론 파이프라인)

Case 4. 기타 연동 및 인프라 필수 포트

방화벽 정책 수립 시 주의 사항

Step 1. 반입 대상 식별 및 패키지 카탈로그 정의

Step 2. 외부 다운로드 서버(DMZ/인터넷망) 수집 및 무결성 패키징

Step 3. 보안 검사 및 망 연계 전송 (반입 파이프라인)

Step 4. 내부망 도착 후 무결성 검증 및 복원

Step 5. 내부 AIStor(MinIO) 업로드 및 GPU 노드 배포

에어갭 모델 반입 시 주요 체크리스트

테스트 단계별 필요 툴 맵핑 요약

1. Phase 1: 하드웨어 및 시스템 무결성 점검 툴

2. Phase 2: GPU 드라이버 및 Burn-In 테스트 툴

1) NVIDIA Driver & Fabric Manager

2) CUDA Samples (p2pBandwidthLatencyTest) & DCGM

3) GPU-Burn

3. Phase 3: vLLM 서빙 및 연동 테스트 툴

1) vLLM

2) 검증 클라이언트 (curl, jq, ncat)

4. Phase 4: 스토리지 네트워크 & I/O 벤치마크 툴

1) iperf3

2) MinIO Client (mc) & Warp (또는 s3-benchmark)

5. Phase 5: 성능 및 부하 테스트 툴

1) vLLM 내장 벤치마크 도구 (benchmark_serving.py)

2) k6 / Locust (Compute Cluster →\rightarrow→ GPU 부하 생성기)

3) DCGM Exporter

배포 형태별 빠른 권장 가이드

26S05b

26S05d

0개의 댓글

1. 클라이언트(운영자/엔지니어 PC) $\rightarrow$ GPU 노드/툴 UI 포트

2. GPU 노드 $\leftrightarrow$ Compute / Storage 클러스터 간 방화벽 포트 매트릭스

Case 2. GPU Node $\rightarrow$ Storage Cluster (MinIO / AIStor) 연동

Case 3. Compute Cluster $\rightarrow$ GPU Node 연동 (vLLM 호출 및 추론 파이프라인)

2) CUDA Samples (`p2pBandwidthLatencyTest`) & DCGM

2) 검증 클라이언트 (`curl`, `jq`, `ncat`)

2) MinIO Client (`mc`) & Warp (또는 s3-benchmark)

1) vLLM 내장 벤치마크 도구 (`benchmark_serving.py`)

2) k6 / Locust (Compute Cluster $\rightarrow$ GPU 부하 생성기)