Re: Does anyone use anycast DHCP service?
From: Leo Bicknell <bicknell () ufp org>
Assuming your DHCP servers are properly clustered, simply have your routers relay all requests to both servers. Here's instructions on setting up ISC DHCPD for redundant (pooled) servers: http://www.madboa.com/geek/dhcp-failover/ .. Works great, no single point of failure, no anycast.
It may very well work *most* of the time, or during controlled failover, but it looks pretty creaky to me. Some thoughts: 1) No third-party "witness" service for the cluster, making split-brain scenarios a very real possibility. 2) Multi-master databases are quite challenging in practice. This one appears to rely on timestamps from the system clock for conflict detection, which has been shown to be unreliable time and again in the application space. 3) There are single points of failure. You've traded hardware as a single point of failure for "bug-free implementation of clustering code on both DHCP servers" as a single point of failure. In general, software is far less reliable than hardware. I think it would be far more reliable to simply have two independent DHCP servers with mutually exclusive address ranges, and have one system be secondary and "delay" its responses by 2s so it always "loses" when the primary is up and running well. Yes, you lose the ability for clients to get the same IP during a lease refresh if the primary is down, but that is a small price to pay for simplicity and robustness. -- RPM
In a message written on Mon, Aug 13, 2012 at 08:54:09AM -0500, Ryan Malayter wrote:
1) No third-party "witness" service for the cluster, making split-brain scenarios a very real possibility.
The ISC implementation is designed to continue to work with a "split brain". I believe the Microsoft solution is as well, but I know less about it. There's no need to detect if the redundant pair can't communicate as things continue to work. (With some caveats, see below.)
2) Multi-master databases are quite challenging in practice. This one appears to rely on timestamps from the system clock for conflict detection, which has been shown to be unreliable time and again in the application space.
You are incorrect. The ISC implementation divides the free addresses between the two servers. The client will only interact with the first to respond (literally, no timestamps involved). Clients talking to each half of a split brain can continue to receive addresses from the shared range, no timestamps are needed to resolve conflicts, because the pool was split prior to the loss of server-to-server communication. There is a down-side to this design, in that if half the brain goes away half of the free addresses become unusable with it until it resynchronizes. This can be mitigated by oversizing the pools.
3) There are single points of failure. You've traded hardware as a single point of failure for "bug-free implementation of clustering code on both DHCP servers" as a single point of failure. In general, software is far less reliable than hardware.
Fair enough. However I suspect most folks are not protecting against hardware or software failures, but rather circuit failures between the client and the DHCP servers. I've actually never been a huge fan of large, centralized DHCP servers, clustered or otherwise. Too many eggs in one basket. I see how it may make administration a bit easier, but it comes at the cost of a lot of resiliancy. Push them out to the edge, make each one responsible for a local network or two. Impact of an outage is much lower. If the router provides DHCP, the failure modes work together, router goes down so does the DHCP server. I think a lot of organizations only worry about the redundancy of DHCP servers because the entire company is dependant on one server (or cluster), and the rest of their infrastructure is largely non-redundant. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Mon, Aug 13, 2012 at 9:10 AM, Leo Bicknell <bicknell@ufp.org> wrote:
The ISC implementation is designed to continue to work with a "split brain". I believe the Microsoft solution is as well, but I know ... You are incorrect. The ISC implementation divides the free addresses between the two servers. The client will only interact with the first to respond (literally, no timestamps involved). Clients talking to each half of a split brain can continue to receive addresses from the shared range, no timestamps are needed to resolve conflicts, because the pool was split prior to the loss of server-to-server communication.
There is a down-side to this design, in that if half the brain goes away half of the free addresses become unusable with it until it resynchronizes. This can be mitigated by oversizing the pools.
Glad to hear it is a better design than my first skimming of the documentation indicated. Essentially,an ISC DHCPD cluster is basically two independent servers, with the added optimization of replicating reservations from one system to the other so it can answer renewals when possible. I still wonder what happens when a renewal happens during failover, and then the original server comes back on-line, and a renewal of the same address happens during startup. Hopefully any node joining a cluster waits until it is fully synchronized before answering queries. I've seen so many two-node "HA pair" setups go horribly sideways during my IT career, I usually assume the worst. Firewalls, load balancers, stackable switches, databases, SANs, you name it. They all usually survive the "pull the plug on one node" test during QA, but that's about it. -- RPM
I think it would be far more reliable to simply have two independent DHCP servers with mutually exclusive address ranges, and have one system be secondary and "delay" its responses by 2s so it always "loses" when the primary is up and running well.
Yes, you lose the ability for clients to get the same IP during a lease refresh if the primary is down, but that is a small price to pay for simplicity and robustness.
That depends on your scenario. In some situations it is important to get the same IP. In other situations, using potentially double the address space is unacceptable. If these points are not a problem for you, I certainly agree that two independent servers are potentially more reliable than a clustered setup. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Sent from my iPad On 2012-08-13, at 12:18 PM, sthaug@nethelp.no wrote:
I think it would be far more reliable to simply have two independent DHCP servers with mutually exclusive address ranges, and have one system be secondary and "delay" its responses by 2s so it always "loses" when the primary is up and running well.
Yes, you lose the ability for clients to get the same IP during a lease refresh if the primary is down, but that is a small price to pay for simplicity and robustness.
That depends on your scenario. In some situations it is important to get the same IP. In other situations, using potentially double the address space is unacceptable.
As some have noted, your environment may dictate which is better (HA with software considerations, or retention of IP lease information). Example: In an ISP environment, I would suggest that you consider prefix delegation for IPv6 (--assuming you plan on IPv6 at some point ). For traditional IPv4 networks (ISP), changing the WAN side IP address occurs often enough that it's annoying, but tolerable. When we consider IPv6, changing the WAN side IP is also reasonable (IA_NA). But if you plan on supplying the home network a prefix delegation (IA_PD), you get into some problems if you wind up renumbering the home network. Not sure if this example fits your profile, but at this point, I would not consider a deployment of any major system without considerations of IPv6. Regards, Victor Kuarsingh
participants (4)
-
Leo Bicknell -
Ryan Malayter -
sthaug＠nethelp.no -
Victor Kuarsingh