On Sun, 2009-03-15 at 02:42 -0500, Brad Knowles wrote:
> on 3/14/09 3:27 PM, Robert Hajime Lanning said:
>
> > 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.
>
> There are certain stages in the protocol where a server can be
> permanently marked as dead/insane. You don't get those back until you
> restart the NTP client.
Personally I think that is a horrible design. A clock goes mad. I find
out and replace it. Now, I have to hunt down every client?
Problem with things designed by theorists. Some practical issues get
missed.
>
> If the upstream NTP server in question is not marked permanently
> dead/insane, then the client will continue to monitor it and if it comes
> back into the world of sanity, then it might be chosen to participate in
> the process of selecting the best truechimer.
>
> However, if you're behind a load balancer, and you can't guarantee that
> all incoming packets from a given client are always directed to the same
> backend server, then the client will notice that your server id, jitter,
> etc... aren't consistent and you won't be one of the final candidates.
> That is unless there are no other final candidates, in which case you've
> got the loonies running the bin.
Right, I already covered this. It becomes a (very) bad candidate.
Technically, you can make them look the same, but the jitter is the most
difficult to solve.
>
> > Even BIND self heals for it's query order with NS records and
> > forwarders.
>
> BIND will periodically re-test the NSes that it knows of for a given
> zone, and continually try to adjust to sending the vast majority of
> traffic to whichever server gives it the best response time.
>
> But there are certain states that BIND can get into that cannot be
> cleared without a restart of the program. With BIND, that is an
> implementation flaw, because the code isn't supposed to work that way.
> But with NTP, there are certain states where the algorithm says you're
> supposed to mark a particular server as being permanently dead/insane.
BIND issues as you state, would be a bug. NTP see above.
>
> > Actually with anycast, it is just fine, unless your route is flapping.
>
> No, it's not. I don't care if you are an anycast expert, if you're not
> also an NTP expert, then you can't understand why this is wrong.
>
> I tried to explain in my article in _;login:_ magazine the issues that I
> was aware of in this space, and I will refer you to that for the extent
> of my understanding. But I do know that this is just the tip of the
> iceberg on this subject.
Can't read it. Not a member. Sorry. I'll see if I can get to it in
October, when it is available.
>
> > 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.)
>
> I know how anycast works. And I have an idea of why it's horribly wrong
> for use with NTP.
>
> You don't need to teach me how anycast works, and unfortunately it is
> clear that I am not the right person to teach you how NTP works. I've
> done the best I can, but I've only been doing this for about five years
> or so, not the ten or twenty years of some of the real experts.
Sorry, I wasn't teaching you how anycast works. I assumed that you
already knew, since you were the one who brought it up.
You should notice, that my emails are not addressed to you, they are
addressed to the list. So some expansion might be seen for the list's
benefit.
Anycast is not a widely used load-balancing technique. As it requires
multiple geographically dispersed datacenters. It is not used within
server farms, which most people are familiar with.
>
> > 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.
>
> Any large server farm can have a significant delay between one server
> being updated and another, thus resulting in inconsistencies.
And how many 1000 node LDAP server clusters have you seen? (ie. the
original question was putting a few LDAP servers behind a load-balancer
for HA)
>
> Heck, the server farm doesn't have to be that large for there to be
> surprisingly large temporal differences as to when one server is updated
> as compared to a different server. There's all sorts of things that can
> get in the way.
>
Seagate runs a suite of 5 read-only LDAP servers for their hole
corporation behind an F5 Big-IP load-balancer. (With a mirror on the
other side of the globe.) There is a suite of 3 writable LDAP server
behind the same Big-IP, though different pool. This runs their identity
management for the company.
It is not hard. There are a lot of ways to do data replication. You
can replicate and activate as separate steps, if you require
synchronization. Or, the way LDAP is usually handled, with serial
replication. (Your new password will be available in five minutes.)
Don't let technical perfectionism get in the way of practical business.
(I have to be careful of this, as I have a strong perfectionist streak
in me and have been hit over the head with this a few times.)
> > 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."
>
> If you can tell Howard Chu how LDAP works, by all means you should go
> ahead and do so. However, over the year-plus that I've been involved in
> this subject, it has become very clear to me that there are a lot of
> people who seem to think they know LDAP, and relatively few who actually
> do. I know that I'm one of those people who doesn't know as much about
> the subject as I would like.
>
> Most of those who actually do know something about LDAP, and are in some
> sort of place where regular people could actually talk to them, are on
> the OpenLDAP mailing lists -- Like Howard Chu or Quanah Parker.
>
> I don't know about you, but I'd rather not try to refer people to
> experts that they don't actually have any chance of being able to get in
> contact with.
Right, and who said I wanted to tell Howard Chu or Quanah Parker
anything? I did not say it was wrong to point to the list. I just did
not like the blanket statement that THE list was THE ONLY place.
It really comes across like you are saying that the people on the LOPSA
list don't know anything.
It's good to refer to a known authoritative source. But don't go around
saying it is the only source. That is just wrong and demeaning to others.
I have implemented LDAP. I have load-balanced LDAP. So have others on
this list. New people wanting to implement and load-balance LDAP can
learn from the experience of those on this list. Not just from the ones
developing the software/protocol, but those implementing it in businesses.
There are quite a few people like me, who know a lot about a lot of
protocols, that don't have the time to monitor every list for every
protocol they know. The LOPSA list is a good place to ask and answer
questions of this type.
--
END OF LINE
--MCP
_______________________________________________
Tech mailing list
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
