<DIV>Hello there,</DIV>
<DIV>see my comments inside.</DIV>
<DIV>KRs,</DIV>
<DIV>Tina<BR><BR><B><I>"Greger V. Teigre" &lt;greger@teigre.com&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<META content="MSHTML 6.00.2900.2604" name=GENERATOR>
<STYLE></STYLE>

<DIV>&gt; Greger, thanks a lot.<BR>&gt; The problem with load balancer is that replies goes to the wrong<BR>&gt; server due to rewriting outgoing a.b.c.d . BTW, as Paul pointed, if<BR>&gt; you define some dummy interface with Virtual IP (VIP), there is no<BR>&gt; need to rewrite outgoing messages (I tested this a little).&nbsp;&nbsp;&nbsp;</DIV>
<DIV><BR>&nbsp;</DIV>
<DIV>Yes, if you use LVS with direct routing or tunneling, that is what you experience.&nbsp;</DIV>
<DIV>===Of course. That why I implemented small "session" stickness. However, it causes additional internal traffic. </DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;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>
<DIV>====Sure, it's better solution; I think we'll go this way soon&nbsp;(in our next version).</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; Why DNS approach is bad (except restricted NAT - let's say I am<BR>&gt; solving this)? <BR></DIV>
<DIV>Well, IMO, DNS SRV in itself is not bad. It's just that many user clients do not support DNS SRV yet.&nbsp; Except that, I like the concept and it will give you a geographical redundancy and load balancing.</DIV>
<DIV>===I am trying to build the following architecture:</DIV>
<DIV>&nbsp;</DIV>
<DIV>DNS (returns domain's public IP)-&gt;LVS+tunneling (Virtual IP)-&gt;ser clusters (with private IPs)</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DB (MySQL 4.1 cluster)</DIV>
<DIV><BR>&gt; I guess, Paul utilizes load-balancer scenario you have described.<BR>&gt; Believe there are only proprietary solutions for<BR>&gt; "the-replies-problem". We tried Vovida call-id-persistence package,<BR>&gt; unfortunately it didn't work for us.&nbsp;&nbsp; <BR></DIV>
<DIV>Are you referring to the load balancer proxy? IMHO, the SIP-aware load balancer makes things a bit messy.&nbsp; It sounds to me that the LVS + tunneling/direct routing + virtual IP on dummy adapter is a better solution.</DIV>
<DIV><BR>&gt; In my configuration I use shared remote DB cluster (with<BR>&gt; replication). Each ser see it as one-public-IP (exactly the approach<BR>&gt; you named for SIP). May be it's good idea to use local DB clusters,<BR>&gt; but if you have more than 2 servers your replication algorythm gonna<BR>&gt; be complex. Additional problem - it still doesn't solve usrloc<BR>&gt; synchronization - you still have to use t_replicate()...&nbsp;&nbsp;</DIV>
<DIV>&nbsp;&nbsp; <BR></DIV>
<DIV>I'm not sure if I understand.&nbsp; </DIV>
<DIV>===Oh, probably I expressed myself not well enough...</DIV>
<DIV>&nbsp;</DIV>
<DIV>So, you have 2 servers at two location, each location with a shared DB and then replication across an IPsec tunnel?? </DIV>
<DIV>&nbsp;&nbsp;&nbsp; IMHO, mysql 3.23.x two-way replication is quite shaky and dangerous to rely on.&nbsp; With no locking, you will easily get overwrites and you have to be very sure that your application doesn't mess up the DB.&nbsp; 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>
<DIV>&nbsp;</DIV>
<DIV>===We have 2 or more servers with MysQL 4.1&nbsp;virtual server (clusters balanced by LVS). We use MySQL for maintaining subscribers' accounts, not for location. User location is&nbsp;still in-memory only so far. I am afraid I have to switch to ser 09 in order to use save_memory (thanks Paul!) and forward_tcp() for replication.</DIV>
<DIV><BR>&gt; With regard to t_replicate() - it doesn't work for more than 2<BR>&gt; servers, so I used exactly forward_tcp() and save_noreply() (you're<BR>&gt; absolutely right - this works fine so far); all sers are happy. Of<BR>&gt; course, this causes additional traffic. Interesting whether Paul's<BR>&gt; FIFO patch reduces traffic between sers?&nbsp;&nbsp;&nbsp; <BR></DIV>
<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>
<DIV>g-)</DIV></BLOCKQUOTE><BR><BR><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/">Try our new resources site!</a>