11 Apr
2005
11 Apr
'05
9:37 p.m.
Hi All.
I don't know if I'm going to be of any help here as I've mentioned before
that I'm as dumb as a door knob when it comes to the network and/or
clustering stuff.
Our underlying network (ie, BGP pipes, routers, firewalls, LVS, MySQL
clusters, SIP clusters, Asterisk clusters, NFS storage, etc, etc) have been
implemented by the engineers we hired from Red Hat.
These guys have implmented (AFAIK) our network layer the same way Google has
done their WWW farm(s). They have intimate knowledge of Google's internal
infrastucture because they worked between Red Hat and Google for about 6
years.
All I know is that it has taken about 4 months of work to get things stable.
We understand that a VoIP platform isn't about the softswitch - but rather
the network. I've asked on more than one occasion if I could release our
network configuration to serusers and the answer has always been "no", so
there's not much I can contribute here.
The ser source files are another story. We fully shared our ser.cfg, tcp/udp
network patch, usrloc patch, etc - but that doesn't help with this.
The only bright point I can offer here is that I'm 100% certain that the LVS
source code has __not__ been modified.
Sorry,
Paul
On Apr 11, 2005 4:46 AM, Greger V. Teigre <greger(a)teigre.com> wrote:
After my last email, I looked at ktcpvs and realized I ignored a couple of
things: ktcpvs only supports tcp (http is obviously tcp-based, but I thought
it supported udp for other protocols). I don't know how much work
implementing udp would be.
Here is a discussion of SIP and LVS that I found useful (though not
encouraging).
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.services_that_dont_w…
Paul: I'm starting to get really curious on the standard LVS components
used for your stickiness! I'm not aware (also after searching now) of an LVS
balancing mechanism that allows correct stickness on SIP udp...!
And I found other too who are looking for it:
http://archive.linuxvirtualserver.org/html/lvs-users/2005-02/msg00251.html
My understanding is that ipvs must be extended (according to the
developer) with a call-id based scheduler and that this work has several
people willing to fund development, but that this has not(?) started yet.
The problem is that ipvs is based on ip header analysis and extending the
hashing algorithms to also include payload-based analysis is not
straight-forward.
g-)