|
> Wow, policy load balabcing.
>
> This would be posible if you matched the packets with the disired
> source addresses and tagged them with apropriate marks, using the
> -m option to ipchains. Then set up ipvs virtual services
> matching on the firwall marks, using ipvsadm -A -f ... .
>
> See the man page for the ipvsadm (>=v1.9) for details on
> using the -f option.
>
> I am thinking that I should write a mini-howoto on the many and varied
> problems people are coming up with that the frewall mark code can
> be used for.
>
> --
> Horms
Hi
That's actually what I'm trying now since weeks. A known problem of
some current internet providers is, that they run out of IP associated
with NAT, so they do something like rr loadbalancing NAT. I mean by
that, that it can be possible for a session, that the sourceIP changes
before the masq entry timeouts but the client is still the same. So
the loadbalancer would of course generate a new entry and forward to
a new server. This can be annoying with persistency and Lars therefor
wrote the netmask patch. But if you configure persistency with a mask,
other people which probably don't come from the same ISP but match the
mask will also be affected and this leads into load imbalance. So in
grabbing the new ip_vs-patch with fwmark support I hoped to overcome
this problem by making following appoach:
/sbin/ipvsadm -A -t 192.168.100.100:0 -s wrr -p 200 -M 255.255.255.255
/sbin/ipvsadm -a -t 192.168.100.100:0 -r 192.168.100.10:0 -g -w 1
/sbin/ipvsadm -a -t 192.168.100.100:0 -r 192.168.100.11:0 -g -w 1
/sbin/ipvsadm -a -t 192.168.100.100:0 -r 192.168.100.12:0 -g -w 1
/sbin/ipvsadm -a -t 192.168.100.100:0 -r 192.168.100.13:0 -g -w 1
ipvsadm -A -f 3 -s wrr -p
ipvsadm -a -f 3 -r 192.168.100.10 -g -w 1
ipvsadm -a -f 3 -r 192.168.100.11 -g -w 1
ipvsadm -a -f 3 -r 192.168.100.12 -g -w 1
ipvsadm -a -f 3 -r 192.168.100.13 -g -w 1
ipchains -A input -p tcp -s 172.23.2.32/27 -d 192.168.100.100/24 80 \
-m 3 -j ACCEPT
The output correctly shows:
IP Virtual Server version 0.9.12 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.100.100:0 wrr persistent 200
-> 192.168.100.13:0 Route 1 0 0
-> 192.168.100.12:0 Route 1 0 0
-> 192.168.100.11:0 Route 1 0 0
-> 192.168.100.10:0 Route 1 0 0
FWM 3 wrr persistent 200
-> 192.168.100.13:0 Route 1 0 0
-> 192.168.100.12:0 Route 1 0 0
-> 192.168.100.11:0 Route 1 0 0
-> 192.168.100.10:0 Route 1 0 0
The problem is, that clients coming from 172.23.2.[32-64] or correctly
marked but unfortunately they are distributed as if persistency does
not apply to them. A short look into the code and the concept show it
and it's clear. However, it would be nice, if a mark could be handled
like a single entity which would always be redirected to the same
server in case of persistency. And the second additional feature which
would be nice is, that one could specify multiple fwmarks as a group
acting as one service. Then one could specify pools of IPs. Example
ipchains -A input -p tcp -s 192.168.100.0/24 -d 192.168.100.100/24 80 \
-m 1 -j ACCEPT
ipchains -A input -p tcp -s 138.190.199.128/28 -d 192.168.100.100/24 80
\
-m 2 -j ACCEPT
ipchains -A input -p tcp -s 172.23.2.32/27 -d 192.168.100.100/24 80 \
-m 3 -j ACCEPT
ipvsadm -A -f 1,2,3 -s wrr -p 200 -M 255.255.255.255
and normal compulsory stuff...
The output would be as follows:
IP Virtual Server version 0.9.13 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.100.100:0 wrr persistent 200
-> 192.168.100.13:0 Route 1 0 0
-> 192.168.100.12:0 Route 1 0 0
-> 192.168.100.11:0 Route 1 0 0
-> 192.168.100.10:0 Route 1 0 0
FWM 1,2,3 wrr persistent 200
-> 192.168.100.13:0 Route 1 0 0
-> 192.168.100.12:0 Route 1 0 0
-> 192.168.100.11:0 Route 1 0 0
-> 192.168.100.10:0 Route 1 0 0
So every CIP coming with fwmark 1 would f.e. go to 192.168.100.10
every CIP coming with fwmark 2 would f.e. go to 192.168.100.11
every CIP coming with fwmark 3 would f.e. go to 192.168.100.12
a new CIP coming without fwmark would f.e. go to 192.168.100.10
the next CIP coming without fwmark would f.e. go to 192.168.100.11
and so on...
Hope I could express myself in a more or less understandable way.
I've already setup something that works in that direction but its
extremely ugly with lots of service entries.
Any help or suggestions appreciated.
Thank you,
Roberto Nibali, ratz
|
