Choosing an enterprise block storage protocol
Fibre Channel, iSCSI, iSER and the NVMe-oF transports can all deliver shared block storage. The correct decision starts with host support, existing infrastructure, failure domains and operational ownership.
Transport suitability depends on the complete host, network and storage path.
Multipathing, target failover and data protection are separate design layers.
A supported end-to-end configuration matters more than a theoretical advantage.
The team must be able to monitor, troubleshoot and test the chosen fabric.
Start with requirements that do not change when a new transport appears
Host ecosystem
List hypervisor versions, operating systems, database requirements, initiators, multipath implementations and boot dependencies.
Failure model
Define what happens during cable, switch, network, target-port, controller and complete storage-node loss.
Existing fabric
Decide whether an operated FC SAN, ordinary Ethernet or a qualified RDMA network should be reused.
Operational ownership
Identify who controls zoning, VLANs, lossless Ethernet settings, firmware, path policies and change windows.
Do not select a transport from bandwidth alone. Queue behaviour, latency consistency, CPU path, recovery timing and platform support are often more important than the nominal link rate.
Similar goals, different command models and operational dependencies
Fibre Channel
Mature FCP block storage using dedicated HBAs and switched FC fabrics.
- Strong fit for existing enterprise SAN estates
- Dedicated fabric and specialist operational model
- Zoning, LUN masking and multipathing remain essential
NVMe/FC
Native NVMe commands transported through a Fibre Channel fabric.
- Can preserve FC operational separation
- Requires end-to-end NVMe/FC support
- Not the same protocol as traditional FCP
iSCSI
The established SCSI command model transported over routable TCP/IP.
- Broad initiator and operating-system compatibility
- Uses familiar Ethernet and IP skills
- Needs independent paths and disciplined storage networking
iSER
iSCSI Extensions for RDMA retain the iSCSI ecosystem while changing the data path.
- Useful where iSCSI semantics must be retained
- Requires compatible RDMA support at both ends
- Fabric qualification is more demanding than ordinary TCP
NVMe/TCP
Native NVMe queues and commands transported over standard TCP/IP networks.
- Routable and deployable on standard Ethernet
- Avoids RDMA-specific fabric requirements
- Host and target feature support must still be validated
NVMe/RDMA
Native NVMe over a qualified RDMA transport such as RoCE or InfiniBand.
- Designed for a lower-overhead data path
- Requires compatible adapters, drivers and fabric
- Operational quality determines whether the advantage is realised
Compare what must be operated—not just what crosses the wire
These characteristics are architectural tendencies. Exact performance and support depend on the implementation, release, hardware and workload.
| Protocol | Command model | Fabric | Routing | Host data path | Operational strength | Primary dependency |
|---|---|---|---|---|---|---|
| Fibre Channel | SCSI / FCP | Dedicated FC | Fabric-based, not IP routing | HBA-centric | Mature SAN procedures and isolation | Qualified HBA, switch, optics, zoning and path policy |
| NVMe/FC | Native NVMe | FC | Fabric-based, not IP routing | HBA-centric | Retains FC fabric model | End-to-end NVMe/FC host, fabric and target support |
| iSCSI | SCSI over TCP | Ethernet / IP | Routable | TCP software or offload path | Broad compatibility and familiar diagnostics | Correct VLAN, path, MTU, security and multipathing design |
| iSER | iSCSI with RDMA data movement | RDMA network | Depends on selected RDMA transport | RDMA-capable path | Preserves iSCSI semantics | Compatible iSER initiator, target, adapters, drivers and fabric |
| NVMe/TCP | Native NVMe over TCP | Ethernet / IP | Routable | TCP software or offload path | Modern NVMe model on standard Ethernet | Host NVMe/TCP features, target capabilities and independent paths |
| NVMe/RDMA | Native NVMe | RoCE, InfiniBand or another supported RDMA transport | Transport-specific | RDMA-capable path | Lower-overhead fabric path when correctly engineered | Complete RDMA qualification and operational fabric discipline |
Use the installed environment to narrow the candidates
Existing or deliberately selected FC fabric
Prioritise mature FCP interoperability, zoning and host multipathing.
Use only when the host, HBA, switches and target support the native NVMe path.
Ethernet or RDMA fabric
Choose for broad compatibility and an established IP SAN operating model.
Retain iSCSI semantics on a qualified RDMA path.
Use native NVMe on routable standard Ethernet.
Use when the complete RDMA network and host path are validated.
The application influences the decision, but rarely determines it alone
Compatibility and recovery behaviour
Validate the ESXi release, initiator, path policy, datastore design and target behaviour. Fused-command support is especially relevant for NVMe-oF and is not identical across storage implementations.
MPIO and cluster coordination
Choose a supported block path and enable the required multipathing on every host. Virtual Fibre Channel adds separate NPIV and guest-level design requirements.
External shared storage consumer
eEVOS can consume compatible shared block storage through integrated initiators while providing virtualisation and integrated Backup & Disaster Recovery.
Latency consistency and recovery
Measure the complete I/O path and confirm database behaviour during path transitions. A lower protocol overhead does not repair an undersized or unstable storage system.
Broad initiator support
iSCSI or established FC may reduce integration risk when several host generations must share the same storage platform.
Parallelism and fabric efficiency
NVMe-oF may align well with highly parallel workloads, but the fabric, CPU, accelerator data path and storage media must be evaluated together.
The protocol does not create high availability by itself
A resilient design must survive failures across the entire data path and preserve storage ownership correctly.
Host path
Separate initiator ports, drivers and multipathing logic must recognise and recover from a failed path.
Network fabric
Two cables connected to one switch or one upstream component are not independent failure domains.
Target service
Target ports, addresses or controllers must fail over without presenting conflicting ownership.
Data layer
Replication, shared-pool ownership or scale-out placement determines whether the underlying data remains available.
Every option moves complexity to a different place
TCP-based storage
Routable networks, familiar tools and broad availability of Ethernet skills.
Congestion, path independence, MTU consistency, host CPU usage and storage traffic isolation.
iSCSI for SCSI compatibility; NVMe/TCP for a native NVMe command model.
Specialised fabrics
Dedicated operational domain and a data path engineered specifically for storage.
Qualification, firmware, optics, fabric configuration and availability of specialist skills.
FCP or NVMe/FC on Fibre Channel; iSER or NVMe/RDMA on a qualified RDMA fabric.
Map each platform to its actual storage role
euroNAS is used as a practical implementation example. The protocol still has to match the current release, licence, hardware and validated client platform.
| Platform | Target protocols in this comparison | Initiator / consumer role | Availability model | Best architectural question |
|---|---|---|---|---|
| euroNAS Premium | FC, iSCSI/iSER and NVMe-oF transports on qualified hardware | Integrated initiators where supported | Standalone storage server, including virtual storage appliance deployments | Is one storage server appropriate for the required service level? |
| euroNAS HA Cluster | Highly available FC, iSCSI/iSER and NVMe-oF targets on qualified hardware | Integrated initiators where supported | Two-node automatic service failover using a synchronous Mirror or a shared-storage model; asynchronous ZFS replication is a separate DR option | Which data model and failover behaviour should the two nodes provide? |
| eEKAS | iSCSI/iSER and NVMe-oF targets No FC target | Can consume compatible external FC targets through its FC initiator | Ceph scale-out storage without a fixed two-node boundary | Does the project need distributed capacity and gateway scale rather than a two-controller system? |
| eEVOS | No storage target role in this comparison | Consumes compatible external shared block storage through integrated initiators | Virtualisation platform with integrated Backup & Disaster Recovery | Should the platform combine compute, virtualisation, backup and storage consumption? |
euroNAS Premium
Use when a standalone storage appliance should present several file and block services.
HA Cluster
Use when target services and their protected data must fail over between two storage nodes.
eEKAS
Use for Ceph-based scale-out storage; external FC storage is consumed only through an initiator.
eEVOS
Use as a VMware alternative that combines virtualisation, storage consumption and Backup & Disaster Recovery.
VMware fused commands: for NVMe-oF projects, confirm that the complete target implementation supports the command behaviour required by the selected VMware release. Protocol connectivity alone is not sufficient, and support differs between storage manufacturers. The euroNAS NVMe-oF target platforms described here support fused commands and multipathing.
Standards and platform guidance
iSCSI protocol
IETF RFC 7143 defines the SCSI-over-TCP protocol, sessions, naming and security considerations.
NVMe over Fabrics
NVM Express explains how native NVMe commands operate across TCP, RDMA and Fibre Channel transports.
NVMe/TCP
NVM Express documents the mapping of NVMe queues and data delivery over TCP.
NVMe/RDMA
The NVM Express RDMA transport specification defines NVMe data and memory transfer across an RDMA fabric.
Fibre Channel
SNIA explains FC fabric topology, lossless in-order block delivery and redundant-fabric practices.
VMware multipathing
Broadcom documents ESXi path-selection policies and ALUA active/optimised behaviour.
Microsoft MPIO
Microsoft documents MPIO requirements for Fibre Channel and iSCSI storage in Hyper-V environments.
Linux DM Multipath
Red Hat explains how multiple SAN paths become one logical block device with failover.
Turn the shortlist into a validated architecture
Share the hosts, applications, existing switches, adapters, availability targets and operational constraints. The result should be a supportable end-to-end design—not merely a protocol name.
Fibre Channel, NVMe, iSCSI, VMware, Hyper-V and related marks belong to their respective owners. VMware and Microsoft are referenced as technical interoperability examples; this page does not imply a partnership or certification. Statements are architectural guidance rather than performance guarantees. Supported configurations depend on current product releases, licences, qualified hardware, drivers, firmware, switches and validated client platforms.