In theory, this is a great idea, particularly in regions prone to tornadoes or other localized natural disasters. However, there are a number of pros and cons that you need to weigh to determine whether or not georedundancy is appropriate for your network.
To ensure reliable delivery of service, you need network connectivity at every stage of device provisioning and service delivery. If you are doing failover between geographically diverse sites, you must ensure that your network connectivity is low latency and extremely reliable. This is because with active-active or active-standby high availability, failover partners rely on their network connections to communicate database changes or transactions. For instance, when a DHCP server allocates an IP lease, it must communicate to its HA failover partner the details of that transaction so that the risk of a DHCP “split-brain” scenario where the change only operates on one half of the pair is minimized.
This may require redundancy in network connectivity where it didn’t exist previously, since same-site redundancy is different to geographically diverse redundancy. Specifically, you need a holistic view of service delivery to ensure that you can maintain consistent subscriber uptime at every stage of the service delivery chain.
This holistic view of network connectivity brings me to the next consideration: integration. It doesn’t really make sense to keep DHCP servers geographically redundant if other parts of your network are still co-located and using same-site redundancy. Do you have geographic resilient redundancy for CMTSs, BNGs, DSLAMs, provisioning databases, etc?
For a truly geographically redundant network, you need to ensure that all servers that are part of the critical path to delivering service to subscribers are geographically diversified. It doesn’t make sense to have georedundant DHCP if the database that holds the DHCP subscriber data is not geographically diverse. This is where network complexity comes in.
Cost and Complexity
Clearly, geo-redundancy increases network complexity. It also increases costs. Not only do you need a separate physical location for your data center, but you also require staff to run it and potentially additional hardware for server and other networking equipment required to support the data center. On top of that, you need to consider the additional network connectivity and integration requirements that I’ve already outlined in this blog. For smaller operators in particular, the costs involved in this level of network complexity may make georedundancy unachievable.
That’s not to say that you shouldn’t consider a georedundant architecture for your provisioning system; however, this should be part of a wider conversation of failover on your network to truly be beneficial.
Want to learn more? Gain further insight about failover options for DHCP here.