|
On Fri, Jul 14, 2000 at 09:01:56AM -0400, Ted Pavlic wrote:
> That's a good idea too, but I don't think that's exactly what I was talking
> about.
>
> What I was asking about would be something like this:
>
> virtual=192.168.6.2-192.168.6.30:80
> real=192.168.6.240:80 gate
> service=http
> request="index.html"
> receive="Test Page"
> scheduler=rr
>
> Unless you and I have different ideas of what a virtual server is and a real
> server is.
>
> A virtual server to me is address to which the end-user connects which makes
> the end-user believe he is connecting to an actual server, however that
> virtual server request is actually load balanced among a real server or two.
>
> If our definitions are reversed, then your modification is exactly what I
> was talking about.
Your terminology is correct.
> Here's my setup... I have 1029 virtual servers -- that is I have 1029 hosts
> which need to be load balanced. I also have four web servers which will
> serve as real servers
The fwmark support in LVS is designed to permit large numbers of
virtual servers with the same IP address. It has the advantage of
simplfying the amount of _kernel_ configuration that has to be done
which is a big win, even if this is automated by a user space application.
Briefly this is how it works.
The basic idea is that this provides a means for LVS to have virtual
services that have more than one host/port/protocol triplet. In your
situation this means that you can have a single virtual service that
handles many virtual IP addresses and all ports and protocols (UDP, TCP and
ICMP).
You should take a look at
http://ultramonkey.sourceforge.net/ultramonkey-1.0.1/topologies/example-lb-3-fwm
+ark.html
for an example of how this can be set up. My understanding is that this is
quite similar to how your LVS topology will be set up, though I understand
you will be having more than one of these configured.
Basically what happens is that you set up LVS to consider any packets
marked with fwmark 1 to belong to a virtual service. This behaves just
like other LVS virtual services other than that no VIP is specified.
e.g.
ipvsadm -A -f 1 -s rr
ipvsadm -a -f 1 -r 192.168.6.3:80 -m
ipvsadm -a -f 1 -r 192.168.6.2:80 -m
ipvsadm -L -n
IP Virtual Server version 0.9.11 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
FWM 1 rr
-> 192.168.6.3:80 Masq 1 0 0
-> 192.168.6.2:80 Masq 1 0 0
The other half of the equation is that ipchains is used to match incoming
traffic for virtual IP addresses and mark them with fwmark 1. Say you have
8 contiguous class C's of virtual addresses beginning at 192.168.0.0/24.
The
ipchains command to set up matching of these packets would be:
ipchains -A input -d 192.168.0.0/21 -m 1
You also need to set up a silent interface so that the LVS box sees traffic
for the VIPs as local. To do this use:
ifconfig lo:0 192.168.0.0 netmask 255.255.248.0 mtu 1500
echo 1 > /proc/sys/net/ipv4/conf/all/hidden
echo 1 > /proc/sys/net/ipv4/conf/lo/hidden
Now, as long as 192.168.0.0/21 is routed to the LVS box, or more
particularly the floating IP address of the LVS box brought up by
heartbeat, traffic for the VIPs will be routed to the LVS box, the ipchains
rules will mark it with fwmark 1 and LVS will see this fwmark and consider
the traffic as destined for a virtual service.
The command above represent the unix commands to achieve this at the lowest
level. For this configuration to be persistent between reboots you should
refer to the URL given above on Red-Hat-centric ways of doing this. Also
as ldirectord and heartbeat are being used ipvsadm commands, other than
"ipvsadm -L -n" should not be invoked directly.
--
Horms
|
