[f-nsp] Load balancing DNS servers on a ServerIron 8XL
Drew Weaver
drew.weaver at thenap.com
Thu Oct 26 11:06:19 EDT 2006
Real Server State CurrConn TotConn TotRevConn CurrSess
PeakConn
DNS1 6 3617 1310263637 0 8658 8973
DNS2 6 31 1400061407 0 62 9791
this kind of illustrates what im talking about
0 removed 192.168.7.242 53 60951 UDP SLB 61 0000 n/a
1 removed 192.168.28.130 53 3606 UDP SLB 61 0000 n/a
2 removed 192.168.27.242 53 6991 UDP SLB 61 0000 n/a
3 removed 192.168.6.82 53 53012 UDP SLB 61 0000 n/a
4 removed 192.168.6.130 53 2430 UDP SLB 61 aba n/a
5 removed 10.1.19.50 53 35778 UDP SLB 61 0000 n/a
6 removed 10.1.19.50 53 42366 UDP SLB 60 0000 n/a
7 removed 10.1.29.130 53 57788 UDP SLB 60 0000 n/a
8 removed 192.168.4.170 53 43671 UDP SLB 60 0000 n/a
9 removed 192.168.4.170 53 43702 UDP SLB 60 0000 n/a
10 removed 10.1.19.50 53 58850 UDP SLB 60 0000 n/a
11 removed 10.1.19.50 53 58897 UDP SLB 60 0000 n/a
12 removed 10.1.19.50 53 58906 UDP SLB 60 0000 n/a
13 removed 10.1.19.50 53 58924 UDP SLB 60 0000 n/a
14 removed 10.1.19.50 53 58927 UDP SLB 60 0000 n/a
15 removed 10.1.19.50 53 58932 UDP SLB 60 0000 n/a
16 removed 10.1.19.50 53 58945 UDP SLB 60 0000 n/a
17 removed 10.1.19.50 53 58953 UDP SLB 60 0000 n/a
18 removed 192.168.5.186 53 2959 UDP SLB 60 0000 n/a
19 removed 10.1.19.50 53 60640 UDP SLB 60 0000 n/a
20 removed 192.168.27.242 53 17349 UDP SLB 60 0000 n/a
21 removed 192.168.4.178 53 34116 UDP SLB 60 0000 n/a
22 removed 192.168.5.210 53 1355 UDP SLB 60 0000 n/a
23 removed 10.1.19.50 53 32911 UDP SLB 60 0000 n/a
24 removed 10.1.30.58 53 40175 UDP SLB 60 0000 n/a
25 removed 192.168.0.9 53 26452 UDP SLB 60 0000 n/a
26 removed 10.1.19.50 53 52642 UDP SLB 60 0000 n/a
27 removed 10.1.19.50 53 36364 UDP SLB 60 0000 n/a
28 removed 10.1.30.58 53 40305 UDP SLB 60 0000 n/a
29 removed 10.1.30.58 53 40325 UDP SLB 60 0000 n/a
30 removed 10.1.30.58 53 40340 UDP SLB 60 0000 n/a
31 removed 10.1.30.58 53 40341 UDP SLB 60 0000 n/a
32 removed 10.119.50 53 57704 UDP SLB 60 0000 n/a
33 removed 192.168.31.146 53 4598 TCP SLB 60 0000 n/a
34 removed 192.168.31.146 53 4600 TCP SLB 60 0000 n/a
35 removed 192.168.31.146 53 4634 TCP SLB 33 0000 n/a
36 removed 10.1.22.98 53 3921 UDP SLB 60 0000 n/a
37 removed 192.168.31.146 53 4693 TCP SLB 32 0000 n/a
38 removed 192.168.6.82 53 54389 UDP SLB 60 0000 n/a
39 removed 0.0.0.1 1 1 TCP SLB 60 0000 n/a
40 removed 192.168.6.130 53 2246 UDP SLB 61 0000 n/a
________________________________
From: p.ramesh [mailto:p_ramesh at rocketmail.com]
Sent: Wednesday, September 27, 2006 7:22 PM
To: Tom Samplonius
Cc: Drew Weaver; foundry-nsp at puck.nether.net
Subject: Re: [f-nsp] Load balancing DNS servers on a ServerIron 8XL
Yeah, that's true. Sorry, I overlooked. One problem could be that DNS1
is failing healthchecks. Check logs.
Check the session table for any long-standing session. Default udp
session-age is 5 minutes. So, a session will start at age 57 and ageout
at 62. Check if there are any session stuck in the table with age 58 to
61.
Thanks,
Ramesh
Tom Samplonius <tom at uniserve.com> wrote:
Actually, it is fairly clear that the original poster is already
using
round-robin.
Tom
On Wed, 27 Sep 2006, p.ramesh wrote:
> That's because you have the default load-balacing predictor as
least-connection ( you wont see in the config, because this is default).
>
> dns connections are usually short-lived, connections get
closed pretty fast. First connections goes to DNS2. by the time second
connections comes, there are no existing connections on any of the 2
servers, so Foundry decided to forward the request to DNS2 because of
least-connection predictor. least connections looks at currently how
many total number of connections are handled by any server
>
> Now, configure "server predictor round-robin", you are at
peace and see both servers taking equal number of connections.
round-robin is dumb, first connection go to DNS1, next time go to DNS2,
third request take it to DNS1, and fourth one goes to DNS2.
>
> Foundry is coming out with powerful ServerIron 4G(read 4 Gig
ports) with SSL support, better upgrade to that, its pretty cheap.
>
> -Ramesh
>
> Hope
> Tom Samplonius wrote:
>
> DNS2 might be too slow to respond, or lost a few hundred
requests.
>
> From reading the docs, the SI has special handling for DNS
requests. It
> removes the connection immediately after the response is
processed. So if there
> is no response, the connection will stay around until it is
aged. So if DNS2
> just discarded a bunch of requests, they would sit around as
connections.
>
>
> Tom
>
>
> On Wed, 27 Sep 2006, Drew Weaver wrote:
>
>> Howdy list, been using foundry load balancers for quite some
time.
>> I'm having a hard time understanding one issue.
>> pertinent config:
>>
>> server real DNS1 10.1.0.2
>> port dns
>> !
>> server real DNS2 10.1.0.3
>> port dns
>>
>> server virtual DNS 192.168.0.89
>> predictor round-robin
>> port dns
>> bind dns DNS1 dns DNS2 dns
>>
>> pretty straightforward right?
>>
>> OK, well I was looking at the real server stats and I noticed
that DNS1
>> had 37 active connections whilst DNS2 had 781 active
connections all of
>> the servers/pcs/devices are set to use 192.168.0.89 as their
resolver,
>> so why is there such a hugely unproportinate number of
connections
>> hitting DNS2?
>>
>> Thanks!
>>
>> -Drew
>>
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp at puck.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>
>
>
> ---------------------------------
> Get your email and more, right on the new Yahoo.com
________________________________
Stay in the know. Pulse on the new Yahoo.com. Check it out.
<http://us.rd.yahoo.com/evt=42974/*http://www.yahoo.com/preview>
More information about the foundry-nsp
mailing list