Using PowerHA with Robot HA - One to Many Role Swap Checklist

NOTES: 

  • *SWAPIP role swap type in Robot HA and Takeover IP Address in PowerHA are not currently supported. Also, ‘cascade flow’ (A to B1 to B2) for data replication is 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 within specific *ONE_TO_N role swap configurations. 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.

Supported Configurations:

Configuration #1: A single copy of the IASP that is switched between the nodes.

Configuration #2: Nodes A and B are sharing a single copy of the IASP that is switched between them, and then Node C has a second copy.

Configuration #3: Node A and B share a copy that is replicated to the copy that Nodes C and D share.

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.


NOTE: The below setup steps use Configuration #2 above but can be modified to adapt to your specific configuration.

  1. [ ] On the *PROD (Node A), ensure that the TCP/IP server is running.

  2. [ ] On the first *BACKUP (Node B), ensure that the TCP/IP server is running.

  3. [ ] On the *PROD (Node A), run the INZRSFHA with BACKUP1 listed as the ‘Secondary System’ for the *BACKUP (Node B):
    NOTE: RSFCFGBKP and RSFBKP libraries for BACKUP1 need to be changed to: RSFCFGBKP1 and RSFBKP1.

    • INZRSFHA CHKSPACE(*NO) SWAPTYPE(*ONE_TO_N) JRNLIB(JRNLIB) RMTJRNLIB(RMTJRNLIB) PRIMARY((PROD) yourProdNodeASystemName ‘prodIPAddress’ *SAME *SAME RSFPRD RSFCFGPRD) SECONDARY((BACKUP1) yourBackupNodeBSystemName ‘backup1IPAddress’*SAME RSFBKP1 RSFCFGBKP1)

  4. [ ] On the second *BACKUP (Node C), ensure that the TCP/IP server is running.

  5. [ ] On the *PROD (Node A), run the INZRSFHA with BACKUP2 listed as the ‘Secondary System’ for the *BACKUP (Node C):
    NOTE: RSFCFGBKP and RSFBKP libraries for BACKUP2 need to be changed to: RSFBKP2 and RSFCFGBKP2.

    • INZRSFHA CHKSPACE(*NO) SWAPTYPE(*ONE_TO_N) JRNLIB(JRNLIB) RMTJRNLIB(RMTJRNLIB) PRIMARY((PROD) yourProdNodeASystemName ‘prodIPAddress’ *SAME *SAME RSFPRD RSFCFGPRD) SECONDARY((BACKUP2) yourBackupNodeCSystemName ‘backup2IPAddress’*SAME RSFBKP2 RSFCFGBKP2)

  6. [ ] Use a file utility to setup the backup records needed in file RBTHALIB/LSTBKP on the *PROD system in library RBTHALIB and copy the file to library RSFUSER. This file should contain only the Backup Systems.

  7. [ ] Sync the RSFUSER library to all backup systems.


NOTE: Auditing is not currently setup for *ONE_TO_N configurations. Auditing will run with the server from the last INZRSFHA command that was run.

 


NOTE: The below scenario uses Configuration #2 above but can be modified to adapt to your specific configuration.

Steps to run a Swap from Prod (Node A) to the first Backup (Node B) and vice-versa

Before the role swap:

  • [ ] End Sync jobs on all partitions before swaps. Leave TCP/IP server active.

Swap *PROD Node A to the *BACKUP role of BACKUP1 Node B (swapping production to backup):

  1. [ ] On the *PROD system Node A, run the following steps in Robot HA:

    1. [ ] Select option 7, Role Swap Menu from the Robot HA Main Menu. Then, select 10, Role Swap.

    2. [ ] Do the following on the Role Swap to Backup panel:

      1. [ ] Choose whether you want to run the role swap from the system console, or specify *YES for Run in batch to submit the job to a job queue.

      2. [ ] If you want to flag the role swap as a test run, change Set test flag to *YES. Otherwise, leave the default as *NO. The option *NOCHG will use the value specified during the last role swap (this is helpful if your role swap needs to be restarted).
        EXAMPLE: Specifying *YES allows you to run different system startup programs, since it's flagged as a test role swap instead of a real one.

      3. [ ] Specify *YES for Are you sure?, otherwise the role swap won't proceed.

      4. [ ] Press Enter.

  2. [ ] Once you receive the message ‘Waiting for reply to message on message queue QSYSOPR.’, select the server name related to the node you are swapping to. (BACKUP1).

