Atlas Multi-Cloud Global Cluster: Always Available, Even in the Apocalypse!
Rate this article
In recent years, "high availability" has been a buzzword in IT. Using this phrase usually means having your application and services resilient to any disruptions as much as possible.
As vendors, we have to guarantee certain levels of uptime via SLA contracts, as maintaining high availability is crucial to our customers. These days, downtime, even for a short period of time, is widely unacceptable.
MongoDB Atlas, our data as a service platform, has just the right solution for you!
If you haven't yet set up your free cluster on MongoDB Atlas, now is a great time to do so. You have all the instructions in this blog post.
MongoDB Atlas offers a very neat and flexible way to deploy a global database in the form of a Global Sharded Cluster. Essentially, you can create Zones across the world where each one will have a shard, essentially a replica set. This allows you to read and write data belonging to each region from its local shard/s.
To improve our network stability and overhead, Atlas provides a "Local reads in all Zones" button. It directs Atlas to automatically associate at least one secondary from each shard to one of the other regions. With an appropriate read preference, our application will now be able to get data from all regions without the need to query it cross-region. See our Atlas Replica Set Tags to better understand how to target local nodes or specific cloud nodes.
MongoDB 4.4 introduced another interesting feature around read preferences for sharded clusters, called Hedged Reads. A hedged read query is run across two secondaries for each shard and returns the fastest response. This can allow us to get a fast response even if it is served from a different cloud member. Since this feature is allowed for
non-Primary read preferences (like nearest), it should be considered to be eventually consistent. This should be taken into account with your consistency considerations.One of the latest breakthroughs the Atlas service presented is being able to run a deployment across cloud vendors (AWS, Azure, and GCP). This feature is now available also in Global Clusters configurations.
We are now able to have shards spanning multiple clouds and regions, in one cluster, with one unified connection string. Due to the smart tagging of the replica set and hosts, we can have services working isolated within a single cloud, or benefit from being cloud agnostic.
To learn more about Multi-Cloud clusters, I suggest you read a great blog post, Create a Multi-Cloud Cluster with MongoDB Atlas, written by my colleague, Adrienne Tacke.
When you set up a Global Cluster, how it is configured will change the availability features. As you configure your cluster, you can immediately see how your configuration covers your resiliency, HA, and Performance requirements. It's an awesome feature! Let's dive into the full set:
| Ability | Description | Feature that covers it |
|---|---|---|
Low latency read and writes in <SHARD REGION> | Having a Primary in each region allows us to query/write data within the region. | Defining a zone in a region covers this ability. |
| Local reads in all zones | If we want to query a local node for another zone data (e.g., in America, query for Europe documents), we need to allow each other zone to place at least one secondary in the local region (e.g., Europe shard will have one secondary in America region). This requires our reads to use a latency based readPreference such as nearest or hedged. If we do not have a local node we will need to fetch the data remotely. | Pressing the "Allow local reads in all zones" will place one secondary in each other zone. |
| Available during partial region outage | In case there is a cloud "availability zone" outage within a specific region, regions with more than one availability zone will allow the region to still function as normal. | Having the preferred region of the zone with a number of electable nodes span across two or more availability zones of the cloud provider to withstand an availability zone outage. Those regions will be marked with a star in the UI. For example: two nodes in AWS N. Virginia where each one is, by design, deployed over three potential availability zones. |
| Available during full region outage | In case there is a full cloud region outage, we need to have a majority of nodes outside this region to maintain a primary within the | Having a majority of "Electable" nodes outside of the zone region. For example: two nodes in N. Virginia, two nodes in N. California, and one node in Ireland |
| Available during full cloud provider outage | If a whole cloud provider is unavailable, the zones still have a majority of electable nodes on other cloud providers, and so the zones are not dependent on one cloud provider. | Having multi-cloud nodes in all three clouds will allow you to withstand one full cloud provider failure. For example: two nodes on AWS N.Virginia, two nodes on GCP Frankfurt, and one node on Azure London. |
After we have deployed our cluster, we now have a fully global cross-region, cross-cloud, fault-tolerant cluster with low read and write latencies across the globe. All this is accessed via a simple unified SRV connection string:
1 "mongodb+srv://user:myRealPassword@cluster0.mongodb.net/test?w=majority"
This cluster comes with a full backup and point in time restore option, in case something really horrible happens (like human mistakes...).
I don't think that our application has anything to fear, other than its own bugs.
To show how easy it is to manipulate this complex deployment, I YouTubed it:
To learn more about how to deploy a cross region global cluster to cover all of our fault tollerence best practices, check out the video.
Covering our global application demand and scale has never been easier, while keeping the highest possible availability and resiliency. Global multi-cloud clusters allow IT to sleep well at night knowing that their data is always available, even in the apocalypse!
If you have questions, please head to our developer community website where the MongoDB engineers and the MongoDB community will help you build your next big idea with MongoDB.
Rate this article