7-1. 설계 — 인프라 편 (이중화, 플랫폼, Tier)
스토리지 설계의 인프라 편. FC/iSCSI 네트워크 이중화와 장애 시나리오, VMware 데이터스토어 선택(VMFS/NFS/vVols)과 장애 리스크, K8s PV/PVC/CSI 설계, Tier 구조와 자동 티어링 리스크까지. 물리적 뼈대를 먼저 세우는 설계의 전반부.
장비를 샀다. 이제 어떻게 구성할 건지 결정해야 한다.
설계를 대충 하면 나중에 고통받는다. 네트워크 이중화를 안 했더니 케이블 하나 빠지면 IO가 끊긴다. VM인지 K8s인지를 안 따지고 LUN을 만들었더니 나중에 데이터스토어를 다시 구성해야 했다. 설계 단계에서 30분 더 생각하면, 운영 단계에서 30시간을 아낄 수 있다.
설계를 두 편으로 나눈다. 이번 편(7-1)은 인프라 설계 — 물리적 네트워크 구조, 플랫폼 환경, 성능 등급을 잡는다. 다음 편(7-2)은 데이터 설계 — 그 위에 볼륨을 배치하고, 이름을 붙이고, 보호 정책을 얹는다.
스토리지 설계 — 전체 그림
설계에서 결정해야 할 것들을 먼저 한 장으로 정리한다. 실무에서 설계할 때의 사고 흐름 순서대로 나열했다.
스토리지 설계 전체 흐름:
┌─────────────────────────────────────────────────────────┐
│ │
│ ① 네트워크 이중화 "뼈대를 먼저 잡는다" │
│ FC 듀얼 Fabric / iSCSI VLAN 프로토콜, 경로, 스위치 │
│ 멀티패싱 정책 → 물리적 기반이 없으면 │
│ 아무것도 못 한다 │
│ │ │
│ ▼ │
│ ② 플랫폼 환경 결정 "뭐 위에서 돌아가나?" │
│ VMware → VMFS / NFS / vVols 베어메탈 / VM / K8s │
│ K8s → CSI, StorageClass → 데이터스토어 유형과 │
│ 베어메탈 → 직접 LUN 매핑 프로토콜이 결정된다 │
│ │ │
│ ▼ │
│ ③ Tier 설계 "성능 등급을 나눈다" │
│ NVMe / TLC SSD / QLC / HDD 워크로드별 성능 요구에 │
│ 자동 티어링 정책 맞춰 등급 배정 │
│ │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ (이상 7-1편) ─ ─ ─ ─ ─ ─ │
│ │ │
│ ▼ │
│ ④ LUN / 볼륨 레이아웃 "데이터를 배치한다" │
│ 분리 기준 (용도/IO패턴) ①②③의 결과를 반영해서 │
│ 크기, Tier 배정, 호스트 매핑 실제 볼륨 구조를 잡음 │
│ │ │
│ ▼ │
│ ⑤ 네이밍 컨벤션 "이름 규칙을 잡는다" │
│ 볼륨, 호스트 그룹, ④에서 결정한 볼륨들에 │
│ Zoning Alias 일관된 이름을 부여 │
│ │ │
│ ▼ │
│ ⑥ 스냅샷 정책 "시점 복구를 설계한다" │
│ 등급별 주기 / 보관 기간 볼륨별 스냅샷 정책 │
│ 용량 예약 배정 │
│ │ │
│ ▼ │
│ ⑦ DR / 복제 구성 "재해 복구를 설계한다" │
│ 동기 vs 비동기 RPO/RTO 요구에 맞춰 │
│ RPO/RTO 매핑 복제 방식 결정 │
│ │ │
│ ▼ │
│ ⑧ 설계 문서 체크리스트 "빠진 건 없는가?" │
│ │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ (이상 7-2편) ─ ─ ─ ─ ─ ─ │
│ │
└─────────────────────────────────────────────────────────┘네트워크 이중화 — 단일 장애점을 없앤다
스토리지 네트워크는 반드시 이중화해야 한다. "이중화 안 해도 괜찮겠지"라는 생각은 케이블 한 가닥이 빠지는 순간 끝난다.
FC SAN 듀얼 Fabric 구성:
서버 스토리지
┌──────────────┐ ┌──────────────────┐
│ HBA Port 1 ─┼──► FC Switch A ──►│ Ctrl A Port 1 │
│ │ (Fabric A) │ Ctrl B Port 1 │
│ │ │ │
│ HBA Port 2 ─┼──► FC Switch B ──►│ Ctrl A Port 2 │
│ │ (Fabric B) │ Ctrl B Port 2 │
└──────────────┘ └──────────────────┘
Fabric A와 B는 완전히 독립된 네트워크.
ISL(Inter-Switch Link)로 연결하지 않는다.
장애 시나리오별 동작:
┌──────────────────────────────────────────────────────┐
│ 장애 상황 │ 서비스 영향 │ 복구 │
├────────────────────┼────────────────┼─────────────────┤
│ FC 케이블 1개 단절│ 없음. │ 케이블 교체 │
│ │ 나머지 경로로 │ │
│ │ 자동 전환 │ │
├────────────────────┼────────────────┼─────────────────┤
│ FC Switch A 장애 │ 없음. │ Switch 교체/ │
│ │ Fabric B로 │ 복구 │
│ │ 전체 IO 처리 │ │
├────────────────────┼────────────────┼─────────────────┤
│ 서버 HBA 1개 장애 │ 없음. │ HBA 교체 │
│ │ 남은 HBA로 동작│ (대부분 재부팅 │
│ │ │ 필요) │
├────────────────────┼────────────────┼─────────────────┤
│ 스토리지 Ctrl 장애│ 순간 지연 │ 자동 Failover │
│ │ (수초~수십초) │ → Giveback │
├────────────────────┼────────────────┼─────────────────┤
│ 두 Fabric 동시 장애│ IO 완전 중단! │ Fabric 복구 │
│ (극히 드묾) │ 서비스 장애 │ 필요 │
└────────────────────┴────────────────┴─────────────────┘
"두 Fabric이 동시에 죽을 일이 있나?"
있다. 두 Switch를 같은 PDU에 꽂아놓고 PDU가 나가면 동시에 죽는다.
→ Switch A와 B는 반드시 다른 PDU, 가능하면 다른 랙에 배치.iSCSI 이중화도 같은 원칙이지만, 추가 주의사항이 있다.
iSCSI 이중화 구성:
서버 스토리지
┌──────────────┐ ┌──────────────────┐
│ NIC1 (VLAN10)┼──► Switch A ────►│ iSCSI Port A │
│ │ (전용 VLAN) │ │
│ │ │ │
│ NIC2 (VLAN20)┼──► Switch B ────►│ iSCSI Port B │
│ │ (전용 VLAN) │ │
└──────────────┘ └──────────────────┘
iSCSI 이중화 추가 주의사항:
┌──────────────────────────────────────────────────────┐
│ · VLAN이 같으면 이중화가 아니다. 같은 L2 도메인에서 │
│ 브로드캐스트 스톰이 나면 양쪽 다 죽는다. │
│ │
│ · Jumbo Frame(MTU 9000)을 쓸 거면 경로 상의 모든 │
│ 장비(NIC, Switch, 스토리지 포트)에서 동일하게 │
│ 설정해야 한다. 하나라도 안 맞으면 패킷 분할 → │
│ 성능 저하 또는 연결 불안정. │
│ │
│ · FC와 달리 iSCSI는 경로 장애 감지가 느리다. │
│ TCP 세션 타임아웃(수십 초)에 의존하므로, │
│ 경로 전환까지 IO 중단이 발생할 수 있다. │
│ → iSCSI 타이머 값(replacement_timeout 등)을 │
│ 벤더 권장값으로 튜닝해야 한다. │
└──────────────────────────────────────────────────────┘멀티패싱 정책도 설계 단계에서 정해야 한다.
멀티패스 정책 비교:
┌───────────────────────────────────────────────────────┐
│ 정책 │ 동작 │ 장단점 │
├───────────────────┼────────────────────┼───────────────┤
│ Round Robin │ 경로를 번갈아 사용 │ 장점: 양쪽 │
│ │ IO 1→A, IO 2→B │ 경로 활용, │
│ │ │ 처리량 최대 │
│ │ │ 단점: 경로 간 │
│ │ │ 성능 차이가 │
│ │ │ 있으면 비효율 │
├───────────────────┼────────────────────┼───────────────┤
│ Least Queue Depth │ 대기 큐가 짧은 │ 장점: 비대칭 │
│ │ 경로로 IO를 보냄 │ 환경에 적합 │
│ │ │ 단점: 경로 │
│ │ │ 모니터링 │
│ │ │ 오버헤드 │
├───────────────────┼────────────────────┼───────────────┤
│ Fixed / Failover │ 평소 경로 A만 사용 │ 장점: 단순 │
│ Only │ A 장애 시 B로 전환 │ 단점: 경로 B가│
│ │ │ 평소에 놀고 │
│ │ │ 있음. 전환 시 │
│ │ │ 지연 발생 │
└───────────────────┴────────────────────┴───────────────┘
벤더 권장: 거의 모든 현대 올플래시 → Round Robin
단, ALUA Non-Optimized 경로로 IO가 가면 컨트롤러 간
내부 전달이 발생해서 레이턴시가 올라간다.
ALUA 상태를 제대로 인식하는지 반드시 확인.플랫폼 환경 결정 — VM인가, 컨테이너인가, 베어메탈인가
요즘 스토리지에 직접 붙는 건 물리 서버가 아니다. VMware ESXi 호스트이거나, Kubernetes 노드다. "이 볼륨 위에서 VM이 돌아갈 건지, 컨테이너가 올라갈 건지"를 설계 단계에서 정해야 데이터스토어 유형, 프로토콜, 멀티패싱 정책을 맞출 수 있다.
VMware — 데이터스토어의 세 가지 선택
┌──────────────────────────────────────────────────────┐
│ VMware 데이터스토어 유형 │
│ │
│ [VMFS] [NFS] [vVols] │
│ │
│ ESXi가 NAS에서 스토리지가 VM별로 │
│ 블록(LUN) NFS Export를 볼륨을 직접 관리 │
│ 위에 VMFS 마운트해서 (VM 단위 제어) │
│ 파일시스템 데이터스토어로 │
│ 생성 사용 │
│ │
│ SAN 필요 이더넷만 있으면 벤더 연동 플러그인 │
│ (FC/iSCSI) 됨 (VASA Provider) 필요 │
└──────────────────────────────────────────────────────┘┌──────────────────────────────────────────────────────────┐
│ VMFS vs NFS vs vVols 비교 │
├────────────────┬──────────┬──────────┬───────────────────┤
│ │ VMFS │ NFS │ vVols │
├────────────────┼──────────┼──────────┼───────────────────┤
│ 프로토콜 │ FC/iSCSI │ NFS │ FC/iSCSI/NFS │
├────────────────┼──────────┼──────────┼───────────────────┤
│ 관리 단위 │ LUN= │ Export= │ VM 단위 │
│ │ 데이터 │ 데이터 │ (VM별 볼륨) │
│ │ 스토어 │ 스토어 │ │
├────────────────┼──────────┼──────────┼───────────────────┤
│ 스냅샷 단위 │ LUN 전체 │ Export │ VM별 스냅샷 │
│ (스토리지측) │ │ 전체 │ (세밀한 제어) │
├────────────────┼──────────┼──────────┼───────────────────┤
│ 구성 복잡도 │ 중간 │ 낮음 │ 높음 (VASA 연동) │
├────────────────┼──────────┼──────────┼───────────────────┤
│ 주 사용 환경 │ 미션 │ 범용 │ 차세대 환경 │
│ │ 크리티컬 │ VDI │ (아직 도입 초기) │
└────────────────┴──────────┴──────────┴───────────────────┘각 방식의 장애 리스크도 설계 단계에서 인지해야 한다.
VMFS는 안정적이지만, LUN 단위 관리라서 VM 수백 대가 하나의 LUN에 올라가면 특정 VM의 IO 폭주가 다른 VM에 영향을 준다(Noisy Neighbor). LUN 장애 시 그 위의 모든 VM이 동시에 영향받는다.
NFS는 구성이 단순하지만, NFS 서버(스토리지)가 응답을 멈추면 ESXi 호스트 전체가 IO 대기 상태에 빠질 수 있다. APD(All Paths Down) 상태가 되면 VM이 먹통이 되고, 복구에도 시간이 걸린다.
vVols는 VM별 세밀한 제어가 매력이지만, VASA Provider에 대한 의존도가 높다. VASA Provider가 다운되면 프로비저닝이 불가능해지고, 벤더 간 마이그레이션도 사실상 불가능해서 벤더 종속이 강화된다.
ESXi 멀티패싱은 거의 모든 현대 스토리지에서 VMW_PSP_RR(Round Robin)을 권장한다. 벤더 문서에 세부 설정(IOPS 제한값 등)이 있으니 반드시 확인해야 한다.
VAAI(vStorage APIs for Array Integration)도 챙겨야 한다. ESXi가 스토리지의 하드웨어 기능을 직접 활용하는 API로, VAAI가 동작하면 VM 배포, 클론, 마이그레이션 속도가 확 빨라진다.
Kubernetes — PV, PVC, CSI
컨테이너 환경에서 스토리지를 연결하는 구조는 VMware와 상당히 다르다.
Kubernetes 스토리지 구조:
[Pod] ──► [PVC] ──► [PV] ──► [StorageClass] ──► [CSI Driver] ──► [스토리지]
Pod가 직접 스토리지를 모른다.
PVC로 "이런 스토리지 필요해"라고 선언하면
CSI 드라이버가 자동으로 프로비저닝한다.설계 시 가장 중요한 건 Access Mode와 StorageClass 설계다.
┌──────────────────────────────────────────────────┐
│ Kubernetes Access Mode │
├──────────────────┬───────────────────────────────┤
│ ReadWriteOnce │ 단일 노드 읽기/쓰기 │
│ (RWO) │ → 블록(iSCSI/FC). DB에 적합 │
├──────────────────┼───────────────────────────────┤
│ ReadOnlyMany │ 여러 노드 읽기 전용 │
│ (ROX) │ → 설정 파일, 정적 콘텐츠 │
├──────────────────┼───────────────────────────────┤
│ ReadWriteMany │ 여러 노드 읽기/쓰기 │
│ (RWX) │ → NFS/CephFS 필요! │
│ │ → 블록 스토리지는 지원 안 됨 │
└──────────────────┴───────────────────────────────┘
흔한 실수: "RWX가 필요한데 iSCSI만 있다"
→ 설계 단계에서 NAS 또는 CephFS 필요 여부를 확인해야 한다.
구축 후에 "NAS가 없네?"라고 하면 늦는다.K8s 스토리지의 장애 리스크는 설계 시 반영해야 한다. CSI 드라이버 버그로 프로비저닝이 안 될 수 있고, PV의 reclaimPolicy를 Delete로 설정하면 PVC 삭제 시 볼륨이 같이 날아간다. 프로덕션은 반드시 Retain으로 설정해야 한다. 노드 장애 시 RWO 볼륨의 강제 detach까지 수 분이 걸릴 수 있어서, StatefulSet의 RTO에 영향을 준다.
벤더별 가상화/컨테이너 통합 도구:
┌──────────────┬───────────────────────────────────────┐
│ NetApp │ ONTAP Tools for VMware (VASA, SRA) │
│ │ Trident: K8s CSI 드라이버 │
├──────────────┼───────────────────────────────────────┤
│ Dell EMC │ PowerStore Integration for VMware │
│ │ CSI Drivers for PowerStore/PowerScale │
├──────────────┼───────────────────────────────────────┤
│ Pure Storage │ VMware Plugin (vSphere Client 통합) │
│ │ PSO for K8s │
├──────────────┼───────────────────────────────────────┤
│ HPE │ Alletra VMware Integration │
│ │ HPE CSI Driver for K8s │
└──────────────┴───────────────────────────────────────┘Tier 설계 — 성능과 비용의 균형
모든 데이터가 같은 등급의 스토리지에 있을 필요는 없다. 미션 크리티컬 DB와 개발 테스트 데이터가 같은 성능의 디스크 위에 있다면, 비용을 낭비하고 있는 거다.
스토리지 Tier 구조:
┌─────────────────────────────────────────────────────┐
│ Tier 0: 최고 성능 │
│ NVMe 올플래시, <0.5ms 레이턴시 │
│ 용도: 미션 크리티컬 OLTP DB, 실시간 트랜잭션 │
│ 가격: $$$$ (GB당 가장 비쌈) │
│ 장점: 극저지연, 예측 가능한 성능 │
│ 단점: 비용, NVMe 드라이브 수명(쓰기 집중 시) │
├─────────────────────────────────────────────────────┤
│ Tier 1: 고성능 │
│ SAS/TLC SSD 올플래시, <1ms 레이턴시 │
│ 용도: 일반 DB, 가상화, 주요 애플리케이션 │
│ 가격: $$$ │
│ 장점: 대부분의 워크로드에 충분한 성능 │
│ 단점: Tier 0 대비 IOPS 한계, 대용량 시 비용 부담 │
├─────────────────────────────────────────────────────┤
│ Tier 2: 범용 │
│ QLC SSD 또는 하이브리드(SSD+HDD) │
│ 용도: 파일 서버, 개발/테스트, 로그 저장 │
│ 가격: $$ │
│ 장점: 용량 대비 비용 효율, 범용적 │
│ 단점: QLC는 쓰기 내구성 낮음, 하이브리드는 │
│ 캐시 미스 시 HDD 성능으로 급락 │
├─────────────────────────────────────────────────────┤
│ Tier 3: 아카이브 │
│ 대용량 HDD, Object Storage, 테이프(LTO) │
│ 용도: 백업, 장기 보관, 컴플라이언스 │
│ 가격: $ │
│ 장점: 최저 비용, 대용량 │
│ 단점: 레이턴시 수십ms 이상, 랜덤 IO 성능 극히 낮음 │
└─────────────────────────────────────────────────────┘자동 티어링은 자주 접근하는(Hot) 데이터를 상위 Tier로 올리고, 오래 접근 안 한(Cold) 데이터를 하위로 내리는 기능이다.
자동 티어링 동작:
Tier 0 (NVMe) ▲ 자주 접근하는 데이터 승격
───────────── │
Tier 1 (SSD) │ Hot ↑ Cold ↓
───────────── │
Tier 2 (QLC/HDD) ▼ 오래 접근 안 한 데이터 강등
벤더별 구현:
┌──────────────┬──────────────────────────────────────┐
│ NetApp │ FabricPool: 로컬 SSD → 클라우드/ │
│ │ Object Storage로 Cold 데이터 이동 │
│ │ 장점: 클라우드 연동 성숙 │
│ │ 단점: Cold→Hot 복귀 시 읽기 레이턴시 │
│ │ 급증 (네트워크 경유) │
├──────────────┼──────────────────────────────────────┤
│ Dell │ PowerStore 내장 티어링 │
│ │ 장점: 자동, 별도 설정 최소화 │
│ │ 단점: 외부 Object Storage 연동은 제한 │
├──────────────┼──────────────────────────────────────┤
│ Pure Storage │ 티어링 없음. "전부 올플래시"가 철학. │
│ │ CloudSnap으로 스냅샷만 클라우드로. │
│ │ 장점: 티어링 오동작 리스크 없음 │
│ │ 단점: 대용량 콜드 데이터도 비싼 │
│ │ 올플래시에 저장해야 함 │
└──────────────┴──────────────────────────────────────┘자동 티어링의 리스크도 알아야 한다. 티어링 정책이 오동작하면 자주 쓰는 데이터가 느린 계층으로 내려가서 성능이 급락한다. 대표적인 사례가 "월말 결산 배치"다. 평소에 접근이 없으니 Cold로 분류되어 Tier 3로 내려갔다가, 월말에 갑자기 접근하면 느린 계층에서 읽어오느라 성능이 바닥을 친다. Tier 0(NVMe)과 Tier 2(QLC)의 성능 차이가 10~50배에 달하기 때문에, 티어 간 이동 시 사용자 체감 성능의 "절벽"이 생길 수 있다. 자동 티어링을 쓸 때는 반드시 예외 처리(특정 볼륨은 티어링 제외)를 설정하고, 모니터링으로 티어링 이동 현황을 추적해야 한다.
인프라의 뼈대가 잡혔다. 네트워크 이중화로 경로를 확보하고, 플랫폼 환경에 맞는 프로토콜과 데이터스토어를 결정하고, Tier로 성능 등급을 나눴다.
다음 편(7-2)에서는 이 기반 위에 데이터를 배치한다. LUN/볼륨 레이아웃, 네이밍 컨벤션, 스냅샷 정책, DR 복제. "데이터를 어떻게 배치하고 보호할 것인가"를 결정하는 설계의 후반부다.
이 글이 어떠셨나요?
관련 포스트
6. 도입 검토 — 요구사항 분석과 벤더 선정
스토리지 도입 시 워크로드 프로파일링 실패 사례, RAW vs 실효 용량과 리덕션 비율의 함정, 벤더 벤치마크 5가지 함정, PoC 진행법, TCO 숨은 비용, 벤더별 약점, CAPEX vs OPEX 비교, 유지보수 계약과 TPM 장단점까지. 장비를 사기 전에 알아야 할 모든 것.
2026. 05. 04. PM 10:00Infrastructure5. RAID와 데이터 보호 — 전통 RAID부터 이레이저 코딩까지
RAID 0/1/5/6/10의 동작 원리부터 대용량 디스크에서 RAID 5가 위험한 이유, 벤더별 독자 RAID 구현, 이레이저 코딩까지. 데이터를 지키는 기술의 본질을 현장 관점에서 정리한다.
2026. 04. 27. PM 10:00Infrastructure2. 스토리지 아키텍처 기초 — DAS / NAS / SAN / Object Storage
DAS, NAS, SAN, Object Storage의 구조와 차이를 아스키 도표와 함께 정리한다. 어떤 워크로드에 어떤 방식을 선택하는가의 판단 기준과 벤더별 제품 포지셔닝까지.
2026. 04. 06. PM 10:00뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.