Creating Highly Available mesibo On-premise Clusters

Estimated reading time: 2 minutes

This section explains how to create highly available mesibo On-premise clusters for greater reliability and stability.

mesibo on-premise server is a highly reliable and stable software. However, there are instances when your systems can fail due to other factors, for example, server hardware failure, power outage, networking component failure, or in the worst case, catastrophic events and natural disasters, such as fires, tsunamis, etc, that can bring the data center down for an extended time.

If you are only running a single instance of your server, any such event can result in a service disruption that will severely impact your business. You can safeguard your organization against such outages and service disruption by running multiple instances of your service and hence making your system available all the time, called high availability.

mesibo offers the highest form of high availability configuration, known as M+N redundancy, where the M is the number of active servers which will serve your users and N is the number of the standby server that will take over when one of the active servers will fail. This approach provides resiliency against any kind of failure including catastrophic events by adding standby servers across the globe. M & N varies depending on the type of the account, M is currently 1 for on-premise.

Mesibo Active Standby Server


Creating High Availability mesibo Cluster

When you run multiple instances on mesibo on-premise, mesibo will automatically configure additional instances as standby and hence you don’t need to worry about the high availability configuration.

However, you need to ensure that the hostname and certificate are different for each instance. The reason is that if your active server fails, mesibo will redirect your users to one of the standby servers. If you use the same hostname, your users may again try to connect to the failed server.

Testing High Availability

To test the configuration, run two instances of on-premise with a different hostname or two different servers. You will see from the log that one instance is active and another is on standby.

Now try connecting a few users, they should connect to the active server. Now, shut down the active server and watch logs on the standby server. The standby server should turn active immediately.

Your users which were connected to the previous server may still try to connect to the previous server for some time. After a few retries, they will start connecting to the active server which was on standby earlier.

on-premise, saf, opensaf, high availability, HA, messaging, chat, voice, video