Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux Virtual Server: Users

[lvs-users] Understanding lb_algo and weighting.

 

 

Linux Virtual Server users RSS feed   Index | Next | Previous | View Threaded


leon.pinkney at network-box

Oct 13, 2009, 4:08 AM

Post #1 of 5 (372 views)
Permalink
[lvs-users] Understanding lb_algo and weighting.

Hi,



We are looking into ways to use LVS to better our current techniques.



I want to load balance http proxy across 3 boxes. Users point at one of
those 3 boxes.



ipvsadm -l

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheduler Flags

-> RemoteAddress:Port Forward Weight ActiveConn InActConn

TCP 10.10.10.51:webcache sh

-> 172.16.254.1:webcache Local 4 237 1669

-> 172.16.254.2:webcache Masq 10 246 1520

-> 172.16.254.3:webcache Masq 10 172 1675



Now my understanding was that sh would ensure each IP would always end
up with all of it's requests going to one machine.



I expected the weighting would split each IP across the boxes, giving
the first box less work to do.



Clearly my understanding appears to be wrong since the first box has the
most connections, when I would expect it to have less than half of the
other two. Can someone enlighten me ?



Is there a better way to achieve this ?



Thanks,



Leon



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

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


horms at verge

Oct 13, 2009, 4:40 PM

Post #2 of 5 (339 views)
Permalink
Re: [lvs-users] Understanding lb_algo and weighting. [In reply to]

On Tue, Oct 13, 2009 at 12:08:41PM +0100, Leon Pinkney wrote:
> Hi,
>
>
>
> We are looking into ways to use LVS to better our current techniques.
>
>
>
> I want to load balance http proxy across 3 boxes. Users point at one of
> those 3 boxes.
>
>
>
> ipvsadm -l
>
> IP Virtual Server version 1.2.1 (size=4096)
>
> Prot LocalAddress:Port Scheduler Flags
>
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
>
> TCP 10.10.10.51:webcache sh
>
> -> 172.16.254.1:webcache Local 4 237 1669
>
> -> 172.16.254.2:webcache Masq 10 246 1520
>
> -> 172.16.254.3:webcache Masq 10 172 1675
>
>
>
> Now my understanding was that sh would ensure each IP would always end
> up with all of it's requests going to one machine.
>
>
>
> I expected the weighting would split each IP across the boxes, giving
> the first box less work to do.
>
>
>
> Clearly my understanding appears to be wrong since the first box has the
> most connections, when I would expect it to have less than half of the
> other two. Can someone enlighten me ?

Hi Leon,

other than a weight of 0, which means don't accept any now connections,
weights are currently ignored by the sh scheduler.


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

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


leon.pinkney at network-box

Oct 13, 2009, 11:58 PM

Post #3 of 5 (337 views)
Permalink
Re: [lvs-users] Understanding lb_algo and weighting. [In reply to]

Simon,

Thanks for the reply. Using sh is important to mee, since I'd like to
keep a users session through one box only, it makes logs easier to
correlate.

Is there a way I can achieve the above, and have differently weighted
real servers ?

Thanks,

Leon

-----Original Message-----
From: Simon Horman [mailto:horms[at]verge.net.au]
Sent: 14 October 2009 00:40
To: Leon Pinkney
Cc: lvs-users[at]linuxvirtualserver.org
Subject: Re: [lvs-users] Understanding lb_algo and weighting.

On Tue, Oct 13, 2009 at 12:08:41PM +0100, Leon Pinkney wrote:
> Hi,
> We are looking into ways to use LVS to better our current techniques.
> I want to load balance http proxy across 3 boxes. Users point at one
of
> those 3 boxes.
>
> ipvsadm -l
>
> IP Virtual Server version 1.2.1 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> TCP 10.10.10.51:webcache sh
> -> 172.16.254.1:webcache Local 4 237 1669
> -> 172.16.254.2:webcache Masq 10 246 1520
> -> 172.16.254.3:webcache Masq 10 172 1675
>
> Now my understanding was that sh would ensure each IP would always end
> up with all of it's requests going to one machine.
>
> I expected the weighting would split each IP across the boxes, giving
> the first box less work to do.
>
> Clearly my understanding appears to be wrong since the first box has
the
> most connections, when I would expect it to have less than half of the
> other two. Can someone enlighten me ?

Hi Leon,

other than a weight of 0, which means don't accept any now connections,
weights are currently ignored by the sh scheduler.


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

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


misch at multinet

Oct 14, 2009, 12:07 AM

Post #4 of 5 (339 views)
Permalink
Re: [lvs-users] Understanding lb_algo and weighting. [In reply to]

Am Mittwoch, 14. Oktober 2009 08:58:49 schrieb Leon Pinkney:
(...)
> Simon,
>
> Thanks for the reply. Using sh is important to mee, since I'd like to
> keep a users session through one box only, it makes logs easier to
> correlate.
>
> Is there a way I can achieve the above, and have differently weighted
> real servers ?
>
> Thanks,
>
> Leon

Hi,

make a central logging server. Than it is very easy to correlate logs from all
of your servers.

--
Dr. Michael Schwartzkopff
MultiNET Services GmbH
Addresse: Bretonischer Ring 7; 85630 Grasbrunn; Germany
Tel: +49 - 89 - 45 69 11 0
Fax: +49 - 89 - 45 69 11 21
mob: +49 - 174 - 343 28 75

mail: misch[at]multinet.de
web: www.multinet.de

Sitz der Gesellschaft: 85630 Grasbrunn
Registergericht: Amtsgericht München HRB 114375
Geschäftsführer: Günter Jurgeneit, Hubert Martens

---

PGP Fingerprint: F919 3919 FF12 ED5A 2801 DEA6 AA77 57A4 EDD8 979B
Skype: misch42

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

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


horms at verge

Oct 14, 2009, 1:35 AM

Post #5 of 5 (333 views)
Permalink
Re: [lvs-users] Understanding lb_algo and weighting. [In reply to]

On Wed, Oct 14, 2009 at 07:58:49AM +0100, Leon Pinkney wrote:
> Simon,
>
> Thanks for the reply. Using sh is important to mee, since I'd like to
> keep a users session through one box only, it makes logs easier to
> correlate.
>
> Is there a way I can achieve the above, and have differently weighted
> real servers ?

Hi Leon,

>From an LVS point of view, I think that the most logical approach would be
to look at enhancing the sh scheduler - that is modify ip_vs_sh.c in
the kernel.

However, as Michael Schwartzkopff suggested in another email in this
thread, a non-LVS solution to this portion of the problem may be worth
considering.


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

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

Linux Virtual Server users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.