Problem with application in MC/Service Guard

[Abdul Salam H S_1]

Hi,

I have configured an active/passive cluster which is working fine. But I'm facing some problems while I configure/interface my applications which is running on 2 systems.
We have application-1 on the HP cluster which talks to application-2 on another Unix server(SUN). We are able to connect to the package IP address from the Sun server successfully. But the situation is that,in the application-2, we need to specify that the request is coming from a particular IP address(ie, we want to set like it is coming from active HP cluster node). We found that when we specify the package IP address, the application-2 is not able to recognise that IP address.But if we give the actual IP address of the active node, application is able to talk with each other.We used some sniffer tool and observed that, the HP cluster is still sending the actual IP address bound to it, rather than the package IP address. Is there a way to do this?
How can I configure the application for automatic failover in this case?

Thanks and Best Regards,
Abdul Salam

[Massimo Bianchi]

Hi,

can you please specify which kind of application is ? Usually there are some parameters that are used when working with virtual ip address, and maybe you are missing some of this.


I think that the HP cluster sends the real IP as an answer because the real ip is the first to answer.

Let me explain: we have lan1 12.13.14.15
and lan1:0 12.13.14.16 .

When we start communication, first interface to answer is always lan1, and not lan1:0.

If you use a "netstat -a" from the client side, what did you see in the connection, the real or the virtual ip ?

I use SAP, and i see connection between real and virtual, as expected. There may be some issues with the mixed sun/hpux config, the way each other resolves the ip address.

If you need, i used a little trick:

remsh virtual_host -n "nslookup $(hostname)".

and then i used that ip address for my application.

HTH,
Massimo

[Tim D Fulford]

Abdul.

This behaviour is normal!! I have seen a way that you can do this, it was totally by accident and is probably unsuported.

What happened was the package netmask/subnet did not match the "base" netmask/subnet.

so
lan0 172.16.8.100, netmask 255.255.0.0
lan0:1 172.16.12.101, netmask 255.255.255.0

I'd test this out a-bit before putting it onto a live box. I saw it on HP-UX 11.0 SG 11.09, so HP MAY have patched it or may not.

Give it a whirl

Tim

[Abdul Salam H S_1]

Hello Massimo,

I think the ouput of the remsh command is returned by looking into the /etc/hosts for this system's corresponding entry in the other machine.What I needed is that the system should be able to send both the real and virtual/package IP addresses when it requests to the Sun system. Is there any way of doing this?

Hello Tim,

I'm a bit confused with what you have asked me to try!
Do you mean to say that I should change the virtual address to a different range and netmask? But,in that case, will my clients be able to connect to the cluster?


Thanks and regards,

Abdul Salam

[Massimo Bianchi]

Hi,
usually what you are asking is done automatically by the client.

Unfortunatly i have no mized sun/hpux environtment to test.

What i suggested was a workaround, if there are no special settings for the application, but this usually heavily depends on the application itself.

In my envs, pure hpux, it works. I think the problem lies in the SUN server, and the way it resolves the IP/ARPA couple.

If you check, arp entries are the same for both virtual and real address, but if your application check for the first occurence of a certain arp entry, maybe it will not find the virtual ip but the phisical id.

But for this i hope there is some SUN net guru over here, to have better help.

HTH,
Massimo

[Tim D Fulford]

Abdul

Your right, Im saying that if the package subnet/network is different to the base subnet/network HP-UX will route OUT of the package IP. A simple test is

% telnet
% telnet
% who -mu
This will show the base address of the network. But if you are able to change the subnet/network of the package relative to the base/machine network address "who -mu" should be the package IP.

Regards

Tim

[Abdul Salam H S_1]

Hello Tim,

'who -mu' will always show me the IP address of the system from where I'm logging into the destination Unix server, irrespective of which IP address of the remote server I use, Real or Virtual. How can this IP be used as package IP?

Thanks and Best Regards,

Abdul Salam

[Tim D Fulford]

Abdul.

Thinking about it.... you are probably right.

OK what I'll do is explain what I saw. May I re-itterate that this was done by mistake. The problem was that when our service-guarded box's application tried to connect to another box it was refused DESPITE having the boxes IP address (lan0) in .rhosts.

I could not understand this & we did loads of network tracing etc, until finally we saw that the packages comming from the SG boxes actually had the source address of the PACKAGE (not base address, lan0). This made no sense to me as it should have come from the base IP address. I started to do ifconfig lan0, lan0:1 etc & noticed that the subnets were different for the two LANs. I fixed it by changing the appropriate serviceguard configs.

So, you now have the whole story....As I said before this is probably unsupported etc...

Regards

Tim

[Tim D Fulford]

Abdul

Attached is a test I did. I chose VERY different networks, but the principal works. All I did was to ifconfig new IPs on lan0:1, no routing etc.

on a180tst1, telnet to 172.16.1.200 (lan0:1 on a180tst3), who -mu gives 172.16.1.100 as source (NOT 192.164.192.208). Quod Erat Demonstrandum!!!

Thinking about this more, it would be best if you package IPs are on different NATURAL networks to your base address as routing may become an issue if the IPs are in a similar NATURAL networks. e.g. 193.164.192.X & 193.164.193.Y would be OK but 172.16.17.X & 172.16.17.Y would not.

Actually thinking about it even more... this may well be a real headache if you have any routers etc to!!!

Regards

Tim

[Tim D Fulford]

One more test....

I assigned two subnetted (to C) class B addrerses, this worked. When I logged onto 172.16.17.X I came from 172.16.17.Y (same network/subnet), when I logged onto 172.16.18.X I came from 172.16.18.Y (same network/subnet)

Then I tried two natural calss B addresses, which did not (as I expected) differentiate between the two networks sources. When I logged onto 172.16.17.X I came from 172.16.18.Y, when I logged onto 172.16.18.X I came from 172.16.18.Y.

I'm not sure why I always came from 172.16.18.Y as it is lan0:2, I would have expected 172.16.17.Y, but the main point is my source address is the same.....

Regards

Tim