2017 m. liepos 31 d.

Virtualizacijos įtaka pfSense tinklo užkardos sistemai: našumo analizė [4 dalis - Noisy Neighbor]


Tiriamasis modelis ir metodika


Apačioje pateikta tipinė virtualaus tinklo mazgo su integruota pfSense tinklo perimetro užkarda loginė schema (žr. 1 pav.). Joje pfSense sistema vykdoma lygiagrečiai su kita virtualia mašina virš vienos fizinės kompiuterio platformos. Šis kompiuterių tinklo perimetro užkardos schema bus praktiškai suderinta ir ištestuota.

1 pav. Virtualizuota tinklo perimetro užkardos sistema

Kaip matyti iš loginės schemos tiriama virtualizuota pfSense užkardos sistema dalinasi vienos fizinės kompiuterio sistemos ištekliais su kita lygiagrečiai veikiančia Linux VM. Taigi, šiuo darbu siekiama ištirti ne tik virtualizacijos sluoksnio įtaką tinklo našumui pfSense sistemos atžvilgiu, bet ir tuo atveju kai pfSense užkarda integruojama į virtualų tinklo mazgą kuriame turi dalintis aparatinės įrangos ištekliais su kitomis virtualiomis mašinomis.
Šioje dalyje bandoma patikrinti kokią įtaką pfSense užkardos našumui turi lygiagrečiai virš vienos fizinės sistemos vykdoma virtuali mašina kuri dirba perkrovos režimu – visapusiškai išnaudoja jai numatytos fizinės platformos dalies resursus. Pažymėtina, jog dėl ribotos testavimo aplinkos darbinės atminties išteklių lygiagrečiai su pfSense vykdoma tik viena papildoma VM. Fizinės platformos išteklių paskirstymas tarp virtualių mašinų pateiktas 1 lentelėje.

1 lentelė. Testuojamų virtualių mašinų techninės specifikacijos
Linux VM
pfSense VM
Hipervizorius
Linux KVM (Proxmox VE 4.4)
Linux KVM (Proxmox VE 4.4)
vCPU branduoliai
2 [host]
4 [host]
RAM
1280 MB (dedikuota, fiksuoto dydžio)
2048 MB (dedikuota, fiksuoto dydžio)
OS
Ubuntu 17.04 Server (64-bit)
pfSense CE 2.3.4 (64-bit)
Tinklo plokštė
1 bendrinama [VirtIO bridge]
1 dedikuota [PCI passthrough]
2 dedikuotos [PCI passthrough]
1 bendrinama [VirtIO bridge]
Standusis diskas
4 GB [VirtIO SCSI, LVM Thin]
4 GB [VirtIO SCSI, LVM Thin]

Kaip matyti iš 1 lentelės pfSense VM priskirta tiek pat išteklių, kaip ir ankstesniais IOMMU virtualizacijos testavimo atvejais. Iš tiesų, tai ta pati VM, tik atkurta į pradinę konfigūracijos būseną. Vadinasi nebereikia per naujo testuoti tos pačios VM, nes jos našumo rezultatai jau yra žinomi.
Gretimai Linux VM priskirta tik dvejų branduolių procesorius su 1280 MB operatyviosios atminties. Daugiau fizinės sistemos išteklių neskirta, nes norima rezervuoti 2 fizinio procesoriaus branduolius ir likusią 768 MB operatyviąją atmintį KVM hipervizoriaus reikmėms, antraip testuose bus matuojama ne gretimos mašinos įtaka pfSense sistemai, o perkrauto hipervizoriaus.
Virtualioms mašinoms numatytos lygios dalys standžiojo disko išteklių dalys, bei jų KVM procesų apdorojimo prioritetai Proxmox VE atžvilgiu vienodi (tipinės Proxmox VE mašinos).
Kadangi pfSense sistema pagal taikomą modelį yra kritinis taškas nuo kurio priklauso prieiga prie interneto tinklo ir vidinės debesų kompiuterijos infrastruktūros bei jų paslaugų administravimas, pfSense VM priskirtos dvi dedikuotos tinklo plokštės – interneto ir vidinio kompiuterių tinklo sąsajoms, per IOMMU virtualizacijos palaikymą; bei viena bendrinama skirtą testų valdymo reikmėms. Dedikuotos sąsajos padeda užtikrinti spartų ir patikimą ryšį.
Vienu atveju gretimai Linux OS vykdančiai VM įdiegta viena VirtIO tinklo plokštė su paravirtualizuotomis tvarkyklėmis, kurios taip pat leidžia tiesioginę prieiga prie fizinės tinklo plokštės, bet ji yra bendrinama tarp kelių mašinų, įskaitant Proxmox virtualios aplinkos sistemą. Ši tinklo plokštė skirta ne tik testų valdymui, bet ir tinklo sąsajos apkrovos imitavimui 100 Mbps dvikrypčiu duomenų srautu.
Antru atveju, į gretimą Linux VM įdiegta viena dedikuota tinklo plokštė per IOMMU virtualizacijos palaikymą, kuri taip pat naudojama testavimui, tinklo sąsajos apkrovos imitavimui 100 Mbps dvikrypčiu duomenų srautu.
Abiem atvejiais kompiuterio aparatinės įrangos (centrinio procesoriaus ir operatyviosios atminties) apkrovos imitavimui pasirinkta paprasta, bet veiksminga stress programinė įranga. stress sisteminio įrankio parametrai suderinti taip, jog sistema būtų reikšmingai ir tolygiai apkrauta – vieno tipo stress sukurti darbiniai procesai neblokuotų kito tipo darbines operacijas. Testų metu naudota stress komanda su parametrais: stress --cpu 1 --io 1 --vm 1 --vm-bytes 1G (sukuria 1 procesoriaus, 1 įvesties/išvesties ir 1 su 1 GB operatyviosios atminties, darbinius procesus perkrovai imituoti)
Dėl testų intensyvumo ir trukmės, standžiojo disko imituojamos apkrovos buvo atsisakyta baiminantis juos pažeisti (kartu testavimo aplinkos vientisumą). Antra vertus, testams suderinta pfSense sistema diską naudoja tik pradinio sistemos paleidimo metu kol įkrauna save į operatyviąją atmintį. Kita vertus, nūdien serverių platformose standusis diskas, ilgą laiką buvęs didžiausias spartos kamštis {bottleneck}, naudojamas tik atsarginėms kopijoms. Sisteminiams diskams kurti juos pakeitė daugelį kartų spartesni lustiniai duomenų kaupikliai (SSD). Be to, diskai Linux OS, kurioje vykdomos KVM virtualios mašinos, gali būti efektyviai ribojami cgroups įrankiais. Dėl šių priežasčių, atsisakyta standaus disko apkrovos testuose, kaip nekritinio kintamojo darbo tikslui pasiekti.
Viename iš testų, kartu su stress sistemos apkrova gretimoje Linux VM imituojamas ir dvikryptis 100 Mbps UDP duomenų srautas su iperf testavimo įrankiu. Pasirinktas imituojamo duomenų srauto kadrų ilgis – 512 baitų, arba 466 baitai UDP paketo krovoje {payload}, nes tai arti vidutinio paketo dydžio interneto tinklo sraute, bei jo apkrova proporcinga stress apkrovai.
Remiantis jau apžvelgtais VirtIO testų rezultatais (žr. 3 straipsnio dalį), šio tipo VM tinklo sąsajos sveikoji dvikryptė pralaida, su 512 baitų ilgio kadrais, apie 300 Mbps. Tačiau, šiuose testuose gretimos Linux VM tinklo sąsajos imituojamas duomenų srautas sumažintas iki 100 Mbps dėl ribotų aparatinės įrangos galimybių. 300 Mbps pralaidos dvikryptis duomenų srautas reikalauja daugiau nei pusė Linux VM procesoriaus laiko. Vadinasi ji negalėtų pakankamai laisvai vykdyti kitų, stress apkrovą imituojančių procesų, ir tolygiai paskirstyti skirtingo tipo apkrovas tarp visų VM resursų. Kita vertus 100 Mbps dvikryptė pralaida dažnai pakankama interneto prieigos greitaveika daugeliui tinklo paslaugų naudojamų smulkiojo ir vidutinio verslo įmonėse.
Vykdant stress ir iperf imituojamas apkrovas vienu metu Linux VM tinklo sąsajos pralaidumas tampa nestabilus. Siekiant visapusiškos sistemos komponentų apkrovos, bet atsižvelgiant į tai, jog tai tinklo mazgo testas, tinklo sąsajos pralaidumui užtikrinti iperf įrankis paleistas su nice sistemine komanda (nice --20 iperf...), perkeliant iperf procesą į bendrosios planuoklės (SCHED_OTHER) sąrašo viršų. Tai užtikrina daugiau procesoriaus laiko iperf proceso apdorojimui.
Su nice prioretizavimu, Linux VM mašinos imituojamo iperf apkrovos srauto nuostoliai nuo stress darbinių procesų įtakos tapo minimalūs: mažiau nei 0,8% pamestų UDP paketų per 7 val. testą.
Iš tiesų, verta atkreipti dėmesį, jog naudojant VirtIO tvarkykles tinklo sąsajai realizuoti, KVM hipervizorius sukuria dar vieną procesą – vhost-[VMpid], skirtą virtualios mašinos VirtIO tinklo plokštės imitavimui ir aptarnavimui. Šis procesas vykdomas šalia kitų KVM VM procesų.
Planuojant vykdyti VM su reikšminga tinklo pralaida per VirtIO tvarkykles, į tai būtina atkreipti dėmesį, nes visos imituojamos tinklo sąsajos atima papildomus aparatinės įrangos išteklius ne iš VM kuriai priskirta VirtIO tinklo plokštė, o iš bendros fizinės sistemos. Todėl reiktų tai įskaičiuot į virtualizacijos hipervizoriaus pridėtines sąnaudas {overhead} ir rezervuoti tam dali išteklių.

Šioje dalyje testuojama gretimos Linux VM įtaka pfSense sistemai, jai veikiant normaliu įsimenamosios tinklo užkardos {stateful firewall} režimu. Šių testų rezultatai bus palyginti su jau turimais analogiškos įsimenamosios užkardos rezultatais apžvelgtais 3 straipsnio dalyje, kai virtualioje mašinoje naudojamos per IOMMU atvaizduotos fizinės tinklo sąsajos.
Skirtingai nei 1 straipsnio dalies apibrėžtoje metodikoje, šiame nebus ieškoma maksimali pralaida, prie kurios duomenų srauto nuostolis nedidesnis už 0,1%, bet pasinaudota jau turima sveikąja pralaida kaip atskaitos tašku, nuo kurio bus pamatuoti UDP duomenų srauto nuostoliai {packet loss}. Tai leis įvertinti kiek gretimos mašinos apkrova turi įtakos pfSense tinklo mazgo našumui.
Kiekvienam paketo ilgiui UDP duomenų srauto testas atliekamas 10 minučių, su jau turimu iperf –b pralaidos parametru iš analogiškų ankstesnių testų (pfSense + IOMMU). Testas atliekamas 3 kartus, iš kurių rezultatų skaičiuojamas vidurkis kaip teisingas rezultatas testuojamam paketo dydžiui.
Tinklo mazgo sukeltam paketų drebėjimui išmatuoti bus pasinaudota tais pačiais 10 min. trukmės testų duomenimis, imant 10 sekundžių drebėjimo išmatavimus 90-100, 190-200, 290-300, 390-400 ir 490-500 sek. intervaluose iš 3 atliktų testų, viso 15 reikšmių kiekvienam paketo dydžiui. Iš šių reikšmių vedamas vidurkis ir užskaitomas kaip teisingas rezultatas atitinkamam paketo dydžiui.
Likusi testavimo metodika iš esmės nesikeitė ir yra paveldima iš pirmos dalies, jei nenurodyta kitaip.
Praktiškai derinamas ir testuojamas pfSense modelis yra tinklo perimetro užkarda, kuri toliau analizuojama, kai:
  • šalia pfSense sistemos virš bendros fizinės kompiuterio sistemos veikia Linux VM, kuri patiria centrinio procesoriaus ir operatyviosios atminties perkrovas (imituojamas stress įrankio);
  • šalia pfSense sistemos virš bendros fizinės kompiuterio sistemos veikia Linux VM, kuri patiria centrinio procesoriaus ir operatyviosios atminties perkrovas (imituojamas stress įrankio) bei apdoroja dvikryptį 100 Mbps duomenų srautą kompiuterių tinkle (imituojamą iperf įrankio) naudojant VirtIO ir IOMMU tinklo sąsajas.

pfSense perimetro užkardos ir gretimos Linux VM sąveikos testavimas


Sisteminio top įrankio parodymais, su pasirinktais stress parametrais, imituojama apkrova per 15 min. laikotarpį gretimoje Linux VM sistemoje būna apie 150 proc. (average load 3.08, 3.03, 3.00), o tai 1,5 kartus daugiau nei procesorius geba susidoroti su užduotimis vienu metu.
Prie stress imituojamos apkrovos pridėjus iperf imituojamą VirtIO tinklo sąsajos apkrovą vienalaikiu dvikrypčiu 100 Mbps duomenų srautu, per 15 min. laikotarpį gretimos Linux VM sistemos apkrova pakyla iki 191 proc. (top įrankio parodymais: average load 3.86, 3.82, 3.81), iš kurių maždaug 0.60 priklauso iperf procesui. Bendrai Linux VM patiria beveik 2 kartus daugiau apkrovos nei procesorius geba susidoroti su vykdomomis užduotimis.
Linux VM ribų, bet jos tiksliais sukurtas vhost-[VMpid] procesas, kuris pasiima dalį išteklių bendros fizinės sistemos sąskaita. Testų metu iperf imituojamas dvikryptis 100 Mbps duomenų srautas, nukreiptas per VirtIO tinklo sąsają, privertė vhost procesą apkrauti vieną realaus procesoriaus branduolį 30 procentų, kuris kaip minėta metodikos skyrelyje, neįskaičiuotas į VM išteklių dalį.
Pastebėta, jog gretimą Linux VM apkrovus stress ir iperf įrankiais ženkliai padaugėjo, ypač fragmentuojamiems paketams, pranešimų apie out-of-order priimtus UDP paketus iperf testų metu.
Prie stress imituojamos apkrovos pridėjus iperf imituojamą IOMMU tinklo sąsajos apkrovą vienalaikiu dvikrypčiu 100 Mbps duomenų srautu, per 15 min. laikotarpį gretimos Linux VM sistemos apkrova mažesnė nei VirtIO atveju (top įrankio parodymais: average load 3.57, 3.66, 3.61), iš kurių maždaug 50% priklauso iperf procesui. Skirtingai nei VirtIO atveju, IOMMU virtualizuotos tinklo plokštės nesukuria papildomų sąnaudu už VM ribų.

