Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Today, I have published in OKay's RPM repository RPMs for the DigitalOcean Pacemaker Resource 0.1. It is well known that DigitalOcean provides floating IP capabilities with the VPS it provides. This resource script enables the floating IP move from the failed server to the new active using Pacemaker.

RPM's are available for Centos 6 and 7. And you can find it if you type yum search resource-agents-digitalocean-floatip.

The DigitalOcean Pacemaker Resource requires that all involved VPS'es to be in the same data centre.

Enjoy!

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

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.

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

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.

generic fusionbx cluster sip rtp not optimized 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.