Ensuring high availability of critical network services like DHCP figures high in the list of priorities for any enterprise. In an environment where clients get their IP addresses and network configuration automatically, uninterrupted network connectivity is dependent on the availability of DHCP service at all times. Let us consider for a moment what high availability of DHCP server is intended for:
- Any authorized computer which connects to the network should be able to obtain its IP address and network configuration from the enterprise DHCP service at all times.
- After obtaining an IP address, a computer shouldbe able to renew its lease and continue using the same IP address so that there is no glitch in connectivity.
Windows Server 2012 DHCP provides a new high availability mechanism addressing these critical aspects. Two DHCP servers can be set up to provide a highly available DHCP service by entering into a failover relationship. A failover relationship has a couple of parameters which govern the behavior of the DHCP servers as they orchestrate the failover. One of them is the mode of the failover operation – I will describe this shortly. The other is the set of scopes that are part of the failover relation. These scopes are set up identically between the two servers when failover is configured. Once set up in this fashion, the DHCP servers replicate the IP address leases and associated client information between them and thereby have up-to-date information of all the clients on the network. So even when one of the servers goes down – either in a planned or in an unplanned manner – the other DHCP server has the required IP address lease data to continue serving the clients.
There are two modes of configuring DHCP failover to cater to the various deployment topologies: Load Balance and Hot Standby. The Load Balance mode is essentially an Active-Active configuration wherein both DHCP servers serve client requests with a configured load distribution percentage. We will look at how the DHCP servers distribute client load in a later post.
The Hot Standby mode results in an Active-Passive configuration. You will be required to designate one of the two DHCP servers as the active server and the other as standby. The standby server is dormant with regard to serving client requests as long as the active server is up. However, the standby server receives all the inbound lease updates from the active DHCP server and keeps its database up to date.
The DHCP servers in a failover relationship can be in different subnets and can even be in different geographical sites.
The support of these two modes enables a wide range of deployment topologies. The most rudimentary one is where two servers in a Load Balance or Hot Standby mode serve a set of subnets which are in the same site.
A slightly more involved deployment where failover is being deployed across two different sites is illustrated in Figure 1. Here, the Hyderabad and the Redmond site each have a local DHCP server servicing clients in that site. To ensure high availability of the DHCP service at both the sites, one can setup two failover relationships in Hot Standby mode. One of the failover relationships will comprise all subnets/scopes at Hyderabad. It will have the local DHCP server as the active server with the DHCP server at Redmond as the standby. The second failover relationship will comprise all subnets/scopes at Redmond. It will have the local DHCP server as the active server and the DHCP server at Hyderabad as the standby.
Figure 1: DHCP Failover Deployed Across Two Sites
This deployment construct of two DHCP servers backing up each other for two different set of scopes via two failover relationships is extensible to more than two sites. One can visualize a ring topology involving multiple sites where a server at each site - in addition to being the active server for the local network – is the standby server for another site. The failover relationships can be set up to form a ring topology through the DHCP servers at different sites.
Hub-and-Spoke is another multi-site deployment topology which lends itself quite well to how organizations are looking to deploy failover. Here, a central DHCP server acts as the standby for multiple active DHCP servers each of which serves a different branch office.
Windows DHCP server has so far met the HA requirement by enabling hosting of the DHCP server on a Windows Failover Cluster or by split scope deployments. These mechanisms have their own disadvantages. The split scope mechanism relies on configuring identical scopes on two DHCP servers and setting up the exclusion ranges in such a fashion that 80% of a subnet’s IP range is used for leasing out IP addresses by one of the servers (primary) and remaining 20% by the other server (secondary). The secondary server is often configured to respond to clients with a slightly delayed response so that clients use IP addresses from the primary server whenever it is available. Split scope deployments suffer from two problems. IPv4 subnets often run at utilization rates above 80%. In such subnets, split scope deployment is not effective given the low free pool of IP addresses available. The other issue with split scope is the lack of IP address continuity for clients in case of an outage of the primary server. Since the IP address given out by the primary DHCP server would be in the exclusion range of the secondary server, the client will not be able to renew the lease on the current IP address and will need to obtain a new IP address lease from the secondary server. In the case of split scope, the two DHCP servers are oblivious to each other’s presence and do not synchronize the IP address lease information.
To host the DHCP server on a Windows Failover Cluster, the DHCP database needs to be hosted on a shared storage accessible to both nodes of a cluster in addition to the deployment of the cluster itself. DHCP servers running on each node of the cluster operate on the same DHCP database hosted on the shared storage. In order to avoid the shared storage being the single point of failure, a storage redundancy solution needs to be deployed. This increases the complexity as well as the TCO of the DHCP high availability deployment.
The Windows Server 2012 DHCP failover mechanism eliminates these shortcomings and provides a vastly simplified deployment experience. Moreover, DHCP failover is supported in all editions (Foundation, Standard, Data Center) of Windows Server 2012. As one of the server reviewers aptly put it, this is high availability of DHCP on a low budget!
DHCP failover can be configured using the DHCP MMC as well as the DHCP PowerShell cmdlets. Everything you can do via the MMC for DHCP failover is achievable via the DHCP PowerShell cmdlets as well. The DHCP MMC provides a Failover Setup wizard which greatly eases the setup of failover. There are two launch points in the DHCP MMC from which a user can start the wizard. The right click menu options on the IPv4 node now have a Configure failover… option. If launched from here, all the scopes on the server which are not yet setup for failover are selected for failover configuration. Alternatively, if you select one or more scopes and right click, you will see the same Configure Failover… option. If launched in this fashion, only the selected scopes are configured for failover. Please see the step by step guide to setup failover using DHCP MMC. You can download the “Understanding and Troubleshooting guide” here.
For the command line users, DHCP PowerShell provides the following PowerShell cmdlets for setting up and monitoring failover:
In addition to these, Get–DhcpServerv4ScopeStatistics cmdlet which returns scope statistics has a “-failover” switch. Specifying this switch causes the cmdlet to return failover specific statistics for scopes which are configured for failover.
In conclusion, DHCP failover in Windows Server 2012 provides a high availability mechanism for DHCP which is very easy to deploy and manage and caters to the critical requirements of continuous availability of DHCP service and IP address continuity for the clients. Early adopters of the feature have shared our enthusiasm for this critical DHCP functionality and feedback from them has been very positive.
Give it a spin on Windows Server 2012 Release Candidate and we hope that you will find it useful!