Planning for dynamic VIPA takeover

Movement by network management automation or operator intervention is not always desirable. Operator intervention takes time and is subject to errors. Automation requires correct detection of the failure and is also prone to error if the failure does not produce the exact console messages anticipated.

The dynamic VIPA takeover function addresses this problem. It is important to understand that dynamic VIPA takeover does not introduce functions that could not be accomplished by operator action or automation. It just removes the dependency on human detection of the error or customer programming for automation. Dynamic VIPA takeover is completely accomplished by the TCP/IP stacks.

DVIPA takeover is possible when a DVIPA is configured as active (using VIPADEFINE) on one stack and as backup (using VIPABACKUP) on another stack within the sysplex. When the stack on which the DVIPA is active terminates or leaves the sysplex group, the backup stack automatically activates the DVIPA and notifies the routing daemon. For information on what causes a stack to leave the sysplex group, see Sysplex problem detection and recovery.

For DVIPA takeover to be useful, the applications that service the DVIPA addresses must be available on the backup stacks. In the absence of the application, the DVIPA will be active, but client connections to the application will still fail. If OMPROUTE is used, it is recommended that GLOBALCONFIG SYSPLEXMONITOR DELAYJOIN be configured. This causes DVIPA takeover to be delayed until OMPROUTE is active and able to advertise DVIPAs on the takeover stack. For more information on how DELAYJOIN works, see Sysplex problem detection and recovery.

To preserve connections during DVIPA takeover, the TCP/IP stacks require XCF links. The DYNAMICXCF option must be coded in the TCP/IP profile of both stacks.

A determination of how the workload will be distributed among the backup stacks when the primary stack fails should be made. It is possible to designate a single stack as a backup and move all the workload to it, or the workload can be distributed among several stacks. In the first case, you need to configure only one DVIPA with a VIPADEFINE statement on the primary stack, and only one VIPABACKUP statement is required on the backup stack. For the second option, you must configure multiple DVIPAs with a VIPADEFINE statement on the primary stack.

After determining the workload distribution, each of the secondary stacks will require a VIPABACKUP statement for the DVIPA it will be supporting.

The following example shows how to implement a single stack backup for multiple applications.

Figure 1. Sample DVIPA addressing in a sysplex environment
Example of implementing a single stack backup for multiple applications
Stack TCPCS:
Uses VIPADEFINE to define 201.2.10.11 
Has a Web server running that binds to INADDR_ANY. 
  Web client programs use 201.2.10.11 as their destination address. 
Has an FTP server running that binds to INADDR_ANY. 
  FTP client programs use 201.2.10.11 as their destination address.
Stack TCPCS3:
Uses VIPABACKUP to define 201.2.10.11 as backup for stack TCPCS.
Has a Web server running that binds to INADDR_ANY.  
Has an FTP server running that binds to INADDR_ANY.

In the preceding scenario, when stack TCPCS goes down, stack TCPCS3 receives all new connection requests for both the web and FTP servers. FTP and web client programs continue to use 201.2.10.11 as their destination address, but they now connect to stack TCPCS3.

The following example shows how to implement a multiple stack backup for multiple applications.

Stack TCPCS:
Uses VIPADEFINE to define 201.2.10.11 and 201.2.10.12 
Has a Web server running that binds to INADDR_ANY. 
  Web client programs use 201.2.10.11 as their destination address. 
Has an FTP server running that binds to INADDR_ANY. 
  FTP client programs use 201.2.10.12 as their destination address.
 
Stack TCPCS2:
Uses VIPABACKUP to define 201.2.10.11 as backup for stack TCPCS. 
Has a Web server running that binds to INADDR_ANY.   
 
Stack TCPCS3:
Uses VIPABACKUP to define 201.2.10.12 as backup for stack TCPCS. 
Has an FTP server running that binds to INADDR_ANY. 
 

In the preceding scenario, when stack TCPCS goes down, new connections for the web server at 201.2.10.11 will connect with stack TCPCS2, and new connections for the FTP server at 201.2.10.12 will connect with stack TCPCS3.