From ISCSI to NVMe-of: A Comparative Look on Storage Protocol Advantages & Challenges
summary
Direct comparison shows RBD usually wins for throughput/IOPS/latency, with NVMe-oF typically faster than iSCSI but slower than raw RBD except in small‐dataset cachey cases; benchmarks and customer migrations confirm improved stability and latency after moving from iSCSI. NVMe-oF deployments require SPDK/ RDMA and careful CPU pinning, plus clustered gateways and multipath tooling to avoid out‑of‑order writes and consistency hazards. Expect higher CPU use, limited Windows initiator support today, and slow vSphere-driven adoption. RBD usually wins for throughput/IOPS/latency NVMe-oF uses SPDK and RDMA, polling and core pinning iSCSI is in maintenance since Nov 2022
AI-written summary · about
chapters (14)
- 0:00Introduction and company overview
- 2:33Overview of Ceph storage protocols
- 3:43History and architectural background
- 7:30Underlying technical implementation
- 9:36Deployment, network, and complexity
- 13:34Featureset comparison
- 14:24Compatibility and scalability
- 16:48Reliability and network tolerance
- 17:43Cost and security considerations
- 18:24Use cases and practical applications
- 19:03Performance benchmarks
- 22:16Challenges and limitations
- 25:49Customer insights and adoption
- 27:29Conclusion and Q&A
related talks
17mCo-Designing Traffic Control with NVMe-oF for Disaggregated Storage: A Comparative Study
44mNVMe-Over-Fabrics Support for Ceph
37mSPDK Based User Space NVMe Over TCP Transport Solution
20mEmpowering Azure Storage with RDMA
34mNVMeoF in Ceph - What's New and Performance Best Practices
01h 24mPreview Session
12mPreview: Networking
39mSecured I/O in the Cloud with NVMe-Over-TCP
