VoIP Mailing List Archives

[funkknob at gmail.com]

Hi everyone, this is my first post.

I'd like to know if there is any plan for an HA solution for
FreeSWITCH. I know the 'heartbeat' trick, but is there or will there
be any way to mirror the configuration changes and even call state
between two boxes in a sort of clustered arrangement?

Thanks,

Tom

_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

[james.green at stealth...]

Tom Warren wrote:

[funkknob at gmail.com]

Hi James,

I'd like to avoid front-ending the FS boxes and instead have them
load-share amongst themselves or sit in a hot/standby arrangement
while updating the other box(es) with call state and configuration
changes. They would be connected directly via a closed tertiary
network so that the heartbeat could be set to a very low value, and
call state data would not traverse the same path as the call traffic.
Am I just dreaming? Could a standby box take over call in progress
when the primary fails?

Thanks,

Tom


On Tue, Aug 26, 2008 at 9:25 PM, James Green <james.green@stealthnet.net> wrote:

[james.green at stealth...]

Tom,

Configuration: that should be easy using XML CURL to load what would
otherwise be in the conf/ XML files. I would strongly recommend looking
at this.

Call state I wouldn't like to comment on, I have not looked into it. I
would imagine it's unlikely to succeed based on the uuid of each call
only being known to the handler FreeSWITCH instance. I could have my
assumptions wrong of course.

I take it incoming calls would be asked to try each of several IPs in
turn until a connection is successful? Else you would need to "notice"
one instance was no longer active and ask whomever was routing calls to
it to divert.

I still prefer the idea of 2+ proxy boxes. It would be simpler to add
more as load increases, and far simpler to add additional IVRs (FS) into
a backend pool. Heartbeat solutions have potential issues such as single
point of failure and split brain.

James

Tom Warren wrote:

[lzwierko at gmail.com]

Hi, Regarding HA, I don't suppose you'll be able to go without any
front-end, beacuse of IP-connectivity reasons, if you plan to work in
active-standby mode . Active box needs to have an unique IP, otherwise
each client will have to have 2 (or more) IP addresses configured.
As solution you can use a switch with ip routing based on heartbeat
(which can be a icmp ping or http get or others). The idea is you
configure virtual ip on each of your boxes, and FS runs on this IP.
Boxes are only connected to your IP network through the switch. the
switch directs all traffic to only one of the boxes, checking the
heartbeat all the time. If one machine failes, trafic starts being
routed to the other box.
With this solution you don't have to do any tricks to have a single IP
address for your clients. there are of course other solutions, this
one gives you the shortest switch time though.

As for the transferring call states between the machines, much of call
data is distibuted into modules. Now if we wanted to keep consistent
states between two FS instances, we'd have to come up with some
interfaces to firstly serialize the states and then 'revoke' them on
second machine. No that is of course doable, but I'd require enhacing
internal FS interfaces (especially those to endpoint modules) so that
a call controls in not-initial states could be created. That is a huge
amount of work, I don't suppose it's worth it.

br

£

2008/8/27 James Green <james.green@stealthnet.net>:

[james.green at stealth...]

£ukasz Zwierko wrote:

[lzwierko at gmail.com]

W dniu 27 sierpnia 2008 13:48 u¿ytkownik James Green
<james.green@stealthnet.net> napisa³:

[james.green at stealth...]

£ukasz Zwierko wrote:

[lzwierko at gmail.com]

W dniu 27 sierpnia 2008 14:46 u¿ytkownik James Green
<james.green@stealthnet.net> napisa³:

[james.green at stealth...]

£ukasz Zwierko wrote:

[funkknob at gmail.com]

Wow, this has turned into quite a debate.

I think HA could be the killer app that catapults FS into the
mainstream. Even if not full implemented today, laying the groundwork
to allow for call state synchronization with a standby box would be a
great leap ahead of any other platform I'm aware of.

Although not fully analogous, if you want to see an example of state
mirroring look at Cisco SNAT. This synchronizes NAT entries to a
standby router so that IP conversations are not reset when switchover
occurs.

Imagine running just two boxes and having a fully redundant and
mirrored configuration where when the primary box fails, the caller
hears only a momentary 'hiccup' then conversation continues on....

Tom


2008/8/27 James Green <james.green@stealthnet.net>:

[jbr at consiglia.dk]

Hi everyone,
I would like to join the choir of Tom Warren: HA with state synchronisation would not just be a killer, it will pave the road for the FreeSWITH all the way to the entrance of the Telco’s.
As a former co-owner of a hosted PBX Telco, I would like to share my experience about customers: They do accept a disconnection as long as it does not happen “often”, and as long as the call can be re-established right after the disconnection. The period of “often” depends on the type of customer, and it ranges from 1 month to 12 months. Mind you, customers are used to the quality of mobile phones.
Therefore, I suggest that focus is put on making the core stable and scalable as the first priority, and, as the second HA-priority, to create the means required to ensure uninterrupted calls during ‘hiccups’ in the box having the call.
Jon Bruel
Consiglia Telecommunications
Denmark

[ranjtech at gmail.com]

[edpimentl at gmail.com]

Service Provider Self healing ha-cluster can and are being manage with the following tools:
1- NGINX or POUND or PERLBAL or HAProxy for LBS
2- WackaMole/Spread ..... For DNS / FOS
3- PUPPET / RPATH...... Rapid System Build
4- GroundWork/Hyperic for Network Management/System Management/Apps
5- XMPP ... no need for explanation
6- Kayako .... eTickets

-E
http://gpro.ws