[Users] MediaProxy / RTPproxy / SER / Asterisk / HA / LVS / DNS [load-balancing and high availability]

[Christian Schlatter]

Thomas Deillon wrote:
> Hi,
> 
> I will try to summarise different load balancing solution and I hope
> that you will correct my mistake to have a good point of view of all
> solution.
> Thanks in advance.
> 
> 
> 1. Solution with DNS SRV allows making Load Balancing (on phone side)
> but need phones that support this function.
> 	1.1: Explanation
> 	
> In your DNS, you can set DNS SRV entry like this: 
> 
> ------------------------------------------------------------------
> |sipserver1.bigu.edu.  43200 IN A       10.0.0.21
> |sipserver2.bigu.edu.  43200 IN A       10.0.0.22
> |;
> |_sip._udp.bigu.edu.   43200 IN SRV 0 0 5060  sipserver1.bigu.edu.
> |_sip._udp.bigu.edu.   43200 IN SRV 0 0 5060  sipserver2.bigu.edu.
> -------------------------------------------------------------------
> 
> In your phone, you set in proxy SIP: "bigu.edu". The DNS will see that
> it's a request SIP in UDP and will return 1/2 times in this order:
> - sipserver1.bigu.edu.
> - sipserver2.bigu.edu.
> 
> Phone understanding DNS SRV, will use the first line and if it doesn't
> work, will use the second one. 
> The phone witch not understands the DNS SRV will always use the first
> line even if it doesn't work.
> 
> Conclusion (C/c): It's a load balancing on phone side and so, if you
> can't choose phone model, it's not a solution (like IP centrex).
> To solve this problem, we have to use a load balancing on network side
> OR server side.

I don't really agree with this conclusion. Load balancing/fail over "in 
the previous hop" is surely the most scalable and reliable solution. And 
it is well documented and standardized in RFC 3263 (Locating SIP 
Servers) published in June 2002. SIP phones that do not support RFC 3263 
are IMHO not SIP compliant (although I have to admit that SIP compliance 
is a somewhat fuzzy term).

So before looking at "failover/load balancing in the redundant hop" 
solutions like network level load balancers, I'd made *really* sure that 
using phones that support 3263 is not an option. You will never reach 
the same degree of scalability and no-bottleneck redundancy with these 
solutions.

Christian

> 
> 
> 2. Solution with HA (Heart Beat) it's a solution on server side.
> 	1.1 Explanation
> This solution is a fail over architecture. You will set a VIP (virtual
> IP address) for two servers. The server 1 will have this VIP and handle
> all the traffic. The second server will listen to the "heart" of the
> first server and it's something going wrong, it will take the VIP.
> 
> C/c: This solution will not load balance traffic, and half of computer
> will not be used.
> 
> 3. [Correct this part please] LVS (linux virtual Server) is a solution
> to load balance traffic but it's not SIP aware. You can use it for TCP
> connection but for SIP, it's very hard.
> However, you can set a load balancing on IP source, and so, each phone
> will see only one server.
> More than this, the LVS solution will not try to know if Asterisk OR SER
> is alive but try to know if the server is alive. (most of the time, only
> the service going down, not the whole server ...)
> 
> C/c: The LVS is not a good solution. This can help but the reactivity is
> very bad.
>  
> 
> 4. RTPproxy with SER
> 	RTPproxy with Ser is use for failover and not load balancing,
> so, it's the same conclusion as HA.
> 
> 5. MediaProxy with SERs.
> 	I'm really not sure, but I thing that we have to use only SER
> servers and the loadbalancer have to be a registrar server ??????
> C/c: can you conclude...
> 
> 
> 6. The ultimate solution...
> 	I'm looking for a solution with SER (or something else) in
> loadbalancer and multiple Asterisk server behind it witch will do all
> SIP function (REGISTRAR, ...).
> This kind of architecture has to support NATed phones.
> 
> 
> 
> Thanks to read this and thanks for your help,
> 
> 
> Thomas Deillon
> 	
> 
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 1951 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.kamailio.org/pipermail/users/attachments/20061207/18b33b1f/attachment.bin