143-130 · Question #27
In an effort to maintain a FICON high availability (HA) architecture, you have separated local production traffic and data being sent to the remote data center. Local production traffic is isolated…
The correct answer is A. The merging of the production fabric across the WAN exposes it to faults. See the full explanation below for the reasoning.
Question
In an effort to maintain a FICON high availability (HA) architecture, you have separated local production traffic and data being sent to the remote data center. Local production traffic is isolated to its own logical fabric. The data to be transported across the WAN is isolated into a different logical fabric. What is the reason for isolating these environments?
Options
- AThe merging of the production fabric across the WAN exposes it to faults.
- BThe remote traffic will negatively affect local production traffic.
- CThe production fabric is too large to connect across the WAN.
- DThe FICON logical switch for the remote traffic never has the same fabric settings as the local
How the community answered
(29 responses)- A79% (23)
- B10% (3)
- C7% (2)
- D3% (1)
Community Discussion
7A is the right answer here. When you merge your local FICON production fabric directly across the WAN, you are exposing your mission-critical local environment to any instability or disruption that occurs on the WAN link or at the remote site. A fabric merge means both sides share the same domain, and a fault event like a link bounce or RSCNs triggered on the remote side can propagate back into your local production fabric and cause disruption to your local HBAs and storage. Keeping them in separate logical fabrics gives you a fault boundary, so a problem on the WAN side stays on the WAN side. B is a tempting wrong answer because it sounds like it is describing a real performance concern, but that is not the primary reason for the isolation in a FICON HA design. The actual risk is fault propagation, not bandwidth contention. D is just not accurate for how logical switches work in a properly configured FICON environment.
Bao covered the fault-boundary piece well, and I would just add that the RSCN storm risk is especially nasty in FICON because channel programs are far less tolerant of fabric events than open-systems HBAs, so even a brief disruption that an FCP host might retry through can cause a FICON channel to abend.
I almost went with B because our senior network guy always talks about bandwidth contention, but he actually walked me through this exact scenario last week and the key word in B is "negatively affect" which sounds like a performance issue, not a fault isolation issue. The whole point of splitting into logical fabrics is that if the WAN link drops or has a fabric event, that instability stays contained and never touches your local production environment, which is exactly what A is describing. So A is the right pick.
Yusuf nailed the fault isolation angle, and here is a sticky way to lock it in for exam day: picture two fishbowls side by side, one WAN bowl and one LAN bowl, a crack in the WAN bowl never drains your LAN bowl, that is exactly what separate logical fabrics give you.
The IBM Redbook on FICON high availability is pretty clear that extending a production fabric across a WAN introduces a single point of failure at the inter-site link, which is exactly the exposure the isolation is designed to prevent. My question for you: do you understand why a fault in the WAN segment would propagate into the local production fabric if they shared the same logical fabric, and can you point to where in the fabric architecture that fault injection actually occurs?
Yes, and the sticky way to remember WHERE the fault actually injects is to picture the principal switch election as the "kingpin" of the whole logical fabric, because the moment that WAN ISL flaps and triggers a Build Fabric event, every N_Port in the shared domain gets flooded with RSCNs, which means your perfectly healthy local hosts are suddenly scrambling to re-register paths they never lost.
A is dead on, and here is the sticky way to remember it: think "WAN Wounds," because stretching your local FICON fabric across the WAN is like leaving a door open to every fault, delay, and disruption that lives on that remote link. Keep them separate, keep production clean.