Colin Campbell wrote:
> On the ISC web site there is/was (can't seem to find it) a discussion
> paper on using DNS for "high availability". The basic argument was that
> it's a waste of time because most clients don't observe TTLs and often
> cache DNS lookup results anyway. So even though you've dropped an entry
> from your DNS, the client might not ask again for minutes/hours/days.
Partly true, but in reality it will work pretty well for the majority of
the clients. But yes, some stupid clients might get stuck with old DNS
data. In most cases the only action required by the user if things go
wrong is to close their browser and open a new one.
For more information on this application of DNS and it's
problems/benefits, read up on lbdns. It is not a dead end, but as you
say it is not entirely problem free either.
There are a number of alternatives for "high-availability" setups:
a) TCP load balancer (commonly referred to as TCP switch) in front of
the caches.
+ Works great
- Costs $$
- Breaks some TCP/IP rules, and some bleeding edge clients might
experience problems from this (i.e. Linux or other OS:es implementing
the latest greates TCP features)
- One more "router" box in the network to manage
b) PAC file.
+ Almost a standard
+ Very flexible
- Old browsers have many incompabilities
- Requires a reliable quite web server from where the PAC file can be
fetched by the clients
- 30 seconds delay every 30 minutes while the primarily selected proxy
is completely down (no answer on the IP). More on UNIX.
- Requires the location of the PAC file to be configured in the
browser settings
c) WPAD, automatic discovery of the PAC file location
+ Very flexible
- Not widely supported. Only modern IE browsers I think
d) DNS load balancing
+ Can be applied to any IP service, at any distance
- Somewhat unreliable failover due to client side DNS caching
e) Machine clustering
+ Quite flexible
- Requires clustering software
My vote for proxies is either TCP load balancing, or active clustering
where other members of the cluster takes over the IP address(es) of the
failed machine.
-- Henrik Nordström Squid hacker -- To unsubscribe, see http://www.squid-cache.org/mailing-lists.htmlReceived on Fri Dec 22 2000 - 03:46:02 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:57:05 MST