[Serusers] more usrloc synchronization

[Java Rockx]

See inline.

On Apr 10, 2005 5:32 AM, Greger V. Teigre <greger at teigre.com> wrote:
> 
> > 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). 
> Yes, if you use LVS with direct routing or tunneling, that is what you 
> experience. What I described was a "generic" SIP-aware load balancer where 
> SIP messages would be rewritten and stickiness implemented based on ex. UA 
> IP address (or call-id like vovida's load balancer).
>  
> > Why DNS approach is bad (except restricted NAT - let's say I am
> > solving this)? 
> Well, IMO, DNS SRV in itself is not bad. It's just that many user clients 
> do not support DNS SRV yet. Except that, I like the concept and it will give 
> you a geographical redundancy and load balancing.
> 
> > 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. 
> Are you referring to the load balancer proxy? IMHO, the SIP-aware load 
> balancer makes things a bit messy. It sounds to me that the LVS + 
> tunneling/direct routing + virtual IP on dummy adapter is a better solution.
> 
> > 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()... 
> I'm not sure if I understand. So, you have 2 servers at two location, each 
> location with a shared DB and then replication across an IPsec tunnel?? 
>  IMHO, mysql 3.23.x two-way replication is quite shaky and dangerous to 
> rely on. With no locking, you will easily get overwrites and you have to be 
> very sure that your application doesn't mess up the DB. I haven't looked at 
> mysql 4.1 clustering, but from the little I have seen, it looks good. Is 
> that what you use?
> 

I agree. That is why we use MySQL 4.1.

> 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? 
> I believe Paul uses forward_tcp() and save_memory() to save the location 
> to the replicated server's memory, while the save("location") on the primary 
> server will store to the DB (which then replicates on the DB level).
> 

My ser.cfg uses t_replicate() and save_memory() with our urecord.c patch 
applied. save_memory() does not work when the db_mode is write-through. What 
happens is save() is called from SIP-01 which does either an INSERT or 
UPDATE sql on the location table.

But save_memory() attempts to do the same thing on SIP-02 (only in 
write-through mode). So we had to patch usrloc's urecord.c file to have it 
honor a flag called FL_MEM because if I call save_memory("location") I 
demand that ser only save to memory - but it doesn't so this, IMHO is a bug.

I posted a patch for this last Thursday to serdev, but unfortunately we 
identified another related bug in ser, so a revised patch is needed, which 
I'll try to post tomorrow.

Regards,
Paul

g-)
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050410/cbaf61d8/attachment.htm>