|
Looks like we'll be going with Cisco IOS SLB (Server Load Balancing)
off of one of our 7xxx routers. Thanks againf or all the info, closing
inquiry.
-Chris
----- Original Message -----
From: "Memblin" <memblin@xxxxxxxxxxxxxx>
To: "LinuxVirtualServer.org users mailing list."
<lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Monday, June 02, 2008 8:40 AM
Subject: Re: [lvs-users] Possibly beating a dead horse - IPVS-NAT -
1Director, 2 Realservers
> I appreciate the information. That actually makes
> alot of sense. I think I maybe be able to configure
> it so that I can switch the cluster into production
> and monitor it to see what happens. If it goes bad
> I'll just switch the traffic back to the current production
> box.
>
> Thanks,
> -Chris
>
> ----- Original Message -----
> From: "Graeme Fowler" <graeme@xxxxxxxxxxx>
> To: "LinuxVirtualServer.org users mailing list."
> <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
> Sent: Monday, June 02, 2008 4:50 AM
> Subject: Re: [lvs-users] Possibly beating a dead horse - IPVS-NAT - 1
> Director, 2 Realservers
>
>
>> Hi
>>
>> On Sat, 2008-05-31 at 09:14 -0500, Memblin wrote:
>>> If I remove the realserver from the ipvs config that is currently
>>> getting
>>> all the traffice (say num 1), the traffic does go to the other
>>> realserver
>>> (say num 2). Then when I put number 1 back into the ipvs configuation
>>> the traffice stays with number 2. If I do nslookups from a windows
>>> box it looks like Windows actually asks for like 8 things per single
>>> request and those get spread out between both servers normally.
>>
>> We need to look a bit more deeply here at what's happening.
>>
>> Firstly, you're using NAT - this makes monitoring things a bit easier
>> because the director has an idea of connection state due to it seeing
>> all packets in both directions (in -DR it can have an idea of state but
>> can get a little confused if packets go astray, which is why -DR tends
>> to report "inactconn" rather than "actconn").
>>
>> Secondly, you're configuring a connectionless service. DNS over UDP is
>> "fire and forget" - the application is responsible for retries, rather
>> than the OS protocol stack - and (this is the important bit) UDP is
>> stateless.
>>
>> If you look at the connections from a single client on an unloaded
>> system, you're likely to see what you do see - every packet goes to the
>> same host, because LVS views them as a "session".
>>
>> On the balance of probabilities, a DNS server will receive many
>> thousands of queries from many hundreds/thousands (or more) of hosts.
>> Over time from a cold start to fully loaded, they will be shared out
>> amongst the realservers according to the scheduler being used and the
>> weight assigned (a word of advice - set the weights to something higher
>> than 1. It makes future tuning *far* easier if you start with everything
>> having a weight of 100, say).
>>
>> You could also look at "ipvsadm --set" and tune down the UDP timeout to
>> something like one or two seconds.
>>
>> Unfortunately, using a small number of clients (where small is some
>> number greater than 0) doesn't give real-world results.
>>
>> Graeme
>>
>>
>> _______________________________________________
>> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
>> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG.
>> Version: 7.5.524 / Virus Database: 269.24.4/1478 - Release Date: 6/2/2008
>> 7:12 AM
>>
>>
>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
>
>
> --
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 269.24.4/1478 - Release Date: 6/2/2008
> 7:12 AM
>
>
|
