Dotaz: HTB efektivita

[kapitan]

Dobry den,

mam problem s vytizenim serveru pri shapovani. Kdyz vypnu shaper je to v poradku. Pouzivam HTB a markuju pomoci iptables.

Prikladam cast shaperu:

/root/sbin/tc qdisc del dev eth0 root 2>/dev/null
/root/sbin/tc qdisc del dev eth0 ingress 2>/dev/null
/root/sbin/tc qdisc add dev eth0 root handle 1:0 htb r2q 2
/root/sbin/tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100Mbit ceil 100Mbit

/root/sbin/tc class add dev eth0 parent 1:1 classid 1:2 htb rate 50000kbit ceil 50000kbit

/root/sbin/tc class add dev eth0 parent 1:2 classid 1:2101 htb rate 1024kbit ceil 1500kbit prio 3

/root/sbin/tc class add dev eth0 parent 1:2 classid 1:2102 htb rate 1024kbit ceil 1500kbit prio 3

# Vytvoreni sfq pravidel..
/root/sbin/tc qdisc add dev eth0 parent 1:2101 handle 2101:0 sfq perturb 15

/root/sbin/tc qdisc add dev eth0 parent 1:2102 handle 2102:0 sfq perturb 15

#iptables pravidla
/sbin/iptables -t mangle -A FORWARD -s 192.168.190.0/24 -j MARK --set-mark 3
/sbin/iptables -t mangle -A FORWARD -d 192.168.190.0/24 -j MARK --set-mark 3

/sbin/iptables -t mangle -A FORWARD -s 172.16.1.254 -j MARK --set-mark 4
/sbin/iptables -t mangle -A FORWARD -d 172.16.1.254 -j MARK --set-mark 4
 

/root/sbin/tc filter add dev eth0 parent 1:0 protocol ip handle 3 fw flowid 1:2101

/root/sbin/tc filter add dev eth0 parent 1:0 protocol ip handle 4 fw flowid 1:2102

takto shapuji na eth0 jeste to same mam na eth1. A shapuji pro asi 2000 IP adres. tady jsem poslal usek pro dve IP adresy.

