[SR-Users] Fail Safe Environment for kamailio

davy van de moere davy.van.de.moere at gmail.com
Thu Mar 6 07:57:50 CET 2014


There are many ways to get to Rome. Or in sip terms, there are many ways to build something redundant.

A method which might be worthwhile to investigate is deploying SIP SRV. This allows you to not have to focus on that one IP address which is always available whatever happens, if you need to do this, get comfortable with everything you find on the internet on LinuxHA.

Now, SIP SRV comes down to having your endpoints connect to your domain, your domain is then defined by SRV records as a bunch of machines which have a preferred load balance sharing, but the endpoint should have the logic to pick e.g. server B if server A is unavailable.

If your endpoints are a bit recent, there’s a good chance they will support this. Especially if you’re building something to have other servers connect to, this should be your way to go.

When making this fail safe, you just put a minimum of two kamailio (but more is better) server in two different locations, using different network connections. On a database front, what you could do is to have replication of your mysql db on the machines running kamailio. And have kamailio connect to it’s locally available DB. This implies that you implement e.g. a master-master replication on mysql, or have a master-slave replication, and add some additional logic in your kamailio routing, that when a user is unavailable on server A, it gets routed to server B, where the user perhaps is available. As a master-slave replication will make it tough to synchronize the location table of your users.

If you don’t like this approach, your alternatives will be to checkout a virtualization technique to skip the risk of failing hardware, get yourself a VMWare cluster, or cheaper (and I personally like it better thanks to it’s simplicity) OpenVZ. Or go for a full blown active-passive setup, using heartbeats, virtual IPs, etc…

Also check out this fosdem presentation: http://kamailio.org/events/2011-fosdem/p_usrloc.pdf

As a bottom line, I’ld advise you to give it a shot with SIP SRV, it’s an elegant solution, which most of the time just works by design. The biggest risk you need to take into account is, that building something which can failover is typically highly complex, and opens up the risk for many unwanted side-effects. We all have seen services go down, exactly because of attempts to have it fully redundant.

Best of luck & Enjoy your time with Kamailio!

Grtz,
Davy Van De Moere




Op 6-mrt.-2014, om 05:40 heeft Owais ul Haq <owaisulhaq at hotmail.com> het volgende geschreven:

> Hello,
> Guys, I need some help. I am tasked to deploy "Fail Safe Architecture" for already running Kamailio Server in our organization. Presently one Kamailio Server is serving the cause with one internet connection and database on MySQL running on Windows 2008 Server R2(which is attached to kamailio server on other LAN card).
> 
> Now the requirement is  to deploy redundancy for internet connection and kamailio server. Like they want two kamailio servers running parallel, so if one fails, other will automatically take over and service will be available to users without any obstruction. At any cost, my organization want to absolutely minimize any possible blackout.
> 
> To further elaborate my point. Here is the network we want. 2 incoming internet connections to 2 kamailio servers. Both attached to a single database placed at the backend. Now is it possible ?? If not what are constraints ?? What workaround is possible ?? I seriously need help as it is matter of job. Thanking in advance for help.
> 
> P.S : kamailio server is running of Fedora machine in our environment.
> 
> Cheers.
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140306/5ff12115/attachment.html>


More information about the sr-users mailing list