I have written before about the load-balanced FusionPBX cluster I offer to the public. Now, I will write about the high availability one. In order 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 high availability FusonPBX cluster.
First thing I need to clarify that a high availability cluster is not a load balanced one. 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 high availability 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 not make a difference in this case, as for their point of view, they are just connecting to a single IP. The database will replicate the information with the other node.
In the very case of a high availability cluster, information flows are almost the same as a stand-alone deployment. The big difference is the database which it is external. Although you may think why not to let the database in the PBX, beside the future performance issues, when the active node goes down, the database will be as well. Depending on the kind of the crash, the database could not recover easily.
When a fault tolerance event happens, the endpoints will keep pointing to the same IP. The floating IP technique used in the high availability PBX cluster detects when the active node stops answering and it is here when the passive node takes the floating IP. When the move happens, the now new active server will notify the neighbours it is now the new holder of the floating IP and it will run a FreeSWITCH recovery process. The end user will only notice a dead air for quite some seconds after that conversations will continue normally.
The following image shows the fault tolerance event.
When the faulting server recovers, it has a new role as the passive node. The roles will switch when the actual active node fails.
I hope this gives you a very clear picture of the way a high availability FusionPBX cluster works.
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.
blog comments powered by Disqus