Dotaz: Rozdělování rychlosti, shaper, Prometheus QOS dosáhl svých limitů

[Zdvori]

Dobrý den, již dlouhá léta používám pro rozdělování rychlosti mezi více uživatelů https://github.com/Arachne-Labs/Prometheus-QoS . Software je nainstalován na Gentoo a až doteď jsem s ním neměl problém, fungoval jak jsem potřeboval, dělil rychlost mezi cca 100 uživatelů, dokázal přerozdělovat přebytky, latence byla v pořádku atd. Problém nastal teď, při překročení rychlosti cca 350mbps přestává stačit a výrazně narůstají latence paketů (z 1 na stovky ms), IRQ se u jednoho jádra dostává na 99%. Je mi jasné, že mít přes když "# iptables-save | wc -l" mi vrátí 1208 a při zaplém shaperu 3770 tak to již není optimální. Jsem shopen to asi vyřešit upgradem železa za něco pořádného (z obstarožních důvodů běží stále na 8*@3,7Ghz, 32GB RAM a navíc je shaper virtualizován (kvůli možnosti migrace na jiný stroj v případě HW problémů).

Měl bych více dotazů:

• Nemá někdo zkušenosti s "nějakým nástupcem" prometheuse? Zkoušel jsem dohledávat a nic rozumného jsem nenašel, možnost přerozdělovat volnou rychlost pokud je k dispozici je pro mě klíčová.
• Jde nějak upravit aby jádro využívalo více procesorových jader pro síťování?
• Zkoušel někdo upravit prometheus na podporu IPv6?
• Myslíte že by přesun shaperu přímo na fyzický stroj z virtálu pomohl (ovladače virtio)?

Napsat si vlastní pravidla by pro mě nyní značně obtížné (přiznám se, že jsem HTB, ač jsem se snažil, úplně nepochopil).

Vím, že to aktuálně jsem shopen vyřešit navýšením hardware, a mám na pár let, než budu znatelně navyšovat rychlost vystaráno, ale nepříjde mi to jako systémové řešení. Byla by tu možnost využívat i omezování prvků na zákaznický klientských routerech, ale tam mi přijde škoda neumožnit uživatelům využívat přebytky v síti.

Děkuji Zdeněk

---

---

Odpovědi

[Petr Šobáň]

Nedal by to nějaký mikrotik?

[Zdvori]

Naposled jsem zkoušel RB4011iGS+, který mam před shaperem, a ten routovat zvládal, omezovat linky již ne.

[vencour]

A napíšete víc?
Dělil jste pásmo poměrem nebo každému natvrdo jen třeba 1Mbps v obou směrech?

[Petr Šobáň]

Jak to vždyť to umí.....

A pokud rozděluješ všem stejně tak ani nemusíš vytvářet hromadu pravidel a značkovat pakety.

Pokud použiješ simple frontu a shaper pcq tak omezíš hromadu pravidel a celý jeden rozsah IP pokud bude mít stejné omezení uděláš jedním příkazem....

Manual:Queue

NetworkPro on Quality of Service

Neměl jsi ve firewallu zapnut fasttrack?

Pak to QoS nefunguje, nebo lépe řečeno dá se použít fasttrack dle diskuzí, ale musí se umístit na takovou pozici aby to neovlivňovalo QoS, ale pokud to CPU stíhá bez fasttrack tak bych to vyhodil.

PS. Doma jsem fasttrack vyházel ale tam mám jenom pár PC které cpu vytíží když je to vypnuté a zapnuté QoS pouze na 3% když moc.....

[Petr Šobáň]

Příklad:

# nov/28/2020 10:28:32 by RouterOS 6.47.8
# software id = N4XT-6Y5V
#
# model = RBD52G-5HacD2HnD
# serial number = CB380B1ED510
/queue simple
add max-limit=100M/100M name=QoS_Global target=bridge1
add limit-at=10M/10M max-limit=20M/20M name=QoS_1_Telefony packet-marks=QoS_Telefony parent=QoS_Global priority=1/1 queue=pcq-upload-default/pcq-download-default target=bridge1 total-priority=1
add limit-at=10M/10M max-limit=100M/100M name=QoS_4 packet-marks=QoS_4 parent=QoS_Global priority=4/4 queue=pcq-upload-default/pcq-download-default target=bridge1 total-priority=4
add limit-at=10M/10M max-limit=100M/100M name=QoS_6 packet-marks=QoS_6 parent=QoS_Global priority=6/6 queue=pcq-upload-default/pcq-download-default target=bridge1
add limit-at=1M/1M max-limit=90M/100M name=QoS_8_Ostatni parent=QoS_Global queue=pcq-upload-default/pcq-download-default target=bridge1

# nov/28/2020 10:33:46 by RouterOS 6.47.8
# software id = N4XT-6Y5V
#
# model = RBD52G-5HacD2HnD
# serial number = CB380B1ED510
/ip firewall mangle
add action=mark-connection chain=forward comment="VoIP odorik" dst-address-list=odorik.cz new-connection-mark=QoS_Telefony out-interface-list=WAN passthrough=yes
add action=mark-connection chain=forward comment="WoWIFI vodafone" dst-address-list=WoWIFI new-connection-mark=QoS_Telefony out-interface-list=WAN passthrough=yes
add action=mark-packet chain=forward connection-mark=QoS_Telefony new-packet-mark=QoS_Telefony passthrough=no
add action=mark-connection chain=postrouting comment=virtual.soban.cz dst-address=37.157.199.90 new-connection-mark=QoS_4 out-interface-list=WAN passthrough=yes
add action=mark-connection chain=prerouting in-interface-list=WAN new-connection-mark=QoS_4 passthrough=yes src-address=37.157.199.90
add action=mark-connection chain=postrouting comment="Spoj do zlatych hor" new-connection-mark=QoS_4 out-interface=<l2tp-Bezrucova> passthrough=yes
add action=mark-connection chain=prerouting in-interface=<l2tp-Bezrucova> new-connection-mark=QoS_4 passthrough=yes
add action=mark-connection chain=postrouting comment="he.net spoj" dst-address=216.66.86.122 new-connection-mark=QoS_4 out-interface-list=WAN passthrough=yes
add action=mark-connection chain=prerouting in-interface-list=WAN new-connection-mark=QoS_4 passthrough=yes src-address=216.66.86.122
add action=mark-connection chain=prerouting dst-port=500,1701,4500 in-interface-list=WAN new-connection-mark=QoS_4 packet-mark=no-mark passthrough=yes protocol=udp
add action=mark-packet chain=postrouting connection-mark=QoS_4 new-packet-mark=QoS_4 passthrough=no
add action=mark-connection chain=postrouting comment="Internet sluzby" dst-port=22,53,80,143,443,465,587,993 new-connection-mark=QoS_6 out-interface-list=WAN packet-mark=no-mark passthrough=yes \
    protocol=tcp
add action=mark-connection chain=postrouting dst-port=53 new-connection-mark=QoS_6 out-interface-list=WAN packet-mark=no-mark passthrough=yes protocol=udp
add action=mark-packet chain=postrouting connection-mark=QoS_6 new-packet-mark=QoS_6 passthrough=no

# nov/28/2020 10:34:38 by RouterOS 6.47.8
# software id = N4XT-6Y5V
#
# model = RBD52G-5HacD2HnD
# serial number = CB380B1ED510
/ipv6 firewall mangle
add action=mark-connection chain=postrouting comment="IPv6 Bezrucova O2" dst-address=2a00:1028:83cc:46e6::/64 new-connection-mark=QoS_4 out-interface-list=WAN passthrough=yes
add action=mark-connection chain=prerouting in-interface-list=WAN new-connection-mark=QoS_4 passthrough=yes src-address=2a00:1028:83cc:46e6::/64
add action=mark-connection chain=postrouting comment=virtual.soban.cz dst-address=2a02:2b88:2:1::/64 new-connection-mark=QoS_4 out-interface-list=WAN passthrough=yes
add action=mark-connection chain=prerouting in-interface-list=WAN new-connection-mark=QoS_4 passthrough=yes src-address=2a02:2b88:2:1::/64
add action=mark-packet chain=postrouting connection-mark=QoS_4 new-packet-mark=QoS_4 passthrough=no
add action=mark-connection chain=postrouting comment="internet sluzby" dst-port=22,53,80,143,443,465,587,993 new-connection-mark=QoS_6 out-interface-list=WAN packet-mark=no-mark passthrough=yes \
    protocol=tcp