Nenapada nekoho jak to zefektivnit protoze zatez serveru je ve vecernich hodinach dosti zalostna :(

Dekuji

Odpovědi

[Opičák]

Ono to asi ani tak nebrzdí HTB jak to markování. Doporučuju nastudovat jak funguje Prometheus, který vyvinul někdo z Czfree. Používá nejspíš nějaké hashe pro iptables a tak ulehčuje procesoru.

[Zdeněk Štěpánek]

Nepouziva, to si jenom xChaos mylne mysli. Ostatne je to pekne popsane v threadu o verzi 0.6.

Nenapsal jsi zakladni veci. Kolik Mbit tam shapujes a co je to za stroj. Bez toho je to jen vesteni z kristalove koule.

Zdenek

[kapitan]

Shapuju zhruba 40-50 Mbit. A stroj je 3 Ghz P4, 2GB RAM, tedy zatim mam Realteaky ale uz jsem objednal Intel.Zkousel jsem i jine PC take nepomohlo.

Jeste tedy zaroven natuju na serveru jestli to nemuze delat potize.

[the.max]

realteky vyhodit, zadupat do zeme a rychle zapomenout. Porid si jakykoli jiny i vyprodejovy sitovky co nemaj realtekovej cip a pak neco zkousej dal. Kamos mel na hostingovym serveru taky realteka ave odpolednich avecernich hodinach mu sel load az nekam do nebes. po vymene za jetyho 3coma za 120kc spadlo vytizeni serveru mimo spicku o 20% a ve spicce mel maximalne 80% ato uz muselo bejt..

[Opičák]

To jsem četl. Nicméně stále je to krok kupředu a je to spíš dohadování se o názvu. On nepopiratelně ulehčuje procesoru práci a to že to někdo za hash nepovažuje je už spíš dohadování se o principu. Všichni mu tam hází klacky pod nohy, ale nikdo mu nepomohl. Přitom to většina z nich používá.

[xxl]

Musíte místo markování použít tc filtry. http://lartc.org/howto/lartc.adv-filter.html

[Opičák]

pokud používá NAT, tak tc filtry nebudou k ničemu.

[kapitan]

Pouzivam NAT. Ale kdyz tohle markuju ve FORWARDu tak i oznacovanim pomoci tc by mohlo take jit. Vyzkousim.

Jinak jsem tehda udelal toto: pouzivame IP: 172.16.0.0/16. Tak jsem to iptables vytvoril pravidla

-A FORWARD -d 172.16.182.0/255.255.255.0 -j pravidlo_16_182

tim iptables nemusi projit 2000 radku ale jen mensi cast. Doufal jsem ze to pomuze ale nic moc vyrazne to nezlepsi :(

[kapitan]

Jen pro jistotu mam zkusit misto iptables pouzit toto jednou pro eth0 a jednou pro eth1?

tc filter add dev eth0 parent 1:0 protocol ip prio 5 u32 match ip src x.x.x.x flowid 1:2

Dekuji

[xxl]

To by asi šlo. Ale ještě lepší je použít hashe. S vaším provozem je to nejspíš nezbytnost. http://lartc.org/howto/lartc.adv-filter.hashing.html

[secido]

Ak sa používa NAT, tak tc na upload fungovať nebude. Ale mohlo byt, ak by sa použilo IMQ.

[georgo23]

zvlastni ja NAT pouzivam , IMQ ne a vse funguje, zvlastni teorie.

[secido]

ako to mas presne nastavene + aka verzia jadra? ja som sice davnejsie skusal s 2.6.15 a nechodilo, mozno nieco vylepsili

[secido]

Prave som vyskusal a nefunguje . Pouzivas HTB na forwardovany traffic?

[Opičák]

Tak to není dost dobře možné. Můžeš mi přesně popsat jak tvůj TC filter ví po provedení NATu (po přepsání zdrojové adresy adresou routeru), že adresa patří tomu a tomu klientovi a ne tvému routeru? A nebo snad nedělíš to co odchází od uživatelů?

[georgo23]

zhruba takto

[Opičák]

No tak asi jsi neporozuměl o čem je tu řeč. Píšeme tu o tom že nelze použít tc filtry provádíš-li NAT. No a ty tc filtry (např. u32) nepoužíváš. Pakety značíš pomocí iptables. Takže jsi žádnou převratnou novinku nevymyslel. Při značení pomocí iptables to totiž funguje úplně v pohodě i při NATu.

[georgo23]

tak to se omlouvam ...

[xxl]

No to by mě tedy zajímalo proč.

[Opičák]

Tak se podívej kdy se provádí filtrování pomocí tc a kdy se provádí NAT.

[Max]

Přesně, proto mj. také existuje IMQ, který můžeš nastavit před nat, nebo až za něj a použít tak tc filtry místo markování :). Ještě musím juknout, co všechno umí IFB :), ale času je čím dál míň :(
Zdar Max

[xxl]

imq do každé rodiny ...

[Opičák]

nezbývá mi než souhlasit. IFB jsem zatím nestudoval a zatím ani nepotřeboval. Když zjistíš jak to funguje tak se prosím ozvi, docela by mě to zajímalo. Díky.

[Max]

Jasně, jinak myslím, že Thunder.m tvrdil, že v tý svý distribuci hodil místo IMQ nové IFB. Tak ten by snad mohl vědět, co to všechno umí a zda se dá taky tak pěně (nečistě :) ) vyhnout problémům okolo natování :)
Zdar Max

[Thunder.m]

Má to dost much, každopádně použít se to dá. Můžeš třídit pouze pomocí tc (nelze markovat pomocí iptables), to je podstatná nevýhoda, další podstatná nevýhoda je že u některých ovladačů způsobuje ifb při zapnutí kernel panic, to se projevuje například u madwifi ovladačů (atheros karty), okamžitě po přesměrování provozu dojde ke kernel panicu.

[Opičák]

Tak v tom případě je to pro mě zatím nepoužitelné. Každopádně děkuji za informace.

[Max]

Jako čekal jsem něco horšího, ale tohle? Wow, to tam aspoň mohli v tom jádře do závorky napsat EXPERIMENTAL, ne? Když se to takto chová :-/. Jak je to vůbec s natem? Proč jsi teda zařadil IFB do svýho distra, když je oproti imq docela zpět? Díky
Zdar Max

[Thunder.m]

