Setting Up a One to Many HA Environment

 

The following are steps to be taken when setting up a One to Many role swap configuration. 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.

Setting up Environment

The following are the steps to setup a One to Many Environment:

1. [ ] On the Production system (Node A), ensure that the TCP/IP server is running.
2. [ ] On BACKUP1 system (Node B), ensure that the TCP/IP server is running and that replication role has been set to *BACKUP.
3. [ ] On the Production system, run the INZRSFHA with BACKUP1 listed as the ‘Secondary System’ for the Backup.

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) yourProdSystemName ‘prodIPAddress’ *SAME *SAME RSFPRD RSFCFGPRD) SECONDARY((BACKUP1) yourBackup1SystemName ‘backup1IPAddress’*SAME RSFBKP1 RSFCFGBKP1)

4. [ ] On the BACKUP2 (Node C) system, ensure that the TCP/IP server is running and that the replication role is set to *BACKUP.
5. [ ] On the Production system (Node A), run the INZRSFHA with BACKUP2 listed as the ‘Secondary System’ for the Backup.

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) yourProdSystemName ‘prodIPAddress’ *SAME *SAME RSFPRD RSFCFGPRD) SECONDARY((BACKUP2) yourBackup2SystemName ‘backup2IPAddress’*SAME RSFBKP2 RSFCFGBKP2)

6. [ ] Use a file utility to edit and setup the backup records needed in file RBTHALIB/LSTBKP on the Production system in library RBTHALIB. Each backup system should contain its own record in the file.

The following parameters should be setup for each backup system:

• Server IDs (BKSRV): This is the Server ID that is defined in the Server Definitions from the Robot HA Setup Menu. (See note 1)
• Number of Server IDs (BKNSRV): Since each record only contains one backup system, this should be 1, unless you have multiple server IDs. If you have more than one server defined for the BKSRV field, then this number should relate to how many server names you have defined. (See note 1)
• System Name (BKSYS): This is the name of the system.
• Serial (BKSRL#): This is the serial number of the system.
• IP Address (BKIP): This is the IP address of the system.
• Startup Program Name (BKSPGM): This is the name of the startup program.
• Startup Program Library (BKSLIB): This is the library where the startup program resides.
• Library Containing RSFBKP (BKRBKP): This is the library name that corresponds to the default name RSFBKP. (See note 2)
• Library Containing RSFCFGBKP (BKCBKP): This is the library that corresponds to the default name RSFCFGBKP. (See note 2)

Note 1:  In early releases of Robot HA, prior to having the option to define a "Set" within Robot HA, you may have more than one server defined to the same backup.  If that is the case, each server needs to be defined in the BKSRV field.  'BACKUP    BACKUPx'.  The second name should start in position 11, the third in position 21, etc.  Most systems today will have only one Server ID for your backup system.
Note 2:  When you have multiple backup systems, each backup system has to have a sync attribute for library RBTHALIB and a system sync attribute for *CFG that is sent to the production system to be used at swap time.  The default names are RSFBKP and RSFCFGBKP.  This can be used on one of the backup systems, but the other backup system needs a unique name (e.g., RSFBKP2 and RSFCFGBKP2) because these libraries are sent to the production when they are synced. 
 

7. Copy the LSTBKP file to library RSFUSER. This file should contain only the Backup Systems
8. [ ] Sync the RSFUSER library to all backup systems.

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

Steps to run a Swap from PROD (Node A) to Backup 1 (Node B)

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 is flagged as a test role swap instead of a real one.
      3. [ ] Specify *YES for Are you sure?, otherwise the role swap will not 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 (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.
   2. [ ] 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 is flagged as a test role swap instead of a real one.
      3. [ ] Specify *YES for Are you sure?, otherwise the role swap will not proceed.
      4. [ ] Press Enter.
2. [ ] Take note that the Server IDs 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 (Node B).
2. [ ] The remaining *BACKUP system (Node C) 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 (NODE C), 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 BACKUP2 (Node C), 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.

5. [ ] Start sync jobs on *PROD PROD (Node B).
6. [ ] Start sync jobs on *BACKUP BACKUP1 (Node A).
7. [ ] Start sync jobs on *BACKUP BACKUP2 (Node C).

Steps to run a Swap from Prod (Node B) to Backup 2 (Node C)

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.
   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 is flagged as a test role swap instead of a real one.
      3. [ ] Specify *YES for Are you sure?, otherwise the role swap will not 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.
   2. [ ] 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 is flagged as a test role swap instead of a real one.
      3. [ ] Specify *YES for Are you sure?, otherwise the role swap will not proceed.
      4. [ ] Press Enter.
2. [ ] Take note that the Server IDs 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.

5. [ ] Start sync jobs on *PROD PROD (Node C).
6. [ ] Start sync jobs on *BACKUP BACKUP1 (Node A).
7. [ ] Start sync jobs on *BACKUP BACKUP2 (Node B).