[Debian] Loadbalancing via een IP-tunnel, wil niet..

[Snow_King]

Hallo,

Ik heb de search er op nageslagen maar zag dat er weinig over LVS wordt gesproken hier, toch hoop ik dat er mensen zijn met verstand van deze kwestie.

LVS staat voor Linux Virtual Server (www.linuxvirtualserver.org) en daarmee kan je clusters maken.

Ik draai nu 3 webservers via NAT achter een LVS loadbalancer, dat werkt opzich best fijn, maar je zit aan het limiet van +/-88Mbit ivm het herschrijven van de pakketjes.

Nu wil ik over naar de IP-tunnel methode, maar dat lukt me niet.

De opstelling
Loadbalancer:
- XP2400+
- 512MB DDR
- 40GB Maxtor
- 1Gbit 3Com (eth0)
- 100Mbit 3Com (eth1)
- 2.4.27 Kernel met IPVS support

Webservers:
- P4 3.2Ghz
- 1GB DDR
- 2x 3Com 100Mbit
- 2.4.27 kernel met IPVS support

De webservers hebben hun /home gemount op een fileserver, maar dat is bij mijn probleem niet relevant, dat functioneert juist.

Als ik de IP-tunnel pagina (http://www.linuxvirtualserver.org/VS-IPTunneling.html) er op na sla moet het het volgende worden:

De IP's
Gateway: 192.168.1.1
Virtuele IP: 192.168.1.2 (Hier moeten alle web requests op binnen komen)
Loadbalancer: 192.168.1.3
Webserver 1: 192.168.1.4
Webserver 2: 192.168.1.5

Aan de hand van de Documentatie heb ik de volgende configuratie gemaakt:

Loadbalancer

auto eth0 eth0:1 eth1
iface eth0 inet static
address 192.168.1.3
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1

iface eth0:1 inet static
address 192.168.1.2
netmask 255.255.255.255
broadcast 192.168.1.2

iface eth1 inet static
address 10.0.0.1
netmask 255.255.255.0

En dan op de webservers (Uiteraard is het adres van eth0 bij elke webserver anders )

auth eth0 eth1 tunl0
iface eth0 inet static
address 192.168.1.4
netmask 255.255.255.0
broadcast 213.189.21.255
gateway 192.168.1.1

iface eth1 inet static
address 10.0.0.5
netmask 255.255.255.0

iface tunl0 inet static
address 192.168.1.2
netmask 255.255.255.255
broadcast 192.168.1.2

Dan moet op de loadbalancer het volgende worden uitgevoerd

#!/bin/sh
echo 1 > /proc/sys/net/ipv4/ip_forward
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0
route add -host 192.168.1.2 dev eth0:1
ipvsadm -A -t 192.168.1.2:80 -s wlc
ipvsadm -a -t 192.168.1.2:80 -r 192.168.1.4 -i -w 1
ipvsadm -a -t 192.168.1.2:80 -r 192.168.1.5 -i -w 1

En op de webservers

#!/bin/sh
echo 1 > /proc/sys/net/ipv4/ip_forward
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0
route add -host 192.168.1.2 dev tunl0

De 10.0.0.x adressen zijn voor het interne netwerk tussen de servers in, dat doet voor mijn bovenstaande verhaal er niet toe.

Helaas werkt dit niet.

Wat gaat er fout?
Een van de webservers "claimed" het IP en stelt zo de loadbalancer + andere webserver buiten spel, weg redundatie dus.

Nu moet ik ergens een fout maken bij het IP-tunnelen, maar echt wijs wordt ik niet uit die site en goede howto's heb ik niet kunnen vinden.

Alvast bedankt voor in ieder geval de moeite te nemen deze lange post te lezen.

N.B. Gebruikt T.net btw ook niet LVS?

[ Voor 5% gewijzigd door Snow_King op 04-11-2004 20:16 ]

[Kees]

Ja, t.net gebruikt ook LVS, maar ik snap niet waarom jij maar 88mbit haalt met NAT, ik haal hier met gemak de voole 100Mbit op een p3 1-ghz

[Snow_King]

Zoals op (http://www.linuxvirtualserver.org/how.html) te lezen is.

The disadvantage is that the scalability of the virtual server via NAT is limited. The load balancer may be a bottleneck of the whole system when the number of server nodes (general PC servers) increase to around 20 or more, because both the request packets and response packets are need to be rewritten by the load balancer. Supposing the average length of TCP packets is 536 Bytes, the average delay of rewriting a packet is around 60us (on Pentium processor, this can be reduced a little by using of higher processor), the maximum throughput of the load balancer is 8.93 MBytes/s. Assuming the average throughput of real servers is 400Kbytes/s, the load balancer can schedule 22 real servers.

Gebruikt T.net wel NAT voor het loadbalancen en niet TUN of DR?

Het nadeel aan NAT is ook het poorten forwarden voor passive FTP e.d., daar bied TUN een uitkomst.

Enig idee wat ik fout doe?

[Kees]

Nee, maar ik gebruik wel gewoon NAT, we zitten nog niet zover (+20) servers dat ik erover zou denken om DR te gaan gebruiken (tun zowiezo niet).

Met NAT kun je prima de FTP gebruiken volgens mij? zit niet voor niets een ftp helper module in lvs/netfilter

[Snow_King]

Ik die net dat DR voor mij beter van toepassing is dan TUN, aangezien en servers allemaal aan de zelfde switch hangen.

[stefklep]

Snow_King schreef op 05 november 2004 @ 12:48:
Ik die net dat DR voor mij beter van toepassing is dan TUN, aangezien en servers allemaal aan de zelfde switch hangen.

Ben er zelf ook druk mee bezig. Heb wel een goede howto gevonden mischien heb je er zelf ook wat aan. Bij mijn werkt het prima met LVS op gentoo met 3 webserver met Freebsd er op.

De volgende link
http://perlstalker.amigo.net/Gentoo/LVS.phtml

Als je andere goede link hebt ofzo ben ik er ook wel in geintresseerd.

[Snow_King]

Welke LVS heb jij? DR? NAT? of TUN?

Ik vond deze Howto nog: http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/

[Gondor]

Misschien denk ik te simpel, maar waarom gebruik je niet iptables voor loadbalancing?

Uit de iptables-tutorial:

iptables -t nat -A PREROUTING -p tcp -d 15.45.23.67 --dport 80 -j DNAT --to-destination 192.168.1.1-192.168.1.10

The above example would send on all packets destined for IP address 15.45.23.67 to a range of LAN IP's, namely 192.168.1.1 through 10. Note, as described previously, that a single stream will always use the same host, and that each stream will randomly be given an IP address that it will always be Destined for, within that stream.

In jouw geval zou die regel ongeveer zo uit zien:

code:

iptables -t nat -A PREROUTING -p tcp -d 192.168.1.2 --dport 80 \
 -j DNAT --to-destination 192.168.1.4-192.168.1.5

Of is het niet zo simpel?

[moto-moi]

Gondor schreef op 06 november 2004 @ 12:12:
In jouw geval zou die regel ongeveer zo uit zien:

code:

iptables -t nat -A PREROUTING -p tcp -d 192.168.1.2 --dport 80 \
 -j DNAT --to-destination 192.168.1.4-192.168.1.5

Of is het niet zo simpel?

Da's round robin, gewoon @ random een ip pakken en daar de meuk naartoe sturen, load balancing zorgt er juist voor dat de server met de minste load de request krijgt, zodoende ervoor zorgend dat niet een server alle requests krijgt.

[Snow_King]

Gondor schreef op 06 november 2004 @ 12:12:
Misschien denk ik te simpel, maar waarom gebruik je niet iptables voor loadbalancing?

Uit de iptables-tutorial:

[...]

[...]

In jouw geval zou die regel ongeveer zo uit zien:

code:

iptables -t nat -A PREROUTING -p tcp -d 192.168.1.2 --dport 80 \
 -j DNAT --to-destination 192.168.1.4-192.168.1.5

Of is het niet zo simpel?

Dan zitten de servers alsnog via NAT achter de loadbalancer en dat beperkt de doorvoer, dat wil ik juist niet.