안녕하세요.

지난 글에서 다룬 NAS에 이어, 이번에는 기업 스토리지 환경에서 NAS와 자주 짝으로 등장하는 SAN(Storage Area Network) 에 대해 알아보겠습니다.

데이터베이스(DB), 가상화(VM), Kubernetes, 대규모 트랜잭션 시스템처럼 높은 성능과 안정성이 필요한 환경에서는 단순 파일 공유만으로는 한계가 있습니다. 특히 수많은 서버가 빠른 속도로 저장장치에 접근해야 하는 환경에서는 더 높은 성능과 낮은 지연시간(Latency)이 필요합니다.

SAN은 이런 요구사항을 해결하기 위해 등장한 고성능 블록 스토리지 네트워크이며, 현재 데이터센터와 엔터프라이즈 인프라의 핵심 저장 기술 중 하나로 사용되고 있습니다.

 

 

SAN(Storage Area Network)의 개념

SAN(Storage Area Network)은 서버와 스토리지를 연결하는 전용 고속 네트워크입니다.

SAN은 서버와 스토리지를 전용 네트워크로 연결해 서버가 원격 저장장치를 마치 로컬 디스크처럼 사용할 수 있도록 만든 구조입니다.

쉽게 말해 NAS가 "원격 파일 서버"라면, SAN은 "원격 디스크 시스템"에 가깝습니다.

SAN 환경에서는 서버가 스토리지에 블록(Block) 단위로 데이터를 주고받습니다. 파일이 아니라 디스크의 섹터(블록) 단위로 동작하므로, 클라이언트 OS가 직접 파일 시스템을 만들어 올리고 관리합니다. 따라서 OS 입장에서는 네트워크 너머의 스토리지가 일반 SSD·HDD처럼 보입니다.

대표적인 활용 예시는 다음과 같습니다.

  • 대용량 데이터베이스 저장소
  • VMware·Hyper-V 같은 가상화 환경
  • 대규모 서버 클러스터
  • 고성능 가상 디스크 환경
  • 금융·ERP·대형 트랜잭션 시스템
  • 백업·복구 인프라

특히 높은 IOPS와 낮은 지연시간이 중요한 환경에서 SAN이 많이 사용됩니다.

 

 

SAN의 필요성

일반 파일 공유 시스템만으로는 해결하기 어려운 문제들이 존재합니다.

문제 설명
높은 I/O 요구사항 DB·가상화 환경은 매우 많은 디스크 접근 발생
대규모 서버 환경 여러 서버가 동시에 고성능 스토리지 필요
안정성 요구 장애 발생 시에도 데이터 지속성 필요
확장성 문제 저장 용량과 성능을 유연하게 확장해야 함
중앙 스토리지 관리 스토리지를 통합 관리할 필요

특히 DB나 VM 환경에서는 작은 랜덤 I/O가 매우 많이 발생하기 때문에, 전용 고속 네트워크 + 블록 단위 접근 + 다중 경로 구성으로 NAS가 닿지 못하는 성능과 안정성 영역을 커버합니다.

 

 

SAN의 동작 방식

SAN의 기본 구조는 다음과 같습니다.

서버(Initiator) → SAN 스위치 → 스토리지(Target) → LUN

서버는 SAN 네트워크를 통해 스토리지에 접근하고, 스토리지는 블록 디바이스 형태로 저장 공간을 제공합니다.

 

SAN을 구성하는 세 가지 핵심 용어가 있습니다.

용어 설명
Initiator 스토리지에 요청을 보내는 쪽 (서버에 장착된 HBA)
Target 요청을 받는 쪽 (스토리지 컨트롤러)
LUN 스토리지에서 서버에 노출하는 논리적 디스크 단위

 

일반적인 동작 흐름은 다음과 같습니다.

  1. 서버(Initiator)가 스토리지 볼륨 요청
  2. SAN 스위치를 통해 스토리지 연결
  3. 스토리지(Target)가 LUN 제공
  4. 서버 OS가 이를 로컬 디스크처럼 인식
  5. 파일 시스템 생성 후 사용

Linux에서는 SAN 볼륨이 /dev/sdX 형태로 보이는 경우가 많습니다.

lsblk

예시 출력:

sdb      8:16   0   500G  0 disk

OS 입장에서는 네트워크 디스크라는 사실을 거의 의식하지 않고 일반 디스크처럼 사용합니다.

 

 

블록 스토리지(Block Storage)의 개념

SAN을 이해하려면 블록 스토리지 개념이 중요합니다.

