On Sat, 2009-03-14 at 11:05 -0500, Brad Knowles wrote:
> on 3/13/09 9:54 PM, Robert Hajime Lanning said:
>
> > On Fri, 2009-03-13 at 20:26 -0500, Brad Knowles wrote:
> >> For example, putting NTP time servers behind load balancers
> >> are a really bad idea.
> >
> > The only real issue with load-balancers, is with applications/clients
> > that keep server state, outside of a single transaction. Since the next
> > transaction could be on a different server.
> >
> > With the NTP reference above, the NTP client keeps offset/jitter
> > information about each server (based on IP) that is references. So,
> > unless the server pool is in EXACT lock step time synchronization, the
> > clients will see a large jitter factor for the cluster IP.
>
> No, that's not the only problem. If just one server behind that load
> balancer goes whacko, then all clients which contacted it through the
> load balancer will mark the load balancer as bad, and will never use
> anything through the load balancer again.
I didn't say it is the only problem. Also, are you absolutely positive
that it will NEVER use ANYTHING through the load-balancer again? That
would be kind of a stupid design, if it wasn't self healing. Especially
since it keeps track of the history of all NTP servers it was told to
reference. You can see the outcome of this via "ntpq -p". (This is all
outside of the administrative kill packet.)
Even BIND self heals for it's query order with NS records and
forwarders.
> NTP already has built-in techniques for auto-discovery, reducing load to
> servers, balancing load, high availability, etc.... You shouldn't try
> to defeat those and destroy the very basis for the NTP protocol by
> putting NTP servers behind a load balancer.
>
> Same deal for doing NTP to IP addresses that are distributed via anycast
> techniques.
Actually with anycast, it is just fine, unless your route is flapping.
Anycast is quite different from a server farm load-balancer. For one,
it is not arbitrary or load based. It is geographical or route
proximity based. So, with anycast, you only change servers when there
is some failure (either server or route failure.)
> But that is just an example of how you have to understand the nature of
> the protocol and how it's used, before trying to put servers for that
> protocol behind something like load-balancers.
Right, which was my point about client-server state relationship.
Which all comes down to the fact that the client side is keeping server
state. And any time you load-balance a service where the client keeps
this information, the load-balancer needs to be aware of it, or you
don't load balance in that manner.
> Obviously, LDAP != NTP, but there may still be some subtle issues that
> need to be considered when you're looking at particular solutions, and
> the only people who might know what those subtleties are would be the
> experts on the mailing lists, etc... for the application in question.
LDAP is pretty much like an SQL query. A TCP connection is made and
authenticated in some form. A data query is sent and a response is
made. There is no server state, just the database consistency. So, the
only issue with LDAP load-balancing is keeping the data consistent
between all servers in the pool. Unless you are doing thousands of
updates a second, this is not a hard task.
BTW, the "experts on the mailing lists, etc... for the application in
question" will not be the "only people who might know what those
subtleties are."
--
END OF LINE
--MCP
_______________________________________________
Tech mailing list
Tech@lopsa.org
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