add action=mark-connection chain=postrouting dst-port=53 new-connection-mark=QoS_6 out-interface-list=WAN packet-mark=no-mark passthrough=yes protocol=udp
add action=mark-packet chain=postrouting connection-mark=QoS_6 new-packet-mark=QoS_6 passthrough=no

[Max]

To je otázkou. Já s tím osobní zkušenosti nemám, ale kdo dřív spravoval hraniční routery, na kterých dělal NAT i QoS, tak středobodem celého řešení byla vždy síťová karta. Špatná síťová karta = CPU na 100% a problémy s výkonem. Tzn. podpora hw offloadingu.
Za jakých podmínek vše funguje ve virtuálu a věcí okolo nevím. Třeba já jsem teď nedávno řešil s hw ofloadingem ve VM problém, bylo na FreeBSD v bhyve a jediným řešením jej bylo vypnout v hostu (dle ofiko KB), v opačném případě chyby v hostu, pomalá / nefunkční síť ve VM apod. Samozřejmě to souviselo i s tím, že jsem do VM propagoval x VLAN a to v kombinaci s bridgem byl pro FreeBSD problém. Koukám, že pfSense to má v KB také.

Pokud jde o Mikrotik, tak pozor, bez znalostí se můžeš dostat jen na zlomek výkonu. Příklad, vyšší řady podporují hw offloading, ale zapneš si filtrování vlan na bridgi, ten to nepodporuje a jsi zase na mizerných číslech.
Jinak nepotřebuješ ani hw, můžeš si koupit jen RouterOS a ten provozovat na fyzickém železe nebo jako VM. Nicméně je potřeba si pohlídat všechny věci okolo.

Dobré diskuse na toto jsou na ispforum.cz, kde lidi řeší hw, sdílejí zkušenosti i specifikace svých serverů atd. Jinými slovy, tvůj server by měl v klidu dát to, co píšeš, takže problém bude asi někde jinde. Nevím, ten Prometheus-QoS neznám a nevím, zda nemáš nějakou velkou botu v pravidlech. Nebo jak jsem psal, máš problémy na úrovni hw (špatná síťovka, nebo nefunkční hw offloading ve VM atd.)
Zdar Max

[X]

Mas 3770 pravidel v iptables? To je neco hodne spatne..

[Max]

Ten počet mi nepřijde moc velký. Znám komerční řešení, kde sadu pravidel generují peer klient a co se síťové propustnosti a zatížení CPU týče, tak to dávají úplně v klidu na normálním železe.
Jako, je možné, že tam bota bude, ale spíš bych to viděl na nedobrou síťovou kartu, nebo na problém síťové karty vs virtuál.
Zdar Max

[Zdvori]

Určitě buď na fyzické železo nebo alespoň zkusit do virtuálu síťovku dopravit přes PCI passthrough, aby si virtuál mohl používat normální ovladač k síťovce a obsluhovat si to přes více IRQ a nebýt odkázaný na virtualizované interfacy. Pozor na to, že pokud se síťovka nechá obsluhovat virtuálem, nemůže ji používat host a musí mít pro ostatní virtuály a další provoz jinou.

Samozřejmostí je síťovka, která umí balancovat přes více IRQ, prakticky jakékoliv serverové Intel síťovky jsou v tomhle jistota.

Vím o Linuxovém shaperu s Prometheem, který má v iptables 100 000 pravidel se špičkovým trafficem 9Gbit a vytížení procesorů na 30 %.

[X]

Ok.

[Zdvori]

