IT블로그(2021-09-13 ~ )

VAST Fundementals(101) - VAST API

의그 — Sun, 2 Aug 2026 19:48:57 +0900

1. VAST는 API-first 구조

VAST는 API-first architecture로 설계되어 있어.

즉, 클러스터의 관리 기능이 먼저 REST API 형태로 제공되고, VMS GUI와 CLI도 내부적으로 동일한 핵심 관리 기능을 사용한다고 이해하면 돼.

VMS GUI ─┐
CLI     ─┼─→ VAST 관리 기능/API ─→ VAST Cluster
REST API ┘

따라서 다음 세 가지 방식으로 같은 종류의 작업을 수행할 수 있어.

VMS GUI: 사람이 웹 화면에서 조작
CLI: 터미널에서 명령어로 조작
REST API: 스크립트나 외부 시스템에서 프로그램 방식으로 조작

예를 들어 View 생성, 사용자 관리, Quota 설정, 정책 구성 등의 기능을 GUI에서 수동으로 하거나 API로 자동화할 수 있다는 뜻이야.

2. VAST RESTful API란?

VAST RESTful API는 프로그램이나 스크립트가 HTTP 요청을 통해 VAST 클러스터를 조회하고 관리할 수 있도록 제공되는 인터페이스야.

일반적인 REST API 방식은 다음과 같아.

GET: 정보 조회
POST: 새 리소스 생성
PATCH 또는 PUT: 기존 설정 수정
DELETE: 리소스 삭제

예를 들면 개념적으로 다음과 같은 작업이 가능해.

GET    → View 목록 조회
POST   → 새로운 View 생성
PATCH  → Quota 값 변경
DELETE → 불필요한 정책 삭제

API를 사용하면 사람이 VMS GUI에서 반복 클릭하지 않아도 프로그램이 같은 작업을 수행할 수 있어.

3. API를 사용하는 주요 목적

교육 자료에서는 API 활용 목적을 세 가지로 구분하고 있어.

① Streamlining Routine Tasks

반복적인 관리 작업 자동화

사용자 생성, Quota 할당, Policy 적용 같은 반복 작업을 스크립트로 자동화하는 것이야.

예를 들어 신규 사용자 100명에게 다음 작업이 필요하다고 해보자.

사용자 계정 생성
→ 역할 할당
→ Quota 설정
→ 접근 권한 적용

GUI에서는 100번 반복해야 하지만, API 스크립트로는 사용자 목록을 읽어 일괄 처리할 수 있어.

장점

반복 작업 시간 절감
입력 실수 감소
사용자마다 동일한 정책 적용
규모가 커져도 쉽게 관리

예시

조직에서 모든 AI 연구원에게 다음 기준을 적용한다고 가정할 수 있어.

Role: AI-Researcher
Quota: 10 TB
Permission: AI Dataset Read/Write

API 스크립트는 신규 사용자 정보를 받아 이 설정을 자동으로 적용할 수 있어.

② Customizing Workflows

조직에 맞는 업무 흐름 구성

VAST를 Service Desk, 자동화 플랫폼, 모니터링 시스템 또는 사내 포털과 연동하는 용도야.

예를 들어 개발자가 사내 셀프서비스 포털에서 스토리지를 요청하는 상황을 생각해 보면 돼.

개발자가 포털에서 스토리지 요청
→ 관리자 승인
→ 자동화 시스템이 VAST API 호출
→ View 또는 스토리지 리소스 생성
→ Quota와 권한 적용
→ 요청자에게 결과 전달

이 방식에서는 개발자가 VMS에 직접 접속할 필요가 없어.

연동 가능한 시스템 예

ServiceNow 같은 ITSM
Ansible 등의 자동화 도구
사내 셀프서비스 포털
Kubernetes 또는 VM 프로비저닝 시스템
모니터링·알림 시스템

즉, VAST를 기존 업무 프로세스 안에 넣을 수 있다는 의미야.

③ Enhancing Reporting and Analytics

맞춤형 보고서 및 분석

VMS에도 기본적인 Capacity와 Analytics 기능이 있지만, API를 사용하면 필요한 데이터를 직접 수집해 조직 전용 보고서를 만들 수 있어.

수집할 수 있는 데이터의 예는 다음과 같아.

클러스터 용량 사용량
Tenant·부서·프로젝트별 사용량
Bandwidth, IOPS, Latency 같은 성능 지표
사용자 활동
워크로드별 성능 추세
비용 배분용 데이터

예시: 부서별 스토리지 비용 계산

VAST API로 부서별 사용 용량 수집
→ 회사의 TB당 비용 계산식 적용
→ 부서별 비용 보고서 생성
→ 매월 자동 배포

예를 들어:

부서사용량TB당 단가산정 비용

AI 연구팀	200 TB	10만 원	2,000만 원
개발팀	80 TB	10만 원	800만 원
백업팀	120 TB	10만 원	1,200만 원

이런 데이터를 BI 도구와 결합해 전사 리포트에 포함할 수도 있어.

4. API 사용의 핵심 장점

정리하면 다음과 같아.

장점설명

자동화	반복적인 사용자·Quota·Policy 작업 자동 처리
일관성	동일한 설정을 누락 없이 반복 적용
오류 감소	수동 입력이나 클릭 과정에서 발생하는 실수 방지
확장성	사용자나 Tenant 수가 늘어도 대량 처리 가능
시스템 통합	ITSM, 포털, 모니터링, 자동화 시스템과 연동
맞춤 분석	필요한 지표를 수집해 전용 보고서 생성

5. VAST API Documentation

API를 사용하려면 각 API Endpoint의 사용법을 알아야 해.

API 문서에는 보통 다음 정보가 들어 있어.

Endpoint URL
HTTP Method
필요한 Parameter
Request Body 형식
인증 방법
Response 형식
상태 코드
실행 예시

예를 들어 개념적으로 다음처럼 표시될 수 있어.

GET /api/views/

의미:

클러스터에 생성된 View 목록을 조회한다.

또는:

POST /api/views/

의미:

새로운 View를 생성한다.

정확한 URL과 Payload 구조는 설치된 VAST 버전의 Swagger 문서에서 확인해야 해.

6. Swagger UI란?

VAST는 API 문서를 보여주기 위해 Swagger UI를 사용해.

Swagger UI는 브라우저에서 다음 작업을 할 수 있는 인터랙티브 API 문서야.

사용 가능한 API Endpoint 검색
각 Endpoint의 목적 확인
필수 및 선택 Parameter 확인
Request Body 형식 확인
Response 예제 확인
브라우저에서 API 호출 시험

즉, 단순 설명서가 아니라 실제 API를 탐색하고 테스트할 수 있는 화면이야.

7. API 문서 접속 방법

현재 사용하는 VMS URL 뒤에 /docs/를 붙이면 돼.

https://<VMS_VIP>/docs/

예를 들어 VMS 관리 VIP가 다음과 같다면:

https://192.168.100.50

API 문서는:

https://192.168.100.50/docs/

로 접속해.

여기서 <VMS_VIP>는 클러스터 설치 시 지정한 Management VIP야.

즉:

VMS GUI 접속: https://<VMS_VIP>/
Swagger API 문서: https://<VMS_VIP>/docs/

이 내용은 앞에서 질문한 **“VMS 웹페이지 IP가 어느 IP인가?”**에 대한 정확한 연결이기도 해. VMS 접속에 사용하는 주소는 설치 시 지정된 **관리용 VIP(Management VIP)**이고, 그 주소 뒤에 /docs/를 붙이면 API 문서가 열려.

8. 실제 활용 흐름

API 자동화는 일반적으로 다음 순서로 진행돼.

https://<VMS_VIP>/docs/ 접속
필요한 API Endpoint 검색
Request Method와 Parameter 확인
인증 방법 확인
Swagger에서 시험 호출
curl 또는 Python으로 스크립트 작성
오류 처리와 결과 검증 추가
운영 자동화 시스템에 연동

개념적인 curl 호출 형태는 다음과 같아.

curl -k \
  -H "Authorization: Bearer <TOKEN>" \
  "https://<VMS_VIP>/api/<endpoint>/"

다만 인증 Header와 실제 Endpoint는 VAST 버전 및 인증 구성에 따라 다를 수 있으므로 반드시 해당 클러스터의 /docs/를 기준으로 작성해야 해.

핵심 정리

VAST는 API-first 구조이므로 GUI, CLI, REST API가 같은 핵심 관리 기능을 제공한다.

REST API를 사용하면:

반복적인 사용자·Quota·Policy 관리 작업을 자동화하고
ServiceNow나 사내 포털 같은 외부 시스템과 연동하며
용량·성능·사용자 활동 데이터를 수집해 맞춤형 분석 보고서를 만들 수 있어.

그리고 API 문서는 다음 주소에서 확인해.

https://<VMS Management VIP>/docs/

VAST Fundementals(101) - Snapshots & Replication

의그 — Sun, 2 Aug 2026 19:48:38 +0900

VAST Data Platform 복제(Replication) 요약

