I'll try to explain this as best as I can, but this can get confusing and this
is based on my understanding. We do have DB2 setup in Data Sharing and
configured using SYSPLEX distributor, which some of the configuration is
similar.
When TCPIP on z/OS allocates a IP address that address is registered in the OSA
so that the OSA has a list of every IP address that is open and which LPAR it
is opened on.
So if you have a VIPA that is defined in the DYNAMIC VIPA range that opens on
LPARA, the OSA knows that IP address is valid and is on LPARA, when it sees
packet for that address it sends it to the TCPIP stack on LPARA. If the STC
that allocated that address stops and TCPIP unregisters it from theOSA. If
that STC is started on LPARB, then the address is registered on the OSA as
belonging to LPARB and any traffic for that address is now sent to LPARB.
If the OSA is connected to a switch and the traffic is switched, not routed,
then nothing should need to be done on the "distributed network" side. The
switch won't see any difference.
What you need to do on z/OS is define the IP address a DYNAMIC VIPA in your
TCPIP PROFILE for each LPAR. Then also define the PORT your server tasks listen
on in your PROFILE's PORT definitions on each LPAR something like:
80 TCP MYSERVER BIND 192.168.40.99
What this does is when MYSERVER starts and try to open's TCP port 80 to listen
on TCPIP will allocate it to IP address 192.168.40.99 specifically.
No matter which LPAR "MYSERVER" is started on the traffic will et sent to the
correct LPAR. If you accidentally start it on both at the same time, bad
things could start to happen. There are ways that you can have MYSERVER up and
running on both LPAR's at the same time, but it does involve a little more
configuration and understanding of your application.
Now if the traffic is routed, this normally means that the OSA's addresses are
in a different subnet from the VIPA's addresses. You will need OMPROUTE and
OSPF setup so the z/OS can tell the distributed router that it is connected to
which LPAR to route the traffic to. This is a more complex setup and typically
is only needed when you have multiple CEC's and you want to move IP addresses
from one CEC to another.
On Wed, 18 Oct 2023 08:45:52 +1300, Laurence Chiu <[email protected]> wrote:
>That is exactly the situation, The second LPAR will be on the same CEC as
>the first, share OSA adapters and be in a sysplex with XCF being the
>mechanism to share the VIPA information. From my reading of the docs, when
>the server application on the primary LPAR is shutdown, and an incoming
>transaction arrives for it, TCP on the second LPAR will see the
>primary host and dynamically route the transaction to the server on the
>second LPAR. By making it dynamic we don't hae to worry about automation
>moving the VIPA, we can let TCP do that.
>
>The second LPAR will be in the same subset as the first.
>
>Youi comment about OMPROUTE is noted.
>
>Thanks
>
>On Wed, Oct 18, 2023 at 1:05 AM John S. Giltner, Jr. <[email protected]>
>wrote:
>
>> 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.
>>
>>
>>
>
>----------------------------------------------------------------------
>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
