Unique application-instance DVIPA

When an application explicitly issues a bind() function call to the IP address, the dynamic VIPA is called a unique application-instance DVIPA.

When an IP application intends to listen, or if an application intends to connect using a specific port or IP address, it must issue a bind() function call. The bind() function call can perform two services:

Associate a socket with a specific IP address
Associate a socket with a specific port number

Reminder: A socket is defined as a four-tuple consisting of:

A local IP address and local port number
A remote IP address and remote port number

For our purposes, we focus only on how a bind() can be used by an application to associate a socket with a specific IP address. An outline of this process is illustrated in Figure 1.

Figure 1. Single application instance DVIPA creation

The process begins with an application requesting the usage of a specific IP address. For example, one of the HTTP servers that runs on z/OS has a parameter in its /etc/httpd.conf file to force the server to use a specific IP address. When the HTTP server requests this IP address, the TCP/IP stack first checks to see if the address is already active.

This address might already be active because of one of the following reasons:

It has been defined by a static definition.
It has been dynamically created by another application.
It has been dynamically created by the TCP/IP stack (multiple application-instance DVIPA).

If the address is already active, the bind is processed with no exceptional processing required.

If the address does not exist, the TCP/IP stack next checks to see if this address is eligible for dynamic activation. If not, the bind is denied.

If the IP address is eligible for activation, then the TCP/IP stack dynamically generates the address. The application successfully binds to the IP address as though the address had always been there.

Note: Some applications issue bind() function calls without specifying any IP address at all. If desired, TCP/IP can be configured using the PORT statement with the BIND ip_address keyword to override such a bind. TCP/IP substitutes the specified ip_address and the application instance DVIPA processing as described in Figure 1 applies.

How DVIPA is enabled on a TCP/IP stack

So what is it that makes an IP address eligible for dynamic activation? The creation of a static VIPA address requires a DEVICE, LINK, and HOME statement. This is not the case for a DVIPA. To illustrate, let's work our way through a set of statements for a simple DVIPA scenario, as shown in Figure 2.

Figure 2. TCP/IP profile statements for DVIPA

 VIPADYNAMIC
        VIPARANGE DEFINE MOVEABLE NONDISRUPTIVE 255.255.255.192 201.2.10.192
 ENDVIPADYNAMIC

All of the DVIPA-related statements are encompassed by a beginning (VIPADYNAMIC) and ending (ENDVIPADYNAMIC) statement. The VIPARANGE statement is exactly what its name implies: it defines a range of IP addresses that are eligible to be dynamically activated. In Figure 2, the range is for IP addresses within the 201.2.10.192 network ID, using a mask of 255.255.255.192.

Tying this back to our HTTP server bind request from Figure 1, you can see that the HTTP server has been configured to request 201.2.10.193. Since this IP address is within our VIPARANGE defined subnetwork, the bind() request results in a new IP address for a DVIPA being activated.

Moving the DVIPA

The VIPARANGE statement has further options to modify its behavior in a context where other applications within a sysplex are also issuing bind() function calls. In our above example, how should this IP address behave if another TCP/IP stack in the same sysplex (with the same VIPARANGE statement in its TCP/IP profile) issues a bind(201.2.10.193)?

By default, a VIPARANGE statement specifies that if another TCP/IP stack requests an activation of the same address, the movement is done in a non-disruptive fashion. This means that existing sockets using this IP address would be maintained. However, any new connection attempts to this address is directed to the TCP/IP stack that has most recently activated the VIPA address. After all sockets using the original TCP/IP stack have been closed, the VIPA address no longer exists on the original image.

Note: As the name implies, a unique application-instance DVIPA functions best when the DVIPA is activated by a single instance of an application.

The circle can be completed if the original application were to be restarted, causing it to issue a new bind to 201.2.10.193. The DVIPA would be moved back to the original stack in the same non-disruptive fashion.

Figure 3 shows a system able to continue HTTP processing if an HTTP server fails or needs servicing or maintenance. In LPAR 1, the HTTP server is bound to a dynamic VIPA address. In the event of a failure or a need to do service or maintenance on LPAR 1, there is an identically-configured HTTP server waiting to be started on LPAR 2.

Figure 3. Unique application-instance DVIPA scenario

There are many automation packages, such as Tivoli NetView for z/OS and System Automation for z/OS, that can start another server automatically when a current server has failed or ended. So the system can automatically initialize a new HTTP server on LPAR 2 if the HTTP server on LPAR 1 ends. In turn, the act of starting the HTTP server on LPAR 2 is enough to initiate a non-disruptive movement of the IP address.