Všem děkuji za odpovědi a podněty. Začnu přehozením na dedikované železo a zbavením se virtuálu a uvidím pak co dál. Ozvu se za pár dní.

Petr Šobáň : Rychlosti dělím symetricky, ale ne všem stejně. Mám tak 8 variant navíc s různou prioritou. Několik klientů má i více IP adres, které využívají pouze "jednu rychlost". Na fasttrack se podívám.

Vantomas : Děkuji za potvrzení, že by to Prometheus měl zvládnout.

[Petr Šobáň]

Jasně tak stačí těch 8 variant nadefinovat, určitě se to dá v tom mikrotiku nastavit rozuměji....

V první řadě bych vypnul ten fasttrack v mikrotiku a skouknul jak je ten mikrotik zatížen a pokud by byla zátěž malá tak bych zkusil QoS nastavit na tom mikrotiku.

Podle mě pro 100 IP by to mikrotik měl dát a ušetříš další HW který můžeš pak využít smysluplněji.

[Zdvori]

Tak jsem to z virtuálu šoupnul na obstarožitní

i7 980, 8GB ram, + 
03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

a 15min loadAvg 0,04...

Takže největší problém bude nejspíš s implementací kvm virtio ethernet driverem.

Takto mi to zatím stačí. I tak se podívám během zimních večerů na možnost to vše řešit přes microtik (zatím bych musel upravit generování z administrace atd).

Zbývá mi jedna otázka s podporou ipv6. Prometheus čte konfiguraci z /etc/prometheus/hosts ve tvaru "192.168.8.65 client-91 #via-prometheus-60000-120000", na čež z toho vygeneruje cca:

shaper ~ # iptables-save | grep 192.168.8.65
-A forw_192_168_8_64_29 -s 192.168.8.65/32 -o eth1 -j CLASSIFY --set-class 0001:2281
-A forw_192_168_8_64_29 -s 192.168.8.65/32 -o eth1 -j ACCEPT
-A post_192_168_8_64_29 -d 192.168.8.65/32 -o eth0 -j CLASSIFY --set-class 0001:2281
-A post_192_168_8_64_29 -d 192.168.8.65/32 -o eth0 -j ACCEPT
-A INPUT -s 192.168.8.65/32 -j ACCEPT
-A FORWARD -d 192.168.8.65/32 -j ACCEPT
-A FORWARD -s 192.168.8.65/32 -j ACCEPT
-A OUTPUT -d 192.168.8.65/32 -j ACCEPT
shaper ~ # tc qdisc show | grep 2281
qdisc sfq 2281: dev eth0 parent 1:2281 limit 127p quantum 1514b depth 127 divisor 1024 perturb 5sec 
qdisc sfq 2281: dev eth1 parent 1:2281 limit 127p quantum 1514b depth 127 divisor 1024 perturb 5sec 

S ipv6 jsem schopen do /etc/prometheus/hosts napsat subnet napr "2001:db8:2::0/64" ale vystup se jiz generuje spatne

-A post_2001:db8:2::0/64 -d 2001:db8:2::0/64/29 -o eth0 -j post_2001:db8:2::0/64
-A post_2001:db8:2::0/64 -d 2001:db8:2::0/64/29 -o eth0 -j post_common
-A forw_2001:db8:2::0/64 -s 2001:db8:2::0 -o eth1 -j forw_2001:db8:2::0/64
-A forw_2001:db8:2::0/64 -s 2001:db8:2::0/64/29 -o eth1 -j forw_common
-A post_2001:db8:2::0/64 -d 2001:db8:2::0/64/32 -o eth0 -j CLASSIFY --set-class 1:2282
-A post_2001:db8:2::0/64 -d 2001:db8:2::0/64/32 -o eth0 -j ACCEPT
-A forw_2001:db8:2::0/64 -s 2001:db8:2::0/64/32 -o eth1 -j CLASSIFY --set-class 1:2282
-A forw_2001:db8:2::0/64 -s 2001:db8:2::0/64/32 -o eth1 -j ACCEPT

