[Freeswitch-users] Freeswitch HA advices

[Federico Castro]

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
>
> 
> 
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20140616/2f567cd5/attachment.html