01 · iSCSI와 NVMe-oF — 네트워크 블록 경로와 비용

NVMe SSD가 꽂힌 서버의 용량을 다른 호스트에 내줄 때, iSCSI를 NVMe-oF로 바꾸면 호스트의 명령 처리 경로와 큐 배치가 달라집니다. SCSI 중간 계층과 명령을 감싸는 단계가 빠질 여지는 있지만, TCP를 쓰면 TCP/IP 처리와 복사·CRC 비용은 남습니다. 타깃이 namespace 뒤에 연결한 볼륨과 복제 계층도 그대로입니다.

따라서 성능을 비교하려면 전송 규약, 타깃 구현, 백엔드가 각각 무엇을 처리하는지 알아야 합니다. NVMe-oF는 NVMe 명령을 네트워크로 주고받는 규약이며, 소프트웨어 타깃은 그 규약에 맞는 controller를 구현합니다. 호스트에 보이는 NVMe 장치를 물리 SSD의 controller와 같은 것으로 이해하면 중간의 처리 비용을 놓치게 됩니다.

공개 측정은 장치·커널·블록 크기·큐 깊이가 서로 달라 같은 자료 안에서만 비교합니다. 수치와 조건은 각 절의 ‘근거와 측정 조건’에 두었습니다. 네트워크로 받은 장치를 VM에 전달하는 방식은 02 VM 디스크 경로에서 다룹니다.

근거 표기 — ✓ 1차 문서 확인 · Ⓑ 공개 벤치마크 · Ⓥ 벤더·프로젝트 주장 · ≈ 추정·역산 · ? 미확인 · Σ 종합 판단.

1. iSCSI보다 무엇이 가벼워지고, 무엇은 남는가

iSCSI는 SCSI 명령 하나를 CDB(명령 기술 블록)에 담고, 이를 PDU(iSCSI 메시지 단위)로 감싸 보냅니다. NVMe 쪽에서는 SCSI 중간 계층과 iSCSI 계층 자리에 NVMe host와 전송 계층이 들어갑니다. Guz 외는 이를 호스트 경로에서 프로토콜 변환을 없애는 것으로 설명합니다. 이 경로 차이가 성능에 기여할 수 있지만, 제거된 SCSI 처리만의 비용을 분리한 실측은 확보하지 못했습니다.

Samsung 연구진의 2017년 RoCEv2 실험에서는 RocksDB 처리량이 로컬과 2% 차이였고, iSCSI는 로컬보다 40% 줄었습니다. 위 도식의 98은 “2% 차이”를 옮긴 근사값입니다. 자료에 차이의 방향이 명시되지 않았고 iSCSI의 전송 구성도 없으므로, 이 수치로 SCSI 처리 제거의 효과나 NVMe/TCP 성능을 판단할 수는 없습니다. 같은 실험에서 NVMe-oF의 평균 지연과 호스트 CPU 사용량은 늘었습니다.

애플리케이션과 장치가 쓰는 시간도 전송 차이의 비중을 바꿉니다. i10의 RocksDB 실험에서는 RocksDB 자체가 CPU를 많이 써서 NVMe/RDMA와 NVMe/TCP의 차이가 fio보다 작았습니다. Blockbridge의 큰 블록 측정에서는 대역폭이 한계에 이르자 NVMe/TCP와 iSCSI의 차이가 거의 없어졌습니다. TCP에서 작은 PDU 처리, 스레드 전환, 복사와 CRC가 발생하는 경로는 4절에서 다룹니다.

장치가 느릴수록 같은 전송 오버헤드가 전체 지연에서 차지하는 비중이 작아진다는 것이 이 자료들을 종합한 해석입니다. HDD는 부록 A, 파일 프로토콜 NFS와의 비교는 부록 B에 있습니다.

이 글이 확보한 논문에서 iSCSI와 같은 조건으로 비교한 NVMe-oF는 RDMA뿐입니다. NVMe/TCP와 iSCSI를 함께 잰 자료는 벤더 자료, Longhorn 벤치마크, StarWind 블로그이며, 어느 자료도 SCSI 처리 제거만의 효과를 분리하지 않았습니다.

2. 타깃은 무엇을 내보내고 호스트는 무엇을 보는가