qdisc sfq 2282: dev eth0 parent 1:2282 limit 127p quantum 1514b depth 127 divisor 1024 perturb 5sec 
qdisc sfq 2282: dev eth1 parent 1:2282 limit 127p quantum 1514b depth 127 divisor 1024 perturb 5sec 

Asi by nebyl problem to "/64/29" opravit pres sed nez to pujde do iptables, ale neprijde mi to moc systemove reseni.

našel jsem, že to někdo i zkoušel ale jen na /128 https://github.com/Arachne-Labs/Prometheus-QoS/commit/64b2d1255780905c78973df33145c93ee5613c9c

Nezná někdo nějakého nástupce prometheuse, případně jak toto řešit?

Děkuji

[erotel]

Nám na Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz + 10Gbit síťovka běží nat,firewall + řízení rychlosti cca 2500 uživatelů(3Gbit provoz).

řešil jsem stejné problémy jako Vy,prometheus jsem taky používal,ale nakonec jsem řízení rychlosti uživatelů udělal po svém.

root@igw:~# iptables -L |wc -l

88

root@igw:~# iptables -L -t mangle --lin -v

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1    1694M 2982G CLASSIFY   all  --  eth0   any     anywhere             anywhere             CLASSIFY set 1:9999
2    1237M  378G CLASSIFY   all  --  eth2   any     anywhere             anywhere             CLASSIFY set 1:9999
3    1694M 2982G SET        all  --  eth0   any     anywhere             anywhere             map-set qos dst map-prio
4    1237M  378G SET        all  --  eth2   any     anywhere             anywhere             map-set qos src map-prio

[Jendа]

Možná by pomohlo přepsat 3770 pravidel to takového toho BPF stavového automatu co teď frčí.

Jde nějak upravit aby jádro využívalo více procesorových jader pro síťování?

To se neděje? Jsem myslel že celé to odstraňování Big Kernel Locku bylo přesně aby fungovalo tohle.

[Vantomas]

Jde nějak upravit aby jádro využívalo více procesorových jader pro síťování?

To se neděje? Jsem myslel že celé to odstraňování Big Kernel Locku bylo přesně aby fungovalo tohle.

Spíš je otázka jak moc je to funkční u virtio. Nějaké lehká dokumentace k tomu je, ale víc jsem hledat nezkoušel.

[j]

Hele ja ti teda nevim, ale na shapovani netreba zadnej extra soft, a (vetsinou)ani pravidla do firewallu.

Ta vec (ten tool) kterym se to resi se jmenuje tc, a pokud to nechces(jako ze nechces) vymejslet rucne, tak na to existuje script, kterej se jmenuje htbinit. Potrebujes k tomu pak uz jen spravny moduly v kernelu (teda ty, ktery chces vyuzivat).

Ipv6 to umi.

Tvuj zasadni problem totiz IMO bude prave v ty hromade pravidel, a vykonem HW to muzes poresit, jen nez ti zas dojde.

Hypoteticky bys pak jeste mozna byl schopen problem ne vyresit, ale rekneme oddalit preskupenim tech pravidel = v nejjednodussim pripade si zjisti, pres ktery pravidla tece nejvic paketu, a ty naladuj co nejvejs.

Pokud ti jde vylozene o rovnomerny rozdeleni per IP (tzn nechces resit ruzny rychlosti pro ruzny stroje) tak je to (za pomoci zminenyho scriptu) na par radku.

Jinak typicka konfigurace pro uzivatele vypada trebas takhle (smerem dovnitr = download):

RATE=500Kbit
CEIL=50000Kbit
BURST=128k
LEAF=sfq
PRIO=4
PERTURB=10

RULE=1.2.3.4
RULEIPv6=::1:2:3:4

Pokud chces resit i upload, vypada to podobne, jen tady je presne to misto, kde potrebujes pouzit MARK, protoze v okamzik, kdy to shapujes, uz ses za NATem = srcIP uz je ta verejna. Ale je to jeden mark per uzivatel, coz by navic IMO slo posefovat mozna i jedinym pravidlem, pokud budes markovat trebas casti IPcka.

---

Dete s tim guuglem dopice!