VAST의 복제는 스냅샷 기반 비동기 복제 방식입니다. 운영 데이터의 모든 쓰기 작업을 실시간으로 전송하는 것이 아니라, 특정 시점의 스냅샷을 생성한 뒤 변경된 데이터만 원격 VAST 클러스터로 전송합니다.

핵심 특징

스냅샷 기반
- 원본 클러스터에서 특정 시점의 데이터 상태를 스냅샷으로 생성합니다.
- VAST는 Write-in-Free-Space 방식을 사용하므로 스냅샷 생성 시 성능 영향이 작고 별도의 사전 공간 할당이 필요하지 않습니다.
비동기 복제
- 데이터가 실시간으로 복제되는 것이 아니라, 설정된 일정에 따라 주기적으로 복제됩니다.
- 따라서 장애 발생 시 마지막 복제 시점 이후의 데이터는 손실될 수 있으며, 복제 주기가 사실상 RPO에 영향을 줍니다.
Restore Point 생성
- 원본 클러스터의 스냅샷이 대상 클러스터로 전송되어 저장되면 이를 Restore Point라고 합니다.
- 장애 발생 시 이 Restore Point를 기준으로 데이터를 복구할 수 있습니다.
변경 데이터만 전송
- 매번 전체 데이터를 복사하지 않고, 이전 스냅샷 이후 변경된 데이터만 추적하여 전송합니다.
- 대규모 데이터셋에서도 네트워크 대역폭과 복제 시간을 줄일 수 있습니다.
Protection Policy로 일정 관리
- 관리자는 Protection Policy를 통해 스냅샷 생성 주기, 복제 주기, 보존 정책 등을 정의할 수 있습니다.
다양한 복제 구성
- 1:1: 하나의 원본 클러스터에서 하나의 대상 클러스터로 복제
- 1:N: 하나의 원본에서 여러 대상 클러스터로 복제
- N:1: 여러 원본 클러스터의 데이터를 하나의 중앙 클러스터로 복제
원격 재해 복구 지원
- 대상 클러스터를 다른 지역이나 데이터센터에 배치할 수 있어, 사이트 전체 장애에 대비한 재해 복구 구성이 가능합니다.

한 문장 정리

VAST Replication은 원본 데이터의 스냅샷을 주기적으로 생성하고, 변경된 데이터만 원격 클러스터에 전송하여 Restore Point를 만드는 효율적인 비동기 재해 복구 방식입니다.

트랜시버 종류(SFP, QSFP, OSFP / CSFP), 방열구조 차이, 광모듈 전송 거리와 광 방식(SR, DR, FR), 광케이블 종류(LC, SC, MPO / UPC, APC) 등

의그 — Mon, 27 Jul 2026 08:21:02 +0900

1. SFP(Small Form-factor Pluggable, 1개 lane)

SFP : 1G

SFP+ : 10G

SFP28 : 25G

SFP56 : 50G

2. QSFP(Quad SFP, 4개 lane)

QSFP : 40G(10Gx4)

QSFP28 : 100G

QSFP56 : 200G

QSFP112 : 400G

3. OSFP(Octal SFP, 8lane, QSP보다 크고 발열 처리 좋음)

OSFP 400G : 8 x 50G

OSFP 800G : 8 x 100G

OSFP 1.6T : 8 x 200G

4. Compact SFP : SFP 크기의 공간에서 2개의 독립적인 광 채널을 처리할 수 있게 만든 트랜시버 폼팩터

SFP는 보통 한 포트에 한 링크, CSFP는 한 모듈 안에 두 Channel이 들어감 -> 같은 장비 전면 공간에서 포트 밀도 2배 높이는 용도로 쓰임. 통신사 액세스망, Metro Ethernet, FTTx 계열에서 자주 사용. BiDi(Bidirectional) 방식과 자주 결합됨. 한 가닥의 fiber에서 송신/수신 파장을 다르게 써서 양방향 통신하는 방식.

-----

OSFP / QSFP 트랜시버의 방열(heatsink) 구조 차이

1. Flat-top(평평한 타입)

- 위가 완전히 평평, 히트싱크 구조 없거나 매우 낮음

- 장점 : 공기 흐름 방해 적음, 밀집도 높음

- 단점 : 방열 성능 낮음

- 저전력 모듈(10G, 25G, 일부 100G 등)에 사용

2. Finned-top(방열핀 타입)

- 위에 핀(fin) 구조 있음. 표면적이 증가 -> 냉각 효율 증가

- 장점 : 발열 처리 가장 좋음, 고속(400G, 800G) 안정성 높음

- 단점 : 공기 흐름 설계 영향 받음, 포트 밀집도 약간 제한

3. Closed-top(덮개형)

- 위가 막혀있고 내부 방열 구조 있음. 공기 흐름을 강제로 유도(duct 역할)

- 장점 : airflow control 가능, 특정 방향 cooling 최적화

- 단점 : 설계 의존적(장비 airflow와 맞아야 함)

-----

SR / DR / FR - 광모듈의 전송 거리와 광 방식을 구분하는 이름

SR : Short Range(짧은 거리, 보통 MMF)

- TX 4 lane(보내기) + RX 4 lane(받기) - 총 8 fiber 사용

- 보통 MPO-12 케이블 사용, 그 중 8개만 실제 사용

- 보통 MMF, 850nm, 짧은 거리

DR : Data Center Reach(약 500m, 보통 SMF)

- 보통 SMF, 1310nm, 더 긴 거리

FR : Fiber Reach(약 2km, 보통 SMF)

- DR vs FR

400G DR4는 4개의 lane을 각각 별도 fiber로 전송 / 400G FR4는 WDM으로 4개의 lane을 multiplexing하여 1lane으로 합침(RX 1 fiber + TX 1 fiber). 보통 LC Duplex 씀.

-----

광케이블 분류

# 커넥터 형태에 따른 분류

1. LC(Lucent Connector) : 데이터센터에서 가장 흔히 보는 소형 광커넥터

- Ferrule 직경: 1.25mm(크기 작음), 포트 밀도 높이기 좋음

- RJ45처럼 작은 latch가 있음.

- SFP/SFP+/SFP28/QSFP 계열 광모듈에서 흔함

2. SC(Subscriber Connector / Standard Connector) : LC보다 큰 사각형 커넥터

- Ferrule : 2.5mm, Push-Pull방식, 통신사/FTTH/ODF/패치패널 등에서 많이 사용

3. ST(Straight Tip) : 예전 LAN이나 광통신 장비 사용

- 둥근 형태이고 돌려서 잠그는 Bayonet 방식

- 요새 거의 쓰이지 않음

4. FC(Ferrule Connector) : 나사 방식으로 돌려서 체결

- 진동에 강함, 매우 안정적으로 고정, 측정장비/실험실/통신 측정 환경에 사용, 요새 DC환경에서 거의 쓰이지 않음

5. MPO / MTP

- LC/SC가 1fiber를 연결하는 것과 달리, 여러 fiber를 한 번에 연결함

- MTP는 MPO의 한 종류이자 상표명(US Conec의 제품군)

** MPO Polarity 종류

1. Type A - Straight Through

MPO-12 기준으로, A사이드로 B사이드 모두 1번은 1번끼리 ~ 12번은 12번끼리 연결

2. Type B - 전체 Reverse

A사이드 1번-B사이드 12번 ~ A사이드 12번-B사이드 1번 연결

(A사이드 TX-B사이드RX, TX<->RX가 자동으로 맞는 구조)

3. Type C - Pair Flip

전체를 뒤집는 게 아니라, 2가닥씩 pair를 바꿈.

A사이드 2번-B사이드 1번, A사이드 3번-B사이드 4번, ~, A사이드 12번-B사이드 11

Side A Side B

1 ───────────── 2

2 ───────────── 1

3 ───────────── 4

4 ───────────── 3

5 ───────────── 6

6 ───────────── 5

7 ───────────── 8

8 ───────────── 7

9 ───────────── 10

10 ──────────── 9

11 ──────────── 12

12 ──────────── 11

** Guide pin 유무에 따른 MPO케이블 분류

MPO Male : Guide Pin 있음(트랜시버 측에 Pin hole인 경우)

MPO Female : Pin hole 있음(트랜시버 측에 guide pin이 있는 경우)

# 끝단 연마 방법(광커넥터 안의 유리 끝부분인 Ferrule을 어떻게 연마했느냐)에 따른 분류

1. PC(Physical Contact polish) : 초기의 평평한 ferrule보다 끝을 약간 둥글게 만들어 두 fiber core가 잘 밀착하도록 한 방식(요새는 UPC가 PC를 대체함)

2. UPC(Ultra Physical Contact) : PC를 더 정밀하게 연마한 방식. 보통 파란색 커넥터. 끝단이 거의 수직으로 맞닿고 표면이 매우 매끄러움.

3. APC(Angled Physical Contact) : 끝단을 약 8도 기울여서 연마함. 광이 반사될 떄 그대로 광원쪽으로 돌아오지 않고 옆으로 빠지게 하기 위해. Return Loss가 훨씬 좋다. 주로 초록색 커넥터.

