[SR-Users] Kamailio Load Balancer Architecture

Daryn Johnson djohnson at telnetww.com
Thu Jun 30 17:43:02 CEST 2016


Thank you Giacomo for the info!

We are thinking to use DNS SRV for failover and  to use multiple LBs and do
some sort of HA on the Load Balancer(s) using keepalived or etcd, etc....
One of my marching orders is to eliminate any single point of failures.
Using one set of hosts would definitely simplify my architecture. Are there
any security concerns that arise when allowing the LB/Proxy/Registrar/GW to
be on the same device and connected to the Public Internet?

*Daryn Johnson*

*Senior VoIP Engineer*

248.485.1109

*www.telnetww.com* <http://www.telnetww.com>
1175 W. Long Lake Rd. | Suite 101 | Troy, MI 48098



On Thu, Jun 30, 2016 at 11:15 AM, Giacomo Vacca <giacomo.vacca at gmail.com>
wrote:

> Hi Daryn,
> it may not be an overkill, depending on the constrains you have. For
> example if the clients can possibly only be instructed to connect to a
> single public IP address (5.5.5.5 in your example), while you want to be
> able to scale the Kamailio architecture with multiple instances, then it
> can be a viable approach. Remember though that the Load Balancer will be
> your Single Point Of Failure. If the Load Balancer dies, for any reason,
> the service is not available.
>
> There has been an interesting thread in this mailing list recently, on
> techniques to provide active/stand-by redundancy to a Kamailio deployment:
> "High Availability".
>
> Depending on the capabilities of the clients you may consider removing the
> Load Balancer from the equation and perform DNS-based load balancing across
> your Proxy/Registrar/PSTN Gw instances. You'd be removing a SPOF, use one
> fewer machine, and simplify the architecture. This is not always possible
> to achieve though, because it delegates load balancing and fail over to the
> clients.
>
> Giacomo
>
>
> On 30 June 2016 at 17:03, Daryn Johnson <djohnson at telnetww.com> wrote:
>
>> I am interested in opinions and suggestions about load balancing with
>> Kamailio.  I work for an ITSP that currently uses Oracle & Broadsoft, and I
>> am working to design and develop an open source solution using Kamailio
>> (Proxy, Registrar, LB) &  other Application/Media servers for more
>> flexibility and freedom :)  Thank you ALL for the work you have put in on
>> Kamailio!
>>
>> After much reading and configuration I have a Kamailio 'proxy' setup,
>> with endpoints registered using the Registrar module, and calls being
>> sent/received to/from the PSTN. I am interested in separating the Load
>> Balancers from the Registrars & logic, for security and in order to be able
>> to scale appropriately.  I will be using the dispatcher module for both
>> load balancers and proxies using the following architecture:
>>
>> PublicIP = 5.5.5.5; Private IP = 192.168.1.0/24
>>
>> USERS (Public Internet) ==> (public: 5.5.5.5)  [ Kamailio (LoadBalancer,
>> Firewall, Sanity Checks) ] (core:192.168.1.2) ==> [ Kamailio Registrar,
>> Proxy, PSTN GW ] ==> AppServers or PSTN GW
>>
>> (we can access our PSTN gateways Via our Core using Private IPs)
>>
>> Questions:
>> 1) Is it overkill to separate the LB & Proxy/Registrars?
>> 2) Is this a common architecture & anyone configured this architecture
>> successfully?
>>
>> Thanks in advance for your help!
>>
>>
>> *Daryn Johnson*
>>
>>
>> *Senior VoIP Engineer*
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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/20160630/ed05a527/attachment.html>


More information about the sr-users mailing list