Virtualaus tinklo mazgo nuostoliai dėl gretimos VM veiklos


Jungtinėje diagramoje (žr. 2 pav.) raudona ir mėlyna spalva pažymėtos linijos vaizdžiai iliustruoja našumo nuostolius {packet loss}, įtakotus stress ir iperf darbinių procesų. Kadangi abiejų vertikalių ašių masteliai vienodi, nubrėžtos kreivės tartum rodo nupjautą našumo dalį nuo pfSense tinklo mazgo su IOMMU atvaizduotomis {remapped} tinklo plokštėmis dėl gretimos Linux VM veiklos, vienu atveju testuotos su VirtIO tinklo sąsajos tvarkyklėmis (tamsiai raudona ir mėlyna kreivės), antru atveju su dedikuota tinklo plokšte per IOMMU virtualizacijos palaikymą (šviesiai mėlyna ir raudona linijos).

2 pav. pfSense stateful užkardos režimu + Linux VM: pralaidos ir nuostolių santykis

Kiek kitoks patirtų tinklo nuostolių vaizdas susidaro padidinus mastelį, kuris leidžia pažvelgti iš arčiau į apkrovą imituojančios Linux VM ir pfSense užkardos sistemos sąveiką.
Remiantis surinktais testų duomenimis galima teigti, jog įtaka pfSense užkardos tinklo našumui minimali ir praktiškai nereikšmingą, kai gretima Linux VM veikla apima tik jai priskirtų resursų naudojimą – užduotys su procesoriumi ir operatyviąja atmintimi (žr. 3 pav., mėlynos linijos).
Tačiau, gretimai Linux VM papildomai naudojant bendrinamą kompiuterių tinklo sąsają su paravirtualizuotomis VirtIO tvarkyklėmis, sukėlė reikšmingus našumo pokyčius pfSense sistemoje su IOMMU atvaizduotomis {remapped} tinklo sąsajomis (žr. 3 pav., tamsiai raudona kreivė).

3 pav. pfSense stateful užkardos režimu + Linux VM: pralaidos nuostoliai iš arti

Iš teisų, gretimoje Linux VM taip pat naudojant dedikuotą tinklo sąsają per IOMMU virtualizacijos palaikymą Linux VM aktyvi tinklo apkrova minimaliai įtakoja gretimą pfSense užkardos sistemą (žr. 3 pav., šviesiai raudona kreivė).
Antra vertus, ne visada įmanoma fiziškai priskirti VM tik išskirtinai dedikuotas tinklo plokštes per IOMMU virtualizacijos palaikymą. Todėl šiame darbe tiriamas ir bendresnis bei aktualesnis kompiuterio platformos virtualizacijos atvejis – kai tarp VM naudojama bendrinama aparatinė įranga. Visgi tuo virtualizacija ir patraukli, nes leidžia sumažinti aparatinės įrangos prastovas ją deleguojant kelioms virtualioms kompiuterio sistemoms.
Autoriaus nepastebėjo aiškaus skirtumo tarp pavienės pfSense VM su IOMMU ir kartu su gretimai tuščiąja eiga veikiančia Linux VM {idle}. Todėl nuspręsta naudoti vieną kreivę šio poskyrio diagramose dviem, bet praktikoje lygioms reikšmėms vaizduoti.

Paketų delsa


Linux gretimos VM paveikė ir paketų apdorojimo laiką pfSense tinklo mazge, delsa tapo mažiau stabili. Tačiau lyginant su pavienės pfSense užkardos sistema, išsaugojo tendenciją turėti didesnę laisvąją delsą už apkrautąją. (žr. 4 ir 5 pav.)

4 pav. pfSense stateful užkardos režimu + Linux VM: laisvoji paketų delsa

Kaip matyti iš 4 paveikslo, ženkliai padidėjo pfSense sistemos laisvosios delsos laikas su 64-1518 kadrų dydžiais, vidutiniškai apie 45%, ir tik ties 8K baitų ilgio paketais susilygina su pavienės pfSense užkardos laisvąja delsa. Įtakos skirtumas tarp stress ir iperf imituojamos apkrovos nežymus.
Įdomu tai, jog gretimos Linux virtualios mašinos įtaka priartino pfSense IOMMU virtualizacijos laisvąją delsa prie pavienės pfSense sistemos naudojančios VirtIO paravirtualizuotas tvarkykles.

5 pav. pfSense stateful užkardos režimu + Linux VM: apkrautoji paketų delsa

Apkrautosios delsos skirtumas, gretimai Linux VM imituojant apkrovas tik su stress įrankiu (per VirtIO sąsają) vidutiniškai 20% didesnis nei pavienės pfSense užkardos sistemos, su 64-1518 baitų ilgio kadrais. Tuo tarpu Linux VM naudojant tinklo plokštę per IOMMU, rezultatai labai nestabilūs.
Prisidėjus ir tinklo apkrovos imitavimui su iperf įrankiu, pfSense sistemos su IOMMU apkrautosios delsos laikas vidutiniškai padidėja iki 45%, su 64-1518 baitų ilgio kadrais, bei tampa labai nestabilus, vėl primindamas sunkiai nuspėjamą VirtIO paravirtualizuotos tinklo sąsajos kreivę.

Paketų drebėjimas


6 pav. pfSense stateful užkardos režimu + Linux VM: paketų drebėjimas

Kaip ir pralaidos testuose, dviejų VM mašinų sąveika beveik neįtakojo paketų drebėjimo pfSense tinklo mazge, kai Linux VM apkrova orientuota tik į jai priskirtus aparatinius išteklius (procesorių ir operatyviąją atmintį), kreivės praktiškai identiškos visų paketų ilgiais.
Nedidelį paketų drebėjimą pfSense užkardoje sukėlė gretimoje Linux VM prisidėjusi tinklo imituojama apkrova (abiem VirtIO ir IOMMU atvejais), kuri apima svarbiausius ir dažniausiai naudojamus realaus tinklo paslaugų kadrų ilgius. Tačiau jos kreivė ties 1024 baitų ilgio kadrais pasiveja nubrėžtą pavienės pfSense užkardos sistemos su IOMMU virtualizacija.

Išanalizavus gautus testavimo duomenis, galima daryti išvadą, jog vienos VM mažesnis tinklo aktyvumas per bendrinamą VirtIO tinklo sąsają daro mažesnę įtaką kitos VM našumui tinkle ir minimalią įtaką kai gretimos virtualios mašina naudoja dedikuotas tinklo plokštes per IOMMU. Virtualios mašinos kurios aktyviai nesinaudoja tinklo paslaugomis ir jų netiekia – neturi reikšmingos įtakos tarpusavio darbui veikiant virš vienos fizinės kompiuterio sistemos ir naudojant Linux KVM hipervizoriaus realizuojamą kompiuterio platformos virtualizaciją.



"Virtualizacijos įtaka pfSense tinklo užkardos sistemai: našumo analizė" Turinys:

2017 m. liepos 30 d.

Virtualizacijos įtaka pfSense tinklo užkardos sistemai: našumo analizė [3 dalis - Firewall mode]

Prieš pradedant analizuoti pfSense sistemos veikimą įprastu įsimenamosios užkardos {stateful firewall} režimu, naudinga apžvelgti pralaidos pokyčius pfSense sistemoje tarp tik maršrutizatoriaus ir įsimenamosios užkardos režimų (be virtualizacijos sluoksnio).

pfSense sistemos našumas maršrutizatoriaus ir užkardos režimu

Kaip matyti iš diagramos, įjungus duomenų srauto filtravimą mažiausių paketų apdorojimo našumas pfSense sistemoje ženkliai krito: maždaug 38-40 proc. Taip yra todėl, jog užkardos sistema turi sužiūrėti ne tik paketų maršrutų lentelę, bet ir filtravimo. Kiekvienas paketas kertantis tinklo mazgą turi būti sutikrintas su paketų filtravimo lentele, o tai reikalauja papildomo procesoriaus laiko ir gali gerokai sulėtinti pfSense pralaidumą jei filtravimo lentelės sąrašas ilgas.
Iš teisų, įsimenamosios užkarda {stateful firewall} turi dar vieną lentelę – būsenos {state table}, kurią peržiūri pirmiausiai. Iki tam tikros ribos ji paspartina užkardos taisyklių peržiūrą greitąja grandine tiems tinklo paketams, kurie žinomi užkardai t.y. priklauso jau užmegztai ryšio sesijai.
Vis dėlto, reiktų stengtis filtravimo taisyklių užkardoje taikyti kuo mažiau, bei kiekviena iš jų būtų pasverta kitų atžvilgiu, parenkant jų eiliškumo tvarką. Tuo tikslu rekomenduojama taikyti tinklo saugos praktiką su strategija – viską blokuoti {default deny} ir praleisti tik tai kas būtina.
Kaip minėta metodikos skyrelyje, remiantis RFC 2544 rekomendacijomis, pfSense užkarda per grafinę vartotojo sąsają sukonfigūruota su 25 vartotojo apibrėžtomis taisyklėmis, kurias sistema nuosekliai visas patikrina prieš užmezgant naują ryšio sesiją per pfSense tinklo mazgą. Taip siekiama imituoti vartotojo sukonfigūruotą ir praktikoje naudojamą užkardos sistemą.
Iš teisų, kadangi pfSense yra sofistiška tinklo apsaugos sistema, ji jau turi maždaug 80 įkoduotų {hardcoded} filtravimo taisyklių, kurios matomos tik per komandinės eilutės sąsają. Jų redagavimas per komandinę eilutę gali pažeisti pfSense sistemos vientisumą ir sutrikdyti normalų jos darbą. Jos kūrėjų palaikomas ir vienintelis teisingas pfSense sistemos konfigūracijos būdas yra per saityno tinklalapį prieinama grafinę vartotojo sąsają.
Nors į šio darbo testavimus neįtraukti testai skirtumui tarp 0 ir 25 vartojo apibrėžtų taisyklių ištirti, darbo autorius nepastebėjo jokio praktiškai reikšmingo skirtumo tarp šių pfSense sistemos konfigūracijų. Tačiau kaip jau apžvelgta, akivaizdus skirtumas atsiranda pilnai išjungus paketų filtravimą, kai pfSense dirba tik maršrutizatoriaus režimu.

Šiame darbe nenagrinėjama, bet autoriaus pastebėjimais pfSense užkardos sistemoje yra didelis našumo skirtumas kaip paketų filtravimo taisyklės apibrėžtos. Pastebėta, jog naudojant specialią užkardos taisyklę apibrėžiančią vienu vardu keletą IP adresų {alias}, eikvojama daugiau sistemos išteklių, nei dvi įprastos su tais pačiais IP adresais. Vis dėlto tai yra tik autoriaus pastebėjimai, nepatenkantis į virtualizacijos tyrimo sritį ir reikalauja atskiro tiriamojo darbo.

Toliau pateikta susistemintų testavimo duomenų vizualizacija diagramose, kai KVM virtualiųjų mašinų tinklo sąsajos realizuojamos trimis skirtingais būdais. Analizuojamas jų našumas tinklo mazgo pralaidumo, paketų delsos ir drebėjimo atžvilgiu, kai pfSense sistema dirba normaliu įsimenamuoju tinklo užkardos režimu {stateful firewall} + 25 vartotojo apibrėžtos taisyklės.

Stateful Firewall mode


Tinklo mazgo pralaidumas


Kaip jau buvo pastebėta, perjungus pfSense sistemą į normalųjį užkardos režimą jos pralaidumas apdorojamų paketų skaičiumi per sekundę krito beveik 40 proc. lyginant su plika aparatinės įranga paremta pfSense sistema – be virtualizacijos sluoksnio. Saugos mokestis palietė ir virtualizuotų pfSense sistemų našumą.
Procesoriaus ištekliams reikli IOMMU virtualizacija tik maršrutizatoriaus režimu savo našumu su aparatinės įrangos susilygino ties 512 baitų ilgio paketais, perjungus pfSense sistemą į užkardos režimą ši riba pasistūmė perpus toliau – iki 1024 baitų ilgio paketų.
VirtIO pralaida taip pat krito. Jei tik maršrutizatoriaus pfSense sistemoje su paravirtualizuotų tinklo tvarkyklių sąsaja savo pralaida tarp didesnių paketų prilygdavo aparatinei įrangai, šiai aptarnaujant pfSense užkardos sistemą nebepakanka fizinių išteklių spartos.
Tačiau kokia prasmė turėti užkardos sistemą kompiuterių tinkle su išjungtu paketų filtravimu. Šiuos nuostolius reikia priimti kaip natūralų motyvą – saugos kainą. Be to, nereikia pamiršti, jog šiame tiriamajame darbe pfSense sistema testuojama su senu ir ekonomiškos klasės serveriu. Nūdienos x86 architektūros serverių aparatinė įranga apginkluota tinklo funkcijas spartinančiomis posistemis, todėl tikėtina su analogiškomis užduotimis susidorotų geriau.

pfSense stateful užkardos režimu: dvikryptis paketų apdorojimo skaičius per sekundę

