하드웨어 중급 #7 스토리지 네트워크 — iSCSI, FC, NVMe-oF, 멀티패스

인프라 하드웨어
5 분 소요

6편까지의 디스크는 서버 안에 있었습니다. 그런데 기초 5편에서 본 것처럼, 규모가 커지면 스토리지는 서버 밖의 공용 장비(SAN)로 나가고 서버는 네트워크 너머의 디스크를 제 것처럼 씁니다. 이번 글은 그 “네트워크 너머의 블록 장치"를 실제로 잇는 기술들입니다. 같은 SAN이라도 무엇으로 잇느냐에 따라 비용과 운영이 크게 달라집니다.

먼저 경계 하나를 분명히 해 두겠습니다. 이 글은 블록 스토리지(서버에 디스크처럼 보이는 것)의 이야기입니다. 파일 단위로 공유하는 NFS·Samba는 RHEL 중급 #3의 영역이고, 층이 다릅니다.

iSCSI — 평범한 네트워크로 잇는 SAN #

iSCSI는 디스크 명령(SCSI)을 평범한 TCP/IP 네트워크에 실어 보내는 프로토콜입니다. 서버(이니시에이터)가 스토리지(타깃)에 로그인하면, 네트워크 너머의 볼륨이 로컬 디스크처럼(/dev/sdX) 나타납니다.

강점은 단연 보편성입니다. 전용 장비 없이 기존 이더넷과 스위치로 시작할 수 있고, 운영 지식도 일반 네트워크의 연장입니다. 대신 그만큼 일반 네트워크의 문제를 그대로 물려받습니다. 다른 트래픽과의 경합, TCP 의 지연 변동이 디스크 지연으로 직결됩니다. 그래서 iSCSI 운영의 제1원칙은 스토리지 트래픽의 분리입니다. 전용 NIC 와 전용 네트워크(최소한 전용 VLAN)를 주고, 서비스 트래픽과 섞지 않는 것입니다.

FC — 스토리지 전용으로 태어난 네트워크 #

FC(Fibre Channel)는 처음부터 스토리지용으로 설계된 별도의 네트워크입니다. 전용 어댑터(HBA)와 전용 스위치로 SAN 패브릭을 짜고, 어느 서버가 어느 볼륨을 보는지를 조닝(zoning)으로 통제합니다.

iSCSIFC
네트워크기존 이더넷전용 패브릭(HBA, FC 스위치)
비용·진입낮음높음
지연의 일관성구성에 따라 변동안정적
운영 지식네트워크 팀의 연장별도 전문 영역(조닝 등)

요지는 우열이 아니라 거래입니다. FC는 일관된 지연과 격리를 돈과 전문성으로 사는 선택이고, iSCSI는 보편성을 택하는 대신 네트워크 설계 책임을 운영자가 지는 선택입니다. 미션 크리티컬 DB에서 FC가 주류였던 이유와, 가상화·일반 워크로드에서 iSCSI가 널리 쓰이는 이유가 이 표 안에 있습니다.

NVMe-oF — 빠른 디스크에는 빠른 길을 #

기초 4편에서 NVMe가 SATA의 명령 체계를 버리고 플래시에 맞게 다시 설계된 인터페이스라는 것을 봤습니다. 같은 일이 네트워크에서도 반복됩니다. SCSI를 실어 나르는 iSCSI/FC 위에 NVMe 디스크를 두면 프로토콜 변환이 끼는데, NVMe-oF(NVMe over Fabrics)는 NVMe 명령을 변환 없이 네트워크(이더넷의 RDMA, FC, 또는 일반 TCP)로 확장해 그 간극을 없앱니다. 로컬 NVMe에 가까운 지연을 네트워크 너머에서 내는 것이 목표입니다.

운영자 관점의 위치는 이렇습니다. 전부 플래시인 최신 스토리지와 저지연이 중요한 워크로드의 조합에서 표준이 되어 가는 중이고, 그중 NVMe/TCP는 특별한 NIC 없이도 동작해 iSCSI를 대신해 보급되고 있습니다. 새 SAN을 설계한다면 “iSCSI냐 FC냐"에 “NVMe-oF는 아닌가"를 함께 묻는 시대입니다.

