Parity level
dRAID1, dRAID2 and dRAID3 tolerate one, two or three child-device failures per vdev respectively, while sufficient readable redundancy remains.
Distributed RAID for ZFS
High-capacity storage without scale-out complexity
dRAID distributes data, parity and optional spare capacity across a larger disk population. It is a cost-conscious option when the requirement is one large storage system—not independent-node scale-out.
Supported euroNAS products: euroNAS Premium and euroNAS HA Cluster.
Large disk population12 to 255 selected data disks in the current euroNAS creation workflow
↓
dRAID vdevConfigurable single, double or triple parity
↓
Distributed recovery capacityReserved across participating disks, not concentrated on one idle spare
↓
File and block servicesCapacity delivered through the required euroNAS storage services
The essential idea
Recovery work and reserved spare space are distributed
When recovery handling activates a distributed spare, surviving disks contribute reserved capacity and reconstruction work. A failed physical drive still has to be replaced.
Distributed spare capacity
Reserves disk-equivalents as a recovery destination across the vdev. It does not add another parity level.
Data columns
Balance nominal capacity efficiency against allocation behaviour. Wider groups can waste more capacity for small blocks.
“Distributed” does not mean scale-out. dRAID spreads layout and recovery activity within one ZFS vdev. It does not copy the pool between independent storage servers.
Why organisations evaluate dRAID
Practical benefits for large local storage
Use large disk populations efficientlyChoose one, two or three parity columns together with planned recovery capacity.
Avoid one recovery bottleneckSurviving devices participate in reconstruction instead of depending only on the write bandwidth of a single spare disk.
Keep the operational model compactBuild a large pool in one server or a shared-storage HA system without deploying a multi-node scale-out storage cluster.
Retain ZFS data servicesUse checksums, scrubs, datasets, snapshots, compression and asynchronous replication around the pool.
Architecture selection
dRAID, conventional ZFS layouts and scale-out are not interchangeable
dRAID can be substantially simpler and more economical when the failure boundary and growth model fit one storage system. Scale-out remains the stronger choice when independent nodes, horizontal service growth or distributed site design are requirements.
| Question | Mirror / RAIDZ | dRAID | Scale-out storage |
|---|---|---|---|
| Primary model | One ZFS pool built from conventional vdevs. | One ZFS pool with a large distributed RAID vdev. | Data distributed across independent storage nodes. |
| Typical strength | Flexible vdev design; mirrors often suit random I/O. | High-capacity repositories and distributed reconstruction. | Horizontal capacity, performance and failure-domain growth. |
| Growth boundary | Within the server or shared-storage design. | Within the server or shared-storage design. | Add qualified nodes and redistribute data across the cluster. |
| Operational effort | Compact storage administration. | Compact storage administration with more geometry planning. | Cluster networking, node services and distributed operations. |
| Best economic fit | Small to medium pools or latency-sensitive layouts. | Large capacity in one system where scale-out is unnecessary. | Environments requiring node-level scale and distributed resilience. |
Fair comparison: dRAID is not “Ceph at a lower price”. It is a different architecture. The saving comes from avoiding scale-out infrastructure when the project does not require scale-out behaviour.
Workload fit
Capacity-oriented workloads are the natural starting point
More disks do not automatically mean lower application latency. Representative testing should include block size, file size, compression, occupancy and simultaneous client activity.
Capacity planning
Parity, spare capacity and data width must be chosen together
The euroNAS wizard estimates geometry before metadata, allocation padding, reserved space and operational headroom. Actual application capacity is lower.
(N − S) × D ÷ (D + P) × smallest disk
NNumber of selected child disks.
SDistributed spare disk-equivalents.
D + PData columns plus parity columns per redundancy group.
Small-block consideration: dRAID uses fixed-width allocation. Small or strongly compressed blocks can consume more physical space than their logical size suggests. Test the actual workload before finalising the geometry.
Premium and HA Cluster
The same disk protection, two availability models
euroNAS Premium
One server owns and operates the dRAID pool. This is the simplest model for a large-capacity storage repository where controller redundancy is not required.
- dRAID1, dRAID2 or dRAID3
- Distributed spare capacity
- ZFS snapshots and asynchronous replication
- File and block storage services
euroNAS HA Cluster
Both controllers can access the shared disks, while exactly one owns the pool for read/write access. Cluster policies coordinate safe takeover and dependent services.
- dRAID1, dRAID2 or dRAID3
- HA manages controller or node continuity
- Client reconnect and multipathing remain part of the design
- Replication or backup provides the independent recovery copy
Layered resilience
dRAID protects disks—not every failure around them
Disk faults
dRAID: reconstructs unavailable data within the selected parity tolerance.
Controller outage
Add HA: coordinated pool and service takeover requires HA Cluster.
Pool or site loss
Add replication: asynchronous transfer maintains a separate recovery copy.
Deletion or attack
Add recovery policy: snapshots, isolated backup and tested restoration remain essential.
Special devices require equal care: metadata or special-allocation devices are durable parts of the pool, not disposable caches. They need a redundant, qualified design and access from both controllers in an HA system.
Evaluate dRAID from the workload and failure boundary
Compare capacity, latency, recovery time, future growth and operational effort before choosing the geometry.
Capacity figures are planning estimates. Actual usable capacity and recovery time depend on geometry, disk size, workload, metadata, allocation behaviour, free-space headroom and the installed euroNAS release. dRAID, HA, replication and backup are separate protection layers.