[Freeswitch-users] Freeswitch HA advices

[Luis Daniel Lucio Quiroz]

are your servers in same LAN or they are in the " cloud "  ?

2014-12-17 17:08 GMT-05:00 Michael Jerris <mike at jerris.com>:
> 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>:
>>
>> 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>:
>>>
>>> On Tue, Jun 10, 2014 at 10:56 AM, Federico Castro <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
>>> http://www.freeswitchsolutions.com
>>>
>>> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>>> http://www.cudatel.com
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org