A switch can die and your storage keeps serving
Your VM's disk lives on a dedicated array, reached over two storage networks that share nothing. Both are live at all times, so a dead switch, a pulled cable, or a whole network taken out for service is a non-event for the workload.
In this article 4 sections
- Every host on our SAN reaches its storage over two completely independent Fibre Channel fabrics, with separate switches, running active/active.
- A switch, a cable, or a port can fail and your LUN keeps serving on the other path. Both paths carry production I/O all the time, so there is no standby to wake up and no cutover to survive.
- RAID inside a single server covers one failure, a dead drive. Everything else in that box takes your storage down with it.
- The design lets a whole fabric be taken out of service with every virtual machine still running on the other.
The disk your workload writes to does not live inside the server running it. It lives on a storage array a network away, and that network can fail like anything else: switches die, cables get pulled, ports start flapping. What decides whether your workload ever notices is whether there is a second road to the disk, and whether that second road is genuinely separate from the first.
Multipath gives every host two live roads to its LUN
A LUN is the block device your virtual machine sees as its disk. On a SAN, that disk lives outside the server running your workload, on a dedicated, dual-controller all-flash array, and the server reaches it over a storage network. Multipath means the server holds more than one physical route to the same LUN at the same time, through different ports, different cables, and different switches.
Active/active means both routes carry traffic every second of the day. A standby path that only wakes up during a failure is a path you have never really tested, and the failure is the worst possible moment to run its first test. When both paths carry live I/O continuously, losing one just leaves the other doing all of the work it was already doing half of. The workload sees nothing, because from where it sits, nothing happened.
Two HBA ports on the host
Two cables, on two separate runs
Two switches, one per fabric
Two Fibre Channel fabrics, both active/active
The two fabrics share no switch, so a fault cannot cross between them
Two paths through the same switch is one path wearing two labels. Whatever kills the switch kills both. Real independence means the two fabrics are built as two separate networks with separate switches, and nothing in the data path between host and array appears in both. A fault in one fabric, whether a dead switch, a flapping port, or a congested link, has nowhere to spread. The second fabric does not hear about it.
A Fibre Channel fabric is the switched network between servers and storage arrays, the storage equivalent of your LAN. Running two of them, fully separate, means your storage traffic always has a second network to live on. The expensive failures in storage networking are rarely clean deaths; they are links that stay up but stall, and independence is what keeps that kind of sickness contained to one side.
RAID inside one server dies with the server
RAID on a controller card inside your server protects you from exactly one thing, a dead drive, and it is good at that. But the drives, the RAID card, the backplane, the power supplies, and the motherboard all live in the same box, and the box is the failure domain. When anything else in it dies, your storage is gone with it, and it comes back when the server does. If the RAID card itself fails, the healthiest drives in the world are unreachable.
A SAN moves the disk out of the failure domain of the machine using it. Your server can die and the LUN it was writing to a second earlier is still there, intact and serving, ready for the workload to come back up on another host. The dual-fabric design extends the same idea to the road between them: the path to your storage is allowed to fail too, so we built two.
| What fails | What your workloads see |
|---|---|
| A cable or a port | The LUN keeps serving on the other path. No cutover, no restart. |
| A whole switch | The second fabric carries everything. Nothing wakes up or switches over. |
| An entire fabric, taken out for service | Every host keeps a good path on the healthy fabric while the work happens. |
| A storage controller node | The second controller keeps serving while the hardware is swapped. |
| The server itself | The LUN survives it. The workload restarts on another host and finds its disk where it left it. |
Taking a whole fabric out of service under live workloads
When a fabric needs service, the procedure is unglamorous: confirm every host holds a good path on the other fabric, take the fabric out of service, do the work, then reintroduce it deliberately. Virtual machines run on one fabric while the work happens and see nothing. That is the correct amount of drama for storage maintenance.
The same posture holds on the array side. The arrays are dual-controller: a controller can be serviced while the other keeps serving. Hardware is serviced on our SAN the way it should be everywhere: while the thing it belongs to keeps doing its job.
Straight answers
Is active/active just a nicer word for failover?+
No. A failover design keeps a second path idle until the first one dies, then attempts a cutover under the worst conditions of the day. Active/active means both fabrics carry production I/O all the time, so a failure removes one working path while the other working path continues. There is no cutover event to survive and no standby getting its first test during your incident.
My server has RAID-10. Is that the same protection?+
RAID inside the server protects your data from a dead drive, and only from that. The RAID card, the backplane, the power supplies, and the server itself remain single points of failure, and your storage shares their fate. On a SAN the storage survives the death of the server using it, and with dual fabrics it also survives the death of the road in between.
What if the whole array fails, or the whole site?+
Different failure class, different tools. This post covers the paths between a healthy host and a healthy array, which is where the everyday failures live. Surviving the loss of an array or a site is a recovery conversation, and we wrote it up separately: how much data loss and downtime your business can honestly tolerate.
How do I know both paths are actually working before one fails?+
Because both fabrics carry live I/O continuously, a dead path is not a silent condition: the moment one side stops moving traffic, it surfaces in monitoring. And every maintenance starts the same way, by confirming each host holds a good path on the surviving fabric before anything is taken out of service.
Ask an engineer what your storage actually sits on
The people who design and run the fabrics are the same people who answer. Bring your current setup and we will tell you plainly what survives what.
Talk to an engineerDead switches, pulled cables and controller service are the failures this design retires. Losing an entire array or an entire site is a different class of failure, and that one starts at the recovery conversation. If you are evaluating hosts, the storage questions worth asking anyone, including us, are in your host's dirty secret is their storage.
You’ve reached the end.
Put the reading to work
What are
you running?
Tell us about the workload, traffic and recovery requirements. Start with the server builder, or talk through the details with an engineer.
Written by the engineers who build and run the infrastructure it describes.Talk to an engineer