An Overview of Hybrid Cloud Database Server Architecture

A hybrid cloud environment uses a mix of private and public cloud and even on-premises services and offers many advantages, including scalability, high availability, faster deployments and effective disaster recovery. One known challenge with this environment is seamlessly managing data movement between environments. Therefore, it is essential to have a good hybrid database architecture design to keep things appropriately synchronised between the different environments. This blog gives you an overview of two different hybrid cloud database architectures, along with their benefits and shortfalls.

Active-Active Database Architecture

The active-active database architecture across the private and public cloud ensures redundancy of the services. Here, we place some of the database nodes in our private cloud/on-prem, and other nodes in public cloud. One of the concerns for making active-active or multi-write nodes is the latency between the private and public.

As you might be aware, active-active allows you to send and distribute traffic to any of the nodes in a hybrid cloud database environment. If one of the nodes is slower when applying the changes, it will impact the whole cluster as active/active replication uses synchronous methods. A good example of active-active would be Galera Cluster for MySQL or MariaDB. It is also possible to place a MongoDB ReplicaSet across the hybrid setup.

Active-Passive Database Architecture

There are different types of active-passive setups. One can be to have one primary, with all secondaries replicating from it. The other way is to set up chained replication, using an intermediate master.

Primary-Secondary Database Architecture

The master-slave database architecture consists of one primary and multiple secondaries. We can put the master in our private cloud, and the secondaries can be spread between private and public cloud as shown below:

In this case, if the private cloud has issues, we can failover/switchover the traffic to the public cloud, promote one of the secondaries in a public cloud, and then re-configure the rest of the them to follow the new primary node.

Primary-Secondary Chained Replication Architecture

Another approach for active-passive database architecture, through chained replication. So here, we will have an intermediate master on a public cloud, with another slave replicating off it. The database architecture for chained replication is shown below:

The benefit of chained replication in a hybrid cloud setup is, if the private cloud has issues, we just need to promote the “Intermediate Master” node to become a new master. The rest of the secondaries can still follow the primary node in the public cloud, so they would not need to failover.

Conclusion

Running hybrid cloud for database architecture relies on the connectivity between the private and public cloud. Also, it depends on the workload of the application side and security whether the data can be copied across the nodes in a mixed environment.

To get an idea of how you can simplify the operational aspects of running this scheme, try out ClusterControl’s Enterprise license with full support free for 30 days (no CC required).

And to ensure that you stay up-to-date with the latest database ops news, concepts and techniques, sign-up for our monthly newsletter or follow us on LinkedIn or Twitter.