Network setup options for Db2 Analytics Accelerator for z/OS

This document describes network setup options for Db2 Analytics Accelerator, independent of the Db2 Analytics Accelerator version unless explicitly stated. All described options assume that the Accelerator is deployed on a different physical server than the Db2 subsystem(s) that are connected to the Accelerator.

Table of contents:

Part 1: Network setup options for Db2 Analytics Accelerator

Part 2: Network setup options for Db2 Analytics Accelerator Incremental Update

• Accelerator network setup within a private data network
• Accelerator network setup within a server farm
• Basic incremental update setup within a private data network
• High-availability incremental update setup within a private data network
• Incremental update setup within a server farm

Content details:

Part 1: Network setup options for Db2 Analytics Accelerator

One option is to set up a separate subnet (called "private data network" in the Accelerator documentation) between the z/OS LPAR(s) hosting the Db2 subsystem(s) and the Accelerator server. A private data network ensures that the Accelerator Server can only be accessed from the LPAR(s) that are part of the private network. It cannot be accessed from the internet or from other defined subnets within your organization (e.g. the organization’s intranet).
Another option is to integrate the Accelerator into the same network and subnet as other distributed servers (typically called server farm). To reach a comparable level of security between the z/OS LPAR(s) and the Accelerator as provided by a private data network setup, it is recommended to configure encryption-of-data-in-motion between the z/OS LPAR(s) and the Accelerator.

The following two subchapters Accelerator network setup within a private data network and Accelerator network setup within a server farm describe the options in more detail.

If you want to use the Incremental Update function of Db2 Analytics Accelerator then this is possible for both options. Additional network settings might be required depending on whether a private data network is used or not, and depending on your high-availability requirements of software and hardware components. The chapter Part 2: Network setup options for Db2 Analytics Accelerator Incremental Update provides more details.

Accelerator network setup within a private data network

The following Figure 1 illustrates an example of a private data network setup consisting of one z/OS LPAR connected to one Accelerator via a 10Gb Ethernet OSA card, one switch, and appropriate fiber optic cables. The Accelerator has a Virtual IP address (10.101.8.9) assigned within the private data network (a.k.a Wall IP address in Db2 Analytics Accelerator V5). The Db2 subsystem running on the LPAR uses this Accelerator Virtual IP address to communicate with the Accelerator. The LPAR has one IP address (10.101.8.1) per OSA interface assigned within the private data network. The Accelerator can reach applications running on the LPAR via this IP address.

Figure 1 Basic private data network setup

Such a setup is typically used for test or development systems that have a Db2 subsystem deployed on a single LPAR.

The following Figure 2 illustrates an example of a private data network setup consisting of more than one LPAR connected to an Accelerator. For high-availability (HA) purposes two OSA cards are used as well as two switches. This ensures that a route is found to the Accelerator and back even if one OSA card, one switch, or one cable fails. Each LPAR has an IP address defined per OSA interface. A static virtual IP address (static VIPA) is defined over both IP addresses of each LPAR (10.101.8.3 and 10.101.8.6 respectively). This static VIPA ensures that applications on the LPAR can be accessed from the Accelerator no matter through which OSA card the network traffic flows.

Such a setup is typically used for production systems that have a Db2 Data Sharing Group defined across multiple LPARs.

Figure 2 High-availability private data network setup

Additional IBM Z servers or LPARs can be easily integrated into both setups as well as additional Accelerators.

For performance reasons, especially for the performance of loading data to the Accelerator, it is recommended to use dedicated OSA cards for the Accelerator private data network. However, sharing the OSA cards with other networks is possible as well.

Note, that the Accelerator supports static routing only. Therefore, use static definitions within the TCP/IP profile for routing to the Accelerator Server. The Db2 Analytics Accelerator V5 Installation Guide contains a Sample TCP/IP Configuration including VTAM definitions and TCP/IP profile settings. This sample configuration applies to Db2 Analytics Accelerator V7 as well because the VTAM and TCP/IP profile settings on IBM Z in general do not differ between Accelerator V5 and Accelerator V7.

Back to top

Accelerator network setup within a server farm

The following Figure 3 illustrates an example network setup where the Accelerator is integrated into the same network and subnet as other distributed servers (typically called server farm).

Figure 3 Accelerator network setup within server farm

