What is Geo Redundancy

Geo redundancy refers to the practice of replicating data and applications across multiple geographically dispersed locations. The goal is to ensure that if one location goes offline due to a disaster or other issue, the system can fail over to another location without interruption. Geo redundancy has traditionally only been implemented for mission-critical systems; more recently, cloud-native and edge-native architectures have made geo redundancy commonplace. By investing in geo-redundant systems, businesses can minimize downtime and ensure that their critical systems are always available to users, even in the face of unexpected events.

‍

‍

Why Implement Geo Redundancy

System-level Benefits of Geo Redundancy

Increased Uptime: For maintenance, load can be shifted to alternative servers. 

Improved Disaster Recovery: Businesses should always have backups in the event of a disaster. 

Better Performance: By having multiple sites serving traffic, systems remain responsive and performant even during periods of high traffic.

Increased Security: If one site is compromised, data and applications can failover to another site.

‍

Company-level Benefits of Geo Redundancy

Ensure Business Continuity: Customers rely on your systems, and outages cause disruptions that hurt your customer relationships.  

Protect Your Reputation: The media loves a story of failure. Don’t become tomorrow's unwanted headline.  

Avoid Financial Loss: Data loss or downtime can result in financial penalties that contractual agreements impose. Company valuations can also be impacted. 

‍

‍

The Three Types of Geo Redundancy

Active-Passive Redundancy

Active-passive redundancy is like having a backup superhero waiting in the wings. In this model, the secondary site is passive and only becomes active if the primary site goes offline. To achieve this, data is replicated from the primary site to the secondary site, but the secondary site doesn't serve traffic until it's needed. This allows the backup to utilize less RAM until it’s called to the scene since it only needs to perform write operations when in secondary mode. As a result, active-passive redundancy is a simpler approach than other alternatives. 

Partial Active-Active Redundancy

On the other hand, partial active-active redundancy is like having a team of superheroes that MUST work together to fight crime. In this scenario, multiple sites are active and serve traffic simultaneously. However, it’s critical to denote the partial nature of this form of redundancy. Many systems are built with servers that have a central write database and many read-only copies. Although the full system is active in this scenario, each component is only partially active. Be wary of partially active solutions since they create a write bottleneck in a centralized location leaving the system prone to service disruptions. This also has the potential of adding significant latency between when the data is written and when it is available to read.

Further failover requires that a read-only database becomes a write-only database and that data flow between the databases is instantly updated to reflect the new data flow requirements. This adds significant complexity making the system more prone to error. This type of geo-redundant architecture is used for many legacy database systems like MongoDB.

Fully Active-Active Redundancy

Fully active-active redundancy is like having a team of superheroes that can fight crime independently and together. In this scenario, each Individual database is fully equipped and capable on its own. Currently, this is the holy grail of geo redundancy since failover does not require data flow to be updated at the database level. Instead, both read and write traffic is simply re-routed to the next nearest available server. Further, fully active-active architectures don’t create write bottlenecks at a single central server. 

Traditionally, fully active-active architectures have been overly complex to build, deploy, and manage; however, with modern database technology like HarperDB, fully active-active redundancy is native and just a simple configuration. You can imagine that at scale, having 10 or more geo-redundant databases spread out across the world can create an extremely high availability system in addition to dramatically reducing global latency.  

‍

‍

How to Implement Geo Redundancy

1. Conduct a Risk Assessment

First, conduct a risk assessment. This involves identifying the risks to your systems and determining the potential impact of an outage. This information can then be used to determine the level of redundancy required.

2. Determine Your Redundancy Needs

Based on the results of your risk assessment, you can determine your redundancy needs. This will depend on various factors, including the criticality of your systems, your budget, and your available resources. Active-active redundancy is typically more expensive than active-passive redundancy. However, some modern database solutions today make deploying fully active-active redundancy easy and budget friendly. Whenever possible, it’s best practice to choose database solutions that offer fully active-active redundancy so that your system has the most flexibility already built in to manage future requirements.  

3. Choose Your Replication Strategy

Once you have determined your redundancy needs, you can choose your replication strategy. This will require you to weigh several factors, including where your users are located, the amount of data that needs to be replicated, where the data is hosted, and the level of network connectivity between sites. 

4. Select Your Secondary Site

Your servers should be spread out across multiple availability zones to minimize the risk of multiple sites in the same zone being impacted by a disruption. It should also have sufficient network connectivity to ensure that data can be replicated promptly. Be conscious of all ingress and egress charges when choosing what infrastructure provider to use. Redundancy requires data to move. Consider using infrastructure providers like Linode that charge far less than hyper scalers do on egress. In the long run, making an intelligent choice on the front end could save you millions down the road.

Also, consider where your users are located. Take the opportunity to place data in locations close to your user base. This way, in addition to improving system resilience, you also reduce latency. 

5. Implement Replication

Once you have selected your secondary site, you can begin implementing replication. This typically involves deploying software solutions to replicate data and applications between your sites. It is essential to test your replication solution to ensure that it is working correctly and that data is being replicated as expected.

If going with an application platform or database that handles replication natively, you’ll need to copy your code and data to the new system. Developers that do this experience less technical debt in the long run since they won’t need to continuously update and manage their middleware replication software or custom code.

6. Configure Failover

Finally, the last step is to configure failover. This involves setting up automatic failover procedures that will redirect traffic to your secondary site during an outage. It is essential to test your failover procedures to ensure that they are working correctly and that you can quickly recover from an outage.

For active-passive and partially active-active systems, failover management needs to happen in addition to global routing. However, with a fully active-active system, the database can stay configured the same since every server already performs reads and writes. For fully active-active systems, only internet routing needs to be altered during an outage.

‍

‍

Best Practices for Geo Redundancy

1. Test Your System Regularly

Don’t get caught with something that used to work. Regular testing is critical to ensuring that systems are working correctly. Systems that rely on custom or application-level replication typically need more periodic testing than other, more refined solutions.

2. Choose the Right Replication Solution

There are a variety of replication solutions; it is crucial to choose the right solution for your needs today and tomorrow. Replication systems are typically part of your infrastructure for the long haul, so choosing options that you can grow into is essential. Also, consider the acceptable consistency level; choosing systems that offer exactly-once delivery guarantees is typically your best bet. Also, whenever possible, avoid middleware implementations that will burden you with technical debt down the road.

3. Monitor Your System

Monitoring is critical to ensuring that your geo-redundancy system is working correctly. Using a platform like Datadog allows you to identify many potential issues before they become critical.

4. Plan for Failures

Even with geo redundancy in place, failures could still occur. With mission-critical applications, it could be worth having multiple layers of redundancy and potential point-in-time snapshots of your data. Having a worst-case scenario plan is always a good idea. 

‍

‍

Conclusion

Geo redundancy is a critical component of modern IT infrastructure design. By replicating data and applications across multiple geographically dispersed locations, businesses can ensure that their systems remain available and reliable even during a disaster. Implementing geo redundancy can be a complex process, but by following best practices and taking a systematic approach, you can ensure success. 

Also, it’s advised that you speak with an expert before pursuing any specific replication strategies. If you are curious about what geo redundancy strategies work best for you, our team of experts are happy to help. If interested in speaking with us, please fill out our contact form.

‍

‍

Related Tutorials

Multi-Cloud HarperDB Cluster using Terraform, AWS & Azure

Deploying HarperDB on Digital Ocean & Linode with Terraform

Deploy HarperDB & StackPath to Reduce Latency at the Edge

Simple Multi-Node Table Replication with HarperDB Pub/Sub

How To Deploy a Cross Cloud Data & Application Environment

‍

‍