NVMe-oF 타깃이 내놓는 단위는 NVM subsystem입니다. subsystem은 NQN이라는 이름으로 식별하고 port로 노출합니다. 호스트가 controller의 Admin Queue에 연결하면 association이 생기며, 그 관계가 유지되는 동안에는 해당 호스트만 그 controller에 연결할 수 있습니다. Discovery controller는 접속할 subsystem을 찾도록 Discovery Log를 제공하고, 데이터 I/O용 큐와 namespace는 갖지 않습니다.

소프트웨어 타깃인 Linux nvmet과 SPDK nvmf는 이 규약에 맞는 NVMe controller를 구현합니다. SPDK 문서에서 namespace는 NVMe의 논리 블록 저장 공간이며, bdev(블록 장치 추상화 계층)가 제공하는 백엔드 블록 장치 하나에 연결됩니다. 물리 NVMe 장치와 가상 bdev 모두 백엔드가 될 수 있습니다. 이를 종합하면 호스트가 연결하는 controller는 타깃 프로그램이 구현한 것이며, namespace 뒤에는 LV·lvol·파일 같은 장치가 놓일 수 있습니다.

명령이 도착한 뒤에는 그 백엔드의 경로를 따릅니다. Guz 슬라이드의 커널 타깃은 받은 명령을 블록 계층의 I/O로 내려보냅니다. 이후에는 연결된 NVMe SSD나 논리 볼륨이 요청을 처리합니다. 호스트가 NVMe 명령을 보냈어도 블록 계층과 볼륨 계층을 거치며, lvol·객체 매핑·복제 비용은 남습니다(5·6절). NVIDIA가 설명하는 하드웨어 오프로드는 별도 경로입니다. 지원 HCA가 일반 I/O를 처리하고 peer-to-peer PCI로 NVMe 장치에 직접 보냅니다.

호스트에서는 연결된 namespace를 블록 장치로 사용합니다. 문서와 구현을 종합하면 /dev/nvmeXnY가 생기고, nvme list의 모델 칸에는 타깃 소프트웨어가 보고한 값이 표시되는 것으로 볼 수 있습니다. Linux는 같은 namespace로 가는 여러 경로를 블록 장치 하나로 묶고, I/O 정책과 관계없이 ANA(경로별 접근 상태)에서 optimized인 경로를 먼저 씁니다. 설정 절차는 부록에 있습니다.

/dev/nvme*라는 이름만으로 그 뒤의 전송을 알아낼 수는 없습니다. 클라우드 볼륨이나 DPU 카드가 NVMe 장치로 보이는 경우는 02에서 다룹니다.

3. 호스트 I/O 스택과 큐 구조는 어떻게 다른가

위 경로는 RFC 7143, open-iscsi README, LIO 문서를 종합한 것입니다. 한 문서에 전체 경로가 제시된 것은 아닙니다. NVMe 쪽에는 SCSI 중간 계층과 iSCSI 계층이 없으며, Guz 외는 이 차이를 프로토콜 변환 제거로 설명합니다.

iSCSI의 비용에는 복사와 프로토콜 처리도 포함됩니다. ReFlex 연구진은 클라이언트와 서버에서 소켓·SCSI·애플리케이션 버퍼 사이에 데이터 복사가 생긴다고 설명합니다. i10 연구진은 당시 Linux iSCSI가 TSO(송신 때 큰 덩어리를 NIC가 나누는 기능)와 GRO(수신 때 작은 패킷을 합치는 기능)를 충분히 쓰지 못하고 TCP/IP 처리용 커널 스레드를 따로 사용해 CPU를 비효율적으로 쓴다고 지적했습니다.

요청을 큐와 연결에 배치하는 방식도 다릅니다. iSCSI 규격은 세션 안에 여러 연결을 두는 MC/S를 허용합니다. 그러나 open-iscsi README의 소프트웨어 iSCSI는 세션마다 scsi_host를 할당하고 연결을 하나만 사용합니다. 커널 소스까지 확인하면 Linux iscsi_tcp의 기본 형태는 세션마다 하드웨어 큐와 TCP 연결을 하나씩 두는 방식으로 해석할 수 있습니다.

NVMe/TCP는 TCP 연결 하나와 큐 쌍 하나를 대응시킵니다. 한 연결에 여러 큐를 섞거나 한 큐를 여러 연결에 나누는 구성은 지원하지 않습니다. RDMA의 I/O 큐 쌍도 RDMA QP 하나에 대응합니다. 이 규약 위에서 Linux host는 기본적으로 CPU 수만큼 I/O 큐와 연결을 만들고, nvme-tcp는 큐마다 CPU를 정해 해당 CPU의 워크큐에서 소켓 송수신을 실행합니다. CPU 수만큼 큐를 만드는 정책 자체는 NVMe 규약의 요구가 아닙니다.