In this example, all mainframes (IBM Z) communicate via a so-called OSA Transfer Network with each other. Any distributed servers are part of a networked server farm. Routers (gateways) and a high- speed network connection exist between the OSA Transfer Network and the Server Farm that enable communication between the mainframes and distributed servers. In the example above, LPAR1 and LPAR3 run Db2 for z/OS and have an Accelerator connected (Server 4 of the Server Farm). The Db2 subsystems on LPAR1 and LPAR3 could either be dedicated Db2 subsystems or could be Db2 members of a Data Sharing Group that is defined across LPAR1 and LPAR3. The TCP/IP setup across the network ensures that the virtual IP address of the Accelerator can be reached from applications such as Db2, running on LPAR1 and LPAR3.

An important difference to the private data network option is that the Accelerator has the gateway IP address of the Server Farm specified as part of its IP setup and this way finds a route to LPAR1 or LPAR3.

Another difference to the private data network option is that in most installations the server farm network can be reached from client applications - depending on firewall rules - and not just from the OSA Transfer network. This means that

• from a security perspective the attack vector of systems reaching the Accelerator is increased
• from a use case perspective other servers and other clients can reach the Accelerator - which will be important for future planned advanced analytics use cases

 

If you want use dedicated OSA card(s) for the communication between Db2 for z/OS and Db2 Analytics Accelerator, then you can do so even if no private network is specified between the LPAR and Db2 Analytics Accelerator. The following possibilities exist:

• Define a static route in the z/OS TCP/IP profile for the Accelerator’s virtual IP address outbound over one or more OSA cards
• Specify a policy-based routing (CDC capture agent address space, Db2 address space and stored procedure WLM address space outbound to Accelerator’s virtual IP address) in PAGENT configuration file to use one or more OSA cards for Db2 Analytics Accelerator

Back to top

Part 2: Network setup options for Db2 Analytics Accelerator Incremental Update

The Incremental Update feature of Db2 Analytics Accelerator is based on, and is a special use of, the existing Change Data Capture component of IBM InfoSphere^® Data Replication. The Change Data Capture component is part of and deeply integrated into the Db2 Analytics Accelerator product and is managed from Db2 Analytics Accelerator user interfaces.

Db2 Analytics Accelerator V5 introduced an option for “continuous incremental update”. With V7, this option has become the default and the only supported option.

The improvements with “continuous incremental update” are the following: It enables loading a replicated table without setting a lock on the entire table and without stopping incremental updates.

Without this extension any INSERT, UPDATE, and DELETE operations against the original Db2 table are not allowed while it is being loaded to the Accelerator because the entire table is locked. Additionally incremental updates are stopped for all replicated tables for a short timeframe at the beginning of the load and again at the end of the load process. The purpose of stopping incremental updates for all tables is to take the table to be loaded out of the incremental update process in order to load it and include it again into the incremental update process after the load has finished.
When continuous incremental updates are enabled it is not necessary to set a lock on the entire Db2 table while it is being loaded. A marker is set when the load process starts and also when it ends. All INSERT, UPDATE, and DELETE operations against the original Db2 table that fall into the load interval are replicated to the Accelerator and are written to a temporary file on the Accelerator (called spill queue). When the load process has finished, the changes are read from the spill queue and are applied to the loaded table. This is called draining. Besides that incremental updates are not stopped for other tables in the Db2 subsystem at the beginning and end of the load. This gives you an additional performance benefit.

In the following Figure 4 the components that are involved in an Incremental Update and Continuous Incremental Update setup are shown:

Figure 4 Incremental Update and Continuous Incremental Update components

The Accelerator Server notifies the Access Server about tables to be replicated after the Db2 Analytics Accelerator user has enabled tables for incremental update. The Access Server manages the table subscriptions and makes the CDC Capture Agent and Replication Engine aware of what to replicate. The CDC Capture Agent started task captures changed data for the replicated tables from the Db2 log and transfers committed data to the Replication Engine on the Accelerator. Afterwards the Replication Engine applies the data to the appropriate tables on the Accelerator.

For continuous incremental update the Accelerator Server requires an additional connection to the Db2 subsystem on the z/OS LPAR to write data into a Db2 table that the CDC Capture Agent requires for continuous incremental update processing. This connection is established via the Distributed Data Facility (DDF) started task of Db2. DDF allows client applications to access data in Db2 for z/OS via DRDA.

