Applications and dynamic VIPAs

While most applications support multiple instances in a sysplex, very few applications expect IP addresses to move around under them. TCP applications use TCP connections to form a relationship between particular client and server instances to exchange data over an extended period. They rely on notification of TCP connection termination to initiate recovery and to reestablish a new relationship (possibly from a client to a different server). Conversely, most UDP applications do the equivalent function at the application layer. Movement of an IP address to a different server could be confusing to the client, unless the new server also is aware of the state of the client work.

UDP applications whose interactions consist of atomic interactions (a single request followed by one or more responses, with no state information maintained at the server between requests) can use dynamic VIPAs in the multiple application-instance scenario. However, if the server application maintains state information between interactions (for example, NFS), then moving a dynamic VIPA to another server might not work unless the client/server application protocol can detect the discontinuity. In that case, the unique application-instance scenario might apply, which would require the restart of the server instance on another TCP/IP.

In addition, the following types of work are not appropriate for distribution with distributed dynamic VIPA:
  • Applications that establish affinity with a particular TCP/IP stack, such as SNMP.
  • FTP servers that receive the PASV or EPSV command for a distributed DVIPA that did not specify SYSPLEXPORTS. The PASV and EPSV commands are supported when SYSPLEXPORTS was specified on the VIPADISTRIBUTE statement of the distributed DVIPA that is the destination IP address being used by the FTP server. These commands request that the FTP server bind() on a data port that is not the default data port, or the one specified on the VIPADISTRIBUTE statement, and to wait for a connection rather than initiate one on receipt of a transfer command (for example, RETR). Because SYSPLEXPORTS cannot be specified for a non-distributed dynamic VIPA, passive mode FTP connections made to a non-distributed dynamic VIPA cannot be recovered when the VIPA is moved through a planned takeover. The control connection remains on the original stack, but attempts to create new data connections for control connections that existed prior to the move will fail. When SYSPLEXPORTS is used with a distributed dynamic VIPA, new data connections are always sent to the same stack containing their control connection. For more information on using the SYSPLEXPORTS parameter in the VIPADYNAMIC block, see z/OS Communications Server: IP Configuration Reference.
  • FTP servers that accept connections on an IPv6 distributed DVIPA that does not have SYSPLEXPORTS specified. The FTP server expects an EPSV command for data transfers to or from an IPv6 address, and use of the EPSV command is supported only when SYSPLEXPORTS was specified on the VIPADISTRIBUTE statement of the distributed DVIPA that is the destination IP address being used by the FTP server.