Swap *BACKUP Node B to the *PROD role that was PROD Node A (swapping backup to production):

  1. [ ] On the *BACKUP system that was BACKUP1 Node B, run the following steps in Robot HA.

    1. [ ] Select option 7, Role Swap Menu from the Robot HA Main Menu. Then, select 10, Role Swap.

      [ ] Do the following on the Role Swap to Production panel:

      1. [ ] Choose whether you want to run the role swap from the system console, or specify *YES for Run in batch to submit the job to a job queue.

      2. [ ] If you want to flag the role swap as a test run, change Set test flag to *YES. Otherwise, leave the default as *NO. The option *NOCHG will use the value specified during the last role swap (this is helpful if your role swap needs to be restarted).
        EXAMPLE: Specifying *YES allows you to run different system startup programs, since it's flagged as a test role swap instead of a real one.

      3. [ ] Specify *YES for Are you sure?, otherwise the role swap won't proceed.

      4. [ ] Press Enter. 

  2. [ ] Take note that the Server ID’s have been changed on ALL Backup Systems (Node A and Node C) to sync to the new *PROD system Node B.

Manual Steps after the role swaps:

  1. [ ] Start the TCP/IP server on the new PROD.

  2. [ ] The remaining *BACKUP systems that did NOT swap with this PROD now have a new PROD to sync to. These backups’ sync attributes need to be changed to SYNCDATE *NONE so they can sync the libraries to the new PROD, and then start syncing at regular intervals. On the *BACKUP system(s) that did not swap, execute the following commands and steps:

    1. [ ] CHGRSFSSA SERVER(PROD) TYPE(*CFG) SYNCDATE(*NONE)

    2. [ ] CHGRSFSA LIB(RBTHALIB) TOLIB(TOLIB name) SERVER(PROD) SYNCDATE(*NONE).

    3. [ ] Run the appropriate Change command for any additional sync entries you may have on the additional Backup system that will sync to the new PROD. Change the SYNCDATE parameter to *NONE.

    4. [ ] Sync the entries to the new PROD.

  3. [ ] Release the RSFUSER/RSFHA job queue on all PROD and BACKUP systems.

  4. [ ] IF you have decided to make the PROD permanent or if you will ever switch the new PROD to the 2nd Backup (the one you did not swap this time), the following steps must be run to identify the new PROD for swapping purposes:

    1. [ ] On the new *PROD (Node B), run INZRSFHA to reset the System for Node B as the preferred *PROD and Node A as the preferred *BACKUP BACKUP1.

      • INZRSFHA CHKSPACE(*NO) RPLSYNCSTR(*YES) RPLSYNCJOB(*YES) RPLMON(*YES) RPLSWAP(*YES) RPLJOBSCDE(*YES) SWAPTYPE(*ONE_TO_N) JRNLIB(JRNLIB) RMTJRNLIB(RMTJRNLIB) PRIMARY((PROD) yourProdNodeBSystemName ‘prodIPAddress’ *SAME *SAME RSFPRD RSFCFGPRD) SECONDARY((BACKUP1) yourBackupNodeASystemName ‘backup1IPAddress’ *SAME RSFBKP1 RSFCFGBKP1)

    2. [ ] On the new *PROD (Node B), run INZRSFHA to reset the System for Node B as the preferred *PROD and Node C as the preferred *BACKUP BACKUP2.

      • INZRSFHA CHKSPACE(*NO) RPLSYNCSTR(*YES) RPLSYNCJOB(*YES) RPLMON(*YES) RPLSWAP(*YES) RPLJOBSCDE(*YES) SWAPTYPE(*ONE_TO_N) JRNLIB(JRNLIB) RMTJRNLIB(RMTJRNLIB) PRIMARY((PROD) yourProdNodeBSystemName ‘prodIPAddress’ *SAME *SAME RSFPRD RSFCFGPRD) SECONDARY((BACKUP2) yourBackupNodeCSystemName ‘backup2IPAddress’ *SAME RSFBKP2 RSFCFGBKP2)

    3. [ ] On the new *PROD system (Node B), update the LSTBKP file in RBTHALIB and copy it to the RSFUSER library to show that the System for Node A is now a Backup and remove the System for Node B.

    4. [ ] Sync the RSFUSER library to *BACKUP BACKUP1 (Node A).

    5. [ ] Sync the RSFUSER library to *BACKUP BACKUP2 (Node C).


