Shaping na Linuxu

peckma

Ahoj,

řešíme poslední dobou problém na Linuxových shaperech... Dle všeho se nám HW fláká ale když provoz dosáhne cca 4Gb/s (cca 2500 userů na stroj.) tak nám provoz drobne třeba o Gb/s dolu a většině lidem to jde úplně na ho*no.
(stroj má 20 jader na 3Ghz XEON, 8GB RAM, Debian..., 10G sitovka Intel)
Přikládám náš konfig. Je tu někdo kdo tam vidí nějaký bullshit který mi nevidíme?

Díky.

tc qdisc del dev bond0 root
tc qdisc add dev bond0 root handle 1: htb
tc class add dev bond0 parent 1: classid 1:1 htb rate 12000mbit ceil 12000mbit burst 14406kb cburst 14406kb
tc class add dev bond0 parent 1:1 classid 1:0017 htb rate 8000mbit ceil 8000mbit burst 9604kb cburst 9604kb
tc class add dev bond0 parent 1:1 classid 1:4017 htb rate 8000mbit ceil 8000mbit burst 9604kb cburst 9604kb

#USER
tc class add dev bond0 parent 1:0017 classid 1:105 htb quantum 10000 rate 8000kbit ceil 40000kbit burst 9kb cburst 47kb
tc qdisc add dev bond0 parent 1:105 handle 105 sfq perturb 40
tc class add dev bond0 parent 1:4017 classid 1:4105 htb quantum 10000 rate 8000kbit ceil 40000kbit burst 9kb cburst 47kb
tc qdisc add dev bond0 parent 1:4105 handle 4105 sfq perturb 40
#USER
tc class add dev bond0 parent 1:0017 classid 1:106 htb quantum 10000 rate 2000kbit ceil 10000kbit cburst 12kb
tc qdisc add dev bond0 parent 1:106 handle 106 sfq perturb 40
tc class add dev bond0 parent 1:4017 classid 1:4106 htb quantum 10000 rate 1000kbit ceil 5000kbit cburst 6kb
tc qdisc add dev bond0 parent 1:4106 handle 4106 sfq perturb 40
#USER
tc class add dev bond0 parent 1:0017 classid 1:107 htb quantum 10000 rate 6000kbit ceil 60000kbit burst 7kb cburst 70kb
tc qdisc add dev bond0 parent 1:107 handle 107 sfq perturb 40
tc class add dev bond0 parent 1:4017 classid 1:4107 htb quantum 10000 rate 6000kbit ceil 60000kbit burst 7kb cburst 70kb
tc qdisc add dev bond0 parent 1:4107 handle 4107 sfq perturb 40

-A s_10.6.1 -s 10.6.1.64 -j CLASSIFY --set-class 1:4112
-A d_10.6.1 -d 10.6.1.80 -j CLASSIFY --set-class 1:113
-A s_10.6.1 -s 10.6.1.80 -j CLASSIFY --set-class 1:4113
-A d_10.1.16 -d 10.1.16.103 -j CLASSIFY --set-class 1:10e
-A s_10.1.16 -s 10.1.16.103 -j CLASSIFY --set-class 1:410e
-A d_10.1.25 -d 10.1.25.4 -j CLASSIFY --set-class 1:13c

dubrma

Zdravím,
jen co uvidím na první pohled, snad to pomůže.
Píšeš 10 Gbps síťovka, ale class 1:1 zvládne 12Gbps, na jakém HW?
Doporučil bych opustit HTB a přejít na HFSC, obzvlášť u tak vysokého toku.
Quantum 10000 neznám, ale vypadá to podezřele 😃

peckma

Class 1:1 je aktuálně zvedlá na 12Gb protože test. Ještě včera měla 6Gb a vlastně se nic nestalo.

pgb

Těch 2500 classify je pod sebou nebo rozházené do jumpů? Jestli to nekolabuje prostě na počtu pravidel....

peckma

pgb Přesně tak, všechny classify jsou pod sebou. Původně jsme to měli na starším železe. Po upgradu to dělá ale úplně to stejné. Jádra běží max na 40%.

pgb

