As stated before, the load-balanced FusionPBX Cluster will allow you to register some endpoints in different servers while you can communicate between extensions within the same context. While this is really cool, it could present a CPU cost. A non-optimized cluster like this will force the FreeSWITCH to proxy the RTP flow, which in my opinion, it is useless and it wastes precious CPU resources.
The following image shows the SIP/RTP flow.
As you see, regardless the PBXes are smart enough to identify if a user is registered locally or if it is in registered in a peer, the RTP flow flows between PBX`1 and PBX 2. Now, lest imagine worst case scenario, let's think we have transcoding. I do not need to explain the advantage and disadvantages of this, but just remind you that transcoding is CPU hungry.
Nagios is an awesome monitoring tool, if you know how to configure it correctly it will not only help system and network administrators to know where the failure is, but it can help non-IT people such as customer care and sells to know about the system status or specific services actions.
One of the hardest things to carry on with Nagios is that you usually don't have a window always open or not always in front of the computer. If you are an IT guy, that could be easily fixed by installing a Nagios client on your cell phone, I recommend you to give a try to TiNag. But if you are not an IT guy, TiNag is not what you need. Some could say that email would be enough, but the truth is that cell phones usually check email every 15 mins (or longer), and people don't attend emails right away; emails are not meant to be read on the spot. On the other hand, I believe SMS is the solution. Texts are sent almost in real-time, a text is almost read in the next 30 secs (do not believe me, send a text to someone aside of you and check it).
I will show here how to enable the SMS with Nagios.
If you are looking for a cluster, but you have a low budget, there is another cluster schema you can have. It is what I call all the eggs in the same nest. This approach is not load-balanced and is far to be a high-availability one. It is more a fault tolerance one, which it means you still have some downtime but you can recover very easily.
So, just to be clear. This approach I will write about it is not load balanced, nor high available.