NOTES:
  • *SWAPIP role swap type in Robot HA and Takeover IP Address in PowerHA are not currently supported. 
  • As part of this integration, be aware that Robot HA does not end all subsystems.
  

The following are steps to be taken when integrating PowerHA with Robot HA during specific role swap scenarios. These instructions are intended as a starting point for advanced configuration and in-depth product considerations within a larger role swap plan. You can supplement this information, where needed, with the Robot HA product documentation and your PowerHA User Guide.

 

Setup:

NOTE: You must be on Robot HA 12.06 or higher
  1. [ ] Run the command CHGDTAARA DTAARA(RBTHALIB/RHAPHA (1 1)) VALUE('1') on all systems in the cluster that can be swapped to create the relationship between PowerHA and Robot HA.

  2. [ ] Run the following to ensure that the configuration object that brings the ASP online after the switch has been turned to *OFFLINE:

    1. [ ] Run the command WRKCLU.

    2. [ ] Take Option 9 within the Work with Cluster panel.

    3. [ ] Take Option 7 on the cluster resource group within the Work with Cluster Resource Groups panel.

    4. [ ] Take Option 2 on the configuration object within the Work with Configuration Objects panel.

    5. [ ] Change the value of Configuration object online to *OFFLINE within the Change CRG Device Entry panel. Press ENTER.

  3. [ ] Ensure that the following integration considerations have been addressed:

    • The following objects can be replicated in Robot HA and also in the Admin Domain, but should be done in one or the other – not in both places: *USRPRF and *AUTL

    • The following are not automatically restored via the APYCFGRSF command in the SWAPTOxxx; and it is recommended that you not include these in your customized role swap code when using Robot HA with PowerHA:

      • *EXITREG – It is not recommended modifying your swap source to include the Exit Point Registration apply. PowerHA and Clusters heavily use Exit Points and you would be replacing them.

      • *DCM - this is where the RSTUSRPRF (Restore User Profiles) command is run. This needs to run when all subsystems are down. Or, one of the following PTF’s must be installed to allow the *DCM configuration to be applied when the system is not in a restricted state. (V6R1, Prd 5760SS1, PTF SI50215), (V7R1, Prd 5770SS1, PTF SI50122). Without these PTF’s, it is not recommended that *DCM be reapplied from the Robot HA swap since it may trigger a failover in PowerHA.

    • *CLS, *JOBD, and *SBSD should not be monitored through PowerHA if they are already replicated via that Library in Robot HA.

    • Ensure that Robot HA is not replicating objects that start with 'QHA' in QGPL.

 

Scenario 1: A planned switchover

  1. [ ] On the Work with Cluster Resource Groups panel within PowerHA, take option 3 to 'change primary' or run the following command:

    • CHGCRGPRI CLUSTER(cluster) CRG(crgname)

  2. [ ] On Site 1, ensure all users are off the system and jobs have ended.

  3. [ ] Review the information in the Before you Begin section of the Robot HA Role Swap User Guide.

  4. [ ] On Site 1, run the Role Swap To Backup procedures in Robot HA.

  5. [ ] On Site 1, press F3 twice to return to the Robot Main Menu.

  6. [ ] On Site 2, ensure all users are off the system and jobs have ended.

  7. [ ] On Site 2, run the Role Swap To Production procedures in Robot HA.

  8. [ ] On Site 2, press F3 twice to return to the Robot Main Menu.

    NOTE: The role swap to production will automatically vary on the ASP.

 

Scenario 2: The cluster goes down on Site 1, but the system stays up or TCP/IP was ended on Site 1.

