LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [lvs-users] The expiration time of persistent template in Backup dir

To: LIANG Sujun <Sujun.Liang@xxxxxxxxxxxxxxxxxx>
Subject: Re: [lvs-users] The expiration time of persistent template in Backup director is updated to original value as long as packets are coming in Master Lunix director when enable connection synchronization
Cc: "lvs-users@xxxxxxxxxxxxxxxxxxxxxx" <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Fri, 31 Mar 2017 10:32:32 +0300 (EEST)
        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@xxxxxx>

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

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

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