a nemůžeš to rozházet přes jump+sety třeba na skupiny po 100 ip ?
-s IPSET-ADDRLIST -j JUMP CLASIFY01-CHAIN

poslal jsem ti pm s telefonem, cinkni mi, nemyslím si že mám pro tebe řešení, ale rád se podělím o zkušenosti

pgb

Pracuju teď na nové GW na debianu a musím říct, že nové nftables jsou naprosto super. Většinu provozu lze odbavit na třetí skok a to množství classify s tolika záznamy to vyloženě zabíjí. Udělal jsem teď pár pokusných testů iptables/nftables classtify vs nftables map a lidi to je skvělé. kam se na to hrabou iptables a chainy. Je to ekvivalent ipsetu, jen to podporuje skoro všechno.

ty nejlepší věcičky:

snat na základě mapy a hash tabulky, takže jedno pravidlo obsáhne tisíce snatů
mapa classify ip : classid
nat 1:1 bez conntracku
a mnoho dalšího

pro zajímavost test classify na apu:

když jsem načetl cca 5000 položek do netfilteru tak conntrack propustnost 0 (ta cílová poslední)
když jsem načetl to samé na mapy, tak propustnost neutrpěla žádnou újmu (ta cílová poslední)

pgb

Jo a fasttrack to samozřejmě podporuje taky, bird2 umí vícevlaknove bgp, firewall se dá psát univerzálně ipv4 a IPv6 naráz ......

kamilj

Doporučoval bych nastudovat si níže uvedené materiály, které vám dopomohou k vysoké propustnosti paketů za sekundu přes router kde běží [ BGP, OSPF, SNAT, QOS, Firewall]

Doporučení:

Taktovací frekvence CPU, čím vyšší tím více a rychleji odbaví CPU pakety. Alepoň 3GHz
Kernel 4.13 a výš, u nás zatím kernel 3.10.826
Fyzické dvě síťové karty. Doporučuji Intel X710 4 porty
Pro každé jádro nastavit odbavovací frontu síťové karty a přerušení na IRQ. 20 jadar máte 20 odbavovacích front do CPU. Doporučuje se max 16. Zbytek jader nechat pro odbavovaní jiných procesů serveru. např. zápis na disk, atd.
Zakázat IRQBALANCE daemona a zprovoznit affinity
Každá síťová karta připojena přes PCI-E zvlášť ke každému SOKET-CPU [0,1]
Mít motherboard s funkční Direct Cache Access (DCA)
Zavést hasing pro QoS TC QDISC FILTTR
NFTABLES bude velmi zajímavé a hlavně výkonné, momentálně nenasazeno.

A tady to máte krok za krokem jak to udělat ;-)
40GbE směrovač pro operační systém GNU/Linux
https://www.vutbr.cz/studenti/zav-prace?zp_id=88683

Studijní materiály:

Pro tuning vysokorychlostního routeru netutils-linux
https://habr.com/en/post/331720/
netutils-linux
https://pypi.org/project/netutils-linux/

Optimalizace QoS - hashing na 3 - 4 skoky dohledá pravidlo, nemusí sekvenčně prohledávat celou tabulku!
QoS v Linuxu a filtr U32
https://habr.com/en/post/138463/
Linux tc multi-level massive hashing
http://www.hazard.maks.net/blog/index.php?op=ViewArticle&articleId=181&blogId=1

Jak bojovat se zpožděním ztráty paketů
https://docs.carbonsoft.ru/pages/viewpage.action?pageId=69926921

Multiprocesorový systém
https://docs.carbonsoft.ru/pages/viewpage.action?pageId=69926921

CPU Affinity Howto
https://www.linuxsecrets.com/2983-cpu-affinity-howto
https://networknuts.net/understanding-cpu-affinity-on-linux-server/

Změna počtu front na síťové kartě
https://docs.carbonsoft.ru/pages/viewpage.action?pageId=72155152

Qdisc FQ_CODEL
https://habr.com/en/post/194274/

How to achieve low latency with 10Gbps Ethernet
https://blog.cloudflare.com/how-to-achieve-low-latency/

Jak posílat proudy paketů přes jednotlivá jádra
Linux Network Scaling: Receiving Packets
https://garycplin.blogspot.com/2017/06/linux-network-scaling-receives-packets.html