# Simplex / Duplex에 따른 분류

Simplex : Fiber 한 가닥, BiDi(양방향 송수신) 방식에서 사용.

Duplex : Fiber 두 가닥(TX 1가닥, RX 1가닥)

# SMF / MMF에 따른 분류

1. SMF : Single Mode Fiber

- OS1, OS2 등

- 1310nm, 1550nm 등, 장거리용, 노란색 jacket 주로 사용

- 코어가 가늘어서 빛이 하나의 모드로 진행함

2. MMF : Multi Mode Fiber

- OM3, OM4, OM5 등

- 주로 850nm, 단거리용

- 코어가 굵어서 빛이 여러 경로로 동시에 진행

예) LC/UPC Duplex OS2 -> 커넥터 타입 LC, Polish타입 UPC, fiber 2가닥, fiber타입 Single Mode

VAST Fundementals(101) - Security & User Management

의그 — Sat, 18 Jul 2026 11:40:08 +0900

VAST에서는 크게 3개의 역할이 있다

1. Active Directory, LDAP, NIS

▼

2. Identity Provider

▼

3. Vast Cluster : Administrator(관리자), VMS(GUI), Users(일반 사용자), NFS/SMB/S3로 데이터 접근

Provider → 사용자 정보를 제공
Administrator → VAST를 관리
User → 데이터를 사용

1. Security & User Management

"multi-layered access control"

즉, 권한을 한 가지만 보는 것이 아니라 여러 단계에서 검사한다.

예) 사용자 로그인 -> AD 인증 -> Group 확인 -> View Policy 확인 -> Security Flavor 확인 -> 파일 권한 확인 -> 접근 허용

외부 Identity Provider 사용

VAST는 사용자를 직접 많이 관리하지 않고 기존 회사의 AD, LDAP를 그대로 사용한다.

2. VMS(VAST Management System)

VMS는 VAST를 관리하는 GUI와 관리 Plane이다.

즉 VAST GUI, CLI, REST API 모두 VMS를 통해 동작한다.

관리자는 여기에서

View 생성
View Policy 생성
Tenant 생성
Quota 설정
User 권한 설정

등을 한다.

3. 세 가지 Role

- Administrator(관리자) : Cluster 생성, View 생성, Qota 설정, Policy 생성, 업그레이드, 모니터링 등

Administrator은 RBAC(Role-Based Access Control) 사용, Role에 따라 권한을 준다

예) Storage Admin -> 모든 권한 / Helpdesk -> Read Only / Operator -> Monitoring

Administrator 인증 - 관리자는 Local User 또는 AD 또는 LDAP로 로그인 가능하다.

- User(일반 사용자) : GPU서버, Windows PC, S3 Application 등 / VMS로그인하지 않고 mount -> 파일 읽기만 함

User는 AD, LDAP, NIS, Local DB 등 다양한 시스템에서 가져올 수 있다.

예) GPU001 -> UID=1001, Windows User -> AD, S3 App -> IAM

- Provider : 외부 인증 시스템(AD, LDAP, NIS) / 이 사람이 누구인가?

실제 동작 예 :

GPU서버가 NFS Mount를 했다 / GPU001 -> UID=1001 -> VAST

그러면 VAST는 UID=1001 -> LDAP 조회 -> AI팀 -> View Policy -> Permission OK -> Read 허용

Windows라면,

Explorer -> SMB -> AD 로그인 -> NTFS ACL 확인 -> 허용

S3라면,

Application -> Access Key -> IAM Policy -> Bucket Policy -> 허용

앞에 배운 Security Flavor와 연결하면,

AD/LDAP - "너 누구야?", 사용자 인증(Authentication) 관점.

Security Flavor - "이 사람이 이 파일을 읽을 수 있나?", 권한 검사(Authorization)

즉,

사용자 -> AD -> 사용자 확인 -> Security Flavor -> 권한 검사 -> 파일 접근

GPU Server -> UID/GID -> LDAP -> 사용자 확인 -> NFS Security Flavor -> POSIX Permission 확인 -> AI Dataset 접근

운영자 -> VMS -> RBAC -> Storage Admin -> View 생성, View Policy 수정, Capacity 확인, Analytics 확인 등 수행

Administrator: VMS에 로그인해서 클러스터를 관리하는 사람(RBAC 적용)
User: NFS/SMB/S3로 실제 데이터를 사용하는 사용자나 애플리케이션
Provider: Active Directory, LDAP, NIS처럼 사용자와 그룹 정보를 제공하는 외부 인증 시스템
Security Flavor: 인증이 끝난 사용자의 파일 접근 권한을 NFS(POSIX), SMB(NTFS ACL), S3(IAM/ACL) 방식 중 어떤 모델로 검사할지 결정하는 정책

즉, Provider는 "누구인지"를 확인하고(Authentication), Security Flavor는 "무엇을 할 수 있는지"를 판단(Authorization)한다는 차이를 이해하면 VAST의 보안 구조를 쉽게 이해할 수 있다.

-----

Identity Provider

VAST가 사용자(Users)와 그룹(Group) 정보를 어디에서 가져오는지(Identity Provider)

1. Active Directory(AD) : Microsoft의 사용자 관리 시스템

가장 많이 사용하는 방식, 계정(ID, 비밀번호), 그룹, 조직 정보가 모두 AD에 저장되어 있다.

예) Username : hong / password : 1234 / Department : AI team / Group : AI_Researchers

VAST는 AD와 연동해서 GPU서버 -> VAST -> AD에게 물어봄 "hong 맞아?" 라고 확인한다.

"Supports multi-domain and cross forest trust"

companyA.local, companyB.local 도메인이 여러 개 있어도, 전부 다 사용할 수 있다는 의미

2.Lightweight Directory Access Protocol(LDAP) : AD와 비슷하지만 운영체제에 독립적인 사용자 관리 시스템

Linux 환경에서는 보통 openLDAP를 많이 사용한다.

예를 들어 GPU 서버가 로그인하려면,

UID=1001 -> LDAP 조회 -> AI Team -> 허용

3. NIS(Network Information Service) : 옛날 Unix에서 많이 사용하던 사용자 관리 시스템

4. Local Users : 외부 인증 서버가 없는 경우 VAST 안에서 직접 사용자를 만든다.

소수 계정이 필요한 경우 또는 S3 Object Storage만 사용하는 경우 Local User를 많이 사용한다.

예를 들어 Access Key, Secret Key를 VAST 내부에서 관리한다.

GPU 클러스터 기준으로 가장 많이 사용하는 조합은,

LDAP 또는 AD -> NFS Security Flavor -> POSIX Permission -> GPU서버 접근

만약 운영팀이 Windows에서 SMB로 동일한 데이터를 사용한다면 AD와 연동하여 SMB View를 추가하거나, Linux와 Windows가 모두 동일한 데이터를 관리해야 한다면 Mixed-Last-Wins Security Flavor를 선택하는 구성을 사용할 수 있다.

-----

Multiple Identity Providers(여러 인증 시스템 동시 사용) : AD, LDAP, Local User 등 여러 인증 시스템 동시 사용 가능

User Mapping : common field를 사용하여 맵핑.

예를 들어,

EmployeeID = 10001이라는 공통 필드를 보고, AD의 hong = LDAP의 hong 이라고 판단한다.

즉 두 계정을 한 사용자로 인식한다.

WIndows에서는 SMB로 접속하고, GPU 서버에서 NFS로 접속할 경우,

User Mapping이 없으면 VAST는 Windows 사용자는 Linux 사용자와 다르다고 생각할 수 있다.

Platform-Independent Permission

single-set of permissions / 권한을 하나만 저장한다.

예전 스토리지는 NFS권한, SMB권한, S3 권한을 따로 관리해야 해서 권한이 서로 달라질 수 있다.

하지만 VAST는 파일 -> 권한 -> 1개만 존재한다.

그리고 Security Flavor가 그 권한을 어떻게 해석할지 결정한다.

예) 파일 하나가 있다. /dataset/image001.jpg

권한은 Owner, AI Team, Read 딱 하나만 있다.

Linux에서 NFS로 보면 / -rw-r----- 처럼 보이고

Windows에서는 Read Modify Full Control 처럼 보인다.

S3에서는 IAM Policy로 해석된다.

하지만 실제 권한은 하나이다.

Security Flavor 역할 : 권한을 어떻게 해석할 것인가를 결정

예)

NFS Flavor면, POSIX/chmod/UID/GID 기준으로 해석

SMB Flavor면, NTFS ACL 기준으로 해석

* Users will have the same access rights regardless of protocol.

* Permissions are immediately reflected across all protocols.

Multiple Identity Providers: AD, LDAP, NIS, Local User 등 여러 인증 시스템을 동시에 사용할 수 있으며, 공통 식별자(Employee ID, Username 등)를 이용해 서로 다른 시스템의 계정을 하나의 사용자로 매핑할 수 있다.
Platform-Independent Permissions: 파일의 권한은 하나만 저장되고, NFS·SMB·S3는 Security Flavor에 따라 그 권한을 각 프로토콜에 맞게 해석한다. 따라서 어떤 프로토콜로 접근하든 동일한 권한이 적용되며, 권한 변경도 모든 프로토콜에 즉시 반영된다.