NOTE: For testing purposes, you can create this scenario by running the command: ENDCLUNOD CLUSTER(cluster) NODE (node)
  1. [ ] On Site 2, check the status of the surviving cluster node (Node B) by running command WRKCLU and taking Option 6 on the Work with Cluster panel.

  2. [ ] On Site 2, if Node A didn’t have time to send out a distress message to the other node indicating it was going down, then change the status of Node A to ‘Failed’ which will initiate the failover. Commands are: WRKCLU, Option 6=Work with cluster nodes, Option 2=Change, and select the Option *CHGSTS.

  3. [ ] On Site 1, ensure all users are off the system and jobs have ended.

  4. [ ] Review the information in the Before you Begin section of the Robot HA Role Swap User Guide.

  5. [ ] On Site 1, run the Role Swap To Backup procedures in Robot HA.

  6. [ ] On Site 1, press F3 twice to return to the Robot Main Menu.

  7. [ ] On Site 2, ensure all users are off the system and jobs have ended.

  8. [ ] On Site 2, run the Role Swap To Production procedures in Robot HA.

  9. [ ] On Site 2, press F3 twice to return to the Robot Main Menu.

    NOTE: The role swap to production will automatically vary on the ASP.

 

Scenario 3: Node A crashes.

NOTE: For testing purposes, you can create this scenario by executing: PWRDWNSYS
  1. [ ] On Site 2, check the status of the surviving cluster node (Node B) by running command WRKCLU and taking Option 6 on the Work with Cluster panel.

  2. [ ] On Site 2, if Node A didn’t have time to send out a distress message to the other node indicating it was going down, then change the status of Node A to ‘Failed’ which will initiate the failover. Commands are: WRKCLU, Option 6=Work with cluster nodes, Option 2=Change, and select the Option *CHGSTS.

  3. [ ] On Site 2, ensure all users are off the system and jobs have ended.

  4. [ ] Review the information in the Before you Begin section of the Robot HA Role Swap User Guide.

  5. [ ] On Site 2, run the Role Swap To Production procedures in Robot HA.

  6. [ ] On Site 2, press F3 twice to return to the Robot Main Menu.

    NOTE: The role swap to production will automatically vary on the ASP.
  7. [ ] When Site 1 comes back up it will be detached from PowerHA. After an unplanned failover, the status of the session is detached. If needed, you can vary on the ASP to view or recover any missing data. Vary off the ASP when finished.

  8. [ ] On Site 1, ensure all users are off the system and jobs have ended.

  9. [ ] On Site 1, run the Role Swap To Backup procedures in Robot HA.

  10. [ ] On Site 1, press F3 twice to return to the Robot Main Menu.

  11. [ ] Site 1 is now the backup and Site 2 is still the primary. Run a REATTACH or RESUME command to resume PowerHA replication.

 

Scenario 4: The user wants to run a swap-while-active role swap.

  1. [ ] Detach the PowerHA replication using a DETACH command.

  2. [ ] Review the information in the Before you Begin section of the Robot HA Role Swap User Guide.

  3. [ ] On Site 2, follow the instructions to perform a Swap-While-Active role swap in Robot HA. This ends the communication between Site 1 and Site 2 and runs the Swap To Production on Site 2.

  4. [ ] Site1 and Site 2 are both *PROD systems; however, they are not communicating with one another. Press F3 twice to return to the Robot Main Menu.

  5. [ ] Manually vary on the ASP on Site 2.

    NOTE: If you want to switch the primary node roles before re-attaching, consult your PowerHA user guide.
  6. [ ] When testing is complete, you will need to manually vary off the ASP on Site 2.

  7. [ ] Follow the instructions for ending the Swap-While-Active role swap in Robot HA. This runs the Swap To Backup on Site 2.

  8. [ ] Discard any changes you made to the target copy.

  9. [ ] When complete, re-attach to resume PowerHA replication using a REATTACH  command.

 

DETACH, REATTACH, and RESUME commands:

For SAN Volume Controller based external storage replication (Including SVC, Storwize V7000, and others), the command is: CHGSVCSSN SSN(sessionName) OPTION(*DETACH or *REATTACH or *RESUME). For geographic mirroring and DS8000 external storage replication, the command is: CHGASPSSN SSN(sessionName) OPTION(*DETACH or *REATTACH or *RESUME).

Still have questions? We can help. Submit a case to technical support

Last Modified On:
You don't have the appropriate permissions.
No, open a new Support Case