|
Hello,
Resumé: Synchronization only works when you use eth0
to send "connections informations" (at least for me).
My two directors are running Linux 2.4.10 with IPVS 0.9.4.
There is a link between those on eth2:
LVS-NAT: VIP = 192.168.1.10, GW_VIP=192.168.2.1
Clients
----+--------------------+--------------------+----
eth0 | 192.168.1.11 192.168.1.12 | eth0
+---+---+ +---+---+
| | 192.168.3.1 192.168.3.2 | |
|
| DIR_1 +---------------------------------+ DIR_2 |
|
| | eth2 eth2 | |
+---+---+ +---+---+
eth1 | 192.168.2.11 192.168.2.12 | eth1
----+---+---------------------------------+---+----
eth0 | 192.168.2.21 192.168.2.22 | eth0
+---+---+ +---+---+
| RS1 | | RS2 |
+-------+ +-------+
On director 1:
ipvsadm --start-daemon=master --mcast-interface=eth2
On director 2:
ipvsadm --start-daemon=slave --mcast-interface=eth2
The connectivity is ok, "connection information" packets are
sent/received correctly, as shown with tcpdump:
11:33:51.738631 192.168.1.11.1028 > 224.0.0.81.8848: udp 28 (DF) [ttl 1]
The problem is that the source address seems to confuse
the receiving socket (on the backup machine) and doesn't
take the packet in consideration.
I verified it by changing the link used for synchronization to
eth0. The result is positive, the synchronization is correct.
I dunno if it's a kernel problem (shouldn't the source address
on eth2 be 192.168.3.1 instead of eth0's address: 192.168.1.11)?
If it's the normal behavior, then the bug may be in ipvs.
I looked a bit at the sources ("ip_vs_sync.c") in the infinite loop
in function "sync_backup_loop". It seems that, when I configure
the synchronization daemons to use eth2, the receive queue
is always empty:
"while (!skb_queue_empty(&(sock->sk->receive_queue))) {"
Thats why I don't know if it's a kernel or ipvs bug :)
Thanks,
Fabrice Bucher
|
