“To Geo or Not to Geo…”?

I’m often asked by operators whether georedundancy is a necessary requirement for provisioning systems. While I’d like to be able to give a clear yes or no answer, the reality is a little more complicated.

Georedundancy refers to the physical separation of data centers between geographic locations. The argument for georedundancy is that it provides resiliency against catastrophic events and natural disasters, such as fires, tornadoes, or other situations that might cause you to lose a data center for a period of time. By physically separating your servers in geographically diverse data centers, you can be sure to have one location up and running, even if the other one fails.

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.

Network Connectivity

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.