SAS Zoning: Sharing a JBOD Between Servers Safely
Connect two servers to the same JBOD and, by default, both of them see every drive in it. Nothing stops either one from writing to any disk, including one the other server believes it owns. That arrangement works only because something above the hardware is keeping them apart, and if that something is wrong or missing, the result is corruption rather than an error message.
SAS zoning is the hardware-level answer to that problem. This guide explains what it does, when you actually need it, the alternatives that handle the same risk in software, and why most single-server deployments should leave it alone.
What zoning does
A zoning-capable expander can partition its ports into groups and enforce which groups are allowed to communicate. Ports are assigned to zone groups, and a permission table decides which zone groups can see each other.
The practical effect is that server A sees only the drives you assigned to it and has no visibility of server B's drives at all. It is the same idea as zoning on a Fibre Channel fabric, applied to a SAS domain, and it is enforced by the expander rather than by agreement between hosts.
Not every expander supports it. Zoning is a feature of the expander silicon and firmware, and plenty of backplanes and entry-level JBODs do not have it. Confirm before designing around it, and confirm against the specific enclosure model rather than the vendor's range. Our guide on SAS expanders and cascading covers what expanders do generally.
Where it earns its place
Shared JBOD between clustered nodes. Two servers attached to one enclosure, each owning a defined set of drives, is the classic case. Zoning makes that ownership physical instead of a convention.
Splitting one enclosure between unrelated hosts. A large JBOD divided between two workloads that have no business seeing each other's data.
Reducing blast radius. A host that cannot see a drive cannot damage it through a driver bug, a misdirected command or an administrator running the wrong thing on the wrong machine.
Where it does not
A single server with its own JBOD. There is nobody to isolate from. Zoning here adds configuration that can go wrong and buys nothing.
Clustered filesystems and software-defined storage that expect full visibility. ZFS, Ceph, vSAN and clustered filesystems are built to see the devices they manage and coordinate access themselves. Zoning them into partial views fights the design. Our guide on RAID controller versus HBA in IT mode covers why those platforms want direct access.
Where the software layer already handles it. SCSI persistent reservations let hosts claim drives and have the drive itself reject writes from anyone else. Cluster software uses this routinely, and it works without any expander configuration. If your cluster stack already does reservations properly, zoning is belt and braces rather than a requirement.
The failure mode that matters
The reason to be careful is the shape of the failure. A zoning mistake does not usually announce itself.
Too restrictive and drives simply do not appear. Annoying, obvious, quickly fixed.
Too permissive and two hosts both see and both believe they own the same drives. Nothing errors. Both mount, both write, and the filesystem is destroyed in a way that is often not noticed until a read comes back wrong. Restoring from backup is the only reliable recovery.
That asymmetry is the whole argument for treating zoning changes as a change-controlled operation, tested on drives holding nothing, rather than something adjusted on a live enclosure.
Zoning and multipath together
These two features interact and it is worth thinking about them at the same time.
Dual-ported SAS drives can be reached through two independent paths, which is what allows an enclosure to survive an expander or cable failure. A zoning configuration that accounts for only one path leaves you protected on paper and single-pathed in practice.
Note also that SATA drives are single-ported and cannot participate in dual-path redundancy at all, so a mixed enclosure has different resilience for different drives. Our guide on dual-port SAS drives and multipath covers the redundancy model.
Practical advice
Document the zone map alongside the physical layout. Which bay, which zone, which host. A zoning configuration that exists only inside the expander is one firmware reset away from being lost, and nobody will reconstruct it from memory under pressure. Our guide on documentation and labelling that survives makes the general case.
Export and keep the configuration. Most zoning tools can save and restore a map. Treat it like any other configuration backup.
Label the bays physically. An engineer replacing a drive needs to know which host owns that bay before pulling anything.
Check the firmware compatibility matrix. Expander firmware, HBA firmware and driver versions are validated as combinations for shared-enclosure configurations, and this is one of the places where running an unvalidated mix produces intermittent behaviour rather than a clean failure. See hardware compatibility lists.
Consider whether you need shared SAS at all. A shared JBOD is one way to give two hosts common storage, and often not the simplest. Our guide on DAS, NAS and SAN architecture covers the alternatives, and JBOD enclosures explained covers what a shared enclosure requires.
Sourcing
We supply enterprise SAS and SATA drives, HBAs, controllers, cables and carriers for server and JBOD deployments. If you are planning a shared enclosure and need to know whether a specific model supports zoning and what firmware combination is validated for it, send us the enclosure and HBA models and we will check before you commit. Request a bulk quote or email sarah.jane@techsellerusa.com.
Common questions
What is SAS zoning?
A zoning-capable expander partitions its ports into groups and enforces which groups can communicate, so a host sees only the drives assigned to it rather than everything in the enclosure. It is the same idea as Fibre Channel fabric zoning applied to a SAS domain, and it is enforced by the expander rather than by agreement between hosts.
Do I need zoning for a single server and its JBOD?
No. There is nobody to isolate the host from, so zoning adds configuration that can go wrong and buys nothing in return. It is worth considering only when more than one initiator is attached to the same enclosure, or where you want to physically prevent a host from reaching drives it should never touch.
What happens if two servers see the same drives?
Unless something above the hardware is arbitrating, both can mount and both can write, and the filesystem is destroyed. The dangerous part is that nothing errors: there is no warning, and the damage is often noticed only when a read comes back wrong. Restoring from backup is usually the only reliable recovery, which is why permissive zoning mistakes matter far more than restrictive ones.
Is zoning the only way to stop hosts clashing?
No. SCSI persistent reservations let a host claim a drive and have the drive itself reject writes from anyone else, and cluster software uses this routinely without any expander configuration. If your cluster stack handles reservations properly, zoning is belt and braces rather than a requirement. Clustered filesystems and software-defined storage generally expect full device visibility and coordinate access themselves.
Does every SAS expander support zoning?
No. It is a feature of the expander silicon and firmware, and plenty of server backplanes and entry-level JBOD enclosures do not have it. Confirm against the specific enclosure model rather than the vendor's product range before designing a shared-storage solution that depends on it.
How does zoning interact with multipath?
They have to be designed together. Dual-ported SAS drives can be reached through two independent paths, which is what lets an enclosure survive an expander or cable failure, so a zone map that accounts for only one path leaves you protected on paper and single-pathed in practice. SATA drives are single-ported and cannot use dual-path redundancy at all, so a mixed enclosure has different resilience for different drives.
If you are planning a shared enclosure, send us the enclosure and HBA models and we will confirm zoning support and the validated firmware combination.
