Sysplex problem detection and recovery

Each sysplex member monitors itself and can automatically leave the sysplex group if it determines that it is no longer able to function correctly as a router, target, backup, or owner of a DVIPA. Through a variety of methods, it monitors:

  • Internal resources and conditions, such as timely execution of sysplex functions, available private storage, and common storage
  • External resources, such as availability of VTAM®, or OMPROUTE if it is being used, or IPsec infrastructure (such as IKED) if IPsec is being used.

As long as the TCP/IP stack is a member of a TCP/IP sysplex group, the sysplex monitor gets control periodically. The time period is determined from the TIMERSECS value specified on the SYSPLEXMONITOR parameter of the GLOBALCONFIG statement in PROFILE.TCPIP. The default TIMERSECS value is 60 seconds.

After a problem is detected, further actions depend on whether RECOVERY or NORECOVERY was specified on the SYSPLEXMONITOR parameter of the GLOBALCONFIG statement. NORECOVERY is the default value.

Joining the TCP/IP sysplex group can be delayed until certain network routing and connectivity availability conditions are met. Those conditions can include any combination of the following conditions:

  • OMPROUTE is active
  • Monitored interfaces are active
  • Dynamic routes over those monitored interfaces are present
  • IPsec components are active and operational

The first condition is activated using the DELAYJOIN option on the SYSPLEXMONITOR parameter of the GLOBALCONFIG statement. The next two conditions are activated using the MONINTERFACE or MONINTERFACE DYNROUTE option on the SYSPLEXMONITOR parameter of the GLOBALCONFIG statement. The last condition is activated by the DELAYJOINIPSEC option on the SYSPLEXMONITOR parameter on the GLOBALCONFIG statement. No sysplex-related definitions within the TCP/IP profile (that is, VIPADYNAMIC and DYNAMICXCF statements) are processed until the sysplex group is joined.

Tips:
  • To determine whether the stack has joined a sysplex group, issue the DISPLAY TCPIP,,SYSPLEX,GROUP command.
  • If you have procedures specified on the AUTOLOG profile statement that bind to a dynamic VIPA, specify the optional DELAYSTART parameter with the optional DVIPA subparameter for these procedures on the AUTOLOG statement. With the DELAYSTART DVIPA subparameter, the procedures will not start until the TCP/IP stack has joined the sysplex group and has processed the dynamic VIPA configuration.
During a planned or unplanned outage, the DVIPAs and distributed DVIPAs for a TCP/IP stack are taken over by backup TCP/IP stacks. When the primary TCP/IP stack is restarted, the DVIPAs and distributed DVIPAs are taken back from the backup TCP/IP stacks.
  • If dynamic routing is used to advertise routes to these DVIPAs, and specified network routing and connectivity availability conditions are not met on the primary TCP/IP stack, existing connections to these DVIPAs might be reset and new connect requests to these DVIPAs might fail. By using the GLOBALCONFIG SYSPLEXMONITOR DELAYJOIN and MONINTERFACE DYNROUTE configuration statements in the TCP/IP profile on the primary TCP/IP stack, it is possible to delay taking back the DVIPAs and distributed DVIPAs until specified network routing and connectivity availability conditions are met. New and existing connections continue to be serviced by the backup TCP/IP stacks until OMPROUTE is active and monitored interfaces and dynamic routes over those monitored interfaces are present on the primary TCP/IP stack.
  • When IPsec infrastructure is needed to establish IPsec protection for traffic using these DVIPAs, and all the necessary IPsec components are not yet operational on the primary TCP/IP stack, existing connections to these DVIPAs might be reset and new connect requests to these DVIPAs might fail. By using the GLOBALCONFIG SYSPLEXMONITOR DELAYJOINIPSEC configuration statement in the TCP/IP profile on the primary TCP/IP stack, it is possible to delay taking back the DVIPAs and distributed DVIPAs until the IPsec infrastructure is operational. New and existing connections continue to be serviced by the backup TCP/IP stacks until the IPsec infrastructure is operational on the primary TCP/IP stack.

For more information about the GLOBALCONFIG statement and its parameters, see z/OS Communications Server: IP Configuration Reference.