The setup of (Continuous) Incremental Update consists of the installation and configuration of the CDC Capture Agent on z/OS and a subsequent enablement step on the Accelerator to establish the communication between components. Main input parameters that you specify during the Incremental Update enablement are the IP addresses to establish the connection from the Access Server to the CDC Capture Agent and from the Accelerator Server to the DDF started task.
The enablement step is described in the Db2 Analytics Accelerator Knowledge Center in chapter Enabling Incremental Updates for a Db2 Subsystem.

Which IP addresses you can use for the connections depends on the network setup option you have chosen. Depending on whether you have set up the Accelerator within a private data network or within a server farm as described in the first part of this document Part 1: Network setup options for Db2 Analytics Accelerator,additional IP addresses might be required for incremental update or continuous incremental update to establish the connection between components, especially if high-availability of components matters. Which IP addresses you can use and whether additional ones are required is discussed in the remainder of this document.

To use (Continuous) Incremental Update in environments where a Db2 subsystem running on a single z/OS LPAR is connected to an Accelerator over a private data network as illustrated in Figure 1, refer to chapter Basic incremental update setup within a private data network.This setup is typically used for test or development systems where high-availability of components is not required. No additional IP addresses are required.

To use (Continuous) Incremental Update in environments where a Db2 Data Sharing group running on multiple z/OS LPARs is connected to one or more Accelerators over a private data network as illustrated in Figure 2, refer to chapter High-availability incremental update setup within a private data network. Such a setup is typically used for production environments where high-availability of components is important. The definition of an additional DVIPA (Dynamic Virtual IP address) is required for high-availability purposes of the CDC Capture Agent. Optionally an additional DDVIPA (Dynamic Distributed Virtual IP Address) can be set up to ensure a high-availability connection to the Db2 Data Sharing group from the Accelerator Server. Both, the DVIPA and DDVIPA must be part of the private data network.

If the Accelerator is integrated within a server farm as illustrated in Figure 3 and you want to use (Continuous) Incremental Update then refer to chapter Incremental update setup within a server farm.This chapter includes high-availability aspects and applies to test, development or production environments. For high-availability of the CDC Capture Agent an additional DVIPA is required.

Basic incremental update setup within a private data network

 

The following Figure 5 shows a basic (continuous) incremental update setup within a private data network. It consists of a z/OS LPAR running a Db2 subsystem and a CDC Capture Agent and has an Accelerator connected. This setup is typically used for test or development systems where high-availability of components is not required.

The private data network is setup as described in Figure 1, consisting of physical network components such as an OSA card and TCP/IP settings; in Figure 5 depicted by a cloud symbol.

Figure 5 Basic continuous incremental update setup

The CDC Capture Agent runs as a started task and listens on a TCP port for requests from the Access Server. The default port is 5999 and is configurable in a CDC configuration file.

The Access server requires this port number and an IP address to connect to the CDC Capture Agent and make it aware of what to replicate. The IP address is the private network IP address of the LPAR on which the CDC Capture Agent is running. In the private network example in Figure 1 it is the IP address 10.101.8.1. You specify both the port number and the IP address when you enable Incremental Update on the Accelerator Server for a Db2 subsystem.
The DDF started task listens on a TCP port for incoming client connections. The port number is configurable, the default being 446. For continuous incremental update the Accelerator Server establishes the connection to Db2 using the DDF port number and an IP address. The IP address is again the private network IP address of the LPAR. It is required that DDF is bound to any IP address (INADDR_ANY) in order that a connection to Db2 can be established using an IP address that belongs to the private data network. You specify both the DDF port number and the IP address when you enable Continuous Incremental Update on the Accelerator Server for a Db2 subsystem

Note that in Db2 Analytics Accelerator V7, continuous incremental update became the default and only option. When you enable that on the Accelerator Server you specify the CDC Capture Agent and DDF port number and IP address in a single step. In Db2 Analytics Accelerator V5 continuous incremental update is an option on top of incremental update. Therefore, you specify the DDF port number and IP address in a separate step.

Back to top

High-availability incremental update setup within a private data network

The following Figure 6 shows a high-availability (continuous) incremental update setup within a private data network. It consists of a Db2 Data Sharing group running on multiple z/OS LPARs that are connected to one or more Accelerators over a private data network. This setup is typically used for production environments where high-availability of components is important. The private data network is setup as described in Figure 2, consisting both of physical network components such as OSA cards and of TCP/IP settings; in Figure 6 this is depicted by a cloud symbol.