The u32 filter
http://linux-tc-notes.sourceforge.net/tc/doc/cls_u32.txt#.

Monitoring and Tuning the Linux Networking Stack: Receiving Data
https://blog.packagecloud.io/eng/2016/06/22/monitoring-tuning-linux-networking-stack-receiving-data/

Monitoring and Tuning the Linux Networking Stack: Sending Data
https://blog.packagecloud.io/eng/2017/02/06/monitoring-tuning-linux-networking-stack-sending-data/

Reducing latency with HPE ProLiant Gen10 Servers
https://community.hpe.com/t5/Servers-The-Right-Compute/Reducing-latency-with-HPE-ProLiant-Gen10-Servers/ba-p/6989167

Building a Single-Box 100Gbps Software Router
http://keonjang.github.io/papers/lanman10.pdf

NFTABLES Zatím musím nastudovat
NFTABLES Zatím nerealizovéno, ale bude to mít velmi vysoký výkon při správné konfiguraci
NFTABLES - Petr Krčmář LinuxDays
LinuxDays 2017 - nftables – budoucnost linuxového firewallu - Petr Krčmář
https://www.youtube.com/watch?v=BLh29Gz9Sac

NFTABLES - Classification to tc structure example
https://wiki.nftables.org/wiki-nftables/index.php/Classification_to_tc_structure_example

A můžete studovat... ;-) Pak dokážete nemožné.
Jen aby jste pochopili, jak je to náročné téma.

darklogic

kamilj Tenhle příspěvek by tu měl někde viset jako nějaké stále HOWTO, až někdo bude potřebovat zase radu v tomhle směru.

pgb

Použít hash tabulku v tc u32 je opravdu výrazně výhodnější, ale pokud to fakt znáš, tak jsi mohl upozornit že TC u32 nejde s natem dohromady. Což je dost podstatné. Celé stromečkování mangle s accepty můžeš taky díky nft hash map hodit do koše.

kamilj

pgb
S tím problémem co popisuješ jsem se nesetkal.
Máme optimalizaci HASING TC FILTER -> CLASS -> QDISC na 3 - 4 skoky najde třídu zákazníka.
Na stejném serveru máme i SNAT pro zákazníky. Latence přes server 0.2 - 0.5 ms i ve špičkách možnostech serveru.

Ještě k NFTABLES

Red Hat Developer - Benchmarking nftables
Měření iptables, nftables, ipset a tc.
https://developers.redhat.com/blog/2017/04/11/benchmarking-nftables/

kamilj

pgb

Ještě k tomu nft hash map
Myslím si, že bude výhodnější a rychlejší než TC a hasing

Viz Classification to tc structure example
https://wiki.nftables.org/wiki-nftables/index.php/Classification_to_tc_structure_example

Kde se píše
Introduction
nftables can replace not even iptables, but it can be used to replace very poorly documented tc filter rules and allow user to classify packets into tc class / qdisc infrastructure.

Chtěl bych přejít z TC hashing na NFT hash map. Myslím si, že příslušný řádek nft najde na jeden krok.

pgb

kamilj

ty tabulky s testy jsou hezké, ale tam u toho nft map jde primárně o to, že nepřidáváš hromady marků, ale stejně jako jsi používal iptables+ipset na různé sety položek (porty, adresy, interfacy), tak nově v nft můžeš udělat i hash mapu "srcip : mark" v jedné položce s hromadou elementů. Taková mapa se pak chová stejně výkoně jako jedno pravidlo s ipsetem (teda neber to úplně doslovně, nějaké rozdíly tam určitě budou 🙂 )
tc u32 matcher má jednu nevhodnou vlastnost v kombinaci se src natem - a to tu, že sedí v netfilterovém diagramu až za srcnat. Příklad: WAN-enp1s0 + LAN-enp2s0 + srcnat počítače v LAN do internetu, tak u32 se věší stejně jako tc qdisc/class na odchozí interface a protože je v netfilteru až za src-nat, tak match na src ip zákazníka v LAN fungovat nebude, protože už má ip dle snatu. Tj download zákazníka se omezí, upload ne. Tady do hry vstupuje imq atd...