NOTE: The Robot HA IBM Job Scheduler Jobs will currently only be run for the last backup you ran INZRSFHA on. This will be changed in a future release of Robot HA.

  1. [ ] Start sync jobs on *PROD PROD (Node B).

  2. [ ] Start sync jobs on *BACKUP BACKUP1 (Node A).

  3. [ ] Start sync jobs on *BACKUP BACKUP2 (Node C).

 

Steps to run a Swap from Prod (Node B) to the second Backup (Node C) and vice-versa

Before the role swap:

  • [ ] End Sync jobs on all partitions before swaps. Leave TCP/IP server active.

Swap *PROD Node B to the *BACKUP role of BACKUP2 Node C (swapping production to backup):

  1. [ ] On the *PROD system Node B, run the following steps in Robot HA:

    1. [ ] Select option 7, Role Swap Menu from the Robot HA Main Menu. Then, select 10, Role Swap.

      [ ] Do the following on the Role Swap to Backup panel:

      1. [ ] Choose whether you want to run the role swap from the system console, or specify *YES for Run in batch to submit the job to a job queue.

      2. [ ] If you want to flag the role swap as a test run, change Set test flag to *YES. Otherwise, leave the default as *NO. The option *NOCHG will use the value specified during the last role swap (this is helpful if your role swap needs to be restarted).
        EXAMPLE: Specifying *YES allows you to run different system startup programs, since it's flagged as a test role swap instead of a real one.

      3. [ ] Specify *YES for Are you sure?, otherwise the role swap won't proceed.

      4. [ ] Press Enter.

  2. [ ] Once you receive the message ‘Waiting for reply to message on message queue QSYSOPR.’, select the server name related to the node you are swapping to. (BACKUP2).

Swap *BACKUP Node C to the *PROD role that was PROD Node B (swapping backup to production):

  1. [ ] On the *BACKUP system that was BACKUP2 Node C, run the following steps in Robot HA.

    1. [ ] Select option 7, Role Swap Menu from the Robot HA Main Menu. Then, select 10, Role Swap.

      [ ] Do the following on the Role Swap to Production panel:

      1. [ ] Choose whether you want to run the role swap from the system console, or specify *YES for Run in batch to submit the job to a job queue.

      2. [ ] If you want to flag the role swap as a test run, change Set test flag to *YES. Otherwise, leave the default as *NO. The option *NOCHG will use the value specified during the last role swap (this is helpful if your role swap needs to be restarted).
        EXAMPLE: Specifying *YES allows you to run different system startup programs, since it's flagged as a test role swap instead of a real one.

      3. [ ] Specify *YES for Are you sure?, otherwise the role swap won't proceed.

      4. [ ] Press Enter.

  2. [ ] Take note that the Server ID’s have been changed on ALL Backup Systems (Node A and Node B) to sync to the new *PROD system Node C.