이 구조 덕분에 Windows 사용자, Linux GPU 서버, S3 기반 AI 애플리케이션이 같은 데이터를 서로 다른 방식으로 접근하면서도 일관된 보안 정책을 유지할 수 있다.

VAST Fundementals(101) - VMS(Vast Management System)

의그 — Sat, 18 Jul 2026 11:14:32 +0900

VMS 기본 UI

VAST Data Element Store

하나의 데이터를 여러 프로토콜(NFS, SMB, S3 등)에서 동시에 접근할 수 있는 Unified Storage

프로토콜 : 데이터를 "어떻게 접근할 것인가"

Element Store : 실제로 데이터가 저장되는 곳 / Metadata(SCM) + Data(Flash)

Metadata : SCM에 저장됨. 메타데이터는 자주 접근해야되기 때문.

- metadata, locks, snapshots, keys, catalog, audit log 등

Data : Hyperscale Flash(NVMe SSD)에 저장됨

- image.jpg, model.pt, checkpoint.bin 등

예) Linux 서버에서는 NFS로 읽고, Windows에서는 SMB로 읽고, Cloud Application은 S3 API로 읽고, Data Scientist는 Pythion, SQL, Arrow로 분석할 수 있다.

예전 스토리지는 NFS 저장공간, SMB 저장공간, S3 저장공간이 따로 있었으나 VAST는 하나의 데이터를 여러 프로토콜에서 접근할 수 있는 것.

View라는 개념.

NetApp 등의 전통 NAS는 NFS Export, SMB Share, S3 Bucket이 전부 따로 있다.

NFS -> /home

SMB -> //home

S3 -> bucket-home

전부 각각 관리해야 한다.

VAST에서는 View만 만든다.

View는 사용자가 데이터를 어떻게 볼 것인가를 정의한다.

예) Engineering View를 만들면 동시에 NFS, SMB, S3 사용 가능

Path와 View의 차이

Path : 데이터가 실제 있는 위치

View : 사용자가 보는 방식

예)

Path - 실제 데이터가 /vast/data/projects/AI 에 있음

View - 리눅스는 /mnt/AI 로 보게 하고, Windows에서는 \\AI 로 보게 하고, S3에서는 bucket-ai 로 보게 함

비유하자면,

Path : 서울시 강남구 테헤란로 123 (실제 주소)

View : 회사 직원->본사 / 택배기사->물류센터 / 고객->A센

즉,

Path는 데이터가 실제 저장된 위치다.
View는 그 데이터를 어떤 프로토콜(NFS, SMB, S3 등)로 사용자에게 보여줄지 정의하는 접근 방식이다.
VAST는 하나의 Element Store에 데이터를 저장하고, 여러 View를 통해 동일한 데이터를 동시에 다양한 프로토콜로 제공한다.

이 구조 덕분에 AI 학습 서버(NFS), 윈도우 사용자(SMB), 클라우드 애플리케이션(S3), 데이터 분석 도구(SQL/Python)가 같은 데이터를 복사 없이 동시에 사용할 수 있는 것이 VAST의 가장 큰 장점 중 하나다.

View Policy

누가 접속 가능? NFS만? SMB도? Root 권한은? VIP는 어디? ACL은? Audit은? 이와 같은 정책 설정

1. Apply to one or more Views : 하나의 Policy를 여러 View에 동시 적용 가능

2. Define Security Flavor : NFS 인증 방식을 무엇으로 할 것인가? AUTH_SYS, Kerberos, LDAP 등

* AUTH_SYS : UID/GID 기반, 가장 일반적

* Kerberos : 사용자 인증, 보안 높음, 기업 환경에서 많이 사용

3. Define which VIP Pools are used

VIP : Virtual IP

VAST는 C노드가 여러개 있다. 클라이언트는 10.10.10.100이라는 VIP로 접속한다.

클라이언트는 자동으로 C1 또는 C2 또는 C3로 연결된다.

'Policy에서 이 View는 VIP Pool A만 사용' 처럼 지정할 수 있다.

Add Policy 화면에서,

Tenant : 어느 Tenant 소속인지, 멀티테넌트 환경에서 사용 - default

Name : Policy 이름 - GPU_POLICY

Security Flavor : 어느 인증 방식 - AUTH_SYS, Kerberos, LDAP 중 선택

VIP Pools : 어느 VIP를 사용할지 - AI Cluster VIP 10.10.10.x

Host-Based Access : 어느 서버가 접속 가능한가 - 10.0.0.0/24 허용, 192.168.1.0 거부

NFS4.1 : NFS 전용 옵션 - Root Squash, ACL, NFS옵션 등

Default POSIX modebits : 리눅스 권한 755, 775, 700 같은 기본 권한 지정

S3 : S3 Bucket으로 사용할 경우 관련 옵션

Auditing : 누가 삭제/읽기/쓰기 를 했는지 로그를 남김

Advanced

- Path Length Limit(파일 이름 길이 제한)

- Allowed Characters(허용 문자) - /, *, ?, % 등 제한

Atime Frequency : Access Time(파일을 언제 읽었는지)을 얼마나 자주 업데이트할 것인지

읽을 때마다 Metadata Write가 발생하기 때문에 꺼두는 경우가 많음

Use 32-bit File IDs : 옛날 시스템 호환성

NFS Posix ACL : ACL 사용 여부

SMB Continuous Availability : SMB 장애 조치, Failover 옵션

예를 들어 GPU 서버 127대가 있다.

이 서버들은 NFS만 사용한다.

그러면,

View -> AI_DATASET -> Policy Security AUTH_SYS Host gpu001~127 VIP AI_VIP Root접근허용 이렇게 하나 만들어둔다.

Windows 사용자는 다른 View를 만들고 -> SMB AD인증 읽기전용 Policy를 붙이면 된다.

같은 데이터인데 접근 방식과 권한만 달라지는 것이다.

-----

Security Flavors : NFS / SMB / Mixed-Last-Wins / S3 Native

-----

Performance & Capacity Monitoring

GPU 학습 속도가 갑자기 느려졌다고 하면, 다음 순서로 확인하는 것이 일반적이다.

Analytics → Read Latency, Metadata Latency, IOPS에 이상이 있는지 확인
Top Actors → 특정 GPU 노드나 Job이 과도한 I/O를 발생시키는지 확인
Data Flow → 문제가 특정 C-node, D-node 또는 VIP 경로에 집중되는지 확인
Capacity → 용량 부족이나 Data Reduction 변화로 인한 영향이 있는지 확인

이 네 메뉴만 제대로 활용해도 대부분의 용량 문제, 성능 저하, 특정 클라이언트의 과도한 사용, 데이터 경로 문제를 빠르게 진단할 수 있다.

VAST Fundementals(101) - Introduction

의그 — Sat, 18 Jul 2026 10:15:14 +0900

DASE(Disaggregated, Shared-Everything) 아키텍처를 보여주는 다이어그램(VAST Data의 핵심 구조)

- CNodes (Compute Layer) / Stateless Containers

역할 : 클라이언트 요청 처리(NFS, SMB, S3 등), 메타데이터 처리, 실제 데이터는 저장 안함

특징 : 상태 없음(Stateless), 장애나도 다른 노드가 바로 takeover 가능, Kubernetes 구조와 유사

- DNodes (Storage Layer) / Exabyte-scale NVMe

역할 : 실제 데이터 저장(NVMe SSD)

특징 : 완전히 Scale-out 가능(노드 수평 확장), Generation N(계속 확장 가능), 기존 스토리지처럼 RAID 컨트롤러 없음

- NVMe Fabric (중간 연결)

역할 : CNode <-> DNode 연결, RDMA 기반(Infiniband / RoCE)

특징 : 매우 낮은 latency, block-level access(NVMe-oF)

데이터 흐름

1. 클라이언트 -> CNode 요청

2. Cnode -> NVMe Fabric 통해 DNode 접근

3. DNode -> 데이터 반환

4. CNode -> 클라이언트 응답

* Disaggregated(분리) : C노드 / D노드 각각 독립적으로 확장 가능

* Shared Everything(공유) : 모든 C노드가 모든 D노드 접근 가능

전통 NAS : 특정 노드에 데이터 묶임 <-> VAST : 전체 클러스터가 하나의 스토리지처럼 동작

Storage, DB, Computing을 하나로 통합한 플랫폼

1. DataStore

- Multi-protocol : NFS / SMB / S3 모두 지원

- 실제 데이터 저장

2. Database

- Transactional Data Warehouse

- 데이터 lake + DB 역할 동시에

- 특징 : 별도 DB서버 불필요, 파일->바로 SQL querry 가능

3. DataEngine

- 데이터 위에서 직접 연산 수행(Container 기반 병렬 처리, 이벤트 기반 처리)

- 데이터 이동 없이 연산 수행

DataSpace

여러 환경을 연결하는 개념

On-prem (HPE, Dell 등)
Cloud (AWS, Azure, GCP)
Colo (Equinix 등)