큐를 나눈 효과는 실제 부하로 확인해야 합니다. ntprof는 NVMe/TCP 연결 하나에 fio job을 더 넣어도 처리량은 조금만 늘고 지연은 커지는 구간을 보고했습니다. 여러 CPU에 큐와 연결을 나누면 한 연결에 집중되던 부하를 분산할 수 있다는 것은 이 글의 종합 판단입니다. 해당 실험은 연결 수 증가를 측정하지 않았으므로 그림의 큐·노드 수를 처리량 배수나 지연 비율로 환산할 근거는 없습니다. 두 경로에 남는 TCP/IP 처리와 복사는 다음 절에서 봅니다.

4. 쓰기 데이터는 어떻게 오가며 TCP에는 무엇이 남는가

NVMe/TCP의 쓰기 데이터는 명령과 함께 보내거나 타깃의 요청을 받은 뒤 따로 보냅니다. 명령·응답을 나르는 정보 단위가 capsule이고, 쓰기 데이터를 명령에 넣는 in-capsule은 I/O 명령의 선택 기능입니다. ntprof가 설명하는 Linux 구현은 작은 쓰기에 in-capsule을 사용합니다. 그 한도를 넘으면 호스트가 controller의 R2T(쓰기 데이터 전송 요청)를 기다렸다가 H2CData PDU로 데이터를 보냅니다.

iSCSI도 R2T와 ImmediateData·InitialR2T·FirstBurstLength·MaxBurstLength 협상으로 쓰기 전송을 조절합니다. 따라서 NVMe/TCP에 in-capsule이 있다는 사실만으로 iSCSI보다 왕복이 줄어든다고 판단할 수는 없습니다.

RDMA에서는 controller가 데이터 이동을 시작합니다. 읽기에서는 RDMA_WRITE로 데이터를 호스트 버퍼에 넣고, 쓰기에서는 RDMA_READ로 가져오거나 in-capsule로 받습니다. TCP와 RDMA는 이처럼 데이터를 옮기는 방식이 달라 RDMA 측정값을 TCP에 그대로 적용할 수 없습니다.

TCP에서는 작은 요청 PDU 처리와 커널 스레드 전환, 복사와 CRC가 CPU를 사용합니다. i10은 요청마다 개입하는 커널 스레드를 비용의 원인으로 짚었고, ntprof는 부하가 늘 때 네트워크 단계가 전체 지연의 대부분을 차지하는 구간을 관찰했습니다. Autonomous NIC Offloads 실험에서는 복사와 CRC가 NVMe-TCP 메시지 처리 사이클의 최대 49%를 사용했습니다. 아래 표에 각 실험의 커널·장비·부하를 함께 두었습니다.

비교할 때는 다이제스트와 TLS 설정도 맞춰야 합니다. 전송 오류를 검출하는 헤더·데이터 다이제스트는 연결할 때 양쪽이 켜야 동작하는 선택 기능입니다. NVIDIA 패치 커버레터의 소프트웨어 경로에서는 다이제스트를 켜면 큰 블록 읽기 처리량이 줄었습니다. 작은 블록과 쓰기는 측정값이 없습니다.

TLS도 선택 구현입니다. NVMe/TCP 규격이 사용할 TLS 버전과 PSK 인증을 정하고, Linux와 RHEL 문서가 구현·지원 상태를 설명합니다. 같은 장비에서 TLS를 켜고 끈 비용을 직접 비교한 공개 수치는 확인하지 못했습니다.

5. 타깃 구현과 백엔드가 이점을 바꾸는 조건

Intel의 SPDK TCP 보고서에서는 타깃만 SPDK로 바꿨을 때 QD1 평균 지연이 약 1µs 줄었고, initiator까지 바꾸면 약 4µs 줄었습니다. 로컬 대비 전송 비용을 뺀 값이 아니라 같은 보고서의 구현 조합 간 차이입니다. SPDK의 NVMe/TCP도 Linux 커널 TCP 스택을 사용합니다.