Manual Steps after the role swaps:

  1. [ ] Start the TCP/IP server on the new PROD.

  2. [ ] The remaining *BACKUP systems that did NOT swap with this PROD now have a new PROD to sync to. These backups’ sync attributes need to be changed to SYNCDATE *NONE so they can sync the libraries to the new PROD, and then start syncing at regular intervals. On the *BACKUP system(s) that did not swap, execute the following commands and steps:

    1. [ ] CHGRSFSSA SERVER(PROD) TYPE(*CFG) SYNCDATE(*NONE)

    2. [ ] CHGRSFSA LIB(RBTHALIB) TOLIB(TOLIB name) SERVER(PROD) SYNCDATE(*NONE).

    3. [ ] Run the appropriate Change command for any additional sync entries you may have on the additional Backup system that will sync to the new PROD. Change the SYNCDATE parameter to *NONE.

    4. [ ] Sync the entries to the new PROD.

  3. [ ] Release the RSFUSER/RSFHA job queue on all PROD and BACKUP systems.

  4. [ ] IF you have decided to make the PROD permanent or if you will ever switch the new PROD to the 1st Backup (Node A - the one you did not swap this time), the following steps must be run to identify the new PROD for swapping purposes:

    1. [ ] On the new *PROD (Node C), run INZRSFHA to reset the System for Node C as the preferred *PROD and Node A as the preferred *BACKUP BACKUP1.

      • INZRSFHA CHKSPACE(*NO) RPLSYNCSTR(*YES) RPLSYNCJOB(*YES) RPLMON(*YES) RPLSWAP(*YES) RPLJOBSCDE(*YES) SWAPTYPE(*ONE_TO_N) JRNLIB(JRNLIB) RMTJRNLIB(RMTJRNLIB) PRIMARY((PROD) yourProdNodeCSystemName ‘prodIPAddress’ *SAME *SAME RSFPRD RSFCFGPRD) SECONDARY((BACKUP1) yourBackupNodeASystemName ‘backup1IPAddress’ *SAME RSFBKP1 RSFCFGBKP1)

    2. [ ] On the new *PROD (Node C), run INZRSFHA to reset the System for Node C as the preferred *PROD and Node B as the preferred *BACKUP BACKUP2.

      • INZRSFHA CHKSPACE(*NO) RPLSYNCSTR(*YES) RPLSYNCJOB(*YES) RPLMON(*YES) RPLSWAP(*YES) RPLJOBSCDE(*YES) SWAPTYPE(*ONE_TO_N) JRNLIB(JRNLIB) RMTJRNLIB(RMTJRNLIB) PRIMARY((PROD) yourProdNodeCSystemName ‘prodIPAddress’ *SAME *SAME RSFPRD RSFCFGPRD) SECONDARY((BACKUP2) yourBackupNodeBSystemName ‘backup2IPAddress’ *SAME RSFBKP2 RSFCFGBKP2)

    3. [ ] On the new *PROD system (Node C), update the LSTBKP file in RBTHALIB and copy it to the RSFUSER library to show that the System for Node B is now a Backup and remove the System for Node C.

    4. [ ] Sync the RSFUSER library to *BACKUP BACKUP1 (Node A).

    5. [ ] Sync the RSFUSER library to *BACKUP BACKUP2 (Node B).


NOTE: The Robot HA IBM Job Scheduler Jobs will currently only be run for the last backup you ran INZRSFHA on. This will be changed in a future release of Robot HA.

  1. [ ] Start sync jobs on *PROD PROD (Node C).

  2. [ ] Start sync jobs on *BACKUP BACKUP1 (Node A).

  3. [ ] Start sync jobs on *BACKUP BACKUP2 (Node B).
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
+1 800-328-1000
[email protected]
Infrastructure Protection & Data Security
Managed Security Services
Automation
IBM i

Copyright © 2023 Fortra