Az a nagy kérdés vetődött fel bennem a minap, amiből nem látom a kiutat, hogy hogyan lehet sok usert szabályozni linux-ban tc-vel. Egy linux interfszen ugyanis nem lehet 65536-nál több qdisc-et létrehozni.
Tegyük fel, hogy szeretnénk usereket korlátozni egy hálóban. Sok fizikai interfészről beirányítjuk a forgalmat egy virtuális interfészbe(ifb vagy imq), ahol minden csomag közösen versenghet. Ha user-enként 8 prioritási szintet különböztetünk meg és up,down irányban is veszünk fel osztályokat, akkor userenként 16 qdisc-re van szükség. így a rendszerben max 4096 user vehető fel. Mi van ha 5000 usert kellene ellátni és nem szeretnénk lemondani a userenkénti 8 sorról. Erre a jelenlegi linux környezet tényleg nem ad megoldást? Létezik az hogy ki kelljen hozni a kernelspace-ből a csomagokat és saját szabályozást implementálni?
A kernel/netfilter kódban egy 32 bites szám 0x0000FFFF mask-al felelős ezért, tehát gyakorlatilag 16 bit áll rendelkezésre és nem integer típusú, tehát a 64 bites architektúrára történő átállás sem oldja meg a szűkösség problémáját.
Kérdés:
Ezt a 16 bites számot nem jutott eszébe még senkinek kiterjeszteni? Valódi probléma ez a limit? Van erre megoldás jelenleg?
- 1497 megtekintés
Hozzászólások
Az mukodne ha letrehoznal x db virtualis interfeszt amelyekkel /y-os subnet-ekre szedned szet a halodat es a kerdeses virtualis interfeszekhez tarsitanal qdisc-eket?
- A hozzászóláshoz be kell jelentkezni
Ezzel gondolom azt akarod mondani, a fizikai interfészen legyen annyi qdisc amennyi subnetre "szétszedem" a hálót és ezek a qdisc-ek legyenek átirányítva virtuális interfészekbe.
Ezzel a megoldással az a baj hogy a virtuális interfész csak formálja a forgalmat(korlátozza a sebességet). És ha dugulás van a fizikai interfészen akkor a versengés nem jut el a virtuális interfész osztályaihoz, csak helyben a x db qdisc versenyez. A helyi qdisc pedig taildrop módon mondjuk a virtuális interfész osztályaiból körkörösen jövő utolsó 500 osztály csomagját(függetlenül attól, hogy ez fontos e vagy nem) eldobja. Ez nem túl korrekt. Sőt egyenesen használhatatlan.
Ha userenként szeretnénk súlyozni és priorizálni és sávszélességhatárokat külön-külön állítani akkor ez a subnet-es dolog szerintem nem jó.
Én még mindig úgy érzem egyébként, hogy valamit nem tudok. BSD-ben is hasonló megkötések vannak egyébként?
- A hozzászóláshoz be kell jelentkezni
Ezzel gondolom azt akarod mondani, a fizikai interfészen legyen annyi qdisc amennyi subnetre "szétszedem" a hálót és ezek a qdisc-ek legyenek átirányítva virtuális interfészekbe.
Azt hiszem nem egyre gondoltunk. En arra gondoltam, hogy a userek legyenek felosztva aranyosan, hogy x db kulonbozo gateway-t hasznaljanak, amelyek valojaban egy fizikai interfeszhez tartozo x kulonbozo interface alias-hoz tartoznak. Feltetelezve, hogy egy-egy interface alias-hoz egyenkent 65536 qdisc-et lehet hozzarendelni ez megoldhatna a problemadat. Ha nem, akkor nem sokat segitettem.
BSD-ben foglalmam sincs, hogy milyen megkotesek vannak, de csak mostanaban kezdtem belemerulni a Linux QoS-be, szoval messze vagyok a guru szinttol :)
- A hozzászóláshoz be kell jelentkezni
Valószínűleg elbeszéltünk egymás mellett. Én virtuális interfészen az IFB és IMQ -t értettem, ami jellemzően a bejövő oldalon használatos. Te pedig a kimenő oldali virtuális interfészeket gondoltad: eth0:1 eth0:2 eth0:3
Egyébként nem lehet ezzel a módszerrel sokszorozni a lehetséges qdisc-ek számát.
# tc qdisc add dev eth0 root handle 1: htb
# tc qdisc add dev eth0:0 root handle 1: htb
RTNETLINK answers: File exists
# tc qdisc add dev eth0:1 root handle 1: htb
RTNETLINK answers: File exists
Tehát ez a szubnetekre szedés elbukik ebben az értelemben. :(
- A hozzászóláshoz be kell jelentkezni