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.