Network interfaces monitoring

Sysplex distributor and other dynamic VIPA (DVIPA) functions depend on an available network path to the TCP/IP stack that owns and advertises a dynamic VIPA. If connectivity is disrupted, clients might not be able to access the applications represented by the DVIPA, impacting their operations. Dynamic XCF interfaces can be configured to provide for a backup network path for DVIPAs. If the dynamic XCF interfaces fail for a given system, the sysplex autonomics function might automatically initiate a recovery action, resulting in the local TCP/IP stack leaving the sysplex and enabling other TCP/IP stacks to assume ownership of the DVIPAs.

However, there are some configurations in which it is not optimal to configure dynamic XCF interfaces as eligible backup network paths for TCP/IP stacks that own and advertise DVIPAs. In these configurations, incoming network traffic for the DVIPAs is expected to arrive over one or more external network interfaces. If these external interfaces fail, or the networks they are attached to experience a failure, the DVIPAs owned by the local TCP/IP stack can become isolated. Client traffic destined for these DVIPAs cannot reach the local TCP/IP stack; the DVIPA is unreachable.

The network interfaces monitoring function enhances the sysplex autonomics function by enabling you to specify key network interfaces that should be monitored by TCP/IP stacks. If a failure occurs on all specified interfaces, sysplex autonomics recovery can be triggered so other TCP/IP stacks in the sysplex can take over responsibilities for the DVIPAs owned by the local stack.

This level of monitoring is useful not only for TCP/IP stacks that currently own and advertise distributed and non-distributed DVIPAs, but also for TCP/IP stacks that are eligible backup stacks for these DVIPAs. This can help ensure that any backup TCP/IP stacks that are experiencing network connectivity problems do not attempt to perform DVIPA takeover activities if the primary DVIPA owner is stopped or fails. By being proactive and detecting these network connectivity problems, the backup stack can remove itself from the sysplex, enabling other healthy backup stacks to perform the takeover activities. While this monitoring function can also be enabled on TCP/IP stacks that act only as targets for distributed DVIPAs, the benefits for this configuration are minimal, as sysplex distributor already automatically monitors the ability of target TCP/IP stacks to communicate with distributed DVIPA clients.

The following functions are provided by the network interfaces monitoring function:

• You can identify which links and interfaces are critical for inbound network connectivity for a distributed DVIPA or DVIPA-owning TCP/IP stack. Specify which links and interfaces are to be monitored by sysplex autonomics using the MONSYSPLEX parameter on the LINK and INTERFACE statements.
• You have the option of enabling the TCP/IP stack to monitor the status of these interfaces through the MONINTERFACE keyword on the GLOBALCONFIG SYSPLEXMONITOR statement. If the MONINTERFACE keyword is specified, by default the TCP/IP stack also monitors the presence of dynamic routes over these interfaces. To override monitoring of dynamic routes, specify the MONINTERFACE NODYNROUTE keyword on the GLOBALCONFIG SYSPLEXMONITOR statement. The monitoring of dynamic routes enables TCP/IP to extend its monitoring beyond the status of the actual network interface, to also include the status of any routers that are connected to the local area network to which these interfaces are attached. Because a dynamic routing protocol is usually required for DVIPAs, by checking for the presence of dynamic routes, TCP/IP can determine whether the local OMPROUTE daemon is successfully communicating with these routers using dynamic routing protocols. If these network interfaces and dynamic routes become unavailable or experience network connectivity failures, the sysplex autonomics function can automatically initiate a recovery action.

If network interfaces monitoring is enabled, you must be aware of the following scenarios where the monitoring function can create problems:

• Monitored interfaces are deleted

  To delete interfaces, the devices or interfaces must first be stopped. When the devices or interfaces are stopped, the interface becomes inactive. If the TCP/IP stack detects that all monitored interfaces are inactive as a result of stopping devices or interfaces, the TCP/IP stack can issue messages regarding the problem and possibly trigger a recovery action. You can disable monitoring of these interfaces before stopping the devices or interfaces, using the VARY TCPIP,,OBEYFILE command and specifying the NOMONSYSPLEX keyword for the LINK or INTERFACE statement. For more information about DEVICE and LINK statements and INTERFACE statements, see z/OS Communications Server: IP Configuration Reference.

• The first hop routers are brought down for maintenance

  If the MONINTERFACE keyword or MONINTERFACE DYNROUTE option is configured on the SYSPLEXMONITOR parameter of the GLOBALCONFIG statement, and the first hop routers are brought down for maintenance, an inadvertent recovery action might be triggered. You can temporarily disable the monitoring of dynamic routes using the VARY TCPIP,,OBEYFILE command and specifying MONINTERFACE NODYNROUTE on the SYSPLEXMONITOR parameter of the GLOBALCONFIG statement.

• Preferred routing interface is not monitored

  If you use multiple interfaces and at least one interface is preferred from a routing perspective over the other interfaces, ensure that the preferred interfaces are monitored (the MONSYSPLEX keyword is specified for the LINK or INTERFACE statement). If the preferred interfaces are not monitored, an inadvertent recovery action might be initiated.

For more information about sysplex autonomics, see Sysplex problem detection and recovery.