|
Hi,
I was looking into a way to write a script that would
run on each LVS box such that the status of each VIP
could be checked, as to which MAC (ethernet) address
the VIP is "running" on. As you know a failover of
the VIP also means the MAC address changes. It seemed
Wrong. You can happily have the same MAC, you just need to make sure the switch
doesn't shut down the ports.
likely to me I could use Linux's "arping" command to
locate this info, process it and mail me at my pager
What's wrong with 'ip neigh show'?
address. We have had a couple circumstances in which
the backup LVS lost connection with the primary, so
both were running LVS and VIPs. When connectivity was
That's a basic problem of hotspare clustering and caused a lot of people
headaches.
restored, LVS daemon was correctly stopped on the
What's an LVS daemon?
backup, but VIPs stayed up on both so routing was
affected. So the following arping statements seemed
likely for a script + pager solution:
(IPs and MACs changed to protect the folks)
THIS DOES ARPING ON DEVICE:
[root@lvs]# arping -I eth0 184.186.18.50 -c 1
ARPING 184.186.18.50 from 184.186.18.51 eth0
Unicast reply from 184.186.18.50 [00:86:58:88:0D:D8]
0.697ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
THIS CHECKS FOR DUPLICATES:
[root@lvs6]# arping -I eth0 184.186.18.50 -D
ARPING 184.186.18.50 from 0.0.0.0 eth0
Unicast reply from 184.186.18.50 [00:86:58:88:0D:D8]
for 184.186.18.50 [00:86:58:88:0D:D8] 0.713ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
Yes, the failover/failback cluster software should definitely be aware that
there is already someone on the same physical segment stealing away packets.
But I can only get the above results from the BACKUP
LVS box, I cannot get any result when run from the
PRIMARY LVS box. The above 184.186.18.50 is the LVS
VIP and the MAC address shown is on the PRIMARY eth0:1
device. Additionally, I cannot get any result when
running those arpings from my own Linux PC. I've tried
playing with the -I and adding -s (source IP) but does
not change outcome.
Despite the fact that I do not understand what exactly you're trying to achieve
you might want to consider the concept of having one or two heartbeat interfaces
via crosscable that check the running state of each director. Now in a
hotspare/cold/master-backup/primary-secondary failover you have a dedicated
machine that normally runs in operational mode while the other(s) sleep. A state
machine (plus in the world of clustering often a STOMITH instance) make(s) sure
that the problem you describe doesn't occur.
Anybody use arping to do this kind of checking ?
I use arping to set up interfaces actually but not to do the checking.
Why does arping only work from the backup and not
the primary LVS nor from my PC ? I cannot seem to
locate this kind of info on the web.
link state down? missing routing info?
Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
| 