멀티패스 — 길이 끊겨도 디스크는 살아야 한다 #

무엇으로 잇든, 네트워크 너머의 디스크에는 새 고장 모드가 생깁니다. 디스크는 멀쩡한데 길(케이블, 스위치, 어댑터)이 끊기는 경우입니다. 그래서 SAN은 길을 두 개 이상 두는 것이 기본이고, 그 길들을 하나의 디스크로 묶어 관리하는 것이 멀티패스(multipath, 같은 볼륨으로 가는 여러 경로를 묶어 장애 시 전환과 부하 분산을 하는 기능)입니다.

multipath -ll (요약) 
mpatha (3600a0980...) dm-2 VENDOR,MODEL
size=2.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:1  sdb  8:16  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:1  sdc  8:32  active ready running

리눅스의 device-mapper multipath가 두 경로(sdb, sdc)를 mpatha 하나로 묶은 모습입니다. 운영 포인트는 세 가지입니다.

  • 애플리케이션은 반드시 묶인 장치(mpatha)를 씁니다. sdb를 직접 쓰면 그 경로가 끊기는 순간 I/O 가 멈춥니다.
  • 경로 하나가 죽은 상태는 6편의 디그레이드와 같은 의미입니다. 서비스는 돌지만 여유가 사라진 상태이므로, 경로 상태도 알림 대상입니다.
  • 정책을 이해하고 둡니다. 모든 경로를 함께 쓰는 분산형이 기본이지만, 스토리지에 따라 우선 경로가 있는 구성(ALUA)도 있어서 스토리지 벤더의 권장 설정을 따르는 것이 안전합니다.

클라우드에서는 — 같은 구조의 재포장 #

클라우드의 블록 스토리지(EBS 같은)는 정확히 이 글의 구조물입니다. 인스턴스에 붙는 볼륨은 로컬 디스크가 아니라 네트워크 너머의 블록 장치이고, 이중화된 경로와 스토리지 장비를 클라우드가 대신 운영해 주는 것입니다. 5편에서 본 “볼륨과 인스턴스 양쪽의 한도"도 이 구조의 결과입니다. 디스크 I/O 가 결국 네트워크 대역폭을 지나가기 때문입니다. 온프레미스의 SAN 지식이 클라우드에서 사양표 읽기로 형태만 바꿔 살아남는 셈입니다.

자주 만나는 함정 #

  • iSCSI를 서비스 네트워크에 섞는다 — 트래픽이 몰리는 순간 디스크 지연이 같이 튑니다. 전용 NIC/VLAN 분리가 iSCSI 운영의 절반입니다.
  • 멀티패스 아래의 원시 장치를 직접 쓴다 — /dev/sdb를 fstab에 적는 순간 이중화가 무효가 됩니다. 묶인 장치와 그 식별자(WWID)를 씁니다.
  • 경로 장애를 조용히 넘긴다 — 한 경로가 죽어도 서비스가 멀쩡해서 알아채기 어렵습니다. 두 번째 경로까지 죽고 나서야 발견하는 사고를 알림으로 막습니다.

정리 #

이번 글에서 잡은 그림입니다.

  • iSCSI는 보편성, FC는 일관성과 격리, NVMe-oF는 플래시 시대의 저지연이라는 각자의 쓰임새가 있습니다.
  • 네트워크 스토리지의 새 고장 모드는 길의 단절이고, 멀티패스가 그 답입니다. 묶인 장치를 쓰고 경로 상태를 감시합니다.
  • 클라우드 블록 스토리지는 이 구조의 재포장입니다. 네트워크 너머라는 본질이 한도와 지연 특성으로 나타납니다.

다음 — GPU 서버 #

다음 글인 “하드웨어 중급 #8 GPU와 가속기"에서는 시리즈의 네 자원에 다섯 번째 손님을 들입니다. AI 워크로드의 주인공인 GPU가 서버 안에서 어떻게 일하는지, VRAM이 왜 새로운 병목인지, nvidia-smi의 숫자를 읽는 법과 GPU를 나눠 쓰는 기술(패스스루, vGPU, MIG)까지 다룹니다.

X