Nors iš stulpelinės pralaidos diagramos sunku įžvelgti, bet VirtIO ir E1000 tinklo sąsajos pralaida šiek tiek nukrenta pereinant nuo 1518 baitų ilgio kadrų prie 4K paketų: atitinkamai iš 79 į 73 kkps ir iš 28 į 24 kkps.
Tuo tarpu pfSense užkardos sistema su IOMMU dedikuotomis tinklo plokštėmis ir be virtualizacijos sluoksnio rodo nedidelį kardų pralaidos prieaugį pereinant iš 1518 baitų ilgio kadrų prie 4K paketų: abiem atvejais didėja nuo 81 iki 88 kkps.
Tai rodo, jog pfSense užkardos sistema su programine įranga imituojamomis tinklo plokštėmis turi sunkumų apdorojant fragmentuojamus tinklo paketus. Tą patvirtina ir testavimo metu su pastarosiomis tinklo sąsajomis prie įprastų tiems dydžiams pralaidos parametrų pradeda masiškai pametinėti tinklo paketus, ir informuoti apie fragmentuojamų paketų perpildymą pfSense sistemoje.

pfSense stateful užkardos režimu: dvikryptė tinklo mazgo greitaveika

Jei krenta kadrų pralaida, būtinai kris ir bitų pralaida per sekundę. Iš greitaveikos diagramos sunku įžvelgti skirtumus, bet remiantis testų duomenimis: pfSense užkardos be virtualizacijos sluoksnio sveikoji maksimali naudingoji dvikryptė pralaida su 64 baitų ilgio kadrais siekia 28 Mbps (bendrai 58 Mbps); IOMMU to pačio ilgio kadrus apdoroja 34 Mbps sparta, o VirtIO ir E1000 tinklo sąsajos tik 22 Mbps ir 8 Mbps atitinkamai.
Tokios tinko mazgo pralaidos išties nedžiugina, vis dėlto, vidutinis paketų dydis internete arčiau 256 baitų ilgio, o tai padidina pfSense tinklo užkardos sveikąją pralaidą su E1000 tinklo sąsajos tvarkyklėmis iki 104 Mbps duomenų srauto (52 Mbps abiem kryptimis). VirtIO tą ribą pakelia du kartus, iki 220 Mbps (110 Mbps abiem kryptimis), tai paknakamai solidi pralaida Fast Ethernet tinklui aptarnauti. IOMMU ir nevirtualizuota pfSense užkardos sistema su turima aparatine įranga gali pasiekti atitinkamai 452 ir 670 Mbps suminę greitaveiką per dvikryptį duomenų srautą.

Paketų delsa


pfSense užkardos sistemai filtruojant ją kertančius paketus tenka apdoroti pagal kelias duomenų struktūras: maršrutizavimo, būsenos ir filtravimo lenteles. Teoriškai toks paketų apdorojimas itin neigiamai atsiliepia pfSense tinklo mazgą kertančių paketų delsos laikui.
Laisvosios pfSense tinklo užkardos sukeltos delsos diagrama primena maršrutizatoriaus laisvosios delsos diagramą.
Blankiau, bet vis dar matoma maršrutizatoriaus režimu veikiančios pfSense sistemos anomalija su didesniais paketais: pfSense veikiant užkardos režimu ties 8K baitų ilgio paketu užfiksuota aparatinės įrangos delsa didesnė nei su IOMMU atvaizduotos tinklo sąsajos sprendimu.
Kaip jau minėta, delsą šiuo atveju gali lemti tinklo plokštės dėklą aptarnaujančio proceso konteksto perjungimas (plačiau apie tai rašyta pfSense tik maršrutizatoriaus platformos analizėje).

pfSense stateful užkardos režimu: laisvoji paketų delsa

Įjungus pfSense sistemoje paketų filtravimą, laisvosios delsos rezultatai bendrai nežymiai padidėjo. Tačiau skirtumas tarp tos pačios tinklo plokštės, kai ši priskirta pfSense užkardos sistemai be virtualizacijos sluoksnio ir kai ji priskirta VM per IOMMU virtualizaciją su tos pačios konfigūracijos pfSense sistema, niekur nedingo. Pastarosios laisvoji delsa vidutiniškai net apie 39% didesnė, imant kadrų ilgius nuo 64 iki 1518 baitų.
Įsimenamosios užkardos režimu dirbančios pfSense sistemos apkrautosios delsos diagrama gerokai skiriasi nuo laisvosios delsos, bet turi akivaizdžių panašumų lyginant ją su pfSense maršrutizatoriaus platforma.

pfSense stateful užkardos režimu: apkrautoji paketų delsa

Kaip ir maršrutizatoriaus režimu, pfSense užkardos laisvoji tinklo delsa linkusi sumažėti ją apkrovus sveikąja pralaida virtualiose mašinose kurios turi tiesioginę prieigą prie fizinės tinklo plokštės. Tai vaizdžiai matoma iš jų suartėjusių delsos kreivių delsos diagramose. Didžiausias sumažėjimas vėl fiksuojamas su VirtIO tinklo sąsajos tvarkyklėmis, kiek mažesnis IOMMU atveju, o nevirtualizuotos pfSense tinklo užkardos sistemos atžvilgiu ji šiek tiek padidėjo. Kaip ir maršrutizatoriaus režimu, tikėtina to priežastis VM tinklo plokštės dėklą aptarnaujančio proceso konteksto perjunginėjimas procesoriuje.
Virtualios mašinos su programine įranga paremtomis E1000 ir VirtIO tinklo sąsajomis testų metu demonstravo nestabilius rezultatus, todėl ir jų kreivės labai nenuoseklios. Tuo tarpu nevirtualizuota pfSense sistema ir VM su realiomis tinklo sąsajomis atvaizduojamas {re-mapped} per IOMMU virtualizacijos palaikymą aparatinėje įrangoje, išlaiko paketų apdorojimo stabilumą pfSense sistemai veikiant įsimenamosios užkardos režimu.
Imituojamos tinklo plokštės su E1000 tvarkyklėmis, kaip ir pfSense maršrutizatoriaus platformos atveju, apkrautoji delsa visiškai nenuosekli ir nenuspėjama, vidutiniškai 2297% didesnė nei aparatinės įrangos, nuo 64 iki 1518 baitų ilgio kadrams.
Apkrautosios delsos skirtumas tarp atvaizduojamos tinklo plokštės pfSense virtualioje mašinoje per IOMMU ir tos pačios tinklo plokštės pfSense užkardos sistemoje be virtualizacijos sluoksnio, vidutiniškai didesnis kiek daugiau nei 15%, tarp 64 ir 1518 baitų ilgio kadrų.

Paketų drebėjimas


Kaip matyti iš paketų drebėjimo diagramos, visų skirtingų tinklo sąsajų kreivės sugeneruotos pfSense užkardos sistemos testavimu metu, pasižymi nuoseklumu ir stabilumu.

pfSense stateful užkardos režimu: paketų drebėjimas

Prie paveldėtos maršrutizatoriaus platformos anomalijos prisidėjo dar viena, taip pat programine įranga paremta tinklo sąsajos tvarkyklė.
Iš tiesų, abi anomalijos jau buvo pastebėtos pralaidos diagramoje ir ją sudarančių lentelių analizėje, kurią sukėlė sumažėjusi pfSense užkardos kadrų pralaida apdorojant fragmentuojamus paketus. Panašu, jog ir VirtIO banguojanti kreivė protestuoja prieš fragmentuotus tinklo paketus pfSense užkardos sistemoje, todėl reiktų vengti didesnių nei 1518 baitų ilgio kadrų kompiuterių tinkle su virtualizuota pfSense užkarda, arba naudoti IOMMU virtualizaciją.
Iš paketų drebėjimo diagramos matyti, jog su 64-256 baitų ilgio kadrais VirtIO paketų drebėjimas mažesnis už IOMMU. Tačiau IOMMU pralaida taip pat didesnė. Jei jos pralaidą sumažinti iki VirtIO, sumažėtų ir paketų drebėjimas, kurį šiuo atveju lemia itin aukšta pfSense sistemos centrinio procesoriaus apkrova.
Kaip ir pfSense maršrutizatoriaus platformos atveju, prie mažiausių tinklo kadro dydžių matyti ryškus skirtumas tarp IOMMU atvaizduojamos tinklo plokštės VM ir tos pačios tinklo plokštės nevirtualizuotoje pfSense užkardos sistemoje. Paketų drebėjimo skirtumas, kaip ir maršrutizatoriaus platformos atveju, išnyksta su didesniais nei 512 baitų ilgio paketais.

pfSense sistemos centrinio vidutinė apkrova


Kaip ir tikėtasi, vidutinės pfSense sistemos apkrovos diagramoje ryškus skirtumas tarp jos veikimo tik maršrutizatoriaus režimu ir įsimenamosios užkardos režimu.

pfSense sistemos vidutinė procesoriaus apkrova stateful užkardos režimu

Padidėjusi pfSense užkardos sistemos vidutinė apkrova lėmė didesnį rezultatų nuokrypį bei šio poskyrio diagramų kreivių netolygumą. Skirtingai nei maršrutizatoriaus režimu, įjungtas paketų filtravimas maksimaliai apkrauna ir nevirtualizuotą pfSense užkardos sistemą.
Kaip minėta pfSense maršrutizatoriaus vidutinės apkrovos analizėje, pfSense vidutinė apkrova sustoja ties 50 proc. riba, nes geba pilnai išnaudoti tik 2 iš 4 procesoriaus branduolių. Po vieną branduolį WAN ir LAN tinklo sąsajas kertančiam duomenų srautui apdoroti.
Testavimų metu pastebėta, jog nepriklausomai nuo turimų laisvų branduolių, pfSense sistemos įvesties/išvesties operacijų kamštis – vieno procesoriaus branduolio sparta. Jei dėl gausaus tinklo duomenų srauto vieno procesoriaus branduolio apkrova viršija 100%, nes nebespėja aptarnauti jam paskirtos tinklo plokštės generuojamas tiesiogines pertraukčių užklausas {interrupt requests}, pfSense (FreeBSD) operacinės sistema persijungia į programinį pavėlintą pertraukčių apdorojimą, tam sistemos branduolyje perkrautai tinklo plokštei sukuriama eilė {queue}, kurios aptarnavimas ne toks dažnas kaip tiesioginių procesoriaus pertraukčių. Nors tai ir sumažina tinklo sąsajos pertraukčių skaičių į procesorių, stipriai padidėja paketų apdorojimo delsos laikas ir duomenų srauto nuostoliai.

Stateless Firewall mode


pfSense buvo sukonfigūruota ir darbui neįsimenamuoju užkardos režimu {stateless firewall}, kai užkarda filtruoja kiekvieną ją kertantį paketą nepriklausomai nuo jo kilmės ir paskirties – kaip naują, net jei tik ką iš tos pačios ryšio sesijos tokį pat paketą apdorojo. Todėl kiekvienas tinklo paketas priverstas patikrinti visą užkardos taisyklių sąrašą + 25 vartotojo apibrėžtas taisykles.
Nepaisant šio tinklo užkardos režimo neefektyvumo praktikoje, šis testas atliktas su siekiu patikrinti kiek nežinomų/naujų paketų geba apdoroti pfSense užkardos sistema per vienetinį laiko tarpą. Taip sudarant apytikrį vaizdą, kiek lygiagrečių tarptinklinio ryšio kanalų pfSense užkarda su turima aparatine įranga gali apdoroti per vieną sekundę, bei įvertinti nuostolius lyginant su virtualizuota pfSense sistema. Testo rezultatai teoriškai turėtų atspindėti tuos kurie būtų gaunami praktikoje, priklausomai nuo kokio tipo ryšio sesijos užmezgamos:
  • Geresni jei ryšio sesijos užmezgamos tarp žinomų, vienodų tinklo adresų, kuriuos normaliu įsimenamuoju režimu dirbanti pfSense sistema įsimena ir apdoroja sparčiau.
  • Blogesni, jei ryšio sesijos užmezgamos tarp nežinomų, skirtingų tinklo adresų, kuriuos normaliu užkardos režimu dirbanti pfSense sistema turi apdoroti kiekvieną atskirai prieš nusprendžiant blokuoti, atmesti ar praleisti. Tokia situacija gali susidaryti kai pfSense kertančio duomenų srauto tinklo paketai daugumoje priklauso TCP protokolui ir siuntėjai nežinomi užkardos sistemai (pvz., DDoS atakos atveju).

Grynasis tinklo mazgo pralaidumas


Šiame darbe, pfSense sistemos veikiančios neįsimenamosios užkardos {stateless firewall} režimu ir apdorojančios maksimalų dvikryptį UDP duomenų srautą, kurio nuostoliai paketo dydžiui nedidesni už 0,1% šiame darbe vadinama grynąja tinklo mazgo pralaida.
Lyginant pfSense maršrutizatoriaus ir įsimenamosios užkardos režimų kadrų pralaidos diagramas akivaizdžiai matyti, jog kiekvieno pfSense tinklo mazgą kertančio paketo tikrinimas sukuria didžiules sąnaudas ir smarkiai sumažina pfSense užkardos našumą: grynoji pfSense mazgo pralaida beveik du kartus mažesnė už įsimenamosios užkardos sveikąją, ir net apie tris kartus už pfSense maršrutizatoriaus platformos pralaidą.

pfSense stateless užkardos režimu: dvikryptis paketų apdorojimo skaičius per sekundę

Jei tarsim, jog vidutinio tinklo vidutinio paketo ilgis apie 256 baitai, tai nevirtualizuota pfSense užkarda su turima aparatine įranga, gebanti apdoroti be žymių nuostolių 214 tūkst. nežinomų/naujų paketų per sekundę – galėtų teoriškai aptarnauti maždaug 214 tūkstančių lygiagrečių tarptinklinių ryšio kanalų per vieną sekundę; tuo tarpu virtualizuota pfSense užkarda geriausiu atveju (su IOMMU palaikymu) apdorotų apie 168 tūkstančius ryšio sesijų per vieną sekundę; o VirtIO ir E1000 atitinkamai po 80 ir 48 tūkstančių.

