[linux-l] Traffic Shaping 1GBit -> 200MBit

[Steffen Dettmer]

* Schlomo Schapiro wrote on Wed, Mar 23, 2005 at 17:24 +0100:
> ich mu? eine GBit Verbindung zwischen zwei Servern auf 200 MBit drosseln 
> (damit ein NFS Backup das Netz nicht dicht macht). Ich habe von 
> http://lartc.org/howto/ mir folgendes Script zusammengestellt:

Ich hatte damals auch ein paar How-Tos gelesen, aber irgendwie konnte
die erwarteten Ergebnisse nicht wirklich reproduzieren... 

> DEV=eth0
> LINK_RATE=1000mbit
> RATE=200mbit

> TARGET=139.65.200.30 # Zielrechner, der per NFS Daten liest
> tc qdisc del dev $DEV root
> tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth $LINK_RATE \
> cell 8

SuSE macht für "reserve 25% for VPN traffic."
$TC class add dev $DEV parent 1:1 classid 1:11 htb \
	rate ${VPN_BW}kbit ceil ${BANDWIDTH}kbit prio 1

also HTB (weiss nicht, ob CBQ günstiger ist) ka. Über ein "handle 1"
könnte man so evtl. einfach ein "ceil 200mbit" setzen.

Ich hab CQB nie benutzt. Ich würde einfach per Firewall ein "MARK"
machen. Für einen Port 2379 verwende ich:

$IPTABLES -A POSTROUTING -t mangle -o $DEV -p tcp \
	-m tos --tos Minimize-Delay \
	-m tcp --dport 2379 -j MARK --set-mark 10

sollte man ja einfach auf destination-address oder wie das heisst
anpassen können und ggf. vereinfachen können (ich hab nur Angst, was
falsches zu schreiben, daher kein Vorschlag :)).

Na, und dann eben (in entsprechendem Context nach del root etc)

tc class add dev $DEV parent 1:1 classid 1:11 htb \
	rate 200mbit ceil 200mbit prio 1

> Leider drosselt es die Verbindung um den Faktor 100 und nicht um den 
> Faktor 5 !!

Ist das UDP oder TCP NFS? Das Problem ist ja AFAIK, das der
TrafficShaper Pakete lediglich dropt, wenn es zuviele werden. Wenn man
bei TCP wiederholt Pakete droppt, greift der exponentielle Backoff-Kram
da, und es bricht schnell der Traffic regelrecht ein. Das fällt bei
diversen FileSharing-Programmen für das Verteilen grosser Kochrezepte
auf: wenn man auf Applikationsebene keine Begrenzung hat, sondern nur
Traffic-Shaping macht, fängt der Datendurchsatz an "zu schwingen". Wenn
man nur eine Verbindung hat, schwingt der, hat man etliche, verteilt
sich das "hin und her". Insbesondere sollte man bei TCP "ACK" Pakete
immer "durchlassen", was aber nicht wirklich geht, weil TCP ja keine
"ACK Pakete" hat - bzw. jedes ein solches ist. In der Praxis fliessen
die Daten oft vermehrt in nur eine Richtung, so dass es in der Praxis
ganz gut hilft, einfach kleine Pakete zu prioritisieren (macht
SuSEFirewall2 z.B. so).

Bei UDP-NFS ist ein Paketverlust AFAIK eine mittlere Katastrophe, weil
dann 10sec oder so gewartet wird. Wenn dann (müsste man mit einen
Netzwerkmonitor a la ethereal sehen) immer nur ganz kurz UDP Traffic
ist, liegt Dein Problem möglicherweise hier:
- schnell viele Daten
- Paketdrop
- 10 sec warten
- schnell viele Daten - und sofort wieder
- Paketdrop
- 10 sec warten
 
(weiss nicht, ob man die 10s einstellen kann - IMHO für'n LAN ein
ziemlich bekloppter Wert. Meine Erfahrungen hier sind aber mit gaaaanz
alten Servern, 2.2er kernel und so).

> Hat einer von Euch Erfahrung in diesem Umfeld ? Wie kann ich den NFS 
> Verkehr zu dem Backup Server entsprechend drosseln ?

rsync!

Ich nehm immer gern rsync (skaliert auch gut; später könnte man z.B.
externe Hosts via SSH holen - ich verwende rsync immer über SSH, das NFS
nur da, wo's sein muss, sprich $HOME und sowas). rsync kann ein:

	--bwlimit=KBPS          limit I/O bandwidth, KBytes per second

und noch viel viel anderes. IMHO für Backupaufgaben /
Filesystemsynchronisation / Verzeichnissynchronisation einfach prima. So
ein "rsync -e ssh -a /src/ user at host:/dest/" [1] oder was in der Art ist
auch im Alltag oft sehr hilfreich.

rsync überträgt nur geänderte Dateien, was natürlich schnell viel
Traffic spart! NFS ist dagegen systembedingt ineffizienter (dafür
"echtzeit").

oki,

Steffen

[1] Noch besser ist natürlich ein 
    export RSYNC_RSH=`which ssh`
    in einem Startsript (profile oder so).
-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.