[Freeswitch-users] High Availability Cluster Module for FreeSWITCH

[Eliot Gable]

On Sun, Feb 10, 2013 at 3:40 PM, Avi Marcus <avi at avimarcus.net> wrote:

> Steve:
> Several reasons.
> One is the mod_ha_cluster is an N+1 Cluster, not a active/passive pair.
> That way if any single node fails, there's something to pick up the slack.
>
> Secondly, in order to recover live calls, you need a list of the calls.
> That currently requires some sort of odbc (or postgres) with replication.
> Again, that's abstracted as part of mod_ha_cluster.
>
> Third: The docs mention a similar of pooling for registration, that you
> can register to one server and you're regged on them all without needing a
> DB to sync everything.
>
> Fourth, according to the docs: single configuration for all FS instances,
> rather than manually ensuring each one has the same config.
>
> Fifth: Voicemail clustering? Or we'll have to wait for mod_voicemail's
> APIs to be rewritten for that, perhaps...
>
> There's certainly *something *special possible with mod_ha_cluster that
> can't be done with existing solutions cleanly, if at all...
>
> -Avi
>

Thanks, Avi, for the voice of support, and for actually reading my
documentation. :)

First, however, I need to correct you on one point. I have actually
designed mod_ha_cluster as a N + x cluster, meaning N master nodes and x
slave nodes. What this means is that you can get better availability than
having 1 slave node, while also getting more cost effective scalability
than having 1 slave node per master (which is all that is really possible
with most other solutions). So, for example, you could run 16 master nodes
and 3 slave nodes in the clusters. In addition, you do not need to deal
with the cost of a database system to synchronize the calls and
registration information between all the nodes. Keep in mind, also, that
you would also then have to have that database system set up in a high
availability configuration, and it would have to be a pretty big box to
handle the load from so many servers. So, bottom line is that
mod_ha_cluster can dramatically reduce the cost of deploying a high
availability solution for FreeSWITCH, as well as ease the configuration.
The reduced deployment complexity not only makes it more approachable for a
much larger audience, it can also actually improve availability simply due
to fewer components involved and fewer places failures or bugs to cause
issues.

Also, as you pointed out, this is more than simply a high availability
module. It is also a clustering module. This means it shares registration
information, call limiting information, call state, and all sorts of other
essential information. Using a shared disk resource, you can have voicemail
and menus shared between multiple nodes and your entire set of potentially
dozens of nodes can act as one single cluster on a single DNS address.

Because of the N + x design, you can use smaller nodes in your cluster and
scale by adding more nodes vs adding more horsepower to individual nodes.
 And, as Avi pointed out, this means that if a single node fails, you have
other nodes to pick up the slack. Using Pacemaker and Corosync with an
active/passive configuration, 16 master nodes requires an additional 16
slave nodes of the same size. That is a lot of unused and expensive gear.
Using mod_ha_cluster, you could take those 32 nodes and run 4 as slaves
while the other 28 are active. That's a much more efficient and effective
design.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130210/539761cc/attachment-0001.html