Distributed Dynamic VIPA
Distributed DVIPA (Dynamic Virtual IP Addressing) allows you to concurrently run identical z/OS® Explorer setups on different systems in your sysplex, and have TCP/IP, optionally with the help of WLM, distribute the client connections among these systems.
- RSE daemon owns the port that is defined for distributed DVIPA,
but the actual work happens in the RSE server, which is active as
a thread in another address space. Therefore, you cannot use the
SERVERWLM
distribution method to do load balancing across your systems, because WLM will give advice based on statistics for RSE daemon, not RSE server. - When using a sysplex with an even number of systems, you should
not use
ROUNDROBIN
as distribution method to do load balancing across your systems, unless you enable encrypted communication.z/OS Explorer clients first attempt to use encryption while setting up communication, and try again without encryption if this fails. This behavior for non-encrypted communication combined with
ROUNDROBIN
on a sysplex with an even number of systems will result in all uneven numbered systems (first, third, ...) being skipped, and all connections will go to the even numbered systems (second, fourth, ...). - The client only knows the DVIPA address used by the Sysplex Distributor
for RSE daemon. The Sysplex Distributor will pass the connection request
to one of the available RSE daemons, which in turn will start an RSE
server thread that will bind to a port on that system. When the client
connects to this port, it will use the DVIPA address again, not the
actual system address, so you must ensure that the Sysplex Distributor
redirects the new connection to the correct system.
Therefore, z/OS Explorer requires the definition of
SYSPLEXPORTS
in theVIPADISTRIBUTE
statement to ensure that the ports used by the RSE server threads are unique within the sysplex.Note:- The usage of
SYSPLEXPORTS
implies that theEZBEPORT
structure must be defined in your coupling facility. - The usage of
SYSPLEXPORTS
implies that TCP/IP will select an ephemeral port for the secondary connection. This implies that you cannot reserve ports for these connections in your TCP/IP profile with thePORT
andPORTRANGE
directives. You also cannot use_RSE_PORTRANGE
inrse.env
to limit the ports used by z/OS Explorer. z/OS Explorer does provide a workaround for this restriction, because this complicates firewall setup.
- The usage of
- The
enable.dDVIPA
directive inrse.env
must be enabled. - To ensure that the z/OS Explorer client
will not interfere with the correct port selection by TCP/IP, you
should enable the
deny.nonzero.port
directive inrse.env
. - All participating z/OS Explorer servers
must have an identical setup. You should share
/usr/lpp/IBM/zexpl
and/etc/zexpl
among all participating systems. You should also share/var/zexpl/pushtoclient
, if these directories are used. Note that/var/zexpl/WORKAREA
and/var/zexpl/logs
must be unique for each system. - See Running multiple instances to learn which z/OS Explorer components must be shared, and which ones must be unique per system.
JES Job Monitor and other z/OS Explorer servers only interact with the local RSE, and thus do not require a DVIPA setup.
Distributed DVIPAs are defined by the VIPADEFine
and VIPABackup
keywords
of the VIPADynamic
block in your TCP/IP profile.
The VIPADISTribute
keyword adds the required Sysplex
Distributor definitions. Distributed DVIPA requires that all participating
stacks are sysplex-aware, which is done via the SYSPLEXRouting
and DYNAMICXCF
keywords
of the IPCONFIG
block in your TCP/IP profile. See Communications
Server: IP Configuration Reference (SC31-8776) for more details
on these directives.
See MVS Setting Up a Sysplex (SA22-7625)
and Communication Server: SNA Network Implementation Guide (SC31-8777)
for more information about setting up the EZBEPORTS
structure
in your coupling facility.