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.<br>
<br>
Regards,<br>
Paul<br><br><div><span class="gmail_quote">On Apr 10, 2005 11:10 PM, <b class="gmail_sendername">Tina</b> <<a href="mailto:kramarv@yahoo.com">kramarv@yahoo.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;"><div>Paul,</div>
<div>I appreciate a lot this information, and am interested in your patch a lot.</div>
<div>Tina<div><span class="e" id="q_1032f3c2e87eeb51_1"><br><br><b><i>Java Rockx <<a href="mailto:javarockx@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">javarockx@gmail.com</a>></i></b> wrote:</span></div></div><div><span class="e" id="q_1032f3c2e87eeb51_3">
<blockquote style="border-left: 2px solid rgb(16, 16, 255); padding-left: 5px; margin-left: 5px;">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" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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>
<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>
<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>
<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>
<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>
<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>
<div>g-)</div></span><br>_______________________________________________<br>Serusers mailing list<br><a href="mailto:serusers@lists.iptel.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Serusers@iptel.org</a><br><a href="http://lists.iptel.org/mailman/listinfo/serusers" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.iptel.org/mailman/listinfo/serusers</a><br><br><br></blockquote></div><br></blockquote></span></div><div><span class="e" id="q_1032f3c2e87eeb51_4"><p>
</p><hr size="1">Do you Yahoo!?<br>
Yahoo! Small Business - <a href="http://us.rd.yahoo.com/evt=31637/*http://smallbusiness.yahoo.com/resources/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Try our new resources site!</a>
<p></p></span></div></blockquote></div><br>