Záťažové testy

• Autor : Tomáš Mokoš, Marek Brodec

V topológií bolo zariadenie pripojené k switchu so 100Mbps rýchlosťou, takže aj keď bol generovaný tok o rýchlostí 140 Mbps, tok bol neskôr na prepínači obmedzený.

Test 1 zdroj vs 1 cieľ

Spočiatku sme pri generovaní paketov z cloudu s generovanou zdrojovou adresou smerujúcich na PC v laboratóriu mali problém, pretože bezpečnostné politiky cloudu nedovolili odoslať z cloudu pakety s odlišnou zdrojovou IP adresou ako mala pridelená daná inštancia cloudu. Preto sme generovali len toky z 1 zdrojovej na 1 cieľovú IP adresu.

Objem prichádzajúcich dát a vplyv na výkon sme pozorovali spomínanými nástrojmi pre monitorovanie rozhraní a tiež na nasledujúcich grafoch môžeme vidieť, že vo chvíli zvýšenia toku začalo kolísať využitie procesora nedostalo sa však nad hranicu 20%. V grafe z názvom Mem môžeme vidieť využitie RAM pamäte všetkými procesmi spustenými na servery, teda i inštanciami Molocha i Snortom a mnohými ďalšími bežiacimi službami + cache pamäť.

Na nasledujúcom grafe je možné vidieť využitie RAM pamäte samotným Elasticsearchom, ktorému bolo pri štarte alokovaných 25GB z ktorých využíva 4.2 GB, keďže sme týmto testom zistili, že zbytočne blokuje veľa pamäte po vykonaní testu sme veľkosť alokoanej pamäte znížili na 18 GB.

Test N zdrojov vs 1 cieľ

Predošlé generovanie nebolo ideálne, pretože relácie mali veľa spoločných charakteristík. Vždy sa jednalo o rovnaké IP adresy rovnaký počet paketov rovnaké telo, čo zjednodušovalo prácu indexovania. Aby sme sa čo najviac priblížili reálnej prevádzke snažili sme sa vyriešiť problém s generovaním zdrojovej adresy. Problém sme vyriešili generovaním paketov s generovanou zdrojovou IP adresou z vlastného notebooku v ktorom bol spustený vo VirtualBoxe zdroj útokov OS Kali Linux. Tento laptop bol pripojený do nášho prepínača a generoval prevádzku smerom do laboratórií. Pakety prechádzali rozhraním, ktorého prevádzka je zrkadlená na ďalšie rozhranie smerujúce k nášmu serveru.

Výsledok testu ukázal že výkon procesora stúpol a pohyboval sa od 20 do max 30 % čo môžeme vidieť na grafe CPU.

Graf Heap Mem ukazuje, že je používaných 6.3GB z alokovaných 19GB RAM.

Výsledok ukázal že množstvo alokovanej RAM pamäte môžeme ešte znížiť. Uvoľnili by sme tak pamäť pre ostatné procesy. Na grafe Mem je totiž vidieť, že všetkými bežiacimi procesmi je využívaných 31GB RAM pamäte. Nepotrebné procesy by tak pri teste bolo vhodné zastaviť, to však nebolo možné pretože paralelne s nami pracovali na svojich bakalárskych prácach na našom serveri iný študenti.

Zhodnotenie testov

Pred testom 1 zdroj vs 1 cieľ bol vykonaný reštart služieb, pred ostatnými inštancie reštartované neboli. Zhodnotili sme, že vyšší tok má vplyv najmä na využitie procesora. V grafoch využívanej RAM Elasticsearchom príp. celkového využitia RAM sa pri príchode generovaného toku neudiali žiadne výrazné skoky. V tabuľke môžeme vidieť, že pri normálnej prevádzke ktorá vo chvíli merania údajov predstavovala 4,5 Mbps je využitie RAM v oboch prípadoch vyššie než pred 1. testom, kde bol tok 20násobne väčší než meraný tok bez generovania. Na tieto dva grafy má vplyv najmä čas od spustenia služby, poprípade množstvo zachytených dát. Testy boli vykonávané v poradí ako sú uvedené v tabuľke s odstupom týždňa. Faktom je, že síce je uvedené v grafe celkového využitia 31 GB z 32 GB dostupných avšak z 18 GB alokovaných je využívaná len 1/3. Táto pamäť je len alokovaná nie obsadená, riešením je obmedziť počet alokovaných GB pri spustení Elasticsearchu a uvoľniť tak väčšie množstvo RAM pamäte pre ostatné procesy. Cache je možné vyčistiť nasledujúcim príkazom

free && sync && echo 3 > /proc/sys/vm/drop_caches && free 

vtedy využitie RAM klesne z 31GB na 20 GB.

Zdroje

• Report Projekt 1-2 – Marek Brodec