Ovidiu wrote:
Salut prieteni,
Administrez un server cu 512MB ram si procesor Duron la 900Mhz cu SO
Linux Slackware 10.1. Acum "duce" in spate cam 100 de clienti intr-o
retea de cartier in dezvoltare; are un firewall destul de stufos (separa
si intranetul de internet), shaping cu htb pt. fiecare (marcare de
Ai uitat sa mentionezi pe ce "banda" de InterNet lucrezi. Dar cum sunt
in general retelele astea, cat de curand duron-u ala o sa se dovedeasca
insuficient daca nu s-a dovedit deja...
pachete in tabela mangle), server DNS, server FTP, grafice MRTG pentru
fiecare client. Acum e totul ok, dar ma intreb care e limita maxima (si
rezonabila) de clienti peste care procesorul ar fi depasit. (chiar si
daca ma gandesc numai la iptables ce contine deja aprox. 500 de reguli
in total). Cum pot verifica incarcarea procesorului la un moment dat ?
500 de reguli cu tot cu marcarea de pachete? Sa inteleg ca nu-ti faci
singur marcarile de pachete? Le primesti deja marcate? Intreb pentru ca
in general sub 800 de reguli doar pt marcarea de pachete nu prea
scapi... Depinde, bineinteles si de peer-ingurile pe care le are
providerul(ii) tau(tai).
Incarcarea procesorului (incarcare reala) nu prea poti s-o observi in
Linux, dar iti poti face o idee dupa idle, cat sta pe intreruperi
hardware/software samd.
Pun o intrebare mai departe, un pic legata de thread-ul acesta. Pentru
500 de reguli de htb, fiecare cu banda lui, discutand numai de
metropolitan (externul se "shape"-uieste in alta parte), ce s-ar folosi
mai degraba, -j CLASSIFY sau tc filter? Mai departe intreb, in cazul lui
-j CLASSIFY, este de preferat sa creezi o structura de chain-uri
complexa, de genul, chain principal POSTROUTING, trimitere spre clasa
/24, trimitere spre clasa /27, -j CLASSIFY dupa ip, sau e de preferat un
singur chain? Intrebarea e pusa pentru ca, dupa cum stim toti iptables
are tendinta de a fi secvential, dar care e pierderea de performanta la
saltul dintr-un chain in altul?
Aruncati cu pietre daca vreti, eu zic ca intrebarile astea si le pun o
gramada de admini de retele mai mici sau mai mari...
Salut lista
_______________________________________________
RLUG mailing list
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug
