Sysplex distributor enhanced workload distribution for z/OS multi-tier, OPTLOCAL configurations with CPC affinity

In addition to multi-tier application awareness and optimizing distribution when these applications are local, you can use the CPCSCOPE keyword to further optimize sysplex distributor load balancing decisions. This configuration option helps to avoid workload distribution to tier 1 servers that cannot perform the tier 2 processing on the same CPC, which requires distribution of those tier 2 connections to systems that are on a different CPC. Figure 1 shows an example configuration in which this option might be useful.

Figure 1. z/OS multi-tier application configuration using CPCSCOPE DVIPAs

Configuration of two-tier server applications that are optimized by using sysplex distributor with CPCSCOPE keyword

In Figure 1, connection requests for tier 1 server applications are distributed to systems based on the aggregate WLM recommendations of the tier 1 and tier 2 server applications running on each system. When connections are directed to a tier 1 server instance, any subsequent tier 2 connections that are originated by that server instance are likely to be directed to the local tier 2 server as a result of the OPTLOCAL keyword, assuming that the tier 2 server application is active on the local system.

If the tier 1 server cannot access a tier 2 server on the same system, the connection requests and their associated data flows are sent to the sysplex distributor for the tier 2 DVIPA; this distributor might be on another system in the sysplex. That system might be on the same CPC as the tier 1 server, or it might be on another CPC at the same site or potentially at a remote site. The sysplex distributor then selects a target tier 2 server instance that is on the same CPC or in another CPC. In either case, inbound traffic from the tier 1 server to the tier 2 server might need to traverse one or more CPCs or external network links before it reaches the tier 2 server.

You can optimize these flows by using the CPCSCOPE keyword and confining the activation and movement of a DVIPA to a specific CPC, which in turn enables any connection using the backup path to a tier 2 server to also remain within an LPAR on the same CPC. This optimization enables these backup data flows to leverage secure, high speed, virtual network links inside the CPC, such as HiperSockets™. This configuration also helps to ensure that these data flows are optimized by avoiding the need to traverse external links, which might result in additional network latency and encryption requirements.

Three DVIPAs are defined in Figure 1:

DVIPA1 represents the tier 1 servers that are on LPAR1 - LPAR4. DVIPA1 is defined as a tier 1 DVIPA, and is associated with the group name WASCICS.
DVIPA2 represents the tier 2 servers that are on LPAR3 and LPAR4 on CPC2. DVIPA2 is defined as a tier 2 DVIPA, and is associated with the group name WASCICS. DVIPA2 also specifies the CPCSCOPE keyword, which ensures that DVIPA2 remains within LPARs on CPC2, even in recovery scenarios where DVIPA takeover is required.
DVIPA3 represents the tier 2 servers that are on LPAR1 and LPAR2 on CPC1. DVIPA3 is similar to DVIPA2; it is also a tier 2 DVIPA, is associated with the same group name (WASCICS), and also specifies the CPCSCOPE keyword. If a takeover is required for this DVIPA, it remains within any backup LPARs on CPC1.

Requirement: Configure the tier 1 application servers on each CPC to use a unique, CPC-specific DVIPA for their tier 2 connections. The tier 1 application server configurations need to be unique based on the CPC where they are.

Guideline: Before activating this feature, consider the benefits that the feature provides versus the additional configuration requirements that this type of configuration requires. You must carefully define the tier 2 DVIPAs to ensure that the correct VIPADEFINE and VIPBACKUP definitions are maintained on each of the LPARs based on the CPC on which the LPARs are defined. These definitions can have implications on your recovery plans and procedures that might allow z/OS® systems or tier 1 server applications to be restarted on LPARs in different CPCs, rather than in the CPC in which they were originally activated.

For more information about the CPCSCOPE keyword on the VIPADISTRIBUTE statement in the VIPADYNAMIC block, see z/OS Communications Server: IP Configuration Reference.