평균이 낮은 구현의 꼬리 지연도 낮지는 않았습니다. 타깃 1코어, null 블록 장치, QD1 4KiB 랜덤 읽기에서는 평균 차이가 작았고 커널 타깃의 꼬리 지연이 더 낮았습니다. LeapIO의 RDMA·RocksDB 실험도 커널 NVMe-oF가 가장 안정적이었다고 보고했습니다. 구현 시기와 부하가 다른 두 실험의 절대값을 직접 비교할 수는 없지만, 꼬리 지연을 SLO로 삼는다면 평균만으로 구현을 고르기 어렵다는 판단은 가능합니다.

처리량 비교에는 사용한 코어 수가 필요합니다. SPDK 보고서의 subsystem당 연결 8개 조건에서는 커널 타깃이 더 많은 코어로 더 높은 절대 처리량을 냈고, 코어당 처리량은 SPDK가 높았습니다. 연결이 하나일 때는 24코어를 고정 폴링하는 SPDK의 효율이 낮았으며, SPDK에 배정한 코어를 줄여 다시 재자 효율 비교가 달라졌습니다. ntprof에서도 타깃 코어를 제한하면 큐 깊이를 높여도 처리량은 거의 늘지 않고 지연만 커졌습니다.

타깃 뒤의 bdev와 볼륨 계층은 별도 비용입니다. SPDK 보고서는 raw polled-mode 드라이버보다 bdev 계층에서 오버헤드가 생기고, lvol이 split NVMe bdev보다 낮은 IOPS를 내는 조건이 있다고 보고했습니다. 드라이브를 나눠 쓰는 일부 조건에서는 lvol 차이가 잡음 수준이었습니다.

이 계층에는 할당과 메타데이터 처리가 있습니다. SPDK lvol은 blobstore 위에 만들며 첫 쓰기 때 저장 공간을 할당하고 snapshot과 clone을 관리합니다. Linux dm-thin은 메타데이터를 별도 장치에 저장하며, 데이터 블록 크기를 생성 후 바꿀 수 없고 새 블록을 기본적으로 0으로 채웁니다. dm-thin의 지연·IOPS 실측은 확인하지 못했습니다.

배포판의 지원 범위도 구현 선택을 제한합니다. RHEL의 NVMe/TCP 문서는 host만 완전 지원하고 타깃 기능과 모듈은 지원하지 않는다고 명시합니다. 같은 가이드의 NVMe/RDMA 장에 타깃 설정 절차가 있다는 것만으로 RDMA 타깃의 지원 범위까지 확정할 수는 없습니다.

6. RBD와 Kubernetes 스토리지에도 같은 설명이 적용되는가

앞의 iSCSI·NVMe-oF는 서버의 블록 장치를 다른 호스트에 내보내는 경로입니다. RBD는 이미지를 RADOS 객체로 나누어 여러 OSD에 분산하고 블록 장치로 제공하는 스토리지입니다. RBD 앞에 NVMe/TCP 인터페이스를 붙여도 그 뒤의 객체 매핑·배치·복제는 계속 수행해야 합니다.

Ceph NVMe-oF gateway의 namespace는 RBD 이미지에 대응하는 SPDK bdev와 연결됩니다. Ceph 문서들을 종합하면 블록과 객체를 매핑하고 CRUSH로 배치하며 OSD에 복제하는 비용은 gateway 뒤에 남는 것으로 볼 수 있습니다. primary OSD가 복제본에 쓰고 응답을 모으는 세부 흐름은 공식 문서에서 확인하지 못했습니다.

gateway가 추가한 비용을 분리할 실측도 부족합니다. rook 토론의 krbd와 NVMe-oF 비교는 원인을 SDN 오버레이로 결론지은 사용자 보고이며 재현성은 확인하지 못했습니다. IBM 저자가 ceph.io에 공개한 측정에는 RBD 직접 접속 값과 일부 조건이 빠져 있습니다.

Mayastor는 nexus에서 child와 replica를 거쳐 디스크에 도달하며, 건강한 모든 child의 쓰기가 완료돼야 initiator에 응답합니다. 개발사 MayaData는 로컬과 가까운 처리량을 보고했지만 장치 정보 일부와 지연 값이 없습니다. 현재 버전의 공식 벤치마크도 확인하지 못했습니다.

Longhorn의 V1·V2 비교는 전송과 engine을 함께 바꾼 결과입니다. V1은 iSCSI와 리눅스 프로세스, V2는 NVMe-TCP 또는 UBLK와 SPDK를 사용합니다. 프로젝트 측정에서 기준선 대비 랜덤 읽기 처리량은 V1 약 2%, SPDK 코어를 많이 배정한 V2 약 30%로 계산됩니다. 이 차이를 전송만의 효과로 분리할 수는 없습니다.