블록 스토리지는 데이터를 일정 크기의 블록(Block) 단위로 저장하는 방식입니다.

스토리지 자체에는 파일·디렉토리 같은 구조가 존재하지 않고, 단순히 "몇 번째 블록을 읽고 써라" 수준의 요청만 받습니다.

따라서 책임이 명확히 갈립니다.

  • 파일 시스템 생성·관리 → 서버 OS 담당
  • 실제 블록 저장 → SAN 스토리지 담당

반대로 NAS는 파일 단위(File Level)로 접근하기 때문에 파일 시스템이 NAS 내부에 있고, 클라이언트는 그 위에서 파일을 주고받습니다. 같은 데이터를 다루지만 구조 자체가 다릅니다.

 

 

SAN의 주요 특징

특징 설명
블록 스토리지 블록 단위 저장 방식
고성능 높은 IOPS와 낮은 지연시간
중앙 스토리지 여러 서버가 공유 가능
고가용성 이중화 및 장애 대응 지원
확장성 스토리지 용량 확장 가능
전용 네트워크 스토리지 트래픽 분리 가능

SAN의 핵심은 결국 성능·안정성·확장성입니다.

 

 

SAN의 구조

SAN은 크게 다음과 같은 구성 요소로 이루어집니다.

구성 요소 설명
서버(Server) 스토리지를 사용하는 시스템
SAN 스위치 서버와 스토리지를 연결
스토리지 어레이 실제 데이터 저장 장비
HBA 카드 SAN 네트워크 연결 장치
디스크 시스템 SSD/HDD 저장 장치

특히 Fibre Channel 기반 SAN에서는 서버에 HBA(Host Bus Adapter)라는 전용 카드가 장착됩니다.

일반 LAN 카드(NIC)와 비슷하지만, SAN 전용 프로토콜을 처리하기 위한 장비입니다.

여기에 더해 SAN 운영에서 빠지지 않는 두 개념이 있습니다.

  • Zoning : SAN 스위치 단에서 어떤 서버가 어떤 스토리지 포트에 접근 가능한지 제한
  • LUN Masking : 스토리지 단에서 어떤 서버에 어떤 LUN을 노출할지 제한

이 둘은 보안과 격리의 기본이며, 잘못 설정하면 한 서버가 다른 서버의 LUN을 덮어쓰는 사고로 이어집니다.

 

 

SAN의 주요 프로토콜

SAN은 어떤 프로토콜을 쓰느냐에 따라 인프라 성격이 크게 달라집니다.

프로토콜 매체 특징
FC (Fibre Channel) 전용 광케이블 가장 전통적, 고성능·저레이턴시
iSCSI 일반 IP 네트워크 TCP/IP 기반, 비용 효율적
FCoE (FC over Ethernet) 이더넷 FC 트래픽을 이더넷에 실음
NVMe-oF (NVMe over Fabrics) FC / RoCE / TCP NVMe SSD의 성능을 네트워크로 확장

FC는 8·16·32·64 Gbps 대역폭을 제공하며 별도 패브릭(전용망)을 요구합니다.

iSCSI는 일반 이더넷 위에서 동작해 도입 장벽이 낮고, 최근에는 25·100 GbE 보급으로 FC와 성능 격차가 줄었습니다.

NVMe-oF는 최신 트렌드로, 플래시 스토리지의 잠재력을 네트워크 너머까지 끌고 가는 기술입니다.

 

 

Fibre Channel(FC)의 개념

SAN에서 가장 대표적으로 사용되는 기술이 Fibre Channel(FC)입니다.

Fibre Channel은 고속 스토리지 네트워크를 위한 전용 통신 기술로, 매우 낮은 지연시간과 높은 안정성을 제공합니다.

특징 설명
고속 전송 16·32·64 Gbps 대역폭
낮은 지연시간 스토리지 전용 네트워크
높은 안정성 기업 환경 최적화
전용 장비 사용 FC 스위치·HBA·전용 케이블 필요

다만 구축 비용이 높기 때문에 대규모 엔터프라이즈 환경에서 주로 사용됩니다.

 

 

iSCSI의 개념

SAN은 반드시 Fibre Channel만 사용하는 것은 아닙니다.

iSCSI(Internet Small Computer System Interface)는 TCP/IP 기반 네트워크 위에서 SAN을 구현하는 기술입니다.

즉, 일반 이더넷 네트워크를 이용해 블록 스토리지를 사용할 수 있습니다.

구분 Fibre Channel iSCSI
네트워크 전용 FC 네트워크 일반 Ethernet
비용 높음 비교적 저렴
성능 매우 높음 네트워크 영향 받음
사용 환경 대기업·데이터센터 중소규모 환경

