Solutions and technologies

Choose the architecture for the outcome you require

Explore storage and virtualisation by workload, technology or operational objective. The right product is easier to identify once access, availability, recovery and growth are understood.

Three ways to enter the same architecture process
WORKLOAD
What runs?
TECHNOLOGY
How is data accessed?
OBJECTIVE
What must improve?
ARCHITECTURE AND STORAGE SELECTION GUIDEWorkload → access → availability and recovery → scale → shortlist
Application firstCompatibility and access semantics define the viable paths.
Architecture before productFailure boundaries and growth determine the operating model.
HA is not backupContinuity and historical recovery solve different events.
Validate the complete pathHosts, networks, storage and operations form one service.
Choose by workload

Start with what the organisation needs to run

Each workload creates a different mixture of latency, throughput, concurrency, retention and recovery requirements.

DATABASES

Transactional workloads

Design for durable writes, predictable tail latency, path resilience and recovery that respects database consistency.

Database storage guide →
CONTAINERS

Kubernetes persistent data

Align CSI integration, access modes, volume lifecycle and data protection with the cluster’s failure domains.

Kubernetes storage guide →
AI & HPC

Data-intensive compute

Keep compute supplied through aggregate throughput, metadata planning and a network designed for parallel demand.

AI and HPC storage guide →
MEDIA

Editing, ingest and rendering

Plan for sustained concurrent streams, a shared namespace, predictable collaboration and recoverable project data.

Media storage guide →
SURVEILLANCE

Continuous video recording

Balance continuous writes, retention, VMS compatibility, failure behaviour and reliable evidence retrieval.

Surveillance storage guide →
FILE SERVICES

SMB and NFS

Choose file access around clients, identity, permissions, locking, namespace and service availability.

SMB and NFS guide →
OBJECT SERVICES

Enterprise and MSP S3

Separate application object storage from provider requirements such as tenancy, capacity quotas, billing and branded end-user access.

Choose by technology

Understand the access model before comparing speed

File, block and object storage expose different semantics. The protocol must fit the application before performance optimisation begins.

FOUNDATION

Block, file or object?

Understand who owns the namespace, filesystem and data lifecycle.

Compare data models →
MODERN BLOCK

NVMe over Fabrics

NVMe/TCP and NVMe/RDMA bring NVMe commands across a network fabric.

Explore NVMe-oF →
LOW-OVERHEAD NETWORKING

RDMA

RoCE, RoCEv2 and InfiniBand can reduce transport overhead when the complete path is engineered correctly.

Explore RDMA →
ETHERNET BLOCK

iSCSI

A mature block-storage choice with broad host knowledge and familiar Ethernet operations.

Explore iSCSI →
SAN FABRIC

Fibre Channel

Dedicated enterprise block fabrics with established zoning, multipathing and operational practices.

Explore Fibre Channel →
FILE ACCESS

SMB and NFS

Shared files, permissions and locking for Windows, Linux/Unix and supported application environments.

Compare SMB and NFS →
DISTRIBUTED STORAGE

Ceph with eEKAS

Scale-out block, file and object services across multiple nodes and explicit failure domains.

Explore scale-out Ceph →

A faster protocol cannot correct the wrong data model. Application support, consistency, host ownership and recovery behaviour remain selection criteria even when bandwidth and latency are important.

Choose by objective

Focus the design on the operational outcome

A project may combine several objectives, but each one changes a different part of the architecture.

Backup & disaster recovery

Separate availability, replication, historical recovery and disaster recovery by event and objective.

Backup and DR guide →

Cyber resilience

Protect clean recovery points across separate trust boundaries and define how verified services return after an incident.

Ransomware recovery guide →

Simpler operations

Use graphical workflows and integrated lifecycle controls to reduce routine command-line dependency.

Use the selection guide →
Not sure where to start?

Use one decision path across every technology

The Architecture and Storage Selection Guide turns workload, access, availability, recovery and growth requirements into an architecture shortlist. euroNAS products appear only after those requirements are clear.

1 · WORKLOADI/O and application behaviour
2 · ACCESSfile, block or object
3 · RESILIENCEHA, recovery and failure domains
4 · GROWTHscale-up, two-node or distributed
RESULT · a supportable architecture and a shortlist to validate
Implementation examples

Different euroNAS products serve different operating models

These are practical examples, not a universal ranking. Selection should follow the workload, failure boundary, recovery objectives and scale model.

STANDALONE STORAGE

euroNAS Premium

Storage OS for one physical server or Virtual Storage Appliance.

  • File, block and S3 services
  • Scale-up within the selected server
  • Snapshots and asynchronous replication options
A focused storage model; automatic two-node storage failover requires a different architecture.
Premium details →
TWO-NODE STORAGE HA

HA Cluster

Automatic local storage service failover within a supported two-node design.

  • Synchronous Mirror or dual-controller shared storage
  • File, block and S3 services
  • Separate asynchronous replication options
Designed for compact local HA rather than distributed multi-node scale-out.
HA Cluster details →
DISTRIBUTED STORAGE

eEKAS

Graphically managed Ceph storage for multi-node scale-out services.

  • Ceph block, file and S3
  • Failure-domain-based protection
  • S3 File Manager, capacity quotas and billing options
Requires an appropriate node count, network, free-capacity reserve and distributed-system design.
eEKAS details →
VIRTUALISATION PLATFORM

eEVOS

A virtualisation product rather than a storage product.

  • VM lifecycle, availability and live migration
  • Integrated Backup & Disaster Recovery
  • Uses internal, external shared or Ceph-based storage
It does not offer storage services itself; it can consume the storage architecture selected for the virtualisation environment.
eEVOS details →
Architecture patterns

See how the operating models differ

Standalone storage

Application
hosts
One storage
server or VSA

Defined scale-up boundaries and straightforward ownership.

Premium example →

Two-node storage HA

Storage
node A
Storage
node B

Automatic service failover with synchronous local protection or shared storage.

HA architecture guide →

Distributed storage

Client
endpoints
Ceph nodes
and services

Scale-out block, file and S3 across explicit failure domains.

eEKAS architecture →

Virtualisation platform

eEVOS
compute
Selected
storage model

Virtual machines and integrated recovery using internal or external storage.

eEVOS architecture →
Before implementation

Validate the complete business service

The final design must be checked against current application support, measured load and operational recovery procedures.

Compatibility

Application, host, hypervisor, protocol, driver and supported topology.

Measured workload

Capacity growth, concurrency, read/write mix, block or object size, latency and bursts.

Failure boundaries

Device, path, node, rack, power and site events that must be tolerated.

Recovery objectives

RPO, RTO, retention, restore granularity and responsibility during an incident.

Network design

Bandwidth, redundant paths, zoning or VLANs, RDMA configuration and monitoring.

Operations and growth

Expansion, maintenance, capacity reserve, skills, testing and lifecycle ownership.

Start with the requirement, then shortlist the platform

We can review the workload, access method, failure domains, recovery objectives and growth model for a business storage or virtualisation project.

Discuss your architecture
Scroll to Top