같은 V2에서도 SPDK 코어 수가 처리량을 바꾸고, replica를 늘리면 동기 복제 쓰기의 지연이 커지고 처리량이 줄었습니다. 아래 비교는 OCI VM 안에서 이루어졌으므로 기준선 NVMe도 클라우드 가상화 계층을 거친 값으로 해석해야 합니다.

7. 내 환경에서 비교할 항목과 자료의 한계

이 조건에 가장 가까운 자료는 StarWind의 비교 글입니다. 벤더가 공개한 측정에서는 같은 장비와 SPDK 타깃으로 iSCSI·NVMe/TCP·NVMe/RDMA를 비교했습니다. 위 그림은 그중 낮은 큐 깊이에서 잰 랜덤 쓰기 결과입니다. 로컬의 같은 조건 값이 없어 전송이 추가한 지연까지 구할 수는 없습니다.

다중 스레드 결과는 읽는 범위가 더 좁습니다. StarWind가 프로토콜마다 numjobs와 iodepth를 다르게 설정했으므로 지연을 서로 견줄 수 없습니다. 각 조건의 처리량에서 RDMA·TCP가 로컬에 가까웠고 iSCSI는 로컬의 82% 수준이었다는 점만 확인할 수 있습니다. 타깃도 커널 nvmet·LIO가 아닌 SPDK였으며, 벤더 블로그에 원자료와 스크립트는 공개되지 않았습니다.

공개 자료가 비어 있거나 원문을 확인하지 못한 범위도 남아 있습니다.

• 커널 6.x에서 로컬 NVMe, NVMe/RDMA, NVMe/TCP, iSCSI를 한 장비로 함께 잰 공개 자료를 찾지 못했다. 표에 인용한 측정은 2017~2026년, 커널 4.4~6.17에 걸쳐 있으며 장치도 다르다.
• NVMe/TCP에서 TLS를 켠 비용의 직접 비교와 다이제스트의 4K·쓰기·지연 수치를 찾지 못했다.
• Guz 논문 본문을 열지 못해 iSCSI 전송 구성, 커널 버전, 그래프 절대값을 확인하지 못했다. ReFlex·i10이 재인용한 “iSCSI 코어당 약 70K IOPS"도 원 출처를 열지 못해 본문에서 제외했다.
• ntprof의 연결 하나·job 5→6개 측정은 fact sheet 한 줄로만 확인했고 §4.3 원문은 열지 못했다. 3절 근거 블록의 해석 행에 Σ가 붙은 이유다.
• Mayastor는 현재 버전의 조건 명시 벤치마크를 찾지 못했다. Ceph NVMe-oF gateway는 사용자 보고와 조건이 불충분한 공식 블로그 외의 실측을 찾지 못했다.
• Ceph primary OSD의 복제 쓰기 흐름을 설명하는 원문은 확인하지 못했다.
• NVMe SR-IOV SSD와 live migration 구현 상태는 VM 쪽 주제이므로 02에서 다룬다.

부록. 용어·설정·연혁·추가 실측

용어

iSCSI 구성과 iSER

iSCSI는 SCSI 명령을 TCP 위에서 나르는 전송 프로토콜입니다. RFC 7143(2014-04)은 RFC 3720 등 앞선 문서를 통합했습니다. SCSI 계층이 만든 CDB를 iSCSI 계층이 PDU로 감싸고, 하나 이상의 TCP 연결(포트 3260)로 주고받습니다. 기본 헤더(BHS)는 48바이트로 고정됩니다 ✓.

세션은 SCSI I_T nexus와 같은 것입니다. CmdSN은 세션 전체에서 매기며, 한 연결 안에서는 CmdSN 순서대로 보내야 합니다. HeaderDigest·DataDigest(CRC32C)는 선택 기능입니다 ✓.

커널 타깃인 LIO는 targetcli로 설정합니다. backstore에는 fileio·block·pscsi·ramdisk가 있으며, block은 로컬 블록 장치 전체를 LUN으로 내보냅니다. /backstores/block에서 create name=block_backend dev=/dev/sdb를 실행하고 /iscsi에서 IQN을 생성합니다. 이어서 luns/에서 backstore를 LUN에 연결합니다 ✓.