inet ------ [enp1s0---netfilter+snat----enp2s0]------PC[192.168.15.3]

tc qdisc add dev enp1s0 root handle 1: htb
tc qdisc add dev enp2s0 root handle 1: htb
tc class add dev enp1s0 parent 1: classid 1:1 htb rate 80mbit
tc class add dev enp2s0 parent 1: classid 1:1 htb rate 80mbit
tc class add dev enp1s0 parent 1:1 classid 1:501 htb rate 20mbit
tc class add dev enp2s0 parent 1:1 classid 1:501 htb rate 60mbit
tc filter add dev enp1s0 protocol ip parent 1:0 prio 0 u32 match ip src 192.168.15.3/32 flowid 1:501
tc filter add dev enp2s0 protocol ip parent 1:0 prio 0 u32 match ip dst 192.168.15.3/32 flowid 1:501

pgb

kamilj
vyřeším ti hledání ... nft list rulset - na jedno pravidlo - zjednodušené

table ip mangle {
	map shaper {
		type ipv4_addr : classid
		flags interval
		elements = { 192.168.16.2 : 1:203, 192.168.16.3 : 1:202,
			     192.168.16.4 : 1:204, 192.168.17.2 : 1:102,
			     192.168.17.3 : 1:104 }
	}
	chain POSTROUTING {
		type filter hook postrouting priority -150; policy accept;
		meta priority set ip daddr map @shaper
		meta priority set ip saddr map @shaper
	}
}

výkonější to je naprosto úžasně, nalil jsem do slaboho boxu 20000 manglu s tím, že až poslední vyhovalo a accepty jsem neřešil, takže by to stejěn procházelo všechny a proti tomu jsem postavil nft hash map se stejným obsahem. Výsledek ???? => router při iptables naprosto zkolaboval a propustnost byla kolem 2Mbps. Při jednom záznamu v nft map normálně dál routoval gigabt. (test proběhl na apu4c2

kamilj

pgb
Díky, to je přesně ono co potřebuji. Už se těším až to dám dohromady ty nft.
Nahradí mně to příkaz pro filtr zákazníka.

tc filter add dev $IFUP protocol ip parent 1:0 prio 10 u32 ht ${utab}:${ubuc}: match ip src ${ip}/32 flowid 1:${htbhex}
ht - hash tabulka

Jinak se podívej na monitoring rozhazování paketů do jader s dalšími informacemi.
netutils-linux
https://pypi.org/project/netutils-linux/

Důležité pro ladění proudu paketů do CPU
RSS: Receive Side Scaling
RPS: Receive Packet Steering
RFS: Receive Flow Steering
XPS: Transmit Packet Steering

Když to zapneš přidá 20-30% výkonu pro zpracování paketů přes CPU
Možná ti to pomůže u toho APU4c2
Doporučím ti APU4C má 4GB RAM

pgb

Já mám APU jen v labu na blbnutí. Ostrý provoz už mi běží na supermicru bez problémů. Ale lab je potřeba neustále. Třeba bird2 je super pokrok.

Ten match v iptables a pak v tc je otravný. Ono to šlo dělat i celé v iptables přes mark, tak mě udivuje že jsi si vybral iptables flowid + tc flowid...... Nově díky nft jsem to celé zahodil a mám jednu mapu a jsem nadšený z celého nft.

kamilj

pgb
SUPERMICRO je skvělé, ale já jsem se rozhodl nakonec pro HP DL360 Gen10, kde konečně udělali, že každý socket CPU je napojen slot PCI-E (nesdílí) pak data zbytečně netečou přes bridge QPI.
Lepší podpora NBD 3-3-3 v místě zákazníka a cena byla stejná i o trošku nižší.

kamilj

pgb
Vybral jsem to protože načítání přes TC FILTER FLOWID je mnohonásobně rychlejší než přes IPTABLES FLOWID
TC FILTER FLOWID 1m:05s
IPTABLES FLOWID cca 20min

Zatím mám BIRD 1.6

ludvik

kamilj Když si pravidla připravíš předem a použiješ iptables-restore, máš to hned ...

Další stránka »