Currently, many applications in the telecommunications industry use databases based on a document collection, as an information repository.
An example of this is MongoDB, which is a general-purpose, document-based database.
Need to know if your database is running slow? Check out these tips to make the most out of your database.
As a summary, this application is classified as a NoSQL database, which uses JSON-like documents (for more information, please refer to https://docs.mongodb.com/).
This component is incorporated into mission-critical platforms, usually as a repository of transactional information, which must be fault-tolerant and have high availability.
For this case, on its website, Mongo indicates that for a multisite architecture, at least three different sites are required.
Since most cable operators have two data centers, that is why this option is presented, which has given outstanding results.
The proposal is based on the use of operating system’s high availability packages, in this case, Linux, configuring them to manage additional resources and thus be able to move them from one data center to another depending on the state of the equipment.
So, the following items must be added to the necessary architecture,
- An additional IP address to be considered as floating
- Additional packages of high availability of the Operating System. For this particular case, Linux is presented (Linux-HA, Pacemaker / Corosync)
- Multisite firewall rules that allow the operation of this solution
Graphically, it is presented like this:
In the graph shown above, it is presented schematically and modularity. It shows in yellow the modules and resources that must be managed by the operating system’s high availability packages.
Possible Operating Scenarios that Can Be Presented
Normal state
Both sites are operating in a normal state. In this case, the floating IP will be associated only with one of the APPs, and only one arbitrator will be available.
In this way, the instances will see the active referee through the floating IP
Datacenter #1 with Arbiter and additional IP
Floating IP attached to APPs located in datacenter #1. Both MongoDB instances reach its arbiter via floating IP.
Arbiter in a sleep state in APP’s machine in datacenter #2.
Datacenter #2 with Arbiter and additional IP
Floating IP attached to APPs located in datacenter #2. Both MongoDB instances reach its arbiter via floating IP.
Arbiter in a sleep state in APP’s machine in datacenter #1.
Abnormal State
A single site is running. This situation may be presented because of an infrastructure issue or a maintenance window.
In this case, the floating IP will be associated only with one of the APPs, and only one arbitrator will be available. This management is done by high availability modules
In this way, the instances will see the active referee through the floating IP
Datacenter #1 in downstate
High Availability applications (Linux-HA, Pacemaker / Corosync) detect site failure and set floating IP and Arbiter on in the datacenter# 2.
Datacenter #2 in downstate
High Availability applications (Linux-HA, Pacemaker / Corosync) detect site failure and set floating IP and Arbiter on in the datacenter# 1.
As you can see, in both scenarios (Normal state and Abnormal State), MongoDB instances reach its arbiter through the floating additional IP address.
By applying this option, high availability can be obtained for platforms that use MongoDB as a database without the need to have three physically distributed sites.
Need to know if your database is running slow? Check out these tips to make the most out of your database.