Mailing List Archive

Hello,

On Thu, 30 Mar 2017, LIANG Sujun wrote:

> Hi Dear,
> I setup my LVS/NAT system by keepalived and it works. I configured the persistent timout as 360 seconds
> I have one question when enable IPVS connection synchronization, I found the expiration time of persistent template in Backup director is updated to original value as long as packets are coming in Master Lunix director
>
> Please see following example:
>
>
> 1. On Master:
> [root@0210-lvs-master ~]# ipvsadm -Lcn
> IPVS connection entries
> pro expire state source virtual destination
> UDP 04:54 UDP 10.195.52.11:5060 10.195.52.18:5060 192.168.0.4:5060
> UDP 05:53 UDP 10.195.52.11:0 10.195.52.18:5060 192.168.0.4:5060
>
>
> On backup:
> [root@lvs-backup ~]# ipvsadm -Lcn
> IPVS connection entries
> pro expire state source virtual destination
> UDP 04:49 UDP 10.195.52.11:5060 10.195.52.18:5060 192.168.0.4:5060
> UDP 05:50 UDP 10.195.52.11:0 10.195.52.18:5060 192.168.0.4:5060
>
>
>
> 2. Send the traffic
>
>
> 3. On Master
>
>
> [root@0210-lvs-master ~]# ipvsadm -Lcn
> IPVS connection entries
> pro expire state source virtual destination
> UDP 05:00 UDP 10.195.52.11:5060 10.195.52.18:5060 192.168.0.4:5060
> UDP 05:12 UDP 10.195.52.11:0 10.195.52.18:5060 192.168.0.4:5060
>
>
>
> On Backup
>
> [root@lvs-backup ~]# ipvsadm -Lcn
> IPVS connection entries
> pro expire state source virtual destination
> UDP 04:18 UDP 10.195.52.11:5060 10.195.52.18:5060 192.168.0.4:5060
> UDP 06:00 UDP 10.195.52.11:0 10.195.52.18:5060 192.168.0.4:5060
>
> You can see the expiration time of persistent template on backup director is updated to 6 min, and the expiration time won't also be synced, why the persistent timeout on backup is updated each time?

The lifetime of template can be extended above
the configured timeout, eg. when new controlled connection
is created or if it is still referenced by controlled
connections, so we try to sync it every time. Also, the
sync transport is unreliable, we do not know if the
template is really created in backup.

May be it would be more correct to send
(cp->timer.expires - jiffies) / HZ instead of cp->timeout / HZ
as it specifies the expiration time but the problem is that
it is not updated yet in some of the cases:

on packet for normal conn we do:
- first time: schedule, update template's cp->timer.expires
- refresh our cp->timeout, eg. in ip_vs_set_state()
- sync the connection
- sync the template
- finally update cp->timer.expires for conn

I.e.

- on packet for normal connection:
- cp->timeout is valid while generating the sync msg
- cp->timer.expires was set from the previous packet,
it will be updated later by ip_vs_conn_put() but after
the sync msg is generated
- cp->timer.expires for its template should be already
set, eg. ip_vs_conn_put(ct) in ip_vs_sched_persist()
happens before generating the sync messages

- packet for normal connection triggers sync for controlling
connection (template or FTP:21):
- using cp->timeout may extend the timeout in backup
above the timeout in master, as you observe
- cp->timer.expires should be more correct to use for
controlling connections but for templates this may
lead to reduced template timeout if the backup
server takes control. This happens because the
template timeout is set once from svc->timeout
while for normal connections we refresh it every
time based on the protocol state. If the sync msg
provides reduced timeout (with 8 seconds in your case),
it will be used forever.

So, as long as we send sync messages containing only the
cp->timeout and not (cp->timer.expires - jiffies) the
problem can not be solved. At least, we try to use longer
timeouts in the backup which is preferred.

Regards

--
Julian Anastasov <ja@ssi.bg>

_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-request@LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users