iSER(RFC 7145, 2014-04)는 같은 iSCSI를 RDMA(iWARP, InfiniBand RC) 위에서 동작시킵니다. RDMA Read/Write로 데이터를 SCSI I/O 버퍼에 중간 복사 없이 놓습니다 ✓. 세션마다 scsi_host와 연결을 하나씩 사용하는 방식은 iscsi_tcp와 같습니다. 이 글의 자료에는 iSER 실측이 없습니다.

NVMe-oF 구성 절차

SPDK 타깃은 기존 블록 장치에 namespace 번호를 붙여 subsystem에 넣고 포트를 열어 가상 NVMe 장치를 제공합니다 ✓.

# 스토리지 서버 (SPDK 타깃)
bdev_lvol_create_lvstore <bdev> <lvs>
bdev_lvol_create -l <lvs> [-t] <name> <size>
nvmf_create_transport -t TCP
nvmf_create_subsystem nqn.2016-06.io.spdk:cnode1 -a -s <serial>
nvmf_subsystem_add_ns <nqn> <bdev>
nvmf_subsystem_add_listener <nqn> -t tcp -a <ip> -s 4420

# 호스트
modprobe nvme-tcp
nvme discover -t tcp -a <ip> -s 4420
nvme connect -t tcp -n <nqn> -a <ip> -s 4420

호스트는 nvme discover와 nvme connect 대신 nvme connect-all을 사용할 수도 있습니다 ✓.

커널 nvmet은 같은 구성을 configfs에 만듭니다. subsystem을 생성하고 namespace의 device path에 블록 장치를 적어 enable합니다. 그다음 port를 만들어 subsystem을 연결합니다 ✓. LVM 논리 볼륨 경로도 블록 장치 경로이므로 사용할 수 있지만, 이 대입을 직접 설명한 문서는 확인하지 못했습니다 ≈. 포트는 NVMe-oF용으로 4420, discovery용으로 8009를 사용합니다 ✓.

전송별 차이

연혁

NVMe-oF 1.0은 2016년 6월에 나왔습니다. Linux 4.8(2016-10)에는 RDMA용 host와 target이 들어갔습니다. TCP 전송의 비준 소식은 2018년 11월에 공개됐으며, Linux 5.0(2019-03)에 host와 target이 함께 들어갔습니다. 멀티패스는 4.15, ANA는 4.19에 추가됐습니다 ✓.

1.1a(2021) 이후 NVMe-oF 스펙은 별도로 개정되지 않고 NVMe 2.0 Base 스펙에 흡수됐습니다. TCP 전송 스펙은 2025년 개정 1.2까지 확인했습니다 ✓.

추가 실측