Protože ikdyž můj patch pro imq jde zkompilovat a chová se že funguje, ve skutečnosti funguje jen částečně, takže imq je v jádře 2.6.18.X zatím nepoužitelné a tak je tohle lepší než nic :)

[Max]

Cena za to, že chceš mít nejaktuálnější kernel. Já si stále updatuju 2.6.16.xx a jsem spokojen :).
Zdar Max

[Thunder.m]

Jo, jenže v tom jádře není podpora nových desek pro Core 2 Duo s chipsetem P965 a jejich IDE řadiče, což je pro mě nepoužitelné.

[Max]

Vyvíjí se ještě vůbec IMQ? Nebo se občas najde jen dobrodinec, co zfunkční patch na novějším jádře a tím to hasne?
Zdar Max

[xxl]

A ještě to má jednu mouchu. Je to pěkná masařka. Ani nejnovější tc neumí do ifb poslat ingress.

[Jiří Lisický]

Takže přes tc je to rychlejší než přes iptables? Dá se o tom něco někde přečíst?

[Thunder.m]

Můžeš zkusit místo htb, hfsc, ale myslím že ti výkon žere spíš to markování.

[kapitan]

A jde vubec kombinovat markovani pomoci iptables a pomoci tc? Abych oznacil i ostatni provoz. BTW vse co nemuzu markovat pomoci tc a IP?

[Thunder.m]

jo v tom není problém, jde to kombinovat.

[dan]

Musite shapovat kazdou IP zvlast? Jestli jde jen o omezeni p2p + aspon trochu spravedlive rozdeleni zbytku trafficu, mel bych na to skript, ktery mi spolehlive funguje.

Zustal jsem pouze u tohoto jednoducheho shaperu, protoze markovani je skutecne moc narocne a pri 700 pocitacich v siti mi malem zkolaboval sempron.

Cele se to konfiguruje pres plneni souboru ip adresami (tim se oznaci komu se ma uriznout/omezit p2p, co radek to ip adresa), pripadne i jinymi daty. Zatim to nemam prilis zdokumentovane a uplne dodelane, ale treba to pomuze: http://dan.steadynet.org/dm-shaper.htm

Na pripadne otazky rad odpovim.

[Thunder.m]

Tak nějak takhle by to mohlo vypadat při použití IFB:

#! /bin/bash

# definujeme cesty v systemu
PATH="/usr/sbin:/usr/bin:/sbin:/bin"

DEV="eth0" # Zarizeni na kterem nenatujeme!
RATE="102400" # Maximalni rychlost linky v kbitech, nyni 100Mbit

IP_ADRESY_TRIDA_A="192.168.190.0/24"
IP_ADRESY_TRIDA_B="172.16.1.254"

# Smazeme vsechny root qdisc
I="1"
while true; do
    if [ "`tc qdisc | grep -v 0: | cut -d \" \" -f3 | sed -n ${I}p`" ]; then
        tc qdisc del dev "`tc qdisc | grep -v 0: | cut -d \" \" -f5 | sed -n ${I}p`" root &>/dev/null
        tc qdisc del dev "`tc qdisc | grep -v 0: | cut -d \" \" -f5 | sed -n ${I}p`" ingress &>/dev/null
    else
        break
    fi
    i="`expr 1 + $I`"
done
#
# Deaktivuji vsechna ifb zarizeni
I="1"
while true; do
    if [ "`ip link show | grep ifb | cut -d \" \" -f 2 | cut -d: -f1 | sed -n ${I}p`" != "" ]; then
        ip link set "`$IP link show | grep ifb | cut -d \" \" -f 2 | cut -d: -f1 | sed -n ${I}p`" down
    else
        break
    fi
    I="`expr $I + 1`"
done
# Odstraneni modulu pro ifb
rmmod -f ifb &>/dev/null

# Zavedeni modulu pro ifb
modprobe ifb numifbs=1 &>/dev/null

# Zacatek ifb0
tc qdisc add dev $DEV ingress
tc filter add dev $DEV parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:0 action mirred egress redirect dev ifb0

