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.
You can have
- One TCPIP image processing 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. 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 across multiple TCPIP images such distributing the connection techniques such as Round Robin, or Hot Standby. This is based on Sysplex Distributor technology.
This blog post discusses the second 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?
Sysplex Distributor background
Sysplex Distributor is like having a router inside your TCPIP on z/OS; it can route traffic transparently to other TCP images in the environment. The Sysplex Distributor can distribute connection requests for a VIPA requests to TCPIP images where the application is running. This set up is called Distributed VIPA (DVIPA).
It took me about 2 weeks to get a Sysplex DVIPA working – about a week understanding the documentation on VIPA, and the other week trying to understand why it didn’t work – and the simple configuration error I had.
I’ll break it down into simple stages which should help you understand the documentation.
The scenario I used was going from my laptop, to z/OS running under zPDT on my laptop. In effect there was an OSA connection between Ubuntu and my z/OS LPAR. If you do not know what an OSA is, think of it as an Ethernet connection which can plug into multiple z/OS LPARs.
- My Ubuntu had an address of 10.1.1.1 over the tunnel connection
- I had one LPAR with three TCPIP images
- TCPIP, host address 10.1.1.1 for the primary “front end”
- TCPIP2, host address 10.1.1.2 for the backup “front end” and where a server instance was running
- TCPIP3, host address 10.1.1.3 with a server instance running.
- I used a VIPA address of 10.1.3.10
The steps are
- Connect from Ubuntu to the z/OS
- Configure the LPAR(s)
- Define the VIPA configuration
- Define the “routing” to where the server was running.
- Getting the server to use the VIPA
- Commands to see what is going on (or not as the case may be)
Connect from Ubuntu to the z/OS
I had an existing tunnel connection from Ubuntu to z/OS.
I used the ip route command
sudo ip r add 10.1.3.10 link tap0
to define the route to 10.1.3.10 via the tunnelling device tap0 . This looks like an OSA connection into z/OS.
Configure the LPAR(s)
The Sysplex Router uses XCF communications between LPARs and TCPIP images on the LPARs.
You configure each TCPIP with a statement
IFCONFIG DYNAMICXCF 172.1.2.x
My “frontend” TCP/IP had IFCONFIG DYNAMICXCF 188.8.131.52, the other two TCP/IP images had 184.108.40.206 and 220.127.116.11.
The 172.1.2.x address can be any address not used by your enterprise. It is internal to the Sysplex configuration.
Define the VIPA configuration
You define the configuration once, in the front end TCPIP. It is visible from the other TCP/IP images because the information is shared via the DYNAMICXCF.
You define the VIPA in the front end TCP/IP image with a VIPADEFINE netmask address. I used
VIPADYNAMIC VIPADEFINE 255.255.255.0 10.1.3.10 ... ENDVIPADYNAMIC
You can define VIPABACKUP in another TCPIP image, so if the main front end TCP/IP is not available then a backup can take the traffic and distribute it to the other TCP/IP stacks.
When the main front end TCP/IP image is restarted, you can have it take back the routing.
Define the “routing” to where the server was running.
You can define a variety of ways of routing the work
- A Hot Standby – where the input to the front end TCP/IP image is routed to a single “backend” application’s TCP/IP image. If this fails, the work is routed to a running backup application.
- A Round Robin – where requests are routed in turn to each TCPIP with an active application.
- Routing depending on WLM or other load characteristics.
This routing is done by the VIPADISTRIBUTE command in the front end TCP/IP image.
The definitions for the front end TCPIP
IPCONFIG SYSPLEXROUTING DYNAMICXCF 18.104.22.168 255.255.255.0 3 VIPADYNAMIC VIPADEFINE 255.255.255.0 10.1.3.10 VIPADISTRIBUTE DEFINE DISTM ROUNDROBIN 10.1 .3.10 PORT 8443 DESTIP 22.214.171.124 126.96.36.199 ENDVIPADYNAMIC
This routes connection requests to the TCPIP images with the DYNAMICXCF of 188.8.131.52 (TCPIP2) and 184.108.40.206 (TCPIP3)
The definitions for TCPIP2
IPCONFIG SYSPLEXROUTING DYNAMICXCF 220.127.116.11 255.255.255.0 3
The definitions for TCIP3
IPCONFIG SYSPLEXROUTING DYNAMICXCF 18.104.22.168 255.255.255.0 3
Use of VIPABACKUP
If the backup TCPIP front end image it used, it can have its own VIPADISTRIBUTE statement, or just use the same statement shared from the main front end TCP/IP image. It is better to have the VIPADISTIBUTE statements, for the case when the backup TCPIP is started before the front end TCPIP. The backup needs the VIPADISTRIBUTE statements. (These statements can be put into a PDS, and included using the INCLUDE dataset(member) statement in both primary and backup environments.)
To define TCPIP2 as a backup I used
VIPADYNAMIC VIPABACKUP MOVEABLE IMMEDIATE 255.255.255.0 10.1.3.10 VIPADISTRIBUTE DEFINE DISTM ROUNDROBIN 10.1.3.10 PORT 8443 DESTIP 22.214.171.124 126.96.36.199 ENDVIPADYNAMIC
Getting the server to use the VIPA
The TCP/IP images hosting the applications just have the IFCONFIG DYNAMICXCF aa.bb.cc.dd statement. They do not have any VIPADYNAMIC … ENDVIPADYNAMIC statements unless they are the main or backup front end TCP/IP images.
The application can connect using the VIPA address, for example create the SSLSOCKET Listener passing the VIPA address. You can also configure TCP/IP so when a port is used, it binds to a particular IP address for example
PORT 8443 BIND 10.1.3.10
So an application using port 8443 to listen, will get IP address 10.1.3.10 – which in my case is a VIPA address.
You can use
9443 TCP * SHAREPORT BIND 10.1.3.7
to allow the port to be shared by many applications on a TCPIP Instance.
How are the connections distributed?
The VIPADISTRIBUTE has many routing options. I used Hot Standby and Round Robin.
With RoundRobin, I had
- the front end TCPIP
- TCPIP2 with two Liberty servers
- TCPIP3 with one Liberty server
I ran some workload and found that the server on TCPIP3 had half the requests, and each of the two servers on TCPIP2 had a quarter of the overall requests. This shows the routing is done at the TCPIP level – not the number of servers.