See inline.<br><br><div><span class="gmail_quote">On Apr 10, 2005 5:32 AM, <b class="gmail_sendername">Greger V. Teigre</b> <<a href="mailto:greger@teigre.com">greger@teigre.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><span class="q">
<div>> Greger, thanks a lot.<br>> The problem with load balancer is that
replies goes to the wrong<br>> server due to rewriting outgoing a.b.c.d .
BTW, as Paul pointed, if<br>> you define some dummy interface with Virtual IP
(VIP), there is no<br>> need to rewrite outgoing messages (I tested this a
little). <br></div></span>
<div>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).</div><span class="q">
<div> <br>> Why DNS approach is bad (except restricted NAT - let's say I
am<br>> solving this)? <br></div></span>
<div>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.</div><span class="q">
<div><br>> I guess, Paul utilizes load-balancer scenario you have
described.<br>> Believe there are only proprietary solutions for<br>>
"the-replies-problem". We tried Vovida call-id-persistence package,<br>>
unfortunately it didn't work for us. <br></div></span>
<div>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.</div><span class="q">
<div><br>> In my configuration I use shared remote DB cluster (with<br>>
replication). Each ser see it as one-public-IP (exactly the approach<br>> you
named for SIP). May be it's good idea to use local DB clusters,<br>> but if
you have more than 2 servers your replication algorythm gonna<br>> be
complex. Additional problem - it still doesn't solve usrloc<br>>
synchronization - you still have to use t_replicate()...
<br></div></span>
<div>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??
</div>
<div> 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?</div></blockquote><div><br>
I agree. That is why we use MySQL 4.1.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><span class="q"><div>> With regard to t_replicate() - it doesn't work for more than
2<br>> servers, so I used exactly forward_tcp() and save_noreply()
(you're<br>> absolutely right - this works fine so far); all sers are happy.
Of<br>> course, this causes additional traffic. Interesting whether
Paul's<br>> FIFO patch reduces traffic between sers?
<br></div></span>
<div>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).</div></blockquote><div><br>
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.<br>
<br>
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.<br>
<br>
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.<br>
</div><br>
Regards,<br>
Paul<br>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><span class="sg"><div>g-)</div>
</span><br>_______________________________________________<br>Serusers mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:serusers@lists.iptel.org">serusers@lists.iptel.org</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.iptel.org/mailman/listinfo/serusers" target="_blank">http://lists.iptel.org/mailman/listinfo/serusers</a><br><br><br></blockquote></div><br>