a question in ipvs sync persistent connection info

[Kingston Wang]

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 at verge.net.au] 
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/