의미

멀티 클라우드 + 온프레 통합 데이터 공간

Similarity Reduction

1. C노드에 연결된 D노드가 죽은 것을 감지하면(클러스터가 감지),

2. 파트너 D노드가 장애 D-node의 SSD와 SCM에 대한 소유권을 가져간다.

3. C노드는 새로운 D노드로 접근한다(C노드가 새로운 D노드로 자동 라우팅).

4. 클라이언트(GPU서버)는 장애를 거의 인식하지 못한 채 계속 데이터 접근이 가능하다.

적은 저장 공간(Overhead)으로도 높은 데이터 안정성(Resilience)를 제공하는 모습.

핵심 keyword

- Erasure Coding(EC)

- Locally-Decodable Erasure Codes(LDEC)

1. 데이터를 보호하기 위해 추가로 필요한 저장 공간(Overhead)

- Triplication : 66%

=> 3중 복제 / 원본 A -> AAA

원본 100TB라면, 추가 공간 200TB, 300TB 중 추가 공간이 200TB이므로 66%

- Legacy Erasure Coding : 30%

Parity를 이용. 원본 D1,D2,D3,D4 라면 추가 공간 P1, P2 추가.

즉 4개의 데이터 + 2개의 패리티

=> 디스크 하나 또는 두 개 죽어도 복구할 수 있음. 30%의 추가 공간 필요

- VAST LDEC : 2.7~3%

원본 데이터 1,2,3, ... , 36 / Parity블록 P1~P4

즉 36개의 데이터 + 4개의 Parity를 하나의 그룹으로 보호함.

왜 Locally-Decodable인가?

기존 EC는 Block17이 죽으면 복구하기 위해 거의 모든 블록을 읽어서 17을 계산한다.

=> 엄청난 DIsk Read, Network Traffic, CPU load 발생

반면 VAST LDEC는 17과 관련된 일부 블록만 읽는다.

예를 들면 15,16,17,18,P2 정도만 읽고 복구할 수 있다.

필요한 부분(Local)만 읽어서 복구한다.

CPU / GPU / NPU / DPU

의그 — Wed, 20 Aug 2025 07:56:55 +0900

CPU, GPU, NPU는 모두 "프로세서(Processor)"이지만, 처리 방식과 최적화된 작업이 다릅니다. 간단히 말해:

1. CPU (Central Processing Unit, 중앙처리장치)

역할: 컴퓨터의 ‘두뇌’. 범용적으로 모든 연산을 처리.
구조: 소수의 강력한 코어 (보통 4~32개)
특징:
- 직렬 연산(순차적 처리)에 강함
- 운영체제, 프로그램 실행, 논리적 판단, 분기 처리에 최적화
예시: 인텔 Core, AMD Ryzen, ARM Cortex 등

일상적인 앱 실행, 웹 브라우징, OS 동작 → CPU가 담당

2. GPU (Graphics Processing Unit, 그래픽 처리 장치)

역할: 원래는 그래픽/영상 처리 전용. 지금은 대규모 병렬 연산(Parallel Processing)에 특화.
구조: 수천 개의 작은 코어
특징:
- 대량의 동일/반복 연산을 동시에 처리하는 데 강함
- 머신러닝 학습, 그래픽 렌더링, 시뮬레이션에 사용
예시: NVIDIA RTX/H100, AMD Radeon, Apple M시리즈 GPU 등

AI 딥러닝 학습, 고해상도 그래픽 처리, 과학 계산 → GPU가 담당

3. NPU (Neural Processing Unit, 신경망 처리 장치)

역할: AI 연산(특히 딥러닝 추론·Inference)에 특화된 가속기
구조: 신경망 연산(행렬 곱셈, Convolution 등)에 최적화된 회로
특징:
- GPU보다 전력 효율이 높음
- AI 추론을 빠르고 저전력으로 실행
- 스마트폰, 엣지 디바이스, 데이터센터에서 많이 채택
예시:
- 구글 TPU (Tensor Processing Unit)
- 삼성/퀄컴 스마트폰의 NPU
- 인텔 Habana Gaudi, AWS Inferentia

AI 모델 추론(예: 음성인식, 얼굴인식, 실시간 번역) → NPU가 최적

4. 비교 요약

구분CPUGPUNPU

강점	범용성, 복잡한 로직	병렬 연산, 대규모 데이터 처리	AI 추론 전용, 전력 효율
코어 수	적음 (수 개~수십 개)	많음 (수천 개)	특화된 행렬 엔진
대표 활용	OS 실행, 일반 연산	딥러닝 학습, 그래픽	딥러닝 추론, 모바일/엣지 AI
전력 효율	보통	낮음 (고전력 소모)	높음

================================================================

1. CPU (중앙처리장치) – 컨트롤 타워

역할: 전체 클러스터의 운영체제(OS), 스케줄링, 네트워크/스토리지 I/O 관리
특징:
- GPU/NPU 같은 가속기에게 연산 작업을 분배하고 관리
- VM/컨테이너 관리, 프로세스 스케줄링, 네트워크 트래픽 처리
데이터센터 활용:
- 일반 서버(node)의 기본 프로세서
- HPC(고성능컴퓨팅) 환경에서 MPI(Message Passing Interface) 기반 통신 제어
- GPU/FPGA/NPU가 붙어 있는 헤테로지니어스 서버의 “두뇌”

2. GPU (그래픽 처리 장치) – 연산 엔진

역할: 대규모 병렬 연산 수행 (행렬, 벡터 계산)
특징:
- 딥러닝 학습(training)에 최적
- 초당 테라플롭스(TFLOPS)~페타플롭스(PFLOPS) 수준의 계산 가능
- 대규모 메모리 대역폭(HBM) 기반
데이터센터 활용:
- GPU 클러스터 (예: NVIDIA DGX, Penguin Computing OriginAI 등)로 구성
- AI 모델 학습 및 과학 시뮬레이션, CFD, 분자 모델링 같은 HPC 작업
- GPU 간 초고속 네트워크(Infiniband, NVLink)로 연결하여 병렬 학습 가속

3. NPU (신경망 처리 장치) – AI 추론 가속기

역할: AI 모델 실행(Inference) 최적화
특징:
- GPU보다 전력 소모가 적고 효율이 좋음
- 학습보다는 실시간 응답이 중요한 서비스용 (예: Chatbot, Vision AI)
데이터센터 활용:
- 엣지 서버나 클라우드 AI API 백엔드에서 대규모 추론 서비스 지원
- 구글 TPU, AWS Inferentia, Habana Gaudi 등 클라우드형 NPU 칩 등장
- GPU 학습 → NPU 추론 파이프라인으로 연결

4. 데이터센터 배치 방식

HPC/AI 학습 클러스터
- CPU + GPU 수천 개 조합
- CPU는 네트워크/스토리지 제어, GPU는 대규모 학습
- NVLink / InfiniBand 같은 초저지연 네트워크로 연결
AI 추론 서버
- CPU + NPU 조합 (전력 효율 최적화)
- 실시간 이미지/음성 인식, 대화형 AI 서비스용
하이브리드 인프라
- CPU + GPU + NPU 혼합 구성
- 예: GPU에서 학습한 모델 → NPU로 추론 배치 → CPU가 서비스 관리

5. 요약 비유

CPU = 관제탑 (조율·분배·관리)
GPU = 발전소 (폭발적인 연산 처리)
NPU = 특수 장비 (AI 추론을 에너지 효율적으로 실행)

정리하자면,

데이터센터에서 AI 학습(HPC) = CPU + GPU 중심
실시간 서비스(추론, Edge AI) = CPU + NPU 중심
클라우드 대형 사업자는 GPU 학습 → NPU/TPU 추론 구조로 비용 절감 및 효율 극대화

=============================================================

Penguin Solutions 같은 HPC/AI 기업이 CPU·GPU·NPU를 어떻게 배치해서 제품화하는지?

1. CPU 중심의 제어 노드 (Control Node)

역할: 클러스터의 운영체제(OS), 작업 스케줄링, 네트워크 통신 관리
제품화 방식:
- 서버 랙 상단에 제어 노드를 별도로 배치
- Slurm, Kubernetes 같은 HPC/AI 워크로드 매니저와 통합
- Penguin Solutions의 ICE ClusterWare™ 같은 관리 소프트웨어와 연결해 전체 자원 조율

2. GPU 기반 컴퓨팅 노드 (Compute Node)

역할: AI 학습·HPC 연산 수행
제품화 방식:
- NVIDIA H100, B200, H200 같은 GPU를 대량 탑재한 서버
- NVLink, InfiniBand, 400G Ethernet 같은 초고속 네트워크로 GPU 간 통신
- Penguin Solutions OriginAI® 서버 제품군이 대표적 (최대 랙당 수십~수백 GPU 집적)
특징:
- GPU는 전력·발열이 크기 때문에 Penguin은 DLC(Direct Liquid Cooling) 방식을 적용
- 효율적인 PUE(전력효율) 달성을 위해 랙 단위 액체 냉각 설계 적용