pfSense stateless užkardos režimu: dvikryptė tinklo mazgo greitaveika

Kaip įprasta, visapusiškai analizei verta į pralaidą pažvelgti ir bitais per sekundę. Jei vėl tarsim, jog vidutinio tinklo duomenų srauto vidutinis paketo ilgis yra apie 256 baitai, tai nevirtualizuota pfSense užkarda su turima aparatine įranga be virtualizacijos sluoksnio sugebės išfiltruoti 180 Mbps dvikryptį duomenų srautą (bendrai 360 Mbps). Virtualizacija geriausiu atveju be reikšmingų nuostolių sugebėtų apdoroti 141 Mbps dvikryptį duomenų srautą (bendrai 282 Mbps). VirtIO ir E1000 sąsajos atitinkamai po 134 Mbps ir 80 Mbps, nežinomos kilmės ir paskirties paketų srauto.



"Virtualizacijos įtaka pfSense tinklo užkardos sistemai: našumo analizė" Turinys:

2017 m. liepos 23 d.

Virtualizacijos įtaka pfSense tinklo užkardos sistemai: našumo analizė [2 dalis - Router mode]

Kartą jau apkalbėta pfSense kompiuterių tinklo užkardos sistema (žr. straipsnį "pfSense kompiuterių tinklo mazge"), turi labai stiprius maršrutizatoriaus bruožus, todėl neretai tinklo administratoriai ją pritaiko kaip pavienį perimetro (WAN) ar vidinio (LAN) tinklo maršrutizatorių. Vidutinio ir didesnio dydžio kompiuterių tinkluose, kurių jungtys sodriai prisotintos paketų srautu, tai atskiras tinklo mazgo vaidmuo pfSense sistemai.
Šioje straipsnio dalyje pateikta susistemintų testavimo duomenų vizualizacija diagramose, kai KVM hipervizoriaus sukurtų virtualiųjų mašinų tinklo sąsajos realizuojamos skirtingais būdais. Analizuojamas jų našumas tinklo mazgo pralaidumo, paketų delsos ir drebėjimo atžvilgiu, kai pfSense sistema veikia tik maršrutizatoriaus režimu {routing platform only} (paketų filtravimas išjungtas).

Tinklo mazgo pralaidumas


Dauguma Ethernet tinklinės įrangos gamintojų pristato savo produktų pralaidą {throughput} bitais per sekundę (pvz., 100 Mbps ar 1 Gbps), tačiau marketingo verčiami pamiršta nurodyti svarbią informaciją: prie kurio paketo dydžio ta pralaida pamatuota. Beveik visada ta pralaida pamatuota su didžiausias paketais, tačiau tai neatspindi realios įrenginio spartos.
Kompiuterių tinklo inžinieriai tinklo įrenginių pralaidą matuoja pirmiausiai kadrais/paketais per sekundę, ir bent keliems skirtingiems jų dydžiams, kurie padeda objektyviau įvertinti įtaiso spartą tinkle. Tokia įrenginio specifikacija ypač naudinga jei tinklo administratorius išanalizavęs prižiūrimą tinklo duomenų srautą ir žino tinkle vyraujančių paketų ilgių pasiskirstymą.
Neatsitiktinai ir šiame tiriamajame darbe pralaida pirmiausiai matuojama ir vertinama kadrų skaičiumi per sekunde (kps). Toks žvilgsnis į pfSense tinklo mazgo sistemą padės geriau įvertinti našumo pokyčius sukeltus visiškos virtualizacijos sluoksnio, ir skirtingų KVM VM tinklo sąsajų.

pfSense tik maršrutizatoriaus režimu: dvikryptis paketų apdorojimo skaičius per sekundę

Pralaidos stulpelinėje diagramoje vertikalioje ašyje žymimas suminis vienalaikis abiejų krypčių kadrų skaičius per sekundę tūkstančiais. Horizontalioje ašyje sužymėti skirtingų dydžių tinklo paketai. Keturių spalvų stulpeliai žymi skirtingas pfSense maršrutizatoriaus realizacijas.
Kaip ir buvo galima tikėtis, pfSense maršrutizuoja paketus sparčiausiai kai jai priskiriamos dedikuotos tinklo plokštės per IOMMU virtualizaciją ir paravirtualizuotas VirtIO tinklo sąsajos tvarkykles, kurios abi leidžia tiesioginę prieigą prie fizinių tinklo plokščių.
Gali nustebinti, bet testuose užfiksuotas ženklus pralaidos našumo skirtumas (apie 27 proc. mažesnis) tarp IOMMU dedikuotų tinklo plokščių ir tų pačių tinklo plokščių aparatinės įrangos (HW) atveju, kai pfSense maršrutizatorius apdoroja mažiausius tinklo kadro dydžius (64-256 baitų ilgio).
Iš diagramos matyti IOMMU dedikuotų tinklo plokščių maksimali 64-256 ilgio paketų apdorojimo riba – apie 470 tūkst. paketų per sekundę. pfSense sistemai veikiant betarpiškai virš aparatinės įrangos, su tomis panašiomis tinklo plokštėmis ir tvarkyklėmis, maksimali riba gerokai aukščiau – daugiau nei 600 tūkst. paketų per sekunde (to priežastis nagrinėjama prie pfSense sistemos procesoriaus vidutinės apkrovos diagramos).
VirtIO ir E1000 tinklo plokštės paketų pralaida išlieka gana stabili nepriklausomai nuo testuojamo paketo ilgio – maždaug 85 ir 32 tūkst. paketų per sekundę atitinkamai. To priežastis aparatinės įrangos spartos ribos, realizuojant programine įranga imituojamas tinklo sąsajas.
IOMMU kadrų pralaidumu prisiveja aparatinę įrangą ties 512 ilgio paketais; VirtIO paveja kai pfSense tinklo mazgas dirba su 1280 baitų paketais, o E1000 sąsaja nepriartėja ne perpus.
Taigi, įvertinus pfSense maršrutizatoriaus tinklo pralaidą kadrais per sekunde, galima į tą pačią pralaidą pažvelgti kitu kampu – bitais per sekundę. Kaip matyti kadrų ir bitų pralaidos paveiksluose vaizduojamų diagramų duomenys tarsi apsivertė. Tai gerai iliustruoja kaip įrenginio pralaidumas bitais priklauso nuo kadrų dydžio ir kaip maždaug vienodas kardų srautas per sekundę tarp visų paketo dydžių duoda skirtingą įrenginio greitaveiką bitais per sekunde (E1000 ir VirtIO atveju). Apačioje pralaidos diagramoje vaizduojama suminė vienalaikė dvikryptė greitaveika bitais per sekundę.

pfSense tik maršrutizatoriaus režimu: dvikryptė tinklo mazgo greitaveika

Gali nustebinti, tačiau net be virtualizacijos sluoksnio pfSense sistema su mažiausiais 64 baitų ilgio paketais, pralaida tik 90 Mbps (45 Mbps abiem kryptimis), kita vertus, šį duomenų srautą sudaro 629 tūkst. kadrų per sekundę; tuo tarpu IOMMU greitaveika beveik trečdaliu mažesnė – 66 Mbps (33 Mbps abiem kryptimis).
Dar prasčiau atrodo E1000 programinės ir VirtIO paravirtualizuotos tinklo sąsajos tvarkyklės, tik 10 ir 24 Mbps atitinkamai. Šiais laikais, kai belaidžio ryšio technologijos gali pasiūlyti didesnę nei 30 Mbps stabilią greitaveiką, vargu ar gali sužavėti tokia virtualaus tinklo mazgo pralaida.
Iš dalies dėl to kalta pridėtinė informacija, kaip minėta metodikos straipsnio dalyje, 64 baitų ilgio paketu perduodamos naudingos informacijos kiekis tik apie 28%, visą kitą sudaro meta duomenys.
Kai pfSense maršrutizatorius dirba su dvigubai ilgesniais 128 baitų paketais, pralaida bitais padidėja daugiau nei 4 kartus, nes ir jų perduodama naudinga informacija didėja daugiau nei du kartus, iki 64%; kartu su kadro ilgio didėjimu matomas ženklus bendros pralaidos augimas bitais.
Visos tinklo sąsajos realizacijos virtualioje mašinoje pasiekia savo praktiškai naudingą pralaidos bitais piką su didžiausiais kadrų dydžiais – 1518, nes ir jų naudingoji krova išauga iki 97%.

Paketų delsa


Kitas svarbus maršrutizatoriaus rodiklis – jį kertančių paketų delsa. Kaip minėta metodikoje, šiame darbe pfSense mazgo delsa matuojama į abi puses {round-trip time}, o ne į vieną {end-to-end}. Toliau nagrinėjama delsa pamatuota dviem atvejais: kai pfSense sistema neveikios būsenos {idle} ir kai yra apkrauta sveikąja pralaida, nustatyta pralaidos testų metu.
Pažymėtina, jog vertikalioji linijinės diagramos vertikalioji ašis logaritminės skalės – maži pokyčiai plokštumoje, turi didelį skaitinių reikšmių skirtumą.

pfSense tik maršrutizatoriaus režimu: laisvoji paketų delsa

Vėlgi, galbūt daugelio nustebimui, bet matyti aiškus skirtumas tarp tos pačios tinklo plokštės, kai ši priskirta pfSense maršrutizatoriaus platformai be virtualizacijos sluoksnio ir kai ji priskirta VM per IOMMU virtualizaciją su tos pačios konfigūracijos pfSense sistema. Vidutiniškai laisvoji delsa IOMMU atveju net 38% didesnė, tarp 64 ir 1518 baitų ilgio kadrų.
Laisvosios delsos anomalija užfiksuota su 8K-64K dydžio paketais, čia VM tinklo plokštė pasižymėjo mažesne delsa nei ta pati tinklo plokštė aparatinės įrangos atveju. Papildomi testais nepavyko šios anomalijos panaikinti, todėl tai turėtų būti teisingi duomenys. Atsižvelgus į mažą pfSense apkrovą apdorojant fragmentuotus paketus, didesnę delsą aparatinės įrangos atveju gali lemti tinklo plokštę aptarnaujančio proceso konteksto perjungimo suvėlinimas.
Laisvosios delsos skirtumas tarp VirtIO ir aparatinės įrangos kiek daugiau nei 91%, imant 64 ir 1518 baitų ilgio kadrus. Nežymus skirtumas užfiksuotas tarp programiškai imituojamų VirtIO ir E1000 tinklo sąsajų. Pastarojo vidutiniškai apie 12% didesnis, tarp 64 ir 1518 baitų ilgio kadrų.
Ryškus laisvosios delsos skirtumas tarp aparatinės įrangos ir E1000 imituojamos tinklo sąsajos: nuo 64 iki 1518 baitų ilgio kadrų užfiksuota vidutiniškai 114% didesnė laisvoji delsa.
Didesnių nei 1518 dydžio, fragmentuojamų tinklo paketų delsa tiesiogiai priklauso nuo Ethernet kanalinio lygmens kadrų delsos, todėl dideliems paketams skiriamas mažesnis dėmesys.
Apkrautosios delsos diagrama ryškiai skiriasi nuo laisvosios delsos. Įdomu tai, jog apkrautoji delsa mažesnė už laisvąją toms VM tinklo sąsajoms, kurios turi tiesioginę prieigą prie fizinės tinklo plokštės. Itin ženkliai sumažėjo VirtIO paravirtualizuotos tinklo sąsajos delsa, nors jos skirtumas lyginant su nevirtualizuota pfSense sistema vidutiniškai kiek daugiau nei 62%, imant 64 ir 1518 baitų ilgio kadrus. Iš pirmo žvilgsnio šie rezultatai prieštarauja logikai, tačiau tiek daug klaidingų duomenų surinkta testų metu negalėjo būti.

pfSense tik maršrutizatoriaus režimu: apkrautoji paketų delsa

To priežastis tikriausiai VM tinklo plokštės eiles aptarnaujančio proceso konteksto keitimas procesoriuje. Jei procesas reikšmingai apkrautas, jam skirta daugiau laiko užduotims atlikti iki procesoriaus planuoklės algoritmai nusprendžia vykdyti brangiai laiko ir našumo atžvilgiu kainuojantį procesoriaus/branduolio konteksto perjungimą. Siekiant efektyviau išnaudoti procesoriaus laiką planuoklės algoritmai siekia sumažinti kontekstų perjungimą, todėl priklausomai nuo apkrovos situacijos tai gali arba padidinti paketų aptarnavimo delsą, arba ją sumažinti.
Skirtingai nei kitos tinklo sąsajos pfSense maršrutizatoriaus apkrautos delsos testuose, E1000 gerokai sublogo. Jos rezultatai itin nenuoseklūs ir nestabilūs, kelis kart kirto 10 ms ribą. Bei apkrautoji delsa vidutiniškai didesnė net 2235% nei aparatinės įrangos, tarp 64 ir 1518 baitų dydžio kadrų.
Nepaisant rezultatų pagerėjimo tinklo plokštė atvaizduojama per IOMMU virtualizaciją vis tiek nepaveja savo našumu tos pačios tinklo plokštės naudojamos pfSense sistemoje be virtualizacijos sluoksnio; jos delsa vidutiniškai 21% didesnė, 64-1518 baitų ilgio kadrams.
Nors VirtIO tinklo sąsajos apdorojamų paketų delsa pfSense maršrutizatoriaus platformoje sumažėjo ir priartėjo prie IOMMU bei aparatinės įrangos atvejų, ji išliko pastebimai didesnė.

Paketų drebėjimas


Kitas svarbus kokybinis tinklo ryšio parametras, dažnai matuojamas kartu su tinklo delsa – tinklo paketų drebėjimas {jitter}. Atsižvelgus į sąlyginai nedidelį paketų drebėjimą sukeltą pfSense maršrutizatoriaus platformos, darbe matuojamas tik apkrautojo tinklo paketų drebėjimas, maksimalios dvikryptės pralaidos metu.

