|
On Fri, Jun 30, 2006 at 05:12:52PM +0800, Kingston Wang wrote:
>
> Horms,
> The ip_vs_dest structure does not exist in ip_vs_sync_conn. That is, when
> sync daemon starts, this ip_vs_dest structure do not sync to the backup
> ip_vs. For we use apache server as web server, and need persistent
> connection visiting. When a connection comes and it already exists in
> connection entry hash table, it would use ip_vs_sched_persist function to
> schedule this connection. In this function, it uses ip_vs_check_template
> function to check connection's dest and schedule it. In normal case, there is
> no problem. But if master/backup ip_vs server switchover in some case. For
> master server do not sync one connection's ip_vs_dest part to the backup
> server(currently it is master server), ip_vs_check_template would find "dest
> is null" and reset the persistent connection port to 65535 and a new
> connection entry is created. That causes newly-coming connections is
> re-scheduled again. The persistent mechanism does not work at that time.
> So I think we need sync ip_vs_dest to the peer to avoid such case.
Hi,
I had a look into it, and it does seem that synchronisation doesn't work
correctly for a new connection that should be scheduled persistantly.
It seems to me that could be solved by adding a flag, such that
on the backup side, when connection is created via syncrhonisation,
it is marked with the flag and cp->dest is treated slightly differntly
in ip_vs_sched_persist().
Also, can you confirm that the persistant templates are being
synchronised, I see there is code to handle them on the receiving end,
and I'm sure that I've seen it working in the past, but I'm scratching
my head over the transmit side.
--
Horms
H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/
|
