Since DHCP is a critical network service, it is important for the designer to take steps that will make it fault tolerant. DHCP does not have a built-in method of fault tolerance. DHCP servers do not communicate with each other, letting the other know which addresses are allocated and whether or not it is still in operation. To create a fault tolerant DHCP service, the designer needs to manually create a fault tolerant design using scopes and/or clustering.
Splitting scopes is a method to create DHCP fault tolerance. It is the process of creating two scopes, one on each DHCP server. The two scopes both service the same subnet, but the range of addresses is divided. If one DHCP server becomes unavailable, the remaining DHCP server continues to service DHCP client requests using its portion of the address range. So where is the address range split? That is determined by the needs of the network implementation.
The 50/50 method of splitting scopes provides both fault tolerance and load balancing for DHCP servers. In this method, 50% of the available address range is given to one scope, and the remaining 50% is given to the other scope. Typically this method is used when both DHCP servers are centrally located on the same subnet. When a DHCP client requests an IP address, the request is received by both servers and both respond with an offer. The client then accepts one of the offers (i.e., the first offer received). The selected DHCP server allocates the address and sends the acknowledgement to the client.
The 50/50 method of splitting scopes can only be implemented where the number of available IP addresses is plentiful. This allows each scope to fully service the number of DHCP clients requesting addresses in the event that one of the DHCP servers fails.
The 80/20 method of splitting scopes provides fault tolerance in a subnetted environment. In the 80/20 method, two DHCP servers are configured. One DHCP server resides on the subnet the scope is servicing. The other DHCP server is on another remote subnet.
80% of the available address range is allocated to the local DHCP server. The remaining 20% is allocated to the remote DHCP server. The router connecting the subnets is configured with a DHCP relay agent that will forward DHCP requests to the remote DHCP server. When a DHCP client on the local subnet sends out a DHCP request, the local DHCP server responds first with an offer. The remote DHCP server’s request arrives later since it needs to traverse the WAN. The DHCP client then accepts the offer from the local DHCP server. In the event that the local DHCP server fails, the client eventually receives a response from the remote DHCP server.
The downside of the 80/20 method is that the remote DHCP server, with only 20% of the available address space, will not be able to handle all DHCP requests from the subnet.
In Windows 2000, Microsoft added a new capability to the DHCP service, called clustering. A cluster is a group of servers (typically two nodes) that work in unison. By working together, the nodes provide load balancing and fault tolerance for the services the cluster provides. To the rest of the network, the cluster looks like a single server. By combining the DHCP service and clustering, a type of DHCP failover can be achieved.
The DHCP Server included in Windows 2000 is a cluster-aware application. This means that in the event that one node in the cluster fails, the DHCP service can be restarted on the surviving node. This is accomplished because the DHCP database, which houses all current address leases, is shared between the nodes. When the second node takes over, it is completely aware of all outstanding IP address leases and will not give out duplicate IP addresses.
Since the cluster itself appears as a single entity to the network, DHCP clients continue to communicate with the cluster’s IP address. They are completely unaware that the second node in the cluster is responding to their requests.
Clustering is Microsoft’s recommended strategy for DHCP fault tolerance in Windows 2000.