ReFlex(ASPLOS'17)는 Xeon E5-2630(12코어, 2소켓), Intel 82599ES 10GbE, Arista 7050S-64 스위치, Ubuntu 16.04 커널 4.4, 1M IOPS급 NVMe를 사용했습니다. jumbo frame을 사용하고 LRO/GRO를 끈 상태에서 4KB 랜덤 QD1 지연을 측정했습니다 Ⓑ. 본문과 장치·링크가 다른 과거 측정이므로 수치를 직접 비교하지 않습니다.

저자는 10GbE TCP/IP가 소프트웨어 스토리지 스택에 닿기 전에 무부하 지연을 최소 50µs 늘린다고 적습니다 Ⓑ.

SPDK 24.05 TCP 보고서에서 SPDK 타깃의 4KiB 랜덤 읽기 처리량은 1코어 611.3K, 8코어 5,571K, 12코어 8,307K IOPS였습니다. 48코어에서는 11,059K(362Gbps)에 이르러 링크가 포화됐습니다. RDMA 보고서(QD128)의 1코어 값은 1,564.5K입니다. TCP와 QD가 달라 배수로 비교하지 않습니다 Ⓑ.

타깃 소프트웨어를 DPU로 옮긴 실측은 SPDK 26.01 RDMA 보고서(NVIDIA, 2026-02)에 있습니다. BlueField-3(Arm Cortex-A78AE 16코어, 커널 5.15)에서 SPDK 타깃을 실행하고 200GbE 2포트와 SSD 16개 JBOF를 거쳤습니다. 4KiB 랜덤 읽기 QD64의 결과는 1코어 469.8K, 8코어 6,135K, 16코어 10,091K IOPS였습니다 Ⓑ.

iSCSI와 직접 비교한 결과는 벤더 자료에 많습니다. Blockbridge는 Proxmox 7.2, 커널 5.15.53, EPYC 7452, ConnectX-5 100GbE, VM 32대, 자사 백엔드에서 측정했습니다. 이 조건에서 NVMe/TCP는 iSCSI보다 512B 평균 IOPS가 35.4% 높았다고 보고합니다. 4K QD4에서는 IOPS가 50% 이상 높고 지연은 33% 낮았지만, 대역폭이 한계인 큰 블록에서는 차이가 약 0.1%였습니다 Ⓥ.

Dell PowerStore 자료(ESXi, 기본 설정; 발행 연도 미확인)는 iSCSI의 IOPS가 가장 낮고 지연과 IO당 CPU가 가장 높다고 적습니다. NVMe/TCP@25GbE는 쓰기에서 NVMe/FC·FCP@32GFC와 비슷하고, 읽기에서는 20% 이내로 뒤진다고 보고합니다 Ⓥ.

Intel·MayaData 공동 문서는 Mayastor의 오버헤드가 Optane P5800X raw 대비 10% 미만이라고 주장했습니다. Blocks & Files는 수치가 불완전하고 단위가 정의되지 않아 비교할 수 없다고 지적했습니다 Ⓥ.

SUSE의 Longhorn 1.6.0 발표(2024)는 V2가 V1보다 쓰기에서 2~4배, 랜덤 읽기에서 2~3배 빠르며 지연은 50~70% 감소한다고 주장했습니다. 단일 replica의 IOPS도 로컬 디스크와 비슷하다고 설명했습니다 Ⓥ. 원 측정 조건은 확인하지 못했으며, 이 주장은 v1.12.0의 기준선 대비 30%와도 어긋납니다.

Ceph NVMe-oF gateway의 한계는 개발 버전 문서 기준으로 gateway 그룹 4개, 그룹당 gateway 8개, 그룹당 subsystem 128개, subsystem당 호스트 32개, 그룹당 namespace 1,024개입니다 ✓. IBM Storage Ceph 7.1 문서의 사이징은 목표 100,000 IOPS에 reactor 코어 1개·총 16코어, 200,000에 2개·18코어, 250,000에 4개·22코어, 300,000에 8개·30코어입니다 Ⓥ.

그 밖의 방식

FC와 FCoE는 전용 패브릭이나 이더넷 위에서 SCSI를 나릅니다. FC는 NVMe 명령도 나르는 NVMe-oF 전송 중 하나입니다 ✓. FCP·FCoE의 1차 표준 문서는 확인하지 못했습니다 ?.

NBD 클라이언트는 블록 읽기 요청마다 TCP로 서버에 요청을 보내고 읽은 데이터를 돌려받습니다. 커널 모듈은 클라이언트에만 있으며 nbd-server는 전부 유저스페이스에서 실행됩니다 ✓. 이 글의 질문에 답할 만한 독립 실측은 없어 방식만 소개합니다.

참고 자료

• RFC 7143 iSCSI Protocol (Consolidated) — IETF, 2014. iSCSI 구조·세션·CmdSN·R2T·다이제스트
• RFC 7145 iSER — IETF, 2014. iSER 구조
• open-iscsi README — open-iscsi, 현행. 세션당 scsi_host·연결 1개
• Linux scsi_lib.c · iscsi_tcp.c · nvme/host/fabrics.c · tcp.c — torvalds/linux master. 하드웨어 큐 수 기본값, NVMe/TCP의 CPU 수만큼 I/O 큐와 io_cpu
• Linux 4.8 · 4.15 · 4.19 · 5.0 · 6.7 — kernelnewbies. scsi-mq 기본화·non-mq 제거, fabrics·멀티패스·ANA·NVMe/TCP·in-kernel TLS 편입 버전
• NVMe Multipath — Linux kernel 문서. I/O 정책과 ANA 우선순위
• Configuring an iSCSI target — Red Hat, RHEL 9. LIO·targetcli·backstore 종류와 설정 순서
• Configuring NVMe over fabrics using NVMe/TCP · RHEL 10 Managing storage devices · RHEL 9.0 · 9.6 · 10.0 릴리스 노트 — Red Hat. nvmet 미지원 문장은 Managing storage devices의 NVMe/TCP 장 기준, nvmet_tcp.ko의 Unmaintained 분류, TLS의 Technology Preview(9.6·10.0 릴리스 노트)
• Network Block Device — Linux 커널 문서. NBD 구조
• Ceph Block Device · rbd(8) — Ceph 문서. RBD 객체 분산, 기본 객체 크기
• NVMe-oF Gateway · ceph-nvmeof — Ceph. RBD 이미지를 NVMe/TCP로 내보내는 gateway 구조와 한계
• Performance at Scale with NVMe over TCP — Burkhart·D’Atri(IBM), ceph.io, 2025-02-03. gateway 측정과 빠진 조건
• NVMe performance best practices — IBM Storage Ceph 7.1. gateway 코어 사이징
• rook/rook Discussion #17210 — 사용자 보고, 2026. krbd 대 NVMe-oF gateway 실측
• NVMe over Fabrics Specification · NVMe over Fabrics 1.1a — NVM Express. 1.0~1.1a 연혁, subsystem·association·capsule·RDMA 큐 매핑
• NVMe over TCP Transport Specification 1.2 — NVM Express, 2025. TCP 연결과 큐 쌍의 1:1 대응, in-capsule·R2T·다이제스트·TLS
• Welcome NVMe/TCP to the NVMe-oF Family of Transports — Grimberg·Minturn, 2018. NVMe/TCP 비준 시점
• NVMe 2.0 Library of Specifications 발표 — NVM Express, 2021. 전송 스펙 목록(PCIe·FC·RDMA·TCP)
• NVMe over Fabrics 문서 · Logical Volumes — SPDK. 타깃 구조, 절차, lvol 동작
• Thin provisioning — Linux kernel 문서. dm-thin 블록 크기와 제로잉
• NVMe-oF target offload — NVIDIA DOCA 문서. 타깃 오프로드 설명
• NVMe-over-Fabrics Performance Characterization (슬라이드) — Guz 외(Samsung), SYSTOR'17. 로컬 대 NVMe/RDMA 대 iSCSI 지연 분해, 처리량·CPU·RocksDB
• ReFlex: Remote Flash ≈ Local Flash — Klimovic·Litz·Kozyrakis, ASPLOS'17. 로컬 대 iSCSI 지연, iSCSI 지연 원인
• TCP ≈ RDMA: CPU-efficient Remote Storage Access with i10 — Hwang 외, NSDI'20. 커널 iSCSI의 CPU 비효율, 코어당 처리량과 TCP 지연 원인
• Understanding and Profiling NVMe-over-TCP Using ntprof — Kang·Liu, NSDI'25. 네트워크 단계 비중, in-capsule 경계, 연결·타깃 코어 한계
• Autonomous NIC Offloads — Pismenny 외, ASPLOS'21. 복사·CRC 비용
• [PATCH v30 00/20] nvme-tcp receive offloads — NVIDIA(Aurelien Aptel), linux-nvme, 2025-07-15. 데이터 다이제스트 켠 소프트웨어 경로 기준선
• SPDK NVMe-oF TCP Performance Report 24.05 · RDMA Performance Report 24.05 — Intel, 2024. QD1 왕복 지연과 커널 대 SPDK 타깃
• SPDK NVMe-oF RDMA Performance Report 26.01 — NVIDIA, 2026. BlueField-3 타깃
• SPDK Vhost Performance Report 24.05 · NVMe BDEV Performance Report 24.05 — Intel, 2024. lvol·bdev 오버헤드
• LeapIO — Li 외, ASPLOS'20. 커널 대 SPDK NVMe-oF의 꼬리 지연
• iSCSI vs NVMe-oF: Performance Comparison — StarWind, 2024-04-04. 벤더 측정, 한 장비에서 세 전송의 QD1 지연
• Proxmox: iSCSI and NVMe/TCP shared storage comparison — Blockbridge. 벤더 측정(게시일 미확인)
• NVMe Transport Performance Comparison (H18892.2) — Dell. 벤더 측정(발행 연도 미확인)
• I/O Path Description — OpenEBS 문서. Mayastor 경로와 복제 쓰기
• Mayastor NVMe-oF TCP performance — MayaData, 2021 추정(Wayback 사본). 개발사 실측
• Intel says Mayastor is fastest open source storage. So where are the numbers? — Blocks & Files, 2021-03-08
• Longhorn Concepts (1.9.0) · Performance Benchmark wiki · v1.12.0 report.pdf — Longhorn 프로젝트. V1·V2 구조와 2026-07-19 벤치마크
• Announcing Longhorn 1.6.0 — SUSE, 2024-02-19. V2 성능 주장