[Freeswitch-users] Freeswitch HA advices

Thu Dec 18 01:08:01 MSK 2014

from switch.conf.xml


    <!-- The system will create all the db schemas automatically, set this to false to avoid this behaviour -->
    <!-- <param name="auto-create-schemas" value="true"/> -->
    <!-- <param name="auto-clear-sql" value="true"/> -->


> On Dec 16, 2014, at 3:57 PM, Federico Castro <fcastelco at gmail.com> wrote:
> 
> Hi Eliot and all, I keep on working in my HA solution. I’m almost done but there are some things I would like to improve. When I finish it I will share my solution with the community. 
> 
> I have two FS Boxes with Postgres running locally. Psql is running in read-write mode in Master node and in read-only mode in Slave. Psql is streaming data asynchronously through nodes.
> 
> First thing I would like to improve:
> 
> FS try to DROP some tables and delete records from sip_registrations, channels, etc. when connecting to psql and if it fails mod_sofia stops loading. This behaviour produces (in my scenary) that FS in Slave server does not start properly If it connects to local database because it is in read-only mode.
> To solve this I configured FS to connect to psql through virtual IP (it is always in Master node) then mod_sofia starts properly in Slave node. The problem here is that FS in slave node delete records from table in Master node when get connected. 
> 
> Is there any way to start FS in a “standby mode” in slave node to avoid it trying to write database?
> 
> Thanks!
> 
> 
> 
> 2014-06-16 12:05 GMT-03:00 Federico Castro <fcastelco at gmail.com <mailto:fcastelco at gmail.com>>:
> Hi Eliot, thanks for your verbose response, it is really useful for me. 
> 
> I'm working on a duplicated FS + postgreSQL schema. The two boxes will have same HW. Both of them will run FS and postgreSQL. One will act as master and the other one as stand-by waiting for the first to fail.
> 
> FS will not have more than a hundred simultaneous calls. 
> 
> I will read about Pacemaker and Corosync and I will update to the list about the implementation.
> 
> Thanks again.
> 
> 
> 
> 2014-06-13 10:45 GMT-03:00 Eliot Gable <egable+freeswitch at gmail.com <mailto:egable+freeswitch at gmail.com>>:
> On Tue, Jun 10, 2014 at 10:56 AM, Federico Castro <fcastelco at gmail.com <mailto:fcastelco at gmail.com>> wrote:
> Hi all, I'm working on a Freeswitch HA solution. Now I'm deciding what method and DB I'll use to track calls. 
> 
> I have installed PostgreSQL on both servers and I configured them to replicate DB asynchronously. 
> 
> I would like to know if someone has experience with this kind of solution and what things do I have to contemplate to deploy a solid solution.
> 
> 
> Lots of people have experience with such a solution; it all depends on what you are trying to achieve.
> 
> Personally, I recommend you setup Corosync and Pacemaker both on your PostgreSQL boxes and on your FreeSWITCH systems. I also recommend you run PostgreSQL on a separate set of boxes from FS. Both can use a lot of memory if you are running a lot of calls and/or have a lot of clients. If you need performance, I recommend using the fastest disks you can get in the PostgreSQL systems. Also install as much RAM as you can afford for the project in the PGSQL boxes. You will want redundant power supplies in each system with each supply plugged into a different circuit. You will also want redundant Ethernet connectivity to redundant switches which also have redundant power supplies. You will also want redundant cross-over connections between the pairs of boxes. 
> 
> Once you have Corosync and Pacemaker configured to start PGSQL and FS on their own boxes and you have tested manual fail-over, then you need to start thinking about every possible way you can make either of those two systems stop working. Think about hard drives failing, power loss, kernel panics, firewall rules blocking communication, someone accidentally removing the IP address from one of the systems (it happens), killing processes, Sofia profiles failing to load because something else is using the port, etc. Make sure you have things set up to detect and recover from any such failure. One of the best ways to do this is to actually build an external testing system which places real calls through the system and has them route back to itself to verify they made it. If it places a call and the call does not make it back to itself, then you know something failed and you can run more tests to determine what failed and reset it. 
> 
> Like I said, it all depends on what you are trying to accomplish. If you want really good automatic HA, you have to go to some pretty great lengths to get it. If you are OK with occasional manual intervention, then you can make some assumptions (like nobody accidentally removing your IP from the interface or telling it to stop responding to ARP or throwing up a firewall rule which blocks something). That makes the setup considerably easier, but it also means manual intervention when something like that happens. In other words, if something like that happens, you experience an outage which the HA system doesn't detect and recover from. When you get calls that service stopped working, you then have someone log in and take a look and manually fix the issue. This could take anywhere from 5 minutes to an hour or more to do, depending on how good your support is and how good your team is. 
> 
> So, probably the first task you should do is list all the things you want it to automatically recover from and all the things you are willing to accept causing an outage and then work on your implementation based on that plan.
> 
> 
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org <mailto:consulting at freeswitch.org>
> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
> 
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
> http://www.cudatel.com <http://www.cudatel.com/>
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org <http://www.freeswitch.org/>
> http://wiki.freeswitch.org <http://wiki.freeswitch.org/>
> http://www.cluecon.com <http://www.cluecon.com/>
> 
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org <mailto:FreeSWITCH-users at lists.freeswitch.org>
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users>
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users>
> http://www.freeswitch.org <http://www.freeswitch.org/>
> 
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services: 
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org <http://www.freeswitch.org/>
> http://confluence.freeswitch.org <http://confluence.freeswitch.org/>
> http://www.cluecon.com <http://www.cluecon.com/>
> 
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org <mailto:FreeSWITCH-users at lists.freeswitch.org>
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users>
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users>
> http://www.freeswitch.org <http://www.freeswitch.org/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20141217/5baf5f40/attachment-0001.html