[Serusers] Loadbalancing / high availability

Jiri Kuthan jiri at iptel.org
Mon Dec 6 08:27:06 CET 2004


What is exactly role of ServerIron when SER does load balancing?
Are you using SER's dispatcher module?

-jiri

At 05:37 PM 12/1/2004, Michael Shuler wrote:
>We use a Foundry ServerIron XL and it seems to work fine.  We do not use SER
>as a stateful proxy though.  SER is basically a SIP message load balancer
>across our Asterisk boxes.
>
>----------------------------------------
>
>Michael Shuler, C.E.O.
>BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
>682 High Point Lane
>East Peoria, IL 61611
>Office: (217) 585-0357
>Cell: (309) 657-6365
>Fax: (309) 213-3500
>E-Mail: mike at bwsys.net
>Customer Service: (877) 976-0711 
>
>> -----Original Message-----
>> From: serusers-bounces at lists.iptel.org 
>> [mailto:serusers-bounces at lists.iptel.org] On Behalf Of Matt Schulte
>> Sent: Wednesday, December 01, 2004 7:42 AM
>> To: serusers at lists.iptel.org
>> Subject: RE: [Serusers] Loadbalancing / high availability
>> 
>> 
>> 
>> I'm curious what brand load balancer you would use, would it be IP
>> based. We tried out a Cisco SLB and had no luck, mainly 
>> because it would
>> NAT to the servers (more trouble than it's worth?). We were 
>> thinking of
>> using a heartbeat type failover, similar to what you would do 
>> for MySQL:
>> 
>> http://linux-ha.org/download/
>> 
>> Has anyone tried this method? We're more concerned about the high
>> availability than anything.
>> 
>> -----Original Message-----
>> From: E. Versaevel [mailto:erik at infopact.nl] 
>> Sent: Wednesday, December 01, 2004 7:24 AM
>> To: serusers at lists.iptel.org
>> Subject: [Serusers] Loadbalancing / high availability
>> 
>> 
>> Hello,
>> 
>> I was wondering if it is necessary for a SIP packet from a 
>> specific call
>> to always go through the same server?
>> 
>> For instance, if you have a load balancer distributing requests over a
>> few servers, it is possible that an INVITE ends up on 1 
>> server while the
>> following INVITE with the credentials ends up on another, 
>> would this be
>> a problem (ie, break the authorization) or should you use a SIP aware
>> loadbalancer for this (who looks at the callid for example)? Assuming
>> the ser servers are setup to use the same userdatabase (and 
>> t_replicate
>> to eachother) the picture would be something like this:
>> 
>>                       |
>>                 --------------
>>               |loadbalancer|
>>                 --------------
>>                    |
>>                    |
>>           --------------------
>>           |          |         |
>>       -------   -------   -------
>>       |     |   |     |   |     |
>>       | ser1|   | ser2|   | ser3|
>>       |     |   |     |   |     |   
>>       -------   -------   -------
>> 
>> If you setup the servers with the same IP as the load 
>> balancer and stop
>> them from replying to ARP requests for that IP, replying back 
>> thru a NAT
>> should not be a problem.
>> 
>> Just thinking out loud, I could use SER for the load balancing and
>> t_relay the packets, however that would require some 
>> tampering with the
>> VIA records (and I should use a reply to via in that case to the
>> original IP the SIP request came from, eg not the load balancer) this
>> way outgoing SIP traffic would not have to go thru the ser 
>> loadbalancer
>> again to get out, hmm, it might even be possible to use a route-record
>> header to get the packets back at the correct server...
>> 
>> 
>> Kind regards,
>> 
>> E. Versaevel
>> 
>> _______________________________________________
>> Serusers mailing list
>> serusers at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
>> 
>> _______________________________________________
>> Serusers mailing list
>> serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>> 
>
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers

--
Jiri Kuthan            http://iptel.org/~jiri/ 




More information about the sr-users mailing list