3. NPU/AI 가속기 노드 (Inference Node)

역할: 학습된 모델을 빠르고 저전력으로 추론 실행
제품화 방식:
- Intel Habana Gaudi, AWS Inferentia, Google TPU 같은 NPU 기반 서버 노드 구성
- GPU 학습 서버와 네트워크로 연결해 Training → Inference 파이프라인 형성
활용:
- 고객사 서비스 환경(챗봇, 이미지/음성 인식)으로 연결해 실제 응용 서비스 제공

4. 스토리지 및 데이터 노드 (Storage Node)

역할: 대규모 학습 데이터와 체크포인트 저장
제품화 방식:
- 병렬 파일 시스템(Lustre, BeeGFS)과 통합
- NVMe-oF, HPC급 병렬 스토리지를 랙 단위로 제공
Penguin 사례: HPC·AI 워크로드에 맞는 확장형 스토리지 솔루션 제공

5. 통합 아키텍처 – Penguin Solutions의 방식

ICE ClusterWare™: CPU, GPU, NPU, 스토리지를 통합 관리하는 소프트웨어 플랫폼
OriginAI®: GPU·NPU 하드웨어 랙 제품군 (AI 학습/추론 특화)
DLC 설계: 고밀도 GPU/NPU 서버를 안정적으로 구동하기 위해 액체 냉각과 최적화된 전력·열 관리 기술 적용

즉, Penguin Solutions는 CPU(제어) + GPU(학습) + NPU(추론) + Storage(데이터)를 하나의 풀 스택 솔루션으로 묶어 고객에게 데이터센터 단위의 제품(랙, POD, 전체 AI 클러스터)으로 제공합니다.

요약:

CPU = 제어와 관리
GPU = 대규모 학습
NPU = 효율적 추론
Penguin Solutions = 이 모든 걸 랙/클러스터 단위로 통합하여 “제품화”

=================================================

Penguin Solutions의 제품화 구조: OriginAI® + ICE ClusterWare™

1. OriginAI® 인프라스트럭처

프리‑컨피규어된 AI 팩토리 솔루션
GPU, 스토리지, 네트워크를 포함한 모듈식 랙 구성(POD 방식) 으로 제공됩니다.
- 모델 구성: 1 POD부터 시작해, 4 POD, 16 POD 구성 옵션
- 스케일 확장: 256개에서 수만 개 GPU에 이르는 확장성 제공Penguin Solutions+9Penguin Solutions+9Penguin Solutions+9
하드웨어 구성 요소:
서버, GPU, 스토리지와 네트워킹 장비가 선구축된 형태로 제공되어, 빠른 배포 및 ROI 극대화를 가능하게 함Penguin SolutionsPenguin Solutions

2. ICE ClusterWare™ (클러스터 관리 플랫폼)

하드웨어 무관하며 지능적으로 확장되는 소프트웨어 플랫폼
베어메탈 서버, 네트워크, 스토리지를 통합 관리하며, 수십 개부터 수만 개 노드까지 자동 스케일링 가능insidehpc.com
핵심 기능들:
- 멀티 테넌시, 자동 프로비저닝, 실시간 헬스 모니터링
- Ansible, Slurm 등의 워크로드 스케쥴러 연동 가능docs.ice.penguinsolutions.com+1
AIM™ 서비스 통합 버전 (ICE ClusterWare AIM™)
- 클러스터의 장애 예측 및 자동 교정 기능 제공
- 예지적 유지보수(Prescriptive Maintenance), 효율적 GPU 사용 최적화 등 실현

구성 요약 (CPU, GPU, NPU 배치 중심으로)

구성 요소역할구축 방식

CPU (컨트롤 노드)	클러스터 전체 관리, 스케줄링, 네트워크 제어	OriginAI 모듈 내 제어 노드
GPU (컴퓨트 노드)	대규모 AI 학습 연산	Rack/POd 형태로 수백~수만 GPU 집적
NPU (추론 노드)	저전력/고효율 AI 추론 처리	OriginAI 솔루션에서 옵션으로 통합 가능 (추론 환경 구축)
스토리지 & 네트워크	데이터 및 모델 저장, 통신 인프라	병렬 스토리지 및 고속 네트워크 통합
소프트웨어 (ICE ClusterWare)	전체 클러스터의 자동화된 배포·관리	하드웨어 무관, 멀티테넌트, 정책 기반 orchestration
AIM 서비스	가동 시간 극대화, 자원 활용 최적화	자동 오류 탐지/대응, 효율 배치 지원

제품화 사례와 장점

프리패키지 검증 인프라
OriginAI는 Penguin의 블루프린트를 기반으로 선구축되며, 현장 설치 시간을 최소화하고, 테스트된 신뢰성을 바탕으로 즉시 사용 가능
대규모 GPU 런타임 운영 경험 보유
Penguin은 85,000개 이상의 GPU와 20억 시간 이상 GPU 런타임 운영 경험을 통해 최적화된 아키텍처 구현 역량 보유
고가용성과 자동화 기반 운영
ICE ClusterWare는 장애 발생 시 헤드 노드 장애 회복, 자동 이미지 배포, 워크로드 분할 운용 등 높은 신뢰성과 운영 효율성을 보장

정리하자면...

Penguin Solutions는 머신러닝과 HPC 인프라를 OriginAI라는 모듈형 제품으로 묶고, ICE ClusterWare를 통해 자동화·운영 최적화를 실현함으로써:

CPU, GPU, NPU 구성 요소를 랙/POd 단위로 효율적으로 설계
하드웨어/소프트웨어/서비스를 통합한 풀 스택 접근 방식
고밀도 구성에서도 운영 안정성과 자원 효율 극대화

를 모두 제공하는 AI 인프라 전문 기업입니다.

=============================

DPU(Data Processing Unit)란 무엇인가?

정의: 데이터센터 서버 안에서 CPU가 담당하던 데이터 입출력(I/O), 네트워크, 스토리지, 보안 작업을 전담하도록 설계된 전용 프로세서.
별칭: SmartNIC(Smart Network Interface Card)라고도 불림.
등장 배경:
- 클라우드·AI 데이터센터는 네트워크 트래픽, 스토리지 암호화, 보안 검증 등 I/O 부하가 기하급수적으로 증가.
- 기존에는 CPU가 연산과 I/O를 동시에 처리했는데, CPU의 자원을 잡아먹어 애플리케이션 성능 저하 발생.
- 이를 해소하기 위해 CPU는 애플리케이션 연산에 집중시키고, DPU가 I/O/보안/네트워크를 전담하게 한 것.

2. DPU의 주요 기능

네트워크 오프로딩
- 가상 스위치, 패킷 라우팅, 방화벽 정책 처리
- CPU 대신 네트워크 패킷을 실시간 처리 → 지연(Latency) 최소화
스토리지 가속
- 압축/암호화/복호화, 데이터 복제/스냅샷 처리
- NVMe-oF 같은 초고속 스토리지 전송 가속
보안 오프로딩
- TLS/IPSec 암호화, 방화벽 룰, 침입 탐지/차단(IDS/IPS) 처리
- 데이터센터의 제로 트러스트(Zero Trust) 아키텍처 구현 지원
가상화 & 클라우드 네이티브 지원
- 하이퍼바이저 기능 일부를 대신 수행 → VM/컨테이너 오버헤드 감소
- 쿠버네티스, OpenStack 같은 클라우드 플랫폼과 밀접하게 통합

3. 대표적인 DPU 제품

NVIDIA BlueField DPU
- Mellanox SmartNIC 기술 기반
- 네트워크·스토리지·보안을 하드웨어에서 가속
- AI·HPC 데이터센터에서 많이 채택
AWS Nitro
- Amazon EC2 인스턴스 내부에서 네트워크, 스토리지, 보안을 오프로딩
- 고객 VM에서 직접 접근 불가 → 보안 강화
Intel IPU (Infrastructure Processing Unit)
- 비슷한 개념, 네트워크 및 스토리지 오프로딩

4. 데이터센터에서 DPU의 역할

CPU: 애플리케이션 연산 집중 (AI 모델 실행, DB 처리 등)
GPU: 병렬 연산, AI 학습 및 HPC 처리
NPU: AI 추론 전용 가속
DPU: 데이터 전송, 네트워크, 보안, 스토리지 관리 담당

즉, CPU·GPU·NPU는 “계산”, **DPU는 “데이터 이동과 보호”**를 맡는 구조입니다.

5. 비유

CPU = 두뇌 (전체 연산 총괄)
GPU = 근육 (대규모 연산 가속)
NPU = 특수부대 (AI 추론 특화)
DPU = 교통경찰/경비병 (네트워크·보안·데이터 이동 전담)

정리하면, DPU는 데이터센터에서 CPU의 부담을 줄이고 네트워크·보안·스토리지 처리 효율을 극대화하는 핵심 가속기입니다.
앞으로 클라우드, AI 인프라 확장과 함께 GPU와 함께 반드시 필요한 가속기로 자리 잡고 있어요.

SKT와 펭귄 솔루션스(Penguin Solutions)의 협력 + SK Hynix

