[Serusers] more usrloc synchronization

[Tina]

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! 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050410/a88ea43c/attachment.htm>