pfSense tik maršrutizatoriaus režimu: paketų drebėjimas

Kaip matyti iš paketų drebėjimo linijinės diagramos visais paketų ilgių matavimo atvejais pfSense maršrutizatoriaus įtakotas paketų drebėjimas, taikant skirtingas tinklo sąsajos realizacijas, pasižymi nuoseklumu ir stabilumu. Tarp kurių geriausiai pasirodė tiesioginę kreiptį prie fizinės tinklo plokštės turinčios virtualios mašinos tinklo sąsajos.
pfSense maršrutizatoriaus platformai apdorojant mažiausius tinklo kadrų dydžius matyti akivaizdus našumo skirtumas tarp IOMMU virtualizacijos priskirtos tinklo plokštės ir tos pačios tinklo plokštės naudojamos betarpiškai virš aparatinės įrangos. Skirtumas pradeda blėsti ties 512 baitų ilgio paketų, o testuojant 1024 baitų ir ilgesnius paketus, užfiksuotas vienodas paketų drebėjimas.
VirtIO ryškiai atsilieka nuo kitų tinklo sąsajos tvarkyklių, turinčių tiesioginę prieigą prie fizinės tinklo plokštės. Našumo skirtumas pakankamai ryškus pfSense apdorojant 128-512 baitų ilgio paketus, tačiau susilygina nuo 1280 baitų ilgio paketų.
Iš dalies blogiausius rezultatus vėl rodo programine įranga imituojama tinklo plokštė su E1000 tvarkyklėmis. E1000 rezultatų anomalija prasideda kartu su paketų fragmentacija. Pakartotini testai linijos trajektorijos nepakeitė, todėl laikomasi nuomonės, jog tai teisingi rezultatai. E1000 tinklo sąsajos pranašumą gali lemti tam tikri jos architektūriniai sprendimai, leidžiantys efektyviau apdoroti fragmentuojamus tinklo paketus.

pfSense sistemos procesoriaus vidutinė apkrova


Visų testų metu buvo fiksuojama pfSense maršrutizatoriaus vidutinė procesoriaus apkrova, tai duoda papildomos įžvalgos į pfSense sistemos ir virtualizacijos sąveiką.
Stebint pfSense vidutinę apkrova gali kilti klausimas, kodėl apkrova neviršija 50 procentų ribos. Dažniausiai, nors nebūtinai, pfSense sistemoje vienai tinklo sąsajai aptarnauti skiriamas vienas procesoriaus branduolys. Kadangi testuojama pfSense maršrutizatorius turi 4 branduolius ir 2 dedikuotas tinklo sąsajas testavimo duomenų srautui apdoroti, jų sveika apkrova neviršija 50 proc.

pfSense sistemos vidutinė procesoriaus apkrova maršrutizatoriaus režimu

Kaip matyt iš skritulinės diagramos IOMMU virtualizacija ir aparatine įranga paremta pfSense sistemos vidutinės apkrovos skritulinė figūra savo forma maždaug sutampa, bet ryškiai skiriasi jų masteliai. IOMMU būdu priskirtos tinklo plokštės VM siūlo ne tik didžiausią pralaidą virš virtualizacijos sluoksnio, bet ir vieną didžiausių pfSense VM centrinio procesoriaus apkrovą.
Iš apkrovos diagramos matyti, jog IOMMU su 64-512 baitų ilgio paketais remiasi į aparatinės įrangos galimybes, o tai paaiškina pralaidos diagramoje pastebėta aiškią IOMMU riba ties 470 tūkstančių kadrų per sekundę.
Iš teisų, IOMMU našumo dilema išlieka: kodėl toks didelis skirtumas tarp tinklo plokštės išskirtinai dedikuotos VM per IOMMU virtualizacijos palaikymą ir tos pačios tinklo plokštės be virtualizacijos sluoksnio, kai pfSense sistemos konfigūracija identiška.
Abiem atvejais, pfSense be virtualizacijos sluoksnio ir su IOMMU virtualizacija, mato tas pačias tinklo plokštes, bei naudoja tas pačias tvarkykles jų darbui tinkle. Tą patvirtina abejose pfSense sistemose, per komandinę eilutė įvykdytos komandos: pciconf –lvc igb1/igb2 ir ifconfig –a bei dmesg | grep igb1/igb2; kurių išvesta informacija praktiškai sutampa. Tačiau IOMMU atveju ta pati tinklo plokštė tampa procesoriaus išteklių siurbliu, dėl ko pasiekia ir mažesnį našumą.
Įtarus, jog virtualizacija smarkiai įtakoja procesoriaus skaičiavimo pajėgumus, su sysbench testavimo įrankiu atliktas VM su IOMMU priskirtomis tinklo sąsajomis ir nevirtualizuotos pfSense sistemos procesoriaus testavimas su komanda: sysbench --test=cpu run --num-threads=1/2/4/32; VM rezultatai buvo 3,22%, 3,23%, 3,25% ir 2,12% atitinkamai mažesni už nevirtualizuotos pfSense sistemos, o tai nepaaiškina kodėl kadrų pralaida kirto net apie 27 procentus.
Iš diagramos gana nuosekliai atrodo VirtIO tinklo sąsajos apkrova, bei apgaulingai nedidelė už mainais siūloma spartą. Iš tiesu, KVM hipervizorius kiekvienai VirtIO sąsajai sukuria po papildomą aptarnaujantį vhost procesą, matoma tik už VM ribų. Nors apkrovos diagramoje jų įtakos nematyti, top įrankio duomenimis vhost procesų apkrova testų metu buvo apie 60% per branduolį/tinklo sąsają, o tai bendrai sudaro daugiau apkrovos fizinei sistemai, nei kitos tiriamos VM tinklo sąsajos.
Kaip matyt iš skritulinės diagramos programine įranga imituojama tinklo sąsaja su E1000 tvarkyklėmis visais testuojamų paketų dydžiais maksimaliai išnaudoja dviejų branduolių išteklius – dviem tinklo plokštėms. Tikėtina, jog lėta bet stabili E1000 kadrų pralaida su visais paketų ilgiais (apie 32 kkps) padeda išlaikyti ir stabilesnį didesnių paketų apdorojimą pfSense tinklo mazge.



"Virtualizacijos įtaka pfSense tinklo užkardos sistemai: našumo analizė" Turinys:

2017 m. liepos 16 d.

Virtualizacijos įtaka pfSense tinklo užkardos sistemai: našumo analizė [1 dalis - Metodika]

Vienas iš pagrindinių darbų kuriuos atlikau ruošdamas savąjį bakalauro baigiamąjį darbą buvo kruopštus Linux KVM virtualizacijos ir pfSense kompiuterių tinklo užkardos sąveikos testavimas. pfSense sistemos atžvilgiu buvo ištestuotas Linux KVM visiškos virtualizacijos našumas Ethernet kompiuterių tinkle, taikant skirtingas tinklo sąsajas realizuojančias tvarkykles. Norėdamas gautus testų rezultatus padaryti kaip galima labiau prieinamus visiems internautams, nusprendžiau baigiamojo darbo praktinės dalies turinį paversti į keturių dalių straipsnį savo tinklaraščiui:
  1. Virtualizacijos įtaka pfSense tinklo užkardos sistemai: našumo analizė [1 dalis - Metodika]
  2. Virtualizacijos įtaka pfSense tinklo užkardos sistemai: našumo analizė [2 dalis - Router mode]
  3. Virtualizacijos įtaka pfSense tinklo užkardos sistemai: našumo analizė [3 dalis - Firewall mode]
  4. Virtualizacijos įtaka pfSense tinklo užkardos sistemai: našumo analizė [4 dalis - Noisy Neighbor]
Iš tiesų, pirmosios trys straipsnio dalys naujos informacijos nesuteikia tiems kas drįso skaityti mano bakalauro baigiamąjį darbą. Tačiau ketvirtoji dalis, kurioje nagrinėjama gretimų KVM virtualių mašinų sąveiką virš vienos fizinės kompiuterio sistemos, papildyta nauja informacija iš papildomai atliktų testų jau po baigiamojo darbo, kurio gautos išvados ir paskatino papildomus testavimus.

Metodika


Prieš pereinant prie atliktų testavimo ir gautų duomenų analizės, šio straipsnio dalyje bus apžvelgta testavimo metodika – Linux KVM virtualizacijos ir pfSense sistemos testavimo procedūros – kuri išsamiai apibrėžia naudojamą aparatinę ir programinę įrangą, taikomus metodus testams, naudojamus įrankius, tyrimo eigą bei kitą informaciją tyrimui atlikti.

Testavimo aplinkos aparatinė įranga


pfSense sistemos ir įvairių Linux KVM virtualizacijos metodų sąveikos testavimui buvo sukurta pakankamai nuo išorės izoliuota ir nepriklausoma kompiuterijos laboratorija. Nors ir su savais trūkumais, tačiau numatytam eksperimentui tinkama testavimo aplinka.

Testavimo aplinkos loginė schema

Testavimo aplinką sudaranti laboratorija suformuota iš kolegijai priklausančios studentų reikmėms skirtos kompiuterijos infrastruktūros, bei asmeninėmis priemonėmis (žr. 1 lentelė). Pažymėtina, jog testavimo aplinką sudarantys serveriai rinkoje pasirodė apie 2011 metus ir priklauso ekonomiškų modelių klasei. Jų skaičiavimų ir duomenų apdorojimo sparta nėra itin didelė. Tai reikia turėti mintyje, jog nesusidaryti klaidingos nuomonės apie nūdienos x86 architektūros platformos galimybes kompiuterių tinklo mazge.
Vis dėlto, testams skirti serveriai yra pakankamai nauji, jog turėtų AMD centrinį procesorių ir lustų rinkinį {chipset} su antros kartos aparatinio lygmens palaikymu x86 platformos virtualizacijai (AMD V 2.0), o tai tenkina minimalius praktinės darbo dalies reikalavimus, jos įgyvendinimą.
Iš tiesų, palankiomis aplinkybėmis renkantis naują serverio sistemą virtualizacijos platformai realizuoti, ypatingas dėmesys skiriamas pasirinkto virtualizacijos sprendimo palaikomos aparatinės įrangos sąrašą, bei pati kompiuterio sistema parenkama daug spartesnė už tą su kuria dirbama šiame tiriamajame darbe.
Kaip matyti iš 1 lentelės, abu serveriai identiški savo specifikacijomis (išskyrus standžiuosius diskus, bet tai neturi kritinės reikšmės tyrimui). Fizinėje testavimo aplinkos schemoje prie serverių pažymėtos tinklo plokštės prievadai (TP) iš kurių pirmieji (TP1) sujungti per komutatorių su kolegijos vidiniu kompiuterių tinklu. Tai leidžia serverius administruoti per nuotolį ir supaprastina praktinės dalies testavimo procesą. Šie prievadai (TP1) naudojami tik serverių administravimui.

1 lentelė. Testavimo aplinkos aparatinės įrangos sąrašas
Serveris 1
HP ProLiant DL165 G7 (Firmware Version: 4.22)
AMD Opteron™ Processor Model 6128 (2.0 GHz, 12MB Level 3 Cache, 8 cores, 80W)
AMD Chipset SR5670
2 x HP NC362i Integrated Dual Port Gigabit Server Adapter
4GB 1Rx4 PC3-10600R-09-10-C1-P1
2 x GB0160EAPRR HP 160GB 3G SATA 7.2K LFF HDD
Serveris 2
HP ProLiant DL165 G7 (Firmware Version: 4.22)
AMD Opteron™ Processor Model 6128 (2.0 GHz, 12MB Level 3 Cache, 8 cores, 80W)
AMD Chipset SR5670
2 x HP NC362i Integrated Dual Port Gigabit Server Adapter
4GB 1Rx4 PC3-10600R-09-10-C1-P1
SAMSUNG Spinpoint F3 HD103SJ 1TB 7200 RPM 32MB Cache SATA 3.0Gb/s 3.5"
Komutatorius
NETGEAR GS305 5-port Gigabit Ethernet Switch
Kabeliai
5 vnt. vytos poros 5e kategorijos kabelių po 2 metrus

Tuo tarpu antrosios (TP2) ir trečiosios tinklo (TP3) sąsajos tarp serverių tiesiogiai sujungtos vytos poros 5e kategorijos kabeliais. Toks pastarųjų serverių tinklo prievadų sujungimas leidžia pasiekti maksimalią tinklo paketų pralaidą ir sumažina pašalinių veiksnių įtaką testų rezultatams. Testų metu pfSense sistemai veikiant tiesiogiai virš aparatinės įrangos ar virš KVM virtualizacijos, TP2 ir TP3 tinklo plokštės prievadai dedikuoti tik tiesioginėms testavimo reikmėms.

Testavimo aplinkos programinė įranga


Praktinėje baigiamojo darbo dalyje naudojama programinė įranga priklauso atvirajam kodui, kuris šiame darbe akcentuojamas kaip teisingas pasirinkimas smulkioms ir vidutinėms organizacijoms, neretai suvaržytoms finansiškai. Antra vertus, didžioji dauguma našumo testavimo įrankių priklauso atvirajai programinei įrangai ir buvo tik natūralus atsitiktinis pasirinkimas (apie juos netrukus). Visa testavimo aplinkoje naudojama programinė įranga pateikta 2 lentelėje.

2 lentelė. Testavimo aplinkoje naudojama programinė įranga
Visiškos virtualizacijos hipervizorius
Linux KVM
Virtualizacijos administravimo įrankiai
Proxmox Virtual Environment 4.4
Tinklo mazgo testavimo įrankių OS
Ubuntu 17.04 Server (64-bit)
Tinklo mazgo testavimo įrankis
iperf 2.0.9 (1 June 2016) pthreads
Kompiuterio apkrovos simuliavimo įrankis
stress 1.0.4
Tinklo užkardos sistema
pfSense CE 2.3.4 (64-bit)


