11 Apr
2005
11 Apr
'05
5:10 a.m.
Paul,
I appreciate a lot this information, and am interested in your patch a lot.
Tina
Java Rockx <javarockx(a)gmail.com> wrote:
See inline.
On Apr 10, 2005 5:32 AM, Greger V. Teigre <greger(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
---------------------------------
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!