|
Hi Folks (just not signing this with gpg, lvs-users-owner reject
message type ;-)),
I'm having some struggles with LVS here.
Running Director with:
* Linux 2.6.9 on HT Xeon 3.00G
* Debian ipvsadm v1.24 2003/06/07 (compiled with popt and IPVS v1.2.0)
* 2x BroadCom BCM5703X Gigabit Ethernet (lan-wan) (tigon3 driver at
100Mbit Full duplex)
* Load Balancing Squid via LVS-DR over internal LAN to 10.0.0.x. With
2 machines.
Case 1:
- Each night the realservers are updated in this way:
* LVS remove realserver-1, run updatescript for realserver 1, LVS add
realserver 1
* Next realserver
So each realserver will be updated each day.
The realserver is taken offline by executing:
# /sbin/ipvsadm --delete-server -t $VIRTUAL_IP:$port -r $realserver
and the server is set back online by using:
# /sbin/ipvsadm -a -t $VIRTUAL_IP:$port -g -r $realserver -w $weight
When LVS removed the server, all connections will be forwarded to the
other realservers. But when the updated realserver comes back it LVS
restores the connection counters too... This is not the problem, but
it *seems* this connections never loop out the hashtable.
Our site here is update at 3:00am and there are 'no' clients online,
so i should not have many open connections.
Here's a table of my experience with a cron-jobbed 'ipvsadm --list'
6 day uptime weight active inactive
-> realserver-2:webcach Route 50 790 2825
-> realserver-1:webcach Route 50 607 2959
7 days uptime
-> realserver-2:webcach Route 50 969 3485
-> realserver-1:webcach Route 50 648 3212
8 days uptime
-> realserver-2:webcach Route 50 1054 3932
-> realserver-1:webcach Route 50 653 3546
9 days uptime
-> realserver-2:webcach Route 50 1069 4492
-> realserver-1:webcach Route 50 682 4050
10 days uptime
-> realserver-2:webcach Route 50 1054 4507
-> realserver-1:webcach Route 50 655 4071
11 days uptime
-> realserver-2:webcach Route 50 1044 5193
-> realserver-1:webcach Route 50 709 4616
12 days uptime
-> realserver-2:webcach Route 50 1109 5791
-> realserver-1:webcach Route 50 695 4957
13 days uptime
-> realserver-1:webcach Route 50 790 5301
-> realserver-2:webcach Route 50 1253 6572
14 days uptime
-> realserver-2:webcach Route 50 1285 7017
-> realserver-1:webcach Route 50 824 5853
15 days uptime
-> realserver-2:webcach Route 50 1678 7946
-> realserver-1:webcach Route 50 1031 6541
16 days uptime
-> realserver-2:webcach Route 50 1705 9036
-> realserver-1:webcach Route 50 1115 7240
17 days uptime
-> realserver-2:webcach Route 50 1656 9103
-> realserver-1:webcach Route 50 1054 7295
18 days uptime
-> realserver-2:webcach Route 50 1699 10154
-> realserver-1:webcach Route 50 1085 8053
19 days uptime
-> realserver-1:webcach Route 50 1155 8681
-> realserver-2:webcach Route 50 1757 11265
20 days uptime
-> realserver-2:webcach Route 50 1735 12062
-> realserver-1:webcach Route 50 1150 9261
21 days uptime
-> realserver-1:webcach Route 50 1226 9879
-> realserver-2:webcach Route 50 1797 12827
22 days uptime
-> realserver-2:webcach Route 50 2044 13726
-> realserver-1:webcach Route 50 1311 10500
23 days uptime
-> realserver-2:webcach Route 50 1978 14981
-> realserver-1:webcach Route 50 1312 11211
24 days uptime
-> realserver-2:webcach Route 50 1988 15003
-> realserver-1:webcach Route 50 1310 11248
25 days uptime
-> realserver-2:webcach Route 50 1838 15823
-> realserver-1:webcach Route 50 1258 11777
You see... how more often I took the servers offline en set them back online,
the more inactive connections LVS creates... And I'm very sure this
is is not because my site is growing ;-)
The ActiveConn field is too large at midnight. My Squids says they
transfer less than 1 request per second at 03:00am.
Case 2:
- I get clients complaining that their SSL connections gets broken
when tunneling through our proxy. I don't have any idea where to
search this. Sometimes the solution is to point the proxy directly
to a realserver, otherwise this is not a solution for everybody (got
someone who is using Citrix NFuse through our LVS-Squid setup and the
connection suddenly breaks after some minutes . Maybe this is a
squid issue? Is there a squid setting to keep CONNECT sessions open,
not breaking after some minutes (disconnecting after 2 minutes).
Someone having this problem too?
Thank you very much.
Regards, Janno.
--
Janno de Wit
DNA Services B.V.
|
