Figure - Cover: Power11 + IBM i Policy-Based HA Campus Cluster.
If you run an IBM i logistics or distribution platform 24/7, downtime isn't just an SLA discussion - it's a transactional bleed and a customer-experience hit that doesn't recover linearly. This thread is a structured walk-through of an Enterprise Power11 + IBM i Campus Cluster we delivered to a mid-size Italian distribution customer in 7 weeks, with RPO=0 across the campus, RTO measured in minutes, and a Safeguarded Copy logical air-gap protecting the IBM i database against ransomware.
I'm sharing this because the pattern - Power11 + FlashSystem 5300 with FCM4 + Policy-Based HA + Safeguarded Copy + PowerHA SystemMirror for i EE - is becoming a reference blueprint for IBM i mid-market in Italy, and I want to compare notes with the community on the parts that worked and the parts where we'd refine the approach next time.
Reference architecture in one line: two Power11 frames (8 cores, 128 GB RAM each), two FS5300 with FCM4, four SAN24B-6 32 Gbps switches, dual VIOS / NPIV, IASP-level failover, immutable Safeguarded Copy + FlashCopy service partition for zero-impact backups.
On a 24/7 logistics platform supporting web portals and a sales network, the failure mode that hurts most isn't data loss - synchronous replication has effectively solved that. The failure mode that hurts most is the time between the failure and the moment transactions resume.
- On the legacy Power10 + logical replication + internal disks setup, an IPL on failover was the bottleneck. Even a 10-minute RTO is too long when web sales are flowing through the platform.
- Customer audit teams in 2026 are now asking for documented RTO numbers, not just SLAs. NIS2 and customer contracts have shifted the conversation.
- Hardware refresh from Power10 was due, so the question wasn't "do we modernise" - it was "if we modernise, do we redesign HA properly or repeat the past?".
The answer that fit the 7-week delivery window - and that we'd recommend again - is IASP-level failover orchestrated by PowerHA SystemMirror for i EE on top of synchronous Policy-Based HA between two FS5300 arrays. No full IPL on failover, RPO=0 within the campus, and a clean cyber-vault sitting underneath.
Figure 1 - RPO and RTO budget across the campus: synchronous PB-HA gives RPO=0 between Sala A and Sala B; IASP-level failover keeps RTO in the minute range.
The Campus Cluster spans two computer rooms in the same site (Sala A primary, Sala B secondary). Each side runs:
- One IBM Power11 frame, 8 physical cores, 128 GB RAM
- One IBM FlashSystem 5300 with FlashCore Module 4 (FCM4), inline hardware compression and AES-256 encryption
- Two IBM SAN24B-6 switches at 32 Gbps, dual-fabric A/B, eight FC ports per server (four per fabric, mirrored across nodes)
- Dual VIOS per frame with SEA failover / LACP on the network side and NPIV on the SAN side, so IBM i LPARs see LUNs and tape directly
Node A in Sala A is the IBM Production node. Node B in Sala B is the CBU/Test node - fully participating in the failover topology while also serving Test workloads under IBM's Capacity BackUp licensing rules. That's a meaningful licence optimisation that's worth designing in from day 1, not bolting on at the end.
Figure 2 - Campus Cluster architecture: Power11 + FS5300 in Sala A and Sala B, dual-fabric 32 Gbps SAN, synchronous Policy-Based HA, Safeguarded Copy and FlashCopy service partition.
The cluster combines two layers that handle different problems:
- Policy-Based HA on the FS5300 pair handles synchronous storage replication between Sala A and Sala B. Consistency Groups align the DB2 database and its transaction logs so that the secondary array always has a transactionally consistent image. RPO=0 across the campus.
- PowerHA SystemMirror for i EE handles the IBM i cluster on top - orchestrating IASP failover, role swap and resource group movement. Crucially, IASP-level failover removes the need for a full IPL when the production role swings to Node B.
In practical terms: an unplanned outage in Sala A doesn't trigger a 10-minute IPL - it triggers an IASP role swap and applications resume in the minute range. That's the single most important operational change versus the legacy Power10 setup.
A note on testing: PowerHA EE failover testing should be scheduled and rehearsed quarterly. We did the first three tests during Hypercare; the customer's IT team now owns the playbook and runs them autonomously.
4. Safeguarded Copy - the immutable cyber-vault layer
Synchronous replication is great against hardware failure but useless against ransomware: corrupted blocks replicate to the secondary in microseconds. The cyber-vault layer is what makes this architecture cyber-resilient.
- Safeguarded Copy creates immutable snapshots in a protected domain on the FS5300. The snapshots cannot be deleted or modified - not even by storage administrators. That's a logical air-gap, the right control surface against modern ransomware.
- The FlashCopy service partition is configured for zero-impact daily IASP backups via BRMS. Backups happen against the snapshot, never against production volumes - no I/O contention, no production slowdown.
- Recovery flow is rehearsed: pick a clean snapshot, mount it through FlashCopy, validate consistency, promote it. We measured minute-to-second recovery in the rehearsal we did with the customer's audit team observing.
The combination of Safeguarded Copy + FlashCopy service partition + BRMS gives the customer two practical capabilities the legacy estate didn't have: documented immutability for audit, and a non-destructive way to test recovery without taking production down.
5. Migration strategy - Side-by-Side, with the legacy Power10 as rollback
On a 24/7 logistics platform, the migration cutover is the riskiest moment of the whole project. We chose a Side-by-Side approach for one reason: the legacy Power10 environment stays intact throughout the migration, and a simple power-on is the rollback path.
- Phase 1 - Pilot on Node B. Test LPAR provisioning, end-to-end backup/restore validation, PowerHA EE installation.
- Phase 2 - Production cut-over weekend. Service stop, GO SAVE 21, LIC/OS install on Power11, data restore, license key update, smoke test.
- Phase 3 - IASP transformation + PowerHA activation. Library to IASP transformation, Metro Mirror / Policy-Based HA enablement on the FS5300 pair, failover testing.
- Phase 4 - Safeguarded Copy + FlashCopy service partition activation.
- Phase 5 - Hypercare, run-book handover, audit documentation.
The whole sequence took 7 weeks. The legacy Power10 was de-commissioned only after 4 weeks of stable production on Power11 and a successful failover test in Sala B.
Figure 3 - Side-by-Side migration timeline: legacy Power10 kept as rollback, 5 phases over 7 weeks, decommissioning only after stable production + failover test.
If you're sizing a similar architecture in 2026:
- Design IASP-level failover from day 1. Re-platforming an IBM i estate without IASPs into a PowerHA EE cluster later is painful - bake it into the cut-over plan, not the post-go-live wishlist.
- Treat Safeguarded Copy as a security control, not a backup feature. Wire its snapshot policies and access reviews into the customer's governance, not into the storage team's quiet corner.
- Side-by-Side migration on Power11 is sober and operationally reassuring on 24/7 estates. Compressing the timeline by killing the legacy environment early is a bad trade - keep the rollback for at least 3-4 weeks of stable production.
Discussion prompts
I'd like to compare notes with the IBM i community on three open questions:
- How are you sizing the FlashCopy service partition for zero-impact IASP backups in a 24/7 estate? Percentage of capacity, fixed reserve, or per-LPAR?
- For PowerHA EE failover testing - quarterly rehearsals, scripted automation or fully manual? What's worked best for keeping the customer team confident over time?
- nyone else combining Policy-Based HA with Safeguarded Copy on FS5300/7300/9500 for IBM i workloads? I'm interested in stories where the cyber-vault recovery had to be exercised for real, not as a drill.
Happy to discuss the parts that didn't go perfectly the first time - and to be challenged on any of these views. The earlier we standardise this pattern across the IBM i partner ecosystem in Europe, the better off our customers will be.
Roberto Renna · CEO & Lead Solutions Architect · YoctoIT (IBM Platinum Partner)
#IBMi #IBMPower #Power11 #PowerHA #PolicyBasedHA #IBMFlashSystem #FCM4 #SafeguardedCopy #IASP #IBMChampions
------------------------------
Roberto Renna
------------------------------