Well like usual, murphy law apply and I cannot reproduce the problem...
The only difference is that yesterday this farm was production with 600
clients, and today i'm alone.
I still believe the IP Persistance in L4 farm is not reliable. I'm 200%
sure my timeout was 4h yesterday when my session disappeared quickly.
Moreover, we have a lot of issues with our clients being kicked out of
the application when using this type of farm. (the error was about
session, so client was auth on a backend and suddenly forwarded to
another backend by ZLB).
I switched back to PEN TCP farm with IP persistence and it's working
perfectly. Could there be a bug with the IP persistance of L4 farm, like
it cannot memorize so much IP? In my PEN farm I see around 600 clients
(differents IP), but with the L4 farm, on the file /proc/net/xt_recent/
there were only about 100-200 different IPs. That would explain why we
had so much problem, if it was not memorizing all IPs or forgetting some
of them very quickly ...
Thanks
tibz
ps: I read in another thread that you consider to obselete PEN, please
do not (yet :-))
ps2: If you wonder why we were happily using PEN and switched to L4,
it's because we started having issue with PEN after several months. I
had configured max 2000 IPs in persistance with a timeout of 3600s. When
2000 is reached, ccording to PEN's doc, it should delete the
oldest/least used connection to make some room for new connections. But
it doesnt seems to work correctly as client were randomly switched to
another backend (like PEN was not deleting the unused entry but some
random entry amongst the 2000)
On 27/02/2014 21:29, tibz wrote:
HI Laura,
Thank you for your answser. When I did my test, the persistance was
configured to 14400s (4h - same timeout as on the http backend).
But still, after I closed my browser (and then no more connection was
made from my laptop), my session disappeared from /proc/net/xt_recent/
in about 1min max. So I believe it's not right.
What you explain is what I was expecting, and i've checked now the
content of the /proc/net/xt_recent/ and I still see plenty of session
despite no one is in the office anymore. So it seems to work "most of
the time", but not always as like I explained, my session during my
test disappeared much quicker than the timeout.
I'll run some more tests tomorrow if possible and i'll update you.
Cheers,
tibz
On 27/02/2014 17:49, Laura Garcia wrote:
Hi again, the persistence will remain until the time specified in the
farm option:
*Source IP Address Persistence time to limit **in secs, only for IP
persistence*.
*
which by default is 140 secs. So it's the right behavior. In order to
work around your problem, you could increase that timeout at the same
value as the HTTP persistence is set in your real servers/web
application.
The L4 farm has nothing to do with your browser so the behavior will
be the same and the persistence will wait until the timeout although
the user has logged out from the web application.
On Thu, Feb 27, 2014 at 10:56 AM, tibz <[email protected]
<mailto:[email protected]>> wrote:
Hi again,
I just did a test. Connected to the farm, then I can find an
entry for my laptop IP in the file in /proc/net/xt_recent/ :
192.168.161.191....................................jeudi 27
février 2014, 10:44:16 (UTC+0100)
(I used a script found there, if someone is interested:
http://forums.fedoraforum.org/showthread.php?t=224461)
I just closed my browser, and then in around 30s to 1min, my
entry is gone. So apparently when the TCP session is gone, the
entry is gone and the persistence is lost. Is this expected or do
I misunderstand something?
I was expecting that the persistence should be kept, regardless
of the current active session, at least as long as the TTL is not
over. So here normally when I close my browser, the TTL should
start counting from 3600 to 0 and then only my persistence should
be erased.
Thanks
tibz
On 27/02/2014 10:34, tibz wrote:
Hi Laura,
Thanks for the information.
I was wondering because we are having issues with a web
application since we switched to a L4 farm. It "seems" some
users are switched to the other backend before the end of the
persistence, and therefore they loose their session and get
disconnected from the application. We are waiting for the
provider to help troubleshooting these errors, but so far when
we run with only one backend, we see far less disconnection
error (though there are still a few).
A last question, I've found that the recent information are
stored under /proc/net/xt_recent/ but I wonder if the files (and
therefore the persistence) is cleared when the farm is
restarted, or does it stay? In another way: can I restart a L4
farm without loosing the persistence?
Thanks
On 25/02/2014 20:49, Laura Garcia wrote:
Hi, yes the L4 farm should behave like the TCP farm in that
subject.
By other hand, you're absolutely right regarding the TTL field
and the farm is not reloaded automatically. This is a bug and
will be fixed in the next release. Good catch!
Thank you.
On Fri, Feb 21, 2014 at 11:44 AM, tibz <[email protected]
<mailto:[email protected]>> wrote:
Hello,
Can someone please confirm that it works as in TCP Farm
with PEN, so
it's the inactivity timeout and not the max session length
? (ie: 3600s
means 1h with no traffic before we remove the persitence)
Also a little feature enhancement, when a L4 farm is
started and you
change the persistence time, it says "The sessions TTL for
ZLB-ULG farm
has been modified." but it's NOT applied, it's just written
in the
config file.
It would be worth mentionning next to this message that a
restart of the
farm is needed...
Thanks
tibz
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid
Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified
tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate
reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Zenloadbalancer-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/zenloadbalancer-support
