|
Hi,
Julian Anastasov wrote:
Well, I assume you don't use any solutions to fix the ARP
problem in the real servers.
yes. my brilliant idea was to use a static arp entry for the VIP on the
router. This worked. Until I changed from two switches to one big
switch. Now the cluster works with 4 servers, but if I add the 2 SMP
servers my setup stops working. And somehow I can't justify to leave the
2 servers offline...
What about ARP, do you see unanswered ARP probes looking in
this way:
who-has GW tell VIP (MAC of RS)
yes. But I figure that some host should tell them... 4 real servers know
the correct MAC-address and tell the other 2 about it.
You can try whether it makes difference by applying one
of the patches:
http://www.linuxvirtualserver.org/~julian/01_arp_prefsrc-2.4.12-5.diff
or of course, the hidden flag:
http://www.linuxvirtualserver.org/~julian/hidden-2.4.5-1.diff
My explanation of a possible problem in your setup:
By default Linux resolves the other hosts by announcing
any local IP in our ARP probes. When bidirectional communication
takes place it is possible the real server to use VIP as source
in our probe (resolving GW). May be GW does not like this probe
because it is from VIP (as source IP). The normal way to reply
to ARP probe is to reply directly to the sender's hwaddr but
may be after makeing some checks for the sender's IP (which is
true in Linux). If arp_prefsrc solves your problem, then this is
the case with your GW. It does not like broadcast ARP probes with
VIP to come from real servers.
I'll check that out.
Nico
--
Nico Lumma nl@xxxxxxxxxxxxxx
orangemedia.de GmbH www.orangemedia.de
Borsteler Chaussee 55 Tel: +49 40 46 85 67 - 20
D-22453 Hamburg Fax: +49 40 46 85 67 - 39
| 