FC Zoning and Multipathing on an All-Flash Array
A bank has deployed an OceanStor Dorado all-flash array for a new core banking system. Six Oracle Linux database servers connect through two Fibre Channel switches in separate fabrics. Each server has two 32 Gb HBAs, one per fabric, and each controller has four 32 Gb front-end ports. The integrator created one zone per fabric containing all six host HBA ports and all eight array ports. After the hosts were rescanned, each server sees eight paths. UltraPath reports four paths as active and four as standby. During a planned controller reboot, one database server lost I/O for 45 seconds and the cluster failed over. The bank requires no single point of failure and a path failover under 10 seconds. The change window is next weekend.
1. Identify the zoning and path-count problems in the current design. What is the correct SAN zoning model for this configuration?
Read the worked answer
The current design is not valid SAN zoning. A zone containing six host HBAs and eight array ports is a many-initiator, many-target zone. Every host registers every array port, so RSCN and fabric events affect all hosts, queue depths are spread over too many paths, and a controller reboot can trigger a storm of login state changes. Correct practice is single-initiator, single-target zoning, or single-initiator with a deliberately limited number of targets:
- Keep Fabric A and Fabric B separate; each server HBA logs into only its own fabric.
- In Fabric A, create one zone per HBA containing that HBA and one front-end port on each controller, giving two targets. Repeat for Fabric B.
- With two HBAs per server, the result is four paths per server: two active/optimized to the owning controller and two standby/non-optimized to the peer.
This gives a predictable path count, isolates RSCN, and keeps each HBA queue depth focused. Also verify LUN masking so each host sees only its own LUNs.
2. Explain why UltraPath shows four active and four standby paths, and why the 45-second outage occurred despite multipathing.
Read the worked answer
UltraPath reports four active and four standby because the array uses ALUA. A LUN is owned by one controller; paths through the owning controller are active/optimized, while paths through the peer are standby/non-optimized. With the current oversized zone, each host sees eight paths, so four are optimized and four are not.
The 45-second outage is not explained by ALUA alone; failover should use the standby paths. Likely contributors are: the all-in-one zone caused RSCN and path flapping and delayed path state updates; the host multipath timers or UltraPath version were not tuned; queue depth was exhausted on the surviving paths; or the cluster I/O timeout was longer than the path failover time. Check UltraPath path state, host HBA logs, array event logs, and whether all standby paths were actually logged in. A 45-second pause suggests the host waited for a SCSI timeout rather than completing a clean failover.
3. What validation steps would you perform before the change window to prove the 10-second failover target?
Read the worked answer
Before the change window: capture baseline path states and latency; verify each HBA has exactly two target ports per fabric; confirm LUN masking and ALUA ownership; check UltraPath and HBA firmware compatibility; set host timeout and queue-depth values per Huawei best practice; and test one non-critical host by rebooting one controller while monitoring I/O. Measure the pause and confirm it is under 10 seconds. Then repeat for the other controller and the other fabric. Prepare a rollback zone set and a communication plan. Do not reboot both controllers or change both fabrics simultaneously.