LOCAL_IP setting on Cloverleaf 5.3

This topic has 3 replies, 2 voices, and was last updated 18 years, 3 months ago by Russ Ross.

Creator

Topic
October 16, 2006 at 6:00 pm #48841
Adam Frederick
Participant
We are in the process of implementing HACMP. Our production box has a service IP address that will follow the resource group to whatever hardware CL is running on. There is also an administrative IP address that is static and will always be tied to that hardware.

We are trying to utilize the LOCAL_IP setting within the protocol section of the thread configuration. This setting is supposed to control what IP address a destination thread uses to initiate a connection with another system.

This setting is part of the GUI on 5.4, but we’re on 5.3. We were told this functionality works in 5.3, but you have to manually edit the NetConfig file to add it. We have edited the NetConfig and set it to the service IP address, but it appears it’s still trying to initiate the connection with the administrative IP address.

This is important because we have a large number of VPN configurations that will need to be reconfigured if this functionlity does not work.

We were wondering if there is a service pack needed for this to work on 5.3 or if this should be part of the original release. Also, has anyone had experience setting this up on 5.3? Do you know if there is anything else needed other then adding the LOCAL_IP setting to the protocol section of the thread?
Creator

Topic

Viewing 2 reply threads

Author

Replies
- October 17, 2006 at 11:14 pm #59866
  Russ Ross
  Participant
  Adam Frederick:
  
  Buckle your seat belt buddy because I
  
  Russ Ross
  RussRoss318@gmail.com
- October 18, 2006 at 12:31 am #59867
  Adam Frederick
  Participant
  Russ-
  
  Thank you very much for the post….this is some great info. We are on AIX as well and I believe the shell script to set the default NIC will work in our situation.
  
  We have one twist. We currently have two production engines…one for our eastern time zone and one for our central time zone. As part of this install we are consolidating our central and eastern time zones onto one box. So we’ll end up with two service IP’s.
  
  In our project plan the first step is to move the central time zone interfaces over to the new hardware in which case we’ll have one service IP. In that case the shell script or subnet seems like it will work just fine.
  
  The part that gets foggy for me is when we move our eastern time zone over to the new hardware we’ll then have two service IP’s. I believe we are set up with IP aliasing and those two addresses are tied to one NIC.
  
  In that case if we set the NIC to the one with the service IP’s associated with it (via your shell script), I’m wondering if the LOCAL_IP then works to intiate the connection with the service IP that is set up in the thread. Is that your impression of how that works?
  
  I’m going to go back and do some more research on this and will let you know what I find. Thanks again for the post…..I’ll get the checks in the mail 🙂
- October 18, 2006 at 1:40 pm #59868
  Russ Ross
  Participant
  Adam:
  
  It sounds like you understand the problem and the work around I came up with for those of us running HACMP on one subnet.
  
  I would like to answer your additional questions for the whole world to see, but your situation goes beyond what I’ve needed to accomplish.
  
  I’m confident what you described (2 service IPs that work correctly on one HACMP cluster) can be accomplished.
  
  As I pointed out before, having each IP to the HACMP machine on its on subnet is the first approach I would do if possible.
  
  So in your case, that would be 3 separate subnets for the following IPs (service_1, service_2, persistent_1).
  
  My guess is that you are bieng forced to use one subnet like I was.
  
  PS: Later versions of AIX have LPARs, which could be another clever way to create 2 independent HACMP clusters using the same physical hardware. That way one HACMP cluster with the first service address could be using one set of LPARs. While the other HACMP cluster with the second service address could be running on another set of LPARs. I’ve already run Cloverleaf fine on different LPARs. Another nice thing is that all LPARs on the same physical hardware only need one cloverleaf license. Now that I’m thinking out loud about this, you might find this a good choice for many reasons (guarantees success of a proven model simply by duplicating it; balances the load; and keeps everything separate like it is now but consolidates it on one physical piece of hardware). I plan to use my additional HACMP/LPAR cluster for future cloverleaf upgrades so I do not have to upgrade in place. As you can see the conversation could be endless so call if you think you want to talk some more, then once you get it working please consider appending your solution to this post for others to benifit.
  
  I will be watching my mail box for that check, and thanks. 😀
  
  Russ Ross
  RussRoss318@gmail.com
Author

Replies

Viewing 2 reply threads

The forum ‘Cloverleaf’ is closed to new topics and replies.