On Sun, 2009-03-15 at 11:23 -0500, Brad Knowles wrote: > 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.
That would be cool. Thanks. > > > 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. So? And how many people work in that environment? Yes, it is there, and a lot of people use the system. But, it is invisible to the users. Look at how many people manage load-balanced server farms. And how many people in that group, use anycast? You are going to find the percentage quite small. Usually when you do use anycast, it is on-top of a standard NAT/next-hop/proxy based cluster. (And to be clear, I said "Usually" not "Every".) > > 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. No, but if someone wants to do it, I would say "go ahead, but here are the caveats..." It might work enough for there needs. One of the things I had learned at Seagate, was that the business requirements need things to be "done." My head kept having the requirement of "done right." I had to meet in the middle. > > > 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. Sounds like you are attempting realtime replication. That is very hard. Mainly because it is impossible to get 0 latency. > > > 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. > Ok, so what is the purpose of the LOPSA "Tech" mailing list? Since it seems that all Tech topics have their own lists. <sarcasm>I guess we should disband this list. And, everyone should go a subscribe to the 150 lists pertaining to all the topics of interest.</sarcasm> These topics are not outside the list's stated topic. Just because there is a "better" place to discuss a specific topic, does not make this an inappropriate place to also discuss it. It is inappropriate when it becomes off-topic for the list. Now, I am going to stop here, as this has gotten off-topic for this list. (Also, I am starting a new job tomorrow, so I won't have time to continue down the philosophical rabbit hole. I was just bored this weekend.) -- 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/
