LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

RE: a question in ipvs sync persistent connection info

To: "Horms" <horms@xxxxxxxxxxxx>
Subject: RE: a question in ipvs sync persistent connection info
Cc: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: "Kingston Wang" <kingston.wang@xxxxxxxxxx>
Date: Tue, 4 Jul 2006 09:52:09 +0800
Horms,
  From the testing result, the persistent templates are already synced to the 
peer. Also, the dest info and virtual service info are synced also. I have 
tried to lookup the service and bind the dest to the synced connection entry. 
It seems to work normally. But the question is when stop or restart lvs server 
after I do such modification, linux is down. I'm working on it to find why.

  Thanks, 


BR,

Kingston,


-----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/


<Prev in Thread] Current Thread [Next in Thread>