최근에는 10·25 GbE 환경이 보편화되면서 iSCSI 사용도 매우 많아졌습니다. 더 나아가 NVMe SSD의 성능을 네트워크 너머까지 확장하는 NVMe-oF(NVMe over Fabrics) 도 차세대 SAN 프로토콜로 주목받고 있습니다.

 

 

LUN(Logical Unit Number)의 개념

SAN에서 자주 등장하는 개념이 LUN(Logical Unit Number) 입니다.

LUN은 스토리지에서 서버에 제공하는 논리적 디스크 단위입니다.

예를 들어 스토리지 관리자가 1TB 공간을 할당하면, 서버는 이를 하나의 디스크처럼 인식합니다.

전체 흐름을 정리하면 다음과 같습니다.

물리 디스크 → RAID 그룹 → 스토리지 풀 → LUN → 서버에 할당

서버는 LUN만 봅니다. 실제 디스크 구성과 RAID 레벨은 스토리지 운영자만 알면 됩니다.

이 추상화 덕분에 디스크 교체·확장을 서버 영향 없이 수행할 수 있습니다.

 

 

멀티패스(Multipath)의 개념

SAN 환경에서는 안정성을 위해 멀티패스(Multipath) 구성을 자주 사용합니다.

이는 서버와 스토리지 사이 경로(Path)를 여러 개 구성하는 방식입니다.

서버 ↔ 스위치 A ↔ 스토리지
서버 ↔ 스위치 B ↔ 스토리지

이렇게 이중 경로를 구성하면 다음과 같은 효과가 있습니다.

  • 한 경로 장애 발생 시 자동 우회
  • 부하 분산 가능
  • 고가용성 확보

실무 SAN 환경에서는 거의 필수적으로 사용됩니다.

 

 

RAID와 LUN의 관계

SAN에서도 RAID는 기본 전제로 깔립니다. 다만 SAN에서는 한 단계 더 들어갑니다.

물리 디스크 → RAID 그룹 → 스토리지 풀 → LUN → 서버에 할당

스토리지 컨트롤러가 물리 디스크들을 RAID로 묶고, 그 위에 스토리지 풀을 만들고, 풀에서 잘라낸 조각이 LUN입니다.

이 추상화 덕분에 얻는 이점은 다음과 같습니다.

  • 서버 입장에서는 디스크 한 개를 받은 것처럼 단순
  • 스토리지 운영자는 RAID·디스크 교체·확장을 서버 영향 없이 수행
  • 동일 풀의 LUN끼리는 성능·용량을 유연하게 분배

 

 

SAN과 NAS의 차이

SAN과 NAS는 자주 비교되는 저장 기술입니다. 가장 큰 차이는 저장 접근 방식입니다.

구분 SAN NAS
저장 방식 블록 스토리지 파일 스토리지
접근 단위 Block Level File Level
주요 프로토콜 FC, iSCSI SMB, NFS
사용 목적 DB·VM·고성능 환경 파일 공유
성능 매우 높음 상대적으로 낮음
비용 높음 비교적 저렴
동시 공유 단일 호스트 점유 원칙 여러 클라이언트 동시 R/W

간단히 정리하면:

  • NAS → 파일을 공유
  • SAN → 디스크를 빌려줌

SAN의 LUN은 기본적으로 한 호스트가 점유합니다.

여러 호스트가 동시에 한 LUN을 쓰려면 VMware VMFS, GFS2, OCFS2 같은 클러스터 파일시스템이 별도로 필요합니다.

 

 

SAN의 장점

장점 설명
고성능 저레이턴시·고 IOPS로 미션 크리티컬에 적합
확장성 LUN 단위 유연한 할당과 확장
안정성 Multipath, 컨트롤러 이중화 등 HA 구성
중앙 집중 관리 여러 서버의 스토리지를 한 곳에서 운영
가상화 친화 VMware, Hyper-V 데이터스토어 표준

DB와 가상화 환경이 SAN을 선호하는 이유는 결국 레이턴시와 안정성입니다. NAS로는 닿지 못하는 영역입니다.

 

 

SAN의 단점

단점 설명
도입 비용 FC SAN은 스위치·HBA·라이선스 모두 고가
운영 난이도 Zoning·LUN Masking·Multipath 등 학습 곡선 존재
확장 설계 부담 패브릭 설계 실수는 확장 시 큰 비용으로 돌아옴
동시 접근 제약 클러스터 파일시스템 없이는 공유 불가
벤더 종속 스토리지·스위치 벤더 의존도 큼

