Configuring a backup controller for disaster recovery

HCL Workload Automation for Z supports the recovery of a system failure between two remote sites. A disaster recovery process ensures that the business supported by the data center is always kept viable by switching from a local site where the failure occurs, to a remote site.

The controller in charge of planning, controlling, and monitoring the workload sends all the data and plan updates to a backup controller running in a different sysplex. In this way, the backup controller (also known as a remote hot standby controller) is kept up-to-date and can act as the primary controller when a planned or unplanned switch occurs.

You can configure a backup controller to replace the primary controller in the event of a system or connection failure. Both controllers must have the same configuration. The backup controller is continuously connected with the primary controller through TCP/IP and kept updated with all the required data. When the backup controller takes over from the primary controller, the tracker, if running, switches its connection from the primary to the backup controller.

To configure a backup controller and set its communication with the primary controller, define the following initialization statements. .

BKPTOPTS: To define the local attributes for the TCP/IP communication between the primary and backup controller. Define this statement on both controllers.
OPCOPTS: To set the OPCHOST parameter, which defines the role of the subsystem. Define this statement on both controllers.
TRROPTS: To define the routing options from a z/OS tracker that is connected to a primary controller, and possibly also to a backup controller.
Note: To connect to a backup controller, a tracker can use only TCP/IP. In this case, to connect to a primary controller the same tracker can use only XCF or TCP/IP connection protocol.

The configuration to include a backup controller supports the following features:

z/OS trackers
HCL Workload Automation agents (also known as z-centric agents)
Dynamic domain managers
Cross dependencies

Configuring trackers, primary controller, and backup controller shows two remote sites, with two images each.

In this configuration:

The primary controller is connected to trackers A and B through XCF links. It is connected to the backup controller, trackers C and D through TCP/IP.
The backup controller connects to trackers A, B, C, and D through TCP/IP links when you issue the modify command /F procname,BKTAKEOVER and the backup controller becomes the controlling system.

On the primary controller you set the following statements:

OPCOPTS  OPCHOST(YES)
BKPTOPTS TCPIPJOBNAME('TCPIP')  
         HOSTNAME('1.11.111.111')  
         LOCPORTNUMBER(7543)        
         PEERHOSTNAME('2.22.222.222')
         PEERPORTNUMBER(6456)       
ROUTOPTS XCF(HWA2)                       1

On the backup controller you set the following statements:

OPCOPTS  OPCHOST(BACKUP)
BKPTOPTS TCPIPJOBNAME('TCPIP')            
         HOSTNAME('2.22.222.222')         
         LOCPORTNUMBER(6456)              
         PEERHOSTNAME('1.11.111.111')    
         PEERPORTNUMBER(7543)             
ROUTOPTS TCPIP(HWA2:'3.33.333.333'/4348)1

On trackers A and B you set the following statements:

TRROPTS  HOSTCON(XCF)                       
         BKPHOSTNAME('2.22.222.222')        
         BKPPORTNUMBER(924)                 
XCFOPTS GROUP(GRUXCFX)                      
        MEMBER(HWA2)                        
TCPOPTS  HOSTNAME('3.33.333.333')          
         TRKPORTNUMBER(4348)

On trackers C and D you have set the following statements:

TRROPTS  HOSTCON(TCP)                       
         TCPHOSTNAME('1.11.111.111')
         TCPPORTNUMBER(424)
         BKPHOSTNAME('2.22.222.222')        
         BKPPORTNUMBER(924)                 
TCPOPTS  HOSTNAME('3.33.333.333')           
         TRKPORTNUMBER(4348)

1: On the primary and backup controller, the destination name in the ROUTOPTS statement must be the same (HWA2, in this example).