RE: LVS, load balancing,and stickness was ==> Re: [Serusers] moreusrloc synchronization

Wouldn't it be possible to use VRRP on teh SIP proxies to provide redundancy and loadbalancing? VRRP seems to be almost similar to cisco's HSRP and afaik it is available on linux via the vrrpd. I am just starting to get into it, but you could also check

On 4/13/05, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote: >My 2 cents: > >1. Use SRV for load balancing. (Yes there are dumb devices, thus also >use A records) Probably this will cause problems with clients which does >not remember the IP address. The client has to remember the IP address >resolved by SRV lookups for all other requests. Once a request fails, >the client should repeat SRV lookup, choose a new server, reREGISTER and >stay with this server till the next failure. > >2. Use dedicated outbound proxies which do NAT traversal. Of course you >have to be sure that all messages to a client has to be routed via the >same outboundproxy. This can be solved by implementing the Path: header, >or by modifiying the Contact: header in REGISTER requests to point to >the outboundproxy. > >3. Use one ore more main proxies with the routing logic. > >I don't like load balancers as they are a single point of failure and >SIP is not that easy to handle as HTTP. > >regards, >klaus > >Greger V. Teigre wrote: > > >>I agree that NAT should be resolved by the peers. I haven't looked at >>the forking proxy details; I assume it will do sort of a redirect for >>REGISTERs and INVITEs, so that everything thereafter is handled by each >>SIP server. I still cannot really see how you solve the NAT >>problem,though. The public IP of the SIP server handling the first >>REGISTER will be the only IP allowed to send an INVITE to the UA, so if >>another UA registered with another server makes a call, the SIP forking >>proxy must make sure that the INVITE is sent through the SIP server >>having done the initial registration of callee. >>g-) >> >>---- Original Message ---- >>From: Alex Vishnev >>To: 'Greger V. Teigre' ; serusers(a)lists.iptel.org >>Sent: Tuesday, April 12, 2005 06:20 PM >>Subject: RE: LVS, load balancing,and stickness was ==> Re: [Serusers] >>moreusrloc synchronization >> >> > Greger, >> > >> > I am not an expert on anycast as well. I just know it exists and >> > people are starting to look at it more seriously for HA option. That >> > is why I though DNS SRV records would be an easier solution. >> > Regarding your comments on NAT, I don't believe it is an issue as it >> > relates to forking proxy. Forking proxy should not resolve NAT, it is >> > a job for its peers. As for configuring SER as forking proxy, I >> > thought I read about it a while back, but now I can't seem to locate >> > it. I hope I was not dreaming ;-). >> > >> > In any case, I will continue to google around to see if SER has this >> > option. >> > >> > Sincerely, >> > >> > Alex >> > >> > >> > >> > >> > From: Greger V. Teigre [mailto:greger@teigre.com] >> > Sent: Tuesday, April 12, 2005 6:21 AM >> > To: Alex Vishnev; serusers(a)lists.iptel.org >> > Subject: Re: LVS, load balancing,and stickness was ==> Re: [Serusers] >> > moreusrloc synchronization >> > >> > Alex, >> > I'm not really knowledgable enough about anycast to say anything >> > useful. The only is that in your described setup, I cannot really >> > see how you get around the UA behind restricted (or worse) NAT. >> > I have never tried to configure SER as a forking proxy, but I >> > wouldn't be surprised if it was possible. >> > g-) >> > >> > ---- Original Message ---- >> > From: Alex Vishnev >> > To: serusers(a)lists.iptel.org >> > Sent: Monday, April 11, 2005 02:30 PM >> > Subject: RE: LVS, load balancing, and stickness was ==> Re: [Serusers] >> > moreusrloc synchronization >> > >> >> Greger and Paul, >> >> >> >> I think you understood me correctly regarding forking proxy. It is >> >> the proxy that will fork out the requests to all available peering >> >> proxies. This approach does not require stickiness based on Call-id. >> >> AFAIK, once the forking proxy receives an acknowledgement from one of >> >> its peers, then the rest of the session will be done directly to that >> >> peer without the use of the forking proxy. I am considering 2 >> >> approaches to resolve availability of forking proxy. 1 - using >> >> ANYCAST (good high level article: >> >> http://www.kuro5hin.org/story/2003/12/31/173152/86). 2 - using dns >> >> srv. I am still trying to determine if ANYCAST is a good solution for >> >> creating local RPs with forking proxy. However, I think that dns srv >> >> records can easily be implemented to allow simple round robin between >> >> multiple forking proxies. Thoughts? >> >> >> >> Alex >> >> >> >> >> >> >> >> >> >> From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] >> >> On Behalf Of Greger V. Teigre >> >> Sent: Monday, April 11, 2005 4:47 AM >> >> To: kramarv(a)yahoo.com >> >> Cc: serusers(a)lists.iptel.org >> >> Subject: LVS, load balancing, and stickness was ==> Re: [Serusers] >> >> more usrloc synchronization >> >> >> >> After my last email, I looked at ktcpvs and realized I ignored a >> >> couple of things: ktcpvs only supports tcp (http is obviously >> >> tcp-based, but I thought it supported udp for other protocols). I >> >> don't know how much work implementing udp would be. >> >> Here is a discussion of SIP and LVS that I found useful (though >> >> not encouraging). >> >> >>http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.services_that_dont

>> >> >> >> Paul: I'm starting to get really curious on the standard LVS >> >> components used for your stickiness! I'm not aware (also after >> >> searching now) of an LVS balancing mechanism that allows correct >> >> stickness on SIP udp...! >> >> And I found other too who are looking for it: >> >> >>http://archive.linuxvirtualserver.org/html/lvs-users/2005-02/msg00251.htm