Guides:Highly Available ZFS Storage with Shared SAS JBODs

By Steve Umbehocker, CTO, OSNexus · Updated October 3, 2026

A shared-JBOD HA pair is two storage servers cabled to the same SAS JBOD enclosures, so either server can import the ZFS pool built on those drives while only one of them owns it at a time. QuantaStor turns that hardware into an active-passive cluster: a storage pool HA failover group ties the pool to the two systems, a site cluster running corosync and pacemaker watches both nodes, and a cluster virtual interface (VIF) carries the client IP address to whichever node currently owns the pool. When the owner fails, the surviving node fences the shared disks, imports the pool and brings the VIF and the block and file services up on its side.

Why it matters

A single ZFS server is a single point of failure: a failed motherboard, HBA, boot device or kernel panic takes every share and LUN offline until the server is repaired. Replication to a second system protects the data, but recovery is a DR event with a recovery point behind it. In a shared-JBOD pair there is only one copy of the pool and no replication lag. The standby node simply takes over the drives the failed node was using.

This is the same pattern as a dual-controller enterprise array: two controllers, one set of shared drives, and one controller serving each pool at a time. Here it is built from standard servers and SAS enclosures from the Hardware Compatibility List, and the software layer is open about how it works: OpenZFS (2.3.9 on Ubuntu 22.04 and 24.04 appliances), corosync and pacemaker. For workloads that need storage-side HA without a proprietary controller, that is a viable design, provided the hardware is qualified and the failover is tested before production, as described below.

If the shared back end is an iSCSI or FC SAN rather than SAS JBODs, see HA Cluster Setup (external SAN) instead. Both models are summarized on Clustered HA SAN/NAS Solutions using ZFS.

How it works

The objects nest in a fixed order, and getting the hierarchy right avoids most configuration mistakes (High-availability VIF Management covers it in depth):

Layer	What it does	Reference
Storage grid	Management layer; both nodes must be grid members first	Grid Configuration
Site cluster	Runs corosync and pacemaker and decides where floating resources live	Site Cluster Setup
Heartbeat ring	One port per member on a shared subnet, used only for cluster heartbeats; one or two rings	Site Cluster Setup
HA failover group	Ties one ZFS pool to the systems allowed to import it	Create Storage Pool High-Availability Group
Cluster VIF	The client-facing address; its use case makes it follow the HA group	Cluster VIFs

A heartbeat ring carries cluster traffic and a VIF carries client traffic. They are separate networks. The VIF's parent is the site cluster, not the pool, even though its use case makes it follow the pool.

Fencing. Both nodes can see every drive in the JBOD, so a takeover must make sure the old owner can no longer write. The taking-over node first preempts the SCSI reservations on the pool's disks. Only once IO is fenced does it run the ZFS import, then it starts the pool's targets and shares and brings up the VIF. When one node takes over several HA pools at once, the pools are imported in parallel, so a small pool is not held behind a large one.

Block paths. For FC and iSCSI ALUA pools, the node that does not own the pool still presents every volume on standby paths, through a standby device that advertises the same provisioning, UNMAP and block geometry as the volume. Initiators therefore see one consistent logical unit on both nodes. On failover the old owner moves its LUNs onto the standby devices instead of removing them, so clients keep their paths. The new owner marks its paths active only after the LUNs are mapped back onto the real volumes.

Clustered SCSI-3 persistent reservations. Client clusters that use reservations, such as Windows failover clusters with Cluster Shared Volumes, need those reservations to stay valid when the pool moves. With the HA group's Clustered SCSI3-PR Reservations setting enabled, reservation state is coordinated between the two nodes through a distributed lock manager (DLM), and the LUN stays on the fabric during a failover. Enabling or disabling the setting applies it to every device of the pool on both nodes. The feature is supported on Ubuntu 22.04 and 24.04 appliances only. Windows Server 2022 Hyper-V failover clusters on FC HA pools have been validated with it through manual and automatic failovers, live migration during a failover, and host drain and reboot. See Clustered SCSI-3 Persistent Reservations.

What triggers a failover, and what does not

Each cluster VIF is a pacemaker IPaddr2 resource with a monitor every 10 seconds. The HA group adds its own pool-level policies. Knowing which events move the pool helps you set expectations and plan tests.

Event	Result
Owner node crashes, powers off or leaves the site cluster	Automatic failover to the partner
VIF monitor finds the address no longer configured on the host	Pacemaker restarts the VIF, on the partner if it cannot start locally
All Ethernet ports link-down (default Ethernet port link state policy)	Preemptive pool failover
Client connectivity checks enabled and ALL (or a MAJORITY) of the listed client IPs unresponsive	Preemptive pool failover
One port of several goes link-down	No failover under the default Failover if ALL Ports are Link-Down policy
Client connectivity checks left disabled (the default)	Client reachability is not a trigger
VIF moved with Move Site Cluster VIF	Planned relocation of the address, not a pool failover
Site cluster in maintenance mode	Resources are frozen in place
HA group deactivated, or not associated with a site cluster	No automatic failover on system failure

The last row is easy to miss. The create dialog states it plainly: HA groups that have no associated site cluster cannot perform automatic failovers in system failure events.

Design and sizing

• Shared SAS. Cable each node to each JBOD, and use Multipath Configuration so a single cable or HBA port failure is a path event, not a failover. Check enclosure and drive health under Hardware Controllers & Enclosures.
• Two heartbeat rings on separate networks. This is the recommended configuration, so that losing one network does not look like losing a node. Every port in a ring must be on the same subnet.
• Separate front-end and cluster networks. HA nodes are multi-homed, and VIF failover relies on clients and switches believing the gratuitous ARP from the new owner. QuantaStor sets strict ARP behavior so each interface answers only for its own addresses (shown below).
• Timeouts. The failover dialog warns that a pool failover can take upwards of 30 seconds, and longer for larger configurations. In lab testing, an FC pool moving on its own reached clients again in 40 to 110 seconds. Set client multipath and application I/O timeouts to ride through that window.
• Active Directory. Service SPNs registered on the HA VIF's AD computer object keep working across failover, so SMB and SQL Server clients authenticate against the VIF name on either node.

On multi-homed systems QuantaStor writes /etc/sysctl.d/70-quantastor-arp.conf:

net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.default.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.default.arp_announce = 2

A setup that relies on any interface answering ARP for any local address (for example an address parked on lo) can opt out with the tf_arp_flux_protection.disable touchfile.

Setting it up

The full procedure is in HA Cluster Setup (JBODs). In outline:

1. Add both nodes to the grid, then create a site cluster with its first heartbeat ring and add a second ring (Site Cluster Setup).
2. Create the ZFS pool on the shared JBOD drives from one node, for example pool1.
3. Open Storage Management → Storage Pools → Storage Pool HA Resource Group → Create Group. Pick the pool, set the Export Timeout, choose the Secondary System and set Clustered SCSI3-PR Reservations to suit your clients.

Create Storage Pool High-Availability Group: the Storage Pool, Export Timeout, Primary and Secondary System fields, and the Clustered SCSI3-PR Reservations setting

1. On the Connectivity tab, choose the Ethernet and FC port link state policies. Optionally enable client connectivity checks, add the client IPs (for example 192.0.2.21 and 192.0.2.22) and press Verify Connectivity. Enforce SMB HA VIF Access and Enforce NFS HA VIF Access restrict file access to the VIF address.

The Connectivity tab: port link state policies, the Enforce SMB and NFS HA VIF Access options, and the ALL or MAJORITY client connectivity rule

1. Add a cluster VIF for the HA group, for example 198.51.100.50/24 on the front-end port (Cluster VIFs, Storage Pool HA Failover Interface Create). Point clients at this address, never at a node's own IP.
2. Activate the group (Storage Pool Ha Failover Group Activate). The settings can be changed later with Modify Storage Pool High-Availability Group.

The Storage Pool HA Groups tab: the group is Normal, owned by the primary system, with the default Failover if ALL Ports are Link-Down policy

Operating and testing

Test before production, and retest after hardware or network changes. With a client running a write and read-back loop against a test LUN or share:

1. Confirm the group is Normal and check where the VIF is running. In the VIF grid, Started On (not Managed By) shows where client traffic is going. From either node:

crm_mon -1

1. Run a planned move with Manual Failover (Storage Pool Ha Failover Group Failover), pick the target system, and time how long the client stalls.

Execute High-Availability Pool Failover: the HA group, its current status, and the From and To systems

1. Let the failover finish completely (pool imported, targets active, VIF started) before you issue the next one, then fail back.
2. Test an unplanned failure by powering off the owner node, and a network failure by pulling every front-end link to match your port policy.
3. Check the client data for errors after each test.

For planned maintenance on one node, put it in standby mode (Configure Member Standby) to evacuate its resources. Maintenance mode instead freezes the whole site cluster (Exit Site Cluster Maintenance Mode). Volume assigns and activations issued while a pool is being exported complete on the node that takes it over. If a group does not reach Normal, start with Scale-up HA Storage Pool Troubleshooting.

FAQ

Is this active-active or active-passive?

Each pool is active-passive: one node imports it and serves it, and the partner holds standby paths. You can run both nodes by placing a separate pool and HA group on each one, so both servers carry load and each is the failover target for the other's pool.

How long does a failover take?

Plan for 30 seconds or more, depending on pool size, number of volumes and protocol. A single FC pool measured 40 to 110 seconds of client-visible pause in lab testing. Set initiator and application timeouts to ride through that window, and measure your own configuration with a manual failover.

What stops both nodes writing to the pool at once?

The node taking over preempts the SCSI reservations on the pool's JBOD disks and confirms IO is fenced before it imports the pool. The heartbeat rings, ideally two on separate networks, keep a single network failure from looking like a node failure.

Do I need clustered SCSI-3 persistent reservations?

You need them when the clients are themselves a cluster that uses persistent reservations, such as Windows failover clusters with Cluster Shared Volumes or Hyper-V. The setting is on the HA group, can be changed later with Modify Group, and is available on Ubuntu 22.04 and 24.04 appliances.

Will a single drive or cable failure cause a failover?

A single cable or HBA port failure is absorbed by SAS multipathing, and losing one Ethernet port does not trigger a failover under the default policy. Drive failures are handled by the pool's own RAID layout, such as mirrors or RAIDZ2, on whichever node owns it.

---

Part of the QuantaStor Guides series. For reference documentation, see the QuantaStor documentation.