Network

Edit online
An SAP high availability solution requires a fault tolerant network. Therefore, to protect against network failures, all network components need to be duplicated. IBM® platforms (z/OS®, Linux® on IBM Z, and AIX®) support an elegant method for identifying the location of hosts and applications in a network: It is done by means of virtual IP addresses (VIPA).

Static VIPAs are used to locate a host, while dynamic VIPAs are used to locate an application. Note that an application can be moved between hosts and can activate a dynamic VIPA on the host on which it is running.

Furthermore, for a fault-tolerant network, it is recommended to define a VIPA together with the SOURCEVIPA option for every participating system.

The OSPF (Open Shortest Path First) routing protocol ensures that failures of any network component (network adapter cards, routers or switches, cables) are detected instantaneously and an alternative route is selected. This automatic rerouting is accomplished by the TCP/IP layer and is transparent to the application. TCP/IP connections are not disrupted.

Figure 1 shows the general concept of a fault-tolerant network with duplicated network components and VIPA.
Figure 1. General concept of a fault-tolerant network with dynamic routing and four subnets
Graphic shows how a fault-tolerant network with dynamic routing and four subnets works

This fault-tolerant network concept is applicable to the connection between a remote SAP application server and the SCS as well as to that between a remote SAP application server and the Db2® on z/OS database server. See Network characteristics for high availability for details on how to set up a highly available network like shown in Figure 1.

The following figures show how dynamic rerouting works. In Figure 2, the virtual IP address virt_addr_1 on z/OS system A can be reached through IP addresses addr_1 and addr_2. These real addresses are seen as gateways to the virtual IP address. ENQ and MSG indicate two applications running on that system. You can imagine that these are the SAP enqueue server and the message server. Connections coming from application server instances choose addr_1 or addr_2 as gateway to z/OS system A.

Figure 2. Alternative paths in a duplicated network
Graphic shows alternative paths in a duplicated network
Figure 3. Rerouting if a network adapter card fails
Graphic shows rerouting if a network adapter card fails

What happens if network adapter card addr_1 fails? As shown in Figure 3 there is still a path from application server instances to z/OS system A. All TCP/IP traffic is now routed through addr_2. The rerouting is absolutely transparent to the application. The router daemons on each system detect the missing links and propagate alternative routes. On z/OS, the router daemon is OMPROUTE.

What happens in case of a TCP/IP or LPAR failure? The automation software is able to detect such an failure, move virt_addr_1 to z/OS system B, and restart the applications there. The takeover of the ENQ and MSG server together with the virtual IP address is shown in Figure 4. Now addr_4, addr_5 and addr_6 are propagated as gateways to virt_addr_1. The IP takeover to another system disrupts existing connections. Application server instances have to reconnect and resynchronize their communication.

Defining DISRUPTIVE VIPAs in z/OS ensures that the VIPA is really moved, that is, that it is certain to be deleted on z/OS system A, and that any connections to applications on z/OS system A using this VIPA are disrupted.
Figure 4. VIPA takeover and dynamic routing
VIPA takeover and dynamic routing

In the scenario described in this book, the connections between Linux (hosting an application server) and z/OS (hosting the primary database server for this application server) take advantage of HiperSockets. The connection through the HiperSockets does not need any physical network adapter cards, routers, switches, or cables and therefore is an absolutely reliable connection. For a HiperSockets "only" configuration, a VIPA definition on the Linux system is not needed with respect to the database connection though it could be useful for incoming connections from the LAN. But in an HA environment, which comprises at least a second IBM Z CEC, LAN connections to that second CEC are necessary for a DB or SAP Central Services failover. So in an HA environment always uses VIPA also on Linux.

Static VIPAs are used for components that are not moved between systems, like DB2® DDF address spaces or SAP application server instances.

Dynamic VIPAs need to be defined for movable components, namely a dynamic VIPA is defined for each of the following resources:

  • NFS server
  • ABAP and Java™ SCS
  • ERS of ABAP SCS
  • ERS of Java SCS
  • SAP network interface router (SAProuter)

While the rerouting shown in Figure 2 through Figure 3 is applicable to both static and dynamic VIPAs, the takeover shown in Figure 4 applies to dynamic VIPAs only.

As previously noted, the concept of a fault-tolerant network relates to the connection between
  • Remote SAP application servers and SCS
  • Remote SAP application servers and the Db2 on z/OS database server.
It is not necessary to introduce dynamic routing on SAP presentation servers (systems running the SAP GUI interface) in order to get to the message server via the VIPA of SCS. Such a connection to the message server is established at group logon time for example. You define a subnet route to the SCS VIPA via the normal SAP application server subnet that the presentation server uses to access the SAP application server itself. When IP forwarding on the SAP application servers is enabled, OSPF will automatically route correctly from the SAP application server to the VIPA of the SCS and back.