Názory k článku Monitorování přenesených dat v síti s 1000 IP adresami
-
ezzzdiy@gmail.com (neregistrovaný)
Az z toho mam skoro dojem ze se jedna o pokus zruinovat konkurenci tim ze jim doporucuje nepouzitelny setup.
Je sice hezke ze se autor pokousi o reseni na vlastni pest, sice to funguje, ale zbytecne slozite a hlavne s narocnosti O(pocet_zakazniku^3). Ta mocnina je aproximace vlivu CPU data cache.
Perlickou uz je pak jen to ze resi blbosti jako mongodb, coz je ovsem naprosto irelevantni bottleneck :)
Takze, jak doopravdy na to:
To kdo muze a nemuze do internetu se dela tak ze ipset a -t nat SNAT/DNAT pravidla. Figl je pak v tom ze se toto zpracuje pouze jednou pro kazde nove vytvorene spojeni, data co pak tecou uz ale nevidime a ani nas nemusi zajimat - drzi si je conntrack. To mame 1, max 2 pravidla (ipset!). Pro 1:1 NAT verejnych ip pouzivame target NETMAP, v nejhorsim muzeme mit nekolik set pravidel pokud vnitrni a verejne ip na sebe "nepasuji".
Do filter a mangle chainu *NIKDY* nic necpat, protoze se prochazi per packet, namisto per-spojeni jak je tomu u -t nat tabulky. Samozrejme takto resime i redirekt pro nezname IP atd.
Provisioning (tj pokud mame tarify) se dela pres http://lartc.org/howto/lartc.adv-filter.hashing.html
Accounting (k cemu vlastne? ze by 3G operator? :) se dela pres http://dev.medozas.de/files/xtables/xtables-addons.8.html
(xtables-addons je bezne pouzivany balik v modernich distribucich, stejne tak ipset kernel modul).
Vysledek? Kazdy paket je (ne uplne presne, kvuli faktorum jako chainy hash tabulek) O(1), narozdil O(pocet_ip_za_natem^neco)
HA-VEL na linuxech routuji i 10GBps (pravda, bez conntracku), holt low-cost, nicmene ukazka toho ze to jde, jen staci trocha toho RTFM.
PS: Na boxu s Quad L5420 @ 2.5GHz v 9 vecer tece 1.5gbps @ 250kpps pro cca 3500 useru za natem. 70% per core je stale idle, ale pocitam ze nekde pri 750kpps to pujde do kolen, coz je bohuzel limit levnych PC sestav.
-
Ondřej CaletkaZlatý podporovatelOpravdu zajímavý příspěvek. Nechceš to rozepsat do pořádného článku/seriálu? Informací z téhle oblasti je málo a podle mě nad tím tápe hodně lidí.
-
Pokud jde o matchování velkého množství adres, není už pohodlnější místo hromady pravidel použít userspace queuing a kontrolovat nová spojení proti nějaké rychlé databázi? Můj bastl (https://github.com/jmakovicka/nfblock) který používám na blacklistování 200k+ roszahů, mi tady na NB s Pentiem na 1.6GHz zvládá matchovat něco přes 2 milióny IP za sekundu, přičemž jede na jednom jádře.
-
+1. Sice už je to 9 let, co jsem z branže pryč, nerad bych se zesměšnil - ale řekl bych, že se to pořád používá. Třeba ipt-netflow zní zajímavě - podle reakcí uživalelů: http://sourceforge.net/projects/ipt-netflow/
-
ui (neregistrovaný)
Domnívám se, že pro větší množství trafiku je vhodnější coby počitadla použít například pmacct (http://www.pmacct.net/).
-
Článek mě "zaujal" především použitím noSQL databáze. Přiznám se, že jsem vždy pracoval pouze s klasickými SQL databázemi. Je k čemu je dobrá noSQL databáze na naprosto klasické tabulce kde jsou všechny řádky stejné?
Nebo je to autorovým viděním: "pakliže mám v ruce kladivo, všechno vypadá jako hřebík" :-)
Kdyby to autor přepsal do PostgreSQL nebo MySQL a pak to porovnal, to byl teprve panečku článeček ;-)
-
Použití Monga mě také zaujalo, už jen z důvodu, že autor potom naď těmi daty dělá agregované dotazy, což se v SQL zvládne jedním dotazem. Pokud to bude mít v Postgresu, tak může použít i Window fce a získat tak snadno zajímavá statistická data per časovou jednotku nebo per IP.
Ještě k tomu Postgresu. Ukládát jen IP a Čas je poměrně velké plýtvání místem (pokud nevadí, netřeba řešit). PostgreSQL má další režijní pole v každém záznamu (pro viditelnost transakcí apod.) Je ale možné použít datový typ pole a tyto časové řady ukládát do pole (dejme tomu po nějakém primárním zpracování a pro účely trvalejšího uložení). To je úspornější. AFAIK mongo na tom bude dost podobně, ukládat jeden JSON dokument per packet je možné, ale je to trochu overkill.
Autor až moc ryhle zavrhnul Redis. Redis je sice primárně key-value DB běžící v paměti, ale umí jednak ukládat svůj stav na disk, ale hlavně se umí replikovat na jiné uzly. Takže pokud někdo chce, může analýzu dat z de facto bezdiskového routeru dělat někde úplně jinde, kde se mohou agregovat data z vícero routerů.
-
Viděl jsem ještě jiné řešení - úprava (nebo nový modul) v ulogd aby dokázal logovat konec spojení. A zápis normálně do MySQL, ovšem min verze 5.1 aby uměla partitioning a nebyla zahlcená mazáním starých záznamů. A pokud to ten router odhazoval do mysql extra síťovou kartou, zátěž byla v podstatě neznatelná.
-
fibre (neregistrovaný)
a ešte existuje taký z jednoduchších (oproti ntop) http://bandwidthd.sourceforge.net/
-
Martin (neregistrovaný)
Moje požadavky jsou trochu jiné, já potřebuji max. do vteřiny vygenerovat statistiky celkového datového přenosu pro zhruba 2000 IP adres za nějakou poslední dobu (tato doba je parametrem programu), rychlost se potom počítá jen jako data/čas.
Používám na to ipac-ng, což je nástroj, který podle pravidal přidává do iptables záznamy pro monitorování (ovšem mám je rozděleny do více chainů - monitoruji více rozhraní, což podstatně snižuje zátěž cpu). ipac-ng každých 5 minut odesílá do PgSQL databáze, která kvůli rychlosti běží v RAM disku. Data se jednou za x hodin kopírují z RAM na HDD.
Nad PgSQL je pak spouštěn program v C vlastní výroby, který generuje statistiky. Data se v noci sumují, protože u starších dat už nepotřebuji takovou podrobnost - úplně aktuální data po 5 minutách, týden staré po 15min, měsíc staré po hodině atp.Za +- 2 roky monitorování zhruba 2000 IP adres má databáze něco okolo 3,5GB, což se pohodlně vejde do RAM disku.
-
Youda (neregistrovaný)
Ale pripada mi, ze v tom nekdo utopil straslive kvantum prace, aby znovu vynalezl kolo....
nebylo by jednodussi koupit entrylevel krabici od Cisca a na te zapnout NetFlow?
A na vyhodnocovani prsknout nejakou opensource netflow VMWARE applianci?Vzdyt to kvantum prace a laborovani by muselo tu Cisco krabici zaplatit 5x ....
-
tmr (neregistrovaný)
...a nebo si koupit/pronajmout jeden skvělý český produkt vytvořený lidmi z MUNI, resp. z AdvaICT :-)
FYI, http://en.wikipedia.org/wiki/FlowMon
BTW, oni taky přemýšleli nad databází, a vybrali si MUMPS (konkrétně Caché+DeepSee) a rozhodně se to nedá považovat za špatnou volbu :)
-
Josef Liška (neregistrovaný)
Nic proti, ale článek jsem raději ani nečetl, můj názor je, že routovat nebo switchovat má jedna krabice a dělat statistiky má jiná krabice, propojit to jde přes netflow nebo i sflow, pokud mi nejde o 100% přesnost, ale jen statistiku, tak to bohatě stačí a vzhledem k tomu, že data se samplují a částečně je agreguje už kolektor, tak jich je relativně málo a dobře to škáluje.
Na druhou stranu diskuse přinesla mnoho zajímavého ovoce, pár nástrojů jsem neznal a určitě se na ně podívám.
-
risototh (neregistrovaný)
Nieco podobne robime na 3300+ IPeckach a traffikoch v maximach okolo 600 Mbps na dvoch masinach. Jedna sluzi iba ako firewall (ktory posktuje aj dane statistiky) s FreeBSD + pf a druha s 20 GB RAM diskom (FreeBSD), kde sa vsetko uklada do RRD (a este tretia, kde je mysql nasho NMS... ale to uz s tymto nesuvisi). Statistiky robime pre traffik z/do dvoch podsieti (internet, univerzita) + nase kvoty, ktore ovladaju firewall. Pravidiel v pf, ktore toto umoznuju je asi 5 s prislusnymi tabulkami IP adries (whitelist)... Rozhodne je to lepsie, ako iptables s 15000 pravidlami...
