|
On Sun, 23 Dec 2007, chris barry wrote:
> Ok, sorry to reply to my own post, but is this such a stupid question,
> that when everyone saw it, they basically said "what an idiot!" and
> immediately deleted it? It may well be an ignorant question, and maybe
> I /should/ already know it, but I really did google all around, and
> could not find anything on it. The whole thing is pretty much black
> magic to me, and I'm just trying to grok it.
this is the most fundamental question about how LVS works.
All of the behaviours of LVS depend on how/where you hook
LVS into the netfilter tables.
There is a diagram/gif by Horms in the HOWTO I'll let you
find it.
Because LVS was originally riding on the coattails of the
masquerading code (ie only LVS-NAT existed), and ip_vs()
on the director only accepted packets for one IP, an IP to
which a service was listening, LVS hooked into the LOCAL_IN
chain. This required the director to have an IP=VIP. The
director was re-routing packets for a service that was
actually listing on an IP on a backend machine (now called
the realserver) and the VIP only existed on the director to
be able to flag the packets of interest to ip_vs()
LVS-DR, fwmarks, LVS's with many IPs and the rewriting of
LVS to be now be based on netfilter (late 2.2 kernels)
rather than masquerading code, it became obvious that the
director was only a router (but with somewhat different
rules than a regular router), and like a router didn't need
to have the IP of any packets that it was routing. Although
the best choice at the time, when based on 2.0.x kernels and
masquerading code for a service listening on an IP, in the
new framework, LOCAL_IN was no longer a good place to hook
LVS.
Horms has written an version of LVS that hooks into
PRE_ROUTING which seems to work OK. It is now generally
agreed (i.e. Horms say so, and it is OK with me) that LVS
should be in the FORWARD chain, where LVS can best look like
a router, and the director will not need a the VIP.
Unfortunately no-one has yet had the time to rewrite
(and test) LVS in the FORWARD chain.
So LVS could be hooked almost anywhere and you just have to
tell the users the expected behaviours. Currently LVS is
hooked into LOCAL_IN, which we can live with, but which is
no longer the best place.
> <...pouring more eggnog...>
having my 4th cup of Chateau cardboard (Australian delicacy)
that I found in the tax free liquor store in New Hampshire
(USA) on the way to my holiday in Maine (I now live in USA).
Joe
--
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!
|