Testavimo sistemos struktūra


Testavimo aplinkos fiziniai serveriai sudaro dvi atskiras sistemas: testuojamą (serveris 1) ir testuojančią (serveris 2). Testuojantis serveris savo ruožtu gali būti išskirtas į duomenų srauto siuntėją ir gavėją (techniškai, abu serveriai siunčia ir gauna duomenis dvikryptės pralaidos testų metu), jų fizinė ir programinė konfigūracija viso testavimo metu nekinta. Tuo tarpu testuojamas serveris testavimo metu kinta tarp dviejų veikimo režimų: tarp aparatinės įrangos kompiuterio platformos su pfSense sistema ir KVM virtualizacijos platformos su pfSense sistema.

Testavimo sistemos struktūrinė schema

Pirmuoju atveju, testuojamas pfSense tinklo mazgas vykdomas be virtualizacijos sluoksnio, tiesiogiai virš aparatinės serverio įrangos. Tai leidžia nubrėžti atskaitos taškus ir nustatyti virtualizacijos sluoksnio įtaką pfSense užkardos sistemos našumui.
Antruoju atveju fizinis testuojamas serveris perjungiamas į Proxmox VE virtualizacijos aplinką, kurioje sukurtos ir pakaitomis vykdomos kelios savo specifikacijomis praktiškai identiškos KVM virtualios mašinos pfSense užkardos sistemos testavimui. Skiriasi tik VM tinklo sąsajos realizavimas skirtingiems testams atlikti.
Taigi, testavimo aplinka suprojektuota taip, jog bet kuriuo laiko momentu būtų galima persijungti tiek į virtualizuotą tiek į aparatinės įrangos pfSense tinklo mazgo testavimo režimą, jei toks poreikis atsiranda (pvz., aptikus klaidą ar netikslumų galima pakartoti tam tikrą testavimo etapą).

Testuojantis serveris


Vienas iš šios testavimo aplinkos trūkumų tas, jog testuojantis serveris taip pat remiasi į virtualizaciją – virš fizinio serverio veikia Proxmox virtualizacijos aplinka, kuri realizuoja siuntėjo ir gavėjo virtualias mašinas. Papildomas programinės įrangos sluoksnis gali įtakoti ir iškreipti testų rezultatus. Todėl, siekiant kompensuoti šiuos testavimo aplinkos trūkumus ir sumažinti gautų duomenų paklaidą, testavimui reikia skirti daugiau laiko, o neretai ir pakartoti didelę deviaciją turinčius rezultatus, jog įsitikinti gautų duomenų teisingumu.
Siuntėjo ir gavėjo virtualioms mašinoms paskirta po lygiai centrinio procesoriaus, operatyviosios atminties, standžiojo disko ir tinklo sąsajos išteklių, bei vienodos jų operacinės sistemos su įtaisų tvarkyklėmis ir visų operacijų prioritetais Proxmox VE atžvilgiu. Testavimo aplinkos siuntėjo ir gavėjo virtualiųjų mašinų charakteristikos pateiktos 3 lentelėje.

3 lentelė. Testavimo aplinkos siuntėjo ir gavėjo VM techninės specifikacijos
VM 1
VM 2
Hipervizorius
Linux KVM (Proxmox VE 4.4)
Linux KVM (Proxmox VE 4.4)
vCPU branduoliai
8 [host]
8 [host]
RAM
1376 MB (dedikuota, fiksuoto dydžio)
1376 MB (dedikuota, fiksuoto dydžio)
OS
Ubuntu 17.04 Server (64-bit)
Ubuntu 17.04 Server (64-bit)
Tinklo plokštė
1 dedikuota [PCI passthrough]
1 bendrinama [VirtIO bridge]
1 dedikuota [PCI passthrough]
1 bendrinama [VirtIO bridge]
Standusis diskas
16 GB [VirtIO SCSI, LVM Thin]
16 GB [VirtIO SCSI, LVM Thin]

Pastebėtina, jog aštuoni virtualaus centrinio procesoriaus branduoliai abiems virtualioms mašinoms nėra klaida (fizinis procesorius turi tik 8 branduolius), o normali ir saugi KVM virtualizacijos praktika. Jei kuri nors viena mašina nenaudoja visų jai priskirtų branduolių, juos gali panaudoti kitos. Tačiau reiktų vengti vienoje VM nustatyti daugiau virtualiųjų branduolių nei turi fizinis procesorius, tai tik sulėtins sistemą dėl dažno procesoriaus konteksto perjunginėjimo.
Kadangi abi virtualios mašinos, siuntėjas ir gavėjas, dirbs su dideliais duomenų srautais tinkle nuo kurių našaus ir nepertraukiamo darbo priklauso testų rezultatai, abiems VM priskirtos dedikuotos tinklo plokštės per IOMMU virtualizacijos palaikymą (dar žinoma kaip PCI passthrough); bei viena bendrinama su paravirtualizuotomis tvarkyklėmis, skirtą testų valdymo reikmėms.
Nors techniškai buvo galima išvengti papildomo virtualizacijos sluoksnio siuntėjui ir gavėjui realizuoti, visgi praktikoje neretai dėl patogumo paaukojamas našumas. Šiuo atveju Proxmox VE administravimo panelė leidžia per nuotolį pasiekti abi virtualias mašinas ir jas valdyti per grafinę saityno tinklalapio vartotojo sąsaja (GUI), o tai supaprastina tiriamojo darbo įgyvendinimą.
Darbo autoriaus nuomone tai pateisintina dėl itin mažos siuntėjo ir gavėjo apkrovos bendrai sistemai. Priklausomai nuo testo, bendra fizinės kompiuterio sistemos apkrova svyruoja nuo 30 iki 50 proc.: po vieną centrinio procesoriaus branduolį tinklo sąsajoms aptarnauti ir maždaug po vieną branduolį testavimo iperf įrankio reikmėms – duomenų srautui generuoti ir registruoti. Antra vertus, prailgintas testavimo laikas gali kompensuoti rezultatų nuokrypio svyravimus ir sumažinti paklaidą.

Testuojamas serveris


Testavimo aplinkos testuojamas serveris priklauso ekonominei klasei, nepasižymi nei funkcijų gausumu nei ištekliu gausa. Todėl nors ir siekta sukonfigūruoti techniškai vienodų aparatinių parametrų VM ir fizinę serverio platformą pfSense užkardos sistemos testavimui, tarp jų yra skirtumų, tačiau atliekamiems testams jie nėra esminiai ir kritiškai reikšmingi (žr. 4 lentelę).

4 lentelė. Testavimo aplinkos testuojamų mašinų techninės specifikacijos
Nevirtualizuota pfSense sistema
Virtualios mašinos su pfSense sistema
Hipervizorius
-
Linux KVM (Proxmox VE 4.4)
vCPU branduoliai
4 (apriboti programiškai)
4 [host]
RAM
4096 MB
2048 MB (dedikuota, fiksuoto dydžio)
OS
pfSense CE 2.3.4 (64-bit)
pfSense CE 2.3.4 (64-bit)
Tinklo plokštė
3 fizinės dedikuotos
1 atvejis: 2 dedikuotos [E1000 bridge]
2 atvejis: 2 dedikuotos [VirtIO bridge]
3 atvejis: 2 dedikuotos [PCI passthrough]
Visais atvejais: 1 bendrinama [VirtIO bridge]
Standusis diskas
4 GB skaidinys [SATA standusis diskas]
4 GB [VirtIO SCSI, LVM Thin]

Vieną skirtumą įtakojo tai, jog testavimo serverio BIOS sistemoje nėra galimybės aparatiniame lygmenyje išjungti dalį centrinio procesoriaus branduolių. Tačiau, šią problemą pavyko išspręsti programiniu būdu – į pfSense paleidimo failą (/boot/loader.conf) įrašius kelias direktyvas: „hint.lapic.CPUid.disabled=1“, kurios nurodė pfSense (FreeBSD) operacinės sistemos branduoliui nenaudoti įvardintus procesoriaus branduolius.
Vis dėlto, sumažinti operatyviosios atminties kiekį nei fiziniu nei apriboti programiniu būdu nepavyko. Tačiau, remiantis sistemos apkrovos stebėjimais, testų metu pfSense užkardos sistemos darbinės atminties sunaudojimas neperžengė 512MB ribos, iš kurių 300MB autorius savo iniciatyva rezervavo /tmp ir /var atminties failų sistemos diskui {memory file system disks}. Iš tiesų, pfSense kūrėjų teigimu, jų sistemą įmanoma sėkmingai vykdyti ir su 128 MB operatyviosios atminties, nors rekomenduojama 256 MB ar daugiau.
Testuojamam serveriui veikiant virtualizacijos platformos režimu, sukurtos virtualios mašinos su pfSense užkardos sistema veikia virš tos pačios platformos pakaitomis. Todėl tarp jų aparatinės ir programinės įrangos parametrų skirtumų nėra (žr. 4 lentelę). Sąmoningai skiriasi tik KVM hipervizoriaus realizuojamos skirtingų savybių tinklo plokštės skirtingiems testams atlikti.
Jei nėra nurodyta kitaip, skirtumų nėra ir tarp pfSense užkardos sistemos konfigūracijos, taikytos virtualizuotoje ir nevirtualizuotoje aplinkoje.

pfSense testavimo modelis


Praktinėje baigiamojo darbo dalyje tinklo mazgo testavimas vykdomas kliento-serverio modelių, kai matuojamas tinklo našumas tarp dviejų tinklo taškų. Šiuo tiriamojo darbo atveju tarp testuojamų dviejų tinklo taškų tik vienas tinklo mazgas – pfSense sistema, todėl matuojamas tik jos tinklo našumas, jei testo metu galinių taškų (serverio ir kliento) ištekliai nėra perkrauti.
Kaip jau buvo minėta praktinėje dalyje atliekamų testų metu testuojančio serverio bendra apkrova svyravo tarp 30 ir 50 proc., priklausomai nuo atliekamo testo. Todėl galima teigti, jog visų testų metu buvo matuojamas tik pfSense tinklo mazgo našumas.

pfSense testavimo modelio schema

Atliktų testų procedūrą, nepriklausomai nuo platformos virš kurios veikia pfSense sistema, suprantamai perteikia testavimo modelio schema. Viena dedikuota pfSense tinklo plokštė sujungta su testavimo įrankio serveriu ir imituoja interneto sąsają (WAN); kita sujungta su klientu ir imituoja vietinio tinklo sąsają (LAN). Klientas su serveriu užmezga ryšį ir pagal nurodytus parametrus generuoja, siunčia bei priima duomenų srautą. Visi testai atliekami vienalaikiu dvikrypčiu duomenų perdavimu, nes ir praktikoje tinklo mazgas patiria vienalaikį dvikryptį duomenų srautą.

Testų metodika ir RFC 2544


Tiriamojo darbo testavimo metodika remiasi RFC 2544 (Benchmarking Methodology for Network Interconnect Devices) rekomendacijomis. Vis dėlto, dėl tinklo mazgų testavimo įrankių palaikančių šį neoficialų standartą trūkumo autoriaus aplinkoje, tik iš dalies laikomasi RFC 2544 nurodymų. Be to, darbe taikomas papildomas paketų drebėjimo {jitter} testas, kuris neapibrėžtas RFC 2544 tinklo įrenginių testavimo metodikoje, nors šiai dienai įvardinamas kaip vienas iš svarbesnių tinklo kokybinių rodiklių. Iš tiesų, nūdienos Ethernet tinklo testavimo įrenginiai palaiko ir naujesnę tinklo mazgų testavimo metodiką, apibrėžtą ITU (International Telecommunication Union) organizacijos Y.1563 (Ethernet frame transfer and availability performance) standartu. Deja pastaroji yra mokama ir dėl finansinių suvaržymų darbe ja nesiremta.
RFC 2544, tai tinklo kartotuvų, komutatorių bei maršrutizatorių testavimo metodikos de facto standartas laisvai prieinamas internete. Jis 1999 metais pristatytas Internet Engineering Task Force organizacijos, siekiant suvienodinti ir aiškiai apibrėžtą tinklo mazgų testavimo metodiką, kuri leistų palyginti skirtingų gamintojų tinklo įrenginius tarpusavyje.
Nors RFC 2544 standartas numato daugiau tinklo mazgo įrenginių testų, šiame tiriamajame darbe pasinaudota tik svarbiausių testų metodikos rekomendacijomis, derinant jas prie darbe naudojamos testavimo įrangos išteklių ir poreikių darbo tikslui pasiekti.

Testavimo įrankiai


Šiame darbe testavimui naudojamas populiarus ir lengvai prieinamas atvirosios programinės įrangos tinklo tiriamasis įrankis – iperf. Jis leidžia pamatuoti tinklo pralaidą UDP ir TCP protokolais, vienakrypčiu {unidirectionally} ir vienalaikiu dvikrypčiu {bi-directionally} duomenų perdavimu, bei keliomis lygiagrečiomis ryšio sesijomis, tarp dviejų tinklo mazgų. Testuojant UDP duomenų srautu, iperf ne tik parodo pralaidos rezultatus, bet suteikia daug naudingos informacijos apie tinklo kokybinius rodiklius: tokius kaip UDP paketų drebėjimą {packet jitter} ir jų nuostolius {packet loss}.
Testavimo įrankį padėjo pasirinkti Barton J. tiriamasis darbas „Performance Testing Tools“, nagrinėjantis tinklo našumui tirti skirtus programinius įrankius RFC2544 rekomendacijos atžvilgiu.
Tačiau tinklo našumo testavimas iperf turi trūkumą, tai programinės įrangos testavimo priemonė veikianti virš bendro pobūdžio Linux operacinės sistemos. Bendros paskirties operacinėje sistemoje veikia sisteminiai procesai, kurie tam tikrais laiko momentais suaktyvėja, o tai gali iškreipti testų duomenis, ne dėl testuojamo tinklo mazgo (pfSense) įtakos.
Kita vertus, testavimo iperf įrankis operuoja virš bendro pobūdžio Linux OS, kuri veikia virš virtualizacijos sluoksnio, sukurtą dar kitos programinės įrangos – Proxmox VE, ši taip pat paremta Linux OS. Deja profesionalūs tinklo mazgo testavimo įrankiai, kuriu integriniai grandynai sukurti tik vienai užduočiai atlikti – tinklo kokybiniams ir kiekybiniams rodikliams matuoti, kainuoja nemenkus finansinius išteklius ir autoriui yra neprieinami.
Nepaisant atsakingo ir kruopštaus testavimo, tiriamojo darbo testų metu surinktus duomenis vertėtų priimti mintyje su nedidele paklaida, atsirandančias dėl minėtų testuojamos aplinkos trūkumų. Tačiau, pateikti galutiniai ir susisteminti rezultatai pakankamai tikslūs, jog būtų galima palyginti skirtingas Linux KVM hipervizoriaus tinklo sąsajos tvarkykles, jų našumą pfSense sistemos atžvilgiu.

