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. 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. > 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. > 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. > 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. > 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. 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. > 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. -- Brad Knowles <[email protected]> If you like Jazz/R&B guitar, check out LinkedIn Profile: my friend bigsbytracks on YouTube at <http://tinyurl.com/y8kpxu> http://preview.tinyurl.com/bigsbytracks _______________________________________________ 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/
