🧭Overview
High availability on IBM i is no longer optional. Geographic mirroring enables near-zero data loss and rapid recovery by replicating an independent ASP (iASP) to a remote node, ensuring operational continuity in the event of system or site failure.
Geographic mirroring can operate in synchronous or asynchronous mode.
Synchronous replication ensures both copies remain identical but is distance-sensitive, while asynchronous replication allows greater distance with minimal potential data loss.
Data changes are replicated at the disk page level by IBM i storage management to maintain consistency between nodes.
This guide explains how to create a PowerHA cluster with two nodes between mad2 and eu‑de‑1, and then how to add a third node in mad4.
Note: This procedure can be performed between IBM Cloud data centers, between on‑premises environments and IBM Cloud, or even between different (or the same) on‑premises locations, depending on the configuration you are implementing.
📋 Prerequisites
System & Software
This configuration was implemented using IBM i 7.5. Other supported IBM i releases can be used, provided the appropriate PowerHA version and recommended PTF levels are applied.
Install:
- IBM i Option 41 (HA Switchable Resources, 5770-SS1 opt 41)
- IBM PowerHA SystemMirror for i 5770-HAS *BASE
- PowerHA for i Enablement 5770-HAS opt 1
Ensure the PowerHA licensed program is installed and updated to the latest available PTF levels.
Install the latest QMGTOOLS build on all nodes. This is especially important for diagnostics and troubleshooting.
Download the latest build: https://public.dhe.ibm.com/services/us/igsc/has/
QMGTOOLS update instructions: https://www.ibm.com/support/pages/qmgtools-how-check-and-update-qmgtools
All nodes are updated to the latest PTFs available for:
- DB2
- HA/DR
- Cluster Services
- TCP/IP
Set network attributes to allow clustering: CHGNETA ALWADDCLU(*ANY)
Start the InetD server, which is required for cluster node communication and discovery: STRTCPSVR SERVER(*INETD)
To enable automatic startup: CHGTCPSVR SERVER(*INETD) AUTOSTART(*YES) or add to QSTRUP startup program.
Storage
- The required number of volumes (in this example, 10 × 50 GB) are attached to each LPAR but not yet configured in IBM i.
- Target disk capacity should match the source (≥95%) to prevent mirror suspension.
- Disk units intended for the targets iASP must be non‑configured and visible in WRKDSKSTS.
Networking
- Heartbeat and data ports must be reachable between nodes.
- Ensure no firewalls block:
- TCP 3972 (cluster services)
- TCP 5040 (geographic mirroring)
- Any custom ports used for monitoring
- DNS or host table entries are consistent across all nodes.
- Ensure sufficient network bandwidth and low latency between nodes, as geographic mirroring performance and resynchronization time depend directly on communication throughput.
Cluster Planning
Define and document:
- Node names and IP addresses
- Site names
- Planned CRG roles (PRIMARY / BACKUP)
Operational
- A maintenance window is available for steps requiring downtime (for example, CFGGEOMIR ACTION(*CREATE)).
- Administrative access (*SECOFR) is available on all nodes.
- Ensure no active jobs or locks exist on the iASP.
- Because geographic mirroring uses host resources, CPU and memory utilization should be evaluated to ensure adequate capacity under peak workloads.
🏗️Environment
|
LPAR
|
POWER Server
|
OS Version
|
IBM Cloud DC
|
Short Name
|
Preferred Role
|
|
IBMi75M2
|
S1122
|
V7R5
|
mad2
|
M2
|
PRIMARY
|
|
IBMi75M4
|
S1022
|
V7R5
|
mad4
|
M4
|
BACKUP
|
|
IBMi75F1
|
S1122
|
V7R5
|
eu-de-1
|
F1
|
BACKUP
|
|
Cluster
|
PHACLU
|
|
Device Domain
|
DEVDMN
|
|
Cluster Resource Group
|
PHACRG
|
|
Cluster Administrative Domain
|
PHACAD
|
|
iASP
|
IASP
|
|
Each IASP Volumes
|
10x 50GB
|
|
M2 <-> F1 Session
|
DRSSN (ASYNC)
|
|
M2 <-> M4 Session
|
HASSN (SYNC)
|
|
Cluster Message Queue
|
CLUMSGQ
|
|
Cluster Message Queue Library
|
POWERHA
|
IP Addresses:
|
LPAR
|
Heartbeat
|
Data Port 1
|
Data Port 2
|
|
IBMi75M2
|
172.27.2.2
|
172.27.2.3
|
172.27.2.4
|
|
IBMi75M4
|
172.27.4.2
|
172.27.4.3
|
172.27.4.4
|
|
IBMi75F1
|
172.27.11.2
|
172.27.11.3
|
172.27.11.4
|
①️ PART 1 - Creating a Two‑Node ASYNC Geographic Mirroring Setup
Is the IASP already created on IBMi75M2?
Yes → Go to step 4
No → Continue in step 1
- On IBMi75M2 do
CFGDEVASP ASPDEV(IASP) ACTION(*CREATE) <Enter>
- On the next screen "Select Non-Configured Disk Units" select the volumes for IASP, press <Enter> and wait for completion.
- IASP already exists on IBMi75M2.
- Create the cluster with:
CRTCLU CLUSTER(PHACLU) NODE((IBMI75M2 ('172.27.2.2')) (IBMI75F1 ('172.27.11.2'))) CLUMSGQ(POWERHA/CLUMSGQ) FLVWAITTIM(*NOMAX) FLVDFTACN(*CANCEL)
- Run:
WRKCLU OPTION(*NODE) - you should see both nodes "Active" and with Device Domain:
- Create Cluster Administrative Domain with:
CRTCAD ADMDMN(PHACAD)
- Check it with:
WRKCLU OPTION(*ADMDMN)
- Now let's add the Resources we want to monitor/replicate.
- First user profiles (we omitted the Q*) with:
ADDCADMRE RESOURCE(*ALL) RSCTYPE(*USRPRF) OMIT((Q*)), and on the next screen remove any profiles you do not want replicated with option 4, and confirm with F16
- Now the Authorization Lists with,
ADDCADMRE RESOURCE(*ALL) RSCTYPE(*AUTL) CONFIRM(*NO)
- In all ADDCADMRE if you do not want to confirm you can use parameter CONFIRM(*NO)
- Resource Types allowed to be monitored/replicated
|
*ASPDEV
|
*NWSHDEV
|
|
*AUTL
|
*NWSSTG
|
|
*CLS
|
*OPTDEV
|
|
*ENVVAR
|
*PRTDEV
|
|
*ETHLIN
|
*SBSD
|
|
*JOBD
|
*SYSVAL
|
|
*NETA
|
*TAPDEV
|
|
*NWSCFG
|
*TCPA
|
|
*NWSD
|
*USRPRF
|
- Some resources like printers you have to add one by one i.e
ADDCADMRE RESOURCE(PRTRQM) RSCTYPE(*PRTDEV) CONFIRM(*NO)
- Create Cluster Resource Group with IASP with:
CRTCRG CRG(PHACRG) CRGTYPE(*DEV) RCYDMN((IBMI75M2 *PRIMARY *LAST MAD ('172.27.2.3' '172.27.2.4')) (IBMI75F1 *CRGTYPE *LAST FRA ('172.27.11.3' '172.27.11.4'))) CFGOBJ((IASP *DEVD *ONLINE))
WRKCLU OPTION(*CRG)
- On the screen from step 17 doing option 6 for the PHACRG entry:
- On the screen from step 17 doing option 7 for the PHACRG entry:
- Now let's configure the Geographic Mirroring for iASP IASP. This next step requires downtime.
- Make sure IASP is "VARIED OFF" use CL command WRKCFGSTS *DEV IASP
CFGGEOMIR ASPDEV(IASP) ACTION(*CREATE) DELIVERY(*ASYNC) COMPRESS(*RESYNC) SSN(DRSSN) This step creates the IASP in IBMi75F1. Wait for it to end.
- After step 24 completion you should have:
- IASP in status "AVAILABLE"
- CRG as "Active"
WRKASPCPYD you should see DRSSN session.
- Let's resume the session DRSSN with,
CHGASPSSN SSN(DRSSN) OPTION(*RESUME) ASPDEV(IASP)
- Did you receive message ID HAD008E - "Geographic mirroring not configured on node IBMI75F1." ?
- Yes → Continue with step 31
- No → Go to step 35
- End the CRG with:
ENDCRG CRG(PHACRG)
- Then vary off the IASP with:
VRYCFG CFGOBJ(IASP) CFGTYPE(*DEV) STATUS(*OFF) ASCVRYOFF(*YES)
- Then vary on the IASP with:
VRYCFG CFGOBJ(IASP) CFGTYPE(*DEV) STATUS(*ON)
- Now it should work with:
CHGASPSSN SSN(DRSSN) OPTION(*RESUME) ASPDEV(IASP)
- Confirm with:
DSPASPSSN DRSSN
- End of PART 1 - Two‑Node ASYNC Geographic Mirroring
②️ PART 2 - Adding a Third Node to the Cluster
- Add the new node:
ADDCLUNODE NODE(IBMI75M4 ('172.27.4.2')) START(*YES) DEVDMN(*CURRENT) ADMDMN(*CURRENT)
WRKCLU OPTION(*NODE)
WRKCLU OPTION(*ADMDMN) → Option 12
- End the CRG:
ENDCRG CRG(PHACRG)
- Add the new node to the CRG:
ADDCRGNODE CRG(PHACRG) RCYDMN(IBMI75M4 *CRGTYPE *LAST MAD ('172.27.4.3' '172.27.4.4'))
- Now let's configure the Geographic Mirroring for iASP IASP on the new node. This next step DOES NOT requires downtime.
CFGGEOMIR ASPDEV(IASP) ACTION(*CREATE) COMPRESS(*RESYNC) TGTNODE(IBMI75M4) SSN(HASSN)
WRKCLU OPTION(*ASPCPYD)
DSPASPSSN SSN(HASSN)
- Press F11
- Review and update the PowerHA policies to match your specific configuration. A reference link is included in the References section.
- End of PART 2 - Adding a Third Node to the Cluster
- Test a planned role swap
💡Note
In this example, the session name DRSSN was used in Part 1, and HASSN was used when adding the third node.
PowerHA replaced the DRSSN session name with HASSN.
This behavior has been reported to IBM, and a note has been added to the following document:
https://fortradocs.atlassian.net/wiki/spaces/IWT/pages/2464448523/Configuring+Multi-Target+Geographic+Mirroring+7.5
💡 Best Practices
Cluster & CRG Design
- Use meaningful site names (e.g. MAD2, MAD4, FRA1).
- Avoid unnecessary site changes after running CFGGEOMIR ACTION(CREATE) or after you have added the ASP copy descriptions. At the time of this writing, some PowerHA components do not automatically update dependent objects, specifically the ASP copy description. If you need to change the node’s site name, you must first end the ASP session, remove the respective ASP copy description, and then create a new ASP copy description.
- Always verify CRG status with
WRKCLU OPTION(*CRG) after any change.
- Review and update the PowerHA policies to match your specific configuration.
- Regular role swap testing is essential to validate application startup procedures and ensure replication resumes correctly after planned or unplanned failovers.
IASP & Mirroring
- Keep IASP names short and descriptive (e.g., IASP, DATAIASP).
- For multi-target setups, define clear naming conventions for sessions and ASP copies.
- After creating or modifying a session, always confirm with DSPASPSSN and WRKASPCPYD
Networking
- Use dedicated VLANs for heartbeat and data ports whenever possible.
- Ensure latency between ASYNC nodes is acceptable; SYNC nodes require very low latency (<5ms RTT).
- Avoid routing heartbeat traffic over VPNs or unstable links.
- You should use explicit host routes to keep replication and heartbeat traffic deterministic. This avoids asymmetric routing, ensures the correct source IP/interface is used, and gives you predictable failover between redundant paths.
Below is the full working example for my environment. Replace my IPs/gateways with yours.
Verify after applying:
-
- NETSTAT OPTION(*RTE)
- PING between each node interface
- Ensure the preferred path is used first (backup path kicks in if the primary fails). The following command traces the first hop only, allowing you to verify which path is being used:
TRACEROUTE RMTSYS('172.27.4.3') RANGE(1 1) PROBES(1) WAITTIME(1) OUTPUT(* VERBOSE) NAMELOOKUP(*NO)
You should see the packet leaving through the preferred gateway/interface:
Probing possible routes to 172.27.4.3 using *ANY interface.
36 BYTES FROM 172.27.2.1 TO 172.27.2.3: ICMP TIME EXCEEDED (TYPE 11 CODE 0).
Full example route table:
Node: IBMI75M2 (subnets 172.27.2.0/26 and 172.27.4.0/26)
/* --- Reach IBMI75M4 (172.27.4.x) via 172.27.2.x --- */
ADDTCPRTE RTEDEST('172.27.4.3') SUBNETMASK(*HOST) NEXTHOP('172.27.2.1') BINDIFC('172.27.2.4')
ADDTCPRTE RTEDEST('172.27.4.3') SUBNETMASK(*HOST) NEXTHOP('172.27.2.1') BINDIFC('172.27.2.3') DUPRTEPTY(*HIGH)
ADDTCPRTE RTEDEST('172.27.4.4') SUBNETMASK(*HOST) NEXTHOP('172.27.2.1') BINDIFC('172.27.2.3')
ADDTCPRTE RTEDEST('172.27.4.4') SUBNETMASK(*HOST) NEXTHOP('172.27.2.1') BINDIFC('172.27.2.4') DUPRTEPTY(*HIGH)
ADDTCPRTE RTEDEST('172.27.4.2') SUBNETMASK(*HOST) NEXTHOP('172.27.2.1') BINDIFC('172.27.2.2') DUPRTEPTY(*HIGH)
/* --- Reach IBMI75F1 (172.27.11.x) via 172.27.2.x --- */
ADDTCPRTE RTEDEST('172.27.11.3') SUBNETMASK(*HOST) NEXTHOP('172.27.2.1') BINDIFC('172.27.2.4')
ADDTCPRTE RTEDEST('172.27.11.3') SUBNETMASK(*HOST) NEXTHOP('172.27.2.1') BINDIFC('172.27.2.3') DUPRTEPTY(*HIGH)
ADDTCPRTE RTEDEST('172.27.11.4') SUBNETMASK(*HOST) NEXTHOP('172.27.2.1') BINDIFC('172.27.2.3')
ADDTCPRTE RTEDEST('172.27.11.4') SUBNETMASK(*HOST) NEXTHOP('172.27.2.1') BINDIFC('172.27.2.4') DUPRTEPTY(*HIGH)
ADDTCPRTE RTEDEST('172.27.11.2') SUBNETMASK(*HOST) NEXTHOP('172.27.2.1') BINDIFC('172.27.2.2') DUPRTEPTY(*HIGH)
Node: IBMI75M4 (subnets 172.27.4.0/26 and 172.27.2.0/26)
/* --- Reach IBMI75M2 (172.27.2.x) via 172.27.4.x --- */
ADDTCPRTE RTEDEST('172.27.2.3') SUBNETMASK(*HOST) NEXTHOP('172.27.4.1') BINDIFC('172.27.4.4')
ADDTCPRTE RTEDEST('172.27.2.3') SUBNETMASK(*HOST) NEXTHOP('172.27.4.1') BINDIFC('172.27.4.3') DUPRTEPTY(*HIGH)
ADDTCPRTE RTEDEST('172.27.2.4') SUBNETMASK(*HOST) NEXTHOP('172.27.4.1') BINDIFC('172.27.4.3')
ADDTCPRTE RTEDEST('172.27.2.4') SUBNETMASK(*HOST) NEXTHOP('172.27.4.1') BINDIFC('172.27.4.4') DUPRTEPTY(*HIGH)
ADDTCPRTE RTEDEST('172.27.2.2') SUBNETMASK(*HOST) NEXTHOP('172.27.4.1') BINDIFC('172.27.4.2') DUPRTEPTY(*HIGH)
/* --- Reach IBMI75F1 (172.27.11.x) via 172.27.4.x --- */
ADDTCPRTE RTEDEST('172.27.11.3') SUBNETMASK(*HOST) NEXTHOP('172.27.4.1') BINDIFC('172.27.4.4')
ADDTCPRTE RTEDEST('172.27.11.3') SUBNETMASK(*HOST) NEXTHOP('172.27.4.1') BINDIFC('172.27.4.3') DUPRTEPTY(*HIGH)
ADDTCPRTE RTEDEST('172.27.11.4') SUBNETMASK(*HOST) NEXTHOP('172.27.4.1') BINDIFC('172.27.4.3')
ADDTCPRTE RTEDEST('172.27.11.4') SUBNETMASK(*HOST) NEXTHOP('172.27.4.1') BINDIFC('172.27.4.4') DUPRTEPTY(*HIGH)
ADDTCPRTE RTEDEST('172.27.11.2') SUBNETMASK(*HOST) NEXTHOP('172.27.4.1') BINDIFC('172.27.4.2') DUPRTEPTY(*HIGH)
Node: IBMI75F1 (subnet 172.27.11.0/26)
/* --- Reach IBMI75M4 (172.27.4.x) via 172.27.11.x --- */
ADDTCPRTE RTEDEST('172.27.4.3') SUBNETMASK(*HOST) NEXTHOP('172.27.11.1') BINDIFC('172.27.11.4')
ADDTCPRTE RTEDEST('172.27.4.3') SUBNETMASK(*HOST) NEXTHOP('172.27.11.1') BINDIFC('172.27.11.3') DUPRTEPTY(*HIGH)
ADDTCPRTE RTEDEST('172.27.4.4') SUBNETMASK(*HOST) NEXTHOP('172.27.11.1') BINDIFC('172.27.11.3')
ADDTCPRTE RTEDEST('172.27.4.4') SUBNETMASK(*HOST) NEXTHOP('172.27.11.1') BINDIFC('172.27.11.4') DUPRTEPTY(*HIGH)
ADDTCPRTE RTEDEST('172.27.4.2') SUBNETMASK(*HOST) NEXTHOP('172.27.11.1') BINDIFC('172.27.11.2') DUPRTEPTY(*HIGH)
/* --- Reach IBMI75M2 (172.27.2.x) via 172.27.11.x --- */
ADDTCPRTE RTEDEST('172.27.2.3') SUBNETMASK(*HOST) NEXTHOP('172.27.11.1') BINDIFC('172.27.11.4')
ADDTCPRTE RTEDEST('172.27.2.3') SUBNETMASK(*HOST) NEXTHOP('172.27.11.1') BINDIFC('172.27.11.3') DUPRTEPTY(*HIGH)
ADDTCPRTE RTEDEST('172.27.2.4') SUBNETMASK(*HOST) NEXTHOP('172.27.11.1') BINDIFC('172.27.11.3')
ADDTCPRTE RTEDEST('172.27.2.4') SUBNETMASK(*HOST) NEXTHOP('172.27.11.1') BINDIFC('172.27.11.4') DUPRTEPTY(*HIGH)
ADDTCPRTE RTEDEST('172.27.2.2') SUBNETMASK(*HOST) NEXTHOP('172.27.11.1') BINDIFC('172.27.11.2') DUPRTEPTY(*HIGH)
Operational Safety
- On a two node cluster, before running CFGGEOMIR ACTION(*CREATE), always:
- Vary off the IASP
- Confirm no locks exist
- Ensure CRG is ended if required
- After any failover or role switch, validate:
- IASP status
- CRG role
- Session direction
- Cluster node health
Monitoring & Maintenance
- Regularly run:
- DSPCLUINF
- DSPASPSSN
- WRKCLU (nodes, CRGs, domains)
- Automate QMGTOOLS collections for HA environments.
- Document every change to cluster configuration - especially site changes.
🛠️ Troubleshooting Tips
- If a session refuses to resume, check for:
- Incorrect site definitions
- CRG not ended
- IASP not varied off/on
- Missing or stale cluster metadata
- When in doubt, collect:
SYSSNAP LICLOGS(Y) COLHA(Y) COLDB2M(Y) and open a case with IBM.
📚 References
PowerHA Policies - IBM Partnership -
PowerHA: Steps to Configure Geographic Mirroring Between Two Nodes
PowerHA SQL Services - IBM Partnership -
IBM PowerHA SystemMirror for i: Using Geographic Mirrioring
Adding an ASP copy description - IBM Documentation
PowerHA SystemMirror for i - IBM Partnership -
Configuring Geographic Mirroring Between Two Systems (7.5) - IBM Partnership -
Configuring Multi-Target Geographic Mirroring (7.5) - IBM Partnership -
Geographic mirroring - IBM Documentation
PowerHA SystemMirror for i overview - IBM Documentation