|
Horms,
I have tried to change ip_vs_process_message() function by adding some codes:
1. firstly I would check whether it is a template or not， if it is a template,
we would call the following function to bind a dest to this synced connection
entry:
get service(ip_vs_service_get())-->lookup
dest(ip_vs_lookup_dest())-->ip_vs_conn_new(..., dest). by passing a dest
pointer to create a new connection.
2. If it is not a template, lookup this template and bind its dest and control
info.
3. To do this, ip_vs_sync_conn called sequence is slightly changed. It is
changed to sending control info firstly then ip_vs_conn itself.
By watching persistent connection, when lvs swaps over(active-->backup,
backup-->active), clients can visit correct destination real server. But the
question is, when switching again, it would cause linux system down. It can
resume normal only when reboot the system. I tried to find why and failed.
Can you help to point out where the question is?
Thanks,
-----Original Message-----
From: Horms [mailto:horms@xxxxxxxxxxxx]
Sent: 2006年7月3日 18:19
To: Kingston Wang
Cc: LinuxVirtualServer.org users mailing list.
Subject: Re: a question in ipvs sync persistent connection info
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/
|
