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

[Schlomo Schapiro]

Hi,

ja, ich hatte auch schon htb.init probiert, mit demselben Ergebnis. Sowohl 
NFS per UDP als auch ein syntethischer netcat Test per TCP verhalten sich 
da identisch.

cbq.init scheint erst auf Kernel 2.6 zu funktionieren, oder mit besonderen 
Patches. Auf dem SLES8 hat es zumindest cbq gar nicht gegeben.

Leider gibt es hier zu NFS auch keine Alternative, da eine Backupsoftware 
per NFS einen entfernten Server abzieht - in situ. Das geht mit rsync 
nicht.

Gruß,
Schlomo

On Wed, 6 Apr 2005, Steffen Dettmer wrote:

> * 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).
>

-- 
Regards,
Schlomo