특히 FC 기반 SAN은 초기 투자 비용과 운영 인력 부담이 크기 때문에, 중소 규모 환경에서는 iSCSI SAN으로 시작하는 경우가 많습니다.

 

 

SAN이 많이 사용되는 분야

분야 설명
DB 고성능 트랜잭션 처리
가상화(VMware) VM 디스크 저장소
ERP 시스템 대규모 기업 업무 시스템
금융 시스템 고가용성 요구 환경
Kubernetes CSI 기반 블록 스토리지
데이터센터 중앙 스토리지 인프라

특히 VMware vSphere 환경에서는 SAN 스토리지가 사실상 표준처럼 사용되는 경우가 많습니다.

 

 

SAN과 Kubernetes

최근 Kubernetes 환경에서도 SAN 기반 블록 스토리지가 많이 사용됩니다.

대표적으로 CSI(Container Storage Interface)를 통해 SAN 볼륨을 Pod에 연결할 수 있습니다.

# SAN 기반 StorageClass를 사용한 PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-pvc
spec:
  storageClassName: san-block      # SAN 기반 StorageClass
  accessModes:
    - ReadWriteOnce                # 단일 Pod 점유 (SAN LUN 특성)
  resources:
    requests:
      storage: 100Gi

여기서 ReadWriteOnce가 핵심입니다. 앞에서 언급한 "SAN LUN은 단일 호스트 점유"라는 특성이 K8s 액세스 모드에 그대로 반영됩니다. NFS 기반 NAS PV가 ReadWriteMany로 여러 Pod이 공유하던 것과 대비되는 지점입니다.

DB Pod처럼 높은 I/O 성능이 필요한 워크로드는 이런 SAN 기반 PV를 사용하는 경우가 많습니다.

 

 

클라우드 시대에도 SAN이 중요한 이유

클라우드 환경이 대중화된 지금도 SAN 개념은 여전히 중요합니다.

AWS EBS, Azure Managed Disk, GCP Persistent Disk 같은 클라우드 블록 스토리지는 본질적으로 클라우드 위의 SAN입니다. EBS 볼륨을 EC2에 붙이면 /dev/xvdf 같은 블록 디바이스로 잡히고, 그 위에 파일시스템을 올립니다.

SAN의 LUN 개념과 동일한 모델이며, 단일 인스턴스 attach가 원칙이라는 제약까지 닮았습니다.

다만 클라우드 블록 스토리지에는 몇 가지 특징이 있습니다.

  • 단일 인스턴스 attach가 원칙 (전통 SAN과 동일한 제약)
  • IOPS·처리량을 비용으로 구매 (예: gp3, io2 티어)
  • 스냅샷 기반의 백업·복제가 표준

즉, 물리적인 FC SAN이 줄어드는 추세일 뿐 "블록 스토리지 네트워크"라는 개념 자체는 지금도 클라우드 인프라의 핵심 기술로 이어지고 있습니다. 온프레미스 SAN은 미션 크리티컬·대규모 가상화 영역에서, 클라우드 블록 스토리지는 퍼블릭 클라우드 워크로드에서 각자 자리를 지키는 구도입니다.

 

 

마무리 정리

SAN은 서버와 스토리지를 전용 네트워크로 연결해, 고성능 블록 스토리지를 제공하는 기술입니다.

입문자 입장에서 SAN을 이해할 때 챙겨야 할 핵심은 세 가지입니다.

  1. SAN은 파일 공유가 아니라 블록 스토리지 구조 — 파일시스템은 서버가 올린다
  2. DB·가상화처럼 높은 IOPS 환경에 적합 — FC와 iSCSI가 대표 프로토콜
  3. 단일 호스트 점유가 원칙 — 공유하려면 클러스터 파일시스템이 필요

NAS가 파일 서버에 가깝다면, SAN은 서버가 직접 사용하는 고성능 원격 디스크 시스템에 가깝습니다.

둘은 경쟁 기술이 아니라 역할이 다른 도구이며, 현재도 데이터센터·클라우드·가상화 환경에서 각자 자리에서 활용되고 있습니다.

 

읽어주셔서 감사합니다.

 

 

참조

저작자표시 비영리 변경금지 (새창열림)

'Infra' 카테고리의 다른 글

NAS(Network Attached Storage)  (0) 2026.05.19
Kubernetes  (0) 2026.05.17
UNIX  (0) 2026.05.16
Linux  (0) 2026.05.14
Docker  (0) 2025.07.03

티스토리툴바