Many people have asked me about the load-balanced FusionPBX cluster I offer to the public. In order to try to answer all your possible question, I am writing this article. I hope after a reading you get a clear picture what it is and what it is not a load-balanced FusonPBX cluster.
First thing I need to clarify that a load-balanced cluster is not a high availability cluster. Although both kinds of approaches are not mutually exclusive (you can combine them), their pros and cons are different and the way they work as well. I will write later a comparison between them, for now just remember it is not the same.
A load-balanced cluster deployment needs at least 5 servers. The following picture shows a basic deployment.
The elements are:
Any cluster holder needs to remember that the cluster is far to be a stand-alone server. There are internal differences; information flows are different and as a consequence, the way it operates is not the same. First, let's list the pros:
Now the cons:
Some side effects that are not good nor bad, but they are different than a stand-alone server:
A cluster's information flow is a little different than a stand-alone FusionPBX server. In a stand-alone deployment, all flows are almost local, then only flow that is external are the ones related to the endpoints or bridging a call to the PSTN. A cluster has some extra flows that cross among the servers.
The endpoints will decide what node to connect by doing DNS requests. When a server connects, the PBX will record some information in the database. The database will replicate the information with the other node.
When a call happens, the receiving PBX will keep all the processing local as much as possible; there is a point in the dial plans that it will need to bridge to an extension. The PBX will then consult the database to know where the desired endpoint is registered. Best case scenario, the extension is registered in the same receiving PBX and the flow will be kept local; worst case scenario, the extension is found active in another server, then the PBX will connect to the other PBX. The other PBX will then connect to its now local endpoint and the call will flow.
When a fault tolerance event happens, the endpoints are the ones who will decide what to do. Thanks to the information from the DNS, the extensions will know who is their second best option and they will connect to the active PBX. Depending on the endpoint brand, some IP Phones may need a reboot; sometimes local DNS caches do not honour the DNS TTL and a router reboot may be needed as well.
The following image shows the fault tolerance event.
The IP Phone that was connected to the PBX 1 now it connects to PBX 2. PBX 1 is the best option for that extension, but as it is not available, it will connect to its second-best option; in this case, the PBX 2.
I hope this gives you a very clear picture of the way a load-balanced FusionPBX cluster works.
Yes, it is possible. I suggest you read my RTP/SDP optimization article to get an idea of what can be done.
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!
blog comments powered by Disqus
Most Read Posts in Technology
About
Read about IT, Migration, Business, Money, Marketing and other subjects.
Some subjects: FusionPBX, FreeSWITCH, Linux, Security, Canada, Cryptocurrency, Trading.