[Serusers] more usrloc synchronization

[Java Rockx]

Well it's going on 1:30AM here in the US so when our Red Hat engineer gets 
in I'll have him give me the final patch for the save_memory() bug. I'll 
post it to serdev then. It should be about 12PM local time on the US east 
coast.

Regards,
Paul

On Apr 10, 2005 11:10 PM, Tina <kramarv at yahoo.com> wrote:
> 
> Paul,
> I appreciate a lot this information, and am interested in your patch a 
> lot.
> Tina
> 
> *Java Rockx <javarockx at gmail.com>* wrote:
> 
> 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
> > 
> > 
> > 
> ------------------------------
> Do you Yahoo!?
> Yahoo! Small Business - Try our new resources site!<http://us.rd.yahoo.com/evt=31637/*http://smallbusiness.yahoo.com/resources/> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050411/603b2a5b/attachment.htm>