on 3/15/09 6:09 AM, Robert Hajime Lanning said: > Can't read it. Not a member. Sorry. I'll see if I can get to it in > October, when it is available.
I'll see if I can find the PDF version I have, and send that to you. > 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. Actually, in some places it is used within server farms. The ISC approach (described at <http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.html>) is not the only one. In practice, anycast has been successfully applied to DNS, as f.root-servers.net has over 50 public installations around the world, and probably at least a hundred more private ones. Most anyone can get their own private copy of f.root-servers.net, if they ask. All of those machines answer for the same IP addresses. In theory, this should cause problems with TCP-based connections, when routes change, etc.... In practice that has not shown to be an issue. However, even though both protocols use UDP, NTP != DNS. With NTP, there's a lot more state stored by the client with regards to their servers, and it's stored for long periods of time -- days, weeks, months, years, or more. If you can give me a 100% guarantee that there will never, ever be any route flaps over that period of time, then maybe this isn't an issue for you. But that doesn't mean that this is a best practice that others should follow, and it doesn't mean that you should be encouraging others to do the same. > 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) I run the LDAP servers for the uTexas Enterprise Directory system (see <http://www.utexas.edu/its/ted/>), and we have three production LDAP servers behind a pair of Netscaler fail-over load-balancing switches. We have had issues with some of the servers getting out of sync. > 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. We're working on re-architecting the system to try to reduce or eliminate the synchronization problems, but just because your systems have always worked perfectly over their entire history doesn't mean that others haven't had significant issues. > It is not hard. Depends on how you try to change the one engine for the plane while it's in the air. > 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. No, I wouldn't say they don't know anything. But although I am subscribed to this list, and I've been supporting the NTP Public Services Project for over five years and I have some experience I can share with people, this still is not the appropriate place to discuss NTP. However, I can tell you where the appropriate place is, over on the mailing lists I help run at lists.ntp.org. Although I have been supporting the Mailman project, a member of the Mailman steering committee, and the primary person running the mail systems for python.org for over five years, does not mean that this is the appropriate place to discuss Mailman. Again, I can tell you where the appropriate mailing lists are (for which I am the primary active listowner), over on mail.python.org. I see no difference for LDAP. -- 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/
