In some environments, having a Linux on IBM Z LPAR colocated with the z/TPF LPAR running in the same processor is ideal. This type of environment is important when the z/TPF LPAR needs low-latency access to features and functions on a Linux on IBM Z system. A colocated Linux on IBM Z system also means the traffic never leaves the processor, eliminating the possibility of networking problems and increasing the security of the connection as the data is never exposed externally. This article takes you through the steps needed to set up connectivity so that a z/TPF system can send requests to a Linux on IBM Z LPAR by using shared OSA-Express connections.
As shown in Figure 1, both the z/TPF and Linux on IBM Z LPARs have external connectivity to the network through multiple OSA cards by using a virtual IP address (VIPA). The z/TPF system and Linux on IBM Z system both have their own OSA-Express cards connected to their own local network. In this environment, for the z/TPF LPAR to communicate with the Linux on IBM Z LPAR, the traffic must be sent through the external interface, leaving the IBM Z processor to reach the destination. The question becomes, in a z/TPF environment, what is the optimal way to set up the connectivity to capitalize on the colocation of a Linux on IBM Z LPAR that runs in the same IBM Z processor.
Let’s assume you wanted to start utilizing IBM Integrated Accelerator for AI on the Linux on IBM Z partition within the IBM z16 processor for something like fraud detection. As a user, you deploy your fraud detection models within the Linux on IBM Z system and the z/TPF system makes requests to the Linux on IBM Z system to make decisions based on the transaction that is processed. Let’s also assume that the protocol used to send the data to the Linux on IBM Z system is API based and therefore you use the z/TPF REST consumer to send requests.
Setting up shared OSA connectivity
The first step in setting up the connectivity for a colocated Linux on IBM Z system is to set up the OSA connectivity between the z/TPF and the Linux on IBM Z LPARs. The z/TPF LPAR and the Linux on IBM Z LPAR share the same OSA cards to ensure there is a path between them without leaving the IBM Z system. You might decide to use your existing external OSA cards for these connections, or you might choose to use a separate set of OSA cards for the internal traffic. Figure 2 shows an example where two new OSA-Express cards were used, and OSA-Express connections were established from the z/TPF system and Linux on IBM Z system to each of them. There are two OSA-Express cards for redundancy in the event that one of the OSA cards fails. The defined z/TPF IP address must be in the same network as the defined IP address on the Linux on IBM Z OSA-Express connection to the same card. Use the ZOSAE command to define OSA-Express connections on the z/TPF system.
Add IP routing table statements
With connectivity set up between the z/TPF and Linux on IBM Z LPARs, you need to direct the z/TPF outbound traffic through these internal connections rather than the existing external connections. To do this, set up IP routing table statements to indicate that when data is sent to a specific remote IP address, the z/TPF client application will send the data across a specific interface by binding to that interface IP address. For example, the following IP routing table statements are based on Figure 2
ZTRTE ADD RIP-233.252.0.5 LIP-233.252.0.4
ZTRTE ADD RIP-192.0.2.5 LIP-192.0.2.4
These z/TPF routing table statements specify to reach remote IP address 233.252.0.5 (Linux on IBM Z), send through local IP address 233.252.0.4. Similarly, to reach remote IP address 192.0.2.5 (Linux on IBM Z), send through local IP address 192.0.2.4. For more information about adding IP routing table entries, see the IP routing table and the ZTRTE command.
Add high-speed connector HTTP client persistent sessions
Now that you have connectivity between the z/TPF system and Linux on IBM Z, you can establish protocol layer connectivity to the Linux on IBM Z system. Because this is an API-based communication method through REST, you can create a high-speed connector group to establish connections through both internal OSA cards to the Linux on IBM Z partition. This approach ensures redundancy because if one OSA card fails, the system still has access to Linux on IBM Z through the other OSA card. From a z/TPF perspective, define your endpoint group descriptor to have two endpoints. One endpoint points to the Linux on IBM Z IP address 232.252.0.5, and the other endpoint points to the Linux on IBM Z IP address 192.0.2.5. These can both be defined as PRIMARY endpoints; this way they are both used until one of the links is unavailable or fails. Figure 3 shows an example of a high-speed connector endpoint descriptor file for the configuration depicted in Figure 2. This is a non-TLS group with each endpoint starting 5 sockets with a maximum of up to 10 sockets.
With this configuration, your REST consumer can be set up to target this high-speed connector group. The z/TPF system controls which path is selected to the Linux on IBM Z system as well as all error and retry conditions. For more information, see the High-speed connector.
Full redundancy with multiple Linux on IBM Z partitions
More than one instance of Linux on IBM Z can be running in the processor as well to ensure full redundancy across OSA cards and Linux on IBM Z endpoints. Figure 4 highlights another configuration that can be used where there are two OSA cards connected to two separate instances of Linux on IBM Z. The Linux on IBM Z instances are normally managed by a hypervisor. From a z/TPF perspective, the OSA-Express definitions and set up are identical. Additional IP routing statements are needed for the additional interfaces (IP addresses) on the Linux on IBM Z LPAR. Then additional endpoints can be added to the endpoint group descriptor file for new Linux on IBM Z interfaces (IP addresses). This configuration provides additional resiliency in the event a Linux on IBM Z instance or an OSA-Express connection were to fail.
Setting up the connectivity between the z/TPF system and a colocated Linux on IBM Z system is simple and easy. This type of environment reduces the network latency because the data is transferred between LPARs through shared memory. The network latency is reduced to microseconds and the resiliency is improved by bypassing the external network. The security is also improved because the traffic remains internal to the IBM Z processor; the need for encrypting the data is eliminated. Now, you can investigate how your z/TPF system can use a colocated Linux on IBM Z partition to exploit features and functions that are available on the Linux on IBM Z system.