Overview of VIPA solutions
You can implement VIPA, where you give your application its own IP address, across multiple TCPIP images. This solves the problem of certificates not matching the host IP address.
- One TCPIP image processes the connection requests. You have multiple TCPIP images – but only one TCPIP image at a time processes the connections. If the TCPIP image stops, another can take over.
- Multiple TCPIP stacks can process connection requests. This uses Sysplex Distributor; a front end TCPIP image takes the connection requests and distributes them to TCPIP instances where the application is running. You can use load balancing such as Round Robin, or Hot Standby.
This blog post discusses the first case.
To provide background information, I created
- How it works – TCPIP (Background knowledge needed to understand how to configure a VIPA)
- HA Liberty web server – introduction to using VIPA to provide high availability connectivity.
- How do I find out about my VIPA configuration?
Using VIPARANGE configuration
The technique uses the VIPARANGE configuration statement.
The concept is that many LPARs can be attached to an OSA adapter, one, just one, TCPIP stack (I dont know which of the available images) takes the connection requests and passes them on to the application on that TCPIP image.
You allocate a range of TCPIP address for your applications, with the same network prefix, for example 9.4.6.x Allocate a host id to a Liberty, for example 184.108.40.206. The Liberty instance keeps this address for whereever it runs. You configure your routers so that 9.4.5.* are routed to the OSA adapter.
For each TCPIP image where you want to run Liberty, add to the TCPIP startup configuration (or to an OBEY file)
VIPADYNAMIC VIPARANGE DEFINE 255.255.255.0 220.127.116.11 ENDVIPADYNAMIC
The 255.255.255.0 is the subnet mask. If your organisation uses a different subnet mask, it affects the IP addresses used.
These instructions say that they are defining a range of IP addresses on this LPAR, for 18.104.22.168 to 22.214.171.124
If an application connects to TCPIP, and the bind specifies a value in this range (126.96.36.199 to 188.8.131.52) then it is considered a VIPA address. If the application used 184.108.40.206 this would count as a VIPA address.
When your application (Liberty) connects to TCP and uses an address in the VIPARANGE, the TCPIP instance will create a dynamic IP address. When I started my server application, I got a z/OS console message
EZD1205I DYNAMIC VIPA 220.127.116.11 WAS CREATED USING BIND BY jobname ON TCPIP2.
When I shut down the server I got
EZD1298I DYNAMIC VIPA 18.104.22.168 DELETED FROM TCPIP2
EZD1207I DYNAMIC VIPA 22.214.171.124 WAS DELETED USING CLOSE API BY jobname ON TCPIP2
If the VIPA address is active on more than one TCPIP image, just one image will get all of the requests. If you stop this image, another TCPIP image can take over.
If you have a different server using the same IP address, but a different port number, because they use the same IP address, the same LPAR will process the requests.
With VIPAROUTE you do not get connections distributed to more than one TCPIP image.
In your browser use 126.96.36.199:9443 address, the network router, routes this to the OSA, a TCPIP captures this and passes it to the application (Liberty). As part of the handshake Liberty sends down its certificate, which has a SAN of 188.8.131.52 which matches the IP address, so this works.
On another day, when a different z/OS image is capturing the VIPA address connections, the TCPIP address is 184.108.40.206 as before, so this matches the SAN in the certificate.
In a test I used “ping -R 220.127.116.11 ” to the VIPA address.
This reported it was sent to TCPIP stack with 10.1.1.2. When I shut this TCPIP image down, ping reported the request was sent to 10.1.1.3. It did this with no manual intervention.