# Chceme nasadit stejny QoS jak na odchozi tak na prichozi provoz na danem rozhrani
for DEV in $DEV ifb0; do
    # Vytvorime root qdisc
    tc qdisc add dev $DEV root handle 1:0 prio bands 3 priomap 2 2 2 2 2 2 0 0 2 2 2 2 2 2 2 2

    # Ve trech zakladnich prio tridach vytvorime esfq pro nelimitovany traffic a htb pro limitovany
    tc qdisc add dev $DEV parent 1:1 handle 11:0 sfq perturb 10
    tc qdisc add dev $DEV parent 1:2 handle 12:0 sfq perturb 10
    tc qdisc add dev $DEV parent 1:3 handle 13:0 hfsc default 111

    # Zakladni hfsc tride dame plnou rychlost, dalsi budou mit rychlost sdilenou HTTP,mail, DC++,
    tc class add dev $DEV parent 13:0 classid 13:1 hfsc ls m2 ${RATE}kbit ul m2 ${RATE}kbit # nastavime maximum omezovani na 100Mbit
    tc class add dev $DEV parent 13:1 classid 13:111 hfsc ls m2 $[5*${RATE}/10]kbit ul m2 ${RATE}kbit # 50Mbit, strop 100Mbit
    tc class add dev $DEV parent 13:1 classid 13:112 hfsc ls m2 $[${RATE}/100]kbit ul m2 $[2*${RATE}/100]kbit # 1024kbit, strop 2048kbit
    tc class add dev $DEV parent 13:1 classid 13:113 hfsc ls m2 $[${RATE}/100]kbit ul m2 $[1*${RATE}/100]kbit # 1024kbit, strop 1024kbit

    # V kazde tride jeste pouziji sfq
    tc qdisc add dev $DEV parent 13:111 handle 111:0 sfq perturb 10
    tc qdisc add dev $DEV parent 13:112 handle 112:0 sfq perturb 10
    tc qdisc add dev $DEV parent 13:113 handle 113:0 sfq perturb 10

    # Pro tideni paketu pouziji tc
    for IP in $IP_ADRESY_TRIDA_A; do
        tc filter add dev $DEV parent 13:0 protocol ip u32 match ip src $IP flowid 13:112
        tc filter add dev $DEV parent 13:0 protocol ip u32 match ip dst $IP flowid 13:112
    done
    for IP in $IP_ADRESY_TRIDA_B; do
        tc filter add dev $DEV parent 13:0 protocol ip u32 match ip src $IP flowid 13:113
        tc filter add dev $DEV parent 13:0 protocol ip u32 match ip dst $IP flowid 13:113
    done
done

[Thunder.m]

Jinak já používám raděj hfsc (což je také v předchozím skriptu), je trochu přesnější než HTB a při větších rychlostech se mi zdálo lepší (nad 20Mbitů).

[*]

a nepsalo htb nahodou do kernel logu info o tom, ze mas zmenit nektere hodnoty podle kterych se pocita interval a propustnost a ze jinak nemusi fungovat korektne? pri prilist malych a pri prilis velkych ryychlostech se u htb musi stelovat takova ta delicka casu ovilivnuje to jednak presnost, interaktivitu shapovaciho pravidla i zatez systemu podle toho jak casto se to prepocitava.

[Thunder.m]

jj. to jsem šteloval, mam na to skript, který to počítá, ale potom co jsem zkusil hfsc, tak myslím že htb není třeba.

[kapitan]

Muzu toto chapat tak ze neni potreba nastavovat trida pro kazdou IP? kdyz mam skupiny treba 100 uzivatelu s temahle rychlostma 100 uzivatelu s jinyma tak se to da vytvorit dvema tridama misto 200?

[Thunder.m]

Bohužel ne, toto přiřadí celé skupině dohromady rychlost definovanou v dané třídě, takže pokud budeš mít v třídě A například 10 adres, tak všechny dohromady budou mít celkem 1024 kbit zaručeno a maximálně 2048 kbit. Pro spravedlivé rozdělení volné kapacity pro všechny IP je tu například ESFQ.

[Opičák]

Ještě jeden dotázek. Použiju-li ESFQ a určím mu, že bude rozdělovat na základě cílových adres (tedy adres klientů), tak i přesto musím použít filter abych házel správné pakety do správných tříd? Podle mého ano, ale chci si to ověřit.

[LFCIB]

To chápu tak, že chceš celou rychlost linky dělit spravedlivě pomocí ESFQ mezi všechny co jí používají, takže v tom případě podle mě stačí jedna třída a default ukazující na ní, pak podle mě vše půjde do této třídy a myslím, že se nemusí něčím ošetřovat kam mají pakety padat. Ruku do ohně za to ale nedám. Taky nevím co by to dělalo při větších rychlostech.

