The Ultimate PBX Cluster Overview: Load Balancing + High Availability

I have written before about the different types of FusionPBX clusters. The first one is the one with the load balanced approach, in which it implements the active-active scheme but the fault tolerance relies on the ability of the endpoints to jump to the second best node. The second one is the one with the high availability approach, this is active-passive but the fault tolerance relies on the server end, the endpoints do not realize of any cluster existence. I have also said that each approach does not exclude the other, in other words, you can have a cluster combining the two techniques.

A Cluster Overview

A load balanced with high availability cluster needs at least sever server, but the optimum deployment is with eleven.

There is no need to relist all the elements. Each data centre holds the same configuration:

• two VoIP servers in high availability scheme,
• two database nodes
• one DNS server

In addition, there is an arbitrator server. The arbitrator is required as the database cluster needs to be 2*n+1 nodes (odd number).

Pro, Cons and Side Effects of a Load-balanced with High Availability FusionPBX Cluster

I believe that if you have already read my other articles, I do not need to remind you that the behaviour of this deployment is far to be as a standalone server. I recommend to read them again if you do not remember. However, I will list the outstanding points. First the pros:

• Your service is almost bullet-proof, both data centres need to be down in order to have no service

Now the cons:

• The passive servers may be considered as a waste of resources

Now, some side effects:

• Each time you do a change, you will need to flush the Memcached on all the servers. You may put a crontab to fix this.
• You need to remember that because this is a cluster, and you really do not know what server is being accessed, the file synchronization is not real-time. Real-time synchronization is possible, but it is a waste of resources, it is better to put a policy to sync things each hour.
• Never, but never reboot all the database nodes at once. If you need to reboot, reboot one per one. The Gallera cluster needs at last one node to be up and running in order to keep sync with new ones.
• The router needs to be VoIP friendly, especially with the ARP tables. If your router has any kind of ARP cache, disable it.

Information Flow

The information flow is the same as the high availability approach in each data centre and as the load balanced on the high-level view.

Fault Tolerance

As this approach is a mix, the following table helps to understand.

How do I get a Cluster like this?

Easy, just send me a text in any of my social media accounts. I am sure we will get into an agreement and you will enjoy a brand new PBX Cluster.

Good luck!