Multiple application-instance DVIPA is conceptually the same as unique application instance DVIPA. The difference is in the layer at which the DVIPA is associated. With multiple application-instance DVIPA, the VIPA address is activated by and associated with the entire TCP/IP stack. The DVIPA address is activated at TCP/IP stack initialization and remains associated with the stack for as long as the stack is functioning correctly.

The idea is communicated best graphically. In Figure 1, LPAR 1 and LPAR 2 have been altered to support multiple application-instance DVIPA.

In this figure, LPAR 1 is configured to be the stack where the DVIPA address is expected to be normally active. In other words, if both LPARs are active in the sysplex, LPAR 1 owns the IP address 10.134.61.190. The address is always active and is unaffected by the presence, or lack of presence, of any particular applications.

In the event of a loss of the TCP/IP stack (for example, an abnormal termination or a manual shutdown of the task), the TCP/IP stack configured in LPAR 2 automatically activates the 10.134.61.190 DVIPA.

Taking a closer look at the VIPABACKUP statements, there are the numbers 50 and 25 as the second parameter on LPARs 2 and 3. This is the backup host's rank. There can be more than one backup host for multiple application instance DVIPA. This rank can be used to control which backup TCP/IP stack should be activated first after the primary stack loses the address. The higher this number, the greater its priority for being used as a backup.

If a backup stack should fail, then the backup stack with the highest rank number would activate the DVIPA. In Figure 1, LPAR 2 is the first host to take over LPAR 1's DVIPA. If both LPAR 1 and LPAR 2 should fail, then LPAR 3 would take over 10.134.61.190.

Figure 1. Multiple application-instance DVIPA

Implicit in unique application-instance DVIPA is the requirement that an operator (or a system automation product) be available to start the new application on the alternate LPAR when the original LPAR, TCP/IP stack, or application fails. This is not the case with multiple application-instance DVIPA.

With multiple application-instance DVIPA, if the LPAR or TCP/IP stack fails, the IP address is automatically started on one of the backup LPARs. The application could already have been running on both the primary and backup systems. Presumably the application has not used a bind() to a specific address. When TCP/IP automatically activates the multiple application-instance DVIPA on the backup host, the application is automatically available at this newly activated address.