<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=ProgId content=Word.Document>
<meta name=Generator content="Microsoft Word 11">
<meta name=Originator content="Microsoft Word 11">
<link rel=File-List href="cid:filelist.xml@01C53F59.F4FDCC40">
<link rel=Edit-Time-Data href="cid:editdata.mso">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:DoNotRelyOnCSS/>
</o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:SpellingState>Clean</w:SpellingState>
<w:GrammarState>Clean</w:GrammarState>
<w:DocumentKind>DocumentEmail</w:DocumentKind>
<w:EnvelopeVis/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
</w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" LatentStyleCount="156">
</w:LatentStyles>
</xml><![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;
        mso-font-charset:0;
        mso-generic-font-family:swiss;
        mso-font-pitch:variable;
        mso-font-signature:1627421319 -2147483648 8 0 66047 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {mso-style-parent:"";
        margin:0in;
        margin-bottom:.0001pt;
        mso-pagination:widow-orphan;
        font-size:12.0pt;
        font-family:"Times New Roman";
        mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline;
        text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
        {color:blue;
        text-decoration:underline;
        text-underline:single;}
span.EmailStyle17
        {mso-style-type:personal;
        mso-style-noshow:yes;
        mso-ansi-font-size:10.0pt;
        mso-bidi-font-size:10.0pt;
        font-family:Arial;
        mso-ascii-font-family:Arial;
        mso-hansi-font-family:Arial;
        mso-bidi-font-family:Arial;
        color:navy;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        mso-style-noshow:yes;
        mso-ansi-font-size:10.0pt;
        mso-bidi-font-size:10.0pt;
        font-family:Arial;
        mso-ascii-font-family:Arial;
        mso-hansi-font-family:Arial;
        mso-bidi-font-family:Arial;
        color:navy;}
span.SpellE
        {mso-style-name:"";
        mso-spl-e:yes;}
span.GramE
        {mso-style-name:"";
        mso-gram-e:yes;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;
        mso-header-margin:.5in;
        mso-footer-margin:.5in;
        mso-paper-source:0;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
        {mso-style-name:"Table Normal";
        mso-tstyle-rowband-size:0;
        mso-tstyle-colband-size:0;
        mso-style-noshow:yes;
        mso-style-parent:"";
        mso-padding-alt:0in 5.4pt 0in 5.4pt;
        mso-para-margin:0in;
        mso-para-margin-bottom:.0001pt;
        mso-pagination:widow-orphan;
        font-size:10.0pt;
        font-family:"Times New Roman";
        mso-ansi-language:#0400;
        mso-fareast-language:#0400;
        mso-bidi-language:#0400;}
</style>
<![endif]--><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=white lang=EN-US link=blue vlink=blue style='tab-interval:.5in'>
<div class=Section1>
<p class=MsoNormal><span class=SpellE><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy'>Greger</span></font></span><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>,<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I am not an expert on <span class=SpellE>anycast</span>
as well. I just know it exists and people are starting to look at it more
seriously for HA option. That is why I though DNS SRV records would be an
easier solution. Regarding your comments on NAT, I don’t believe it is an
issue as it relates to forking proxy. Forking proxy should not resolve <span
class=GramE>NAT,</span> it is a job for its peers. As for configuring SER as
forking proxy, I thought I read about it a while back, but now I can’t
seem to locate it. I hope I was not dreaming ;-).<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>In any case, I will continue to <span
class=SpellE>google</span> around to see if SER has this option. <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Sincerely,<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Alex<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> Greger V. Teigre
[mailto:greger@teigre.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, April 12, 2005 6:21
AM<br>
<b><span style='font-weight:bold'>To:</span></b> Alex Vishnev;
serusers@lists.iptel.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: LVS, load
balancing,and stickness was ==> Re: [Serusers] moreusrloc synchronization</span></font><o:p></o:p></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Alex,<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>I'm not really knowledgable enough about anycast to say anything
useful. The only is that in your described setup, I cannot really see how
you get around the UA behind restricted (or worse) NAT.<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> I have never tried to configure SER as a forking
proxy, but I wouldn't be surprised if it was possible.<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>g-)<o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'> <o:p></o:p></span></font></p>
</div>
<div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>---- Original Message ----<br>
From: Alex Vishnev<br>
To: serusers@lists.iptel.org<br>
Sent: Monday, April 11, 2005 02:30 PM<br>
Subject: RE: LVS, load balancing, and stickness was ==> Re: [Serusers]<br>
moreusrloc synchronization <br>
<br>
> Greger and Paul,<br>
> <br>
> I think you understood me correctly regarding forking proxy. It is<br>
> the proxy that will fork out the requests to all available peering<br>
> proxies. This approach does not require stickiness based on Call-id.<br>
> AFAIK, once the forking proxy receives an acknowledgement from one of<br>
> its peers, then the rest of the session will be done directly to that<br>
> peer without the use of the forking proxy. I am considering 2 <br>
> approaches to resolve availability of forking proxy. 1 – using<br>
> ANYCAST (good high level article:<br>
> http://www.kuro5hin.org/story/2003/12/31/173152/86). 2 – using dns<br>
> srv. I am still trying to determine if ANYCAST is a good solution for<br>
> creating local RPs with forking proxy. However, I think that dns srv<br>
> records can easily be implemented to allow simple round robin between<br>
> multiple forking proxies.
Thoughts? <br>
> <br>
> Alex<br>
> <br>
> <br>
> <br>
> <br>
> From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org]<br>
> On Behalf Of Greger V. Teigre <br>
> Sent: Monday, April 11, 2005 4:47 AM<br>
> To: kramarv@yahoo.com<br>
> Cc: serusers@lists.iptel.org<br>
> Subject: LVS, load balancing, and stickness was ==> Re: [Serusers]<br>
> more usrloc synchronization <br>
> <br>
> After my last email, I looked at ktcpvs and realized I ignored a<br>
> couple of things: ktcpvs only supports tcp (http is obviously<br>
> tcp-based, but I thought it supported udp for other protocols). I<br>
> don't know how much work implementing udp would be. <br>
> Here is a discussion of SIP and LVS that I found
useful (though<br>
> not encouraging). <br>
>
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.services_that_dont_work_yet.html<br>
> <br>
> Paul: I'm starting to get really curious on the standard LVS<br>
> components used for your stickiness! I'm not aware (also after<br>
> searching now) of an LVS balancing mechanism that allows correct<br>
> stickness on SIP udp...! <br>
> And I found other too who are looking for it:<br>
> http://archive.linuxvirtualserver.org/html/lvs-users/2005-02/msg00251.html<br>
> <br>
> My understanding is that ipvs must be extended (according to the<br>
> developer) with a call-id based scheduler and that this work has<br>
> several people willing to fund development, but that this has not(?)<br>
> started yet. The problem is that ipvs is based on ip header analysis<br>
> and extending the hashing algorithms to also include payload-based<br>
> analysis is not straight-forward. <br>
> g-)<br>
> <br>
>> With regards to stickiness: Have you looked at ktcpvs? SIP is an<br>
>> "http-like" protocol and I'm pretty sure that you can use
the<br>
>> http-based regex hashing to search for Call-Id. If you cannot
use it<br>
>> right out of the box, I'm pretty sure the modifications are minimal.<br>
>> The user location problem: With a cluster
back-end, I also only<br>
>> see save_memory() as the only option.<br>
>> g-)<br>
>> <br>
>>> "Greger V. Teigre" <greger@teigre.com> wrote:<br>
>>>> 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>
>>> <br>
>>> <br>
>>> Yes, if you use LVS with direct routing or tunneling, that is what<br>
>>> you experience.<br>
>>> ===Of course. That why I implemented small "session"
stickness.<br>
>>> However, it causes additional internal traffic.<br>
>>> <br>
>>> What I described was a "generic" SIP-aware load
balancer where SIP<br>
>>> messages would be rewritten and stickiness implemented based on
ex.<br>
>>> UA IP address (or call-id like vovida's load balancer).<br>
>>> ====Sure, it's better solution; I think we'll go this way soon (in<br>
>>> our next version).<br>
>>> <br>
>>>> Why DNS approach is bad (except restricted NAT - let's say I
am<br>
>>>> solving this)?<br>
>>> <br>
>>> Well, IMO, DNS SRV in itself is not bad. It's just that many user<br>
>>> clients do not support DNS SRV yet. Except that, I like the
concept<br>
>>> and it will give you a geographical redundancy and load balancing.<br>
>>> ===I am trying to build the following architecture:<br>
>>> <br>
>>> DNS (returns domain's public IP)->LVS+tunneling (Virtual
IP)->ser<br>
>>> clusters (with private IPs)<br>
>>> <br>
>>>> <br>
>>> <br>
>>>> <br>
>>>
DB<br>
>>> (MySQL 4.1 cluster)<br>
>>> <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>
>>> <br>
>>> Are you referring to the load balancer proxy? IMHO, the SIP-aware<br>
>>> load balancer makes things a bit messy. It sounds to me that
the<br>
>>> LVS + tunneling/direct routing + virtual IP on dummy adapter is a<br>
>>> better solution.<br>
>>> <br>
>>>> In my configuration I use shared remote DB cluster (with<br>
>>>> replication). Each ser see it as one-public-IP (exactly the<br>
>>>> approach you named for SIP). May be it's good idea to use
local DB<br>
>>>> clusters, but if you have more than 2 servers your replication<br>
>>>> algorythm gonna be complex. Additional problem - it still
doesn't<br>
>>>> solve usrloc synchronization - you still have to use<br>
>>>> t_replicate()... <br>
>>> <br>
>>> <br>
>>> I'm not sure if I understand.<br>
>>> ===Oh, probably I expressed myself not well enough...<br>
>>> <br>
>>> So, you have 2 servers at two location, each location with a
shared<br>
>>> DB and then replication across an IPsec tunnel??<br>
>>> IMHO, mysql 3.23.x two-way replication is
quite shaky and<br>
>>> dangerous to rely on. With no locking, you will easily get<br>
>>> overwrites and you have to be very sure that your application<br>
>>> doesn't mess up the DB. I haven't looked at mysql 4.1
clustering,<br>
>>> but from the little I have seen, it looks good. Is that what you<br>
>>> use? <br>
>>> <br>
>>> ===We have 2 or more servers with MysQL 4.1 virtual server
(clusters<br>
>>> balanced by LVS). We use MySQL for maintaining subscribers'<br>
>>> accounts, not for location. User location is still in-memory only<br>
>>> so far. I am afraid I have to switch to ser 09 in order to use<br>
>>> save_memory (thanks Paul!) and forward_tcp() for replication.<br>
>>> <br>
>>>> 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>
>>> <br>
>>> I believe Paul uses forward_tcp() and save_memory() to save the<br>
>>> location to the replicated server's memory, while the<br>
>>> save("location") on the primary server will store to the
DB (which<br>
>>> then replicates on the DB level).<br>
>>> g-)<br>
>>> <br>
>>> <br>
>>> <br>
>>> <br>
>>> <br>
>>> Do you Yahoo!?<br>
>>> Yahoo! Small Business - Try our new resources site!<br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> Serusers mailing list<br>
> serusers@lists.iptel.org<br>
> http://lists.iptel.org/mailman/listinfo/serusers<o:p></o:p></span></font></p>
</div>
</div>
</body>
</html>