Ethernet kompiuterių tinklo kadrų ilgiai


Išsamiai tinklo mazgo charakteristikai gauti RFC 2544 rekomenduoja, jog visi testai būtų atliekami bent su penkiais skirtingo dydžio tinklo kadrais. Tarp kurių būtinai mažiausias ir didžiausias galimas testuojamam kanalinio lygmens standartui.
Ethernet kompiuterių tinklo atveju, RFC 2544 rekomendacijos apibrėžia šiuos tinklo kadro dydžius: 64, 128, 256, 512, 1024, 1280 ir 1518 baitų; tarp kurių mažiausias ir didžiausias galimi, bei keletas tarpinių lengvai įsimenamų kadro dydžių.
Iš tiesų, nėra vieno geriausio kadro dydžio tinkamo visiems Ethernet tinklams, kadangi visuose kompiuterių tinkluose vyrauja skirtingas kadrų dydžių pasiskirstymas. Tačiau, jei tinklo įrenginio gamintojas pristato savo įrenginio spartą/pralaidą vienu skaičiumi, RFC 2544 rekomenduoja, jog pralaida būtų išreikšta mažiausiu tinklo kadro dydžiu. Deja marketingo vedami didelė dalis tinklinės įrangos gamintojų pristato savo prietaisų pralaidą išmatuota su didžiausiais tinklo kadrais, dažnai pamiršdami tai nurodyti ne tik ant pakuotės, bet ir įrenginio instrukcijose, specifikacijose.
Mažesni tinklo kadrai padeda testuoti tinklo mazgo aparatinės įrangos spartą, kadangi maksimaliai mazgo pralaidai pasiekti reikia apdoroti daugiau tinklo kadrų per vienetinį laiko tarpą. Tuo tarpu didesni tinklo kadrai neša daugiau naudingos informacijos ir gali tą pačią pralaidą pasiekti su mažesniu tinklo kadrų skaičiumi per vienetinį laiko tarpą.
Iš dalies laikantis RFC 2544 nurodymų, šiame darbe testai atliekami ne tik su didžiausiu Ethernet standarto kadro dydžiu, bet ir didžiausiu leidžiamu IP protokolo paketų dydžiu, bei keliais tarpiniais tinklo lygmens paketų dydžiais. Taigi, šiame darbe papildomai testuojami šie IP paketų dydžiai: 4096, 8192, 16384, 32768 ir 65507 baitų.
Kompiuterių tinkle maksimalus perdavimo vienetas – vadinamasis MTU {maximum transmission unit} – kanaliniame lygmenyje tik 1518 baitų ilgio. Todėl dideliems IP protokolo paketams reikalinga fragmentacija – didesnių tinklo lygmens paketų skaidymas į mažesnius kanalinio lygmens kadrus, kurį atlieka TCP/IP protokolų rinkinį palaikantis maršrutizatorius.
Kadrų dydžių išplėtimą IP paketų dydžiais siekiama išsiaiškinti kaip pfSense susitvarko su paketų fragmentacija vykstančia tinklo lygmenyje. Šiame darbe atliekami testai orientuoti ne kiek tinklų tilto (kuris apdoroja tik kanalinio lygmens kadrus), bet į interneto tinklą (paremta IP protokolu) sudarančių tinklo mazgų operacijoms testuoti.
Kita vertus operuoti 65507 baitų paketais virš pakankamai mažo standartinio Ethernet MTU yra pavojinga. Fragmentų surinkimas vykdomas tik tada, kai gaunami visi jo fragmentai. Tai sulėtina pilno paketo apdorojimą. Antra vertus, pametus bent vieną fragmentą, tenka siųsti visus fragmentus iš naujo. Vadinasi, vienas kadro netekimas prilygsta maždaug 44 įprastų MTU praradimui.
Nors paketo ir kadro sąvokos skiriasi, šiame darbe šie terminai neretai vartojami kaip lygus. Vis dėlto darbe dažniau vartojama paketo sąvoka. Viena vertus, testuojamas tinklo mazgas (pfSense) operuoja tinklo lygmenyje; antra vertus, ne IT srities atstovui paketo sąvoka suprantamesnė už kadro.
Tačiau reiktų turėti mintyje, jog IP protokolo leidžiamas paketo ilgis yra 20-65535 baitai, o žemesniojo Ethernet kanalinio lygmens kadrų: 64-1518 baitai. Todėl analizuojant gautus testų duomenis, visuose diagramose abscisės ašyje nuo 64 iki 1518 žymimas kanalinio lygmens kadrų ilgis baitais, o nuo 4K iki 64K paketų ilgis baitais. Pralaidos diagramos ordinatės ašyje mazgo sparta matuojama tik kadrais ir bitais per sekundę. Autoriaus nuomonė kadrai reikšmingesnė informacija už paketus vertinant tinklo mazgo spartą, kadangi paketai žemesniame lygmenyje vis vien perduodami kaip tinklo kadrai kurių maksimali naudingųjų duomenų krova {payload} tik 1500 baitų.
Šiame darbe testavimo įrankiu iperf tinklo mazgo našumo rodiklius pasirinktinai matuojama su UDP paketų srautu, kuris pagal OSI modelį priklauso ketvirtajam lygmeniui. Tuo tarpu Ethernet kadarai priklauso antrajam, kanaliniam lygmeniui. Todėl norint siųsti pageidaujamo dydžio kadrus kanaliniame lygmenyje, reikia nepamiršti apskaičiuoti ir atmesti iš siunčiamo paketo tarpinių lygmenų antraščių ilgius.
Pavyzdžiui, jei iperf nurodoma siusti 1518 baitų UDP paketus, kanaliniame lygmenyje pridėjus antraštes jo dydis bus matomas kaip 1546 baitai, o tai reiškia fragmentaciją, bet ne vieną standartinį Ethernet MTU, kas iškreiptų testo rezultatus. Jog neįsiveltų klaida, darbe siunčiamų paketų ir kadrų dydžių tikslumu buvo įsitikinta juos patikrinus tcpdump paketų analizatoriumi.
Taigi, norint išsiųsti tam tikro dydžio kadrą kanaliniu lygmeniu reikia nepamiršti transportinio (TCP/UDP), tinklinio (IP) bei kanalinio lygmens (Ethernet) antraščių ilgių sumos atimti iš siunčiamo paketo su iperf testavimo įrankiu.
Jei MTU 1518 baitų, norint išvengti UDP paketo fragmentacijos maksimalus jo ilgis neturėtų viršyti 1472 baitų: 1518 – 18 (Ethernet antraštė) – 20 (IP antraštė) – 8 (UDP antraštė);
Atitinkamai TCP protokolo atveju maksimalus TCP paketo ilgis neturėtų viršyti 1460 baitų: 1518 – 18 (Ethernet antraštė) – 20 (IP antraštė) – 20 (TCP antraštė).
Visi kadrų ir paketų ilgiai naudoti testavimo metu su iperf –l parametro reikšmėmis pateikti 5 lentelėje, naudingos UDP paketo krovos {payload} stulpelyje.

5 lentelė. Testuojamų kadrų ir paketų ilgiai baitais
Ethernet kadro dydis
UDP paketo krova
Ethernet kadro dydis
UDP paketo krova
64
18
1518
1472
128
82
fragmentuojama į 1518
4096
256
210
fragmentuojama į 1518
8192
512
466
fragmentuojama į 1518
16384
1024
978
fragmentuojama į 1518
32768
1280
1234
fragmentuojama į 1518
65507

Iš 5 lentelės gerai matyti, jog labai skiriasi naudingos perduodamos informacijos ir pridėtinės informacijos (antraščių) santykis: kuo jis didesnis, tuo efektyviau išnaudojama tinklo mazgo pralaida. Iš tiesų, galima nesunkiai paskaičiuoti UDP protokolo efektyvumą Ethernet atžvilgiu:
  • Siunčiant mažiausius kadro dydžio paketus:
  • (Naudinga UDP paketo krova)/(Mažiausias Ethernet kadro dydis)=18/64≈28%;
  • Siunčiant didžiausius kadro dydžio paketus: 
  • (Naudinga UDP paketo krova)/(Ethernet MTU)=1472/1518≈97%
Atitinkamai pridėtinės UDP protokolo informacijos {protocol overhead} santykis išreikštas procentais: maždaug 72% su mažiausiais kadrais ir 3% su didžiausiais (Ethernet atžvilgiu).

Sekančiame skyrelyje apibrėžta tinklo mazgo (pfSense) pralaidos matavimo metodika, kuri šiame darbe matuojama tik naudingos informacijos srauto atžvilgiu, t.y. tokią, kurią galima išnaudoti praktiškai, neskaičiuojant paketų antraščių sukuriamo pridėtinės informacijos duomenų srauto.

Sveikoji tinklo mazgo pralaida


Tinklo pralaida {throughput} esminis tinklo našumo kiekybinis rodiklis, marketingo tikslais dažnai perteikiamas bitais per sekunde (bps), tartum leidžiantis iš pirmo žvilgsnio įvertinti tinklo įrenginio spartą. Tačiau, tinklo pralaida matuojama ne tik bitais per sekundę, bet ir kadrais/paketais per sekundę (kps/pps). Būtent pastarasis pralaidos matavimo vienetas padeda objektyviau įvertinti įrenginio spartą. Be to, svarbu nurodyti su kuriuo tinklo kadro ilgiu įrenginio pralaida išmatuota, kadangi dažnas Ethernet tinklo įrenginys pasieks afišuojamą 1 Gbps duomenų perdavimo spartą siunčiant didelius paketus, bet retas pasieks bent pusę nurodytos pralaidos su mažais tinklo paketais.
RFC 2544 tinklo mazgo pralaidą apibrėžia kaip maksimalų kadrų skaičių per sekundę, perduotą be nuostolių per 60 sekundžių laikotarpį – išsiųstų kadrų skaičius lygus gautųjų skaičiui. Pralaidą rekomenduojama įvardinti kadrų skaičiumi per sekundę, visiems testuojamiems kadro dydžiams.
Šiame darbe pralaida taip pat įvardinama kadrais per sekundę (kps), bei bitais per sekundę (bps) dėl visuotinio aiškumo. Tačiau taikoma didesnė leidžiamoji nuostolių riba – 0,1 proc. Absoliučia dauguma atveju tinklo paslaugos turėtų be problemų susitvarkyti su 0,1% paketų nuostoliais tinkle.
Visgi reikia pažymėti, jog iš pirmo žvilgsnio ir nedidelė dalis pamestų tinklo paketų (pvz., 1-2 proc.), priklausomai nuo naudojamo transportinio protokolo, skirtingai įtakoja tinklą ir jo paslaugas. Pavyzdžiui, pamestas UDP paketas nepersiunčiamas ir papildomo krūvio tinklui dėl to nesukuria. Tačiau pamestas TCP paketas pagal protokolo apibrėžimą yra pakartotinai persiunčiamas, o tai gali paskatinti tinklo grūstį ir dar didesnius paketų nuostolius.
Nors tinklo mazgo pralaidą galima matuoti TCP paketais, šiame tiriamajame darbe pralaida matuojama su UDP paketų srautu, kadangi šis testavimo režimas su iperf tinklo testavimo įrankiu suteikia ne tik kiekybinės, bet ir kokybinės informacijos apie tinklo ryšį, reikalingos testų duomenims surinkti, bei testų patikimumui įvertinti. Visi pralaidos testai atliekami vienalaikiu dvikrypčiu duomenų perdavimu, nes ir praktikoje tinklo mazgas apdoroja vienalaikį dvikryptį duomenų srautą.
Tinklo mazgo pralaidos testai atliekami parenkant iperf –b parametro reikšmes ir laikomas sėkmingu jei testo metu prarastų paketų dalis mažesnė arba lygi 0,1 proc. Surasta –b parametro reikšmė nurodo testuojamam paketo dydžiui maksimalią pralaidą (paketais ir bitais) su kuria pfSense sistema gali susidoroti be žymių UDP paketų nuostolių. Maksimali pralaida kurios nuostoliai pasirinktam paketo dydžiui nedidesni už 0,1% šiame darbe vadinama sveikąja pralaida.
Vienas pralaidos testas trunka 100 sekundžių ir periodiškai pakartojamas 3 kartus. Jei bent 1 iš 3 bandymų rezultatų, imant vidurkį iš dvikrypčio duomenų srauto rezultatų, tenkina keliamus nedidesnių nei 0,1% nuostolių reikalavimus, o deviacija proporcinga kitiems rezultatams, jis užskaitomas kaip teisingas testas. Jei visi bandymai atitinka iškeltus reikalavimus, imami to bandymo rezultatai, kurio gauti duomenys turi mažesnius nuostolius, o paketų pralaida ir drebėjimas atrodo stabilesni už kitus. Antraip vėl kartojamas 3 bandymų ciklas kol randama iperf –b parametro reikšmė. Ieškant –b parametro reikšmės naudotas derinimo detalumas ir tikslumas: didesniems tinklo paketams po 5 Mbps, mažiems po 1 Mbps (nors galima derinti ir kps).