LFCIB

[moole]

Sorry za popnuti stareho tematu... ale pokud je tvuj problem stale aktualni, mam velmi vyrazne vylepseni na stavajici konfiguraci. Resil jsem to taky, velmi vyraznou cast cpu (tak 60-70% aktualni zateze) zere skutecne prochazeni paketu pravidly iptables pro markovani. Pokud ma kazdy z treba 15k paketu za sekundu projit tvych prinejmensim 2000 pravidel, je to velmi narocne.

Seradil jsem proto pravidla pro markovani paketu do chainu usporadanych do stromove struktury podle oktetu porovnavane ip adresy. vznikne ti tak strom treba 200 chainu (podle rozsahu adresniho prostoru site), kdy v kazdem rozvetvovacim chanu budou jen pravidla pro porovnani ip adresy a skoku na dalsi chain (rozvetveni nebo list) a v kazdem listu uz jen presne matchnuti ip adresy, omarkovani a vykopnuti paketu.

Priklad, sestaveny skriptikem z databaze klientu:

/sbin/iptables -t mangle -N D_192
/sbin/iptables -t mangle -A FORWARD -d 192.0.0.0/8 -j D_192
/sbin/iptables -t mangle -N S_192
/sbin/iptables -t mangle -A FORWARD -s 192.0.0.0/8 -j S_192
/sbin/iptables -t mangle -N D_192_168
/sbin/iptables -t mangle -A D_192 -d 192.168.0.0/16 -j D_192_168
/sbin/iptables -t mangle -N S_192_168
/sbin/iptables -t mangle -A S_192 -s 192.168.0.0/16 -j S_192_168
/sbin/iptables -t mangle -N D_192_168_1
/sbin/iptables -t mangle -A D_192_168 -d 192.168.1.0/24 -j D_192_168_1
/sbin/iptables -t mangle -N S_192_168_1
/sbin/iptables -t mangle -A S_192_168 -s 192.168.1.0/24 -j S_192_168_1
/sbin/iptables -t mangle -A D_192_168_1 -d 192.168.1.130 -j MARK --set-mark 101
/sbin/iptables -t mangle -A S_192_168_1 -s 192.168.1.130 -j MARK --set-mark 3101
/sbin/iptables -t mangle -A D_192_168_1 -d 192.168.1.131 -j MARK --set-mark 102
/sbin/iptables -t mangle -A S_192_168_1 -s 192.168.1.131 -j MARK --set-mark 3102
...

pakety tak misto 2000 po sobe jdoucoch pravidel (z nich jen JEDNO je to spravne(!!)) prochazi hierarchicky treba jen 50 pravidel a zatez CPU jde rapidne dolu! Podstatatne je, ze s pribyvajicimi pravidly nevzrusta zatez cpu linearne, ale, ehm, pomaleji. Na PD 3.4GHz shapujeme cca 120 Mbps / >24kpps pro cca 4000 ip adres a zatez CPU je kolem 75% ve spicce, 35% v prumeru. Masina je intel-only, jadro rady 2.6.20, 2×gbit lan, no imq, no ifb a je 100% stable. Sic toto reseni neni uplne idelani, tak momentalnim potrebam a zamerum vic nez vyhovuje.

[b42]

Tady mozna bych videl prostor pro male vylepseni. Iptables pravidla mas sice usporadana do stromu, nicmene predpokladam ze klasifikace pomoci marku (tc filter) je delana opet prochazenim seznamu vsech marku. Pokud vim tak u32 sice podporuje matchovani podle marku, ale jiz podle nej neni mozno hashovat.

Takze v tvem pripade by se dalo misto iptables targetu MARK pouzit iptables target CLASSIFY, ktery primo urci tridu do ktere ma traffic z dane ip jit a zcela se tak vyhnout linearnimu prochazeni seznamu vsech marku.

Nebo, pouzit target IPMARK, ktery paket omarkuje zdrojovou nebo cilovou ip adresou a pomoci tc filter jej klasifikovat podle marku do konkretni tridy. Bohuzel tento target neni v jadre, takze je nutne jej opatchovat.