One Ceph platform for block, file and object data
eEKAS turns standard x86 servers into a resilient, independently scalable storage cluster. It provides shared storage services for external hosts while the graphical management layer makes complex Ceph operations accessible to enterprise IT teams.
iSCSI · NVMe-oF
SMB · NFS
S3
Dedicated storage nodes serve independent clients and applications.
Ceph as a dedicated storage service
eEKAS is designed for organisations that want storage to scale independently from compute. Capacity, performance and protection are distributed across multiple storage nodes, while applications consume services over standard protocols.
This is a different operating model from hyperconverged eEVOS: eEVOS combines virtualisation and Ceph storage on the same platform; eEKAS concentrates on serving storage to VMware, Hyper-V, eEVOS, databases, backup systems and other clients.
eEKAS or eEVOS Ceph?
Choose according to the workload boundary—not simply according to the storage technology.
- eEKAS: independent scale-out storage for multiple external consumers.
- eEVOS Ceph: hyperconverged storage integrated with the eEVOS virtualisation platform.
- Both approaches use distributed Ceph principles, but address different operational teams and expansion patterns.
Use the protocol that fits the application
A single cluster can present different service types. Protocol choice still matters: each interface has its own access model, host integration and performance characteristics.
Block storage
Present volumes to servers and hypervisors where the host controls the file system. NVMe-oF is suited to modern, latency-sensitive designs; iSCSI remains broadly established.
File storage
Provide shared namespaces for users, applications and workflows. SMB/CIFS and NFS simplify access where several clients work with the same files.
Object storage
Deliver S3-compatible object access for applications, repositories and large unstructured datasets. Multi-zone and multi-site designs are available for broader resilience requirements.
Separate client access, service continuity and data placement
A sound Ceph design is more than a group of disks. Client services, cluster communication and storage failure domains must be planned together.
Replication and erasure coding solve different problems
Protection profiles should be matched to workload, capacity efficiency, recovery objectives and the number of available failure domains.
Copies for predictable performance
Data is stored as multiple complete copies across selected failure domains.
- Often appropriate for latency-sensitive block workloads and metadata.
- Simpler read and recovery behaviour.
- Consumes more raw capacity than erasure coding.
Capacity efficiency at scale
Data and parity chunks are distributed across multiple nodes.
- Well suited to large capacity and object-oriented workloads.
- Improves usable-capacity efficiency.
- Introduces additional computation, recovery traffic and design constraints.
Select the protection model in the GUIThe creation wizard explains both choices before the administrator selects a profile. No Ceph command syntax or manual pool creation is required.Important:
Redundancy keeps services available through component failures; it does not replace an independent backup, retention strategy or disaster-recovery copy.
Keep client endpoints available when a node fails
eEKAS IP Groups treat service addresses and their associated services as movable units. If the preferred node becomes unavailable, the group can move to a healthy cluster node, reducing manual intervention and preserving the client-facing endpoint.
S3 access can additionally use load-balanced endpoints so requests are distributed across available gateways.
ACTIVE
Routine operation through guided workflows
Administrators do not need Ceph command-line knowledge or previous Ceph experience to provision and manage everyday eEKAS services.
Cluster creation, drive selection, pool protection, metadata placement, service endpoints and health monitoring are presented in the euroNAS graphical interface.
Good architecture still matters: node balance, failure domains, network capacity and recovery headroom should be planned for every production cluster.
DB/WAL and file-system metadata are different acceleration layers
Both may benefit from faster media, but they serve different parts of the storage stack. eEKAS exposes both decisions through guided graphical workflows.
BlueStore DB/WAL offload
Each Ceph OSD uses BlueStore. Its RocksDB database stores internal object metadata, while the write-ahead log records small transactional updates. With HDD-backed OSDs, placing DB/WAL on substantially faster SSD or NVMe media can reduce metadata latency and improve responsiveness.
- Most relevant when the main OSD device is an HDD.
- The fast device must be sized and protected as part of the node design.
- It accelerates OSD internals; it is not the same as a CephFS metadata pool.
CephFS metadata pool
A Ceph file system separates namespace metadata from file content. Directories, file names, permissions and related metadata generate small, latency-sensitive I/O. Placing this metadata pool on SSD or NVMe can improve directory traversal, file creation, deletion and other metadata-heavy operations while bulk file data remains on capacity media.
- Useful for large directory trees and many small files.
- The data pool and metadata pool can use different media and protection profiles.
- eEKAS guides drive selection and creates the required metadata pool.
In short: DB/WAL accelerates the internal work of every OSD; the CephFS metadata pool accelerates file-system namespace operations.
They may use the same class of faster media, but they are independent design choices and should not be confused.
1Independent pools
Different pools may use different media and protection profiles, allowing the architecture to reflect workload classes rather than one global compromise.
2Balanced nodes
Consistent drive, CPU and network characteristics across nodes help Ceph distribute work predictably and recover efficiently.
Start with the right failure domains, then expand
Clusters can begin with three nodes, although five or more are generally recommended for broader design freedom and maintenance headroom. Current eEKAS configurations can grow to as many as 60 nodes, subject to workload and architecture qualification.
Where dedicated scale-out storage delivers value
Virtualisation clusters
Shared block or file storage for VMware and Hyper-V, and external shared storage for eEVOS where compute and storage should scale independently.
Databases and analytics
Distributed block storage for platforms that need resilient capacity and planned multipath access.
Media and research
Large shared namespaces and scalable throughput for growing unstructured datasets.
Backup repositories
Capacity-efficient storage targets with clearly separated backup software and retention policies.
Private S3 services
S3-compatible object access for applications, archives and data services; a dedicated S3 technology page will examine the details.
Service-provider platforms
Multiple protocols and independently scalable capacity for diverse tenant or departmental workloads.
Cluster status without a wall of command output
The interface consolidates cluster-wide health, capacity, pools and OSD placement into two equally weighted operational views.
Cluster drive overviewSee raw and usable capacity, OSD state and the replicated or erasure-coded pools associated with each cluster drive.
OSD status by nodeReview which OSD belongs to which node, its state, utilisation and any assigned DB/WAL device.Plan the cluster around your workloads
Share your protocols, capacity growth, failure domains and recovery expectations. We will help translate them into a practical eEKAS architecture.
Technical background: Ceph architecture, erasure coding and BlueStore configuration. Product capabilities and supported configurations depend on the current euroNAS release and qualified system design.