Simon,

Thank you very much, this would be very beneficial for us to get working.. I 
did try the timeout value as you suggested and if I only send one request every 
second (since that appears to be as low as I can make it) then everything works 
fine, one DHCP packet is sent to one real server, the next DHCP packet is sent 
to the next real server.. unfortunately I am running tests at about 500 DHCP 
ACKs per second, so the timeout never happens and all the packets still go to a 
single real server. 

What can I do to help get "Julian Anastasov's" one packet scheduler patches 
into the 2.6 kernel as this appears to be exactly what we need?

Thanks again,
Brian Carpio

-----Original Message-----
From: Simon Horman [mailto:ho...@verge.net.au] 
Sent: Saturday, March 27, 2010 5:22 PM
To: Brian Carpio
Cc: linux-ha@lists.linux-ha.org
Subject: Re: [Linux-HA] UDP / DHCP / LDIRECTORD

On Fri, Mar 26, 2010 at 12:57:36PM -0700, Brian Carpio wrote:
> Hi,
> 
> Currently I have a very unique situation where I need to load balance DHCP 
> ACKs to two different real servers, my issue (and this hopefully is just a 
> simple configuration issue) is that when we test our ldirectord load balacner 
> all the DHCP ACKs go to a single "real server"  if the source port is not 
> randomized, we solved this problem in our test lab by changing our test 
> application to randomize the source port if this is done then one DHCP ACK 
> goes to one real server, the next DHCP ACK goes to the other real server, 
> everything is perfectly load balanced, the problem is that in our production 
> environment the device which sends us the DHCP ACKs is not randomizing the 
> ports, all the DHCP ACKs come from the same source port 8000 so ldirectord 
> sends all the requests to the same "real server" (even if I send 1,000,000 
> DHCP ACKs in two hours) here is a look at my config:
> 
> checktimeout=10
> checkinterval=2
> autoreload=yes
> logfile="/var/log/ldirectord.log"
> quiescent=yes
> virtual=lbvip01:67
>         real=server01:67 masq
>         real=server02:67 masq
>         protocol=udp
>         checktype=ping
>         #persistent=1
>         scheduler=rr
> virtual=lbvip01:68
>         real=server01:68 masq
>         real=server02:68 masq
>         protocol=udp
>         checktype=ping
>         #persistent=1
>         scheduler=rr
> 
> 
> I have tried to set and comment out the persistent setting but it doesn't 
> seem to make any difference.
> 
> Hopefully I am missing something.

Hi Brian,

I think that the problem that you are seeing is that LVS regards
a series of packets with the same SRC_HOST:SRC_PORT and DST_HOST:DST_PORT
as a connection of sorts and thus sends them to the same real-server.
This is separate from the behaviour of persistence which broadends
the rule by ignoring the SRC_PORT.

You may be able to mitigate this behaviour to some extent
by setting a very low timeout on UDP "connections" using ipvsadm --set.
However I suspect that due to implementation details of LVS that
very short timeouts won't work as well as one might hope.

A better solution to this problem is Julian Anastasov's one packet
scheduler patches[1,2]. Unfortunately it seems to be rather out of date,
based on the 2.4 kernel. I would be happy to work with you on getting
it into the mainline 2.6 kernel.

[1] 
http://docs.huihoo.com/hpc-cluster/linux-virtual-server/HOWTO/LVS-HOWTO.ipvsadm.html#one_packet_scheduler
[2] http://www.ssi.bg/~ja/#lvs_patches


No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.791 / Virus Database: 271.1.1/2771 - Release Date: 03/29/10 
00:32:00
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to