10 Apr
2005
10 Apr
'05
4:35 p.m.
See inline.
On Apr 10, 2005 5:32 AM, Greger V. Teigre <greger(a)teigre.com> wrote:
I agree. That is why we use MySQL 4.1.
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?
With regard to t_replicate() - it doesn't work for
more than 2
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-)
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).
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers