In addition to failover, which is active/active no matter how you set the split value and which comes with its own headaches, you might also consider an appliance-based solution that offers HA clustering.
I work for BlueCat, and we offer dhcpd on Linux including features designed to support failover. But we also have an HA clustering feature which can work between data centers, as long as a layer 2 VLAN can be stretched between the two sites. Then only one appliance would be active at a time, with all leases written to disk in both servers. The cluster has a VIP, an IP address which floats between the two appliances.
I apologize for sounding like a commercial. Please note that BlueCat is not the only vendor offering this kind of solution. Different vendor offerings have different strengths and weaknesses, so you should evaluate which one best fits your needs.
Hope this helps.
Chris Buxton
Sent from my iPhone
> On Mar 6, 2018, at 8:07 AM, Pereida, Alejandro <
[hidden email]> wrote:
>
> We would like redundancy to support the existing addresses (about 80
> address pools), yes both the active Datacenter and DR center are
> permanently tied
> Together via a redundant 10Gb fiber link
>
> On 3/6/18, 5:13 AM, "dhcp-users on behalf of Simon Hobson"
> <
[hidden email] on behalf of
[hidden email]>
> wrote:
>
>> "Pereida, Alejandro" <
[hidden email]> wrote:
>>
>>> We have been using a single Linux server as our DHCP server running ISC
>>> DHCP Server 4.3.1
>>> We are building a ³secondary datacenter² for disaster recovery
>>> purposes. What is the most recommended
>>> Option for implementing a redundant DHCP server scenario in case the
>>> main datacenter (where the DHCP server resides)
>>> goes dark?
>>
>> You need to expand a bit - is this to support the existing addresses, or
>> another range, or something else ? And are the sites permanently
>> networked together ?
>>
>> In principle, all you need to do is add another server in a failover pair
>> - and then both servers will support the same address range(s). Given the
>> additional hop, it's likely that the on-site server will handle requests
>> most of the time as it'll get a reply back to the clients first.
>>
>> _______________________________________________
>> dhcp-users mailing list
>>
[hidden email]
>>
https://lists.isc.org/mailman/listinfo/dhcp-users>
> _______________________________________________
> dhcp-users mailing list
>
[hidden email]
>
https://lists.isc.org/mailman/listinfo/dhcp-users>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users