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, and the endpoints do not realize 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 a high availability cluster needs at least seven servers, 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 a 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).
Pros, 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 from being a standalone server. I recommend reading 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 to have no service
Now the cons:
- The passive servers may be considered a waste of resources
Now, some side effects:
- Each time you make 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 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 least one node to be up and running to keep in 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 the load balance on the high-level view.
Fault Tolerance
As this approach is a mix, the following table helps to understand.
| Kind of failure | Fault Tolerance Approach |
| Data centre failure | Load Balancing |
| One SIP node fails in one data centre | High Availability |
| Two SIP nodes fail in the same data centre | Load Balancing |
How do I get a Cluster like this?
Easy, just send me a text on 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!
";