In such a setup it is recommended to set up a high availability (HA) environment for the CDC Capture Agent in that the CDC Capture Agent runs in active mode on one LPAR and in hot standby mode on other LPARs. If the active CDC Capture Agent goes down for any reason one of the hot standby capture agents takes over and becomes the active CDC Capture Agent.

Figure 6 High-availability setup for continuous incremental updates

The Access Server on the Accelerator must be able to communicate to the active CDC Capture Agent no matter on which LPAR it is running. This is achieved by setting up a dynamic virtual IP address (DVIPA) across all LPARs that should have an active or hot standby CDC Capture Agent running. The DVIPA is part of the private network between the LPARs and the Accelerator. The technote High Availability Setup for the Incremental Update Capture Engine describes how to set up high availability and the DVIPA for the CDC Capture Agent.

When you enable Incremental Update on the Accelerator Server for the Db2 Data Sharing group you specify the DVIPA and the TCP listening port (Default 5999) of the CDC Capture Agent.

For continuous incremental update the Accelerator Server must be able to establish a connection to the Db2 Data Sharing group via DDF using the DDF port number and an IP address within the private data network. The DVIPA configured for high-availability of the CDC Capture agent can be reused for this purpose. It is required that DDF is bound to any IP address (INADDR_ANY) in order that a connection to the Db2 Data Sharing group can be established using an IP address that belongs to the private data network. Additionally, it is required that DDF is started on all LPARs or Db2 Data Sharing group members that also either run an active or hot standby CDC Capture Agent. Since the DVIPA is bound to the LPAR running the active CDC Capture Agent, the Accelerator Server always connects to the Db2 Data Sharing group via the DDF started task that runs on the same LPAR as the active CDC Capture Agent. If the active CDC Capture Agent fails over to another LPAR then the DVIPA is bound to this new LPAR and the DDF started task on this LPAR is used for connecting to Db2 from the Accelerator Server. If it hasn’t been started initially the connection to the Db2 Data Sharing group will fail.

In the just described setup the DVIPA is used for two purposes. The original purpose is to act as a DVIPA for the CDC Capture Agent so that the Access Server can reach the active CDC Capture Agent no matter on which LPAR it is running. In addition, the DVIPA is reused for a second purpose; that is to act as the Db2 group IP address for client connections within the private data network for continuous incremental updates. Both purposes are incremental update and Accelerator related; however, organizations might have policies to define dedicated IP addresses for dedicated purposes. If this is the case in your organization then follow the description in this technote to establish a high-availability network setup for continuous incremental updates.

The described setup creates an additional distributed dynamic virtual IP address (DDVIPA) within the private data network that is used by client applications, such as the Accelerator Server, to connect to a Db2 Data Sharing group.

You specify both the DDF port number and the IP address (either the DVIPA or the DDVIPA) when you enable Continuous Incremental Update on the Accelerator Server for a Db2 subsystem.

Note that in Db2 Analytics Accelerator V7, continuous incremental update became the default and only option. When you enable that on the Accelerator Server you specify the CDC Capture Agent and DDF port number and IP address in a single step. In Db2 Analytics Accelerator V5 continuous incremental update is an option on top of incremental update. Therefore, you specify DDF port number and IP address in a separate step.

Back to top

Incremental update setup within a server farm

It is possible to integrate the Accelerator into the same network and subnet as other distributed servers (typically called a server farm) as already shown in Figure 3 in chapter Accelerator network setup within a server farm.

In test or development environments where high-availability of components is not important, no additional TCP/IP settings for (continuous) incremental updates are required. The Access Server can access the CDC Capture Agent using the defined IP address of the LPAR within the OSA Transfer Network. The Accelerator Server can connect to Db2 using the IP address that is used by all Db2 client applications in your organization. A DDF bind to any IP address (IPADDR_ANY) might not be required.

In production environments a high-availability setup for the CDC capture agent requires the definition of a DVIPA address that is part of the OSA transfer network. The Access server uses this DVIPA to connect to the CDC Capture Agent. The Accelerator Server connects to the Db2 Data Sharing group using a DDVIPA address that is already setup and already used by all Db2 client applications in your organization.

Back to top