Storage Area Networks (SAN) Explained: Topologies, Protocols and Monitoring Tools

Storage decisions shape application performance, backup windows and recovery times. A SAN adds a layer of design choices: protocol, topology, zoning and monitoring. This guide walks through each so infrastructure teams can plan, secure and operate one with confidence.

SANs also connect to the wider B2B stack: hypervisors, database platforms, backup tools, ITSM ticketing, SSO for administrators and monitoring systems that feed dashboards and alerts.

What is a storage area network?

A storage area network (SAN) is a dedicated high-speed network that presents block storage from shared arrays to servers as if the disks were local. It separates storage traffic from the LAN and is common in databases, virtualization and mission-critical workloads.

The NIST glossary describes the idea as a network of storage devices that servers access at block level. Hosts see logical units (LUNs) and format them with their own file systems, which is why a SAN suits databases and hypervisors that need predictable low-latency I/O.

Core components

• Hosts with host bus adapters (HBAs) or iSCSI initiators.
• Switches that form the fabric and enforce zoning.
• Storage arrays that expose LUNs from pooled disks or flash.
• Cabling, optics and management software.

SAN protocols: Fibre Channel, iSCSI and NVMe over Fabrics

Fibre Channel, iSCSI and NVMe over Fabrics are the main SAN transports. Fibre Channel uses dedicated switches and HBAs, iSCSI carries SCSI commands over Ethernet and IP, and NVMe over Fabrics extends the NVMe command set across a network for lower latency.

Your choice usually follows existing skills and budget. Teams with Ethernet expertise and modest performance demands often start with iSCSI. Large enterprises with strict latency and isolation requirements keep Fibre Channel. NVMe over Fabrics appears where flash arrays need to remove protocol overhead, and Fibre Channel standards continue to be maintained by technical committees in the storage community.

SAN topologies and when to use each

A SAN topology is the arrangement of hosts, switches and arrays. Common designs are point-to-point, arbitrated loop, single or dual switched fabric, mesh and core-edge. Dual independent fabrics are the usual choice when availability matters.

Single and dual fabric

One switch fabric is simple and cheap but a single failure interrupts every host. Two independent fabrics, with every host and array connected to both, let multipathing software keep I/O flowing when a switch, cable or HBA fails.

Core-edge

Hosts connect to edge switches, while storage and inter-switch links meet at a core. This scales port count and keeps storage close to the center, at the cost of oversubscription you must calculate.

For example, sixteen 16 Gb host ports feeding two 32 Gb inter-switch links gives 256 ÷ 64, a 4:1 ratio. Lower ratios cost more but protect bursty workloads.

Arbitrated loop and point-to-point

These older designs survive in small or legacy setups. They share bandwidth or limit scale, so new builds rarely choose them.

SAN versus NAS and direct-attached storage

A SAN delivers block storage over a dedicated network, NAS delivers files over standard network protocols such as NFS or SMB, and direct-attached storage connects disks to a single server. Choose by access pattern: blocks for databases, files for shared documents.

NAS is easier to deploy and share across users, while a SAN gives servers raw volumes with finer performance control. Many organizations run both: a SAN under virtual machines and databases, NAS for departmental shares. Cloud block storage services play the SAN role for virtual machines in public cloud, and cloud management tools such as CloudBolt or Morpheus Data help govern hybrid estates.

Security and resilience: zoning, LUN masking and multipathing

Zoning limits which ports can see each other on the fabric, LUN masking limits which hosts see which volumes, and multipathing keeps I/O alive across multiple physical paths. Together they protect data from misconfiguration, outages and lateral access.

• Zoning: use single-initiator zones so one host port is paired with only its target ports.
• LUN masking: present each volume only to the hosts that need it, ideally by cluster.
• Multipathing: confirm failover by pulling a link in a maintenance window.
• Management plane: restrict switch and array administration to a segmented network, enforce SSO and role-based access, and log changes.
• Encryption: enable array or fabric encryption where policy requires it for data at rest or in flight.

These controls map to broader guidance on protecting stored data and access paths in the NIST Cybersecurity Framework.

How to monitor SAN performance

SAN monitoring tracks latency, throughput, IOPS, queue depth, port errors and capacity at hosts, switches and arrays. Teams watch for rising response times, credit starvation, CRC errors and capacity growth so they can fix issues before applications slow down.

Dedicated storage resource monitors and general infrastructure platforms both help. General tools such as Nagios XI, SolarWinds Network Performance Monitor and ManageEngine OpManager can poll switches and arrays over SNMP, while Paessler PRTG uses sensors for storage devices. Verify that your array and fabric vendors expose the SNMP or API data you need.

Metrics worth alerting on

• Read and write latency per LUN against an agreed baseline.
• Port errors, link resets and CRC counts on switches.
• Pool capacity and growth rate for forecasting.
• Path status and multipath failover events.

Use the formula for a quick runway estimate, then confirm with the trend graph. Our storage monitoring tools guide compares products in more depth.

How to choose SAN monitoring and management tools

Pick tools that support your array and switch vendors, show real-time alerts, forecast capacity and fit your team's skills. Request a trial against your own fabric before committing, because vendor support for specific models varies.

• Multi-vendor coverage: confirm supported arrays, switches and HBAs.
• Alerting: thresholds, dependencies and integration with your ITSM or chat tools.
• Capacity planning: trend reports and what-if projections.
• Usability: dashboards a storage admin and a network admin can both read.
• Total cost: licensing unit (per device, sensor or port) and the staff time to maintain it.

Browse the full Data Center Networking Software category and Network Monitoring Software category to shortlist options.

SAN implementation checklist

A reliable SAN rollout moves through requirements, design, build, test and operate. Document capacity and performance targets first, design dual fabrics, apply zoning and masking, test failover, then monitor from day one.

• Define workloads, IOPS, latency and growth targets.
• Pick protocol and topology; plan oversubscription.
• Build two fabrics and cable them consistently.
• Configure zoning, LUN masking and multipathing.
• Test failover, restore and rebuild scenarios.
• Enable monitoring, alerts and capacity reports.
• Document runbooks and review firmware compatibility at least twice a year.

Frequently Asked Questions

Is a SAN worth it for a small business?
Usually not at first. Small teams often do better with NAS or cloud block storage, and a SAN pays off when several servers need shared, high-performance block storage for databases or virtualization. Compare total cost including switches, licensing and skilled staff.

Can I migrate from iSCSI to Fibre Channel later?
Yes, but it is a project, not a toggle. You need new HBAs, switches and zoning, then volumes must be moved or re-presented. Plan a phased migration with a rollback path and test with non-critical workloads first.

How long does a SAN deployment take?
A small dual-fabric build can take a few weeks including cabling, configuration and testing. Larger enterprise migrations run for months because of change windows and data moves. Allow time for failover testing before production cutover.