의그 — Tue, 19 Aug 2025 21:16:16 +0900

SK텔레콤(SK T)과 펭귄 솔루션스(Penguin Solutions)의 협약은 AI 데이터센터(AIDC) 솔루션 개발 및 글로벌 사업 확장을 중심으로 한 전략적 협력입니다. 특히 SK하이닉스와도 함께 이뤄진 3자 협약으로, 협업 범위가 보다 구체적으로 설정되어 있습니다.

주요 협력 범위

1. 글로벌 시장 확대

일본, 아시아태평양(APAC), 중동 등 지역에서 AI 데이터센터 구축 및 확장을 추진합니다.HPCwire+15미래를 보는 창 - 전자신문+15더팩트+15

2. 솔루션 공동 연구개발(R&D) 및 상용화

AI 데이터센터 구축과 운영에 필요한 **소프트웨어 풀 스택(Full Stack)**을 공동 개발합니다.
SKT의 인프라 관리 SW와 펭귄 솔루션스의 Scyld ClusterWare® 기반의 OriginAI® 솔루션 아키텍처를 결합하여 더욱 간편하고 효율적인 AI 클러스터 관리 체계를 구축합니다.더팩트+4SK텔레콤 뉴스룸+4톱데일리+4ir.penguinsolutions.com

3. 차세대 메모리 어플라이언스 개발

SK하이닉스와 펭귄 솔루션스가 협력해 AI 데이터센터에 특화된 차세대 메모리 기술, 특히 HBM(고대역폭 메모리) 기반의 어플라이언스를 개발합니다.SK hynix Newsroom -+13미래를 보는 창 - 전자신문+13FETV+13
이를 통해 전력 효율과 방열 성능을 개선하는 데이터센터 기술 혁신을 목표로 합니다.SK hynix Newsroom

4. SKT의 전략과 연계

이번 협력은 SKT가 지난해 7월 체결한 2억 달러 규모의 전략적 투자를 기반으로, 시너지 TF(Task Force)를 구성해 구체적 협력 계획을 논의한 결과입니다.HPCwire+15미래를 보는 창 - 전자신문+15SK텔레콤 뉴스룸+15
SKT는 이를 통해 **’한국형 소버린 AI 인프라 비즈니스 모델(BM)’**을 구축, “세계에서 가장 경제적이고 효율적인 AI 데이터센터” 실현을 목표로 하고 있습니다.worktoday.co.kr+11미래를 보는 창 - 전자신문+11톱데일리+11

요약

협력 항목주요 내용

글로벌 확장	일본, APAC, 중동 등에서 데이터센터 시장 개척
R&D 및 상용화	풀 스택 소프트웨어 솔루션 개발 및 AI 클러스터 상용화
메모리 기술 개발	HBM 기반 어플라이언스 기술 협력 개발
전략적 기반	2억 달러 투자, 시너지 TF 구성, 한국형 BM 구축

이처럼 SKT와 펭귄 솔루션스의 협약은 단순한 투자나 공급 계약을 넘어, 글로벌 AI 인프라 구축을 위한 전략적 동맹을 목표로 하고 있으며, SK하이닉스와의 메모리 기술 협력을 포함한 기술적, 사업적 다방면의 협력을 포함하고 있습니다.

PUE 개선을 위한 DLC / TUE / TDP

의그 — Tue, 19 Aug 2025 20:48:34 +0900

DLC (Direct Liquid Cooling, 직접 액체 냉각)

1. 개념

CPU, GPU 같은 고성능 칩에서 발생하는 열을 **액체(물이나 특수 냉각액)**를 통해 직접 흡수하여 냉각하는 방식.
공랭(팬, 공기 흐름) 대비 열전달 효율이 매우 뛰어남 → 고밀도 서버·AI/HPC 환경에서 필수 기술.

2. 방식

Cold Plate 방식
칩 위에 금속 블록(Cold Plate)을 장착하고, 그 안에 냉각수가 흐르면서 열을 흡수.
Immersion Cooling (침지 냉각)
서버 전체를 절연 특수액체 속에 담가 냉각. (2상 냉각/단상 냉각으로 나뉨)

3. 장점

공랭 대비 3,000배 이상 효율적인 열전달 (물의 열전도율이 공기보다 월등히 높음)
랙당 전력밀도가 30~100kW 이상 올라가도 안정적인 냉각 가능 → AI GPU 클러스터(H100, B200 등) 운영에 적합
데이터센터 전체의 냉각 전력 사용 감소 → 에너지 효율 개선

4. 단점/과제

초기 구축 비용이 높음 (배관, 냉각수 분배 장치, 누수 방지 설계 필요)
유지보수 난이도 상승 (누수 관리, 펌프/밸브 점검 필요)
데이터센터 전반적인 인프라 설계 변경 필요

PUE (Power Usage Effectiveness, 전력 사용 효율)

1. 개념

데이터센터의 **총 전력 사용량 대비 IT 장비(서버, 스토리지, 네트워크)**가 실제 사용하는 전력의 비율.
계산식:

PUE=데이터센터총전력IT장비전력PUE = \frac{데이터센터 총 전력}{IT 장비 전력}

예)

데이터센터 총 전력 = 1,500kW
서버/네트워크 등 IT장비 전력 = 1,000kW
PUE = 1.5

2. 해석

PUE = 1.0 → 전력이 100% IT 장비에 쓰임 (이론적 이상적인 상태, 현실적으로 불가능).
일반 전통 데이터센터: 1.6~2.0
고효율/친환경 데이터센터: 1.2~1.3
최신 AI/HPC 특화 시설(DLC, 액침, 외기냉방 등 적용): 1.1 이하 도 가능

3. 의미

PUE는 데이터센터의 운영 효율성을 보여주는 대표 지표.
글로벌 빅테크(구글, 마이크로소프트, 메타 등)는 PUE를 낮추기 위해 DLC, AI 기반 냉각 제어, 재생에너지 사용을 확대.

⚖️ DLC와 PUE 관계

DLC 적용 → 냉각에 필요한 에너지가 줄어듦 → PUE 개선.
예: 공랭식 데이터센터 PUE 1.6 → DLC 적용 후 1.2~1.1 수준 달성 가능.
즉, DLC는 고성능 AI/HPC 서버 냉각 문제 해결 + 데이터센터 전력 효율 개선의 핵심 기술.

✅ 정리하면:

DLC = 고성능 칩을 액체로 직접 냉각하는 기술 → 고밀도 GPU 서버 운영 가능하게 만듦.
PUE = 데이터센터 효율성을 나타내는 지표 → 1.0에 가까울수록 효율적.
DLC를 적용하면 냉각 전력을 줄여 PUE를 낮추는 데 직접 기여합니다.

=============================================

DLC 적용과 PUE 변화: 실제 사례

1. NVIDIA & Vertiv 합동 분석 사례

미국 필라델피아 인근, 중형(1~2 MW) 데이터센터에서 DLC 도입 영향 분석
DLC 비중 75% 수준(Study 4)에서:
- 시설 전체 전력 사용량 약 10.2% 감소
- PUE는 1.38 → 1.34, 즉 3.3% 수준 하락
- 서버 팬 전력은 80% 감소, 결과적으로 IT 전력도 약 7% 감소 Datacenter Dynamics+7Uptime Institute Blog+7CoolIT Systems+7HPCwire+11vertiv.com+11vertiv.com+11
결론적으로, DLC는 시설 전력과 IT 전력을 동시에 줄여 전통적인 PUE 계산 방식에서는 효율성과 차이를 제대로 반영하지 못함.
따라서 **TUE(Total Usage Effectiveness)**라는 새로운 지표가 제안되었으며, 해당 사례에서는 TUE가 약 15.5% 향상됨 vertiv.com+1

2. Emmy 슈퍼컴퓨터 데이터센터 (독일 GWDG) 사례

Phase 1: 공랭 방식, Phase 2: DLC 하이브리드 적용
랙당 최대 전력 밀도는 DLC 랙이 공랭 대비 4배 (96 kW vs 23.5 kW) CoolIT Systems
평균 PUE:
- 공랭 시스템: 1.24
- DLC 시스템: 1.07
따라서 PUE가 최대 약 13.7%까지 개선됨 Wikipedia+11CoolIT Systems+11Datacenter Dynamics+11

3. Shell 사례 — Penguin Solutions의 침지(Immersion) 냉각

Shell 하우스턴 데이터센터에 도입된 단상 침지 냉각:
- 전력 사용량 최대 48% 감소
- CPU 성능 최대 40% 향상
- CO₂ 배출량 최대 30% 감소
- 데이터센터 면적 약 80% 절감
- PUE는 1.1 수준까지 가능 → 평균 1.55였던 기존에 비해 크게 개선 ResearchGate+12penguinsolutions.com+12Uptime Institute Blog+12

DLC vs PUE: 핵심 정리

항목주요 변화 및 특징

