4. 프로토콜 깊이 파기 — FC / iSCSI / NFS / SMB / S3
FC Zoning과 ALUA, iSCSI 네트워크 설계, NFS 마운트 옵션, SMB 멀티채널, S3 API까지. 스토리지 프로토콜의 동작 원리와 실무 설정 포인트를 아스키 도표와 함께 정리한다.
"스토리지 연결했는데 LUN이 안 보여요."
이 한마디를 듣고 원인을 찾으려면, 프로토콜을 알아야 한다. FC라면 Zoning을 확인해야 하고, iSCSI라면 이니시에이터 설정을 봐야 하고, NFS라면 Export 정책을 체크해야 한다. 프로토콜에 따라 문제를 찾는 경로가 완전히 다르다.
2편에서 SAN은 블록, NAS는 파일이라고 했다. 이번 편에서는 그 위를 달리는 프로토콜들 — FC, iSCSI, NFS, SMB, S3 — 을 하나씩 파본다. 동작 원리를 알면 장애 원인을 추적하는 속도가 달라진다.
Fibre Channel — SAN의 전통 강자
FC(Fibre Channel)는 스토리지 전용으로 설계된 네트워크 프로토콜이다. 이더넷과는 완전히 다른 세계다.
┌─────────────────────────────────────────────────────┐
│ FC SAN 기본 구조 │
│ │
│ 서버A ──HBA──┐ ┌── 스토리지 │
│ (WWPN: │ ┌──────────┐ │ 포트A │
│ 10:00:...:01)├────►│ FC Switch├──►│ (WWPN: │
│ │ │ (Fabric) │ │ 50:00:...:0a)│
│ 서버B ──HBA──┘ │ │ │ │
│ (WWPN: │ Zoning │ │ 포트B │
│ 10:00:...:02) │ 테이블 │ │ (WWPN: │
│ └──────────┘ │ 50:00:...:0b)│
│ └────────────────│
│ │
│ HBA: Host Bus Adapter (서버의 FC 카드) │
│ WWPN: World Wide Port Name (FC 포트의 고유 주소) │
│ Fabric: FC Switch들로 구성된 네트워크 │
└─────────────────────────────────────────────────────┘FC에서 가장 중요한 개념은 Zoning이다. IP 네트워크의 방화벽 규칙 같은 거다. "서버 A의 HBA 포트(WWPN)는 스토리지의 포트 A(WWPN)와 통신할 수 있다"는 규칙을 FC Switch에 설정하는 거다.
Zoning을 안 하면 Fabric에 연결된 모든 장비가 서로 보인다. 이러면 한 서버가 다른 서버의 LUN에 접근해서 데이터를 덮어쓸 수 있다. 그래서 Zoning은 선택이 아니라 필수다.
Zoning 방식:
WWPN Zoning (권장) Port Zoning
───────────────── ──────────────
Zone1: Zone1:
10:00:...:01 (서버A HBA) Switch Port 1
50:00:...:0a (스토리지A) Switch Port 5
서버를 다른 포트로 옮겨도 서버를 다른 포트로 옮기면
Zoning이 유지된다 Zoning을 다시 설정해야 한다
→ 현장에서는 거의 WWPN Zoning을 쓴다FC에서 서버가 스토리지에 연결되는 과정을 간략하게 보면 이렇다.
1. FLOGI (Fabric Login)
서버 HBA → FC Switch: "나 접속할게요" → FC ID 할당받음
2. PLOGI (Port Login)
서버 HBA → 스토리지 포트: "당신과 통신하겠습니다"
3. PRLI (Process Login)
SCSI 프로토콜 레벨 세션 수립
4. LUN Discovery
서버가 스토리지에서 접근 가능한 LUN 목록을 확인
장애 시: nameserver show, fcns database를 확인하면
어디서 끊겼는지 추적할 수 있다.ALUA(Asymmetric Logical Unit Access)도 알아야 한다. 듀얼 컨트롤러 스토리지에서 LUN이 어느 컨트롤러에 "소유"되어 있는가의 개념이다.
┌─────────────────────────────────────────────┐
│ ALUA 개념 │
│ │
│ 서버 ────► 컨트롤러A (Active/Optimized) │
│ │ └─ LUN 001의 소유자 │
│ │ └─ 이 경로가 최적 │
│ │ │
│ └──────► 컨트롤러B (Active/Non-Optimized) │
│ └─ LUN 001에 접근 가능 │
│ └─ 하지만 내부적으로 A를 거침 │
│ └─ 약간 느림 │
│ │
│ 멀티패스 소프트웨어가 ALUA 상태를 보고 │
│ 최적 경로로 IO를 보낸다. │
└─────────────────────────────────────────────┘서버의 멀티패스 소프트웨어(Linux dm-multipath 등)가 ALUA 상태를 인식해서 Optimized 경로로 IO를 우선 보낸다. 이걸 제대로 설정 안 하면 모든 IO가 Non-Optimized 경로로 가서 성능이 떨어진다. "연결은 됐는데 왜 느리지?" 하면 ALUA 설정을 의심해봐야 한다.
iSCSI — IP 네트워크 위의 블록 스토리지
iSCSI는 SCSI 명령을 TCP/IP로 캡슐화해서 전송한다. FC처럼 전용 네트워크가 아니라 기존 이더넷을 쓸 수 있다는 게 핵심이다.
┌──────────────────────────────────────────────────┐
│ FC vs iSCSI 프로토콜 스택 │
│ │
│ FC iSCSI │
│ ┌──────────┐ ┌──────────┐ │
│ │ SCSI │ │ SCSI │ │
│ ├──────────┤ ├──────────┤ │
│ │ FC-4 │ │ iSCSI │ │
│ ├──────────┤ ├──────────┤ │
│ │ FC-2 │ │ TCP │ │
│ ├──────────┤ ├──────────┤ │
│ │ FC-1 │ │ IP │ │
│ ├──────────┤ ├──────────┤ │
│ │ FC-0 │ │ Ethernet │ │
│ └──────────┘ └──────────┘ │
│ 전용 프로토콜 스택 IP 위에 얹음 │
└──────────────────────────────────────────────────┘iSCSI의 네트워크 설계에서 자주 하는 실수가 있다.
✗ 잘못된 구성: 일반 트래픽과 iSCSI가 같은 네트워크
서버 ──┐
├── [같은 스위치/같은 VLAN] ──► 스토리지 iSCSI 포트
일반 ─┘
트래픽 웹 트래픽이 몰리면 iSCSI IO가 밀린다
✓ 올바른 구성: iSCSI 전용 네트워크 분리
서버 NIC1 ──── [전용 스위치/전용 VLAN] ──► 스토리지 iSCSI 포트A
서버 NIC2 ──── [전용 스위치/전용 VLAN] ──► 스토리지 iSCSI 포트B
서버 NIC3 ──── [일반 네트워크] ──► 서비스 트래픽
iSCSI는 반드시 전용 VLAN에 격리한다.
Jumbo Frame(MTU 9000)은 벤더 권장사항을 따른다.올플래시 시대에 FC와 iSCSI의 성능 차이는 많이 줄었다. HDD 시대에는 디스크가 병목이어서 프로토콜 오버헤드가 눈에 안 보였고, 올플래시에서는 프로토콜 레이턴시가 상대적으로 드러나지만, 25GbE 이상에서는 대부분의 워크로드에서 체감 차이가 미미하다. "FC를 꼭 써야 하나?"라는 질문에 대한 답은 "워크로드와 기존 인프라에 따라 다르다"이다.
다만 장애 대응 관점에서 iSCSI의 약점은 분명하다. TCP 기반이라 네트워크 혼잡이 발생하면 IO 레이턴시가 예측 불가능하게 튄다. FC는 Flow Control이 프레임 레벨에서 동작하지만, iSCSI는 TCP의 congestion control에 의존하기 때문에 패킷 유실 → 재전송 → 레이턴시 급증 패턴이 나타난다. 경로 장애 감지도 FC(수 초)보다 느리다 — iSCSI는 TCP 세션 타임아웃(기본 수십 초)이 지나야 경로 전환이 일어나므로, 그 사이에 IO가 멈출 수 있다. 이런 이유로 Oracle RAC 같은 초저지연 미션 크리티컬 환경에서는 여전히 FC가 선호된다.
NFS — 리눅스 환경의 표준 파일 공유
NFS(Network File System)는 리눅스/유닉스 환경에서 파일을 공유하는 표준이다. VMware의 NFS 데이터스토어도 NFS다.
NFSv3와 NFSv4의 차이는 실무에서 중요하다.
┌──────────────────────────────────────────────────────┐
│ NFSv3 vs NFSv4 핵심 차이 │
├──────────────────┬───────────────┬────────────────────┤
│ │ NFSv3 │ NFSv4(.1/.2) │
├──────────────────┼───────────────┼────────────────────┤
│ 상태 관리 │ Stateless │ Stateful │
│ │ (상태 없음) │ (상태 유지) │
├──────────────────┼───────────────┼────────────────────┤
│ 파일 잠금 │ NLM 별도 필요 │ 프로토콜 내장 │
├──────────────────┼───────────────┼────────────────────┤
│ 포트 │ 여러 포트 │ TCP 2049 단일 │
│ │ (portmapper) │ (방화벽 친화적) │
├──────────────────┼───────────────┼────────────────────┤
│ 보안 │ IP 기반 │ Kerberos 지원 │
├──────────────────┼───────────────┼────────────────────┤
│ 성능 │ 검증됨, 안정적│ pNFS로 병렬 IO │
├──────────────────┼───────────────┼────────────────────┤
│ 현장 사용 │ 아직 많음 │ 점차 전환 중 │
└──────────────────┴───────────────┴────────────────────┘NFS 마운트 옵션이 성능에 미치는 영향은 생각보다 크다. 실수 하나로 성능이 반토막 날 수 있다.
# 기본 마운트 (성능 최적화 안 됨)
mount -t nfs server:/vol /mnt
# 성능 최적화된 마운트
mount -t nfs -o rw,hard,nointr,rsize=1048576,wsize=1048576,\
tcp,vers=3,actimeo=0 server:/vol /mnt
핵심 옵션:
┌──────────────┬────────────────────────────────────┐
│ rsize/wsize │ 읽기/쓰기 블록 크기. 기본값이 작을 │
│ │ 수 있으니 1MB로 올린다. 처리량 증가 │
├──────────────┼────────────────────────────────────┤
│ hard vs soft │ hard: 서버 응답 올 때까지 대기 │
│ │ soft: 타임아웃 후 에러 리턴 │
│ │ → 데이터 무결성 위해 hard 권장 │
├──────────────┼────────────────────────────────────┤
│ actimeo │ 속성 캐시 시간. 0이면 항상 최신 │
│ │ DB용은 0, 일반 파일은 60 정도 │
├──────────────┼────────────────────────────────────┤
│ nconnect │ (NFSv4.1+) TCP 연결 수 증가 │
│ │ 단일 마운트의 처리량 한계 극복 │
└──────────────┴────────────────────────────────────┘
흔한 실수: rsize/wsize를 기본값으로 두고 "NFS 느리다"고 불평NFS 트러블슈팅에서 가장 흔한 증상은 "stale file handle"이다. 서버에서 볼륨이나 Export를 변경했는데 클라이언트 캐시에 옛날 정보가 남아있으면 발생한다. umount 후 다시 mount하면 보통 해결된다.
SMB — Windows 세계의 파일 공유
SMB(Server Message Block)는 Windows 환경의 기본 파일 공유 프로토콜이다. 예전에는 CIFS라고도 불렸는데, 지금은 SMB가 공식 이름이다.
SMB 3.0 이후로 기업용으로 쓸 만한 기능이 많이 추가됐다.
┌──────────────────────────────────────────────────────┐
│ SMB 버전별 핵심 기능 │
├──────────┬───────────────────────────────────────────┤
│ SMB 1.0 │ 레거시. 보안 취약. WannaCry 공격 벡터. │
│ │ → 절대 쓰지 말 것 │
├──────────┼───────────────────────────────────────────┤
│ SMB 2.x │ 성능 개선, 요청 파이프라이닝 │
├──────────┼───────────────────────────────────────────┤
│ SMB 3.0 │ 멀티채널 (여러 NIC 동시 사용) │
│ │ SMB Direct (RDMA 지원, 네트워크 바이패스) │
│ │ 암호화 지원 │
│ │ → Hyper-V 공유 스토리지로 사용 가능 │
├──────────┼───────────────────────────────────────────┤
│ SMB 3.1.1│ 사전인증 무결성, AES-128-GCM 암호화 │
│ │ → 현재 권장 버전 │
└──────────┴───────────────────────────────────────────┘SMB 멀티채널은 하나의 SMB 세션에 여러 NIC를 동시에 사용하는 기능이다. 10GbE NIC 두 장이면 이론상 20Gbps 처리량이 나온다. NFS에서 nconnect와 비슷한 개념이지만 SMB 쪽이 먼저 구현했다.
Linux에서 SMB를 마운트할 일도 있다. mount -t cifs 또는 mount.cifs를 쓴다. Windows AD 환경과 연동할 때 Kerberos 인증 설정이 좀 까다로울 수 있다.
SMB의 단점도 짚어야 한다. 가장 큰 리스크는 보안 이력이다. SMB 1.0은 WannaCry 랜섬웨어의 공격 벡터였고, 절대 활성화하면 안 된다. 그런데 레거시 시스템 때문에 SMB 1.0을 끄지 못하는 현장이 아직 있다. Linux 환경에서의 SMB 호환성도 완벽하지 않다. cifs 마운트 시 파일 권한 매핑이 POSIX와 다르게 동작해서 예상치 못한 접근 거부가 발생하기도 한다. 또한 SMB는 AD(Active Directory)에 대한 의존도가 높아서, AD에 장애가 나면 인증 전체가 막힐 수 있다.
S3 — HTTP로 접근하는 오브젝트
S3는 AWS가 만든 오브젝트 스토리지 API인데, 사실상 표준이 됐다. 온프레미스 스토리지도 S3 호환 API를 제공하는 게 당연해졌다.
전통 프로토콜 vs S3 API:
FC/iSCSI: 서버 ──블록 디바이스로 마운트──► dd, mkfs
NFS/SMB: 서버 ──파일시스템 마운트──────► ls, cp, cat
S3: 앱 ───HTTP REST API 호출─────► PUT, GET, DELETE
# S3 API 사용 예시 (aws-cli)
aws s3 cp backup.tar s3://my-bucket/backup/
aws s3 ls s3://my-bucket/
aws s3api put-object --bucket my-bucket --key data.csv --body data.csv
파일시스템처럼 마운트하는 게 아니라,
HTTP 요청으로 오브젝트를 넣고 빼는 방식이다.S3에서 알아두면 좋은 기능은 버전닝과 라이프사이클 정책이다. 버전닝을 켜면 같은 키에 대한 이전 버전이 보존되어 실수로 덮어써도 복구가 가능하다. 라이프사이클 정책으로 "30일 지난 오브젝트는 Glacier로 이동", "90일 지난 건 삭제" 같은 자동화가 된다. 이건 온프레미스 S3 호환 스토리지(MinIO, StorageGRID)에서도 대부분 지원한다.
S3의 단점은 레이턴시와 접근 모델의 제약이다. HTTP 기반이라 첫 바이트까지의 시간(TTFB)이 수~수십 밀리초로, 블록/파일 프로토콜 대비 느리다. 오브젝트의 일부만 수정하는 게 불가능하고 전체를 다시 업로드해야 한다. 클라우드 S3에서는 API 호출 자체에 비용이 발생하기 때문에(PUT/GET 건당 과금), 소량의 오브젝트를 빈번하게 읽고 쓰는 패턴에서는 비용이 예상보다 크게 나올 수 있다. 장애 시 복구 관점에서는 S3가 "결과적 일관성(eventual consistency)"이었던 시절의 습관이 남아있는 애플리케이션이 있을 수 있으니, 쓰기 직후 읽기가 보장되는지 구현별로 확인해야 한다.
프로토콜 선택 가이드
┌──────────────────────────────────────────────────────┐
│ 프로토콜 선택 종합 가이드 │
├──────────┬────────┬──────────┬───────┬───────┬───────┤
│ │ FC │ iSCSI │ NFS │ SMB │ S3 │
├──────────┼────────┼──────────┼───────┼───────┼───────┤
│ 접근레벨 │ 블록 │ 블록 │ 파일 │ 파일 │오브젝트│
├──────────┼────────┼──────────┼───────┼───────┼───────┤
│ 네트워크 │ FC전용 │ 이더넷 │이더넷 │이더넷 │이더넷 │
├──────────┼────────┼──────────┼───────┼───────┼───────┤
│ 레이턴시 │ 최저 │ 낮음 │ 낮음 │ 낮음 │ 높음 │
├──────────┼────────┼──────────┼───────┼───────┼───────┤
│ 공유 │ 1:1 │ 1:1 │ 1:N │ 1:N │ 1:N │
│ │(기본) │(기본) │ │ │ │
├──────────┼────────┼──────────┼───────┼───────┼───────┤
│ 대표 │ 미션 │ 가상화, │Linux │Windows│백업, │
│ 사용처 │크리티컬│ 중소DB │파일 │파일 │아카이브│
│ │ DB │ │공유 │공유 │비정형 │
├──────────┼────────┼──────────┼───────┼───────┼───────┤
│ 비용 │ 높음 │ 중간 │ 낮음 │ 낮음 │ 낮음 │
└──────────┴────────┴──────────┴───────┴───────┴───────┘프로토콜을 잘 이해하면 장애 대응 속도가 빨라진다. "LUN이 안 보인다"가 FC Zoning 문제인지, LUN Masking 문제인지, 멀티패스 문제인지를 빠르게 판단할 수 있다. 프로토콜은 스토리지 엔지니어의 기본 무기다.
다음 편에서는 RAID와 데이터 보호를 다룬다. RAID 5가 왜 대용량 디스크에서 위험한지, 벤더마다 RAID 구현이 왜 다른지, 이레이저 코딩은 뭐가 다른지. 데이터를 지키는 기술의 본질을 파본다.
이 글이 어떠셨나요?
관련 포스트
3. 병렬 파일 시스템과 분산 스토리지 — Lustre, GPFS, HDFS
Lustre, GPFS, BeeGFS, HDFS, Ceph, MinIO까지. HPC와 AI 학습 환경에서 병렬 파일 시스템과 분산 스토리지가 왜 필요한지, 각각의 아키텍처와 포지셔닝을 현장 관점에서 비교한다.
2026. 04. 13. 오후 10:00Infrastructure2. 스토리지 아키텍처 기초 — DAS / NAS / SAN / Object Storage
DAS, NAS, SAN, Object Storage의 구조와 차이를 아스키 도표와 함께 정리한다. 어떤 워크로드에 어떤 방식을 선택하는가의 판단 기준과 벤더별 제품 포지셔닝까지.
2026. 04. 06. 오후 10:00Infrastructure1. 스토리지, 왜 어렵고 왜 중요한가
서버는 죽어도 살리면 되지만 스토리지는 잃으면 끝이다. 10년차 시스템 엔지니어가 스토리지가 어렵고 중요한 이유, 스토리지 담당자의 실제 업무, 기술의 진화 흐름을 현장 경험 기반으로 풀어본다.
2026. 03. 30. 오후 10:00뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.