Since sysplex distributor requires dynamic XCF, the first configuration step is to enable dynamic XCF on each host. All these configuration statements belong in the TCP/IP profile data set.

The dynamic XCF IP addresses in Figure 1 are used by the distributing TCP/IP host when it redirects packets to a target host.

Figure 1. Dynamic XCF network sample

In order to balance the connections to the appropriate targets, TCP/IP is going to need to be talking to the workload manager. By coding SYSPLEXROUTING in the IPCONFIG section of the TCP/IP profile, we can ensure that WLM is consulted for connection distribution advice.

If LPAR 1 is to function as a distributor, the next thing to be defined is the IP address it uses. We'll use the definitions in Figure 2. This means that 10.134.61.190 is the IP address a client on the network would use to connect to the sysplex.

Figure 2. Multiple application-instance DVIPA

At this stage, you might notice, the only new statement discussed is the SYSPLEXROUTING statement in order to involve WLM. But how do we go about getting the TCP/IP stack in LPAR 1 to function as a distributing host? For this, we need to add a VIPADISTRIBUTE option within the VIPADYNAMIC block of statements; see Figure 3.

 IPCONFIG SYSPLEXROUTING DYNAMICXCF 192.168.80.1 255.255.255.0
 VIPADYNAMIC
 VIPADEFINE 255.255.255.192 10.134.61.190
 VIPADISTRIBUTE DEFINE SYPLEXPORTS 10.134.61.190 PORT 21 DESTIP ALL
 ENDVIPADYNAMIC

The VIPADISTRIBUTE statement identifies DVIPA address 10.134.61.190 as an IP address to be distributed. Only connections for port 21 is distributed. And, those connections are only distributed to target hosts that have an active listen on port 21 (allowing for application failure or seamless application take down). The destination IP addresses are all active dynamic XCF IP addresses within the sysplex.

The SYSPLEXPORTS parameter on the VIPADISTRIBUTE statement is used to manage the assignment of ephemeral ports among the LPARs.

What about the other hosts in this sample? Do they need to have any definitions changed? For our purposes, the answer is no. Returning to Figure 3, LPARs 2 and 3 are both backup LPARs for 10.134.61.190.

In event of a failure in LPAR 1, LPAR 2 would take over the DVIPA. In addition, it automatically inherits the distribution capabilities and characteristics that are defined for LPAR 1. If both LPAR 1 and LPAR 2 fail (either at the same time or in sequence), LPAR 3 would become the distributor of 10.134.61.190.

When the problem is recovered and LPAR 1 is brought back into the sysplex, it would non-disruptively take back the role as the distributor.