[Serusers] more usrloc synchronization
Tina
kramarv at yahoo.com
Fri Apr 8 21:05:29 CEST 2005
Greger, thanks a lot.
The problem with load balancer is that replies goes to the wrong server due to rewriting outgoing a.b.c.d . BTW, as Paul pointed, if you define some dummy interface with Virtual IP (VIP), there is no need to rewrite outgoing messages (I tested this a little).
Why DNS approach is bad (except restricted NAT - let's say I am solving this)?
I guess, Paul utilizes load-balancer scenario you have described. Believe there are only proprietary solutions for "the-replies-problem". We tried Vovida call-id-persistence package, unfortunately it didn't work for us.
In my configuration I use shared remote DB cluster (with replication). Each ser see it as one-public-IP (exactly the approach you named for SIP). May be it's good idea to use local DB clusters, but if you have more than 2 servers your replication algorythm gonna be complex. Additional problem - it still doesn't solve usrloc synchronization - you still have to use t_replicate()...
With regard to t_replicate() - it doesn't work for more than 2 servers, so I used exactly forward_tcp() and save_noreply() (you're absolutely right - this works fine so far); all sers are happy. Of course, this causes additional traffic. Interesting whether Paul's FIFO patch reduces traffic between sers?
KRs,
Tina,
software engineer
"Greger V. Teigre" <greger at teigre.com> wrote:
Hi Tina,
> I enjoy reading your posts, thanks a lot for the great work you are
> doing for ser users!
Thanks :-)
> I am going to consider that kind of scenario as well (load balancer
> returning Virtual IP address). I think for such configuration server
> side has to keep session information and always forward a call to the
> right server.
I believe the load balancer can be in front and transparantly translate addresses in the SIP messages:
User agent always sees a.b.c.d
|
Load balancer with public IP a.b.c.d
| |
ser1 (10.0.0.2) ser2 (10.0.0.3)
Paul: You have a similar load-balancing solution, right? Do you use a commerical load balancer that you can reveal the name of? :-)
The load balancer need to understand SIP (sort of) and use something (ex. IP address of user agent) to select SER server to send to and rewrite incoming to 10.0.0.2 and 10.0.0.3 respectively and outgoing to a.b.c.d. ser1 and ser2 will happily believe they are alone and communicate directly with user agent using their own private addresses. Both should know about all users (usrloc). Paul just recently posted a small patch for a setup where they use two-way replication between two mysql servers and where each SER instance will save all REGISTERs it receives from user agents, but only save to memory those replicated from the other SER peer. Klaus pointed out that the same can be done by not doing mysql replication, but have one DB for each SER and just use t_replicate() and save_noreply() (for two servers, for more than two you need to use forward_tcp()).
I have heard complaints that this approach will generate too much network traffic. Also, t_replicate() does not guarantee delivery of the replication (forward_tcp is better, but not fool proof). So, the "best" solution would probably be to hope that Paul's recent TCP/UDP patch for network access to FIFO commands get included in the CVS. Then, a new replication module should use XMLRPC or whatever protocol the patch is using to forward (in a guaranteed mode) the usrloc information, which then would be injected directly into SER's memory, just like save() would, and of course in whatever db_mode you would like. The replicaton module would have to keep a queue (of course, flushed to a DB or something) in case of network problems, so that the replication would be done (sooner or later) regardless of problems.
Of course, this is a major undertaking, so for most replication scenarioes, I would think the forward_tcp() + save_noreply() would work just fine.
g-)
> "Greger V. Teigre" <greger at teigre.com> wrote:
> I was thinking about a load balancing scenario where the load
> balancer will replace the IP addresses.
> g-)
>
> ---- Original Message ----
> From: Tina
> To: Greger V. Teigre
> Sent: Wednesday, April 06, 2005 09:45 PM
> Subject: Re: [Serusers] still no help - usrloc synchronization
>
>> Thank you for givingme the scenario with "restricted IP" NAT, I am
>> starting to find some acceptable solution.
>> Unfortunately, "one-public-IP" approach is not free from problems
>> also. If your SIP router inserts this "one-public-IP" into the VIA
>> header, the reply routing goes via wrong SIP server...
>> If your SIP server inserts its real-IP-address - the scenario
>> mentioned above is still not resolved.
>> Any comments?
>> Tina
>>
>> "Greger V. Teigre" <greger at teigre.com> wrote:
>> See inline.
>>
>>> If you use DNS server for load balancing... the client receives one
>>> of your domain IP addresses according to SRV. I don't see the
>>> problem
>>> with a call here, cause UAC asks t! he address only once (before
>>> sending INVITE). UAC already has the IP for BYE/reINVITEs. So why
>>> would you replicate INVITEs?
>>
>> I would never replicate INVITEs, I would just make sure that they are
>> proxied through the correct SER server (i.e. IP).
>>
>> The problems depends on your setup. If you have SERs with different
>> IPs, ex UA1 has registered with server A and UA2 has registered with
>> server B: If UA2 wants to call UA1 and UA is behind an IP restricted
>> NAT, server A is stored in the NAT table of the NAT in front of UA1.
>> If server B sends an INVITE to UA1, the INVITE will be refused by
>> UA1's NAT.
>> This is why a "one public IP" in front of a load balancing
>> cluster probably is a good way to go.
>>
>>> If you use IPVS/LVS... I believe you can force SER to insert it's
>>> public IP into VIA,! so there is no problem with replies. With
>>> regard
>>> to another requests, I believe load balancer keeps connection
>>> template, then when another request comes it would be forwarded to
>>> the same ser.
>>
>> Yes. There are different "keys" to use to load balance SIP messages.
>> One good way from a NAT point of view is to use originating IP
>> address. What you must remember is that the problem is not on the
>> server side, but on the client side. The NAT will in many situations
>> stop incoming UDP packets if the originating ip:port is not already
>> stored in the NAT table. The Via header does not matter for the NAT.
>> g-)
>>
>>> Any comments?
>>>
>>> "Greger V. Teigre" <greger at teigre.com> wrote:
>>> Yes, I believe that is so. But still you get a problem if the NAT is
>>> restricted, port-restricted or symmetric... The best would be to
>>> load>> balance and always make sure that a given client is handled
>>> through a given
>>> SER (REGISTER and INVITEs). That includes forwarding INVITEs from
>>> one
>>> SER to
>>> another... OR you must load balance in front of your servers with
>>> one
>>> common
>>> public IP.
>>> g-)
>>>
>>> Matt Schulte wrote:
>>>> Ack, I didn't even think about NAT. Would these be added before it
>>>> gets sent off to the second proxy? ie:
>>>>
>>>> if (!src_ip==blah.netlogic.net) {
>>>> add_rcv_param();
>>>> t_replicate("blah.netlogic.net", "999");
>>>> };
>>>>
>>>> -----Original Message-----
>>>> From: Greger V. Teigre [mailto:greger at teigre.com]
>>>> Sent: Tuesday, April 05, 2005 7:49 AM
>>>> To: Matt Schulte; kramarv at yahoo.com
>>>> ! ; Cc: serusers at lists.iptel.org
>>>> Subject: ! Re: [Serusers] still no help - usrloc synchronization
>>>>
>>>>
>>>> Well, you still have the NAT issues unless you do load balancing
>>>> and your
>>>> SER servers have the same public IP.
>>>> Have you looked at 0.9.0 nathelper function add_rcv_param() ? It
>>>> will add received info to the contact header for the other SER to
>>>> process. Haven't really tried yet...
>>>> g-)
>>>>
>>>> Matt Schulte wrote:
>>>>> I'm starting to lean this direction, using t_replicate and all. I
>>>>> could never get usrloc (db mode) to function properly..
>>>>> t_replicate is
>>>>
>>>>> a dirty but very effective workaround.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Greger V. Teigre [mailto:greger at teigre.com]
>>>>> Sent: Saturday, April 02,! 2005 1:33 AM
>>>>> To: kramarv at yahoo.com
>>>>> Cc: serusers at lists.iptel.org
>>>>> Subject: Re: [Serusers] still ! no help - usrloc synchronization
>>>>>
>>>>>
>>>>> Have a look at this thread:
>>>>> http://lists.iptel.org/pipermail/serusers/2005-January/014669.html
>>>>> g-)
>>>>>
>>>>> Java Rockx wrote:
>>>>>> Tina,
>>>>>>
>>>>>> I thought I saw you post the other day that you did not want to
>>>>>> use t_replicate(), however, this is probably your best bet to
>>>>>> getting this
>>>>>
>>>>>> to work, IMHO.
>>>>>>
>>>>>> Regards,
>>>>>> Paul
>>>>>>
>>>>>> On Apr 1, 2005 4:08 PM, Tina wrote:
>>>>> ! >>
>>>>>> ! ;> Hi, please help me, I'm stuck with it!!!!!
>>>>>>> I am trying to set up several sers with a shared MySQL database
>>>>>>> for location service.
>>>>>>>
>>>>>>> I set in each ser.cfg:
>>>>>>>
>>>>>>> modparam("usrloc", "db_mode", 2)
>>>>>>> modparam("usrloc",
>>>>>>> "db_url","sql://ser:heslo@192.168.25.163/ser")
>>>>>>>
>>>>>>> and the servers are not synchronized.
>>>>>>> The I set
>>>>>>> modparam("usrloc", "db_mode", 2)
>>>>>>>
>>>>>>>
>>>>>>> made UAC (Xlite) register to one of the servers.
>>>>>>> I see it via usrloc, but there is no record in "location" mySQL
>>>>>>> table....So others do not see the client and I'm unable to make
>>>>>>> calls....
>>>>>>>
>>>>>>>
>>>>>>> Please help how to work with usrloc and mySQL...
>>>>>>>
>>>>>>> Tina,
>>>>>>> software engineer
>>>>>>>
>>>>>>> ________________________________
>>>>>>> Do you Yahoo!?
>>>>>>> Better first dates. More second dates. Yahoo! Personals
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>
>>>
>>>
>>>
>>> Yahoo! Messenger
>>> Show us what our next emoticon should look like. Join the fun.
>>
>>
>> Do you Yahoo!?
>> Better first dates. More second dates. Yahoo! Personals
>
>
> Yahoo! Messenger
> Show us what our next emoticon should look like. Join the fun.
---------------------------------
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050408/ae2bb30d/attachment.htm>
More information about the sr-users
mailing list