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:[EMAIL PROTECTED] 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>
