I am probably not understanding it correctly either. We have one LPAR with static IP and a server on that LPAR that supports both internal and external clients. 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.
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: - They can be configured to be moved dynamically from a failing stack to a backup stack within the same sysplex without operator intervention or 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. On Tue, Oct 17, 2023 at 1:15 PM Jon Perryman <[email protected]> wrote: > You're confusing dynamic IP addresses with dynamic VIPA. I've never seen > DVIPA use dynamic IP addresses. > > A static IP address is an address that doesn't change. Many people > incorrectly assume it's assigned to a specific machine. You decide how this > IP address is used. > > Talk with your IBM hardware / software reps because you may not even need > to involve your non-z/OS network people. The world has gone to smart > routers and I suspect IBM included IBM smart routers in your configuration. > In that case, everything is in your domain. It wouldn't be surprising if > IBM smart routers automagically changed with DVIPA requirements. I'm more > familiar with Unix these days which has seen improvements in high > availability requirements. > > If you must involve your network people, don't tell them more than they > need to know. You determine your DVIPA setup which is more about you than > them. Let's assume a simple scenario. Let's say you have 10 systems in a > sysplex with IP addresses 192.168.40.#. You have a static IP address > 192.168.40.177 for DVIPA that will be on one or more of those machines. How > will you tell his router the next hop for 192.168.40.177? Does he want to > keep it simple and forward the packets to the next available z/OS system > and let z/OS forward it to the correct system? > > As for DNS, he defines 192.168.40.177 once. DNS doesn't care where or what > machine uses this address. > > If you're network person is insistent about DVIPA, tell him to think about > it as a virtual network adapter but with more capabilities. This is all > very dependent upon how you will use DVIPA. > > On Tue, 17 Oct 2023 10:07:14 +1300, Laurence Chiu <[email protected]> > wrote: > > >I am having a debate with a network person (but not z/OS) how DVIPA works. > >We have a LPAR with static IP which many hosts and firewalls know about > it. > >I want to make this host part of a sysplex and so need to make certain IP > >addresses/ports dynamic so they can be switched to the second LPAR if the > >first goes down. This is a typical business requirement for DVIPA. > > > >My view is we change the IP definition of the IP address from static to > >virtual (VIPA) and the make it dynamic - hence DVIPA but it's actual value > >does not change so that we need no firewall changes or DNS changes. > > > >He thinks we need a new IP address for the host and that means firewall > and > >DNS changes. Not not having worked in a static to VIPA environment before > I > >don't know but from my reading of the TCP documentation for z/OS it seems > >we don't need a new IP address - just a change in the way it's defined. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
