|
Horms wrote:
> On Thu, Oct 13, 2005 at 04:47:23AM -0400, Peter J Milanese wrote:
>
>>Apologies for the mail layout here...
>>
>>Did the conversation go from load balancing dns to using dns to balance load?
>>I
>>
>>If the former, if dns is designed properly (helpful if phones are dhcp), then
>>dns would be inherently robust enough to handle it. I feel that adding hops
>>to measure response/status would be a feature without much benefit.
>>
>>If the later, I agree that all of the above (ok, below) would need to be
>>satisfied. Also, throw persistence out the window.
>
>
> I could rabbit on about this for quite some time. But basically my
> feeling is, if you want to distribute traffic between hosts
> that have fast, reliable links, like a LAN, then LVS is a good option.
> No, an excellent option.
>
> If you want to distribute traffic between geographically separtated
> hosts, then you don't want something like LVS that channles packaets
> through a single location then to another. Something DNS based is
> probably the way to go - though round robin is not nearly smart
> enough for my liking.
>
> In practice, if you do have geographically distributed sites,
> then each site should probably be an LVS cluster. So essentially
> you end up using two techniques to solve different parts of the
> same problem.
>
> I wrote quite a lot of this on supersparrow.org once upon a time,
> its still there if people want to read/play/enhance/...
>
Good morning, Horms and all -
We've touched on a lot of issuse that I have been trying to delal with
here, through the last couple days, on this list. I'm glad to see that
I can extract some good information from it all.
Although your suggestion for a seperate LVS cluster for each
geographically distributed site is a good one, and one I've given great
consideration to, there's still one more point there that would then
itself rely on some sort of round-robin approach.
We are developing a few applications which need to authenticate against
certain servers on the Internet. It is imparative that this application
can communicate with one of the servers at any given time, else the
system as a whole is not useable. Because there's never a guarantee
that we will be able to hold on to IPs indefinitely, and an equally
disappointing task to rely on DNS as a starting point for load balancing
because of having to worry about TTLs not being agreed upon, I was going
to create a small list of "dns load balancers" in the application, to
which the application would connect to, and the "dns load balancers"
would do the round-robin approach of things, and in essence, the client
would then be redirected to either the least weighted cluster,
regardless of geographic location, or perhaps even the closest one, via
geographical location.
The reason why we cannot hard-code the hostnames of these geographically
dispursed locations in the application is because over time, more of
these locations would be added to the system as a whole, and it is
unlikely that we'd be able to go back and update the software to
accomodate for these new servers. In order to distribute the load as
evenly as we can, we cannot "assume" to switch the convention by which
we make the client connect to these servers, based on, say, 10,000,000
users, and just "hopping" on to the next cluster. Take into
consideration, even, fiascos such as the L3/Cogent split, and you'll see
how unreliable this approach is, as well.
I think the only solution at this point is to have the application
connect to some sort of master distribution center, a machine which
would poll the LVS clusters, and dnamically organize them all inside a
flat text file, listed as CSV, indicating priority, descriptions, IP
addresses (thereby completely circumventing DNS altogether), and any
other misc information that we'll need to throw in there. This list
would be dynamically generated every 10 seconds or so, and the client
application would download this file and parse it every, say, hour. By
convention, it's a terrible approach, but I think that's the only
feasable ultimate solution here.
I know this was a long email, but I hope that others might be able to
think of ways around DNS using the information that I have provided.
With any luck, someone's going to say "Hey Dan, you moron - do it this
way...", and teach me a thing or three ;)
Thanks for the time
-dant
|
