In addition to everything Jon has stated a few other questions may help figure out what needs to be done, or not done.
Are both LPARS on the same CEC? If both LPARS are on the same CEC, do they share OSA's? Are the IP addresses you plan to use as VIPA's in the same subnet as the OSA's IP addresses? With certain setups you may need to run OMPROUTE configured for OSPF. I think if both LPAR's are on the same CEC and they share OSA's and the VIPA addresses are in the same subnet as the OSA's, there is not much to do, but to configure both TCPIP stacks with the same VIPA range and then with PORT definitions assign what VIPA address you want that application to use. On Tue, 17 Oct 2023 01:52:07 -0500, Jon Perryman <jperr...@pacbell.net> wrote: >On Tue, 17 Oct 2023 16:00:56 +1300, Laurence Chiu <lch...@gmail.com> wrote: > >>We have one LPAR with static IP > >You are saying: >LPAR 1 has static IP address 192.168.40.70 >LPAR 2 has static IP address 192.168.40.71 > >> and a server on that LPAR > >"on that LPAR" is wrong. You actually mean: >You have a server "application" sometimes on LPAR 1 and other times on LPAR 2. >A third static IP address is needed to specifically for server application. > >STOP CALLING THIS IP ADDRESS DVIPA. Technically DVIPA but it's confusing you. >IPA stands for IP Address. You want a static IP Address. DV is unimportant >until it becomes important. Avoid discussing the technology with your network >people since they don't understand it. > >> that supports both internal and external clients. > >When you say "internal", I assume you mean intranet and "external" internet. >For security purposes, your company probably has multiple intranets. For >instance, you would want an intranet for the lobby where untrusted people come >and go. It's still part of your company. > >Your network people will want to know who needs protection from this IP >address because your server may be dangerous. They will also want to know what >protections this IP address will need because others thon your network can be >dangerous. > >Step 1 for you is to create the basic DVIPA definitions. The network people >don't trust you because you didn't prep to understand your software. You can't >answer their questions until you know your setup and what you will take care >of. For instance, apparently you don't care that everyone in the world has >access to TN3270 on your systems. Will your DVIPA definitions have incoming >port numbers restricted to the server application port numbers? What are these >port numbers that must pass thru to the internet? They will want to know that >this IP address is as trustworthy as LPAR 1 & LPAR 2 IP addresses. > >> We want to duplicate that server >>application on a second LPAR and they will be in a sysplex. If the first >>LPAR goes goes down, we want incoming traffic not worry about it. This is >>because automation will startup the server on the second LPAR (they cannot >>be up at the same time since they need to share a VSAM file and we do not >>have VSAM/RLS. > >Keep it simple. You have a server application that will be moved between 2 >LPARS but never active on both. You want the move to be as automatic as >possible. > >We don't duplicate in z/OS which is an important distinction with Unix. There >are situations where the server application moves and both LPARS are active. > >>What we want is for z/OS to move the VIPA to the second LPAR. Since the two >>TCP stacks on the two LPARs are sharing information via XCF, the second >>LPAR should see the primary LPAR is down and take over the service. >> >>So from my reading of the IBM docs, I need the host IP to be a dynamic VIPA >>(DVIPA) so that quoting this manual >> >>https://www.ibm.com/docs/en/zos/2.1.0?topic=addressing-static-vipas-dynamic-vipas-distributed-dvipas >> >>Dynamic VIPAs have the following characteristics:uc >> >> - They can be configured to be moved dynamically from a failing stack to >> a backup stack within the same sysplex without operator intervention ord >> external automation. >> >>I don't want to have to make any changes to upstream routers, IP changes >>etc. The goal is to make it transparent. > >Step 2 you need to educate yourself about the routers that are connected LPAR >1 and LPAR 2. > >DVIPA automatically deletes the IP address in LPAR 1 and defines it in LPAR 2 >but the routers must be told to send data to LPAR 2 instead of LPAR 1. You >need to find out if they are from IBM and IBM automatically changes them. Or >maybe they are unique unshared routers that require automation include router >changes. This is something you must determine > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
