SAN configuration: where fault tolerance breaks
SAN configuration begins not with purchasing switches, but with a path map: where traffic flows, what happens if any element fails, and how quickly the service will be restored.
The storage area network is a separate circuit, and errors in it do not manifest immediately, but at the moment of peak load or scheduled maintenance, when the reserve is already unavailable.
The most common problem with SAN connectivity is zone misalignment.
A mask on the switch allows one initiator access to a target that has already been moved to another node, and instead of a single VM failing, the entire cluster goes down: the host sees someone else's LUN, the file system goes read-only, the hypervisor loses the storage.
The second typical point is path congestion: all volumes hang on a single HBA or a single uplink, and when the card fails, traffic does not switch over because multipath is configured formally, without verifying the actual failover.
A separate category is the lack of redundancy at the fabric level. One switch, one array controller, a shared cable to the racks: while everything works, the metrics are clean, but the very first firmware update or power supply replacement halts the service for hours. The storage bottleneck here is not in the disks — it is in the architecture of access to them.
The cost of such failures is measured not in equipment downtime, but in product unavailability: transactions do not go through, queues grow, and recovery after replica desynchronization takes longer than the failure itself.
SAN fault tolerance is a property of the entire scheme, not of an individual component. Let's break down how this is addressed at the level of zones, paths, and replication.
What a Properly Configured Storage Network Delivers
What Changes in the Numbers After Configuration
Before configuration, the I/O path goes through a single controller and a single fabric — the failure of any link stops writes.
After configuration with two independent fabrics and a multipath driver on the hosts, failover to the standby path takes seconds rather than minutes of manual intervention.
The share of lost operations when a single link fails drops to zero: the I/O queue is replayed over the live path.
Classes of Failures That Are Eliminated
Proper zoning by WWN eliminates the situation where a host sees someone else's volumes and corrupts data of a neighboring service — this is the most expensive class of incidents.
Separate zones for production and test environments remove "noisy" backup and migration operations from the critical path. HBA failure is addressed separately: with two adapters per node and asymmetric load balancing, the load is redistributed without stopping applications.
Comparison of Access Organization Options
| Option | When It Fits | Limitations |
|---|---|---|
| Single fabric, single path | Small environment, downtime during recovery is acceptable | No automatic failover, switch failure = outage |
| Two fabrics, multipath | Production with a continuity requirement | More expensive in ports and licenses, requires zoning discipline |
| Software storage over the network | Flexibility and fast provisioning of new volumes | Sensitive to network latency, requires QoS configuration |
What Delivers a Measurable Effect
Properly set queue sizes and failover timeouts deliver predictable recovery time: when a path fails, the application does not notice the interruption.
Consistent snapshots at the volume level shorten the backup window and allow data to be rolled back to the point before the failure. We verify the result with link-disconnection tests — not according to documentation, but by the actual failover.
Brocade
Stages of implementing SAN connectivity for a task
Setting up SAN is not "plug in an HBA and configure zoning." A mistake at the design stage of the connection scheme surfaces months later: the path degrades under load, the volume drops out at peak transactions, and rollback requires stopping the service.
That is why we build the SAN setup process as a sequence with checkpoints, where each stage is closed by a measurable result, not by the fact that "the command executed."
- Infrastructure audit. We build a map: which servers and storage systems already exist, how many ports are free on the switches, how the paths are laid out, where the throughput bottlenecks are. The output is a list of constraints that cannot be worked around by configuration.
- Designing the SAN connection scheme. We determine the topology: how many independent paths per volume, how the switches are separated, where the failure points are. The scheme is fixed before installation — redoing it on a live system costs many times more.
- Switch preparation and zoning. We configure zones so that each initiator sees only its own target ports. Zone isolation eliminates the class of failures where one server's fault affects its neighbors.
- Volume and mapping configuration. We partition LUNs for the task, set the multipath policy, and verify that balancing goes across all paths, not just one. This is also where we configure the fault-tolerance parameters.
- SAN verification under load. We run a profile close to production: we look at latencies, path distribution, and behavior when one of them is disconnected. SAN verification is considered passed only when the system survives a path break without loss of access.
- Handover and documentation. We deliver the scheme, zone and volume configurations, and the diagnostics procedure. The customer's engineers must be able to distinguish path degradation from disk failure without our help.
Each stage ends with an artifact — a map, a scheme, a config, a load report. If at any step the result does not match the design, we go back and fix it rather than "pushing through" at the next one. Describe your task — we will come back with an estimate and a stage-by-stage plan.
How is SAN different from NAS and when should you choose which?
The key difference is at what level access is provided. NAS provides file access: the client sees a shared folder over a network protocol, while the file system lives on the storage device itself.
SAN provides block access: the server receives a logical volume as a local disk and decides for itself which file system to deploy on it and how. Everything else follows from this — a different cost of error, a different load profile, different scenarios.
File access is convenient where several nodes need to see the same data simultaneously: shared directories, home directories, backups, media storage. The upside is simplicity and built-in rights management.
The downside is protocol overhead and a single point through which all traffic flows; as the number of clients grows, it is the first to hit the ceiling.
Block access is chosen for databases, virtual machines, and clusters where predictable latency and high input/output operation speed matter. The volume looks like a local disk, so the application works without a network layer in file operations.
The flip side is consistency: if two nodes write to the same volume without a clustered file system, the data will be corrupted. This is an infrastructure-level task, and it is solved at the design stage, not "later."
The two options affect fault tolerance differently. In SAN, a path failure is compensated by multipath access: several physical routes to the array, and if one breaks, traffic moves over the backup without stopping the service.
In NAS, the failure of a storage node means the entire shared directory becomes unavailable, so replication and clustering of the device itself are critical here.
Choosing a storage network is not about "what is more modern," but about the load profile. A mixed approach also works: block volumes for databases and virtualization, file access for shared data and archives.
In practice, we first capture the input/output operation profile, and then propose a topology — otherwise it is easy to end up with an expensive solution that does not address the bottleneck.
Case study: how we eliminated downtime caused by SAN failures
The customer came with a classic picture: a two-node cluster, a disk array connected over Fibre Channel, but the path to the volumes was configured in a single leg — without redundancy.
Every few weeks, one of the switches would go down for maintenance or hit a port error, and both nodes simultaneously lost access to storage. The downtime lasted from 40 minutes to several hours: the service was down while an engineer manually switched the zoning. Over the quarter, there were seven such outages.
What it was before. One active path per volume, multipath was assembled formally, but the path selection policy was set to default and did not survive a failure.
Monitoring saw a node going down but did not distinguish between "the server went down" and "the volume disappeared" — the on-call engineer diagnosed the cause only after the fact.
Metrics: average recovery time after a SAN failure — 95 minutes, the share of failures that led to a complete service outage — 100%.
What we changed. We split the zoning across two independent switches, each node got two paths to the array, and we enabled multipathing with a policy that keeps both legs active and switches over when a link degrades.
The volumes were aligned to block boundaries to eliminate unnecessary read-write operations. Separately, we set up alerts for a path disappearing and for growth in volume response latency — now a failure is visible before the service starts to degrade.
What it became. The failure of a single switch or port no longer takes down the service: traffic moves over the second leg, the switchover takes seconds and requires no manual intervention.
Average recovery time dropped from 95 minutes to 4, and the class of failures "complete loss of access to storage" disappeared from the statistics over the observed period.
Predictability increased, among other things, because the on-call engineer now receives a signal about path degradation rather than about a service outage.
We honed the methodology of path redundancy and zone separation on projects with arrays from different vendors — the approach is the same, only the configuration syntax differs.
Multipath I/O combined with correct zoning closes exactly the class of failures that most often leads to downtime: not a disk failure, but the failure of a single access leg.
Compatibility, migration, and rollback concerns
SAN compatibility is the first question that comes up before work begins: the customer already has servers, switches, and an array, and no one wants to hear "everything will have to be replaced." In practice, the connection is built on top of the existing fabric: we check support for the target modes on the controllers, coordinate zoning by WWN, and align the block size and volume type with the workload.
If the array can present volumes over the required protocol and the switches support the required topology, no hardware replacement is needed.
What if some of the equipment is outdated? Then we offer two paths: leave it in a separate fabric segment for non-critical tasks, or decommission it from the perimeter in stages, without stopping production.
SAN migration goes through an intermediate node: volumes are connected to the new path, data is transferred on the live system, and the old path is disconnected only after integrity verification.
Rollback of changes is ensured at every step — the zone and masking configuration is saved as snapshots, and returning to the previous state takes minutes, not hours.
What about access? We delineate rights by role: fabric administrator, volume operator, auditor. All changes go through agreed windows, actions are logged, and SAN access is granted on a personal basis and revoked when a role changes.
Can migration be performed without stopping services?
Yes, if a second path to the data exists. Volumes are presented through the new target port, the multipath driver sees both paths, and traffic switches by priority. No downtime is required — the service continues running on the active path while the standby path synchronizes.
What the customer receives:
- a fabric diagram with zoning and volume masking;
- a mapping of volumes, LUNs, and workloads;
- role-based access policies and the procedure for granting them;
- a rollback procedure with configuration save points;
- SAN documentation: connection parameters, limits, growth points;
- an acceptance testing report after migration.
Describe your current perimeter — which arrays, switches, and servers are already in operation. We will come back with a compatibility assessment and a migration plan for your infrastructure.
SAN Configuration Timeline: Stages and Benchmarks
The SAN configuration timeline is determined not by the "power" of the equipment, but by how quickly zoning, masking, and access policies are agreed upon between existing systems.
In practice, the work schedule breaks down into stages of varying duration: auditing the current infrastructure and gathering workload requirements takes less time than migrating volumes and verifying path fault tolerance. Below are benchmarks that we refine after the initial task review.
| Stage | What Happens | Estimated Duration |
|---|---|---|
| Audit and requirements gathering | Inventory of hosts, volumes, current arrays; documenting performance and fault tolerance requirements | 2-5 days |
| Design | Fabric diagram, zoning plan, LUN masking, topology selection (single- or dual-fabric) | 3-7 days |
| Equipment preparation | Installation, cabling, basic configuration of switches and arrays, time synchronization | 3-10 days |
| Configuration and zoning | Zone configuration, binding volumes to hosts, multipath setup on servers | 5-14 days |
| Data migration | Volume transfer, integrity verification, test path failovers | 5-20 days |
| Acceptance and handover | Load testing, path failure drills, documentation, team training | 3-7 days |
The ranges are intentionally wide: a SAN deployment plan for two servers versus a virtualization cluster with dozens of hosts represents vastly different scopes of work.
The key factor is how many existing systems need to be migrated without service downtime: the more hosts migrated "hot," the longer the migration stage, but the lower the business impact.
We build the work schedule so that critical stages do not overlap with the customer's maintenance windows.
If part of the infrastructure is already running on the target array, the audit and design proceed in parallel with configuring new zones — this shortens the overall timeline.
We will provide precise benchmarks for your task after the audit: describe your current setup and requirements — we will come back with a plan and an estimate.