|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Joseph,
According to the HOWTO text, it seems you misunderstood the purpose of
my patch a little bit: I don't provide a new schedular, but a new
director. This director is very non-intrusive, because it only changes
1 field in the skb and then returns to the normal network stack, at
the same point where "ip_vs_in()" was called. (See piece of proza below:)
Anyway, I changed my patches a bit because of the uglyiness of the
extra FORWARD hook. (See patches in attachment)
In my new patches I provide a Netfilter Target called "LVS" which can
be used in the mangle table on the Forward hook. When used, this
target calls "ip_vs_in()" directly, providing the routing capability
of lvs.
Thus:
1 Packet coming in from LAN.
2 Packet has non-local destination, normal Linux routing will call
ip_forward.
3 Netfilter Forwarding hook is called
4 In the mangle table the following two targets will be called:
#iptables -A FORWARD -t mangle -s <lan-ip> -d 0.0.0.0/0 -m state
- --state NEW -j MARK --set-mark 1
#iptables -A FORWARD -t mangle -m mark --mark 1 -j LVS
5 The LVS target will call ip_vs_in(), with a schedular on fwmark 1,
using the new "reinject" director:
#ipvsadm -A -f 1 -p
#ipvsadm -a -f 1 -j -r <gateway1>
#ipvsadm -a -f 1 -j -r <gateway2>
6 The reinject director will make sure the packet will continue
transfering the mangle table, but with a new Nexthop (skb->dst).
7 The packet will continue through the normal network stack, through
POSTROUTING, etc.
8 The packet will be send towards the internet through the selected
gateway (specified as nexthop).
The provided patches have three unfinished drawbacks:
- -I'm not sure if the kernelpatches compile correctly when used as
modules. Therefor I force the LVS subsystem to "inbuild/yes" when
selecting the iptables target.
- -I didn't check the usage of the iptables target for the FORWARDING
hook. It is still possible to select this target in PREROUTING, even
though this is ineffective, it will not work.
- -It's against 2.6.11 (which is old allready:)
Hopefully I'll find time to clean that up somewhere next week. Or
maybe someone else has time/energy to clean them up?
Some more info for the Howto:
Linux networking is very flexible when it comes to routing. It is
possible to use several internet connections through one router. The
process of selecting from these multiple defaultroutes is called
multipath routing.
One of the remaining problems for multipath routing under Linux is the
lack of flexibility on the scheduling of these multiple defaultroutes.
The normal multipath routing only provides a weight factor, but no
further setup parameters. It is a basic form of load-balancing, but
nothing fancy. Another problem is that multipath routing is only
supported on defaultroutes, not on any route with more than one
possible gateway.
The lvs_reinjection patches are designed to provide the full
effectiveness of the LVS schedulars for deciding which route a given
packet will take. Contrary to normal LVS setups it provides the
possibility to schedule any traffic through the router. With normal
LVS the scheduled service is a local service on the director which is
then transfered to one or more realservers. The solution provided
through these patches can select any traffic passing the director and
then force this traffic through a nexthop/gateway.
At first you'll mark the traffic that should be balanced over the
internet connections by a firewall mark(fwmark).
This can be done on any place in the networking stack, using iptables.
Then you'll need to tell the network stack to send the traffic through
the LVS subsystem. This is done through the use of a new iptables
target called LVS. The purpose of this target is to call the entry
function of LVS.
Basically you can then use any of the LVS functions, any director
available. But of the three standard directors available, non is very
effective for the internet loadbalancing case. The LVS/NAT director
will mangle the headers of the packets, therefor loosing final
destination information. The LVS/TUN director will try to setup a
tunnel to the realservers (in this case: the gateways), but most
gateway's don't provide such a tunnel capability. Only the LVS/DR
director provides effective behaviour: it will send the packets
unmodified to the correct gateway. But the LVS/DR director does this
by bypassing all local routing on the router, and sends the packet
directly through the ethernet drivers output function. This means no
further services, like SNAT, Masquerading, etc. can be done on these
packets.
For this problem the patches introduce a new director, called
LVS/Reinject. This is a very simple director, similar to LVS/DR. But
instead of sending the packet directly out the ethernet device, this
director leaves that to the normal network stack. It just returns back
to where LVS was called in the first place. This means that using this
director in normal LVS setups is ineffective: Normally LVS is called
in "Local_in". Returning there would mean that the packet will try to
be locally delivered. But in combination with the ability to call LVS
on forwarded traffic (through the LVS iptables target) this provides a
very effective setup.
Greetings,
Ludo.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDN/oaOF3sCpZ+AJgRAtUHAKDcXJVGgRGftOUS9shHnM/XjQXLUwCfQ122
ZQ8xEe/ya2d9g8IA5SZLBeg=
=swT1
-----END PGP SIGNATURE-----
|