PUE 개선	DLC 도입 시 공랭 대비 PUE가 1.24 → 1.07 수준으로 개선 (Emmy 사례)
시설 전력 감소	Vertiv 사례: 전체 전력 약 10% 절감, 팬 전력 80% 감소
효율 지표 한계	PUE는 IT 전력도 감소시키는 DLC 특성을 반영하기 어려움 → TUE와 같은 보완 지표 필요
고밀도 처리	DLC 통해 랙당 전력 4배 증가 가능, 컴퓨팅 밀도 증대
환경 및 성능 개선	침지 냉각: 에너지, CO₂, 공간 절감, 성능 향상 (Shell 사례)

요약

DLC는 데이터센터 효율성을 크게 강화하며, PUE를 낮추는 데도 기여하지만,
PUE는 IT 전력도 낮추는 DLC의 특성을 충분히 반영하지 못하므로, TUE 같은 새로운 지표가 필요해요.
실제 사례들을 보면 DLC는 에너지, 성능, 공간, 환경 측면에서 다방면으로 매우 뛰어난 효과를 냅니다.

==================================================

**TDP (Thermal Design Power, 열 설계 전력)**은 CPU나 GPU 같은 반도체 칩이 일반적인 동작 조건에서 발생시키는 열의 최대량을 의미해요. 쉽게 말해, **“이 정도 열(전력 소모)을 감당할 수 있게 냉각 설계를 하라”**라는 기준값입니다.

TDP의 의미

단위: 와트(W)
칩이 최대 부하에서 소비하는 전력과 그에 따른 발열량을 나타냄
예: CPU TDP = 125W → 정상 동작 시 최대 약 125W 전력 소모, 그에 따른 열이 발생하므로 쿨러/방열판은 최소 125W 이상을 해소할 수 있어야 함

TDP = 소비 전력?

꼭 같지는 않음.
- 소비 전력(Power Consumption): 실제 동작 시 들어가는 전력 (상황에 따라 변동)
- TDP: 냉각 솔루션 설계 기준치 (안정적 운영을 위해 잡아둔 상한선)
예: CPU 소비 전력이 순간적으로 TDP보다 더 높아질 수 있음 (Intel Turbo Boost, AMD Precision Boost 같은 기능이 켜지면 순간 전력 소모가 폭증)

⚖️ TDP의 활용

쿨링 설계 기준
- 제조사(인텔, AMD, 엔비디아)는 CPU/GPU마다 TDP를 명시 → 적절한 쿨러 선택 가능
- 예: TDP 350W GPU라면 **액체냉각(DLC)**이 사실상 필수
서버/데이터센터 인프라 설계
- 서버 랙 밀도를 정할 때, 장비별 TDP를 합산 → 냉각/전력 인프라 설계 기준
- AI GPU(H100, B200)는 TDP가 700~1000W 이상 → 공랭으론 한계, DLC/Immersion 필요

오해하기 쉬운 점

TDP = 성능 지표가 아님
TDP가 높다고 반드시 성능이 더 좋은 건 아님. (단, 고성능 칩일수록 전력 소모가 커져 TDP도 높은 경향이 있음)
제조사마다 기준이 다름
인텔, AMD, 엔비디아가 TDP를 산정하는 방식이 서로 달라 직접 비교는 어렵습니다.

✅ 정리하면:

TDP = 칩이 최대 부하 시 발생시키는 **열량(=전력 소모량)**을 수치화한 것.
의미 = 냉각기, 서버 설계, 데이터센터 인프라 용량을 결정하는 핵심 지표.
HPC/AI GPU의 경우 TDP가 매우 높아 → DLC(Direct Liquid Cooling) 같은 첨단 냉각 기술이 필요합니다.

PCIe vs NVLink(Nvidia 자체 기술) / NVLink-C2C / RDMA / RoCE 등

의그 — Mon, 18 Aug 2025 20:58:46 +0900

PCIe(Peripheral Component Interconnect Express) : 컴퓨터 내부에서 CPU, 메모리, 그래픽카드, SSD, 네트워크 카드 같은 장치들을 빠르게 연결하기 위한 고속 인터페이스 규격

핵심 특징

고속 전송: 기존 PCI, AGP보다 훨씬 빠른 데이터 전송 속도를 제공. (버전이 올라갈수록 속도 증가: PCIe 3.0 → 8GT/s, PCIe 4.0 → 16GT/s, PCIe 5.0 → 32GT/s 등)
레인(Lane) 구조: 데이터 통로를 1개(x1), 4개(x4), 8개(x8), 16개(x16)처럼 병렬로 묶어서 사용 가능 → 그래픽카드는 보통 x16, NVMe SSD는 x4 사용.
호환성: 물리적으로 같은 슬롯이면 상위/하위 버전 간 호환 가능(다만 속도는 낮은 쪽에 맞춰짐).
범용성: GPU, NVMe SSD, RAID 카드, 네트워크 카드, 캡처 카드 등 다양한 하드웨어가 PCIe 슬롯을 통해 연결됨.

간단히 말하면

도로 비유: PCIe는 “고속도로” 같은 역할을 하고, Lane(x1, x4, x8, x16)은 차선 수예요. 차선이 많을수록 더 많은 데이터를 동시에 오갈 수 있음.
세대 차이: PCIe 3.0, 4.0, 5.0, 6.0처럼 세대가 올라갈수록 도로 자체가 넓어져서 같은 차선 수라도 속도가 배로 빨라져요.

NVLink : NVLink는 NVIDIA가 만든 GPU 간 초고속 인터커넥트(Interconnect) 기술이에요.
PCIe보다 훨씬 빠른 속도로 GPU끼리 데이터를 주고받을 수 있도록 설계된 “전용 통신 다리”라고 보면 됩니다.

주요 특징

초고속 대역폭
- PCIe 4.0 x16: 약 32GB/s
- NVLink(3세대 기준, A100 GPU 사용 시): GPU당 최대 600GB/s 이상
  → GPU끼리 직접 연결되기 때문에, PCIe 대비 훨씬 빠른 데이터 교환이 가능해요.
직접 연결 (Peer-to-Peer)
CPU를 거치지 않고 GPU들끼리 직접 데이터를 교환할 수 있어요. → 딥러닝, HPC(High Performance Computing) 같은 연산에서 큰 장점.
확장성
여러 GPU를 하나의 거대한 메모리 풀처럼 사용할 수 있게 해 줌. → 대규모 모델 학습, 시뮬레이션, AI 추론 등에 적합.
NVSwitch 지원
GPU가 많아지면 NVLink만으로는 연결이 복잡해져서, NVSwitch라는 스위치 칩을 통해 수십~수백 개의 GPU를 전부 연결 가능.
(예: NVIDIA DGX, HGX 서버에 쓰임)

정리 (비유)

PCIe: GPU와 CPU, GPU와 SSD 같은 장치들이 연결되는 일반 “고속도로”
NVLink: GPU들끼리만 오가는 “초고속 전용도로”
NVSwitch: GPU 전용 고속도로의 “인터체인지/교차로”

1. RDMA (Remote Direct Memory Access)

개념: 네트워크를 통해 원격 서버의 메모리에 CPU 개입 없이 직접 읽고 쓰는 기술.
특징:
- 전송 시 OS 커널을 거치지 않아 낮은 지연시간 (low latency) 제공
- CPU 사용률이 크게 줄어들어 애플리케이션 성능 향상
- HPC, AI/ML, DB 클러스터, 스토리지 시스템 등에서 사용
주요 장점:
- 낮은 지연시간
- 높은 대역폭 활용
- 낮은 CPU 오버헤드

2. RoCE (RDMA over Converged Ethernet)

개념: 이더넷 네트워크에서 RDMA 기능을 구현하는 표준.
- 원래 RDMA는 인피니밴드(InfiniBand)에서 많이 사용됐는데, RoCE는 이더넷 환경에서도 RDMA를 가능하게 함.
버전:
- RoCE v1: Layer 2에서 동작 → 같은 브로드캐스트 도메인 내에서만 가능
- RoCE v2 (Routable RoCE): UDP/IP 기반 Layer 3 지원 → 라우팅 가능, 데이터센터 간 연결 가능
요구 조건:
- 낮은 지터와 손실 없는 전송을 위해 DCB(Data Center Bridging), PFC(Priority Flow Control) 같은 이더넷 QoS 기술 필요
활용 사례:
- 클라우드 데이터센터 (예: Azure, AWS 등에서 HPC 워크로드)
- 스토리지 프로토콜 (NVMe over Fabrics with RoCE)
- 대규모 AI/ML 클러스터 통신

3. 비교

구분RDMARoCE

기본 개념	원격 메모리에 CPU 개입 없이 직접 접근	RDMA를 이더넷 위에서 구현
기반 네트워크	인피니밴드(주로) / 전용 RDMA 지원 HW	이더넷 (L2: RoCEv1, L3: RoCEv2)
지연시간	매우 낮음	이더넷 최적화 시 낮음
확장성	인피니밴드 스위치 필요 → 상대적으로 제한적	기존 이더넷 인프라 활용 가능, 대규모 클라우드 친화적
사용처	HPC, 금융거래, 고속 DB	클라우드, AI/ML, 스토리지 (NVMe-oF)