Sėkmingo iperf –c 10.0.2.20 –u –b 130 M –d –t 100 –i 10 –l 82 testo fragmentas:

[ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[3]  0.0-10.0 sec   155 MBytes   130 Mbits/sec   0.006 ms 2182/1981800 (0.11%)
[3] 10.0-20.0 sec   155 MBytes   130 Mbits/sec   0.008 ms 2101/1981718 (0.11%)
[3] 20.0-30.0 sec   155 MBytes   130 Mbits/sec   0.008 ms 1071/1981710 (0.054%)
[3] 30.0-40.0 sec   155 MBytes   130 Mbits/sec   0.008 ms 1669/1981713 (0.084%)
[3] 40.0-50.0 sec   155 MBytes   130 Mbits/sec   0.006 ms  494/1981713 (0.025%)
[3] 50.0-60.0 sec   155 MBytes   130 Mbits/sec   0.008 ms 2276/1981709 (0.11%)
[3] 60.0-70.0 sec   155 MBytes   130 Mbits/sec   0.009 ms 1554/1981703 (0.078%)
[3] 70.0-80.0 sec   155 MBytes   130 Mbits/sec   0.006 ms 1742/1981718 (0.088%)
[3] 80.0-90.0 sec   155 MBytes   130 Mbits/sec   0.008 ms 1693/1981697 (0.085%)
[3] 0.0-100.0 sec  1.51 GBytes   130 Mbits/sec   0.008 ms 19657/19817064 (0.099%)


Laisvoji ir apkrautoji paketų delsa tinkle


Paketų delsa {latency} yra vienas esminių kompiuterių tinklo kokybinių rodiklių, leidžiantis įvertinti ryšio kokybę. Vėlinimas itin neigiamai įtakoja realaus laiko tinklo paslaugas, tokias kaip VoIP, vaizdo konferencijas, kompiuterinius žaidimus tinkle bei kt. Nesunku įsivaizduoti, kaip laike vėlinamas pokalbis telefonu, ar vaizdo konferencija sumažina produktyvumą ir jų panaudojimo efektyvumą. Tuo tarpu žaidimai tinkle visai netoleruoja ir sąlyginai nedidelės paketų delsos.
Tinklu keliaujantis paketas yra pristabdomas kiekvieno tinklo mazgo kurį jis kerta, tol kol bus apdorotas pagal apibrėžtas mazgo taisykles. Kiek ilgai paketas užtruks tinkle, priklauso nuo tinklo mazgų spartos, todėl renkantis tinklo mazgą itin svarbu atkreipti dėmesį į jo sukeltą paketų vėlinimą.
Šiame darbe delsa matuojama dviem atvejais: kai pfSense sistema neveikios būsenos {idle} ir kai apkrovos būsenos {load}. Tuo tarpu RFC 2544 apibrėžia tik apkrovos būsenos matavimą. Neveikios būsenos delsos laiką šiame darbe vadinsime laisvąja delsa, o apkrovos – apkrautąja delsa.
RFC 2544 taip pat taiko skirtingą delsos laiko matavimo metodiką, kuri matuoja tinklo mazgo vidinės delsos laiką {end-to-end time}. Šiame darbe testavimo metodika supaprastinta iki ping įrankio, matuojančio delsos laiką tinkle į abi puses {round-trip time}, tačiau visiškai tinkamo skirtumui ir įtakai tarp įvairių tinklo mazgo sprendimų pamatuoti.
Nors RFC 2544 rekomenduoja tikrinti testuojamos sistemos delsą maksimalia pralaida nustatyta mazgo pralaidumo testuose, tačiau, atsižvelgus į testavimo sistemos jautrumą, pfSense tinklo paketų apkrautos delsos testai atliekami kartu su 95% maksimalia greitaveika, t.y. sveikoji pralaida sumažinta 5% kiekvienam testuojamo paketo dydžiui.
RFC 2544 numato vieną delsos testą kiekvienam paketo dydžiui vykdyti 120 sekundžių ir siųsti tik vieną delsos tikrinimo paketą po 60 sekundžių. Šį testą siūloma kartoti bent 20 kartų ir teisingam atsakymui imti vidurkį iš visų 20-ties gautų delsos tikrinimo paketų.
Šiame darbe delsos testas tai pat vykdomas 120 sekundžių, kurio metu po 60 sek. siunčiama 10 ping komandos sugeneruotų delsos tikrinimo paketų (kanaliniame lygmenyje 64 baitų ilgio). Vieno testo metu fiksuojamas vidurkis iš 10 delsos paketų. Toks išplėstas testavimas leidžia patikrinti delsos deviaciją tarp 10 paketų, ir padeda pastebėti galimai iškreiptus rezultatus dėl anksčiau aptartų testavimo sistemos trūkumų.
Delsos testai po 120 sek. kartojami 9 kartus kiekvienam paketo ilgiui. Iš geriausių 6 delsos laiko rezultatų imamas vidurkis kaip teisingas rezultatas testuojamam paketo dydžiui. Jei 9 testų metu gauti duomenys tarpusavyje prastai koreliuoja, turi didelę deviaciją ir nuostolius, visi duomenys atmetami ir testų serija atitinkamam paketo dydžiui kartojama.

Tinklo paketų drebėjimas


Kitas svarbus kokybinis kompiuterių tinklo rodiklis yra paketų drebėjimas {jitter}, kuris taip pat atsiranda dėl tinklo mazgo kaltės, jų paketų apdorojimo metodų ir spartos. Kaip ir paketų delsos atveju ryšio drebėjimas neigiamai įtakoja realaus laiko tinklo paslaugas. Sakoma, jog didelė paketų delsa ir drebėjimas sumažina naudingo kompiuterių tinklo diametrą.
Pavyzdžiui, VoIP perduodamo balso duomenų srauto paketų perteklinis drebėjimas gali sukelti girdimos kalbos trūkinėjimus telefono garsiakalbyje kitame ryšio gale; analogiškai trūkinėja ir tinklu transliuojamas vaizdo signalas. Taip nutinka jei priimančio prietaiso buferis lengvai perpildomas ar laiku negauna duomenų, kuris procesorinio įtaiso apdorojamas reguliariais laiko intervalais.
Paketų drebėjimas tai paketų delsos svyravimas, dėl kurio tinkle susidaro nelygus tarpai tarp nuosekliai siunčiamų paketų. Jei nuosekliai siunčiamų kadrų perdavimo pradžioje jų tarpkadrinis laiko tarpas buvo vienodas, tinklo paketams keliaujant tinklu ir kertant ne vieną tinklo mazgą tarpkadrinis laiko tarpas pradeda kisti. Jis kinta dėl ilgo kadrų apdorojimo laiko tinklo mazge, mazgo buferinės atminties sukeltų kadrų pliūpsnio {burst}, ar susidariusių skirtingų tinklo kelių tarp paketų.
Atrodytų keista, bet paketų drebėjimo testas nėra apibrėžtas RFC 2544 rekomendacijoje. Galbūt todėl, jog 1999 metais šio kokybinio kompiuterių tinklo rodiklio reikšmę ateičiai buvo sunku numatyti? Kaip ten bebūtų, dauguma nūdienos tinklo testavimo įrenginių siūlo ne tik delsos, bet ir paketų drebėjimo testą. Ne išimtis ir šio tiriamojo darbo testavimas, kadangi paketų drebėjimas ir delsa gali sukelti daug problemų realaus laiko tinklo paslaugoms.
Paketų drebėjimo testai buvo atlikti kartu su maksimalios sveikosios pralaidos matavimais. Testuose naudojamas iperf tinklo testavimo įrankis kartu su UDP paketų pralaida leidžia matuoti ne tik pralaidą, pamestų paketų skaičių, bet ir suteikia informacija apie paketų drebėjimą.
Pralaidos testavimo metu pastebėtas iperf įrankio trūkumas – jis neskaičiuoja vidutinės paketų drebėjimo reikšmės, o pateikia tą, kurią fiksavo standartinės išvesties momentu. Atsižvelgus, jog paketų drebėjimo vidurkį tenka skaičiuoti lėtuoju-rankiniu būdu, bei į testų metu surinktų duomenų gausą, nuspręsta ryšio drebėjimą skaičiuoti tik iš vieno stabiliausio pralaidos testo duomenų.
Vienas pralaidos testas, 100 sekundžių trukmės, paketų drebėjimą užfiksavo 10 kartų, lygiais laiko tarpais kas 10 sekundžių nuo testo pradžios. Šių duomenų vidurkis buvo priimtas kaip paketų drebėjimo rezultatas tam pačiam paketų dydžiui kuriam matuota sveikoji pralaida.

Užkardos funkcijų testavimas


Dauguma tinklo mazgų turi bent minimalias galimybes filtruoti duomenų srautą, kurios neretai panaudojamos tinklo saugumo didinimui. Todėl RFC 2544 rekomendacijos apibrėžia paketų filtravimo testą, kuriuo siekiama patikrinti tinklo mazgo galimybes efektyviai filtruoti paketus pagal tinklo protokolo siuntėjo ir gavėjo adresus. Šis tinklų tilto ir maršrutizatoriaus našumą įtakojantis testas buvo pritaikytas ir pfSense užkardos testavimo reikmėms. Testu tiriamajame darbe siekiama imituoti vartotojo sukonfigūruotą pfSense užkardos sistemą su vartotojo apibrėžtomis taisyklėmis.
Atliekant skirtingus pfSense užkardos sistemos režimų testus, pirmiausia buvo užfiksuota pfSense sistemos paketų apdorojimo sparta kai jos duomenų srauto filtravimo galimybės išjungtos, ir sistema dirba tik maršrutizatoriaus režimu (pfctl -d). Vėliau, į pfSense užkardos sistema su įjungtu duomenų srauto filtravimu (pfctl -e) buvo įtrauktos 25-ios vartotojo apibrėžtos paketų filtravimo taisyklės ir atliktas išsamus testavimas.
RFC 2544 nurodymais pirmosios 24 vartotojo apibrėžtos taisyklės turi blokuoti apibrėžtus, testų duomenų srautui nenaudojamus IP adresus, o paskutinė 25-oji taisyklė suteikti leidimą testo duomenų srautui kirsti pfSense mazgą iki paskirties taško. Taigi, pfSense sistema priverčiama nuosekliai tikrinti visas 25 vartotojo apibrėžtas paketų filtravimo taisykles. Toks taisyklių tikrinimas gali gerokai įtakoti tinklo mazgo našumą, jei šis nėra pritaikytas tinklo apsaugos užduotims vykdyti.
Reikia pastebėti, jog RFC 2544 nurodo 24 pirmas taisykles kaip blokavimo. Tačiau tinklo užkardose dažniausiai taikoma saugos praktika paremta strategija viską blokuoti {default deny} ir praleisti tik tai kas būtina. Todėl pfSense sistema sukonfigūruota su 25 leidimo taisyklėmis, iš kurių taip pat tik viena ir paskutinė duoda leidimą testo duomenų srautui kirsti pfSense tinklo mazgą.
Atsižvelgiant į tai, jog vidinio tinklo adresai dažniau kerta pfSense užkardą, pirmosios 12 filtravimo taisyklių skirtos iš LAN sąsajos ateinantiems paketams ir sekančios 12 iš WAN pusės ateinantiems paketams; tuo būdu tikimasi optimizuoti užkardos paketų tikrinimą. Paskutinioji taisyklė, duodanti teigiamą leidimą testų duomenų srautams, tikrina abiejų sąsajų (WAN ir LAN) įeinantį {inbound} srautą. Taisyklių sąrašas naudotas pfSense užkardos testuose įkeltas į priedus.

Virtualizacijos ir pfSense sistemos sąveikos testavimas


Siekiant geriau suprasti kuri iš Linux KVM hipervizoriaus palaikomų tinklo plokštės tvarkyklių efektyviausiai – sparčiausiai ir su mažiausiomis sąnaudomis – atlieka Ethernet kompiuterių tinklo paketų apdorojimą, šiame skyriuje analizuojami testų metu surinkti duomenys su skirtingomis tinklo plokštės tvarkyklėmis virtualioje mašinoje:
  • E1000 – programine įranga imituojamos tinklo plokštės tvarkyklės, leidžia prieigą prie bendrinamos fizinės tinklo plokštės;
  • VirtIO – paravirtualizuotos tinklo plokštės tvarkyklės leidžia tiesioginę prieigą prie fizinės, bendrinamos arba dedikuotos, tinklo plokštės;
  • IOMMU virtualizacija – įgalina tiesioginę kreiptį prie sistemos išteklių {PCI passthrough}, VM priskiriama tik jai dedikuota fizinė tinklo plokštė su įprastomis įtaiso tvarkyklėmis.
Skirtingi tinklo plokštės realizavimo būdai KVM virtualioje mašinoje analizuojami tinklo mazgo pralaidumo {throughput}, paketų delsos {latency} ir drebėjimo {jitter} atžvilgiu, kai:
  • pfSense sistema tik persiunčia paketus {forwarding}, paketų filtravimas išjungtas – veikia tik kaip maršrutizatoriaus platforma {routing platform only};
  • pfSense sistema dirba normaliu įsimenamuoju tinklo užkardos režimu {stateful firewall};
  • pfSense sistema veikia specifiniu neįsimenamuoju užkardos režimu {stateless firewall}.
Norint įvertinti virtualizacijos įtaką pfSense tinklo sistemos našumui, reikia ne tik mokėti jį testuoti, bet ir nusibrėžti atskaitos liniją, kuri leis įvertinti virtualizacijos įtaka pfSense sistemai. Todėl kartu su skirtingais KVM virtualizacijos būdais buvo ištestuota pfSense ir fizinės aparatinės įrangos našumas, kuris visose diagramose žymimas HW (nuo angl. hardware) trumpiniu.



"Virtualizacijos įtaka pfSense tinklo užkardos sistemai: našumo analizė" Turinys: