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@infopact.nl] Sent: Wednesday, December 01, 2004 7:24 AM To: serusers(a)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(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers