
I'll chime in with at least one potential option. If the free SIP proxies/load balancers all fell off the table solely because of lack of stateful HA, then perhaps running your proxy/proxies on VMware vSphere and taking advantage of their Fault-Tolerance feature is an option. I haven't used it personally quite yet, however it's supposed to provide stateful failover for the entire system. Brian ----- "anorexicpoodle" <anorexicpoodle at gmail.com> wrote:
I have come across the need for a stateful SIP load balancer with fail-over and HA capabilities, and I am hoping some on this list can chime in with some personal experience.
The need is not for a particularly large volume of traffic, more to act as a socket to adapt my active/active model UM system to Metaswitch's 1:1 UM system model, which cannot support active/active application servers. Yes I felt this was a strange omission in functionality as well.
I have pretty much ruled out OpenSER/OpenSIPS/Kamilio because it isn't stateful in HA failover. Passing it through an Acme is ridiculously costly for the need i have, and most hardware based load balancers I am finding just aren't sip-aware, so I don't see them doing much better than OpenSER in a fail-over scenario, it would just be a different kind of ugliness.
Thanks in advance
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

Or you could use Linux-HA, or you could use super-low TTLs and do some monitoring+DNS magic, could do multi-layer proxies as well ... there are lots of ways to ensure uptime on open source software, especially with Linux. Randal On Fri, Nov 6, 2009 at 3:25 PM, Brian Sneddon <bsneddon at gc1.com> wrote:
I'll chime in with at least one potential option. If the free SIP proxies/load balancers all fell off the table solely because of lack of stateful HA, then perhaps running your proxy/proxies on VMware vSphere and taking advantage of their Fault-Tolerance feature is an option. I haven't used it personally quite yet, however it's supposed to provide stateful failover for the entire system.
Brian

None of those will preserve state, however, which I believe was the main issue being presented by the original poster. I use Linux-HA quite a bit and it's great for service availability, but doesn't really help if you're trying to perform a stateful failover. Brian ----- "randal k" <rkohutek at gmail.com> wrote:
Or you could use Linux-HA, or you could use super-low TTLs and do some monitoring+DNS magic, could do multi-layer proxies as well ... there are lots of ways to ensure uptime on open source software, especially with Linux.
Randal
On Fri, Nov 6, 2009 at 3:25 PM, Brian Sneddon <bsneddon at gc1.com> wrote:
I'll chime in with at least one potential option. If the free SIP proxies/load balancers all fell off the table solely because of lack of stateful HA, then perhaps running your proxy/proxies on VMware vSphere and taking advantage of their Fault-Tolerance feature is an option. I haven't used it personally quite yet, however it's supposed to provide stateful failover for the entire system.
Brian

<selfpromotion level="innocent"> Our SIPmethod sip servlet platform includes support for HA and call replication. Writing a quick proxy or b2b UA application on it might be an option: http://www.micromethod.com/products/sipmethod.htm We have a free developer version up for download if you want to give it a try. </selfpromotion> --- RJ Auburn CTO, Voxeo Corporation tel:+1-407-418-1800 On Nov 6, 2009, at 6:32 PM, Brian Sneddon wrote:
None of those will preserve state, however, which I believe was the main issue being presented by the original poster. I use Linux-HA quite a bit and it's great for service availability, but doesn't really help if you're trying to perform a stateful failover.
Brian
----- "randal k" <rkohutek at gmail.com> wrote:
Or you could use Linux-HA, or you could use super-low TTLs and do some monitoring+DNS magic, could do multi-layer proxies as well ... there are lots of ways to ensure uptime on open source software, especially with Linux.
Randal
On Fri, Nov 6, 2009 at 3:25 PM, Brian Sneddon <bsneddon at gc1.com> wrote:
I'll chime in with at least one potential option. If the free SIP proxies/load balancers all fell off the table solely because of lack of stateful HA, then perhaps running your proxy/proxies on VMware vSphere and taking advantage of their Fault-Tolerance feature is an option. I haven't used it personally quite yet, however it's supposed to provide stateful failover for the entire system.
Brian
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

On Nov 6, 2009, at 3:32 PM, Brian Sneddon wrote:
None of those will preserve state, however, which I believe was the main issue being presented by the original poster. I use Linux-HA quite a bit and it's great for service availability, but doesn't really help if you're trying to perform a stateful failover.
Brian
[snip] I, for one, would be very interested to see anyone's results with the logically extreme version of "keeping state", meaning keeping media state. Asterisk can't perform failover between two discreet systems and maintain media state, if media is indeed being handled as a B2BUA and RTP relay. We (Digium) have been asked a few times about it, but the engineering effort is much much larger than the payoff and nobody from the open-source community has stepped forward with any code. The amount of synchronization data that would have to be exchanged between two systems running RTP and signaling is large. VERY large. That's not to say it can't be done, but I just haven't seen it done even with VMWare or other VM-based systems which may claim to be able to synchronize instances between chassis platforms. Most failures aren't hardware or chassis-based; they're software- based, so duplicating corrupted memory structures between two machines will give you (surprise!) two dead machines, or two dead apps on two machines regardless of the application being used. So this has limited use. Anyone who has code that relays minimal state WITHOUT mirroring the whole app/system so that two instances of (for instance) Asterisk could be synchronized without shared fate... I'll be very VERY interested in that. :-) So: has anyone out there done this with any RTP-capable systems running on Linux (Asterisk or otherwise)? If so, can you post notes and operational techniques? JT --- John Todd email:jtodd at digium.com Digium, Inc. | Asterisk Open Source Community Director 445 Jan Davis Drive NW - Huntsville AL 35806 - USA direct: +1-256-428-6083 http://www.digium.com/

John Todd wrote:
I, for one, would be very interested to see anyone's results with the logically extreme version of "keeping state", meaning keeping media state.
Asterisk can't perform failover between two discreet systems and maintain media state, if media is indeed being handled as a B2BUA and RTP relay. We (Digium) have been asked a few times about it, but the engineering effort is much much larger than the payoff and nobody from the open-source community has stepped forward with any code. The amount of synchronization data that would have to be exchanged between two systems running RTP and signaling is large. VERY large. That's not to say it can't be done, but I just haven't seen it done even with VMWare or other VM-based systems which may claim to be able to synchronize instances between chassis platforms.
Most failures aren't hardware or chassis-based; they're software-based, so duplicating corrupted memory structures between two machines will give you (surprise!) two dead machines, or two dead apps on two machines regardless of the application being used. So this has limited use. Anyone who has code that relays minimal state WITHOUT mirroring the whole app/system so that two instances of (for instance) Asterisk could be synchronized without shared fate... I'll be very VERY interested in that. :-)
So: has anyone out there done this with any RTP-capable systems running on Linux (Asterisk or otherwise)? If so, can you post notes and operational techniques?
I believe this effort is a specious and misguided waste of time, and the interest in it is principally the expression of the following deficiencies in the thought process of those doing the asking: (1) Exaggerated, megalomaniacal perceptions of the relative importance of four-9s vs. nine-9s uptime, and with it, lack of cursory accompanying understanding of the Pareto principle; (2) Lack of non-superficial comprehension of how the technology works, which you have covered quite well with your post. These are not satellite guidance systems. That level of failover is simply unnecessary, although I have met more than one proud ITSP owner who is prepared to solicit proposals for magic. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
participants (5)
-
abalashov@evaristesys.com
-
bsneddon@gc1.com
-
jtodd@digium.com
-
rj@voxeo.com
-
rkohutek@gmail.com