The SAN design reference guide most people are searching for is HPE’s, currently Edition 110 (June 2026), free on the HPE Support Center. Read it alongside Broadcom’s SAN Design and Best Practices and Cisco’s MDS zoning guide. Strip out the switch tables and all three agree on five rules: two fabrics, core-edge layout, sized fan-in, small zones, matched firmware.
None of them were written for someone with an N100 mini-PC, a NAS and a free weekend. They assume director-class Fibre Channel switches, dual-controller arrays and a change board that meets on Tuesdays. The useful part for a small setup is the vocabulary and the availability levels, which tell you exactly which rules you are breaking and what that costs. If block storage versus a file share is still fuzzy, read what a SAN storage area network is first.
Which SAN design reference guide should you read?
Start with HPE’s, because it is the only one built as an actual reference: availability levels, topologies, fabric rules, zoning and iSCSI each get their own page, so you can look a rule up instead of reading the whole thing. Use Broadcom’s for sizing, Cisco’s configuration guide for zoning mechanics, and IBM’s Redbook if the vocabulary is new.
| Document | Publisher | Current version | Read it for |
|---|---|---|---|
| SAN Design Reference Guide | HPE | Edition 110, June 2026 | Availability levels, topologies, fabric and interop rules |
| SAN Design and Best Practices (53-1004781) | Broadcom (Brocade) | Revision 07, November 2025 | Fan-in, ISL sizing, monitoring |
| MDS 9000 Fabric Configuration Guide, zoning chapter | Cisco | NX-OS 9.x | Zone sizing, Smart Zoning, default zone policy |
| Introduction to Storage Area Networks (SG24-5470-08) | IBM Redbooks | December 2017, updated October 2018 | Fundamentals and terminology |
Two caveats before you open any of them. All four are vendor documentation, so each one quietly assumes you are buying that vendor’s switches. And a large share of HPE’s guide is interoperability tables: the Edition 110 changes are mostly B-series switch entries, Fabric OS 10.x support and the Gen8 128G platform, none of which matters unless that hardware is in your rack. The design chapters are the part worth reading, and they are general enough to apply to any fabric.
What do the SAN design reference guides agree on?
They agree on five rules: build two independent fabrics, pick a topology that can grow without a redesign, size fan-in by bandwidth, keep zones small with a deny default, and keep switch firmware in step. Everything else in those documents is product detail. Here is each rule and where it comes from.
1. Two fabrics beat one resilient fabric
HPE grades designs on four data availability levels:
| Level | HPE’s name | What it adds |
|---|---|---|
| 1 | Single connectivity fabric | Connectivity only, no fabric resiliency or redundancy |
| 2 | Single resilient fabric | Multiple ISLs between switches, so a failed link reroutes |
| 3 | Single resilient fabric with multiple device paths | Servers and storage each get more than one path into the fabric |
| 4 | Multiple fabrics and device paths (NSPOF) | Paths across physically separate fabrics |
Cisco’s SAN migration white paper is blunter: “In almost all installations of SAN, there are always dual fabrics.” Level 3 falls short because a single fabric shares one configuration. Cisco’s zoning guide notes that only one zone set can be active at a time and that the active set is distributed across the fabric, so one bad zoning change reaches every path at once.
Two fabrics also make maintenance boring, which is the goal. HPE’s expansion guidance points out that you can route server I/O through one fabric while the other is being modified.
2. Core-edge, with room to grow
Hosts connect to edge switches, storage connects to the core, and inter-switch links (ISLs) join them. HPE’s core-edge definitions split this into a fat tree, where at least half the edge ports are ISLs for a 1:1 ratio, and a skinny tree, where fewer than half are, for 2:1 or higher.
Its planning page asks for an initial topology that can grow without changing to a different one, and suggests starting with an entry-level SAN if you are new to this. The expansion page adds: leave spare ports on the core switches for future edge switches. The lesson generalises well beyond Fibre Channel. The first switch you buy decides how painful the second one is.
3. Size fan-in by bandwidth, not port count
Fan-in is how many devices share one storage port or ISL, written from the shared port’s side, so 7:1 means seven hosts on one port. Broadcom’s fan-in and fan-out guidance has a simple rule for the core: a storage port should not be oversubscribed into it, so a 32G storage port needs a 32G pipe behind it. For hosts, it notes that queue depth, IOPS and throughput all matter but only throughput is a network concern, and that virtualized servers already oversubscribe internally, so network oversubscription should drop proportionally.
The same page has the example that should stop anyone from buying one fast port for the array and calling it done. A host on a 32G link reading from two 32G targets can be sent 64G, the host link becomes the bottleneck, and the backpressure congests switches upstream. Ethernet handles overload differently, but the arithmetic carries over: a 10GbE NAS port can send more than a 2.5GbE mini-PC can receive.
4. Small zones, deny by default
Cisco’s zoning guide says “a single initiator with a single target is the most efficient approach to zoning” and advises against large numbers of initiators or targets in one zone. Smart Zoning exists for when that gets unwieldy; it implements hard zoning of large zones with fewer hardware resources. The default zoning policy is deny, and Cisco says to configure it on each switch, because a mismatch between switches can make a zone merge fail.
HPE gives zone naming its own page, which is a hint about how often names go wrong. For why zoning and LUN masking are separate layers, see SAN zoning and LUN masking explained.
5. Firmware moves in step
HPE’s B-series switch rules say all like switch models must run the same firmware version in a single-fabric or multi-fabric SAN, with two successive versions allowed temporarily during an update. With two fabrics that update is a non-event: do fabric A, confirm every host still has its paths, then do fabric B.
How does a SAN design reference guide scale down to a mini-PC and a NAS?
Unevenly, and that is fine. A mini-PC, one switch and a NAS is HPE Level 1. Two storage NICs on each end get device paths to Level 3, and a second switch gets the network to Level 4. A typical home NAS has one controller, though, so it stays a single point of failure whatever the network looks like.
HPE’s iSCSI network requirements fit on a sticky note: a dedicated IP network for iSCSI storage, at least GbE bandwidth, and a multipathing driver when you want high availability. The Proxmox multipath guide gives the home version of Level 4: the two paths “should use at least two dedicated NICs, separate networks, and separate switches.”
| Reference guide rule | Mini-PC and NAS version |
|---|---|
| Two fabrics | Two storage subnets on two switches, or two direct cables to a single host |
| Core-edge topology | Skip it. One switch is your core and your edge |
| Fan-in by bandwidth | Match NAS port speed to what the initiators can absorb |
| Single-initiator zones | Storage VLAN with no gateway, each LUN mapped to one named initiator |
| Firmware in step | Update the NAS by hand, with the VMs on its LUNs shut down first |
Is Level 4 worth it at home? Usually not. Two switches, four storage NICs and a multipath config protect you from a switch dying, and a dead switch is rarely the first thing to take a homelab down. The single-controller NAS rebooting for an update, or a thin LUN quietly filling its pool, gets there sooner. Level 3 on one switch is the fair middle ground if your mini-PC has two ports: you survive a cable pull and you learn multipath without buying anything. How to implement SAN storage walks through that build in order, including the cable-pull test.
If the NAS is all-flash and you are eyeing NVMe/TCP instead of iSCSI, the availability levels apply unchanged. NVMe SAN storage covers when switching transports is worth the extra work.
What do SAN design reference guides leave out?
Mostly, getting data back. The reference guides are about keeping paths up, and a perfectly redundant fabric will faithfully deliver ransomware or a mistyped mkfs down every path at once. Snapshots on the same NAS protect you from a bad upgrade, not from a dead NAS.
Back up VMs to separate hardware, then prove it with a restore drill once a quarter: restore one VM to a new ID with its network disconnected, boot it, check the application data, delete it and write down how long it took. Do the first drill before the first VM you care about lands on the LUN. Until then you have a backup job, not a backup.
They are also light on what to alert on at small scale. Broadcom’s tooling watches every port for oversubscription and congestion. At home, three alerts cover most of it: fewer storage paths than expected, real pool usage on the NAS rather than LUN allocation, and a backup job that did not run. When the SAN is up but slow, SAN high latency: where to look first is the next stop.
FAQ
where can i find the hpe san design reference guide
HPE publishes the SAN Design Reference Guide free on the HPE Support Center as document sd00001803en_us, and the current release is Edition 110 from June 2026. It is split into topic pages, so jump to “Levels”, “Core-edge fabric types” or “Zoning” from the contents instead of reading it front to back.
is the hpe san design reference guide useful without hpe hardware
Yes, for the design chapters. The availability levels, core-edge definitions, planning advice and iSCSI network requirements apply to any Fibre Channel or iSCSI SAN. The switch tables, firmware rules and product-specific zoning tables are HPE-only, so take those from your own vendor’s interoperability documentation, not from HPE’s guide.
what is a good fan-in ratio for a san
There is no universal number; size it by bandwidth and workload. Broadcom’s rule is that a storage port should not be oversubscribed into the core, and virtualized hosts need less network oversubscription than physical ones. Ratios are written from the shared port’s side, so 7:1 means seven hosts sharing one storage port or ISL.
do i need two fabrics for a homelab san
No. Two fabrics protect against one switch or one bad zoning change taking down every path, which matters when downtime costs money. In a homelab, the single-controller NAS is usually the bigger single point of failure. Build one clean storage network, test your restores, and add a second path once you have a reason.
