Start with the workload—not the product name
Choose storage and virtualisation architecture by access semantics, failure boundaries, recovery objectives and growth. Product selection should be the result of that process, not its starting point.
and I/O behaviour
file, block or object
and recovery targets
and operating model
Identify what the application needs from storage
The same capacity figure can describe very different systems. Start with access pattern, concurrency, consistency, recovery and operational ownership.
VMware, Hyper-V or eEVOS
Prioritise: supported shared storage, multipathing, consistent failover and VM-level recovery. eEVOS is also a complete virtualisation alternative with integrated Backup & Disaster Recovery.
Open the virtualisation guide →Transactional and latency-sensitive I/O
Prioritise: durable writes, predictable tail latency, path resilience and application-consistent recovery. Benchmark the real database profile.
Compare block-access choices →Kubernetes persistent data
Prioritise: CSI integration, access modes, failure-domain alignment, lifecycle behaviour and protection outside the Pod.
Open the Kubernetes guide →Parallel data pipelines
Prioritise: aggregate throughput, metadata behaviour, network design and feeding multiple compute nodes. GPUDirect Storage is not implied.
Open the AI and HPC guide →Editing, ingest and rendering
Prioritise: concurrent sustained streams, shared namespace, project protection and predictable collaboration across clients.
Open the media guide →Continuous recording and evidence
Prioritise: sustained write load, retention, camera/VMS compatibility, failure behaviour and practical retrieval.
Open the surveillance guide →SMB and NFS collaboration
Prioritise: identity, permissions, locking, client mix, namespace and service failover—not only aggregate bandwidth.
Review file-access characteristics →S3 for applications or service providers
Prioritise: API compatibility, tenancy, protection, lifecycle, quotas and operating model. MSP requirements deserve a separate design.
Open the enterprise S3 guide →Choose the interface the workload can use correctly
A protocol is not a performance guarantee. Hosts, networks, path design, queue behaviour, storage media and the application all influence the result.
| Access | Data model | Good starting point | Design trade-offs to validate | Technical guide |
|---|---|---|---|---|
| SMB | File | Windows-oriented file services, collaboration, media and application shares | Identity, ACLs, locking, dialect and multichannel/client support | SMB & NFS |
| NFS | File | Linux/Unix applications, VMware NFS and shared namespaces | Version, locking, identity mapping, mount behaviour and failover | SMB & NFS |
| iSCSI | Block over Ethernet | Broadly understood shared block storage for virtualisation and applications | Multipathing, network isolation, host filesystem ownership and queue design | iSCSI → |
| Fibre Channel | Block over FC fabric | Established enterprise SAN environments with operational FC expertise | Zoning, dual fabrics, HBAs, multipathing and lifecycle cost | Fibre Channel → |
| NVMe/TCP | NVMe block over TCP/IP | Modern Ethernet block storage without an RDMA requirement | Host qualification, multipathing, loss/latency, CPU and end-to-end support | NVMe-oF → |
| NVMe/RDMA | NVMe block over RDMA | Low-overhead, latency-sensitive fabrics where the complete path is qualified | RoCE/InfiniBand engineering, NICs, switching, congestion and operational skills | RDMA → |
| S3 | Object | Applications, archives, backup targets and multi-tenant services using an S3-compatible API | Application compatibility, consistency expectations, object sizing, lifecycle and tenancy | Enterprise S3 → |
Do not translate file access into block access casually. With block storage, the host normally owns the filesystem and coordination. Multiple hosts require an application or clustered filesystem designed for shared block access.
Select the failure boundary—not an abstract “HA” label
Decide which faults must be tolerated automatically, which events may use a recovery procedure and how much history must remain independently recoverable.
One storage server
Focused and economical, but server-level failure is not masked by a second storage node. Add independent recovery and an operational plan.
Automatic two-node failover
Protects local service continuity through synchronous Mirror or dual-controller shared storage. Latency, quorum and paths matter.
Separate recovery copy
Provides a recoverable point at another system or site. The data gap follows the last completed replication cycle.
Scale-out continuity
Places data across multiple nodes and failure domains. Quorum, protection policy, free capacity and network design set the tolerance.
Backup and retained versions
Protects against deletion, corruption or unwanted change. A second live copy alone is not a historical backup.
Can the service continue after a component, path or node fails?
Can a service be restored beyond the local failure boundary within its RPO and RTO?
Can known historical data be recovered independently and verified?
Compare euroNAS examples after the requirements are clear
The platforms below solve different operational problems. None is universally “best”; the right shortlist depends on the architecture already defined.
| Decision point | euroNAS Premium | HA Cluster | eEKAS | eEVOS |
|---|---|---|---|---|
| Primary role | Storage OS for one physical server or Virtual Storage Appliance | Automatic two-node storage service | Distributed Ceph storage platform | Virtualisation platform with integrated data protection |
| Topology | Standalone, scale-up | Two nodes: synchronous Mirror or dual-controller shared storage | Multi-node scale-out without a fixed two-node boundary | Compact, two-node, shared-storage or scale-out virtualisation designs |
| Client services | File, block and S3 services | Highly available file, block and S3 services | Ceph block, file and S3 services | Virtual machines; storage can be internal, external shared or Ceph-based |
| Availability | Depends on the server design; asynchronous replication can provide a separate recovery copy | Automatic local service failover within the supported two-node architecture | Distributed service and data protection across nodes and failure domains | VM availability, live migration and cluster operation according to the chosen topology |
| Growth model | Scale up inside one server | Scale up inside the two-node design | Add qualified nodes and capacity; rebalance across the distributed cluster | Add compute nodes at any time; they use the configured internal, external or Ceph storage |
| Recovery scope | Snapshots and asynchronous replication for storage-level recovery workflows | Automatic failover plus snapshots and separate asynchronous replication options | Distributed protection plus application-appropriate backup or external recovery processes | Integrated Backup & Disaster Recovery, including Instant Backup & Recovery, network backup and cloud backup |
| S3 operations | S3-compatible service and integrated S3 File Manager; bucket-count quotas | S3-compatible service and integrated S3 File Manager; bucket-count quotas | Ceph S3, S3 File Manager, bucket-count and capacity quotas; billing functions for service-provider use | Not the general-purpose S3 storage platform in this comparison |
| Important distinction | No automatic two-node storage failover | Fixed local two-node architecture; not a distributed scale-out cluster | Requires appropriate node count, network, capacity reserve and distributed-system planning | A virtualisation platform rather than a storage product. It does not provide storage services itself, but can use internal storage, external shared storage and Ceph-based storage. |
| Best first fit | Focused standalone storage with a defined scale envelope | Compact automatic local storage HA | Larger scale-out storage, Ceph services and MSP-oriented S3 | Organisations wanting virtualisation, VM operations and recovery in one platform |
| Product detail | Premium → | HA Cluster → | eEKAS → | eEVOS → |
The table is a first-selection aid, not a compatibility statement or sizing result. Confirm the required protocols, host versions, hardware, network design and application behaviour for the proposed configuration.
A product follows the operating model
Use these questions to narrow the architecture, then validate the workload and protocol in detail.
- Do you need a complete virtualisation platform or storage for another hypervisor?
- Must storage continue automatically after a complete server failure?
- Is the growth boundary one server, two nodes or a distributed cluster?
- Are backup and recovery required for VMs, storage data or both?
- Which team will operate the network, hosts, storage and recovery procedures?
Four architectures cover very different boundaries
Standalone storage
hosts
server or VSA
Simple ownership and a defined scale-up envelope. Add a separate recovery destination where required.
Premium example →Two-node storage HA
node A
node B
Automatic failover with synchronous local protection or a shared-storage controller model.
HA Cluster example →Distributed storage
endpoints
and services
Block, file and S3 services distributed across qualified nodes and explicit failure domains.
eEKAS architecture →Virtualisation platform
compute
or Ceph storage
VM lifecycle, availability and integrated recovery with storage chosen for the required topology.
eEVOS architecture →Validate the complete service, not only the storage appliance
A credible design combines measured workload data with current compatibility and a tested operating procedure.
Supported protocol, versions, filesystem ownership, consistency and recovery requirements.
Capacity growth, block and object size, read/write mix, concurrency, latency and burst behaviour.
Device, node, switch, rack, power and site events that the service must tolerate.
RPO, RTO, retention, restore granularity, immutability and responsibility during an incident.
Bandwidth, redundancy, multipathing, zoning/VLANs, RDMA configuration and operational visibility.
Expansion steps, maintenance windows, rebuild reserve, monitoring, skills and lifecycle ownership.
Turn requirements into a shortlist
We can review the workload, access method, failure domains, recovery objectives and growth plan for a business storage or virtualisation project.