<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v =
"urn:schemas-microsoft-com:vml" xmlns:o =
"urn:schemas-microsoft-com:office:office" xmlns:w =
"urn:schemas-microsoft-com:office:word" xmlns:st1 =
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content=Word.Document name=ProgId>
<META content="MSHTML 6.00.2900.2604" name=GENERATOR>
<META content="Microsoft Word 11" name=Originator><LINK
href="cid:filelist.xml@01C53E70.B65A07E0" rel=File-List><LINK
href="cid:editdata.mso" rel=Edit-Time-Data><!--[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]--><o:SmartTagType name="PersonName"
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><!--[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]--><!--[if !mso]>
<STYLE>
st1\:*{behavior:url(#default#ieooui) }
</STYLE>
<![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-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 lang=EN-US style="tab-interval: .5in" vLink=blue link=blue bgColor=white>
<DIV>Alex,</DIV>
<DIV>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.</DIV>
<DIV> I have never tried to configure SER as a forking proxy,
but I wouldn't be surprised if it was possible.</DIV>
<DIV>g-)</DIV>
<DIV> </DIV>
<DIV>---- 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</DIV></BODY></HTML>