<div class="gmail_quote">On Sun, Feb 10, 2013 at 3:40 PM, Avi Marcus <span dir="ltr">&lt;<a href="mailto:avi@avimarcus.net" target="_blank">avi@avimarcus.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Steve:<div>Several reasons.</div><div>One is the mod_ha_cluster is an N+1 Cluster, not a active/passive pair. That way if any single node fails, there&#39;s something to pick up the slack.</div><div><br></div>


<div>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&#39;s abstracted as part of mod_ha_cluster.</div><div><br>


</div><div>Third: The docs mention a similar of pooling for registration, that you can register to one server and you&#39;re regged on them all without needing a DB to sync everything.</div><div><br></div><div>Fourth, according to the docs: single configuration for all FS instances, rather than manually ensuring each one has the same config.</div>


<div><br></div><div>Fifth: Voicemail clustering? Or we&#39;ll have to wait for mod_voicemail&#39;s APIs to be rewritten for that, perhaps...</div><div><br></div><div>There&#39;s certainly <i>something </i>special possible with mod_ha_cluster that can&#39;t be done with existing solutions cleanly, if at all...</div>
<span class="HOEnZb"><font color="#888888">

<div><br></div><div><span style="font-family:Verdana,Arial,Helvetica,sans-serif">-Avi</span></div></font></span><div><div class="h5"><div></div></div></div></div></blockquote></div><br><div>Thanks, Avi, for the voice of support, and for actually reading my documentation. :)<br>
<br></div><div>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.</div>
<div><br></div><div>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. </div>
<div><br></div><div>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&#39;s a much more efficient and effective design.</div>
<div><br></div>