DHCP Failover with Microsoft Server 2012 R2
One of the great features in Windows Server 2012 R2 is the DHCP failover for Microsoft DHCP scopes. For those who have experienced Microsoft DHCP management in Windows 2000/2003/2008 you will recall that one of the long requested features was a true load balancing and failover option.
Prior to Windows Server 2012 the only failover option was to have full copies of the scope definitions on a secondary server with the scope disabled. You would have to manually enable to scope in the event of a failure at the primary server, but this would be time consuming and could cause IP address conflicts as machines requested new IP information from the new DHCP server.
Alternatively, you could load balance the scopes by using the same scope and gateway information, but different portions of the scope are active on each server. This can be done by using a technique known as DHCP scope splitting.
Load Balancing versus Failover
One of the first things that can confuse many Systems Administrators is the difference between load balancing and failover. They aren’t always mutually exclusive, so it is even more important to understand the key differences.
Load balancing is the use of an active-active configuration which shares services between multiple nodes which may be spread among remote sites for safety and redundancy. In application environments, load balancing will be configured based on a balancing algorithm that may be as simple as round robin, and as complex as route cost based on latency and response for service delivery by locality.
Failover is where the environment suffers an outage of a service which triggers the failover of that service function to a secondary server or site. The assumption for most failover configurations is that the primary server is completely unavailable. With our DHCP failover, we can actually mix the two roles of failover and load balancing by operating the scope on multiple servers across your data centers. This hybrid operational model greatly reduces the risk of service loss.
What about our DHCP Configuration on Network Equipment?
As you may already know, we require configuration at our routers, and potentially Layer 3 switches, to make our client nodes aware of the DHCP servers that are servicing the subnet. This is done with the DHCP Relay Agent, sometimes known as the DHCP Helper address.
By defining the DHCP Relay, any nodes on that switch with access to the appropriate VLAN will go through the normal process of requesting an IPv4 DHCP address. This is done with the DHCPDISCOVER request which is forwarded by the router to the DHCP server by the DHCP Relay Agent. The DHCP server returns a DHCPOFFER, followed by a DHCPREQUEST, and finally a DHCPACK confirming the IP address and lease information.
This is all good, but what happens in the case where we have more than one DHCP server, and require multiple DHCP Relay Agent addresses at the router? This is a great question, and it explains why we will really appreciate the new Windows Server 2012 R2 DHCP services.
If we have multiple 2003/2008 DHCP servers, the scopes must be disabled on the second server, otherwise both DHCP servers will be replying to the DHCPDISCOVER broadcast and may hand out the same IP address to more than one workstation since they aren’t aware of each other.
Under Windows Server 2012 R2, we have the new failover DCHP model that has the primary server actively servicing DHCP requests, and the failover instance is aware of, but not active in the process.
Let’s take a look at the configuration of a failover scope before we go any further.
Configuring a DHCP Failover Scope
There is no difference in the base configuration of a DHCP scope to prepare it for being protected with a failover scope on a secondary server. Here is a sample scope named Failover Scope A (10.20.30.0/24) that we configure just like a normal scope.
The IP address configuration is also done in the typical way that we have done in any DHCP server up to this point.
Now that we have our demo scope available, we will right-click the Scope in the DHCP Manager console and select Configure Failover:
The Failover Configuration wizard opens up with a list of scopes that are available to protect. In our sample, we have the 10.20.30.0/24 scope:
Next up we are asked about assigning a partner server for our scope. We will be using one named PartnerServer in our example:
By default, a name is chosen for the replication relationship name. It is ideal to pick something that will be meaningful to your team for continued management.
The parameters in our failover relationship allow us to set the failover mode which can be Active-Active (Load balance) or Active-Passive (Hot standby). In load balancing mode, there is an option to set the weight of the scope distribution at the partner. The default is a 50% split scope.
In this case, we are configuring a Hot standby server.
You will need a shared secret password configured:
Once you complete the failover scope wizard, the process will complete and the scope will be created on the target server. The process will show the status as successful for each of the steps in the wizard:
With the scope configured for hot standby failover, we now have a fully operational scope that is getting asynchronous updates from the source server to keep track of current leases, reservations, options, and any other scope-specific configuration parameters. It’s just that easy!
For our own curiosity, it is good to check what the failover scope looks like. You simply open the target DHCP partner server, expand the scopes and right-click the failover scope in the DHCP Manager window. On the properties page there is a Failover tab which displays all of the information about the connection.
Now that failover is configured, you will also see additional options available on the context menu for the protected scope. Using these options, you can remove the failover configuration, force replication of the scope, and force replication of the relationship information:
Options outside the GUI
If you’ve been managing DHCP up to this point on Windows 2008 or earlier servers, you will know that most of the configuration is done in the GUI. In fact, much of the configuration was only available in the GUI in previous versions.
Under Windows Server 2012 and Windows Server 2012 R2, PowerShell has become vastly more powerful and important in the Microsoft ecosystem. New and enhanced DHCP Cmdlets are available by simply importing the DHCP Server module. This is done with a simple one-liner Import-Module DHCPServer as you can see below.
Once loaded, we can query all of the DHCP CmdLets using Get-Command *dhcp* as shown partially here:
Better Features and Better Management
This is a great step forward with the Microsoft DHCP tool set which provides better failover options, better load balancing options, and more options for managing the environment. By extending the management into a scriptable format with PowerShell, this is an excellent tool for administrators to move towards more orchestration of their Microsoft DHCP environments.