Learn how to upgrade or update the operating system in a PowerHA environment.

In this scenario:

NODEA is the Primary cluster node with the production copy of the IASP.
NODEB is the Backup cluster node, with the mirror copy of the IASP.
Replication is occurring in the direction from NODEA to NODEB.

This example includes instructions for upgrading the operating system in any PowerHA environment including Metro Mirror, Global Mirror, and Geographic Mirroring.

Procedure

Part 1 - Upgrading the Backup Cluster Node

Begin with the environment pictured above.
Detach replication by using the *DETACH option on the Change Session Command. See the appropriate procedure depending on the type of replication:

To detach SVC/Storwize Metro Mirror or Global Mirror Sessions, use the CHGSVCSSN command. For example: CHGSVCSSN SSN(MYGMIRSSN) OPTION(*DETACH)

To detach DS8000 CSM Metro Mirror or Global Mirror Sessions, use the CHGCSMSSN command. For example: CHGCSMSSN SSN(MYGMIRSSN) OPTION(*DETACH)

To detach DS8000 ASP Metro Mirror or Global Mirror Sessions, use the CHGASPSSN command. For example: CHGASPSSN SSN(MYGMIRSSN) OPTION(*DETACH)

To detach Geographic Mirroring Sessions, use the CHGASPSSN command. For example: CHGASPSSN SSN(GEOMIRSSN) OPTION(*DETACH)

With Geographic Mirroring, when upgrading to a new IBM i release, these instructions will cause a full re-synchronization of data to occur as part of a reattach of the Geographic Mirrored IASP in the instructions below.

Data transfer times for geographic mirroring are dependent upon several factors including the amount of used storage on the IASP and connection between systems. Transfer times may be reduced by enabling Geographic Mirroring compression and increasing the geographic mirroring synchronization priority.

If the status of the CRG is anything other than Inactive, end the cluster resource group with the ENDCRG command. In this scenario, the command is: ENDCRG CRG(MYCRG)
End clustering on the Backup Node. This is NODEB in the example by using the ENDCLUNOD command. In this scenario, the command is: ENDCLUNOD NODE(NODEB)
Upgrade NODEB to the new software level. This new level could be for program temporary fixes (PTFs) or to a new release. If upgrading to a new release see Upgrading or replacing IBM i and related software for details.
Vary on the IASP on NODEB. Testing the applications ensures that they operate as expected within the new update. After application tests are completed, you can finish the upgrade by completing the rest of these steps.

If using Geographic Mirroring, when upgrading to a new IBM i release, varying on the IASP on a newer OS release on the target, will require a full re-synchronization of data to occur as part of a reattach of the Geographic Mirrored IASP in the instructions below.

Data transfer times for geographic mirroring are dependent upon several factors including the amount of used storage on the IASP and connection between systems. Transfer times may be reduced by enabling Geographic Mirroring compression and increasing the geographic mirroring synchronization priority.

Work with the configuration status of the independent ASP (IASP) by using the WRKCFGSTS command. For example: WRKCFGSTS CFGTYPE(*DEV) CFGD(MYIASP).
Use Option 1 to vary on the IASP.
In another session, use the Display ASP Status Command (DSPASPSTS) to monitor the vary on progress.

Once testing is completed, Vary off the IASP on NODEB.
If clustering is inactive on NODEB, start clustering by using the STRCLUNOD command. For example: STRCLUNOD NODE(NODEB)
If the cluster resource group is inactive, start the Cluster Resource Group using the STRCRG command. For example: STRCRG CRG(MYCRG)
Reattach the mirrored copy using the Change Session command. See the appropriate procedure depending on the type of replication. This initiates a resynchronization of the mirrored data. After the resynchronization is completed, you can continue the upgrade process.

Part 2 - Switch users to the Backup Node

Now that initial testing is completed, users can be switched to the backup node to make it the new primary node. This will enable the original primary node to be upgraded while users continue to access Node B.

Perform a switchover using the CHGCRGPRI command. For example: CHGCRGPRI CRG(MYCRG)

Part 3 - Upgrading the Original Primary Node

If the status of the CRG is anything other than Inactive, end the cluster resource group with the ENDCRG command. In this scenario, the command is: ENDCRG CRG(MYCRG)
End clustering on the original primary node. This is NODEA in the example by using the ENDCLUNOD command. In this scenario, the command is: ENDCLUNOD NODE(NODEA)
Upgrade NODEA to the new software level. This new level could be for program temporary fixes (PTFs) or to a new release. If upgrading to a new release see Upgrading or replacing IBM i and related software for details.
If clustering is inactive on NODEA, start clustering by using the STRCLUNOD command. For example: STRCLUNOD NODE(NODEA)
If the cluster resource group is inactive, start the Cluster Resource Group using the STRCRG command. For example: STRCRG CRG(MYCRG)
Display the PowerHA replication session using the display session command. See the appropriate procedure depending on the type of replication:

If the replication status is suspended, resume replication using the Change Session command. See the appropriate procedure depending on the type of replication. This initiates a resynchronization of the mirrored data. After the resynchronization is completed, you can continue the process:

Part 4 - Switch Users Back to the Original Primary Node

Now that everything has been upgraded, users can be switched back to the original primary node, NODEA in this example.

Perform a switchover using the CHGCRGPRI command. For example: CHGCRGPRI CRG(MYCRG)

Results

Both nodes in the PowerHA environment have been upgraded; the outage users experienced was reduced to only the amount of time it takes to perform a switchover in a PowerHA enviornment.

IBM Partnership

Upgrading or Updating the Operating System in a PowerHA Environment